Survey programming

• La programmation d’une enquête se divise généralement en trois étapes : la planification, la programmation et la phase de test. Dans la pratique, ces étapes ne sont pas clairement séparées : la programmation d’une enquête est souvent un processus itératif.
• Utilisez les outils de votre plateforme d’enquête (comme le formatage HTML, les champs de notes et les contraintes) pour faciliter l’administration de l’enquête par les enquêteurs.
• Harmonisez les noms et les valeurs des variables, à la fois au sein d’une même enquête et d’une enquête à l’autre, afin de réduire le temps consacré au nettoyage des données.
• Utilisez des conditions de pertinence pour sauter les questions qui ne s’appliquent pas au répondant, ou pré-remplissez les champs pour lesquels vous disposez déjà d’informations plutôt que de répéter les questions, de façon à minimiser la charge de travail des répondants.
• Prévoyez le temps nécessaire pour tester le formulaire afin de pouvoir identifier et corriger les erreurs de programmation avant le lancement de l’enquête.

   

Le travail de conception d’une enquête commence par l’élaboration d’une série de questions. Ces questions, ainsi que la logique associée, sont ensuite programmées dans le logiciel de CAPI. Les questions et les modules seront soumis à plusieurs phases d’examen. Des modifications peuvent être apportées (et le seront) à divers stades, que ce soit pendant les phases de conception, de programmation et de test ou lors de la mise en œuvre: il est important de s’y préparer. Vous devez être prêt à documenter toutes les modifications apportées aux questions et au code de l’enquête. Lors de la phase de programmation initiale, il est recommandé de procéder à un « gel du code », procédure décrite plus bas, pour vous donner le temps de programmer une version stable de l’enquête. Par la suite, il est également conseillé de prévoir le temps nécessaire à l’intégration des changements et à la mise à jour de l’historique des modifications.

Comme la programmation d’une enquête est un processus itératif, il y a de fortes chances pour que vous deviez modifier l’enquête après son déploiement sur le terrain, aussi bien pour résoudre des problèmes de programmation que pour ajouter ou supprimer des questions. Ces modifications de l’enquête doivent elles aussi être conçues, programmées et testées, et vous devez donc mettre au point un protocole à cet effet. Il peut s’agir d’un plan très simple, comme : « Avant de déployer une version actualisée de l’enquête, nous budgétisons trois jours de travail pour programmer et tester les modifications, et un jour pour former les enquêteurs à ces modifications ». La mise en place d’un tel protocole avant le lancement de l’enquête vous évitera d’avoir à créer et à mettre en œuvre une stratégie pour gérer les modifications une fois l’enquête commencée. Ce travail de planification contribue également à réduire le nombre d’itérations nécessaires pour finaliser l’enquête, ce qui permet de gagner du temps et de l’argent. Avant de se lancer dans la programmation, il est utile de réfléchir aux éléments suivants :

Le contrôle de versions

Vous aurez très probablement deux versions de votre instrument : un document Word et le fichier utilisé par la plateforme d’enquête (par exemple, dans SurveyCTO, il s’agit d’un tableur Google Sheets/Excel). En cas de modification de l’instrument d’enquête, ces deux fichiers doivent être mis à jour. Le système de contrôle de versions doit être le même pour les deux documents, et les deux versions qui se correspondent doivent être clairement identifiées comme telles. Une solution très simple consiste à nommer les deux fichiers « Enquête_Nom_V##.extension de fichier », ou encore « Enquête_Nom_Date.extension de fichier ». 

• Outre le contrôle de versions, il est important de documenter tout ce qui a été modifié, et pourquoi. Si vous utilisez SurveyCTO, vous avez la possibilité d’ajouter une colonne au formulaire xlsx (voir l’image ci-dessous). Cette colonne peut servir à noter le numéro de version du formulaire et à consigner les modifications. ¹
• Le contrôle de versions est particulièrement important si plusieurs personnes participent à la programmation de l’enquête. Certaines plateformes vous permettent de programmer l’enquête dans Google Sheets, ce qui élimine certains de ces problèmes. Si vous ne pouvez pas utiliser Google Sheets, mettez au point un protocole permettant à plusieurs personnes de travailler sur l’enquête sans écraser le travail des autres ni créer des copies en conflit. Il peut s’agir d’un plan très simple comme « La personne X programme le formulaire de 8h00 à midi, et la personne Y traduit le travail de la personne X de midi à 16h00. »

