# Note de protection des données — Performance du circuit de référencement en protection

Documentation technique du projet *Performance du circuit de référencement en
protection*. C'est délibérément le **premier** livrable du projet, non une annexe
à l'analyse : ce que l'on ne collecte pas fait partie de la conception, et un jeu
de données de performance assemblé sans ces décisions ne peut pas être sécurisé
après coup.

- **Jeu de données source :** `protection-referrals-2024.v1.csv` (1 850 cas,
  6 zones admin2)
- **Analyse :** `notebooks/referral-pathway.python.fr.ipynb`
- **Décision éclairée :** quelle ligne de service et quelle zone reçoivent une
  capacité supplémentaire, et si l'écart lié au handicap appelle une réponse
  distincte
- **Normes appliquées :** CHS, Sphère, principes de gestion de l'information sur
  les VBG, orientations IASC sur la responsabilité des données

Il s'agit de données de protection et de VBG synthétiques. Aucune personne réelle
n'y est décrite, et ce fichier ne doit jamais servir de modèle pour stocker des
données de cas réelles — la forme sûre de cela est un système de gestion de cas
régi par le consentement.

---

## 1. Limitation de finalité

Ce jeu de données existe pour répondre à une seule question : **où le circuit de
référencement perd-il des personnes ?** Chaque champ est justifié au regard de
cette question, et tout champ qui ne peut pas l'être n'est pas collecté.

La question porte sur le *circuit*, non sur les *personnes*. C'est cette
distinction qui rend un jeu de données sûr possible : mesurer si un référencement
a atteint un service ne requiert aucun détail sur l'incident qui l'a motivé.

**Usages secondaires interdits.** Ce jeu de données ne doit pas servir au suivi de
cas, à la vérification de services, à l'identification de bénéficiaires, ni à
aucune finalité exigeant de localiser une personne. Il ne peut pas les soutenir —
par construction — et une tentative de l'utiliser ainsi signale que le mauvais
jeu de données est employé.

---

## 2. Ce qui est collecté, et pourquoi chaque champ mérite sa place

| Champ | Pourquoi il est nécessaire |
| --- | --- |
| `case_id` | Déduplication et appariement des enregistrements au sein de l'analyse. Non dérivé d'un attribut personnel. |
| `admin2` | Le niveau auquel la capacité est allouée. |
| `service_requested` | La ligne de service, c'est-à-dire ce qu'une décision de capacité finance. |
| `consent_to_refer` | Conditionne le dénominateur (§4). Sans lui, performance et consentement sont confondus. |
| `referral_made` | Le premier nœud du circuit. |
| `referral_accepted` | Le résultat du circuit. |
| `days_to_first_service` | Ponctualité, sur l'horloge propre du circuit (§6). |
| `disability_reported` | Désagrégation d'équité, qui est un engagement CHS. |
| `age_group` | Tranche large uniquement. Suffisante pour l'équité, insuffisante pour identifier. |
| `sex` | Désagrégation d'équité. |

---

## 3. Ce qui n'est délibérément **pas** collecté

| Exclu | Raison |
| --- | --- |
| Noms, initiales, tout identifiant | Jamais nécessaires pour mesurer un circuit. |
| Coordonnées | Idem. Leur présence ferait du fichier un outil de localisation. |
| Texte libre / récit de cas | Le plus grand risque de réidentification des données de protection, et de toute façon jamais analysable à l'échelle. |
| Date de l'incident | Combinée à la localisation, elle identifie. La ponctualité est mesurée depuis le référencement (§6). |
| Localisation en dessous de l'admin2 | Un village, plus une ligne de service, plus une tranche d'âge sont identifiants dans une petite population. |
| Âge exact | La tranche d'âge suffit à l'analyse d'équité. |
| Type d'incident | Non nécessaire pour mesurer l'aboutissement d'un référencement, et parmi les champs les plus sensibles qui existent. |
| Détail sur l'auteur | Ne quitte jamais l'agence de gestion de cas, en aucune circonstance. |

**Selon les principes de gestion de l'information sur les VBG, les champs au
niveau de l'incident ne quittent jamais l'agence de gestion de cas.** Ce jeu de
données se situe en aval de cette frontière, et c'est cette frontière qui rend
son partage avec un cluster possible.

