La cryptographie a quitté le périmètre des spécialistes. En 2026, n’importe quel développeur, sysadmin ou freelance manipule au quotidien des certificats TLS, des clés SSH, des hashs de mots de passe et des fichiers chiffrés — souvent sans en mesurer pleinement les enjeux. Une mauvaise configuration TLS expose un site, un mot de passe stocké en clair compromet une base de données entière, une clé SSH partagée ouvre un serveur à n’importe qui. Cet article fait le tour pratique de ce qu’il faut savoir et savoir faire pour protéger correctement code, données et accès — avec une orientation outils gratuits et démarches reproductibles. Pour la théorie pure (chiffrement symétrique, asymétrique, fonctions de hachage, certificats), des articles plus conceptuels existent déjà sur le site. Cet article-ci va à la pratique.
À qui s’adresse cette démarche
Trois profils tirent un bénéfice direct des opérations couvertes. Le développeur web qui déploie des sites en production et veut éviter les pièges classiques — HTTPS mal configuré, mots de passe stockés en MD5, clés API en clair dans le dépôt Git. Le sysadmin ou freelance DevOps qui gère des serveurs Linux et a besoin de SSH propre, de TLS automatisé et de chiffrement de fichiers de configuration. L’entrepreneur tech ou responsable IT qui veut comprendre les enjeux pour choisir des prestataires et auditer leur travail.
Cinq sujets pratiques qui couvrent 90 % des besoins
La cryptographie pratique en 2026 se ramène à cinq opérations concrètes que tout profil tech rencontre régulièrement. Aucune n’est exotique, aucune ne demande un diplôme — mais chacune doit être réalisée correctement.
1. TLS / HTTPS sur un site web
Aujourd’hui, déployer un site sans HTTPS est inacceptable — Chrome, Firefox et Safari affichent un avertissement Non sécurisé, le SEO chute, les API modernes (géolocalisation, service workers, paiement) refusent de fonctionner. La solution standard est Let’s Encrypt, autorité de certification gratuite et automatisée qui livre des certificats valides pour 90 jours, renouvelables automatiquement. L’outil Certbot gère l’obtention et le renouvellement sur la plupart des serveurs web (Nginx, Apache).
Pour qui héberge sur un service mutualisé (Hostinger, OVH, Infomaniak, hébergeurs sénégalais comme Sonatel ou Hosteur), HTTPS est généralement activable en deux clics depuis le panneau de contrôle. Pour un VPS ou un serveur dédié, Certbot tourne en cron et renouvelle sans intervention humaine.
2. Hachage des mots de passe
Tout site avec authentification stocke des mots de passe — la question est comment. Stocker un mot de passe en clair est une faute professionnelle. Stocker en MD5 ou SHA-1 est presque aussi grave : ces fonctions sont cassables en quelques heures avec un GPU moderne. Les standards actuels sont bcrypt, argon2 et scrypt — fonctions de hachage spécifiquement conçues pour ralentir les attaques par force brute.
argon2 est le gagnant du Password Hashing Competition (2015) et la recommandation actuelle pour les nouveaux projets. bcrypt reste largement déployé et acceptable. La règle pratique : utiliser une bibliothèque maintenue (par exemple bcrypt en Node.js, argon2 en Python, password_hash() en PHP qui choisit automatiquement) plutôt que d’implémenter soi-même.
3. Clés SSH
L’accès SSH par mot de passe est dépassé en 2026. Les bots scannent en permanence les ports 22 d’Internet et tentent les mots de passe courants. La parade : authentification par clé publique. Le couple clé privée locale + clé publique sur le serveur remplace le mot de passe et résiste aux attaques par force brute.
Le standard actuel est ed25519, plus rapide et plus sûr que RSA. Une clé ed25519 fait quelques dizaines d’octets et offre un niveau de sécurité équivalent à une clé RSA 3000 bits. La génération se fait en une commande, l’installation sur le serveur en deux. Une fois activée, désactiver l’authentification par mot de passe sur le serveur.
4. Chiffrement de fichiers
Pour envoyer un fichier sensible par mail, stocker un secret dans un dépôt Git, ou transporter des données confidentielles sur clé USB, le chiffrement de fichier est la réponse pratique. Deux outils dominent. GPG (GNU Privacy Guard) fait du chiffrement asymétrique — on chiffre avec la clé publique du destinataire, lui seul peut déchiffrer avec sa clé privée. C’est la voie pour un échange. age est un outil moderne plus simple à utiliser, équivalent fonctionnel pour les usages courants. Pour un fichier qu’on garde pour soi, le chiffrement symétrique avec GPG ou age en mode passphrase suffit et tient dans une commande.
5. Chiffrement de disque
Un ordinateur portable volé, c’est éventuellement un coût matériel — mais si le disque n’est pas chiffré, c’est aussi tous les emails, contrats, sauvegardes, mots de passe enregistrés dans le navigateur et fichiers personnels qui partent. Le chiffrement intégral de disque est aujourd’hui standard sur tous les systèmes. BitLocker sur Windows Pro, FileVault sur macOS, LUKS sur Linux, VeraCrypt en multiplateforme open-source. Activable en quelques minutes, transparent à l’usage, sauf au démarrage où une phrase secrète est demandée.
Vue d’ensemble pratique
Chaque sujet fait l’objet d’un tutoriel pas-à-pas associé :
- Configurer Let’s Encrypt avec Certbot sur Nginx — du domaine au certificat valide en 15 minutes
- Hasher des mots de passe avec bcrypt et argon2 — implémentations Node.js, Python et PHP
- Générer et utiliser une clé SSH ed25519 — connexion sans mot de passe sur un serveur Linux
- Chiffrer un fichier avec GPG — symétrique pour soi, asymétrique pour un destinataire
- Chiffrer un disque avec BitLocker, VeraCrypt ou LUKS — pas-à-pas pour Windows et Linux
Approfondir les algorithmes en pratique
Pour aller plus loin que la simple utilisation et comprendre les algorithmes derrière les outils, quatre tutoriels appliqués détaillent les chiffrements eux-mêmes — du code reproductible et les mathématiques expliquées de manière accessible :
- Chiffrer en AES-256-GCM — OpenSSL et Python, dérivation PBKDF2, script de fichier, mathématiques du corps fini GF(2⁸)
- Chiffrer et signer en RSA-3072 — OAEP, PSS, chiffrement hybride avec AES, théorèmes d’Euler et Fermat
- Chiffrer en ChaCha20-Poly1305 — alternative à AES-GCM, principe ARX, hash universel modulo 2¹³⁰−5
- De Lucifer à AES — réseau de Feistel, DES et 3DES legacy, paradoxe des anniversaires et migration concrète
Les pièges classiques à éviter
Trois erreurs structurelles reviennent dans les audits de sécurité.
L’algorithme dépassé. Utiliser MD5 ou SHA-1 pour hasher des mots de passe, du DES ou du 3DES pour chiffrer, du SSL 3.0 ou du TLS 1.0 pour HTTPS — autant de choix techniques qui étaient acceptables il y a quinze ans et qui sont aujourd’hui des vulnérabilités. La règle simple : suivre les recommandations actuelles de SSL Labs, du NIST, ou de l’ANSSI, et bannir les algorithmes marqués déconseillé.
L’implémentation maison. Coder son propre algorithme de chiffrement ou son propre hash est presque toujours une erreur — la cryptographie est un domaine où les bibliothèques éprouvées (OpenSSL, libsodium, BouncyCastle) ont été auditées par des spécialistes pendant des années, et où la moindre subtilité (générateur aléatoire faible, choix du IV, padding mal géré) ouvre la porte à des attaques. Utiliser les fonctions standard de la plateforme.
La gestion des clés. La meilleure cryptographie du monde ne sert à rien si la clé privée traîne dans un dépôt Git public, est partagée sur Slack, ou stockée sans protection. Deux règles : ne jamais committer une clé privée ou un secret dans un dépôt (utiliser git-secret, des variables d’environnement, ou un gestionnaire de secrets type Vault), et générer des clés différentes pour chaque environnement (dev, staging, production).
Audit rapide de sa propre infrastructure
Pour évaluer rapidement où on en est, cinq vérifications prennent moins d’une heure. Tester son site sur SSL Labs — l’outil note la configuration TLS de A+ à F. Viser au moins A. Auditer le code du site pour la fonction de hachage des mots de passe — chercher MD5, SHA1, SHA256 sans sel ou itération, et remplacer par bcrypt ou argon2. Vérifier que les serveurs n’acceptent plus l’authentification SSH par mot de passe (PasswordAuthentication no dans /etc/ssh/sshd_config). Activer le chiffrement de disque sur les laptops de l’équipe. Auditer les dépôts Git pour les secrets éventuellement committés (git-secrets, truffleHog, gitleaks).
Les outils à connaître
| Besoin | Outil | Plateforme |
|---|---|---|
| HTTPS automatisé | Certbot + Let’s Encrypt | Linux serveur |
| Hash mot de passe | bcrypt, argon2 (lib langage) | Tous |
| SSH clé publique | ssh-keygen + OpenSSH | Tous |
| Chiffrer fichier | GPG ou age | Tous |
| Chiffrer disque | BitLocker, FileVault, LUKS, VeraCrypt | Selon OS |
| Stocker secrets | HashiCorp Vault, Bitwarden, KeePass | Tous |
| Auditer dépôt | gitleaks, truffleHog | Tous |
| Tester TLS | SSL Labs, testssl.sh | Web ou Linux |
Cryptographie sur VPS abordable et fibre Sonatel
Trois ajustements à connaître pour appliquer la cryptographie en pratique sous nos latitudes. Les certificats Let’s Encrypt fonctionnent partout, y compris sur les domaines en .sn, .ci, .bf, .ml — pas de blocage régional, le challenge HTTP-01 valide sans difficulté particulière. Les fournisseurs cloud locaux (Sonatel Cloud, Hosteur, Senercloud) supportent désormais TLS automatique sur leurs offres mutualisées — vérifier l’option avant achat car certaines offres bas de gamme imposent encore un certificat tiers. Et les obligations légales de la CDP au Sénégal et équivalents régionaux imposent une protection raisonnable des données personnelles, ce qui inclut le chiffrement des sauvegardes contenant des données identifiantes — un audit rapide vaut mieux qu’une amende, particulièrement depuis la montée en activité des autorités de contrôle dans la sous-région.
Questions fréquentes
Faut-il payer un certificat SSL ?
Non, sauf cas spécifiques. Let’s Encrypt délivre des certificats Domain Validation (DV) gratuits, suffisants pour 99 % des sites. Les certificats payants (Extended Validation, Organization Validation) ajoutent une vérification d’identité de l’organisation — utile pour des sites bancaires, e-commerce haut de gamme, ou services réglementés.
bcrypt ou argon2 pour un nouveau projet ?
argon2 si la bibliothèque est facilement disponible dans le langage utilisé — c’est la recommandation 2026 de l’OWASP. bcrypt si argon2 n’est pas disponible ou si la base de code est ancienne. Les deux sont acceptables ; ne pas perdre de temps à migrer une application bcrypt fonctionnelle vers argon2 sans raison forte.
Une phrase secrète vaut-elle une clé SSH ?
Non. Une phrase secrète, même longue, reste devinable par dictionnaire ou force brute distribuée. Une clé SSH ed25519 a une entropie de 256 bits, qu’aucune attaque par force brute ne peut casser. La phrase secrète qui protège la clé SSH locale est un complément, pas un substitut.
VeraCrypt ou BitLocker ?
BitLocker si on est sur Windows Pro et qu’on accepte un outil propriétaire Microsoft — intégration parfaite, performances optimales. VeraCrypt si on veut un outil open-source auditable, ou si on est sur Windows Home (où BitLocker n’existe pas), ou si on a besoin de transporter des conteneurs chiffrés entre Windows, macOS et Linux. Les deux sont sécurisés.
Comment stocker une clé privée SSH en sécurité ?
Sur le poste local, dans le dossier ~/.ssh/ avec permissions 600. Protégée par une phrase secrète robuste, déverrouillée à la session via ssh-agent. Pour les sauvegardes, dans un coffre Cryptomator ou Bitwarden — jamais en clair sur un disque partagé ou un cloud non chiffré.
Pour aller plus loin
- OWASP Top 10 — vulnérabilités web les plus fréquentes
- OWASP Password Storage Cheat Sheet
- ANSSI RGS — recommandations cryptographiques
Sources et références
- Let’s Encrypt — autorité de certification gratuite
- NIST Computer Security Resource Center — standards cryptographiques
- OpenSSH et GnuPG
- VeraCrypt — site officiel
- SSL Labs — test de configuration TLS