Gérer la création d’un portail web (avec Rebecca Germond de FCV Interactive)

Lisez la transcription :

Nous testons la transcription de nos podcasts à l’aide d’un logiciel. Merci d’excuser toute faute de frappe, le robot n’étant pas fiable à 100 % du temps.

Ben Aston :

Bienvenue sur le podcast DPM où nous allons au-delà de la théorie pour vous donner des conseils d’expert en gestion de projet numérique pour mener de meilleurs projets digitaux. Merci de votre présence. Je suis Ben Aston, fondateur de The Digital Project Manager.

Les besoins des clients évoluent, et le rôle des agences digitales change et évolue également. Comme la conception et le développement de sites web sont devenus plus standardisés, il existe un besoin grandissant d’agences capables d’aller au-delà du simple partenaire web pour devenir aussi des partenaires stratégiques et techniques, afin de construire bien plus que des sites, campagnes ou pages d’atterrissage. Dans le podcast d’aujourd’hui, nous allons nous pencher sur les créations de portails : ce qu’ils sont, comment on les construit, et certains enseignements à retenir si vous vous lancez dans ce type de projet. Restez à l’écoute si vous voulez tout savoir sur l’évolution des agences digitales et sur une approche de développement produit pour la relation client.

Aujourd’hui, je suis avec Rebecca Germond. Rebecca est directrice des services clients chez FCV. Elle a une solide expérience en gestion de projet et en communication médiatique. Rebecca est en fait quelqu’un que j’ai embauché il y a quelques années. Je me souviens de ton entretien où je t’ai fait venir dans la pièce et je me suis dit, ok, je l’embauche direct. Je ne me souviens même plus des questions que je t’ai posées, mais j’étais convaincu. Tu te souviens de l’entretien ?

Rebecca Germond :

Je me souviens de l’entretien. J’avais l’impression d’être passée sur le gril... Non, je plaisante. Je m’en rappelle surtout à cause de la vue depuis le bureau, c’est ça qui m’a convaincue, je pense, en plus de notre discussion évidemment.

Ben Aston :

Ce n’était pas moi alors, c’était la vue !

Rebecca Germond :

Oui.

Ben Aston :

Rebecca, pour ceux qui se demandent ce que tu fais au quotidien, ça consiste en quoi être directrice des services clients ? C’est de la gestion de projet ? De la gestion de compte ? Qu’est-ce que cela veut dire pour toi aujourd’hui ?

Rebecca Germond :

Oui, c’est un peu les deux, plus la gestion de l’équipe de chefs de projet – c’est cool. C’est nouveau pour moi depuis un an environ. Je ne suis plus autant dans l’opérationnel des projets. Il y en a quelques-uns auxquels je reste attachée, mais globalement, je travaille directement avec les PM pour m’assurer qu’ils délivrent et leur apporter le soutien nécessaire. Je gère aussi la plupart de nos clients, donc j’ai une bonne relation de type gestion de compte avec eux. J’ai commencé en gestion de comptes avant d’évoluer vers la gestion de projets, donc c’est un retour aux sources pour moi, ce qui est sympa.

Ben Aston :

Sympa. Pour ceux qui s’intéressent à ce rôle de responsable d’une équipe de chefs de projet : à quoi ressemble ton quotidien ? Comment les manages-tu, sachant qu’on ne peut pas être dans les détails de tous les projets tout le temps ? Quand tu fais un point avec eux, concrètement, tu fais quoi ?

Rebecca Germond :

Oui, bonne question. En général, je révise beaucoup de livrables qu’ils veulent envoyer. Par exemple, je leur donne mon avis sur une SoW ou un planning. Si une escalade a lieu, j’interviens ou je les aide à gérer une situation difficile. Je les vois en one-to-one chaque semaine, mais je garde aussi le contact via Slack pour m’assurer que tout le monde se sente soutenu au jour le jour. Je participe parfois à leurs réunions clients importantes. Bref, un peu tout ça.

Je participe aussi fortement au développement commercial chez FCV. Au quotidien, je gère aussi la question de combien allons-nous facturer à nos clients, et je m’assure du bon suivi de notre processus de gestion des changements. Et puis d’autres choses, les petites activités quotidiennes avec les PM, etc.

