La principale différence réside dans le moment du traitement
À 10 h 14, une équipe éditoriale publie la modification des coordonnées d'un service de conseil. Le site web doit immédiatement afficher le nouveau numéro de téléphone, un moteur de recherche du portail interne doit actualiser son index et une version linguistique accessible devra ensuite faire l'objet d'une vérification du fond. Ces conséquences découlent de la même modification, mais ne doivent pas toutes être traitées au même moment.
Un webhook est un message qu'un système envoie à un autre immédiatement après un événement. Le système éditorial indique par exemple : « Cette page a été publiée. » Le système destinataire peut alors récupérer et traiter précisément ce contenu. Il n'attend pas la prochaine exécution générale et ne recherche pas continuellement de nouvelles modifications.
Lors d'un traitement par lots, plusieurs tâches sont regroupées et exécutées ensemble. Chaque soir, toutes les pages modifiées dans la journée peuvent par exemple être vérifiées pour un rapport. Cette exécution n'est pas immédiate, mais elle se planifie facilement. Elle peut traiter de grandes quantités les unes après les autres et fournir le résultat sous forme de vue d'ensemble cohérente. Le traitement suit un début connu et une fin identifiable.
Les webhooks conviennent aux événements individuels importants
Les webhooks sont pertinents lorsqu'une réaction rapide apporte un avantage identifiable. Après la publication d'une alerte, l'application doit recevoir le même contenu à jour. Après le retrait d'une page, celle-ci doit disparaître de la recherche interne. Dans chaque cas, le message est créé par une action concrète et concerne un contenu clairement identifiable.
Pour l'équipe éditoriale, ce processus paraît immédiat. Elle valide une publication et voit peu après la nouvelle version dans le canal associé. Cette rapidité ne doit cependant pas être confondue avec une simultanéité garantie. Des erreurs de réseau, une maintenance ou un système destinataire surchargé peuvent retarder le traitement. Le système doit résister à ces interruptions.
Toutes les modifications enregistrées ne doivent pas déclencher un webhook. Un brouillon sauvegardé automatiquement n'est pas encore pertinent pour la recherche publique. Les événements utiles suivent le sens visible : publié, substantiellement actualisé, retiré ou supprimé. Les systèmes associés reçoivent ainsi moins de messages et peuvent traiter plus clairement les changements d'état importants. Les corrections internes de fautes de frappe peuvent, si nécessaire, être traitées autrement que les nouveaux faits.
Le traitement par lots convient aux volumes importants et aux échéances fixes
Une exécution importante convient lorsque de nombreux contenus doivent être traités selon les mêmes règles. Une organisation souhaite peut-être vérifier chaque nuit toutes les pages publiées afin de repérer les dates de vérification manquantes. Pour les lecteurs, le fait que le résultat soit disponible à 2 h ou à 2 h 20 change peu de choses. Un message immédiat après chaque petite modification serait inutilement complexe dans ce cas.
Une reconstruction complète peut elle aussi être délibérément regroupée. Après une modification du système de recherche, il faudra peut-être réindexer 80 000 pages. Des webhooks individuels ne décriraient pas le stock de manière fiable, car les contenus inchangés sont également concernés. Un traitement par lots commence avec un volume connu et consigne les pages traitées avec succès.
L'horaire fixe facilite la planification de la charge. Les descriptions d'images, les ébauches de traduction ou les contrôles de qualité approfondis exigent du temps de calcul et des services externes. Une exécution nocturne peut limiter ce travail sans ralentir la publication dans le système éditorial. Sa durée devient ainsi plus prévisible pour l'exploitation et le prestataire. Les contenus urgents ont néanmoins besoin d'une voie plus rapide si une longue attente entraînerait la diffusion de fausses informations.
Le délai autorisé est le premier critère de décision
La question la plus importante est la suivante : pendant combien de temps le système associé peut-il afficher un ancien état ? Pour une alerte météorologique, quelques minutes peuvent être déterminantes. Pour une analyse mensuelle de la qualité des textes, une journée ne pose généralement pas de problème. Une indication temporelle claire est plus utile que l'exigence générale selon laquelle chaque traitement doit être aussi rapide que possible.
Le volume d'une modification habituelle entre ensuite en ligne de compte. Si une seule page est généralement publiée, un webhook peut la désigner précisément. Si des ensembles complets sont régulièrement modifiés, une exécution planifiée offre davantage de clarté. L'importation de 4 000 nouveaux sites ne doit pas déclencher sans contrôle 4 000 traitements consécutifs simultanés.
Les conséquences d'une panne font elles aussi partie de la décision. Si un message se perd, un ancien numéro de téléphone peut rester dans l'application. Si un rapport nocturne échoue, l'équipe éditoriale peut le relancer le matin. Le délai tolérable doit être explicitement convenu pour chaque canal associé. Plus le préjudice immédiat est important, plus les nouvelles tentatives rapides, les avertissements visibles et une comparaison supplémentaire de l'ensemble des contenus deviennent nécessaires.
Un message de webhook reste court et sans ambiguïté
Un bon message indique ce qui s'est produit, le contenu concerné et le moment où l'événement a été créé. Il comprend également un numéro d'événement unique et la version du format du message. Le système destinataire peut ensuite récupérer les données complètes et actuelles par une interface protégée. Le message reste ainsi facile à gérer et ne contient pas inutilement l'article entier.
Cette approche évite également qu'un message retardé ne diffuse un ancien texte. Supposons qu'une équipe éditoriale corrige deux fois le même numéro de téléphone à quelques instants d'intervalle. En raison d'un dysfonctionnement, le premier message arrive après le deuxième. Si le système destinataire récupère l'état actuel, il reçoit néanmoins la dernière version validée, et non le contenu du message retardé.
Les contenus à caractère personnel ou confidentiels n'ont pas leur place dans le message sans nécessité. Les journaux, les rapports d'erreur et les interfaces d'administration conservent souvent les données des webhooks pendant une durée plus longue. Un identifiant de contenu et le type d'événement suffisent dans de nombreux cas. Le système destinataire autorisé récupère les autres informations uniquement lorsqu'il doit réellement les traiter. Même un rapport d'erreur technique reste ainsi exempt de contenus spécialisés inutiles.
Les messages répétés sont un cas normal
Lorsque le système destinataire ne confirme pas la réception d'un message, le système source l'envoie à nouveau. Le premier message a peut-être déjà été traité, mais sa confirmation s'est perdue. Le destinataire doit donc pouvoir accepter plusieurs fois le même événement sans publier deux fois un article ni commander deux fois la même traduction.
Le numéro d'événement unique est utile à cette fin. Si ce numéro a déjà été traité avec succès, le système peut confirmer la répétition et l'ignorer. Cette méthode est plus fiable qu'une comparaison des heures ou des titres. Deux modifications distinctes peuvent avoir lieu presque simultanément et un titre peut changer alors qu'il s'agit toujours du même contenu.
L'ordre n'est pas toujours garanti non plus. Un message sur la publication peut arriver après celui qui signale une correction ultérieure. Les numéros de version ou la récupération du contenu actuel empêchent l'ancien état de l'emporter. Pour les équipes éditoriales, cela signifie que l'état visible doit être correct même si les messages techniques suivent un parcours agité. La date de réception ne doit donc pas déterminer à elle seule la version valide.
Le destinataire doit vérifier l'origine
Une adresse de webhook accessible au public peut en principe être appelée par des personnes non autorisées. Le système destinataire ne doit donc pas faire confiance à un message uniquement parce qu'il arrive par le chemin attendu. Une signature numérique calculée à partir du contenu et d'une clé secrète partagée est couramment utilisée. Le destinataire la calcule à nouveau et compare les deux valeurs.
La transmission utilise HTTPS afin de protéger le contenu et les identifiants d'accès pendant le trajet. La clé secrète ne doit figurer ni dans le code source, ni dans une documentation publique, ni dans le texte du message. Elle est stockée de manière protégée, rendue accessible uniquement aux services nécessaires et renouvelée régulièrement. Les anciennes clés doivent devenir invalides après une transition contrôlée.
Un horodatage limite en outre la durée pendant laquelle un message correctement signé est accepté. Un appel enregistré ne peut ainsi pas être répété beaucoup plus tard à volonté. Les réponses d'erreur ne doivent révéler aucun détail interne aux attaquants. L'équipe interne conserve néanmoins suffisamment d'informations pour examiner précisément une signature refusée ou un format de message obsolète. Les accès suspects sont limités et consignés de manière traçable pour le contrôle de sécurité. Des délais de conservation appropriés et clairement documentés s'appliquent à ces journaux.
Un traitement important a besoin d'un état traçable
Pour 20 000 pages, un traitement par lots réussit rarement entièrement ou échoue entièrement. Certains contenus peuvent comporter des informations non valides tandis que le reste est correctement traité. L'exécution doit donc consigner pour chaque élément ce qui a réussi et ce qui doit faire l'objet d'une nouvelle tentative. Une seule page défectueuse ne doit pas bloquer toutes les pages suivantes.
Les limites des services externes doivent être prises en compte. Une interface autorise peut-être seulement un certain nombre de requêtes par minute. L'exécution divise alors le volume en groupes acceptables et reprend après une pause. Elle enregistre son avancement afin qu'un redémarrage ne reprenne pas à la première page et ne répète pas inutilement un travail déjà payé.
Pour l'équipe éditoriale, un résultat compréhensible est plus important qu'un long fichier de journal technique. Elle doit reconnaître l'exécution concernée, le nombre de contenus terminés et les pages qui nécessitent une aide spécialisée. Un message tel que « 37 erreurs » ne suffit pas. L'association avec le titre de la page, son adresse et la cause précise transforme l'erreur en tâche traitable. Une fois les nouvelles tentatives réussies, elles disparaissent de la liste éditoriale des tâches ouvertes.
Une exécution planifiée complète souvent les webhooks
Les webhooks et le traitement par lots ne s'excluent pas. Un portail d'actualités peut signaler immédiatement les nouveaux articles à son moteur de recherche et comparer tout son stock pendant la nuit. La voie rapide maintient les modifications importantes à jour. L'exécution planifiée trouve les événements manquants à cause d'un dysfonctionnement, d'un mauvais paramètre ou d'un système destinataire temporairement désactivé.
Une version linguistique accessible peut elle aussi nécessiter les deux rythmes. Lorsqu'une page spécialisée est modifiée, le webhook crée immédiatement une tâche pour l'équipe éditoriale compétente. La version validée n'est pas remplacée automatiquement. Un rapport quotidien indique en plus toutes les tâches ouvertes, leurs échéances et les contenus pour lesquels le lien avec la page source manque.
Une source claire de l'état valide est déterminante. Un webhook signale une modification, tandis que la comparaison régulière confirme l'état actuel du stock. Si les deux fournissent des informations différentes, le dernier processus exécuté ne doit pas l'emporter par hasard. Le système de publication reste la référence et les systèmes associés y alignent leur état. Cette règle doit rester documentée sans ambiguïté même après un changement de système.
Le fonctionnement doit rester compréhensible pour les personnes
La fiabilité technique se manifeste dans les informations visibles. Les équipes doivent savoir combien de temps une transmission prend habituellement et à partir de quel moment un retard est signalé. Un avertissement nomme le canal et le contenu concernés, et pas seulement un nom de processus interne. L'équipe éditoriale peut ainsi évaluer si les visiteurs voient actuellement un état obsolète.
Chaque processus a besoin d'un service responsable. Celui-ci peut renvoyer un message bloqué, poursuivre un traitement par lots ou arrêter une publication erronée. Il doit en même temps être clair quand une responsabilité liée au contenu est nécessaire. Une équipe technique peut transférer un fichier, mais ne peut pas décider si une condition d'admissibilité modifiée a été correctement expliquée sur le fond.
La solution adaptée découle donc du contenu, du temps et du préjudice possible. Les webhooks réagissent rapidement à des événements individuels. Les traitements par lots prennent en charge des volumes planifiables et comparent les stocks. Ensemble, ils couvrent les modifications actuelles et l'exhaustivité du stock. Lorsque les nouvelles tentatives, la sécurité et les messages compréhensibles sont prévus dès le départ, les sites web et services associés restent à jour sans alourdir le quotidien éditorial d'une technique inutile.