Catalog QA Auditor

Le Catalog QA Auditor détecte les erreurs que personne ne trouve en ouvrant les fiches une par une. Il exécute des scans automatiques en lecture seule sur une base de fiches produits, ne montre que les anomalies, et les corrige avec une relecture après chaque écriture. Construit pour un répertoire de 1 900 fiches où un audit complet coûte quelques milliers de tokens au lieu d'une lecture intégrale, il a attrapé de vrais incidents : des prompts d'installation contenant littéralement rien d'autre qu'un bloc de code vide, le même prompt collé sur la mauvaise fiche, et des prix qui contredisaient leurs propres étiquettes. La liste de contrôles couvre les prompts d'installation (vides, corrompus ou dupliqués entre fiches), les résidus de template ({{ }}, TODO, lorem, marqueurs [insérer dans les textes visibles), les traductions manquantes (EN présent mais FR vide), les dates de création invalides ou vides (qui cassent les sections "Nouveautés" et les tris par date), les URL de dépôt dupliquées (normalisées avant comparaison, pour attraper les suffixes /blob/... comme les URL racine), les incohérences de prix (flag payant vs prix vs étiquette), les secrets et données personnelles balayés dans les textes (clés API et emails collés par accident, invisibles à l'oeil nu), les vendeurs orphelins et les slugs suspects, et les écarts entre sitemap et base (un écart signale un build incomplet). La santé des liens tourne chaque trimestre en tâche de fond car des milliers de requêtes HTTP, c'est lent. Le workflow est mensuel, plus après tout incident de données, avec un journal de corrections daté à chaque passage. Les règles d'exploitation sont strictes : scans en SELECT uniquement, déduplication sur slugs et ids jamais sur les noms d'affichage, une correction à la fois avec relecture entre les écritures, et chaque bug de pipeline découvert devient un nouveau garde-fou au lieu d'une simple correction de données. Il inclut aussi le rituel de validation post-insertion né d'un incident réel : après chaque insertion en masse et avant chaque build, valider en base que les champs critiques sont réellement présents et non vides, car les tests de truthiness mentent.