IA restaurant RGPD données clients : ce qu’il faut savoir

En bref. Une IA de gestion restaurant touche forcément des données personnelles : réservations, historique de commande, fichier de fidélité. Le RGPD ne l'interdit pas — il impose un principe précis : minimisation, finalité déclarée, durée de conservation limitée, et surtout aucune décision automatique non expliquée sur une donnée sensible. La bonne architecture n'est pas « pas d'IA sur les données clients » mais IA qui propose, humain qui valide, et trace conservée sur chaque action — avec jusqu'à 4 % du chiffre d'affaires mondial de sanction possible pour qui l'ignore.

Contexte / Définition

Un restaurant qui installe un logiciel avec IA pense d'abord cuisine, marges et service — rarement protection des données. Pourtant dès qu'un client réserve une table, commande en ligne ou s'inscrit à un programme de fidélité, le restaurant devient responsable d'un traitement de données personnelles au sens du RGPD↗, que ce traitement soit fait à la main sur un cahier ou par une intelligence artificielle intégrée au logiciel restaurant avec IA.

En 2026, le marché des logiciels restaurant communique massivement sur l'IA « qui fait tout seul » — mais très peu détaillent ce qui se passe concrètement sur les données sensibles. C'est précisément l'angle qui mérite d'être éclairci avant de choisir un logiciel tout-en-un pour son restaurant, pas après.

Comment l'IA d'un logiciel de gestion restaurant traite-t-elle les données clients sans enfreindre le RGPD ?

Réponse directe : en appliquant un principe simple à chaque action possible sur une donnée personnelle — l'IA propose, un humain confirme, et l'action laisse une trace immuable. C'est ce que la charte produit Onrush appelle le principe diff → confirmation humaine → application → audit, et il s'applique à toute mutation initiée par l'IA, pas seulement aux données RGPD.

Étape 1 — L'IA ne touche jamais directement la base de données

Une proposition de l'IA (par exemple relancer un client qui n'est pas revenu depuis trois mois) reste une suggestion tant qu'elle n'a pas été validée. Techniquement, cela signifie qu'aucun appel direct de l'IA n'écrit dans la table clients — elle passe par une couche intermédiaire appelée l'action layer, qui refuse toute action non confirmée.

Étape 2 — Le restaurateur voit le changement avant qu'il s'applique

Le diff montre exactement ce qui va changer : quelle donnée, pour quel client, avec quelle justification. Pas de case « tout accepter » qui masquerait le détail — chaque proposition reste lisible individuellement.

Étape 3 — Chaque validation est journalisée de façon inaltérable

Une fois confirmée, l'action est appliquée et consignée dans un journal d'audit qui ne peut être ni modifié ni supprimé — le même principe de traçabilité inaltérable qui protège déjà la caisse conforme NF525 sur les ventes. En cas de contrôle ou de demande d'un client exerçant son droit d'accès, cette trace répond à la question « qui a fait quoi, et sur quelle base ». C'est le même garde-fou que celui qui encadre déjà les alertes automatiques de l'agent de garde IA ou le pilotage du restaurant à la voix : l'IA signale et propose, elle n'agit jamais seule.

Quelles données clients un logiciel de gestion restaurant avec IA collecte-t-il concrètement ?

Réponse directe : trois familles de données concentrent l'essentiel du risque et de l'usage réel — l'historique de commande, les coordonnées de réservation, et le fichier de fidélité quand il existe.

1. L'historique de commande et de panier

Plats commandés, fréquence de visite, panier moyen — des données qui permettent à l'IA de proposer un plat du jour pertinent ou de repérer une baisse de fréquentation d'un client régulier, sans jamais publier ni partager cette donnée hors du restaurant.

2. Les coordonnées de réservation

Nom, téléphone, email — collectés pour honorer une réservation, pas pour nourrir une base marketing tierce sans consentement explicite. La finalité déclarée au moment de la collecte encadre strictement ce que l'IA peut en faire ensuite.

3. Le fichier de fidélité

Quand un programme de fidélité existe, les préférences et le solde de points s'ajoutent au dossier client. C'est le fichier le plus sensible du lot, détaillé en profondeur dans le fichier client RGPD du programme de fidélité — avec ses propres règles de durée de conservation et de droit à l'oubli.

Qui est responsable en cas de manquement RGPD : l'éditeur du logiciel ou le restaurant ?

