Étude de cas
Comment La Cité des Nuages détecte les régressions avant ses clients
Deux fois par jour et après chaque déploiement, une suite end-to-end valide la boutique contre sa préproduction — avec de la régression visuelle sur les pages qui comptent.
La boutique
La Cité des Nuages est un marchand PrestaShop belge francophone, avec un catalogue riche, des modules custom et un environnement de préproduction protégé par une HTTP Basic Auth et un bandeau de consentement RGPD. Le genre de configuration qui rendait le test end-to-end automatisé pénible.
Le problème
Chaque mise en production comportait un risque de régression silencieuse quelque part dans le FrontOffice : tunnel invité cassé, page de module renvoyant une 500, décalage visuel sur la liste des marques. Passer manuellement par tous les parcours critiques après chaque déploy n'était pas tenable — et lorsque la vérif était sautée, les clients trouvaient le bug avant l'équipe.
Le dispositif avec PrestaFlow
Un workflow GitHub Actions déclenché sur repository_dispatch: prod-deploy et sur un schedule (2×/jour, UTC). PrestaFlow tourne contre la préprod — jamais contre la production.
Une suite par module dans un strategy.matrix avec fail-fast: false : catalogue, tunnel invité, compte client, pages Marques, cartes cadeaux, produit en précommande. Chaque suite tourne sur un runner frais — un navigateur frais — pour qu'un test connecté n'hérite pas d'un panier invité.
Des presets HTTP pilotés par variables d'environnement : PRESTAFLOW_BASIC_USER/_PASS pour la préprod, PRESTAFLOW_COOKIES pour neutraliser le bandeau RGPD en une ligne de JSON, un User-Agent réaliste pour ne pas se battre avec un filtre anti-bot.
Régression visuelle sur les pages critiques — accueil, liste des marques, page carte cadeau, fiche produit. La baseline est gelée dans actions/cache avec un salt (VISUAL_BASELINE_VERSION) : rafraîchir la baseline après une évolution voulue devient un simple bump de variable.
Chaque page critique est capturée à trois tailles d'écran — desktop (1920×1080), tablette (768×1024), mobile (375×812) — via un second axe du strategy.matrix. Chaque combinaison suite × taille a sa propre baseline, donc une régression qui ne touche que le mobile n'est pas noyée dans la comparaison desktop.
Ce que chaque run publie
Un rapport JUnit XML consommé par mikepenz/action-junit-report avec require_tests: true. Si le navigateur ne démarre pas sur un runner froid et qu'aucun test ne s'est exécuté, le check part au rouge au lieu de passer au vert silencieusement.
Un Job Summary directement sur la page du run : un tableau markdown de chaque checkpoint visuel avec son statut pass/fail et son score de similarité, généré depuis visual-results.json.
Le rapport HTML complet de régression visuelle — référence, actuel, diff côte à côte pour chaque checkpoint — publié sur GitHub Pages depuis un dépôt public compagnon. Toute l'équipe peut ouvrir le lien, sans télécharger d'artifact.
Le résultat
Déployer n'est plus un saut dans le vide. Quand quelque chose change visiblement sur une page surveillée, la CI l'attrape — avec une capture — avant que personne n'ouvre la boutique. Quand un parcours critique casse, le check part au rouge dans l'heure, pas au prochain email client. L'équipe déploie en continu, avec la confiance qu'elle réservait auparavant aux releases hebdomadaires planifiées.
Pour aller plus loin
- ➜ Presets HTTP — Basic Auth, cookies, User-Agent.
- ➜ Régression visuelle — l'API des checkpoints et la gestion de la baseline.
- ➜ GitHub Actions — patterns CI — les patterns exacts utilisés dans ce dispositif.
Essayez sur votre boutique
PrestaFlow fonctionne contre n'importe quel environnement PrestaShop 1.7 → 9. Commencez par le guide d'installation.