« Erreur : capacité d’envoi non déclarée pour ce rôle » — c’est précisément le message que renvoie le système lorsqu’une tentative, volontaire ou non, cherche à faire franchir à l’agent une limite qu’il ne doit jamais franchir : celle de l’envoi direct d’une relance de loyer à un locataire. Ce message d’erreur n’est pas un bug à corriger, c’est une protection délibérément construite par un cabinet de gestion locative gérant plusieurs dizaines de biens en location.
Le cabinet a choisi de confier à un agent la rédaction des relances de loyer en retard, une tâche répétitive et sensible au ton employé, tout en conservant l’envoi effectif sous contrôle humain systématique. Cette séparation stricte entre rédaction et envoi structure l’ensemble du dispositif mis en place.
Pourquoi séparer aussi nettement rédaction et envoi
Une relance de loyer touche à la fois à l’argent et à la relation humaine avec un locataire, parfois en difficulté passagère, parfois de mauvaise foi. Le cabinet a estimé qu’un agent, aussi bien réglé soit-il, ne pouvait pas juger seul du bon moment ni du ton approprié pour chaque situation individuelle, sans connaître l’historique complet de la relation avec ce locataire précis.
Le fonctionnement concret du dispositif
Chaque premier jour de retard détecté sur un loyer déclenche la génération d’un brouillon de relance par l’agent, en tenant compte du nombre de jours de retard et de l’historique des relances précédentes pour ce même bien. Ce brouillon apparaît dans une file de validation consultée quotidiennement par les gestionnaires du cabinet.
La déclaration des abilities côté extension
Techniquement, seule une ability de lecture et de génération de contenu est déclarée pour l’agent, à l’exclusion de toute ability d’envoi. Cette déclaration explicite, via l’Abilities API disponible depuis l’été 2025, rend la limitation vérifiable dans le code plutôt que reposant uniquement sur une consigne donnée au modèle.
wp_register_ability(
'gestion-locative/rediger-relance',
array(
'label' => 'Rédiger une relance de loyer',
'category' => 'contenu',
'execute_callback' => 'rediger_relance_loyer',
'permission_callback' => function () {
return current_user_can( 'agent_gestion_locative' );
},
)
);
// Aucune ability d'envoi n'est enregistrée pour ce rôle :
// l'action d'envoi reste exclusivement humaine.Ce que la relecture humaine a modifié dans la pratique
Sur les premiers mois de fonctionnement, les gestionnaires ont ajusté environ un brouillon sur quatre avant envoi, principalement pour tenir compte d’un élément que l’agent ne pouvait pas connaître : un accord verbal récent avec le locataire, un dégât des eaux en cours de traitement, ou une situation personnelle signalée par téléphone.
- Le brouillon généré sert de base de travail, pas de version finale automatique.
- Aucune relance n’a été envoyée sans qu’un gestionnaire nommé ne l’ait explicitement validée.
- Le temps de rédaction par relance a diminué, sans réduire le temps de relecture attentive.
Un cas où la limite a montré son utilité
Un locataire ayant signalé un problème de chauffage non résolu depuis plusieurs semaines a reçu, dans le même temps, un brouillon de relance pour un loyer en léger retard. Un gestionnaire a repoussé l’envoi de plusieurs jours, le temps que le problème de chauffage soit traité, plutôt que d’envoyer une relance qui aurait été perçue, à juste titre, comme déplacée dans ce contexte précis.
Un brouillon qui attend une validation humaine coûte quelques minutes par jour ; une relance envoyée au mauvais moment coûte bien plus en relation de confiance avec un locataire.
Pour aller plus loin
Ce dispositif ne cherche pas à automatiser l’intégralité du processus de relance, mais à décharger la partie la plus répétitive — la rédaction — tout en gardant la décision d’envoi entièrement humaine. Pour un cabinet de gestion locative, où chaque relation avec un locataire a son propre historique et ses propres nuances, cette limite volontaire semble mieux adaptée qu’une automatisation complète du circuit.
