Versionnement des CGV et preuve d’acceptation : documentation

Installation

Installez le module depuis Modules > Gestionnaire de modules > Installer un module en envoyant le fichier ZIP, ou déposez le dossier dftermsversion dans le répertoire /modules/ de votre boutique puis cliquez sur Installer.

À l’installation, le module crée ses tables, ajoute deux onglets sous le menu Commandes (Versions des CGV et Registre des acceptations) et importe le contenu de votre page CMS de CGV sous forme de brouillon. Rien n’est encore visible pour vos clients : aucune version n’est en vigueur tant que vous n’en avez pas publié une.

Publier votre première version

Ouvrez Commandes > Versions des CGV. Le brouillon importé apparaît avec le statut Brouillon. Cliquez dessus pour le relire dans chaque langue, puis sur Modifier si nécessaire.

Les champs d’une version

• Numéro de version : le libellé affiché aux clients, par exemple 2026-10 ou 4.2. Il doit être unique.
• Titre et texte : par langue. Une langue laissée vide reprend le texte de la langue par défaut à la publication.
• En vigueur à partir du : laissez vide pour appliquer la version dès sa publication. Une date future planifie le changement. Une date passée sert à ajouter une ancienne version à l’historique (voir plus bas).
• Résumé des modifications : affiché dans l’historique public.

Cliquez ensuite sur Publier. La version est verrouillée : son texte, son empreinte SHA-256 et ses PDF, générés dans chaque langue, ne pourront plus changer. Si l’horodatage est actif, le module demande aussitôt un horodatage à l’autorité configurée.

Modifier vos CGV

Depuis une version publiée, cliquez sur Créer une nouvelle version à partir de celle-ci. Un brouillon est créé avec le même texte. Modifiez-le, renseignez le résumé des modifications, choisissez la date d’entrée en vigueur, puis publiez.

Comparer deux versions

Sur la vue d’une version, le bloc Comparer propose par défaut la version précédente, ou la version en vigueur si vous êtes sur un brouillon. Cliquez sur Voir les modifications : les paragraphes modifiés, ajoutés et supprimés sont surlignés, au mot près pour les paragraphes modifiés, et les paragraphes inchangés sont repliés. Changez de langue avec les boutons en haut à droite.

Planifier un changement

Une version publiée avec une date future apparaît avec le statut Planifiée. Elle devient la version en vigueur automatiquement à cette date, sans tâche cron. La page de configuration affiche la prochaine version planifiée.

Ce que voit le client

• Au paiement : au-dessus des moyens de paiement, une mention indique la version en vigueur, sa date et un lien vers son PDF, ainsi qu’un lien vers les versions précédentes si l’historique public est actif.
• Dans l’email de confirmation : le PDF de la version acceptée est joint à l’email order_conf.
• Dans son compte : le détail de chaque commande rappelle la version acceptée avec un lien de téléchargement.
• Sur la facture : une mention de la version et de son empreinte, si l’option est active.

Ce que le module enregistre sur chaque commande

Quand l’étape de paiement s’affiche, le module note la version montrée au client, avec son adresse IP, son navigateur et l’heure. À la validation de la commande, il enregistre la version montrée, l’empreinte SHA-256 du texte dans la langue du client, et ces informations d’affichage.

Si aucun affichage n’a été tracé, par exemple avec un checkout qui n’utilise pas le hook displayPaymentTop, le module enregistre la version en vigueur à la date de la commande et le mode d’enregistrement « Validation de la commande ». Une commande créée depuis le back-office est enregistrée avec le mode « Back-office ».

Consulter la preuve d’une commande

Dans la fiche commande du back-office, la carte CGV acceptées affiche la version, les dates, l’IP, le mode d’enregistrement, le contrôle d’intégrité du texte et la position de la commande dans le registre. Trois boutons :

• Dossier de preuve (ZIP) : le fichier à transmettre en cas de litige (détail ci-dessous).
• Attestation d’acceptation (PDF) : un document récapitulant toutes les données enregistrées, suivi du texte intégral accepté.
• CGV acceptées (PDF) : le PDF de la version, tel que joint à l’email.

Contenu du dossier de preuve

• 01-acceptance-certificate.pdf : l’attestation d’acceptation.
• 02-...pdf : le PDF de la version acceptée.
• 03-accepted-text.txt : le texte source exact. Son SHA-256 est égal à l’empreinte enregistrée avec la commande.
• 04-version-timestamp/ : le manifeste de la version et son jeton d’horodatage .tsr.
• 05-register/ : l’entrée de la commande dans le registre, un extrait de la chaîne (identifiants et empreintes uniquement, sans données d’autres clients) et le scellement qui la couvre.
• README.txt : l’explication de chaque fichier et les commandes de vérification, dans la langue de l’employé.

Le registre scellé

Chaque acceptation contient l’empreinte de son contenu et l’empreinte de l’acceptation précédente. Modifier une ligne, en insérer une ou en supprimer une après coup rompt cette chaîne. Dans Commandes > Registre des acceptations, le bouton Vérifier le registre recalcule toute la chaîne et indique la première entrée altérée le cas échéant.

Scellements

