Centraliser ses insights pour ne plus perdre ses données client grâce au Research Repository

Combien de tests A/B votre équipe a-t-elle relancés cette année sans savoir qu'ils avaient déjà été menés, gagnés ou perdus ?

À mesure qu'une équipe multiplie les tests, la connaissance client se disperse : une analyse dans un Drive, un thread Slack introuvable, un deck de restitution jamais rouvert. Le paradoxe est cruel : plus vous faites de recherche, plus vous risquez d'en perdre le bénéfice.

Dans la littérature UX Research internationale, la réponse à ce problème porte communément le nom de Research Repository. Chez Welyft, on l'appelle également Insight Repository parce qu'il met l'accent sur ce qui compte vraiment : pas la donnée brute elle-même, mais ce qu'on en tire.

Les deux désignent la même réalité : une base de données centralisée qui rassemble les données, insights et recommandations issus de vos travaux de recherche utilisateur, pour les rendre retrouvables et réutilisables par d'autres membres de l'organisation bien après la fin du projet qui les a produits. Ce n’est pas un outil de plus à ajouter à la pile, c’est une discipline : faire de chaque test, de chaque verbatim issu de tests utilisateurs, de chaque plainte du support client, de chaque résultat de sondage et de chaque audit un actif réutilisable plutôt qu’un livrable jetable. Un insight non partagé (et donc introuvable) est un insight perdu.

Le coût de l'amnésie organisationnelle

Une organisation CRO mature fait tourner des dizaines de tests par an, plusieurs consultants ou PM sur un même produit, parfois plusieurs marchés. Sans mémoire collective structurée, cette activité génère un coût caché que peu d'équipes mesurent vraiment.

Ce problème d'infrastructure de la connaissance ne fait que s'aggraver avec le temps : plus une organisation accumule de tests sans structure pour les organiser, plus l'écart se creuse entre ce qu'elle sait réellement et ce qu'elle est capable d'en exploiter.

Les 4 piliers de l’Atomic Research

La méthodologie de référence pour structurer la donnée s'appelle l'Atomic Research, théorisée par le designer Daniel Pidcock. Son principe : plutôt que de stocker des rapports entiers illisibles six mois plus tard, on découpe chaque apprentissage en briques élémentaires, indexables et recherchables indépendamment du projet qui les a produites. C'est cette architecture que nous utilisons en interne pour construire nos propres bases de connaissance.

1. Les Experiments

Ce sont les méthodes utilisées pour collecter de la donnée, qu'elles soient qualitatives (interviews clients, tests d'utilisabilité, retours du support, observation, card sorting) ou quantitatives (tests A/B, web analytics, sondages, données transactionnelles, analyse des tendances de recherche).

2. Les Facts

Les facts exposent le quoi révélé par les experiments. Non interprétés, ils prennent trois formes : l'observation ("les visiteurs prennent 5 minutes pour compléter le formulaire"), le verbatim ("je n'arrive pas à me repérer dans le menu"), ou la statistique ("le taux d'ajout panier est 50% plus élevé pour les visiteurs qui utilisent les filtres sur les pages de listing"). Un fact ne provient que d'une seule expérimentation et n'est jamais directement actionnable seul.

3. Les Insights

Un insight combine plusieurs facts, souvent issus de plusieurs expériences différentes, pour expliquer le pourquoi derrière le quoi.

4. Les Recommendations

C'est la traduction opérationnelle : ce qu'on décide de faire de l'insight. Un bon réflexe consiste à viser plusieurs recommandations possibles pour un même insight, pas une seule, en pensant itération et derisking. Une recommandation peut aussi répondre à plusieurs insights à la fois, et rien n'empêche d'organiser un atelier d'idéation pour en générer davantage collectivement.

Sans ce dernier maillon, le repository reste une bibliothèque de constats. Avec lui, il devient un générateur d'hypothèses testables.

Quand franchir le pas vers un Research Repository ?

Mettre en place un repository trop tôt est presque aussi risqué que ne jamais le faire : un outil sophistiqué sans matière à y mettre finit par mourir de sous-utilisation. À l'inverse, certains signaux indiquent clairement que le moment est venu.

