Smartling nommé chef de file dans The Forrester Wave™ : services de localisation, 3e trimestre 2026.
Smartling nommé Leader dans The Forrester Wave™
Lire le rapport

Qu’est-ce qu’un webhook de traduction, et comment en configure-t-on un?

Un webhook de traduction est un abonnement qui fait envoyer à Smartling une requête HTTP vers une URL que vous contrôlez chaque fois qu’un événement spécifique se produit dans un projet — une tâche de traduction terminée, une publication de fichiers, un problème créé — afin que votre système le découvre dès que cela se produit au lieu de sonder l’API selon un calendrier. Les Webhooks sont configurés par projet via le tableau de bord Smartling ou l’API Webhooks, et le point de terminaison qu’ils appellent doit être adressable publiquement, ce qui est le bloqueur de configuration le plus courant pour un connecteur fonctionnant derrière un pare-feu.

Dernière révision : 4 septembre 2026

Pourquoi utiliser un webhook au lieu de sonder l’API de traduction?

  • Les sondages gaspillent des appels pour rien. Un script qui vérifie toutes les quelques minutes si une tâche est terminée fait la plupart du temps des appels API vides entre les rares moments où quelque chose a réellement changé.
  • L'interrogation périodique ajoute de la latence de façon intentionnelle. Même un intervalle d'interrogation de cinq minutes signifie qu'une traduction terminée peut rester non traitée jusqu'à cinq minutes avant que quoi que ce soit ne le remarque — un webhook se déclenche dès que l'événement se produit.
  • Les rappels et les webhooks résolvent différents problèmes. Un rappel est une notification unique liée à une demande précise — la documentation de Smartling la présente comme un avertissement immédiat lorsqu’une action spécifique, comme la traduction d’un seul fichier, est terminée — tandis qu’un webhook est un abonnement permanent qui vous informe à chaque fois qu’une catégorie d’événement se répète dans un projet.
  • Un pare-feu bloque silencieusement la notification, pas la traduction. La documentation du connecteur de référentiel de Smartling indique clairement que les webhooks nécessitent que le point de terminaison de réception soit accessible publiquement ; un connecteur situé derrière un pare-feu peut traduire le contenu avec succès et ne jamais recevoir la notification de fin de traitement.
  • Des problèmes de réseau ou de service peuvent interrompre la livraison d'un webhook. La documentation d'intégration de Smartling reconnaît qu'un rappel ou un webhook peut ne pas arriver en raison d'un problème de réseau ou de service de part et d'autre, c'est pourquoi un pipeline construit uniquement autour de « l'attente du webhook » sans solution de repli présente un mode de défaillance réel, bien que rare.

Qu’est-ce qu’il faut configurer avant qu’un webhook de traduction soit déclenché?

  • Une URL de terminaison que votre équipe contrôle – un point de terminaison HTTP adressable publiquement capable de recevoir et de réceptionner la requête de Smartling; c’est le champ défini directement dans la configuration webhook du tableau de bord Smartling ou via l’API Webhooks.
  • Un ensemble spécifique d’événements abonnés – les webhooks – est axé sur les types d’événements auxquels vous êtes abonné (par exemple, tâche complétée ou fichier publié), listés dans le catalogue d’événements de Smartling, plutôt que de déclencher par défaut chaque changement possible de projet.
  • La bonne portée de projet – un abonnement webhook est lié à des projets spécifiques, donc un compte multi-projets a besoin d’un abonnement configuré par projet qu’il devrait couvrir, pas d’un seul paramètre global.
  • Un propriétaire d’abonnement visible – le tableau de bord indique si un webhook a été configuré via l’interface utilisateur ou « Ajouté par API », ce qui est important lorsque plusieurs membres du système ou de l’équipe gèrent des abonnements.
  • Un plan pour les échecs de livraison : étant donné qu’un webhook peut ne pas arriver en raison d’un problème de réseau ou de service, une intégration en production nécessite soit une attente de nouvelle tentative de la part de Smartling, soit un contrôle de réconciliation périodique côté réception, et non une conception qui suppose que chaque événement arrive toujours.

