5.5.2 Nommer ses variables et options

TABLE DES MATIÈRES

• Comment nommer une variable ou une option
  • Règles générales pour les questions (variables) et les choix de réponses (options)
  • Règles spécifiques pour la désignation des questions (variables)
  • Règles spécifiques pour la désignation des options de réponse
• Penser à l’utilisation des données
  • Humanitarian Exchange Language (HXL)

---

La désignation de vos questions/variables ou des options de réponses est un aspect important lors de la conception de votre formulaire. Mais pourquoi est-ce si important ?

1. Pour l’analyse de vos données : L’export de vos données avec les « noms » des variables et des options plutôt qu’avec les libellés rendra vos données beaucoup plus faciles à lire, avec des données plus courtes et plus expressives.
2. Chaque fois que vous avez besoin de modifier votre formulaire : imaginez que vous avez créé votre formulaire et qu’après avoir mené des tests, vous réalisez que vous devez encore le modifier un peu. Le fait d’avoir une convention de nomenclature cohérente et harmonisée tout au long de votre formulaire, avec des noms descriptifs/significatifs et faciles à retenir pour vos variables/questions et vos options, vous permettra de trouver rapidement la ou les variables qui doivent être modifiées. Au contraire, si vous avez un système de nommage non harmonisé avec des noms non descriptifs, il vous faudra beaucoup plus de temps que prévu pour trouver les variables qui vous intéressent et les modifier.
3. Chaque fois que quelqu’un d’autre a besoin de modifier votre formulaire : imaginez que l’un de vos collaborateurs a besoin de faire une enquête très similaire à la vôtre et qu’il souhaite partir de votre enquête au lieu de repartir de zéro (afin d’éviter la duplication). Les mêmes principes s’appliquent ici : plus votre système de nommage est cohérent, descriptif/significatif et facile à retenir, plus il est facile pour lui de commencer à travailler à partir de votre enquête.

Vous pouvez trouver ici explication visuelle des définitions et de la différence entre nom et libellé dans le codage (en anglais).

Comment établir une convention de nomenclature cohérente et harmonisée ? Il n’y a pas de “meilleure” réponse à cette question, mais elle se résume à : “Faites ce que vous voulez, mais faites-le pour une raison.” Moins vous prendrez de décisions sans avoir vraiment de raisonnement derrière, meilleure sera votre méthode de codage. Les conseils suivants ont tous été élaborés dans cet esprit. Par conséquent, n’hésitez pas à les prendre dans leur intégralité, ou à les adapter à vos besoins et préférences. Cette partie attire également l’attention sur le fait que vous devez tenir compte de l’utilisation des données lorsque vous nommez vos questions et vos options.

Comment nommer une variable ou une option

Règles générales pour les questions (variables) et les choix de réponses (options)

Règles spécifiques pour la désignation des questions (variables)

Règle spécifique : le nom de la question (variable) doit être unique Quoi que vous fassiez, quel que soit le nombre de variables que vous créez et par quelle méthode vous nommez vos variables (XLSForm versus KoBoToolbox), le nom de chacune d’entre elles doit être unique ! KoBoToolbox n’acceptera pas de déployer votre formulaire s’il détecte qu’un nom de variable est attribué plus d’une fois à une variable.

Pourquoi le nom de la variable ou des questions doit-il être unique ? Les noms des questions ou des variables doivent être uniques afin que KoBoToolbox sache exactement à laquelle vous faites référence. Prenons l’exemple d’une “contrainte”, d’un “critère de passage” (ou “saut de question”) ou d’un “calcul” : lorsque vous codifiez l’une des variables, vous dites à KoBoToolbox ce qu’il doit faire et vous devez parfois spécifier exactement à quelle variable/question vous faites référence dans votre formule. Par exemple, vous voulez que la question B n’apparaisse que si la réponse à la question A est “oui” (saut de question) : vous devrez alors spécifier exactement à quelle variable la variable B sera associée. Si la variable C porte exactement le même nom que la variable A, KoBoToolbox sera confus et ne saura pas exactement de laquelle vous parlez.

Règle spécifique 2 : Lorsque vous créez un nouveau nom de variable, essayez d’être à la fois concis et descriptif Par exemple, disons que nous voulons attribuer un nom à une variable concernant les groupes vulnérables de personnes déplacées à l’intérieur du pays par type d’abri. Il existe de nombreuses façons de nommer cette variable :

1. vulnerable_groups_displaced_people
2. vulnerableGroupIDP
3. VULNGRP_IDP
4. Question_5_2A

