Webhooks : contrôler les destinataires et les reprises

Un webhook transmet automatiquement un message lorsqu’un événement se produit : dossier prêt, rendez-vous déplacé ou document disponible. Dès que ce message concerne une personne identifiable, sa destination, son contenu et ses nouvelles tentatives d’envoi doivent être maîtrisés. Une signature valide ou une réponse technique positive ne démontre pas, à elle seule, que la communication est autorisée et correctement traitée.

Le point sensible est le temps écoulé entre la création de l’événement et sa livraison. Un destinataire peut perdre son habilitation, une adresse être corrigée ou un dossier changer d’affectation pendant que le message attend. La revue RGPD doit donc examiner le circuit complet, jusqu’aux files d’échec et aux copies chez le destinataire.

Décrire la communication avant de configurer l’adresse

Pour chaque webhook, associez l’événement à une opération précise : qui doit être averti, sur quels dossiers, pour faire quoi et pendant quelle période ? Une URL ne suffit pas à identifier l’organisme destinataire. Retrouvez son propriétaire, l’environnement visé et les éventuels services intermédiaires qui reçoivent le contenu.

La communication doit respecter la finalité, la minimisation, l’exactitude et la conservation limitée. La base légale du traitement doit être déterminée ; le choix du webhook n’en fournit aucune. RGPD, Art. 5(1)(b) à (e) et Art. 6(1).

Si le destinataire agit pour votre compte, documentez les instructions et l’assistance attendue dans la relation de sous-traitance. S’il poursuit ses propres finalités, examinez ce partage selon les responsabilités réelles. Le nom « intégration partenaire » ne tranche pas cette qualification. Art. 4(7) et (8) et Art. 28(3).

La spécification d’une API partenaire permet d’aligner le périmètre accessible sur celui des notifications. Un destinataire ne doit pas recevoir, par événement automatique, des données que ses appels ordinaires ne l’autorisent pas à consulter.

Choisir ce que contient le message

Une notification peut contenir une référence seule, un statut, une date ou une copie complète du dossier. Le choix dépend de l’action attendue. Si le destinataire doit simplement savoir qu’un dossier est disponible, son historique, ses commentaires et ses pièces jointes ne sont pas nécessaires par défaut.

La CNIL recommande de limiter les données partagées par API aux destinataires et finalités prévus, et d’organiser la coordination entre acteurs. Cette recommandation technique ne remplace pas l’analyse du traitement. CNIL, sécurité des API.

Une référence avec récupération ultérieure peut réduire le contenu de la notification. Mais la récupération doit vérifier les droits au moment de l’appel. Un lien qui ouvre directement un dossier à toute personne qui le détient peut, au contraire, créer un accès difficile à maîtriser. L’absence de nom dans le message ne rend pas la référence anonyme si elle reste rattachable à une personne.

Définissez aussi la signification temporelle des champs. « Dossier prêt à 9 heures » peut décrire un événement historique ; « dossier actuellement disponible » affirme un état présent. Si le message sert à déclencher une action actuelle, il faut prévoir comment vérifier que cet état et les droits sont toujours valables.

La fiche W-18 : notification sans dossier complet

Prenons une situation entièrement fictive. Une entreprise organise des interventions à domicile. Elle traite les données nécessaires à l’exécution de la prestation demandée par son client, sur l’Art. 6(1)(b). Un opérateur de planification agit comme sous-traitant, dans le périmètre expressément retenu pour cet exemple. Le webhook l’avertit qu’une intervention qui lui est affectée peut être préparée.

Voici la spécification décidée pour W-18. Elle ne décrit ni un produit essayé ni une configuration universelle.

L’adresse et le téléphone restent nécessaires à une étape ultérieure de cette prestation, mais pas à cette notification. Cette distinction évite de présenter la minimisation comme une interdiction absolue de transmettre des coordonnées. Le contenu dépend du destinataire, de l’opération et du moment.

La fiche doit préciser la période de reprise, la conservation et les responsables selon le service réel. Le RGPD ne fixe pas un nombre universel de tentatives. Une équipe peut choisir une fenêtre adaptée à son besoin, mais doit ensuite expliquer le sort des événements expirés et des traces restantes.

Trois livraisons qui n’appellent pas la même action

À 9 h, W-18 crée un événement pour l’opérateur A. La tentative échoue. À 9 h 02, l’intervention est réaffectée à B. À 9 h 05, une reprise automatique est prévue. Dans ce scénario, A n’a plus de besoin autorisé pour préparer cette intervention : la reprise vers A est annulée. On ne remplace pas simplement son adresse par celle de B dans l’ancien message sans examiner les règles de cette nouvelle communication. Un événement approprié est créé pour B si les conditions sont réunies.

Deuxième situation : B reçoit un événement, mais la réponse de son serveur se perd. Le système émet de nouveau le même événement. Le destinataire doit pouvoir reconnaître cette répétition et éviter de créer deux interventions. Cette propriété doit être définie dans le contrat technique : quelle référence identifie l’événement, combien de temps la mémoire des traitements est utile, et que signifie une nouvelle tentative ?

