Preflight QC

Preflight QC est une option premium qui vous offre un contrôle qualité professionnel de vos sorties. Soumettez une sortie et Preflight QC l’analyse de bout en bout : métadonnées, dates de sortie, audio, pochette, contenu IA, identifiants du catalogue, distribution antérieure et justificatifs de licence. Vous recevez un rapport de qualité clair et actionnable. Corrigez ce qu’il signale à votre rythme, puis confirmez la sortie pour révision quand vous êtes satisfait.

Pour les labels et les intégrateurs de l’API, Preflight QC sert de brique de base. Récupérez le rapport de qualité de manière programmatique, branchez-le sur votre propre pipeline de QA, conditionnez votre processus interne d’approbation à ses résultats et confirmez les sorties pour révision automatiquement. Votre équipe fixe le niveau d’exigence, et Preflight QC fait l’analyse.

Une sortie qui arrive propre traverse la révision rapidement. Preflight QC vous y amène avant même de soumettre.

Qu’est-ce que Preflight QC

Avec Preflight QC activé sur votre compte, soumettre une sortie pour distribution ne l’envoie pas directement dans la file de révision. La sortie passe d’abord en mise en attente avant révision (« en attente de votre relecture ») pendant que Preflight QC effectue son analyse de qualité : métadonnées, dates de sortie, audio, pochette, contenu IA, identifiants du catalogue, distribution antérieure et justificatifs de licence. Le résultat est un rapport de qualité, et ce que vous en faites vous appartient :

• Votre propre processus de QA (API). Faites passer votre catalogue par l’analyse de qualité, récupérez le rapport de manière programmatique dans votre propre pipeline de QA, conditionnez votre processus interne d’approbation aux résultats, et ne confirmez chaque sortie pour révision que lorsqu’elle franchit votre barre. Voir Utilisation de l’API pour les intégrations.
• Le parcours dans l’application. Lisez le rapport sur la page de la sortie, corrigez ce qu’il signale et confirmez lorsque tout vous convient.

Dans les deux cas, c’est la confirmation qui fait entrer la sortie dans la file de révision normale : rien n’entre en révision tant que vous n’avez pas donné votre feu vert.

Preflight QC ajoute une étape de qualité avant la révision. Il ne change rien à ce qui se passe après : une fois que vous confirmez, votre sortie suit le même processus de validation et révision que n’importe quelle autre.

Comment obtenir Preflight QC

Preflight QC est une option premium activée par compte par notre équipe. Pour l’activer sur votre compte, contactez notre équipe commerciale et indiquez-lui que vous souhaitez Preflight QC.

Une fois activé, vous verrez la nouvelle étape de mise en attente et de confirmation lors de votre prochaine soumission d’une sortie pour distribution.

Le déroulé de Preflight QC

Voici le parcours complet d’une sortie avec Preflight QC activé, de la soumission à la révision.

1. Soumettez votre sortie pour distribution

Créez et complétez votre sortie comme d’habitude, puis soumettez-la pour distribution. Avec Preflight QC activé, cela ne place pas la sortie dans la file de révision tout de suite. À la place, la sortie passe en mise en attente avant révision et est marquée en attente de votre relecture.

2. L’analyse de qualité s’exécute

Pendant que votre sortie est en attente, Preflight QC l’analyse de bout en bout. L’analyse couvre :

• Les métadonnées : titres, artistes, crédits et autres détails de la sortie et des pistes
• Les dates de sortie : la configuration des dates et les versions de la sortie
• L’audio : les fichiers audio que vous avez importés
• La pochette : votre image de couverture
• Le contenu IA : si le recours à l’IA est déclaré, et la musique ou les pochettes générées par IA que nous détectons
• Les identifiants du catalogue : la validité de vos ISRC, et si un enregistrement a déjà été revendiqué par un autre ayant droit
• La distribution antérieure : si la sortie ou ses pistes sont déjà en boutique via un autre distributeur
• Les licences : lorsqu’une reprise, un sample ou un élément similaire nécessite une pièce justificative

L’analyse se termine généralement quelques minutes après la fin de l’import et du transcodage. Tant qu’elle est en cours, le rapport de qualité indique que les vérifications sont en cours et ne liste encore aucun problème.

3. Lisez votre rapport de qualité