• L'équipe grandit. Dès que plusieurs personnes travaillent en parallèle sur de la recherche pour un même produit ou un même client, le bouche-à-oreille informel ne suffit plus à diffuser les apprentissages.
• Le volume de données explose. Plusieurs tests par mois, des interviews récurrentes, un audit qui s'ajoute au précédent. Sans structure, cette matière devient vite invisible plutôt que précieuse.
• Le compte devient transverse. Plusieurs marchés, plusieurs équipes, plusieurs consultants référents sur un même client : c'est le stade où le repository cesse d'être un confort pour devenir une nécessité de collaboration.
• Un propriétaire naturel de la donnée existe déjà. Une personne (Research Ops, lead CRO, consultant senior) prête à porter la discipline de mise à jour. Sans elle, même le meilleur outil finit à l'abandon.

Chez Welyft, c'est une dynamique que nous observons directement avec notre propre base de tests : plus les années s'accumulent, plus son utilité grandit. À l'inverse, si votre organisation lance encore peu de recherche, la priorité n'est pas le repository : c'est d'abord d'installer le réflexe de recherche lui-même. Un repository vide, aussi bien conçu soit-il, n'apprend rien à personne.

Comment s'y prendre ?

Créer et maintenir un Research Repository n'est pas une tâche anodine. C'est un vrai projet, qui nécessite un sponsor, une réelle volonté organisationnelle, et des ressources humaines et financières, pas seulement un outil qu'on installe sur un coup de tête.

Pour mener à bien cette démarche, il est important de suivre quelques étapes clés :

1. Clarifier le pourquoi et le pour qui : Quel est l'objectif du repository ? Quelles problématiques d'équipe doit-il résoudre en priorité ? Qui va principalement s'en servir ? Sans réponse claire à ces questions, le projet part sans boussole.
2. Faire l'inventaire de l'existant : Combien de recherches ont déjà été menées dans l'organisation ? Où sont-elles cachées aujourd'hui ? Cet inventaire sert autant à cadrer le périmètre qu'à convaincre en interne de la valeur du chantier.
3. Commencer petit, voir grand : Pas besoin de viser l'exhaustivité dès le lancement. Un périmètre restreint permet de tester l'approche et de l'ajuster avant d'intégrer de nouvelles équipes.
4. Poser une première taxonomie : Définir en amont une liste de tags partagée (par page du parcours, par persona, par type de friction, par client) permet de croiser rapidement des insights qui viennent d'études différentes. Sans convention commune, chaque contributeur invente ses propres catégories, et le repository devient vite impossible à interroger.
5. Choisir le bon outil : Des outils spécialisés en UX Research library existent (Dovetail, Stravito, Marvin, Glean, ou TheyDo pour la cartographie de parcours), mais des solutions plus génériques suffisent souvent pour démarrer (Airtable, Notion, Jira Product Discovery), à condition de partir d'un outil déjà connu en interne.
6. Réunir une équipe pluridisciplinaire : Le projet avance plus vite, et surtout est mieux adopté, quand il est porté par plusieurs profils (recherche, data, produit) plutôt que par une seule personne isolée.
7. Établir les règles de gouvernance : Qui a la responsabilité d'alimenter le repository, à quel moment, selon quelles règles ? Deux modèles coexistent : une gouvernance centralisée portée par un rôle dédié, ou une gouvernance distribuée où chaque contributeur loggue ses propres résultats selon un format partagé.
8. Prouver la valeur pour ancrer l'adoption : Communiquer sur les premiers résultats concrets, directement dans les habitudes de travail existantes plutôt qu'à côté, est ce qui transforme un repository en réflexe collectif plutôt qu'en projet oublié.

Le principal risque, ce n'est pas la théorie, c'est l'adoption !

Un repository qui ne répond pas aux besoins réels des équipes ne survit pas, aussi bien pensé soit-il sur le papier. Le scénario classique : une belle machine de guerre, jamais vraiment exploitée, qu'on arrête progressivement d'alimenter puis de consulter. Dans une organisation en flux tendu, la priorité va aux urgences business, et l'insight repository passe vite au second plan. La vraie difficulté n'est pas technique, elle est organisationnelle : faire adhérer des équipes différentes à un processus commun sans écraser leurs enjeux propres.

Le premier obstacle, c'est l'alimentation : Sur le terrain, documenter manuellement chaque fact et le relier au bon insight est chronophage : c'est le retour que nous font régulièrement les consultants qui ont testé nos premiers prototypes en conditions réelles. Ce n'est pas un détail : c'est la raison numéro un pour laquelle des repositories pourtant bien pensés finissent à l'abandon. La réponse n'est pas de renoncer à la structure, mais d'automatiser la partie la plus fastidieuse : import direct depuis un rapport existant, extraction automatique des facts par IA à partir d'un compte rendu ou d'un support de restitution, avec validation humaine avant intégration.

