Pour commencer : pour les analystes

Aperçu

Cette section de la bibliothèque de codes SNT s’adresse aux analystes, qu’ils soient membres du personnel du programme national, partenaires de mise en œuvre ou conseillers techniques, qui sont responsables de l’exécution des flux de travail de données qui alimentent l’adaptation infranationale. Elle couvre les étapes essentielles de configuration pour nous aider à utiliser efficacement la bibliothèque de codes : comment le guide est structuré, quelles sont les compétences de base attendues, comment organiser les dossiers de projet et comment écrire du code propre et cohérent dans différents langages.

L’objectif est de réduire les frictions, de prévenir les erreurs précoces et d’établir un flux de travail fluide et reproductible que d’autres peuvent suivre. Que nous commencions une nouvelle analyse ou que nous poursuivions un travail commencé par quelqu’un d’autre, cette section garantit que notre environnement est correctement configuré, que nos données sont organisées et que notre code est structuré de manière portable et collaborative.

Si nous sommes novices en codage dans notre langage préféré, R, Python ou Stata, nous proposons des liens vers des ressources fiables pour aider à développer rapidement les compétences de base. Si nous sommes déjà expérimentés, cette section aide à s’aligner sur les conventions utilisées dans l’ensemble de la base de code SNT. Investir un peu de temps ici au début nous fera gagner des heures plus tard lors de la mise à l’échelle, de l’adaptation ou du partage du travail entre équipes.

Une fois cette section terminée, nous serons prêts à commencer à exécuter les flux de travail dans la bibliothèque SNT. En pratique, le travail d’analyse est séquencé avec le cycle du plan stratégique national de lutte contre le paludisme (PSNP), y compris les examens de programme, le développement de plans et les calendriers de demandes de financement, afin que les analyses alimentent les décisions lorsqu’elles sont nécessaires.

Comment travailler avec l’équipe SNT

Voir l’Annexe 1 — Termes de référence pour le chef d’équipe SNT dans le Manuel d’adaptation infranationale des interventions contre le paludisme de l’OMS pour la composition et les responsabilités de l’équipe SNT, y compris comment l’équipe d’analyse s’intègre.

Une solide collaboration entre les analystes et l’équipe SNT est essentielle pour garantir que l’analyse est pertinente, fiable et exploitable. Bien que la bibliothèque de codes fournisse des flux de travail techniques, elle ne remplace pas le jugement programmatique. Ces flux de travail sont destinés à soutenir un processus mené par le dialogue, avec l’équipe SNT au centre.

Voici quelques principes à garder à l’esprit lorsque nous travaillons avec l’équipe SNT :

Utiliser les bonnes données, avec la bonne approbation : Nous ne devons utiliser que des sources de données qui ont été approuvées et fournies par l’équipe SNT ou convenues conjointement. L’accès aux données pays est régi par le programme national de lutte contre le paludisme et, le cas échéant, par des accords formels de partage de données ; voir le chapitre sur l’assemblage et la gestion des données du manuel SNT de l’OMS pour l’approche recommandée. Lorsque des données modélisées (par exemple, MAP, WorldPop) ou des proxys sont utilisés, ces choix doivent être discutés et validés avant utilisation. Toujours documenter l’origine et la version de chaque ensemble de données utilisé.
Être transparent sur les méthodes : Toutes les étapes d’analyse doivent être documentées clairement dans le code et les notes de support. Les hypothèses, transformations, exclusions et calculs doivent être explicables. L’objectif est de rendre visible le raisonnement derrière les résultats, pas seulement les résultats eux-mêmes.
S’attendre à un examen et une validation : L’équipe SNT devra examiner et approuver formellement les principaux résultats, y compris les résultats de stratification, les scores de priorisation et les comparaisons de scénarios. Nous devons nous attendre à plusieurs cycles de retours et y répondre de manière constructive. Tous les retours ne conduiront pas à des changements, mais nous devons expliquer clairement quand quelque chose ne peut pas ou ne doit pas être changé, et pourquoi. Le SNT est rarement noir ou blanc, et construire une compréhension partagée fait partie du travail.
Être clair lorsque les changements ne sont pas faisables : Toutes les demandes de l’équipe SNT ne peuvent pas ou ne doivent pas être mises en œuvre. Nous devons être prêts à expliquer quand les limitations en matière de données, de méthodes ou de calendriers empêchent une révision, et à justifier pourquoi. Être honnête sur les contraintes aide à renforcer la confiance et évite les mauvaises interprétations.
Rester aligné sur l’objectif : Nous ne sommes pas là uniquement pour exécuter du code. Nous sommes là pour aider l’équipe SNT à interpréter ce que disent les données, comment elles se connectent aux décisions passées et futures, et quelles incertitudes ou lacunes doivent être reconnues. Cela signifie s’engager dans le dialogue, pas seulement livrer des fichiers.
S’attendre à réviser et itérer : Le SNT n’est pas un exercice ponctuel. Nous devons nous attendre à revisiter les analyses à mesure que de nouvelles contributions, questions ou retours proviennent de l’équipe SNT. C’est une partie normale et nécessaire de la construction de l’appropriation et de l’assurance que les résultats servent les besoins réels de planification.
Comprendre qu’itération ≠ refaire le travail : Revisiter les résultats ne consiste pas à refaire le travail passé, il s’agit de répondre à des questions changeantes et de rendre l’analyse plus utile. Nous devons aborder cela comme une partie attendue et constructive du processus.
Prioriser le dialogue plutôt que la livraison : Traiter chaque résultat comme un point de départ de conversation. Ne pas simplement envoyer des fichiers, mais engager l’équipe SNT pour l’aider à interpréter la signification et les implications des résultats. Utiliser des aides visuelles claires, des résumés ou des briefings verbaux lorsque cela est utile.
Mettre le contexte local en premier : Lorsque les résultats, en particulier ceux basés sur des modèles, entrent en conflit avec ce qui est connu localement (par exemple, sur la saisonnalité ou la charge du paludisme), les données locales doivent guider les décisions. Nous devons être prêts à ajuster ou annoter les résultats pour refléter ce contexte.
Documenter les compromis et les contraintes : Tenir un journal continu des compromis effectués, tels que les choix de proxy, les hypothèses ou les ensembles de données omis. C’est essentiel pour la transparence et pour expliquer les décisions aux parties prenantes.
Maintenir un enregistrement partagé des résultats et des discussions : Parallèlement au code, maintenir un document PowerPoint partagé (ou document similaire) qui capture chaque étape du travail, les résultats, les retours, les décisions et la justification. Le mettre à jour régulièrement afin qu’il y ait un historique clair et centralisé de ce qui a été fait et convenu. Cela facilite l’intégration de nouvelles personnes, réduit les répétitions et aide à préserver la mémoire institutionnelle.

Ensemble, ces principes garantissent que l’analyse est techniquement solide et alignée sur les priorités pays et les processus de prise de décision. Travailler en étroite collaboration avec l’équipe SNT aide à renforcer la confiance dans les résultats, garantit que les méthodes reflètent le contexte local et augmente la probabilité que les résultats soient utilisés pour éclairer la stratégie. Considérez la bibliothèque de codes comme un point de départ. La vraie valeur vient de son adaptation avec l’orientation de l’équipe SNT.

