Cas particuliers

Modifier un document à signer existant ne met pas à jour son périmètre. Changer les filtres format / financeur d’un document déjà créé ne se répercute pas : le document continue de s’appliquer selon ses filtres d’origine, et l’échec n’est visible nulle part. Toute modification de périmètre passe par le pôle technique.

Supprimer un document à signer supprime toutes les signatures associées — y compris celles déjà signées, avec leur certificat et leur journal.

Une session ne doit porter qu’une seule signature active. Plusieurs outils (génération du certificat de consentement, corrections de dates) refusent de fonctionner sinon. Un doublon est le signe qu’un document a été créé deux fois ou qu’un rattrapage rétroactif s’est appliqué en trop.

Décalage d’une session : lorsqu’une session est recopiée pour être décalée, la signature, son certificat et son journal sont recopiés sur la nouvelle session. L’apprenant n’a pas à resigner, et la preuve de sa signature d’origine est conservée.

Signature antérieure à la fin de session. Certains financeurs contrôlent que l’attestation a bien été signée après la fin de la formation. Le point de vigilance : un déclencheur mal choisi peut faire signer trop tôt, et le problème ne se voit qu’au moment du contrôle.

Nettoyages non automatisés. Des routines existent pour supprimer les signatures des sessions non officielles et les signatures jamais signées de sessions terminées, mais elles ne tournent pas automatiquement : elles doivent être déclenchées à la demande par le pôle technique.

Comptes en accès spécial : ils ne reçoivent jamais de signature, quelle que soit la formation.

Un apprenant qui est aussi formateur n’a aucune signature

Symptôme. Un apprenant ne voit aucune signature dans « Mes documents », alors que sa session devrait en porter une. En regardant son compte, on constate qu’il porte aussi un rôle formateur.

Cause. À la création de la session, la plateforme ignore la création des consentements pour les comptes portant un rôle formateur (même logique que les comptes administrateurs). La session est donc bien créée, mais sans aucune signature attendue — et rien ne le signale.

Correction — dans cet ordre (l’ordre est important) :

1. Corriger d’abord le rôle du compte. Sur dashboard.erevo.fr (dashboard EasyAdmin de l’internal-api) → User CRUD → éditer l’utilisateur et retirer le rôle formateur. Voir la fiche entité User. Ce geste doit être fait avant de rejouer le webhook : sinon la recréation revérifie le rôle et les consentements ne seront de nouveau pas créés.
2. Sur HubSpot, basculer la transaction en phase « perdu » (closed lost). Cela déclenche la suppression de la session côté plateforme.
3. Rebasculer la transaction vers sa phase d’origine. Cela déclenche le webhook qui recrée la session — cette fois avec ses consentements, le rôle ayant été corrigé au préalable.

Ce basculement supprime puis recrée la session — risque de perte de données

Passer la transaction en « perdu » puis la rebasculer supprime et recrée la session : la progression de l’apprenant et tout ce qui était rattaché à l’ancienne session sont perdus. À réserver tôt, sur un dossier sans progression. Si l’apprenant a déjà de la progression ou des signatures existantes sur cette session, passez par le pôle technique plutôt que de rejouer le webhook.