CNIL 2026 : les nouvelles recommandations sur la sécurité des API
Pourquoi la CNIL s'intéresse aux API
Les API sont devenues le principal vecteur d'échange de données dans les SaaS RH. Chaque fois qu'un logiciel de paie transmet un bulletin à un coffre-fort numérique, qu'un ATS envoie un profil candidat à un outil d'évaluation, ou qu'un SIRH synchronise les absences avec la DSN, une API est sollicitée.
Le problème : beaucoup de ces API exposent plus de données que nécessaire, ne vérifient pas correctement les droits d'accès, ou journalisent insuffisamment les appels. La CNIL l'a constaté lors de ses contrôles 2025 et a décidé de mettre à jour ses recommandations.
Ce qui change concrètement
Authentification et autorisation
La CNIL insiste désormais sur la séparation stricte entre authentification (qui appelle ?) et autorisation (a-t-il le droit ?). Les tokens d'API doivent avoir une durée de vie limitée — la recommandation est de 15 minutes maximum pour les access tokens — et les refresh tokens doivent être révocables individuellement.
Pour un éditeur de paie, ça signifie qu'un token généré pour synchroniser les salaires ne doit pas pouvoir accéder aux dossiers disciplinaires. Le principe du moindre privilège, appliqué endpoint par endpoint.
Minimisation des données
Nouveau point fort : chaque endpoint doit retourner uniquement les champs nécessaires à l'usage déclaré. Un partenaire qui a besoin du nom et de l'email d'un collaborateur ne doit pas recevoir son numéro de sécurité sociale dans la même réponse, même si le champ existe dans la base.
La CNIL recommande désormais des mécanismes de projection côté serveur (fields filtering) plutôt que de compter sur le client pour ignorer les champs inutiles.
Journalisation
Toute API traitant des données sensibles doit journaliser :
Ces logs doivent être conservés 6 mois minimum et être exploitables en cas de contrôle.
Impact pour les éditeurs SaaS RH
Si vous développez un logiciel RH, de paie ou de recrutement, ces recommandations ne sont pas optionnelles. La CNIL les utilise comme référentiel lors de ses contrôles. Ne pas les suivre, c'est s'exposer à une mise en demeure.
Concrètement, voici les actions à mener :
read:employees est trop large — préférez read:employees:identity et read:employees:payroll.Comment CleanIssue peut aider
Notre audit API et webhooks vérifie exactement ces points. On teste vos endpoints comme le ferait un attaquant : en manipulant les paramètres, en testant les contrôles d'accès, en cherchant les fuites de données dans les réponses. Le rapport inclut les recommandations de la CNIL en regard de chaque constat.
Si vous êtes éditeur SaaS RH et que vous n'avez jamais fait auditer vos API, c'est le moment.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
CNIL 2025 : 487M€ d'amendes. Ce que les petites équipes SaaS doivent retenir
Record d'amendes CNIL en 2025. Analyse des sanctions et des leçons concrètes pour les équipes produit qui gèrent des données sensibles.
RGPD Article 32 : obligations de sécurité technique pour les applications web
Ce que "mesures techniques appropriées" signifie concrètement : chiffrement, contrôle d'accès, tests, pseudonymisation. Avec exemples de code.
RGPD et logiciel de recrutement : ce que la CNIL regarde vraiment en 2026
Les points de vigilance les plus concrets pour un ATS ou logiciel de recrutement : données candidats, accès recruteurs, conservation et sécurité visible.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.