Beaucoup d'équipes choisissent d'abord un relais ou un proxy pour intégrer Kling : changer l'URL de base et la clé semble plus simple qu'un accès direct. Mais la génération vidéo repose sur des tâches asynchrones, et un relais ajoute, par rapport à une API texte, la persistance des tâches, la correspondance des états, la transmission des callbacks et la recopie des résultats. Si un maillon est fragile, le symptôme est toujours le même : « la soumission réussit, mais la vidéo n'arrive pas ».

Cet article part de la chaîne réelle d'un relais et traite la fiabilité des tâches, la conservation des résultats, la transparence de la facturation, les risques liés aux clés et les critères d'acceptation d'une migration depuis un accès direct.

Remarque : Kling est une marque ou une marque déposée de Kuaishou et de ses sociétés affiliées. Cet article est purement technique et n'implique aucune affiliation ni coopération avec Kuaishou. Les interfaces, modèles et règles de facturation font foi dans la documentation officielle et sur la page Tarifs des modèles du site ; les prix peuvent évoluer.

1. Quatre types de « relais » : sachez ce que vous achetez

Type Ce qui est réellement fourni Risque principal Cas adapté
Proxy inverse Transmet les requêtes vers l'API amont Point unique, bande passante de sortie, configuration d'authentification Équipes avec ops, voulant unifier la sortie
Passerelle agrégatrice Point d'entrée unique, plusieurs modèles vidéo Correspondance des états, écarts de paramètres, recopie des résultats Activité multi-modèles, petites équipes
Distribution / recharge déléguée Revente de quotas ou paiement pour compte Stabilité amont, conditions de service, sécurité du solde Essai temporaire, petits besoins
Passerelle auto-hébergée Déploiement et maintenance de la couche de transfert Serveur, certificats, anti-abus entièrement à votre charge Besoin de maîtrise des données, équipe technique

Ce que vous achetez — un « service technique » ou un « quota de modèle » — détermine qui répond en cas de panne, qui émet la facture et avec qui vous signez les clauses de données. Vérifiez le contrat et la facture selon cette distinction, sans vous fier au seul nom Kling affiché sur une page.

2. Le parcours des états dans la chaîne de relais

Votre application
  → point d'entrée du relais (authentification, quotas, facturation)
  → création de la tâche en amont, retour de l'id de tâche
  → le relais enregistre la correspondance id de tâche / numéro métier
  → le relais interroge l'amont ou reçoit les callbacks
  → conversion en états unifiés, API d'interrogation ou webhook
  → vous téléchargez et recopiez le résultat

Les états de la nouvelle interface sont généralement submitted, processing, succeeded et failed ; l'ancienne peut écrire l'état de réussite succeed. Si le relais ne mappe que réussite et échec, votre application peut attendre indéfiniment processing ; si une tâche amont expire, il faut aussi prévoir une sortie de type expired.

Chaque saut supplémentaire est une occasion de perdre un état : le relais redémarre et la correspondance en mémoire disparaît ; l'amont a créé la tâche mais le relais renvoie un échec, et l'appelant resoumet ; un callback sans clé d'idempotence est enregistré deux fois côté métier. À l'évaluation, demandez : où sont stockés les identifiants de tâche, pendant combien de temps, peut-on retrouver une tâche par numéro métier, et comment les échecs sont-ils compensés ?

3. Conservation et recopie des résultats

La documentation officielle indique que les URL de résultats générés sont nettoyées après 30 jours et que les adresses sont protégées contre le hotlinking. Trois pratiques de relais existent, avec des responsabilités très différentes :

  • Transmettre l'URL amont : l'appelant assume la recopie dans les 30 jours.
  • URL mise en cache ou proxifiée : préciser le retour à la source après expiration, la durée de cache et la facturation éventuelle.
  • Recopie hébergée : le relais télécharge et conserve durablement ; vérifier l'emplacement, les droits d'accès, la suppression et la durée de conservation.

Un « lien permanent » semble pratique, mais si le relais ne fait que pointer son domaine vers une adresse amont qui expire, il sera également inaccessible après expiration. Lors de l'acceptation, vérifiez l'accès 24 heures après la réussite, puis à l'approche du 30e jour, pour confirmer que le lien fonctionne encore.

4. Comment vérifier la transparence de la facturation

Une vidéo Kling est souvent facturée selon la durée, la résolution, l'audio ou le contrôle de mouvement, avec parfois des packs et des slots de concurrence. Un relais peut ajouter une marge, imposer un minimum de consommation ou modifier la validité des packs : ne regardez pas uniquement la remise annoncée.

Pour le rapprochement, exigez au minimum : identifiant de tâche, numéro métier, modèle, durée, résolution, état, montant débité et devise. Le champ billing des callbacks officiels distingue les débits en espèces et sur pack, avec montant, devise et type de forfait ; la manière dont le relais expose ces champs est un indicateur direct de transparence.

Vérifiez aussi si les échecs, timeouts, annulations et refus de modération sont facturés, si les soumissions en double sont dédupliquées, et comment remboursements et factures sont traités. Les prix font foi sur la page Tarifs des modèles. Avant de signer, faites tourner 20 à 50 petites tâches pendant une semaine et alignez ligne par ligne réussites, échecs et facture.

5. Clés, données et risques amont