Ben Aston :

Raconte-nous un peu ton parcours. Tu venais de l’account management. Je sais que tu as même commencé ta carrière au ministère du Travail. Comment passe-t-on du ministère du Travail à l’agence digitale, à l’account management puis la gestion de projets ? Ça ressemblait à quoi pour toi ?

Rebecca Germond :

En fait, j’étais à l’école, et ma tante a une agence d’intérim. Elle me trouvait des missions quand je cherchais ma voie. Je savais que je voulais travailler en agence. J’ai eu une mission au ministère du Travail, un peu d’administratif gouvernemental, mais c’était sympa. J’ai appris plein de choses sur les rouages du gouvernement, ce qui m’a beaucoup servi car la plupart des projets sur lesquels j’ai travaillé dans ma première agence, puis maintenant chez FCV, concernent le secteur public. Donc expérience très utile.

Elle m’a aussi placée à Manifest Communications à Toronto pour remplacer quelqu’un à l’accueil deux semaines. À la fin, ils m’ont proposé un stage – ce que je visais – que j’ai fait trois mois, puis ils m’ont embauchée pour quatre ans. J’ai commencé comme chargée de compte, donc je gérais les clients mais pas encore des projets digitaux. Petit à petit, ça a évolué. Après un an, je suis devenue aussi productrice, et là ça devenait 60% digital, mais aussi radio, broadcast, print... Expérience super intéressante !

Ben Aston :

Nous sommes encore au premier trimestre : niveau carrière ou développement personnel, tu as des objectifs pour cette année, vu qu’on parle aujourd’hui de portails qui sont une nouvelle étape pour toi ?

Rebecca Germond :

C’est marrant mais non, cette année pas d’objectifs pros précis. Ça peut paraître bizarre, mais je termine la vingtaine et j’ai juste envie de profiter à fond comme une Millennial. J’ai des envies de voyage ! Niveau carrière, j’ai adoré bosser sur ce projet de portail. C’est devenu un produit, on fait sans cesse des mises à jour, on fait évoluer les choses. J’aimerais beaucoup renouveler ce type de projet.

Ben Aston :

Parlons des challenges du moment : de quoi t’occupes-tu principalement ? C’est quoi ton plus gros casse-tête à surmonter au quotidien en ce moment, sur un projet en particulier peut-être ?

Rebecca Germond :

Au quotidien, je suis habituée à « babysitter » mon équipe projet, tu vois ce que je veux dire. En tant que chefs de projet, nous gérons beaucoup d’ego et différentes personnalités. Maintenant, il y a encore plus d’enjeux : moins de projets mais l’organisation entière a des besoins ou des priorités différents. Il faut jongler avec ça tout en s’assurant que les PM aient ce dont ils ont besoin, c’est capital. C’est parfois difficile. Et puis, on se retrouve dans des tâches qu’on croyait anecdotiques, comme de l’admin... Bref : tenir à jour ma propre to-do list est un vrai challenge ces temps-ci.

Ben Aston :

Comment fais-tu pour suivre tout ça ? À quoi ressemble ta to-do list, tu utilises une méthode ?

Rebecca Germond :

J’utilise surtout Evernote, mais on a ajouté une nouvelle intégration Slack : Workast. Ça permet de garder une to-do directement dans un canal Slack et d’assigner des choses aux membres si besoin, ou juste écrire une note pour soi qu’on retrouve dans sa liste à faire. Ça envoie aussi des rappels à l’échéance des tâches. C’est récent, mais ça me plaît bien.

Ben Aston :

Ça s’appelle Workast ?

Rebecca Germond :

Workast, W-O-R-K-A-S-T.

Ben Aston :

Workast, ok. Nom rigolo, Workast.

Rebecca Germond :

Oui ! Pour l’instant, c’est plutôt bien. Le souci, c’est que tu ne consultes ta to-do que très tôt le matin ou tard le soir. 70% de ma journée c’est réunions, téléphones, réponses à des emails ou sur Slack… Pas simple d’être productif en ce moment.

Ben Aston :

Qu’y a-t-il d’autre dans ta boîte à outils PM ? La to-do list est utile pour prioriser ce qui compte mais quels autres outils utilises-tu pour gérer tes projets ?

