CI/CD & E-commerce : Déployer un PrestaShop Headless en automatique avec GitHub Actions

Questions fréquentes

Tout ce que vous devez savoir sur ce sujet.

Qu'est-ce qu'un pipeline CI/CD appliqué au e-commerce ?

Un pipeline CI/CD (Continuous Integration / Continuous Delivery) e-commerce est un ensemble de processus automatisés qui testent, construisent et déploient votre boutique en ligne à chaque modification du code source. Pour PrestaShop, cela signifie qu'un push sur GitHub peut déclencher automatiquement le déploiement vers un environnement de préproduction ou de production, sans intervention manuelle.

Pourquoi choisir GitHub Actions plutôt qu'un autre outil CI/CD ?

GitHub Actions est nativement intégré à GitHub, ce qui évite de gérer un outil tiers comme Jenkins ou CircleCI. Pour un développeur indépendant, les 2 000 minutes mensuelles gratuites sur les dépôts privés couvrent largement les besoins d'un projet PrestaShop. La syntaxe YAML est lisible, la marketplace d'actions réutilisables est très fournie, et la gestion des secrets est native.

Combien coûte la mise en place d'un pipeline CI/CD pour PrestaShop ?

Sur le plan des licences logicielles, le coût est quasi nul : GitHub Actions, Docker et Nginx sont gratuits ou open source. Le vrai investissement est le temps de configuration initiale — comptez entre 1 et 3 jours pour un développeur expérimenté. Sur le long terme, le gain en fiabilité et en temps économisé sur les déploiements rentabilise largement cet investissement dès les premières semaines.

Comment fonctionne l'isolation des environnements prod et preprod avec Docker ?

L'isolation repose sur les réseaux Docker : chaque environnement dispose de son propre réseau interne (ex. ac_network pour la prod, preprod_network pour la preprod). Les conteneurs d'un réseau ne peuvent pas communiquer avec ceux d'un autre réseau sans configuration explicite. Chaque environnement a sa propre base de données MariaDB, sa propre instance Redis et sa propre instance Nuxt — aucune donnée ne peut fuiter d'un environnement à l'autre.

Qu'est-ce qu'un reverse proxy Nginx et pourquoi en avoir besoin avec PrestaShop Headless ?

Un reverse proxy est un serveur intermédiaire qui reçoit les requêtes des clients et les redirige vers le bon service backend. Dans une architecture PrestaShop Headless avec Nuxt 3, Nginx reçoit toutes les requêtes HTTP/HTTPS et les route vers le bon conteneur Nuxt selon le domaine (prod ou preprod). Il gère également la terminaison SSL via Let's Encrypt, la compression gzip et la mise en cache des assets statiques.

Comment sécuriser les variables d'environnement dans GitHub Actions ?

Les variables sensibles (mots de passe, clés API, clés SSH) doivent être stockées dans GitHub Secrets (Settings > Secrets and variables > Actions) et jamais commitées dans le code. Dans le fichier workflow, on les référence avec la syntaxe ${{ secrets.NOM_DU_SECRET }}. Ces valeurs sont masquées dans les logs d'exécution. Pour les variables moins sensibles, on peut utiliser GitHub Variables, qui sont visibles mais non modifiables par les runners non privilégiés.

Comment faire un rollback rapide avec Docker Compose en cas de problème ?

La stratégie la plus simple consiste à tagger les images Docker avec le SHA du commit Git lors du build. En cas de problème en production, on peut revenir à l'image précédente en modifiant le tag dans le docker-compose.yml et en exécutant docker compose up -d. Avec GitHub Actions, on peut également déclencher manuellement un workflow de rollback qui re-déploie le dernier tag stable. L'opération prend moins de 2 minutes.

Le CI/CD est-il adapté aux petites boutiques PrestaShop avec peu de développements ?

Oui, et même particulièrement pour elles. Les petites boutiques n'ont souvent pas de développeur dédié pour surveiller les déploiements — un pipeline automatisé apporte donc une sécurité que les ressources humaines ne peuvent pas garantir. Même une boutique avec seulement quelques mises à jour par mois bénéficie d'un environnement de préproduction pour tester les mises à jour PrestaShop et les nouveaux modules avant de les passer en production.

