Expertise PrestaShop

Conseils techniques e-commerce et PrestaShop

Une question ? Contactez Les Vikings

LiveAgent : prérequis techniques PHP 8, MariaDB, Elasticsearch, mod_rewrite

Prérequis pour héberger LiveAgent : PHP 8.2/8.3 (extensions, OPcache), MariaDB utf8mb4, Elasticsearch 8.x, mod_rewrite, staging et monitoring.

Kévin DECQ-CAILLET

|

|

Mis à jour le Lecture : 13 min

Illustration de concepts techniques liés à PHP 8, MariaDB, et Elasticsearch sur un écran d'ordinateur.

Table des matières :

  1. Périmètre technique : ce que couvrent (vraiment) ces prérequis LiveAgent
  2. PHP 8 (8.2/8.3) : extensions indispensables, exécution et réglages qui évitent les tickets “ça rame”
  3. MariaDB : version LTS, InnoDB, charset et garde‑fous anti‑corruption
  4. Elasticsearch : pourquoi l’ajouter, comment le dimensionner, et ce qui casse en premier
  5. mod_rewrite : routing, règles de réécriture et erreurs 403/404 typiques (Apache et équivalents Nginx)
  6. Déploiement propre : staging, sécurité, CI/CD et monitoring (sinon vos prérequis ne valent rien)

Périmètre technique : ce que couvrent (vraiment) ces prérequis LiveAgent

Dans l’écosystème e‑commerce, “LiveAgent” est le plus souvent consommé comme un service externe (SaaS) et intégré côté front via un snippet JS ou un widget. Dans ce cas, vos prérequis serveur se limitent essentiellement à la capacité de votre site (PrestaShop ou autre) à charger ce script sans dégrader le LCP/INP, et à exposer des endpoints de webhooks/API sortants si vous synchronisez des événements. PHP/MariaDB/Elasticsearch/mod_rewrite ne sont alors pas des dépendances “LiveAgent”, mais des briques de votre plateforme.

Le titre de l’article suppose néanmoins un scénario plus “stack applicative” : soit (1) un composant LiveAgent/adjacent auto‑hébergé (proxy, connecteur, middleware, portail support) tournant sur votre infra, soit (2) une base de connaissances / portail client développé en PHP et couplé à une recherche full‑text (Elasticsearch), tout en restant cohérent avec les contraintes habituelles d’une prod PrestaShop. C’est ce périmètre qu’on traite ici, avec des recommandations applicables à 2026 sur Debian 12/Ubuntu 24.04, PHP 8.2/8.3, MariaDB LTS et Elasticsearch 8.x.

Pour éviter les malentendus en cadrage, la question utile est : quel composant vit réellement “chez vous” ?

Scénario Où tourne l’app ? Prérequis PHP/MariaDB/ES/mod_rewrite
Widget LiveAgent SaaS + webhooks LiveAgent (SaaS) Pas de dépendances côté serveur, sauf endpoints sortants/entrants (API/webhooks) et performance front
Portail support / KB client Chez vous (PHP) Oui (PHP + routing), DB si contenu/tickets synchronisés, ES si recherche full‑text
Middleware / connecteur (sync commandes, clients, tickets) Chez vous (PHP/worker) Oui (PHP + DB pour état/queue), ES selon fonctionnalités
Proxy/API gateway (sécurité, IP allowlist, logs) Chez vous (reverse proxy) PHP pas forcément, mais réseau/TLS/journalisation + règles de réécriture selon serveur

Enfin, on parle de prérequis au sens “conditions minimales de fonctionnement en production” : versions, extensions, réglages, droits, réseau, et surtout pièges récurrents (mod_rewrite mal activé, collation incohérente, heap Elasticsearch sous‑dimensionné, etc.). Avant de toucher une prod, vous devez disposer d’un staging fidèle (même version PHP, même engine DB, même type de cache), cf. https://www.expertise-prestashop.fr/2026/08/07/staging-prestashop-creer-un-environnement-docker-fidele-a-la-production/.

