Tête de réseau : caisse connectée imposée + CRM de réseau dual (franchisés + succursales) : ce que le Data Act change (vraiment) pour une tête de réseau ?
Le Data Act vise l’accès aux données générées par la caisse (et, parfois, par le service connexe)
Quand la caisse est qualifiée de produit connecté et que le back-office est un service connexe , le Data Act organise, au profit de l’ utilisateur (souvent le franchisé qui exploite la caisse), un droit d’accès aux données « facilement disponibles générées par l’usage (données brutes / prétraitées), et la faculté de demander au détenteur de données de les mettre à disposition d’un tiers (BI, expert-comptable, prestataire analytics, etc.).
Deux vigilances pratiques :
· tout ce qui relève de l’ enrichissement (scoring, segmentation, modèles prédictifs CRM) n’est pas nécessairement dans le même périmètre que les données « facilement disponibles » au sens de l’art. 2 §13 du Data Act (données que le détenteur peut mettre à disposition sans effort de collecte ou de traitement supplémentaire) ;
· dès qu’il y a données personnelles (fidélité, tickets nominatifs), l’articulation RGPD redevient centrale : le Data Act ne « court-circuite » pas le RGPD.
Qui « porte » l’obligation : le verrou peut venir de la tête de réseau… mais l’obligation d’accès pèse souvent sur l’éditeur POS
Dans beaucoup d’architectures contractuelles, le détenteur de données (data holder) au sens du Data Act est l’éditeur / intégrateur POS ou l’opérateur du back-office cloud (celui qui détient techniquement les données « facilement disponibles » et peut les extraire). La tête de réseau n’est pas toujours le débiteur direct. Mais attention : lorsqu’elle accède aux données et exerce un contrôle effectif sur leur traitement, elle peut elle-même être qualifiée de data holder au sens du Data Act (point souvent sous-estimé dans les montages en réseau, qui engage sa responsabilité propre).
En pratique, la tête de réseau pilote le risque : c’est elle qui impose/référence l’outil, qui impose les clauses réseau, et qui organise (ou verrouille) les sorties. C’est donc elle qui doit sécuriser le « pack contractuel » (franchise + IT/CGU + process de sortie) pour éviter un contentieux « accès à la donnée ».
Les clauses « no export / no copy / no exit » deviennent juridiquement fragiles
Le Data Act ne consacre pas une « propriété » de la donnée. En revanche, il met en place une police contractuelle B2B : certaines clauses relatives à l’accès/usage des données, imposées et déloyales , peuvent devenir « non contraignantes » (art. 13 : elles « ne lient pas » la partie sur laquelle elles sont imposées).
Dans un schéma caisse connectée, les stipulations les plus exposées sont typiquement celles qui:
· interdisent par principe tout export ou toute interconnexion tierce, alors même que l’utilisateur peut demander une mise à disposition ;
· empêchent d’obtenir une copie structurée des données générées (pendant le contrat ou après la fin « dans un délai raisonnable ») ;
· ou rendent la sortie économiquement impraticable (restitution tardive, formats non exploitables, conditions unilatérales).
« Accès » ne veut pas dire « accès sans garde-fous ». Le Data Act impose aussi de préserver la sécurité et les secrets d’affaires , et, le cas échéant, le cadre RGPD mais ces réserves doivent être traitées comme des mesures de protection , pas comme des clauses-verrous générales.
Le Data Act ne modifie pas le droit des ententes. Mais en pratique, il peut augmenter la circulation (ou la contestabilité du verrouillage) des données. En distribution duale, cela impose de revisiter l’analyse « échanges d’informations » au sens de l’art. 101 §1 TFUE : la tête de réseau active en aval via ses succursales est un concurrent potentiel de ses franchisés, et l’exemption verticale (2022/720) n’englobe ces échanges que s’ils sont directement liés à l’accord vertical et nécessaires à l’amélioration de la production ou de la distribution (lignes directrices sur les accords verticaux).
Autrement dit : plus la tête de réseau (concurrente en aval via ses succursales / e-commerce) a accès à des données fines et actionnables par point de vente (prix, promotions, volumes, paniers, marges, stocks), plus elle doit être en mesure de :
· justifier la finalité « réseau » (standardisation, animation commerciale, supply, qualité, obligations contractuelles, etc.) ;
· réduire la granularité quand c’est pertinent (agrégation, délais, anonymisation) ;
· encadrer l’accès interne (need-to-know, habilitations) ;
· cloisonner (firewalls) lorsque des équipes opèrent en concurrence en aval.
Le bon réflexe n’est pas d’ajouter une « annexe data » au contrat de franchise mais d’adopter une méthode en trois temps :
1. Cartographier : quelles données la caisse génère, où elles résident (éditeur / tête de réseau), quelles sont « facilement disponibles », quelles données sont personnelles, quels secrets d’affaires sont en jeu.
2. Réécrire la mécanique d’accès et de sortie : exports, formats, API/connecteurs, délais, copie « à la sortie », conditions de mise à disposition à un tiers, en évitant les zones rouges de l’art. 13 (clauses imposées et déloyales susceptibles d’être non contraignantes).
3. En réseau dual : formaliser une doctrine « échanges d’informations » : ce que le siège collecte, à quel niveau de détail, pour quelles finalités, avec quelles habilitations et quels cloisonnements , pour rester dans le champ des échanges directement liés et nécessaires.
Chloé Zylberbogen, Avocat à la Cour