statut: brouillon_en_attente — c’est l’état dans lequel se trouve systématiquement une relance générée par l’agent mis en place dans un office notarial de taille moyenne, avant qu’un clerc ou le notaire lui-même ne la valide. Aucune relance ne franchit cette étape sans intervention humaine, quelle que soit la confiance accordée au modèle après plusieurs mois d’usage.
Le contexte est sensible : des honoraires impayés, des clients parfois en difficulté, une relation de confiance à préserver malgré le retard de paiement. L’office a choisi de confier à un agent la partie la plus chronophage — repérer les dossiers en retard et rédiger une relance adaptée au ton attendu — tout en gardant la main sur l’envoi effectif via PayPlug.
Le périmètre : repérer et rédiger, jamais envoyer
L’agent dispose d’un accès en lecture aux dossiers dont l’échéance de paiement est dépassée de plus de quinze jours, via une requête sur un type de contenu personnalisé dossier_honoraires. Il génère un brouillon de message adapté à l’ancienneté du retard, mais ne dispose d’aucune capacité d’envoi ni de génération de lien de paiement PayPlug.
Pourquoi cette limite précise et pas une autre
L’équipe a envisagé, dans un premier temps, de laisser l’agent générer directement un lien de paiement PayPlug à inclure dans le message. Ce choix a été écarté après une simulation ayant montré qu’une erreur de montant, même rare, aurait des conséquences disproportionnées dans un contexte notarial où la confiance du client est un actif difficile à reconstruire.
Le circuit de validation mis en place
Chaque brouillon généré par l’agent apparaît dans une file d’attente dédiée, consultable par les clercs, avec le montant, le nom du client et le nombre de jours de retard affichés en tête. La validation déclenche alors, et alors seulement, la création du lien de paiement PayPlug et l’envoi du message.
function valider_relance_honoraires( int $relance_id ): bool {
$relance = get_post( $relance_id );
if ( 'brouillon_en_attente' !== get_post_meta( $relance_id, 'statut', true ) ) {
return false;
}
$lien_paiement = creer_lien_payplug(
get_post_meta( $relance_id, 'montant', true ),
get_post_meta( $relance_id, 'dossier_id', true )
);
update_post_meta( $relance_id, 'statut', 'validee_envoyee' );
update_post_meta( $relance_id, 'lien_paiement', $lien_paiement );
return true;
}La fonction creer_lien_payplug n’est appelée qu’après la validation humaine, jamais à l’initiative de l’agent. Ce point unique de passage obligé constitue la vraie garantie du dispositif, bien plus que n’importe quelle instruction donnée au modèle dans son prompt.
Ce que la validation a corrigé, concrètement
Sur les premiers mois d’utilisation, les clercs ont modifié environ une relance sur cinq avant validation, le plus souvent pour ajuster le ton — trop froid pour un client fidèle en difficulté passagère, ou au contraire trop conciliant pour un dossier déjà relancé à plusieurs reprises sans réponse.
- Le ton des relances est resté un point d’ajustement humain récurrent, jamais entièrement automatisable.
- Aucune erreur de montant n’a été détectée après validation, le calcul restant une opération déterministe côté serveur.
- Le temps de rédaction des relances a diminué nettement, sans réduire le contrôle exercé sur leur contenu final.
Un garde-fou supplémentaire : la double vérification du destinataire
Au-delà du montant, l’adresse e-mail de destination fait l’objet d’une vérification automatique croisant l’e-mail stocké dans le dossier et celui utilisé lors du dernier paiement réussi. Un écart entre les deux bloque la validation et alerte le clerc, une précaution qui s’est révélée utile lors d’un changement d’adresse non répercuté dans tous les systèmes.
Le gain de temps d’un agent ne vaut rien s’il se paie en perte de contrôle sur des opérations qui touchent directement à l’argent d’un client.
Notre verdict
Ce dispositif ne cherche pas la rapidité maximale mais un équilibre assumé : l’agent absorbe le travail répétitif de rédaction, l’humain garde la responsabilité de tout ce qui touche au paiement effectif. Pour un office notarial, où la relation de confiance prime souvent sur le gain de temps, cette répartition des rôles s’est révélée plus adaptée qu’une automatisation complète du circuit de relance.