Petit rappel “terrain” (utile en France/UE) : un portail support traite presque toujours des données personnelles (identité, email, historique d’échanges, pièces jointes). Même si LiveAgent est SaaS, votre composant auto‑hébergé peut devenir un point de fuite (logs trop verbeux, dumps, exports). D’où l’importance d’un périmètre clair (quelles données transitent, où elles sont stockées, combien de temps, qui y a accès).

PHP 8 (8.2/8.3) : extensions indispensables, exécution et réglages qui évitent les tickets “ça rame”

Sur un déploiement moderne, partez sur PHP 8.3 (ou 8.2 si vous avez une contrainte de compatibilité). Les écarts entre 8.2 et 8.3 (performances, avertissements, etc.) ne sont pas anecdotiques : vous voulez les mêmes versions en CLI et en FPM/Apache pour éviter des bugs “uniquement en cron”. Si vous hébergez ce composant à côté de PrestaShop 9, la cohérence de stack est un vrai avantage (PHP 8.3/Symfony 6.4), cf. https://www.expertise-prestashop.fr/2026/08/11/prestashop-9-guide-de-migration-symfony-6-4-et-php-8-3/

Le point qui casse le plus souvent en PHP 8, ce n’est pas le binaire, c’est l’écosystème d’extensions. Sans présumer des besoins exacts de votre intégration LiveAgent, voici un socle réaliste pour un portail support / middleware PHP :

Besoin Extensions typiques Pourquoi c’est non‑négociable en prod
DB MariaDB pdo_mysql / mysqli latence, pool, gestion erreurs SQL propre
HTTP/API curl, openssl appels sortants (API LiveAgent), TLS
Texte mbstring, intl Unicode, tri/collation, formats, locale FR
Archives zip import/export, pièces jointes compressées
Images gd ou imagick thumbnails, avatars, base de connaissance
Perf opcache coût parsing PHP prohibitif sans cache

À ce socle, vous ajoutez généralement (selon projet) :

  • fileinfo (détection MIME fiable à l’upload, important pour éviter des contournements),
  • xml / dom (flux XML/HTML, imports),
  • bcmath (calculs et formats, parfois requis par des libs),
  • et, côté runtime, la capacité à envoyer des emails (via SMTP applicatif, pas “mail()” en prod).

Côté exécution, évitez les “faux amis” : Apache + modphp reste viable, mais PHP‑FPM (avec Apache en proxyfcgi ou Nginx) donne un contrôle bien plus fin sur la concurrence, la mémoire et l’isolation. Si votre infra est déjà standardisée sur Nginx/PHP‑FPM pour PrestaShop, restez aligné (mêmes patterns d’observabilité, mêmes limites FPM), cf. https://www.expertise-prestashop.fr/2026/08/06/php-fpm-comprendre-le-flux-dexecution-avec-nginx-et-apache/

“The OPcache extension improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request.” — PHP Manual (OPcache), https://www.php.net/manual/en/book.opcache.php

Concrètement, sans OPcache, vous payez du CPU sur chaque requête (parsing + compilation), ce qui est exactement le genre de dette “invisible” qui se transforme en tickets support. En prod, visez au minimum : opcache.enable=1, opcache.memory_consumption=128 (voire 256+ si codebase lourde), opcache.interned_strings_buffer=16, opcache.max_accelerated_files dimensionné à votre nombre de scripts, et un opcache.validate_timestamps=0 si vous avez un déploiement atomique (symlink release) ; sinon, laissez validate_timestamps=1 avec un revalidate_freq raisonnable.

