Dans le paysage actuel du développement logiciel pour le secteur fintech, la robustesse du code n’est pas un luxe, mais une exigence de conformité. Lors de la conception d’un CRM destiné à la gestion de dossiers de crédit, l’erreur la plus courante est de confier le cycle de vie du dossier à une série désordonnée de conditions booléennes. Dans ce contexte, la Machine à États Finis (FSM – Finite State Machine) émerge comme l’entité architecturale fondamentale pour garantir que des processus complexes, comme l’octroi d’un prêt immobilier, suivent des parcours déterministes et sécurisés. Cet article explore comment appliquer les principes de l’ingénierie des systèmes pour transformer la logique métier en un moteur de workflow inattaquable, reflétant l’expérience acquise dans le développement de plateformes à haute criticité comme le CRM BOMA.

Le Problème de la « Spaghetti Logic » dans les CRM Financiers

Imaginez devoir gérer un dossier de prêt immobilier. Dans une approche naïve, le développeur pourrait ajouter des colonnes à la base de données comme is_approved, docs_uploaded, contract_signed. Le code résultant pour vérifier si un prêt peut être débloqué ressemblerait à ceci :

if (loan.is_approved && loan.docs_uploaded && !loan.is_rejected) {
  // Débloquer les fonds
}

Cette approche passe à l’échelle de manière désastreuse. Que se passe-t-il si le dossier est suspendu ? Ajoutons-nous un drapeau is_suspended ? Et s’il est rouvert ? La combinaison de N drapeaux booléens crée 2^N états possibles, dont la plupart sont des états incohérents (ex. un dossier simultanément « refusé » et « en attente de signature »). Les machines à états finis résolvent ce problème en réduisant l’univers des possibles à un graphe orienté d’états valides et de transitions explicites.

Qu’est-ce qu’une Machine à États Finis (FSM) ?

Une FSM est un modèle mathématique de calcul. C’est un système abstrait qui peut se trouver exactement dans l’un d’un nombre fini d’états à un moment donné. La FSM change d’état en réponse à des entrées externes ; le passage d’un état à un autre est appelé transition.

Pour un CRM de prêts immobiliers, une FSM est définie par :

• États (S) : {BROUILLON, INSTRUCTION, DÉCISION, SIGNATURE, DÉBLOQUÉ, REFUSÉ, ANNULÉ}
• Événements/Entrées (E) : {ENVOYER_DOCUMENTS, APPROUVER_CRÉDIT, SIGNATURE_CLIENT, VIRER_FONDS}
• Fonction de Transition (δ) : Une règle qui définit : Si je suis dans l’état X et que l’événement Y se produit, je passe à l’état Z.

Modélisation du Workflow de Prêt Immobilier

Au lieu de se demander « quels drapeaux sont actifs ? », nous nous demandons « dans quel état se trouve le dossier ? ». Voici comment modéliser un flux de prêt standard :

1. BROUILLON : Le courtier saisit les données. Le seul événement possible est ENVOYER_EN_INSTRUCTION.
2. INSTRUCTION : La banque analyse les documents. Événements possibles : APPROUVER (mène à DÉCISION) ou REFUSER (mène à REFUSÉ). Il n’est pas possible d’aller directement à DÉBLOQUÉ.
3. DÉCISION : Le crédit est approuvé. Événement : ÉMETTRE_OFFRE.
4. SIGNATURE : Le client doit signer. Événement : ENREGISTRER_SIGNATURE.
5. DÉBLOQUÉ : État final positif.

Diagramme des Transitions (Représentation Logique)

La puissance des machines à états finis réside dans l’interdiction implicite. Si le système reçoit l’événement VIRER_FONDS alors que le dossier est dans l’état INSTRUCTION, la FSM ne doit pas se contenter d’échouer silencieusement : elle doit lancer une exception de Transition Illégale. Cela rend le système déterministe.

Implémentation Technique : Patterns et Code

Pour implémenter une FSM dans une stack backend moderne (ex. Node.js/TypeScript ou Python), nous déconseillons l’utilisation de switch/case géants. Il est préférable d’utiliser le State Pattern ou des bibliothèques dédiées comme XState. Voici un exemple d’implémentation conceptuelle en TypeScript :