Une fois l’analyse terminée, ouvrez le rapport de qualité de la sortie pour voir ce qui, le cas échéant, demande votre attention. Vous pouvez le consulter à deux endroits :

• Via l’API publique, pour votre propre pipeline de QA ; voir Utilisation de l’API ci-dessous.
• Dans l’application, sur la page de la sortie.

Le rapport liste chaque problème avec un titre clair et un message décrivant ce qu’il faut corriger. Voir Comprendre le rapport de qualité pour savoir comment lire les champs.

4. Corrigez ce qui est signalé

Passez en revue les problèmes de votre rapport :

• Problèmes de métadonnées : modifiez les détails de la sortie ou de la piste.
• Problèmes d’audio ou de pochette : remplacez le fichier concerné.
• Problèmes qui demandent un retour : répondez dans le fil de notes du problème, ou importez le document demandé (par exemple, une licence pour une reprise ou un sample).

Modifier votre sortie pendant qu’elle est en attente marque le rapport actuel comme obsolète : les résultats ne reflètent plus l’état le plus récent de votre sortie. Modifiez autant que vous le souhaitez, puis demandez une nouvelle analyse, depuis la page de la sortie dans l’application ou via l’endpoint d’actualisation pour les intégrations. L’analyse se relance et le rapport se met à jour avec les nouveaux résultats. Vous pouvez répéter ce cycle autant de fois que nécessaire, dans la limite d’un usage raisonnable du nombre de nouvelles analyses que vous pouvez lancer par sortie et par heure.

5. Confirmez la sortie

Lorsque votre rapport est propre, ou que vous avez traité tout ce qu’il fallait, confirmez la sortie. Dans l’application, c’est un bouton de confirmation sur la sortie ; pour les intégrations, c’est l’endpoint de confirmation.

La confirmation sort la sortie de l’attente et l’envoie dans la file de révision normale. La confirmation nécessite une analyse terminée et à jour : si vous avez modifié la sortie après la dernière exécution, le rapport est obsolète ; demandez donc une nouvelle analyse et laissez-la se terminer avant de confirmer.

6. Révision normale

Après confirmation, votre sortie est révisée exactement comme n’importe quelle autre. Pour savoir ce qui se passe pendant la révision, les délais et les résultats possibles, voir Validation et révision.

Comprendre le rapport de qualité

Le rapport de qualité comporte deux parties : une liste de problèmes et un petit bloc de détails du rapport sur l’exécution elle-même.

Problèmes

Chaque problème du rapport décrit un point à examiner. Les champs avec lesquels vous travaillerez :

Champ	Ce qu’il vous indique
Titre	Un nom court et en langage clair pour le problème.
Message	En quoi consiste le problème et ce qu’il faut faire.
Gravité	L’importance du problème, pour vous aider à prioriser.
Bloquant	Si le problème doit être résolu avant que vous puissiez confirmer (voir ci-dessous).
Demande un retour	Si le problème nécessite une réponse écrite ou un document importé de votre part.
Description personnalisée	Des détails supplémentaires propres à votre sortie, lorsqu’ils sont disponibles.
Pistes concernées	À quelles pistes le problème s’applique. Les problèmes au niveau de la sortie ne listent pas de pistes précises.
Preuves	Sur les problèmes de dates, de doublons et de distribution antérieure, les sorties correspondantes que nous avons trouvées, pour que vous puissiez vérifier le conflit vous-même (voir ci-dessous).

Bloquant ou informatif

• Les problèmes bloquants doivent être résolus avant que vous puissiez confirmer la sortie pour révision. Corrigez ce qu’ils décrivent, lancez une nouvelle analyse, et ils disparaîtront de votre rapport.
• Les problèmes informatifs sont là pour signaler un point qui mérite un coup d’œil, mais ils ne vous empêchent pas de confirmer. Examinez-les, puis confirmez quand vous êtes prêt.

Problèmes qui demandent un retour

Certains problèmes ne se règlent pas par une simple modification : ils nécessitent quelque chose de votre part, comme une explication écrite ou une pièce justificative (par exemple, une licence pour une reprise ou un sample). Ils sont marqués comme demande un retour. Pour en résoudre un, répondez dans le fil de notes du problème ou importez le document demandé avant de confirmer.

Preuves sur un problème