Tenir des registres

Nous devons tenir de bons registres de notre travail. Cela peut inclure le stockage de tous les détails de processus et de résultats via un document PowerPoint en croissance (ou autre document vivant), qui est partagé avec l’équipe SNT à chaque mise à jour. Le document vivant doit également inclure les enregistrements des discussions avec l’équipe SNT et leurs conclusions, de sorte que l’enregistrement complet de l’analyse existe en un seul endroit.

Cet enregistrement, bien qu’étendu, doit expliquer de manière claire et logique ce qui a été fait, ce qui a été décidé et pourquoi. Nous devons également conserver les procès-verbaux des discussions de l’équipe SNT concernant notre travail et diffuser les procès-verbaux après les réunions avec des éléments d’action clairs et des responsables.

Tenir de bons registres tout au long du processus facilitera et accélérera la préparation d’un rapport final approfondi et clair du travail.

Jalons clés de validation

Voir le Tableau 1 du manuel SNT de l’OMS pour le processus complet étape par étape et où l’équipe SNT approuve formellement les résultats d’analyse.

Au minimum, l’équipe d’analyse doit prévoir de présenter les résultats à l’équipe SNT pour validation à ces jalons :

Après l’assemblage des données et l’examen de la situation, pour confirmer quelles données sont utilisées et comment elles ont été traitées.
Après la stratification de l’épidémiologie du paludisme et de ses déterminants, pour confirmer les choix de classification et les cartes résultantes.
Après l’adaptation des interventions, pour confirmer la combinaison d’interventions proposée et les critères de ciblage.
Après les scénarios stratégiques et opérationnels chiffrés, pour confirmer la priorisation et l’allocation des ressources.

Chaque jalon est un point où l’analyse s’arrête pour examen et décision, plutôt qu’une simple mise à jour de statut.

Orientation et configuration

Comment utiliser ce guide

Chaque section de la bibliothèque de codes SNT est conçue pour être claire, structurée et autonome. Que nous cherchions à traiter des données DHIS2, extraire des rasters de population ou calculer des taux d’incidence, nous constaterons que chaque page suit la même logique cohérente, nous permettant de nous concentrer sur les étapes analytiques sans avoir besoin de nous réorienter à chaque fois.

Voici comment le guide est organisé :

Aperçu en haut

Chaque section commence par un Aperçu qui explique ce que fait le flux de travail, pour quel type de données il est conçu et comment il s’intègre dans le processus SNT plus large. L’objectif est de nous aider à nous orienter avant l’introduction de tout code. Il expose ce que la section couvre, quand le flux de travail est pertinent et comment il se connecte avec d’autres parties du pipeline. S’il y a des points où une consultation avec l’équipe SNT est requise, par exemple, si nous devons confirmer qu’un ensemble de données modélisées est approprié ou vérifier que la méthode utilisée a été validée, cela est noté clairement au début, afin de ne pas être manqué plus tard dans les étapes.

Orientation étape par étape

Le cœur de chaque page est une série d’étapes qui parcourent la tâche en détail. Chaque étape comprend du code exécutable R, Python et Stata, de brèves explications de ce que fait le code, et le cas échéant, de courts commentaires sur les hypothèses, la logique ou les pièges typiques.

Encadrés pour la clarté et l’accent

Tout au long de la documentation, des encadrés visuels sont utilisés pour mettre en évidence des informations importantes :

Encadré Objectif

Les encadrés Objectif apparaissent au début de chaque page et résument ce que la section est conçue pour nous aider à réaliser. Ils nous aident à nous orienter avant que tout code ne commence.

Encadrés Conseil

Les encadrés Conseil offrent des suggestions pratiques ou des rappels utiles, conventions de nommage, astuces de performance ou petites façons de réduire la complexité. Ils sont basés sur l’expérience pratique et sont destinés à rendre notre flux de travail plus fluide.

Encadrés Important

Les encadrés Important sont utilisés pour signaler les exigences techniques, les limitations des données ou les points où l’interprétation erronée est facile. Nous les verrons souvent lors de l’utilisation de données modélisées comme MAP ou WorldPop, ou lors du travail avec des ensembles de données incomplets.

Consulter l’équipe SNT

Les encadrés Consulter l’équipe SNT apparaissent lorsque nous devons vérifier avec l’équipe SNT avant de continuer, par exemple, avant d’utiliser des rasters modélisés, de définir des règles de classification ou d’appliquer des indicateurs proxy. Ils sont souvent placés tôt dans la section, afin de ne pas être manqués plus tard.

Valider avec l’équipe SNT

Les encadrés Valider avec l’équipe SNT sont utilisés après les étapes d’exécution de code qui génèrent des résultats nécessitant un examen, tels que les résultats de stratification, les listes de districts priorisés ou les couches de risque visualisées. Ces étapes doivent être examinées par l’équipe SNT nationale avant d’être utilisées dans la prise de décision.

Comment adapter le code

À la fin de la plupart des blocs de code, il y a une note “Comment adapter le code”. Celles-ci sont adaptées aux utilisateurs appliquant le flux de travail dans un pays différent, avec des noms de fichiers différents ou utilisant des limites administratives différentes. Ces instructions sont minimales mais ciblées, juste assez pour montrer quoi modifier et comment, sans ralentir le flux de travail.

Code complet en bas

Chaque section se termine par un bloc de code complet qui rassemble tout. Si nous comprenons déjà ce que fait la section et voulons simplement exécuter l’ensemble, nous pouvons faire défiler vers le bas et le copier en une seule fois. C’est également utile lors de l’examen ou du dépannage d’un script que nous avons déjà écrit.

Une note finale : De nombreux exemples dans cette bibliothèque utilisent les données DHIS2 de Sierra Leone pour illustrer comment fonctionnent différents flux de travail. Ces exemples sont destinés à démontrer la structure et la logique, pas à être copiés directement. Nous devrons adapter le code pour correspondre à notre propre contexte, y compris les noms de fichiers, les limites administratives, les noms d’indicateurs et les structures de données. Chaque section comprend des notes (dans la section “Comment adapter le code”) pour guider ce processus, mais il est de notre responsabilité de nous assurer que le flux de travail s’aligne sur les données et les exigences d’analyse de notre pays.

Exigences système et configuration

La bibliothèque de codes SNT prend en charge les flux de travail en R, Python et Stata, avec des modules de base conçus pour fonctionner de manière cohérente dans tous les langages. Bien que chaque page de la bibliothèque de codes puisse présenter un langage en premier, des scripts et une logique équivalents sont fournis dans des sections à onglets tout au long, permettant aux utilisateurs de suivre le même flux de travail en R, Python ou Stata.

Pour commencer, choisissez le langage que nous utiliserons et assurons-nous que notre environnement est correctement configuré. Chaque onglet ci-dessous décrit ce qui est requis et attendu pour ce langage, y compris les instructions d’installation, les outils recommandés et les conseils sur les packages.

