Comment traduire et classer automatiquement les réponses de formulaires avec n8n et l’IA

Dans les deux articles précédents de cette série, nous avons d’abord vu pourquoi il vaut la peine de recueillir du feedback client puis comment créer un formulaire de feedback utile pour comprendre ce qui se passe sur un site web ou une app juste après une conversion.

Dans ce troisième article, nous allons un cran plus loin. Nous ne parlons plus seulement de recueillir des réponses, mais de les traiter. 

Parce qu’analyser les réponses des champs ouverts de n’importe quel formulaire prend du temps si ce n’est pas automatisé. Surtout si elles arrivent en plusieurs langues.

La série complète sur la manière de recueillir et d’utiliser le feedback client comporte quatre parties :

1. Pourquoi recueillir du feedback client est indispensable.
2. Comment créer un formulaire de feedback utile.
3. Comment utiliser l’IA pour traduire et classer des réponses ouvertes.
4. Comment transformer ce feedback en dashboards et en routine de suivi mensuelle.

Ici, nous allons nous concentrer sur le troisième point : monter un workflow avec n8n, Google Sheets et Gemini pour traduire, classer et enrichir des réponses ouvertes de formulaires.

Quel problème résolvons-nous avec ce workflow ?

Les questions fermées du formulaire sont faciles à analyser. 

Si tu demandes d’évaluer de un à dix la facilité du processus (ou quoi que ce soit d’autre), le principal motif de décision, l’âge, le pays ou si l’utilisateur a eu des problèmes, chaque réponse est classée avec une valeur parmi un nombre limité de valeurs.

Le problème apparaît avec les réponses ouvertes.

C’est là que l’utilisateur explique avec ses propres mots ce qui lui est arrivé : il ne trouvait pas une information, le paiement lui a donné des doutes, il a comparé avec une autre plateforme où c’était moins cher, il a eu un problème avec un coupon au checkout, il voulait parler à une personne ou le processus était clair et rapide.

Ce type de commentaire est très précieux, mais il présente trois difficultés :

1. Il faut le lire.
2. Il faut comprendre et interpréter le contexte.
3. Et, s’il y a plusieurs langues, il faut le traduire ou le normaliser avant de le comparer.

Si tu as peu de réponses, tu peux le faire à la main. Si tu commences à avoir du volume, des marchés différents ou des commentaires en cinq langues, cela cesse d’être faisable. 

Dans le cas que nous utilisons comme exemple, le formulaire était prévu en espagnol, néerlandais, français, anglais et allemand. C’est pourquoi il était logique d’ajouter une couche d’IA.

L’idée n’est pas que l’IA décide à la place de l’entreprise, mais qu’elle prépare la donnée : 

1. Traduire les commentaires.
2. Classer les incidents.
3. Détecter les mentions de concurrents.
4. Laisser un document Google Sheets prêt à être analysé à l’étape suivante.

Ce que nous allons construire

Nous allons construire un workflow n8n qui fait ceci :

1. Il lit une feuille Google Sheets contenant les réponses de formulaires.
2. Il détecte quelles réponses sont nouvelles pour ne pas traiter de doublons.
3. Il ajoute un contexte de catégories pour que l’IA classe de manière cohérente.
4. Il envoie les champs ouverts à un LLM (Gemini, dans notre cas).
5. Il reçoit une réponse en JSON.
6. Il transforme ce JSON en colonnes avec le bon format.
7. Il écrit le résultat final dans une autre feuille Google Sheets avec les résultats de l’IA.

Ce n’est pas une recette universelle que tu peux copier sans rien toucher. 

Elle est adaptée à un formulaire concret de feedback client sur un site de réservation, mais la logique peut être transférée à un site e-commerce, une formation, un site de services ou n’importe quel formulaire de feedback sur un actif digital où tu veux classer des réponses ouvertes.

Outils que nous allons utiliser

Pour ce flux, nous utilisons plusieurs outils précis :

• n8n, comme outil d’automatisation.
•  Google Sheets, comme feuille d’entrée et de sortie.
• Gemini, comme modèle d’IA pour traduire et classer.
• Data Studio, qui sera la destination naturelle pour visualiser les données dans l’article suivant.

