Comment concevoir le flux d’une enquête : Skip Logic, Branching et questions conditionnelles

Une bonne enquête ne consiste pas seulement à rédiger de bonnes questions. Une bonne enquête montre la bonne question à la bonne personne, au bon moment.

Poser une question sur une expérience qu’un répondant n’a jamais vécue peut détériorer la qualité des données. Mais l’inverse est tout aussi dangereux : ne pas montrer une question critique à une personne qui aurait dû la voir.

Dans les projets de recherche plus complexes, le flux d’enquête n’est pas un détail technique. Il fait partie de la conception méthodologique.

Skip Logic, Branching Logic et Conditional Logic sont les outils qui permettent de construire cette architecture. Bien utilisés, ils réduisent la fatigue du répondant, masquent les questions non pertinentes, affichent les questions sensibles uniquement aux groupes concernés et produisent des données plus propres. Mal utilisés, ils peuvent envoyer les répondants vers les mauvaises sections, masquer des questions à des personnes concernées, créer des données manquantes difficiles à expliquer et affaiblir le reporting.

Ce guide explique comment concevoir un flux d’enquête, comment utiliser les questions gatekeeper, comment fonctionne la logic dans les enquêtes multilingues, quelles erreurs de flow sont fréquentes, comment tester les règles et comment PublicOp Advanced Polls s’intègre dans ce workflow.

Qu’est-ce qu’un flux d’enquête ?

Le flux d’enquête désigne la structure qui détermine quelles questions les répondants voient et dans quel ordre.

Dans une enquête simple, le flux peut être linéaire :

Question 1
Question 2
Question 3
Question 4
Thank You Page

Mais dans une recherche plus complexe, il n’est souvent pas pertinent de montrer toutes les questions à tous les répondants.

Par exemple :

Une personne qui n’a jamais utilisé un produit ne devrait pas voir les questions d’expérience produit.
Une personne qui n’a pas participé à une formation ne devrait pas répondre aux questions de satisfaction sur cette formation.
Un répondant qui ne donne pas son consentement ne devrait pas continuer l’enquête.
Un répondant qui donne une mauvaise note peut avoir besoin d’une question de suivi : “pourquoi ?”
Des rôles différents peuvent nécessiter des blocs de questions différents.

Dans ces cas, le flux devient conditionnel.

Qu’est-ce que le Skip Logic et le Branching Logic ?

Skip Logic permet de sauter certaines questions selon la réponse du répondant.

Exemple simple :

Question :
Avez-vous utilisé ce produit au cours des 6 derniers mois ?

- Oui
- Non

Flux :

Si la réponse est Oui :
Afficher les questions sur l’expérience produit.

Si la réponse est Non :
Sauter les questions sur l’expérience produit.

Branching Logic dirige les répondants vers différents chemins ou sections.

Exemple :

Si le répondant est enseignant :
Aller à la section enseignants.

Si le répondant est étudiant :
Aller à la section étudiants.

Si le répondant représente une organisation :
Aller à la section représentants d’organisation.

Le Skip Logic désigne généralement le fait de sauter des questions. Le Branching Logic désigne plutôt l’orientation vers différents chemins. En pratique, les deux font partie de la conception d’un flux d’enquête conditionnel.

Pourquoi le flux d’enquête est essentiel pour la qualité des données

Le flux d’enquête ne concerne pas seulement l’expérience utilisateur. Il affecte directement la qualité des données.

Un mauvais flux peut :

• afficher des questions non pertinentes,
• augmenter la fatigue du répondant,
• faire répondre les mauvaises personnes aux mauvaises questions,
• masquer des questions critiques aux bonnes personnes,
• créer des missing data difficiles à expliquer dans l’export,
• rendre les dénominateurs difficiles à interpréter dans les rapports,
• mesurer le même concept de manière incohérente,
• réduire la confiance dans les résultats.

Un bon flux peut :

• afficher uniquement les questions pertinentes,
• rendre l’enquête plus courte et plus significative,
• éviter d’exposer inutilement les répondants à des questions sensibles,
• produire des données plus propres,
• séparer plus correctement les groupes de répondants,
• rendre le reporting plus défendable.