La bibliothèque de codes est conçue pour être utilisée dans un flux de travail basé sur R. Tous les exemples sont écrits en R et supposent que nous travaillons depuis RStudio, qui offre l’environnement le plus fiable pour exécuter des morceaux de code et prévisualiser les résultats, naviguer dans les dossiers et gérer les chemins de fichiers, travailler avec des documents Quarto et intégrer le contrôle de version via Git. Au minimum, nous devons avoir : R version 4.2 ou supérieure (qui peut être téléchargée ici), la dernière version de RStudio (disponible ici), une connexion Internet active pour installer les packages et télécharger des données externes si nécessaire.

Tous les packages sont gérés à l’aide du package pacman, qui simplifie à la fois le chargement et l’installation. Nous verrons cette approche utilisée tout au long de la bibliothèque de codes :

pacman::p_load(
  dplyr,
  sf,
  exactextractr,
  terra)

La bibliothèque de codes peut également être utilisée dans un flux de travail basé sur Python. Les exemples supposent que nous travaillons depuis JupyterLab, Jupyter Notebook ou VS Code, qui sont les environnements les plus courants pour le codage interactif, l’analyse de données et la visualisation. Au minimum, nous devons avoir : Python 3.9 ou supérieur (téléchargeable depuis python.org ou inclus dans Anaconda), et une connexion Internet active pour installer les packages et télécharger des données externes si nécessaire.

Tous les packages sont gérés à l’aide de pip ou conda (si vous utilisez Anaconda). Pour simplifier la gestion des packages dans différents environnements, nous recommandons de créer un environnement virtuel ou un environnement conda pour le projet. Un ensemble minimal de packages requis peut être installé comme suit :

# Using pip
pip install pandas geopandas rasterio shapely matplotlib

# Or using conda
conda install pandas geopandas rasterio shapely matplotlib -c conda-forge

Dans les scripts Python tout au long de la bibliothèque, les packages sont généralement importés en haut de chaque script comme ceci :

import pandas as pd
import geopandas as gpd
import rasterio
from shapely.geometry import Point
import matplotlib.pyplot as plt

Connaissances supposées

Cette bibliothèque de codes suppose une connaissance pratique de base de R, Python ou Stata, selon le langage que nous utilisons pour suivre les exemples.

Un profil d’analyste SNT typique combine plusieurs compétences complémentaires :

Aisance avec au moins un de R, Python ou Stata pour la manipulation de données et la visualisation.
Compréhension de base des systèmes d’information géographique (SIG) et des données spatiales, car la plupart des résultats SNT sont cartographiés à adm1, adm2 ou adm3.
Familiarité pratique avec les principales sources de données SNT (surveillance de routine HMIS / DHIS2, enquêtes ménages, estimations modélisées, couverture des interventions).
Aisance avec le contrôle de version (généralement Git) et les structures de projet reproductibles.

Nous n’avons pas besoin d’être expert dans tous les domaines pour utiliser la bibliothèque, mais nous devons prévoir de développer les éléments manquants au fur et à mesure de la progression des analyses.

Pour les utilisateurs de R, nous devons être à l’aise pour exécuter du code dans RStudio, lire et écrire des fichiers de données en utilisant des fonctions comme rio::import() et readRDS(), et utiliser des packages couramment appliqués tels que dplyr et ggplot2.

Bon nombre des flux de travail s’appuient sur des fonctions pré-construites du package sntutils qui gère les tâches courantes comme le téléchargement, le nettoyage, l’agrégation ou la visualisation de données. Notre tâche principale est de fournir les bonnes entrées et de comprendre comment la sortie s’intègre dans le pipeline plus large.

Si nous rencontrons des problèmes avec une fonction dans sntutils et que l’aide intégrée ou la documentation ne les résout pas, veuillez contacter info@appliedhealthanalytics.org pour obtenir de l’aide. Cela garantit que tous les bogues ou comportements peu clairs sont signalés et traités de manière centralisée.

Par exemple, la fonction ci-dessous télécharge les rasters de précipitations CHIRPS mensuels pour janvier à mars 2022 en Afrique et les enregistre dans un dossier local :

# download Africa monthly rainfall for jan to mar 2022
download_chirps(
  dataset = "africa_monthly",
  start = "2022-01",
  end = "2022-03",
  out_dir = "data/chirps"
)

Nous ne sommes pas censés regarder à l’intérieur de ces fonctions ou les modifier. Elles sont construites pour simplifier le flux de travail et réduire les erreurs.

Et si je suis novice en codage ?

Si nous sommes novices en R, Python ou Stata, il existe d’excellentes ressources adaptées aux débutants pour nous aider à démarrer. Bien que la bibliothèque de codes SNT soit conçue pour être lisible et réutilisable, elle suppose une certaine familiarité de base avec la syntaxe, les fonctions et comment exécuter des scripts dans le langage choisi.

Cette bibliothèque n’est pas destinée à enseigner un langage à partir de zéro, mais les compétences qu’elle suppose sont largement enseignées et faciles à développer avec les bons outils. Ci-dessous sont des ressources sélectionnées pour aider à acquérir les bases nécessaires pour travailler efficacement avec la bibliothèque de codes.

Voici quelques ressources recommandées pour débuter avec R, toutes gratuites et bien considérées dans les communautés de science des données et d’épidémiologie. Celles-ci aideront à développer les compétences de base nécessaires pour travailler efficacement avec la bibliothèque de codes SNT :

Livres et tutoriels pour débutants

R for Data Science (2e) par Hadley Wickham et Mine Çetinkaya-Rundel : Une excellente et accessible introduction à R et au tidyverse. Les chapitres parcourent l’importation de données, la manipulation, la visualisation et la modélisation, avec des exemples exécutables.
The Epidemiologist R Handbook: Adapté aux cas d’usage de santé publique et d’épidémiologie. Offre des exemples concis et des conseils pratiques sur les flux de travail épidémiologiques du monde réel, y compris dplyr, sf et ggplot2.

Tutoriels interactifs à rythme libre

RStudio Primers: Tutoriels interactifs gratuits basés sur navigateur hébergés par Posit (anciennement RStudio). Idéal pour apprendre les packages tidyverse tels que dplyr, ggplot2 et tidyr grâce à une pratique guidée.
Swirl: Un package qui enseigne R directement dans la console RStudio. Idéal pour les débutants, installez-le, exécutez swirl::swirl() et commencez à apprendre depuis R lui-même. Couvre des sujets comme les types de données, dplyr et le traçage.

Vidéos et MOOC

Datacamp: Introduction to R: Un cours pratique pour débutants qui parcourt la syntaxe R, les types de données et les vecteurs. Offre des défis de code interactifs dans le navigateur (le niveau gratuit comprend un accès limité).
Coursera: R Programming by Johns Hopkins: Un cours fondamental qui introduit les bases du langage R et développe jusqu’aux fonctions et structures de données. Gratuit en audit.

Autres ressources utiles

Posit Cheatsheets: Références PDF compactes pour les packages populaires comme dplyr, ggplot2 et sf. Utile pour les recherches rapides et les rappels lors du travail avec la bibliothèque de codes SNT.
R Bloggers: Un agrégateur de blogs communautaire pour tout ce qui concerne R. Bon pour découvrir des tutoriels, des meilleures pratiques et des conseils de dépannage.

Python est un langage de programmation de haut niveau, à usage général, qui met l’accent sur un code lisible et utilise une indentation significative pour structurer les programmes.