Dans ce cas, nous utilisons Gemini Flash Lite parce que la tâche est relativement légère : analyser des commentaires courts, choisir une catégorie, détecter si un concurrent apparaît et renvoyer un JSON. Nous n’avons pas besoin du modèle le plus puissant pour cela, mais d’un modèle rapide, bon marché et stable.

Dans notre cas, le coût prévu n’était que de quelques centimes par jour. Nous avons aussi choisi la version latest de Flash Lite parce qu’en fixant des versions antérieures, comme 2.0 ou 2.5, des problèmes de disponibilité apparaissaient. 

Et dans un flux automatisé, la stabilité compte autant, voire plus, que la qualité.

La température du modèle est configurée à 0.1.  

C’est aussi intentionnel : ici nous ne cherchons pas la créativité, mais la cohérence. 

Nous voulons que des réponses similaires soient classées de manière similaire et que le modèle respecte le format JSON que nous lui demandons.

Avant de commencer : comment la feuille de réponses doit être préparée

Comme je l’ai expliqué dans l’article précédent, avant de monter le workflow, nous avons besoin d’une feuille Google Sheets avec les réponses originales du formulaire.  

Elle peut venir directement de Google Forms ou être une feuille où nous avons unifié des réponses arrivant d’un autre système, comme un CRM ou plusieurs formulaires dans différentes langues.

L’important est que la feuille ait une structure stable : une ligne par réponse et une colonne par question. 

Dans cet exemple, nous travaillons avec des champs associés aux réponses :

• Record ID (que nous utilisons pour éviter les doublons).
• Date.
• Marché (il y a cinq domaines différents).

Et les champs des réponses elles-mêmes :

• Facilité de réservation (échelle 1-10).
• Motif de décision (5 possibilités).
• S’il y a eu des incidents et le détail de l’incident.
• Évaluation du site web.
• Commentaire libre.
• Pays (ce n’est pas la même chose que le marché, car un Finlandais peut réserver sur le site anglais).
• Genre.
• Âge.
• Et si l’utilisateur attend une réponse.

Ta feuille n’a pas besoin d’avoir exactement les mêmes colonnes. L’important est qu’il y ait un identifiant unique par réponse. Dans ce workflow, nous utilisons Record ID pour savoir quelles lignes ont déjà été traitées et lesquelles sont nouvelles.

Si tu travailles en plusieurs langues, il est conseillé de conserver la même structure de questions et de réponses dans toutes, en ne variant que la traduction. 

Tu peux ainsi analyser des données agrégées tout en segmentant par langue, pays ou marché. Nous avons vu tout cela dans l’article précédent sur la création du formulaire.

Workflow dans n8n pas à pas

Le workflow complet est organisé en neuf nœuds principaux :

Toutes les heures :

 → Lire les Sheets source.

 → Packager la source.

 → Filtrer les nouveaux IDs.

 → Construire le contexte de catégories.

 → Classer avec Gemini Flash.

 → Parser la réponse de l’IA.

 → Préparer les résultats pour le nouveau Google Sheet.

 → Écrire dans le nouveau Google Sheet.

Je t’explique d’abord le fonctionnement du flux dans les grandes lignes, puis nous détaillons chacun d’eux.

Dans ce flux, n8n s’exécute avec une fréquence définie, lit la feuille de réponses, normalise les données, écarte les enregistrements déjà traités, ajoute les catégories que l’IA doit utiliser, envoie les champs ouverts à Gemini, interprète la réponse et écrit une ligne enrichie dans la feuille finale.

Maintenant, voyons nœud par nœud.

Étape 1 : Toutes les heures

Ce nœud est le déclencheur du workflow.  

Dans l’exemple, il est configuré pour s’exécuter toutes les heures, mais la fréquence peut être adaptée au volume de réponses.  

Si tu reçois beaucoup de réponses, il peut être logique de l’exécuter toutes les heures. Si tu en reçois peu, une fois par jour peut suffire. 

Tu devras aussi le lancer manuellement pendant une phase de tests.

Configuration de base :

Node type: Schedule Trigger
Rule: every hour

La clé est d’ajuster la fréquence. Pour du feedback de formulaires, il n’est généralement pas nécessaire de traiter chaque minute. 

Étape 2 : Lire la feuille Google Sheets source

Ce nœud lit la feuille Google Sheets où se trouvent les réponses originales du formulaire.  