Autrement dit, un bon flux d’enquête est une couche invisible de contrôle qualité.

Comment fonctionne Branching / Skip Logic dans PublicOp ?

Dans PublicOp, Branching / Skip Logic est disponible dans Advanced Polls. QuickPoll est conçu pour des enquêtes de feedback courtes et linéaires ; il ne prend pas en charge les flux complexes.

Dans Advanced Polls, les règles fonctionnent selon une structure IF / THEN :

IF :
Le répondant a sélectionné une réponse spécifique à une question spécifique

THEN :
Aller à une question spécifique
Aller à une section spécifique
Sauter une section
Terminer l’enquête

Dans PublicOp, cette logic repose sur les structures internes Question ID et Option ID, et non sur le texte visible. Une règle est liée à l’identité cachée de l’option, pas au mot affiché au répondant.

C’est particulièrement important dans les enquêtes multilingues. La même option peut apparaître comme “Yes” en anglais, “Oui” en français, “Ja” en allemand et “Evet” en turc. Si ces options partagent le même Option ID, elles déclenchent la même règle.

Qu’est-ce que Rule Builder ?

Dans PublicOp, les règles de logic sont créées dans Logic Editor / Rule Builder à l’intérieur de l’éditeur visuel.

La structure générale est :

IF la réponse correspond à une condition
THEN diriger le répondant vers une cible

Par exemple :

IF “Avez-vous utilisé ce service ?” = “Non”
THEN sauter la section “Expérience du service”.

Rule Builder applique le flux conditionnel conçu par le chercheur. Il ne conçoit pas le flux tout seul. Le chercheur doit toujours décider quelle réponse doit ouvrir quelle section.

Cette distinction est importante :

PublicOp applique le flow.
Le chercheur conçoit le flow.

Quels types de questions fonctionnent bien avec la logic ?

Branching / Skip Logic fonctionne le mieux avec des questions fermées, basées sur des options.

Single choice

Single choice est le type de question le plus propre et le plus recommandé pour la logic d’enquête.

Exemple :

Avez-vous utilisé ce service au cours des 6 derniers mois ?

- Oui
- Non

Cela permet un flux clair :

Oui -> Questions d’expérience
Non -> Sauter les questions d’expérience

Multiple choice

Multiple choice peut aussi être utilisé pour créer une logic selon qu’une option précise a été sélectionnée ou non.

Exemple :

Quels services avez-vous utilisés ?

- Service A
- Service B
- Service C

Si le répondant a sélectionné “Service B”, la section d’expérience Service B peut être affichée.

Cependant, la logic Multiple choice peut devenir plus complexe que la logic Single choice. Si un même répondant peut déclencher plusieurs sections, la charge de test augmente.

Likert / rating

Les réponses Likert ou rating peuvent être utilisées pour la logic lorsqu’elles sont traitées comme des options sélectionnables.

Exemple :

Comment évaluez-vous ce service de 1 à 5 ?

Une question de suivi peut être affichée aux répondants qui donnent une mauvaise note :

Si la note est 1, 2 ou 3 :
Afficher “Quelle est la principale raison de votre note ?”

Consent

Les questions de consentement peuvent aussi orienter le répondant.

Exemple :

Acceptez-vous de participer à cette recherche ?

- Oui, j’accepte
- Non, je n’accepte pas

Flux :

Non -> End survey
Oui -> Continuer vers les questions de l’enquête

Numeric input et texte ouvert

Dans PublicOp, la logic est principalement construite sur des options fermées. La logic fondée sur Numeric input, Short text ou Long text, par exemple “âge > 18” ou “le texte contient tel mot”, n’est pas prise en charge.

Si l’âge, la tranche de revenu ou le statut d’expérience doit orienter le flux, il est plus sûr de concevoir la question sous forme d’options.

Exemple :

Quelle est votre tranche d’âge ?

- Moins de 18 ans
- 18-24
- 25-34
- 35-44
- 45+

Cette structure est plus adaptée à la logic qu’une saisie numérique libre.

