ITSkillsCenter
Blog

Pourquoi Redis pour une PME africaine

12 min de lecture

Ce que vous saurez faire à la fin

  1. Installer Redis 7 sur Ubuntu Server ou Docker en moins de 10 minutes et le sécuriser pour la production.
  2. Utiliser Redis comme cache applicatif pour accélérer un site WordPress, Laravel ou Django de 5x à 20x.
  3. Mettre en place un message broker simple avec Pub/Sub et Streams pour découpler vos services.
  4. Maîtriser les structures de données Redis : strings, hashes, lists, sets, sorted sets et leurs cas d’usage métier.
  5. Configurer la persistance, les sauvegardes RDB/AOF et superviser un Redis en production sénégalaise.

Durée : 3h. Pré-requis : serveur Ubuntu 22.04 LTS ou Docker installé, 1 Go RAM minimum, terminal SSH, notions de base de programmation (Node.js, Python ou PHP), budget total : 0 à 3 000 FCFA/mois.

Étape 1 — Pourquoi Redis pour une PME africaine

Redis est une base de données en mémoire ultra-rapide (100 000+ opérations/seconde sur un VPS modeste) qui résout 5 problèmes courants : sessions utilisateurs partagées entre serveurs, cache de pages WordPress, file d’attente de tâches lourdes (envoi SMS, génération PDF), classements en temps réel (top vendeurs, leaderboard), messagerie pub/sub entre microservices.

Pour une boutique e-commerce dakaroise avec 10 000 visites/jour, ajouter Redis devant la base de données fait passer le temps de chargement de 2,8 s à 0,4 s, et permet d’absorber un pic Black Friday sans changer de serveur. Coût : 0 FCFA en logiciel, quelques heures de configuration.

Étape 2 — Installer Redis 7 sur Ubuntu

# Ajouter le repository officiel Redis
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list

# Installer
sudo apt update
sudo apt install -y redis

# Démarrer et activer au boot
sudo systemctl start redis-server
sudo systemctl enable redis-server

# Vérifier
redis-cli ping
# Réponse attendue : PONG

redis-cli INFO server | grep redis_version

Redis écoute par défaut sur 127.0.0.1:6379. Le fichier de configuration est /etc/redis/redis.conf. Les données par défaut sont dans /var/lib/redis. Une installation standard occupe 50 Mo et démarre en moins de 2 secondes.

Étape 3 — Alternative Docker (idéal pour dev)

# Lancer Redis en container Docker
docker run -d \
    --name redis-pme \
    -p 6379:6379 \
    -v redis-data:/data \
    --restart unless-stopped \
    redis:7-alpine \
    redis-server --requirepass "MotDePasseRedisFort2026!" --appendonly yes

# Tester
docker exec -it redis-pme redis-cli -a MotDePasseRedisFort2026! ping

# Variante avec docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: "3.8"
services:
  redis:
    image: redis:7-alpine
    restart: unless-stopped
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - redis-data:/data
    command: redis-server --requirepass MotDePasseRedisFort2026 --appendonly yes
volumes:
  redis-data:
EOF

docker compose up -d

Docker simplifie l’isolation et la mise à jour. Pour la production sur un VPS dédié, l’installation directe via apt reste plus performante (moins de couches). Pour le développement local sur Windows ou Mac, Docker est l’option la plus simple.

Étape 4 — Sécuriser Redis

sudo nano /etc/redis/redis.conf

# Définir un mot de passe (chercher requirepass)
requirepass MotDePasseRedisTresFort2026!

# Lier seulement à localhost (déjà par défaut)
bind 127.0.0.1 -::1

# Désactiver les commandes dangereuses en production
rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command CONFIG "CONFIG_X9z2"
rename-command DEBUG ""

# Activer le mode protégé
protected-mode yes

# Limiter la mémoire pour éviter OOM kill
maxmemory 768mb
maxmemory-policy allkeys-lru

# Redémarrer
sudo systemctl restart redis-server

# Tester avec mot de passe
redis-cli -a MotDePasseRedisTresFort2026! ping

Plus de 60% des serveurs Redis exposés sur Internet ont été infectés par des malwares de cryptominage en 2023. Ne jamais ouvrir le port 6379 publiquement. Utilisez SSH tunnel ou VPN pour les accès distants.

Étape 5 — Strings : le type le plus simple

redis-cli -a votre_password

# SET / GET basique
SET pme:nom "ITSkillsCenter Dakar"
GET pme:nom

# Avec expiration en secondes (cache classique)
SET session:user:42 "{\"nom\":\"Mamadou\",\"role\":\"admin\"}" EX 3600
GET session:user:42
TTL session:user:42