Dans ce cas, nous utilisons l’onglet source en lecture seule. 

Important: nous ne marquons pas les lignes, nous n’écrivons pas de statuts et nous n’utilisons pas cette feuille comme base de données opérationnelle.

Nous pourrions le faire, mais comme cette feuille a été créée par le client, il vaut mieux ne pas y toucher. Si c’est pour ta propre entreprise, il est probablement logique d’y ajouter une deuxième feuille, au lieu de créer un autre Google Sheet comme nous le faisons ici.

Configuration de base :

Node type: Google Sheets
Operation: Read
Document ID: [ID_DEL_SPREADSHEET_ORIGEN]
Sheet name: [NOMBRE_HOJA_ORIGEN]
Credential: [CREDENCIAL_GOOGLE_SHEETS]

La feuille source doit être aussi propre que possible. 

Si elle vient de Google Forms, tu auras déjà une structure assez confortable. Si elle vient d’un CRM ou de plusieurs formulaires, il vaut mieux unifier les réponses au préalable dans une feuille avec des colonnes cohérentes.

Étape 3 : Packager la source

Ce nœud de code (JS) normalise les lignes qui viennent de la feuille source et les prépare pour le reste du workflow.  

En pratique, il copie chaque item tel quel. 

Code du nœud :

// Normaliza las filas del Sheets origen para usarlas despues desde otros nodos.
// El origen es solo lectura, asi que no marcamos nada aqui.

return $input.all().map(item => ({
  json: { ...item.json }
}));

Étape 4 : Filtrer les nouveaux Record ID

Ce nœud évite les doublons. 

C’est l’un des points les plus importants du workflow. Si, à chaque exécution du flux, nous envoyions toutes les réponses à Gemini, nous traiterions encore et encore les mêmes commentaires, nous dépenserions plus de tokens et nous remplirions la feuille finale de doublons.

Pour l’éviter, nous utilisons le nœud Remove Duplicates de n8n avec l’opération Remove Items Processed in Previous Executions. La configuration est basée sur le champ Record ID, qui doit être unique pour chaque réponse.

Configuration de base :

Node type: Remove Duplicates
Operation: Remove Items Processed in Previous Executions
Value to Dedupe On: {{ $json["Record ID"] }}

C’est important :

Si le workflow est monté avant qu’il y ait des réponses, il n’y a rien à initialiser. La première réponse qui arrivera sera nouvelle et sera traitée.

Si la feuille contient déjà d’anciennes réponses lorsque tu actives le workflow (cas habituel), il vaut mieux exécuter tout le flux jusqu’à ce nœud (inclus) avant de le connecter au reste du flux. 

Ainsi, n8n apprend que ces Record ID ont déjà été vus et n’envoie pas tout l’historique à l’IA lors de la première exécution.

Il est aussi conseillé de tester le flux sans encore le publier : exécuter une fois, vérifier quels enregistrements passent, exécuter à nouveau et vérifier qu’ils ne sont pas dupliqués. 

N’appuie pas sur Clear Deduplication Historysauf si tu veux tout retraiter.

Étape 5 : Construire le contexte de catégories

Ici, nous définissons les catégories que l’IA peut utiliser pour classer les réponses.  

Ce point est essentiel parce que nous ne voulons pas que Gemini invente une catégorie différente pour chaque commentaire. Nous voulons qu’il classe dans un cadre fermé.

Dans cet exemple, nous avons deux groupes de catégories : un pour les incidents du processus de réservation et un autre pour les commentaires ouverts.

Catégories pour Q3, incidents du processus :

• Paiement / passerelle.
• Code de réduction.
• Navigation / UX.
• Disponibilité incorrecte.
• Problèmes avec la réservation.
• Autre.

Catégories pour Q5, commentaires ouverts :

• Satisfaction / éloge.
• Promotions / réductions.
• Service / support humain.
• Mode de paiement / virement.
• Prix.
• Comparaison avec la concurrence.
• Information du listing.
• Politique d’annulation.
• Temps de réponse.
• Aucun commentaire pertinent.
• Autre.

Dans ce cas, nous avons décidé de hardcoder les catégories à l’intérieur du nœud de code lui-même afin d’éviter une lecture supplémentaire de Google Sheets.  