Types de conditions prises en charge

La logic PublicOp repose sur des réponses fermées.

Les conditions généralement prises en charge sont :

equals
not equals
selected option includes
selected option does not include
contains
does not contain

Elles sont particulièrement utiles pour les questions Single choice et Multiple choice.

Les modèles non pris en charge ou trop avancés incluent :

greater than
less than
is empty
is not empty
conditions nested complexes
groupements AND / OR avancés
logic par plage numérique
logic basée sur le contenu d’un texte

Plusieurs règles peuvent être enchaînées, mais les structures de conditions nested complexes ne sont pas prises en charge. Pour cette raison, il vaut mieux garder l’architecture de l’enquête aussi simple que possible.

Quelles actions la logic peut-elle déclencher ?

Dans PublicOp Advanced Polls, la logic peut déclencher des actions comme :

Skip to question
Skip to section
Skip to section end
End survey

Voici leur signification.

Skip to question

Le répondant est envoyé vers une question ultérieure précise. Les questions situées entre les deux sont sautées.

Skip to section

Le répondant est dirigé vers une section spécifique. C’est plus propre pour les grands blocs.

Skip to section end

Le répondant saute le reste d’une section.

End survey

L’enquête du répondant est terminée. C’est utile pour un refus de consentement ou un screen-out.

Les actions non prises en charge incluent :

• envoyer les répondants vers différentes pages de rapport,
• générer différentes pages de résultats,
• rendre une question obligatoire ou optionnelle par logic,
• attribuer des valeurs par défaut par logic,
• changer le texte d’une question par logic.

Changer dynamiquement le texte d’une question relève de Piping, pas de Branching / Skip Logic.

Pourquoi la structure en sections est importante

Dans les grandes enquêtes, configurer la logic question par question peut rapidement devenir difficile à gérer. C’est pourquoi la structure en Section est importante dans PublicOp Advanced Polls.

Une section est une page ou un bloc dans l’enquête.

Exemple de structure :

Section 1 : Démographie
Section 2 : Utilisateurs du produit
Section 3 : Non-utilisateurs
Section 4 : Évaluation de satisfaction
Section 5 : Feedback ouvert

Une bonne pratique est :

Regrouper les questions sur la même expérience dans la même section.
Ne pas mélanger les questions destinées à des groupes différents dans la même section.
Utiliser la question gatekeeper pour diriger les répondants vers la bonne section.

Structure faible :

Une page mélange les questions pour utilisateurs et non-utilisateurs.
Chaque question nécessite une logic complexe séparée.

Meilleure structure :

Les questions pour utilisateurs sont dans une section.
Les questions pour non-utilisateurs sont dans une autre section.
La question gatekeeper dirige les répondants vers la bonne section.

Cela facilite les tests et l’interprétation des exports.

Qu’est-ce qu’une question gatekeeper ?

Une gatekeeper question ou trigger question est la question principale qui détermine si un répondant doit voir un bloc ultérieur.

Exemple :

Avez-vous utilisé ce service au cours des 6 derniers mois ?

Cette question ouvre ou ferme des sections suivantes :

Oui -> Section expérience d’utilisation
Non -> Sauter la section expérience d’utilisation

La question gatekeeper est la porte du flux d’enquête.

Les bonnes questions gatekeeper sont :

• claires,
• fermées,
• mutuellement exclusives,
• utiles pour l’analyse,
• non répétées avec une formulation légèrement différente,
• reliées à toutes les sections concernées en aval.

Ne posez pas deux fois la même variable gatekeeper

Une erreur fréquente dans les enquêtes complexes consiste à poser le même concept plusieurs fois et à utiliser les deux versions comme triggers.

Par exemple :

Avez-vous utilisé ce service ?

puis plus tard :

Avez-vous bénéficié de ce service ?

Si ces deux questions ouvrent des blocs différents, l’enquête peut se dérégler lorsque les répondants y répondent différemment.

Cela peut créer :

• une incertitude sur la variable principale,
• des sections différentes selon des triggers différents,
• des contradictions dans le jeu de données,
• des blocs non pertinents affichés à certains répondants,
• des blocs pertinents masqués à d’autres.

