PRD V1 consolidé et enrichi¶

Plateforme de renouvellement assisté pour courtiers et assureurs¶

Version 1.1 – Cadrage fonctionnel, métier, conformité, sécurité et exploitation terrain¶

1. Objet du document¶

Ce document définit le périmètre consolidé et enrichi de la V1 de Papillon Collection Software : une plateforme de renouvellement assisté destinée aux courtiers, réseaux structurés et, à terme, aux compagnies d’assurance. La V1 vise prioritairement les petits cabinets et certains cabinets de taille intermédiaire, avec :
- un mode d’intégration simple fondé sur l’import de fichiers normalisés, - une supervision opérateur forte, - un parcours client léger, - un encaissement marchand officiel - et un fonctionnement réaliste dans des contextes de connectivité imparfaite.

Le document couvre : - le problème métier ; - la proposition de valeur ; - les utilisateurs cibles ; - le périmètre fonctionnel de la V1 ; - les règles métier ; - les exigences de conformité et de sécurité ; - les contraintes techniques ; - les indicateurs de succès ; - les dépendances et les exclusions explicites de la V1.

2. Contexte¶

Dans de nombreux cabinets de courtage et agences d’assurance, le renouvellement des contrats reste largement manuel : - appels téléphoniques, - messages WhatsApp, - transmission de documents par messagerie, - paiement sur numéro mobile money personnel d’un agent, - voire déplacement du client à l’agence.

Ce fonctionnement entraîne une faible traçabilité, une productivité limitée, une expérience client médiocre et des risques en matière de données, de preuve et d’encaissement.

Le contexte réglementaire s’est structuré avec le Règlement CIMA 01-24 sur la distribution et la gestion du contrat d’assurance par voie numérique, qui encadre les activités numériques des assureurs et intermédiaires, et avec la loi ivoirienne n°2013-450 sur la protection des données personnelles, qui impose des obligations fortes sur les traitements, les formalités et la sécurité.

3. Problème à résoudre¶

La V1 doit répondre à ce problème central :

Comment permettre à un cabinet ou une agence de détecter les contrats proches de l’échéance, de contacter les clients à distance, de leur permettre de renouveler et de payer simplement, puis de suivre les statuts sans dépendre d’un ERP avancé ni de processus manuels dispersés ?

Ce problème se décompose en six sous-problèmes : - absence de détection automatique fiable des contrats à renouveler ; - absence de processus unifié de relance ; - absence de lien sécurisé entre notification et action client ; - absence de paiement marchand intégré ; - manque de visibilité pour l’opérateur sur les paiements et les échecs ; - manque de traçabilité et d’encadrement conformité.

4. Vision produit¶

Le produit est une plateforme de renouvellement assisté qui se branche au-dessus des systèmes existants. Il ne s’agit pas d’un ERP complet, mais d’une couche d’orchestration métier située entre les données issues du cabinet, les canaux de communication, le portail client et le module de paiement.

Le flux cœur est le suivant : 1. ingestion de données clients et contrats ; 2. sélection des contrats arrivant à échéance ; 3. validation opérateur ; 4. envoi de notifications ; 5. authentification légère côté client ; 6. consultation des contrats à renouveler ; 7. paiement via un canal marchand officiel ; 8. suivi, relance et traitement des exceptions.

5. Objectifs V1¶

Objectifs métier¶

Réduire fortement les relances manuelles par téléphone et WhatsApp libre.
Réduire les déplacements clients pour les renouvellements simples.
Offrir une visibilité opérationnelle sur les échéances, envois, paiements et échecs.
Permettre un encaissement structuré via un canal marchand officiel.

Objectifs produit¶

Offrir un parcours utilisable par un petit cabinet sans API ERP.
Permettre une mise en service pilote en quelques jours.
Créer un socle technique extensible vers une V2 multi-agence et API.

Objectifs conformité¶

