Analyser les réponses ouvertes d'une enquête, et la place de l'IA

La plupart des équipes mettent tout leur effort dans les questions notées et traitent le champ de commentaire comme un détail. C'est l'inverse qu'il faut faire. Les questions fermées vous disent ce qui s'est passé. La seule question ouverte à la fin vous dit pourquoi. Le texte libre est aussi l'endroit où l'analyse s'effondre en silence, car lire quelques milliers de réponses libres est lent et aucun tableau de bord ne le fait à votre place. Alors on les survole, ou on les colle dans un modèle qui rend un résumé net que personne ne vérifie. Voici comment le faire correctement, et connaître la limite où un modèle d'IA cesse d'aider.

Pourquoi les réponses ouvertes valent la peine

Une note vous dit la taille d'un ressenti, pas sa cause. Un client qui vous met 3 sur 5 vous a donné un chiffre que vous pouvez moyenner, mais il reste muet : le prix, l'accueil, un mauvais ticket de support, ou une publicité d'un concurrent vue le matin même ? La réponse ouverte à côté du chiffre est le seul endroit où la raison apparaît dans les mots de la personne, avant tout filtre par votre supposition sur le problème.

Le texte libre est aussi la partie d'une enquête que vous n'avez pas décidée d'avance. Chaque question fermée est une hypothèse : vous avez deviné les réponses et les avez imprimées comme options. Si votre supposition était incomplète, la question ne peut pas vous le dire, car l'option manquante n'est pas là. Dans le champ ouvert apparaît la réponse à laquelle vous n'aviez pas pensé. Jetez-la, et vous ne gardez que ce que vous attendiez déjà.

Le codage est la compétence dont tout dépend

Le hic, c'est que le texte libre n'arrive pas sous forme de données. Il arrive en prose, de longueur, orthographe, langue et effort très variables, et rien ne rentre dans un graphique tant que quelqu'un ne lui impose pas une structure. Cette étape s'appelle le codage, et c'est là que tout se joue.

Coder veut dire lire chaque réponse et l'étiqueter d'une ou plusieurs catégories, de sorte que "le paiement expirait sans cesse" et "la page a gelé deux fois" tombent sous un code comme fiabilité du paiement. Une fois que chaque réponse porte des codes, vous pouvez les compter, les croiser avec la note, et rapporter que 31% des détracteurs ont cité la fiabilité du paiement, au lieu de trois commentaires frappants dont vous espérez qu'ils soient typiques. Le codage transforme l'anecdote en preuve.

L'ensemble des codes et de leurs définitions est votre livre de codes. Un bon livre de codes a des catégories assez distinctes pour ne pas se chevaucher, assez précises pour agir dessus, et définies en une phrase, de sorte que deux personnes qui étiquettent la même réponse arrivent au même code. Des codes vagues comme "expérience utilisateur" sont inutiles, car tout y entre. Analyser du texte libre, c'est construire et appliquer un livre de codes solide. Et c'est exactement le travail dont on espère que l'IA le prendra en charge.

Codage déductif et inductif ne sont pas la même tâche

Cette distinction décide où l'IA est sûre, donc mieux vaut être précis. Le codage déductif veut dire apporter le livre de codes aux données : vous avez vos catégories, et la tâche est de les appliquer de façon cohérente sur des milliers de réponses. Le codage inductif veut dire que vous bâtissez le livre de codes à partir des données : vous lisez les réponses sans catégories fixes et laissez les thèmes émerger. La plupart des projets font les deux : esquisser un livre de codes à partir d'un premier échantillon, puis l'appliquer à l'ensemble.

Les deux tâches demandent des choses différentes. Appliquer un code connu est un appariement avec une bonne réponse claire. Découvrir un thème relève de l'interprétation. Cela dépend du ton, du contexte, et du jugement de voir que trois plaintes formulées autrement visent le même problème. Gardez cette distinction en tête : elle recoupe presque exactement ce qu'un modèle de langage sait faire et ne sait pas faire.

Là où l'IA est vraiment fiable : appliquer un livre de codes que vous avez écrit

Donnez à un modèle un livre de codes clair et il étiquette les réponses à peu près aussi bien qu'une personne. Une comparaison en aveugle publiée dans PLOS Digital Health en avril 2026 a testé plusieurs modèles contre des analystes humains sur des données d'entretien de santé. Sur le codage déductif, l'application de codes prédéfinis, les modèles se sont révélés non inférieurs aux humains : accord moyen de 93,5% contre 92,7%. Le taux strict d'hallucination, où un modèle inventait une preuve absente du texte, était de 1,2%. Pour la moitié fastidieuse et volumineuse du codage, c'est un vrai gain : un modèle étiquette dix mille réponses contre votre livre de codes en une nuit, sans faiblir. Vous gardez l'interprétation et déléguez la mise à l'échelle. Le guide sur l'analyse des enquêtes par IA via MCP montre comment brancher un modèle sur vos données en lecture seule, pour cet étiquetage sur des données qu'il ne peut pas modifier.