Rebecca Germond :

J’ai pas mal d’outils. On a testé plusieurs solutions ces dernières années, et désormais, je suis contente de notre arsenal. Comme je l’ai dit, j’utilise Evernote. On utilise Jira très sérieusement maintenant. Toute l’équipe – UX, design et clients – utilise Jira, ce qui centralise tout et permet de suivre les tickets. J’utilise Slack quotidiennement.

On teste aussi Microsoft Teams à la place de Skype for Business, mais juste pour les conférences avec les clients. Ça marche bien. Pour la planification de projets, j’utilise Merlin. On utilisait MS Project mais on n’en exploite que 15 % ... On garde quand même 2-3 licences pour les besoins clients. Spotify est aussi essentiel pour moi. Et puis Outlook, même si l’email est mon calvaire.

Ben Aston :

À part Workast, tu as découvert d’autres outils récemment ou de vraies révolutions dans ta gestion de projet ?

Rebecca Germond :

Pas vraiment. Le gros changement, c’est notre usage de Jira. On utilise des intégrations avec Slack. Quand un ticket est modifié ou qu’un client commente, seules les infos clés partent sur notre canal Slack – car sinon, Jira t’envoie 40 emails/minute ! Franchement, personne ne lit ces mails. MS Teams aussi est une bonne surprise : avant, nos clients refusaient la vidéo, et ils s’y mettent peu à peu.

Ben Aston :

Super. Parlons de ton post, ta première étude de cas publiée, bravo Rebecca !

Rebecca Germond :

Merci!

Ben Aston :

Parlons d’un portail. Un portail, c’est juste un site web ou y a-t-il une vraie différence ? Si oui, laquelle ?

Rebecca Germond :

Pour moi, un portail est bien plus complexe : il est en général pensé pour différents utilisateurs ayant chacun de nombreux parcours, fonctionnalités ou actions. En l’occurrence, il y avait trois niveaux d’utilisateurs à prendre en compte, et la façon dont ils s’influencent entre eux, c’est quelque chose qu’on avait sous-estimé. Les portails sont vraiment complexes à cause de tous ces rouages cachés, que tu n’as pas sur un site classique consulté par n’importe qui en page d’accueil.

Ben Aston :

Donc, en gros, on parle d’une interactivité bien plus poussée, basée sur des rôles et qui active/desactive des fonctionnalités selon l’utilisateur?

Rebecca Germond :

C’est ça. Dans notre portail, sans identifiant, tu ne fais pas grand-chose depuis la page d’accueil. Il y a des barrières, et embarquer de nouveaux clients n’est pas facile. Il y a plein d’aspects complexes qui ne se posent pas sur un site classique.

Ben Aston :

Concrètement, peux-tu donner un aperçu fonctionnel de ce portail ?

Rebecca Germond :

Bien sûr. Notre client est un détaillant d’électronique qui a des clients B2B – des entreprises qui commandent auprès d’eux en gros. Avant le portail, tout se faisait au téléphone, en appelant un gestionnaire de compte pour passer commande... C’était très manuel, pénible pour tout le monde. Ils cherchaient un portail permettant aux clients de se connecter, de voir le catalogue de produits qui leur est réservé et de commander uniquement ces produits-là. S’ajoute un mécanisme compliqué de remise, appliqué selon la quantité ou la nature des achats. Sans le portail, ils pouvaient acheter sur le site grand public, mais comme ils commandent en gros, ils bénéficient de remises très personnalisées selon leurs achats. Voilà un aspect.

On a aussi ajouté une fonction panier, un tableau de bord sur lequel le client voit ses produits commandés le plus souvent, ses commandes en cours, tout ce qui a été passé les 30 derniers jours. Il y a un tas d’outils utiles pour bien visualiser son activité sur le portail.

Enfin, plusieurs niveaux d’utilisateur existent : certains peuvent simplement commander, mais il faut, selon les organisations, qu’un administrateur client approuve la commande avant le traitement, ou la refuse si le budget alloué est dépassé. Donc il y a toute une gestion là aussi.

Ben Aston :

