Support Revolution : créer un centre d’assistance dans votre boutique PrestaShop

La plupart des marchands PrestaShop gèrent leur support depuis une boîte Gmail partagée et ne se rendent pas compte que PrestaShop intègre déjà un centre d’assistance — un vrai, avec des fils de discussion reliés aux fiches clients et aux commandes, qui dort inutilisé dans le back-office. Le problème n’est pas l’absence d’outil. C’est que l’outil natif s’arrête précisément là où une boutique en croissance commence à souffrir : statuts limités, pas de priorités, pas de compteurs SLA, pas de réponses préenregistrées, et un formulaire de contact que la plupart des marchands ne configurent jamais jusqu’au bout. Ce guide explique comment créer un centre d’assistance dans votre boutique — d’abord en activant ce qui existe déjà, puis en sachant exactement quand et comment passer à l’étape supérieure — pour que les échanges de support conservent le contexte de la commande au lieu de commencer chaque fois par « quel est votre numéro de commande ? ».

Dernière mise à jour : juin 2026.

Nous parlons ici du volet opérationnel du support client, directement dans la boutique. Les canaux conversationnels qui l’alimentent — chat en direct, WhatsApp, Messenger — méritent chacun leur propre analyse, et nous y renvoyons au bon endroit plutôt que de tout réexpliquer ici.

Le centre d’assistance que PrestaShop vous fournit déjà

Ouvrez votre back-office et allez dans Service client → Service client. C’est le centre d’assistance natif, piloté par le contrôleur AdminCustomerThreads. Chaque message envoyé par un client via le formulaire de contact de votre boutique devient un CustomerThread, et chaque réponse est un CustomerMessage qui lui est rattaché. PrestaShop fait ici plus que la plupart des marchands ne l’imaginent : si l’expéditeur est un client connecté (ou si son e-mail correspond à un compte), le fil est lié à ce client ; s’il mentionne une commande, il est aussi lié à cette commande. Ouvrez un fil et vous voyez qui est la personne, ce qu’elle a acheté et tout l’historique des échanges au même endroit.

Tout cela est alimenté par le formulaire Contact, servi par le ContactController à l’adresse /contact-us. Dans Service client → Contacts, vous définissez vos services de contact — Service client, Webmaster ou tout autre service que vous ajoutez — et chacun peut pointer vers une adresse e-mail différente. Choisissez « Service client » et PrestaShop enregistre le message comme un fil de discussion ; choisissez un service paramétré autrement et il peut simplement transmettre le message par e-mail. La liste déroulante des services sur le formulaire de contact est l’équivalent natif de « transmettre cette demande à la bonne équipe ».

Qu’est-ce que cela vous apporte concrètement ? Trois choses pour lesquelles vous payez peut-être déjà un outil tiers : toutes les demandes sont capturées dans une file unique au lieu d’être dispersées dans des boîtes personnelles ; le contexte client et commande est ajouté automatiquement, ce qui permet à un agent de répondre sans interroger d’abord le client ; et l’historique reste accessible même lorsqu’un employé part avec sa boîte mail. Pour une boutique qui reçoit quelques demandes par jour, l’activer — et faire pointer réellement le lien « Contactez-nous » vers ce formulaire — constitue une vraie amélioration par rapport à une boîte partagée, sans coût supplémentaire.

Là où le centre d’assistance natif atteint ses limites

Le système natif de fils de service client a été conçu pour être suffisant, pas complet. Ses limites sont prévisibles, et elles apparaissent toutes au même moment : lorsque le volume de support passe de « je lis chaque message » à « il me faut un système pour que rien ne passe entre les mailles ».

Rien de tout cela n’est un défaut de PrestaShop — c’est simplement la différence entre un journal de messages et un centre d’assistance. Le bon cadre de décision dépend du volume : sous une douzaine de tickets par jour environ, le natif accompagné d’une page /contact-us propre suffit, et ajouter un logiciel serait surdimensionné. Au-delà, les pièces manquantes commencent à coûter du temps réel et de vrais clients, et une couche dédiée se rentabilise.

Transformer le système natif de fils en véritable centre d’assistance par tickets

Lorsque vous dépassez les capacités du natif, vous avez les trois options habituelles : le reconstruire avec un développeur (contrôle total, coût continu, et une tendance à casser lors de la prochaine mise à jour majeure), brancher un outil SaaS d’assistance externe (puissant, mais le support vit alors hors de votre boutique et perd le contexte de commande qui rendait la version native intéressante), ou ajouter un module qui prolonge le même modèle intégré à la boutique.

