---
name: ifpb-collection-circuit
description: "IFPB Collection Pipeline - Circuit de recouvrement Zéro-Coulage: notification SMS, paiement dématérialisé, rapprochement Trésor Public"
version: "1.0.0"
tags: [ifpb, recouvrement, paiement, mobile-money, sms, tresor, securite]
---

# IFPB Collection Circuit Skill (Zéro-Coulage)

## Objectif
Implémenter le circuit sécurisé de recouvrement de l'IFTB selon le modèle Zéro-Coulage du Livre Blanc : notification automatique → paiement dématérialisé → rapprochement Trésor.

## Architecture du Flux (4 Étapes)

```
┌─────────────┐    ┌─────────────┐    ┌──────────────┐    ┌──────────────┐
│  ÉTAPE 1    │    │  ÉTAPE 2    │    │   ÉTAPE 3     │    │   ÉTAPE 4    │
│ Notification│───▶│Encaissement │───▶│ Sécurisation  │───▶│ Rapprochement│
│    SMS      │    │  Contribuable│   │  Trésor Public│    │   Quotidien  │
└─────────────┘    └─────────────┘    └──────────────┘    └──────────────┘
```

### Étape 1 — Notification Automatique

**Déclencheur** : Génération du rôle fiscal par le Fiscal Engine

```json
{
  "notification": {
    "canal": "SMS cellulaire",
    "destinataire": "${proprietaire_telephone}",
    "template": "IFPB Mairie [Commune] - Réf: ${reference_parcelle}\nMontant dû: ${montant_total} Ar (IFTB + CAC)\nPayez via Mobile Money ou au guichet Perception.\nCode marchand: ${code_marchand}",
    "expediteur": "IFPB-MAIRIE",
    "automatique": true,
    "retry": {"max": 3, "interval_h": 24}
  }
}
```

**Contenu Avis d'Imposition :**
- Référence Fiscale Unique (Code Parcelle)
- Identité du Contribuable / Adresse du bien / Usage constaté
- Détails du calcul automatique (Surface totale, Valeur Locative, Taux appliqué)
- Montant Principal IFTB + Centimes Additionnels Communaux (10%)
- Procédure de paiement sécurisé

### Étape 2 — Encaissement Dématérialisé

**Canaux autorisés (par ordre de priorité) :**

| Canal | Processus | Avantage |
|-------|-----------|----------|
| **Mobile Money** (MVola/Airtel Money/Orange Money) | Code Marchand Commune | Instantané, traçable |
| **Virement Bancaire** | Compte de Dépôt Trésorerie Principale | Direct, sans intermédiaire |
| **Guichet Perception** | Chèque du Trésor + reçu officiel | Seul canal espèces autorisé |

⚠️ **Règle d'or** : Aucun paiement en espèces en dehors du guichet de la Perception Principale contre reçu officiel.

### Étape 3 — Sécurisation Trésor Public

**Architecture technique :**
```
Compte Marchand Digital (Opérateur)
        │
        ▼ (adossement technique automatique)
Compte de Dépôt Commune ← Trésorerie Principale
        │
        ▼
Fonds intègrent le circuit financier public
        │
        ✅ ZÉRO manipulation intermédiaire d'espèces
```

**Garanties :**
- Les flux comptes marchands sont adossés techniquement au compte de dépôt de la commune auprès du Trésor Public
- Pas d'accès direct aux fonds pour aucun agent ou élu
- Traçabilité complète de chaque transaction

### Étape 4 — Rapprochement Automatisé Quotidien

**Responsable** : Receveur Municipal

**Processus :**
1. Export table de collecte du jour (depuis Kobo/Fiscal Engine)
2. Import relevé compte marchand (depuis banque/opérateur)
3. Appliquer Matrice de Rapprochement Automatisé (tableur)
4. Mettre à jour liste des restes à recouvrer
5. Générer rapport journalier pour le Maire et le SG

**Matrice de Rapprochement :**

| Champ Collecte | Champ Banque | Match ? | Action |
|----------------|--------------|---------|--------|
| reference_parcelle | référence_paiement | ✅ | Marquer PAYÉ |
| montant_attendu | montant_reçu | ✅ = | Confirmer |
| montant_attendu | montant_reçu | ⚠️ ≠ | Flag anomalie |
| reference_parcelle | NULL | ❌ | Ajouter restes à recouvrer |

## Modèle de Données Transaction

```json
{
  "transaction": {
    "id_transaction": "UUID",
    "reference_fiscale": "string",
    "montant_du": float,
    "montant_paye": float,
    "devise": "MGA",
    "date_echeance": "date",
    "date_paiement": "datetime",
    "canal_paiement": "mobile_money|virement_bancaire|guichet",
    "reference_paiement_externe": "string",
    "statut": "emis|notifie|paye_partiel|paye|retard|contentieux",
    "rapprochement": {
      "date_rapprochement": "date",
      "operateur_rapprochement": "string",
      "conforme": bool
    }
  }
}
```

## États du Rôle Fiscal

```
EMIS (génération) → NOTIFIÉ (SMS envoyé) → PAYÉ (rapproché)
                                          ↘ RETARD (>30j) → CONTENTIEUX (>90j)
```

## Gestion des Restes à Recouvrer

| Délai | Action |
|-------|--------|
| J+0 | Émission rôle + SMS notification |
| J+7 | Relance SMS automatique #1 |
| J+15 | Relance SMS automatique #2 + appel téléphonique |
| J+30 | Lettre de mise en demeure signée Receveur |
| J+60 | Visite terrain agent recenseur |
| J+90 | Transmission contentieux (Tribunal administratif) |

## Indicateurs de Performance (KPIs Recouvrement)

| KPI | Formule | Cible |
|-----|---------|-------|
| Taux de notification | SMS envoyés / rôles émis | 100% |
| Taux de recouvrement J30 | Payés J30 / total notifié | > 60% |
| Taux de recouvrement J90 | Payés J90 / total notifié | > 85% |
| Délai moyen paiement | Avg(jours entre notification et paiement) | < 15 jours |
| Taux rapprochement | Transactions rapprochées / totales | 100% |
| Volume coulages détectés | Anomalies rapprochement | 0 (zéro tolérance) |

## Sécurité & Anti-Fraude

1. **Séparation des duties** : Ordonnateur (Maire) ≠ Comptable (Receveur)
2. **Paiement exclusif dématérialisé** : pas d'espèces hors guichet officiel
3. **Traçabilité blockchain-lite** : chaque transaction immuable et horodatée
4. **Audit trail complet** : qui a fait quoi, quand, depuis quel terminal
5. **Alertes automatiques** : toute anomalie de rapprochement notifiée en temps réel

## Intégrations Systèmes

| Système | Rôle | Protocole |
|---------|------|-----------|
| Fiscal Engine | Source des rôles fiscaux | REST API |
| SMS Gateway | Envoi notifications | SMPP / HTTP API |
| Opérateurs Mobile Money | Encaissement | Merchant API |
| Banque (Trésor) | Compte dépôt | EBICS / SWIFT |
| Tableur Rapprochement | Validation Receveur | CSV import/export |