Là où l'IA se trompe de thèmes : les découvrir à votre place

Inversez la tâche. Demandez à un modèle de lire des réponses brutes et de vous dire quels sont les thèmes, sans livre de codes, et il devient bien moins fiable. Dans la même étude, un seul modèle a atteint le seuil sur l'analyse inductive. Les modèles étaient les plus faibles là où ça compte : la sensibilité à la nuance et au sens latent, cette lecture qui saisit une plainte implicite. Le taux d'erreur large, correspondances partielles et mauvaises attributions comprises, était de 12,4%.

L'échec est rarement une invention grossière. Il est plus discret, et c'est pire. Un modèle produit une série de thèmes plausible et bien rangée qui a l'air de faire autorité, et il lisse les cas atypiques, fond deux problèmes sous un même titre, ou promeut une formulation vue une fois en "thème majeur". Vous ne l'attrapez pas depuis le résumé, qui a toujours l'air sûr de lui. Vous l'attrapez en ayant lu les réponses brutes d'abord. Un modèle avec une pile mince de réponses rend quand même cinq thèmes nets, sans vous prévenir que l'échantillon était trop petit pour les porter.

Un déroulé qui utilise l'IA pour ses points forts

Mettez les deux constats côte à côte et le partage des tâches s'écrit tout seul. Lisez d'abord un échantillon à la main, quelques centaines de réponses, assez pour voir les formes qui reviennent. C'est l'étape inductive, et elle reste humaine, car c'est là que l'IA est la plus faible. Esquissez votre livre de codes, une phrase par catégorie. Confiez ensuite le livre de codes et l'ensemble des données au modèle pour l'étape déductive, en étiquetant chaque réponse à grande échelle. Contrôlez son travail par sondage en recodant vous-même une tranche au hasard. Si vous divergez sur plus d'une petite part, c'est votre livre de codes qui est ambigu, pas le modèle. Ce que l'humain ne cède jamais, c'est de décider des catégories et de la validité des résultats.

Quantifier le texte libre sans mentir avec les chiffres

Une fois les réponses codées, vous voudrez des pourcentages, et c'est là que l'analyse du texte libre se survend le plus. Un code présent dans 8% des commentaires n'est pas un problème touchant 8% des clients : seule une partie a écrit, et ceux-là se tiennent au bord le plus motivé ou agacé de l'échantillon. Rapportez le texte libre codé comme une part de ceux qui ont commenté, jamais comme une part de tout le monde.

Attention aussi aux petits nombres. Un thème porté par neuf commentaires sur quatre mille est un signal à creuser, pas une tendance pour fonder des décisions. Le guide sur la conception des questions à échelle explique pourquoi un chiffre a besoin d'assez de réponses derrière lui avant de vouloir dire quelque chose, et le texte libre codé ne fait pas exception.

Les pièges à surveiller

Quelques pièges reviennent. L'attribution des réponses : donnez beaucoup de réponses d'un coup et le modèle peut brouiller quel commentaire disait quoi, ce qui explique en partie le taux d'erreur large. Les thèmes complaisants : les modèles penchent vers le résumé net, si bien qu'un constat contradictoire ou gênant peut être gommé. Le cas rare qui disparaît : le seul commentaire sur un grave défaut d'accessibilité ou un risque juridique pèse bien plus que sa fréquence d'un sur trois mille, et un résumé piloté par la fréquence le laisse tomber. Et les réponses de faible qualité ou écrites par une machine polluent l'entrée avant même le codage. Le guide sur le suivi de la qualité des réponses explique comment les filtrer d'abord.

Rien de tout cela ne veut dire éviter l'IA. Cela veut dire : lisez vous-même un vrai échantillon du texte brut, gardez en vue les commentaires rares mais graves, et traitez tout thème que le modèle fait remonter seul comme une hypothèse à vérifier, pas un constat à publier.

L'analyse commence à l'écriture de la question

L'analyse de texte libre la plus propre se prépare des mois plus tôt, en posant une bonne question. "D'autres remarques ?" produit un cimetière de "non", "s. o." et de défoulement difficile à coder, car ça ne porte sur rien de précis. Une invite ciblée comme "Quelle seule chose aurait rendu cela plus facile ?" produit des réponses qui se regroupent déjà, car vous avez cadré le sujet avant qu'ils ne tapent. Le guide pour écrire de meilleures questions d'enquête s'applique ici directement. Une question ouverte ciblée est plus aimable pour le répondant, et c'est la différence entre un livre de codes qui se construit presque seul et un que vous devez forcer sur des réponses éparses. Posez-en donc plutôt une bonne que trois vagues.