Troisième situation : l’événement annonce une intervention désormais annulée. Le message ancien ne doit pas recréer une tâche active par simple arrivée tardive. Le destinataire vérifie l’état de référence ou applique le mécanisme de version prévu. Le bon comportement dépend du système ; il doit être écrit et vérifiable, pas laissé à l’ordre supposé des communications.

À titre d’exemple technique concret, GitHub documente l’emploi d’un identifiant de livraison et précise qu’une réémission du même événement conserve l’identifiant de la livraison originale. Sa documentation distingue également la réception du message d’un traitement ultérieur dans une file. Ces propriétés concernent GitHub ; vérifiez celles de votre propre fournisseur plutôt que de les transposer implicitement. Documentation GitHub sur les webhooks.

Protéger l’envoi, la réception et la configuration

La sécurité doit être adaptée aux risques de divulgation, d’altération et de perte, conformément à l’Art. 32(1) et (2). Protégez les communications et les secrets, limitez les personnes qui peuvent modifier les destinations, et vérifiez l’origine des messages avant de les utiliser. La preuve technique d’origine ne valide pas la finalité ou les champs transmis.

Une modification de destination doit être contrôlée comme un changement de destinataire potentiel. Qui l’a demandée ? Quel organisme reçoit désormais les messages ? L’adresse est-elle prévue pour la production ? Que deviennent les événements déjà en attente et les accès liés à l’ancienne intégration ? Conservez la décision et les références de configuration utiles, sans exposer les secrets dans le dossier de conformité.

Évitez les données personnelles et les identifiants d’authentification dans une URL lorsqu’ils n’y sont pas nécessaires. GitHub met notamment en garde contre l’inclusion d’informations sensibles dans l’adresse de destination et recommande de protéger le secret et les communications. Il s’agit d’un repère technique à adapter, non d’une certification de votre circuit.

Au niveau de la réception, une validation technique ne doit pas déclencher automatiquement toute opération permise par le logiciel. Le message doit aussi correspondre à un événement attendu, à un destinataire autorisé et à une version connue. Un type inconnu exige une décision de traitement ; l’accepter silencieusement peut élargir l’intégration à de nouvelles données.

Prévoir une recette avec des résultats attendus

Avant la mise en service, utilisez des données fictives et des destinations maîtrisées. Voici les résultats attendus pour W-18, à vérifier effectivement dans votre environnement :

• Un événement autorisé produit une seule tâche chez le bon opérateur ; sa répétition ne crée pas une seconde tâche.
• Après réaffectation, l’ancien opérateur ne reçoit pas la reprise et ne peut plus récupérer le dossier.
• Une intervention annulée reste annulée même si une notification ancienne arrive ensuite.
• Une destination non approuvée, un message non authentifié ou un type inconnu ne déclenche pas l’action métier.
• Une interruption prolongée produit une alerte exploitable et un traitement de la file, pas une accumulation invisible.

Ces résultats sont une spécification, pas le compte rendu d’un essai réellement effectué. Conservez les observations de vos propres contrôles et les réserves. Une réponse technique de réception ne prouve pas l’achèvement de la tâche chez le destinataire : demandez la preuve adaptée au fonctionnement convenu.

Corriger, fermer et traiter les copies

Une adresse corrigée peut rester dans un ancien événement, une file d’échec ou un outil de diagnostic. La propagation des rectifications doit couvrir ces copies selon leur rôle. Un historique exact peut nécessiter un contexte différent d’une consigne actuelle ; ne réutilisez pas une valeur devenue inexacte pour une nouvelle intervention. L’Art. 19 encadre également la notification des rectifications aux destinataires. RGPD, Art. 16 et 19.

À la fin de l’intégration, arrêtez les nouveaux événements, examinez ceux en attente, désactivez les accès et révoquez les secrets concernés. Traitez séparément les données déjà reçues et les traces conservées pour une finalité justifiée. Une désactivation de configuration n’efface pas automatiquement la file ni le système du partenaire.

Les journaux d’erreurs doivent permettre de diagnostiquer sans devenir une copie intégrale de chaque dossier. Définissez les références utiles, l’accès et la durée. Si des messages ont été envoyés à un destinataire non autorisé, analysez la violation éventuelle et ses obligations au titre des Art. 33 et 34 ; fermer le webhook ne clôt pas cette analyse.

Ce qu’il faut retenir

• Le contenu autorisé dépend de l’action et du destinataire, pas des champs disponibles.
• Réexaminez les droits et l’état avant les reprises d’envoi.
• Distinguez message reçu, action exécutée et événement déjà traité.
• La fermeture doit couvrir les files, les accès et les copies résiduelles.

FAQ

Un webhook sans nom contient-il des données personnelles ?

Oui, si une référence ou une combinaison d’informations reste rattachable à une personne. Un identifiant technique n’est pas automatiquement anonyme.

Peut-on conserver tous les échecs pour les rejouer plus tard ?

Pas sans besoin ni durée justifiés. Définissez les conditions de reprise et le traitement des événements périmés ; le destinataire et l’état du dossier peuvent avoir changé.

Une signature dispense-t-elle de contrôler les champs ?

Non. Elle contribue à vérifier l’origine ou l’intégrité selon le mécanisme employé, mais ne justifie pas un contenu excessif ni une communication devenue non autorisée.

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.