Positionner la plateforme comme prestataire technique opérant pour des courtiers et assureurs, et non comme distributeur d’assurance autonome.
Encadrer les traitements de données personnelles conformément à la loi ivoirienne applicable.
Prévoir des traces suffisantes pour la preuve, l’audit et le rapprochement des paiements.

6. Non-objectifs V1¶

La V1 NE cherche PAS à : - remplacer l’ERP de l’assureur ou du courtier ; - gérer l’intégralité du cycle de vie du contrat ; - supporter dès le départ tous les types de produits d'assurance complexes ; - fournir une signature électronique avancée ou qualifiée ; - gérer des workflows complexes de souscription complète ; - proposer, dès V1, des connecteurs ERP multiples sur mesure ; - supporter un mode offline transactionnel complet ; - servir immédiatement toutes les compagnies comme solution enterprise.

7. Utilisateurs cibles¶

Admin cabinet¶

Responsable du paramétrage, de la supervision générale, des imports, des règles et des utilisateurs.

Opérateur agence¶

Utilisateur métier quotidien. Il vérifie les listes, corrige les anomalies, valide les envois, suit les paiements et les échecs.

Superviseur / direction¶

Consulte les tableaux de bord, les statuts et les résultats des campagnes.

Client final assuré¶

Reçoit une notification, confirme son identité, voit ses contrats, choisit ce qu’il renouvelle et paie.

Partenaires externes¶

Prestataires de paiement, éventuellement prestataires de messagerie, et plus tard fournisseurs de données ou d’ERP.

8. Segment et cas d’usage prioritaire V1¶

Segment prioritaire¶

Petits cabinets de courtage, puis cabinets intermédiaires.

Cas d’usage prioritaire¶

Renouvellement à distance de contrats récurrents et relativement standards, avec peu de modifications structurelles entre deux périodes.

Pourquoi ce choix¶

Ce segment a une forte douleur, peu d’outillage et accepte plus facilement un mode d’intégration simple par Excel/CSV. Cela permet de valider rapidement la valeur du produit avant d’aller vers les réseaux structurés et les compagnies.

9. Proposition de valeur V1¶

Pour le cabinet : - plus de dossiers renouvelés ; - moins de relances manuelles ; - meilleure visibilité sur les échéances et les paiements ; - moins de dépendance aux pratiques informelles.

Pour le client final : - moins de déplacement ; - parcours simple ; - possibilité de payer à distance via un canal officiel.

Pour les partenaires : - architecture extensible et marché vertical concret, dans un cadre compatible avec la numérisation croissante des flux d’assurance et de paiement.

10. Principes de conception V1¶

Small broker first : la V1 doit fonctionner avec un simple export de fichier.
Human-in-the-loop : l’envoi ne part pas automatiquement sans validation humaine.
Compliance by design : la conformité et la sécurité ne sont pas ajoutées à la fin.
Data quality first : la qualité des données est un problème central du produit.
Official payment only : pas d’encaissement sur compte personnel d’agent.
Traceability first : toute action importante doit être journalisée.
Mobile-first côté client : le portail client est pensé d’abord pour des smartphones Android d’entrée de gamme.
Low-bandwidth and resumable by design : le parcours client doit rester utilisable sur réseau dégradé, avec reprise de session et de paiement dans la fenêtre de validité du lien (24h à 72h).

11. Périmètre fonctionnel V1¶

11.1. Gestion et ingestion de données¶

Import manuel Excel/CSV.
Modèle de fichier imposé.
Contrôles de format et de cohérence.
Journal d’import.
Détection d’anomalies bloquantes et non bloquantes.
Déduplication des dossiers.

11.2. Détection des renouvellements¶

Paramètre X jours avant échéance.
Planification de la sélection au moins 2 fois par semaine.
Génération d’une liste de dossiers candidats.
Déduplication en cas d’imports multiples.

11.3. Console opérateur¶

Vue “liste de tâches”.
Filtres par agence, date, produit, statut.
Vérification et correction de certains champs.
Validation d’envoi par lot ou individuellement.
Historique des actions.

11.4. Notifications¶