Certains problèmes incluent des preuves pour vous aider à vérifier un signalement sans deviner : les sorties existantes que nous avons rapprochées de la vôtre. Vous les verrez sur les problèmes de dates, de doublons et de distribution antérieure. Chaque correspondance indique le titre et l’artiste de la piste correspondante, le titre de sa sortie, la date de sortie et l’ISRC, ainsi qu’un lien vers une boutique où cette sortie est disponible, et lesquelles de vos pistes sont concernées. Jusqu’à trois correspondances sont listées par piste. Servez-vous des preuves pour confirmer si le conflit est réel (par exemple, un import antérieur qui vous appartient) avant de décider comment réagir.

Les détails du rapport

À côté des problèmes, le rapport inclut quelques détails sur l’exécution :

Champ	Ce qu’il vous indique
generated_at	Quand le rapport actuel a été produit. Ce champ est vide tant que la première analyse est en cours.
checks_in_progress	true tant que l’analyse est en cours ; la liste des problèmes reste vide jusqu’à sa fin.
stale	true lorsque vous avez modifié la sortie (ou l’une de ses pistes) après la dernière analyse terminée, de sorte que les résultats ne reflètent plus l’état actuel. Toute modification compte. Demandez une nouvelle analyse pour mettre à jour le rapport.
hold	Si la sortie est actuellement en mise en attente avant révision.
review_status	Le statut de révision actuel de la sortie.
release_status	Le statut global de la sortie elle-même, en plus du statut propre à la révision.
profile	Le profil de qualité appliqué à cette sortie, avec son nom et sa version.

Utilisation de l’API pour les intégrations

Si vous développez sur l’API publique de LabelGrid, vous pouvez brancher Preflight QC sur votre propre pipeline : faites passer chaque sortie par l’analyse de qualité, récupérez le rapport dans votre propre processus de QA, conditionnez votre processus interne d’approbation aux résultats et confirmez pour révision depuis vos propres outils. Preflight QC fournit trois endpoints à cet effet, qui utilisent tous la même authentification par jeton Bearer que le reste de l’API publique. Pour les schémas de requête et de réponse complets et toujours à jour, voir la référence de l’API.

Webhook pour savoir quand le rapport est prêt

Plutôt que d’interroger les résultats à intervalles réguliers, vous pouvez laisser LabelGrid vous prévenir dès qu’un rapport est prêt. Abonnez-vous à l’événement de webhook release.preflight.report_ready : il se déclenche dès que Preflight QC termine l’analyse d’une sortie en mise en attente avant révision, y compris chaque fois qu’une nouvelle analyse que vous demandez se termine. Vous recevez exactement un événement par cycle d’analyse.

Abonnez-vous de la même manière qu’aux autres événements de webhook de sortie de LabelGrid, depuis vos paramètres de webhook dans l’application ou via l’API. Chaque événement transporte un résumé compact de l’exécution, jamais les problèmes eux-mêmes :

• Identifiants de la sortie : release_id, label_id, release_cat et release_title.
• generated_at : quand ce rapport a été produit. Il correspond au generated_at du rapport lui-même.
• profile : le profil de qualité à travers lequel les décomptes ont été calculés, sous la forme {name, version}.
• counts : les totaux blocking, informational et requires_feedback. Le décompte requires_feedback recoupe les deux autres.

Servez-vous des décomptes pour décider si vous devez agir, puis récupérez le rapport lui-même pour le détail. Le schéma d’intégration recommandé :

1. Abonnez-vous à release.preflight.report_ready.
2. À chaque événement, appelez Obtenir le rapport de qualité pour lire l’ensemble des problèmes.
3. Corrigez et relancez : après avoir modifié une sortie en attente, appelez l’endpoint d’actualisation pour lancer une nouvelle analyse ; le webhook se déclenche à nouveau lorsqu’elle se termine.
4. Décidez et confirmez depuis vos propres outils une fois que la sortie franchit votre barre.

Pour la référence complète du payload et le fonctionnement des webhooks (la signature, les nouvelles tentatives et l’enveloppe), voir Webhooks.

Obtenir le rapport de qualité

GET /api/public/releases/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

Renvoie le rapport de qualité actuel de la sortie. La réponse contient :