# Compteur atomique (inscrit-vues, likes, panier)
SET visites:page:accueil 0
INCR visites:page:accueil
INCR visites:page:accueil
INCRBY visites:page:accueil 10
GET visites:page:accueil
# Réponse : 12

# DECR pour décrémenter
DECR stock:produit:samsung-a15

# SETNX : ne définit que si la clé n'existe pas (lock simple)
SETNX lock:facture:001 "processus_paiement"
EXPIRE lock:facture:001 30

Convention de nommage des clés : utilisez « : » comme séparateur (objet:champ:id). Cette convention est universelle dans la communauté Redis et facilite l’organisation. Évitez les clés de plus de 100 caractères.

Étape 6 — Hashes : objets structurés

# Stocker un client comme un hash
HSET client:1001 nom "Aïssatou Ndiaye" \
    telephone "+221771234567" \
    ville "Dakar" \
    inscription "2026-01-15"

# Lire un champ
HGET client:1001 telephone

# Lire tous les champs
HGETALL client:1001

# Lire plusieurs champs
HMGET client:1001 nom ville

# Incrémenter un champ numérique
HSET client:1001 commandes 0
HINCRBY client:1001 commandes 1
HINCRBY client:1001 commandes 5

# Vérifier l'existence d'un champ
HEXISTS client:1001 email
HSET client:1001 email "a.ndiaye@gmail.com"

# Supprimer un champ
HDEL client:1001 telephone

# Lister tous les champs et leurs longueurs
HKEYS client:1001
HLEN client:1001

Les Hashes sont parfaits pour stocker des objets dont vous mettez à jour quelques champs souvent. Plus efficace en mémoire qu’un JSON sérialisé en string : 30% à 50% d’économie pour des objets de 5+ champs.

Étape 7 — Lists : files d’attente FIFO

# File d'attente d'envoi de SMS
LPUSH queue:sms "{\"to\":\"+221771234567\",\"msg\":\"Confirmation commande #1234\"}"
LPUSH queue:sms "{\"to\":\"+221761234567\",\"msg\":\"Code OTP : 4582\"}"
LPUSH queue:sms "{\"to\":\"+221331111111\",\"msg\":\"Bienvenue sur notre boutique\"}"

# Worker qui consomme un message à la fois (bloquant 30s max)
BRPOP queue:sms 30
# Le worker récupère le plus ancien et le retire

# Voir la longueur de la file
LLEN queue:sms

# Voir les 10 prochains messages sans les retirer
LRANGE queue:sms 0 9

# Lists comme historique de navigation (10 dernières pages vues)
LPUSH historique:user:42 "/produits/samsung-a15"
LPUSH historique:user:42 "/promotions"
LPUSH historique:user:42 "/panier"
LTRIM historique:user:42 0 9   # garde uniquement les 10 plus récentes
LRANGE historique:user:42 0 -1

Pattern producer/consumer : LPUSH ajoute en tête, BRPOP retire de la queue en bloquant. Plusieurs workers peuvent consommer en parallèle, chaque message n’est traité qu’une seule fois. Idéal pour : envoi SMS Orange Money, génération PDF factures, redimensionnement images.

Étape 8 — Sets : ensembles uniques

# Tags d'un article de blog
SADD article:42:tags "wordpress" "performance" "afrique" "tutoriel"
SMEMBERS article:42:tags

# Vérifier l'appartenance
SISMEMBER article:42:tags "wordpress"

# Compter
SCARD article:42:tags

# Catégories suivies par un utilisateur
SADD user:101:categories "smartphone" "ordinateur" "accessoire"
SADD user:102:categories "smartphone" "tissu" "alimentaire"

# Intersection : centres d'intérêt communs
SINTER user:101:categories user:102:categories
# Réponse : "smartphone"

# Union : toutes les catégories des deux
SUNION user:101:categories user:102:categories

# Différence
SDIFF user:101:categories user:102:categories

# Visiteurs uniques d'une page (efficace pour millions)
SADD visiteurs:page:accueil:20260423 "ip:41.82.12.5"
SADD visiteurs:page:accueil:20260423 "ip:154.121.5.8"
SCARD visiteurs:page:accueil:20260423

Sets sont parfaits pour : tags articles, droits utilisateur, visiteurs uniques, déduplication. SADD est idempotent (ajouter deux fois le même élément ne fait rien). Le coût mémoire est de 80 octets par élément en moyenne.

Étape 9 — Sorted Sets : classements et leaderboards

