La plupart des plantages d’apps de streaming les jours de match ne sont pas des bugs de code. Le code va bien. Les tests passent. Mais un éditeur a publié un hero banner sans image, ou une promotion programmée a expiré et laissé un deep link cassé vers un contenu supprimé. Résultat : 200 000 fans regardent un écran d’erreur.
Nous avons vu ce schéma sur assez de plateformes pour en faire une règle :
Quand une organisation dispose enfin d’un QA code solide, le QA contenu repose encore sur l’espoir et des vérifications manuelles.
Et aucun processus ne corrige un problème structurel.
La pyramide de test suppose que votre UI est statique
La pyramide classique a été pensée pour des applications dont l’UI est déterminée par le code. Les apps pilotées par CMS ne fonctionnent pas ainsi. La page d’accueil est un payload JSON assemblé côté serveur à partir de ce qu’un éditeur a publié le matin même. Le rail hero d’hier peut avoir disparu, changé ou pointer vers un contenu dépublié pendant la nuit. Un test qui vérifie que “Trending Now” apparaît en troisième position échoue dès qu’il devient “What’s Hot”. Aucun code n’a changé ; le test n’est plus valide.
Netflix affiche une page différente pour chaque utilisateur et chaque session. Disney+ gère cinq hubs de marque pilotés par CMS. La BBC valide métadonnées, images, fenêtres de disponibilité et classifications d’âge sur plus de 1 500 variantes d’appareils. C’est l’environnement normal de toute plateforme streaming sérieuse.
La suite est verte. L’app est cassée.
Le diamant de test
Le modèle vers lequel convergent les plateformes les mieux opérées ressemble davantage à un diamant. L’investissement le plus lourd se situe au niveau des contrats et des schémas.
Les tests unitaires restent à la base, les smoke tests E2E au sommet, mais le vrai travail qualité se fait au milieu : valider le contrat entre l’app et le CMS avant qu’un seul pixel ne soit rendu.
Les couches :
- Tests unitaires pour la logique métier et les transformations de données : formatteurs, parsers, calculs de prix, conversions de fuseau horaire.
- Tests de composants pour vérifier que l’UI gère toutes les formes de données CMS : titres de 3 ou 300 caractères, thumbnail nul, carrousel vide ou avec un élément.
- Tests de schéma et de contrat comme couche principale. Ils définissent ce que l’app attend de l’API CMS et l’exécutent à chaque changement.
- Régression visuelle ensuite : non pas “le texte dit-il Stranger Things”, mais “le hero a-t-il un titre, une image et un CTA alignés”.
- Tests E2E uniquement pour les parcours critiques : ouvrir un titre, lancer la lecture, vérifier le playback ; s’abonner et valider les droits.
Cette inversion reflète une réalité : dans une app CMS, un contrat cassé entre app et CMS cause plus d’incidents que du code cassé.
À quoi ressemble le contract testing avec Pact
Ici, le contract testing diffère de la version microservices. Le CMS n’est pas une API déterministe. L’éditeur avec droits de publication est le provider, et il ne lance pas de tests avant de publier.
Le contrat doit être défini au niveau du modèle de contenu : champs obligatoires, types et contraintes. Un hero slot doit avoir une image de fond. Un carrousel doit contenir entre 3 et 12 éléments. Un épisode doit avoir un numéro de saison.
Pact permet de définir ces contrats côté consumer, l’app, et de les vérifier en CI contre le provider, API CMS ou BFF. Les provider states sont essentiels : vous définissez “homepage avec hero banner pour événement live” comme état nommé, et le provider prépare le contenu correspondant. Si editorial ajoute un champ obligatoire non géré par l’app, le test échoue avant la production.
Pour les CMS GraphQL, GraphQL Inspector détecte les changements de schéma cassants. Dans les architectures fédérées, Rover CLI vérifie que les changements de subgraph CMS, playback, entitlement ou EPG ne cassent pas le supergraph composé.
Le constat honnête : bien le configurer prend du temps. Pact a une courbe d’apprentissage, et écrire de bons provider states demande une collaboration étroite entre QA et équipes de modèles de contenu.
L’alternative est de découvrir les ruptures de contrat en production, pendant un live, au pire moment.
CMS Testing : validation de schéma avant publication
Le contract testing détecte les problèmes au déploiement. La validation de schéma les détecte plus tôt, au moment de publier.
La plupart des CMS headless ont des hooks natifs. Contentful déclenche des webhooks sur Entry.publish. Sanity prend en charge des règles de validation au niveau document avec vérifications asynchrones. Strapi, qui soutient notre plateforme Velvet, possède des lifecycle hooks beforeCreate et beforeUpdate pour rejeter une entrée avant qu’elle n’atteigne l’API.
Cette couche doit couvrir ce que le modèle ne peut pas imposer seul. Exiger une image non vide est simple. Vérifier qu’elle fait au moins 1280x720 et que l’URL ne renvoie pas 404 nécessite une validation externe.
À tester explicitement : thumbnails manquants, null, chaîne vide, URL invalide et 404 ; titres aux limites, 3, 50, 100, 200 et 500 caractères ; carrousels vides qui doivent disparaître sans espace orphelin ; texte RTL pour audiences arabes ou hébraïques.
La plupart des bugs de contenu viennent de choix de schéma, pas seulement d’erreurs éditoriales. Si le modèle permet de publier un hero sans image, cela finira par arriver. Corrigez le modèle avant d’essayer de tester autour.
Régression visuelle au bon niveau
La régression visuelle a une réputation fragile sur les apps CMS. Elle est méritée si elle s’exécute sur du contenu live, car les captures changent sans cesse.
L’approche utile consiste à tester contre des réponses CMS simulées : des fixtures déterministes représentant toutes les formes de données que les composants doivent gérer.
Applitools Eyes avec Layout Match convient bien. Il valide la structure tout en acceptant les variations de contenu : un titre différent n’est pas une régression, un CTA mal aligné l’est. Chromatic, basé sur Storybook, convient à la couche composant et teste chaque composant CMS isolément avec ses fixtures.
Les apps Connected TV sur Lightning.js restent plus difficiles. Le framework rend dans WebGL Canvas, pas dans le DOM. Percy, Chromatic et les outils DOM ne voient rien. Les tests par capture fonctionnent encore, mais on perd l’arbre d’accessibilité et la granularité composant.
Qui possède le QA contenu sans release ?
Quand un bug de code part en production, la chaîne de responsabilité est claire. Quand une configuration CMS casse la homepage, elle ne l’est plus. Le contenu a changé, il n’y a pas eu de release et l’ingénierie ne l’a pas vu.
Les équipes qui réussissent le QA contenu le traitent comme un problème de plateforme. La validation est automatisée dans le pipeline de publication CMS, le staging reflète la production pour la régression visuelle, et un dashboard suit images cassées, erreurs API contenu et pics d’échec de rendu avec alertes avant les utilisateurs.
Le modèle Spotify est utile : contrôler la logique de rendu côté serveur, valider et filtrer avant que le contenu n’atteigne un client. Idéalement, le CMS ne doit jamais servir une réponse que l’app ne peut pas rendre proprement.
Si votre architecture ne le permet pas encore, commencez par un webhook pre-publish avec JSON Schema et vérification d’URLs d’images, plus un dashboard de santé du contenu.
Où les tests streaming échouent sur Connected TV
Sur CTV, les défis se cumulent. L’infrastructure de test mobile se transpose mal.
Les outils Roku sont immatures par rapport au mobile. Les cycles build-deploy-test prennent 30 à 60 secondes. Un lab couvrant Roku, Fire TV, Apple TV, Samsung Tizen, LG webOS et Android TV coûte 2 000 à 5 000 dollars avant le premier test. Les labs cloud CTV sont rares ; AWS Device Farm ne prend en charge que Fire TV.
Suitest est la seule plateforme d’automatisation CTV dédiée avec support multi-plateforme, mais elle est récente. Beaucoup d’organisations testent encore sur des labs physiques, corrects pour le manuel et acceptables pour l’automatisation, à condition que quelqu’un les possède et les maintienne.
Le problème plus profond : la CTV a des modes d’échec contenu que le mobile ne voit pas. La validation EPG couvre précision horaire, mapping chaîne-stream, continuité de grille et transitions de fuseau sans trou, presque toujours sur mesure. La validation des deep links varie entre Roku, Fire TV, Apple TV, Tizen et webOS.
Le QA CTV demande beaucoup d’infrastructure et reste plus fragile que le mobile. Construisez d’abord la couche contrat ; elle attrape la majorité des bugs contenu CTV sans appareil.
Le point de départ
Tout n’a pas besoin d’être construit en même temps.
Si vous partez de zéro, l’ordre compte. D’abord : validation de schéma à la publication. C’est l’intervention au meilleur levier et au coût d’infrastructure le plus faible : ajoutez un webhook, définissez vos schémas avec ajv et rejetez le contenu malformé avant la production.
Ensuite : tests de composants avec fixtures variées. Choisissez les cinq composants qui causent le plus d’incidents, testez données manquantes, longueurs extrêmes et collections vides, puis exécutez-les en CI.
Troisième étape : un dashboard de santé contenu. Images cassées, erreurs API contenu, pics d’échec de rendu. On ne corrige pas ce qu’on ne voit pas.
Contract testing, régression visuelle et automatisation de lab viennent après. Ils sont précieux, mais exigent plus d’infrastructure et d’alignement.
Le test de maturité : si un éditeur publie un hero cassé à 3 h du matin, le saurez-vous avant un fan ?
Si la réponse est non, la pyramide n’est pas le problème. C’est ce que vous lui demandez de tester.