type LoanState = 'DRAFT' | 'UNDERWRITING' | 'APPROVED' | 'DISBURSED' | 'REJECTED';

class MortgageFSM {
  private state: LoanState;

  private transitions = {
    DRAFT: { SUBMIT: 'UNDERWRITING' },
    UNDERWRITING: { APPROVE: 'APPROVED', REJECT: 'REJECTED' },
    APPROVED: { DISBURSE: 'DISBURSED', CANCEL: 'REJECTED' },
    DISBURSED: {}, // État terminal
    REJECTED: {}   // État terminal
  };

  constructor(initialState: LoanState) {
    this.state = initialState;
  }

  public transition(event: string): void {
    const nextState = this.transitions[this.state][event];
    
    if (!nextState) {
      throw new Error(`Transition invalide : Impossible d'exécuter ${event} depuis l'état ${this.state}`);
    }

    console.log(`Transition : ${this.state} -> ${nextState}`);
    this.state = nextState;
    this.onStateChange(nextState);
  }

  private onStateChange(newState: LoanState) {
    // Hook pour effets de bord (ex. envoi e-mail, webhooks)
  }
}

Persistance et Base de Données

Au niveau de la base de données (SQL), la représentation la plus efficace n’est pas une série de booléens, mais une colonne unique status indexée, souvent soutenue par un type ENUM pour garantir l’intégrité référentielle.

Cependant, pour des pistes d’audit complexes (requises par la réglementation bancaire), une table séparée loan_state_history est recommandée :

• loan_id (FK)
• previous_state
• new_state
• trigger_event
• timestamp
• user_id (qui a déclenché la transition)

Architecture Orientée Événements et Effets de Bord

L’intégration des machines à états finis avec une architecture événementielle est le moment où le CRM devient proactif. Chaque transition d’état valide doit émettre un Domain Event.

Le Flux Réactif

1. L’utilisateur clique sur « Approuver le dossier » dans le tableau de bord.
2. L’API invoque la FSM : fsm.transition('APPROVE').
3. La FSM valide la logique, met à jour la BDD et, en cas de succès, émet l’événement LoanApprovedEvent sur un message broker (ex. RabbitMQ ou Kafka).
4. Des consommateurs découplés réagissent :
   • Le Notification Service envoie un e-mail au courtier.
   • Le Document Service génère le PDF de la décision.
   • Le Audit Service enregistre l’opération pour la conformité.

Ce découplage empêche la logique d’envoi d’e-mails de « polluer » la logique pure d’approbation du crédit.

Prévention des États Incohérents (Sécurité)

Dans l’expérience de développement de systèmes comme BOMA, nous avons identifié trois règles d’or pour la sécurité des FSM :

1. Atomicité : La transition d’état et la sauvegarde en BDD doivent se produire dans la même transaction de base de données. Si la sauvegarde échoue, l’état en mémoire doit être restauré.
2. Idempotence : Si un système externe envoie deux fois l’événement APPROVE, la FSM doit gérer la seconde tentative avec grâce (en l’ignorant ou en renvoyant l’état actuel), sans créer de doublons ou d’erreurs.
3. Gardes (Guards) : Outre la validité de la transition (A -> B), il est possible d’implémenter des « gardes ». Exemple : « Tu ne peux passer de INSTRUCTION à DÉCISION que si la somme des documents chargés > 5 ». Les gardes ajoutent un niveau de logique conditionnelle contrôlée au sein de la structure rigide de la FSM.

Conclusion

L’adoption des machines à états finis dans le développement de CRM pour prêts immobiliers n’est pas seulement un choix stylistique de code, mais une décision architecturale stratégique. Elle déplace la complexité de la gestion des erreurs vers la phase de conception, obligeant les ingénieurs et les chefs de produit à définir le processus métier avec une précision chirurgicale avant d’écrire une seule ligne de code. Le résultat est un système prévisible, auditable et, surtout, sécurisé pour la gestion d’actifs financiers.

Foire aux questions