Meilleure pratique :

Utiliser une seule question gatekeeper principale.
Relier toutes les sections concernées à ses Option IDs.
Ne pas reposer le même concept comme second trigger.

Vous pouvez demander des détails plus tard, mais gardez la variable principale de routage unique.

Comment concevoir les questions d’expérience impliquant plusieurs parties

Certaines enquêtes portent sur des expériences qui peuvent concerner le répondant, un partenaire, un membre de la famille, un collègue, une organisation ou une autre personne.

Exemple général :

Qui a vécu cette expérience ?

- Moi
- Mon partenaire / une autre personne
- Nous deux
- Personne

Ces questions exigent une conception de flow attentive.

Un modèle simple est :

Moi -> section expérience du répondant
Mon partenaire / une autre personne -> section partenaire / autre personne
Nous deux -> section répondant, puis section partenaire / autre personne
Personne -> sauter les deux sections

Pour ce type de question gatekeeper, Single choice est généralement plus propre. Multiple choice peut rendre l’arbre de logic difficile à contrôler, surtout si plusieurs sections peuvent être déclenchées en même temps.

L’option “Nous deux” doit être testée très attentivement.

Exemple :

“Moi” ouvre seulement la section self.
“Mon partenaire” ouvre seulement la section partenaire.
“Nous deux” ouvre la section self puis la section partenaire.
“Personne” saute les deux sections.

L’objectif est de définir clairement quelle réponse ouvre quel bloc.

Ne confondez pas Piping et Branching / Skip Logic

Piping transporte une réponse précédente dans le texte d’une question ultérieure.

Exemple :

Question précédente :
Quel service avez-vous le plus utilisé ?

Réponse :
Service A

Question ultérieure :
Pouvez-vous décrire votre expérience avec Service A ?

Piping personnalise le texte.

Branching / Skip Logic change le chemin de l’enquête.

Exemple :

Si Service A a été sélectionné :
Aller aux questions Service A.

Si Service B a été sélectionné :
Aller aux questions Service B.

En résumé :

Piping = change la formulation.
Branching / Skip Logic = change le chemin.

Les deux peuvent être utilisés ensemble, mais ce ne sont pas la même chose.

QuickPoll ou Advanced Polls ?

Dans PublicOp, QuickPoll et Advanced Polls répondent à des besoins différents.

QuickPoll sert aux enquêtes :

• courtes,
• rapides,
• linéaires,
• à faible friction,
• sans logic complexe.

Advanced Polls sert aux enquêtes :

• plus longues,
• organisées en sections,
• avec routage conditionnel,
• proposant différents chemins à différents groupes,
• destinées à des recherches plus approfondies.

La distinction doit être claire :

Enquête courte et standard = QuickPoll
Flux conditionnel et enquête de recherche = Advanced Polls

Si une logic complexe est nécessaire, il ne faut pas forcer QuickPoll. Il faut utiliser Advanced Polls.

Comment la logic est-elle préservée dans les enquêtes multilingues ?

Dans les enquêtes multilingues, il est essentiel que la logic dépende d’IDs, et non du texte traduit.

Dans PublicOp, la logic fonctionne avec :

Question ID
Option ID

Ainsi, même si le texte visible change selon la langue, la logic reste stable tant que l’Option ID reste le même.

Exemple :

Anglais : Yes
Français : Oui
Allemand : Ja
Turc : Evet

Si ces réponses sont liées au même Option ID, elles déclenchent la même règle.

C’est l’un des points forts de PublicOp pour les recherches multilingues. Mais cela implique une condition :

L’arbre de questions doit rester symétrique dans toutes les langues.

PublicOp ne prend pas en charge un chemin d’enquête en anglais et un chemin totalement différent en français. Comme la plateforme utilise une architecture single dataset, toutes les versions linguistiques partagent la même structure de questions sous-jacente.

La traduction ne casse pas forcément la logic, mais elle peut casser le sens

