Skip to main content

Proposals & Invoices · Article 5.4

Ce que voit votre client quand un avenant arrive

Le client reçoit un e-mail avec un nouveau code PIN, arrive sur une page protégée par PIN, voit une comparaison côte à côte de l'ancien versus le nouveau avec les totaux et une raison, et signe (ou refuse) — exactement comme le flux du devis original, mais avec la comparaison intégrée.

L'expérience client pour un avenant reflète délibérément l'expérience du devis original. Même style d'e-mail (nom d'affichage = votre raison sociale), même portail PIN, même schéma d'URL hébergé sur Clozo, même capture de preuves à la signature. La différence est la page elle-même : au lieu d'un seul aperçu de devis, le client voit une comparaison structurée pour que le changement soit sans ambiguïté. Cette cohérence est importante — les clients qui ont signé un devis une fois ne devraient jamais avoir l'impression de naviguer dans une interface étrangère pour signer l'avenant.

Step by step

  1. L'e-mail arrive en ~5 secondes.

    Depuis noreply@useclozo.com, nom d'affichage « [Votre raison sociale] via Clozo ». L'objet par défaut est « Demande de modification de devis : [titre original] » mais est modifiable à l'étape 4 de l'assistant.

  2. Le client clique sur Consulter la modification.

    Il arrive sur app.useclozo.com/p/amendment/{slug} — une page hébergée par Clozo protégée par le code PIN à 4 chiffres imprimé dans le corps de l'e-mail.

  3. Le client saisit le PIN.

    Cinq tentatives incorrectes en 24 heures déclenche un blocage par slug (clé de cache slug_amend_locked:{slug}). Après le blocage, seul vous pouvez émettre un nouveau PIN (article 7.7).

  4. Le client lit la vue de comparaison.

    Les lignes originales apparaissent à gauche, les révisées à droite. Les étiquettes colorées reflètent l'assistant : vert + ajouté, ambré ~ modifié, rouge − supprimé, gris identique. Le delta des totaux est prominent en bas (« Augmentation du coût : +500 € » / « Diminution du coût : −500 € » / « Remboursement dû : 1 200 € »). La raison que vous avez rédigée à l'étape 2 apparaît comme une note citée au-dessus de la comparaison.

  5. Case de renonciation B2C (le cas échéant).

    Sur les avenants Δ+ où le client est marqué B2C, la page affiche deux cases de renonciation obligatoires immédiatement au-dessus du bouton Signer. Les deux doivent être cochées avant que Signer soit activé. Voir l'article 7.5 pour les mécanismes juridiques.

  6. Le client signe (ou refuse).

    La signature capture les mêmes preuves eIDAS que le devis original : nom tapé, e-mail, IP, User-Agent, horodatage serveur et indicateur de consentement. Le statut de l'avenant passe à signé, le pipeline post-signature s'exécute, et les e-mails de confirmation sont envoyés aux deux parties en quelques secondes.

La page de détail du devis affiche un panneau « Avenant en attente » avec le numéro d'avenant, l'horodatage d'envoi, le compte à rebours d'expiration (14 jours depuis sent_at) et trois boutons : Copier le lien de signature, Renvoyer avec un nouveau PIN, Annuler l'avenant. La Chronologie enregistre Avenant proposé à HH:MM UTC. Quand le client ouvre le lien, un événement de Chronologie Avenant consulté à HH:MM UTC par IP X.X.X.X apparaît. Quand il signe, le panneau disparaît, remplacé par les nouveaux documents dans le menu déroulant Documents plus un e-mail de confirmation dans votre boîte de réception.

Why this works this way

Pourquoi un nouveau PIN par avenant, même pour le même client qui a déjà signé le devis original ? Parce que l'avenant est un artefact juridique distinct — il dispose de sa propre piste d'audit, de sa propre pile de preuves, de son propre enregistrement immuable. Partager le PIN du devis original confondrait les deux artefacts et affaiblirait la chaîne de preuves si l'avenant est jamais contesté. Le blocage après 5 tentatives en 24 heures (_check_amendment_access_code dans backend/apps/public/amendment_views.py) s'applique indépendamment par slug d'avenant.

Le rendu de la vue de comparaison utilise une comparaison par position (computeDeltaAction dans AmendmentWizard.tsx) — la ligne à l'index i dans la liste révisée est comparée à la ligne à l'index i dans l'originale. Les ajouts apparaissent en bas de la liste révisée avec des étiquettes vertes ; les suppressions apparaissent dans la colonne originale avec des barres rouges ; les modifications restent en place avec des étiquettes ambrées. C'est simple et prévisible ; cela ne détectera pas un « intervertir deux lignes adjacentes » comme une non-opération (les deux apparaîtront comme modifiées) — par conception, car de telles réorganisations peuvent changer l'emphase d'un contrat même si les totaux de lignes correspondent.

Troubleshooting

Keep reading