Donc, si je suis une grande entreprise – disons Telus – et que je veux commander 2000 écrans, je me connecte, je commande, un admin approuve, puis je peux suivre ma commande ?

Rebecca Germond :

C’est exactement ça.

Ben Aston :

De l’eCommerce à grande échelle !

Rebecca Germond :

Exactement !

Ben Aston :

Dans ton post, tu parlais d’un choix technologique intéressant. Peux-tu nous donner un aperçu de l’architecture, de la façon dont tout cela a été construit, et ce qui était original dans la solution d’un point de vue PM ?

Rebecca Germond :

Bien sûr. Nos développeurs pourraient mieux en parler, mais voici la vue d’ensemble.

Ben Aston :

La version chef de projet !

Rebecca Germond :

On utilise .NET Core pour alimenter des microservices, avec React en front-end pour afficher ces services. En gros, ce sont des points d’accès réutilisables comme on veut. Par exemple, en récupérant des données de volumes de commandes, ça nous permet de montrer ces stats sur le tableau de bord ou de manipuler ces données autrement, donc c’est super flexible. Nos devs aiment beaucoup React. On a développé une bibliothèque de composants à réutiliser sur tout le site, pour éviter de tout recoder et garantir une cohérence graphique à chaque page, sans se détacher de l’identité du client par rapport à leur site grand public.

Ben Aston :

Donc, il n’y a pas de CMS ? Dans .NET, vous avez créé toute la gestion produit ? Comment ça se passe de ce côté-là ?

Rebecca Germond :

Non, en fait, toute l’info produit arrive d’une API fournie par le client pour leur site grand public. Ces infos produits sont mises à jour en permanence. Un script tourne chaque jour pour nous assurer d’avoir le prix et les spécifications les plus à jour. Donc, l’ajout d’un nouveau produit est entièrement automatisé, ce qui est vraiment top.

Ben Aston :

Génial. Tu parles ici d’un vrai développement produit, donc planification spécifique. Quel était votre processus pour organiser la création du portail ?

Rebecca Germond :

On a clairement opté pour une approche MVP (« produit viable minimal »), qui a ses avantages et ses inconvénients car au fil du temps, l’idée du MVP s’est élargie, ce n’était plus si minimal. Mais au lancement et pour planifier, ce choix nous a aidés. Avec un backlog bien défini dès le départ, on a pu directement commencer les sprints de développement sans trop traîner sur la phase de recueil de besoins. On gérait les besoins en sprint planning meeting pour chaque fonctionnalité à développer dans le sprint à venir.

Ben Aston :

Pour le MVP, il y avait un budget/délai spécifiques ? Comment déterminiez-vous ce qui rentre dans le budget et ce qui n’y rentre pas ?

Rebecca Germond :

Oui, clairement. Le plus difficile en agence sous agile, c’est que les clients veulent un prix pour tout. L’agile authentique, c’est plutôt une facturation au sprint, donc au bout d’un sprint on n’a parfois pas une feature terminée. Nous avons dû estimer chaque fonctionnalité à la carte, pour que le client sache combien coûte telle ou telle option et les priorise si besoin. Certaines fonctionnalités dépendaient d’autres. Une fois la composition du MVP figée, on estimait alors le coût global et les dépendances. Ensuite, pour adapter à la facturation par sprint, on regroupait les features concernées. On avait 5 mois pour terminer, avec 1 mois de recette utilisateur, plus 2 semaines de préparation d’environnement au début. En tout, six ou sept sprints.

Ben Aston :

Tu as mentionné avoir largement sous-estimé certaines features obligatoires, et que c’est ça qui a rendu la chose intéressante. Quelles étaient ces sous-estimations et pourquoi ?

Rebecca Germond :

La plus grosse sous-estimation, c’était la constitution du catalogue et l’application des remises dessus. On pensait juste “on applique une remise sur certains produits”, mais quand on commence à fouiller dans l’API, les catégories de produits, toutes les facettes possibles... Puis la logique des remises par-dessus… ça devient sacrément compliqué. Il fallait aussi parfois exclure certains produits—par exemple : jamais de remise sur Apple, car ils font peu de marge dessus. Donc il fallait filtrer, afficher certains produits, pas la marque Apple, et appliquer/remettre à qui de droit. Très complexe, beaucoup de logique métier à traiter.

