Chiffrement des données en entreprise : guide pour vos chats

Chaque commande WhatsApp, chaque message privé Instagram et chaque conversation de support Telegram laisse derrière elle des données clients : numéros de téléphone, adresses de livraison, historiques de conversation et les tokens d'accès qui relient vos canaux. Le chiffrement des données en entreprise transforme ces données en texte chiffré, illisible pour quiconque n'a pas la clé, pendant qu'elles circulent sur les réseaux comme pendant qu'elles dorment dans vos bases et vos sauvegardes.

Points clés

Le chiffrement des données en entreprise repose sur deux couches : le chiffrement en transit (TLS) protège les données qui circulent, le chiffrement au repos (généralement AES) protège les données stockées.
Les tokens d'accès aux canaux, les clés API et les secrets de webhook sont des identifiants. Un token qui fuite peut permettre à un attaquant d'agir au nom de votre entreprise : chiffrez-les au niveau du champ.
Le chiffrement de disque protège un disque volé, pas un serveur en fonctionnement. Le chiffrement au niveau du champ, avec des clés conservées hors de la base de données, protège encore ces champs dans un dump qui fuite.
AES-256-GCM est un chiffrement authentifié : il masque les données et détecte toute altération, et il repose sur le fait de ne jamais réutiliser un nonce avec la même clé.
Le chiffrement n'arrête pas ceux qui ont le droit de déchiffrer. Une plateforme de réponse automatique par IA doit lire les messages pour y répondre : le contrôle d'accès et la conservation comptent donc autant que les algorithmes.

Ce que le chiffrement des données en entreprise doit couvrir quand vous vendez par chat

Une entreprise qui vend par messagerie, par exemple via une boîte de réception IA pour WhatsApp, possède son propre inventaire de données :

Identifiants et secrets. Tokens d'accès des pages Facebook et de WhatsApp Business, tokens de bot Telegram, clés des fournisseurs d'IA, clés des prestataires de paiement et secrets de webhook.
Données personnelles des clients. Numéros de téléphone, adresses e-mail, adresses de livraison et identifiants clients. Dans le commerce par chat, le numéro de téléphone tient souvent lieu d'identité.
Historiques et médias. Transcriptions, messages vocaux, photos et factures envoyés par les clients.
Mots de passe des équipes. Ils doivent être hachés, pas chiffrés (voir plus bas).
Appareils des équipes. Ordinateurs portables et téléphones qui ouvrent la boîte de réception ou hébergent des exports. Activez FileVault ou BitLocker, les codes de verrouillage et l'effacement à distance.
Les copies. Sauvegardes, exports CSV, journaux et bases de préproduction, souvent moins protégés que la production.

Une règle simple pour le chiffrement des données clients, ce que beaucoup appellent encore le « cryptage des données » : protégez au niveau du champ tout ce qui donne un accès ou identifie une personne, et accordez à chaque copie la même protection qu'à l'original.

Chiffrement au repos et chiffrement en transit

Le chiffrement en transit protège les données pendant qu'elles circulent entre un navigateur, votre serveur et des API tierces. Le chiffrement au repos protège les données stockées sur les disques, dans les bases de données et dans les sauvegardes.

Critère	Chiffrement en transit	Chiffrement au repos
Protège contre	L'écoute du réseau, l'altération, les faux serveurs	Les disques volés, les dumps qui fuitent, les sauvegardes exposées
Standard habituel	TLS 1.2 ou TLS 1.3	AES-256, souvent AES-256-GCM
Où il s'applique	Du navigateur à l'application, webhooks, appels d'API	Disque, base de données, champs individuels, sauvegardes
Ne couvre pas	Les données une fois arrivées et déchiffrées	Les données en cours d'utilisation par une application qui tourne

La norme NIST SP 800-52 Rev. 2 impose aux serveurs TLS du gouvernement américain de prendre en charge TLS 1.2, et de prendre en charge TLS 1.3 d'ici janvier 2024. C'est une base raisonnable pour n'importe quelle entreprise : acceptez TLS 1.2 et 1.3, et désactivez tout ce qui est plus ancien.

TLS ne protège que le trajet. WhatsApp Cloud API livre ses webhooks en HTTPS, et la documentation de Meta explique que Cloud API déchiffre les messages entrants avant de les transmettre à l'entreprise, en les conservant 30 jours au maximum. Ensuite, ce sont le stockage et le contrôle d'accès qui prennent le relais.

Chiffrement de disque, de base de données et au niveau du champ