Rappel vs. webhook : comment les deux mécanismes se comparent

Mécanisme Modèle de déclenchement Best fit
RappelNotification unique liée à une demande spécifique (par exemple, la traduction d’un seul fichier)Des intégrations simples à action unique qui n’ont besoin que d’une notification
WebhookAbonnement permanent, par projet qui se déclenche chaque fois qu’un événement abonné revient (tâche complétée, fichier publié, numéro créé, etc.)Pipelines en cours — connecteurs CI/CD, CMS — qui nécessitent une notification continue au fur et à mesure que le travail de traduction se répète
Exigences de livraisonLe point de terminaison de réception doit être accessible publiquement.Tout connecteur derrière un pare-feu a besoin d’un point de terminaison accessible au public avant que les webhooks fonctionnent
Mode de défaillanceLa livraison peut ne pas arriver en raison d’un problème de réseau ou de service de part et d’autre.Les pipelines de production doivent associer les webhooks à un contrôle de réconciliation, et non supposer une livraison à 100 %.

Comment configurez-vous un webhook de traduction pour une intégration CMS ou CI/CD?

La configuration d'un webhook pour une intégration basée sur un connecteur (AEM, Drupal, Contentful ou un pipeline CI/CD personnalisé) suit la même séquence quel que soit le système qui reçoit la notification.

  1. Configurez un point de terminaison accessible publiquement : vérifiez que l’URL de réception est accessible depuis Internet avant de configurer quoi que ce soit dans Smartling, car un connecteur derrière un pare-feu sans point de terminaison public est la raison la plus courante pour laquelle un webhook n’arrive jamais silencieusement.
  2. Choisissez les événements du catalogue d'événements, pas tous ; abonnez-vous spécifiquement aux événements sur lesquels votre intégration doit agir (tâche terminée, fichier publié) plutôt qu'à un abonnement général qui envoie des notifications que votre système doit filtrer de son côté.
  3. Configurez l’abonnement par projet – configurez la connexion web dans le tableau de bord Smartling ou via l’API Webhooks pour chaque projet à couvrir, en confirmant que l’URL du point de terminaison et les événements abonnés sont corrects avant de vous y fier.
  4. Faites en sorte que le point de terminaison récepteur reçoive et agisse sur l’événement – le point de terminaison que vous contrôlez devrait accepter la requête de Smartling, déclencher l’action qui en dépend (extraire du contenu traduit dans un CMS, reprendre un pipeline CI/CD), et retourner une réponse au lieu de laisser la requête en suspens.
  5. Ajoutez une vérification de rapprochement pour les événements manqués – parce qu’une livraison par webhook peut échouer sur un problème réseau ou service, combinez-la à une vérification occasionnelle du statut de l’API pour des tâches qui auraient dû déclencher un webhook mais ne l’ont pas fait, plutôt que de faire confiance à la livraison comme garanti.

Cette approche convient aux équipes qui...

  • Exécutez un connecteur CMS ou de référentiel (AEM, Drupal, Contentful, GitHub) qui doit savoir dès que le contenu traduit est prêt, et non lors de la prochaine vérification planifiée.
  • Déclencher une étape du pipeline CI/CD — reprendre une compilation, déployer du contenu traduit — basée sur la fin de la traduction, où le polling ajouterait un délai inacceptable.
  • Avoir des ressources d'ingénierie pour mettre en place et sécuriser un point de terminaison accessible publiquement, plutôt que de se fier uniquement à la vue d'état manuelle du tableau de bord.
  • Gérer plusieurs projets ou types de contenu et avoir besoin de contrôle par projet sur les événements qui déclenchent réellement une notification.
  • J’utilise déjà le mécanisme de rappel de Smartling pour les notifications en une seule action et nous évoluons vers une intégration récurrente multi-événements que les rappels seuls ne couvrent pas.