Quelques réglages “anti‑tickets” qui reviennent souvent sur un portail support (uploads, exports, jobs) :

  • Uploads : alignez upload_max_filesize et post_max_size sur la taille réelle des pièces jointes acceptées (et imposez la limite côté app). Les incidents typiques : “la PJ disparaît” (limite PHP), ou “504” (timeout proxy).
  • Temps d’exécution : préférez déplacer les tâches lourdes (sync, import, reindex) vers des workers CLI plutôt que d’augmenter aveuglément max_execution_time.
  • FPM : dimensionnez pm.max_children selon RAM réelle et consommation moyenne par process. Exemple de règle simple : si un process PHP consomme ~120–180 Mo en pic, 20 enfants = 2,4–3,6 Go uniquement pour PHP (sans OS, sans cache, sans ES). D’où l’intérêt d’un staging mesuré.
  • Erreurs : en prod, display_errors=0, logs centralisés, et séparation claire entre logs applicatifs et logs d’accès.

Mini‑scénario fréquent : vous ajoutez un “portail support” sur le même serveur que la boutique. Tout fonctionne en heures creuses, puis à 10h30 les agents importent un CSV (ou déclenchent une sync), et subitement la boutique “rame”. La cause n’est pas LiveAgent : c’est la concurrence CPU/RAM entre FPM (portail + boutique), MariaDB et Elasticsearch. Le prérequis réel est donc une enveloppe de ressources (ou une isolation par VM/containers) et des limites FPM par pool (un pool pour la boutique, un pool pour le portail), plutôt qu’un simple “installer PHP 8.3”.

MariaDB : version LTS, InnoDB, charset et garde‑fous anti‑corruption

Pour MariaDB, privilégiez une branche LTS (ex. 10.11 LTS, ou la LTS fournie par votre distribution si vous maîtrisez les backports). L’objectif est la stabilité et le support sécurité, pas la dernière feature. Si vous cohabitez avec une base PrestaShop, isolez au minimum : un schéma (database) dédié, un utilisateur dédié, et des limites de privileges strictes. Si vous êtes en phase de migration MySQL → MariaDB, ne partez pas “à l’instinct” : charset, collation et engine sont des sujets à cadrer, cf. https://www.expertise-prestashop.fr/2026/07/29/prerequis-systeme-migration-mysql-vers-mariadb-innodb-et-collation-utf-8/

Le prérequis le plus important en 2026 : UTF‑8 partout en utf8mb4 (base, tables, connexions), et une collation cohérente. Le mismatch (ex. tables en utf8_general_ci, connexion en utf8mb4) produit des tri incohérents et, pire, des erreurs au runtime sur certains caractères (emoji, apostrophes typographiques). Pour un portail FR, vous pouvez opter pour utf8mb4_unicode_ci (compat large) ou une collation plus récente si vous maîtrisez les impacts (tri, index). Dans tous les cas : imposez character_set_server=utf8mb4 et collation_server=..., et configurez explicitement le charset côté PDO (SET NAMES utf8mb4).

Point d’attention “support” : les contenus utilisateurs (messages, signatures email, copier‑coller depuis Word/Outlook) contiennent souvent des caractères non‑ASCII (guillemets typographiques, tirets cadratins). Si vous voyez des “?” ou des erreurs à l’enregistrement, ce n’est pas un bug fonctionnel : c’est presque toujours un problème d’encodage ou de collation (ou un champ trop court).

Côté InnoDB, la performance “perçue” vient surtout de la mémoire. Un ordre de grandeur simple (à adapter) : innodb_buffer_pool_size ≈ 60–70% de la RAM si le serveur est dédié DB ; sinon beaucoup plus bas si la DB cohabite avec PHP/Elasticsearch. Sur des workloads support (tickets, messages), vous avez souvent beaucoup d’écritures et des index sur dates/statuts : surveillez les slow queries, l’indexation et les locks. Pour une méthodologie exploitable (slow query log, index, EXPLAIN), reprenez la démarche de https://www.expertise-prestashop.fr/2026/07/31/prestashop-mysql-analyser-slow-query-log-et-optimiser-index/

