Comment journaliser les appels d'une API sans stocker de données personnelles ?

Journaliser les appels reçus par une interface de programmation est indispensable : sans trace, aucun incident ne se diagnostique, aucun abus ne se détecte, aucune facturation à l'usage ne se justifie. Le problème est que le réflexe consistant à tout enregistrer produit des journaux contenant des adresses électroniques, des identifiants clients, des contenus de messages et parfois des jetons d'authentification, conservés indéfiniment et accessibles à toute l'équipe technique. La journalisation d'une API demande donc de décider explicitement ce que l'on garde, pour combien de temps et pour quoi faire. Ce qui suit décrit des pratiques techniques et ne constitue pas un avis juridique.

Pourquoi journaliser les appels

Trois usages distincts justifient l'enregistrement, et ils n'exigent pas les mêmes données. Le diagnostic technique demande de savoir quel point d'entrée a été appelé, avec quel résultat, en combien de temps et depuis quelle version de client. Il ne demande presque jamais le contenu de la requête. La sécurité demande de repérer des comportements anormaux, ce qui suppose une identification du client et un horodatage précis, sans nécessiter davantage. La facturation demande un comptage par client et par opération, encore moins. Poser ces trois usages côte à côte, sur une feuille, est la première chose à faire avant d'écrire la moindre ligne de journalisation.

Cette distinction est décisive parce qu'elle montre que la quasi totalité des besoins réels se satisfait de métadonnées, sans conserver le contenu des échanges. Or c'est précisément le contenu qui pose problème, puisqu'il transporte les données que les clients manipulent. Séparer ces trois usages, et ne collecter pour chacun que ce dont il a besoin, réduit le volume conservé dans des proportions considérables sans rien enlever à l'utilité. Cette logique rejoint celle décrite dans notre article sur la manière de centraliser et exploiter les journaux de sécurité. Elle a aussi un effet secondaire appréciable : des journaux plus légers se cherchent plus vite et coûtent moins cher à stocker.

Un quatrième usage, plus rare, justifie parfois de conserver davantage : la reconstitution d'un incident où l'on doit savoir exactement ce qui a été envoyé. Ce besoin est réel sur les traitements financiers et sur les intégrations complexes, et il doit être traité comme une exception encadrée plutôt que comme le mode par défaut. Un mode de journalisation détaillée, activable temporairement sur un client précis, répond à ce besoin sans imposer une collecte permanente à tout le monde. Ce mode doit s'éteindre automatiquement au bout d'une durée courte, faute de quoi il devient le mode par défaut sans que personne ne l'ait décidé.

Ce qui se retrouve dans un journal sans qu'on l'ait voulu

Le premier réflexe consiste à enregistrer la ligne complète de la requête, ce qui inclut les paramètres d'adresse. Une adresse contenant une adresse électronique, un numéro de téléphone ou un identifiant de personne se retrouve donc en clair dans les journaux, souvent dupliquée dans ceux du serveur web, du service en périphérie et de l'application. Cette multiplication est le premier point à traiter, car elle rend toute mesure de protection inefficace si elle n'est appliquée qu'à un seul niveau. Le recensement des endroits où une requête laisse une trace est donc le préalable à toute intervention.

Le deuxième cas est celui des en-têtes. Le jeton d'authentification, la clé d'interface, le témoin de session et parfois des informations sur l'utilisateur y figurent. Un journal enregistrant les en-têtes complets contient donc des identifiants directement réutilisables, ce qui transforme un accès en lecture aux journaux en accès aux comptes des clients. C'est le défaut le plus grave et le plus fréquent, et il se corrige par une liste des en-têtes à masquer, écrite une fois pour toutes. Cette liste doit inclure les en-têtes personnalisés que votre propre interface définit, souvent oubliés parce qu'ils ne portent pas de nom standard.

Le troisième cas est celui des corps de requête, enregistrés lors des phases de mise au point puis laissés en place. Un point d'entrée recevant un formulaire de contact enregistre alors le message complet, avec le nom et l'adresse de l'expéditeur. Ces enregistrements relèvent d'un traitement de données personnelles au sens des textes, ce qui suppose une base légale, une durée de conservation et une information des personnes, comme le rappelle notre article sur le RGPD et la conformité d'un site. La désactivation de cette journalisation détaillée doit figurer explicitement dans la liste de contrôle de mise en production.

Le principe de minimisation appliqué aux journaux

La démarche consiste à partir de zéro et à ajouter ce qui est nécessaire, plutôt qu'à partir de tout et à retirer ce qui gêne. Cette inversion change complètement le résultat obtenu, pour un effort de conception identique. Un journal utile contient un horodatage, un identifiant de requête, le point d'entrée appelé, la méthode, le code de réponse, la durée de traitement, la taille de la réponse et un identifiant de client. Ces huit champs couvrent le diagnostic technique, la sécurité et la facturation. Aucun ne constitue une donnée personnelle en dehors de l'identifiant de client, qui n'est qu'une référence interne. Cette liste tient sur une ligne et devrait constituer le point de départ de toute nouvelle interface.