Bien entendu, la première est la plus descriptive, mais elle n’est pas concise. Que se passe-t-il si cette question est imbriquée dans un groupe de questions liées à la protection et à la sécurité, qui est lui-même imbriqué dans un groupe de facteurs de vulnérabilité ? Si vous êtes cohérent, vous pouvez avoir nommé les groupes “protection_security” et “vulnerability_factors”, de sorte que dans la base de données, vous avez un nom de colonne tel que “vulnerability_factors/protection_security/vulnerable_groups_displaced_people”. Il existe des limites à la longueur qui peut être attribuée à ces colonnes, et elles sont spécifiques à la base de données. Se heurter à celles-ci peut entraîner des problèmes plus tard.

La toute dernière option, qui consiste à nommer la question d’après son numéro (probablement dans le formulaire papier), bien que couramment utilisée, présente de nombreux inconvénients :

• Ajouter/supprimer des questions signifie que la numérotation devra être ajustée (travail inutile).
• Cela vous oblige à faire des allers-retours entre le XLSForm, le formulaire papier et le résultat pour savoir ce qui signifie quoi.
• Enfin, votre XLSForm n’est plus autonome : pour vraiment savoir comment le formulaire est structuré, vous devez presque vous référer à cet autre document (word ou formulaire papier).

De notre point de vue, la troisième option sera la plus efficace, surtout si l’expression “Vulnerable groups” arrive souvent: en un rien de temps VLNGRP sera synonyme de “vulnerable_group”. C’est un équilibre entre le fait d’être suffisamment descriptif pour être reconnaissable au premier coup d’œil, sans être trop encombrant.

Règles spécifiques pour la désignation des options de réponse

Règle spécifique 1 : le nom des options ne doit pas nécessairement être unique. Contrairement au nom des variables ou des questions, le nom des options ne doit pas nécessairement être unique sauf dans une liste donnée.

Règle spécifique 2 : garder le même modèle (c’est à dire utiliser les mêmes noms pour des libellés similaires telles que “autre” ou “NSP”). Comme indiqué ci-dessus, il n’est pas nécessaire que les options aient des valeurs uniques. Au contraire, chaque fois que vous avez des libellés similaires tels que “autre” ou “NSP”, il est fortement recommandé d’utiliser les mêmes noms pour elles. L’harmonisation de la désignation des options dans une enquête donnée (et même dans une délégation si possible) facilite l’analyse des données recueillies.

Règle spécifique 3 : une liste peut être réutilisée autant de fois que nécessaire dans le formulaire (uniquement avec XLSForm) Si vous devez utiliser la même liste de réponses plusieurs fois au cours de votre enquête, il n’est pas nécessaire de créer une nouvelle liste d’options spécifiques à ces questions. Vous pouvez utiliser cette même liste autant de fois que nécessaire. Voici quelques conseils pour gerer des longues listes de choix dans les formulaires longs avec de nombreuses questions à choix uniques ou multiples :

1. Attribuer des noms similaires au “nom de la liste” (qui constituent les questions à choix multiple dans l’onglet “choice”) et au nom de la question dans la feuille “survey “. Certains différenciateurs peuvent être utilisés, comme l’ajout d’un “L” à la fin (pour liste). Pourquoi faire ? De cette façon, vous pouvez facilement modifier n’importe quel choix de liste sans avoir à consulter constamment la feuille d’enquête principale (et vice-versa). Vous savez alors que pour modifier la question relationHosts, vous devez modifier la liste relationHostsL dans l’onglet “choice”.
2. Si vous placez les différentes listes de choix dans l’ordre alphabétique, il est également plus facile de les retrouver dans l’onglet de choix (c’est pourquoi vous placez les différenciateurs à la fin). L’exception à cette règle serait les listes de choix très communes partagées par plusieurs questions, comme Oui/Non, Augmentation/Diminution/Stable, etc.

Règle spécifique 4 : les options couramment utilisées (oui, non, NSP…) devraient faire l’objet d’un traitement spécial. Dans les options de liste, certaines options sont récurrentes pour différentes questions, telles que “Oui”, “Non”, “Autre”, “NSP”, etc. L’objectif dans ces cas devrait être de respecter les caractéristiques susmentionnées d’une bonne convention d’appellation, mais peutêtre aussi d’envisager l’utilisation que vous allez faire des données.

• Parce qu’il peut très bien arriver, lors de l’analyse des données ou même dans les calculs intégrés à l’enquête, qu’il soit nécessaire de résumer toutes les réponses “oui” à une question donnée, attribuer 1 à “Oui” et 0 à “Non” peut être une option intelligente.

• Pour illustrer ces principes, l’échantillon de données produit ci-dessous peut être compris dans la plupart des cas sans même tenir compte de l’enquête qui a produit ces données :

La question “consent_survey” peut facilement être résumée directement pour indiquer le nombre de réponses, le pourcentage de non-réponses, etc.