Le second obstacle, moins visible, c'est le suivi de l'usage : Un repository bien alimenté mais jamais consulté produit le même effet qu'un repository vide : personne ne sait quels insights ont réellement été utilisés, quels tests ont été relancés grâce à lui, quelle recommandation a été retenue plutôt qu'une autre. Sans cette visibilité, impossible de prouver la valeur du dispositif, et donc impossible d'en ancrer l'adoption dans la durée.

Vers une mémoire CRO collective

Chez Welyft, cette question n'est pas théorique. Elle nourrit un travail en cours depuis plusieurs années, avec ses réussites et ses vrais points de friction.

Depuis nos débuts, nous maintenons sur Notion une base centralisée de l'ensemble des tests A/B lancés : contexte, hypothèse, résultats, KPI de validation, page du parcours concernée. Chaque consultant a la responsabilité de l'alimenter à l'issue de chaque analyse. Elle nous sert à trois choses concrètes : vérifier si des tests similaires ont déjà été lancés, argumenter face aux clients en citant des résultats obtenus sur des contextes comparables, et structurer nos rétrospectives clients, y compris sur les tests perdants, souvent le moment où la valeur du programme d'expérimentation devient la plus visible.

Il faut être honnête, cette base reste, à ce stade, un index de résultats de tests, pas un Research Repository complet au sens Atomic Research. Pour retrouver le détail des facts et des insights qui ont motivé un test, il faut encore aller les chercher manuellement dans les rapports sources.

Le prototype que nous avons testé

Nous avons construit un premier prototype complet via Airtable, structuré autour des quatre briques de l'Atomic Research, avec deux ajouts qui vont au-delà de la théorie : la possibilité de projeter les insights sur le customer journey pour visualiser les zones mal couvertes par la recherche, et le rattachement de chaque insight et recommandation à un OKR, pour ancrer la recherche dans la stratégie business plutôt que dans un exercice isolé.

Testé en conditions réelles sur un compte client, ce prototype a confirmé ce que la théorie ne dit jamais assez fort : documenter manuellement chaque fact et le relier à son insight prend du temps. C'est aujourd'hui le principal frein à l'adoption, davantage que la théorie elle-même.

Ce vers quoi nous allons

La prochaine version, en cours de construction, vise à unifier deux approches : une vue structurée classique par filtres et taxonomie, et une couche conversationnelle pilotée par IA, capable d'aller chercher directement les facts et insights dans un rapport existant, où l'on pose ses questions en langage naturel. À terme, notre base de tests actuelle a vocation à être absorbée dans cet outil plus complet, avec une vue par client et une vue transverse par consultant.

C'est cette vue transverse qui nous intéresse le plus. En recherche, la fiabilité d'une conclusion suit une hiérarchie assez simple : un avis d'expert reste une intuition, la recherche utilisateur qualitative apporte de la nuance, une analyse de données ou un audit avant/après révèle des corrélations, et un test A/B apporte une vraie causalité. Le sommet de cette hiérarchie, c'est la méta-analyse : quand une même conclusion ressort de plusieurs expérimentations indépendantes, sa fiabilité dépasse celle de n'importe quelle étude isolée.

‍

Un Research Repository construit à l'échelle d'une agence, produit exactement ce type de méta-analyse. C'est notre ambition à moyen terme : transformer des années de tests A/B, chez des dizaines de clients, en bonnes pratiques CRO backées par de la donnée réelle, un peu à la manière de ce que Baymard fait pour l'e-commerce à l'échelle du marché.

Au fond, le terme Research Repository, ou Insight Repository si l'on préfère notre appellation, n'est jamais qu'un nom à la mode pour désigner quelque chose de beaucoup plus fondamental : la gestion de la connaissance. Sans une vraie base de gestion de la connaissance, une organisation a beaucoup de mal à croiser ses analyses entre elles, et finit inévitablement par perdre le savoir accumulé au fil des années.

C'est là que l'IA change la donne : plutôt que de dépendre de la mémoire de quelques collaborateurs (le fameux "je crois qu'on avait fait un truc comme ça il y a quelques années, mais je ne sais plus où"), une IA qui a accès à l'ensemble du repository peut devenir la mémoire fiable et permanente de l'organisation. C'est la vraie promesse du sujet : transformer une connaissance fragile, dépendante des individus, en un actif solide et durable pour l'entreprise.

‍