15-1 · Chapitre 15 · 7 min de lecture

Pourquoi le CI/CD Frontend Web n'est pas le CI/CD Backend

Découvrez pourquoi le pipeline CI/CD pour le frontend web diffère fondamentalement du backend : environnements non contrôlés, mise en cache, dépendances API et tests spécifiques.

Pourquoi le CI/CD Frontend Web n'est pas le CI/CD Backend

Lorsqu'une équipe commence à construire un pipeline CI/CD, la première chose qui vient à l'esprit est généralement le backend. Il y a un serveur à redémarrer, une migration de base de données à exécuter, une API à vérifier pour des réponses correctes. Le backend s'exécute sur une infrastructure que l'équipe contrôle. Vous connaissez le système d'exploitation, la version du runtime, la mémoire disponible et la date du dernier redémarrage du serveur. Si quelque chose se casse, vous vous connectez en SSH, consultez les logs et redémarrez le processus.

Le frontend web ne fonctionne pas de cette manière. Une fois l'application déployée, le JavaScript, HTML et CSS sont envoyés au navigateur de l'utilisateur. Ce navigateur peut être Chrome, Firefox, Safari ou autre chose. L'utilisateur peut être sur un PC Windows, un Mac ou un téléphone Android. Sa connexion Internet peut être rapide ou terriblement lente. L'équipe n'a aucun contrôle sur ces variables. La seule chose que vous pouvez contrôler est le code que vous livrez : qu'il soit correct, léger et compatible avec autant d'environnements que possible.

Cette différence change tout dans la conception d'un pipeline frontend. Les stratégies qui fonctionnent pour le déploiement backend échouent souvent ou créent de nouveaux problèmes lorsqu'elles sont appliquées au code frontend.

Actifs Statiques vs. Rendu Côté Serveur

Les déploiements frontend web impliquent généralement deux types d'actifs. Les actifs statiques sont des fichiers qui ne changent pas en fonction de qui les demande : HTML, CSS, JavaScript, images, polices. Ces fichiers peuvent être stockés sur un CDN, mis en cache par le navigateur et servis depuis le serveur le plus proche de l'utilisateur. Ils sont simples à déployer : téléchargez-les dans un bucket de stockage ou un CDN, et les utilisateurs obtiennent la dernière version lorsqu'ils actualisent la page.

La complication vient de la mise en cache. Même après avoir déployé une nouvelle version, le navigateur ou le CDN peut encore servir les anciens fichiers. Un utilisateur qui a visité votre site il y a une heure peut voir l'ancienne interface pendant des heures ou des jours, selon les en-têtes de cache et le comportement du service worker. C'est un problème spécifique au frontend que les équipes backend rencontrent rarement. Un changement d'API backend prend effet immédiatement sur le serveur. Un changement frontend peut être invisible pour les utilisateurs parce que leur navigateur a décidé de conserver les anciens fichiers.

L'autre type d'actif frontend est le contenu rendu côté serveur (SSR). En SSR, la page est construite sur le serveur et envoyée au navigateur sous forme de HTML prêt. Cette approche est courante pour les applications nécessitant des chargements de page initiaux rapides, un bon référencement (SEO) ou un contenu dynamique qui change par utilisateur. Le SSR signifie que votre code frontend s'exécute sur un serveur que vous contrôlez, au moins pour le rendu initial. Mais le JavaScript qui hydrate la page s'exécute toujours dans le navigateur de l'utilisateur, donc vous avez toujours le problème de compatibilité. Le SSR ajoute une cible de déploiement supplémentaire : vous devez maintenant gérer les processus serveur qui génèrent le HTML, gérer la mise à l'échelle et surveiller les erreurs.