Deux garde‑fous pragmatiques qui évitent des incidents pénibles :

  • Clés et index : un portail support stocke vite “beaucoup de petits objets” (messages, événements, statuts). Sans index sur les colonnes filtrées (date, état, agent, client), vous fabriquez des scans et des locks. Ajoutez les index après observation (slow log), pas au hasard.
  • Transactions : si vous faites de la synchro (ex. commande → ticket), mettez les écritures “métier” en transaction côté DB, et traitez l’indexation Elasticsearch à part (voir section suivante) pour éviter de tenir des locks “le temps d’un appel réseau”.

Enfin, ne confondez pas “ça marche” et “c’est exploitable”. En prod, vous devez pouvoir restaurer : sauvegardes logiques (mysqldump) + physiques (mariabackup) selon votre RPO, tests de restore, et un plan de rotation. Pour les grosses volumétries (pièces jointes + historique long), évitez de stocker des blobs en DB : préférez un stockage objet/S3 compatible, ou au minimum un filesystem avec quotas et monitoring.

Checklist “restaurabilité” (souvent oubliée) :

  • un test de restauration trimestriel sur un serveur isolé (preuve que les dumps sont exploitables),
  • une vérification d’intégrité (au minimum, restauration + requêtes de contrôle),
  • et une séparation des rôles : le compte applicatif ne doit pas avoir les droits d’administration (DROP/GRANT).

Elasticsearch : pourquoi l’ajouter, comment le dimensionner, et ce qui casse en premier

Elasticsearch n’est pas un “bonus »: dès que vous avez une recherche plein texte sur tickets, articles de base de connaissance, ou un portail client avec autocomplétion, l’écart de qualité/perf avec du SQL LIKE devient massif. Le point clé est de savoir ce que vous indexez (tickets seulement ? KB + tickets + clients ?) et comment (synchrone, asynchrone, full reindex nocturne, incremental). Sans stratégie, vous allez avoir de l’incohérence (DB vs index) et des tickets “je ne retrouve pas…”.

“Elasticsearch is a distributed, RESTful search and analytics engine capable of addressing a growing number of use cases.” — Elastic documentation, https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html

En 8.x, Elasticsearch active la sécurité par défaut (TLS, auth). Ne désactivez pas ça en prod “pour aller vite” : isolez le cluster sur un réseau privé, exposez uniquement via un reverse proxy si nécessaire, et utilisez des API keys avec des rôles minimaux. Côté sizing, la règle opérationnelle reste : heap JVM ~50% de la RAM (sans dépasser ~31–32 Go de heap pour garder les compressed oops), le reste pour le filesystem cache. Pour un usage support “classique” (quelques centaines de milliers de tickets + KB), un nœud 2 vCPU / 8–16 Go RAM / SSD NVMe peut suffire ; mais l’indexation initiale et les agrégations (stats, facettes) sont les premiers à saturer CPU/heap.

Un modèle d’indexation robuste (qui évite les incohérences) ressemble souvent à ceci :

  1. Écriture source de vérité en MariaDB (ticket/message).
  2. Émission d’un événement (table outbox, queue, ou cron qui détecte les changements).
  3. Indexation asynchrone dans Elasticsearch (worker), avec retry et dead‑letter si échec.
  4. Possibilité de rebuild complet (reindex) sans immobiliser l’app (index alias + swap).

Ce pattern est particulièrement utile si votre portail est en France/UE avec des contraintes de disponibilité : une panne Elasticsearch ne doit pas bloquer la création d’un ticket (vous acceptez une recherche dégradée temporairement, pas une perte de service).

Sur la partie “qualité de recherche”, votre prérequis n’est pas que matériel : c’est l’analyse linguistique. Pour du français, configurez un analyzer adapté (stemming, stopwords) et testez les requêtes avec vos vrais cas (accents, fautes, pluriels). Exemple concret à valider sur vos données : un client tape “retractation” (sans accent) et doit trouver “rétractation” ; un agent cherche “remboursements” et veut retrouver “remboursement”.

