Pourquoi un historique de code ne protège pas seul votre boutique PrestaShop

Ce que Git voit, et ce qu’il ne voit pas

Git suit le contenu des fichiers : thème, modules custom, classes surchargées, traductions exportées. Quand une équipe parle de « code propre », elle parle souvent de cet espace-là, et il est effectivement bien couvert par un dépôt soigné.

Mais une boutique PrestaShop s’appuie aussi sur des éléments que Git n’enregistre pas : les réglages stockés en base (ps_configuration), l’état des modules installés, les règles panier, les transporteurs, les taxes, les images produits et le cache Smarty. Deux environnements peuvent avoir exactement le même code et se comporter différemment parce que leur base diffère.

C’est cette zone invisible qui provoque le plus d’incidents : un module activé en local mais pas en production, une variable d’environnement absente, un cache non vidé après une mise à jour. Le commit est parfait, la boutique casse quand même.

Les risques d’un déploiement piloté uniquement par Git

Le premier risque est de croire qu’un merge réussi équivaut à une boutique fonctionnelle. Un pipeline peut afficher un voyant vert alors que le tunnel de commande renvoie une erreur, parce que les tests automatiques ne reproduisent pas le parcours d’achat réel avec les modules de la production.

Le deuxième risque concerne la base de données et les overrides. Une surcharge de template écrite il y a deux ans peut entrer en conflit avec une mise à jour de module sans qu’aucun fichier versionné ne signale le problème. La régression n’apparaît qu’au moment où un client ajoute un produit au panier.

Le troisième risque est humain : sans étape de validation visible, la personne qui pousse le code et celle qui décide de publier sont souvent la même, sous pression, sans recul. La trace technique existe, mais la preuve métier — « le paiement fonctionne » — manque.

La méthode : garder Git, ajouter une validation métier

L’idée n’est pas de remplacer Git mais de le compléter. On conserve le dépôt comme source de vérité du code, et on ajoute une preview construite à partir de ce code, avec une copie représentative de la base et des modules de la production.

Sur cette preview, on vérifie ce que Git ne peut pas garantir : la page produit s’affiche, le panier accepte un article, un transporteur apparaît, le paiement de test passe, l’email de confirmation part. Ces contrôles transforment un commit en preuve exploitable.

La publication n’intervient qu’ensuite, après une validation humaine explicite. DriftOps relie ces étapes — dépôt, preview, contrôles, décision — pour qu’un changement PrestaShop reste traçable de bout en bout, sans imposer de manipulation serveur.

Versionnage seul vs versionnage + preview validée

La méthode classique s’arrête au déploiement du code : on pousse, on synchronise les fichiers, on vide éventuellement le cache, et on espère que la base suit. Elle fonctionne sur une petite correction isolée, mais expose la production dès qu’un module ou un réglage entre en jeu.

L’approche complétée par une preview validée déplace la vérification avant la mise en ligne. Le code reste versionné, mais la boutique est observée dans des conditions proches du réel avant d’être exposée aux clients.

Un cas concret en agence PrestaShop

Une agence corrige un module de livraison pour un client. Le diff est minimal, le code passe la revue, le commit est propre. Sur la preview construite à partir de ce commit, le transporteur disparaît pourtant du panier pour les commandes multi-colis.

Le problème ne venait pas du code mais d’une règle de transporteur configurée en base, absente de l’environnement de test initial. Sans preview alimentée par une copie réaliste, l’incident serait apparu en production, un jour de forte commande.

Avec une validation visible, l’agence repère la régression, ajuste la configuration, revalide, puis publie. Le client reçoit une preuve — un lien de preview fonctionnel — au lieu d’une promesse.

Checklist : ce que Git ne couvre pas et qu’il faut vérifier

Avant chaque publication PrestaShop, complétez le contrôle du code par une vérification de la boutique réelle.

• Page produit : affichage, déclinaisons, prix et stock corrects.
• Panier : ajout, mise à jour des quantités, transporteurs disponibles.
• Tunnel de commande : adresse, livraison, paiement de test, confirmation.
• Emails : confirmation de commande et notifications partent bien.
• Modules : ceux touchés par le changement sont actifs et configurés.
• Cache Smarty et assets : purgés ou reconstruits après mise à jour.
• Back office : accessible, sans erreur sur les pages clés.
• Rollback : version saine identifiée avant de publier.

Mesurer que le workflow devient plus fiable

Le bon indicateur n’est pas le nombre de commits, mais le nombre d’incidents évités avant la production. Suivez combien de régressions sont détectées en preview plutôt qu’en boutique vivante : ce ratio doit s’inverser avec le temps.

Observez aussi le délai entre la demande de changement et la publication sereine, et la fréquence des corrections en urgence. Quand l’équipe sait quoi tester et qui valide, ces deux chiffres baissent nettement.

Conclusion : Git pour l’histoire, la preview pour la preuve

Git reste irremplaçable pour suivre, relire et annuler des modifications de code. Mais une boutique PrestaShop se juge sur sa capacité à vendre, pas sur la propreté de son historique.

En ajoutant une preview validée et une décision humaine avant publication, vous couvrez la zone que Git ne voit pas : la base, les modules, le cache et le parcours d’achat. DriftOps relie ces étapes sans transformer votre équipe en équipe DevOps.