Gérer la performance dans un projet de tag JavaScript : le récit d’un Product Manager #3.
Je suis Product Manager chez AB Tasty, et aujourd’hui je vous parle du projet d’amélioration des performances de notre tag JS.
Que-quoi ? Vous voulez lire cette conclusion sans avoir lu l’article en entier? 😱 quelle idée !
Conclusion
J’en suis maintenant rendu environ 12 mois après avoir commencé à aborder ce sujet. Et pourtant, est-ce que je peux dire que le “problème de la performance” est résolu ? Dans l’absolu non, ce ne serait pas techniquement honnête. En revanche, la performance de notre tag est aujourd’hui sans commune mesure avec celle d’avant.
Ce simple constat me permet de tirer un certain nombre de conclusions.
La plus triviale est que ce n’était (et ça n’est toujours) pas un projet facile et ce pour plein de raisons : complexité technique, hétérogénéité de l’environnement d’évolution de l’outil, gestion de l’existant et des migrations, etc.
La plus frappante est que la performance est presque devenue du jour au lendemain un sujet phare là où il avait été jusqu’à alors délaissé. Bien sûr, on a toujours eu des utilisateurs nous parlant de notre impact sur les performances, mais ça a toujours été sporadique et généralement sans suites. Maintenant, les temps d’affichage d’un site web font l’objet d’une gigantesque course à l’armement (ou au désarmement des outils tiers) qui a tendance à s’essoufler mais qui a connu un paroxysme que je situerais pour le moment vers le mois de Mai 2021.
En guise de petite note personnelle, j’ajouterais que ça en dit long sur l’hégémonie qui n’est plus à démontrer de Google sur le monde numérique et le web en particulier. Lorsqu’ils décident que leurs mesures de la performance devient le maître étalon, l’intégralité de l’industrie doit s’y plier au risque de subir son courroux. Certains diront que ça nous amène objectivement à un web plus léger, plus rapide, plus agréable et je dois y concéder certaines vérités. D’autres trancheront en pointant du doigt la main-mise de Google sur un pan gigantesque de notre quotidien à tous. Je vous laisse vous faire votre avis !
Et enfin, ma conclusion la plus instructive est évidemment celle qui se rapporte à mon métier de Product Manager : que m’a apprit ce projet, où m’a-t-il fait grandir et quelles leçons j’en retiens pour mes futurs projets ?
Au risque de provoquer un grand nombre de face palm d’évidence, je vous annonce que la Donnée est clée.
Mesurer, détecter, signaler, quantifier, qualifier, bref, avoir de la donnée sur ce qui se passe.
C’est terrifiant de se rendre compte qu’on est le gestionnaire d’un outil qui s’exécute à tout instant sur littéralement des millions de navigateurs à travers le monde et de ne pas avoir d’informations précises et exhaustives sur ce qu’il s’y passe. Imaginez-vous un instant être empris d’un doute, que ce doute puisse signifier que vous impacter négativement un certain nombre de visiteurs. Vous ne savez pas si ce doute est réel ou fantasmé et vous ne savez pas si ça concerne 1 visiteur ou des millions. C’est terrifiant, je vous dis.
Aujourd’hui, je n’aurais pas la prétention de dire qu’on a réglé ce problème car je ne pense pas que ce soit possible d’y parvenir à 100%. En revanche, maintenant je peux dire de manière assez solide que l’on sait un certain nombre de choses.
Les performances sont mesurées de manière précises et comparatives. L’usage de notre outil nous est rapporté quotidiennement, de manière sommaire, incomplète mais suffisante et efficace. L’outil s’auto-analyse et notifie de ses dysfonctionnements (j’ai vulgarisé les termes “catch” et “log”). Des informations cruciales sur la bonne marche de l’outil sont maintenant rapportées à l’utilisateur final dans le Centre de Performances.
Ca va même plus loin : j’ai aussi en charge la gestion d’un autre produit chez AB Tasty : toute la chaîne de valorisation de la donnée collectée pour le compte de nos clients. Là aussi on a pu mettre en route des projets de détection d’anomalies, de mesures d’usages et de contrôles d’intégrité automatisés. D’une gestion quasi à l’aveuglette (je caricature encore pour amplifier mon propos, pas de panique 😁) on est maintenant passé à une gestion de plus en plus mesurée et contrôlée, quitte à être un peu plus lent.
Ensuite, le projet a aussi remis en question ma perception de la facilité d’usage d’un produit. Oui, bien sûr qu’un produit doit être le plus simple possible à utiliser, même s’il s’adresse à des personnes techniques. Tous les progrès qu’a fait l’industrie en matières d’UX est un soulagement considérable. Ca permet de se concentrer sur sa tâche plutôt que sur son outil. Plus le produit est sans couture, meilleur sera son adoption et plus large sera son usage.
MAIS, bien sûr il faut nuancer. Simplifier ne signifie pas dégrader.
Prenons l’exemple du vélo fixie. Pour ceux qui ne connaissent pas, un vélo fixie est un vélo sans freins, sans vitesses. C’est littéralement un vélo avec lequel lorsque vous pédalez, vous avancez, lorsque vous arrêtez de pédaler, vous vous arrêtez. Pas de câbles, pas de transmission complexe, pas de lubrification, pas de “boutons” au guidon. La simplicité a son paroxysme.
Maintenant, mettez tous les cyclistes sur des fixies, et je peux vous garantir que vous allez en faire suer plus d’un (dans les deux sens du terme), encombrer les urgences inutilement et vous risquez surtout de ne pas favoriser la Solution Vélo (et là je peux vous dire que ce serait un drame).
On en revient au même : la simplicité va causer de gros problèmes de performance !
Trouvez toujours la solution la plus simple et qui ne va pas dégrader vos autres indicateurs importants. Votre solution idéale doit être une combinaison de plusieurs éléments. Le mieux est parfois l’ennemi du bien, ne l’oubliez pas !
Si c’est ardu, ce n’est pas grave. Persistez et continuer à chercher, vous finirez par trouver. Faites des détours, multipliez les solutions (tout en restant raisonnable) et employez vous à ajouter de la complexité intelligente et invisible pour l’utilisateur final.
La solution retenue doit rester simple à l’usage mais efficace en arrière plan.
Rappelez-vous que la solution peut être de déformer un usage, de le conduire ailleurs si nécessaire, mais le statu quo ne résoudra rien.
Enfin, parlez et faites parler des obstacles. Le rôle d’un Product Manager est, entre autre, de favoriser l’émulsion. Les autres seront toujours plus compétents que vous sur un nombre considérable de sujet. A force de détricoter un sujet, vous en tirerez plein d’idées, des bonnes comme des mauvaises. A vous ensuite de les choisir, de les raffiner et de les orchestrer…
Evidemment que dans ce sujet il y a eu des couacs, des bugs et des fausses bonnes idées. Mais on les a accepté, corrigé et maintenant on ne les fait plus.
J’ai l’impression que cette conclusion est très bateau, mais probablement que c’est toujours utile de rappeler des choses simples.
Merci de m’avoir lu 🙂
