Chiffrement, encodage, hachage - Protégez vos données !

Dans un système d’information, le chiffrement change surtout une chose : ce que l’on peut lire immédiatement, et ce que l’on doit d’abord déverrouiller avec une clé. C’est ce qui fait la valeur d’une donnée chiffrée : elle reste exploitable pour celui qui possède les droits, tout en devenant illisible pour les autres. Je vais donc clarifier ce que recouvre vraiment cette notion, la différence avec l’encodage et le hachage, puis la manière de la déployer sans affaiblir la sécurité globale.

Ce que recouvre vraiment une donnée protégée par chiffrement

En pratique, je distingue toujours deux états : la donnée en clair et sa version chiffrée. La première est lisible par tout système autorisé ; la seconde est transformée de façon à n’avoir de sens qu’avec la bonne clé et le bon algorithme. Cette transformation est réversible, ce qui la distingue d’un simple changement de format ou d’un marquage technique.

La confusion est fréquente, parce que le mot “chiffrer” est parfois utilisé comme un synonyme vague de “sécuriser”. Or une donnée chiffrée n’est pas automatiquement protégée contre tout. Si la clé est mal gérée, si le point de déchiffrement est trop large, ou si les sauvegardes restent en clair, le gain réel peut être faible. Je le répète souvent en audit : le chiffrement est une brique de sécurité, pas une assurance tous risques.

Cette nuance compte aussi pour la gouvernance. En SI, la vraie question n’est pas seulement “est-ce chiffré ?”, mais “à quel moment, par qui, avec quelle clé et dans quel périmètre ?”. C’est précisément ce qui permet d’éviter les fausses bonnes réponses, et c’est la porte d’entrée vers la distinction entre chiffrement, codage et hachage.

Chiffrement, encodage et hachage ne jouent pas le même rôle

Je vois souvent ces trois mécanismes mis dans le même panier. C’est une erreur de conception fréquente, et elle mène à de mauvais choix techniques. Le chiffrement protège la confidentialité ; l’encodage sert à représenter l’information dans un autre système de symboles ; le hachage produit une empreinte courte et non réversible, utile surtout pour vérifier l’intégrité ou stocker des mots de passe.

La différence est concrète. Si je code un message en Base64, je ne le protège pas, je le transforme. Si je le hache, je ne peux pas revenir au message initial. Si je le chiffre, je garde une voie de retour, mais seulement avec la clé appropriée. La CNIL rappelle d’ailleurs que le chiffrement vise la confidentialité, alors que le hachage répond à un autre besoin.

Pour les mots de passe, le bon réflexe n’est donc pas le chiffrement mais le hachage avec une fonction adaptée, par exemple Argon2, bcrypt ou scrypt. C’est une distinction simple, mais elle évite des architectures bancales dès le départ. Une fois ce socle posé, on peut regarder comment le chiffrement s’intègre concrètement dans un SI.

Comment le chiffrement s’insère dans un SI moderne

La CNIL distingue trois états de la donnée : au repos, en transit et en traitement. Je trouve cette grille très utile, parce qu’elle force à penser la protection en fonction du contexte réel plutôt qu’en fonction d’un seul outil. Un disque chiffré ne répond pas au même risque qu’un flux HTTPS, et un traitement applicatif n’a pas la même contrainte qu’une sauvegarde.

Dans les environnements cloud, le point sensible est presque toujours la gestion des clés. La CNIL rappelle qu’un chiffrement opéré par le fournisseur peut impliquer un accès transitoire aux clés et aux données en clair. Autrement dit, chiffrer au repos ne suffit pas toujours si le fournisseur doit aussi déchiffrer pour traiter le service.

À l’inverse, un chiffrement de bout en bout garde le contrôle des clés du côté du client et limite l’accès du fournisseur aux seuls paquets transportés. C’est un modèle plus exigeant, mais il devient très pertinent dès qu’on parle de messagerie sensible, de partage de fichiers ou de collaboration entre entités distinctes. Cette logique est utile, mais elle n’a d’intérêt que si l’on sait où elle apporte vraiment un gain mesurable.

Où le chiffrement apporte le plus de valeur en entreprise

Je commence presque toujours par les données qui ont le plus de conséquences en cas de fuite : dossiers clients, documents RH, exports comptables, sauvegardes, secrets applicatifs et pièces jointes sensibles. Ce sont des cas simples à prioriser, parce que l’impact métier d’un accès non autorisé y est immédiatement compréhensible.