Une traduction IA ou manuelle ne casse pas la logic technique si les Option IDs restent inchangés. Mais si le sens d’une option change dans la traduction, la méthodologie peut être compromise.

Par exemple, si une option signifie “je ne l’ai jamais utilisé” dans une langue, mais devient “je l’ai rarement utilisé” dans une autre, le même Option ID porte désormais des significations différentes. Le flow fonctionne techniquement, mais le sens de recherche n’est plus cohérent.

Dans la conception d’une logic multilingue, vérifiez :

• Les significations des options sont-elles cohérentes entre les langues ?
• Les options gatekeeper sont-elles correctement traduites ?
• Les options comme “aucun”, “les deux” et “non applicable” sont-elles claires dans chaque langue ?
• Le même arbre de questions est-il conservé dans toutes les langues ?
• Preview mode a-t-il été utilisé pour tester les mêmes chemins de réponse dans plusieurs langues ?

LANGUAGE column n’est pas une condition de logic

PublicOp conserve la langue de réponse dans la LANGUAGE column. C’est utile pour l’export et l’analyse.

Cependant, la logic fondée sur LANGUAGE, par exemple “afficher une question supplémentaire uniquement aux répondants en français”, n’est pas prise en charge. La logic dépend des réponses du participant, pas de la langue de réponse.

L’analyse par langue doit être réalisée ensuite via Live Report, Global Filter ou l’analyse après export.

Comment la logic améliore la qualité des données

Une logic bien conçue améliore la qualité des données de plusieurs façons.

Elle masque les questions non pertinentes

Les répondants ne voient pas les questions qui ne les concernent pas. Cela raccourcit l’enquête et réduit la fatigue.

Elle montre les questions d’expérience au bon groupe

Les personnes qui n’ont pas vécu une expérience ne sont pas invitées à l’évaluer.

Elle aide à gérer les questions sensibles

Les questions sensibles peuvent être affichées uniquement aux groupes concernés. Cela ne supprime pas tout risque éthique, mais c’est préférable à un affichage inutile.

Elle produit des données de sous-groupes plus propres

Les utilisateurs d’un produit, certains groupes de rôles ou les répondants avec une mauvaise note peuvent être dirigés vers les bonnes sections.

Elle rend les questions ouvertes de suivi plus pertinentes

Demander “pourquoi ?” aux répondants qui ont donné une mauvaise note est plus ciblé que poser la même question à tout le monde.

Erreurs fréquentes dans les flux d’enquête

Les grandes enquêtes complexes rencontrent souvent les mêmes problèmes de flow.

Afficher des questions aux mauvaises personnes

Si l’on interroge des répondants sur une expérience qu’ils n’ont pas vécue, les données deviennent bruyantes.

Exemple :

Demander à une personne qui n’a jamais utilisé un service d’en évaluer la qualité.

Ne pas afficher les questions aux bonnes personnes

C’est plus discret, mais tout aussi dangereux. Le répondant appartient au groupe concerné, mais une erreur de logic lui masque une question critique.

Cela crée des données manquantes qui ne seront parfois repérées qu’après export.

Utiliser deux questions trigger pour le même concept

Si la même expérience ou le même statut est demandé deux fois, des contradictions peuvent apparaître. Il devient difficile de savoir quelle réponse doit contrôler le flow.

Relier les questions d’un même bloc à des conditions différentes

Les premières questions d’un bloc peuvent s’ouvrir correctement, tandis que les dernières sont liées à une autre condition. Cela crée des missing data au niveau du bloc.

Meilleure pratique :

Toutes les questions d’un même bloc doivent être reliées à la même condition gatekeeper principale.

Mal gérer les options “les deux”

Dans les structures self / partner / both, l’option “les deux” doit généralement ouvrir les deux sections concernées. Si elle n’en ouvre qu’une seule, le jeu de données devient incomplet.

Mal configurer le consentement

Si des répondants qui ne donnent pas leur consentement peuvent continuer, cela crée des problèmes éthiques et méthodologiques. Un refus de consentement doit généralement conduire à End survey.

Prendre les réponses partielles pour des erreurs de flow