Le chiffrement au repos se décline en plusieurs couches :

Le chiffrement de disque ou de volume protège un disque volé ou mis au rebut. Tant que le serveur tourne, le système d'exploitation déchiffre les données automatiquement : un attaquant déjà présent sur le serveur voit donc des données en clair.
Le chiffrement des fichiers de base de données a la même limite : quiconque peut interroger la base récupère du texte en clair.
Le chiffrement au niveau du champ chiffre des colonnes précises, un token ou un numéro de téléphone par exemple, dans l'application avant qu'elles n'atteignent la base. La clé vit ailleurs : un dump qui fuite ou une sauvegarde copiée ne montre que du texte chiffré pour ces champs.

Le compromis porte sur la recherche : impossible de filtrer normalement en SQL sur une colonne chiffrée. En pratique, réservez le chiffrement au niveau du champ aux secrets et aux coordonnées les plus sensibles. Les équipes qui doivent retrouver un client par téléphone ou par e-mail peuvent stocker une empreinte à clé (un index aveugle) à côté du texte chiffré et faire la recherche dessus.

AES-256-GCM : taille de clé et mode

AES est défini par la norme FIPS 197, avec des clés de 128, 192 et 256 bits. AES-256 utilise la plus longue des trois.

Le mode compte autant que la taille de la clé. GCM (NIST SP 800-38D) est un chiffrement authentifié : il garde les données confidentielles et détecte si quelqu'un a modifié le texte chiffré. Ne réutilisez jamais un nonce avec la même clé : cette réutilisation casse les garanties de GCM. Laissez une bibliothèque maintenue générer les nonces, et n'écrivez jamais votre propre cryptographie.

Comment stocker des clés API et des tokens d'accès en toute sécurité

Le choix dépend d'une seule question : avez-vous besoin de récupérer la valeur d'origine ?

Chiffrez les secrets que vous devez transmettre à un tiers : tokens d'accès WhatsApp et Instagram, tokens de bot Telegram, clés des fournisseurs d'IA et clés de paiement. Utilisez AES-GCM au niveau du champ, avec une clé conservée hors de la base de données.
Hachez les secrets que vous ne faites que vérifier : mots de passe, clés API partenaires et codes à usage unique. Une empreinte ne se déchiffre pas, mais une valeur courte ou devinable se casse par force brute : utilisez une fonction de hachage lente comme Argon2id ou bcrypt pour les mots de passe, et un HMAC à clé pour les codes.
Tenez-les hors des journaux, des messages d'erreur, des outils d'analyse et des URL.
Limitez la portée et faites tourner les clés. Ne demandez que les permissions dont un token a besoin, et remplacez les tokens quand une personne qui y avait accès s'en va.

Le chiffrement au repos ne protège pas un token pendant qu'il reste déchiffré en mémoire, le temps d'un appel d'API. Le durcissement des serveurs et le moindre privilège réduisent ce risque.

Les bases de la gestion des clés de chiffrement

Le chiffrement ne vaut que ce que vaut l'endroit où la clé est rangée. L'échec classique : une clé stockée à côté des données, dans la même base ou dans un fichier de configuration versionné.

Séparez les clés des données. Gardez-les dans un gestionnaire de secrets, un KMS ou une configuration serveur que la base de données ne peut pas atteindre.
Passez au chiffrement par enveloppe à grande échelle. Une clé maîtresse chiffre les clés de données : la faire tourner n'oblige pas à tout rechiffrer.
Dérivez des clés dédiées à chaque usage avec une fonction de dérivation comme HKDF.
Prévoyez la rotation et la récupération. Une clé perdue, ce sont des données perdues, sauvegardes comprises.

Contrôle d'accès et moindre privilège : le chiffrement ne suffit pas

Le chiffrement arrête les personnes qui n'ont pas la clé, pas celles ni les systèmes autorisés à déchiffrer. Une plateforme de réponse automatique par IA doit lire le message d'un client pour rédiger une réponse : ses serveurs traitent donc des messages lisibles.

La même logique vaut en amont. Le livre blanc sur la sécurité de WhatsApp ne considère pas comme chiffrées de bout en bout les conversations avec des entreprises qui utilisent Cloud API, parce que les messages ne sont pas remis directement à un terminal contrôlé par l'entreprise. Lisez WhatsApp Business Cloud API ou application Business avant de choisir votre configuration.

La couche suivante concerne donc les personnes qui peuvent atteindre les données :