Ce n’est pas seulement une préférence technique : cela aide à réduire les appels à l’API Google Sheets.

Il peut sembler pratique d’utiliser Google Sheets comme une petite base de données : une feuille pour les réponses, une autre pour les catégories, une autre pour vérifier les lignes déjà traitées, une autre pour écrire les résultats. 

Mais si le flux grandit, tu peux tomber sur des limites de quota, comme cela nous arrivait ici. 

C’est pourquoi, dans ce cas, nous utilisons Google Sheets comme entrée et sortie, pas comme base de données générale du système (qui utilisera celle que tu as dans ton installation n8n, SQLite par défaut).

Code du nœud :

// Categorías hardcodeadas para eliminar una lectura adicional a Google Sheets.
// Si cambias Categorias_Config, actualiza estas listas aquí.

const categoriasQ3 = [
  [
'Pago / pasarela',
'Tarjeta rechazada, fallo con Bancontact, Paypal u otro metodo de pago'
  ],
  [
'Codigo descuento',
'Cupon o codigo de descuento invalido que bloquea o impide completar el pago'
  ],
  [
'Navegacion / UX',
'Problemas de usabilidad en la web, ej. volver al listado, botones confusos'
  ],
  [
'Disponibilidad incorrecta',
'Fechas que desaparecen, alojamiento mostrado como disponible pero no lo esta'
  ],
  [
'Problemas con la reserva',
'Reserva equivocada, duplicada o cancelada por error del sistema, demora o ausencia de confirmacion de reserva, email de confirmacion o validacion del propietario'
  ],
  [
'Otro',
'Incidencia que no encaja en ninguna categoria anterior'
  ],
];

const categoriasQ5 = [
  [
'Satisfaccion / elogio',
'Comentarios positivos, felicitaciones, recomendacion del servicio o buena experiencia'
  ],
  [
'Promociones / descuentos',
'Peticiones de codigos promocionales, descuentos para clientes habituales o promociones'
  ],
  [
'Atencion / soporte humano',
'Peticiones de hablar con una persona, chat humano, soporte no automatizado o ayuda comercial'
  ],
  [
'Forma de pago / transferencia',
'Comentarios sobre transferencia, tarjeta, medios de pago disponibles o preferencia de pago'
  ],
  [
'Precio',
'Comentarios sobre subida de precios, coste percibido como alto o comparacion de precio'
  ],
  [
'Comparacion con competencia',
'Menciona explicitamente otra plataforma como Booking.com, Airbnb, Vrbo, etc.'
  ],
  [
'Informacion del listing',
'Falta de fotos, ubicacion/coordenadas poco claras, info de mascotas, descripcion del alojamiento'
  ],
  [
'Politica de cancelacion',
'Plazo de cancelacion gratuita considerado corto o poco flexible'
  ],
  [
'Tiempo de respuesta',
'Quejas sobre lentitud en la respuesta a consultas o soporte'
  ],
  [
'Sin comentario relevante',
"Respuestas vacias de contenido: 'No', 'nada que destacar', 'all good', etc."
  ],
  [
'Otro',
'Comentario con contenido pero que no encaja en ninguna categoria anterior'
  ],
];