L'identifiant de requête mérite une mention particulière : généré à l'entrée et propagé dans toute la chaîne, il permet de relier les traces produites par plusieurs composants pour un même appel. Il est renvoyé au client dans un en-tête, ce qui permet à celui ci de le citer lors d'un signalement. Cette pratique simple transforme le traitement des incidents : au lieu de chercher dans des millions de lignes, on retrouve la trace exacte en une requête. Ce même identifiant permet également de relier une trace applicative à une trace de serveur web, ce qui simplifie considérablement les diagnostics répartis.

Ce qui ne figure pas dans cette liste ne doit pas être enregistré par défaut. Les paramètres d'adresse doivent être filtrés pour ne conserver que ceux qui sont utiles au diagnostic et ne portent aucune information personnelle. Les en-têtes doivent être réduits à ceux qui servent réellement, jeton exclu. Le corps de la requête ne doit pas être conservé, sauf activation explicite et temporaire. Ces trois règles suffisent à obtenir un dispositif propre. Elles doivent être écrites dans la configuration de la bibliothèque de journalisation plutôt que confiées à la discipline de chacun, seule façon de garantir leur application uniforme.

Les techniques pour journaliser sans conserver

Le masquage consiste à remplacer une valeur sensible par une mention neutre avant écriture. La mention doit rester lisible, du type valeur masquée, afin que la présence du champ reste visible sans que sa valeur ne le soit. Il doit être appliqué au niveau de la bibliothèque de journalisation, dans un filtre commun, et non à chaque appel, sous peine d'être oublié quelque part. La liste des clés à masquer doit inclure les variantes de casse et les noms approchants, un en-tête d'autorisation pouvant s'écrire de plusieurs façons selon les clients. Ce filtre se teste, comme n'importe quel code, avec un jeu de cas incluant des valeurs sensibles. Un test vérifiant qu'aucun jeton connu ne se retrouve dans la sortie du journal se rejoue à chaque modification et coûte quelques lignes.

Le hachage permet de conserver la capacité de comparer sans conserver la valeur. C'est la technique appropriée lorsqu'on a besoin de savoir que deux appels concernent la même personne sans avoir besoin de savoir laquelle. Une adresse électronique remplacée par son empreinte permet toujours de compter les appels d'un même utilisateur ou de repérer un comportement anormal, sans que l'adresse figure dans le journal. Il faut savoir qu'une empreinte reste une donnée personnelle au sens des textes lorsqu'elle permet d'individualiser, et qu'un sel propre au traitement, non conservé avec les journaux, renforce sensiblement la protection. Le hachage sans sel d'une adresse électronique reste réversible par simple comparaison avec une liste d'adresses connues, ce qui lui retire l'essentiel de son intérêt.

La troncature s'applique bien aux adresses réseau : conserver les trois premiers groupes d'une adresse suffit à identifier une origine géographique et un fournisseur d'accès, tout en réduisant fortement la capacité d'individualisation. Cette pratique est recommandée par les autorités pour la mesure d'audience et se transpose bien aux journaux techniques, à condition d'accepter qu'elle réduise aussi l'utilité pour le blocage précis d'une source abusive, sujet traité dans notre article sur la manière de limiter le débit d'une API. Un compromis courant consiste à conserver l'adresse complète pendant quelques jours pour les besoins de sécurité, puis à la tronquer automatiquement.

Durées de conservation et purge

Chaque catégorie de trace mérite sa propre durée, fixée à partir de son usage. Les traces de diagnostic servent quelques jours à quelques semaines : passé ce délai, personne ne revient sur un incident technique ancien. Sept à trente jours couvrent la quasi totalité des besoins réels de cette catégorie. Les traces de sécurité justifient une conservation plus longue, six mois à un an étant une pratique courante, afin de pouvoir reconstituer une intrusion découverte tardivement. Les compteurs de facturation doivent suivre les obligations comptables et peuvent être agrégés plutôt que conservés ligne à ligne. Cette distinction par usage est ce qui permet d'être à la fois utile et sobre, là où une durée unique oblige à trancher au détriment de l'un ou de l'autre.

Cette dernière remarque est importante : une agrégation quotidienne par client et par point d'entrée conserve toute l'information nécessaire à la facturation et au suivi d'usage, tout en supprimant les lignes individuelles. Elle réduit le volume dans des proportions considérables et supprime au passage la question des données personnelles, puisqu'un compteur n'individualise rien. Sur une interface recevant plusieurs millions d'appels par mois, le gain de stockage se compte en ordres de grandeur. Cette bascule vers l'agrégé après quelques semaines est probablement la mesure la plus efficace de tout le dispositif. Elle se met en place par une tâche planifiée qui calcule les agrégats puis supprime les lignes détaillées correspondantes.