Contrôle d'accès au moindre privilège : donnez à chaque membre de l'équipe le rôle le plus restreint qui fonctionne. Un agent qui répond aux conversations n'a pas besoin de la facturation.
Connexion renforcée : ajoutez une seconde étape de vérification et révoquez les sessions à la déconnexion.
Cloisonnement des données par entreprise : chaque requête doit prouver que l'appelant appartient bien à cette entreprise.
Journaux d'audit et conservation : enregistrez les actions privilégiées, et ne gardez les historiques de conversation que le temps nécessaire.

Sauvegardes, exports et conservation

Les sauvegardes sont des copies complètes des données clients, souvent conservées plus longtemps et surveillées de moins près que la production. Chiffrez les fichiers de sauvegarde, limitez qui peut les télécharger, testez les restaurations, récupération de clé comprise, et supprimez les vieux exports CSV partagés par e-mail ou par chat.

Le chiffrement a aussi un poids juridique. L'article 32 du RGPD cite le chiffrement parmi les mesures de sécurité, et l'article 34(3)(a) permet au responsable du traitement de ne pas informer les personnes concernées d'une violation quand le chiffrement a rendu les données incompréhensibles pour les personnes non autorisées. L'obligation de l'article 33, notifier l'autorité de contrôle dans les 72 heures après avoir pris connaissance d'une violation, est distincte. La PDPL saoudienne et la KVKK turque fixent elles aussi des délais de 72 heures auprès du régulateur.

Ceci est une information générale, pas un conseil juridique. Savoir si le RGPD ou une autre loi s'applique, et si une exemption convient à une violation précise, dépend de votre situation : consultez un avocat qualifié.

Les questions à poser à tout éditeur de chat ou de CRM

Avant de connecter vos canaux, envoyez ces questions de sécurité à l'éditeur, sous la forme d'un questionnaire écrit :

Quelles versions de TLS vos endpoints acceptent-ils ?
Quelles données sont chiffrées au repos, et à quelle couche ? Le contenu des messages en fait-il partie ?
Les tokens de canaux et les clés API sont-ils chiffrés au niveau du champ, et où la clé est-elle stockée ?
Les sauvegardes sont-elles chiffrées, et qui peut y accéder ?
Vos équipes peuvent-elles lire nos conversations, et cet accès est-il journalisé ?
Quels rôles et quelles permissions pouvons-nous définir pour notre équipe ?
Comment nos données sont-elles isolées de celles de vos autres clients ?
Nos conversations servent-elles à entraîner des modèles d'IA, chez vous ou chez vos fournisseurs d'IA ?
Qui sont vos sous-traitants ultérieurs, et où les données sont-elles stockées ?
Signerez-vous un DPA, et sous quel délai les données sont-elles supprimées après notre départ ?

Méfiez-vous des réponses du type « chiffrement de niveau militaire » ou « toutes les données sont entièrement chiffrées ». Un éditeur digne de confiance nomme l'algorithme, la couche et les angles morts.

Ce que Raabt chiffre et protège aujourd'hui

Chaque point ci-dessous reflète le code de Raabt en septembre 2026.

Chiffrement au niveau du champ : les champs sensibles sont chiffrés au niveau applicatif avec AES-256-GCM. Les nouvelles écritures utilisent une clé dérivée via HKDF-SHA256, et les anciennes valeurs sont rechiffrées avec elle lors de leur prochain enregistrement. L'application refuse de démarrer sans une clé d'au moins 32 caractères.
Ce qui est chiffré : les identifiants et les tokens (tokens d'accès aux canaux Facebook, Instagram, WhatsApp et Telegram, clés API des fournisseurs d'IA et de paiement, secrets de webhook) et certaines coordonnées (numéros de téléphone, e-mails et adresses de commande des clients).
Hachage : les mots de passe utilisent Argon2id (19 Mio de mémoire, 2 itérations), et les anciennes empreintes bcrypt sont mises à niveau à la connexion. Les secrets des clés API partenaires ne sont stockés que sous forme d'empreintes SHA-256.
Connexion : les connexions par e-mail et mot de passe exigent un code à usage unique envoyé à l'adresse e-mail de l'utilisateur avant l'ouverture de toute session (la connexion Google n'utilise pas ce code). Les codes ne sont stockés que sous forme d'empreintes HMAC-SHA256, expirent et ne fonctionnent qu'une fois.
Accès de l'équipe : quatre rôles (owner, admin, agent, viewer) avec des permissions par section. L'accès à la facturation ne peut pas être délégué à un non-propriétaire.
Isolation : les endpoints d'entreprise vérifient que l'appelant est un membre actif de cette entreprise, et renvoient « introuvable » dans le cas contraire.
Webhooks et médias : les webhooks Meta sont rejetés sans une signature X-Hub-Signature-256 valide, les webhooks Telegram exigent un token secret, et les pièces jointes ne sont servies que par des URL signées qui expirent.
Infrastructure : l'application n'est pas exposée directement à Internet ; le trafic public l'atteint par un Cloudflare Tunnel. Les journaux d'erreurs de base de données n'incluent jamais les paramètres de requête : les numéros de téléphone et les e-mails restent donc hors de ces journaux.
Journal d'audit des administrateurs de la plateforme : les actions des administrateurs de la plateforme sont écrites dans un journal d'audit en ajout seul (qui, quoi, quand, IP, avec des instantanés avant/après et les secrets masqués). Ce n'est pas un journal des messages clients.

