Peut-on utiliser l'IA pour l'e-commerce sans risque ?

Plutôt oui, à une règle près : ne collez jamais de données client brutes ni de numéro de carte. L'IA peut rédiger vos fiches produit, répondre aux acheteurs et résumer les retours. Elle n'a pas besoin des vrais noms pour ça. Mais un export de commandes, ce sont des données personnelles de vos clients. Il relie un nom à une adresse, un e-mail, un téléphone et un historique d'achats. Collé dans un chatbot grand public, il part vers un tiers que votre client n'a jamais choisi. Les numéros de carte sont encore plus stricts. Sous PCI DSS, le code de sécurité d'une carte ne doit jamais être stocké. La parade est simple : anonymisez la commande avant le prompt, et gardez les numéros de carte complets à l'écart.

Une commande, c'est de la donnée client

Commençons par ce qu'une commande contient vraiment. Un export n'est pas un simple champ. C'est le profil complet d'une personne.

• Un nom de client et une adresse de livraison.
• Une adresse e-mail et un numéro de téléphone.
• Un historique d'achats complet, commande par commande.
• Parfois un fragment de numéro de carte ou une référence de paiement.

Ce bloc, ce sont des données personnelles. Votre client vous les a confiées pour finaliser un achat. Il n'a pas accepté de les envoyer à un fournisseur d'IA. Collez un export dans un chatbot grand public, et il quitte votre contrôle. Il atteint un tiers que votre client n'a jamais choisi.

La carte a ses propres règles : PCI DSS

Les données de carte suivent leur propre livre de règles. Il s'appelle PCI DSS (Payment Card Industry Data Security Standard, la norme de sécurité des données des cartes de paiement). Le PCI Security Standards Council trace une ligne nette. Certaines données ne doivent jamais être conservées après l'autorisation d'un paiement. C'est le cas des données complètes de piste magnétique ou de puce. C'est le cas du code de sécurité, les trois ou quatre chiffres imprimés sur la carte (le CVV/CVC). Et c'est le cas du code PIN. Même chiffrées, ces données ne doivent pas être retenues.

D'autres champs peuvent être conservés pour un motif métier légitime. Le nom, le numéro de carte, la date d'expiration. Mais ils doivent être protégés. Et quand un numéro de carte est affiché, il doit être masqué. Au maximum, seuls les six premiers et les quatre derniers chiffres peuvent apparaître. Coller un numéro de carte complet et en clair dans un chatbot va directement à l'encontre de ce principe.

Vous êtes le responsable de traitement : RGPD

Passons au volet juridique. Si vous servez des clients dans l'UE, le RGPD s'applique. Le RGPD, c'est le Règlement (UE) 2016/679. Il définit le « responsable du traitement » comme la partie qui décide des finalités et des moyens du traitement. Quand vous choisissez de passer des données de commande dans un outil d'IA, ce responsable, c'est vous. Vous en répondez.

Cela ne disparaît pas parce qu'un fournisseur détient les données. L'export relie un nom à une adresse, un e-mail, un téléphone et un historique. Ce sont des données personnelles dont vous êtes comptable. Elles restent sous votre responsabilité, où que vous les envoyiez. Aux États-Unis, des lois d'État comme le CCPA jouent un rôle voisin, et vous y êtes le « business ».

Le piège du bot support : OWASP

Il existe un risque plus subtil avec les bots de support. Imaginez que vous affiniez un modèle sur vos propres tickets clients. Le projet OWASP GenAI suit ce sujet. Son Top 10 pour les applications LLM classe la « divulgation d'informations sensibles » parmi les risques majeurs. Un modèle peut divulguer des données qu'il a mémorisées à l'entraînement.

L'OWASP note un point important pour les marchands. La mémorisation est souvent plus forte sur de petits jeux de données propres à une organisation. Une donnée peu volumineuse et répétée s'ancre plus fort. C'est exactement un bot support entraîné sur vos propres tickets. Dans de rares cas, les détails d'un client pourraient apparaître dans la session d'un autre. C'est probabiliste, pas garanti. Mais c'est une vraie raison de réduire ce que le modèle voit.

Une dernière catégorie s'oublie facilement : vos propres chiffres. Les prix d'achat fournisseurs et les conditions négociées sont commercialement sensibles. Ce ne sont pas des données personnelles réglementées. Aucune loi ne les protège donc automatiquement. Leur valeur vient du fait qu'ils restent secrets. Collez-les dans un outil d'IA non validé, et vous pouvez éroder discrètement votre avantage de marge.

La parade : anonymiser avant l'envoi

Bonne nouvelle : l'IA fait toujours le travail. Elle rédige la fiche produit. Elle répond à l'acheteur. Elle résume les retours. Elle n'a simplement besoin d'aucun vrai nom pour ça. Réduisez la donnée à la source.

1. 1Anonymisez les noms de clients, les adresses et les identifiants de commande avant le prompt.
2. 2Ne collez jamais un numéro de carte complet, un code CVV/CVC ou un PIN.
3. 3Préférez des outils intégrés et validés, liés par un DPA (Data Processing Agreement, accord de traitement) et des clauses de non-entraînement.
4. 4Gardez une relecture humaine sur tout ce qu'un client va lire.

C'est le rôle d'ONYRI Sanitize. Le moteur détecte les données sensibles — nom, adresse, e-mail, téléphone, identifiant de commande — et les remplace par des jetons réversibles avant l'envoi. La détection et le mapping restent dans votre navigateur. Seul un texte anonymisé atteint le modèle. L'IA n'y trouve que des jetons, jamais les données réelles de vos clients. Vous obtenez la rédaction et le support, sans le risque que PCI DSS, le RGPD et l'OWASP vous demandent d'écarter.