Préparer son fichier CSV pour l'import dans Feedier
Avant d'importer vos données dans Feedier, il est nécessaire de vérifier si le format de ce dernier et de son contenu respecte les prérequis Feedier.
Ce guide couvre les prérequis de format, les règles de nommage, et surtout les particularités liées aux différents types de questions Feedier.
Les règles de base du fichier CSV
Peu importe le contenu de votre fichier, certaines règles s'appliquent systématiquement.
Encodage et délimiteur. Utilisez l'UTF-8. Le délimiteur par défaut est la virgule, mais le point-virgule est aussi supporté — précisez-le à votre CS lead lors du setup. Ne mélangez jamais les deux dans un même flux d'import.
Ligne d'en-tête obligatoire. La première ligne de votre fichier doit contenir les noms de colonnes. Ces derniers ne doivent pas excéder 180 caractères (espace compris).
Stabilité des headers. Dans le cas d'imports automatisés. Une fois votre premier import réalisé et le mapping enregistré, les noms de colonnes ne doivent plus changer. Si vous modifiez un header, le mapping existant ne le reconnaîtra plus et l'import échouera silencieusement — ou pire, mappera la colonne ailleurs. Si un changement est inévitable, prévenez votre CS lead pour qu'il mette à jour le mapping ou le preprocessing.
Dates et heures. Gardez un format cohérent et de type ISO YYYY/MM/DD (ex :
2025-08-24ou2025-08-24T14:30:00).
Pourquoi le type de question change le format attendu
Feedier propose plusieurs types de questions (NPS, satisfaction, tableau de notation, emoji, texte libre, choix unique/multiple). Chacun alimente différemment les KPIs de la plateforme — Satisfaction Ratio, score NPS, analyse de sentiment — et le mode de calcul impose un format de données précis. Pour le détail du fonctionnement de chaque KPI, consultez l'article Feedier KPI and Scores.
Ce qu'il faut retenir pour le formatage de votre CSV :
NPS vs. Satisfaction : même échelle 0–10, mais pas le même calcul. Une colonne NPS et une colonne de satisfaction contiennent toutes deux des entiers entre 0 et 10, mais Feedier les traite différemment.
Le NPS classe les réponses en Promoteurs / Passifs / Détracteurs avant de calculer un score ; la satisfaction normalise la note en pourcentage (7/10 = 70%). Si vous mappez une colonne NPS comme question de satisfaction (ou inversement), vos dashboards afficheront des KPIs faux. Veillez à bien associer chaque colonne au bon type de question lors du mapping.
Tableaux de notation : une colonne par critère. Si votre survey contient un tableau de notation (ex : propreté, accueil, rapidité notés sur 5), chaque critère doit avoir sa propre colonne dans le CSV avec un entier dans l'échelle définie. Feedier calculera la moyenne pour le Satisfaction Ratio.
Echelle de satisfaction : Plusieurs points sont à vérifier.
- Attention aux échelles inversées. Si votre source de données utilise une échelle où 1 = très satisfait et 10 = très insatisfait (ou l'inverse de ce que Feedier attend). Il faut inverser les valeurs avant l'import, sinon vos meilleurs clients apparaîtront comme les plus mécontents dans les dashboards.
- Si votre fichier contient des valeurs textuelles (ex: Satisfait, Pas du tout satisfait, etc), il faudra les remplacer par des valeurs numériques pour que le résultat soit exploitables dans les rapports et dashboards.
Emoji / Smiley : des entiers, pas des icônes. Les questions emoji doivent être converties en valeurs numériques correspondant au rang (ex : 1 à 5). Vérifiez le mapping avec votre CS lead.
Choix unique / multiple : la valeur exacte de l'option. Les choix simple ne sont généralement pas à formater, mais ce n'est pas le cas pour un choix multiple = séparez les valeurs par le séparateur suivant : "
|" (à la place d'une virgule classique ou autre séparateur) dans une même colonne.
Les attributs (métadonnées contextuelles)
Au-delà des réponses aux questions, votre CSV contiendra probablement des attributs contextuels : email du client, identifiant ticket, date de création, pays, agence, etc. Ce sont des colonnes que Feedier ne traite pas comme des réponses mais comme des filtres et des segments.
Mêmes règles de formatage que les headers : minuscules, underscores, pas de caractères spéciaux. Les valeurs de dates doivent suivre un format ISO cohérent.
De la même manière que pour les question à choix multiples, séparez les valeurs d'un même attribut par le séparateur suivant : "|" (à la place d'une virgule classique ou autre séparateur) dans une même colonne.
Dédoublonnage : la contrainte d'unicité
Si vous envoyez des fichiers régulièrement (snapshots hebdomadaires, par exemple), un même enregistrement peut apparaître dans plusieurs fichiers successifs — un ticket qui passe de « en cours » à « résolu ». Sans règle d'unicité, vous l'importerez deux fois.
Ajouter la contrainte d'unicité en spécifiant une clé stable présente dans chaque ligne : ticket_id, case_number, ou tout identifiant qui ne change pas dans le temps.
Exemple de fichier complet
Voici un exemple de CSV qui combine attributs, NPS, satisfaction, tableau de notation et verbatim :
NPS (0 à 10) | Echelle de satisfaction - Aspect 1 (ex : 1 à 5) | Echelle de satisfaction - Aspect 2 (ex : 1 à 10) | Choix | Attribut | Verbatim |
8 | 4 | 2 | Réponse1|Réponse2|Réponse3 | Valeur1|Valeur2|Valeur3 | Text ou commentaire de satisfaction |
Checklist avant envoi
Avant de déposer votre fichier sur le SFTP ou de lancer l'import manuel, vérifiez :
Les headers ne dépassent pas 180 caractères
L'encodage est bien UTF-8.
Les colonnes NPS contiennent des entiers entre 0 et 10.
Les colonnes de satisfaction respectent l'échelle configurée dans l'enquête (pas d'échelle inversée).
Les verbatims contenant des virgules ou guillemets sont correctement encadrés.
Les dates utilisent un format cohérent.
La clé d'unicité (si activée) est présente dans chaque ligne.
Le fichier ne contient pas l'intégralité historique de votre base — uniquement les nouveaux enregistrements ou la fenêtre de temps définie.