Conditions générales de vente de votre boutique : ce qu'elles doivent contenir
Dernière révision : juin 2026. Les chemins du back-office correspondent à PrestaShop 1.7, 8 et 9 ; les points juridiques sont datés lorsque la date a son importance.
Ceci est une information générale, pas un conseil juridique. Vos conditions générales relèvent de votre responsabilité : une page CMS et une case à cocher dans le tunnel de commande font accepter un document, elles ne rédigent pas à votre place un texte conforme. Pour une boutique multinationale, B2B ou avec abonnements, faites relire le texte par un avocat spécialisé en e-commerce ; le coût est faible comparé à une seule plainte auprès d'une autorité de contrôle.
Les conditions générales sont la page la moins séduisante de votre boutique, et celle que vous serez heureux d'avoir bien préparée le jour où un client conteste un paiement, refuse un retour ou dépose une réclamation auprès d'une autorité de protection des consommateurs. Dans l'UE, elles ne sont pas facultatives, et « je les ai copiées sur une plus grande boutique » est exactement le type de réponse qui transforme un simple désaccord en dossier perdu. La bonne nouvelle pour les marchands PrestaShop : la plateforme vous donne déjà un endroit où les publier, un moyen de les faire accepter aux clients au moment de la commande, et les hooks nécessaires pour imposer cette acceptation. Ce guide explique ce qui doit figurer dans le document et comment l'intégrer correctement dans PrestaShop : pas la bannière cookies, pas la politique de confidentialité, pas tout le processus de retour, qui ont chacun leur propre rôle et leurs propres articles sur ce blog.
Ce que signifient vraiment les « conditions générales » dans PrestaShop
Il est utile de distinguer deux éléments que les marchands confondent souvent. Il y a le document : le texte contractuel qui indique qui vous êtes, ce que le client achète et les règles de la vente. Et il y a le mécanisme de consentement : la case « J'accepte les conditions générales » qu'un client coche avant de pouvoir passer commande. PrestaShop gère le premier comme une page CMS et le second comme un réglage natif du tunnel de commande, les deux étant liés par une seule valeur de configuration. Paramétrez correctement ces deux volets et PrestaShop imposera l'acceptation des conditions au moment de la commande ; gardez toutefois à l'esprit que le cœur ne conserve pas, pour chaque commande, une copie de la version exacte des conditions acceptées. Si vous devez prouver quel texte un client a accepté, datez et versionnez vos conditions, puis archivez chaque version (ou utilisez un module qui l'enregistre).
Le document lui-même est une simple page CMS située dans Design → Pages (le contrôleur CMS). Une installation PrestaShop neuve inclut une page provisoire « Conditions d'utilisation » : cette page est le défaut de conformité le plus fréquent que nous voyons, parce qu'elle paraît réelle à un propriétaire pressé qui ne l'ouvre jamais. C'est du remplissage du niveau Lorem ipsum. Remplacez-la.
Le minimum légal que vos conditions doivent couvrir (UE)
Le droit européen de la consommation exige que certaines informations parviennent au client avant qu'il ne soit lié par le contrat. Une partie est couverte par vos fiches produit et le tunnel de commande ; le reste doit figurer dans les conditions générales. Au minimum, le document doit couvrir :
- Identité de l'entreprise : dénomination légale complète, adresse enregistrée, e-mail et numéro de téléphone. Une boîte postale ne suffit pas : c'est votre adresse enregistrée réelle qui compte. (En Allemagne, cela recoupe l'obligation distincte d'Impressum ; consultez le guide du droit e-commerce dans l'UE pour une vue pays par pays.)
- Ce qui est vendu et le prix total : les caractéristiques essentielles des biens, ainsi que le prix tout compris incluant la TVA et les éventuels frais de livraison ou de traitement ; aucun montant ne doit apparaître pour la première fois à l'étape du paiement.
- Paiement et livraison : les moyens de paiement acceptés, le moment où le paiement est prélevé, le délai de livraison et la personne qui supporte les frais d'expédition.
- Le droit de rétractation de 14 jours : son existence, la manière de l'exercer et les catégories de produits auxquelles il ne s'applique pas. Ce point a de vraies conséquences ; il est détaillé ci-dessous.
- Garantie légale de conformité : la responsabilité minimale obligatoire de deux ans dans l'UE pour les biens qui ne correspondent pas à ce qui a été vendu, à distinguer clairement de toute garantie commerciale que vous choisissez d'ajouter.
- Traitement des réclamations et résolution des litiges : la manière dont un client signale un problème, ainsi qu'une référence, lorsque c'est requis, à l'organisme national compétent de règlement extrajudiciaire des litiges ou de réclamation des consommateurs.
Et alors ? Omettre ou cacher l'une de ces informations n'est pas un problème de style : cela déplace les droits juridiques en faveur du client. L'exemple le plus clair : si vous n'informez pas correctement l'acheteur de son droit de rétractation, le délai d'annulation ne reste pas à 14 jours, il s'étend à 12 mois. Une page de conditions vagues peut vous obliger à accepter des retours presque un an après une vente que vous pensiez définitive.
Le droit de rétractation est la clause qui peut coûter cher : soyez précis
Le délai de rétractation de 14 jours est la partie de vos conditions la plus susceptible d'être invoquée ; elle mérite donc une formulation précise, pas une phrase vague. Vos conditions doivent indiquer clairement que ce droit existe, expliquer comment le client l'exerce (par e-mail, formulaire ou courrier), mettre à disposition le formulaire type de rétractation de l'UE, s'engager à rembourser dans les 14 jours suivant l'information de la rétractation (pour les biens, vous pouvez différer le remboursement jusqu'à réception des biens retournés ou jusqu'à ce que le client fournisse une preuve d'expédition, selon la première de ces dates), et préciser clairement qui paie les frais de retour : vous pouvez les mettre à la charge du client, mais seulement si vous l'en avez informé à l'avance.
Vous devez aussi énoncer honnêtement vos exceptions : les articles fabriqués sur mesure ou personnalisés, les produits d'hygiène scellés une fois descellés, les denrées périssables et les téléchargements numériques que le client a accepté de lancer avant la fin du délai sont réellement exclus. Listez uniquement les exceptions sur lesquelles vous vous appuyez effectivement ; ne revendiquez pas des exclusions générales que vous ne pouvez pas justifier. Le droit de rétractation rejoint la façon dont vos retours sont réellement traités dans le back-office, sujet plus vaste à part entière : consultez la vente à distance et le droit de rétractation et, pour la gestion quotidienne, ce qu'une politique de retour doit imposer.
Raccorder les conditions générales au tunnel de commande PrestaShop

Une page de conditions que personne n'a acceptée ne prouve rien. La valeur de PrestaShop ici, c'est qu'il peut imposer l'acceptation et l'enregistrer. Deux réglages l'activent, tous deux dans Paramètres de la boutique → Paramètres de commande, onglet Général :
- Activer les conditions générales de vente : l'interrupteur stocké dans la valeur de configuration PS_CONDITIONS. Activez-le et l'étape de paiement du tunnel de commande affiche une case « J'accepte les conditions générales » que le client ne peut pas ignorer.
- Page des conditions générales : une liste déroulante stockée dans PS_CONDITIONS_CMS_ID, qui fait pointer le lien de la case vers la bonne page CMS. C'est ici que les marchands se trompent : ils activent la case, mais la laissent pointer vers la page provisoire, si bien que les clients acceptent du Lorem ipsum.
Sous le capot, la classe native ConditionsToApproveFinder lit PS_CONDITIONS ; lorsqu'elle est activée, elle construit la case par défaut à partir de la page CMS désignée par PS_CONDITIONS_CMS_ID et empêche le OrderController de valider la commande tant que la case n'est pas cochée. Vous n'avez pas besoin de toucher à ce code, mais savoir que l'obligation est appliquée côté serveur, et pas seulement par du JavaScript côté front-office, est rassurant : un client ne peut pas contourner l'acceptation en désactivant les scripts.
Un détail mérite d'être connu si vous vendez plusieurs types de produits ou exploitez une activité B2B : cette même classe exécute un hook PrestaShop, termsAndConditions, de sorte qu'un module peut ajouter des cases de consentement supplémentaires (un accusé de réception distinct du formulaire de rétractation, une vérification d'âge, des conditions propres au B2B) à côté de la case par défaut. Chaque case porte un identifiant, et une case ultérieure avec le même identifiant remplace la précédente ; c'est ainsi qu'un module remplace proprement la case standard au lieu de la dupliquer. Conséquence pratique : vous n'êtes pas limité à une seule case globale de conditions, et ajouter un second consentement ne signifie pas modifier les fichiers du cœur.
Multilingue et multiboutique : là où la page provisoire fait deux fois mal
Comme les conditions sont stockées dans une page CMS, elles héritent du modèle de traduction de PrestaShop : une page CMS possède un corps distinct pour chaque langue installée. Si vous vendez en France, en Allemagne et en Pologne, la page des conditions dispose d'une version française, allemande et polonaise ; et PrestaShop affichera sans problème un onglet vide ou anglais à un client français si vous n'en avez rempli qu'un seul. Un lien « Conditions » qui mène à une page vide dans la langue du client revient, juridiquement, à ne pas fournir de conditions du tout. Vérifiez chaque onglet de langue actif sur la page, pas seulement votre langue par défaut.
Le multiboutique amplifie ce point. PS_CONDITIONS et PS_CONDITIONS_CMS_ID sont toutes deux des valeurs de configuration compatibles multiboutique, si bien que chaque boutique d'un groupe multiboutique peut faire pointer sa case vers sa propre page de conditions. C'est correct et utile : une boutique B2C et une boutique B2B dans le même groupe doivent renvoyer vers des conditions différentes ; mais cela signifie que « je l'ai configuré une fois » n'est pas vrai. Définissez la page, ainsi que les deux réglages, pour chaque boutique et chaque langue.
Ne laissez pas vos conditions absorber les autres politiques
L'envie de faire des conditions générales un méga-document unique se comprend, mais c'est une erreur. PrestaShop traite la confidentialité, les cookies, les retours et la livraison comme des sujets distincts, et le droit aussi ; les regrouper rend chaque information plus difficile à trouver pour le client et plus difficile à mettre à jour pour vous sans devoir tout retoucher. Gardez des pages séparées, chacune avec son propre lien :
- Politique de confidentialité (RGPD) : les données que vous collectez, la base légale, les destinataires, la durée de conservation et les droits des clients. C'est un document distinct avec ses propres obligations : commencez par le RGPD pour les boutiques en ligne et, pour les spécificités PrestaShop, la conformité RGPD et cookies pour PrestaShop.
- Consentement aux cookies : la bannière et ce qui constitue un consentement valable relèvent d'un test juridique à part entière ; voyez ce que le consentement aux cookies exige réellement.
- Livraison et retours : les clients cherchent ces informations avant d'acheter ; donnez-leur donc une page autonome facile à trouver au lieu d'enterrer les délais de livraison et les étapes de retour dans la clause 14 des conditions. La mécanique est expliquée dans retours et remboursements.
- Présentation des prix : la manière d'afficher les prix HT, TTC et unitaires est un domaine de conformité à part entière : les règles d'affichage des prix en Europe.
Vos conditions peuvent, et doivent, renvoyer vers ces pages. Elles ne doivent pas les reproduire.
Les erreurs qui coûtent vraiment de l'argent
| Erreur | Pourquoi elle vous expose | Le correctif dans PrestaShop |
|---|---|---|
| Mettre en ligne la page provisoire par défaut | Les clients « acceptent » un texte de remplissage ; vous n'avez pas de conditions opposables | Réécrivez la page CMS dans Design → Pages avant la mise en production |
| Case activée, mais pointant vers la mauvaise page | PS_CONDITIONS est actif, mais PS_CONDITIONS_CMS_ID pointe encore vers la page provisoire | Réglez « Page des conditions générales » dans Paramètres de commande → Général |
| Conditions traduites dans une seule langue | Les clients utilisant une autre langue voient une page juridique vide | Remplissez chaque onglet de langue actif de la page CMS |
| Copier mot pour mot les conditions d'une autre boutique | Elles mentionnent des produits et obligations qui ne sont pas les vôtres | Adaptez-les à votre catalogue, vos pays et vos moyens de paiement réels |
| Clause à l'américaine « ventes définitives / aucun remboursement » | Le droit de rétractation de 14 jours ne peut pas être écarté dans l'UE : la clause est nulle | Remplacez-la par une clause de rétractation conforme et les exceptions indiquées |
| Aucune date de version sur le document | Vous ne pouvez pas prouver quelles conditions s'appliquaient à une commande donnée | Datez les conditions ; la commande elle-même horodate le consentement |
Rédiger des conditions que les gens peuvent vraiment lire
Conformité et lisibilité ne s'opposent pas. Le droit exige que les informations requises soient présentes et claires ; il n'impose pas un jargon juridique intimidant, et ce jargon tend même à réduire les chances que l'on puisse dire qu'un client a réellement compris ce qu'il acceptait. Utilisez la même structure que pour toute bonne page : des titres, des paragraphes courts, et les points qui intéressent les clients — retours, livraison, garanties — placés au début. Une page de conditions qu'un client peut parcourir et comprendre est à la fois plus conforme et un petit signal de confiance au moment précis où il décide de payer.
Pour une petite boutique B2C opérant dans un seul pays, un bon modèle conforme au droit de l'UE, soigneusement adapté à votre activité, suffit généralement. Dès que vous ajoutez une vraie complexité — vente dans plusieurs pays de l'UE, B2B en plus du B2C, abonnements ou biens numériques — le coût d'un avocat spécialisé en e-commerce est faible comparé à une seule plainte auprès d'une autorité de contrôle pour une information de rétractation manquante. Si cette complexité vous concerne, les guides voisins sont les prochaines lectures logiques : les retours transfrontaliers, l'e-commerce B2B avec PrestaShop, et les obligations de TVA qui vont avec dans la TVA dans l'UE : OSS et IOSS.
FAQ
Puis-je simplement copier un modèle ou les conditions d'une autre boutique ?
Un bon modèle conforme au droit de l'UE est un point de départ raisonnable pour une petite boutique B2C opérant dans un seul pays ; mais adaptez-le à votre catalogue, vos pays, vos moyens de paiement et votre politique de retour réels avant la mise en ligne. Copier mot pour mot les conditions d'une autre boutique correspond exactement au cas d'échec du tableau des erreurs : leur document mentionne des produits, obligations et juridictions qui ne sont pas les vôtres, et une clause inadaptée peut être pire qu'une clause manquante. Dès que vous ajoutez une vraie complexité (plusieurs pays de l'UE, B2B en parallèle du B2C, abonnements, biens numériques), faites relire le texte par un avocat.
L'activation de la case des conditions prouve-t-elle qu'un client donné a accepté une version précise ?
Elle prouve qu'il a coché la case dans le tunnel de commande : PrestaShop l'impose côté serveur via ConditionsToApproveFinder et le OrderController, si bien qu'un client ne peut pas la contourner en désactivant JavaScript, et la commande horodate le moment où il l'a fait. Ce que le cœur ne fait pas, c'est stocker pour chaque commande une copie du texte exact des conditions en vigueur à cet instant. Donc, si vous devez pouvoir prouver quelle formulation s'appliquait à une commande, datez et versionnez vos conditions, archivez vous-même chaque version, ou utilisez un module qui enregistre le texte accepté avec la commande.
La confidentialité, les cookies et les retours doivent-ils figurer dans le document des conditions ?
Non. Gardez-les sous forme de pages CMS séparées, chacune avec son propre lien : le droit traite la confidentialité, le consentement aux cookies, les retours et la présentation des prix comme des sujets distincts, et les regrouper rend chaque information plus difficile à trouver pour le client et plus difficile à mettre à jour pour vous. Vos conditions peuvent et doivent renvoyer vers ces pages ; elles ne doivent pas les reproduire. Les guides liés sur le RGPD, le consentement aux cookies et les retours couvrent chaque sujet sur sa propre page.
Une clause « ventes définitives / aucun remboursement » est-elle valable dans l'UE ?
Non. Le droit de rétractation de 14 jours prévu par la directive relative aux droits des consommateurs (2011/83/UE) ne peut pas être écarté pour les ventes à distance B2C ; une clause générale « aucun remboursement » est donc nulle et signale à une autorité de contrôle que le reste du document n'est pas fiable. Remplacez-la par une clause de rétractation conforme, accompagnée des véritables exceptions sur lesquelles vous vous appuyez réellement (sur-mesure, produits d'hygiène descellés, denrées périssables, téléchargements numériques commencés). La mécanique est expliquée dans la vente à distance et le droit de rétractation.
Un module peut-il ajouter une deuxième case de consentement sans modifier le cœur ?
Oui. La même classe native exécute un hook PrestaShop, termsAndConditions, ce qui permet à un module d'ajouter des cases de consentement supplémentaires (un accusé de réception distinct du formulaire de rétractation, une vérification d'âge, des conditions propres au B2B) à côté de la case par défaut. Chaque case porte un identifiant, et une case ultérieure avec le même identifiant remplace la précédente ; c'est ainsi qu'un module remplace ou complète proprement la case standard sans toucher aux fichiers du cœur. Vous n'êtes pas limité à une seule case globale de conditions.
Les conditions générales ne déclencheront pas une vente. Mais ce sont elles qui décident si un litige tourne en votre faveur ou en celle du client, et PrestaShop vous fournit déjà les pièces pour faire les choses correctement : une vraie page CMS dans chaque langue, la case PS_CONDITIONS pour imposer l'acceptation (appliquée côté serveur), et l'horodatage de la commande pour marquer le moment où le client l'a passée ; pour une preuve plus solide du texte exact accepté, ajoutez un archivage des versions ou un module qui l'enregistre. Consacrez-y un après-midi une fois, puis n'y pensez plus jusqu'au jour où vous serez heureux qu'elles soient là.
Commentaires
Aucun commentaire pour le moment. Soyez le premier !
Soyez le premier à poser une question ou à partager un retour utile.
Laisser un commentaire
Partagez une question, un détail de pose ou un retour qui pourrait aider un autre lecteur.