Éprouver le moteur sur données réelles (Vague D)

🎯 À retenir

Confronter le passif calculé par le moteur à une référence externe réelle (attestation d'un cabinet, provision comptabilisée), sur une population réelle anonymisée — l'aboutissement de la campagne de validation. Insight : comparer à une attestation est exactement un scénario green (valeur attendue = valeur attestée, tol = écart méthodologique). Aucun mécanisme nouveau ; le corpus existant suffit.

L'insight de cadrage : comparer à une attestation est exactement un scénario green — la valeur attendue est la valeur attestée, et la tolérance encode l'écart méthodologique acceptable. Aucun mécanisme nouveau ; le corpus existant suffit.

1. Anonymiser la photo

Le moteur n'a besoin que de : matricule, age, anciennete, salaire, sexe[, entreprise].

• Retirer tout identifiant direct (nom, prénom, n° de sécurité sociale…).
• Pseudonymiser le matricule (un code stable mais non ré-identifiant).
• Conserver age, anciennete (années), salaire (FCFA mensuel), sexe (H/F), entreprise (filiale, si groupe).
• Déposer le CSV dans validation/datasets/reel/ — gitignoré (jamais committé, même anonymisé : confidentialité). Voir le README de ce répertoire.

⚠️ Piège — filtrer avant tout

Le garde-fou d'ingestion (ingestion.valider) détecte au passage les aberrations de saisie (âge hors plage, salaire nul, ancienneté incohérente, matricule dupliqué). Le scénario ingestion-qualite-aberrante en est le test ; passer la vraie photo par ce filtre est la première chose à faire.

2. Transcrire les hypothèses de l'attestation

Dans le bloc hypotheses du scénario, reporter exactement les hypothèses qui ont produit l'attestation : taux_actualisation, taux_revalorisation_salaire, age_retraite, table_mortalite (CIMA H/F, genre_mixte si mixte), grille_ifc, date_evaluation, et le cas échéant payer_deces/payer_depart (multi-décréments).

Si une hypothèse de l'attestation ne se transcrit pas telle quelle (méthode d'attribution différente, table non embarquée), le noter : c'est une source d'écart attendue, à refléter dans la tolérance ou à investiguer.

3. Choisir la référence

• Une attestation existe (DBO/provision d'un cabinet, provision comptabilisée) → scénario green : expected.dbo_totale.value = la valeur attestée, tol = l'écart méthodologique accepté (négocié avec l'actuaire ; documenté dans la description).
• Aucune attestation → run diagnostique : geler la valeur obtenue comme golden-master de non-régression, et la faire valider par un actuaire avant de la considérer comme référence.

Voir le gabarit travaillé reel-exemple-attestation.green.yaml (exemple synthétique, committé) à copier.

4. Lancer et lire l'écart

backend/.venv/bin/python validation/runner.py <id-du-scenario>

• ✅ Conforme : le moteur reproduit l'attestation dans la tolérance. Le passif est éprouvé sur ce cas réel.
• ❌ Écart hors tolérance : ouvrir une investigation avant de toucher au moteur.

⚠️ Piège — l'écart n'est pas forcément un bug

Avant de modifier le moteur, qualifier l'écart : différence d'hypothèse (taux, table) ? de méthode d'attribution (A1/A2/A2′) ? de périmètre (qui est inclus) ? L'écart est une information — le tracer, le qualifier, puis décider (corriger le moteur, ou documenter la divergence méthodologique légitime).

Confidentialité

validation/datasets/reel/ n'est jamais committé. Le scénario (hypothèses + valeur attestée, sans population nominative) peut l'être si le client l'autorise — il ne ré-identifie personne.