Python se classe parmi les langages de programmation les plus populaires et bénéficie d’une large adoption en apprentissage automatique. De nombreux instructeurs l’utilisent également pour introduire la programmation.

La polyvalence de Python le rend idéal pour les projets axés sur les données, y compris l’épidémiologie et les analyses de santé publique. Pour utiliser efficacement la bibliothèque de codes SNT, nous recommandons les ressources suivantes. Elles enseignent les concepts essentiels de Python, la manipulation de données et les techniques d’analyse, nous préparant à travailler en toute confiance avec les données de routine sur le paludisme et les ensembles de données connexes.

Livres et tutoriels pour débutants

Python for Everybody : Un livre largement utilisé et adapté aux débutants qui introduit les bases de Python, les structures de données et le travail avec les fichiers de données.
Automate the Boring Stuff with Python : Une introduction pratique à Python avec des exemples du monde réel comme la gestion de fichiers, les feuilles de calcul et l’automatisation. Idéal pour les débutants qui veulent une pratique concrète.
Think Python : Une introduction gratuite et claire qui construit des bases solides dans les concepts de programmation en utilisant Python.

Tutoriels interactifs à rythme libre

Kaggle Learn Python : Cours interactifs gratuits et courts conçus pour les débutants. Comprend les bases de Python, pandas et la visualisation de données.
DataCamp: Introduction to Python : Un cours pratique pour débutants axé sur Python pour la science des données, couvrant les variables, les structures de données et le traçage simple (le niveau gratuit comprend un accès limité).
Google’s Python Class : Une ressource gratuite pour les personnes ayant un peu d’expérience en programmation qui veulent apprendre Python, avec des leçons écrites et des exercices.

Vidéos et MOOC

Coursera: Python for Everybody : Une spécialisation complète pour débutants couvrant les fondamentaux de Python et la gestion des données. Gratuit en audit.
Harvard CS50’s Introduction to Programming with Python : Un excellent MOOC gratuit introduisant les concepts fondamentaux de programmation avec Python.

Autres ressources utiles

Python Cheatsheet : Une référence compacte aux commandes et syntaxe Python courantes.
Real Python : Une plateforme communautaire offrant des tutoriels et des meilleures pratiques pour Python, du débutant à l’avancé.
Stack Overflow Python Tag : Un lieu de référence pour le dépannage et le support communautaire.

Ces ressources sont plus que suffisantes pour aider à développer les compétences de base attendues ici. Nous n’avons pas besoin de tout maîtriser avant d’utiliser la bibliothèque de codes SNT, mais gagner en aisance avec la syntaxe de base et les flux de travail dans le langage préféré rendra l’ensemble du processus plus fluide et plus facile d’adapter le code à notre propre contexte spécifique.

Conventions de travail

Structures de dossiers et chemins de fichiers

Organiser les fichiers de projet de manière cohérente est l’une des étapes les plus importantes que nous pouvons prendre pour réduire les erreurs, éviter la duplication et rendre notre analyse reproductible. Dans la bibliothèque de codes SNT, nous supposons que nous travaillons dans un système de dossiers structuré qui reflète la logique du flux de travail SNT, avec des dossiers dédiés pour les entrées (comme les shapefiles bruts ou les données d’enquête), les sorties (comme les graphiques ou les résumés) et les scripts de codage regroupés par sujet.

Nous recommandons fortement d’initialiser chaque analyse pays ou flux de travail comme son propre système de dossiers autonome, idéalement structuré comme un projet RStudio (voir ci-dessous). Cela garantit que les chemins relatifs se comporteront comme prévu et que les sorties ne seront pas dispersées sur la machine.

Exemple de structure

Voici une version de base de ce à quoi cela pourrait ressembler :

your-snt-project/
│
├── 01_data/
│   ├── 1.1_foundational/
│   │   ├── 1.1a_admin_boundaries/{raw,processed}/
│   │   ├── 1.1c_health_facilities/{raw,processed}/
│   │   └── 1.1e_population/
│   │       ├── 1.1ei_national/{raw,processed}/
│   │       └── 1.1eii_worldpop_rasters/{raw,processed}/
│   ├── 1.2_epidemiology/
│   │   ├── 1.2a_routine_surveillance/{raw,processed}/
│   │   └── 1.2b_pfpr_estimates/{raw,processed}/
│   └── 1.5_environment/
│       └── 1.5a_climate/{raw,processed}/
├── 02_scripts/
├── 03_outputs/
│   ├── 3.1_validation/{figures,tables}/
│   ├── 3.2_intermediate_products/{figures,tables}/
│   ├── 3.3_final_snt_outputs/{figures,tables}/
│   └── 3.4_model/{figures,tables}/
├── 04_reports/
├── 05_metadata_docs/
└── README.md

Nous n’avons pas besoin de copier cela exactement, le point est d’avoir une séparation claire entre les données brutes, les données traitées, les scripts et les sorties, et de garder la structure cohérente entre les projets et les membres de l’équipe.

Utiliser la fonction de modèle SNT (optionnel mais recommandé)

Si nous commençons de zéro, le package sntutils (exemple R montré ici) comprend une fonction utilitaire qui configure ce type de système de dossiers. Cela fait gagner du temps et aide à réduire les frictions précoces avec la gestion des fichiers.

sntutils::initialize_project_structure(
  base_path = "sierra_leone_snt"
)

Cela générera un répertoire comme celui ci-dessous, avec des sous-dossiers déjà créés pour les données fondamentales, l’épidémiologie, les interventions, l’environnement, les systèmes de santé et d’autres domaines majeurs de l’analyse SNT :

sierra_leone_snt/
│
├── 01_data/
│   ├── 1.1_foundational/
│   │   ├── 1.1a_admin_boundaries/{raw,processed}/
│   │   ├── 1.1b_physical_features/{raw,processed}/
│   │   ├── 1.1c_health_facilities/{raw,processed}/
│   │   ├── 1.1d_community_health_workers/{raw,processed}/
│   │   ├── 1.1e_population/
│   │   │   ├── 1.1ei_national/{raw,processed}/
│   │   │   ├── 1.1eii_worldpop_rasters/{raw,processed}/
│   │   │   └── 1.1eiii_displaced_pop/{raw,processed}/
│   │   └── 1.1f_cache_files/{raw,processed}/
│   ├── 1.2_epidemiology/
│   │   ├── 1.2a_routine_surveillance/{raw,processed}/
│   │   ├── 1.2b_pfpr_estimates/{raw,processed}/
│   │   └── 1.2c_mortality_estimates/{raw,processed}/
│   ├── 1.3_interventions/
│   │   ├── 1.3a_itns/{raw,processed}/
│   │   ├── 1.3b_iptp/{raw,processed}/
│   │   ├── 1.3c_smc/{raw,processed}/
│   │   ├── 1.3d_vap/{raw,processed}/
│   │   ├── 1.3e_anc/{raw,processed}/
│   │   └── 1.3f_irs/{raw,processed}/
│   ├── 1.4_drug_efficacy_resistance/{raw,processed}/
│   ├── 1.5_environment/
│   │   ├── 1.5a_climate/{raw,processed}/
│   │   ├── 1.5b_accessibility/{raw,processed}/
│   │   └── 1.5c_land_use/{raw,processed}/
│   ├── 1.6_health_systems/
│   │   └── 1.6a_dhs/{raw,processed}/
│   ├── 1.7_entomology/{raw,processed}/
│   ├── 1.8_commodities/{raw,processed}/
│   ├── 1.9_finance/{raw,processed}/
│   └── 1.10_final/
├── 02_scripts/
├── 03_outputs/
│   ├── 3.1_validation/{figures,tables}/
│   ├── 3.2_intermediate_products/{figures,tables}/
│   ├── 3.3_final_snt_outputs/{figures,tables}/
│   └── 3.4_model/{figures,tables}/
├── 04_reports/
└── 05_metadata_docs/