const catsQ3 = categoriasQ3
  .map(([cat, desc]) => `- ${cat}: ${desc}`)
  .join('
');

const catsQ5 = categoriasQ5
  .map(([cat, desc]) => `- ${cat}: ${desc}`)
  .join('
');

return $input.all().map(item => ({
  json: {
...item.json,
    categorias_q3_texto: catsQ3,
categorias_q5_texto: catsQ5,
  }
}));

Évidemment, ces catégories ne sont pas universelles. Pour d’autres activités numériques, il faudrait les adapter. 

Étape 6 : Classer avec Gemini Flash

C’est le nœud qui envoie les champs ouverts à Gemini. Concrètement, nous analysons deux champs : le détail de l’incident pendant la réservation et le commentaire libre final.

Le modèle doit renvoyer uniquement un JSON valide, sans explications, sans markdown et sans texte additionnel. C’est fondamental parce que le nœud suivant attend de parser cette réponse et de la transformer en colonnes.

Configuration de base :

Node type: Google Gemini
Model: models/gemini-flash-lite-latest
Temperature: 0.1
Credential: [CREDENCIAL_GEMINI]

Prompt utilisé :

Tu es un classificateur de feedback d’utilisateurs d’un site de réservation d’hébergements ruraux. Tu dois analyser deux champs de texte et renvoyer UNIQUEMENT un JSON valide, sans texte additionnel, sans markdown, sans backticks.

Champ Q3 - Issue Detail (incident pendant la réservation) : "{{ $json['Q3 - Issue Detail'] }}"

Catégories autorisées pour Q3 (choisis-en une, ou utilise exactement le texte "Sin incidencia" si le champ est vide) :
{{ $json.categorias_q3_texto }}

Champ Q5 - Comments (commentaire libre) : "{{ $json['Q5 - Comments'] }}"

Catégories autorisées pour Q5 (choisis-en une, ou utilise exactement le texte "Sin comentario relevante" s’il est vide ou n’apporte pas de contenu comme 'Non', 'nada', 'all good') :
{{ $json.categorias_q5_texto }}

En plus :
- Si Q5 mentionne explicitement une plateforme concurrente (Booking.com, Airbnb, Vrbo, Expedia, HomeAway ou autre), indique menciona_competidor true et le nom détecté. Sinon, false et une chaîne vide.
- Traduis le contenu de Q5 en espagnol de manière fidèle et naturelle dans comentario_traducido_es. S’il est vide, renvoie une chaîne vide.
- Pour Q3, en plus de la catégorie, indique dans causa_raiz_resumen une phrase courte (maximum 8 mots) en espagnol qui résume la cause technique, utile pour regrouper des incidents similaires même s’ils sont rédigés différemment. S’il n’y a pas d’incident, chaîne vide.

Renvoie exactement ce format JSON :
{
  "q3_categoria": "",
  "q3_causa_raiz_resumen": "",
  "q5_categoria": "",
  "q5_menciona_competidor": false,
  "q5_competidor_detectado": "",
  "q5_comentario_traducido_es": ""
}

Le prompt fait plusieurs choses à la fois : 

• Il classe et traduit Q3.
• Il résume une cause racine courte pour les incidents.
• Il classe et traduit Q5.
• Il détecte si un concurrent est mentionné et traduit le commentaire libre en espagnol. 

Tout cela revient dans un JSON avec des champs fixes.

La partie importante est que le modèle ne décide pas librement quoi faire. Nous lui donnons des catégories autorisées, le format exact de sortie et nous lui demandons de ne pas ajouter de texte hors du JSON.

Étape 7 : Parser la réponse de l’IA

Ce nœud transforme la réponse de Gemini en colonnes utiles. 

Il extrait d’abord le texte renvoyé par le modèle, nettoie d’éventuels backticks ou blocs markdown puis tente de le convertir en JSON.

Il inclut aussi une couche de sécurité : si l’IA renvoie quelque chose qui ne peut pas être parsé, il marque la ligne comme Erreur de classification. Ainsi, le flux ne se casse pas à cause d’une réponse ponctuelle mal formée.

En plus, il force une règle importante pour notre cas d’exemple : si Q3 n’a pas de détail ou si l’utilisateur a indiqué qu’il n’a pas eu de problèmes, la catégorie Q3 reste Sin incidencia. 

Cela évite que l’IA interprète un commentaire de Q5 comme s’il s’agissait d’un incident du processus.

Code du nœud :

function extractModelText(json) {
  // Caso Gemini n8n actual:
  // item.json.content.parts[0].text
  if (json?.content?.parts?.[0]?.text) {
return json.content.parts[0].text;
  }

  // Otros formatos posibles según nodo/modelo
  if (typeof json?.text === 'string') return json.text;
  if (typeof json?.message === 'string') return json.message;
  if (typeof json?.output === 'string') return json.output;
  if (typeof json?.content === 'string') return json.content;

  // OpenAI/LangChain style fallback
  if (json?.message?.content) return json.message.content;
  if (json?.choices?.[0]?.message?.content) return json.choices[0].message.content;

  return '';
}

function cleanJsonText(raw) {
  return String(raw || '')
.replace(/```json/gi, '')
.replace(/```/g, '')
.trim();
}

const items = $input.all();
const originales = $('Construir contexto de categorias').all();

return items.map((item, index) => {
  const raw = cleanJsonText(extractModelText(item.json));

  let parsed;

  try {
parsed = JSON.parse(raw);
  } catch (e) {
parsed = {
  q3_categoria: 'Error de clasificacion',
  q3_causa_raiz_resumen: '',
  q5_categoria: 'Error de clasificacion',
  q5_menciona_competidor: false,
  q5_competidor_detectado: '',
  q5_comentario_traducido_es: ''
};
  }

  const original = originales[index] ? originales[index].json : {};

  const q3HadIssues = String(original['Q3 - Had Issues'] || '').trim().toLowerCase();
  const q3Detail = String(original['Q3 - Issue Detail'] || '').trim();

  if (!q3Detail || q3HadIssues === 'no') {
parsed.q3_categoria = 'Sin incidencia';
parsed.q3_causa_raiz_resumen = '';
  }
 
  return {
json: {
  'Record ID': original['Record ID'],
  'Timestamp': original['Timestamp'],
  'Market': original['Market'],
  'Q1 - Ease of Booking': original['Q1 - Ease of Booking'],
  'Q2 - Decision Driver': original['Q2 - Decision Driver'],
  'Q2 - Other (Specify)': original['Q2 - Other (Specify)'],
  'Q3 - Had Issues': original['Q3 - Had Issues'],
  'Q3 - Issue Detail': original['Q3 - Issue Detail'],

  'Q3 - Cluster Causa Raiz': parsed.q3_categoria || '',
  'Q3 - Causa Raiz Resumen': parsed.q3_causa_raiz_resumen || '',

  'Q4 - NPS Score': original['Q4 - NPS Score'],
  'Q5 - Comments': original['Q5 - Comments'],

  'Q5 - Cluster Tema': parsed.q5_categoria || '',
  'Q5 - Menciona Competidor': parsed.q5_menciona_competidor ? 'Si' : 'No',
  'Q5 - Competidor Detectado': parsed.q5_competidor_detectado || '',
  'Q5 - Comentario Traducido ES': parsed.q5_comentario_traducido_es || '',

  'Country': original['Country'],
  'Gender': original['Gender'],
  'Age': original['Age'],
  'Reply Requested': original['Reply Requested'],
  'Fecha Procesado IA': new Date().toISOString()
}
  };
});

Si tu changes le nom du nœud précédent, tu devras ajuster cette ligne :

const originales = $('Construir contexto de categorias').all();

Dans n8n, les références par nom de nœud doivent correspondre exactement. C’est pourquoi il vaut mieux utiliser des noms clairs et ne pas les changer ensuite sans revoir le code.

Étape 8 : Préparer Resultados_IA

Ce nœud fait un nettoyage final avant d’écrire les données dans la feuille de résultats. Il supprime les champs internes qui ne servent que pendant le processus, comme les catégories en texte que nous avions ajoutées pour le prompt.

Code du nœud :

// Limpia campos internos antes de escribir en Resultados_IA.

return $input.all().map(item => {
  const row = { ...item.json };
  delete row['_timestamp_unix'];
  delete row['_clasificacion_error'];
  delete row['_error_message'];
  delete row['categorias_q3_texto'];
  delete row['categorias_q5_texto'];

  return { json: row };
});

Cette étape ne transforme pas l’analyse, mais elle laisse la sortie plus propre. 

La feuille finale n’a pas besoin de conserver tout ce qui a été utilisé en interne pour classer, mais seulement les données que nous allons analyser ensuite.

Étape 9 : Écrire Resultados_IA

Le dernier nœud écrit la ligne enrichie dans une nouvelle feuille Google Sheets. 

Dans ce cas, nous utilisons une feuille appelée Resultados_IA et l’opération append, pour ajouter une nouvelle ligne par réponse traitée.

Configuration de base :

Node type: Google Sheets
Authentication: Service Account
Operation: Append
Document ID: [ID_DEL_SPREADSHEET_RESULTADOS]
Sheet name: [NOMBRE_HOJA_RESULTADOS]
Mapping mode: Auto-map input data
Credential: [CREDENCIAL_GOOGLE_SHEETS]

La feuille finale contient à la fois les données originales et les champs générés par l’IA. Par exemple :

• Record ID
• Timestamp
• Market
• Q1 – Ease of Booking
• Q2 – Decision Driver
• Q3 – Had Issues
• Q3 – Issue Detail
• Q3 – Cluster Causa Raiz
• Q3 – Causa Raiz Resumen
• Q4 – NPS Score
• Q5 – Comments
• Q5 – Cluster Tema
• Q5 – Menciona Competidor
• Q5 – Competidor Detectado
• Q5 – Comentario Traducido ES
• Country
• Gender
• Age
• Reply Requested
• Fecha Procesado IA

À partir d’ici, nous n’avons plus seulement des réponses isolées. Nous avons une table enrichie, avec des commentaires traduits, des incidents regroupés, des thèmes classés et des champs prêts à être utilisés dans des graphiques.

Ce que nous obtenons à la fin du processus

À la fin du workflow, chaque nouvelle réponse devient une ligne plus utile pour l’analyse. 

Nous conservons toujours la donnée originale, mais nous ajoutons des couches qui demandaient auparavant une révision manuelle.

En pratique, nous obtenons :

• Des commentaires ouverts traduits en espagnol.
• Des incidents classés par cause racine.
• Des commentaires regroupés par thème.
• La détection de mentions de concurrents.
• Une date de traitement par l’IA.
• Une table prête à être connectée à Looker Studio.

Cela ne remplace pas la révision humaine. Ce que cela fait, c’est enlever du travail mécanique.

Au lieu de commencer par lire cent commentaires en cinq langues, tu commences par voir des thèmes, des catégories, des fréquences et des commentaires traduits. Ensuite, tu peux réviser des échantillons et décider quelles actions ont du sens, comme nous le verrons dans le prochain et dernier article de la série.

Erreurs fréquentes lors de l’automatisation du feedback avec l’IA

Voyons les plus habituelles.

Laisser l’IA inventer des catégories

Si chaque exécution crée de nouvelles étiquettes, tu ne pourras plus rien comparer ensuite. 

Pour que le système fonctionne, l’IA doit classer dans une liste fermée ou, au moins, très contrôlée.

Ne pas valider le JSON renvoyé par le modèle

Même si tu demandes un format concret, il peut parfois mal répondre. C’est pourquoi le nœud de parsing doit nettoyer, essayer de convertir en JSON et prévoir les erreurs sans casser tout le flux.

Ne pas vérifier les doublons

Avant de publier le workflow, il vaut mieux l’exécuter en test et vérifier qu’une même réponse ne se retrouve pas plusieurs fois dans la deuxième feuille. 

Le nœud des nouveaux Record ID est ce qui t’évite de payer deux fois pour la même classification et de salir la feuille finale.

Utiliser Google Sheets comme base de données opérationnelle

Google Sheets fonctionne très bien comme entrée et sortie, mais il ne convient pas de faire des lectures constantes pour tout : catégories, statuts, vérifications, résultats et suivi des éléments déjà traités. 

Si tu en abuses, tu peux te retrouver avec des problèmes de quota ou un flux plus fragile que nécessaire.

Publier le flux sans le tester

Il faut d’abord l’exécuter manuellement, vérifier quelles données entrent, quelles données sortent, si le JSON se parse bien, s’il n’y a pas de doublons et si les catégories sont celles que tu veux.

Croire que l’IA exécutera tout le travail

L’IA classe et traduit, mais l’entreprise doit toujours interpréter. 

Une catégorie fréquente n’implique pas toujours une action immédiate. Il faut évaluer le volume, l’impact, la facilité de mise en œuvre et le contexte.

Étape suivante : transformer ces données en dashboard

Après ce workflow, nous avons déjà une feuille de résultats qui complète la feuille originale du formulaire. 

Nous savons non seulement ce que chaque utilisateur a répondu, mais nous avons aussi des champs préparés pour l’analyse : catégories, traductions, concurrents, incidents et date de traitement.

L’étape suivante et finale est :

Emmener ces données dans un dashboard et créer la governance de suivi.

Dans l’article suivant, nous verrons comment connecter les feuilles Google avec Data Studio, quelles métriques il est pertinent d’afficher et comment transformer le feedback en routine mensuelle de suivi.

Parce qu’automatiser l’analyse ne sert à rien si personne ne regarde les données ensuite, ce qui arrive généralement.