La raison pour laquelle nous avons créé Support Revolution, c’est cette troisième option : garder le support dans PrestaShop afin de conserver le contexte client et commande, tout en ajoutant la couche opérationnelle qui manque au natif. Chaque demande devient un ticket suivi avec de vrais statuts, des conversations en fil, un routage par service pour que la question arrive à la bonne équipe plutôt que dans une file partagée, des niveaux de priorité pour qu’une livraison en retard passe devant une question de taille, des pièces jointes pour qu’un client puisse envoyer dans le fil une photo de l’article endommagé, et des notifications par e-mail qui font avancer les deux côtés sans que personne ait à rafraîchir le back-office. Le module fonctionne aussi bien pour les invités que pour les clients inscrits, avec une option conversion d’e-mails en tickets par IMAP : si un client répond simplement à l’e-mail de notification, sa réponse revient dans le bon ticket au lieu d’atterrir dans une boîte sans issue.

Quelle est donc la différence concrète un jour de forte activité ? Les tickets cessent de passer entre les mailles parce que chacun possède un statut dont quelqu’un est responsable ; les agents arrêtent de retaper les mêmes réponses ; les urgences remontent au lieu d’être noyées ; et comme tout fonctionne dans votre back-office sur PrestaShop 1.7, 8 et 9, les données de support restent à côté des commandes concernées plutôt que dans un tableau de bord SaaS séparé facturé chaque mois. Le vrai bénéfice pour le propriétaire : vous pouvez enfin mesurer le délai de première réponse et le temps de résolution, puis corriger la file au lieu de simplement la vider.

Chaque ticket porte son statut, sa priorité et la commande concernée — exactement le contexte qu’un SaaS externe laisse de côté.

Détourner les demandes avant le support : le libre-service dans la boutique

Le ticket le moins cher est celui auquel le client trouve lui-même la réponse. Avant de faire grandir le centre d’assistance, faites grandir ce qui empêche les questions de l’atteindre — et PrestaShop vous donne déjà la plupart des points d’accroche nécessaires.

• Le suivi de commande dans l’espace client. « Où est ma commande ? » est la demande la plus fréquente, et presque entièrement traitable en libre-service. La page Historique & détails des commandes du client (les contrôleurs history et OrderDetail) affiche déjà le statut et, si vous avez saisi un numéro de suivi sur la commande, un lien de suivi. Assurez-vous que les transporteurs disposent d’une URL avec l’espace réservé @ configurée dans Livraison → Transporteurs, afin que le numéro de suivi devienne un lien cliquable — ce seul réglage supprime toute une catégorie de tickets.
• Une vraie FAQ qui couvre les 20 questions à l’origine de 80 % du volume. Délais de livraison, retours, tailles, moyens de paiement, suivi de commande — une réponse rédigée une fois, toujours facile à retrouver. Une page CMS statique fonctionne ; une FAQ structurée et consultable fonctionne mieux. Un Issue Tracker pour les notes sur les problèmes connus avec suivi de statut, associé à un gestionnaire de FAQ structuré, transforme ces réponses en onglet directement sur la page produit, là où la question naît.
• Des pages produit qui anticipent la question. Des guides de tailles précis, des notes de compatibilité et des photos claires répondent aux questions avant achat avant qu’elles ne deviennent des tickets. Chaque question résolue sur la page produit est un ticket qui n’a jamais existé.

Le libre-service ne remplace pas le support — c’est ce qui garde le centre d’assistance suffisamment petit pour rester excellent.

Les canaux conversationnels qui alimentent le centre d’assistance

Une file de tickets permet de répondre aux questions en profondeur ; le chat en direct et la messagerie y répondent maintenant. Les deux ne sont pas concurrents — le chat capte le moment d’avant-vente « est-ce que cela convient ? », tandis que le centre d’assistance traite tout ce qui demande un historique ou un suivi. Plutôt que de réexpliquer chaque canal ici, voici où ils s’inscrivent dans le sujet :

• Pour savoir si le chat en direct fait réellement bouger les chiffres avant d’ajouter un nouveau widget : le chat en direct augmente-t-il vraiment les ventes.
• Pour choisir un outil de chat gratuit : comparatif Tawk.to vs Tidio vs Crisp, ainsi que le comparatif plus large WhatsApp vs Messenger vs Tawk.to.
• Pour rejoindre les clients sur les applications qu’ils utilisent déjà : chat WhatsApp pour PrestaShop (avec le guide pratique configuration et bonnes pratiques), ou chat Messenger : avantages, limites et configuration.

Et lorsqu’un échange de support se termine bien, il ne doit pas s’arrêter là — ce même client est votre meilleur candidat pour une séquence d’e-mails après achat, et un client inactif pour une campagne de reconquête. Support et fidélisation sont la même relation, observée à deux moments différents.

Mesurer si votre centre d’assistance fonctionne

Vous ne pouvez pas améliorer ce que PrestaShop natif ne vous permet pas de voir — et c’est précisément pourquoi les indicateurs ci-dessous sont le meilleur argument en faveur d’une vraie couche de gestion de tickets. Dès que les tickets portent des statuts et des horodatages, suivez quatre chiffres :

