Signature électronique d’un mandat de vente, directement depuis un bloc

Faut-il rediriger un client vers une page tierce pour signer un mandat, ou l’inviter à le faire sans quitter le site de l’agence ? Une agence immobilière indépendante de taille moyenne voulait proposer à ses vendeurs de signer leur mandat de vente directement depuis l’espace client de son site WordPress, plutôt que de recevoir un e-mail externe renvoyant vers l’interface d’un prestataire de signature électronique.

Le point de départ technique était clair dès le cahier des charges : ce bloc ne devait jamais se substituer au prestataire de signature électronique sur le plan juridique — la valeur légale de la signature reste entièrement de la responsabilité de ce service tiers, certifié pour ce type d’usage. Le rôle du bloc se limite à orchestrer l’envoi du document et à refléter son statut, sans jamais recréer un mécanisme de signature maison.

Architecture générale du dispositif

Bloc "agence/signature-mandat"
├── Édition : sélection du modèle de mandat, du champ CPT "mandat_vente"
├── Rendu front : bouton "Signer le mandat" si statut = en_attente
├── Action : appel API REST vers le prestataire de signature
│     └── Envoi du PDF généré + coordonnées du signataire
├── Webhook entrant : /wp-json/agence/v1/statut-signature
│     └── Met à jour le meta "statut_signature" du mandat
└── Affichage conditionnel selon le statut courant

Cette architecture confie deux responsabilités bien distinctes à deux systèmes différents : WordPress orchestre et affiche, le prestataire de signature signe et fait foi. Aucune donnée de signature (image manuscrite, certificat, horodatage qualifié) ne transite ni ne se stocke sur le serveur WordPress.

Générer le document et déclencher l’envoi

Le clic sur le bouton déclenche un appel REST personnalisé, qui génère d’abord le PDF du mandat à partir des attributs du CPT mandat_vente, puis le transmet à l’API du prestataire :

register_rest_route( 'agence/v1', '/envoyer-mandat/(?P<id>\d+)', array(
    'methods'             => 'POST',
    'callback'            => 'agence_envoyer_mandat_signature',
    'permission_callback' => function( $request ) {
        return is_user_logged_in() && agence_utilisateur_proprietaire_mandat( $request['id'] );
    },
) );

function agence_envoyer_mandat_signature( $request ) {
    $mandat_id = (int) $request['id'];
    $pdf       = agence_generer_pdf_mandat( $mandat_id );

    $reponse = wp_remote_post( 'https://api.prestataire-signature.example/v1/documents', array(
        'headers' => array( 'Authorization' => 'Bearer ' . AGENCE_CLE_API_SIGNATURE ),
        'body'    => array(
            'document'  => $pdf,
            'signataire' => get_post_meta( $mandat_id, 'email_vendeur', true ),
        ),
    ) );

    if ( is_wp_error( $reponse ) ) {
        return new WP_Error( 'envoi_echec', 'Impossible de contacter le service de signature.' );
    }

    update_post_meta( $mandat_id, 'statut_signature', 'en_attente' );
    return array( 'statut' => 'en_attente' );
}

Le contrôle de permission vérifie explicitement que l’utilisateur connecté est bien propriétaire du mandat concerné — un point de sécurité indispensable puisque cette route agit sur un document juridiquement engageant.

Recevoir et traiter le webhook de statut

Le prestataire notifie WordPress de chaque changement d’état via un webhook, que le site expose sur une route REST dédiée, distincte de celle utilisée pour l’envoi :

register_rest_route( 'agence/v1', '/statut-signature', array(
    'methods'             => 'POST',
    'callback'            => 'agence_recevoir_statut_signature',
    'permission_callback' => 'agence_verifier_signature_webhook',
) );

function agence_recevoir_statut_signature( $request ) {
    $donnees   = $request->get_json_params();
    $mandat_id = agence_retrouver_mandat_par_reference( $donnees['reference'] );

    update_post_meta( $mandat_id, 'statut_signature', sanitize_key( $donnees['statut'] ) );

    return array( 'recu' => true );
}

La fonction agence_verifier_signature_webhook() valide une signature HMAC transmise en en-tête par le prestataire, condition indispensable pour s’assurer qu’une requête sur cette route provient bien du service de signature et non d’un tiers malveillant.

Ce que le bloc affiche selon le statut

Trois statuts suffisent à couvrir le cycle de vie complet du document : en_attente, signe et refuse. Le bloc adapte son affichage en conséquence — bouton d’envoi, message d’attente avec lien de relance, ou confirmation avec accès au document final signé, récupéré à son tour via l’API du prestataire une fois le statut passé à signe.

Un bloc qui orchestre une signature électronique doit rester transparent sur ce qu’il ne garantit pas : la valeur juridique du document appartient au prestataire certifié, jamais au site qui l’affiche.

Ce que cette architecture ne couvre pas

La valeur juridique de la signature électronique, sa conformité au règlement eIDAS et les recours en cas de contestation relèvent entièrement du prestataire choisi par l’agence — un point hors du périmètre technique de ce bloc, qui se contente d’orchestrer un flux et d’afficher un statut. Aucune analyse juridique n’a été menée dans le cadre de ce projet, celle-ci relevant du service juridique de l’agence et de son prestataire.

En résumé

Intégrer une demande de signature électronique directement dans un bloc évite à un vendeur de quitter l’espace client de l’agence, tout en laissant au prestataire spécialisé l’entière responsabilité de la valeur juridique du document. L’architecture repose sur deux routes REST bien séparées — envoi et réception de webhook — et sur un principe simple : WordPress orchestre, il ne signe jamais lui-même.