Envoi WhatsApp ou SMS selon disponibilité.
Templates paramétrables.
Liens signés sécurisés à durée limitée.
Historique d’envoi.
Statut d’échec.

11.5. Portail client¶

Accès sans mot de passe permanent.
Identification légère : lien + date de naissance.
Vue des contrats à renouveler.
Sélection partielle ou totale, selon règles.
Récapitulatif avant paiement.
Mise en page mobile-first à partir de 360px de largeur.
Pages légères et tolérantes aux réseaux lents.
Session "reprenable" après perte de connexion.

11.6. Paiement¶

Paiement via compte marchand officiel ou API de paiement web/mobile money.
Génération d’une référence transactionnelle.
Retour de statut.
Rapprochement paiement ↔ contrat(s).

11.7. Suivi et relances¶

Vue des dossiers payés, non payés, échoués.
Relances automatiques hebdomadaires, paramétrables.
Mise en évidence des dossiers à moins de 7 jours.
File des échecs à retraiter.

12. Sources de données V1¶

Source primaire V1¶

Import Excel/CSV normalisé.

Source complémentaire V1¶

Correction manuelle assistée dans un périmètre limité.

Troisième source opérationnelle : atelier de correction pré-campagne¶

Même avec un import structuré, certains dossiers seront incomplets ou imparfaits : - téléphone invalide, - date de naissance absente, - montant incohérent, - doublon, - contrat déjà traité, - agence mal renseignée. La V1 doit donc intégrer un mini-atelier de correction manuelle assistée permettant à l’opérateur de compléter ou - corriger un sous-ensemble de champs avant validation de campagne, sans transformer le produit en ERP de saisie générale.

Ce flux est essentiel pour la réalité terrain : il permet de récupérer de la valeur malgré des données imparfaites, tout en imposant une barrière de contrôle humain avant envoi.

Justification¶

Les APIs ERP existent parfois, mais leur disponibilité n’est pas garantie. Le mode fichier permet un démarrage commercial plus rapide et convient mieux au segment prioritaire ; l’atelier de correction limite l’impact de la mauvaise qualité des exports.

13. Données attendues à l’import¶

Données minimales obligatoires¶

identifiant client source ;
nom/prénom ou raison sociale ;
numéro de téléphone principal ;
date de naissance ou donnée d’authentification choisie ;
identifiant contrat ;
type de contrat / branche ;
date d’expiration / échéance ;
montant à payer ;
agence / cabinet de rattachement.

Données souhaitables¶

email ;
numéro de police ;
immatriculation / référence métier ;
devise ;
statut contractuel source ;
informations additionnelles nécessaires au message.

Champs calculés par la plateforme¶

statut d’éligibilité ;
statut de notification ;
statut de session client ;
statut de paiement ;
score d’anomalie ;
urgence opérationnelle.

14. Parcours métier V1¶

14.1. Parcours opérateur¶

Importer un fichier.
Corriger les erreurs de format détectées.
Lancer ou attendre la sélection des dossiers proches d’échéance.
Ouvrir la liste des tâches.
Examiner les anomalies.
Traiter l’atelier de correction pré-campagne si nécessaire.
Valider l’envoi.
Suivre les statuts d’envoi.
Consulter les paiements.
Traiter les échecs et relances.
Signaler les dossiers non résolus ou critiques.

14.2. Parcours client¶

Recevoir un message.
Cliquer sur le lien.
Vérifier son identité.
Consulter les contrats concernés.
Choisir quoi renouveler.
Voir le total à payer.
Effectuer le paiement.
Recevoir une confirmation.

15. Règles métier V1¶

15.1. Sélection des contrats¶

Un contrat entre dans la file si sa date d’échéance est dans X jours.
X est configurable au niveau cabinet.
Un contrat déjà payé ou déjà marqué comme traité ne doit pas revenir dans la même campagne, sauf relance explicitement autorisée.

15.2. Campagnes¶

