Les Product Managers (PM) et les chercheurs en expérience utilisateur (UX Researchers) se retrouvent fréquemment face à un volume massif de 50 000 à plus de 300 000 mots de données brutes après avoir mené plusieurs dizaines d'entretiens approfondis. La codification manuelle de ces verbatims et la création de diagrammes d'affinité demandent souvent des jours, voire des semaines. Par ailleurs, l'utilisation de modèles d'IA dotés de fenêtres de contexte limitées contraint les équipes à découper les textes en sous-parties ou à s'appuyer sur la génération augmentée par récupération (RAG). Ce découpage brise la vision d'ensemble, fausse le décompte de fréquence des problèmes et masque les contradictions subtiles entre différents personas.
Le modèle Kimi, développé par Moonshot AI, apporte une réponse directe à ce défi. Grâce à des fenêtres de contexte atteignant 1 million de tokens sur son modèle phare Kimi K3 et 256K tokens sur K2.6 et K2.7 Code, les équipes produit peuvent injecter l'intégralité d'une campagne d'entretiens dans une seule et même session. Ce guide détaille la préparation des données, la mise en œuvre d'un cadre de prompts en trois phases, l'optimisation des coûts via la mise en cache de contexte (Context Caching) et les règles essentielles de contrôle méthodologique.
Pourquoi Kimi débloque l'analyse des recherches qualitatives
La recherche utilisateur qualitative repose avant tout sur la comparaison croisée. La critique isolée du Participant 3 ne prend son sens que lorsqu'elle fait écho aux blocages rencontrés par les Participants 12 et 27. Lors de l'utilisation d'approches d'IA conventionnelles, trois écueils majeurs se présentent :
- Perte de la perspective globale : Les architectures RAG sélectionnent des fragments sur la base de la proximité sémantique. Elles peuvent repérer si quelqu'un a mentionné un problème de facturation, mais s'avèrent incapables d'identifier avec précision les cinq obstacles majeurs les plus récurrents parmi l'ensemble des 25 participants, ni de comparer objectivement les réponses des administrateurs et des utilisateurs finaux.
- Fragmentation de l'analyse : Résumer les entretiens un à un dans des sessions distinctes oblige le chercheur à agréger manuellement des dizaines de synthèses, réintroduisant la fatigue mentale et le biais d'interprétation.
- Généralisations vagues et superficielles : Sans consignes formelles, les modèles génératifs produisent souvent des déclarations génériques du type « les utilisateurs souhaitent une interface plus ergonomique », omettant l'étape précise du parcours où survient le blocage et les verbatims indispensables pour alimenter les spécifications produit.
L'architecture de Kimi ingère de très grands corpus de manière native. Une fenêtre de 1 million de tokens absorbe sans difficulté 40 à 60 transcriptions intégrales d'entretiens de 45 minutes (avec une prise en charge de fichiers individuels jusqu'à 100 MiB aux formats txt, md, docx et pdf). Le modèle applique ainsi son mécanisme d'attention sur l'ensemble de la base pour croiser les données et dénombrer les occurrences avec rigueur.
Le flux de travail en 4 étapes : de la transcription à l'arbitrage produit
Une méthodologie structurée en quatre étapes préserve la rigueur qualitative tout en automatisant 80 % des tâches répétitives de catégorisation.
Étape 1 : Anonymisation et standardisation des métadonnées
Avant de soumettre les transcriptions à Kimi, nettoyez les données personnelles (PII Scrubbing) et homogénéisez la structure des documents :
- Suppression des données sensibles : Remplacez les noms réels, raisons sociales, mots de passe et montants financiers par des identifiants normalisés, par exemple
P01_Designer_ETIouP02_AdminSys_GrandCompte. - Métadonnées d'en-tête uniformisées : Insérez un en-tête de quatre lignes au début de chaque transcription :
- Identifiant participant : P01
- Persona / Rôle : Responsable des opérations
- Taille de l'entreprise : 500 à 1 000 salariés
- Objectif métier : Clôture mensuelle des stocks et export des bilans
- Harmonisation des formats : Enregistrez les fichiers en texte brut (
.txt), Markdown (.md) ou Word (.docx). Dans l'interface web de Kimi, le chargement s'effectue par glisser-déposer groupé ; via l'API, les textes sont regroupés au sein d'un bloc structuré.
Étape 2 : Ancrage du contexte et définition du rôle
Lors du premier échange avec Kimi, évitez de lui demander un résumé immédiat. Commencez par définir la posture d'analyse, les règles de preuve et l'indexation des participants :
Tu agis en tant que Lead UX Researcher et Principal Product Manager.
J'ai téléversé 20 transcriptions d'entretiens anonymisées issues de notre étude sur le module de reporting analytique.
Ton rôle est de servir de moteur d'analyse qualitative selon les principes suivants :
1. Chaque constatation doit être rigoureusement appuyée sur le texte fourni. Ne fabrique aucune citation et ne suppose aucun fait non décrit.
2. Associe systématiquement chaque élément de preuve à l'identifiant du participant (P01 à P20).
3. Distingue impérativement les demandes fonctionnelles de surface ("je veux un bouton d'export CSV") des points de douleur opérationnels profonds ("le système plante lors de la synchronisation de plus de 10 000 lignes").
Confirme la bonne prise en compte des 20 transcriptions, liste les identifiants et rôles reconnus, puis attends mes consignes d'analyse spécifiques.
Le canevas de prompts en trois phases pour extraire les frictions récurrentes
Pour transformer des remontées disparates en opportunités de développement concrètes, menez l'analyse en trois paliers successifs.
Phase 1 : Extraction granulaire des frictions et des verbatims
Ce prompt oblige le modèle à parcourir l'ensemble des textes, à isoler les moments d'irritation précis et à recueillir les citations textuelles directes :
Réalise une extraction thématique exhaustive sur l'ensemble des 20 transcriptions d'entretiens.
Identifie chaque situation où un participant a exprimé de la frustration, de la confusion, une interruption de tâche ou un mécontentement.
Restitue les résultats sous forme de tableau Markdown comportant les colonnes suivantes :
- Identifiant friction (PP01, PP02, etc.)
- Étape du parcours utilisateur (ex. : Onboarding, Import de données, Configuration des filtres, Export récurrent)
- Description concrète du problème (explication factuelle de l'obstacle rencontré)
- Niveau de gravité (Élevé : blocage complet de la tâche ; Moyen : contournement complexe nécessaire ; Faible : gêne mineure)
- Participants concernés (liste de tous les identifiants ayant mentionné le problème, ex. : P03, P07, P18)
- Verbatim représentatif (une citation textuelle exacte illustrant la friction, avec son identifiant)
Phase 2 : Regroupement thématique et analyse comparative par segment
L'arbitrage de roadmap impose de hiérarchiser les sujets. Cette étape regroupe les points récurrents, mesure leur fréquence réelle et compare les profils :
À partir des frictions identifiées, regroupe en thèmes clés celles qui ont été mentionnées par 3 participants ou plus, en les classant par nombre décroissant de personnes impactées.
Pour chaque thème récurrent, détaille les points suivants :
1. Intitulé du thème et énoncé synthétique du problème
2. Fréquence : nombre de participants uniques affectés et pourcentage par rapport au total (ex. : 14/20 participants, 70 %)
3. Répartition par segment : différences de perception entre Administrateurs et Utilisateurs opérationnels
4. Cause profonde : le problème découle-t-il d'une limite technique du système, d'une architecture de l'information inadaptée ou d'un décalage entre le modèle mental de l'utilisateur et la logique de l'outil ?
5. Stratégies de contournement : quelles solutions provisoires les utilisateurs mettent-ils en place (ex. : exports manuels vers Excel, scripts développés en interne, double vérification sur papier) ?
Phase 3 : Traduction en opportunités Jobs-to-be-Done (JTBD)
Formulez les problèmes confirmés sous forme d'opportunités de conception sans vous enfermer prématurément dans des choix techniques :
Formule les 5 principaux points de friction sous forme de déclarations d'opportunités Jobs-to-be-Done (JTBD) selon la structure suivante :
"Lorsque [contexte ou déclencheur], les utilisateurs souhaitent [action ou motivation], afin de [bénéfice métier attendu], mais ils sont actuellement freinés car [cause racine validée par Kimi]."
Pour chaque opportunité JTBD :
- Propose 2 hypothèses de fonctionnalités distinctes et testables pour l'équipe produit.
- Précise les éventuels conflits d'usage (ex. : une personnalisation avancée plébiscitée par les experts qui alourdirait la prise en main des débutants).
Optimisation technique : réduire les coûts grâce au Context Caching
Dans le cadre d'un traitement par l'API de Kimi (avec les modèles kimi-k3 ou kimi-k2.6), renvoyer l'intégralité des transcriptions à chaque requête entraîne une consommation élevée de tokens et allonge les délais de réponse.
Le mécanisme de Context Caching (mise en cache de contexte) de Moonshot AI supprime cette contrainte :
- Principe de fonctionnement : En plaçant les transcriptions au début du prompt (dans le message
system) et en activant la mise en cache (prompt_cache_optionsoucache_control), Kimi stocke ce préfixe statique en mémoire cache. - Choix de la durée (TTL) : Définissez un TTL de 5 minutes (
5m) pour des scripts d'extraction automatisés en chaîne, ou de 1 heure (1h) pour des sessions d'exploration interactives menées par un chercheur. Chaque requête touchant le cache réinitialise gratuitement sa durée de validité. - Réduction significative des coûts : Le coût des tokens d'entrée mis en cache est environ dix fois inférieur à celui des tokens non mis en cache (sur
kimi-k3, ¥2 par million de tokens en cas de succès de cache contre ¥20 par million en accès standard). Une équipe peut ainsi exécuter des dizaines de requêtes d'approfondissement sur le même corpus pour un coût minime et avec un temps de réponse initial (TTFT) quasi instantané.
from openai import OpenAI
client = OpenAI(
api_key="VOTRE_CLE_API_MOONSHOT",
base_url="https://api.moonshot.cn/v1",
)
# Transcriptions positionnées en préfixe avec une mise en cache de 1 heure
completion = client.chat.completions.create(
model="kimi-k3",
messages=[
{
"role": "system",
"content": f"Tu es un assistant de recherche UX. Transcriptions des entretiens :\n\n{bulk_transcripts_text}",
},
{
"role": "user",
"content": "Compare la manière dont les grands comptes et les PME décrivent la latence d'exportation.",
},
],
prompt_cache_options={"mode": "implicit", "ttl": "1h"},
)
print(completion.choices[0].message.content)
Bonnes pratiques et garde-fous méthodologiques
Bien que l'IA accélère considérablement l'exploitation des données qualitatives, les équipes de recherche doivent conserver des points de contrôle stricts :
| Dimension analysée | Écueil fréquent | Pratique recommandée |
|---|---|---|
| Authenticité des citations | Prendre une reformulation synthétique du modèle pour une vraie citation client | Exiger des verbatims intégraux avec identifiant participant et contrôler des extraits aléatoires dans le document source |
| Biais de fréquence | Confondre l'insistance d'un seul participant volubile avec une attente partagée | Décompter les participants uniques ; les réclamations multiples d'une même personne ne comptent que pour une voix |
| Confidentialité des données | Téléverser des coordonnées réelles, des identifiants ou des secrets industriels | Anonymiser rigoureusement les fichiers en amont de toute transmission |
| Prévention des hallucinations | Accorder du crédit aux extrapolations du modèle sur des sujets non abordés | Imposer la règle : « Pour tout élément non présent dans le corpus, indiquer explicitement 'Non mentionné dans les transcriptions' » |
Conclusion
En associant la fenêtre de contexte de 1 million de tokens de Kimi à un protocole de prompts en trois phases, les Product Managers et chercheurs UX condensent en quelques heures un travail d'analyse qualitative qui mobilisait auparavant plusieurs semaines. Loin des découpages arbitraires du RAG et des résumés impersonnels, les équipes disposent d'une cartographie objective, chiffrée et sourcée des irritants clients, prête à étayer les choix stratégiques de développement.