Les exclusions ne sont pas un caviardage appliqué à un extrait plus complet.
**Ce sont des absences au point de collecte.** Un champ collecté puis retiré a
tout de même existé, a été transmis, et se trouve dans une sauvegarde quelque
part ; un champ jamais collecté, non.

---

## 4. Le consentement conditionne le dénominateur

L'aboutissement est mesuré sur les cas ayant **consenti** au référencement.

| | Valeur |
| --- | --- |
| Cas | 1 850 |
| Ayant consenti | 1 638 (88,5 %) |
| Ayant atteint un service | 757 |
| **Aboutissement (conditionné au consentement)** | **46,2 %** |
| Aboutissement si tous les cas sont comptés | 40,9 % |

Les deux chiffres diffèrent de 5,3 points, et le mauvais impute au circuit des
personnes qui ont choisi de ne pas être référées. **Compter un cas sans
consentement comme un échec du circuit fausse à la fois la performance et la
décision de la personne** — le circuit a fait ce qu'il devait lorsque quelqu'un a
refusé.

Le consentement ici est le consentement *au référencement*, recueilli à
l'admission. Ce n'est pas un consentement au partage de données, qui est une
conversation distincte, et cette note ne traite pas le premier comme couvrant le
second.

---

## 5. Suppression des petites cellules

**Seuil : 20 cas.** Toute cellule d'un tableau croisé comptant moins de 20 cas est
laissée vide, ni arrondie ni fusionnée.

**Ce seuil est une décision de protection prise avec l'agence de gestion de cas,
non une préférence de mise en forme.** Il est consigné ici pour ne pas pouvoir
être modifié par la prochaine personne qui éditera le notebook. En protection, une
petite cellule est un risque de divulgation autant qu'un problème statistique :
« 2 cas à Mirebalais, service juridique, 12–17 ans » peut identifier un enfant
pour quiconque travaille dans ce district.

S'applique à : la grille zone × service, et à toute désagrégation ajoutée
ultérieurement. Le notebook calcule les effectifs à côté des moyennes et laisse la
moyenne vide lorsque l'effectif est sous le seuil.

**Ne pas contourner la suppression par agrégation.** Publier une grille supprimée
et un total de ligne permettant de retrouver la cellule supprimée par soustraction
constitue la même divulgation. Là où un total le permettrait, supprimer aussi le
total.

---

## 6. La ponctualité est mesurée depuis le référencement, non depuis l'incident

`days_to_first_service` court du référencement au premier contact avec un
service, parce que le jeu de données ne contient aucune date d'incident et que,
selon les principes de gestion de l'information sur les VBG, il ne doit pas en
contenir.

**La conséquence doit être énoncée dans tout rapport.** Une survivante qui a
atteint un travailleur social tardivement puis un service rapidement apparaît ici
comme rapide. Cette mesure est une propriété du circuit après l'entrée, non du
parcours complet d'une personne vers l'aide.

---

## 7. Contradictions de qualité : signalées, non supprimées

| Contradiction | Cas |
| --- | ---: |
| Délai de service saisi, référencement non abouti | 11 |
| Délai de service saisi, aucun référencement effectué | 6 |
| Abouti, aucun délai de service saisi | 40 |

**En gestion de cas, un enregistrement contradictoire est un problème de saisie à
renvoyer au travailleur social, et le supprimer détruit la seule trace de
l'existence du cas.** La suppression silencieuse est un manquement de protection,
non une étape de nettoyage.

Les 40 référencements aboutis sans délai de service signifient que le
**dénominateur de la ponctualité est plus petit que celui de l'aboutissement**.
Les deux sont rapportés séparément et ne doivent jamais figurer dans un tableau
laissant supposer une base commune.

---

## 8. Désagrégation d'équité

Enregistrer le handicap est un engagement CHS, et l'analyse qu'il permet est le
constat le plus lourd de conséquences du projet.

**Aboutissement selon le handicap**

| Statut | Cas | Aboutis | Aboutissement |
| --- | ---: | ---: | ---: |
| Handicap déclaré | 202 | 62 | 30,7 % |
| Aucun handicap déclaré | 1 436 | 695 | 48,4 % |

**Écart : −17,7 points**, khi-deux p = 3,3 × 10⁻⁶.