Ce qui casse en premier, en pratique :

  • Disque : l’index grandit, les watermarks déclenchent des protections, et soudain plus d’indexation (symptôme : backlog de jobs).
  • Heap/GC : trop peu de RAM → GC fréquent → latence de recherche, timeouts côté app.
  • Mapping : champs mal typés (dates/numériques) → requêtes lentes, agrégations fausses.
  • Sécurité/réseau : certificats expirés, auth mal gérée, ES exposé publiquement par erreur.

Si votre besoin est davantage “search‑as‑you‑type” et tolérance aux fautes qu’un moteur d’analytics, comparez aussi les alternatives (Meilisearch/Algolia) pour éviter de porter l’overhead Elastic sans bénéfice, cf. https://www.expertise-prestashop.fr/2026/07/30/moteur-de-recherche-marketplace-meilisearch-elasticsearch-ou-algolia/

mod_rewrite : routing, règles de réécriture et erreurs 403/404 typiques (Apache et équivalents Nginx)

Si vous servez votre portail support via Apache, mod_rewrite est souvent requis dès que vous avez des routes “propres” (sans index.php?route=...). En pratique, les incidents viennent rarement des règles elles‑mêmes, mais d’un module non chargé, d’un AllowOverride None, ou d’un .htaccess ignoré au niveau du vhost.

“The modrewrite module uses a rule-based rewriting engine, based on a PCRE regular-expression parser, to rewrite requested URLs on the fly.” — Apache HTTP Server Documentation, https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html

Checklist Apache rapide (Debian/Ubuntu) : activer le module (a2enmod rewrite), redémarrer proprement, puis vérifier le vhost : AllowOverride All (ou au minimum AllowOverride FileInfo si vous savez ce que vous faites), et désactiver MultiViews si vous utilisez des routes (sinon négociation de contenu et 404 bizarres). Exemple de bloc vhost minimaliste pour un portail support sur /support (en supposant un front controller public/index.php) :

<VirtualHost *:443>
  ServerName support.example.com
  DocumentRoot /var/www/liveagent-portal/public

  <Directory /var/www/liveagent-portal/public>
    AllowOverride All
    Options -MultiViews
    Require all granted
  </Directory>

  # TLS configuration omitted
</VirtualHost>

Deux erreurs typiques “après mise en ligne” :

  • 404 sur toutes les routes sauf la home : .htaccess non lu (AllowOverride), ou rewrite non activé.
  • 403 sur des assets (CSS/JS) : droits filesystem, ou directives <Directory> trop restrictives (surtout après un déploiement par CI qui change owner/group).

Sur Nginx, vous ne “traduisez” pas mod_rewrite ligne à ligne : vous appliquez le pattern try_files vers le front controller, et vous limitez l’accès à ce qui ne doit pas être public (config, cache, dumps). Typiquement : location / { try_files $uri /index.php$is_args$args; } + un location ~ \.php$ vers PHP‑FPM. Si vous vous prenez des 403 après déploiement, c’est souvent des droits Unix (owner/group), SELinux/AppArmor, ou une règle du WAF ; pour une grille de diagnostic pragmatique, voyez https://www.expertise-prestashop.fr/2026/08/06/erreur-403-forbidden-causes-et-depannage-etape-par-etape/

Enfin, si vous faites cohabiter boutique + portail support sur le même domaine (ex. /support), testez explicitement :

  • collisions de routes (réécritures PrestaShop vs portail),
  • règles de cache (CDN, reverse proxy) : un portail support est souvent non‑cacheable côté public,
  • et les en‑têtes de sécurité (CSP, X‑Frame‑Options) qui peuvent casser un widget ou une page d’auth.

Déploiement propre : staging, sécurité, CI/CD et monitoring (sinon vos prérequis ne valent rien)