Malheureusement, le client avait opté pour une prestation au forfait. On a rattrapé un peu le coup avec des demandes d’évolution (“change requests”) ou des modifications de fonctions déjà prévues. On a vraiment dû être rigoureux sur notre processus de gestion des changements. Mais il est difficile de revenir vers le client en avouant s’être trompé sur une estimation…

Ben Aston :

J’imagine qu’une part de ça vient du fait que certains besoins (par exemple la complexité des remises) n’étaient pas clairs à la base ?

Rebecca Germond :

Exactement ! Au début, la “discount engine” qu’on devait fabriquer était supposée bien plus simple… ça s’est corsé en avançant.

Ben Aston :

Et c’est souvent ça, notamment sur des projets agiles, où le but est justement de s’adapter à l’imprévu… mais il faudrait un modèle de coût qui suive. Donc là, vous étiez en forfait avec des spécifications parfois floues. Avec ton retour d’expérience, comment ferais-tu différemment ?

Rebecca Germond :

On a bien travaillé avec les besoins disponibles. Ce que j’aimerais tester pour la prochaine fois (on s’entend très bien avec le client désormais, il comprend les enjeux, il fait partie intégrante de l’équipe, c’est top), c’est tenter une facturation par sprint. On n’en est pas encore là, mais on a réussi à négocier plus de souplesse sur le planning. Si c’était à refaire, je donnerais une fourchette large au début, afin qu’ils disposent d’un budget à valider en interne. Pendant chaque sprint, on pourrait alors estimer précisément ce qu’on vise et le coût exact en fonction des besoins réels et du staffing. Finalement, je ne changerais pas grand-chose à la dynamique de l’équipe : on était très agiles, peu nombreux, ce qui limite les interlocuteurs côté client et accélère tout. Dès que c’était nécessaire, le seul bon stakeholder était là pour chaque feature de chaque sprint. Super efficace.

Ben Aston :

Parlons justement de cette petite équipe et de l’approche agile hybride évoquée dans ton post. Qui composait l’équipe ? Comment rendre efficace la relation entre design et développement sur ce type de projet ?

Rebecca Germond :

C’est compliqué ! Dans une agence, il est franchement difficile de faire du pur agile, car le client ne paye pas une équipe dédiée sur cinq mois entiers. Il veut surtout savoir combien coûte chaque fonctionnalité, donc il ne “loue” pas une équipe, il achète des fonctionnalités. C’est différent de l’internalisation où les gens sont à plein temps. Du coup, c’est forcément hybride.

On avait dans l’équipe deux dev back-end, deux en front-end, un UX à mi-temps, une designer qui passait valider le créa ou features à l’occasion, un QA mi-temps également (plus dédié sur les phases de test). Pas de business analyst, ce qui ne nous a pas handicapé car on savait ce qu’on construisait, et la connaissance de l’API ne vient pas d’un BA mais du travail avec le client. Pas de stratège non plus, car le produit et le MVP étaient très bien définis par le client, avec un vrai “use case”. Et puis moi, évidemment !

Notre fonctionnement : comme tout partait de zéro, sans composant existant, on s’est basé uniquement sur la charte graphique. Le design et l’UX travaillaient un sprint en avance, ce qui n’est pas vraiment agile “pur” mais se justifiait ici car il fallait créer la confiance du client et valider nos choix design/expérience. En parallèle, le premier sprint pour les devs servait à tout mettre en place, déployer l’infrastructure, etc. Le client avait aussi l’habitude de l’agilité, donc il suivait le rythme, et aimait ce mode de travail. Côté cérémonies agiles, on a vraiment joué le jeu : scrums, démos, rétrospectives, le client participait à tout ou presque !

Ben Aston :

Parlons du client ! L’avantage ici, c’est qu’il faisait office de product owner – un seul stakeholder, c’est génial. Tu dis qu’il était super, mais aussi qu’il a imaginé de nouvelles fonctionnalités en cours de route. Comment as-tu géré ça, avec un budget fixe et une approche agile qui encourage pourtant ce genre de demandes ?

Rebecca Germond :