Les campagnes peuvent être générées automatiquement, mais doivent être validées manuellement avant envoi.
Une campagne garde une trace de sa date, de son opérateur, de son lot et de ses paramètres.

15.3. Authentification client – gradation des niveaux de sécurité¶

La V1 doit formaliser une logique de sécurité progressive, afin de permettre un parcours simple sans perdre la capacité d’augmenter le niveau de confiance selon le risque.

Niveau	Mécanisme	Usage recommandé	Statut V1
Niveau 1	Lien signé + date de naissance	Cas standard, faible friction	Inclus en V1
Niveau 2	Lien signé + date de naissance + OTP SMS/WhatsApp	Cas sensibles, montants plus élevés, clients à risque	Prévu pour extension proche
Niveau 3	Question/réponse secrète ou mécanisme complémentaire de secours	Cas exceptionnels, secours si OTP indisponible	Hors périmètre standard V1

Le niveau 1 constitue le schéma minimal de la V1. Le nombre de tentatives doit être limité, le lien doit avoir une durée de validité limitée, et tout échec répété doit faire basculer le dossier en exception.

15.4. Paiement¶

Le client peut payer tout ou partie uniquement si le paramétrage du produit l’autorise.
Une transaction doit toujours porter une référence unique.
Un paiement confirmé doit mettre à jour le statut du dossier.
Un paiement incertain doit rester en état intermédiaire jusqu’à résolution.

15.5. Relances¶

Une relance hebdomadaire peut être activée.
Les dossiers proches de l’échéance doivent être mis en évidence.
Un dossier en anomalie critique ne doit pas être relancé automatiquement sans validation.

16. Exigences de conformité¶

16.1. Positionnement réglementaire¶

La plateforme doit être présentée et documentée comme un prestataire de services techniques agissant pour le compte d’assureurs et d’intermédiaires, conformément à la logique du règlement CIMA 01-24,
et non comme un acteur autonome de distribution d’assurance.

16.2. Contrat numérique et information¶

Le règlement CIMA 01-24 impose que le contrat d’assurance distribué ou géré par voie numérique reste conforme au Code CIMA et qu’il comporte des informations spécifiques sur les usages, plafonds, responsabilités, risques, modalités de contestation et d’opposition.

La V1 doit donc : - prévoir des écrans ou documents permettant d’exposer les informations nécessaires ; - prévoir l’archivage des preuves de consultation ou d’acceptation dans la mesure du possible ; - permettre aux assureurs/courtiers de personnaliser les textes requis.

16.3. Données personnelles¶

La V1 doit être compatible avec la loi ivoirienne n°2013-450, qui encadre les traitements de données personnelles, les formalités et les mesures de protection.

Conséquences : - cartographie des traitements ; - contrat de sous-traitance avec les clients B2B ; - minimisation des données ; - gestion des durées de conservation ; - mécanisme de journalisation ; - documentation pour les formalités et la mise en conformité ARTCI.

16.4. Paiement¶

Les paiements doivent être opérés via des comptes marchands officiels et des APIs ou services prévus pour les entreprises. La V1 exclut tout mécanisme de paiement sur numéro personnel d’employé.

16.5. Preuve¶

Le produit doit conserver des traces suffisantes pour : - prouver l’envoi d’un message ; - prouver l’accès au portail ; - prouver le paiement ; - reconstituer la chronologie événementielle d'un cycle de renouvellement (notification → authentification → paiement) à partir du journal d'audit.

17. Exigences de sécurité¶