Le gel du code 

Le « gel du code » est un moment où le personnel de terrain et les chercheurs principaux conviennent ensemble qu’aucun changement supplémentaire ne sera fait à la version actuelle de l’enquête avant le début du travail sur le terrain. Cela laisse le temps de détecter les dysfonctionnements potentiels tout en limitant le risque que des ajouts de dernière minute introduisent des erreurs dans l’enquête. C’est important pour deux raisons : 

• Il est très probable que l'enquête comporte des bugs (ce qui est normal et ne devrait pas poser de problème si l’on dispose de suffisamment de temps pour revoir le code). Un gel du code donne donc à l’équipe le temps nécessaire pour corriger les bugs de l’enquête avant son lancement.
• Pendant la formation des enquêteurs et la phase de pilotage, l’équipe de terrain vous fournira probablement des commentaires utiles sur la formulation des questions, l’ordre des sections, les ambiguïtés, les exceptions, etc. La phase de gel du code vous donnera le temps d’intégrer toutes ces modifications.

L’objectif principal de la programmation est de rendre l’enquête aussi claire que possible pour trois catégories de personnes : les enquêteurs, les répondants et les personnes qui vont exploiter les données.

Programmer pour les enquêteurs

Réfléchissez à ce qui peut compliquer le travail des enquêteurs et aux façons dont vous pouvez leur faciliter la tâche. Certains aspects de la programmation des enquêtes permettent de réduire le risque d’erreur humaine, notamment en forçant les champs à prendre certaines valeurs ou en n’affichant les questions que lorsqu’elles sont pertinentes. D’autres visent à harmoniser autant que possible la manière dont les enquêteurs posent les questions grâce à la mise en forme du texte ou à l’ajout d’indications. 

Ces deux aspects de la programmation pour les enquêteurs permettent d’obtenir des données de meilleure qualité et incluent notamment les recommandations suivantes :

• Incluez des indications destinées aux enquêteurs. SurveyCTO vous permet d’ajouter des indications aux questions, qui apparaissent en italique :

Apparaît de la manière suivante :

• Utilisez la mise en forme du texte pour guider les enquêteurs. SurveyCTO autorise le formatage HTML, ce qui signifie que vous pouvez mettre du texte en gras et modifier la police, la taille et l’emplacement du texte. Utilisez ce formatage pour uniformiser les procédures d’entretien des enquêteurs. Par exemple, si une question à choix multiples figure en gras, cela signifie que l’enquêteur doit lire toutes les options à voix haute à l’enquêté avant de lui demander sa réponse. La mise en forme du texte peut également servir de guide aux enquêteurs lorsqu’ils lisent les questions à haute voix, en les aidant par exemple à ne pas perdre le fil de leur lecture. 
• Limitez la quantité de texte par page et tenez compte de la taille de l’écran, surtout si l’enquêteur doit lire le texte au répondant. Pendant la phase de programmation, prévisualisez l’enquête sur l’appareil qui sera utilisé pour l’administrer afin de vous assurer que la quantité de texte est adaptée. 
• Ajoutez des numéros de question pour permettre aux enquêteurs de se souvenir plus facilement des questions qui leur ont posé problème ou des erreurs qu’ils ont remarquées. 

• Utilisez à la fois des contraintes dures et des contraintes douces pour confirmer les réponses, lorsque c’est utile. Les contraintes douces consistent à ajouter des questions supplémentaires à l’enquête lorsqu’une réponse semble étrange : « Vous avez dit que le revenu de votre ménage était de 100 $. C’est bien cela ? » Ce type de contrainte est utile pour les réponses qui sont inhabituelles, mais pas impossibles (par exemple, un revenu familial nettement supérieur ou inférieur à une certaine valeur, des rendements agricoles excessifs, etc.). Voici un exemple de code :