Un scellement fait horodater par l’autorité l’empreinte de la dernière entrée du registre. Il prouve que tout le registre jusqu’à cette entrée existait à cette date, et il détecte aussi la suppression des dernières entrées. Cliquez sur Sceller maintenant, ou programmez l’URL affichée dans le bloc Scellement automatique une fois par jour dans une tâche cron :

0 3 * * * curl -s "https://votre-boutique.fr/module/dftermsversion/cron?token=..." > /dev/null

L’URL ne scelle que si de nouvelles entrées ont été enregistrées depuis le dernier scellement.

Horodatage par une autorité tierce

L’horodatage RFC 3161 fait signer une empreinte par une autorité indépendante, avec la date. Le module l’utilise pour chaque version publiée (sur un manifeste listant l’empreinte du texte dans chaque langue) et pour les scellements du registre.

Par défaut, le module utilise http://timestamp.digicert.com, gratuit et sans compte. Vous pouvez indiquer une autre autorité dans la configuration, par exemple https://freetsa.org/tsr ou une autorité qualifiée eIDAS. Le serveur de la boutique doit pouvoir joindre l’autorité en sortie.

Si l’autorité ne répond pas à la publication, la version est quand même publiée. L’erreur s’affiche sur la vue de la version, avec un bouton Horodater maintenant pour relancer.

Boutique existante : historique et commandes passées

Pour couvrir les commandes passées avant l’installation :

1. Publiez d’abord la version actuelle de vos CGV.
2. Créez une nouvelle version par ancienne version de vos CGV, avec sa vraie date d’entrée en vigueur dans le passé, et publiez-la. Le module refuse une date passée seulement si des commandes déjà rattachées à une autre version tombent dans la période concernée.
3. Dans Commandes > Registre des acceptations, le bloc Commandes antérieures indique combien de commandes ne sont rattachées à aucune version. Cliquez sur Rattacher ces commandes : le traitement se fait par lots, avec une barre de progression.

Ces commandes reçoivent la version en vigueur à leur date et sont marquées Rattachée a posteriori, sans IP ni trace d’affichage. Le module ne prétend pas avoir constaté ce qu’il n’a pas vu : ces rattachements valent indication de la version applicable, pas preuve d’affichage.

Réglages du module

• Joindre le PDF aux emails et Modèles d’email : order_conf par défaut, vous pouvez ajouter par exemple payment ou bankwire.
• Afficher la version au paiement : la mention au-dessus des moyens de paiement. Désactivée, le module trace quand même la version affichée.
• Mention sur les factures.
• Historique public des versions : une page listant les versions publiées avec leur PDF.
• Mettre à jour la page CMS automatiquement : quand une version entre en vigueur, son texte remplace celui de la page CMS choisie, pour que la case du tunnel pointe toujours vers la bonne version. Le bouton Mettre à jour la page CMS maintenant force la synchronisation.
• Anonymiser les adresses IP : ne conserve que la partie réseau de l’IP.
• Horodatage par un tiers et Autorité d’horodatage.
• Demandes d’effacement RGPD : voir ci-dessous.
• Supprimer toutes les données à la désinstallation : désactivé par défaut. Laissez-le désactivé, vos versions et votre registre sont vos preuves.

RGPD

Le module se branche sur le module RGPD officiel de PrestaShop (psgdpr). Les acceptations d’un client sont incluses dans l’export de ses données. Pour les demandes d’effacement, deux choix :

• Conserver la preuve (par défaut) : les enregistrements sont gardés, ce que permet l’article 17.3.e du RGPD pour la constatation, l’exercice ou la défense de droits en justice. Mentionnez-le dans votre politique de confidentialité.
• Effacer l’adresse IP et le navigateur : ces champs sont vidés. Le registre reste vérifiable et une empreinte calculée à l’effacement protège les champs restants, mais la preuve est plus faible pour ce client.

Dépannage

La mention n’apparaît pas au paiement

Vérifiez qu’une version est en vigueur et que l’option d’affichage est active. Si votre thème ou votre module de checkout n’appelle pas le hook displayPaymentTop, les commandes sont enregistrées avec la version en vigueur à la date de commande.

Le PDF n’est pas joint à l’email

Vérifiez l’option Joindre le PDF aux emails et le nom exact du modèle. Certains modules de paiement envoient leur propre email de confirmation sous un autre nom de modèle : ajoutez-le à la liste.

L’horodatage échoue

Le message d’erreur indique la cause. Le plus souvent, l’hébergeur bloque les connexions sortantes. Testez une autre autorité ou demandez à votre hébergeur d’ouvrir l’accès à l’adresse de l’autorité. L’extension PHP cURL est recommandée.

La vérification du registre signale une altération

Le message indique l’entrée concernée et la nature du problème : contenu modifié, entrée insérée ou supprimée avant elle, ou entrée scellée disparue. Restaurez la table dftv_acceptance depuis une sauvegarde antérieure à l’altération, puis relancez la vérification.

Compatibilité

• PrestaShop 8.0 à 9.x, le même ZIP couvre les deux branches.
• Multiboutique et multilingue.
• PDF générés avec le TCPDF intégré à PrestaShop, extension PHP zip requise pour le dossier de preuve.
• Architecture ModuleAdminController, sans dépendance Composer.
• Interface disponible en français, anglais, espagnol, allemand, italien, néerlandais, polonais et portugais.