# Top vendeurs avec score = chiffre d'affaires
ZADD vendeurs:ca:202604 250000 "Boutique Touba" \
    180000 "Marché Sandaga" \
    420000 "Plateau Tech" \
    95000 "Pikine Mode"

# Top 3 vendeurs (ordre décroissant)
ZREVRANGE vendeurs:ca:202604 0 2 WITHSCORES

# Position d'un vendeur dans le classement
ZREVRANK vendeurs:ca:202604 "Boutique Touba"

# Score d'un vendeur
ZSCORE vendeurs:ca:202604 "Boutique Touba"

# Incrémenter le score (nouvelle vente)
ZINCRBY vendeurs:ca:202604 35000 "Boutique Touba"

# Vendeurs avec CA entre 100 000 et 300 000
ZRANGEBYSCORE vendeurs:ca:202604 100000 300000 WITHSCORES

# Trending : score = nb de likes dans les dernières 24h
ZADD trending:articles 0 "article:42"
ZINCRBY trending:articles 1 "article:42"   # à chaque like

# Top 10 trending
ZREVRANGE trending:articles 0 9 WITHSCORES

Sorted Sets sont la structure secrète qui permet à Twitter, Instagram et TikTok d’afficher leurs trending topics en temps réel. Pour une PME, idéal pour : top produits, classement vendeurs, leaderboard de jeu, articles populaires.

Étape 10 — Cache pattern dans une application

# Python avec redis-py
# pip install redis

import redis
import json
import psycopg2

cache = redis.Redis(host='localhost', port=6379,
                    password='votre_password', decode_responses=True)

def get_produit(produit_id):
    cache_key = f"produit:{produit_id}"

    # 1. Tenter le cache
    cached = cache.get(cache_key)
    if cached:
        return json.loads(cached)

    # 2. Aller en base si miss
    conn = psycopg2.connect("dbname=pme user=app password=...")
    cur = conn.cursor()
    cur.execute("SELECT id, nom, prix FROM produits WHERE id = %s", (produit_id,))
    row = cur.fetchone()
    cur.close(); conn.close()

    if row is None:
        return None

    produit = {"id": row[0], "nom": row[1], "prix": float(row[2])}

    # 3. Mettre en cache pour 1 heure
    cache.setex(cache_key, 3600, json.dumps(produit))
    return produit

# Invalidation : quand un produit est modifié
def update_prix(produit_id, nouveau_prix):
    # ... mise à jour SQL ...
    cache.delete(f"produit:{produit_id}")

Pattern « cache-aside » : on tente le cache, on tombe en base si miss, on réécrit le cache. La règle d’or : invalider le cache au moment de la modification, pas après. Sinon vous servez des données obsolètes.

Étape 11 — Pub/Sub pour notifications temps réel

// Node.js : npm install ioredis

const Redis = require('ioredis')

// Subscriber : écoute les messages
const sub = new Redis({password: 'votre_password'})

sub.subscribe('notifications:dakar', 'commandes:nouvelles', (err) => {
    if (err) console.error(err)
    else console.log('Subscribed to channels')
})

sub.on('message', (channel, message) => {
    console.log(`[${channel}] ${message}`)
    // Pousser via WebSocket vers le navigateur, etc.
})

// Publisher : un autre processus émet
const pub = new Redis({password: 'votre_password'})

pub.publish('notifications:dakar',
    JSON.stringify({type: 'panne_courant', quartier: 'Plateau'}))

pub.publish('commandes:nouvelles',
    JSON.stringify({id: 5821, montant: 45000, client: 'Mamadou'}))

Pub/Sub est « fire and forget » : si aucun subscriber n’écoute au moment du publish, le message est perdu. Pour une livraison garantie, utilisez Redis Streams (étape 12).

Étape 12 — Redis Streams : message broker durable

# Producer : ajouter un événement au stream
XADD events:commandes * type "creation" id "5821" montant "45000" client "Mamadou"
XADD events:commandes * type "paiement" id "5821" methode "wave"
XADD events:commandes * type "livraison" id "5821" zone "Plateau"

# Lister les 10 derniers événements
XRANGE events:commandes - + COUNT 10

# Créer un groupe de consumers
XGROUP CREATE events:commandes traitement-paiement $ MKSTREAM

# Consumer 1 du groupe lit les nouveaux messages
XREADGROUP GROUP traitement-paiement worker-1 COUNT 10 BLOCK 5000 \
    STREAMS events:commandes >

# Acquitter un message après traitement
XACK events:commandes traitement-paiement 1714912345-0

# Voir les pending (non acquittés)
XPENDING events:commandes traitement-paiement

# Information sur le stream
XINFO STREAM events:commandes