Projets R et chemins relatifs (utilisateurs R uniquement)

Pour ceux qui utilisent R, la bibliothèque de codes SNT suppose que l’analyse de chaque pays est gérée comme un projet RStudio dédié. Cela signifie que tous les scripts, données, sorties et rapports vivent dans le même dossier, avec le fichier .Rproj à la racine. La configuration d’un projet R est simple, et plus de détails peuvent être trouvés ici sur la façon d’en créer un en utilisant RStudio.

Travailler de cette manière présente plusieurs avantages :

Les chemins de fichiers sont prévisibles et portables.
Les chemins codés en dur qui ne fonctionnent que sur une machine sont évités.
Les entrées et les sorties sont organisées et faciles à localiser.
Les erreurs dues à des répertoires de travail incompatibles (getwd()) sont minimisées.
Le code devient plus facile à partager entre les équipes lorsque tout le monde utilise la même structure.

Lorsque nous ouvrons un projet via le fichier .Rproj (par exemple, sierra_leone_snt.Rproj), RStudio définit ce dossier comme répertoire de travail. Nous n’avons pas besoin d’utiliser setwd() ou de gérer le répertoire de travail manuellement.

Toujours utiliser here::here() pour les chemins de fichiers

Cette bibliothèque de codes utilise systématiquement here::here() pour construire les chemins de fichiers. Cela garantit que les scripts peuvent accéder aux entrées et enregistrer les sorties de manière fiable, quelle que soit la machine ou le système d’exploitation. Par exemple :

# avoid this
readRDS("C:/Users/yourname/Desktop/snt_project/01_data/...")

# use this
readRDS(
  here::here(
    "01_data",
    "1.1_foundational",
    "1.1a_admin_boundaries",
    "sle_spatial_adm3_2021.rds"
  )
)

Exemple : dossier de projet Sierra Leone

Si cette configuration était appliquée au flux de travail SNT de Sierra Leone, le dossier de niveau supérieur ressemblerait à :

sierra_leone_snt/
│
├── sierra_leone_snt.Rproj
├── 01_data/
├── 02_scripts/
├── 03_output/
│   ├── 3a_figures/
│   └── 3b_tables/
└── README.md

En gardant tout dans un seul dossier autonome et en utilisant des chemins relatifs avec here::here(), nous simplifions la collaboration, facilitons le débogage et garantissons que notre code reste portable et reproductible, principes fondamentaux tout au long de la bibliothèque de codes SNT. Cette structure jette également les bases de la façon dont les données sont organisées et accessibles dans les étapes ultérieures. Pour plus de détails sur la façon dont les entrées, les sorties et les types de fichiers sont structurés dans le flux de travail, voir la section Structures de données.

Style et formatage du code

Pour soutenir la clarté, la collaboration et la facilité d’adaptation entre les projets, la bibliothèque de codes SNT suit une approche cohérente pour écrire du code. Des exemples équivalents pour R, Python et Stata sont fournis tout au long en utilisant des ensembles d’onglets. Bien que la syntaxe diffère, les mêmes principes de structure propre, de logique cohérente et de formatage lisible s’appliquent à tous les langages. Nous ne sommes pas stricts sur l’application de chaque ligne, mais nous encourageons l’adoption de ces habitudes car elles favorisent la clarté et les bonnes pratiques, en particulier dans les flux de travail partagés ou à long terme.

Principes généraux de style

Préférer la syntaxe de style tidyverse : Nous écrivons la plupart du code en utilisant dplyr, tidyr et d’autres outils tidyverse. Cela maintient la logique transparente et cohérente. Nous évitons de mélanger les idiomes R de base avec tidyverse sauf en cas de besoin.
Utiliser le pipe R de base |> par défaut : Le pipe natif est natif à R (depuis la version 4.1), ne nécessite aucun package supplémentaire et évite les dépendances inutiles. Cela aide les nouveaux utilisateurs à éviter de charger magrittr ou dplyr juste pour utiliser les pipes. Nous verrons encore |> utilisé dans les scripts lourds en tidyverse, mais pour le chaînage général, |> est préféré et plus pérenne.
Utiliser un pipe par ligne : Éviter d’écrire de longues chaînes sans pauses. Au lieu de cela, écrire chaque étape clairement sur une nouvelle ligne. Cela facilite le débogage et aide les autres à suivre la logique.
Toujours inclure les espaces de noms de packages : Écrire dplyr::mutate() ou readxl::read_excel() plutôt que de s’appuyer sur library(). Cela évite l’ambiguïté lorsque des fonctions de différents packages partagent des noms (par exemple, filter() qui existe dans R de base et dplyr), et cela facilite la compréhension de l’origine de chaque fonction.
Garder le code à 80 caractères de large : Le retour à la ligne aide à la lisibilité et rend les différences de contrôle de version beaucoup plus faciles à suivre. Si une ligne devient trop longue, la diviser logiquement sur plusieurs lignes.
Utiliser des commentaires pour structurer le script : Commencer chaque section par un court en-tête et utiliser des commentaires pour expliquer la logique où elle n’est pas évidente. Même quelques lignes comme # Import data ou # Convert date columns aident à orienter le lecteur.

Pour voir comment ces principes se rejoignent, dépliez l’exemple ci-dessous. Il montre un script bien organisé qui suit les conventions que nous recommandons : syntaxe de style tidyverse, pipes R de base, espaces de noms explicites, commentaires structurés et formatage propre tout au long. Cette structure améliore la lisibilité, réduit les bogues et facilite la réutilisation ou l’adaptation du code dans les futurs flux de travail.

Dépliez ci-dessous pour voir ces principes et ce style appliqués en pratique, en utilisant le nettoyage de données DHIS2 comme exemple.

Show example code

# set up and data import -------------------------------------------------------

# install pacman if missing
if (!requireNamespace("pacman", quietly = TRUE)) {
  install.packages("pacman")
}

# load required packages
pacman::p_load(
  readxl, # excel import
  dplyr,  # data manipulation
  tidyr,  # reshaping
  janitor # cleaning names
)

# import raw DHIS2 data
raw_data <- readxl::read_excel("data/dhis2_malaria_data.xlsx")

# data cleaning and wrangling --------------------------------------------------

