J’ai perdu l’outil de capture d’écran que j’utilisais jusqu’ici, pratique au quotidien. Je me suis tournée vers ShareX, un logiciel gratuit et open source pour Windows, riche en fonctionnalités.
Pourquoi ShareX
ShareX permet de capturer une zone d’écran, de l’annoter directement, puis de la copier ou de l’enregistrer. Il propose beaucoup plus de possibilités qu’un simple outil de capture basique, notamment un éditeur d’annotation complet. Voir toutes les possibilités sur le site : https://getsharex.com/
Le raccourci de capture
J’utilise le raccourci prédéfini Ctrl + Impr écran pour lancer une capture de zone.
Configurer les tâches après la capture
Par défaut, ShareX propose plusieurs actions automatiques une fois la capture réalisée. Dans le menu « Tâches après la capture », seules « Copier l’image dans le presse-papier » et « Enregistrer l’image comme fichier » étaient cochées.
J’ai ajouté l’option « Afficher le menu des tâches rapides ». Elle ouvre l’éditeur d’annotation juste après la capture, avant toute copie ou sauvegarde. Cela permet d’annoter l’image immédiatement, ce qui est très utile pour expliquer une manipulation ou pointer un élément précis à l’écran.
Les outils d’annotation
L’éditeur intégré propose de nombreux outils de dessin. Sur l’exemple ci-dessous, on retrouve :
Flèche, pour pointer un élément précis
Forme, ici un rectangle, pour encadrer une zone
Trait libre, pour dessiner à main levée
Surligner, pour mettre en évidence du texte ou une zone
Pixeliser une zone, combiné ici avec une boîte de texte et un émoticône, pour flouter une information tout en la commentant
En résumé
ShareX est un outil complet, gratuit, qui va bien au-delà de la simple capture d’écran. L’ajout du menu de tâches rapides après la capture m’a fait gagner du confort : je peux annoter à chaud, sans étape supplémentaire.
Tu synchronises déjà tes fichiers en temps réel entre plusieurs appareils, mais une synchronisation n’est pas une sauvegarde : une erreur ou une suppression accidentelle se propage aussi vite que le reste. Voici comment mettre en place une sauvegarde périodique automatisée d’un service cloud vers un autre, avec un script simple et fiable.
y, puis saisis le mot de passe Nextcloud (il sera masqué et stocké de façon obscurcie dans rclone.conf, pas en clair)
bearer_token>
Laisse vide, valide
Edit advanced config?
n
Keep this remote?
y
q) Quit config
q
Pour vérifier que c’est ok :
rclone lsd nextcloud:OBSIDIAN-sync
Tu dois voir le contenu de ton dossier OBSIDIAN-sync dans Nextcloud.
Étape 2 : configurer un remote vers la destination, limité à un dossier particulier
Par prudence, plutôt que de donner à rclone un accès à l’intégralité de ton espace de stockage de destination, il est possible de limiter un remote à un seul dossier, appelons le « folder », grâce à son identifiant unique.
Récupérer l’identifiant du dossier
Ouvre le dossier cible dans Google Drive, depuis un navigateur
Copie la chaîne de caractères qui suit folders/ dans l’URL, par exemple :
Choisis de créer un nouveau remote « gdrive-scope », sélectionne drive comme type de stockage, laisse les champs client_id et client_secret vides (valeurs par défaut), puis, à l’étape des réglages avancés (réponds y à la question Edit advanced config?), renseigne le champ root_folder_id avec l’identifiant récupéré à l’étape précédente.
Autoriser l’accès sans navigateur local (connexion SSH)
Si tu configures ce remote depuis une session SSH sans interface graphique, l’assistant propose une autorisation manuelle : il faut alors lancer rclone authorize "drive" sur une machine disposant d’un navigateur, se connecter avec le compte Google concerné, puis copier le jeton généré dans le terminal SSH en attente.
Vérifier l’accès
bash
rclone lsd gdrive-scope:
Cette commande devrait lister directement le contenu du dossier ciblé, sans que tu aies besoin de préciser de chemin.
Étape 3 : le script de sauvegarde
Le script copie le contenu source dans un dossier temporaire, le compresse en une seule archive, puis envoie cette archive vers la destination. Il prend en paramètre le nom du sous-dossier à sauvegarder, ce qui permet de le réutiliser pour plusieurs contenus différents avec une seule et même logique. En cas de besoin, l’archive se décompresse normalement pour retrouver les fichiers d’origine.
Attention, il faudra que tu modifies SOURCE_REMOTE (nextcloud:chemin-source/) et DEST_REMOTE (gdrive-scope:destination/) et tu remplaces USER par ton nom d’utilisateur dans le mini PC
#!/bin/bash
# Sauvegarde d'un dossier source (cloud A) vers un dossier destination (cloud B)
# Usage : backup-cloud-to-cloud.sh <nom-du-dossier>
# Exemple : backup-cloud-to-cloud.sh mon-dossier
set -e
FOLDER_NAME="$1"
if [ -z "$FOLDER_NAME" ]; then
echo "Erreur : nom du dossier manquant. Usage : backup-cloud-to-cloud.sh <nom-du-dossier>"
exit 1
fi
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
TMP_BASE="/home/USER/tmp/cloud-backup"
TMP_DIR="${TMP_BASE}/${FOLDER_NAME}"
ARCHIVE_NAME="${FOLDER_NAME}_${TIMESTAMP}.tar.gz"
ARCHIVE_PATH="${TMP_BASE}/${ARCHIVE_NAME}"
SOURCE_REMOTE="nextcloud:chemin-source/${FOLDER_NAME}"
DEST_REMOTE="gdrive-scope:destination/${FOLDER_NAME}/"
echo "=== Sauvegarde ${FOLDER_NAME} - $(date) ==="
# Nettoyage préalable au cas où une exécution précédente aurait échoué
rm -rf "$TMP_DIR"
mkdir -p "$TMP_DIR"
# Copie depuis le cloud source vers un dossier temporaire local
echo "Copie depuis la source..."
rclone copy "$SOURCE_REMOTE" "$TMP_DIR" --transfers 4 --checkers 8 --fast-list
# Compression en une seule archive
echo "Compression..."
tar -czf "$ARCHIVE_PATH" -C "$TMP_BASE" "$FOLDER_NAME"
# Upload de l'archive unique vers la destination
echo "Upload vers la destination..."
rclone copy "$ARCHIVE_PATH" "$DEST_REMOTE" --transfers 1
# Nettoyage
rm -rf "$TMP_DIR"
rm -f "$ARCHIVE_PATH"
echo "=== Terminé - $(date) ==="
Si ce script tourne sur une machine où tu utilises sudo pour d’autres tâches, ne l’utilise jamais avec rclone. La commande sudo rclone réécrit le fichier de configuration rclone.conf avec les droits root lors du renouvellement d’un jeton d’accès, ce qui casse ensuite l’utilisation normale de rclone en tant qu’utilisateur courant. Seule une éventuelle commande tar nécessitant des droits élevés (rare dans ce cas précis, puisque le script travaille dans le dossier personnel de l’utilisateur) justifierait sudo, jamais rclone lui-même.
Étape 4 : planifier avec cron
Pour une sauvegarde hebdomadaire, chaque dimanche à 4h du matin :
La fréquence gagne à être adaptée à la criticité du contenu : un document en cours d’écriture active justifie un rythme hebdomadaire, un dossier de veille alimenté plus occasionnellement peut se contenter d’un rythme mensuel.
Assure-toi que le dossier de logs existe avant la première exécution planifiée :
bash
mkdir -p /home/USER/scripts/logs
Étape 5 : tester avant de laisser cron s’en charger
Un test manuel permet de vérifier le bon fonctionnement avant de dépendre entièrement de la planification automatique :
Vérifie ensuite, dans l’interface web du service de destination, que l’archive est bien apparue au bon endroit, avec un nom cohérent incluant l’horodatage.
Ce que ce schéma permet au-delà de ce cas précis
Ce principe (remote limité à un dossier, compression en une seule archive, upload unique, planification cron) se réutilise pour n’importe quelle paire de services cloud supportés par rclone, pas seulement Nextcloud vers Google Drive. C’est un schéma générique de sauvegarde périodique, applicable à d’autres contenus que des notes ou des documents.
Pour aller plus loin
Si ce projet t’intéresse, deux articles complémentaires détaillent la suite :
Tu veux consulter et modifier ton coffre Obsidian aussi bien sur ton ordinateur que sur ton téléphone, sans payer d’abonnement ni confier tes notes à un serveur tiers inconnu. Voici comment construire cette synchronisation avec un Nextcloud auto-hébergé, en évitant les pièges que j’ai moi-même rencontrés en cours de route.
Le contexte : un coffre de veille, accessible partout
Ce projet concerne un coffre Obsidian dédié à la veille professionnelle : des liens, des extraits, des notes de lecture, à consulter et enrichir aussi bien devant ton ordinateur que dans les transports avec ton téléphone. Contrairement à d’autres coffres qui restent sur PC, celui-ci a une contrainte supplémentaire : l’accès mobile est indispensable.
L’architecture retenue
Le principe : un seul mécanisme de synchronisation actif par appareil, jamais deux en parallèle sur le même dossier. C’est une règle que j’ai apprise à mes dépens en laissant tourner par erreur une synchronisation Google Drive et le plugin Remotely Save simultanément sur le même coffre, un scénario à risque de doublons et de conflits de fichiers.
Appareil
Mécanisme
PC (Windows)
Client officiel Nextcloud, synchronisation au niveau du système de fichiers
Android
Obsidian + plugin Remotely Save, connexion WebDAV directe à Nextcloud
Sur PC, Obsidian n’ouvre qu’un dossier local classique, sans aucun plugin de synchronisation. Sur mobile, Remotely Save devient nécessaire parce qu’Android ne permet pas à Obsidian d’accéder en arrière-plan à un dossier synchronisé par une autre application.
Étape 1 : installer Nextcloud Hub chez un hébergeur
La plupart des hébergeurs web proposent un installeur applicatif en un clic pour Nextcloud. Voici la démarche générale (les noms d’écran peuvent varier légèrement selon l’hébergeur) :
Dans le panneau d’administration de ton hébergement, ajoute un nouveau site
Choisis un sous-domaine dédié, par exemple cloud.tondomaine.com
Si ton nom de domaine est géré ailleurs que chez ton hébergeur (registrar différent), crée les enregistrements DNS nécessaires (type A et AAAA) pointant vers l’adresse fournie par l’hébergeur
Dans le catalogue d’applications, sélectionne Nextcloud Hub
Renseigne un nom d’utilisateur et un mot de passe administrateur robustes, à conserver dans ton gestionnaire de mots de passe
Laisse la mise à jour automatique sur « mises à jour mineures et sécurité », un bon compromis entre stabilité et protection
Une fois l’installation terminée, active un certificat HTTPS gratuit (Let’s Encrypt) pour sécuriser les échanges
Choisir un nom de sous-domaine discret
Plutôt qu’un nom explicite comme nextcloud.tondomaine.com, qui annonce directement la nature du service à quiconque le croise, un nom neutre (cloud., espace., docs.) apporte un léger renfort de sécurité par obscurité, en complément de l’authentification.
Préparer l’arborescence de dossiers
Avant de connecter quoi que ce soit, crée une arborescence dédiée dans Nextcloud, par exemple un dossier parent OBSIDIAN-sync contenant un sous-dossier par coffre :
/OBSIDIAN-sync/veille-2026
Ça garde tes coffres regroupés et lisibles, même si tu en ajoutes d’autres plus tard.
Étape 2 : connecter le PC via le client Nextcloud officiel
Télécharge le client officiel Nextcloud pour Windows depuis le site nextcloud.com.
À la connexion, un point de vigilance : le champ d’adresse serveur attend uniquement la racine du site, sans aucun chemin après :
https://cloud.tondomaine.com
Une fois connecté, configure la synchronisation du dossier OBSIDIAN-sync vers un dossier local dédié, par exemple D:\NextCloud\OBSIDIAN-sync. Le sous-dossier veille-2026 apparaîtra automatiquement dedans une fois la synchronisation active.
Dans Obsidian, choisis « Ouvrir un dossier existant », et pointe vers ce sous-dossier local. Répète l’opération sur chaque PC que tu utilises.
Étape 3 : connecter le téléphone avec Remotely Save
Sur Android, la logique est différente : Obsidian ne peut pas s’appuyer sur un dossier synchronisé en arrière-plan par une autre application, il faut donc un plugin de synchronisation intégré.
Installe Obsidian depuis le Play Store, crée un coffre vide
Va dans Paramètres > Plugins communautaires, recherche et installe Remotely Save, puis active-le
Dans les réglages du plugin, choisis la méthode WebDAV
Trouver l’adresse WebDAV
L’adresse WebDAV de Nextcloud suit ce format, avec ton identifiant de connexion à la fin (pas ton adresse e-mail) :
Comme ce champ ne gère qu’un seul niveau de dossier via le réglage dédié (voir plus bas), le plus simple est d’inclure le dossier parent directement dans l’adresse serveur :
Renseigne ensuite ton nom d’utilisateur et ton mot de passe Nextcloud. Si une erreur 403 apparaît lors du test de connexion, deux causes fréquentes :
L’adresse serveur ne contient pas ton identifiant, une erreur facile à faire en copiant une adresse générique
Une double authentification est activée sur ton compte Nextcloud, auquel cas il faut générer un mot de passe d’application dédié plutôt que d’utiliser ton mot de passe principal
Définir le dossier distant précis
Une fois la connexion établie, utilise le champ « Change The Remote Base Directory » pour préciser le sous-dossier exact du coffre, par exemple :
veille-2026
Ce champ n’accepte qu’un nom simple, pas un chemin avec plusieurs niveaux (le / y est refusé), d’où l’astuce d’inclure le dossier parent directement dans l’adresse serveur, comme montré plus haut.
Les réserves de sécurité à connaître sur Remotely Save
Même si Remotely Save est un choix plus rassurant que le plugin écarté au départ (pas de serveur intermédiaire propriétaire pour la connexion WebDAV, tes identifiants vont directement à ton propre Nextcloud), il mérite deux réserves.
Pas de chiffrement de bout en bout par défaut. Sans mot de passe de chiffrement configuré dans le plugin, tes notes sont stockées en clair sur le serveur Nextcloud, lisibles par quiconque y aurait un accès (administrateur du serveur, faille de sécurité éventuelle). Le protocole HTTPS protège le trajet des données, pas leur stockage.
Gestion des conflits limitée en version gratuite. Sur cette version du plugin, les seules options gratuites de résolution de conflits sont « la version la plus récente écrase l’autre » ou « la version la plus volumineuse écrase l’autre ». Il n’existe pas d’option gratuite pour créer automatiquement un fichier de conflit séparé et comparer les deux versions, cette fonctionnalité relève de l’offre payante.
Ce que ça signifie concrètement
Pour un coffre de veille, avec des liens et des notes de lecture sans caractère confidentiel, ces limites sont acceptables : la perte occasionnelle d’une modification récente en cas de conflit reste un inconvénient mineur, largement compensé par le filet de sécurité de la fonction native « Historique des fichiers » (voir plus bas).
Pour un coffre contenant des documents de travail sensibles, ces mêmes limites deviennent plus problématiques. Dans ce cas, active le chiffrement de bout en bout dans les réglages du plugin (champ « Encryption Password »), avec pour conséquence que le contenu synchronisé ne sera plus lisible directement depuis l’interface web de Nextcloud, ni exploitable tel quel par un script ou une IA sans déchiffrement préalable.
Gérer les conflits et les pertes accidentelles
En complément de Remotely Save, active la fonction native d’Obsidian, indépendante de tout cloud :
Va dans Paramètres > Modules principaux
Active « Récupération de fichier » (File Recovery)
Réduis l’intervalle de capture à environ 2 minutes
En cas de fausse manipulation ou d’écrasement par la synchronisation, retourne dans Paramètres > Historique des fichiers > Afficher pour restaurer une version locale enregistrée par Obsidian dans son propre cache, indépendamment de ce qui s’est passé côté serveur.
Pour aller plus loin
Si ce projet t’intéresse, deux articles complémentaires détaillent la suite :
L’application Google Drive pour ordinateur propose deux mécanismes de synchronisation complètement différents, logés dans le même menu. Ne pas les distinguer, c’est la garantie de ne plus rien comprendre à ce qui se synchronise, où, et pourquoi. Voici comment les différencier et les utiliser correctement.
Deux outils dans une seule application
Quand tu ouvres les préférences de Google Drive, la colonne de gauche affiche deux sections qui se ressemblent, mais qui n’ont rien à voir l’une avec l’autre.
A. « Google Drive / Mon Drive » (le mode cloud natif)
C’est l’espace central. Tout ce qui réside sur ton compte Google Web est répercuté sur ton ordinateur sous forme d’un dossier virtuel (par exemple D:\Google Drive\Mon Drive).
Usage idéal : synchroniser tes fichiers de travail entre plusieurs ordinateurs (PC fixe et PC portable).
Fonctionnement : tout ajout ou modification dans ce dossier est instantanément répercuté dans le cloud et sur tes autres appareils.
B. « Mon ordinateur » (le mode sauvegarde locale)
Cette option s’adresse à ceux qui veulent sauvegarder des dossiers existants sans changer leur arborescence Windows (par exemple le dossier Documents ou Images de Windows).
Usage idéal : créer une sauvegarde en arrière-plan d’un répertoire local spécifique.
Dans le cloud, ces dossiers n’apparaissent pas dans « Mon Drive », mais sous un onglet séparé nommé « Ordinateurs » sur le web.
L’erreur à éviter
N’utilise jamais la fonction « Ajouter un dossier » (dans la section Mon ordinateur) sur un dossier qui se trouve déjà dans ton dossier Mon Drive. Tu demanderais à Google Drive de synchroniser deux fois le même emplacement via deux circuits différents. Résultat : les deux mécanismes se marchent dessus, plus rien ne se synchronise comme prévu, et tu perds toute visibilité sur ce qui se passe réellement.
Streaming vs miroir : économiser l’espace de son disque dur
Dans la section Google Drive des préférences, tu dois choisir comment les fichiers de Mon Drive sont stockés physiquement sur ta machine.
Mode
Mise en cache et stockage
Avantages et inconvénients
Accès en ligne (streaming) – recommandé
Les fichiers restent hébergés sur le cloud. Seuls des raccourcis virtuels sont visibles dans l’Explorateur Windows.
+ Économise l’espace disque / SSD. + Ouverture transparente des fichiers à la demande. – Nécessite une connexion Internet par défaut.
Dupliquer les fichiers (miroir)
Tous les fichiers du cloud sont téléchargés et doublés en local sur ton disque dur.
+ Tous les fichiers sont accessibles hors ligne. – Saturation rapide des disques durs / SSD de petite taille.
Guide pratique : rendre des dossiers disponibles hors ligne
Le mode streaming est le plus optimisé. Si tu pars en déplacement sans connexion Internet, voici comment préparer tes dossiers :
Ouvre l’Explorateur de fichiers Windows et navigue dans ton dossier Mon Drive.
Fais un clic droit sur le dossier ou le fichier dont tu auras besoin.
L’application télécharge une copie locale sécurisée.
Une pastille verte avec une coche confirme la disponibilité hors ligne, tandis qu’une icône de nuage bleu indique un fichier stocké uniquement en ligne.
Dépannage : résoudre les blocages et icônes rouges
Si la synchronisation se bloque ou si un dossier affiche une croix rouge :
Fermer les applications : un fichier ouvert dans Word, Excel ou un lecteur PDF verrouille la synchronisation. Ferme l’application concernée.
Vérifier les caractères spéciaux : évite les caractères interdits par Windows dans les noms de fichiers (/ \ ? * : " < > |).
Réinitialisation propre : si les icônes de statut ne s’affichent plus, va dans Préférences de l’application > Paramètres > Déconnecter le compte, puis reconnecte-toi. Cela re-scanne la base de données sans retélécharger tes données déjà présentes.
Checklist récapitulative
Un seul point d’entrée : travaille exclusivement dans le dossier Mon Drive.
Espace disque : active le mode streaming pour ne pas surcharger ton SSD.
Déplacements : utilise le clic droit « Disponible hors connexion » de manière ciblée.
Sécurité : laisse la section « Mon ordinateur » vide, sauf besoin explicite de sauvegarde locale.
Une sauvegarde nocturne qui tournait en quelques minutes s’est mise à durer plus de 7 heures, avec des erreurs de quota Google. Voici le diagnostic et la correction : remplacer des milliers de petits fichiers par une seule archive compressée.
La sauvegarde nocturne d’un dossier Docker (une dizaine de containers, environ 1,9 Go au total) copiait chaque nuit l’intégralité du dossier vers Google Drive, avec une rétention GFS (Grand-Père / Père / Fils, une stratégie classique qui conserve des sauvegardes quotidiennes, hebdomadaires, mensuelles et annuelles). Cette sauvegarde aurait dû se faire en quelques minutes. Un jour, elle a mis plus de 7 heures à se terminer, sans plantage visible, juste un processus qui semblait ne plus avancer.
Diagnostiquer un dépassement de quota API
Premier réflexe : regarder le fichier de log. Il s’arrêtait net, sans nouvelle ligne depuis des heures. Le processus rclone tournait pourtant toujours (ps aux | grep rclone le confirmait), mais avec un temps CPU (temps de calcul processeur réellement utilisé) dérisoire par rapport à sa durée de vie, signe qu’il passait le plus clair de son temps à attendre.
Relancer une simple commande de lecture a permis de voir l’erreur clairement :
rclone size gdrive:/daily
googleapi: Error 403: Quota exceeded for quota metric 'Queries' and limit 'Queries per minute' of service 'drive.googleapis.com'
Le quota en cause n’est pas l’espace de stockage, mais le nombre de requêtes envoyées à l’API (interface de programmation, le canal par lequel un logiciel comme rclone communique avec les serveurs de Google) Google Drive en une minute. Chaque fichier transféré, vérifié ou supprimé individuellement génère plusieurs requêtes. Un compte pour voir venir le problème :
find /home/USER/docker -type f | wc -l
Résultat : plus de 10 000 fichiers, dans un seul dossier quotidien. Multiplié par une rétention de 7 jours (plus les copies hebdomadaires, mensuelles et annuelles), le script devait gérer chaque nuit plusieurs dizaines de milliers d’opérations individuelles sur l’API. Ce n’est pas le volume de données (1,9 Go, rien d’énorme) qui posait problème, c’est le nombre d’objets.
L’effet de bord du sudo sur la configuration rclone
Un deuxième problème s’est ajouté en cours de route : le fichier de configuration rclone (rclone.conf) changeait régulièrement de propriétaire, passant de l’utilisateur normal à root, ce qui bloquait toute utilisation manuelle de rclone en dehors du script.
La cause : le script utilisait sudo rclone pour contourner des permissions sur certains fichiers Docker appartenant à root. Mais lancer rclone entièrement en root a un effet de bord : le jeton d’accès Google expire régulièrement (environ toutes les heures), et rclone le renouvelle automatiquement en réécrivant le fichier de configuration. Réécrit par un processus root, ce fichier devient la propriété de root, et l’utilisateur normal perd l’accès à sa propre configuration.
La correction : ne plus jamais faire tourner rclone lui-même avec sudo. Seule la commande qui a besoin de lire les fichiers appartenant à root (tar, dans la solution ci-dessous) utilise sudo, sans aucun rapport avec la configuration rclone.
La solution : une archive compressée plutôt que des milliers de fichiers
Plutôt que de copier des milliers de fichiers un par un, le script compresse désormais l’intégralité du dossier en une seule archive avant l’envoi. Une archive à transférer, c’est une poignée de requêtes API au lieu de dizaines de milliers.
La logique GFS reste identique, mais la rotation hebdomadaire, mensuelle et annuelle se fait par copie du fichier archive directement entre deux emplacements sur Google Drive (côté serveur, sans repasser par le Mini PC), plutôt que par un nouveau balayage de milliers de fichiers.
Le nettoyage des sauvegardes obsolètes change aussi de nature : supprimer un fichier unique par jour dépassé, au lieu de parcourir et supprimer des milliers de fichiers individuellement.
Le script complet
#!/bin/bash
# ═══════════════════════════════════════════════════════════════
# backup-docker.sh — Sauvegarde Docker vers Google Drive
# v5 - archive unique compressée (fin du problème de quota API)
# export automatique des YAML depuis l'API Portainer
# ═══════════════════════════════════════════════════════════════
# -- Configuration ────────────────────────────────────────────────
SOURCE="/home/USER/docker"
REMOTE="gdrive:"
LOG="/home/USER/rclone-logs/backup-docker.log"
RCLONE_CONF="/home/USER/.config/rclone/rclone.conf"
PORTAINER_URL="https://192.168.1.100:9443"
PORTAINER_TOKEN=$(cat /home/USER/docker/scripts/.portainer-token)
DATE=$(date +%Y-%m-%d)
DAY=$(date +%u) # 1=lundi ... 7=dimanche
DOM=$(date +%d) # jour du mois (01-31)
MONTH=$(date +%m) # mois (01-12)
ARCHIVE_NAME="docker-$DATE.tar.gz"
TMP_ARCHIVE="/tmp/$ARCHIVE_NAME"
# -- Création du dossier de log si nécessaire ─────────────────────
mkdir -p /home/USER/rclone-logs
# -- Fonction de log ──────────────────────────────────────────────
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG"
}
# -- Commande rclone de base ──────────────────────────────────────
# Important : plus de sudo ici. rclone tourne toujours en tant que
# l'utilisateur normal, son fichier de config n'est donc plus
# jamais réécrit par root. Seul tar (plus bas) a besoin de sudo
# pour lire les fichiers appartenant à root dans les volumes
# Docker.
RCLONE="rclone --config $RCLONE_CONF --log-file=$LOG"
log "=== Début sauvegarde ==="
# -- Export automatique des YAML (format de fichier de configuration
# lisible, utilisé par Docker Compose) depuis l'API Portainer ─────
log "Export des YAML depuis Portainer..."
STACKS_JSON=$(curl -sk \
-H "X-API-Key: $PORTAINER_TOKEN" \
"$PORTAINER_URL/api/stacks")
if [ -z "$STACKS_JSON" ] || [ "$STACKS_JSON" = "null" ]; then
log "ERREUR : impossible de contacter l'API Portainer - les YAML ne seront pas mis à jour."
else
STACK_COUNT=$(echo "$STACKS_JSON" | python3 -c "
import sys, json
stacks = json.load(sys.stdin)
print(len(stacks))
" 2>/dev/null)
log "$STACK_COUNT stack(s) trouvée(s) dans Portainer."
echo "$STACKS_JSON" | python3 -c "
import sys, json
stacks = json.load(sys.stdin)
for s in stacks:
print(s['Id'], s['Name'])
" 2>/dev/null | while read stack_id stack_name; do
YAML_CONTENT=$(curl -sk \
-H "X-API-Key: $PORTAINER_TOKEN" \
"$PORTAINER_URL/api/stacks/$stack_id/file" \
| python3 -c "
import sys, json
data = json.load(sys.stdin)
print(data.get('StackFileContent', ''))
" 2>/dev/null)
if [ -n "$YAML_CONTENT" ]; then
DEST="$SOURCE/$stack_name/docker-compose.yml"
mkdir -p "$SOURCE/$stack_name"
echo "$YAML_CONTENT" > "$DEST"
log "YAML exporté : $stack_name/docker-compose.yml"
else
log "ATTENTION : YAML vide ou inaccessible pour la stack $stack_name"
fi
done
fi
# -- Vérification des docker-compose.yml manquants ────────────────
# Seuls les containers gérés comme des stacks Portainer ont un
# docker-compose.yml généré automatiquement ci-dessus. Certains
# dossiers ne sont pas des containers et doivent être exclus de
# cette vérification.
log "Vérification des docker-compose.yml..."
for dir in "$SOURCE"/*/; do
logiciel=$(basename "$dir")
# "scripts" : pas un container Docker
# à adapter : tout dossier qui n'est pas une stack Portainer
# (par exemple un environnement virtuel Python) doit être
# ajouté ici pour éviter une fausse alerte à chaque exécution
if [ "$logiciel" = "scripts" ]; then
continue
fi
compose="$dir/docker-compose.yml"
if [ ! -f "$compose" ]; then
log "ATTENTION : docker-compose.yml manquant dans $logiciel - à créer manuellement !"
fi
done
# -- Création de l'archive compressée ─────────────────────────────
# sudo est nécessaire ici car certains fichiers dans les volumes
# Docker appartiennent à root. tar n'a aucun rapport avec la config
# rclone, donc rclone.conf n'est jamais impacté par ce sudo.
log "Création de l'archive $ARCHIVE_NAME..."
sudo tar --exclude="*.db-shm" --exclude="*.db-wal" -czf "$TMP_ARCHIVE" -C "$SOURCE" .
sudo chown USER:USER "$TMP_ARCHIVE"
log "Archive créée : $(du -h "$TMP_ARCHIVE" | cut -f1)"
# -- Envoi de l'archive vers Google Drive (sauvegarde quotidienne) ─
log "Copie vers daily/..."
$RCLONE copy "$TMP_ARCHIVE" "$REMOTE/daily/"
# -- Copie hebdomadaire (chaque dimanche) ──────────────────────────
# Copie côté serveur, aucun ré-upload depuis le poste local
if [ "$DAY" -eq 7 ]; then
log "Dimanche : copie hebdomadaire"
$RCLONE copyto "$REMOTE/daily/$ARCHIVE_NAME" "$REMOTE/weekly/$ARCHIVE_NAME"
fi
# -- Copie mensuelle (le 1er de chaque mois) ───────────────────────
if [ "$DOM" -eq 01 ]; then
log "1er du mois : copie mensuelle"
$RCLONE copyto "$REMOTE/daily/$ARCHIVE_NAME" "$REMOTE/monthly/$ARCHIVE_NAME"
fi
# -- Copie annuelle (le 1er janvier) ───────────────────────────────
if [ "$DOM" -eq 01 ] && [ "$MONTH" -eq 01 ]; then
log "1er janvier : copie annuelle"
$RCLONE copyto "$REMOTE/daily/$ARCHIVE_NAME" "$REMOTE/yearly/$ARCHIVE_NAME"
fi
# -- Nettoyage du fichier temporaire local ─────────────────────────
rm -f "$TMP_ARCHIVE"
# -- Nettoyage des anciennes sauvegardes sur Drive ─────────────────
# Suppression de fichiers uniques, plus de parcours fichier par fichier
log "Nettoyage daily > 7 jours..."
$RCLONE delete "$REMOTE/daily" --min-age 7d --include "*.tar.gz"
log "Nettoyage weekly > 28 jours..."
$RCLONE delete "$REMOTE/weekly" --min-age 28d --include "*.tar.gz"
log "Nettoyage monthly > 365 jours..."
$RCLONE delete "$REMOTE/monthly" --min-age 365d --include "*.tar.gz"
# Annuelles : conservées indéfiniment, pas de nettoyage automatique
log "=== Sauvegarde terminée ==="
Résultat mesuré après cette réécriture : script complet exécuté en 8 minutes, contre plus de 7 heures avant correction.
Un point de vigilance si tu reprends ce script : les fichiers docker-compose.yml gérés par Portainer sont écrasés chaque nuit avec la version stockée dans Portainer. Toute modification doit se faire dans l’interface Portainer, jamais directement dans le fichier local, sous peine d’être effacée à la prochaine exécution.
Un point à ne pas manquer au déploiement : ce sudo tar doit être explicitement autorisé sans mot de passe, sans quoi il échoue silencieusement lorsqu’il est lancé par cron (qui n’a pas de terminal interactif pour saisir un mot de passe). L’échec ne remonte alors aucune erreur exploitable dans le log applicatif, l’archive reste simplement vide.
Plutôt que d’autoriser tar sans restriction (ce qui donnerait un accès complet en lecture et écriture à tout le système à quiconque contrôle ce compte), la règle sudoers peut être limitée à la commande exacte utilisée par le script :
Le joker (*) dans le nom de fichier autorise uniquement la variation de la date, tout le reste de la commande doit correspondre au caractère près à ce que le script envoie. Si le script évolue plus tard (nouvelle option, chemin différent), cette règle doit être mise à jour en même temps, sinon le même échec silencieux se reproduira.
Se faire alerter automatiquement avec Home Assistant
Le script écrit un journal détaillé, mais rien ne prévenait activement en cas de souci, il fallait aller consulter le fichier manuellement. Un capteur Home Assistant permet de surveiller ce journal et de déclencher une notification par email en cas d’anomalie.
Monter le dossier de logs dans le container Home Assistant, dans la section volumes du fichier de configuration de la stack (via Portainer) :
- /home/USER/rclone-logs:/rclone-logs:ro
Le :ro (lecture seule) suffit, Home Assistant n’a pas besoin d’écrire dans ce dossier.
Créer le capteur. Depuis la version 2023.8 de Home Assistant, la syntaxe sensor: - platform: command_line ne fonctionne plus, le capteur doit être déclaré sous une clé command_line: dédiée :
Ce capteur isole la dernière exécution du script (entre le dernier === Début sauvegarde === et la fin du fichier), puis renvoie soit le nombre de lignes d’alerte ou d’erreur trouvées, soit 99 si la ligne === Sauvegarde terminée === est absente, ce qui signale un script resté bloqué ou interrompu avant la fin.
Un piège à connaître sur cette commande : grep -c compte des lignes, mais son code de sortie (au sens Unix, pas sa sortie affichée) vaut 1 dès que ce compte est à zéro, 0 seulement s’il trouve au moins une ligne. L’intégration command_line traite tout code de sortie différent de zéro comme un échec de la commande, et dans ce cas, elle n’écrit jamais la valeur dans le capteur. Résultat contre-intuitif : le capteur reste bloqué sur unknown précisément quand tout va bien (zéro anomalie trouvée). La solution, déjà intégrée ci-dessus, consiste à isoler le comptage dans une variable puis à l’afficher avec un echo séparé, qui réussit toujours quel que soit le chiffre affiché.
Créer l’automatisation qui envoie l’alerte par email :
automation:
- alias: "Alerte anomalie sauvegarde Docker"
id: alerte_anomalie_sauvegarde_docker
trigger:
- platform: time
at: "03:30:00"
condition:
- condition: numeric_state
entity_id: sensor.sauvegarde_docker_anomalies
above: 0
action:
- service: notify.email_alertes
data:
title: "[home ALD] Anomalie sauvegarde Docker"
message: >
Une anomalie a été détectée dans la sauvegarde Docker de cette nuit (code {{ states('sensor.sauvegarde_docker_anomalies') }}).
Automatisation déclenchante : automation.alerte_anomalie_sauvegarde_docker
Consulter le log complet sur le Mini PC : /home/USER/rclone-logs/backup-docker.log
Le déclenchement à 3h30 laisse une marge confortable après le lancement du script à 3h00, largement suffisante avec un temps d’exécution ramené à quelques minutes.
Attention si tu ajoutes une automatisation dans un fichier automations.yaml existant : chaque automatisation est un élément de liste, le tiret - qui la démarre doit être collé à gauche, sans indentation, sous peine d’erreur de chargement.
Tu veux migrer un compte Dropbox vers Google Drive avec rclone, et le transfert stagne à quelques centaines de kilo-octets par seconde alors que ta connexion tient des centaines de mégabits. Voici ce qu’on a découvert en cherchant pourquoi, et la méthode qui a fini par fonctionner.
Précision : migration réalisée avec l’aide de Claude.ai et parfois Gemini aussi. Cet article a été préparé par Claude.ai sur la base des essais que j’ai réalisé et de ce qui a fonctionné.
Le symptôme
J’ai d’abord essayé sur un dossier Dropbox Pilote, appelé « A-TRANSFERER ». L’idée c’était d’identifier la meilleure façon de faire avec un « petit » dossier avant de transférer l’ensemble de ma Dropbox (quelques centaines de giga-octets). Et tout de suite l’essai s’est heurté à des difficultés.
le problème : un dossier Dropbox de plus de 50 000 fichiers à transférer vers Google Drive, pour une taille totale de quelques dizaines de giga-octets. La commande de départ, sur un petit serveur Linux (un mini PC sous Ubuntu) :
Résultat : un débit de 263 Ko/s (kilo-octets par seconde), et une estimation de temps restant (ETA, « estimated time of arrival ») de plusieurs heures pour quelques giga-octets. Un test de débit de la connexion (speedtest-cli) confirmait pourtant 397 Mbit/s en envoi (upload), soit environ 47 Mo/s. Le débit réel était donc mille fois inférieur à ce que la connexion permettait.
Les fausses pistes (et pourquoi elles n’ont pas suffi)
Augmenter le parallélisme. Première réaction logique : monter --transfers et --checkers, et supprimer la limite --tpslimit. Le débit a un peu progressé (jusqu’à 1,5 Mio/s par moments), mais restait très instable, avec des chutes à quelques kilo-octets par seconde et des ETA remontant parfois à plusieurs semaines.
--drive-chunk-size. Ce paramètre découpe les fichiers volumineux en blocs pour accélérer leur envoi vers Google Drive. Sur le papier, ça semble pertinent. En pratique, il ne s’applique qu’aux fichiers dépassant --drive-upload-cutoff (8 Mo par défaut) : en dessous, rclone envoie le fichier en un seul appel. Pour un lot de dizaines de milliers de petits fichiers (quelques centaines de kilo-octets en moyenne), ce réglage n’a strictement aucun effet.
Changer de machine pour plus de bande passante. L’hypothèse suivante : et si le goulot d’étranglement venait de la connexion du mini PC ? Un test sur Google Cloud Shell (un terminal Linux temporaire fourni gratuitement par Google, accessible depuis un navigateur) a permis de vérifier. Sur un fichier unique volumineux, le débit obtenu (1,5 Mio/s) n’était pas meilleur que ce qu’on avait déjà. La bande passante n’était donc pas non plus en cause.
Le vrai diagnostic
rclone copy entre deux services cloud distincts n’est pas un transfert serveur à serveur : chaque fichier est téléchargé depuis la source puis envoyé vers la destination, en passant par la machine qui exécute la commande. Avec des dizaines de milliers de petits fichiers, chaque aller-retour compte, et l’API de Dropbox s’est révélée nettement plus sensible à la concurrence que celle de Google Drive. Les recommandations généralement admises pour Dropbox vont d’ailleurs à l’inverse de ce qu’on avait tenté : réduire la concurrence (2 à 3 transferts, 4 vérificateurs), pas l’augmenter.
Un signal confirmait cette hypothèse : des erreurs sporadiques du type suivant, dans le journal (log) de transfert :
ERROR : chemin/vers/un/fichier: Failed to copy: failed to open source object: invalid character '<' looking for beginning of value
Cette erreur signifie que Dropbox a renvoyé une page HTML d’erreur au lieu de la réponse JSON attendue, un signe classique de sursollicitation de l’API.
La méthode qui a fonctionné : passer par un disque local
Plutôt que de faire transiter chaque fichier directement entre les deux services cloud, la solution a été de synchroniser d’abord Dropbox sur un disque dur externe (via le client Dropbox classique, sur un PC Windows ou macOS), puis de transférer ce disque vers Google Drive avec rclone, sans repasser par l’API Dropbox.
Étape 1 : synchroniser Dropbox sur un disque local
Rien de spécifique à rclone ici : il s’agit d’utiliser le client Dropbox habituel (application de bureau) pour synchroniser sélectivement les dossiers voulus sur un disque, idéalement externe pour ne pas saturer le disque principal.
Point de vigilance avant de désactiver ensuite la synchronisation Dropbox : le client Dropbox traite le contenu synchronisé comme un simple reflet du cloud. Décocher un dossier dans la synchronisation sélective supprime les fichiers correspondants en local, sans avertissement particulier. Il faut donc s’assurer que la copie de sécurité (le disque externe, dans ce cas) est bien complète et vérifiée avant de toucher à quoi que ce soit côté Dropbox.
Étape 2 : monter le disque sur le serveur Linux
lsblk
Cette commande liste les périphériques de stockage connectés, pour repérer le nouveau disque (généralement /dev/sdX, où X est une lettre).
sudo blkid /dev/sda1
Vérifie le système de fichiers du disque. Pour un disque formaté sous Windows, ce sera le plus souvent ntfs.
Si le disque n’a pas été démonté proprement avant d’être débranché (ça arrive), un message de ce type peut apparaître au montage :
The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.
Pas d’inquiétude : c’est le mécanisme de correction automatique de ntfs-3g, qui répare les petites incohérences avant de monter le disque.
Étape 3 : exclure ce qui ne doit pas partir vers le cloud
Avant de tout copier, il vaut mieux vérifier le contenu à la racine du disque. Il n’est pas rare d’y trouver des fichiers isolés qui n’ont rien à faire dans une migration cloud : mots de passe en clair, clés privées, bases de données de gestionnaire de mots de passe. Un fichier de filtre permet d’exclure ce type d’éléments proprement :
Différence notable avec la tentative initiale : la concurrence est ici volontairement élevée (12 transferts, 16 vérificateurs), parce que la destination est Google Drive, qui tolère bien mieux ce type de charge que Dropbox. Le débit obtenu avec cette méthode a dépassé 2 Mio/s en continu, contre 79 à 143 KiB/s lors des essais directs Dropbox vers Google Drive, soit un facteur supérieur à 15.
Le nohup ... & en début de commande permet de fermer la session SSH ou d’éteindre le poste depuis lequel elle a été lancée, sans interrompre le transfert sur le serveur.
--fast-list réduit fortement le nombre de requêtes nécessaires pour parcourir l’arborescence de destination, un point important : sans cette option, la vérification d’un grand nombre de dossiers peut elle-même déclencher une limitation de l’API Google (erreur 403 Quota exceeded, avec la mention RATE_LIMIT_EXCEEDED). Ce paramètre fonctionne côté Google Drive, mais pas côté Dropbox, qui ne le prend pas en charge (rclone l’ignore silencieusement s’il est utilisé sur un remote Dropbox).
Résultat attendu en cas de succès :
NOTICE: Google drive root 'NOUVEAU-DOSSIER': 0 differences found
NOTICE: Google drive root 'NOUVEAU-DOSSIER': 55653 matching files
Deux pièges annexes, utiles à connaître
Un dossier de destination qui n’est pas à la racine attendue. Si le remote gdrive: a été configuré pour un autre usage au préalable (une sauvegarde automatisée, par exemple), il peut pointer vers un sous-dossier précis plutôt que vers la racine réelle du Drive, via un paramètre caché nommé root_folder_id. Un dossier créé avec gdrive:/MonDossier peut alors atterrir plusieurs niveaux plus bas que prévu, invisible à première vue dans l’interface web. Pour vérifier :
rclone config show gdrive
La présence d’une ligne root_folder_id confirme ce comportement.
Deux configurations rclone distinctes, deux dossiers distincts. Autoriser rclone sur deux machines différentes (un serveur et Cloud Shell, par exemple) crée deux configurations indépendantes. Si elles ne pointent pas vers le même compte Google, ou si l’une a un root_folder_id différent de l’autre, un même nom de dossier de destination peut désigner deux emplacements complètement différents. Google Drive autorisant les doublons de noms, l’interface web peut alors sembler afficher un contenu incohérent selon le moment où elle est consultée. En cas de doute, mieux vaut vérifier directement avec rclone lsd et rclone size plutôt que de se fier au rendu de l’interface, qui peut aussi simplement mettre du temps à se rafraîchir.
Ce qu’on ferait différemment en repartant de zéro
Mesurer la structure du contenu avant de choisir une méthode (rclone size, rclone lsd) : beaucoup de petits fichiers oriente d’emblée vers un passage par disque local, peu de fichiers volumineux se prête bien à un transfert direct.
Vérifier le root_folder_id du remote gdrive: avant le premier transfert.
Protéger systématiquement toute commande longue avec nohup dès le premier lancement, pas après une mauvaise surprise.
Exclure les fichiers sensibles ou indésirables avant de copier, pas après avoir découvert le mélange.
Toujours vérifier avec rclone check --fast-list en fin de transfert, jamais se contenter d’une comparaison de volumes ou de comptage de fichiers.
Pour aller plus loin
Cet article fait partie de la série projets Ubuntu, qui documente les projets techniques menés sur mon infrastructure Linux personnelle.
Tu veux recevoir une alerte si une porte s’ouvre chez toi pendant ton absence, avec une photo prise automatiquement par ta caméra ? Voici comment mettre en place ce système avec Home Assistant, des capteurs Zigbee et l’application Companion sur Android.
Prérequis : Home Assistant installé et accessible depuis l’extérieur via une URL sécurisée (https), Zigbee2MQTT opérationnel, application Home Assistant Companion installée sur ton téléphone Android, service d’envoi d’email déjà configuré dans HA (voir Détecter une coupure de courant avec Home Assistant).
Les capteurs d’ouverture de porte
Les capteurs d’ouverture Zigbee doivent être appairés et visibles dans Home Assistant avant de commencer. Si ce n’est pas encore fait, consulte l’article Étendre son réseau Zigbee dans Home Assistant qui couvre l’appairage et le maillage Zigbee.
Une fois appairés, chaque capteur expose une entité de type binary_sensor dans HA. Pour retrouver leurs identifiants exacts, va dans Paramètres > Appareils et services > Entités et filtre sur « contact ». Tu obtiendras des identifiants de la forme :
Note : certains capteurs bon marché (comme les MOES ZG-1027L utilisés ici) mesurent aussi la luminosité en plus de l’ouverture. Les deux fonctions coexistent sans se gêner – l’entité contact reste bien celle qui détecte l’ouverture.
Créer le groupe de capteurs
Plutôt que de surveiller chaque capteur individuellement dans l’automatisation, on les regroupe dans un seul capteur virtuel. Ce groupe passe à « activé » dès qu’une seule porte s’ouvre, et revient à « désactivé » quand toutes sont fermées. Ajouter une nouvelle porte plus tard se résume à ajouter une ligne dans ce groupe.
Va dans Paramètres > Appareils et services > Entrées, clique sur + Créer une entrée, puis choisis Groupe > Groupe binaire.
Nom : Groupe ouvertures surveillées
Membres : ajoute tes capteurs d’ouverture
Option « Toutes les entités » : désactivée (logique « au moins un »)
Enregistre. HA crée automatiquement l’entité binary_sensor.groupe_ouvertures_surveillees.
Détecter la présence par téléphone
Créer l’entité Personne
Dans HA, va dans Paramètres > Personnes, crée une entrée pour chaque personne à suivre et associe-lui le téléphone correspondant. HA crée automatiquement une entité person.personne_1 qui passe à home ou not_home selon la position du téléphone.
Configurer l’application Companion
La détection de présence ne fonctionne correctement que si l’application est bien configurée. Deux points sont critiques.
L’URL du serveur : l’app doit pouvoir joindre HA aussi bien depuis le réseau local que depuis l’extérieur. Dans l’app, va dans ≡ > Paramètres > Companion app > Serveur et configure :
URL de Home Assistant : https://ha.ton-domaine.com (ton URL externe)
URL de connexion interne : http://192.168.x.x:8123 (l’IP locale de ton mini PC)
Si seule l’IP locale est renseignée, le téléphone perd le contact avec HA dès qu’il quitte le Wi-Fi maison et ne remonte plus aucune donnée – y compris sa position.
Les capteurs de localisation : dans ≡ > Paramètres > Companion app > Capteurs > Capteurs de localisation, active :
Localisation en arrière-plan
Zone de localisation
Sans ces deux options, HA ne reçoit aucune information de position.
Dans les paramètres Android, vérifie aussi que l’app Home Assistant dispose de la permission de localisation réglée sur « Toujours autoriser », et que l’optimisation de batterie est désactivée pour cette app.
Le capteur Wi-Fi comme filet de sécurité
La détection GPS peut être lente ou imprécise selon les conditions. On ajoute donc un deuxième critère : si le téléphone n’est plus connecté au Wi-Fi maison, on considère la personne comme absente.
L’entité à utiliser est sensor.telephone1_wi_fi_connection (remplace par l’identifiant correspondant à ton téléphone). Sa valeur est le nom du réseau Wi-Fi connecté (par exemple MON_RESEAU_WIFI) quand tu es à la maison, et <not connected> quand tu es dehors.
Pour activer ce capteur, va dans Paramètres > Appareils et services > Entités, recherche ton téléphone et active l’entité « Wi-Fi connection » si elle est désactivée.
L’automatisation
L’automatisation se déclenche quand le groupe de capteurs passe à « ouvert », à condition qu’au moins l’une des deux conditions suivantes soit vraie : person.personne_1 est not_home, ou le Wi-Fi du téléphone n’est pas le réseau maison.
Elle prend alors un snapshot de la caméra avec un nom horodaté, puis envoie un email avec la photo en pièce jointe.
Note sur la caméra : cette configuration fonctionne avec une caméra intégrée dans HA via l’intégration Tuya. Cette intégration cloud est limitée – elle ne permet pas l’enregistrement local continu ni la gestion avancée des flux vidéo. Le snapshot (photo statique au moment du déclenchement) est la seule action fiable disponible depuis HA avec ce type de caméra.
Le snapshot est sauvegardé dans le dossier /media du container Home Assistant. Ce dossier doit être mappé explicitement dans le docker-compose.yml de Portainer :
Crée le dossier sur le mini PC avant de redémarrer le container :
mkdir /home/USER/docker/home-assistant/media
Va dans Paramètres > Automatisations, clique sur + Créer une automatisation, choisis Créer une automatisation vide, puis passe en mode YAML et colle le code suivant :
alias: "[home AL] Alerte ouverture en absence"
description: >-
Alerte si une porte s'ouvre alors qu'aucune personne autorisée n'est à la
maison. Automatisation : alerte_ouverture_absence_v2
triggers:
- entity_id: binary_sensor.groupe_ouvertures_surveillees
to: "on"
trigger: state
conditions:
- condition: or
conditions:
- condition: state
entity_id: person.personne_1
state: "not_home"
- condition: not
conditions:
- condition: state
entity_id: sensor.telephone1_wi_fi_connection
state: "MON_RESEAU_WIFI"
actions:
- variables:
snapshot_file: >
/media/alerte_ouverture_{{ now().strftime('%Y%m%d_%H%M%S') }}.jpg
- action: camera.snapshot
data:
filename: "{{ snapshot_file }}"
target:
entity_id: camera.ma_camera
- action: notify.email_alertes
data:
title: "[home AL] Ouverture détectée en absence"
message: >
Une porte ou fenêtre surveillée vient de s'ouvrir alors qu'aucune
personne autorisée n'est détectée à la maison.
Heure : {{ now().strftime('%d/%m/%Y à %H:%M:%S') }}.
(Automatisation : alerte_ouverture_absence_v2)
data:
images:
- "{{ snapshot_file }}"
mode: single
Adapte les identifiants suivants à ta configuration :
binary_sensor.groupe_ouvertures_surveillees : l’identifiant de ton groupe de capteurs
person.personne_1 : l’entité Personne de ton téléphone
sensor.telephone1_wi_fi_connection : le capteur Wi-Fi de ton téléphone
MON_RESEAU_WIFI : le nom de ton réseau Wi-Fi maison
camera.ma_camera : l’identifiant de ta caméra
notify.email_alertes : le nom de ton service d’email
Tester
Pour tester sans sortir de chez toi, désactive le Wi-Fi de ton téléphone. L’entité sensor.telephone1_wi_fi_connection passe alors à <not connected>, ce qui satisfait la condition d’absence.
Ouvre ensuite une porte surveillée. Tu dois recevoir un email avec la photo en pièce jointe dans les secondes qui suivent, et un fichier horodaté doit apparaître dans /home/USER/docker/home-assistant/media/.
Pour vérifier le détail d’une exécution, va dans Paramètres > Automatisations > [home AL] Alerte ouverture en absence > Historique des exécutions.
Ajouter un deuxième téléphone
Pour surveiller un deuxième téléphone, ajoute son entité Personne et son capteur Wi-Fi dans les conditions. L’alerte ne se déclenche que si les deux personnes sont absentes :
conditions:
- condition: or
conditions:
- condition: and
conditions:
- condition: state
entity_id: person.personne_1
state: "not_home"
- condition: state
entity_id: person.personne_2
state: "not_home"
- condition: and
conditions:
- condition: not
conditions:
- condition: state
entity_id: sensor.telephone1_wi_fi_connection
state: "MON_RESEAU_WIFI"
- condition: not
conditions:
- condition: state
entity_id: sensor.telephone2_wi_fi_connection
state: "MON_RESEAU_WIFI"
Tu veux savoir si une coupure de courant a eu lieu chez toi pendant ton absence, sans investir dans du matériel dédié ? Voici comment détecter une panne secteur avec des prises connectées Zigbee et Home Assistant, et recevoir une alerte par e-mail à chaque coupure et à chaque retour du courant.
Cet article s’inscrit dans la série Domotique avec Home Assistant et réutilise l’infrastructure mise en place dans la série Projets Ubuntu (Docker, Portainer, Zigbee2MQTT).
Le matériel utilisé
Un mini PC Ubuntu, protégé par un onduleur, faisant tourner Home Assistant, Mosquitto et Zigbee2MQTT en containers Docker
Un dongle Zigbee (Sonoff MG21)
Cinq prises connectées Zigbee Nous A7Z, chacune alimentant un appareil différent de la maison (dont le réfrigérateur et le congélateur, dont la charge constante en fait de bons indicateurs)
Un Chromecast Audio, connecté en Wi-Fi
L’idée : si tous ces appareils disparaissent du réseau en même temps, c’est qu’il n’y a plus de courant dans la maison. Le mini PC et sa box internet, eux, restent en ligne grâce à l’onduleur.
Demander à Zigbee2MQTT de vérifier activement le réseau
Sans réglage supplémentaire, une prise Zigbee débranchée, ou sans courant, ne passe jamais à indisponible : Zigbee2MQTT ne vérifie pas activement, par défaut, si un appareil alimenté sur secteur répond encore. Il se contente d’afficher la dernière valeur reçue, indéfiniment, tant qu’aucun nouveau message n’arrive. Pour une prise débranchée, ça veut dire un blocage permanent sur son dernier état connu.
Il faut donc activer la fonctionnalité de vérification de disponibilité de Zigbee2MQTT, qui va interroger (ping) les prises à intervalles réguliers pour confirmer qu’elles répondent encore.
Piège à éviter : ce réglage ne doit jamais être fait en éditant directement le fichier configuration.yaml de Zigbee2MQTT à la main. Zigbee2MQTT garde sa configuration active en mémoire et la réécrit sur le fichier physique à chaque redémarrage du container, ce qui efface silencieusement toute modification manuelle qui n’a pas été prise en compte par le service lui-même.
Le bon réglage passe par l’interface Web de Zigbee2MQTT :
Va dans Paramètres > Disponibilité
Active la case « Activer les vérifications de disponibilité »
Dans la section Active, renseigne un timeout (en minutes). Trois minutes est un bon compromis entre rapidité de détection et charge sur le dongle Zigbee
Enregistre
Ce réglage global s’applique à tous les appareils Zigbee alimentés sur secteur (comme les prises), sans qu’il soit nécessaire d’activer quoi que ce soit individuellement pour chacune.
Une fois activé, débranche une prise et observe sa fiche dans le frontend de Zigbee2MQTT : après le délai configuré, elle passe à « Disponibilité : Désactivé ». Côté Home Assistant, l’entité switch correspondante passe à indisponible au même moment, ce qui fait automatiquement basculer le capteur de groupe.
Sécuriser l’envoi d’e-mail
Avant de configurer l’envoi d’alertes, un point de sécurité important : n’utilise jamais un compte e-mail personnel ou professionnel pour ce genre d’automatisation. Si ce compte est compromis un jour, l’impact reste limité à cette seule automatisation.
La bonne pratique consiste à créer un compte Gmail secondaire, dédié uniquement à l’envoi de ces alertes, avec un mot de passe d’application (pas le mot de passe du compte lui-même). Tout le détail de cette mise en place, avec l’activation de la double authentification (mais pas la création du mot de passe d’application), fait l’objet d’un article séparé : Sécuriser son compte Gmail avec la double authentification et Aegis Authenticator.
Une fois le mot de passe d’application créé, tous les identifiants (mot de passe, adresse expéditrice, adresse destinataire) sont stockés dans secrets.yaml, jamais directement dans configuration.yaml, pour ne jamais les exposer si tu partages ta configuration.
Dans /home/USER/docker/home-assistant/config/secrets.yaml :
Après modification, redémarre complètement le container Home Assistant : ce type de service (notify) n’est pas pris en compte par un simple rechargement de configuration.
Pour tester, va dans Outils de développement > Actions, cherche notify.email_alertes, renseigne un message, et lance l’action. Vérifie ta boîte de réception, y compris le dossier spam : un premier envoi automatisé depuis une adresse encore peu utilisée y atterrit parfois. Marquer le message comme « non spam » et ajouter l’adresse aux contacts résout le problème pour la suite.
Créer les capteurs template et le groupe
Le Chromecast Audio se comporte différemment des prises Zigbee : c’est un appareil Wi-Fi, dont Home Assistant détecte lui-même la perte de connexion en quelques secondes, sans configuration particulière à ajouter côté réseau. Son entité media_player passe directement à indisponible en cas de coupure.
Les prises Zigbee, elles, ont besoin d’un réglage supplémentaire détaillé dans la section suivante avant de se comporter de la même façon. On va surveiller la présence de chaque appareil sur le réseau Zigbee, pas sa consommation. Home Assistant expose pour chaque prise Zigbee une entité switch, qui représente son état de connexion. Tant que la prise répond, cette entité a une valeur (on ou off, selon que la prise est allumée ou éteinte manuellement). Si la prise ne répond plus, l’entité passe à indisponible.
On crée d’abord un capteur « template » par appareil : des capteurs virtuels qui traduisent l’état de chaque appareil en on ou off, selon qu’il est présent ou non sur le réseau. Puis on les regroupe en un seul capteur, qui résume l’état du secteur pour toute la maison.
À ajouter dans configuration.yaml :
template:
- binary_sensor:
- name: "Courant Prise A Bureau"
unique_id: courant_prise_a_bureau
device_class: power
state: >
{{ states('switch.prise_a_bureau_entree') != 'unavailable' }}
- name: "Courant Prise B Salon"
unique_id: courant_prise_b_salon
device_class: power
state: >
{{ states('switch.prise_b_salon_tel') != 'unavailable' }}
- name: "Courant Prise C Garage"
unique_id: courant_prise_c_garage
device_class: power
state: >
{{ states('switch.prise_c_garage_machine_a_laver') != 'unavailable' }}
- name: "Courant Chromecast Salon"
unique_id: courant_chromecast_salon
device_class: power
state: >
{{ states('media_player.salon') != 'unavailable' }}
- name: "Courant Prise D Frigo"
unique_id: courant_prise_d_frigo
device_class: power
state: >
{{ states('switch.prise_d_frigo') != 'unavailable' }}
- name: "Courant Prise E Congélateur"
unique_id: courant_prise_e_congelateur
device_class: power
state: >
{{ states('switch.prise_e_congelateur') != 'unavailable' }}
binary_sensor:
- platform: group
name: "Courant Secteur Maison"
unique_id: courant_secteur_maison
entities:
- binary_sensor.courant_prise_a_bureau
- binary_sensor.courant_prise_b_salon
- binary_sensor.courant_prise_c_garage
- binary_sensor.courant_chromecast_salon
- binary_sensor.courant_prise_d_frigo
- binary_sensor.courant_prise_e_congelateur
Remplace switch.prise_a_bureau_entree et les autres par les identifiants exacts de tes propres prises. Tu les trouves dans Outils de développement > États, en filtrant sur switch..
Le groupe fonctionne en logique « au moins un » : il reste à on tant qu’un seul des appareils listés est présent sur le réseau, et ne passe à off que si tous sont indisponible en même temps. C’est ce qui permet de distinguer une vraie coupure générale d’un simple appareil débranché ou en panne.
Pour ajouter une prise supplémentaire plus tard, il suffit de dupliquer un bloc de capteur template avec le bon identifiant, et d’ajouter la ligne correspondante dans entities: du groupe. Rien d’autre à modifier : ni le service notify, ni les automatisations, qui s’appuient uniquement sur le capteur de groupe.
Activer le ping de disponibilité sur Zigbee2MQTT
Sans réglage supplémentaire, une prise Zigbee débranchée ne passe jamais à indisponible : Zigbee2MQTT ne vérifie pas activement, par défaut, si un appareil alimenté sur secteur répond encore. Il se contente d’afficher la dernière valeur reçue, indéfiniment, tant qu’aucun nouveau message n’arrive. Pour une prise débranchée, ça veut dire un blocage permanent sur son dernier état connu.
Il faut donc activer la fonctionnalité de vérification de disponibilité de Zigbee2MQTT, qui va interroger (ping) les prises à intervalles réguliers pour confirmer qu’elles répondent encore.
Piège à éviter : ce réglage ne doit jamais être fait en éditant directement le fichier configuration.yaml de Zigbee2MQTT à la main. Zigbee2MQTT garde sa configuration active en mémoire et la réécrit sur le fichier physique à chaque redémarrage du container, ce qui efface silencieusement toute modification manuelle qui n’a pas été prise en compte par le service lui-même.
Le bon réglage passe par l’interface Web de Zigbee2MQTT :
Va dans Paramètres > Disponibilité
Active la case « Activer les vérifications de disponibilité »
Dans la section Active, renseigne un timeout (en minutes). Trois minutes est un bon compromis entre rapidité de détection et charge sur le dongle Zigbee
Enregistre
Ce réglage global s’applique à tous les appareils Zigbee alimentés sur secteur (comme les prises), sans qu’il soit nécessaire d’activer quoi que ce soit individuellement pour chacune.
Une fois activé, débranche une prise et observe sa fiche dans le frontend de Zigbee2MQTT : après le délai configuré, elle passe à « Disponibilité : Désactivé ». Côté Home Assistant, l’entité switch correspondante passe à indisponible au même moment, ce qui fait automatiquement basculer le capteur de groupe.
Les automatisations
Deux automatisations : une pour signaler le début d’une coupure, une pour signaler le retour du courant. Toutes deux intègrent un délai de 30 secondes avant de se déclencher, pour éviter une alerte sur une micro-coupure sans conséquence.
À ajouter dans /home/USER/docker/home-assistant/config/automations.yaml :
- id: alerte_debut_panne_courant
alias: "Alerte début de panne de courant"
trigger:
- platform: state
entity_id: binary_sensor.courant_secteur_maison
to: "off"
for:
seconds: 30
action:
- service: notify.email_alertes
data:
title: "[home ALD] Coupure de courant détectée"
message: >
Une coupure de courant a été détectée à {{ now().strftime('%H:%M:%S') }}.
Ce mail a été généré automatiquement par Home Assistant d'Anne-Laure, suite à l'automatisation id: alerte_debut_panne_courant.
- id: alerte_fin_panne_courant
alias: "Alerte fin de panne de courant"
trigger:
- platform: state
entity_id: binary_sensor.courant_secteur_maison
to: "on"
for:
seconds: 30
action:
- service: notify.email_alertes
data:
title: "[home ALD] Retour du courant"
message: >
Le courant est revenu à {{ now().strftime('%H:%M:%S') }}.
Ce mail a été généré automatiquement par Home Assistant d'Anne-Laure, suite à l'automatisation id: alerte_fin_panne_courant.
Deux détails utiles à reproduire, indépendamment du sujet de l’automatisation :
Un préfixe cohérent dans le titre (ici [home ALD]) permet de créer facilement un filtre ou une étiquette dans ta messagerie pour regrouper toutes les alertes de ta maison connectée
Une ligne de traçabilité dans le corps du message, citant l’identifiant de l’automatisation à l’origine de l’envoi, facilite le diagnostic si tu dois un jour retrouver quelle automatisation a déclenché quel e-mail
Après modification, recharge les automatisations (Outils de développement > YAML > Recharger les automatisations), ou redémarre complètement Home Assistant si tu préfères.
Bilan des tests réels
Le test décisif consiste à débrancher réellement les appareils concernés, plutôt que de forcer un état depuis l’interface, pour valider le comportement de bout en bout.
En débranchant une seule prise, rien ne se passe : le groupe reste alimenté grâce aux autres appareils encore présents sur le réseau, exactement le comportement attendu. En débranchant tous les appareils, le capteur de groupe passe à indisponible, et l’e-mail de coupure arrive environ 30 secondes après la détection effective par Zigbee2MQTT, conformément au délai configuré dans l’automatisation.
Au rebranchement, le Chromecast est détecté quasiment tout de suite (c’est un appareil Wi-Fi). Les prises Zigbee, elles, réapparaissent en quelques minutes au maximum, le temps que Zigbee2MQTT confirme leur présence lors de son prochain cycle de vérification.
J’ai récemment entrepris de sécuriser l’ensemble de mes comptes en ligne – Google, stockage cloud, messagerie. Ce que j’ai découvert en chemin m’a surprise : ma configuration de départ, que je croyais raisonnable, était en réalité fragile à plusieurs endroits. Cet article retrace la démarche et les principes qui m’ont guidée. Je ne peux pas en détailler toutes les étapes comme je le fais habituellement – la nature même du sujet impose de ne pas trop exposer ses choix techniques. Mais les principes, eux, sont utiles à partager.
Mon point de départ – et ses problèmes
Mon point de départ : un compte Google professionnel et un compte Google personnel, chacun configuré avec un mot de passe plutôt solide et l’adresse de l’autre pour une éventuelle récupération.
Le seul point positif : les mots de passe étaient stockés dans un gestionnaire de mots de passe.
Ce système posait plusieurs problèmes :
Circularité des deux comptes : si quelqu’un prend le contrôle de l’un des deux comptes, il accède immédiatement à l’autre via la récupération. Les deux comptes tombent ensemble.
Absence de second verrou : si quelqu’un accédait à mon mot de passe, il pouvait accéder à mon compte puis à l’autre. La solution : mettre en place la double authentification avec une application indépendante de toute plateforme, qui fonctionne sans connexion réseau.
un ordinateur portable avec des disques durs non chiffrés, que n’importe qui aurait pu lire.
si je n’avais plus accès à mon téléphone, je me retrouvais dépourvue de toute information pour agir.
Voici les solutions adoptées pour résoudre successivement ces problèmes.
Limiter le « blast radius »
Il faut tout faire pour que la compromission d’un seul compte n’ait pas d’impact sur les autres. C’est le principe de limitation du « blast radius » – le rayon de l’explosion.
On évite donc les adresses de récupération croisées : si l’adresse A est l’adresse de récupération de l’adresse B, alors l’adresse de récupération de l’adresse A doit être une adresse C indépendante – pas l’adresse B. Sinon, si quelqu’un prend le contrôle de l’un des deux comptes, il accède immédiatement à l’autre. Les deux tombent ensemble.
Pour les mêmes raisons, les mots de passe des différentes adresses doivent être différents, et on ne stocke pas de données sensibles dans un compte secondaire – les mots de passe d’autres comptes, par exemple.
La double authentification : choisir une application indépendante
Mais cette solution crée une nouvelle dépendance : si je perdais l’accès à mon téléphone (perte, vol, casse), je perdais l’accès à tous les comptes protégés par l’application d’authentification. Les codes de secours sont la réponse à ce problème.
Les codes de secours : prévoir la perte du téléphone
Les codes de secours donnent accès aux comptes protégés même si le téléphone ne peut plus servir : des codes à usage unique, générés par chaque service au moment de l’activation de la 2FA, qui te permettent de te connecter sans téléphone. Chaque code ne peut être utilisé qu’une seule fois.
Quelques principes pour les stocker correctement :
Les copies doivent être indépendantes les unes des autres. Si tous tes codes de secours sont sur Google Drive et que tu perds l’accès à ton compte Google, tu perds aussi les codes qui auraient pu te permettre de le récupérer. Utilise au moins un service de stockage indépendant de Google pour cette copie.
Les copies doivent être géographiquement séparées. Une copie à domicile et une copie ailleurs – chez une personne de confiance, dans un coffre, sur un service cloud accessible depuis n’importe où. Un incendie ou un cambriolage ne doit pas effacer toutes tes copies en même temps.
Une copie papier reste utile. Dans un scénario où tu n’as plus accès à aucun appareil ni à aucun service en ligne, un bout de papier chez une personne de confiance peut être ce qui te permet de tout récupérer.
Note que tous les services ne proposent pas de codes de secours. C’est un critère à prendre en compte : un service qui gère des données importantes et ne propose pas de codes de secours t’expose à une perte d’accès définitive si tu perds ton téléphone.
Chiffrer son ordinateur portable
Un portable volé, c’est potentiellement toutes tes données exposées – y compris les sessions ouvertes, les mots de passe en cache dans les navigateurs, les fichiers temporaires. Le chiffrement du disque rend ces données illisibles sans le bon mot de passe, même si quelqu’un retire le disque et le branche ailleurs.
Un point souvent négligé : si ton ordinateur a deux disques, chiffre les deux – en commençant par le disque qui contient Windows. Le disque système contient bien plus de données sensibles qu’il n’y paraît, même si tous tes fichiers personnels sont sur le second disque.
La personne de confiance et la procédure d’urgence
Tous les systèmes de récupération décrits jusqu’ici supposent que tu peux accéder à quelque chose : un service cloud, un gestionnaire de mots de passe, un appareil. Mais dans un scénario extrême – perte simultanée du téléphone, de l’ordinateur et de l’accès à internet – il faut un dernier filet.
Ce filet, c’est une personne de confiance à qui tu as remis les informations minimales pour t’aider à récupérer l’accès à tes comptes essentiels : codes de secours imprimés, procédure claire expliquant quoi faire et dans quel ordre.
Cette procédure doit être rédigée pour quelqu’un qui n’est pas technicien – elle doit être compréhensible et actionnable sans contexte. Elle doit aussi prévoir un moyen de vérifier l’identité de la personne qui appelle, pour éviter qu’un attaquant ne se fasse passer pour toi.
Les informations les plus sensibles – mots de passe, clés de récupération, informations bancaires – méritent d’être séparées du reste, dans une enveloppe scellée distincte, avec une recommandation de la conserver dans un coffre.
Ce que cette démarche ne couvre pas
Cette démarche se concentre sur les comptes en ligne et l’ordinateur portable. Elle ne couvre pas :
La sécurisation des appareils mobiles (code PIN, chiffrement Android ou iOS)
La gestion des mots de passe eux-mêmes – un gestionnaire de mots de passe (1Password, Bitwarden, Dashlane ou KeePass) est un prérequis implicite à tout ce qui est décrit ici
La sécurité du réseau domestique (routeur, Wi-Fi)
Les sauvegardes de données – un sujet distinct, tout aussi important
Ces sujets ont chacun leur propre complexité et mériteraient des articles dédiés.
Un ordinateur portable volé, c’est d’abord des données personnelles exposées. BitLocker, intégré à Windows, chiffre le contenu de tes disques pour les rendre illisibles sans le bon mot de passe – même si quelqu’un retire le disque dur et le branche sur un autre ordinateur.
Ce que BitLocker protège – et ce qu’il ne protège pas
BitLocker protège les données au repos : quand l’ordinateur est éteint ou verrouillé, le contenu des disques est illisible sans la clé de déchiffrement. Un voleur qui récupère ton portable éteint ne peut rien faire des données.
En revanche, BitLocker ne protège pas un ordinateur allumé et déverrouillé. Si quelqu’un accède à ta session Windows ouverte, il accède aussi à tes fichiers. Le chiffrement du disque ne remplace pas un mot de passe de session solide et l’habitude de verrouiller son écran quand on s’éloigne.
Prérequis
BitLocker est disponible sur Windows 10 et Windows 11 en versions Pro, Entreprise et Éducation. Il n’est pas disponible sur les versions Home.
Pour vérifier ta version de Windows : clique droit sur le menu Démarrer > « Système » > regarde la ligne « Édition Windows ».
Il te faut aussi les droits administrateur sur l’ordinateur pour activer BitLocker.
Pourquoi commencer par le disque qui contient Windows (C:)
Même si tu ranges tous tes fichiers personnels sur un second disque, ton disque C: contient bien plus de données sensibles qu’il n’y paraît :
Les mots de passe enregistrés dans les navigateurs (Chrome, Firefox, Edge) sont stockés sur C:
Les sessions de messagerie et leurs jetons de connexion sont sur C: – un accès à ce disque peut suffire à ouvrir tes boîtes mail sans connaître tes mots de passe
Tout ce qui passe par le dossier Téléchargements atterrit par défaut sur C:
Windows utilise C: comme mémoire temporaire : si tu ouvres un document confidentiel depuis D:, Windows peut en copier des fragments sur C:
Il faut donc toujours commencer par chiffrer C:, et ensuite seulement s’occuper des autres disques.
Chiffrer le disque principal (C:)
Ouvrir le gestionnaire BitLocker
Dans le menu Démarrer, tape « BitLocker » et clique sur « Gérer BitLocker ». Tu arrives sur une page qui liste tous les disques de ton ordinateur.
Activer BitLocker sur C:
Clique sur « Activer BitLocker » à côté du lecteur C:. Windows lance un assistant en plusieurs étapes.
Sauvegarder la clé de récupération
C’est l’étape la plus importante. Windows te propose plusieurs options pour sauvegarder la clé de récupération – un code à 48 chiffres qui te permet de déverrouiller le disque si quelque chose se passe mal au démarrage.
Si ton ordinateur est lié à un compte Microsoft, tu peux choisir « Enregistrer sur mon compte Microsoft » : la clé sera accessible depuis account.microsoft.com > Appareils > Clés de récupération BitLocker.
Si ton ordinateur n’est pas lié à un compte Microsoft (ce qui est tout à fait possible et même recommandé pour des raisons de confidentialité), cette option n’est pas disponible. Dans ce cas :
Choisis « Enregistrer dans un fichier » et sauvegarde ce fichier sur un emplacement extérieur au disque C: en cours de chiffrement – une clé USB, un autre disque, ou un dossier cloud accessible depuis un autre appareil
Tu peux aussi choisir « Imprimer la clé de récupération » pour en avoir une copie papier
Note l’identifiant de clé affiché (une suite de caractères du type 85CDA21F-...) : il te permettra de retrouver la bonne clé si tu en as plusieurs. Conserve cette clé précieusement dans un endroit sûr, séparé de l’ordinateur – idéalement chez une personne de confiance ou dans un gestionnaire de mots de passe accessible hors ligne.
Choisir quoi chiffrer
Windows te demande si tu veux chiffrer uniquement l’espace utilisé ou tout le disque. Choisis « Chiffrer tout le lecteur » si l’ordinateur est utilisé depuis un moment – c’est plus long mais plus complet.
Choisir le mode de chiffrement
Choisis « Nouveau mode de chiffrement » si ton ordinateur tourne sous Windows 10 ou 11 – c’est le mode le plus récent et le plus solide.
Lancer le chiffrement
Clique sur « Démarrer le chiffrement ». Le processus se lance immédiatement en arrière-plan – tu peux continuer à utiliser l’ordinateur pendant ce temps. La durée dépend de la taille du disque et peut aller de quelques minutes à plusieurs heures.
Windows te demandera peut-être de redémarrer pour terminer le chiffrement.
Chiffrer un second disque (D:)
Une fois le disque C: chiffré, retourne dans le gestionnaire BitLocker et clique sur « Activer BitLocker » à côté de ton second disque.
Cette fois, Windows te demande de définir un mot de passe pour déverrouiller ce disque. Choisis un mot de passe solide et note-le dans ton gestionnaire de mots de passe.
Sauvegarde la clé de récupération de ce second disque – elle est différente de celle du disque C:. Conserve-la avec le même soin, en indiquant clairement de quel disque elle provient.
Déverrouillage automatique
À la fin de la procédure, BitLocker peut te proposer d’activer le déverrouillage automatique de ce disque quand tu ouvres une session Windows. Si cette option est disponible, coche-la : le disque D: s’ouvrira automatiquement à chaque démarrage, sans que tu aies à saisir son mot de passe.
Si cette option n’est pas proposée, tu devras saisir le mot de passe du disque D: à chaque démarrage, ou l’activer manuellement plus tard depuis le gestionnaire BitLocker.
Un point important : si le disque D: est un disque amovible ou s’il est séparé physiquement du disque C: (par exemple après un remplacement de disque), le déverrouillage automatique ne fonctionnera plus. Dans ce cas, tu auras besoin du mot de passe ou de la clé de récupération spécifique à ce disque pour y accéder.
Vérifier que tout fonctionne
Redémarre l’ordinateur. Si le démarrage se passe normalement et que tu accèdes à ta session Windows comme d’habitude, le chiffrement est en place et fonctionne correctement.
Pour confirmer : ouvre le gestionnaire BitLocker. Chaque disque chiffré doit afficher « BitLocker activé ».
Pour aller plus loin
BitLocker protège tes données en cas de vol physique de l’ordinateur. C’est une brique importante, mais elle s’inscrit dans une démarche de sécurisation plus large : mots de passe solides, double authentification sur tes comptes en ligne, sauvegardes régulières.
Commentaires récents