Research-in-the-loop : aligner la recherche utilisateur sur un développement à vitesse IA

Nielsen Norman Group a publié le 13 novembre 2026 un article sur le « research-in-the-loop », qui défend l'idée que la recherche utilisateur doit s'adapter à l'accélération du développement par l'IA plutôt que de servir de barrière finale. L'idée centrale : la recherche peut définir ce que chaque version doit mesurer et ce qu'elle peut aider les équipes à découvrir. C'est un changement de rôle : la recherche passe d'une étape avant le lancement à un composant intégré au cycle de livraison.

Pourquoi l'enchaînement classique ne tient plus

Le schéma habituel est séquentiel. La recherche est menée, les résultats sont rédigés, le design les absorbe, le développement construit, et un test arrive près de la fin. Cette séquence suppose que chaque cycle est assez long pour absorber une étude. Quand le développement se comprime, le test tardif arrive après les décisions qu'il devait éclairer, et les équipes livrent sur des hypothèses que personne n'a vérifiées.

Repenser la recherche comme une boucle change ce qu'elle produit. Au lieu d'un verdict unique par projet, la boucle pose une question plus étroite à chaque version : que doit prouver cette version, et que pourrait-elle révéler d'inattendu ? La première moitié relève de la mesure, la seconde de la découverte. Les deux doivent être tranchées avant le début du build, pas après.

Ce qu'une équipe peut vérifier cette semaine

La pratique concrète découle de ce cadre, et l'essentiel ne demande pas de nouvel outil.

• Pour la prochaine version prévue, notez le comportement qu'elle doit changer et la manière dont vous observerez ce changement.
• Séparez les métriques à atteindre des questions auxquelles vous voulez répondre, et assurez-vous que la seconde liste n'est pas vide.
• Prenez deux ou trois versions déjà livrées et demandez ce qui a été appris après le lancement, pas avant.

Si le dernier point ne donne rien, la recherche n'est pas dans la boucle : elle est dans un tiroir. Si les enseignements sont arrivés trop tard pour compter, la boucle existe mais est branchée au mauvais point du cycle.

Ce que le modèle ne tranche pas

L'article pose le principe et le rôle de la recherche ; il ne précise ni les structures d'équipe, ni les tailles d'échantillon, ni la cadence, ni l'outillage, et l'annonce ne cite pas de méthodes particulières pour garder les études assez rapides face à des builds assistés par IA. Ces décisions restent locales.

Deux tensions méritent d'être nommées. D'abord, une boucle a besoin d'une unité d'itération stable, or le développement assisté par IA tend à raccourcir les itérations en continu plutôt que par paliers nets : les équipes doivent donc choisir ce qui compte comme une version. Ensuite, la discipline de mesure dispute la même attention que la découverte. Une équipe qui ne fait qu'instrumenter optimisera ce qu'elle croit déjà important, tandis qu'une équipe qui ne fait qu'explorer ne saura jamais si le changement a fonctionné.

Le test pratique n'est pas de savoir si la recherche existe dans le processus, mais si un résultat peut encore changer une décision au moment où il arrive. À mesure que la vitesse de build augmente, cette fenêtre se resserre, et la place de la recherche dans le cycle compte autant que ce qu'elle étudie.