raw_data2 <- raw_data |>
  janitor::clean_names() |>
  dplyr::rename(
    adm1 = orgunitlevel2,
    adm2 = orgunitlevel3,
    facility = organisationunitname,
    period = periodname
  ) |>
  tidyr::separate(period, into = c("month", "year"), sep = " ") |>
  dplyr::mutate(
    month = match(
      month,
      c(
        "Janvier",
        "Fevrier",
        "Mars",
        "Avril",
        "Mai",
        "Juin",
        "Juillet",
        "Aout",
        "Septembre",
        "Octobre",
        "Novembre",
        "Decembre"
      )
    ),
    month = base::as.integer(month),
    year = base::as.integer(year)
  )

Principes généraux de style pour les scripts Python

Utiliser des imports clairs et explicites

Toujours importer tous les packages requis en haut du script

import pandas as pd
import geopandas as gpd
import matplotlib.pyplot as plt

Utiliser des alias courts et significatifs pour la lisibilité

# 'pd' for pandas, 'gpd' for geopandas, 'plt' for matplotlib
df = pd.read_csv("malaria_data.csv")
gdf = gpd.read_file("chiefdom_boundaries.shp")

Éviter from module import * car cela masque la source des fonctions

# Bad practice:
# from pandas import *
# This can cause conflicts and make code unclear

Suivre les directives de style PEP 8

Utiliser 4 espaces par indentation et lowercase_with_underscores pour les noms de variables

# Example function showing proper indentation
def calculate_average_coverage(df):
    total_cases = df["cases"].sum()
    total_population = df["population"].sum()
    average_coverage = total_cases.div(total_population) * 100
    return average_coverage

# Example DataFrame
import pandas as pd

df = pd.DataFrame({
    "cases": [1000, 2000, 0],
    "population": [5000, 0, 2500]
})

avg_coverage = calculate_average_coverage(df)
print(f"Average coverage: {avg_coverage:.2f}%")

Utiliser pandas .div() pour éviter la division par zéro lors du travail avec des DataFrames

# Example DataFrame
import pandas as pd

df = pd.DataFrame({
    "cases": [100, 50, 120],
    "population": [1000, 0, 2000]  # note the zero
})

# Safe division: returns NaN instead of raising an error
df["coverage"] = df["cases"].div(df["population"]) * 100

print(df)

Utiliser des docstrings pour expliquer les entrées, les sorties et l’objectif

def calculate_coverage(cases, population):
    """
    Calculate coverage as a percentage of cases over population.

    Args:
        cases (int or float): Number of cases.
        population (int or float): Total population.

    Returns:
        float: Coverage percentage.
    """
    return (cases / population) * 100

Utiliser le chaînage de méthodes pour la lisibilité

Chaîner les méthodes au lieu de créer plusieurs variables intermédiaires

df_cleaned = (
    df.dropna(subset=["cases", "population"])  # Remove rows where 'cases' or 'population' are NaN
      .assign(coverage=lambda x: x["cases"] / x["population"] * 100)  # Calculate coverage %
      .query("coverage <= 100")  # Keep rows where coverage is <= 100
)

Garder une opération par ligne pour la clarté

# Each chained step is on its own line for readability
df_filtered = (
    df.dropna(subset=["cases"])
      .assign(coverage=lambda x: x["cases"]/x["population"]*100)
)

Commenter généreusement et structurer le code

Commencer les sections par un en-tête pour faciliter la navigation

# ==== 1. Load Data ====
df = pd.read_csv("malaria_data.csv")

Ajouter des commentaires en ligne pour la logique complexe ou non évidente

df["coverage"] = df["cases"] / df["population"] * 100  # convert to %

Séparer visuellement les sections pour la clarté

# ==== 2. Filter Data ====
df_filtered = df.query("coverage <= 100")

6. Gérer les erreurs et les exceptions

Utiliser des blocs try/except pour empêcher les scripts de planter de manière inattendue.

try:
    df = pd.read_csv("malaria_data.csv")
except FileNotFoundError:
    print("File not found. Please check the path.")

Un style de codage cohérent rend notre travail plus facile à lire, réviser et réutiliser. Les pratiques partagées ici, telles que diviser le code en sections claires, utiliser une dénomination descriptive et appliquer un formatage cohérent, ne sont pas des règles strictes mais des habitudes utiles. Elles réduisent les erreurs, soutiennent la collaboration et facilitent le maintien et l’adaptation du code au fil du temps. Pour les nouveaux utilisateurs, ce sont des habitudes particulièrement bonnes à développer tôt.

Structures de données pour les flux de travail SNT

Après avoir configuré notre environnement de travail et organisé notre structure de dossiers, l’étape suivante consiste à s’assurer que nos données sont structurées de manière à soutenir l’analyse, la collaboration et la reproductibilité. Cela implique une conception réfléchie de la façon dont les données sont formatées, à la fois dans les ensembles de données individuels et dans le référentiel de données plus large.

Pourquoi cela importe pour le SNT

Le SNT repose sur la combinaison d’ensembles de données divers, surveillance de routine, estimations de PfPR, couverture des interventions, population, entomologie, et plus encore. Ces données doivent être interopérables : elles doivent s’aligner sur la localisation, le temps et les définitions de variables. Sans structure, l’analyse devient ad hoc, manuelle et sujette aux erreurs. Avec une bonne structure, les flux de travail deviennent automatisés, les ensembles de données deviennent réutilisables et l’analyse devient plus facile à valider et à partager.

Il existe deux niveaux de structures de données, et ce sont :

Structure au sein des ensembles de données : La structure commence par la clarté interne. Les colonnes sont-elles nommées de manière intuitive et sans ambiguïté ? Les valeurs, telles que les dates, les codes ou les catégories, sont-elles formatées de manière cohérente dans toutes les lignes ? Les unités géographiques et les variables temporelles sont-elles normalisées pour soutenir la jointure, le filtrage et la comparaison ? Un ensemble de données bien structuré est ordonné, prêt pour l’analyse et réduit l’ambiguïté avant toute intégration ou analyse ne commence.

Structure entre les ensembles de données : La structure signifie également la cohérence entre les différents ensembles de données SNT. Peuvent-ils être joints de manière fiable en utilisant des clés communes comme adm1, adm2, year_month ou indicator_code ? Les formats de fichiers et les noms de dossiers sont-ils cohérents et intuitifs ? Cela garantit que les ensembles de données peuvent être joints sans problèmes et résident dans un référentiel organisé et navigable, rendant l’ensemble du système plus facile à gérer, à mettre à l’échelle et à faire confiance.

Dans les sections qui suivent, nous décrivons les principes et les étapes pratiques pour rendre nos ensembles de données à la fois ordonnés et harmonisés, prêts à être intégrés dans n’importe quel flux de travail SNT.

Structure au sein d’un ensemble de données

La structure commence au sein de chaque ensemble de données. Chaque ensemble de données doit être clair en interne, ordonné et prêt pour l’analyse, cela forme la base pour une jointure, un filtrage et une agrégation fiables. Il doit suivre les principes de données ordonnées, utiliser des noms de colonnes standardisés et être autonome avec des étiquettes et une documentation claires.

Pour y parvenir, nous nous concentrons sur quelques pratiques clés :

1. Doit être ordonné

Les données ordonnées sont un concept de Hadley Wickham qui définit une manière simple et structurée d’organiser les données de manière organisée et utilisable :

