Il y a les Product Crew qui ont été lancés, qui sont aussi des mini-communautés de 5 PM qui peuvent échanger tous les mois ensemble et travailler sur des problématiques communes. Donc l'idée c'est vraiment de partager des ressources et de travailler mieux, de s'enrichir des informations des autres, etc. L'association Les Valeurs c'est la gratuité, le travail entre pères et sans prosélytisme. On a de quoi rejoindre la communauté Slack si vous le souhaitez, notre petite pub. Et voilà les chapters régionaux, on a Nantes-Bretagne, nous Renalps, on a Lyon qui est très actif, on est en train de voir si Grenoble aussi est actif, il est en train de lancer des événements sur Grenoble, mais sinon il y a plein de régions en France. Ça c'est l'équipe qui anime la communauté Renalp, pas très intéressant. Et on a du coup des sponsors qui nous aident à animer tous ces événements, qui les financent, donc Sunset Blue, EXACT et Advisory, et ce soir on remercie surtout HomeServe qui nous accueille, qui propose aussi l'apéritif après pour pouvoir continuer à échanger sur les différentes problématiques. Donc merci à eux pour tout ça. Et on a aussi Indie en sponsor local. Et je laisse la parole à Coris, la star de la soirée, pour nous présenter un petit peu toute son expérience sur la transformation digitale qui a été opérée ces derniers mois. Merci. Bonsoir à tous. Je vais essayer de vous raconter un petit peu l'histoire qu'on a vécue ces 18 derniers mois, avec quelques-unes des personnes qui sont présentes. J'espère que ça pourra vous inspirer. On a essayé, dans une boîte qui n'était pas du tout product, de faire du product. Modestement, je pense qu'on a réussi quelques trucs. Pour vous qui êtes des vrais experts du product, tout ça paraîtra extrêmement simple et tout. Pour nous ça a été plein de challenges, mais intéressant. Pour vous présenter, je travaille chez HomeSurf depuis deux ans. Ça fait un temps que je travaille dans le web et beaucoup dans les médias. Auparavant, je faisais un groupe de presse et puis beaucoup chez le groupe WebSkills aussi. J'ai créé dix ans de product. J'ai commencé comme PO, puis je me suis fié là-bas comme formateur, mentor, etc. Puis j'ai été PM, un groupe PM. J'ai passé l'essentiel de ce temps-là. Chez N6Web, qui est devenu Bellrock maintenant. Récemment, HomeSurf. J'ai beaucoup fait de big data, de data science, de machine learning pendant ces dernières années. Mon background, jadis, j'ai été dev. J'ai été journaliste. J'ai une formation de sociologie. Il n'y a rien à voir avec ce qu'on appelle un unifié. Pour vous présenter un peu HomeSurf et l'endroit où vous êtes, parce que ce n'est pas une boîte qui parle à tout le monde. HomeSurf, c'est un groupe européen. On est présent dans six pays. On a 6000 collaborateurs, 3,5 millions de clients qui sont des abonnés, qui payent tous les mois. C'est un groupe européen, mais qui est très décentralisé. En France, on a une activité qui est assez isolée des autres pays. En France, notre mission, c'est de simplifier les réparations et la performance énergétique de la maison. On fait ça avec principalement deux types de solutions, de l'entretien et du dépannage sur différents domaines. C'est la plomberie, l'électricité, le gaz, la serrerie, des choses comme ça. Et puis, une deuxième solution qui est le confort thermique et la performance énergétique de la maison. On existe depuis un peu plus de 20 ans en France. On a environ 250 millions d'euros de chiffre d'affaires. On a 1200 collaborateurs en France, 1,3 million de clients qui payent tous les mois. On a une couverture nationale avec 17 filiales qui font du chauffage, de la clim, de la rénovation énergétique. On a un réseau de 4000 professionnels qui interviennent tous les jours chez les particuliers. Et on fait 250 000 interventions par an. C'est un peu les dents de ligne. On est Best Workplaces depuis pas mal d'années. On a un gros programme RSE en 2030. Donc, ce qu'on a fait ici ces 18 derniers mois, c'est une transformation de product. Donc, c'est une transformation digitale, mais on a fait du product. Pour commencer peut-être pour vous donner un petit peu la timeline et poser un petit peu toutes les grandes lignes, les principales étapes de ce qu'on a fait. On a terminé en novembre 2021 un gros projet de transformation qu'on a conduit grâce à une product team. Et puis autour, on avait une poignée de component team et tout un tas de projets qui ont piloté avec de la PMO. On avait une grosse activité ici qui s'appelle du BAU, donc le Business Residual. Et il y avait un million de sujets qui logeaient là-dedans. Et voilà. Et quand on avait un projet, généralement, on a une idée, on construit une équipe qui mène le projet. En janvier 2022, on débute le projet My Own Serve. Et en fait, on a décidé de le mener sous forme de product team. Et notamment avec l'aide de Cédric qui est juste là. Quelques mois passent. En juin 2022, on initie la troisième product team. Troisième product team en juin. Quelques mois passent encore. Au mois de novembre de l'année dernière, donc c'est pas si vieux que ça, on construit un budget des investissements de la boîte en mode full product team. Donc on dit, OK, l'année prochaine, il y aura huit product teams. Et on a construit pour chacune de ces product teams un budget dans une approche P&L. Donc on a des dépenses, des investissements. Et puis en face, on a mis des objectifs business de revenus. Et toutes les product teams, on les a défendues comme ça. Et voilà. Donc depuis, on a commencé à retravailler la trajectoire de tout un tas de component teams qui sont devenus des product teams. En mars de cette année, on a créé les septièmes et huitièmes product teams. Et on a commencé à mettre à niveau un peu toute l'organisation pour essayer d'arriver à quelque chose d'assez standardisé en termes de product avec des visions dans toutes les product teams, avec des étoiles polaires, des objectifs. Et aujourd'hui, on arrive déjà devant vous. Et puis, on crée l'organisation product. Et on se lance dans un moment encore très long qui consiste à stabiliser tout le modèle et commencer un long chemin vers la maturité des product. Alors avant de vous raconter notre histoire, je pense que c'est intéressant d'avoir un peu de bavarande, de savoir un peu d'où HomeServe vient. Et la culture historique de HomeServe, elle n'est pas trop product, elle n'est pas tout à fait dans ce que vous connaissez peut-être très bien. C'est une culture qui est très verticale, qui est très commande and control, où comme c'est une boîte qui vient d'un historique assurantiel, tout est prédictible. Donc on sait prédire tous nos revenus quasiment sur l'année, mais aussi sur le mois et sur la semaine. Et à chaque fois qu'on a un écart sur ce qui s'est passé cette semaine, on se pose des questions. Voilà, tout est prédictible. Et du coup, le corollaire, c'est qu'on a une aversion au risque très forte. Le moindre truc qui n'est pas prévu, ça ne passe pas très vite. On a aussi une culture de l'ultra spécifique. J'ai une idée, on fabrique une solution qui répond exactement à ça et à rien d'autre. Et puis, une défiance assez globale envers tout ce qui est nouveau. Ça, c'était la culture historique. Si on regarde aujourd'hui, la différence est sans doute assez visible pour n'importe qui qui débarquerait et qui entendrait cette histoire. Donc, si on fait un peu le avant- après, là, en janvier 2022, on avait une product team, six components team. Aujourd'hui, on a huit product team et deux components team. Vraiment, la bascule, elle s'est opérée. Dans la manière dont on vit autour de la tech dans l'entreprise, il y a vraiment eu un changement fort. C'est qu'avant, on avait une relation entre l'équipe business et la tech qui était conflictuelle. Je pense que tous les gens qui ont bossé dans des grosses boîtes un peu historiques ont dû connaître ça. C'était une réalité assez forte chez Omseur et un rapport qui était très client-fournisseur. Aujourd'hui, et ça transpire au quotidien, entre les équipes business et les équipes tech, on est en confiance, on est solidaires, on est bienveillants envers les autres et on collabore tous ensemble autour d'un impact qu'on essaie d'atteindre. Après, d'autres éléments, c'est avant, on résonnait en Kougou, en roadmap, en rétro-planning. Aujourd'hui, on résonne en vision, en objectif, en PNL. Avant, on avait une idée qui donnait lieu à un projet et à un changement.
la création d'une équipe. Maintenant, on a une idée qui devient une initiative dans le backlog d'une équipe qui est déjà en place. Avant, le retour sur investissement était inconnu. Il y avait un compte management qui disait, OK, on investit sur ce sujet. Puis, on avait bien fait tous les trucs qu'on avait prévus. Est-ce que ça a rapporté, pas rapporté ? Une grande question. Aujourd'hui, le retour sur investissement, il est dans les forecasts budgétaires. Dès le début de l'année, on prévoit tous les retours sur investissement dans notre bilan à venir et on les mesure dans le bilan financier à la fin. Les productifs ont contribué tout au long de l'année au bilan de l'entreprise. Et puis, d'un point de vue un peu culturel, je pense qu'avant, on considérait que la tech, c'était un problème. Maintenant, c'est une source de solution. Je crois que c'est la vraie victoire, c'est que tout est devenu vraiment beaucoup plus simple. Le point de départ de cette histoire, c'est une transformation agile qui a eu lieu chez OMSA et qui a été menée pendant plusieurs années, donc avec du coaching, de la formation et toute l'entreprise a été embarquée dans la notion d'agilité. On a créé une première productivité d'ampleur dans un gros projet de transformation de tout le système d'information historique qui était pluridisciplinaire, qui a été construit sur un modèle très inclusif. Il y avait entre 20 et 40 personnes dans la productivité en proportion à une minorité de devs, il y avait vraiment énormément de ventes dans tous les métiers, et puis avec tout un système de gouvernance autour, beaucoup de communication interne autour de cette productivité. Et on a appliqué des méthodes assez standards. On a fait du Scrum avec un backlog. Peut-être un truc un peu étonnant, c'est qu'on n'avait pas de pion de métier, on avait une personne qui a fait la transformation elle-même pendant ce truc-là. Probablement très agile by the book. On a introduit la notion de business value. On a vraiment essayé de construire dans le fonctionnement de l'équipe, la communication et la collaboration by design. Ça, c'est les trois ans qui ont précédé. Je pense qu'il y a quelques limites. Finalement, en arrivant avec une expérience et un regard, j'ai assez vite posé ce diagnostic en disant qu'en fond, il y a quelques limites à ce modèle. Et c'est, de mon point de vue, les limites des transformations agiles, un peu comme on les connaît. C'est des transformations qui se basent vachement sur l'évangélisation. On va prendre des gens qui vont aller convaincre un peu tout le monde pour leur expliquer qu'ils devraient travailler autrement et en fait, faire mener la transformation aux autres. On n'est pas en train de faire, on est en train de faire faire. Et on crée un écosystème où il y a beaucoup de paroles, de convictions et on essaie d'embarquer les gens plutôt que d'avoir un impact hyper concret. Deuxième limite que je vois dans ces modèles-là, c'est autour de la business value. Moi, pendant des années chez Bedrock, j'avais toujours ce bug, parce qu'on parlait de la business value et puis au moment de la définir, en fait, c'était celui qui parlait le plus fort, qui avait un avis hyper convaincu que c'était vraiment ça qu'il fallait faire et pas autre chose. Celui qui était le mieux payé, je ne sais pas quoi. Je n'étais jamais très à l'aise avec ça. Donc, c'est plutôt un truc que j'ai appelé la feeling value. Ça peut être le feeling du chef, mais c'est quand même du feeling, il n'y a rien de rationnel en dessous. Je suis plus tombé par des choses plus data-driven. Et du coup, dans cette démarche, on ne pose pas trop des hypothèses en disant oui, je pense que je peux avoir un impact, j'ai une idée. Est-ce que je suis sûr d'avoir cet impact ? Je fais l'hypothèse que oui, mais peut-être qu'il faut que j'arrive à avoir des moyens de vérifier sans dépenser toute l'énergie pour y arriver et puis on ne donne pas trop le droit à l'erreur parce que du coup, on met un peu les petits plats dans les grandes containes et hop, c'est parti. On lance toute la machine agile, on délivre le truc et idéalement, c'est intérêt de toucher la cible, sinon c'est un problème. Et pour les gens qui sont peut-être plus dans la culture product, ce qu'on fait là, c'est une feature factory. Donc, le succès, c'est d'avoir produit plein de features. Ce n'est pas d'avoir produit rien. Et du coup, on tourne autour de concepts comme la vélocité, le fait qu'on a tenu nos engagements, des choses comme ça. Mais du coup, on est totalement orienté sur une tournoue. Est-ce que ça a amélioré le business ? Est-ce que ça l'a dégradé ? On n'en sait rien. Et d'ailleurs, on ne s'est jamais trop posé la question, on s'en fiche un peu parce qu'on connaît tout. Alors du coup, ici, on a pris une approche différente. Ce n'était pas que volontaire. Au début, j'arrivais avec plein de grandes idées et ça ne s'est pas passé comme prévu, mais du coup, on a fait une transformation plutôt par l'exemple. Donc moi, je suis arrivé mes six premiers mois, je suis allé voir tout le monde, je leur ai expliqué les bonnes pratiques du product, je leur ai dit vraiment que c'est trop bien, vous allez voir, la vie va changer. Je leur ai montré tous les frameworks, je leur ai expliqué la bonne organisation et comment on n'était vraiment pas dans le coup. Et voilà, j'étais un peu comme ce mec-là qui essayait de me dire « venez, regardez ». Et ça a été un gros fail. J'ai appris beaucoup, je n'ai pas réussi à faire grand-chose, mais voilà. Pour les gens à qui j'ai parlé, en fait, cette approche-là était assez déstabilisante, c'était très théorique. J'étais un peu même donneur de leçons, peut-être, pour certains. Pas du tout connecté à la réalité de l'entreprise. Je pense qu'il y en a certains qui se sont demandés si je ne trouvais pas que ma vie d'avant était bien mieux que ma vie d'aujourd'hui, parce que je ne m'étais pas trompé d'endroits. Et puis, moi, j'avais un petit problème avec ça, c'est que ce n'était pas trop moi. Moi, je suis plutôt quelqu'un qui fait les choses et pas quelqu'un qui... Je ne me reconnais pas trop dans les transformations agiles, le coaching, l'émancipalisation, ce n'est pas trop moi. Et du coup, la solution, c'était de se mettre en action. Et la manière dont on a fait ça, c'est qu'on est arrivé à la conclusion avec Frédéric qui est juste là, que probablement qu'en me donnant un mandat limité sur un projet, on pouvait peut-être faire quelque chose de très concret et qu'il allait vraiment changer la donne. Et il a eu raison. Donc, ce qu'on a fait, c'est qu'on a fait un projet qui s'appelle, un produit d'ailleurs, qui s'appelle MyObserve et qui existe toujours et qui a eu beaucoup d'impact ces derniers temps sur l'activité de la boîte. Donc, on a réuni les bonnes personnes sur le bon scope avec la bonne méthode. On a construit une vision grâce au sponsoring de tout notre leadership et de nos execs qui ont été hyper actifs. On a réuni deux product managers expérimentés. C'était Cédric ici présent et moi. On a réuni plein d'experts métiers de la boîte. On a mobilisé tout ce monde autour de la digitalisation de la relation avec nos clients. L'essentiel de la relation avec nos clients encore aujourd'hui est au téléphone et on a voulu la digitaliser avec une approche qui était user-centric. On a construit des étoiles polaires, enfin une étoile polaire à toutes les métriques, ce qui permettait d'évaluer l'impact qu'on avait sur les utilisateurs et on a connecté vraiment tout ce qu'on avait voulu faire et toute notre vision à l'impact et la performance d'entreprise. On a construit une machine de delivery, donc toujours avec nous et les experts métiers et puis avec des développeurs qui étaient déjà là et qu'on a fait évoluer dans ce modèle. On a scientifié l'expérience de nos 1,3 million de clients et puis on a utilisé une approche relativement standard. On a fait du Scrum qui a permis d'avoir un bon outil du point de vue pour le monter en maturité. On a travaillé sur le cadrage avec peut-être une particularité, c'est que notre cadrage, on le pilote en sprint en parallèle du Scrum. Et puis on a intégré beaucoup de key users, on a la chance d'en avoir plein dans la boîte, on a plus de 200 conseillers qui répondent au téléphone. On les a vachement intégrés dans tous nos tests pour qu'ils s'approprient toutes les évolutions qu'on avait faits. Et on a eu un dernier truc, c'est la conduite du changement où on a embarqué des formateurs, des responsables de plateau, des opérationnels de la boîte pour simplifier leur travail. Et là, dans tous ces processus de transformation, on a utilisé des processus qui étaient en place parce que la boîte était déjà relativement bien équipée de ce point de vue. Avec ce bon scope, ce bon mandat, on a construit un peu méticuleusement un succès visible. Non seulement il fallait réussir, c'était un challenge, par rapport à ce qui avait été connu auparavant, on avait des ambitions qui étaient plutôt plus fortes que ce qu'on avait toujours eues et donc réussir, c'était pas gagner. On a tout fait pour réussir et en plus, c'est à rendre ça visible pour essayer de capitaliser dessus. Donc, on a principalement appliqué un modèle qui marche et avec notre expérience, c'est ça qu'on a apporté. Donc, on a posé des objectifs qui étaient clairs, on a vraiment réussi le maillage au niveau leadership entre le business et la tech. Donc, c'était une ambition qui a été vraiment portée conjointement. On a construit un impact extrêmement fort sur l'entreprise, mais qui était mesurable pour l'équipe et pour tout le monde. Donc, c'est ce qu'on a apporté. On a créé une collaboration réelle avec beaucoup d'alignements un peu à tous les niveaux de la chaîne, avec un gros travail sur la transparence, la pédagogie autour de nos méthodes. On a embarqué l'entreprise de manière assez large et pour ça, grâce au sponsoring de notre leadership et de nos execs qui étaient vraiment actifs. Ça, c'est vraiment une chance qu'on a chez Homeserve, les execs, qui aussi habitent ici, les execs de l'entreprise, qui sont dans les étages et qui se mobilisent dans leur quotidien.
On les voit, on leur parle, on les entend et du coup, leur sponsoring qui a été hyper fort a vraiment vachement chaudé. Derrière, on a produit un résultat, c'est qu'on a une relation avec les clients qui a évolué à vue d'œil pour les gens qui bossent dans les étages ici. Le mix entre les canaux, donc entre le téléphone et le digital, c'est des trucs qu'ils ont senti dans leur quotidien et ça a bougé. Leur expérience de collaborateur a vraiment évolué pendant ce temps-là. Et puis, en termes de résultats et d'impact financier, on a été au rendez-vous. C'est un succès. Je pense que le bilan qui retire un peu l'emprisonnement global, c'est que ce qu'on a fait sur My Homeserv, c'est performant. On a été 30 par an, on a généré de la confiance, plein de choses se sont passées plutôt vite par rapport à ce qu'on avait l'habitude de faire. On a eu de l'impact sur le business, mais quand même, malgré tout, la boîte a été aussi regardante sur le délire et est-ce qu'on a vraiment fait des trucs, est-ce qu'on a fait des trucs, tout n'a pas disparu. Mais voilà, comme on avait l'impact, on a pu quand même se desserrer un peu les taux autour de ça et un élément clé de notre succès, c'est le sponsoring du leadership. On a commencé avec My Homeserv et avec un projet, une product team. Et puis, les mois ont passé et on est arrivé à la situation où il y avait des nouvelles idées qui ont émergées et la bonne question de qu'est-ce qu'on fait ? C'est important. Alors, du coup, est-ce qu'on utilise le modèle classique en projet ou est-ce qu'on utilise un modèle plutôt nouveau qui est la product team ? On impose les pour et les contre. Un projet, ça veut dire qu'il faut construire une équipe, choisir un délivré modèle, trouver un PO, cadrer, créer le backlog, monter toute la mécanique de pilotage. Sur ces modèles-là, notre expérience nous dit qu'en gros, on sort les premières features au bout de six mois. Et en interne, le ressenti qu'il y a autour des projets, c'est beaucoup de défiance, beaucoup de frustration, une visibilité assez faible de ce qui se passe et de l'impact qu'on peut avoir. Il y a quand même un peu tout un bagage qui tourne autour de la notion de projet chez Homeserv. Et puis, l'alternative, c'est de faire une product team et plutôt de faire entrer ou de faire entrer une initiative dans une product team existante. Et ça, ça veut dire qu'on peut capitaliser sur une équipe qui existe, même dans un certain nombre de cas, c'est une component team qu'on a un peu fait évoluer et on capitalise quand même sur une dynamique collective. C'est utiliser un délivré modèle qui est déjà en place et qui fonctionne. C'est se reposer plutôt sur des PM de métier. Rentrer dans le backlog et le pilotage qui est déjà complètement en place. Et là, on rentre dans une situation où la première feature, on peut peut-être la sortir au bout de deux sprints. Donc, on gagne beaucoup de temps et du coup, j'ai beaucoup utilisé ça. En gros, soit on monte une équipe et du coup, on va payer tous ces gens qui vont juste se mettre en action pendant six mois ou alors, on ne va pas investir là-dedans et on va juste produire des résultats. Évidemment, ça fonctionne assez bien. Voilà. Et les product teams, grâce au succès de My Homeserv ont un peu une image de confiance, de collaboration, d'utilité, une image assez positive. Toutes les fois qu'on a posé cette décision, bizarrement, la valance a assez facilement penché dans le sens des product teams. Et c'est comme ça qu'on est passé d'une product team à deux, puis trois et ça a commencé à faire des petits. Alors, l'approche qu'on a eue, ça a été d'avancer par étapes. Donc, c'est un peu des petits cailloux où on a posé un caillou et puis un deuxième et puis un troisième et puis on avance comme ça. Au bout d'un moment, ça posait peut-être un petit tas de cailloux et personne ne voit vraiment bien où on va en venir, mais quand même, on sent que c'est en train de dessiner un truc. Et voilà, à la fin, ça commence à prendre forme, mais personne n'avait vraiment vu venir qu'il y avait une logique en dessous de tout ça et que ça voulait dire quelque chose. Donc, ça veut dire qu'on a construit un truc avec une vision, avec une expérience et une approche du product, mais sans expliquer la grande histoire à tout le monde d'abord, mais plutôt en les prenant par la main et en faisant des étapes où ils trouvaient de la valeur, ça marchait pour eux et ensuite, petit à petit, on construit la big picture et c'est ça qu'on a construit. Et ça, ça a fonctionné puisque c'est devenu maintenant le modèle pour tous les projets d'investissement de l'OMSR. Donc, à partir de ce premier succès, et puis des tips que ça a pu faire, on a commencé à construire une organisation centrée sur l'impact et un modèle qu'on peut amener à l'échelle. Je vais vous raconter un peu, on rentre un peu dans la technique du product, mais l'anatomie d'une product team chez OMSR, c'est quoi ? C'est une équipe qui est pluridisciplinaire, qui a une vision, qui a des objectifs, qui a des objectifs, qui est pluridisciplinaire, qui est dédiée, c'est-à-dire qu'on réunit plein de gens qui passent le plus gros de leur temps sur ce produit. Voilà, on sort de la situation où je vais me coordonner avec plein de services différents qui ont tous leurs priorités et ils s'occuperont de mon petit suivi, peut-être dans une semaine. Très présent. Un modèle qui est très inclusif, on embarque beaucoup de gens de l'entreprise auprès de l'équipe et on mélange des anciens de l'entreprise avec toute l'expérience du métier, toute notre culture et des nouveaux qui peuvent apporter des nouvelles pratiques et s'étonner de plein de choses qui nous permettent de grandir dans notre manière de travailler. Donc concrètement, ça veut dire que la product team, on a dans toutes les product teams, un PM, un tech lead, un product designer, un QA, des data analystes, au sein de l'équipe, on a cette constitution-là qui est sans doute assez standard pour l'essentiel d'entre vous, mais peut-être ce qui est un peu différent, c'est qu'on a la logique d'extended team ou très, très près de la product team, on va avoir des experts métiers, des personnes qui travaillent sur les plateaux, des équipes juridiques, des gens de la finance qui sont vraiment déportés dans la product team. On n'envoie pas une demande juridique et puis il y a l'ADN corporat, ils font partie de l'équipe et on se parle hyper régulièrement, on bosse ensemble. Et puis, on implique beaucoup le leadership. Donc, les PM sont en contact direct et régulier avec les directeurs ou les sponsors de l'initiative. Et on implique aussi les execs, qui, du coup, avec une périodicité qui est quand même assez resserrée, qui sont en contact direct de l'équipe et qui sont vraiment en travail avec l'équipe. Et dans la gouvernance, il y a plusieurs trucs, c'est qu'on raisonne avec un empowerment sport de l'équipe. Donc, en fait, l'entreprise a un problème, l'équipe s'occupe de trouver des solutions et de proposer son plan. Les PM ont un leadership sport, à la fois dans leur équipe, mais aussi autour. Vraiment, ils portent toute leur initiative et tous leurs produits et tous leurs impacts vers l'entreprise. On essaye de raisonner plutôt par transparence que par reporting. Donc, l'équipe ne fait pas un reporting pour expliquer ce qu'elle fait. Elle ouvre le capot et elle montre ses artefacts de travail et y compris les execs viennent lire les outils de travail de l'équipe. On est dans une logique de transparence. Le leadership aussi, c'est au service de l'équipe produit. Donc, ce n'est pas je rends des comptes et puis je me fais challenger ou je reçois quelques missiles en passant. C'est plutôt je vais voir le leadership pour obtenir de l'aide sur les trucs qui pourraient m'empêcher d'atteindre mon impact ou de faire avancer mon produit. Et tout ça, on le fait d'abord parce que le leadership qui n'a pas perdu la chef d'entreprise fixe des objectifs et tant qu'on se retrouve sur les objectifs, tout va bien. Ils n'ont pas besoin de micromanager tout ce qui se passe. Le contrat, c'est les objectifs. En termes de démi-livre et modèle, on n'a pas inventé grand-chose. Pour le coup, on a fait du Scrum, évoluant Scrum Bank ou quelque chose d'important. On a considéré que c'était le bon choix et ça l'est encore aujourd'hui parce que c'est des repères connus. L'essentiel des équipes, c'est à peu près où on va. On crée un peu par design la logique de se parler tous les jours, de faire des rituels, d'itérer. Et puis, on se dit que la maturité, ça se construit. Il faut commencer par là. Après, il y a des gens qui font des produits avec d'autres méthodes que le Scrum ou le Canberra ou d'autres choses. Mais avant d'aller là, il faut déjà qu'on développe la maturité. Il y a quelques limites qui sont un peu celles que je disais au début. On n'est pas focus sur l'impact par design. On est vraiment focus dans ces méthodes-là sur le délivery. Et il y a un autre truc, je ne sais pas si vous l'avez vécu quand vous faites du Scrum, c'est qu'on enchaîne les streams et tout. Mais en fait, on ne prend jamais de recul pour se poser sur la vision, sur OK, mais attends, qu'est-ce qu'on a fait de bien ? Qu'est-ce qu'on a fait de mal ? Et puis, on se dit que c'est bon, c'est bon. Ça fait partie des limites qui commencent quand même aujourd'hui à nous frustrer un peu. On verra où on ira autour de ça. Un autre point important pour les product teams, c'est un positionnement qui est user-centric. Donc, là où avant, on était très focus sur les équipes de demandeurs et qui ont fabriqué tous les trucs qu'ils nous demandaient. On mettait une équipe en phase 2. Là, on est très focus sur les équipes de demandeurs qui ont fabriqué tous les trucs qu'ils nous demandaient. On mettait une équipe en phase 2. Là, on a plutôt dit, en fait, nos clients, nos utilisateurs, eux, ils ont une vie avec nous. On va essayer d'être très concentré autour de ça et de fabriquer.
des trucs qui ressemblent à leur histoire. Donc, la vie du client, c'est le monde d'acquisition, c'est sa vie qu'il a avec nous, puisque l'essentiel de nos clients sont abonnés. Et puis, il y a des moments, il y a un moment clé, qui est l'intervention d'un professionnel chez vous. Donc, ça, c'est trois moments clés de la vie. Et sur ces trois moments, on mobilise des productives focalisées sur une partie de chacun de ces moments. Et en transverse, on va avoir l'expérience de nos collaborateurs qui apparaîtront. C'est aussi un cadre méthodologique assez riche. Donc là, on est dans la boîte à outils des products, mais je pense que vous connaissez l'essentiel de ces outils. Donc, on utilise vraiment, je pense, de manière active dans les équipes, la vision board, où on définit qui on s'adresse, quels pain points on adresse, quelles sont les solutions et pourquoi on le fait. On utilise le framework de l'étoile polaire. On utilise énormément le RISE, c'est même un peu le cœur de notre machine, et le confidence meter qui permet d'enrichir le RISE. On résonne en rolling roadmap, on se pose des objectifs stratégiques et puis on a les grosses initiatives de l'année, plutôt par quarter. On utilise, mais en vrai, on espère utiliser plutôt, les OKR. On n'est pas encore tout à fait au rendez-vous là-dessus. On travaille beaucoup en risk management. Donc, on a des objectifs et on se focalise beaucoup sur qu'est-ce qui pourrait nous empêcher d'atteindre ces objectifs. Et l'essentiel de nos discussions avec le leadership sont autour de ça. Et puis, on a construit des logiques de burn-up, où on a notre impact et on progresse vers notre impact. Le point clé dans tout ce fonctionnement, c'est que les contrats qu'on a avec le leadership et l'entreprise, c'est l'impact. Et pour rassurer tout le monde et remarquer tout le monde, on utilise des artefacts de pilotage qui vont leur permettre de voir ce qui se passe et d'être rassurés sur le fait que tout est en train d'être bien fait. Et donc, ils n'ont pas besoin de faire des deep dive et du micro-management. Un autre point qui est important, c'est qu'on réalise l'empowerment des équipes. C'est grâce au focus qu'on a sur l'impact, qu'on a beaucoup entendu parler de l'impact. C'est vraiment la clé de notre succès. Donc, on a une approche qui va un peu dans les deux sens. Donc, on a une approche top-down, où on pose un budget et puis, on construit un P&L sur chaque productivité. Donc, des investissements en payant une équipe et puis des revenus qu'on espère en face. On pose des grandes idées d'initiatives en disant, voilà, en gros, comment on veut orienter la boîte et voilà ce qu'on attend un peu de vous. Et puis, de l'autre côté, l'équipe va travailler, brainstormer autour de ça pour construire tout un tas d'idées, imaginer tout un tas d'idées qui pourraient vraiment nous amener pour cet impact. Et on va matérialiser cette rencontre dans le RISE, dont je parlais tout à l'heure, où on a toutes les initiatives. Et puis en face, on a l'impact. Et ce n'est pas un impact basé sur le feeling. C'est un impact qui, dans l'essentiel des cas, est calculé, basé sur notre vrai business et voilà, on a des chiffres. On construit des chiffres qui sont d'abord des hypothèses, puis une fois qu'on les déploie, deviennent des faits. Et voilà, on travaille vraiment autour de ça. Et très directement collé à notre framework RISE, on a la finance qui intervient, le contrôle de gestion. Donc, c'est eux qui, quelque part, reprennent le RISE et mettent en place les chiffres et utilisent la rolling roadmap qui donne le moment où chaque initiative va sortir. Et c'est eux qui vont construire le beurre neuf qui dit, OK, tu sors cette initiative qui a ton impact à tel moment, ça veut dire ça, puis quand on a glissé, ça veut dire quelque chose. Et on traduit tout ça à la fin en euros pour vraiment arriver jusqu'au résultat de l'entreprise. Ça, quelque part, on parle le langage du business, on parle le langage de l'entreprise, on parle le langage du senior management. Et du coup, avec ça, on arrive à créer la confiance. Parce qu'on est en train de tendre vers le même objectif que eux. C'est ça qui est vraiment important. On commence l'année avec un forecast, donc déjà là pour toute l'année qui vient. On a déjà construit nos forecasts qui disent, OK, en novembre, il va se passer ça et ça produira tel résultat pour l'entreprise. Et puis ensuite, on a juste en permanence, quand les roadmaps bougent, on bouge notre prévision. Et du coup, peut-être que ça peut générer des risques ou des opportunités pour l'entreprise. C'est vraiment dans les bilans financiers. Et tout ça finit dans le compte de résultats de l'entreprise avec des bénéfices qui sont vraiment directement constatés. Donc, on arrive à dire, My Homestead, l'année dernière, ça représentait tant d'euros. Je ne vous dirai pas combien. Peut-être l'artefact qui permet un peu ça, c'est le bar 9 où je fais un zoom. L'idée, c'est vraiment de dire, au fil du temps, il y a de nouvelles choses qui sortent et on s'est fixé un budget et on a une trajectoire en principe qui était prévue pour aller vers ce budget. Et puis après, on va re-forecaster au réel pour savoir si on est en track ou pas. Voilà. Alors, c'est quoi les challenges et les next steps sur tout ce qu'on a fait là ? En termes de challenge, maintenant qu'on est passé quand même à une échelle relative, on a vu le Product Team, il y a un challenge sur la maturité. Ça a un peu copié dans tous les sens. La maturité n'est pas tout à fait égale entre les Product Team. Et d'autant que pas mal des PO ou PM, ou en mutation, ont fait des mobilités internes. Donc, c'est des gens qui ne connaissaient pas le métier. Et du coup, il faut accompagner leur montée en compétences. La compréhension du modèle de Product Team est inégale. Tout le fonctionnement qui tourne autour de l'impact plutôt que du délivré, ce n'est pas maîtrisé par tous. Le discovery, pour certains, c'est un grand principe et une ambition. Oui, j'ai fait ma discovery l'année dernière. Et puis, on n'est pas encore dans une approche très intégrée où ça fait partie du quotidien. Je pense qu'on pourra progresser là-dessus. Pour l'entreprise, comme ça a un peu copié dans tous les sens, maintenant, un peu de lisibilité. C'était très bien quand c'était une Product Team et que les execs pouvaient la suivre de très près, et qu'on était transparent et c'était lisible. Maintenant, il y en a huit, il se passe plein de choses dans plein d'endroits. La communication remontante n'est pas au top. Et la gouvernance aussi, parce que les execs, ils pouvaient se mobiliser régulièrement quand c'était une équipe. Il faut faire huit rituels de huit équipes, une même planning pour eux. C'est la partie de nos challenges du moment. Voilà, donc, nous, on est XTEF. Maintenant, on rentre dans un moment où on veut vraiment stabiliser le modèle. On veut harmoniser le niveau des pratiques, construire la gouvernance, construire la communication remontante, développer les filières RH aussi. Ça veut dire quoi être Product Manager ? Comment on fait grandir les gens dans cette expertise ? C'est quoi la filière Product Design ? Et comment on arrive à devenir fort dans ce domaine-là ? C'est quoi les autres expertises autour du product ? Comment on arrive à augmenter notre rapidité d'itération vers l'impact ? Souvent, on est quand même encore dans le truc de, OK, on a une grande idée. On itère, on fait plein de trucs, mais en fait, on met peut-être plusieurs mois avant de changer d'objectif ou avant de se réajuster. Voilà, la mécanique de cascade un peu descendante des objectifs du top management jusqu'aux équipes et toute la remontée de la formation, c'est encore un peu faible. Voilà, je conclue avec un petit wrap-up. Donc, c'est quoi les quelques points ? S'il faut retenir quelques points, notre méthode, quelque part, c'est ce qu'on a appris. Le premier point, je ne sais pas si je l'ai bien appuyé, c'est l'amorcer de la révolution culturelle. La transformation agile qui a eu lieu chez nous pendant plusieurs années, elle a eu vraiment une vertu, c'est que probablement qu'elle a fait bouger beaucoup les mindsets sur toute la verticalité, tout ce mode de fonctionnement qui était un peu bizarre avec des postilles. Sans doute que cette révolution culturelle-là, elle a eu besoin d'avoir lieu et on n'aurait sans doute pas réussi si elle n'avait pas eu lieu avant. Deuxième point, c'est créer un success case sans faire de la théorie. On se met dans l'action, on fait un truc qui marche. Et parce que ça marche, après, on peut raconter une histoire qui n'est pas de la théorie, qui n'est pas du genre, mais qui est très complète. Baser sur l'impact et créer cette connexion entre le backlog et la finance autour de l'impact, c'est un élément clé. Construire un pilotage qui est vraiment transparent et inclusif pour que, pendant qu'on est en train de faire ça, ce ne sont pas des gens qui font des trucs bizarres dans un coin, mais en fait, on est vraiment embarqué, on comprend ce qui se passe, on nous apprend au fil du chemin, et construire la confiance. Il y a plein de méthodes et de choses là-dessous. Probablement quand même qu'un des éléments clés, c'est qu'on est pote avec les directeurs des business. On se parle quand on n'est pas d'accord, on se le dit, on parle d'une même voix. Cette confiance et ce partenariat qu'on a créé, c'est aussi une histoire d'humains et c'est un élément qui nous vient. Une fois qu'on a créé le success case, répliquer le modèle et continuer à répliquer des succès, à garder vraiment ça, puis scaler la gouvernance afin d'essayer de construire la maturité de l'organisation. Voilà, c'était l'essentiel de ce que...
Je ne sais pas si vous avez des questions, des remarques, des désaccords. Je crois que Maria-Lise a fait les démarches. La première, c'est comment vous avez construit l'étoile polaire de Mayumsa, est-ce que c'est aussi un exercice qui est devenu itératif ou c'est quelque chose que vous avez posé il y a un an, deux ans ? Difficilement. En vrai, si on est honnête, sans embarquer dans le monde, mais on leur donnait l'impression qu'ils étaient hyper embarqués. Je pense qu'en grande partie, avec Cédric, on s'est enfermé, on a dit ok, vas-y, on écrit un truc, ce ne sera pas parfait, mais on écrit un truc. Et puis après, on a fait des ateliers avec plein de gens, on les a fait brainstormer et puis on a fait converger tout ça vers ce qu'on avait écrit. Ça a un peu commencé comme ça, il faut être honnête. Cet exercice de travail sur la vision, ce n'est pas un truc naturel pour plein de gens qui n'en ont pas l'habitude. Même pour des gens qui en ont l'habitude, moi je continue de trouver ça assez difficile, vraiment identifier les utilisateurs, faire un vrai travail sur les pain points, imaginer des solutions en étant quand même ambitieux mais aussi réaliste. Ce n'est pas hyper évident. Maintenant, on commence quand même à répliquer souvent ce truc-là, donc Zakia qui est là, avec qui je ne l'ai fait pas plus tard qu'hier, ou je ne l'ai commencé pas plus tard qu'hier, je pense que ça fonctionne beaucoup plus facilement qu'à l'époque. Une question, je pense que c'est à Nortard, on parle beaucoup de PNM qui vous drive, est-ce que vos Nortards sont formulés avec des impacts PNM ? Oui, c'est même un endroit où on peut encore s'améliorer je pense. Au départ, on est parti dans l'idée que le produit en fait pour changer des comportements utilisateurs et les impacts financiers sont une conséquence. Je continue de défendre cette approche. Il y a quand même un petit principe de réalité parce qu'on a vraiment une boîte qui joue le jeu et qui rentre dedans. Et du coup, à un moment, sur certains sujets, on n'a pas tout à fait parlé le même langage et ça a brouillé la piste. Donc probablement qu'on va un peu hacker les Nortards pour quand même faire en sorte qu'au moins la grosse étoile polaire soit quand même assez traductible facilement en finance. D'abord, merci pour ta présentation et la qualité du support, c'est hyper clair. Ça me ressemble un peu à tout ça. Tu parles du ROI sur les features et je me demande comment t'arrives à mesurer entre les équipes qui ont développé une feature et le fait qu'elle ait une valeur en euros. Sachant qu'entre temps, il y a vraiment un découpage fonctionnel qui est lié à ça et puis il y a ce qu'il y a autour. Et aussi, il y a le temps pour vendre cette feature, donc la responsabilité côté business. Comment vous avez réussi à être au temps main dans la main avec le business de se dire si on a fait la bonne feature. Après, vous avez mis du temps à mettre en place le processus commercial pour le vendre. Aujourd'hui, si on n'est pas au ROI sur cette feature, c'est parce qu'on avait trop de temps. Pour l'instant, par chance, on n'a peut-être pas tout à fait le problème de ne pas être au rendez-vous du ROI. Peut-être que le jour où on ne sera pas au rendez-vous, il y aura plus de frottements. Je pense qu'il ne faut pas se raconter l'histoire. Il faut les construire, les capillaires et c'est du boulot. J'ai passé je ne sais pas combien d'heures dans les tranchées avec les gars du contrôle de gestion à essayer de trouver le truc pour que ça fonctionne. Et encore plus de temps à aller débuguer le résultat à la fin pour être vraiment d'accord avec tout le monde. Aujourd'hui, ce n'est pas juste un truc hyper lumineux où on a posé le truc et tout le monde s'est d'accord. On construit de manière assez itérative où on pousse une idée, on essaye de travailler en finance, on se rend compte que ça ne marche pas tout à fait bien, on itère dessus. Je ne sais pas trop si c'est la bonne situation. Il y a une sorte d'amortissement. Lui, il a eu le sprint. Après la vente, on se dit que le sprint qui suivra, ce sera X millier d'euros. Le sprint qui suivra, ce sera encore X millier d'euros. Là, on raisonne vraiment quasiment de manière financière. On est sur une année, on dépense 1000 sur une équipe, ça nous rapporte 2000. Du coup, à la fin de l'année, le REI est là. On ne fait pas l'initiative par l'initiative. Au total, l'équipe m'a coûté ça cette année. Elle m'a rapporté ça et du coup, ça va. Donc, on ne rentre pas dans le détail. Après, sur comment on calcule le revenu, c'est une situation complexe. C'est intéressant, les différents niveaux en termes de l'équipe produit. Est-ce que tu peux nous parler un petit peu de comment c'était de les inclure, de leur faire comprendre ce rôle d'être invités ponctuellement finalement dans l'équipe produit ? On n'a pas beaucoup expliqué. Je l'ai dit, vous venez et du coup, on va se parler de ça. Merci. Je pense vraiment qu'on n'a pas fait de théorie. En amont, on n'a pas spécialement expliqué. On a dit qu'on a un truc, il faut qu'on bosse, vous venez là et on bosse. Et puis, petit à petit, ils se sont rendus compte. Ah oui, mais en fait, c'est un rituel. C'est un rituel, on se regarde de tel et tel truc pour un tel résultat. Vous n'aviez pas, par exemple, de pousser au début des gens qui disaient je suis là, vous portez-vous auprès de moi ? Je pense que certains ont un peu buggé. Typiquement, dans le leadership, il y a des gens qui ont voulu être recommandés en contrôle. On leur a dit, je comprends, mais du coup, non, je ne vais pas répondre à ta question, on va faire autre chose. Donc, on les a un peu déstabilisés par le moment, je pense. Après, avec un peu de rondeur et en étant sympa et en étant potes avec les gens, ça passe mieux. Je ne sais pas si Cédric, tu as une autre réponse ? Je pense qu'on a quand même des profils de collaborateurs qui sont plutôt proactifs. Je suis arrivé il y a un an et je me suis fait assez étonner. Il y a des gens qui sont en train de comprendre ce qui se passe et porter leur expertise. Ça, ça a beaucoup aidé, notamment les stand-up kings. C'est beaucoup des expérimentiers et des personnes qui ont une bonne compréhension de la boîte. Dès qu'ils ont vu qu'on s'appuie sur eux pour aller chercher de l'information, ça a tout de suite créé le sentiment de « ah ok, je comprends mieux ». Mais si on est à ce côté où ils veulent rentrer un peu trop dans l'information, etc. Non, on n'est pas là pour ça. En l'expliquant, ils ont assez vite eu l'intérêt, très fier, d'être à leur place. Est-ce qu'on attend les deux ? On a encore souvent des « mais c'est quoi votre roadmap ? » On ne sait pas, on verra bien. Ce qui est positivement étonnant chez HomeSurf, c'est que beaucoup des gens avec qui on parle, moi j'étais habitué dans les médias, avec des gens qui arrivaient assez forts de leur certitude et qui te disaient « non, la vie est comme ça, on s'en fout parce qu'elle est comme ça la vie. » Ici, assez facilement, on s'est retrouvé contre des gens qui avaient 15 ans de boîte, beaucoup d'habitude, une expertise forte. En gros, on leur dit « on ne peut pas du tout faire ça, on va faire autre chose ». Ils ont accepté de renoncer à toute leur certitude et suivre un truc. Évidemment, il y a un peu d'humain et on a su raconter un peu le truc pour les embarquer. Mais quand même, assez facilement, plein de gens qui ont abandonné beaucoup de leur certitude et de leur manière d'investir. C'est sans doute aussi facile. D'autres questions ? Merci pour cette présentation. Tu as assez peu parlé de la partie tech. Est-ce qu'il y avait aussi un travail de faire évoluer, tu parlais de PO, BPM, est-ce qu'il y avait aussi un travail sur la partie tech de faire évoluer des politiques anciennes vers… Déjà, de ne pas parler de la tech, une fois que j'ai posé un peu mes idées, je me suis dit que la tech a un rôle important, elle s'est mise au cœur de ce qu'on fait. Du coup, c'est bizarre de ne pas en parler. Le partenariat, il est énorme, quotidien, etc. Probablement, tout ça, c'est beaucoup une évolution sur le pilotage et pas tant sur la manière de développer et de travailler au quotidien dans les équipes. Du coup, je parlais avec un développeur tout à l'heure du Meetup, et à la fois, oui, ils ont vu que plein de trucs étaient devenus plus simples, plus visibles, dans leur quotidien, ça n'a pas franchement révolutionné. Probablement que dans le futur, on va devoir aussi travailler sur la maturité. Aujourd'hui, on travaille en Scrum, je trouve que le Scrum, c'est assez infantilisant pour des devs. On a beaucoup d'autres challenges. Ça fait sans doute partie des limites qui sont du très loin pour nous, où on va avoir besoin que ça mûrisse aussi un peu. On va leur jeter la pierre. Ils ne sont pas là ce soir. C'est une question par rapport à la maintenance. Comment vous êtes organisé ? Par rapport à la maintenance, il y a deux trucs. On va dire toute la maintenance avec des techniques. Il y a ce fameux truc chez UMSR qui est le BMI.
Et du coup, en gros, toutes les petites demandes, mais on ne va pas rentrer au budget ou faire le business case, mais il faut quand même le faire. Ce qu'on essaie de faire là, c'est plutôt de raisonner par principe, où on dit, on a des couloirs qui sont réservés. Donc dans le Product Team, on a 15 ou 20% de la bande passante, donc en gros, il y a un ticket sur cinq qui est de la botte technique. Et l'équipe technique décidera bien de ce qu'il faut y mettre. Si des fois, il faut faire beaucoup plus que ça, faire une refonte, là, on s'en parle, mais tant qu'on reste dans ce couloir, ça fonctionne. Et c'est même un engagement qu'on a en tant que produit vers les équipes, pour dire, la dette, on va s'en occuper, on ne la met pas sur le tapis. Donc ça, c'est le premier point. Et après, les sujets de BAU, pour certains, ça fonctionne comme ça. Je sais que c'est vrai que ça fonctionne très bien comme ça. Sur d'autres équipes, ce n'est pas le cas. On va essayer de construire ce couloir et vraiment le sécuriser, parce qu'il y a quand même des réalités. Il y a plein de trucs qui sont des vieilles plateformes dont personne ne se préoccupe, parce qu'il n'y a pas de nouveautés dessus. Mais pourtant, il faut bien que ça fonctionne pour faire de l'exemple. Il y a une marée à l'exemple, putain. Je voulais juste voir comment t'intègres la dynamique concurrentielle de ton marché, dans tes roadmap, parce que les facteurs clés dessus, ce n'est généralement pas les features, mais c'est un ensemble de features. Il y a aussi l'extérieur. Et la deuxième question corollaire, c'est que je n'ai pas bien compris, si vous n'étiez pas vraiment dans le développement intégré de vos outils, vous aviez juste des products et plein d'autres équipes qui s'appuyaient sur des VRP achetés à droite à gauche. Là, vous avez vu tout ce qu'il se passe. C'est là que ça se passe. D'accord. Et comment est-ce que tu as réussi à combattre le DSI, de te lâcher au-delà d'un POC, c'est joujou, et puis on arrive là. Il se trouve que le DSI, c'est le mec qui m'a embauché et qui m'a tout appris, jusqu'au jour où j'ai commencé à dire qu'on en a un plus que l'autre. Donc, du coup, il était déjà convaincu avant même qu'on se mette en action. Et pardon, j'ai perdu mon fil. Dynamique concurrentielle. Ouais, dynamique concurrentielle. Alors, ça ne doit pas vous arriver souvent, on a une chance chez HomeServe, il n'y a pas de concurrent. Qui propose aujourd'hui des abonnements pour s'occuper de ta maison ? Qui te permet d'avoir, d'une manière hyper simple et unifiée, des artisans qui viennent chez toi ? Il y a deux, trois petites start-up qui ont tenté. Construire un réseau de 4000 professionnels qui intervient tous les jours, c'est juste imposable. Les artisans, déjà pour te décrocher, pour que tu leur vendes la solution, je peux dire que c'est impossible. Donc, en fait, il n'y a quasiment personne d'autre qui le fait. Et ENGIE ? Alors, sur certains segments, on va avoir AXA qui fait certains trucs. Sur les jobs à la demande, on va avoir EDF et ENGIE qui font des trucs. Mais globalement, ils ne sont pas spécialement d'ailleurs dans l'innovation, ils sont juste dans le cas où on déroule un truc. Et du coup, on ne les voit pas vraiment comme des concurrents où il faut suivre et être sur la brèche. Alors, nous, aujourd'hui, le challenge, c'est plutôt comment on exploite au mieux le potentiel qu'on a ? Parce qu'en fait, notre réseau de professionnels et notre capacité à intervenir chez les gens avec un niveau de satisfaction qui est de 98 % après intervention, comment on arrive juste à déployer ça, à le massifier et à l'amener le plus vite possible à un maximum de gens ? Moi, avant de venir chez UMSURF, je ne connaissais pas UMSURF, quand je suis venu ici, je ne m'imaginais même pas que ce soit possible. Il y a une boîte qui s'est envoyé un professionnel avec une quasi-garantie de résultat. Il y a très peu de gens qui savent faire ça en France et du coup, on n'est pas dans cette bataille. Vous avez parlé d'un résultat difficile à vue d'œil avec le premier élection de l'OMSURF. Ma question, c'est par rapport à quand c'est indiqué en spécifique, parce que peut-être les premières pictures sont sorties très tôt, mais à partir de quel moment ? Alors, certains de nos vrais challenges du début, c'est qu'on croyait qu'on avait plein de coups de poing. Il y a eu une époque où on a raconté que dans deux semaines, ça a mis six mois de sortir les premières pictures. D'ailleurs, on a un peu retourné cette histoire en notre faveur, c'est que j'ai montré qu'on a beau être bien expérimenté et savoir combien faire, ça nous a quand même pris six mois d'être dans l'action. Et du coup, on n'a pas envie de payer ça à chaque fois qu'on a une idée. Donc ça, c'est le premier truc. Donc on a mis du temps. Et puis une deuxième partie à ta question. C'était à quel moment il y a eu cet engouement autour de l'équipe ? L'engouement autour de l'équipe, donc au bout de ces six mois, en gros, c'était à partir de la rentrée de l'année prochaine. Là, on a commencé à vraiment mettre en place, à sortir des premières features qui ont vraiment changé la donne. Et très vite, là, on parle de milliers, de dizaines de milliers de traitements de courriers ou de traitements de demandes qui prennent du temps à des gens ici qui n'ont plus. Et d'un seul coup, leur charge de travail, leur pression, c'est vachement réduit. Les clients, un client qui voulait résilier, il attendait peut-être 25 jours avant que la résiliation soit effective. Maintenant, c'est moins de trois jours, voire c'est instantané pour plus de la moitié d'entre eux. Donc, c'est des trucs qui ont été hyper concrets pour les gens qui bossent ici. Et en plus, on voyait l'impact financier de tout ça. Il y avait une main au fond d'abord et puis après toi. Non ? Ah non, j'avais pardon. Pourquoi ça prend six mois ? Alors, pourquoi ça prend six mois de démarrer une équipe ? Même question. Franchement, je pense qu'on n'aurait pas cru. Ce n'est pas du tout l'histoire qu'on avait racontée au début. Je pense que le point de départ, c'est déjà comprendre c'est quoi ce projet ? Qu'est-ce qu'on est censé faire ? Rien que le comprendre. Amener par exemple un PO, c'est une discussion. Et avoir un PO, ça nous prend un peu de temps. Et puis, commencer à amorcer cette discussion. C'est quoi ton idée ? Et pourquoi ? Et comment ? Commencer à amener ça à un niveau de maturité où on peut commencer à poser les grandes lignes d'un cadrage, qu'on puisse commencer à faire des ateliers d'archi, poser une stack techno, puis commencer à avoir des devs qui s'approprient tout ça. Et un backlog qui commence à s'écrire pour qu'on puisse commencer à le fabriquer, qu'on finisse, qu'on teste et qu'on l'envoie. En fait, ça fait pas mal de choses. Et tu prends un mois, deux mois sur chacune des étapes. On pensait que ça irait beaucoup plus vite. On avait notre lot de quick wins qui devait occuper les premiers mois pendant qu'on construisait tout ça. Il n'y en a aucun qui a vu le jour. C'était compliqué. Prochaine question, c'est sur le RICE. Est-ce que tu RICE toutes tes idées ? Ou est-ce que tu as un premier règle créole ? Tu as l'air d'être assez consommateur de temps vu que tu veux être très précis sur l'impact financier de ton RICE. Donc là, le « i » du RICE, c'est uniquement le mortier ? Non, c'est l'impact sur le comportement utilisateur. Par ailleurs, avec une formule, on s'est traduit en financier. On est quand même vraiment sur l'impact sur nos utilisateurs. On a trouvé une manière d'utiliser le RICE à grande échelle. Dans le backlog de MyObserve, aujourd'hui, on a 130 lignes. Et elles sont toutes RICÉ. Mais elles sont RICÉ par itération. Le premier truc, on fait un atelier de brainstorm, on arrive avec 40 idées, on remplit un coup de tableau. Si on veut faire des business case sur tout, on est parti pour 6 mois d'études, d'analyses, et on va jamais s'en sortir. Donc en fait, on fait une première passe où on fait un truc au feeling. En gros, on ne donne pas plus de 30 secondes à chaque idée pour l'évaluer. Même dans le cadre des ateliers de brainstorm, on pose une première pesée qui dit « OK, c'est un gros impact, c'est un petit impact, c'est compliqué, pas compliqué, mais vraiment extrêmement rapide. » Ça permet de créer le tableau dans un premier temps pour dire « OK, il y a des trucs, on a un bon feeling. On sent que là, ici, il se passe quelque chose. Et d'autres, clairement, il ne se passe rien. » Première itération, on va peut-être commencer à explorer sur celles qui émergent en haut de liste, explorer nos datas, notre connaissance, notre research, et consolider un peu ces idées, et dire « OK, quand même, je fais une hypothèse là qui dit que c'est vraiment beaucoup ou pas trop, en fait. » Et on raffine encore pour arriver à un business case vraiment féminin ou en particulier sur My Home Serve, parce que là, on était vraiment sur des actes et des interactions qu'on a déjà avec les clients et qu'on voulait juste faire autrement avec des certitudes. On sait qu'il y a tant de résiliation ou tant de demandes de ce type. Et voilà, go, itérations successives. Merci pour la présentation. Juste une question parce qu'il y a beaucoup parlé de l'impact auprès du business. Mais parfois, pour développer une feature, une société qui va avoir beaucoup d'impact, il peut y avoir plein de manières d'offrir ce parcours à notre utilisateur, à notre client, de l'implémenter, de le mettre en œuvre, de le tester, d'itérer dessus. Et du coup, je n'arrive pas trop à comprendre, est-ce que vous arrivez à mettre des boucles un peu d'itération sur certaines choses, parce que j'ai l'impression que vous mettez tellement d'impact avec la finance, vous essayez d'évaluer le chiffre d'affaires que ça représente et toutes ces choses-là. Du coup, j'ai du mal à comprendre.
à quel moment on peut se dire, le process de résiliation, la pensée comme ça, finalement on se rend compte qu'il faut itérer ou peut-être pour certains utilisateurs c'est mieux de le faire. Comment ça remet cette idée de feedback qui est normalement un peu dans product by the book, on doit itérer par ses retours. De base aujourd'hui, je pense que c'est une de nos zones de faiblesse. On fait des hypothèses, on les déploie, on y va et ça marche pas trop mal quand même. D'abord parce qu'il y avait tellement de trucs à faire qu'on a commencé par des trucs qui étaient tellement des évidences que ça pouvait pas trop rater. Plus le temps avance et plus les évidences sont faites et au plus il faut reprendre. C'est pas hyper naturel et encore plus pour d'autres gens c'est pas la culture. Ça c'est un des trucs qu'on doit intégrer d'ailleurs parce que Cédric il a eu sa première mauvaise surprise récemment. On a investi trois mois dans une feature, on y croyait à fond et il y a eu deux clics au bout de quelques semaines. Et du coup on s'est dit, ah oui en fait s'il avait juste mis le bouton voir s'il y avait des clics c'est tout, on aurait appris mieux. Donc comment on intègre l'itération ? Aujourd'hui si on est honnête, pas beaucoup et c'est un de nos vrais axes de progrès parce qu'au contraire, il faut rendre dans une logique qu'on a des hypothèses, le plus vite possible on arrive à les compter. On utilise de manière assez rigoureuse la confiance basée sur quel matériel permet de définir l'impact qu'on a en face. Donc si c'est juste quelqu'un qui en est convaincu ou si on a envie d'observer des choses, on a des ratés là-dessus. Donc ça c'est un des premiers niveaux, c'est le nouveau. On va monter en confiance en faisant plus de research, en allant tester des choses avant de se lancer pour ne pas trop rater la suite. Mais effectivement oui, il faut qu'on base vraiment notre feedback loop. Je ne sais pas où on est en termes de timing. C'est la patronne ? En termes d'outils vraiment, il faut qu'on en parle. Google Slides beaucoup, Google Spreadsheet aussi. Peut-être dans pas très longtemps, Productboard en explore. Sur les remontées de data, je pense qu'on combine un peu deux sources. Là on a les Google Analytics pour la partie web, sur Pwik. Et puis tout notre coeur de CRM est sur Salesforce. Et donc toutes les demandes, tous les process métiers, on prend dans Salesforce. S'il vous plaît, je vous propose de continuer la discussion.