Vous avez passé des semaines sur votre installation. Les bibliothèques Emby ou Jellyfin s’analysent, les applications Nextcloud s’installent, le site web s’affiche sur votre ordinateur portable. Puis un ami l’ouvre sur une TV, un téléphone et un navigateur, et quelque chose « ne fonctionne parfois pas ». C’est exactement le moment où une vérification indépendante devient utile.
Ce tutoriel décrit comment nous menons un audit QA chez Assurance qualité, rédigé pour que vous puissiez soit refaire les mêmes contrôles vous-même, soit transmettre la liste et acheter quelques heures de tests. Le livrable est toujours le même : un rapport écrit indiquant ce qui a été testé, ce qui a été constaté et ce qu’il faut corriger en priorité. Voyez-le comme une liste de contrôle pour un test de site web et une liste de contrôle de serveur multimédia en une seule passe.
Ce qu’il vous faut d’abord
- Une copie de préproduction ou un créneau calme sur le système en production. L’audit comprend une répétition de mise à jour sur une copie de votre serveur, donc une copie est idéale, mais une soirée à faible trafic convient aussi.
- La liste de ce qui compte : quels clients les utilisateurs emploient réellement (TV, téléphones, navigateurs, applications clientes), quels utilisateurs et permissions existent, quels ports sont ouverts sur Internet.
- Un accès pour le testeur : un compte administrateur sur le serveur multimédia ou l’instance Nextcloud, et un compte utilisateur normal, car les permissions font partie du test.
- Un moyen de nous joindre avec le périmètre : le formulaire de contact, un ticket ou Telegram. Vous recevez gratuitement une estimation écrite avec le périmètre et les heures avant tout achat.
Les heures s’achètent sur la page produit avec un minimum d’une heure et sont décomptées par tranches de 15 minutes. Les heures non utilisées restent sur votre compte pendant 12 mois.
Étape 1 : définir le périmètre
Avant de toucher à quoi que ce soit, convenez de ce qui sera vérifié. L’audit couvre les logiciels (plan de tests, tests manuels et automatisés, rapports d’anomalies avec étapes de reproduction), les serveurs multimédias et de messagerie (Emby, Jellyfin, Nextcloud ou mailcow : configuration, utilisateurs et permissions, sécurité, performance, transcodage, distribution du courrier et sauvegardes), les appareils (TV, téléphones, navigateurs, applications clientes : compatibilité, sous-titres, pistes audio, transcodage et accès distant), les sites web (accessibilité, référencement et performance avec Lighthouse et des contrôles manuels) et les changements (répétition des mises à jour, test de restauration des sauvegardes, tests de charge, tests de sécurité de base).
Choisissez les parties qui vous concernent. Un opérateur Jellyfin avec un petit site web a besoin d’un mélange différent d’un administrateur Nextcloud. Un périmètre écrit et court concentre les heures et rend le rapport final plus facile à lire.
Étape 2 : construire la matrice de lecture
C’est le cœur d’une vérification de serveur multimédia. Faites un tableau avec vos clients en lignes et les éléments susceptibles de casser en colonnes.
Lignes suggérées :
- TV du salon avec l’application native
- Téléphone (au moins un appareil Android et un appareil iOS)
- Navigateur de bureau
- Toute autre application cliente sur laquelle vos utilisateurs comptent
Colonnes suggérées :
- Lecture directe d’un fichier typique
- Transcodage d’un fichier que le client ne peut pas lire (vérifiez qu’il transcode réellement au lieu d’échouer)
- Sous-titres : intégrés et externes, et s’ils restent synchronisés
- Pistes audio : basculer entre elles en cours de lecture
- Accès distant depuis l’extérieur de votre réseau
Remplissez chaque cellule par réussi ou échec et une note d’une ligne. Les échecs constituent la liste du rapport, chacun avec des étapes de reproduction et une sévérité. Ne cherchez pas toutes les combinaisons ; un échantillon représentatif par client suffit à repérer les problèmes habituels.
Pour Emby et Jellyfin, la configuration et les permissions font partie de la même passe : vérifiez qu’un utilisateur normal ne voit pas de bibliothèques ou de zones d’administration qu’il ne devrait pas voir, et que les réglages de transcodage correspondent à ce que votre matériel peut faire.
Étape 3 : vérifier l’exposition en matière de sécurité
C’est là que les petites installations réservent le plus souvent des surprises. Restez au niveau de la configuration : quels ports sont joignables depuis Internet, si les certificats sont valides et se renouvellent, quels comptes existent et si des comptes administrateur par défaut ou inutilisés sont encore actifs. Pour Nextcloud, les utilisateurs et permissions font partie de la vérification du serveur multimédia ; pour mailcow, la distribution du courrier est vérifiée également.
Les tests de sécurité de base font partie du service, vous n’avez donc pas besoin de lancer des exploits vous-même. Ce qui aide, c’est un inventaire simple : listez chaque service que vous exposez, pourquoi il est exposé et qui devrait pouvoir y accéder. Tout ce que vous ne pouvez pas justifier retourne derrière le pare-feu ou le VPN. Si vous menez l’audit vous-même, cet inventaire seul vaut souvent l’après-midi.
Étape 4 : performance, référencement et accessibilité pour le site web
Si vous exploitez aussi un site web, l’audit comprend des audits d’accessibilité, de référencement et de performance avec Lighthouse et des contrôles manuels, avec des priorités. Lancez Lighthouse sur une page représentative, pas seulement sur la page d’accueil, et notez les trois résultats qui comptent le plus pour vous. Les contrôles manuels repèrent ce que Lighthouse ne voit pas : navigation au clavier, contraste lisible, texte de lien explicite, titres cohérents.
Gardez cette section courte et factuelle dans le rapport. « Le Largest Contentful Paint est lent sur la page de tarifs, l’image n’est pas compressée » est plus utile qu’une série de scores. Les corrections peuvent être faites par nous en développement sur mesure ou par votre propre équipe à partir du rapport.
Étape 5 : répéter la mise à jour et restaurer une sauvegarde
Une répétition de mise à jour sur une copie de votre serveur répond à la question « la prochaine version va-t-elle casser mes plugins ou mes clients ? » avant que vous ne le découvriez à vos dépens. Un test de restauration de sauvegarde répond à la question plus inquiétante : la sauvegarde se restaure-t-elle vraiment ? Les deux font partie du service et figurent tous deux dans le rapport comme réussi ou échoué, avec des notes.
Des tests de charge sont également disponibles si vous attendez un pic d’utilisateurs, par exemple après la publication d’un lien.
Étape 6 : en faire un rapport exploitable
Le rapport est le livrable. Exigez cette structure, que vous l’écriviez vous-même ou que vous receviez le nôtre :
- Ce qui a été testé, avec le périmètre et les clients utilisés.
- Les constats, chacun avec sa sévérité, les étapes de reproduction et, si utile, une capture d’écran.
- Ce qu’il faut corriger en priorité, classé par sévérité et par effort.
- Ce qui a réussi, pour savoir ce qu’il ne faut pas toucher.
La sévérité est ce qui rend un rapport utile. Un échec de connexion pour les utilisateurs normaux n’équivaut pas à un décalage de sous-titres sur une TV. Classez honnêtement et gardez une liste assez courte pour être traitée.
Étape 7 : corriger, puis retester
Les corrections sont retestées dans le cadre du service. C’est l’étape que l’on saute : une correction non vérifiée est un espoir, pas une correction. Relancez les cellules en échec de la matrice de lecture, revérifiez les ports exposés que vous avez fermés et relancez Lighthouse sur les pages modifiées. Les heures sont décomptées par tranches de 15 minutes, donc un court retest coûte peu.
Conseils et dépannage
- « Ça ne marche parfois pas » est un symptôme, pas un bug. Notez le client, le fichier, l’heure et ce que vous avez vu. Cette note est le début d’une reproduction.
- Testez avec un compte utilisateur normal, pas seulement avec l’administrateur. La plupart des problèmes de permissions se cachent là.
- Ne testez pas sur le serveur en production aux heures de pointe si vous pouvez l’éviter ; les tests de transcodage et de charge entrent en concurrence avec les vrais spectateurs.
- Gardez un périmètre restreint. Une heure de tests ciblés vaut mieux qu’une demande vague de « tout vérifier ».
- Rédigez le rapport au fil de l’eau. Reconstituer les étapes une semaine plus tard fait perdre des heures.
- Consultez la base de connaissances et la FAQ pour les questions de configuration avant l’audit, afin que les heures servent aux tests plutôt qu’aux bases de la configuration.
Conclusion
Un audit QA ne consiste pas à chercher la faute dans votre travail ; il s’agit de remplacer « ça ne marche parfois pas » par une liste que vous pouvez corriger dans l’ordre. Construisez la matrice de lecture, inventoriez ce que vous exposez, lancez Lighthouse sur les pages qui comptent, répétez la mise à jour et la restauration, et rassemblez le tout dans un rapport court avec des sévérités. Si vous préférez confier cela à quelqu’un d’indépendant, le périmètre et l’estimation sont gratuits, et les heures sont à vous. Commencez par Assurance qualité.