Streams (depuis Redis 5) sont l’équivalent simplifié de Kafka. Idéal pour : pipeline de paiement, notification SMS/email, audit log. Les messages sont persistés et peuvent être relus, contrairement à Pub/Sub.

Étape 13 — Persistance RDB et AOF

sudo nano /etc/redis/redis.conf

# RDB : snapshot complet périodique (par défaut)
save 3600 1     # snapshot si 1 modif en 1h
save 300 100    # snapshot si 100 modifs en 5 min
save 60 10000   # snapshot si 10000 modifs en 1 min

dbfilename dump.rdb
dir /var/lib/redis

# AOF : log de chaque commande (plus durable)
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec   # compromis perf/durabilite

# Redémarrer
sudo systemctl restart redis-server

# Forcer un snapshot manuel
redis-cli -a votre_password BGSAVE

# Vérifier la dernière sauvegarde
redis-cli -a votre_password LASTSAVE

# Sauvegarder le fichier RDB pour cron
sudo cp /var/lib/redis/dump.rdb /var/backups/redis/dump_$(date +%Y%m%d).rdb

Combinaison recommandée pour PME : RDB + AOF activés. RDB pour restauration rapide en cas de perte, AOF pour récupérer les données récentes (max 1 seconde de perte avec everysec). Coût en performance : moins de 5%.

Étape 14 — Monitoring et commandes utiles en prod

# Statistiques en temps réel
redis-cli -a password INFO stats
redis-cli -a password INFO memory
redis-cli -a password INFO replication

# Suivre les commandes en direct (attention : impact perf)
redis-cli -a password MONITOR

# Top clients connectés
redis-cli -a password CLIENT LIST

# Slow log (requêtes > 10ms par défaut)
redis-cli -a password CONFIG SET slowlog-log-slower-than 10000
redis-cli -a password SLOWLOG GET 10

# Mémoire utilisée par type de clé
redis-cli -a password --bigkeys

# Latence
redis-cli -a password --latency

# Suppression progressive d'un grand nombre de clés
redis-cli -a password --scan --pattern "session:*" | xargs redis-cli -a password DEL

# Info sur une clé spécifique
redis-cli -a password OBJECT ENCODING client:1001
redis-cli -a password MEMORY USAGE client:1001

Lancez INFO memory et –bigkeys une fois par semaine pour identifier les clés qui grossissent anormalement. Une clé hash de 10 Mo qui n’expire jamais peut faire planter Redis quand la RAM est saturée.

Erreurs fréquentes

  • Aucun mot de passe configuré : 100% des Redis exposés finissent infectés par des cryptominers en moins de 48h. requirepass est obligatoire.
  • Pas de maxmemory défini : Redis grossit jusqu’à manger toute la RAM, le serveur swap, l’application crashe. Toujours fixer maxmemory et maxmemory-policy.
  • Utiliser KEYS * en production : bloque le serveur pendant plusieurs secondes sur une grosse base. Toujours préférer SCAN itératif.
  • Oublier les TTL : sans EXPIRE, vos sessions et caches s’accumulent indéfiniment. Toutes les données temporaires doivent avoir un TTL.
  • Stocker des objets de plusieurs Mo : Redis est optimisé pour des valeurs courtes. Au-delà de 512 Ko par clé, prévoyez une autre solution.
  • Pas de persistance activée : si vous redémarrez Redis sans RDB ni AOF, vous perdez tout. Activez au moins RDB pour les caches non critiques.
  • Pub/Sub pour des messages critiques : aucune garantie de livraison. Pour les paiements, utilisez Streams ou un vrai broker comme RabbitMQ.

Checklist de mise en production

  • Redis 7 installé via repository officiel ou Docker avec image alpine
  • requirepass défini avec mot de passe fort de 24+ caractères
  • bind 127.0.0.1 ou IP privée, jamais 0.0.0.0
  • protected-mode yes activé
  • Commandes dangereuses renommées (FLUSHDB, FLUSHALL, CONFIG)
  • maxmemory défini (75% de la RAM disponible)
  • maxmemory-policy adapté : allkeys-lru pour cache, noeviction pour broker
  • Persistance activée : RDB + AOF avec everysec
  • Sauvegarde quotidienne du dump.rdb vers stockage offsite
  • Convention de nommage des clés respectée (ex: objet:id:champ)
  • TTL systématique sur les sessions et caches temporaires
  • Slowlog activé avec seuil 10 ms pour détecter les requêtes lentes
  • Monitoring INFO et –bigkeys planifiés en hebdomadaire
  • Pool de connexions configuré côté application (jamais 1 connexion par requête)
#audited
Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité

Articles Similaires