Pour forcer le CDN à récupérer les derniers fichiers après un déploiement, vous pouvez invalider son cache. Par exemple, avec AWS CloudFront :

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/*"

Cette commande indique au CDN de jeter tous les fichiers en cache et de demander des copies fraîches à l'origine. Sans cette étape, les utilisateurs pourraient voir des actifs obsolètes pendant des heures même après un déploiement réussi.

Le Problème de Dépendance à l'API

Les applications frontend existent rarement seules. Presque toutes les applications web modernes récupèrent des données depuis une API, envoient des entrées utilisateur ou gèrent l'authentification. Cela crée un couplage étroit entre le frontend et le backend qui rend la conception du pipeline plus difficile qu'il n'y paraît.

Lorsque vous publiez une nouvelle version frontend, vous devez être sûr que l'API backend correspond toujours. Si le backend a modifié la structure des réponses sans en informer l'équipe frontend, les utilisateurs verront des pages cassées ou des données manquantes. Si le frontend commence à appeler un endpoint qui n'existe pas encore sur le backend, l'application générera une erreur.

Cela signifie qu'un pipeline frontend ne peut pas s'arrêter à "construction réussie". Le pipeline doit également vérifier que la version frontend sur le point d'être publiée est compatible avec l'API actuellement en production. L'équipe doit savoir quelle version de l'API est en ligne, si des changements cassants ont été introduits et comment gérer la période de transition lorsque le frontend et le backend sont publiés à des moments différents.

En pratique, cela conduit souvent à des API versionnées, des feature flags ou une coordination minutieuse entre les cycles de publication frontend et backend. Certaines équipes adoptent une approche de test de contrat où le pipeline frontend exécute des tests contre une spécification d'API connue avant d'autoriser un déploiement. D'autres utilisent des canary releases ou des déploiements blue-green sur le frontend pour détecter les incompatibilités tôt.

Les Tests sont Différents pour le Frontend

Les tests unitaires dans le frontend ont une forme différente de ceux du backend. Un test unitaire backend appelle généralement une fonction ou un endpoint et vérifie la réponse. Un test unitaire frontend doit prendre en compte l'interaction utilisateur, le comportement du navigateur et le rendu visuel.

L'habitude industrielle d'assimiler les tests unitaires au test de fonctions ou de classes individuelles est trompeuse pour le frontend. Un test unitaire devrait vérifier un comportement significatif à partir d'un point d'entrée pertinent. Pour le frontend, ce point d'entrée est souvent une action utilisateur : un clic, une soumission de formulaire, une navigation ou un changement d'état visible. Le test devrait prouver que le système répond correctement à cette interaction, pas qu'une méthode interne a été appelée avec les bons arguments.

Cela signifie que votre suite de tests ne devrait pas échouer simplement parce que vous avez refactorisé du code interne. Si vous avez changé la façon dont un composant gère son état interne mais que l'utilisateur voit toujours le même résultat, les tests devraient toujours passer. Les tests fortement couplés aux détails d'implémentation deviennent un fardeau de maintenance et ralentissent le pipeline sans ajouter de réelle sécurité.

Pour le frontend, l'environnement de test pertinent peut inclure un runtime de navigateur. Les émulateurs ou simulateurs peuvent être des environnements d'exécution valides pour les tests unitaires si le comportement testé nécessite des API de navigateur, des calculs de mise en page ou des fonctionnalités d'exécution. Les appareils physiques sont encore nécessaires pour les scénarios dépendants du matériel : appareil photo, capteurs, variations réseau et performances réelles.

L'Étape de Construction n'est pas une Simple Compilation

Dans le CI/CD backend, l'étape de construction signifie généralement compiler le code et l'empaqueter dans un artefact déployable. Pour le frontend, l'étape de construction fait bien plus. Elle regroupe les modules JavaScript, minifie le code, optimise les images, génère des source maps, injecte des variables d'environnement et produit plusieurs versions de fichiers pour différents navigateurs ou appareils.

Le résultat de la construction n'est pas un artefact unique. C'est une collection de fichiers avec des hashs anti-cache dans leurs noms. Ces hashs sont essentiels pour la gestion du cache. Lorsque vous déployez une nouvelle version, seuls les fichiers qui ont changé obtiennent de nouveaux hashs. Les fichiers qui n'ont pas changé conservent leurs anciens hashs, donc le cache du navigateur continue de les servir. Cela réduit la taille du téléchargement pour les utilisateurs qui ont déjà visité votre site.

Mais l'anti-cache ne fonctionne que si votre pipeline le gère correctement. Si votre processus de construction ne génère pas de hashs uniques pour les fichiers modifiés, ou si votre processus de déploiement ne met pas à jour les références HTML pour pointer vers les nouveaux hashs, les utilisateurs obtiendront un mélange d'anciens et de nouveaux fichiers. Le résultat est une interface utilisateur cassée, difficile à déboguer car elle ne se produit que sur certains navigateurs ou après certains modèles de navigation.

Liste de Vérification Pratique pour le CI/CD Frontend

Vérifiez que votre étape de construction génère des hashs anti-cache uniques pour les fichiers modifiés.
Testez votre frontend contre la version exacte de l'API en production, pas seulement une API mock ou de staging.
Incluez des tests basés sur le navigateur qui simulent des interactions utilisateur réelles, pas seulement des tests unitaires sur des fonctions internes.
Configurez des politiques d'en-têtes de cache qui équilibrent fraîcheur et performance. Temps de cache courts pour le HTML, temps de cache longs pour les actifs hashés.
Exécutez une vérification rapide de régression visuelle pour détecter les changements d'interface non intentionnels avant la publication.
Confirmez que votre processus de déploiement met à jour toutes les références vers les nouveaux hashs d'actifs, y compris les fichiers service worker si vous en utilisez un.

L'Essentiel à Retenir

Le CI/CD frontend n'est pas une version simplifiée du CI/CD backend. Il a ses propres contraintes : environnements utilisateur non contrôlés, comportement de mise en cache qui peut cacher ou casser votre publication, couplage étroit aux API backend et une étape de construction qui fait plus que compiler du code. Traiter le déploiement frontend comme "il suffit de télécharger quelques fichiers" conduira à des expériences utilisateur cassées et difficiles à diagnostiquer. Construisez votre pipeline frontend autour de la réalité que le code s'exécute dans le navigateur de quelqu'un d'autre, sur le réseau de quelqu'un d'autre, et vous n'avez qu'une seule chance de faire bonne première impression.