Les requêtes passant par un tiers, les prompts, images de première frame et vidéos générées peuvent être vus ou stockés. Avant l'achat, vérifiez :

  1. La clé peut-elle limiter le quota, les IP et la durée de validité ? Peut-elle être bloquée rapidement en cas de fuite ?
  2. Les requêtes et résultats sont-ils stockés, pendant combien de temps, où, et qui y a accès ?
  3. Les données servent-elles à l'entraînement ou à l'amélioration du service ? Peut-on signer une clause de traitement des données ?
  4. L'amont est-il un canal unique ou multiple ? Comment les retraits de modèles et changements de version sont-ils notifiés ?
  5. Les conditions autorisent-elles la revente ou le proxy ? Comment les responsabilités sont-elles délimitées en cas de litige ?
  6. Qui signe les callbacks, quelle est la fenêtre d'horodatage, comment les rejeux sont-ils refusés ?

Ne placez jamais une clé de production dans un frontend, un dépôt ou une capture de ticket. Pour les contenus sensibles, privilégiez un prestataire sans stockage ou avec accord signé ; à défaut, anonymisez avant l'envoi. La clé Kling n'est généralement affichée en entier qu'une fois dans la console : si elle est perdue, créez-en une nouvelle au lieu de deviner.

6. Migrer de l'accès direct vers un relais

  1. Inventorier les appels existants : modèles, paramètres, concurrence, durée moyenne et types d'échec.
  2. Établir une table de correspondance : domaines, authentification, champs, états et codes d'erreur.
  3. Valider en environnement de test les quatre chemins : création, interrogation, callback et téléchargement.
  4. Faire tourner un shadow run sur le même lot, accès direct et relais en parallèle, en comparant sans basculer.
  5. Comparer taux de réussite, latence P95, taux de téléchargement et coût par vidéo réussie.
  6. Basculer progressivement 5 % à 20 % du trafic, avec un interrupteur de retour à l'accès direct.
  7. Observer 3 à 7 jours et vérifier que facture, détail des tâches et numéros métier se rapprochent.
  8. Après le basculement complet, conserver une période de secours sur deux canaux, puis simplifier l'architecture.

Pendant la migration, ne supprimez pas la clé directe et n'écrivez pas deux jeux de tâches sous le même numéro métier : le rapprochement deviendrait impossible.

7. Comment valider un relais

# 1. Soumettre une tâche minimale ; noter l'id de tâche, le numéro métier et l'heure
curl -X POST "$RELAY_BASE_URL/text-to-video/kling-2.6" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Un chat baille près d'une fenêtre",
    "settings": {"duration": 5, "resolution": "720p", "aspect_ratio": "16:9"},
    "options": {"external_task_id": "relay-test-20261019-01"}
  }'

# 2. Interroger toutes les 10 secondes ; noter le parcours complet des états et les messages d'erreur
curl "$RELAY_BASE_URL/tasks?task_ids=$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Provoquez volontairement des anomalies : annulation immédiate après soumission, identifiant de modèle erroné, dépassement de concurrence, coupure pendant le téléchargement, callback envoyé deux fois. Observez si les états, codes d'erreur et débits renvoyés par le relais restent cohérents. Revenez sur l'URL de résultat après 24 heures, puis après 7 jours, et une dernière fois à l'approche de 30 jours pour vérifier que lien et enregistrement existent toujours.

8. Supervision et retour arrière après migration

  • Compter les tâches par état, en surveillant la part de failed, cancelled et tâches expirées.
  • Mesurer le temps total entre soumission et réussite, en séparant attente en file et génération.
  • Surveiller le taux de téléchargement ; envoyer les échecs dans une file de compensation plutôt que réessayer sans fin.
  • Compter les 401, 404, 429 et 5xx, en distinguant clé, modèle, concurrence et panne amont.
  • Calculer le coût par vidéo réussie, pas seulement le prix d'une requête.
  • Définir un seuil de retour arrière : par exemple, repasser en direct si le taux de réussite reste nettement sous la référence pendant deux heures.

Questions fréquentes

Les vidéos générées via un relais sont-elles identiques à celles d'un accès direct ?

Cela dépend de la transmission du même modèle et des mêmes paramètres en amont. Version, durée, résolution et audio peuvent différer : avant l'intégration, comparez plusieurs vidéos avec le même prompt et les mêmes paramètres.

Le relais conserve-t-il mes vidéos ?

Cela varie. Demandez si les fichiers sont stockés, pendant combien de temps, où, qui peut y accéder et comment ils sont supprimés. Pour des contenus clients, privilégiez des conditions clairement définies.

Une tâche se perd côté relais : que faire ?

Cherchez d'abord par numéro métier dans vos enregistrements locaux, puis dans les journaux du relais et les tâches amont. Sans récupération possible, il faut resoumettre. Vérifiez donc avant la migration si le relais persiste la correspondance des tâches et permet une recherche par numéro métier.

La facture ne correspond pas au nombre de tâches : pourquoi ?

Les causes fréquentes sont les soumissions en double, les retries après échec, des règles d'annulation différentes, un minimum de consommation ou un pack expiré. Exigez le détail des débits par identifiant de tâche et vérifiez ligne par ligne, pas seulement le total.

Combien de code faut-il modifier pour migrer ?

Si le relais est compatible avec l'interface officielle, seuls le domaine, la clé et quelques champs changent ; si la correspondance des états ou le format des callbacks diffère, il faut adapter le polling et la persistance. Un shadow run permet de détecter l'essentiel des écarts.

Prochaines étapes

Créez une clé de test sur ZSQH AI Gateway, validez les quatre chaînes — création, polling, callback et facturation — avec une tâche minimale, puis migrez progressivement. Les modèles et tarifs sont sur la page Tarifs des modèles ; la disponibilité du canal vidéo Kling est précisée dans la documentation du site.

Lectures associées :