Webhooks : contrôler les destinataires et les reprises
Encadrer les notifications par webhook : destination autorisée, contenu minimal, tentatives répétées et suppression des envois en attente.
Un webhook envoie automatiquement des données lorsqu’un événement se produit : dossier créé, statut modifié ou document disponible. Si l’adresse du destinataire change ou si la livraison échoue, les tentatives répétées peuvent conserver et transmettre un contenu devenu obsolète. La revue doit couvrir l’événement, la destination et toute la file d’attente.
Ce qu’il faut retenir
- Un événement technique peut déclencher une communication de données personnelles.
- Limitez le contenu transmis au besoin réel du destinataire.
- La file d’attente et les journaux peuvent contenir leurs propres copies.
- Les changements de destinataire, de droit ou de statut doivent être pris en compte avant une nouvelle tentative.
Cartographier la chaîne de livraison
Pour chaque webhook, notez l’événement déclencheur, l’organisme destinataire, le propriétaire de la configuration, les données envoyées et les règles de reprise. Une URL seule ne permet pas toujours d’identifier la société ou l’équipe qui reçoit effectivement les données.
Les articles 5(1)(b), 5(1)(c), 5(1)(e) et 32(1) du RGPD imposent finalités, minimisation, conservation limitée et sécurité adaptée. RGPD. Une transmission automatisée reste soumise à ces exigences.
La spécification d’une API partenaire constitue le point de départ : les droits et le contenu autorisés doivent rester cohérents avec les notifications.
Définir le contenu de l’événement
| Option de contenu | Question à examiner |
|---|---|
| Simple référence | Le destinataire peut-il récupérer ensuite les seules données autorisées ? |
| Statut et date | Ces éléments suffisent-ils à l’opération ? |
| Fiche complète | Chaque champ est-il nécessaire à ce destinataire ? |
| Pièce jointe | Faut-il transmettre le document ou signaler sa disponibilité ? |
| Ancienne et nouvelle valeur | Les deux sont-elles indispensables au traitement prévu ? |
Exemple hypothétique : un prestataire doit être averti qu’un dossier est prêt. Envoyer l’identifiant utile et le nouveau statut peut suffire, au lieu de joindre toutes les pièces. Une récupération ultérieure reste à sécuriser et ne constitue pas automatiquement la meilleure solution dans tous les contextes.
La CNIL recommande de limiter les données partagées par API aux finalités et destinataires prévus, avec une coordination entre acteurs. CNIL, sécurité des API.
Maîtriser les tentatives et les événements en attente
Définissez le nombre ou la période de reprises selon le besoin, le traitement des échecs et la durée des contenus stockés. Le RGPD ne fixe pas une valeur universelle de tentatives pour les webhooks.
Vérifiez les conséquences d’un événement devenu ancien : données rectifiées, dossier supprimé, destinataire désactivé ou contrat terminé. Un renvoi tardif ne doit pas recréer sans examen une donnée retirée ou être adressé à une ancienne destination.
La propagation des rectifications doit couvrir ces files lorsque des données erronées y restent. Déterminez si l’événement doit être annulé, remplacé ou interprété avec son contexte historique, selon l’opération concernée.
Protéger la configuration et les traces
Restreignez la modification des destinations et des secrets aux personnes habilitées. Vérifiez l’authenticité des échanges et la protection de leur contenu avec les équipes techniques ; la méthode dépend de l’architecture et du risque.
Distinguez les informations nécessaires à la preuve de livraison du contenu personnel complet. Les journaux et outils de diagnostic ne doivent pas devenir un archivage parallèle de tous les événements. Notre guide sur les journaux d’erreurs aide à choisir les traces pertinentes.
Lors de la fermeture d’une intégration, désactivez les nouveaux envois, examinez les événements en attente et traitez le sort des copies. Vérifiez ensuite qu’aucune configuration secondaire ne continue les communications.
FAQ
Un webhook sans nom contient-il encore des données personnelles ?
Une référence, un statut ou un lien peut rester rattachable à une personne. L’absence de nom ne suffit pas à rendre l’événement anonyme.
Peut-on garder indéfiniment les événements en échec ?
Non. Définissez un besoin et une durée, puis un processus de traitement des échecs. L’utilité hypothétique d’une nouvelle tentative ne justifie pas un stockage permanent.
Une signature du message remplace-t-elle la minimisation ?
Non. Elle peut contribuer à la sécurité et à l’authenticité selon le mécanisme utilisé ; elle ne justifie ni les données excessives ni une destination sans autorisation.
Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.