L’enquêteur doit revérifier la réponse de l’enquêté si elle se situe dans une certaine fourchette (dans cet exemple, un revenu inférieur à zéro ou supérieur à 10 000 $), puis passer à la question suivante. Les enquêteurs doivent être formés à revenir en arrière pour corriger la réponse hh_inc s’ils sélectionnent « non » à la question de confirmation (vous pouvez également envisager de ne proposer que « oui » comme réponse de confirmation, ce qui les obligerait à retourner corriger la valeur du revenu si elle était erronée).

• Les contraintes dures sont codées dans une question particulière pour empêcher la poursuite de l’enquête tant qu’une nouvelle valeur n’a pas été saisie. Elles sont utiles pour éviter les réponses impossibles ou extrêmement improbables (âge inférieur à zéro, taille du ménage supérieure à 100, etc.). Voir l’exemple de code ci-dessous.

Ici, l’enquête n’autorise la poursuite du questionnaire que si l’âge est supérieur à zéro ou inférieur à 120. Si la réponse se situe en dehors de cette fourchette, le formulaire affiche le message de contrainte (« Cette personne ne peut pas avoir moins de 0 an ou plus de 120 ans. Veuillez réessayer »).

• Résistez à la tentation de perfectionner votre enquête à l’excès en y ajoutant un trop grand nombre de contraintes. En effet, vous risquez d’introduire des contraintes qui entravent la collecte des données. Par exemple, imaginons une contrainte dure qui stipule que la taille de la famille doit être supérieure à un, alors que certains répondants vivent seuls. Dans ce cas, le formulaire ne pourrait pas être rempli, alors qu’une famille composée d’une seule personne peut tout à fait exister.
• Rendez les questions obligatoires si nécessaire, mais prévoyez des portes de sortie. Lorsqu’une question est obligatoire, le répondant doit impérativement y répondre pour que l’enquête puisse se poursuivre. On peut être tenté de rendre toutes les questions obligatoires, mais une telle démarche manque de flexibilité. En effet, il est possible qu’une question donnée ne s’applique pas à la personne interrogée pour diverses raisons. Or, si la question est obligatoire, le répondant ou l’enquêteur seront alors obligés d’inventer quelque chose. Laissez aux répondants la possibilité de donner des réponses comme « Je ne sais pas/Je refuse de répondre/Non concerné », et surveillez de près ces questions lors de vos contrôles à haute fréquence pour savoir à quelle fréquence les personnes interrogées ne répondent pas aux questions. 

• Dans le même ordre d’idée, utilisez des instructions conditionnelles et des sauts de questions. Par exemple, ne demandez à un répondant si ses enfants vont à l’école que s’il ou elle a des enfants. Dans SurveyCTO, ce concept s’appelle la « pertinence » (relevance). Comme nous l’avons vu plus haut, si un trop grand nombre de personnes répondent « Je ne sais pas » ou « Non concerné » à une question donnée, il est peut-être nécessaire d’ajouter une condition de pertinence à cette question pour qu’elle n’apparaisse que lorsqu’elle s’applique au répondant. Dans l’exemple ci-dessous, la question complémentaire « De quand date le tracteur ? » ne s’affiche que pour les personnes qui ont répondu « oui » à la question « Est-ce qu’un membre de votre ménage possède un tracteur ? ». (${tractor_yn}=1).

• Dans le cadre de la formation des enquêteurs, un manuel détaillé doit être fourni pour accompagner le questionnaire. Ce manuel de l’enquêteur doit contenir tous les détails nécessaires pour garantir que les enquêteurs comprennent et posent les questions de la même manière (par exemple, si vous avez utilisé une mise en forme particulière, par exemple si le texte en gras indique que l’enquêteur doit lire toutes les options de réponse avant de demander à la personne de répondre, expliquez ce que signifie cette mise en forme). Il est également important d’expliquer aux enquêteurs la logique, les contraintes et les sauts de questions utilisés dans la programmation de l’enquête. Dans cette perspective, il peut donc être utile de rédiger le manuel de l’enquêteur parallèlement à la programmation de l’enquête. SurveyCTO peut générer un document Word de votre enquête incluant les conditions de pertinence et les contraintes, qui peut tout à fait servir de point de départ à la création du manuel de l’enquêteur.

Programmer pour les répondants