Authentification opérateur ( agence d'assurance ou courtier)¶

Compte nominatif obligatoire.
Mots de passe robustes.
Journalisation des connexions.
Déconnexion automatique après inactivité.

Contrôle d’accès¶

Rôles distincts : admin, opérateur, lecture.
Cloisonnement par cabinet/agence.
Accès au strict nécessaire.

Sécurité des données¶

Chiffrement en transit.
Chiffrement au repos si possible sur les données sensibles.
Limitation des données visibles dans l’interface.
Pas d’exposition inutile des dates de naissance complètes si un masquage partiel est possible dans certaines vues.

Sécurité du portail client¶

Lien signé.
Durée de vie limitée.
Limitation des tentatives.
Anti-rejeu.
Journaux des accès.

Sécurité paiement¶

Vérification des statuts via API/webhook.
Références transactionnelles uniques.
Vérification de l’intégrité des retours.

Sécurité opérationnelle¶

Sauvegardes.
Journalisation centralisée.
Alertes minimales sur erreurs critiques.
Procédure d’incident.

18. Exigences de journalisation et audit¶

Chaque événement suivant doit être journalisé : - import de fichier ; - détection d’erreur d’import ; - validation de campagne ; - envoi de notification ; - échec de notification ; - ouverture de lien ; - tentative d’authentification ; - succès ou échec d’authentification ; - déclenchement de paiement ; - confirmation ou échec de paiement ; - modification manuelle d’un dossier ; - changement de paramètre.

Les journaux doivent comporter au minimum : - identifiant de l’événement ; - horodatage ; - utilisateur ou système initiateur ; - dossier concerné ; - résultat.

19. Gestion des anomalies¶

Typologie minimale¶

téléphone manquant ou invalide ;
date de naissance absente ;
contrat sans montant ;
contrat déjà expiré ;
doublon ;
paiement en statut incohérent ;
retour de paiement impossible à rapprocher ;
trop d’échecs d’authentification.

Classification opérationnelle des anomalies¶

Type d’anomalie	Effet	Exemple
Anomalie bloquante	Empêche l’envoi ou la poursuite du flux	Téléphone absent, montant absent, identité insuffisante
Anomalie non bloquante	Permet l’envoi avec avertissement opérateur	Email absent, donnée secondaire manquante
Anomalie de surveillance	N’empêche pas l’action mais déclenche suivi	Paiement en attente prolongée, échec de callback

Règles¶

Une anomalie bloquante bloque l’envoi ;
Une anomalie non bloquante peut permettre l’envoi avec avertissement ;
Une anomalie de surveillance doit remonter dans une file spécifique de contrôle ( = un écran back-office - Vue des anomalies).
Toutes les anomalies doivent être visibles dans une file dédiée.

20. Fonctionnalités hors connexion V1¶

La V1 ne doit pas promettre une exploitation complète hors connexion, mais elle peut prévoir un socle minimal : - consultation de la dernière liste synchronisée ; - prise de notes locale ; - préparation de commentaires ou corrections à resynchroniser ; - consultation de scripts d’appel et d’informations statiques.

Ne doivent PAS être supportés hors connexion : - l’envoi effectif de messages, - la validation finale d’une campagne, - la confirmation définitive d’un paiement - un changement irréversible de statut de contrat.

21. Interfaces et écrans V1¶

Back-office¶

Connexion.
Tableau de bord.
Import de fichier.
Résultat d’import.
Liste des tâches / contrats à échéance.
Détail dossier client.
Atelier de correction pré-campagne.
Validation d’envoi.
Historique des notifications.
Vue des paiements.
Vue des anomalies.
Paramètres cabinet.
Gestion utilisateurs.

Portail client¶

Page d’accès sécurisée.
Vérification identité.
Liste des contrats éligibles.
Récapitulatif de paiement.
Retour succès / échec / en attente.

22. KPI de succès V1¶

KPI métier¶

taux de dossiers contactés ;
taux de dossiers consultés ;
taux de conversion paiement ;
délai moyen entre envoi et paiement ;
nombre de dossiers évitant un déplacement en agence.

KPI qualité¶

taux d’erreur d’import ;
taux de numéros invalides ;
taux d’échec de paiement ;
taux d’échec d’authentification ;
taux de dossiers non rapprochés.

KPI produit¶

temps d’onboarding d’un cabinet ;
temps moyen de traitement d’une campagne ;
satisfaction des opérateurs pilotes.

23. Hypothèses à valider en pilote¶

Les cabinets savent exporter un fichier exploitable avec un minimum d’adaptation.
Les clients acceptent un parcours sans mot de passe, fondé sur lien sécurisé + donnée personnelle simple.
Le paiement via compte marchand officiel réduit réellement les encaissements informels.
Les opérateurs préfèrent une validation humaine avant envoi à une automatisation complète.
Les branches ciblées sont suffisamment homogènes pour une V1 simple.

24. Dépendances externes¶

Prestataire de paiement / API marchande.
Canal SMS.
Canal WhatsApp ou équivalent.
Partenaires pilotes disposés à fournir des exports réels.
Appui juridique pour validation finale du montage réglementaire.

25. Risques V1¶

Risques produit¶

qualité de données insuffisante ;
trop de cas particuliers métier ;
faible taux de transformation client si le parcours est trop lourd.

Risques conformité¶

traitement de données non suffisamment cadré ;
documentation réglementaire insuffisante ;
ambiguïté sur la valeur probatoire du parcours numérique.

Risques techniques¶

intégration paiement plus complexe que prévu ;
qualité variable des exports ;
dépendance aux prestataires de messagerie.

Risques go-to-market¶

petits cabinets très intéressés mais à faible budget ;
besoin d’accompagnement fort lors des premiers déploiements.

26. Décisions produit à figer avant build¶

Avant de lancer le développement, les points suivants doivent être arbitrés : - quelles branches ou produits sont inclus en pilote ; - le niveau exact d’authentification client de la V1 ; - les canaux de notification inclus dès V1 ; - le ou les prestataires de paiement retenus ; - le format officiel du fichier d’import ; - les textes et mentions juridiques minimaux du portail ; - la politique de conservation des logs et données.

27. Recommandation d’architecture fonctionnelle¶

La V1 doit être construite autour des objets métier suivants : - Cabinet, - Agence, - Utilisateur, - Client, - Contrat, - Échéance, - Campagne - Notification - Session client - Paiement - Anomalie - Journal d’audit.

Cette modélisation est suffisante pour lancer une V1 sans figer trop tôt des abstractions enterprise inutiles.

28. Plan de livraison recommandé¶

La V1 est livrée par tranches verticales successives (vertical slices), chacune apportant une fonctionnalité complète et utilisable de bout en bout.
Il n'existe pas de sprint "infrastructure" ou "modèle de données" isolé. Chaque table, chaque endpoint et chaque écran est livré avec la story qui en a le premier besoin.

Le découpage détaillé est délégué au workflow de développement assisté (AI_Development_Workflow.md) :

la session ANALYST produit un PRD par module (docs/prd/<module>-prd.md), en cohérence avec le présent document V1 ;
la session ARCHITECT décompose chaque module en slices verticales et précise les dépendances inter-modules ;
la session PRODUCT_OWNER produit les story files auto-portants, ordonnancés par valeur métier et dépendances techniques. Le présent §28 ne fixe pas d'ordonnancement de livraison — cet ordonnancement est une décision de la session ANALYST.

Ordre de priorité métier indicatif¶

(à affiner par l'ANALYST)

Ingestion de données — import, validation, atelier de correction
Détection des renouvellements + console opérateur (liste des tâches)
Notifications — envoi WhatsApp/SMS + génération du lien signé
Portail client — authentification + vue contrats
Paiement + rapprochement
Suivi, relances, gestion des anomalies

29. Annexe – stratégie tarifaire V1/V2/V3¶

La logique tarifaire recommandée doit rester simple en V1, lisible pour les petits cabinets et extensible vers les segments plus structurés. Pour les nouveaux produits B2B, une logique de paliers par segment et métrique d’usage est plus robuste qu’un prix unique ou qu’une commission opaque.

Principes de pricing¶

Aligner le prix sur la valeur créée, donc principalement sur les contrats de renouvellement traités plutôt que seulement sur le nombre d’utilisateurs.
Garder une lecture très simple pour les petits cabinets.
Faire payer explicitement l’intégration, le multi-agence et la gouvernance plus avancée dans les versions supérieures.
Éviter en V1 un pourcentage direct sur la prime, qui pourrait brouiller la perception du service et compliquer le positionnement.

Structure recommandée¶

Offre	Cible	Modèle tarifaire recommandé
Starter	Petits cabinets	Abonnement fixe + plafond d’usage raisonnable
Growth	Réseaux structurés	Abonnement + variable d’usage par volume traité
Enterprise	Compagnies	Minimum annuel + contrat sur mesure + options

Mécanique proposée¶

Métrique principale : nombre de contrats de renouvellement traités par mois.
Métrique secondaire : éventuellement seuil de notifications pour protéger les coûts variables.
Frais d’onboarding : recommandés dès que le projet inclut paramétrage, formation, nettoyage de données ou intégration spécifique.

Cette annexe ne fixe pas encore des montants, mais verrouille la logique de monétisation et évite d’oublier ce chantier dans la suite du projet.

30. Stratégie connectivité, mobile-first et faible bande passante¶

30.1. Contexte terrain¶

La plateforme est déployée en Côte d’Ivoire et, potentiellement, dans l’espace CIMA, où une large part des assurés accède à Internet principalement via des smartphones Android d’entrée de gamme, où la donnée mobile peut être coûteuse, où la 3G reste dominante hors des grands centres, et où les agences subissent régulièrement des coupures ou instabilités de connexion.

La V1 doit être conçue avec ces contraintes comme des exigences de premier rang, et non comme des détails d’optimisation tardive.

30.2. Côté client – faible bande passante et reprise de session¶

Mobile-first : chaque écran client est conçu d’abord pour 360–414 px en portrait.
Payload léger : cible < 200 KB gzip au rendu initial du portail client ; les ressources non critiques sont différées.
Cache agressif sur les ressources statiques : TTL longs et noms de fichiers versionnés.
Tolérance aux réseaux lents : délais de timeout explicites et retry sur les lectures idempotentes.
Liens signés reprenables : la fenêtre de validité doit couvrir au moins 48–72 heures pour absorber les coupures prolongées.
Paiement reprenable : un paiement démarré mais dont le retour n’est pas connu doit être réconciliable par webhook et vérification de statut, sans double débit.
Dégradation gracieuse : le portail doit signaler clairement l’état hors connexion et ne jamais perdre silencieusement la sélection du client.
SMS comme canal de secours : si WhatsApp ou la donnée mobile échoue, le même lien signé doit pouvoir être délivré par SMS.

30.3. Côté opérateur – offline minimal¶

Le back-office est desktop-first et online-first. Le minimum offline autorisé reste : consultation de la dernière liste synchronisée, notes locales, préparation de corrections. La validation de campagne, la confirmation de paiement et les actions irréversibles restent hors périmètre offline en V1.

30.4. Non-objectifs explicites de connectivité V1¶

Pas d’application mobile native.
Pas de moteur offline-first complet avec IndexedDB et résolution de conflits.
Pas d’USSD ou de mécanisme de paiement alternatif hors des parcours standards en V1.

30.5. Signaux d’acceptation¶

La stratégie connectivité est considérée comme satisfaisante en V1 si : - le portail client reste utilisable sur un profil réseau lent ; - un client qui perd la connexion peut reprendre son parcours via le même lien sans tout ressaisir ; - un paiement au retour incertain peut être réconcilié sans double débit ; - les opérateurs peuvent préparer ou relire leur travail pendant une courte coupure sans perte locale de notes.

31. Conclusion opérationnelle¶

La V1 doit être conçue comme un produit simple à déployer mais rigoureux dans son exécution. Sa réussite dépendra moins d’un empilement de fonctionnalités que de six fondations : qualité de l’ingestion des données, atelier de correction pré-campagne, clarté de la console opérateur, intégration d’un paiement marchand officiel, robustesse du parcours mobile en réseau dégradé, et socle sérieux de conformité, sécurité, journalisation et preuve.