**Par ligne de service** — l'écart apparaît sur quatre des cinq. La sécurité et la
sûreté font exception, à environ 35 % de part et d'autre.

| Ligne de service | Sans handicap | Handicap déclaré |
| --- | ---: | ---: |
| Santé | 66,1 % | 32,1 % |
| Juridique | 32,4 % | 21,1 % |
| Soutien aux moyens de subsistance | 23,6 % | 15,8 % |
| Psychosocial | 57,7 % | 38,5 % |
| Sécurité et sûreté | 35,4 % | 35,1 % |

Le fait qu'il ne soit pas concentré sur une seule ligne rend improbable qu'il
s'explique par la composition des services demandés par les personnes en situation
de handicap. **Ce que cela ne dit pas, c'est le mécanisme** — inaccessibilité
physique, circuits supposant la mobilité, ou autre chose — et cela se répond en
interrogeant les travailleurs sociaux, non par ce tableau.

### 8.1 La normalisation de codage qui a rendu l'écart visible

Une zone a saisi le handicap en `Yes`/`No` plutôt qu'en `true`/`false`. Sans
normalisation, la désagrégation éclate en quatre catégories, dont deux issues de
cette seule zone et toutes deux sous le seuil de suppression — **l'écart aurait
donc été invisible**, et le constat le plus important du projet aurait été perdu
par accident de codage.

La table de correspondance est une liste d'autorisation explicite ; tout ce qui
en sort reste manquant, et ces cas sont exclus de l'analyse sur le handicap
plutôt que présumés négatifs. **Un champ handicap manquant n'est pas un « non ».**

---

## 9. Accès, conservation et partage

- **Accès.** L'analyse s'effectue sur l'extrait dépersonnalisé décrit ici.
  Personne n'a besoin du système de gestion de cas pour l'exécuter, et personne ne
  doit s'en voir accorder l'accès à cette fin.
- **Conservation.** L'extrait est conservé pour le cycle de rapportage qu'il
  éclaire. Il n'a aucune valeur de suivi de cas, puisqu'il ne peut délibérément pas
  soutenir un suivi.
- **Partage.** L'extrait peut être partagé avec le cluster protection et le
  sous-cluster VBG aux niveaux d'agrégation de cette note, le §5 étant appliqué.
  Les données au niveau de la ligne ne sont pas partagées hors de l'agence de
  gestion de cas.
- **Publication ultérieure.** Tout chiffre publié à l'extérieur doit avoir passé
  le §5. En cas de doute, agréger davantage ; un chiffre plus grossier mais sûr
  vaut mieux qu'un chiffre précis qui ne l'est pas.

---

## 10. Limites

1. **Les enregistrements de référencement montrent ce que le circuit a fait, non
   ce dont les personnes avaient besoin.** Une ligne de service avec peu de
   référencements peut être une ligne dont personne n'a besoin ou une ligne que
   personne n'offre, et ce jeu de données ne permet pas de distinguer les deux.
2. **Le consentement est enregistré, non expliqué.** Un taux de consentement en
   baisse peut traduire un refus éclairé ou un problème de confiance, et les
   données du circuit ne les distinguent pas.
3. **La métrique d'écart suppose que le manque tient à la capacité, non au
   besoin** (voir le notebook). Elle a la bonne forme pour une décision de
   capacité et la mauvaise pour une évaluation des besoins.
4. **Dépersonnalisation n'est pas anonymisation.** Même avec ces exclusions, une
   population suffisamment petite et une connaissance auxiliaire suffisante
   permettent de réidentifier. Le §5 est le contrôle d'exploitation, et les
   exclusions du §3 sont ce qui maintient le risque résiduel à un niveau
   maîtrisable.

---

## 11. Reproduire cette analyse

```bash
pnpm examples:build
```

Puis exécuter `notebooks/referral-pathway.python.fr.ipynb`. Il requiert pandas,
numpy et scipy et lit le CSV en HTTPS.

Le jeu de données est versionné par nom de fichier et immuable ; une correction
est publiée en `.v2.csv` avec ce document révisé en même temps.

---

## 12. Journal des versions

| Date | Modification |
| --- | --- |
| 27/07/2026 | Première émission, sur le jeu de données v1. |