Votre objectif est de créer une enquête qui minimise les contraintes imposées aux répondants et le temps nécessaire pour y répondre. Outre la dimension éthique, il est également prouvé que les enquêtes trop longues ne génèrent pas forcément des données de meilleure qualité que les enquêtes plus courtes (Kilic & Sohnesen 2015). 

• Réduisez au maximum la quantité d’informations que les répondants doivent calculer eux-mêmes. Imaginons que vous souhaitiez mesurer le nombre d’heures de travail hebdomadaires et le salaire horaire des répondants. Pour réduire la charge cognitive qui pèse sur le répondant, vous pouvez calculer le montant total de ses revenus hebdomadaires et le lui montrer, plutôt que de lui demander de faire lui-même le calcul mental (voir l’exemple ci-dessous). SurveyCTO appelle cela un « calcul » (exemple de code ci-dessous).

• Faites en sorte que les questions s’affichent de manière logique. De nombreuses plateformes d’enquête proposent plusieurs options pour l’affichage des questions et des groupes de questions. Par exemple, pour l’élaboration d’une liste des membres du ménage, vous pouvez faire en sorte que les détails sur chaque membre de la famille s’affichent en spécifiant « tableau » dans la colonne d’apparence du groupe (voir le guide de SurveyCTO sur l’apparence des groupes de questions). Cela peut aider les répondants à se souvenir des membres de la famille dont ils ont parlé et à fournir des informations plus précises.
• Le cas échéant, utilisez les informations dont vous disposez déjà sur le répondant. À l’issue de la collecte de données initiale (enquête initiale ou recensement, par exemple), vous disposerez d’un certain nombre d’informations sur les répondants. La plupart des plateformes d’enquête permettent d’extraire ces informations pour les intégrer directement dans les questions de l’enquête. Dans SurveyCTO, cela nécessite de joindre à votre enquête un fichier .csv contenant les données initiales et d’utiliser un champ de calcul spécifique appelé « pulldata » (pour plus d’informations, voir la documentation de SurveyCTO sur le préchargement). Ces informations peuvent alors être utilisées pour raccourcir la durée de l’enquête. En effet, demander à au répondant « Lors de notre dernière visite, vous possédiez cinq parcelles et pratiquiez les six cultures suivantes. Est-ce toujours le cas ? » prend beaucoup moins de temps que de passer en revue chacune des parcelles et chacune des cultures pour obtenir les mêmes informations.

• Programmer pour les analystes de données

  La personne qui programme l’enquête est souvent aussi celle qui analyse les données. Que ce soit ou non le cas, certaines mesures peuvent être prises lors de la programmation pour minimiser le travail de nettoyage qui sera nécessaire par la suite. 

• Utilisez des noms de variables explicites pour que les variables soient faciles à trouver lors de l’analyse. Par exemple, utilisez hh_tot_income plutôt que q25inc, ou nommez les variables contenant des informations d’identification personnelle (ou PII) pii_varname pour en faciliter la suppression. 
  • Dans les questions à choix multiples, les catégories « autre, précisez » doivent toutes être nommées de la même manière (par exemple, rootvar_oth). 
  • Si une même question est posée dans plusieurs enquêtes ou dans plusieurs vagues de collecte de données, il est conseillé d’utiliser le même nom afin de faciliter la comparaison des réponses et l’estimation des changements. 
  • Les questions appartenant à une même section doivent être désignées par un préfixe/suffixe commun. Par exemple, les questions relatives au ménage peuvent comporter le préfixe « hh_ ».
• Adoptez des conventions pour le libellé et le nom des valeurs lorsqu’une option de réponse apparaît dans plusieurs questions. Par exemple, -777 = « Ne sait pas », tandis que -888= « Préfère ne pas répondre ».
  • Le fait de préserver la cohérence de ces valeurs tout au long de l’enquête facilitera ensuite l’identification et le nettoyage des différents types de données manquantes. Notez que cela nécessite toutefois un travail de programmation supplémentaire : il faut par exemple que les enquêteurs puissent taper -777 pour les questions de saisie de texte, ce que ne permet souvent pas la plateforme d’enquête que vous aurez choisie. 
  • Ces valeurs doivent également être les mêmes d’une vague d’enquête à l’autre : Si actif = 1 et sans emploi = 0 dans l’enquête initiale, il convient d’utiliser ces mêmes valeurs dans les vagues d’enquêtes suivantes.
  • En général, dans les questions catégorielles qui comportent deux réponses possibles, on attribue 1 à la réponse qui confirme la question (par exemple, si l’on demande « Êtes-vous au chômage ? », 1 = Sans emploi et 0 = Actif, tandis que si l’on demande « Avez-vous un emploi ? », 1 = Actif et 0 = Sans emploi). Ce type de codage des questions binaires rend l’interprétation des variables plus intuitive. Par exemple, la moyenne des variables correspond ainsi au pourcentage de personnes interrogées ayant répondu à la question par l’affirmative. 
