La sécurité des données sous-traitant ne se délègue jamais entièrement : l’entreprise qui confie des données personnelles reste tenue de choisir, encadrer et contrôler son prestataire. L’incident VACAF confirmé par la Cnaf le 10 octobre 2026 illustre un risque fréquent : une plateforme externe peut être compromise alors que le système d’information principal demeure isolé. Contrat, accès, journaux et procédure d’incident doivent être cadrés avant la mise en ligne.
Que révèle la fuite VACAF sur les risques liés aux prestataires ?
L’incident VACAF montre qu’un service hébergé chez un prestataire externe peut exposer des données sans compromettre le système d’information principal. Le 10 octobre 2026, la Cnaf a confirmé un incident de cybersécurité et suspendu vacaf.org, tandis que les systèmes servant à gérer et payer les prestations Caf restaient séparés et opérationnels.
VACAF est le service d’aide aux vacances du réseau des Caf. Selon la communication officielle de la Cnaf du 10 octobre 2026, la plateforme était opérée par la Caf de l’Hérault et hébergée auprès d’un prestataire externe. Les nouvelles réservations ont été suspendues, mais les réservations existantes et le versement des prestations sont restés valides.
Cette séparation technique a limité les conséquences opérationnelles. Les premières constatations excluaient aussi les coordonnées bancaires des bénéficiaires et les mots de passe des services en ligne des Caf. L’identité du prestataire, le vecteur d’attaque, la chronologie précise et la liste complète des champs exposés n’étaient toutefois pas rendus publics au 13 octobre 2026.
Le chiffre d’environ 1,2 million de dossiers, relayé le 13 octobre 2026 par Le Monde Informatique à partir d’une revendication attribuée à FrenchBreaches, n’avait pas été confirmé par la Cnaf. Il ne doit donc pas être présenté comme un bilan établi. En matière de crise cyber, distinguer un fait officiel d’une revendication évite d’aggraver la confusion.
Qui reste responsable de la sécurité des données sous-traitant ?
Le responsable de traitement reste comptable du choix et de l’encadrement de son sous-traitant, tandis que le prestataire doit appliquer les mesures de sécurité prévues. L’article 28 du RGPD, adopté en 2016, exige des garanties suffisantes, un contrat contraignant et la transmission d’obligations équivalentes aux éventuels sous-traitants ultérieurs.
Le responsable de traitement est l’organisation qui décide pourquoi et comment les données personnelles sont utilisées. Le sous-traitant traite ces données pour son compte : hébergeur, agence web, éditeur SaaS (logiciel accessible en ligne), prestataire d’emailing ou mainteneur d’une application.
Signer un accord de traitement des données ne suffit pas. L’article 32 du RGPD de 2016 impose au responsable et au sous-traitant des mesures adaptées au risque, qui peuvent inclure le chiffrement, la résilience des systèmes, la restauration des données et des tests réguliers. La sécurité des données sous-traitant relève donc d’une responsabilité répartie, mais pas diluée.
La même logique s’applique lorsqu’un prestataire délègue l’hébergement, la sauvegarde ou l’envoi d’emails à une autre société. La chaîne contractuelle doit rester visible. Ce mécanisme de dépendances rappelle aussi l’effet cascade de NIS2 sur les sous-traitants, même si les obligations exactes varient selon l’activité et le statut de l’organisation.
Que faut-il vérifier avant de confier des données à un prestataire ?
Avant de confier des données personnelles, l’entreprise doit cartographier les informations traitées, identifier les accès, vérifier les sous-traitants ultérieurs et obtenir des garanties contrôlables. La CNIL recommandait en 2024 d’encadrer l’authentification, les habilitations, le signalement des incidents, la restitution ou suppression des données et les revues de sécurité.
Une cartographie des données indique quelles informations entrent dans le service, où elles sont stockées, qui peut les consulter et quand elles sont supprimées. Sans cette vue, impossible d’évaluer correctement l’impact d’une fuite ou de savoir si une base de test contient encore de vraies données clients.
Les vérifications utiles suivent un ordre concret :
- décrire les catégories de données, leur finalité et leur durée de conservation ;
- recenser les administrateurs, comptes techniques et accès d’assistance ;
- identifier l’hébergeur et chaque sous-traitant ultérieur autorisé ;
- exiger une journalisation, c’est-à -dire un historique exploitable des connexions et actions sensibles ;
- prévoir le chiffrement, la sauvegarde, la restauration et des tests de sécurité réguliers ;
- fixer une procédure de restitution ou de suppression en fin de contrat ;
- définir le canal et le délai d’alerte en cas d’incident.
La CNIL indiquait en 2024 que les garanties peuvent être vérifiées par des audits ou des inspections sur site. Elle recommande notamment d’examiner le chiffrement, la traçabilité, la gestion des autorisations, la protection du réseau et les pratiques d’administration. Une attestation commerciale sans périmètre ni date apporte peu de garanties.
Sur les projets que nous menons, nous voyons souvent un risque négligé : le compte d’administration partagé entre plusieurs intervenants. Il réduit la traçabilité et complique la révocation d’un accès. Un compte nominatif, une authentification multifacteur et des droits limités à la mission sont généralement des choix plus solides.
Quelles clauses de sécurité faut-il inscrire dans le contrat ?
Un contrat de sous-traitance doit transformer les promesses de sécurité en obligations vérifiables : périmètre des données, mesures techniques, gestion des accès, sous-traitants ultérieurs, assistance, audit et notification d’incident. En 2024, la CNIL recommandait aussi d’encadrer la restitution ou l’effacement des données à la fin de la prestation.
Le tableau suivant relie les clauses aux conséquences concrètes pour un projet web ou mobile.
| Point contractuel | Exigence vérifiable | Risque réduit |
|---|---|---|
| Accès | Comptes nominatifs, habilitations limitées et révocation documentée | Accès persistant ou impossible à attribuer |
| Traçabilité | Journaux de connexion et d’administration conservés selon une durée définie | Incident impossible à reconstituer |
| Sous-traitance ultérieure | Liste des acteurs, localisation et procédure d’autorisation ou d’information | Chaîne technique inconnue |
| Incident | Alerte sans délai indu, canal d’urgence et informations minimales attendues | Notification réglementaire tardive |
| Fin de contrat | Restitution, format d’export, suppression et preuve d’effacement | Données oubliées chez l’ancien prestataire |
| Contrôle | Droit d’audit, justificatifs datés et plan de correction | Garanties impossibles à confirmer |
Le piège contractuel classique consiste à accepter une clause vague du type « mesures conformes aux bonnes pratiques ». Honnêtement, une formule aussi large protège mal le projet : elle ne précise ni les contrôles, ni les responsabilités, ni les preuves attendues. Un contrat utile décrit ce qui peut être vérifié sans imposer une architecture figée.
Le budget doit aussi prévoir la maintenance après livraison. Les correctifs de sécurité, la revue des comptes et le renouvellement des composants ne sont pas des options ponctuelles. Une démarche de gestion des mises à jour sans interruption de production aide à clarifier les responsabilités entre l’entreprise, l’agence et l’hébergeur.
Comment réagir lorsqu’un prestataire signale une fuite de données ?
Lorsqu’un prestataire détecte une violation de données personnelles, il doit prévenir le responsable de traitement sans délai indu. Selon la procédure publiée par la CNIL en 2018, le responsable documente chaque violation et, lorsqu’un risque existe, la notifie à la CNIL si possible dans les 72 heures après en avoir pris connaissance.
Une violation de données personnelles est une atteinte à la confidentialité, à l’intégrité ou à la disponibilité d’informations permettant d’identifier une personne. Il peut s’agir d’une consultation non autorisée, d’une modification, d’une perte ou d’une indisponibilité.
Le premier réflexe consiste à préserver les preuves tout en contenant l’incident : suspendre un accès compromis, isoler le service si nécessaire et conserver les journaux. La Cnaf a ainsi suspendu l’accès à vacaf.org le 10 octobre 2026, activé une cellule de crise, informé l’Agence nationale de la sécurité des systèmes d’information et la CNIL, puis annoncé une plainte pénale.
Si la violation présente un risque élevé pour les personnes, celles-ci doivent également être informées. Le message doit distinguer les données confirmées comme touchées de celles qui ne le sont pas. Pour VACAF, la Cnaf indiquait le 10 octobre 2026 que les données bancaires et les mots de passe Caf n’étaient pas concernés selon les premières constatations.
Côté agence, le réflexe est de préparer cette séquence avant l’incident : coordonnées d’urgence, responsables habilités à décider, modèle de registre et procédure de collecte des preuves. Les enseignements tirés des incidents de sécurité touchant un prestataire d’emailing montrent aussi qu’un service périphérique mérite la même discipline qu’une application centrale.
Comment limiter l’impact d’une compromission externe ?
La réduction d’impact repose sur le cloisonnement, la limitation des données et des accès, ainsi que sur une capacité de restauration testée. L’incident VACAF de 2026 illustre l’intérêt du cloisonnement : la plateforme affectée était techniquement séparée du système servant à gérer et payer les prestations Caf, qui a continué de fonctionner.
Le cloisonnement consiste à empêcher qu’un incident sur un service ouvre automatiquement l’accès aux autres. Une plateforme événementielle, un extranet ou un outil d’emailing ne devrait pas disposer d’un accès permanent à toute la base clients. À ce niveau de risque, mieux vaut échanger le strict nécessaire plutôt que répliquer une base complète par facilité.
La minimisation réduit également les conséquences : moins une plateforme stocke d’informations, moins une compromission peut en exposer. Pour une application mobile, cette logique commence dès la conception ; les principes de protection des données dès la conception évitent de corriger tardivement une architecture trop permissive.
Les sauvegardes ne suffisent pas si leur restauration n’est jamais testée. De même, les journaux sont inutiles s’ils peuvent être modifiés par le compte compromis ou si personne ne sait les exploiter. La sécurité des données sous-traitant doit être testée dans des scénarios concrets, y compris la perte d’un compte administrateur et l’indisponibilité du prestataire.
Cadrer la sous-traitance avant le développement évite une grande partie des mauvaises surprises contractuelles et techniques. Un regard extérieur peut notamment rapprocher le contrat, l’architecture et la procédure de crise, trois sujets encore trop souvent traités séparément.
FAQ sur la sécurité des données confiées à un prestataire
Un hébergeur est-il un sous-traitant au sens du RGPD ?
Un hébergeur est généralement un sous-traitant lorsqu’il stocke ou traite des données personnelles pour le compte de l’entreprise. Son rôle, ses mesures de sécurité et ses propres prestataires doivent alors être encadrés conformément à l’article 28 du RGPD de 2016.
Peut-on interdire à un prestataire de recourir à d’autres sociétés ?
Le contrat peut encadrer le recours à des sous-traitants ultérieurs par une autorisation préalable spécifique ou générale, conformément à l’article 28 du RGPD de 2016. Des obligations équivalentes de protection des données doivent leur être imposées.
Le délai de 72 heures commence-t-il lors de l’attaque ?
Le délai de 72 heures concerne, lorsque la notification est requise, le moment où le responsable de traitement a connaissance de la violation, et non nécessairement la date technique de l’attaque. La CNIL précise depuis 2018 qu’une notification initiale peut être complétée si toutes les informations ne sont pas encore disponibles.
Une certification dispense-t-elle d’auditer un prestataire ?
Une certification peut contribuer à démontrer des garanties, mais elle ne remplace pas l’évaluation du service réellement utilisé. La CNIL recommandait en 2024 de vérifier les mesures par des audits ou des inspections et d’examiner notamment les accès, le chiffrement, les journaux et l’administration.