Horaire : 14:00-16:30 Dakar
OpenTalk : https://meet.opentalk.eu/room/60fb1399-1fb0-49dd-8af5-45b19acaa730?invite=dda1a71a-762c-4df7-93b3-6d1b170a1886
Questionnaire : https://kyc20-data-lineage-production.up.railway.app/
| Durée | Bloc | Message clé |
|---|---|---|
| 10 min | Présentations | Savoir qui est dans la salle ; consentement enregistrement ; une attente pour aujourd'hui |
| 5 min | Cadrage — toutes les villes, toutes les années | Cela aide tout le monde, partout, dans la durée - pas seulement Ziguinchor aujourd'hui |
| 5 min | Démo Kblock | Les données cartographiques existantes peuvent soutenir de vraies décisions, combinées aux données de la fédération |
| 25 min | Questionnaire en ligne | Documenter ce que vous avez et ce que vous prévoyez - on demande, on n'impose pas |
| 5 min | Pause (après le questionnaire) | Faire le lien entre ce que vous avez entendu et la suite |
| 15 min | Cas d'usage au tableau | Nommer de vrais problèmes du terrain - pas des fonctionnalités ou de la technologie |
| 15 min | Relier questionnaire et cas d'usage | Chaque cas d'usage prioritaire a besoin de données derrière - ou d'un manque assumé |
| 10 min | Pause (avant les personas) | Reprendre son souffle avant le travail d'empathie |
| 15 min | Personas | Une bonne persona est quelqu'un qu'on peut se représenter : nom, métier, objectif, frustration, besoin en données |
| 30 min | User stories par persona | Une histoire concrète par rôle, liée aux données du questionnaire |
| Clôture | Conclusion | Relire ce qu'on a convenu - pas de nouveaux sujets |
Message clé : Tout le monde sait qui est dans la salle et pourquoi on est là avant d'ouvrir le questionnaire.
Avant de parler : lancer l'enregistrement (voir checklist). Coller les liens OpenTalk et questionnaire dans le chat.
Dire une fois (enregistrement) : on enregistre pour partager les notes avec celles et ceux qui n'ont pas pu venir. Si quelqu'un s'y oppose, le dire maintenant.
Facilitateurs (30 secondes chacun) : prénom, rôle, organisation.
Tour de table (~30-45 secondes par personne) :
- Prénom et rôle
- Organisation ou équipe (UrbaSEN, fédération, SDI, etc.)
- Une phrase : qu'est-ce qui rendrait la session utile pour vous aujourd'hui ?
Restez léger — pas de long discours. Noter noms et rôles pour le bloc personas plus tard.
Une phrase sur la session : aujourd'hui on documente les données de Ziguinchor dans le questionnaire et on clarifie qui utilisera la plateforme et pour quoi. Pas besoin de jargon technique.
« Bonjour à toutes et à tous. On enregistre la session — si quelqu'un a une objection, dites-le maintenant.
Chacun·e se présente : prénom, rôle, organisation, et en une phrase ce qui vous aiderait aujourd'hui. »
Message clé : La valeur de ce projet concerne toutes les villes du programme et plusieurs années - incluez les données que vous avez déjà, pas seulement ce que ce projet va collecter.
Aujourd'hui on travaille sur Ziguinchor, mais la plateforme est pensée pour les sept villes du programme. Elle doit aussi accueillir des données de différentes années - une vieille carte ou un ancien relevé compte autant qu'une collecte récente. En documentant ce que vous avez et ce que vous prévoyez, vous aidez votre ville et le réseau. Le questionnaire ne concerne pas seulement ce projet : incluez tout ce que votre fédération détient déjà depuis des années.
Message clé : Cette démo montre ce qui est possible quand les couches cartographiques servent des décisions locales - c'est une motivation, pas le produit final.
Montrer Kblock comme exemple concret d'une bonne utilisation des données de carte. OpenStreetMap est une entrée parmi d'autres ; l'idée est de transformer des couches existantes en quelque chose d'utile pour des décisions locales (par exemple voir des motifs bloc par bloc). Dire clairement que c'est une démo de motivation, pas le produit final. OpenStreetMap seul ne suffit pas - il est plus fort combiné aux données de la fédération : limites de quartier, relevés terrain, etc. Après la démo, demander : quelle couche avez-vous déjà, laquelle manque, et qui dans votre équipe s'en occupe ?
Message clé : Le questionnaire est une photo partagée de vos données - on note ce qui existe, ce qui est prévu, et qui est responsable, seulement quand vous êtes prêts à le dire.
Parcourir le questionnaire lineage ensemble. Chacun se connecte, choisit le Sénégal, et remplit ce qu'il connaît - pas besoin de tout finir aujourd'hui. Pour chaque jeu de données : existe aujourd'hui ? prévu ? non applicable ? Si quelque chose manque, demander avec douceur s'ils prévoient de le collecter, à quelle échéance (même approximative), dans quel projet, et qui serait responsable - seulement s'ils sont prêts à répondre. Noter à confirmer quand ils ne sont pas sûrs. Corriger les lignes erronées ou exemples copiés-collés (par exemple sur OpenStreetMap). Les vols de drone n'étaient pas autorisés à Ziguinchor pour des raisons d'ordre public ; une cartographie au niveau de la rue a été proposée comme alternative - si confirmé, l'ajouter comme possible nouveau type de données.
Message clé : Utiliser cette pause pour transformer les réponses du questionnaire en matière utile pour le tableau - ne pas enchaîner à froid.
Mettre la session en pause. Dire que vous revenez dans cinq minutes.
Pour vous (interne) : noter ce qui a été rempli, ce qui manque, qui est responsable de quoi, les surprises ou blocages. Ces notes serviront pour les cas d'usage et les personas - en lien avec ce que vous avez vraiment entendu.
« On fait une pause de cinq minutes. On reprend dans un instant pour la partie tableau blanc. »
Message clé : Un bon cas d'usage part d'un problème concret ce mois-ci - pas d'un souhait pour un meilleur système.
Demander quels problèmes la plateforme ville doit aider à résoudre : préparer une réunion avec la mairie, montrer les manques de services sur une carte, relier un récit à un lieu, exporter des chiffres pour un rapport. Écrire 4 à 6 cas d'usage sur des post-its. Ne pas débattre de la technologie. Retenir les 2 ou 3 les plus urgents pour la première version.
Message clé : Si un cas d'usage ne pointe pas vers des données que vous avez ou prévoyez de collecter, il reste un souhait - marquer le manque honnêtement.
Tracer des liens sur le tableau entre chaque cas d'usage prioritaire et les jeux de données du questionnaire qui le soutiennent. Pas de données derrière le cas d'usage : marquer le trou. Des données sans cas d'usage : noter disponible mais peu utilisé ou usage à clarifier. Chaque cas d'usage important doit pointer vers des données existantes, prévues, ou un manque assumé.
Message clé : Le travail sur les personas demande de l'empathie - reprendre souffle et relire vos notes avant de décrire les utilisateurs.
Pause avant le bloc personas. Relire rapidement questionnaire et cas d'usage pour que les exemples au tableau reflètent Ziguinchor, pas un modèle générique.
« Petite pause avant la partie personas - on reprend dans dix minutes. »
Message clé : Une bonne persona est quelqu'un qu'on peut se représenter - si vous ne pouvez pas nommer son métier, son objectif et sa frustration, c'est encore trop vague.
Nommer les personnes qui utiliseront vraiment la plateforme ou décideront de ce que les autres voient. Éviter les étiquettes floues comme communauté ou gouvernement - les reformuler de façon concrète. Viser jusqu'à cinq rôles pour la première version.
Checklist d'une bonne persona :
- Un nom ou un rôle clair (pas « la communauté »)
- Qui elle est et ce qu'elle fait au quotidien
- Un objectif et une motivation (pourquoi c'est important pour elle)
- Un besoin urgent et une frustration aujourd'hui
- Quelles données elle utilise et quel accès il lui faut
- À quoi ressemble la réussite pour elle
Exemple de persona (modèle au tableau - le groupe adapte ou remplace) :
Aminata Diallo - animatrice communautaire, UrbaSEN Ziguinchor
| Qui elle est | Aminata a 34 ans. Elle travaille avec des groupes d'épargne dans deux quartiers de Ziguinchor. Ce n'est pas une experte en cartographie ; elle utilise un téléphone et parfois un ordinateur au bureau UrbaSEN. |
| Au quotidien | Visite les quartiers, accompagne les enquêteurs, prépare les membres de la fédération pour les réunions avec la mairie, transforme les résultats d'enquête en cartes simples et points de discussion. |
| Objectif | Éviter que des habitants perdent leur logement sans preuves. Faire écouter la mairie avec des cartes datées et des chiffres, pas seulement des récits. |
| Motivation | Le quartier de sa tante a été déguerpie sans préavis. Elle ne veut pas que cela se reproduise sans que la fédération puisse montrer qui habite où et quels services existent. |
| Besoin urgent | Avant la prochaine réunion au conseil dans six semaines : une carte avec les limites du quartier, le nombre de ménages et les points d'eau - tout à la même date, facile à montrer sur une tablette. |
| Frustration aujourd'hui | Les données sont éparpillées - dossier Drive de quelqu'un, notes papier, ancien fichier sur un seul ordinateur. Elle passe des jours à recopier des chiffres dans des diapositives au lieu d'organiser. |
| Données dont elle a besoin | Limites de quartier, enquête ménages, infrastructure (eau, toilettes), photos ou récits liés aux lieux. |
| Accès dont elle a besoin | Lire et exporter pour les réunions ; elle ne charge pas les enquêtes brutes elle-même - elle passe par le gestionnaire des données. |
| Réussite pour elle | Elle ouvre la plateforme sur son téléphone, choisit son quartier, et a une carte et un résumé qu'elle peut présenter à la mairie en toute confiance. |
| Vie privée | Les noms de ménage et numéros de téléphone ne doivent pas apparaître sur ce que le public ou le conseil voit sans accord explicite. |
Demander au groupe : Qui dans votre équipe ressemble à Aminata - ou est différent ? Donnez-lui un nom, un métier, un objectif, une frustration.
Message clé : Une bonne user story nomme une action sur la plateforme et un résultat concret sur le terrain - et pointe vers des données documentées dans le questionnaire.
Pour chaque persona prioritaire, écrire une user story en langage simple : En tant que [rôle], je veux [faire quelque chose sur la plateforme], afin de [résultat dans le travail réel]. Une histoire par rôle suffit dans la salle. Optionnel : reformuler une histoire en Étant donné / Quand / Alors si le groupe le souhaite. Garder le lien avec les données du questionnaire - si l'histoire a besoin de données qui n'existent pas, noter le manque plutôt que de faire comme si elles étaient là.
Exemples à mettre au tableau (à adapter avec le groupe) :
1. Régularisation
En tant qu' organisatrice de la fédération préparant un dossier de régularisation, je veux rassembler limites de quartier, totaux de ménages agrégés, couverture des structures et manques de services dans un dossier cartographique daté, afin de montrer à la municipalité quels îlots informels répondent aux critères de reconnaissance formelle sans exposer les noms des résidents.
Utilise : limites, enquête ménages (agrégats), infrastructure, KYC.TV en option
2. Quand la carte officielle ne correspond pas à la réalité
En tant qu' organisatrice communautaire comme Aminata, je veux comparer notre limite de quartier vérifiée par la communauté avec la carte administrative sur un seul écran, avec les totaux de ménages rattachés, afin de montrer aux autorités locales où les habitants vivent vraiment quand la carte officielle les laisse de côté ou trace mal la limite.
Utilise : limites (communauté vs officiel), totaux ménages agrégés
3. Plaidoyer qui respecte la vie privée
En tant que responsable de programme / contrôleur des données, je veux garder les couches complètes d'enquête ménages en interne et publier seulement totaux agrégés et cartes approuvés par la fédération, afin d' utiliser les mêmes données en négociation et en plaidoyer public sans que noms ou numéros de téléphone apparaissent sur le web ouvert.
Utilise : enquête ménages (souvent données personnelles), règles de publication
Si une histoire a besoin de données qui n'existent pas encore, noter le manque plutôt que de faire comme si elles étaient prêtes.
Message clé : Terminer avec clarté - ce qu'on a capturé, ce qui reste ouvert, et comment suivre si les participants le souhaitent.
Relire ce qui a été noté : cas d'usage principaux, données qui les soutiennent, personas retenues, une histoire chacune, manques et points à confirmer. Mentionner brièvement qui décide des règles de publication (contrôleur des données vs gestionnaire au quotidien) si le temps le permet - le détail viendra plus tard. Proposer un groupe WhatsApp pour ceux qui veulent continuer le questionnaire ou clarifier des noms après la session (nom suggéré : KYC 2.0 Sénégal - suivi données). Confirmer un court résumé écrit sous 48 heures. Remercier et arrêter l'enregistrement.
Demander ; ne pas imposer. Noter les plans seulement quand les participants les partagent. Les données personnelles ne vont pas sur la carte publique par conception - noter les cas sensibles pour une discussion de gouvernance ultérieure.