API partenaires : limiter les données de chaque appel

Une API partenaire peut être correctement authentifiée tout en donnant accès à trop de données. Pour maîtriser le partage, il faut définir les dossiers autorisés, les opérations permises et les champs réellement nécessaires, puis vérifier la réponse produite. Masquer une information dans l’interface ne protège pas un champ déjà transmis au logiciel du partenaire.

La bonne unité de décision est l’usage : consulter un statut, préparer une intervention ou modifier un rendez-vous ne justifient pas le même contenu. Une spécification courte et renseignée permet au métier, au juriste et aux développeurs de travailler sur un périmètre commun.

Qualifier le partage avant de créer un accès

Décrivez d’abord l’organisme qui reçoit les données, sa finalité et sa relation avec les personnes. Le contrat commercial entre deux entreprises ne constitue pas automatiquement la base légale du traitement des clients ou salariés concernés. Chaque opération doit satisfaire les conditions de l’Art. 6(1), ainsi que les exigences supplémentaires applicables à certaines catégories de données. RGPD, Art. 6(1) et Art. 9.

Déterminez ensuite les rôles juridiques. Une API peut servir une prestation exécutée pour le compte d’un responsable, un partage entre responsables distincts ou une organisation conjointe selon les faits. Le terme « partenaire » et le propriétaire du serveur ne suffisent pas à décider.

La CNIL distingue trois rôles fonctionnels — détenteur, gestionnaire d’API et réutilisateur — qui ne préjugent pas des responsabilités juridiques. Elle précise également que ses recommandations API portent sur les mesures techniques, sans fixer le cadre juridique général du partage. CNIL, portée et responsabilités des API.

L’information des personnes doit correspondre au traitement réel : finalités, destinataires ou catégories, conservation et droits selon les Art. 13 ou 14. Un accès invisible pour le client n’est pas dispensé de transparence. Si un usage nouveau est ajouté, réexaminez la base, la compatibilité et l’information avant de l’activer ; le maintien de la même adresse technique ne maintient pas nécessairement le même traitement.

Contrat de données A-26 : deux opérations séparées

Prenons un exemple entièrement fictif. Une entreprise de réparation confie à un prestataire la planification des interventions demandées par ses clients. L’entreprise reste responsable du traitement ; le prestataire agit sur ses instructions pour cette mission. L’Art. 6(1)(b) est retenu pour les données nécessaires à l’exécution du service demandé par le client, sans l’étendre à une prospection ou à des analyses propres du prestataire.

Les équipes séparent deux opérations. Le tableau de planning montre les interventions affectées à ce prestataire. L’ouverture d’une intervention donne ensuite les informations nécessaires pour la préparer. Le prestataire n’a pas besoin de recevoir les coordonnées de tous les clients dès l’affichage du planning.

Ce « contrat de données » est une spécification pratique, pas le contrat complet de sous-traitance. Les obligations de l’Art. 28(3), notamment sur les instructions, la confidentialité, l’assistance et la fin de prestation, doivent être encadrées séparément. RGPD, Art. 28(3).

Décider champ par champ, y compris les données dérivées

L’Art. 5(1)(c) impose de limiter les données à ce qui est nécessaire. L’Art. 25(2) demande des mesures appropriées pour que, par défaut, le traitement reste limité dans sa quantité, son étendue, sa durée et son accessibilité. Ces principes concernent aussi un résultat calculé, un score ou une catégorie, pas seulement les noms et adresses.

Dans A-26, la zone du planning doit avoir la précision utile à l’organisation. Si un secteur suffit, l’adresse complète n’a pas à apparaître dans la liste. Lorsqu’un agent prépare l’intervention affectée, l’adresse détaillée peut devenir nécessaire. Il ne s’agit donc pas de déclarer un champ toujours interdit ou toujours accessible : on le rattache à une action autorisée.

Les champs libres posent une difficulté particulière. Une consigne opérationnelle peut contenir une information de santé, un code d’accès ou une appréciation personnelle sans utilité pour le prestataire. La spécification exclut le commentaire général et organise une consigne distincte limitée au besoin réel. Si une donnée sensible est effectivement nécessaire, sa licéité et sa protection doivent être examinées ; on ne la rend pas ordinaire en changeant son nom de champ.

Vérifiez enfin les données cachées dans la structure de la réponse : objets imbriqués, adresses secondaires, anciens statuts et pièces jointes. Une réponse contenant un objet « client » complet peut annuler la réduction des champs visibles de premier niveau. La règle porte sur ce qui est transmis, même si le partenaire affirme ne pas tout afficher.

Autoriser un dossier, une fonction et un champ

L’authentification répond à la question de l’identité technique de l’appelant. L’autorisation doit ensuite vérifier ce qu’il peut faire sur le dossier demandé. Une référence difficile à deviner ne remplace pas cette vérification. L’OWASP décrit ce risque dans sa fiche sur les autorisations au niveau de chaque objet.

Pour A-26, chaque consultation contrôle l’affectation actuelle au prestataire. Le contrôle ne doit pas reposer sur un identifiant de partenaire fourni librement dans la requête : le système doit le rapprocher du compte effectivement authentifié. Changer une référence de dossier ne doit pas ouvrir celui d’un autre prestataire.