Selon ce principe : - Chaque variable forme une colonne - Chaque observation forme une ligne - Chaque type d’unité d’observation forme sa propre table

Cette structure minimise l’ambiguïté et réduit les frictions lors de l’analyse. Au lieu de passer du temps à remodeler et nettoyer des tableaux mal organisés, les analystes peuvent se concentrer sur des tâches plus substantielles. Les ensembles de données ordonnés facilitent la fusion avec d’autres sources, comme combiner les données de cas de routine avec les estimations de population ou les rasters environnementaux, et améliorent la réutilisabilité du code dans les scripts partagés et les pipelines d’analyse.

Par exemple, considérons un ensemble de données de population fourni dans ce format large :

region	district	pop_u5_2020	pop_u5_2021	pop_total_2020	pop_total_2021
Boké	Gaoual	6500	6800	47000	48500

Cette structure rend difficile le filtrage par année ou groupe d’âge. Une version ordonnée remodèle les données en format long, les rendant beaucoup plus utilisables :

region	district	year	age_group	population
Boké	Gaoual	2020	u5	6500
Boké	Gaoual	2020	total	47000
Boké	Gaoual	2021	u5	6800
Boké	Gaoual	2021	total	48500

Avec des données en format ordonné, le filtrage et la transformation deviennent intuitifs. Par exemple :

pop_data |>
    dplyr::filter(year == 2020) |>
    dplyr::select(
        district, year,
        age_group, pop
    )

pop_data = (pop_data
    .query("year == 2020")
    .loc[:, ['district', 'year', 'age_group', 'population']]
)

# Alternative pandas syntax:
pop_data[pop_data['year'] == 2020][['district', 'year', 'age_group', 'population']]

# Or using method chaining:
pop_data.loc[pop_data['year'] == 2020, ['district', 'year', 'age_group', 'population']]

Ce qui donne :

district	year	age_group	pop
Gaoual	2020	u5	6500
Gaoual	2020	total	47000

Le format ordonné facilite le filtrage, le regroupement, la jointure, la visualisation ou la modélisation des données sans remodelage constant. En organisant les ensembles de données dans un format long cohérent, nous réduisons les frictions tout au long du flux de travail. Cette approche soutient une logique claire, un code évolutif et une intégration plus fluide avec les outils sur toutes les plateformes. Pour plus de conseils sur les données ordonnées, consultez R for Data Science – Chapter 12: Tidy Data.

2. Doit avoir des colonnes standardisées

Les données ordonnées nous donnent une base solide, mais la structure seule ne suffit pas. Pour rendre les données vraiment prêtes pour le SNT, nous avons besoin de normalisation. La normalisation signifie aligner les éléments clés, y compris les géographies, les dates, les noms de variables et les groupes de population, afin que les ensembles de données puissent être joints, comparés et analysés de manière fiable. Sans cela, les fusions échouent et les sorties deviennent trompeuses. Avec cela, nos flux de travail sont plus simples, plus réutilisables et moins sujets aux erreurs.

À la base, la normalisation consiste à aligner les dimensions clés entre les ensembles de données afin qu’ils soient interopérables :

Géographies : Utiliser des noms et des codes cohérents pour les unités administratives (adm1, adm2, etc.). Les noms de districts incompatibles ou les codes manquants peuvent silencieusement casser les jointures.

Exemple : Si adm2 est orthographié Gaoual dans un ensemble de données et Guoal dans un autre, les deux ne se joindront pas correctement, conduisant à des enregistrements manquants ou incompatibles.
Dates : Adopter un format de date unifié (par exemple, year_month = “2023-09”). Les périodes de référence doivent être alignées afin que les indicateurs de différentes sources reflètent la même période.

Exemple : Des formats incohérents comme “Jan 2023” dans un ensemble de données et “2023-01” dans un autre peuvent faire échouer silencieusement les jointures ou produire des résultats mal alignés.
Variables : Les noms de colonnes et les définitions doivent suivre des conventions partagées (par exemple, utiliser conf_mic, pas confirmed_microscopy ; utiliser adm2, pas district_name).

Exemple : Si un ensemble de données utilise conf_mic et un autre utilise confirmed_microscopy, tenter de lier des lignes ou de joindre des tables échouera à moins que les colonnes ne soient renommées d’abord. C’est pourquoi il est préférable de convenir d’une convention de dénomination dès le début et de l’appliquer de manière cohérente dans tous les ensembles de données.
Groupes de population : Si les ensembles de données sont désagrégés (par exemple, par âge, sexe ou groupe à risque), assurez-vous que les catégories s’alignent. Par exemple, u5, 5_14, 15plus doivent être utilisés de manière cohérente dans tous les indicateurs.

Exemple : Si un ensemble de données utilise u5, 5_14, 15plus, mais qu’un autre utilise under_5, 5to14, 15_and_above, le regroupement et la comparaison entre les tranches d’âge deviennent sujets aux erreurs.
Unités de mesure : Aligner la façon dont les valeurs sont rapportées. La prévalence est-elle rapportée comme 0,1 ou 10 % ? Les taux sont-ils pour 10 000 ou pour 100 000 ? Cela peut affecter les comparaisons et l’analyse ultérieure s’ils ne sont pas harmonisés.

Exemple : Un ensemble de données peut rapporter l’incidence en pourcentage (1,2 %), un autre en décimal (0,012) et un troisième pour 10 000 habitants. Sans harmoniser ces unités, les comparaisons ou les résumés pondérés seront trompeurs.

Investir dans la normalisation dès le départ réduit les frictions en aval, permettant des jointures plus propres, des comparaisons cohérentes et une réutilisation plus facile dans les flux de travail SNT.

3. Doit être autonome

Avec des données ordonnées et normalisées en place, l’étape finale consiste à les rendre autonomes. Cela signifie que tout le contexte nécessaire, étiquettes, définitions, unités et versionnage, est soit intégré soit clairement lié. C’est une petite étape mais cruciale qui rend les données réutilisables, reproductibles et faciles à développer.

Les bonnes pratiques de formatage incluent :

Métadonnées : Chaque variable doit avoir des étiquettes, des unités et des définitions claires. Par exemple, il devrait être évident si une valeur est un compte, un pourcentage ou un taux pour 1 000 personnes.

Les métadonnées ne vivent pas toujours dans l’ensemble de données lui-même, elles peuvent également inclure des notes ou des documents autonomes qui capturent des décisions analytiques importantes. Par exemple, si les taux de rapport ont été calculés différemment pendant la période COVID-19 en raison de perturbations, cela devrait être explicitement noté. Un simple document Word décrivant ces ajustements, par exemple, comment les valeurs d’indicateurs du paludisme ont été imputées ou interprétées différemment en 2020-2021, ajoute un contexte essentiel. Ces décisions moins visibles façonnent la façon dont les données doivent être comprises et comparées, et les documenter garantit la transparence, la reproductibilité et la crédibilité à travers l’équipe et avec les parties prenantes.

Nous pouvons également utiliser des commentaires en ligne dans le code pour expliquer les décisions au moment où elles ont été prises. C’est tout aussi important que les métadonnées autonomes. Cela aide les autres analystes à suivre notre raisonnement et nous rappelle pourquoi quelque chose a été fait des mois plus tard.