• Postes portables et mobiles : le chiffrement intégral du disque réduit fortement le risque en cas de vol ou de perte physique.
• Sauvegardes : elles sont souvent oubliées alors qu’elles concentrent des volumes importants de données. Sans chiffrement, une simple copie de backup devient une porte ouverte.
• Échanges externes : pour un envoi vers un partenaire, un client ou un prestataire, le chiffrement des flux ou des pièces jointes sensibles évite de dépendre du seul canal de transport.
• Stockage cloud : il faut arbitrer entre simplicité d’administration et niveau de contrôle des clés. Plus on veut limiter l’accès du fournisseur, plus la solution devient exigeante à opérer.
• Bases de données : le chiffrement de champs précis est utile quand seule une partie de l’information est sensible, par exemple un identifiant national, un IBAN ou un numéro de santé.

La bonne logique n’est pas de chiffrer tout partout de la même manière. Je préfère une approche par couche : flux, stockage, application, puis clés. C’est plus lisible pour l’équipe technique, et surtout plus robuste dans la durée. Cette méthode met aussi en évidence les erreurs de conception que je rencontre le plus souvent.

Les erreurs qui fragilisent les données protégées

Le chiffrement échoue rarement parce que l’algorithme est “faible” dans l’absolu. Il échoue surtout à cause de sa mise en œuvre. La CNIL recommande des tailles de clés de 128, 192 ou 256 bits pour AES, et au moins 2 048 bits pour RSA ; je regarde aussi le mode de construction, car AES-GCM ou ChaCha20-Poly1305 sont des choix solides quand on veut à la fois confidentialité et vérification de l’intégrité.

• Conserver les clés dans le même périmètre que les données : si la clé et le contenu chiffré tombent ensemble, l’intérêt chute immédiatement.
• Oublier les sauvegardes : un backup non chiffré annule une protection bien mise en place ailleurs.
• Chiffrer sans contrôler l’accès applicatif : un utilisateur ou un service trop permissif peut récupérer le contenu en clair après déchiffrement.
• Confondre chiffrement en transit et chiffrement de bout en bout : la frontière entre les deux change complètement le niveau d’exposition.
• Utiliser des algorithmes ou des modes de construction dépassés : ce n’est pas seulement la recette qui compte, c’est aussi son mode d’emploi.

Je vois aussi une erreur plus subtile : croire qu’un service est sûr parce qu’il chiffre le disque. En réalité, si l’application doit lire la donnée, elle la manipule en clair à un moment donné. C’est précisément ce moment qu’il faut cadrer, isoler et tracer. Une stratégie utile ne s’arrête donc pas au choix de l’algorithme, elle commence avec la gouvernance des clés et des accès.

Ce que je conseille pour une mise en place réaliste et durable

Si je devais déployer une stratégie de chiffrement dans un SI sans le surcharger, je suivrais un ordre très simple. D’abord, je classe les données par sensibilité et par état. Ensuite, je choisis le niveau de chiffrement qui réduit le risque réel, pas celui qui coche le plus de cases sur le papier. Enfin, je traite les clés comme des actifs critiques, au même titre que les données elles-mêmes. Je ne réduis jamais le coût au seul CPU : le vrai prix, c’est aussi la gestion des clés, la rotation, les restaurations et la formation des équipes.

1. Commencer par les flux : TLS 1.3 pour les échanges web, API et intégrations exposées, avec une configuration propre et des certificats bien gérés.
2. Sécuriser le stockage : chiffrement de disque ou de fichier pour les postes, serveurs, sauvegardes et archives.
3. Remonter au niveau applicatif quand le périmètre d’accès doit être plus fin, par exemple pour quelques colonnes sensibles d’une base.
4. Séparer les clés des données : droits restreints, rotation, sauvegarde des secrets, procédure de récupération en cas de perte.
5. Tester le déchiffrement autant que le chiffrement, parce qu’une restauration ratée vaut parfois pire qu’une absence de protection.

La CNIL insiste aussi sur un point que je partage complètement : il faut choisir des solutions adaptées à l’état de la donnée et à l’emplacement du traitement. En clair, une solution simple à opérer peut suffire pour des documents peu sensibles, mais un contexte cloud ou multi-acteurs demande souvent un contrôle plus fin des clés et des flux. Je préfère une architecture cohérente et maintenable à une usine à gaz théoriquement parfaite.

Ce que je garde en tête avant de trancher

Si le besoin principal est la confidentialité, le chiffrement est souvent la bonne réponse. Si le vrai problème est l’intégrité, il faut regarder le hachage ou la signature. Si le sujet est seulement la représentation d’un message, un encodage suffit, sans surpromesse de sécurité. Cette hiérarchie évite de surdimensionner un projet ou, à l’inverse, de le sous-protéger.

Dans un SI réel, je pars toujours d’une question simple : qui doit pouvoir lire quoi, à quel moment, et avec quelle clé ? Quand cette réponse est nette, la technique suit beaucoup plus facilement. Quand elle est floue, aucune donnée protégée par chiffrement ne compensera un mauvais design de départ.