Ce que le chiffrement ne peut pas faire ici : une boîte de réception IA doit lire le texte des messages pour rédiger une réponse, donc le contenu des conversations est traité en clair sur le serveur. C'est exactement pour cela que les points sur le contrôle d'accès, la conservation et les sauvegardes pèsent autant que l'algorithme que vous choisissez.

Les demandes de suppression de données Meta renvoient un code de confirmation, avec un lien de statut sur notre page de suppression des données. La suppression d'un compte exige votre mot de passe et un code à usage unique envoyé par e-mail ; le compte est désactivé et son adresse e-mail anonymisée.

Check-list du chiffrement des données en entreprise : dans quel ordre le déployer

Le chiffrement des données dans une TPE/PME fonctionne mieux dans un ordre fixe, en commençant par ce qui fait le plus de dégâts en cas de fuite :

Servez tout en HTTPS, avec TLS 1.2 ou 1.3 uniquement.
Activez le chiffrement intégral du disque et le verrouillage de l'écran sur chaque appareil qui ouvre les conversations clients.
Faites passer les tokens et les clés API au chiffrement au niveau du champ, avec des clés séparées.
Hachez les mots de passe avec Argon2id ou bcrypt et ajoutez une seconde étape à la connexion.
Chiffrez les numéros de téléphone, les e-mails et les adresses de vos clients.
Chiffrez les sauvegardes, définissez des rôles au moindre privilège et fixez des durées de conservation des conversations.
Envoyez les questions à poser à l'éditeur à chaque outil de chat, de CRM et d'IA que vous utilisez.

Questions fréquentes

Quelles données une entreprise doit-elle chiffrer ?

Commencez par tout ce qui donne un accès ou identifie une personne : tokens de canaux, clés API, secrets de webhook, et numéros de téléphone, e-mails et adresses de vos clients. Couvrez ensuite les historiques de conversation, les appareils des équipes et chaque sauvegarde ou export.

Quelle différence entre chiffrement au repos et chiffrement en transit ?

Le chiffrement en transit, généralement TLS, protège les données qui circulent entre appareils, serveurs et API. Le chiffrement au repos, généralement AES, protège les données stockées.

Le chiffrement AES-256 suffit-il à protéger les données clients ?

AES-256 est solide, mais l'algorithme est rarement le maillon faible. Les points de défaillance habituels : un mauvais stockage des clés, des nonces réutilisés, des accès trop larges pour les équipes et des sauvegardes non protégées.

Comment stocker des clés API et des tokens d'accès en toute sécurité ?

Chiffrez les tokens que vous devez réutiliser avec AES-GCM au niveau du champ, et gardez la clé hors de la base de données. Hachez les secrets que vous ne faites que vérifier, comme les mots de passe et les clés API partenaires.

Si j'utilise HTTPS, mes données sont-elles protégées sur le serveur ?

Non. HTTPS ne protège que les données en transit. Sur le serveur, la sécurité dépend du chiffrement au repos, du contrôle d'accès et de la façon dont vous gérez les sauvegardes.

Quelles questions de sécurité poser à un éditeur de chatbot ou de CRM ?

Demandez quelles versions de TLS il accepte, ce qui est chiffré au repos et à quelle couche, où les clés sont stockées, si l'accès de ses équipes aux conversations est journalisé, qui sont ses sous-traitants ultérieurs et où les données sont stockées, si les conversations entraînent des modèles d'IA, et s'il signera un DPA assorti d'un délai de suppression.

Prêt à faire tourner vos conversations sur une boîte de réception IA qui chiffre les tokens de canaux et certaines coordonnées de vos clients ? Commencer gratuitement.