Septembre a toujours été un mois de reprise. Pour les équipes digitales, cependant, reprendre est devenu plus complexe que de rouvrir Jira et de s’attaquer au premier élément du backlog.
Les cycles de release sont plus courts, les produits évoluent en continu, les attentes des clients changent et les expériences digitales dépendent de plus en plus d’écosystèmes complexes mêlant appareils, systèmes d’exploitation, intégrations et services tiers. L’IA ajoute une nouvelle couche d’accélération, en permettant de concevoir, tester et itérer plus rapidement qu’auparavant.
Dans ce contexte, une roadmap définie avant l’été peut encore être parfaitement pertinente en septembre. Mais elle ne devrait pas être considérée comme automatiquement valide.
Un backlog garde la trace de ce qu’une équipe a décidé de faire. Il ne nous dit pas nécessairement si les éléments qui ont conduit à cette décision sont toujours d’actualité, si le problème a évolué ou si une hypothèse auparavant raisonnable est devenue une source de risque.
Alors, avant de se demander « Sur quoi devrions-nous travailler en premier ? », une autre question mérite d’être posée :
Qu’est-ce qui doit être vrai pour que nos priorités du T4 réussissent et à quel point sommes-nous certains que c’est toujours le cas ?
Toute décision produit repose sur des hypothèses.
Une équipe qui repense son onboarding peut supposer que réduire les frictions augmentera le taux de complétion. Une équipe qui travaille sur le checkout peut penser qu’une étape spécifique est responsable des abandons. Un Product Manager qui priorise une nouvelle fonctionnalité peut s’appuyer sur des demandes récurrentes de clients. Une équipe QA peut décider de concentrer ses tests sur les appareils et les parcours historiquement associés aux risques les plus élevés.
Rien de tout cela n’est inhabituel. Les équipes Produit ne peuvent pas attendre de disposer d’informations parfaites avant d’agir.
Le problème commence lorsque les hypothèses deviennent progressivement impossibles à distinguer des faits.
Lorsqu’une idée devient une epic, se voit attribuer une priorité et trouve sa place dans un trimestre, elle acquiert une certaine permanence. L’équipe voit le travail à réaliser, mais les éléments qui avaient initialement justifié son importance deviennent moins visibles.
C’est particulièrement problématique, car un backlog n’a jamais été conçu pour être statique. Atlassian décrit le product backlog comme un artefact « vivant », qui doit être mis à jour à mesure que de nouvelles informations apparaissent. Ses recommandations sur le backlog refinement vont dans le même sens : le refinement est un processus continu au cours duquel les priorités sont réévaluées en fonction des retours et de la valeur business.
Autrement dit, modifier le backlog lorsque les éléments disponibles évoluent n’est pas un écart par rapport aux bonnes pratiques de product management. Cela en fait partie.
Le même principe s’applique au-delà des méthodologies Agile. Dans la Harvard Business Review, Stefan Thomke, professeur à la Harvard Business School, et Gary Loveman défendent une approche plus scientifique du management : remettre en question les hypothèses, formuler des hypothèses testables, expérimenter et laisser les résultats faire évoluer la décision.
Un ticket terminé nous indique que quelque chose a été livré. Une fonctionnalité mise en production nous indique que quelque chose est arrivé jusqu’aux utilisateurs.
Mais ni l’un ni l’autre ne nous dit, à lui seul, si le problème initial a été correctement compris ou si le résultat attendu a été atteint.
Quelques semaines loin du rythme opérationnel habituel peuvent sembler insuffisantes pour remettre en cause une stratégie.
Et souvent, elles le sont.
Mais la roadmap n’est pas la seule chose qui compte.
Pendant que les priorités restent sur un planning, les utilisateurs continuent d’interagir avec le produit. De nouveaux tickets de support s’accumulent. Les outils analytics collectent de nouvelles données comportementales. Des releases introduisent des changements. Les concurrents lancent de nouvelles alternatives. Les sources d’acquisition évoluent. De nouvelles versions des systèmes d’exploitation apparaissent. Les priorités business changent.
L’idée n’est pas de considérer que tout a changé.
Mais les équipes devraient savoir ce qui a changé avant de partir du principe que rien n’a changé.
C’est particulièrement important pour les expériences digitales, car le produit lui-même n’est qu’un des éléments qui déterminent l’expérience.
Un checkout peut être techniquement identique en juin et en septembre alors que les personnes qui l’utilisent, leurs attentes, les sources de trafic ou la répartition des appareils ont évolué. Un parcours performant dans certaines conditions peut se comporter différemment dans d’autres.
Comme nous l’avons exploré en nous intéressant aux produits utilisés dans des conditions réelles, les utilisateurs interagissent rarement avec les services digitaux dans l’environnement contrôlé dans lequel ils ont été conçus ou testés. Ils changent de réseau et d’appareil, font plusieurs choses à la fois, sont interrompus et rencontrent des situations difficiles à reproduire en interne.
L’été rend certains de ces changements particulièrement visibles, mais le principe reste valable toute l’année : le contexte fait partie de l’expérience.
Pour les équipes qui reviennent à la planification du T4, la conséquence est simple. Avant de vérifier l’état d’avancement du travail, il vaut la peine de vérifier si les éléments qui ont motivé les décisions sont toujours valables.
Imaginons qu’une équipe ait priorisé la refonte d’un checkout parce qu’une étude menée neuf mois auparavant avait identifié des frictions au moment du paiement.
Ces résultats sont nettement plus solides qu’une simple opinion interne.
Mais sont-ils encore suffisants ?
Le checkout a-t-il changé depuis l’étude ? Les moyens de paiement utilisés ont-ils évolué ? Les mêmes problèmes apparaissent-ils aujourd’hui dans les analytics ou les demandes adressées au support ? Le problème se produit-il toujours sur les appareils et dans les environnements qui comptent le plus ?
Les données ne deviennent pas soudainement inutiles parce qu’elles datent de six ou douze mois. Leur pertinence dépend de l’évolution du produit, de son audience et du contexte depuis leur collecte.
Une étude portant sur un workflow B2B relativement stable peut rester pertinente pendant longtemps. Les conclusions concernant un parcours grand public qui évolue rapidement peuvent nécessiter des vérifications beaucoup plus fréquentes.
La question n’est donc pas simplement « Avons-nous des données ? », mais plutôt : « S’agit-il toujours des bonnes données pour la décision que nous devons prendre aujourd’hui ? »
Ces éléments peuvent être récents et directement observés à travers des données comportementales, de la recherche utilisateur ou des tests. Ils peuvent être plus anciens mais toujours pertinents. Ils peuvent être indirects, issus des échanges avec le support, des retours des parties prenantes ou de signaux du marché. Ou une analyse plus attentive peut révéler qu’un élément que tout le monde pensait établi n’a en réalité jamais été véritablement validé.
Rendre ces distinctions visibles peut considérablement changer une discussion sur les priorités.
La plupart des roadmaps intègrent déjà une forme de priorisation basée sur l’impact, l’effort, l’urgence ou la valeur stratégique.
Ce qu’elles rendent moins souvent visible, c’est l’incertitude.
Imaginons qu’une équipe aborde septembre avec trois grandes priorités pour le T4 : améliorer l’onboarding, repenser une partie du checkout et développer une fonctionnalité régulièrement demandée par les clients.
Les trois peuvent sembler parfaitement raisonnables. La discussion habituelle portera sur les ressources, l’impact attendu et les dates de livraison.
Mais avant de les classer par ordre de priorité, une autre question mérite d’être posée :
Qu’est-ce qui doit être vrai pour que chacune de ces initiatives fonctionne ?
Prenons l’onboarding. L’hypothèse de départ pourrait être que les utilisateurs abandonnent le processus parce qu’il comporte trop d’étapes.
Cela semble plausible. Et c’est peut-être effectivement le cas.
Mais le nombre d’étapes n’est peut-être pas le véritable problème. Les utilisateurs ne comprennent peut-être pas pourquoi certaines informations leur sont demandées. La friction peut apparaître plus tôt dans le parcours. Ou les utilisateurs peuvent tout simplement ne pas percevoir suffisamment de valeur pour aller jusqu’au bout.
Une équipe pourrait donc réussir à raccourcir son onboarding sans pour autant améliorer son taux de complétion.
C’est ici que l’incertitude devient un critère de priorisation utile.
Au lieu de regarder uniquement l’impact attendu et l’effort nécessaire, les équipes peuvent intégrer deux variables supplémentaires : à quel point sommes-nous confiants dans cette hypothèse, et que se passerait-il si elle était fausse ?
Une hypothèse peu étayée mais aux conséquences limitées peut être parfaitement acceptable.
Une hypothèse importante, soutenue par des éléments solides et récents, ne nécessite pas nécessairement une nouvelle phase de recherche.
La zone la plus intéressante se trouve là où une faible confiance rencontre des conséquences importantes.
Pour le Product, cela peut être la conviction qu’une fonctionnalité demandée répond réellement au besoin du client.
Pour l’UX, l’hypothèse qu’un comportement observé lors d’une étude précédente représente toujours les utilisateurs actuels.
Pour la QA, cela peut concerner les workflows, intégrations, environnements ou appareils présentant le plus de risques avant une release importante.
Dans ces situations, la recherche et les tests cessent d’être des activités réalisées uniquement après la conception ou le développement d’une solution. Ils deviennent des outils permettant de réduire l’incertitude avant que les décisions coûteuses ne soient prises.
Il existe une autre raison de réexaminer les éléments disponibles avant que l’exécution du T4 ne s’accélère : ils sont souvent fragmentés au sein de l’organisation.
Le Product peut se concentrer sur les métriques d’adoption et les indicateurs business. L’UX dispose peut-être de données qualitatives issues de la recherche. La QA peut observer des bugs récurrents et des edge cases invisibles dans les analytics produit. Le Customer Support sait quels problèmes génèrent régulièrement de la frustration. Les Sales entendent des objections et des demandes qui n’apparaissent parfois jamais dans un dashboard.
Chaque source décrit une partie différente de la réalité.
Prenons un parcours produit dont le taux de conversion diminue.
Les analytics peuvent montrer où les utilisateurs abandonnent, sans nécessairement expliquer pourquoi. La recherche utilisateur peut révéler de la confusion, des attentes ou des motivations, mais une étude qualitative ne permet pas à elle seule de déterminer l’ampleur d’un comportement. Les tests QA peuvent révéler un problème fonctionnel affectant un environnement particulier sans en montrer l’impact commercial global.
Regarder ces signaux ensemble permet d’obtenir une vision plus complète que d’attendre d’une seule source qu’elle fournisse toute la réponse.
Il existe également un bénéfice organisationnel : les données donnent aux équipes cross-fonctionnelles une base concrète autour de laquelle s’aligner.
On peut observer cet effet dans le cas Lottomatica, où les équipes UX, Product et Market Research ont travaillé de manière itérative avec les utilisateurs, en passant d’un premier test d’utilisabilité à des modifications du design, puis à leur validation. La recherche a permis à l’équipe de confirmer certaines hypothèses tout en identifiant des problèmes dans des domaines qui ne semblaient pas critiques au départ.
Cette distinction est importante.
Les données sont utiles non seulement parce qu’elles nous apprennent quelque chose sur les utilisateurs. Elles donnent également aux différentes fonctions un point de référence commun pour prendre des décisions.
« Validons cette hypothèse » peut donner l’impression d’ajouter une nouvelle phase à une roadmap déjà bien remplie.
Ce n’est pas nécessairement le cas.
La méthode doit être adaptée à l’incertitude.
Si la question concerne un comportement, les analytics existants contiennent peut-être déjà une partie de la réponse. Si l’équipe doit comprendre les motivations ou les attentes, une recherche qualitative peut être plus appropriée. Si l’incertitude concerne la compréhension ou l’interaction, un prototype peut être testé avant le développement. Si le risque est technique, des tests exploratoires, de compatibilité ou en conditions réelles peuvent révéler des problèmes que les environnements internes contrôlés ne permettent pas de reproduire.
Parfois, des interactions apparemment mineures méritent d’être étudiées parce que leur impact sur l’utilisateur ou le business est disproportionné.
Dans le projet Nexi Mobile POS, par exemple, la recherche utilisateur s’est intéressée à des aspects très spécifiques de l’interaction avec un pavé numérique, notamment à la visibilité et à la compréhension de certaines commandes. La taille d’un élément d’interface ne reflète pas nécessairement son impact sur l’expérience globale.
Et parfois, les tests confirment simplement que l’hypothèse initiale de l’équipe était correcte.
C’est également utile.
Lorsqu’une initiative est sur le point de mobiliser un temps de développement important ou d’influencer un objectif business majeur, renforcer la confiance dans la décision sous-jacente a une valeur en soi.
Il existe un dernier risque à prendre en compte avant le début du T4 : les données ne conservent pas toutes la même valeur au fil du temps.
Une équipe Produit peut prendre une décision parfaitement raisonnable à partir de recherches, d’analytics ou de tests, puis devoir la réexaminer quelques mois plus tard. La question n’est pas de savoir si les données initiales étaient bonnes, mais si les conditions dans lesquelles elles ont été collectées sont toujours comparables à celles d’aujourd’hui.
Une release importante peut modifier le comportement des utilisateurs. Un nouveau canal d’acquisition peut attirer un public différent. Des changements de prix, d’authentification ou de moyens de paiement peuvent transformer un parcours établi. De nouveaux appareils, mises à jour de systèmes d’exploitation et intégrations tierces peuvent introduire des conditions techniques qui n’existaient pas lors de la définition de la stratégie de test.
C’est pourquoi une prise de décision fondée sur des données ne doit pas être confondue avec le simple fait d’avoir des données. Ce qui compte, c’est de savoir si les informations disponibles sont récentes, pertinentes et adaptées à la décision à prendre.
Pour les équipes qui abordent le T4, cela permet de faire une distinction utile entre les décisions qui doivent être entièrement repensées et celles qui ont simplement besoin d’être vérifiées.
La plupart des priorités passeront probablement ce test. Certaines auront besoin d’éléments plus solides. Quelques-unes pourraient finalement chercher à résoudre un problème qui a changé, disparu ou qui n’avait jamais été complètement compris.
Identifier ces quelques priorités est précisément là où se trouve la valeur.
Tout cela ne signifie pas qu’il faille passer les premières semaines de septembre à rouvrir chaque décision prise avant l’été. Cela créerait une autre forme d’inefficacité.
Une approche plus utile consiste à se concentrer sur les initiatives qui combinent le plus fortement impact business, incertitude et coût d’une mauvaise décision.
Pour chaque grande priorité du T4, les équipes devraient pouvoir expliquer quatre choses :
Quel problème essayons-nous de résoudre ?
Quels éléments nous indiquent que ce problème existe toujours ?
Sur quelles hypothèses notre solution repose-t-elle ?
Quelles nouvelles informations pourraient réellement modifier notre décision ?
Si les réponses sont claires, le backlog peut remplir exactement son rôle : transformer les priorités en actions.
Si elles ne le sont pas, déplacer un ticket vers In Progress ne fera pas disparaître l’incertitude sous-jacente.
C’est sans doute la façon la plus utile d’envisager la reprise de septembre. L’objectif n’est pas de ralentir l’exécution ni de remettre en question la roadmap pour le principe. Il s’agit de s’assurer que la dernière partie de l’année, souvent la plus intense, commence avec des priorités qui reflètent toujours la réalité en dehors de l’organisation.
Car un backlog est utile pour se souvenir de ce qu’une équipe avait prévu de faire.
Ce sont les faits qui permettent de savoir si c’est toujours la bonne chose à faire.
Vous avez des hypothèses à valider avant d’accélérer sur vos priorités du T4 ? Avec UNGUESS, confrontez-les à de vrais utilisateurs et testez vos produits dans des conditions réelles, avant d’investir du temps et des ressources dans la mauvaise direction.