Un répondant qui abandonne l’enquête en cours de route ne signale pas automatiquement une erreur de flow. Les réponses partielles doivent être interprétées avec prudence.

Supposer que le flow fonctionne sans contrôler les réponses completed

Un preview réussi ne suffit pas. Après le lancement, les données exportées doivent être contrôlées avec des croisements logiques.

Pourquoi tester la logic est indispensable

Une logic ne doit jamais être publiée sans test.

La difficulté est que beaucoup d’erreurs de logic sont invisibles pour le répondant. Le répondant ne voit que le chemin qui lui est présenté. Il ne peut pas savoir quelle question il aurait dû voir mais n’a pas vue.

Les chercheurs doivent donc tester différents chemins de réponse.

PublicOp propose un preview / test mode qui permet de tester les chemins d’enquête. Dans les enquêtes multilingues, les chercheurs peuvent changer de langue et vérifier que les mêmes chemins de réponse sont conservés.

Cependant, PublicOp ne détecte pas automatiquement toutes les questions inaccessibles, tous les conflits de logic ou tous les problèmes de validation de flow. Le test manuel est indispensable.

Checklist de test de survey logic

Avant publication, vérifiez :

Toutes les questions gatekeeper ont-elles été testées ?
Chaque option de réponse a-t-elle été testée ?
Les options “aucun” ou “non applicable” sautent-elles les bonnes sections ?
Les options “les deux” ouvrent-elles toutes les sections nécessaires ?
Le refus de consentement termine-t-il correctement l’enquête ?
Les répondants avec une mauvaise note voient-ils la question de suivi ?
Les répondants avec une bonne note sautent-ils les suivis inutiles ?
Chaque section est-elle atteignable par au moins un chemin de test ?
Toutes les questions d’un même bloc sont-elles ouvertes par la même condition ?
Les versions multilingues produisent-elles le même flow pour les mêmes réponses ?

Les tests par personas sont particulièrement utiles.

Exemples :

Répondant sans expérience pertinente
Répondant avec seulement une expérience personnelle
Répondant avec expérience du partenaire / d’une autre personne
Répondant avec les deux types d’expérience
Répondant mineur
Répondant dans un rôle spécifique
Répondant qui refuse le consentement
Répondant avec mauvaise note
Répondant avec bonne note

Une grande enquête ne devrait pas être publiée avant que ces chemins soient testés.

Validation du flow après publication

Le test avant publication ne suffit pas. Une fois les premières données collectées, le flow doit être validé sur le jeu de données.

Les contrôles après publication peuvent poser les questions suivantes :

Combien de personnes ont répondu à un bloc qu’elles n’auraient pas dû voir ?
Combien de personnes qui auraient dû voir un bloc l’ont laissé vide ?
Les réponses gatekeeper sont-elles cohérentes avec les réponses de bloc ?
Toutes les questions d’un même bloc ont-elles été répondues par le même groupe éligible ?
Les répondants “les deux” ont-ils répondu aux deux sections concernées ?
Les répondants sans consentement ont-ils continué ?

Ces contrôles doivent porter en priorité sur les réponses completed. Les réponses partial peuvent aussi être examinées, mais toute valeur vide dans une réponse partielle n’est pas une erreur de flow. Le répondant peut simplement avoir abandonné.

PublicOp ne réalise pas cette validation automatiquement. Les chercheurs doivent exporter les données et effectuer des contrôles logiques dans Excel, SPSS ou un autre outil d’analyse.

Comment interpréter les données exportées après logic

Les questions sautées peuvent apparaître comme vides, nulles ou system missing dans l’export.

La limite importante est la suivante :

L’export PublicOp ne distingue pas automatiquement “vue mais non répondue” de “non affichée à cause de la logic”.

Les chercheurs doivent interpréter les missing data à partir de la carte de logic.

Par exemple :

Ce bloc est-il vide parce que le répondant n’a pas répondu ?
Ou parce que le répondant n’a jamais vu ce bloc ?

Cette distinction est critique pour le reporting.

Parfois, la formulation la plus sûre est :

Parmi les répondants ayant répondu à cette question...