La purge doit être automatique et vérifiée. Une purge manuelle est une purge qui finira par ne plus être faite, généralement au moment où elle importerait le plus. Un mécanisme de rotation supprimant les fichiers au delà de la durée retenue, complété par un contrôle périodique de ce qui reste réellement présent, évite la situation classique où l'on découvre trois ans de journaux sur un serveur oublié. La purge doit également couvrir les sauvegardes, point systématiquement négligé et qui rend la conservation effective bien plus longue que la durée annoncée. Une sauvegarde conservée trois ans contient trois ans de journaux, quelle que soit la politique de purge appliquée en production.

Accès, sécurité et traçabilité

Les journaux constituent une source d'information sensible et doivent être protégés comme telle. Sur beaucoup d'organisations, ils sont paradoxalement moins protégés que la base de données dont ils reflètent pourtant une partie du contenu. L'accès doit être restreint aux personnes qui en ont besoin, ce qui exclut l'accès par défaut de toute l'équipe. Sur un système de centralisation, cette restriction se configure par rôle. Sur des fichiers déposés sur un serveur, elle repose sur les droits du système et sur la restriction de l'accès à la machine, ce qui est plus grossier et souvent suffisant. Il faut en revanche penser aux copies : un extrait de journal envoyé par messagerie pour analyser un incident échappe entièrement à ces contrôles.

Les journaux ne doivent jamais être accessibles par une adresse web. Un répertoire de journaux placé dans l'arborescence servie publiquement est une fuite complète, et ce cas se rencontre régulièrement sur les développements où le fichier de trace a été créé à côté du code pour aller plus vite. Le contrôle prend dix secondes : essayer d'accéder au fichier depuis un navigateur et vérifier qu'il n'est pas servi. Ce contrôle doit être refait après chaque changement de configuration du serveur, une modification de règle pouvant rouvrir l'accès sans que rien ne le signale.

L'accès aux journaux mérite lui même d'être tracé lorsque leur contenu est sensible. Cette traçabilité de second niveau paraît excessive et devient nécessaire dès que les journaux contiennent des informations que l'on aurait à justifier. Elle se met en place simplement sur les systèmes de centralisation et elle constitue une bonne pratique sur toute organisation ayant à démontrer la maîtrise de ses accès. Elle rassure également les clients de l'interface, qui savent que leurs données ne sont pas consultables sans trace.

Ce qu'il faut écrire dans la documentation

Un registre décrivant ce qui est enregistré, pourquoi, pour combien de temps et qui y accède constitue à la fois une obligation dans certains cas et un outil de travail utile en toutes circonstances. Il doit couvrir chaque système produisant des traces, y compris ceux que l'on n'a pas écrits soi même. Il tient en une page par système et se relit en cinq minutes lors d'un contrôle. Sa rédaction oblige surtout à répondre aux questions posées plus haut, exercice qui révèle presque toujours des collectes dont personne n'avait décidé. La rédaction se fait bien plus vite au moment de la conception qu'après coup, où elle suppose de reconstituer des choix oubliés.

La documentation destinée aux clients de l'interface doit indiquer ce qui est enregistré et pendant combien de temps. Cette transparence est attendue par les intégrateurs, qui doivent eux mêmes documenter leurs traitements auprès de leurs propres clients. Une section de quelques lignes dans la documentation technique suffit , placée à côté des informations d'authentification où les intégrateurs la trouveront,, et son absence provoque régulièrement des questions au moment de la contractualisation, moment où l'improvisation coûte cher. Les clients professionnels posent aujourd'hui systématiquement ces questions, et une réponse préparée fait gagner plusieurs semaines.

Enfin, la revue périodique de ce dispositif mérite d'être programmée. Elle peut se greffer sur une échéance existante, comme la revue annuelle de sécurité, plutôt que constituer un rendez vous supplémentaire. Les points d'entrée évoluent, les traces ajoutées pour un débogage restent, les durées dérivent. Une relecture annuelle du registre confrontée à ce qui est réellement enregistré remet le dispositif en cohérence, et elle prend une demi journée. C'est le seul moyen d'éviter que l'écart entre ce que l'on croit collecter et ce que l'on collecte réellement ne se creuse indéfiniment. Cet écart est mécanique et ne résulte d'aucune négligence particulière : il suffit de quelques ajouts faits dans l'urgence pour qu'il apparaisse. Une relecture du contenu réellement écrit dans les journaux, faite une fois par trimestre sur un échantillon de quelques lignes, suffit à ramener cet écart à zéro avant qu'il ne devienne un sujet.