Dans l’interface du gestionnaire de destinations, cliquez sur “Nouvelle destination” ou l’icône équivalente pour commencer la création.

Saisissez l’URL complète du destinataire (https://…). Assurez‑vous que le domaine est accessible depuis l’extérieur et que le certificat TLS est valide si vous utilisez HTTPS.

Sélectionnez la méthode souhaitée (généralement POST). Pour certains flux, PUT ou PATCH peuvent être utilisés — vérifiez ce que le destinataire attend.

Ajoutez en‑têtes nécessaires comme Content-Type (application/json) et tout en‑tête exigé par le destinataire (ex. X-Custom-Token). Évitez d’exposer le secret dans un en‑tête public.

Choisissez le mode d’authentification : Bearer token, Basic auth, ou signature HMAC. Si vous utilisez un token, saisissez le token (ou sélectionnez un type géré) dans le champ prévu.

Activez la signature HMAC si disponible et fournissez/validez un secret partagé. Sélectionnez l’algorithme recommandé (ex. HMAC‑SHA256) si l’option existe.

Définissez la politique de réessai (nombre de tentatives, intervalle exponentiel) et activez le backoff pour éviter la surcharge côté destinataire.

Enregistrez la destination puis lancez un test de livraison (envoi d’un payload de test) pour vérifier l’authentification, la signature et la réception.

Consultez les logs de test et la réponse HTTP du destinataire pour corriger les en‑têtes, le format du payload ou les erreurs d’authentification.

N’acceptez que les connexions HTTPS avec certificats valides. Refusez les requêtes HTTP non sécurisées.

Vérifiez la présence et la validité de Authorization ou X-Api-Key si c’est la méthode configurée. Rejetez la requête si l’en‑tête est absent ou invalide.

Si une signature est fournie, récupérez le payload brut (avant parsing), appliquez la même méthode de hachage et comparez la signature reçue et calculée en utilisant une comparaison en temps constant.

Si un en‑tête X-Signature-Timestamp est présent, acceptez la requête seulement si le timestamp est dans une fenêtre de tolérance (ex. ±5 minutes). Rejetez les requêtes trop anciennes ou futures.

Vérifiez que le Content-Type correspond (ex. application/json) et que le payload respecte le schéma attendu avant de l’utiliser.

Pour les opérations non‑répétables, utilisez un identifiant unique fourni (ex. X-Request-Id) et stockez‑le temporairement pour détecter les livraisons en double.

Enregistrez les en‑têtes, les résultats de vérification (succès/échec) et la réponse renvoyée pour faciliter le diagnostic.

Renvoyez 2xx pour accepter la livraison, 4xx pour les erreurs définitives (ex. authentification échouée), 5xx si l’erreur est côté destinataire et mériterait un réessai.

Lancez l’envoi de test. Le test doit reproduire l’en‑tête de signature et d’authentification configurés.

• 2xx : livraison acceptée.
• 4xx : problème d’authentification ou de format ; vérifiez les en‑têtes et le schéma.
• 5xx : problème côté destinataire ; vérifier logs serveur du destinataire et re‑essayer.

Comparez les signatures (attendue vs calculée) et vérifiez le timestamp. Si le calcul diffère, vérifiez l’encodage, l’ordre des champs et la présence d’espaces ou de saut de ligne.

Assurez‑vous que le certificat du destinataire est valide et que le nom du host correspond à l’URL utilisée. Les erreurs TLS empêchent la livraison.

Testez avec payloads petits et volumineux. Certains destinataires ont des limites de taille ou des timeouts qui cassent les livraisons.

Si le destinataire est parfois indisponible, vérifiez la politique de retry et le backoff configurés pour éviter surcharge et duplications.

Prévenez le destinataire et planifiez une fenêtre de maintenance si nécessaire.

Configurez temporairement le destinataire pour accepter l’ancienne et la nouvelle signature simultanément (vérifiez les deux secrets lors de la validation).

Dans l’interface, remplacez le secret par le nouveau secret et sauvegardez.

Envoyez des tests et monitorisez les logs pour s’assurer que la nouvelle signature est validée. Conservez les journaux des deux signatures pendant une période transitoire (ex. 7 jours).

Une fois stabilisé, retirez l’ancien secret côté destinataire et n’acceptez plus que la nouvelle signature.

Supprimez l’ancien secret des systèmes, changez les clés si besoin et enregistrez l’opération dans votre gestionnaire d’accès.