News
FNAC app: €7 million in fines for tracking after users declined
The CNIL has fined two FNAC companies. After users declined tracking, a multi-purpose API still processed data for product recommendations and training their recommendation algorithm.
A user declines tracking, opens a product page—and their interaction is still processed for recommendations. France’s data protection authority, the CNIL, found this behaviour when it inspected the FNAC app in March 2024. On 29 October 2026, it announced penalties totalling €7 million: €6 million against FNAC DARTY PARTICIPATIONS ET SERVICES and €1 million against FNAC DIRECT. The decision was adopted on 22 October. Its legal basis is Article 82 of France’s Data Protection Act, which governs access to users’ devices. (CNIL announcement)
The case is particularly relevant to product, engineering and privacy teams because the decision examines a specific technical link: A single read/write operation through an API served multiple purposes. A potentially necessary function could therefore not be assessed separately from purposes requiring consent.
One API data flow, several uses
After users selected “Continuer sans accepter”—“Continue without accepting”—requests still went to a third-party domain. They contained an identifier assigned by FNAC and activity data, such as the products viewed.
The linked uses included personalised and complementary product recommendations, similar products, and training the recommendation algorithm. This was a product recommendation algorithm, not a finding about training generative AI. The CNIL describes the purposes and their shared technical mechanism in paragraphs 26 and 33–39 of its decision.
This distinction matters when mapping an application’s behaviour. A service’s name does not fully describe what happens to the interactions it receives. A service can return an immediately visible result while also using the same data to improve future recommendations. Both uses need to be visible to the team assessing the implementation.
An important distinction for similar products
In paragraph 37, the CNIL does not rule out displaying similar products being theoretically necessary, depending on the implementation, to deliver the service requested by the user. In this case, however, that function could not be isolated: the same operation also supported other purposes that did not qualify for an exemption from consent.
Under the decision’s reasoning, one potentially exempt purpose does not allow the entire multi-purpose operation to run without consent. Every purpose of that operation would have to meet the conditions for an exemption. (Decision, paragraphs 37–39)
This is not a blanket finding that every product recommendation or every API requires consent. What matters is the specific operation on the device, its purposes and the conditions for the relevant exemption. The violation decided here concerns French law; assessing another service requires its own legal context.
What app teams can check in the actual user journey
Our technical interpretation: Acceptance testing should start with the user’s choice and follow it through to how the data is used. That helps identify which function genuinely operates independently and which purposes remain technically coupled.
A reproducible test might work as follows: Launch a defined app version with a known consent state. Decline the optional purposes, then open a product page and inspect the associated device access and network activity. Suitable test data is sufficient; real customer data should not casually end up in captures or issue trackers.
| Test step | What to record for acceptance testing |
|---|---|
| Establish the starting state | App and operating system versions, existing consent state and, where relevant, sign-in state |
| Decline consent | Which purposes were declined and when the choice took effect |
| Use a specific function | For example, a product search followed by a product page, in a reproducible sequence |
| Map the data flow | Destination, transmitted fields, associated device operation and actual purposes of use |
| Assess the result | Expected behaviour, observed deviation and the person responsible for the fix |
A network log alone does not reveal every subsequent use. To establish whether data also improves a recommendation algorithm, a team may need to examine service configuration and technical documentation and work with the provider. Conversely, a declined option in the interface does not by itself establish that the corresponding technical operation has stopped.
Sign-in deserves a separate test case, too. An anonymous session and a signed-in request can produce different identifiers and flows. Which variants need testing depends on the actual application, rather than a universal checklist designed to maximise the number of tests.
Fixing the problem may require an architectural change
If necessary and optional purposes are technically coupled, the team needs to make a deliberate decision about the data flow. One option may be to prevent the operation until the required consent has been obtained. Another may be to genuinely separate the functions and data uses, then reassess the remaining operations.
Adding a field marked “declined” does not automatically resolve that coupling. What matters is which accesses and uses downstream components still carry out. Renaming an endpoint does not turn several purposes into one, either.
Product owners, engineering and privacy specialists should work through the change together. The product team defines which service should remain available without optional processing. Engineering makes the required data path explicit. Privacy specialists assess the implementation actually proposed. The same test case can then be run again against the corrected version.
For a release, a small, specific acceptance record is more useful than a blanket statement about the entire service: the affected function, version, assessed purposes, implemented change and test result. If an update later changes how the data is used, that record helps identify exactly what needs reassessment.
What is known about the app’s current state
The announcement describes findings from 2024, not our own test of the current app. According to the decision, the companies stated that they retired the earlier tool at the end of 2024 and replaced it in early 2025. (Decision, paragraph 29) The CNIL requires evidence that the new tool obtains consent where needed. (CNIL announcement)
It allows one month from notification of the decision, with a potential penalty of €10,000 per day for late compliance. The publication date does not establish when that period began. The sources reviewed do not establish whether an appeal has been lodged or the decision is final. (CNIL announcement)
Turning a technical finding into work with clear ownership
The necessary changes need to remain actionable across teams: Who establishes the purposes, who changes the data flow, and who accepts the result? Kopexa can connect assessed requirements with owners, measures and evidence, and make outstanding work traceable. Application analysis and legal assessment remain the responsibility of the relevant specialists.
Our article on ISO 27001 and data protection explains how privacy work can connect with information security management. In the FNAC case, the specific task is narrower: carrying a user’s decision through to the data processing that actually takes place.