• Facilitez la mise en correspondance des répondants d’une vague d’enquête à l’autre en pré-chargeant les identifiants de l’enquête initiale ou du recensement dans les enquêtes ultérieures. De cette façon, l’enquêteur n’a plus qu’à revérifier qu’il interroge bien le bon répondant.

Une fois l’enquête programmée, prévoyez un à trois jours de test, selon le degré de complexité de l’enquête. Déployer une enquête sur le terrain alors qu’elle contient des erreurs est coûteux et représente une perte de temps aussi bien pour les répondants que pour les enquêteurs. En outre, la phase de test du questionnaire permet de générer des données qui pourront ensuite être utilisées pour mettre en place des contrôles de la qualité des données. 

Trois groupes de personnes doivent tester l’enquête, chacun d’entre eux se concentrant sur un aspect différent :

1. Test de l’enquête par les programmeurs : Les programmeurs savent comment le formulaire est censé fonctionner et doivent donc en tester la logique interne (par exemple les sauts de questions, les contraintes, etc.). Dans cette perspective, ils peuvent tester le formulaire en utilisant une copie papier de l’enquête afin d’en vérifier la logique. Les programmeurs sont également bien placés pour détecter les bugs de programmation (voir la check-list des tests ci-dessous). 

2. Test de l’enquête par des personnes extérieures : Les personnes extérieures, ou qui n’ont pas participé à la programmation du formulaire, ignorent comment celui-ci est censé fonctionner. Ils sont particulièrement bien placés pour essayer de détourner et de mettre en échec le formulaire, et doivent donc donner des réponses illogiques ou contradictoires, ou encore essayer de parcourir le formulaire le plus rapidement possible. Il peut être utile de demander à ces personnes de tester le formulaire avec des cas extrêmes (par exemple, une famille qui compte 30 membres, etc.). Si la vérification de ce type de cas extrême peut être trop chronophage pour les programmeurs et les enquêteurs, il est néanmoins utile de les tester au cas où ils se produiraient sur le terrain. Pour tester le formulaire, les personnes extérieures doivent elles aussi utiliser la check-list ci-dessous.

3. Test de l’enquête par les enquêteurs : Une fois que le formulaire a été testé de manière approfondie par les programmeurs et des personnes extérieures, c’est au tour des enquêteurs de le faire dans le cadre de leur formation. Ils doivent alors se concentrer sur la traduction et l’interprétation des questions et tester le formulaire sur l’appareil qu’ils utiliseront pour effectuer les enquêtes sur le terrain. Il peut être utile de rédiger une série de scénarios que les enquêteurs pourront utiliser pour tester le formulaire (par exemple, le répondant n’est pas disponible pour répondre à l’enquête, il souhaite abandonner l’enquête, une famille comptant 10 membres avec des détails sur chacun d’entre eux, ou un agriculteur possédant six champs, etc.). Notez que le test des enquêteurs intervient avant que vous ne testiez plus formellement la clarté du contenu de l’enquête dans le cadre du pilotage du questionnaire. Les enquêteurs doivent donc se concentrer sur la compréhension et le test des mécanismes du formulaire plutôt que sur le contenu de ce dernier. 

Check-list de test

Cette check-list doit être utilisée pour vérifier que l’enquête a été correctement programmée. Notez tous les cas où la programmation de l’enquête est problématique (par exemple, si une question sur l’âge d’un individu autorise les réponses négatives). Pour vérifier que les questions de l’enquête mesurent bien ce que vous voulez qu’elles mesurent, ou que les répondants comprennent bien l’enquête, veuillez consulter les check-lists relatives à la conception de l’enquête et au pilotage du questionnaire, respectivement. 