• issues[] : une entrée par problème, chacune avec id, code (une chaîne stable ; voir Travailler avec les codes de problème), title, message, status, severity, is_blocking, requires_feedback, custom_description et affected_tracks. Sur les problèmes de dates, de doublons et de distribution antérieure, l’entrée porte aussi un tableau evidence (voir ci-dessous).
• report : generated_at, checks_in_progress, stale, hold, review_status, release_status et profile (un objet avec name et version). stale vaut true lorsque la sortie ou l’une de ses pistes a été modifiée après la dernière analyse terminée ; relancez l’analyse avec l’endpoint d’actualisation avant de confirmer.

Tant que l’analyse est en cours, le rapport renvoie checks_in_progress: true avec une liste issues vide. Si vous préférez ne pas utiliser les webhooks, interrogez cet endpoint à intervalles réguliers jusqu’à ce que generated_at soit renseigné, généralement quelques minutes après la fin de l’import et du transcodage, puis lisez les problèmes. Pour être prévenu dès que le rapport est prêt, utilisez plutôt le webhook de rapport prêt.

Un exemple de réponse une fois l’analyse terminée :

{
  "issues": [
    {
      "id": "12345",
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "status": "confirmed",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456],
      "evidence": [
        {
          "affected_track_id": 456,
          "track_title": "Matched track title",
          "artist": "Matched artist",
          "release_title": "Matched release",
          "release_date": "2024-03-01",
          "isrc": "USRC12345678",
          "store_url": "https://…"
        }
      ]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "stale": false,
    "hold": true,
    "review_status": "…",
    "release_status": "…",
    "profile": { "name": "quality_report", "version": 2 }
  }
}

Chaque élément d’evidence décrit une sortie existante qui correspond à la vôtre : affected_track_id (à laquelle de vos pistes s’applique la correspondance), les track_title, artist, release_title, release_date et isrc correspondants, et un store_url pointant vers une page de boutique où la correspondance est disponible. Trois correspondances au maximum sont listées par piste, et la clé n’est présente que sur les types de problème ci-dessus.

Demander une nouvelle analyse

POST /api/public/releases/{id}/quality-report/refresh
Authorization: Bearer YOUR_API_TOKEN

Lance un nouveau cycle d’analyse Preflight QC pour une sortie en attente. Modifier une sortie en attente ne relance pas les vérifications à lui seul : cela marque seulement le rapport actuel comme obsolète (report.stale: true). Lorsque vous avez terminé vos modifications, appelez cet endpoint pour relancer l’analyse ; lorsque le cycle se termine, le webhook de rapport prêt se déclenche et report.stale repasse à false.

Un appel réussi renvoie 202 Accepted :

{
  "status": "refreshing",
  "checks_in_progress": true,
  "review_status": "pending_customer_review",
  "release_status": "to_review"
}

L’appel est idempotent tant qu’un cycle est en cours : le rappeler renvoie le même corps « en cours », ne met pas en file une seconde analyse et ne compte pas dans votre quota. Autres réponses à gérer :

• 409 not_in_customer_review_hold : la sortie n’est pas actuellement en attente pour votre révision Preflight QC.
• 409 refresh_coalesced : une analyse de cette sortie s’est terminée il y a un instant, donc rien n’a été mis en file. Réessayez après le délai indiqué par l’en-tête Retry-After (en secondes).
• 429 preflight_recheck_limit_reached : vous avez atteint le quota d’usage raisonnable de 6 cycles d’analyse lancés par sortie et par heure glissante. L’en-tête Retry-After (en secondes) vous indique quand la prochaine actualisation est autorisée. Interroger une analyse en cours est gratuit ; seul le lancement d’un nouveau cycle consomme du quota.
• 403 RELEASE_NOT_VALIDATED : la sortie doit passer la validation avant qu’une nouvelle analyse puisse démarrer (la même règle que pour la distribution) ; effectuez d’abord la validation.
• 403 pre_review_qc_not_enabled : Preflight QC n’est pas activé pour le compte propriétaire.

Confirmer la sortie pour révision

POST /api/public/releases/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

Sort la sortie de l’attente et l’envoie dans la file de révision normale : l’équivalent, via l’API, du bouton de confirmation de l’application.

La confirmation nécessite une analyse terminée et à jour. Deux conflits à gérer :

• 409 checks_in_progress : l’analyse est encore en cours. Attendez le webhook de rapport prêt (ou interrogez jusqu’à ce que generated_at soit renseigné), puis réessayez.
• 409 checks_stale : la sortie a été modifiée après la dernière analyse terminée (report.stale vaut true). Appelez l’endpoint d’actualisation, attendez le nouveau rapport, puis réessayez la confirmation.

