Architecture en étapes séquentielles avec codes de sortie
Chaque étape de QA est un script autonome qui écrit ses résultats dans un fichier JSON structuré et retourne 0 (succès) ou 1 (échec). Le runner CI (GitHub Actions dans notre cas) interprète ces codes et interrompt la chaîne dès le premier échec. Cette convention simple élimine la tentation de « continuer quand c’est possible ».
Les étapes sont ordonnées par coût de calcul croissant : les vérifications syntaxiques (JSON-LD valide, champs obligatoires présents) passent en premier, car elles sont gratuites. Les calculs lourds (similarité cosinus, rendu Lighthouse) passent en dernier pour ne pas consommer de ressources inutilement si une vérification basique échoue.
Gestion des erreurs partielles : tout ou rien
Une question récurrente : peut-on publier les 3 950 pages valides et bloquer seulement les 50 en échec ? La réponse est non pour les déploiements normaux. Une publication partielle crée un état intermédiaire difficile à tracer et peut introduire des incohérences dans les sitemaps et les liens internes. L’intégrité du graphe de liens prime sur la vitesse de publication.
Une procédure d’urgence existe pour les corrections critiques (erreur factuelle grave, lien cassé en production). Elle permet de déployer un sous-ensemble de pages après validation manuelle explicite. Cette procédure laisse une trace dans le log de déploiement avec le nom de l’auteur et le motif.
Rapports d’échec : format et diffusion
Chaque échec de QA produit un rapport au format JSON contenant : la liste des slugs en échec, l’étape et la valeur mesurée, un lien vers la page de build CI, et le timestamp UTC. Ce rapport est posté automatiquement dans un canal Slack dédié et archivé dans un bucket de logs.
Les rapports sont agrégés en résumé hebdomadaire : nombre de builds réussis, nombre d’échecs par étape, temps moyen de résolution. Ce tableau de bord permet d’identifier les étapes qui génèrent le plus de friction et d’orienter les efforts d’amélioration du pipeline.
Questions fréquentes
Combien de temps dure un cycle de QA complet sur 4 000 pages ?
Entre 8 et 12 minutes sur notre infrastructure actuelle (8 cœurs, 16 Go RAM). Les étapes parallélisables (rendu de pages individuelles) tournent sur 6 workers simultanés. L’étape de similarité cosinus, non parallélisable dans sa version actuelle, représente 40 % du temps total.
Que se passe-t-il si le serveur de CI tombe en cours de QA ?
Le déploiement ne se déclenche pas. GitHub Actions considère un job interrompu comme un échec et ne continue pas vers l’étape de déploiement. Les artefacts partiels sont supprimés automatiquement après 24 heures.