Ce n’est clairement pas évident ! À chaque nouvelle demande, on lui expliquait que c’était une demande de changement nécessitant un devis dédié, et il comprenait. Par contre, ça ralentit l’avancement « normal » car il fallait arrêter le dev en cours pour l’estimer et obtenir l’accord. Mais globalement, il était super, jouant vraiment ce rôle de product owner, avec toute l’autonomie désirée. Il avait bien préparé son projet, et on a pu lui suggérer des évolutions auxquelles il n’avait pas pensé.

Il a souvent eu de bonnes idées en plein milieu, mais c’était toujours pertinent. Par exemple, initialement, ils envisageaient toujours d’embarquer chaque client à la main, avec PDF d’inscription, etc. Après trois sprints, on a proposé un assistant d’onboarding automatisé : envoi d’email contenant un accès, l’utilisateur configure son mot de passe, télécharge des documents, les réuploade... Ça a vraiment facilité la gestion pour le client, et au final, le produit aussi.

Ben Aston :

Intéressant. Tu as parlé des enseignements à retenir : maintenir l’engagement de son équipe et impliquer le client. Des conseils pour engager client et équipe dès le départ ?

Rebecca Germond :

Pour nous, cette façon de travailler était nouvelle. Beaucoup de nos clients historiques, notamment publics, sont très conservateurs. Mais là, impliquer le client à ce point a eu un impact très positif. On tenait aussi à maintenir son engagement car on voulait une phase 2 derrière ! Ce n’est pas un simple site mais une plateforme “vivante”.

Côté équipe, ils étaient très motivés parce qu’ils ont choisi leur stack technique, bossé sur un projet innovant, utilisé leurs propres outils. Ils appréciaient aussi le contact direct avec le client grâce au Slack partagé, ils pouvaient échanger facilement – selon les profils, ça change tout. En bref, ils se sont investis car c’était un projet qui les passionnait vraiment.

Ben Aston :

Trouver le bon équilibre process / agilité : tu expliques dans ton post que tu as éliminé des process inutiles et renforcé ceux qui comptent. Qu’est-ce que tu as modifié, peut-être abandonné puis réadopté en cours de projet ?

Rebecca Germond :

Oui, par exemple, on a arrêté les rétrospectives sprint après la deuxième, car on avait assez de recul sur ce qui marchait ou pas. Prendre du temps là-dessus privait nos devs de temps précieux. Le client étant très impliqué, il nous donnait ses retours au fil de l’eau. Ce process mis de côté ne nous a pas manqué.

Il était aussi compliqué de tenir des scrums quotidiens entre Toronto et Vancouver. On a préféré des scrums « à la demande », de 15 minutes en visio plutôt que traîner pendant une heure sur Slack...

Ben Aston :

Donc, plus de scrums quotidiens fixes, mais des stand-ups improvisés selon les besoins ?

Rebecca Germond :

Exactement. On visait 9h30, mais au bout de quelques sprints on réunissait l’équipe seulement quand c’était nécessaire, ou via Slack.

Ben Aston :

Est-ce qu’un process supprimé a manqué et vous a poussé à le réintégrer ?

Rebecca Germond :

Pas vraiment, mais on aurait souhaité impliquer plus tôt notre QA. Rien n’était prêt avant le troisième sprint, et on s’est dit qu’on aurait dû le faire avancer plus tôt. Je me souviens qu’on faisait certaines démos à la dernière minute, en espérant que tout fonctionne... On travaillait un peu en « cowboy » sur la fin, mais c’était super fun !

Ben Aston :

Parfait. Merci beaucoup Rebecca pour ta participation. C’était un plaisir !

Rebecca Germond :

Merci, à tout moment !

Ben Aston :

Merci ! Si les portails vous intéressent, allez lire l’étude de cas rédigée par Rebecca, vous y trouverez plein d’informations utiles. Et si vous souhaitez échanger, rejoignez notre équipe Slack. Rendez-vous sur digitalprojectmanager.com/slack pour discuter gestion de projets digitaux avec la communauté ! Si vous avez aimé ce podcast, laissez un avis sur Apple Podcasts (anciennement iTunes), vos retours et avis sont précieux pour nous aider à améliorer l’émission. À la prochaine, et merci de nous avoir écoutés.