Note

Tant qu’une sortie est en mise en attente avant révision, la soumettre par la voie de distribution normale renvoie 409 preflight_recheck_required : une sortie en attente ne quitte l’attente que par le flux d’actualisation et de confirmation décrit ici.

Travailler avec les codes de problème

Si vous construisez de la logique au-dessus du rapport de qualité, appuyez-la sur le code du problème :

• code est une chaîne stable au format slug (par exemple, audio.trailing-silence). Vous pouvez mapper les codes dans votre système et construire votre logique dessus en toute sécurité.
• Les titres et messages sont des textes destinés aux humains. Ils peuvent être affinés au fil du temps : ne basez jamais votre logique sur le texte ; utilisez-le uniquement pour l’affichage.
• De nouveaux codes peuvent apparaître à mesure que la couverture de Preflight QC s’étend. Traitez les codes inconnus de manière générique : affichez le title et le message de la réponse plutôt que d’échouer.
• Vos rapports vous apprennent les codes qui comptent. À mesure que vous faites passer des sorties par Preflight QC, les codes pertinents pour votre catalogue apparaissent naturellement dans vos propres rapports de qualité.
• Ce que couvre l’analyse. Les problèmes relèvent de ces catégories : métadonnées de la sortie et des pistes, dates et versions de la sortie, qualité audio, pochette, contenu IA, identifiants du catalogue, distribution antérieure, licences et justificatifs.

Le catalogue des problèmes

Pour mapper les problèmes lorsque vous bâtissez votre propre processus de QA, récupérez le catalogue complet de manière programmatique :

GET /api/public/issue-definitions
Authorization: Bearer YOUR_API_TOKEN

Il renvoie tous les problèmes susceptibles d’apparaître dans un rapport de qualité, indexés par leur code (chaîne stable), avec le titre, le modèle de message, la gravité, l’indicateur bloquant, requires_feedback et sa catégorie (type). La réponse contient aussi le profil de qualité à travers lequel le catalogue a été calculé, sous la forme {name, version}. L’endpoint n’est disponible que pour les comptes disposant de l’option Preflight QC.

FAQ

Que faire si l’analyse est encore en cours ?

Le rapport affichera checks_in_progress: true sans problème listé pour l’instant. C’est normal juste après la soumission. Patientez quelques minutes après la fin de l’import et du transcodage, puis revérifiez : dans l’application, le rapport se met à jour tout seul. Via l’API, vous pouvez vous abonner au webhook de rapport prêt pour recevoir une notification dès qu’il est prêt, ou l’interroger jusqu’à ce que generated_at soit renseigné.

Puis-je modifier ma sortie pendant qu’elle est en attente ?

Oui, modifiez aussi librement que vous le souhaitez : une sortie en mise en attente avant révision reste entièrement modifiable. La modification ne relance pas les vérifications à elle seule ; elle marque le rapport actuel comme obsolète. Lorsque vous avez terminé vos changements, demandez une nouvelle analyse (depuis la page de la sortie dans l’application, ou l’endpoint d’actualisation pour les intégrations) pour voir les résultats actualisés sans quitter l’attente. La nouvelle analyse doit se terminer avant que vous puissiez confirmer.

Que se passe-t-il après ma confirmation ?

Votre sortie quitte l’attente et rejoint la file de révision normale, où elle est révisée comme n’importe quelle autre. Voir Validation et révision pour comprendre le déroulé de la révision, sa durée et les résultats possibles.

Puis-je repasser une sortie en brouillon ?

Oui : tant que votre sortie est en mise en attente avant révision et que vous ne l’avez pas encore confirmée, elle n’est pas entrée en révision ; vous êtes donc libre de continuer à la modifier ou de la laisser en brouillon pour y revenir plus tard. Elle n’entre dans la file de révision qu’au moment où vous la confirmez.

Dois-je corriger tous les problèmes avant de confirmer ?

Vous devez résoudre les problèmes bloquants avant de pouvoir confirmer. Les problèmes informatifs ne vous empêchent pas de confirmer, mais ils méritent un coup d’œil : régler autant que possible avant la révision est la voie la plus rapide vers l’approbation.

---

Des questions sur Preflight QC ? Contactez notre équipe. Nous serons ravis de vous aider.