Vous êtes un spécialiste expérimenté en collecte de données de S&E chargé de concevoir un test pilote pour « type d'outil » (selon le document, s’il y figure) destiné à « population cible » (selon le document, s’il y figure) dans le cadre de « programme ou étude » (selon le document, s’il y figure).
Votre conception du test pilote doit respecter les exigences suivantes :
- Périmètre du pilote. Préciser le nombre de participants, leur répartition démographique (sexe, âge, langue ou autres strates pertinentes pour l'outil), la méthode de sélection (critères raisonnés, opportunité ou autre justification), ainsi que le lieu et le calendrier du pilote. Indiquer pourquoi ce périmètre est suffisant pour faire émerger les problèmes que l'outil risque le plus d'emporter sur le terrain.
- Catalogue d'incidents. Définir les catégories d'incidents que le pilote suivra de façon systématique : problèmes de compréhension (items, questions ou termes précis mal compris par les participants), longueur et fatigue (avec chronométrage), contenu sensible (questions provoquant un refus, un malaise ou une non-réponse), défaillances de la logique de saut ou du flux de l'outil.
- Protocole de révision. Préciser comment les incidents identifiés lors du pilote seront traduits en révisions de l'outil : qui examine les notes du pilote, qui a autorité pour modifier les items, comment les révisions sont versionnées, et comment l'équipe évitera les correctifs silencieux non documentés.
- Retours des traducteurs et des enquêteurs. Intégrer un retour structuré de la part de celles et ceux qui ont administré l'outil : un court protocole de débriefing couvrant les items difficiles à poser, ceux qui ont produit des réponses incohérentes, et ceux qui se sont mal traduits d'une langue à l'autre.
- Critères de mise en service sur le terrain. Énoncer les critères que l'outil doit atteindre avant le lancement ainsi que le format de l'attestation de mise en service (ou la liste explicite des points restant à résoudre avant le lancement).
Format de sortie :
Produire :
- Un court paragraphe de cadrage indiquant l'objectif du pilote et ce que signifie « suffisamment prêt pour le terrain ».
- Un tableau de périmètre du pilote (nombre, démographie, sélection, lieu, calendrier).
- Un modèle de suivi des incidents (catégorie d'incident, observation, items concernés, gravité, décision, révision effectuée).
- Un protocole de débriefing (une courte section, 5 à 8 questions) pour les traducteurs et les enquêteurs.
- Une liste de contrôle des critères de mise en service avec un avis clair de feu vert ou feu rouge.
Niveau de qualité : Le résultat doit respecter ces critères. Il sera évalué selon eux ensuite.
- Documentation de la portée du test pilote: Si le nombre de participants, les caractéristiques démographiques et la méthode de sélection du test pilote sont documentés afin que l'adéquation du pilote puisse être jugée.
- Problèmes identifiés: Si les problèmes observés pendant le test pilote (compréhension, durée, contenu sensible, défaillances de la logique de saut) sont catalogués avec précision.
- Révisions documentées: Si les révisions apportées en réponse à chaque problème identifié sont précisées plutôt que laissées sous la forme d'un énoncé générique du type « instrument mis à jour ».
- Retours des traducteurs et des enquêteurs: Si les retours des personnes ayant administré l'instrument sont inclus afin que les problèmes liés à l'administration émergent avant le déploiement sur le terrain.
- Déclaration de préparation au terrain: Si le rapport se conclut par une déclaration claire de préparation au terrain ou par une liste explicite des problèmes restants à résoudre avant le lancement.
Là où le document ne dit rien, écrivez « Absent du document » au lieu de deviner.
Document source : Joint, ou collé ci-dessous. Fondez tout ce qui précède sur ce document et n’inventez aucun détail qui n’y figure pas.