• Délai de première réponse — le temps nécessaire avant qu’un humain réponde. Un objectif courant est de quelques heures pendant les horaires ouvrés ; l’essentiel est que la tendance baisse, pas le seuil exact.
• Temps de résolution — de l’ouverture à la fermeture, pour les demandes standard.
• Taux de résolution au premier contact — la part des demandes résolues sans second aller-retour. C’est là que le contexte de commande porte ses fruits, car l’agent ne demande pas des informations que le système possède déjà.
• Répartition des sujets de tickets — et c’est l’indicateur qui économise vraiment de l’argent. Si un tiers de vos tickets porte sur la même question, ce n’est pas un problème de support : c’est une entrée de FAQ manquante, une page retours peu claire ou une description produit incomplète. Corrigez la cause racine et les tickets cessent d’arriver.

Analysez chaque mois la répartition des sujets. Le but d’un bon centre d’assistance n’est pas de traiter toujours plus de tickets toujours plus vite — c’est de réduire chaque catégorie de tickets en corrigeant ce qui la provoque, afin que votre file diminue même lorsque votre nombre de commandes augmente.

Le support est un centre de coûts qui protège discrètement le chiffre d’affaires : chaque demande bien traitée préserve un client dont la valeur vie client dépasse largement le coût d’une bonne réponse, et chaque demande abandonnée risque un avis négatif ou une contestation de paiement. La leçon propre à PrestaShop est simple : vous ne partez pas de zéro — vous possédez déjà un système de fils contextualisé dans Service client → Service client. Activez-le, faites pointer votre page de contact vers lui, détournez les questions prévisibles avec du libre-service, puis ajoutez une couche de gestion de tickets comme Support Revolution dès que le volume transforme « je lis chaque message » en « il me faut un système ». Gardez-le dans la boutique, et le support conserve la seule chose qu’un outil externe laisse de côté : la commande concernée.

FAQ sur le centre d’assistance intégré à la boutique

PrestaShop dispose-t-il déjà d’un centre d’assistance ? Oui — Service client → Service client, piloté par le contrôleur AdminCustomerThreads. Les messages envoyés via votre formulaire de contact deviennent des fils liés au client et, lorsqu’elle est mentionnée, à la commande. La plupart des marchands ne font jamais pointer leur lien « Contactez-nous » vers ce système et utilisent à la place une boîte Gmail partagée. Pour quelques demandes par jour, le simple fait de l’activer est une vraie amélioration sans coût supplémentaire.

Quand faut-il aller au-delà des fils natifs du service client ? À peu près lorsque le volume passe de « je lis chaque message » à « il me faut un système pour que rien ne passe entre les mailles » — autour d’une douzaine de tickets par jour. En dessous, le natif plus une page /contact-us propre suffit, et ajouter un logiciel serait surdimensionné. Au-delà, les éléments manquants (priorités, compteurs SLA, réponses préenregistrées, notes internes, conversion d’e-mails en tickets) commencent à coûter du temps réel et des clients.

Qu’est-ce que le support natif de PrestaShop ne fait pas ? Pas de niveaux de priorité, pas de réponses enregistrées, pas de notes internes réservées aux agents, pas de suivi du délai de réponse/SLA, des pièces jointes client limitées, et pas de réponse par e-mail qui revienne dans la file. Ses deux états « En attente » ne sont pas libellés, vous ne pouvez donc pas distinguer ce qui attend une réponse du client de ce qui attend une action de votre part.

Pourquoi garder le support dans PrestaShop plutôt que d’utiliser un outil SaaS d’assistance ? Parce que le système de fils intégré à la boutique relie automatiquement chaque conversation au client et à la commande. Déplacez le support vers un SaaS externe : vous gagnez des fonctionnalités, mais vous perdez ce contexte de commande — l’agent revient à « quel est votre numéro de commande ? ». Un module qui étend le modèle natif conserve le contexte et ajoute la couche opérationnelle.

Comment réduire le volume de tickets sans recruter ? Détournez les demandes grâce au libre-service : un suivi de commande fonctionnel (définissez l’URL du transporteur avec l’espace réservé @ dans Livraison → Transporteurs afin que les numéros de suivi deviennent des liens cliquables), une vraie FAQ couvrant les 20 questions à l’origine de 80 % du volume, et des pages produit qui anticipent les questions grâce à des tailles précises et des photos claires. Ensuite, analysez chaque mois la répartition des sujets de tickets et corrigez la cause racine de la plus grosse catégorie.

Lectures complémentaires

• Support Revolution — ajoute statuts, priorités, services, pièces jointes et conversion d’e-mails en tickets via IMAP, le tout dans votre back-office.
• Issue Tracker et gestionnaire de FAQ — détournent les questions avant qu’elles n’atteignent le centre d’assistance.
• Le chat en direct augmente-t-il vraiment les ventes — le canal en temps réel qui alimente la file.