Du coup, j'étais en train de dire merci à Alexandre, merci à toute la team du coup French Products déjà de relancer ses meet-up en physique. Déjà, je pense qu'il mérite des petits applaudissements pour avoir relancé tout ça. C'est hyper cool de se retrouver. Et du coup, je suis aussi hyper content d'inaugurer ces nouveaux meet-up pour vous parler d'un sujet qui me passionne et qui me tient à cœur depuis plusieurs années, c'est celui des applications mobiles. On va prendre 45 minutes ensemble pour parler des applications mobiles et vous partager un peu toute mon expérience de ces dernières années. Avant de commencer et de rentrer un peu dans le vif du sujet, je vais en profiter pour me présenter déjà. Je suis Damien, je suis senior lead product chez Mano Mano depuis maintenant un an. Et avant ça, ça fait 10 ans que je bosse, j'ai commencé ma carrière en tant que consultant notamment dans le milieu des médias TF1, Canal+, France TV, pendant 5 ans avant de switcher sur des problématiques de travel et notamment Webus et BlaBlaCar ayant acheté acquis Webus au passage. Et chez Webus, c'est là que du coup, je vais commencer à m'intéresser aux applications mobiles. J'ai eu l'occasion d'avoir des expériences hyper intéressantes chez Webus de mise de mise sur le marché de deux applications mobiles. La première, c'était celle de nos voyageurs pour acheter leur billet de bus et valider leur titre de transport. Et la seconde, c'était celle de nos chauffeurs avec une application opérationnelle pour valider les titres de transport et vendre des billets à bord des bus avec des imprimantes, avec des TPE, etc. C'était l'expérience travel et puis après, je suis parti dans un domaine un peu différent chez Ubisoft sur des problématiques product mais e-commerce abonnement, sur des problématiques web et au bout d'un an et demi, mes premiers amours du mobile m'ont vite rappelé. C'est pour ça que j'ai quitté Ubisoft et je suis arrivé chez ManoMano à l'été dernier. Chez ManoMano, je suis responsable d'une équipe product en lead sur les parties acquisition, rétention. Un des forts volets de la rétention chez ManoMano, c'est les applications mobiles. Quelques chiffres sur les applications mobiles, on est en forte croissance, on est passé de 100 000 téléchargements à plus d'un million 5 en 4 mois, on est en forte croissance sur ces aspects-là et c'est un gros enjeu pour ManoMano de déployer à l'échelle cette application mobile. Rapidement, quelques mots sur ManoMano, quelques chiffres clés déjà, 50 millions de visiteurs uniques par mois, 7 millions de clients actifs, un catalogue de plus de 10 millions de produits, on est une marketplace dédiée au bricolage, au jardinage et à l'aménagement intérieur pour ceux qui ne connaissent pas. On est présent en France, en Grande-Bretagne, en Italie, en Espagne et en Allemagne et nos bureaux sont situés à Paris, à Bordeaux et à Barcelone et surtout partout en France et partout en Espagne grâce au full remote. On est plus de 1000 collaborateurs aujourd'hui et comme toute boîte tech, on a aussi plus de 10 postes ouverts en product, 10 fois aussi pour en parler après mais ce n'est pas le sujet du jour, le sujet du jour c'est les applications mobiles et du coup j'ai construit une structure en 4 points clés qui sont fruits d'observations, parfois d'échecs, on le verra, que je partagerai en toute transparence, évidemment de réussite d'équipe et puis de conseils baglanés tout au long de ces XP, des personnes que j'ai pu rencontrer et qui ont pu aussi m'accompagner dans le virage des apps mobiles. Du coup la structure a été choisie pour être le plus concret possible avec des actionnables qu'on peut rapporter chez soi, des conseils assez simples, on verra que la simplicité ça va être aussi un fil conducteur de la présentation et puis aussi et surtout pour un peu démystifier le monde des applications mobiles qui peut paraître parfois un peu obscur, parfois un peu exclusif et en fait selon moi c'est tout l'inverse, il y a des choses passionnantes derrière donc plus on peut l'ouvrir et plus on peut expliquer ce qu'il y a derrière et le démystifier, le mieux c'est et je serais ravi si ça contribuait à cet objectif avec cette présentation de ce soir. Voilà donc 4 points sur la stratégie produit, sur le cycle de vie, sur le pouvoir des push notifications et sur la qualité. Ces 4 points ont été choisis parce qu'ils sont un peu spécifiques, ils sont spécifiques aux applications mobiles donc évidemment tout ce qu'on va dire ce soir ça se complète aux autres aspects du product management, ça vient en complément mais voilà j'ai voulu zoomer sur 4 clés spécifiques aux applications mobiles. On y va ? C'est parti, première clé du coup c'est sur la stratégie produit, 2 disclaimers pour commencer. Le premier c'est que non, une application mobile c'est pas le copier-coller d'un site web, premier disclaimer pourquoi ? Parce que c'est pour un product manager un enjeu de pédagogie, d'évangélisation important et de management de ses stakeholders aussi, de faire comprendre que sur une app il y a des enjeux de navigation différents, on le verra parfois on n'a pas les mêmes personnages, on ne souhaite pas atteindre les mêmes objectifs donc par défaut non ce n'est pas un copier-coller de notre site web, toujours se poser du coup la question si ce qu'on a en tête ça fait sens sur notre app, le disclaimer 2 il va avec le premier, c'est que oui l'application mobile elle est construite en cohérence avec le site web, le risque c'est notamment quand les équipes mobiles sont dédiées comme on a chez ManoMano, on a des équipes applications mobiles dédiées, c'est d'avoir deux tracks indépendantes qui ne travaillent pas forcément en cohérence et qui managent chacun son canal, sa plateforme plutôt qu'un produit global, donc l'enjeu ça va vraiment être de mutualiser les enjeux app et web mais également tirer toute la puissance aussi de la synergie entre votre web mobile et votre app puisqu'évidemment on va avoir les mêmes complexités de navigation notamment avec les contraintes des devices par exemple, l'idée c'est vraiment de maximiser chacun des canaux pour maximiser la valeur à son utilisateur et pas faire la course à la feature web versus app, donc c'était les deux disclaimers pour commencer qui peuvent être des généralités mais qui sont hyper importantes notamment encore une fois en évangélisation au sein de vos organisations. On va rentrer dans la première clé, c'est comment adapter sa stratégie produit sur une app, on va se poser des questions un peu différemment et notamment on va se poser la première question c'est comment on va créer le réflexe application mobile comme mon utilisateur et pourquoi mon utilisateur va chercher à télécharger l'application plutôt que d'utiliser le site web sur son téléphone, qu'est-ce qu'il gagne, et la seconde question c'est est-ce que mon app apporte assez de valeur pour que je la conserve sur mon téléphone, sur mon téléphone j'ai plein d'app, j'ai très peu de place, est-ce que cette app mérite de rester sur mon téléphone par rapport aux autres, évidemment on touche derrière des aspects d'acquisition et de rétention et en chapeau de tout ça si on a bien suivi les deux premiers disclaimers c'est en quoi mon application elle est complémentaire à mes autres canaux notamment mon site web et pour ça pour se poser ces deux questions il y a deux aspects qui sont importants de garder en tête pour un PM qui travaille sur une application mobile, le premier il est assez structurant c'est la spécificité des utilisateurs qu'on va toucher sur une application mobile, première spécificité c'est qu'ils vont être orientés tâche c'est à dire qu'ils vont chercher à accomplir un but rapidement et efficacement contrairement au web où on aura plus des comportements d'exploration, de renseignement, d'apprentissage avant la conversion sur une app en général on va être plus sur une recherche d'accomplir une action aussi vite et aussi efficacement que possible pourquoi parce que ça va être aussi avec le deuxième point ce qu'il faut bien comprendre que du coup les utilisateurs ils vont être facilement distraits ils vont être facilement distraits pourquoi parce qu'ils vont être sur un usage bien souvent en mobilité entre deux tâches donc très soumis aux distractions donc on doit les garder focus et pour ça pour les garder focus et pour être efficace et rapide on va construire sa réflexion autour de trois piliers qu'on va garder en tête tout au long des étapes de construction de sa stratégie mobile le premier ça va être la simplicité le second ça va être l'utilité et le troisième ça va être la fiabilité du coup la simplicité pourquoi on l'a vu parce qu'on va être orienté tâche on va vouloir être le plus efficace possible l'utilité parce que on va chercher à vouloir retenir l'utilisateur est-ce que l'utilisateur il nous fasse une place sur son téléphone donc il faut qu'on soit utile et fiable on le verra parce que comme tout compagnon on rentre sur un téléphone donc on doit être fiable pour pour rentrer sur le téléphone une fois qu'on a bien bien en tête ces deux spécificités des utilisateurs mobiles et on va on a ces trois piliers en tête et ben on va rentrer dans chacun des piliers on va prendre un peu des exemples de ce que ça veut dire concrètement la simplicité l'utilité la fiabilité rentons dans le dans le dans le premier la simplicité je pris deux exemples enfin trois exemples exemple sur la gauche c'est l'appli binance pour ceux qui sont dans la dans la crypto c'est l'appli binance de gestion de ses cryptomonnaies on voit sur la hausse
par exemple, on a plus de 20 actions possibles, là typiquement on est dans un cas où on a cherché à copier-coller le site web, on a voulu faire entrer toute notre maison dans notre studio, et en termes de charge cognitive pour l'utilisateur, sur la homepage quand il arrive, la charge cognitive est assez forte et on peut très facilement perdre le focus et ne plus être focus sur l'action qu'on cherchait à faire, donc là on est vraiment sur un contre-exemple de simplicité, versus deux exemples que j'ai choisis dans le milieu du transport, pour le coup la première c'est la feature, je pense qu'on est plusieurs à l'utiliser ici, qui est rentrer à la maison de CityMapper, ou sur la homepage en un tap, on a notre itinéraire pour rentrer chez soi, et le second exemple c'est la homepage de l'application BlaBlaCars, difficile de ne pas parler de BlaBlaCars en parlant de simplicité, puisque évidemment je vous renvoie également un très bon podcast de Rémi Guyot, le CPO de BlaBlaCars, qui échange beaucoup sur ces sujets de simplicité, là on est vraiment sur un exemple où sur la homepage on a un formulaire de recherche en quatre champs, donc un bon exemple de simplicité, ne pas hésiter à garder vraiment cet aspect de simplicité en tête, et donc du coup de mesurer l'efficacité des features, et de faire du feature killing, c'est à dire faire du nettoyage aussi dans les features qui ne sont pas ou peu utilisées, donc vraiment toujours continuer de mesurer l'impact de ces features, et l'utilité et l'utilisabilité des features, et de ne pas tomber dans le travers au fil du temps d'avoir une app qui se complexifie, et du coup qui perd le focus de ce premier pilier de la simplicité. Simple du coup mais aussi utile, et ce qui est bien avec les applications mobiles, c'est qu'on va pouvoir utiliser le device pour construire des features qui apportent de la valeur, je dis des features qui apportent de la valeur parce que la tentation quand on a accès au device, c'est de faire des features gadget, avec l'appareil photo, avec le nfc, etc. Du coup toujours se poser la question de l'utilité, et on va voir qu'avec les capacités du device, on va pouvoir faire des choses hyper intéressantes et hyper utiles surtout. Le premier qu'on a en tête c'est d'utiliser la caméra, notamment pour des scans de code barres, l'utilisation derrière évidemment pour se substituer à une recherche, une saisie utilisateur qui peut être longue. On a le second exemple à côté de l'application Maid, qui propose la réalité augmentée pour visualiser son produit dans une pièce, un potentiel levier de conversion. La frontière entre gadget et feature utile est assez mince, donc ce qui fera la différence entre les deux c'est évidemment de mesurer l'impact de cette feature, en aval et en amont, toutes les recherches utilisateurs et est-ce que ça répond vraiment à un besoin. On peut faire confiance à Maid pour que ça réponde à un vrai besoin, mais ici on est typiquement dans des features d'exploration et qui font appel au device. Le second exemple c'est le mode hors ligne, en l'occurrence on est sur l'exemple de MyCanal, mais ça va être souvent intéressant pour prendre en compte le cas d'usage de la mobilité, puisque évidemment sur un smartphone l'utilisateur est en mobilité, et prendre en compte la contrainte qu'en mobilité on n'a pas toujours du réseau, et de conserver votre app fonctionnelle sur ses fonctionnalités critiques, fonctionnelles quand on n'a pas de réseau. Donc ça c'est souvent utile aussi dans le monde du transport. Un exemple du problème qu'on avait à résoudre quand on était chez Webus, c'était comment vérifier la validité des billets de bus quand on est dans une gare souterraine à Bercy sans réseau. On avait vraiment deux problèmes à résoudre, côté client et côté chauffeur. On a utilisé le mode hors ligne à la fois sur l'application client pour télécharger le billet en mode hors ligne à chaque fois qu'il était à chaque achat et à chaque import de billet, pour vraiment que l'utilisateur puisse présenter son billet qu'il ait du réseau ou pas, et également côté chauffeur, de pouvoir télécharger toutes les informations nécessaires quand il avait du réseau, et de se resynchroniser en temps réel dès qu'il récupérait le réseau. Prendre en compte le fait qu'on n'a pas tout le temps du réseau, et le mode hors ligne là-dessus, évidemment il est aussi critique et hyper intéressant à prendre en compte dans la conception. Et le dernier exemple, c'est celui de la géolocalisation évidemment. Là c'est l'exemple de Citymapper, mais qui peut être hyper aussi intéressant, notamment parce que les recherches d'adresses peuvent être assez douloureuses sur la partie mobile. Voilà, c'est trois exemples, il y en a d'autres, il y a évidemment les wallets natifs, pour ceux qui font du e-commerce, Apple Pay, Google Pay, l'accès au contact pour des fonctionnalités de partage, notamment via WhatsApp, le NFC, etc. Et le Bluetooth, également pour les apps opérationnelles, pour appairer avec des devices physiques, je le disais en intro, c'est par exemple ce qu'on a fait à l'époque à Ouibus, quand on a connecté notre application mobile des chauffeurs à la fois des terminaux de paiement type SumUp, et des imprimantes portatives qu'ils avaient à la ceinture. Ça répondait à un vrai besoin, c'était utile, c'était complexe, et du coup je vais délier l'utilité de la complexité, puisque sans doute qu'une des features que j'ai eu l'occasion de déployer la plus utile, c'était loin d'être la plus complexe, c'était par exemple l'activation de la torche derrière le téléphone pour scanner les billets de bus en mode nuit, enfin quand il faisait nuit ou quand il faisait sombre. Donc là en l'occurrence en termes de recherche utilisateur, en termes de design, en termes de spécifications et en termes de dev, évidemment on n'est pas loin d'être sur une complexité monstrueuse, mais en termes d'impact et de gain, on était évidemment hyper bien. L'utilité ça ne veut pas dire forcément la complexité, donc toujours aussi penser simplicité. Une fois qu'on a notre appli qui est du coup simple, utile, il faut aussi qu'elle soit fiable. Pourquoi ? Parce que quand vous êtes sur une application mobile et que votre enjeu ça va être qu'elle soit téléchargée, que l'utilisateur soit engagé, qu'il l'utilise, ça veut dire que vous allez rentrer sur le téléphone de la personne et que vous allez devenir un peu un compagnon, et comme tout compagnon on se doit d'être digne de confiance, et du coup on se doit d'être fiable sur des aspects, il y en a plusieurs, j'en ai cité trois, par exemple protection des données avec des consentements GDPR hyper clairs, explicites, les authentifications à leur compte client en utilisant les capacités du device type Face ID, on a aussi sur Google, et évidemment la qualité de votre app, on y reviendra après, elle va être aussi déterminante dans le fait que l'utilisateur la garde sur son téléphone. L'exemple ici c'est une page d'erreur, je crois que c'est une marketplace de bricolage et de jardinage, typiquement on est sur le cas d'une erreur sur une page de paiement, évidemment on est sur des étapes hyper critiques, donc l'appli elle se doit aussi d'être hyper qualie, et d'éviter au maximum les crashes, on verra, on a aussi des metrics qui permettent de les suivre, sinon évidemment votre taux de désinstallation va comme par magie bondir, et ça c'est ce que tout PM app veut éviter. Et le dernier sujet, travaillez aussi avec vos équipes CRM, ça va être la pression marketing, c'est à dire, vraiment là on est sur un exemple de plusieurs push notifications par jour, multiplié par le nombre d'app qu'on a, ça va être aussi un critère, la pression marketing de choix de l'utilisateur, de garder ou non une app, à garder en tête les trois aspects, simplicité, utilité et fiabilité, et une fois qu'on a designé notre app, pensé notre app comme étant simple, utile, fiable, et bien on va mesurer tout ça, on va mesurer son impact avec des nouvelles metrics, donc ça ne se substitue pas aux metrics que tout PM a l'habitude de suivre, mais voilà, c'est des focus sur des metrics app spécifiques, donc premier volet sur l'acquisition, nombre de téléchargements, nombre d'activations, donc ça va être téléchargement, utilisation de l'app, donc l'engagement de l'utilisateur, le moment où il va l'utiliser pour la première fois, et évidemment le taux de désinstallation, la vue, et une fois qu'on aura acquis et engagé l'utilisateur, on va chercher à ce qu'il utilise notre app le plus fréquemment possible, et travailler les aspects de rétention, notamment avec ce qu'on appelle les monthly active users, donc le nombre d'utilisateurs qui utilisent votre application par jour et par mois, les aspects évidemment revenus, avec des metrics type revenus moyens générés par un utilisateur sur une période donnée, des concepts de LTV, donc de lifetime value, je ne vais pas rentrer dans les détails de ces calculs, taux de conversion, donc là on est typiquement sur des metrics qui se rapprochent des autres canaux, et ce qu'on appelle le revenu mix, donc vraiment le poids que va représenter votre application mobile au sein de votre environnement, au sein de votre business global, selon vos objectifs que vous avez définis auparavant. Et les derniers types de metrics, ça va être la partie qualité, avec notamment votre note que vont vous donner vos utilisateurs sur les stores, on va voir que pour un PM, c'est hyper important, donc c'est une des metrics à suivre de très près, et très régulièrement, et également le nombre d'utilisateurs qui ne subissent pas de crash, ça c'est des infos qui remontent un peu prête à l'emploi dans les stores. Voilà pour le premier point qui était l'adaptation de sa stratégie produit avec vraiment des spécificités.
l'application mobile. Ce qu'il faut retenir c'est aussi simplicité, utilité, fiabilité. Et puis une fois qu'on a pensé ces features selon ces trois principes, il va falloir les déployer parce que votre but c'est que l'utilisateur les utilise évidemment. Mais c'est pas si simple que ça sur une application mobile parce qu'il va falloir comprendre les cycles de mise à jour de vos applications mobiles sur le téléphone. Ça c'est un exemple, c'est l'exemple de nos mises à jour chez ManoMano. On voit qu'à une date donnée, par exemple ici, on avait quatre versions en parallèle de notre app qui représentent la majorité de nos utilisateurs. C'est-à-dire que cette semaine-là, plus de 90% de nos utilisateurs étaient répartis sur quatre apps en parallèle. Et on voit qu'il y en a quatre ou cinq qui sont minoritaires qui partagent les 10% restants. Du coup ça veut dire quoi ? Ça veut dire deux choses. Ça veut dire qu'il faudra gérer plusieurs versions en parallèle, notamment avec toute la complexité que ça peut impliquer, notamment en termes de compatibilité avec des systèmes tiers quand vous avez quatre versions majoritaires en parallèle. Et ça veut aussi dire que quand vous voulez déployer une feature sur une version donnée, il va falloir attendre environ dix jours, une semaine, dix jours pour que ça représente la majorité de votre parc. Donc si on est sur une feature critique, un lancement, etc., il va bien falloir comprendre le cycle de mise à jour pour anticiper au maximum et déployer cette nouvelle version. Évidemment on a aussi des possibilités, on verra plus tard, d'inviter ou de forcer aux utilisateurs à mettre à jour leur application mobile trop ancienne. Donc évidemment à chaque fois que vous allez déployer l'application mobile, une nouvelle version, vous n'allez pas le jour J forcer vos utilisateurs. Mais on peut aussi limiter le nombre de versions en parallèle. Et pour déployer une nouvelle version de votre application mobile, vous allez adopter deux nouveaux outils qui vont devenir un peu vos deux meilleurs amis. Ça va être les stores d'Apple et de Google. La complexité c'est qu'il va falloir maîtriser ces deux outils qui ne sont pas vraiment construits de la même manière et que parfois vous allez avoir des choses en double à faire, évidemment. Dedans vous allez y retrouver tout un tas de métrics, malheureusement qui ne sont pas non plus tout le temps calculés de la même manière. Donc il va falloir s'imprégner de ces règles spécifiques à chacun et notamment sur une des règles principales qui va être le délai de validation de votre app sur les stores. Sur Google, le délai de validation d'une app sur les stores, ça veut dire quoi ? Ça veut dire qu'à un moment donné, vous avez une version de votre app qui est prête, vous allez l'envoyer au store, Google et Android, et les équipes de Google et d'Android vont la valider, vont vérifier certains critères et tant qu'ils ne l'ont pas validée, vous ne pouvez pas l'envoyer sur le téléphone de votre utilisateur, ils ne seront pas disponibles sur les stores. On a une différence entre Google qui met à peu près 2 heures, entre 1 heure et 3 heures, et Apple, ça va de 1 jour et demi à 3 jours, la moyenne est autour de 2 jours. Du coup, ça veut dire quoi ? Ça veut dire qu'il va falloir anticiper ces délais et de bien planifier votre cycle de vie produit en fonction de ces délais, mais aussi et surtout, un petit peu anticiper, ce qu'on n'aime pas trop quand on est PM sur une app, c'est d'être soumis à la validation des stores et de recevoir ce genre de mail qui est le refus de l'app par les stores, notamment ici, on est sur l'exemple d'Apple, ça arrive et bien souvent au mauvais moment, quand on ne veut pas, quand on attend vraiment la future, quand on a vraiment besoin, le dernier exemple en date chez ManoMano de pourquoi on s'est fait refuser une app par Apple, c'est parce que nos captures d'écran qu'on met dans la fiche produit du store n'étaient pas assez fidèles à la réalité de notre app, c'est-à-dire qu'elles avaient été un peu retravaillées, on avait mis des titres, etc., on les avait un peu trop retravaillées et pour ça, notre app, parce que les photos qu'on avait mis de notre app, que vous voyez quand vous allez sur le store, n'étaient pas assez fidèles à l'application mobile, l'application mobile elle-même a été refusée. Donc ça veut dire que vraiment, parfois il y a des critères qu'on n'a pas en tête, donc on apprend, évidemment on a une courbe d'apprentissage par rapport à tout ça, mais il faut toujours se garder de la marge, notamment pour les versions critiques et du fait qu'on dit à peu près 1h, 48h, mais ça peut être plus ou moins, ça peut arriver parfois en pleine nuit. Donc aussi le conseil c'est de toujours cocher cette option qui n'est pas par défaut par les stores, c'est de garder le contrôle sur quand est-ce que l'application va être effectivement publiée, c'est-à-dire que vous n'allez pas dire à Apple, ok dès que vous l'avez validée, vous l'envoyez, ça peut être au milieu de la nuit, donc pour un PM app, on n'aime pas trop ça, donc vous allez vraiment conserver, publier cette version manuellement et garder le contrôle au maximum sur le déploiement. Et puis une fois qu'elle sera déployée, vous allez pouvoir suivre son impact et adapter du coup vos déploiements en fonction notamment d'un critère qui est hyper important pour un PM app, ça va être les rating and review, donc vraiment les notes et les avis que vous donnent vos utilisateurs sur les stores. Pourquoi c'est important ? Parce que c'est doublement important, le premier c'est que ça va être un vecteur d'informations, une source d'informations, mais aussi à la fois un impact, c'est-à-dire que certes vous allez pouvoir vous nourrir des avis, mais également si vous avez un problème sur votre app, ça va très vite rejaillir dans les avis et du coup avoir un impact négatif sur la visibilité de votre app. Là typiquement on est sur un exemple où on n'avait rien dans nos monitorings, rien sur notre analytics, pas de drop important, mais pourtant on commençait à recevoir pas mal de commentaires négatifs, donc on a évidemment commencé à monter un peu le stress force, on a pu aussi contacter certains utilisateurs et très vite déployer un correctif, donc très vite ça veut dire une heure pour Android, ça veut dire deux jours pour Apple, donc évidemment on n'attend pas Apple mais on déploie Android en premier qui représente globalement en Europe la majorité du parc, 60-70%, et du coup ça c'est également une source d'informations assez importante, c'est pour ça qu'un des conseils aussi c'est d'utiliser certains outils qui existent pour pouvoir transférer les reviews en direct sur Slack, vous pouvez avoir des channels Slack où vous recevez quasiment en temps réel l'ensemble des avis qui sont laissés sur votre app, et ça c'est une mine d'informations hyper intéressante pour un PM, et le deuxième conseil ça va être de répondre aux avis et surtout aux avis négatifs, pourquoi ? parce que l'utilisateur a la possibilité non pas de vous répondre, c'est pas une conversation, mais il a la possibilité de changer sa note. Typiquement on est sur un exemple, c'est un deuxième cas où il y a un problème de push notification, donc là l'utilisateur nous avait mis 1 sur 5, on a répondu, donc comme je dis il nous a pas répondu, c'est pas une conversation, en revanche il a changé sa note, on est passé de 1 à 4, juste parce qu'on a répondu sur les stores en lui disant merci de la remonter, on a corrigé, téléchargez la dernière version, et ça c'est un comportement globalement qu'on voit, qui n'est pas rare, donc le deuxième conseil c'est de répondre sur les stores, et le troisième et dernier c'est vraiment en dernier recours, sachez que vous avez toujours la possibilité de réinitialiser votre note, mais pour repartir du bon pied, ça c'est vraiment le dernier recours parce qu'après on a toute l'inertie de nouveau pour récolter l'ensemble des notes et des avis. Voilà pour la partie cycle de vie produit, la troisième clé que je voulais partager ce soir, elle est le fruit de l'onboarding de PM qui ne venait pas du monde des apps, et en fait en discutant avec eux lors de l'onboarding, je me suis aperçu que c'était un point qui était au final assez important quand on est PM d'une app, donc on va un petit peu plonger dans le pouvoir des push notifications, ce que ça vous offre quand vous êtes PM app. Déjà pour bien comprendre de quoi on parle, on va distinguer push notifications et in-app messages, donc évidemment les push notifications on connaît tous, c'est ce qu'on reçoit dans notre centre de notification iOS Android, avec un bon exemple de l'appli France TV ici, avec une bonne nouvelle. Là on parle ici des push notifications, ce qu'il faut savoir c'est que du coup on va avoir une grosse différence entre iOS et Android, où sur Android on peut contacter l'utilisateur par défaut, c'est-à-dire qu'il n'aura pas besoin de donner sa permission, de donner son autorisation de s'obtenir, par défaut sur Android on peut contacter l'utilisateur, là où sur Apple on va avoir besoin de lui demander la permission, c'est cette petite note qu'on voit sur les notes.
Le problème sur Apple, c'est que votre application ne peut le demander qu'une seule fois. Ensuite c'est fini. J'ai partagé une des bonnes pratiques, mais il y en a beaucoup. Vous trouverez beaucoup d'exemples sur le net et beaucoup de littérature sur comment optimiser cette prise de permission. La bonne pratique au global, sans rentrer dans le détail, c'est de la précéder d'un message explicatif de pourquoi on demande cette permission, et de laisser la possibilité de lui dire oui ou non via la croix ou un deuxième bouton. Si l'utilisateur n'est pas intéressé, ne pas lui demander et garder sa possibilité pour plus tard. Et si on sait qu'il a une appétence, à ce moment-là, demander la permission Apple pour maximiser la prise d'opt-in. S'il a répondu non, travailler les scénarios de comment le redemander à un meilleur moment, peut-être après une commande, par exemple pour suivre sa livraison. Travailler vos scénarios de demande de permission. Voilà, c'est la grosse différence entre Android et Apple. C'est assez critique parce que la contactabilité de l'utilisateur, c'est aussi ce qu'on va rechercher notamment pour les problématiques de rétention. Mais au-delà des push notifications, ce qui va être hyper intéressant pour un PM app, c'est ce qu'on appelle les in-app messages. Les in-app messages, on le connaît tous, c'est les petites modales qu'on reçoit à l'intérieur des apps. On a l'exemple bien souvent pour des offres promotionnelles. On a l'exemple de la livraison gratuite sur l'appli ManoMano. On a l'exemple d'un push par NH sur Deliveroo. Et ce qui est intéressant avec les in-app messages, c'est que contrairement à ce qu'on a vu tout à l'heure, les push notifications, les in-app messages, on n'est soumis à aucun consentement. C'est-à-dire qu'à partir du moment où on est dans votre app, considère qu'on peut contacter l'utilisateur et discuter avec lui, ça fait partie, c'est comme une feature. Donc on n'a pas besoin de consentement. Ça, ça va être hyper intéressant parce que du coup, c'est un canal de communication direct avec votre utilisateur qui va vous permettre potentiellement, au lieu de penser features spécifiques, penser in-app messages et voir comment ça peut permettre de répondre à votre besoin pour aller plus loin que ces push promotionnels. Pour un PM app, il y a quatre exemples, mais il y en a d'autres. Le premier exemple, c'est un push in-app qu'on ne veut absolument pas activer. On croise les doigts pour jamais l'activer. C'est l'indisponibilité de votre produit. Là, typiquement, on est sur un push in-app qu'on déploierait chez ManoMano si on a un problème sur notre checkout, un problème de paiement par exemple, etc. On peut le déployer pour prévenir l'utilisateur, plutôt que de le laisser avec un checkout qui ne marche pas, le prévenir et l'inviter à revenir plus tard. Second exemple, c'est un recrutement de user pour un panel. Troisième exemple, c'est celui de l'inviter, voire de le forcer à mettre à jour sa version. On l'a vu tout à l'heure pour réduire la complexité et jouer sur les facteurs. On a vu tout à l'heure qu'on avait quatre versions majoritaires et six ou sept minoritaires. Pour tous ceux qui ont la version en dessous de la version X, on leur envoie ce message et quand on clique sur une mise à jour, globalement, on va sur les stores et on met à jour l'application. Pour un PM app, c'est hyper intéressant. Et le dernier, on parlait de notation tout à l'heure, c'est de pouvoir demander à l'utilisateur de noter son app au bon moment, quand on pense qu'il est satisfait de l'app, de pouvoir lui envoyer ce type de message et de lui demander la notation. Là, typiquement, on peut aller même encore plus loin, on est sur « Appréciez-vous l'application ManoMano ? » « Oui, pas vraiment ». Si on met « pas vraiment », on va aller capter la raison via un formulaire spécifique. Et si on met « oui », on va aller à ce moment-là renvoyer l'utilisateur sur les stores. Ce sont des mécaniques assez classiques dans le monde des apps, mais ça permet aussi d'avoir un levier sur la notation. Encore une fois, pensez à In-App Message, parce que ça a vraiment une vertu hyper intéressante. Et surtout, on peut toucher tous les utilisateurs. C'est-à-dire qu'on n'a pas besoin d'attendre qu'il y ait une nouvelle version, que tout le monde ait la nouvelle version. C'est-à-dire que quand on envoie un In-App Message, on touche tout le monde et on n'a pas besoin d'attendre. Donc ça, pour un PMApp, c'est encore une fois une valeur importante. J'ai l'impression qu'on se rapproche des verts, puisqu'on a la dernière section qui est celle de la qualité. Et la qualité plus que jamais. Pourquoi ? Parce que le premier aspect, c'est qu'on va être dans un monde hyper fragmenté. On en a parlé, on en a vu un petit peu tout à l'heure, sur l'ensemble des versions qu'on avait en parallèle. Mais en fait, on va être dans un monde hyper complexe. Pourquoi ? Parce qu'on va avoir l'ensemble des versions des OS, donc l'ensemble des versions iOS, Android, sur le marché, installées sur les utilisateurs. Premier facteur. Second facteur, on va avoir l'ensemble des devices du parc. Donc l'ensemble des iPhones, l'ensemble des Androids, surtout, sur le marché à l'heure actuelle. Et le troisième facteur, ça va être celui de vos versions de l'app en parallèle, qui sont disponibles et sont installées sur les devices de vos utilisateurs. Donc le premier conseil, c'est qu'on ne maîtrise pas cette complexité, donc on n'essaie pas de la contrôler, sinon ce n'est pas possible. Le deuxième conseil, c'est qu'en fait, si on ne peut pas la contrôler, on peut la maîtriser. Et notamment en jouant sur deux facteurs. On l'a vu tout à l'heure, la version des apps, on peut inviter les utilisateurs, voire forcer les utilisateurs à monter deux versions pour en avoir le minimum en parallèle. Et la deuxième possibilité, c'est de jouer sur les OS également. Donc les OS trop anciens, qui ont plus d'un an et demi, deux ans, on a la possibilité de ne plus les accepter aussi. Donc pour vraiment réduire le nombre de facteurs et réduire le nombre de combinaisons qui sont sur le marché. Et puis, pour assurer la qualité et pour tester notamment, on va faire face à cette complexité. Donc pour ça, évidemment, encore une fois, n'essayez pas de la contrôler, parce que vous ne pourrez pas tester sur l'ensemble de vos combinaisons. En revanche, regardez dans vos analytics, voire par défaut dans vos stores, qui vous donnent des informations assez précieuses là-dessus, et investissez dans un parc de smartphones représentatifs, représentatifs des devices, représentatifs des versions d'iOS, de versions d'iOS ou d'Android, des tailles d'écran, etc. Et puisqu'on ne peut pas contrôler tout ça, on peut aussi, évidemment, et c'est un concept, travailler avec des simulateurs type BrowserStack, mais il y en a plein sur le marché qui vous permettent d'émuler un device, un OS, et une version de l'app en particulier, si vraiment vous avez une complexité, avec une situation en particulier que vous souhaitez reproduire et adresser. Mais du coup, assurer la qualité face à cette complexité, comment ? Autre disclaimer, il n'y a pas de recette miracle. On va évidemment tester, on en a parlé tout à l'heure, avec un parc de devices, avec des simulateurs, évidemment avec le maximum de tests automatiques. On va suivre ces metrics, on l'a vu tout à l'heure, on a nos metrics standards d'un PM, on a aussi des metrics spécifiques app, et utiliser notre dernier levier, des avis qui sont bien souvent une mine d'informations assez intéressante, et prendre les actions nécessaires le plus rapidement possible. Le plus rapidement possible étant tout de même d'être soumis au store. Pourquoi ? Parce qu'en fait, quand vous travaillez sur une app, il n'y a pas de rollback possible. Ça veut dire quoi ? Ça veut dire que si vous avez une application qui rencontre un problème, voire un problème critique, vous ne pouvez pas faire de rollback, donc vous allez devoir attendre la prochaine version, et donc sa validation, qui elle-même peut ne pas arriver. On peut être sur des cycles de 48, plus 48, plus 48, donc vraiment anticiper au maximum, et on verra qu'on a quand même des leviers pour minimiser ça. Et évidemment en termes d'impact, on le disait tout à l'heure, la note et les avis, c'est une source d'informations, mais c'est aussi très vite un impact, et notamment sur ce qu'on appelle l'ASO, c'est le référencement de votre app au sein des stores, quand vous tapez des mots-clés, et ça peut assez rapidement l'impacter. Mais la principale clé en fait, elle n'est pas dans les tests, elle n'est pas dans le parc de device, elle est en fait dans le fait d'accepter l'imprévu tout simplement, et de faire preuve de résilience, et la résilience quand on est PM sur une app, c'est encore plus vrai. Trois exemples pour illustrer l'imprévu. Premier exemple, c'est une discussion avec une PM app dans mon équipe, chez ManoMano, où elle active une bannière promotionnelle, et elle a un écran blanc dans l'app un soir, en fin d'après-midi, donc comme elle me dit, petite surprise du soir, et on voit en fait qu'elle a l'habitude de travailler sur des apps, parce qu'elle n'est pas plus paniquée que ça. Pourquoi ? Notamment parce qu'elle a pensé au feature flag, donc la capacité à distance d'activer ou pas une feature, et ça quand on va travailler sur des apps, notamment de par toute la complexité qu'on a vu tout à l'heure, ça va être hyper important, parce qu'on va s'acheter la possibilité quand même d'interagir directement avec l'app, et de maîtriser un tout petit peu, de minimiser un tout petit peu le...
la complexité de passer par les stores, etc. Le deuxième exemple, il y en a un plus récent, je crois que c'était Julien, chez Air France. À l'époque, on avait Maxime chez Webus, qui faisait des tests de push notification, et il était content parce que ça marchait, sauf qu'en fait, évidemment, c'était en fraude. Donc, accepter l'imprévu, faire preuve de résilience, mais aussi savoir rebondir. Et en l'occurrence, on avait, à l'époque, dans les dix minutes qui suivaient, renvoyé un push notification avec un code Merci Maxime ou quelque chose comme ça, qui proposait 5 euros de réduction sur le prochain achat. Et paradoxalement, c'était une des campagnes qui avait mieux marché. Voilà donc, accepter l'imprévu, être résilient, mais aussi savoir rebondir derrière. Ça fait aussi partie de ce qu'on apprend quand on travaille sur une application mobile. Et évidemment, apprendre de ses fails, les partager et ajuster un peu tout ça. Évidemment, ensuite, on avait revu le cloisonnement des environnements, etc. Donc, il faut savoir rebondir, mais derrière aussi, prendre le recul nécessaire pour faire les post-mortem, ajuster les procédures, etc. Et le troisième exemple, c'était un 23 décembre. Donc, 23 décembre, ça commence à être la forte activité pour le bus, parce qu'on commence à avoir les départs pour Noël. Et on était sur le cas, donc on avait une application native Android. Et comme je disais tout à l'heure, souvent, c'est 1h à 2h Android. Donc, on avait une nouvelle version qu'on voulait absolument mettre, qu'on voulait absolument déployer avant les grands départs qui commençaient à 13h. Donc, on avait pris de la marge, on s'était pris à 7h30, 8h, on s'était dit à 10h, c'est bon. Donc, en fait, un 23 décembre, Google, ils sont comme tout le monde, je pense qu'ils commencent à partir en vacances aussi. Et ça a pris beaucoup plus de temps. Et puisqu'à l'époque, on n'avait pas appris de nos fails et qu'on n'avait pas encore ajouté nos procédures, on n'avait pas coché l'option dont je vous parlais tout à l'heure et on a mis le déploiement automatique. Et en fait, sauf que l'application, Google l'a validée à 12h30, soit pile au moment où tous les passagers commencent à embarquer. Et évidemment, une des rares fois où c'est arrivé, 30% des utilisateurs, des chauffeurs de bus qui utilisaient cette app ont eu un bug critique. Donc, quand vous êtes PMApp, là, l'emoji, celui-là, vous essayez de l'appliquer. Mais évidemment, il faut faire preuve de résilience et savoir rebondir, toujours aussi avoir des procédures de backup. Donc là, en l'occurrence, on avait un petit site Internet à côté qui faisait le minimum. Une fois que ça s'est passé, évidemment, on a retravaillé nos plans de backup et on a ajusté. Voilà, donc c'était les trois situations qui prouvent qu'il faut faire preuve de résilience et que ce n'est pas facile tous les jours d'être PMApp. Mais ce genre de situation, c'est aussi, avec le recul, aussi passionnant à vivre. Voilà, on arrive au bout de ce meetup. En très résumé, du coup, ce qu'on s'est dit, c'est qu'évidemment, la culture mobile, elle s'acquiert. Mais surtout, quand on est PMApp, elle se diffuse et elle se partage au sein de vos organisations. Ce que j'ai appris en passant d'organisation en organisation, c'est qu'il y avait parfois un niveau d'évangélisation très hétérogène parmi... Ça va dépendre de votre culture d'entreprise, etc. Donc, c'est aussi une des cascades du PMApp, d'évangéliser tout ça et de faire comprendre les basiques, de comprendre que, oui, sur iOS, on ne peut pas faire partir un push si on n'a pas le consentement d'utilisateur. C'est aussi le rôle du PMApp d'évangéliser au sein de son organisation. Que l'application mobile, ce n'est pas en parallèle ou contre le web, mais c'est complémentaire au web. Et donc, toujours se poser les bonnes questions et de se poser la question et de penser simplicité, utilité, fiabilité. Et évidemment, on vient de le voir que la résilience, la patience, il faut être hyper patient. Et la rigueur, évidemment, notamment dans la conception, dans les tests, dans votre plan de déploiement. Ça sera évidemment vos meilleurs alliés. Et évidemment, on l'a vu, il y a beaucoup de complexité, mais surtout, je voulais finir aussi par ça, c'est que c'est aussi un bon levier pour un PM, de profiter de cette complexité, de toutes ses spécificités, pour se réinventer, pour pouvoir utiliser les technologies que l'on a déjà utilisées. Donc, il ne me reste plus qu'à vous remercier. J'étais très content de partager un extrait de mes aventures mobiles avec vous sur les quatre clés que j'avais sélectionnées. Et puis, évidemment, je serai encore plus content de répondre à toutes vos questions, maintenant ou autour d'un verre. Je réponds très bien aux questions autour d'un verre, donc n'hésitez pas. Merci à tous pour votre écoute. Je vais faire passer un micro. Si vous avez des questions, n'hésitez pas à lever la main. Je pense qu'on va faire, je ne sais pas, un petit 10-15 minutes de questions et après, on va se faire un petit débat. Donc, je vous dis à tous de vous répondre. Merci. Et puis après, on ira à l'apéro. Première question, c'est toujours la plus dure. Qu'est-ce qui veut se lancer ? Une question un peu technique et très pragmatique en termes de conseils sur l'outillage mis en place pour tester, tu disais, essayer d'avoir des smartphones représentatifs du parc. Mais concrètement, vous faites quoi ? Vous avez un gros rig, toutes les équipes passent dessus. Quelques infos qu'on pourra développer autour d'un verre. Oui, j'ai vu plusieurs choses. Du coup, ça va aussi dépendre, encore une fois, de la maturité de l'organisation et les moyens qu'il y a. J'ai vu des choses différentes entre Webus, entre BlaBlaCar et ManoMano. Aujourd'hui, chez ManoMano, on est en plein dans cette réflexion. Donc l'idée, oui, c'est de construire un parc d'une trentaine de smartphones représentatifs, mais c'est un investissement. Il faut aussi, on a des problématiques derrière, matériels qui sont toutes basiques, mais comment on les stocke ? Maintenant, avec le full remote, comment nos PM ont accès à ces mobiles quand ils sont en full remote ? Donc, en fait, cet aspect-là s'est pas mal complexifié ces derniers temps. Donc, on est en plein dans les réflexions. Après, oui, j'ai vu des organisations qui avaient, en effet, un rack avec plein de téléphones qui étaient à dispo, sécurisés, etc. Mais ça, ça devient un peu moins vrai avec le full remote. Donc, on est, en tout cas, c'est une réflexion plus moyen terme, très court terme, mais en fait, globalement, ce qui marche quand même pas mal, c'est les simulateurs. Et ça permet aussi à tout le monde à distance de s'en servir. Mais c'est le vrai sujet. Enfin, il n'y a malheureusement pas de réponse très facile à cette problématique. J'ai une question de stratégie. À quel moment tu décides, dans ton organisation, de faire une app mobile ? Parce que, par exemple, pour ManoMano, vous avez commencé sur une web app, une version responsive aussi. Et c'est quel élément qui vous a dit, OK, on va investir dans une app ? Et comme tu l'as précisé, il y a quand même pas mal d'investissements parce que c'est complètement différent. Oui, évidemment, ça va être une question, c'est la question qu'on se pose, c'est est-ce qu'on fait une app ou pas ? Et pour ça, en fait, on va se poser la question aussi de, c'est les deux questions que je posais tout à l'heure, c'était, est-ce qu'elle va être utile et est-ce qu'elle va être complémentaire à mes autres produits ? Et qu'est-ce que je vais chercher à atteindre comme objectif avec cette application mobile ? On sait, et notamment dans le milieu du e-commerce, on sait que les applications mobiles, on a une plus forte rétention, on a une tendance à avoir un réachat plus fort. Donc ça peut être un des leviers qui peut aussi pousser à la création d'une app. Mais ça va être bien souvent ta réflexion produit aussi, d'où est-ce que tu veux emmener ton produit au global ? Et en quoi l'app, elle peut être complémentaire avec cet extrait de produit ? Donc, encore une fois, ça va être vraiment, je pense, l'utilité, en quoi ton application mobile, elle t'apporte quelque chose de complémentaire à ton produit ? Et c'est à ce moment-là que tu vas, et qu'est-ce que tu cherches à atteindre comme objectif ? Et à ce moment-là, tu vas décider ou non de faire une app en essayant d'avoir le maximum de data possible pour en effet mesurer le ROI de cet investissement qui est quand même assez important. Encore quelques questions pour ceux qui veulent. Tu parlais d'investissement, justement, c'est quelle part à peu près du budget Product Tech que représentent ces apps mobiles ? Et éventuellement, Android versus iOS, est-ce qu'il y a une différence ? Oui, ça va dépendre aussi de la techno utilisée. Là, chez ManoMano par exemple, on utilise le React Native, donc ça permet de mutualiser pas mal les investissements, parce qu'on ne va pas être sur deux teams, une team iOS, une team Android, comme on peut avoir dans certaines organisations. L'application ManoMano, elle est assez récente, donc ça nous permet d'utiliser cette technologie qui permet de mutualiser pas mal de choses. Après, en termes d'investissement, je ne répondrai pas avec des chiffres précis, mais globalement en termes d'organisation, aujourd'hui, comme je le disais, on est organisé un peu en Impact Team avec des équipes dédiées.
Mutualiser l'ensemble des efforts et tirer au maximum des synergies, et donc de maîtriser les investissements, ça va être aussi de faire appel à l'ensemble de nos future teams, qui travaillent aujourd'hui sur le web, pour participer à l'effort collectif du mobile, et non pas de recréer une deuxième équipe engineering, une deuxième équipe product dédiée au mobile. Je ne sais pas si ça répond à ta question, mais l'idée c'est vraiment d'essayer de mutualiser au maximum les investissements engineering et app. Et aujourd'hui, sur une app comme ManoMano, on a trois PM dédiées, là où sur le web par exemple on en a une dizaine. Peut-être une dernière question ? Quelles ont été les clés principales de la diffusion de cette culture mobile chez ManoMano ? Elle est en cours, puisque c'est assez récent, l'application mobile a un an, mais la clé c'est d'être le plus pédagogue possible et d'expliquer les choses comme on le fait aujourd'hui, et ne pas avoir le biais de penser que c'est évident. Et quand on travaille sur les app depuis un petit moment, on a tendance à penser que c'est évident et que tout le monde devrait tout savoir. Donc ça va être vraiment d'évangéliser, d'expliquer au maximum, un peu comme on le fait ce soir. Et ce meet-up par exemple, je pourrais très bien le faire chez ManoMano. Pour moi la clé c'est ça, c'est d'expliquer, d'évangéliser, à la fois auprès des équipes Product, mais aussi surtout auprès de l'ensemble des stakeholders, et de diffuser cette culture mobile au sein de l'entreprise. Et je pense que pour le coup le Product a un vrai rôle à jouer là-dedans, et si on croit fortement au mobile au sein de l'organisation, c'est un rôle qu'il ne faut pas du tout prendre à la légère. Et là-dessus le Product, on a un vrai rôle à jouer je pense.