Réponse directe : le restaurant, en tant que responsable de traitement — l'éditeur du logiciel est au mieux sous-traitant, et cette distinction juridique ne change rien au fait que c'est le restaurateur qui répond devant la CNIL en cas de contrôle.

C'est exactement pour cette raison qu'un restaurateur ne peut pas se contenter de la promesse marketing « notre IA est responsable » — il doit pouvoir vérifier, démo en main, que l'outil choisi applique réellement le principe de validation humaine sur toute action touchant une donnée sensible, et pas seulement sur les données financières ou réglementaires déjà protégées comme le food cost calculé par IA ou la TVA. Comparatif détaillé des approches dans le meilleur logiciel tout-en-un restaurant 2026.

Cas pratique — La Verrerie, Gaillac (2015-2018)

À La Verrerie, le fichier client tenait en trois endroits distincts : un cahier de réservation papier à l'accueil, un tableur Excel pour le programme de fidélité maison, et une liste d'emails collectée au fil des événements privés. Aucun des trois n'avait de règle de durée de conservation, et aucun processus n'existait pour répondre à une demande de suppression si un client l'avait formulée.

Le RGPD est devenu pleinement applicable le 25 mai 2018 — la même année où La Verrerie a fermé après le redressement judiciaire. Avec le recul, je sais aujourd'hui qu'en l'état, je n'aurais pas pu répondre dans le délai légal d'un mois à une demande d'accès ou de suppression : les trois fichiers n'étaient reliés par rien, et je n'aurais même pas pu garantir avoir retrouvé toutes les occurrences d'un client donné.

Ce n'était pas de la négligence volontaire — c'était l'absence totale de système pensé pour cette question, à une époque où la cuisine, les marges et la trésorerie absorbaient déjà toute l'attention disponible. La leçon tirée, appliquée ensuite au Lunch Wagon puis à la conception d'Onrush : un seul fichier client, une seule source de vérité, et une trace de chaque usage dès la conception plutôt qu'ajoutée après coup dans l'urgence.

IA opaque, IA sans traçabilité, ou IA transverse encadrée : que choisir ?

Trois niveaux d'IA sur les données clients, avec un écart de risque qui ne se voit qu'au moment où un client exerce ses droits.

Le point commun des deux premières colonnes : la confiance qu'on leur accorde repose sur une promesse, pas sur une preuve consultable. La troisième colonne retourne la logique — c'est au restaurateur de vérifier, pas à l'éditeur de jurer sur parole.

Source officielle

Erreurs fréquentes

Erreur 1 : accepter une IA qui agit seule « pour gagner du temps ». Le temps gagné sur une action non validée se paie en entier le jour où cette action doit être justifiée devant un client ou un contrôle — voir le guide complet du logiciel restaurant avec IA sur ce principe appliqué à l'ensemble du pilotage, pas seulement aux données RGPD.

Erreur 2 : confondre consentement marketing et conformité RGPD complète. Faire cocher une case de consentement ne suffit pas si rien ne trace ensuite ce que l'IA fait réellement de la donnée collectée.

Erreur 3 : laisser le fichier client éclaté entre plusieurs outils non reliés. Comme à La Verrerie en 2015-2018, un fichier dispersé rend impossible une réponse complète et rapide à une demande d'accès ou de suppression — voir le fichier client RGPD du programme de fidélité.

Erreur 4 : ne jamais demander en démo ce qui se passe en cas d'erreur de l'IA. C'est la question qui révèle le plus vite si l'éditeur a vraiment pensé la question, ou s'il l'a simplement évitée dans sa communication.

Conclusion

1. L'IA ne change rien aux obligations RGPD du restaurant — elle en change l'ampleur. Plus de lignes du fichier client traitées en un clic veut dire plus d'exposition si rien n'encadre ces actions.

2. Le principe qui protège vraiment, c'est diff → confirmation → audit. Pas l'absence d'IA, mais une IA qui propose et laisse toujours un humain décider sur une donnée sensible.

3. La responsabilité reste celle du restaurant, pas de l'éditeur. Choisir un outil qui le prouve par une trace consultable, plutôt que par une promesse marketing.

La bonne question à poser avant de signer n'est pas « votre IA est-elle intelligente ? » — c'est « que se passe-t-il si elle se trompe sur une donnée de mon client, et puis-je le prouver ensuite ? »

Dernière mise à jour le 2026-11-03. Rédigé par Cyril Quesnel, fondateur Onrush, chef entrepreneur (La Verrerie 2015-2018, Lunch Wagon 2023-2026).