Dans certains cas, la formulation suivante peut être trop forte :

Parmi tous les répondants remplissant cette condition...

S’il y a eu des erreurs de flow ou des changements de version, il faut utiliser une formulation plus prudente.

PublicOp conserve les Variable Labels, Value Labels, le Codebook et la LANGUAGE column lors de l’export. La logic ne casse pas la structure d’export. Mais l’interprétation des valeurs manquantes reste un travail de nettoyage des données par le chercheur.

Comment Live Report fonctionne avec la logic

Dans PublicOp, si une question est sautée à cause de la logic, Live Report rapporte cette question sur la base des répondants qui l’ont vue et y ont répondu. Les répondants qui n’ont jamais vu la question ne sont pas inclus dans le dénominateur de cette question.

C’est généralement correct. Compter des personnes qui n’ont jamais vu une question comme non-répondants serait trompeur.

Cependant, l’interprétation du rapport doit tenir compte des dénominateurs.

Par exemple :

Cette question peut avoir été répondue par 37 personnes, et non par les 100 répondants.

Global Filter peut être utilisé pour examiner des sous-groupes, comme un rôle spécifique ou des répondants ayant vécu une expérience précise.

Mais plus l’échantillon devient petit, plus l’interprétation devient fragile. Trop de branching peut créer des sous-groupes trop réduits.

Quand ne pas utiliser la logic

La logic est puissante, mais elle ne doit pas être utilisée partout.

Soyez prudent lorsque :

• la taille de l’échantillon est faible,
• chaque petite différence devient un chemin séparé,
• la maintenance de l’enquête devient difficile,
• le nombre de scénarios de test devient ingérable,
• certaines questions risquent de devenir inaccessibles,
• il est important que tous les répondants répondent aux mêmes questions centrales,
• l’enquête doit rester courte et rapide.

Dans certains cas, il peut être préférable d’utiliser des options comme :

Non applicable
Je ne sais pas
Je préfère ne pas répondre
Je n’ai pas vécu cette expérience

Ces options donnent au répondant une sortie honnête tout en gardant l’information visible dans les données.

Dans les recherches à petit échantillon, trop de branching peut diviser les données en sous-groupes trop petits pour être interprétés.

La logic ne résout pas tous les risques éthiques des questions sensibles

La logic peut servir à afficher des questions sensibles uniquement aux répondants concernés. C’est une bonne pratique. Mais cela ne supprime pas tout risque éthique.

Les chercheurs doivent se demander :

• la question gatekeeper est-elle claire et sûre ?
• un répondant peut-il être mal classé dans une section sensible ?
• faut-il proposer “je préfère ne pas répondre” ?
• le consentement et l’information apparaissent-ils avant les sections sensibles ?
• les questions ouvertes obligatoires sont-elles appropriées ?
• le reporting sur de petits sous-groupes peut-il identifier des répondants ?

Dans les recherches sensibles, “nous avons masqué la question avec la logic” ne suffit pas. La logic n’est qu’une partie de la conception éthique.

Changements de version et reporting

Dans les grandes enquêtes, un problème de flow peut être découvert après le lancement et corrigé dans une version ultérieure.

Dans ce cas, les données des anciennes et nouvelles versions doivent être traitées avec prudence.

Points importants :

PublicOp ne corrige pas automatiquement les anciennes données selon le nouveau flow.
Si des versions antérieures ont affiché des questions aux mauvaises personnes, cela doit être noté.
Si des versions antérieures ont masqué des questions aux bonnes personnes, la perte de données doit être évaluée.
Si les versions ont utilisé des flows différents, les comparaisons nécessitent une note méthodologique.

Les données d’une ancienne version ne doivent pas toujours être supprimées. Mais elles doivent être utilisées avec limites, notes et prudence.

Dans certains cas, la formulation la plus sûre est :

Parmi les répondants ayant répondu à cette question...

Une formulation plus forte peut être risquée :

Parmi tous les répondants remplissant cette condition...

Si le flow a changé, le rapport doit inclure une note méthodologique.

Quel est le rôle de PublicOp ?

