Checklist de mise en production

Une démo n’a besoin que d’une requête. Un produit doit résister aux délais dépassés, aux webhooks en double, aux liens expirés et à une clé qui fuit. Parcourez cette liste avant le lancement.

Clés

• La clé est dans le gestionnaire de secrets de votre serveur, jamais dans un navigateur ni dans une application.
• Chaque environnement et chaque service a sa propre clé, révocable seule.
• Les clés de production sont limitées aux modèles utilisés et ont un plafond quotidien.
• Vous savez renouveler une clé sans interruption (Authentification).

Créer des tâches

• Chaque createTask envoie un Idempotency-Key dérivé de votre propre identifiant de travail, généré une fois et réutilisé à chaque nouvelle tentative.
• Seuls 429, 500, 503 et 50301 sont réessayés, avec délai croissant et Retry-After (Erreurs).
• 400, 40004 et les autres erreurs « corrigez la requête » sont affichées ou journalisées, pas réessayées.
• Si vous affichez des prix, vous demandez d’abord un devis, passez quoteId et expectedCredits, et gérez 40901.
• Un solde bas (40201) alerte une personne — alerte, e-mail, bannière — avant que les utilisateurs ne s’en aperçoivent.

Récupérer les résultats

• Les tâches portent une callBackUrl ; votre endpoint vérifie la signature et rejette les horodatages trop anciens.
• Le gestionnaire de webhook répond 2xx rapidement et fait le travail en tâche de fond.
• Les livraisons en double sont ignorées grâce à request_id.
• Un passage régulier lit les tâches dont le webhook n’est jamais arrivé.
• Votre code considère tout état autre que succeeded, failed, expired et canceled comme « encore en cours ».

Fichiers

• Les fichiers terminés sont copiés dans votre propre stockage (ou votre bibliothèque de ressources) au lieu de pointer vers l’URL signée, qui expire au bout d’une vingtaine de minutes.
• Vous stockez des taskId, pas des liens signés.
• Votre code de téléchargement n’envoie pas la clé API à l’URL signée.
• Les fichiers de référence sont des liens HTTPS publics vers le fichier lui-même, des envois ou des ressources — pas des pages de partage.

Coûts

• Vous connaissez l’unité de prix de chaque modèle (par image, par seconde, par requête) et les réglages qui la font monter.
• Les aperçus et les tests utilisent la résolution la moins chère et la durée la plus courte.
• Un plafond de dépense arrête les boucles incontrôlées avant qu’elles ne vident le solde.
• Vous vérifiez credits et settled au lieu de supposer que l’estimation a été débitée.

Supervision

• Vous journalisez request_id, taskId, code et errorCode pour chaque échec.
• Vous suivez la part de tâches failed par modèle ; une hausse soudaine signale en général un changement de prompt, d’entrée ou de modèle.
• Vous mesurez le délai entre createTask et le webhook par modèle, avec une alerte sur les valeurs aberrantes.
• Quelqu’un dans l’équipe sait où se trouvent les journaux et la page d’usage de la console API.

Contenu

PopNow est un service grand public. Les modèles appliquent leurs propres règles de contenu, et les requêtes qu’ils refusent échouent avec content_rejected. Si vos utilisateurs écrivent les prompts, expliquez-leur dans votre propre interface pourquoi une requête a été refusée, plutôt que d’afficher une erreur brute, et laissez-les la modifier.