Enfin, envisagez de générer automatiquement un dictionnaire de données à la fin du script. Par exemple, écrivez du code qui extrait les noms de variables, les étiquettes et les unités dans un tableau et l’enregistre sous forme de fichier Excel ou de base de données. Ce type de résumé est extrêmement utile pour notre propre référence, pour les transferts et pour partager avec l’équipe SNT.
Dictionnaire de données : Un fichier séparé (ou onglet dans un ensemble de données) qui explique chaque colonne en termes clairs : ce qu’elle signifie, comment elle a été calculée et quelles catégories ou unités sont utilisées. C’est particulièrement important lorsque les ensembles de données sont partagés ou réutilisés par d’autres.

Un dictionnaire de données solide fait plus que décrire les variables. Il documente également les étapes de traitement clés. Par exemple, si confirmed_cases a été imputé dans certains districts, le dictionnaire pourrait noter : “Imputé en utilisant les valeurs moyennes de la même période et du même district.”

Nous pouvons même générer ce dictionnaire automatiquement à la fin du script. Par exemple, écrivez du code qui extrait les noms de variables, les étiquettes et les unités dans un tableau et l’enregistre sous forme de fichier Excel ou de base de données. Ce type de résumé est extrêmement utile pour notre propre référence, pour les transferts et pour partager avec l’équipe SNT.

Il peut également être utile d’inclure des versions traduites du dictionnaire, en particulier lorsque les équipes opèrent dans des contextes multilingues. Si les analystes travaillent en français mais que les parties prenantes préfèrent l’anglais, avoir les deux versions côte à côte rend l’ensemble de données plus accessible. Ceci est simple à générer en utilisant des outils comme le package R gtranslate.
Versionnage cohérent : Les fichiers doivent suivre un format de nommage prévisible (par exemple, gin_dhis2_processed_2018-2024_v2025-03-28.rds) afin que les mises à jour soient traçables et que la confusion soit évitée.

Dans cet exemple, gin fait référence au pays (Guinée), dhis2 est la source de données, processed indique l’état de l’ensemble de données (traité vs. brut), 2018-2024 est la plage de dates couverte par les données, et v2025-03-28 est la date de version indiquant quand le fichier a été créé.

Ensemble, ces étapes rendent nos ensembles de données SNT explicites, suffisamment clairs pour se tenir debout seuls sans qu’il soit nécessaire que quelqu’un nous les explique. Cela réduit les frictions dans la collaboration et rend les pipelines de données plus faciles à déboguer, réutiliser et maintenir.

Structure entre les ensembles de données

Avec les ensembles de données individuels maintenant ordonnés, normalisés et autonomes, l’étape suivante consiste à s’assurer qu’ils peuvent fonctionner ensemble. La structure entre les ensembles de données consiste à construire un système cohérent, où les fichiers sont organisés logiquement, formatés de manière cohérente et prêts à être joints. Cela permet à l’analyse de s’étendre en douceur à travers les domaines, les périodes et les géographies.

À la base, cette étape implique trois éléments principaux :

1. Référentiel organisé Une structure de dossiers bien organisée réduit le temps nécessaire pour trouver les fichiers pertinents, réduit le risque d’erreurs et facilite grandement le transfert de travail ou l’intégration de nouveaux utilisateurs. Comme introduit plus tôt dans la section Structure de dossiers, cette organisation devrait déjà être en place et suivie de manière cohérente.

Les ensembles de données doivent être regroupés thématiquement et ne pas être tous jetés dans un seul dossier. Par exemple, garder les données d’épidémiologie, d’interventions et d’environnement dans des dossiers séparés, chacun avec ses propres sous-dossiers.

Chaque thème doit également suivre une séparation claire entre :

raw/ : fichiers originaux non touchés. Ce sont votre source de vérité et ne doivent jamais être modifiés directement.
processed/ : ensembles de données nettoyés, harmonisés et prêts pour l’analyse.

L’idée derrière cette séparation est qu’elle empêche la confusion sur quel fichier a été modifié, préserve la traçabilité et garantit que les scripts peuvent toujours être réexécutés à partir des mêmes entrées brutes.

Ci-dessous est un exemple de décomposition claire des dossiers pour les ensembles de données de base. Toutes les données DHIS2 brutes doivent être stockées dans le dossier raw/, tandis que les versions nettoyées et prêtes pour l’analyse appartiennent à processed/ :

data/
├── 02_epidemiology/
│   └── 2a_routine_surveillance/
│       ├── raw/
│       └── processed/

Une disposition thématique claire soutient la mise à l’échelle, l’ajout d’un nouveau pays ou indicateur devient plus facile lorsque la structure est prévisible. Cela rend également le transfert et la collaboration moins sujets aux erreurs.

2. Formatage cohérent et prêt à joindre

Beaucoup des principes que nous avons couverts sous Structure au sein d’un ensemble de données, structures de colonnes et de lignes claires, formats de date normalisés, unités administratives harmonisées, sont les plus efficaces lorsqu’ils sont appliqués de manière cohérente dans tous les ensembles de données SNT. C’est ce qu’on entend par formatage cohérent entre les ensembles de données.

Lorsque chaque ensemble de données utilise les mêmes conventions, adm1, adm2, year_month et les noms de variables communs, alors la jointure devient facile. Nous ne perdons plus de temps à corriger des colonnes incompatibles ou à réconcilier des différences de formatage. Nos données sont prêtes pour l’analyse et s’intègrent proprement dans l’étape SNT suivante.

Exemple : Même de petites différences peuvent silencieusement casser les jointures. Si adm2 est orthographié Gaoual dans un fichier mais Gaoal dans un autre, la fusion échouera. Si les dates sont 2023-04 dans l’un et April 2023 dans un autre, l’alignement devient désordonné. Et si un ensemble de données utilise u5 et un autre under_5, nous passerons du temps supplémentaire à corriger les regroupements. Ce sont des problèmes évitables, normaliser tôt évite les frictions plus tard.

Le formatage cohérent transforme nos ensembles de données en blocs de construction interopérables. Cela garantit que chaque ensemble de données parle le même langage, à travers les géographies, les dates, les variables et les groupes. Cela réduit les frictions, augmente la réutilisation et rend notre flux de travail SNT plus facile à mettre à l’échelle ou à transférer. Lorsque le formatage est incohérent, les ensembles de données ordonnés perdent en fiabilité. Appliqués de manière cohérente, ils deviennent réutilisables et robustes dans le pipeline SNT.

Résumé

Établir une configuration propre, de la structure de fichiers aux conventions de codage en passant par le formatage des ensembles de données, est la première et la plus importante étape dans la construction de flux de travail SNT fiables. En fondant notre travail sur ces principes et en restant en coordination étroite avec l’équipe SNT, nous créons un processus qui est techniquement solide et aligné sur les priorités nationales. La bibliothèque de codes SNT offre les outils et la structure pour commencer, mais sa vraie valeur vient lorsqu’elle est adaptée, examinée et itérée dans le contexte. Avec ces fondations en place, nous sommes prêts à commencer à exécuter des flux de travail qui sont reproductibles, évolutifs et prêts pour la prise de décision.