1. Si la question est censée être obligatoire, peut-on la passer sans y répondre ?
2. Si la question est censée être obligatoire, offre-t-elle une porte de sortie, par exemple une option de réponse comme « Je ne sais pas/NA » ?
3. Si vous passez rapidement sur une question, cela pose-t-il des problèmes au niveau du formulaire ?
4. Si la question requiert une réponse numérique, saisissez à la fois des nombres positifs et négatifs. Est-il normal que les deux soient autorisés ?
5. Si la question nécessite une réponse sous forme de texte, essayez de saisir des chiffres et des symboles. Ces derniers sont-ils censés être autorisés ? Par exemple, si la question demande une adresse e-mail, « @ » doit être autorisé. Y a-t-il un nombre maximum ou minimum de caractères à autoriser ?
6. Si la question est censée comporter des instructions pour les enquêteurs, ces instructions apparaissent-elles ? Sont-elles correctement mises en forme (c’est-à-dire différemment du reste du texte de la question) ?
7. Contraintes : Si la question comporte une contrainte, vérifiez les cas limites et les valeurs aberrantes (par exemple, si une contrainte impose que l’âge soit compris entre 0 et 100, essayez de saisir -1, -1000, 101, 1000). La contrainte bloque-t-elle les réponses correctes ? Vérifiez que le programmeur n’a pas utilisé « > » au lieu de « < », ou « >= » au lieu de « > », etc.
8. Conditions de pertinence / sauts de questions : Si vous sélectionnez une réponse qui est censée déclencher des questions complémentaires, celles-ci apparaissent-elles ? Pouvez-vous revenir en arrière et modifier votre réponse à cette question (et souhaitez-vous que les enquêteurs puissent le faire aussi) ?
9. Calculs : Le calcul est-il correctement effectué ? Si SurveyCTO ne parvient pas à effectuer le calcul, vous verrez s’afficher la mention « ... » à l’endroit où le résultat du calcul est censé apparaître. Vérifiez que le calcul est correct en le faisant à la main (par exemple, s’il faut multiplier deux champs précédents, vérifiez le résultat en faisant le calcul vous-même).
10. Données pré-chargées : Si le formulaire est pré-rempli , est-ce que les données pré-saisies sont les bonnes (par exemple, le formulaire saisit-il l’âge là où il devrait saisir le sexe, etc.) ? Comme pour les calculs, si SurveyCTO ne parvient pas à effectuer le pré-remplissage, il affichera « ... » à l’endroit où les données pré-remplies sont censées apparaître. Si les données pré-remplies sont utilisées dans le cadre de conditions de pertinence ou de contraintes, vérifiez-les d’autant plus attentivement (par exemple, si une section donnée ne doit s’afficher que pour le groupe de traitement et que le formulaire est pré-rempli avec le statut de traitement des répondants, assurez-vous que cette section s’affiche bien pour les répondants qui appartiennent au groupe de traitement).

Une fois qu’une enquête est lancée et que les données sont en cours de collecte, toute modification doit être effectuée avec la plus grande prudence. SurveyCTO ne peut exporter que les données correspondant à la dernière version du formulaire. En d’autres termes, si vous modifiez l’enquête et que vous supprimez une question, il vous sera ensuite impossible d’accéder aux réponses à cette question. En revanche, vous pouvez faire en sorte que SurveyCTO n’affiche plus cette question en tapant « oui » dans la colonne « désactivé » (disabled) de cette question. Une autre solution consiste à définir des critères de pertinence irréalisables pour cette question afin qu’elle ne soit jamais proposée aux répondants.

Le coût, les fonctionnalités de sécurité, la flexibilité et la compatibilité sont autant d’aspects importants à prendre en compte lorsque vous choisissez le logiciel que vous allez utiliser pour vos enquêtes numériques. Vous trouverez ci-dessous quelques-unes des plates-formes les plus répandues :

Dernière modification : juillet 2020.

Ces ressources sont le fruit d’un travail collaboratif. Si vous constatez un dysfonctionnement, ou si vous souhaitez suggérer l'ajout de nouveaux contenus, veuillez remplir ce formulaire.