Quand une intégration webhook n’est peut-être pas la bonne priorité

  • Pour les petits projets de traduction peu fréquents, la vérification manuelle de l'état des tâches dans le tableau de bord est nettement plus rapide à mettre en place que la création et la sécurisation d'un point de terminaison webhook.
  • Pour les équipes ne disposant d'aucune infrastructure accessible publiquement et n'ayant aucun plan à court terme pour en mettre une en place, un système de rappel lié à une demande spécifique ou des vérifications d'état manuelles constituent la solution de repli réaliste en attendant que cela change.
  • Les intégrations qui ne nécessitent qu'une seule notification ponctuelle pour une seule action, où le mécanisme de rappel de Smartling couvre déjà ce besoin sans abonnement webhook permanent.

Liste de vérification d’évaluation : questions à poser avant de construire une intégration de webhooks de traduction

Votre point de terminaison récepteur est-il réellement adressable publiquement?
Vérifiez cela avant de configurer quoi que ce soit dans Smartling — un connecteur derrière un pare-feu sans point de terminaison public ou tunnel est la raison la plus courante pour laquelle un webhook n’arrive jamais, et la panne ressemble à « rien ne s’est passé » du côté de Smartling.

Quels événements spécifiques avez-vous réellement besoin, dans le catalogue complet des événements?
S’abonner à tout signifie que votre endpoint doit filtrer le bruit; s’abonner trop étroitement signifie que vous manquez un événement dont votre intégration dépend réellement.

L’abonnement est-il axé sur le bon projet, ou sur tous les projets du compte?
Confirmez explicitement la portée plutôt que de supposer qu’une seule configuration de webhook couvre un compte multi-projet.

Que se passe-t-il de votre côté si une livraison par webhook est abandonnée?
Puisque la livraison peut échouer sur un problème réseau ou de service de part et d’autre, assurez-vous que votre intégration a une vérification de rapprochement plutôt que de supposer que chaque événement arrive toujours.

Avez-vous besoin d'un rappel ponctuel ou d'un abonnement webhook permanent ?
Une intégration à action unique peut ne nécessiter que le mécanisme de rappel de Smartling ; un pipeline récurrent à événements multiples est précisément ce pour quoi un abonnement webhook est conçu.

Comment fonctionne le système webhook de Smartling pour les intégrations de développeurs?

Smartling prend en charge à la fois les rappels et les webhooks comme deux mécanismes de notification distincts pour des intégrations personnalisées. Un rappel est une notification unique, spécifique à une requête — elle informe immédiatement une intégration lorsqu’une action particulière, comme la traduction d’un seul fichier, est terminée. Un webhook est un abonnement permanent, par projet, à un ou plusieurs types d’événements issus du catalogue d’événements de Smartling — travail complété et fichier publié en sont des exemples courants — qui continue de se déclencher chaque fois qu’un événement abonné se récidifère, ce dont un pipeline CI/CD ou un connecteur CMS a besoin pour une livraison automatisée de traduction continue plutôt qu’une seule notification. Les Webhooks sont configurés soit via le tableau de bord Smartling, où un abonnement affiche les événements abonnés, les projets associés et l’URL du point de terminaison (et est étiqueté « Ajouté par API » lorsqu’ils sont configurés par programmation plutôt que via l’interface utilisateur), soit directement via l’API Webhooks de Smartling pour les équipes souhaitant gérer les abonnements comme du code. L’exigence technique que les développeurs rencontrent le plus souvent est que le point de terminaison récepteur doit être adressable publiquement — la documentation du connecteur de dépôt de Smartling précise explicitement qu’un connecteur fonctionnant derrière un pare-feu peut avoir de la difficulté à recevoir les notifications de webhook même lorsque la traduction elle-même se termine avec succès — et les directives d’intégration de Smartling reconnaissent qu’un rappel ou une livraison par webhook peut parfois échouer à recevoir en raison d’un problème de réseau ou de service, ce qui explique pourquoi une intégration en production devrait jumeler la livraison par webhook à une vérification périodique de statut plutôt que de considérer la livraison comme garantie.

Questions connexes

Prêt à voir Smartling en action?

Discutez avec un membre de l’équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.

Prendre un rendez-vous