Règle spécifique 5 (facultatif) : utilisation de valeurs numériques ou de noms Dans la liste de choix, vous pouvez utiliser des chiffres comme valeurs au lieu de lettres. Il y a des avantages et des inconvénients à cela, mais cela ajoute l’objectivité qui vient avec l’attribution de chiffres à chaque option : un 5 est un 5, alors que le choix “Religious Minorities” pourrait avoir un certain nombre de “valeurs” qui lui sont attribuées, des combinaisons infinies de séparateurs en majuscules ou en tirets bas, des lettres majuscules, etc.

Un autre avantage potentiel de cette méthode (bien qu’il soit certainement possible d’utiliser également des lettres comme valeurs) est d’utiliser la même valeur pour des options très courantes qui apparaissent dans de nombreuses listes :

• 88 pour “Autres”.
• 99 pour “Ne sait pas”.
• 0 pour “Non”, 1 pour “Oui”

Vous pouvez établir des conventions similaires pour toute valeur commune de votre formulaire. Le bon côté est que lors du codage des contraintes, des conditions ou des questions-réponses “Si autre, veuillez préciser”, la valeur à vérifier sera toujours la même. Pas besoin d’aller vérifier la liste de choix pour cela. Les contraintes/conditions pertinentes similaires peuvent également être copiées et collées, car l’action à entreprendre si la réponse est “Autre” ou “Non” est souvent similaire.

Pour la question elle-même, il faut utiliser des noms réels. Cependant, en ce qui concerne les questions à options unique ou multiple, il y a 2 conventions principales - utiliser des noms descriptifs ou des valeurs numériques. Considérez ce qui suit, qui est simplement l’onglet “choices” d’un XLSForm:

Dans un cas une valeur numérique est attribuée à chaque option, de 1 à 7 (et 96 pour “autre”), tandis que dans l’autre est utilisé un nom descriptif (peut-être légèrement raccourci). Voici les données de sortie lorsqu’elles sont téléchargées depuis KoBoToolbox:

Si vous utilisez des valeurs numériques assignées à chaque option (le cas ci-dessus à gauche), envisagez d’utiliser des nombres plus élevés pour “autre”, “NSP” et réponse similaire. Si vous utilisez un nombre plus élevé (comme 96 ci-dessus), vous pouvez garder la même valeur pour “autre” pour toutes les questions, quelle que soit la longueur de la liste, alors que si vous lui attribuez un nombre bas (par exemple 5), toute liste de 5 options ou plus peut vous demander de modifier la valeur attribuée à “autre”. Cette pratique rend également la sortie des données plus facile à lire, car 96 ou 99 se distinguera des options régulières.

Penser à l’utilisation des données

La façon dont les données sont susceptibles d’être utilisées devrait être prise en considération lors de l’établissement d’une convention de nommage. Cela inclut :

• Les conventions existantes dans votre secteur, au sein des organisations partenaires avec lesquelles la collaboration est fréquente, ou avec des enquêtes similaires. Pour comprendre ce que sont les normes et comment elles peuvent faciliter l’utilisation des données et l’interopérabilité, veuillez vous référer au Module 5: Making data useful, useable and shareable de l’IFCR Data Playbook (en anglais), en particulier
  • 5 - 3 Should We Apply Standards to Our Data?
  • 5 - 4 Understanding data standards
  • 5 - 2 Standards support humanitarian action
• Votre plan d’analyse, y compris si des calculs sont susceptibles d’être effectués directement pour une question donnée.

Par exemple, si les P-codes sont déjà établis et disponibles dans votre région, vous devriez envisager de les utiliser dans votre formulaire XLSForm pour les entités administratives. Cela faciliterait le partage des données avec d’autres organisations (en supposant qu’elles utilisent également les P-codes).

Humanitarian Exchange Language (HXL)

Le Langage d’échanges humanitaires (Humanitarian Exchange Language (HXL)) est une norme de classification et nomination des données dans le secteur. Il permet d’avoir une compréhension commune des données en les normalisant. Il évite le gaspillage d’efforts pour copier, préparer, valider et nettoyer manuellement les données, ce qui peut être très utile pour le partage des données. Le système de tags et d’attributs est simple, permet un bon niveau de précision et contribue à éviter toute confusion sur la signification réelle des données. Par conséquent, il contribue à renverser les barrières linguistiques sur les ensembles de données.

HXL est une norme de données pour les données désordonnées, qui utilise des hashtags pour accélérer le traitement des données et créer une interopérabilité entre les sources de données. Il s’agit d’une approche ingénieuse consistant à coder les données au moyen de hashtags (#), comme sur Twitter.