Accueil › Documentation fonctionnelle › Revue juridique
Menu du document← Accueil
Documentation fonctionnelle
  1. 01Facturation & comptabilité OHADA
  2. 02Pipeline de la facture
  3. 03Demande de financement
  4. 04Analyse de dossier
  5. 05Offres & conditions structurées
  6. 06Position concurrentielle & fourchettes de marché
  7. 07Contrats, facilité et suivi du financement
  8. 08KYB institution
  9. 09Abonnements institutions
  10. 10Collatéral & assiette
  11. 11Tierce détention
  12. 12Alertes & observabilité métier
  13. 13Établissements partenaires et disponibilité
  14. 14Revue juridique
  15. 15IA embarquée
  16. 16Espace entreprise, appels d'offres et veille
  17. 17CRM, candidatures & contrats de marché
  18. 18Ressources humaines & capacité d'exécution
  19. 19Cautions de marché & crédits d'exécution
  20. 20Dossier bancaire, consentement & instruction
  21. 21Décision bancaire, émission & preuve documentaire
  22. 22Collateral documentaire & limites de vérification
  23. 23Droits d'accès, programme Fondateurs & notifications
  24. 24Données et intégrations : exports universels
  25. 25Applications connectées, API publique, webhooks & MCP
  26. 26Connecteurs ERP & synchronisations
  27. 27API bancaire & Collateral
Autres documents
Documentation fonctionnelle

Revue juridique

Pourquoi

Les règles utilisées pour traiter une sûreté doivent avoir été relues par un juriste habilité avant leur activation. Le module de revue juridique organise les propositions, les corrections, la validation et l'activation de ces règles, en conservant l'identité et l'habilitation de la personne responsable de chaque décision.

Comment dans l'application

Une règle traverse une machine à états à quatre positions : PROPOSEE_A_VALIDER, puis, après validation, VALIDEE_CONSEIL, et enfin, après un second geste distinct, ACTIVEE — seul cet état rend la règle utilisable en production. La distinction entre les deux derniers états est volontaire : le conseil peut dire ce que le droit permet sans que quiconque ait encore décidé de s'en servir, par exemple parce qu'un moteur n'est pas prêt ou qu'une question opérationnelle reste ouverte. Une position de correction (A_CORRIGER) permet de renvoyer une proposition en amont sans la perdre.

Trois habilitations distinctes gouvernent ces gestes : relire, commenter et demander une correction sont ouverts à un réviseur ; verser une proposition dans l'espace de revue est ouvert à un éditeur de règles, qui n'emporte aucun pouvoir de validation ; valider et activer sont tous deux réservés à un approbateur, enregistré nommément avec le cabinet et la source de son habilitation. Chaque correction d'une règle déjà proposée crée une nouvelle version plutôt que d'écraser la précédente — une règle relue six mois plus tard doit pouvoir montrer ce qui avait été soumis et ce que le conseil avait répondu à ce moment-là.

Le référentiel de base couvre vingt-deux régimes de sûretés OHADA, complétés par des surcouches nationales propres à chaque pays ; une cellule non validée ou explicitement marquée indisponible ne peut jamais être utilisée par défaut — toute opération qui la rencontrerait est bloquée et remontée explicitement à un humain, plutôt que de recevoir une valeur par défaut qui produirait une sûreté silencieusement nulle.

Garde-fous

  • Déposer une proposition et la valider nécessitent des habilitations distinctes : un éditeur peut préparer la revue sans disposer du pouvoir d'approuver la règle.
  • Seules les règles validées puis activées pour le pays et le régime concernés peuvent être appliquées au dossier.
  • Une valeur par défaut erronée serait pire qu'un blocage : un blocage coûte un appel téléphonique, une sûreté nulle coûte le principal du financement.