Un monorepo (dépôt monolithique) est une architecture de gestion de code source où plusieurs projets, applications et bibliothèques partagées coexistent dans un seul dépôt Git, gérés par des outils d'orchestration comme Nx, Turborepo ou Lerna qui optimisent les builds et les tests en fonction du graphe de dépendances.
Les monorepos ont gagné. Les équipes front-end qui gèrent plusieurs applications — un site marketing, un dashboard admin, une app client, un portail partenaire — les regroupent dans un seul dépôt. C'est plus simple pour partager du code, plus cohérent pour le design system, plus efficace pour les mises à jour transversales.
Mais pour le test visuel, c'est un cauchemar logistique. Pas parce que le test visuel ne fonctionne pas en monorepo. Il fonctionne très bien. Le problème, c'est qu'il fonctionne trop : un changement dans un package partagé déclenche potentiellement des tests visuels sur tous les projets qui en dépendent. Et quand votre monorepo contient 15, 30 ou 50 projets, "tester tout à chaque commit" n'est plus une option.
Le problème fondamental : le graphe de dépendances
Dans un monorepo, les projets ne sont pas indépendants. Ils partagent des packages : un design system, une bibliothèque d'utilitaires, des composants communs, des configurations partagées. Ces dépendances forment un graphe — et c'est ce graphe qui rend le test visuel complexe.
Prenons un exemple concret. Vous avez un package "ui-components" qui contient vos boutons, formulaires et composants de navigation. Ce package est utilisé par 12 applications dans votre monorepo. Vous modifiez le padding d'un bouton dans "ui-components". Visuellement, ce changement affecte potentiellement les 12 applications. Chaque page qui contient un bouton pourrait avoir un rendu différent.
Si vous lancez des tests visuels sur les 12 applications, vous capturez potentiellement des centaines de screenshots. La pipeline CI/CD prend 45 minutes. Les développeurs attendent. Et si l'un des tests échoue — un faux positif lié à un problème de rendu headless — c'est le développeur du package "ui-components" qui doit investiguer un échec dans une application qu'il ne connaît même pas.
C'est insoutenable. Et c'est exactement ce qui se passe dans les monorepos qui n'ont pas de stratégie de test visuel.
Tester ce qui a changé, pas tout : le principe d'affectation
La première règle du test visuel en monorepo est simple en théorie, complexe en pratique : ne tester que ce qui est affecté par le changement.
Les outils de monorepo modernes — Nx et Turborepo en tête — savent calculer le graphe de dépendances et identifier les projets "affectés" par un changement. Quand vous modifiez un fichier dans le package "ui-components", Nx peut vous dire que les applications A, C, F et K dépendent de ce package, mais pas B, D et les autres.
C'est la base. Mais pour le test visuel, ce n'est pas suffisant. Parce que "l'application A dépend de ui-components" ne signifie pas que toutes les pages de l'application A utilisent le composant modifié. Si vous avez changé le bouton, seules les pages qui contiennent un bouton sont affectées. Les pages qui n'en contiennent pas sont stables.
Le test visuel intelligent en monorepo opère donc à deux niveaux de filtrage. Premier niveau : quels projets sont affectés par le changement, selon le graphe de dépendances. Deuxième niveau : quelles pages ou quels composants de ces projets utilisent réellement l'élément modifié.
Le premier niveau est résolu par les outils de monorepo. Le deuxième niveau est beaucoup plus difficile — il nécessite soit une analyse statique du code (quelles pages importent quel composant), soit un mapping explicite maintenu par l'équipe (ce composant est utilisé sur ces pages).
La réalité des packages partagés
Les packages partagés sont la force et la faiblesse du monorepo. Ils permettent la cohérence : un seul design system, une seule source de vérité pour les composants visuels. Mais ils créent aussi un effet de blast radius considérable.
Il y a trois types de packages partagés qui posent des problèmes spécifiques au test visuel.
Les packages de composants UI. C'est le cas le plus évident. Un changement dans un bouton, un formulaire ou une modale affecte visuellement toutes les pages qui les utilisent. Le blast radius est proportionnel à la popularité du composant. Un composant de layout utilisé partout (Header, Footer, Sidebar) a un blast radius maximal.
Les packages de styles et de tokens. Un changement dans les design tokens — couleurs, espacements, typographies — est souvent invisible dans le graphe de dépendances traditionnel. Si vous modifiez la couleur primaire dans votre fichier de tokens, le graphe de dépendances voit un changement dans le package "design-tokens". Mais ce changement affecte visuellement tout : chaque bouton primaire, chaque lien, chaque élément accentué dans toutes les applications. Le blast radius est total.
Les packages d'utilitaires avec side effects visuels. Moins évidents : les fonctions utilitaires qui formatent des dates, tronquent du texte ou calculent des layouts. Un changement dans une fonction de troncature de texte — passer de 100 à 80 caractères max — a un impact visuel direct sur tous les composants qui l'utilisent. Mais le graphe de dépendances ne sait pas que c'est un changement "visuel".
Les stratégies qui fonctionnent
Après avoir observé des dizaines d'équipes gérer le test visuel en monorepo, voici les stratégies qui produisent les meilleurs résultats.
Stratégie 1 : le test visuel par couches
Organisez vos tests visuels en trois couches avec des fréquences d'exécution différentes.
La couche composant. Testez chaque composant du design system en isolation, via Storybook ou équivalent. Ces tests s'exécutent uniquement quand le package de composants change. Ils sont rapides (quelques minutes) et protègent la librairie elle-même. C'est le premier filet, celui décrit dans l'article sur les tests visuels dans les design systems.
La couche page — affectée. Testez les pages des applications affectées par le changement, identifiées par le graphe de dépendances. Ces tests s'exécutent sur chaque pull request, mais uniquement sur les projets affectés. Ils sont le cœur de votre stratégie.
La couche complète. Testez toutes les pages de toutes les applications. Cette couche ne s'exécute pas sur chaque PR — c'est trop coûteux. Exécutez-la une fois par jour (nightly), ou avant chaque release. Elle attrape les régressions que le graphe de dépendances n'a pas su prédire.
Stratégie 2 : le mapping composant-page explicite
Maintenez un fichier de configuration qui associe chaque composant partagé aux pages qui l'utilisent. Quand le composant Button change, le fichier indique que les pages /login, /signup, /checkout et /settings de l'application A utilisent ce composant. Seules ces pages sont testées.
Ce mapping est fastidieux à maintenir manuellement. Mais il peut être généré automatiquement par une analyse statique du code — en parcourant les imports de chaque page et en remontant les dépendances. Nx propose des plugins qui facilitent ce type d'analyse.
L'avantage est considérable : au lieu de tester 200 pages de l'application A quand un composant change, vous n'en testez que 12. La pipeline passe de 30 minutes à 3 minutes.
Stratégie 3 : la baseline partagée avec override
Dans un monorepo avec un design system commun, les baselines visuelles (les screenshots de référence) ont une particularité : les composants partagés ont le même rendu dans toutes les applications (en théorie). Vous pouvez donc maintenir une baseline du design system au niveau du package, et ne re-capturer les baselines au niveau des applications que quand le contexte d'intégration change.
Concrètement : quand vous modifiez le composant Button, vous mettez à jour la baseline du Button dans le package ui-components. Les applications qui utilisent le Button héritent de cette nouvelle baseline. Seules les applications où le Button a un rendu différent en contexte (à cause de CSS spécifique, de thème, ou d'override) ont besoin de leurs propres baselines.
Les erreurs classiques à éviter
Tester tout, tout le temps. C'est la réaction naturelle, et c'est la pire. Vos pipelines deviennent lentes, vos développeurs ignorent les résultats parce qu'il y a trop de bruit, et les vrais bugs se noient dans les faux positifs. Le test visuel en monorepo doit être chirurgical.
Ignorer le graphe de dépendances. Certaines équipes configurent leurs tests visuels indépendamment de l'outil de monorepo. Résultat : les tests ne savent pas quels projets sont affectés et testent soit tout, soit rien. Intégrez votre outil de test visuel avec Nx ou Turborepo. Utilisez leurs commandes "affected" pour déclencher les bons tests.
Mettre toutes les baselines dans un seul dossier. Les baselines visuelles doivent vivre à côté des projets qu'elles protègent. Si vous centralisez toutes les baselines dans un dossier racine, vous perdez la granularité : vous ne savez plus quelle baseline correspond à quel projet, et le nettoyage des baselines obsolètes devient impossible.
Négliger le versioning des baselines lors des mises à jour transversales. Quand vous modifiez un design token qui affecte tous les projets, toutes les baselines doivent être mises à jour simultanément. Si vous les mettez à jour projet par projet dans des PRs séparées, vous créez une fenêtre pendant laquelle certains projets ont les nouvelles baselines et d'autres les anciennes. Les tests deviennent incohérents.
Le rôle de la CI/CD dans le test visuel monorepo
La configuration CI/CD est critique. Votre pipeline doit être capable de trois choses.
Premièrement, calculer l'ensemble des projets affectés par le changement. C'est le travail de Nx (nx affected) ou Turborepo (turbo run --filter). Cette étape détermine le périmètre des tests.
Deuxièmement, paralléliser les tests visuels par projet. Si trois applications sont affectées, lancez les tests des trois applications en parallèle, pas en séquence. Chaque application a son propre jeu de baselines et son propre rapport de résultats. La parallélisation est la seule façon de maintenir des temps de pipeline acceptables.
Troisièmement, agréger les résultats et bloquer la PR si nécessaire. Même si les tests sont parallélisés, le verdict final doit être unique : la PR passe ou elle ne passe pas. Si l'application A a une régression visuelle et pas les autres, la PR est bloquée. Le développeur sait exactement quelle application est affectée et peut investiguer.
Quand le no-code simplifie tout
Les outils de test visuel basés sur le code — Playwright, Cypress avec des plugins visuels — s'intègrent bien dans un monorepo parce qu'ils vivent dans le même dépôt, à côté du code qu'ils testent. Mais ils ajoutent du code de test à maintenir, des configurations par projet, des scripts de CI/CD spécifiques.
Les outils no-code comme Delta-QA proposent une approche différente. Plutôt que de tester depuis le code source, ils testent depuis les URLs déployées. Vous configurez les URLs de chaque application, l'outil capture les screenshots et compare avec les baselines. Le monorepo n'est plus un facteur de complexité — l'outil ne voit que des URLs, pas des packages.
L'inconvénient : vous ne bénéficiez pas du graphe de dépendances pour filtrer les tests. L'avantage : la configuration est instantanée, il n'y a pas de code de test à maintenir, et le test est indépendant de l'architecture du dépôt. Pour les équipes qui n'ont pas de développeurs dédiés aux tests, c'est souvent le bon compromis.
FAQ
Nx ou Turborepo est-il meilleur pour le test visuel en monorepo ?
Nx a un avantage significatif grâce à son graphe de dépendances plus détaillé et ses plugins d'analyse statique. La commande nx affected identifie précisément les projets impactés, et les executors Nx permettent d'intégrer des tâches de test visuel dans le graphe de tâches. Turborepo est plus simple mais offre un filtrage moins granulaire.
Comment gérer les baselines quand un design token change et affecte tout ?
Traitez-le comme une mise à jour transversale. Créez une PR dédiée qui modifie le token et met à jour toutes les baselines affectées en une seule opération. Exécutez la couche complète de tests visuels, approuvez les changements attendus en lot, et mergez. Ne fragmentez jamais une mise à jour de token en plusieurs PRs — c'est la porte ouverte aux incohérences.
Combien de temps un test visuel devrait-il prendre dans une pipeline monorepo ?
En ciblant uniquement les projets affectés : moins de 10 minutes pour une PR standard qui touche un seul projet. Moins de 20 minutes pour un changement dans un package partagé affectant 3 à 5 projets. Si vos tests prennent plus de 30 minutes sur une PR, votre stratégie de filtrage est insuffisante. La couche complète (nightly) peut prendre plus longtemps — 30 à 60 minutes est acceptable.
Faut-il des baselines séparées par environnement (dev, staging, prod) ?
Oui, si les environnements ont des contenus ou des configurations différents. Non, si le rendu est identique. En pratique, maintenez une seule baseline par projet, capturée dans un environnement de staging stable. Comparer contre la production est tentant, mais le contenu dynamique (dates, données utilisateur, A/B tests) génère trop de faux positifs.
Le test visuel en monorepo fonctionne-t-il avec Lerna ?
Lerna est principalement un outil de gestion de versions et de publication de packages. Son graphe de dépendances est moins sophistiqué que celui de Nx ou Turborepo. Vous pouvez l'utiliser, mais vous devrez probablement complémenter avec un script personnalisé pour identifier les projets affectés. Si vous démarrez un nouveau monorepo, préférez Nx ou Turborepo.
Comment éviter que les développeurs ignorent les résultats de test visuel ?
Trois règles. Maintenez un taux de faux positifs proche de zéro — si les développeurs voient régulièrement des faux positifs, ils arrêtent de regarder. Bloquez les PRs sur les échecs de test visuel — pas de merge sans approbation. Et gardez les temps de pipeline courts — si le test visuel ajoute 45 minutes à la PR, les développeurs trouveront des moyens de le contourner.