Quelle est la différence entre intégration continue (CI) et déploiement continu (CD) ?

L'intégration continue (CI) désigne l'automatisation des phases de build et de test à chaque commit : on s'assure que le code ne casse pas les tests existants. Le déploiement continu (CD) va plus loin : il automatise le déploiement du code validé vers un environnement cible (preprod ou prod). Dans la pratique pour PrestaShop, la CI vérifie que le code Nuxt compile et que les tests passent, tandis que la CD se charge de pousser ce code sur le VPS.

Comment éviter le downtime lors d'un redémarrage de conteneur Docker ?

La technique la plus accessible sans orchestrateur (Kubernetes, Swarm) est d'utiliser la directive `restart: unless-stopped` dans Docker Compose et de s'appuyer sur les health checks Docker. On peut aussi adopter une stratégie blue-green simplifiée : on lance le nouveau conteneur en parallèle sur un port alternatif, on vérifie qu'il répond correctement, puis on bascule Nginx vers lui avant d'arrêter l'ancien. Cette approche garantit un downtime de quelques secondes seulement.

GitHub Actions peut-il déployer automatiquement des modules PrestaShop personnalisés ?

Absolument. Le pipeline peut inclure un step qui copie le dossier du module (ex. back-office/modules/ac_base/) vers le VPS via rsync ou scp, puis exécute les commandes PrestaShop CLI pour vider le cache et recharger les modules. On peut même conditionner ce déploiement à la détection de modifications dans le dossier du module via les filtres de paths de GitHub Actions : `paths: ['back-office/modules/**']`.

Comment configurer les variables d'environnement Nuxt 3 pour une architecture headless PrestaShop ?

Dans Nuxt 3, les variables sensibles (clé API PrestaShop) sont déclarées dans nuxt.config.ts via runtimeConfig. La clé privée n'est accessible que côté serveur (server/api/), tandis que les clés préfixées public: sont exposées côté client. Sur le VPS, un fichier .env non versionné contient les valeurs réelles. Nuxt les charge automatiquement au démarrage. Dans GitHub Actions, on génère ce fichier .env à partir des GitHub Secrets lors du step de déploiement.

Peut-on mettre en place un pipeline CI/CD sur un hébergement mutualisé PrestaShop ?

Les hébergements mutualisés sont très limités pour le CI/CD : pas d'accès Docker, pas de clés SSH sur certains plans, pas de contrôle sur les processus. Pour un pipeline GitHub Actions complet, un VPS est indispensable (comptez à partir de 5-10€/mois chez des hébergeurs comme OVH, Hetzner ou Scaleway). Sur mutualisé, on peut se limiter à un déploiement FTP automatisé, mais sans isolation d'environnement et avec des risques significatifs lors des mises à jour.

Quels sont les métriques DORA et pourquoi sont-ils importants pour un e-commerce ?

Les 4 métriques DORA (Google) mesurent la performance d'une équipe DevOps : la fréquence de déploiement, le délai moyen entre un commit et sa mise en production (lead time), le taux d'échec des changements, et le temps moyen de rétablissement après incident (MTTR). Pour un e-commerce, ces indicateurs sont directement corrélés au chiffre d'affaires : un MTTR bas signifie moins de temps de downtime, une fréquence de déploiement élevée signifie des corrections de bugs plus rapides.

Combien de temps faut-il pour mettre en place un pipeline GitHub Actions complet pour PrestaShop ?

Pour un développeur familier avec Docker et Git, comptez environ 2 à 3 jours de travail effectif : une demi-journée pour la configuration des réseaux Docker et du docker-compose.yml, une journée pour la configuration Nginx avec SSL, et une journée pour le fichier workflow GitHub Actions et les tests du pipeline complet. La mise en place d'une stratégie de tests automatisés peut prendre plus longtemps si vous partez de zéro, mais ce n'est pas un prérequis pour commencer.