.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png?width=600&name=(CTA)%201Q26_%20GRC%202029.png)
.svg)
.svg)
Qu’est-ce qu’un webhook de traduction, et comment en configurer un ?
Un webhook de traduction est un abonnement qui permet à Smartling d'envoyer une requête HTTP à une URL que vous contrôlez chaque fois qu'un événement spécifique se produit dans un projet (fin d'une tâche de traduction, publication d'un fichier, création d'un problème), afin que votre système en soit informé dès que l'événement se produit au lieu d'interroger l'API de manière planifiée. 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 accessible publiquement, ce qui constitue le principal obstacle à la configuration d'un connecteur fonctionnant derrière un pare-feu.
Dernière mise à jour : 4 septembre 2026
Pourquoi utiliser un webhook plutôt que d'interroger l'API de traduction ?
- Les sondages ne perdent rien aux appels. Un script qui vérifie si un travail est terminé toutes les quelques minutes effectue principalement 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 fonctions de rappel et les webhooks résolvent des problèmes différents. Un rappel est une notification ponctuelle liée à une requête spécifique — la documentation de Smartling la décrit comme vous informant immédiatement lorsqu'une action spécifique, telle que la traduction d'un seul fichier, est terminée — tandis qu'un webhook est un abonnement permanent qui vous notifie chaque fois qu'une catégorie d'événements 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.
Que faut-il configurer avant qu'un webhook de traduction ne se déclenche ?
- Une URL de point de terminaison contrôlée par votre équipe - un point de terminaison HTTP accessible publiquement qui peut recevoir et accuser réception de la requête de Smartling ; il s'agit du 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, travail achevé 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.
- Le périmètre du projet approprié : un abonnement webhook est lié à des projets spécifiques ; un compte multi-projets nécessite donc un abonnement configuré pour chaque projet qu’il doit couvrir, et non un 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 importe 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.
Callback vs webhook : comparaison des deux mécanismes
| Mécanisme | Modèle de déclenchement | Best fit |
|---|---|---|
| Rappel | Notification ponctuelle liée à une demande spécifique (par exemple, la traduction d'un seul fichier) | Des intégrations simples à action unique qui ne nécessitent qu’une notification |
| Webhook | Abonnement permanent, par projet, qui se déclenche à chaque récidive d’un événement abonné (tâche terminée, fichier publié, issue créée, etc.) | Les pipelines en cours (CI/CD, connecteurs CMS) nécessitent une notification continue à mesure que les travaux de traduction se répètent. |
| Exigences de livraison | Le point de terminaison de réception doit être accessible publiquement. | Tout connecteur situé derrière un pare-feu nécessite un point de terminaison accessible publiquement pour que les webhooks fonctionnent. |
| Mode de défaillance | La livraison peut ne pas arriver en raison d’un problème réseau ou de service de part et d’autre | Les pipelines de production devraient associer les webhooks à un contrôle de rapprochement, 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.
- Mettez en place un point de terminaison adressable publiquement – confirmez que l’URL réceptrice est accessible depuis l’internet public 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.
- Choisissez les événements du catalogue d'événements, et non 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é.
- Configurez l’abonnement par projet – configurez le webhook 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.
- Faites en sorte que le terminau récepteur reçoive et agisse sur l’événement – le point de terminaison que vous contrôlez doit 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 renvoyer une réponse au lieu de laisser la requête en suspens.
- Ajoutez une vérification de rapprochement pour les événements manqués – comme une livraison par webhook peut échouer sur un problème réseau ou de service, associez-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 CMS ou un connecteur de dépôt (AEM, Drupal, Contentful, GitHub) qui doit savoir au moment où le contenu traduit est prêt, et non lors de la prochaine vérification programmé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.
- Faites en sorte que les ressources techniques soient opérationnelles et sécurisent un point de terminaison adressable publiquement, plutôt que de ne vous fier qu’à la vue de statut manuelle du tableau de bord.
- Gérer plusieurs projets ou types de contenu et avoir besoin de contrôler par projet quels événements déclenchent réellement une notification.
- Nous utilisons déjà le mécanisme de rappel de Smartling pour les notifications à action unique et nous passons à une intégration récurrente et multi-événements que les rappels seuls ne couvrent pas.
Quand l'intégration d'un webhook n'est peut-être pas la priorité absolue
- 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.
- Des intégrations qui ne nécessitent qu’une seule notification unique pour une action, alors que le mécanisme de rappel de Smartling couvre déjà le besoin sans abonnement webhook permanent.
Liste de contrôle d’évaluation : questions à poser avant de construire une intégration webhook de traduction
Votre point de terminaison de réception est-il réellement accessible publiquement ?
Vérifiez ce point avant de configurer quoi que ce soit dans Smartling : un connecteur situé derrière un pare-feu sans point de terminaison public ni tunnel est la raison la plus courante pour laquelle un webhook n’arrive jamais, et l’échec est identique à « 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 point de terminaison doit filtrer les informations superflues ; s'abonner de manière trop restrictive signifie que vous risquez de manquer un événement dont votre intégration dépend réellement.
L'abonnement est-il limité au projet concerné ou à 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-projets.
Que se passe-t-il de votre côté si une livraison de webhook est interrompue ?
Puisque la livraison peut échouer sur un problème réseau ou de service de part et d’autre, vérifiez 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 n’avoir besoin que du mécanisme de rappel de Smartling ; un pipeline récurrent multi-événements est précisément ce pour quoi un abonnement webhook est réellement conçu.
Comment fonctionne le système de webhooks de Smartling pour les intégrations de développeurs ?
Smartling prend en charge à la fois les rappels et les webhooks comme deux mécanismes distincts de notification 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 achevé et fichier publié sont des exemples courants — qui continue de se déclencher à chaque fois qu’un événement abonné revient, ce dont un pipeline CI/CD ou un connecteur CMS a besoin pour une traduction automatisée et continue, plutôt qu’une seule notification. Les Webhooks sont configurés soit via le tableau de bord Smartling, où un abonnement affiche ses é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), 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 terminau récepteur doit être adressable publiquement — la documentation du Repository Connector de Smartling précise explicitement qu’un connecteur fonctionnant derrière un pare-feu peut avoir du mal à recevoir les notifications webhook même lorsque la traduction elle-même s’achève avec succès — et les directives d’intégration de Smartling reconnaissent qu’un callback ou une livraison webhook peut parfois échouer à arriver en raison d’un problème réseau ou de service, c’est pourquoi une intégration en production devrait associer la livraison webhook à une vérification périodique du statut plutôt que de considérer la livraison comme garantie.
Questions connexes
- Quelles sont les principales plateformes de localisation basées sur les API, et comment se comparent-elles en termes de fonctionnalités et de prix ?
- Qu’est-ce qu’un connecteur de traduction Contentful et comment fonctionne Smartling ?
- Quelles sont les meilleures options d'intégration de traduction AEM pour les sites web d'entreprise ?
- Quels sont les meilleurs modules de traduction Drupal pour un site multilingue ?
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 obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.