Concevoir un formulaire KoboToolbox semble simple jusqu'au moment où vous récupérez les premières données du terrain. Voici cinq erreurs que je rencontre encore régulièrement, et comment les éviter.

1. Oublier la validation sur les champs numériques

C'est l'erreur la plus fréquente. Un enquêteur saisit 250 au lieu de 25.0 pour le poids d'un enfant, et personne ne le remarque avant l'analyse — trois semaines plus tard.

La solution est simple : ajoutez systématiquement une contrainte de plage sur chaque champ numérique. Dans XLSForm : 

type        | name   | label   | constraint           | constraint_message
integer     | poids  | Poids   | . >= 2 and . <= 80   | Poids inhabituel

Le message d'erreur s'affiche immédiatement sur le terminal de l'enquêteur, qui peut corriger sa saisie sur place.

2. Coder en dur les choix au lieu d'utiliser un fichier externe

Quand vous avez une liste de 200 villages, ne les saisissez pas un par un dans l'onglet choices. Utilisez plutôt un fichier CSV externe (itemsets.csv) que vous pouvez mettre à jour sans toucher au formulaire.

Pourquoi c'est essentiel

  • Vous évitez les fautes de frappe dans les noms de localités
  • Vous pouvez ajouter ou retirer des choix sans redéployer le formulaire
  • Le formulaire reste rapide à charger sur les anciens téléphones
Un formulaire bien conçu fait économiser plus de temps que dix tableaux de bord ne pourront jamais en récupérer.

3. Ne pas tester en mode hors-ligne

La plupart des terrains en zone rurale n'ont pas de connexion stable. Testez systématiquement votre formulaire en mode avion avant de le déployer. Vérifiez en particulier :

  1. Les médias (audio, vidéo) référencés dans le formulaire
  2. Les listes en cascade qui dépendent de fichiers externes
  3. La sauvegarde locale des soumissions partielles

4. Négliger les labels en langue locale

Si vos enquêteurs travaillent en haoussa, en zarma ou en peulh, traduisez les questions principales. Ce n'est pas seulement une question de confort : c'est une question de qualité des données. Une question mal comprise produit une réponse aléatoire.

KoboToolbox gère nativement plusieurs langues via les colonnes label::fr, label::ha, etc. Documentation officielle ici.

5. Concevoir le formulaire seul, sans pilote terrain

Même avec quinze ans d'expérience, je fais toujours au moins un pilote avec deux à trois enquêteurs avant de déployer. Vous découvrirez des problèmes que vous n'auriez jamais imaginés : un mot ambigu, une question qui prend cinq minutes au lieu d'une, une logique de saut qui ne couvre pas un cas réel.

Le bon ratio temps

Pour un déploiement de 30 jours, prévoyez 3 à 5 jours de pilote. C'est le meilleur investissement possible.

Ces cinq pièges ne sont pas exhaustifs, mais ils représentent à eux seuls 80 % des problèmes que je rencontre quand on me demande de réparer une collecte en cours. Anticipez-les, et vous gagnerez des semaines.

Pour aller plus loin, j'ai publié une série de tutoriels vidéo sur ces sujets sur ma chaîne Data Solution.

Designing a KoboToolbox form seems simple until you receive the first field data. Here are five mistakes I still encounter regularly, and how to avoid them.

1. Forgetting validation on numeric fields

This is the most common error. A surveyor enters 250 instead of 25.0 for a child's weight, and no one notices until analysis — three weeks later.

The solution is simple: systematically add a range constraint to each numeric field. In XLSForm: 

type        | name   | label   | constraint           | constraint_message
integer     | weight | Weight  | . >= 2 and . <= 80   | Unusual weight

The error message appears immediately on the surveyor's device, who can correct on the spot.

2. Hard-coding choices instead of using an external file

When you have a list of 200 villages, don't enter them one by one in the choices tab. Use an external CSV file (itemsets.csv) that you can update without touching the form.

Why it matters

  • You avoid typos in locality names
  • You can add or remove choices without redeploying the form
  • The form stays fast to load on older phones
A well-designed form saves more time than ten dashboards could ever recover.

3. Not testing offline

Most rural field sites don't have stable connectivity. Always test your form in airplane mode before deployment. In particular, check:

  1. Media (audio, video) referenced in the form
  2. Cascading lists depending on external files
  3. Local saving of partial submissions

4. Neglecting labels in local languages

If your surveyors work in Hausa, Zarma or Fulani, translate the key questions. It's not just a comfort issue — it's a data quality issue. A misunderstood question produces a random answer.

KoboToolbox natively supports multiple languages via the label::fr, label::ha columns, etc. Official documentation here.

5. Designing the form alone, without a field pilot

Even with fifteen years of experience, I always run at least one pilot with two or three surveyors before deployment. You'll uncover issues you'd never have imagined: an ambiguous word, a question that takes five minutes instead of one, a skip logic that doesn't cover a real-world case.

The right time ratio

For a 30-day deployment, plan 3 to 5 pilot days. It's the best investment you can make.

These five pitfalls aren't exhaustive, but they alone account for 80% of the problems I encounter when asked to fix an ongoing collection. Anticipate them, and you'll save weeks.

For more, I've published a series of video tutorials on these topics on my Data Solution channel.