Un déploiement “propre” en 2026, c’est au minimum : staging = prod (versions + conf), déploiement reproductible (CI/CD), et un rollback. Sur un portail support PHP + MariaDB + Elasticsearch, Docker Compose est souvent le bon compromis pour figer les versions et éviter les dérives d’environnement (à condition de maîtriser le stockage persistant). Si vous avez besoin d’un socle pour orchestrer des services, reprenez les patterns de https://www.expertise-prestashop.fr/2026/07/31/docker-compose-orchestrer-des-services-multi-conteneurs-en-production/

Côté CI/CD, un pipeline “réaliste” pour éviter les surprises inclut généralement :

  • composer install en mode prod (sans dépendances dev), build d’assets si nécessaire,
  • exécution de tests min (lint + tests unitaires critiques),
  • migration DB contrôlée (avec fenêtre de maintenance si migration bloquante),
  • warmup de cache applicatif,
  • et, côté recherche, un job de reindex (complet ou incrémental) déclenchable et observable.

Côté sécurité, évitez la vision “ça ne gère que du support”. Un portail client manipule des identités, des emails, parfois des pièces jointes, donc des surfaces d’attaque classiques : upload, XSS, IDOR, fuite d’API keys, etc. Votre prérequis réel est un durcissement serveur + un contrôle des dépendances. Pour le hardening d’un serveur PHP/Symfony (principes transposables), cf. https://www.expertise-prestashop.fr/2026/08/07/symfony-securiser-un-serveur-php-avec-hardening-et-gestion-cve/ ; et pour une approche SBOM/WAF/CI, cf. https://www.expertise-prestashop.fr/2026/08/07/prestashop-securiser-apis-et-modules-avec-sbom-waf-et-ci-cd/

Pour ancrer ça dans des recommandations largement reconnues : OWASP Top 10 place Broken Access Control en tête des risques applicatifs (un classique des portails clients mal cloisonnés). Source : https://owasp.org/Top10/ (OWASP Top 10, 2021). C’est directement pertinent ici (tickets consultables par mauvaise personne, pièces jointes accessibles via URL devinable, endpoints d’API trop permissifs).

Enfin, sans monitoring, vous allez diagnostiquer “à la main” en incident, donc trop tard. Au minimum : métriques système (CPU/RAM/disk/IO), métriques PHP‑FPM (status page, saturation), DB (connections, slow queries), Elasticsearch (heap, GC, queue, rejected requests), plus une centralisation logs. Netdata est une solution rapide à activer pour un premier niveau de visibilité, cf. https://www.expertise-prestashop.fr/2026/08/06/netdata-activer-et-configurer-les-collectors-pour-monitoring-temps-reel/ ; et si vous avez déjà Prometheus en place, standardisez vos alertes (heap > 75%, disk watermark Elastic, FPM max_children atteint, etc.), cf. https://www.expertise-prestashop.fr/2026/08/05/prometheus-configuration-des-alertes-metriques-et-requetes-promql/

Checklist opérationnelle (à copier dans votre runbook)

  • PHP 8.2/8.3 : OPcache activé, extensions validées, limites FPM dimensionnées, même version en CLI et web.
  • MariaDB LTS : utf8mb4 partout, InnoDB correctement dimensionné, sauvegardes testées, slow log exploité.
  • Elasticsearch 8.x : heap/RAM cohérents, sécurité activée, stratégie d’indexation (rebuild + incremental), analyzers FR testés.
  • mod_rewrite / routing : module chargé, AllowOverride correct, MultiViews désactivé, règles anti‑fuite (deny fichiers sensibles).
  • Staging + CI/CD : déploiement reproductible, migrations DB contrôlées, reindex Elastic scripté.
  • Observabilité : dashboards + alertes, rotation logs, traçage des erreurs applicatives.

Si vous cherchez une base de configuration serveur cohérente avec un écosystème PrestaShop (Nginx, PHP‑FPM, MariaDB, Redis), le guide suivant sert de référence de stack et de terminologie : https://www.expertise-prestashop.fr/2026/08/11/serveur-dedie-prestashop-config-nginx-php-fpm-mariadb-redis/

À lire aussi