PublicOp ne doit pas être présenté comme un système qui “pense” automatiquement la logic.

Un positionnement plus exact est :

PublicOp est un outil professionnel de Research Operations qui applique le flux conditionnel conçu par le chercheur.

PublicOp :

• prend en charge Branching / Skip Logic dans Advanced Polls,
• propose Rule Builder pour créer des règles IF / THEN,
• utilise des structures Question ID et Option ID afin que la logic ne dépende pas du texte,
• prend en charge le routage par sections,
• permet des flux de screen-out avec End survey,
• conserve la même structure de logic dans les enquêtes multilingues,
• permet de tester les flux avec Preview / Test mode,
• exporte les données brutes en CSV, Excel et SPSS,
• aide à examiner les résultats de sous-groupes avec Live Report et Global Filter,
• préserve les structures single dataset et LANGUAGE column.

PublicOp ne fait pas :

• détection automatique de toutes les erreurs de logic,
• détection de toutes les questions inaccessibles,
• résolution automatique des conflits de logic,
• conception automatique du flow,
• branching complexe dans QuickPoll,
• flows totalement différents selon la langue,
• étiquetage automatique “vue mais non répondue” vs “non affichée à cause de la logic” dans l’export,
• génération automatique d’un rapport de validation du flow,
• quota sampling ou panel screening.

Connaître ces limites aide les chercheurs à utiliser la plateforme correctement.

Conseils pratiques pour concevoir un flux d’enquête

1. Dessinez d’abord la carte du flow

Avant d’ouvrir l’éditeur d’enquête, écrivez les chemins principaux :

Qui doit voir quelles sections ?
Quelle réponse ouvre quelle section ?
Quelle réponse termine l’enquête ?
Quelles sections sont visibles par tout le monde ?

2. Utilisez une seule question gatekeeper par concept

N’utilisez pas deux questions trigger différentes pour le même concept. Choisissez une question gatekeeper principale et reliez toutes les sections pertinentes à cette question.

3. Gardez les sections propres

Regroupez les questions sur la même expérience dans la même section. Ne mélangez pas les questions destinées à des groupes différents dans une seule section.

4. Préférez Single choice pour les routages critiques

Pour les questions essentielles de flow, Single choice est généralement plus sûr que Multiple choice. La logic Multiple choice exige davantage de tests.

5. Testez soigneusement les options “les deux”

Les options comme “les deux” sont une source fréquente d’erreurs de flow. Si elles doivent ouvrir deux sections, vérifiez que les deux sont effectivement atteintes.

6. Séparez Piping et logic

Piping personnalise le texte. Branching change le chemin. Ce ne sont pas la même chose.

7. Testez les versions multilingues

Même si la logic est basée sur des IDs, la traduction peut modifier le sens. Vérifiez que les options gatekeeper signifient la même chose dans chaque langue.

8. Validez avec les données réelles après publication

Après les premières réponses, exportez le jeu de données et effectuez des contrôles logiques. Cette étape est particulièrement importante pour les grands projets de recherche.

Conclusion

La conception du flux d’enquête est l’un des éléments les plus importants et les plus faciles à négliger dans la qualité de la recherche.

Un bon flow :

• montre la bonne question au bon répondant,
• masque les questions non pertinentes,
• réduit la fatigue du répondant,
• gère plus prudemment les questions sensibles,
• améliore la qualité des données,
• renforce le reporting.

Un mauvais flow :

• montre des questions aux mauvaises personnes,
• masque des questions critiques aux bonnes personnes,
• crée des missing data,
• divise mal les sous-groupes,
• affaiblit le reporting,
• réduit la confiance dans l’étude.

Dans les grands projets de recherche, la conception du flux d’enquête n’est pas une magie technique. C’est une architecture méthodologique.

PublicOp Advanced Polls aide les chercheurs à appliquer une logic IF / THEN, à préserver le flow dans les enquêtes multilingues grâce aux structures Question ID et Option ID, et à soutenir le contrôle qualité avec Live Report et Data Export.

Mais concevoir, tester, valider et interpréter prudemment le flow reste la responsabilité du chercheur.