La même logique s’applique aux modifications. Autoriser la proposition d’un créneau ne donne pas le droit de modifier toutes les propriétés envoyées dans la requête. Le serveur ne doit accepter que les opérations et champs permis ; l’absence de bouton dans l’interface du partenaire ne suffit pas à les interdire. La fiche OWASP sur les autorisations des propriétés distingue les données lisibles des valeurs modifiables.

La CNIL recommande notamment de séparer les fonctions ordinaires de l’administration, de protéger les clés et de maintenir la documentation à jour. Elle préconise aussi un environnement d’expérimentation utilisant des données fictives. CNIL, sécurité des interfaces API. Ces repères complètent l’obligation de sécurité adaptée au risque prévue par l’Art. 32(1) et (2).

Une recette qui démontre le périmètre

Voici une proposition de recette pour la spécification A-26. Les identifiants P-1, P-2 et I-101 sont inventés ; aucun résultat d’essai réel n’est présenté.

Conservez un contrôle positif : un dossier autorisé doit rester accessible comme prévu. Un système qui refuse tout ne démontre pas que la séparation des droits fonctionne correctement. Inversement, un refus visible n’est pas suffisant si le message d’erreur contient le nom du client ou des détails du dossier interdit.

Les exports, recherches et appels en série doivent être inclus. Une consultation unitaire restreinte ne protège pas une fonction d’export général restée accessible. Examinez également les caches et copies chez les intermédiaires : retirer un droit dans la base principale ne prouve pas que toutes les voies de lecture appliquent déjà ce changement.

Si une réponse dépasse le périmètre, suspendez le flux concerné ou réduisez-le effectivement pendant la correction. Reprenez ensuite les parcours touchés et vérifiez les données qui ont pu être communiquées en production. Une anomalie observée avec des données fictives ne prouve pas une fuite réelle ; une exposition réelle appelle sa propre analyse au titre des Art. 33 et 34.

Suivre les corrections et les copies reçues

Une API n’est pas seulement une fenêtre ouverte sur votre base : le destinataire peut conserver ce qu’il a reçu. Définissez donc les finalités, les durées et le traitement des corrections, effacements ou restrictions dans les systèmes aval. Dans A-26, l’assistance du sous-traitant et ses instructions doivent couvrir ces opérations.

L’Art. 19 impose, sous ses conditions, de notifier aux destinataires les rectifications, effacements relevant de l’Art. 17(1) et limitations, sauf impossibilité ou efforts disproportionnés. Une fermeture d’accès ne vaut pas notification ni suppression des copies existantes. RGPD, Art. 16 à 19.

Si les changements sont poussés automatiquement, les webhooks et leurs reprises doivent appliquer le même périmètre. Un événement en attente peut contenir une valeur ancienne ou viser un prestataire qui n’est plus affecté. Prévoyez le sort de cette file avant de considérer la correction comme propagée.

Les journaux d’erreurs doivent rester utiles sans recopier systématiquement les réponses complètes. Une trace peut associer un compte, une opération, une référence et un résultat ; son contenu et sa durée doivent être justifiés. Ne transformez pas un outil de diagnostic en base parallèle accessible à une équipe plus large.

Revoir chaque extension et organiser la sortie

Un ajout de champ à une réponse existante constitue potentiellement une extension du partage, même si le partenaire ne modifie pas son code. Faites valider sa nécessité avant l’activation. Une liste explicite des champs autorisés rend ce changement plus visible qu’une réponse reproduisant automatiquement toute la fiche interne.

Documentez les versions, leurs destinataires et leur date de retrait. Une nouvelle version correctement limitée n’efface pas l’exposition de l’ancienne. La migration doit préserver la continuité utile tout en fermant les accès qui ne répondent plus aux exigences retenues.

À la fin du partenariat, désactivez les comptes et secrets concernés, vérifiez les flux programmés, puis traitez les copies selon les obligations et instructions applicables. Demandez une confirmation qui distingue les données supprimées, restituées et éventuellement conservées pour un motif identifié. Le simple arrêt des appels ne permet pas d’affirmer que le partenaire ne détient plus de données.

Ce qu’il faut retenir

• Une identité technique valide ne justifie pas l’accès à tous les dossiers ou champs.
• Définissez la population, l’opération et le contenu nécessaire avant d’ouvrir l’API.
• Vérifiez les réponses complètes, les erreurs, les exports et les anciennes versions.
• La correction et la sortie doivent atteindre les données déjà transmises.

FAQ

Une API privée peut-elle transmettre toute la fiche client ?

Seulement si toutes les données sont nécessaires à l’usage autorisé et que le partage respecte les conditions applicables. Le caractère privé ne dispense ni de minimisation ni d’une base légale.

Faut-il créer un profil différent pour chaque partenaire ?

Des profils communs peuvent convenir à des usages identiques. L’autorisation doit néanmoins contrôler les dossiers accessibles à chaque organisme et les circonstances particulières de son intervention.

Une réponse sans nom est-elle anonyme ?

Pas nécessairement. Une référence, un lieu ou une combinaison de valeurs peut permettre le rattachement à une personne. Traitez les identifiants selon leur contexte réel, sans assimiler suppression du nom et anonymisation.

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.