Installation de Raspberry Pi OS : carte SD bien faite (et comment éviter la corruption)

février 26, 2026 • février 26, 2026 • Lecture : 28 min • Views: 0

Cet article vous a aidé ?

Rien n’humilie un ingénieur confiant comme un Raspberry Pi qui « fonctionnait hier » et qui démarre maintenant sur un système de fichiers en lecture seule, avec l’expression émotionnelle d’une brique.
Le coupable n’est souvent pas Linux, ni votre application, ni la phase de la lune. C’est votre procédure autour de la carte SD : choix du média, flashage, vérification, et la routine quotidienne des pertes d’alimentation et des petites couches de traduction de la flash.

Voici la manière pragmatique, orientée production, d’installer Raspberry Pi OS sur une carte SD pour qu’il reste installé. Nous ferons les vérifications ennuyeuses qui préviennent les pannes,
nous expliquerons pourquoi les cartes « rapides » échouent en slow motion, et nous établirons un guide de diagnostic pour quand le Pi reste bloqué sur un écran arc‑en‑ciel cinq minutes avant une démo.

Ce qui cause réellement la corruption des cartes SD sur un Pi

Les cartes SD ne sont pas des « petits SSD ». Ce sont de petits dispositifs flash avec des contrôleurs extrêmement variables, des firmwares inconsistants, des blocs de rechange limités, et une couche de traduction qu’on ne peut pas régler.
Quand vous corrompez un système de fichiers sur un Pi, le système de fichiers n’est généralement pas le méchant. Il est le messager. Le message est : « une écriture a été interrompue, ou le support a menti. »

Les trois mécanismes de corruption les plus courants

Perte soudaine d’alimentation pendant des écritures de métadonnées. ext4 est résilient, mais il ne peut pas journaliser ce qui n’est jamais sorti du cache du contrôleur.
Un Pi avec une alimentation marginale ou un pic de charge pratique le chaos engineering sans billet.
Usure du média + contrôleurs faibles. Les cartes bon marché échouent « gracieusement » seulement dans le texte marketing. En réalité elles peuvent commencer à renvoyer des erreurs I/O,
ou remapper des blocs silencieusement jusqu’à l’effondrement des performances, puis la carte devient lecture seule ou disparaît.
Amplification d’écritures élevée due au « comportement normal de Linux ». Logs, mises à jour de paquets, caches de navigateur, swap, télémétrie et bases de données.
Le Pi n’est pas tendre par défaut ; il est simplement petit.

Voici la vérité opérationnelle : une installation sur carte SD est fiable lorsque vous concevez pour les modes de défaillance, pas quand vous espérez que votre carte particulière est « l’une des bonnes ».
La fiabilité est un workflow : choisir un média sensé, flasher correctement, vérifier, puis réduire les écritures inutiles et arrêter d’abuser l’alimentation.

Blague n°1 : Une carte SD, c’est comme un sous‑traitant : elle peut être rapide, bon marché ou fiable — choisissez deux, et parfois vous n’obtenez qu’un.

Faits intéressants et un peu d’histoire (qui influencent vos choix)

Vous n’avez pas besoin de nostalgie pour faire fonctionner un Pi, mais quelques détails historiques expliquent pourquoi les installations modernes de Raspberry Pi OS se comportent comme elles le font.

La SD Association a lancé SD en 1999. C’est plus ancien que beaucoup d’architectures « cloud‑native », et l’écosystème porte encore des contraintes héritées.
Le wear leveling dépend du contrôleur. Deux cartes « identiques » de 32 Go peuvent se comporter différemment parce que le firmware du contrôleur décide comment remapper et mettre en cache les écritures.
La « Speed Class » pour microSD a été conçue pour des écritures séquentielles vidéo. Ce n’est pas votre charge de travail. Démarrer Linux c’est de nombreuses petites lectures aléatoires plus des rafales d’écritures de métadonnées.
Les classes de performance pour applications (A1/A2) ont été introduites pour l’E/S aléatoire. A1/A2 se rapprochent de ce dont un Pi a besoin, mais ce n’est pas une garantie.
Raspberry Pi s’est initialement appuyé sur la SD parce que c’était bon marché et accessible. La plateforme a grandi avec de la flash amovible comme stockage principal, donc beaucoup de projets partent encore de cette hypothèse.
Le journaling des systèmes de fichiers est devenu courant sur les desktops Linux pour une raison. Le journal ext4 réduit la douleur de récupération après crash, mais il n’annule pas une mauvaise alimentation ou un mauvais média.
Les modèles Pi modernes supportent le démarrage depuis USB. Ce n’est pas triviaux : c’est votre issue de secours face à la fragilité SD quand vous passez au « ça doit tourner pendant un an ».
La flash bon marché échoue souvent en passant en lecture seule. C’est un comportement protecteur du contrôleur quand il ne peut plus garantir les écritures.

Choisir la bonne microSD (endurance, labels A et mensonges)

Acheter une carte SD, c’est comme recruter pour un poste fiabilité en ne lisant que le CV. Les vendeurs vous diront qu’elle est « rapide », « premium », et « gaming ».
Aucun de ces mots ne signifie « survit à une base de données et à journald pendant 18 mois ».

Ce qu’il faut prioriser

Classe endurance (High/Max Endurance). Cela compte quand vous avez des petites écritures constantes : logs, métriques, SQLite, mises à jour de paquets.
Les cartes endurance sont conçues pour les dashcams et la vidéosurveillance : charges ennuyeuses, écritures incessantes, longue disponibilité. C’est vous.
Marge de capacité. Les cartes plus grandes se comportent souvent mieux parce qu’il y a plus de blocs de rechange pour le wear leveling.
Aussi, ext4 avec une racine presque pleine fonctionne et récupère moins bien.
Chaîne d’approvisionnement réputée. Les contrefaçons sont fréquentes. Si le prix est suspect, considérez la carte comme menteuse jusqu’à preuve du contraire.
Label A1/A2 (avec réalisme). A1 est un bon baseline. A2 peut être plus rapide, mais certains hôtes n’en tirent pas pleinement parti, et certaines cartes se comportent étrangement sous I/O mixte soutenue.

Ce qu’il ne faut pas optimiser (sauf si vous aimez le debug)

Débit séquentiel maximal en MB/s. Votre Pi démarre à partir de nombreuses petites lectures et effectue beaucoup de petites écritures. « 170 MB/s » sur l’étiquette, c’est surtout du spectacle.
Le prix au Go le plus bas. Vous ne construisez pas une archive froide. Vous construisez un petit serveur.
Très petite capacité. Les cartes 8 Go existent encore. Les pagers aussi. Aucun des deux n’est un bon signe.

Règle pratique

Pour les projets « jouet » : une carte A1 de marque décente 32–64 Go, achetée chez un vendeur réputé, suffit.
Pour « ça fait tourner un service » : achetez de l’endurance, 64–128 Go, et budgétez le remplacement comme un consommable (parce que c’en est un).
Pour « ça compte » : utilisez le démarrage sur SSD USB si votre Pi le supporte. Les cartes SD sont pour la commodité, pas pour votre budget d’incident.

Réalité de l’alimentation et des E/S : votre Pi est un système de stockage

La corruption SD est souvent un problème d’alimentation déguisé en problème de stockage. Le Pi n’a pas de cache alimenté par batterie. Le contrôleur de la carte SD peut avoir un cache interne,
mais vous ne contrôlez pas son comportement de vidage. Quand la tension chute, les écritures sont interrompues. Parfois vous le remarquez tout de suite. Parfois la corruption se développe plus tard comme de la moisissure.

Pièges d’alimentation qui ressemblent à des « bizarreries Linux »

Sous‑tension lors d’un pic de charge. Périphériques USB, rafales Wi‑Fi, pics CPU, modules caméra. Le Pi peut brunouter brièvement sans crash spectaculaire.
Câbles faibles. Une bonne alimentation avec un mauvais câble reste une mauvaise alimentation.
Alimentation en retour et hubs douteux. Si votre hub USB fait des choses discutables, votre stockage fera des choses discutables aussi.

Si votre Pi est distant, ou si quelqu’un peut le débrancher à la légère, concevez comme si la prise allait être retirée au pire moment possible. Parce que ce sera le cas.

Flasher Raspberry Pi OS correctement (et vérifier)

L’échec d’installation le plus commun que je voie n’est pas « image corrompue ». C’est « on a écrit l’image sur le mauvais périphérique », « on n’a pas vérifié », ou « la carte est fausse ».
L’étape de flashage est là où vous établissez la confiance dans le support et le processus.

Approche opinionnée

Utilisez Raspberry Pi Imager quand vous voulez la voie la plus simple avec des valeurs par défaut sensées et la vérification intégrée.
Utilisez l’imagerie brute (dd) seulement si vous vérifiez aussi et si vous pouvez identifier correctement les périphériques à chaque fois, même sur une station de travail chargée.
Vérifiez toujours ce que vous avez écrit en utilisant des sommes de contrôle ou une comparaison en lecture. « Ça a flashé avec succès » n’est pas une vérification ; ce sont des impressions.

Aussi : si vous flashez depuis Linux et que vous ne savez pas à quoi correspond /dev/sdX, arrêtez. C’est comme ça qu’on transforme « installer Raspberry Pi OS » en « pourquoi mon portable ne démarre plus ».

Durcissement au premier démarrage : réduire les écritures, améliorer la survie

Un Raspberry Pi OS frais démarre bien sur presque tout. Le problème survient après des semaines : apt update, logs, swap, caches navigateur, et le journalisme enthousiaste de votre application.
Le durcissement, c’est décider si ce Pi est un jouet ou une appliance.

Mouvements à fort impact pour réduire les écritures

Déplacez les logs volatils en RAM (ou réduisez la persistance de journald).
Désactivez le swap sur la SD si vous avez assez de RAM, ou déplacez le swap vers un SSD.
Soyez intentionnel avec les bases de données. SQLite convient, mais adaptez-le et évitez les rafales de fsync si vous n’en avez pas besoin.
Gardez de l’espace libre. Visez au moins 20–30% d’espace libre sur la racine pour les performances et le comportement du wear leveling.

Citation requise (idée paraphrasée) : « Tout échoue ; le travail consiste à concevoir pour que les défaillances soient survivables et que la récupération soit ennuyeuse. » — John Allspaw (idée paraphrasée)

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches réelles que vous pouvez exécuter depuis une station Linux (pour le flash) et depuis le Pi (pour la validation et le diagnostic).
Chacune inclut ce que la sortie signifie et quelle décision vous prenez à partir de cela. Cette dernière partie fait la différence entre « commandes » et « opérations ».

Task 1: Identify the SD card device correctly (workstation)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,HOTPLUG,MOUNTPOINTS
NAME      SIZE MODEL            SERIAL        TRAN HOTPLUG MOUNTPOINTS
nvme0n1  953G Samsung SSD 980   S64...        nvme       0 /
sda      931G WDC WD10...       WD-...        usb        0 /media/cr0x/backup
sdb     59.5G USB SD Reader     000000000000 usb        1 /media/cr0x/boot
                                                /media/cr0x/rootfs

Signification : sdb est le lecteur SD amovible (HOTPLUG=1) et il a des partitions montées.
Décision : Vous allez démonter et écrire sur /dev/sdb, pas sur une partition comme /dev/sdb1, et certainement pas sur votre disque système.

Task 2: Unmount all SD partitions before imaging (workstation)

cr0x@server:~$ sudo umount /dev/sdb1 /dev/sdb2
umount: /dev/sdb1: not mounted.
umount: /dev/sdb2: not mounted.

Signification : Soit déjà démonté, soit pas monté sous ces noms.
Décision : Confirmez avec lsblk qu’aucun point de montage ne subsiste ; écrire sur un périphérique monté risque la corruption et des erreurs « busy ».

Task 3: Wipe old partition table signatures (workstation)

cr0x@server:~$ sudo wipefs -a /dev/sdb
/dev/sdb: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdb: 8 bytes were erased at offset 0x00000438 (ext4): 53 ef

Signification : Anciennes signatures supprimées.
Décision : Faites-le si vous avez eu des comportements de montage étranges ou des partitions « fantômes ». Cela empêche votre OS de deviner incorrectement.

Task 4: Flash Raspberry Pi OS image with dd and show progress (workstation)

cr0x@server:~$ sudo dd if=2025-01-15-raspios-bookworm-arm64.img of=/dev/sdb bs=4M conv=fsync status=progress
1610612736 bytes (1.6 GB, 1.5 GiB) copied, 19 s, 84.8 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 53 s, 81.1 MB/s
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 66 s, 81.3 MB/s
1280+0 records in
1280+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 66.1386 s, 81.2 MB/s

Signification : Image écrite ; conv=fsync force un flush à la fin, réduisant les erreurs de type « arrachée juste après dd ».
Décision : Ne retirez pas la carte encore ; vous devez toujours vérifier et vous assurer que le noyau est stabilisé.

Task 5: Force the OS to flush disk caches (workstation)

cr0x@server:~$ sync

Signification : Flush demandé.
Décision : Après le flash, faites toujours sync. C’est peu coûteux et évite le classique « je l’ai arrachée juste après dd ».

Task 6: Re-read partition table and confirm partitions appear (workstation)

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk /dev/sdb
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb      8:16   1 59.5G  0 disk
├─sdb1   8:17   1  512M  0 part
└─sdb2   8:18   1  5.0G  0 part

Signification : Les partitions boot et root attendues existent.
Décision : Si les partitions n’apparaissent pas, vous pouvez avoir un lecteur/carte défaillant ou vous avez écrit sur le mauvais périphérique. Arrêtez et enquêtez.

Task 7: Verify the image by comparing bytes (workstation)

cr0x@server:~$ sudo cmp -n 5368709120 2025-01-15-raspios-bookworm-arm64.img /dev/sdb

Signification : Aucune sortie signifie que les premiers 5 368 709 120 octets correspondent exactement (taille de l’image).
Décision : Si cmp signale une différence, ne démarrez pas le Pi pour « voir ce qui se passe ». Reflashez, essayez un autre lecteur, et suspectez la carte SD.

Task 8: On first boot, confirm undervoltage events (Pi)

cr0x@server:~$ vcgencmd get_throttled
throttled=0x0

Signification : 0x0 indique qu’aucun drapeau de throttling/sous‑tension n’a été levé depuis le démarrage.
Décision : Si vous voyez une valeur non nulle (commun : variantes 0x50000), corrigez l’alimentation avant d’accuser le système de fichiers. Remplacez l’alim/le câble, réduisez les périphériques, ou utilisez un hub alimenté.

Task 9: Check kernel logs for SD I/O errors (Pi)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mmc|I/O error|ext4|buffer I/O|blk_update_request' | tail -n 30
[Mon Feb  5 10:14:28 2026] mmc0: new high speed SDHC card at address aaaa
[Mon Feb  5 10:14:29 2026] mmcblk0: mmc0:aaaa SU64G 59.5 GiB
[Mon Feb  5 10:14:30 2026] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: none.

Signification : Détection et montage normaux.
Décision : Si vous voyez des I/O error répétés ou mmc0: Timeout waiting for hardware interrupt, considérez la carte comme suspecte et planifiez une migration.

Task 10: Confirm root filesystem and mount options (Pi)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/mmcblk0p2 / ext4 rw,relatime

Signification : La racine est sur mmcblk0p2, ext4, montée en lecture‑écriture.
Décision : Si elle est en ro, vous êtes en mode gestion des dégâts : vérifiez les erreurs fs, l’alimentation et la santé de la SD avant de redémarrer des services qui écrivent.

Task 11: Check filesystem health and last errors (Pi)

cr0x@server:~$ sudo tune2fs -l /dev/mmcblk0p2 | egrep -i 'Filesystem state|Errors behavior|Last error|Last mount time|Last checked'
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Mon Feb  5 10:14:30 2026
Last checked:             Mon Feb  5 10:10:02 2026

Signification : ext4 se croit propre.
Décision : Si l’état n’est pas clean, planifiez un fsck contrôlé depuis un démarrage de maintenance (ou un autre système) plutôt que de « espérer que le journal rattrape le coup ».

Task 12: Measure SD performance with a quick random read test (Pi)

cr0x@server:~$ sudo apt-get update -y
Hit:1 http://deb.debian.org/debian bookworm InRelease
Reading package lists... Done
cr0x@server:~$ sudo apt-get install -y fio
Reading package lists... Done
The following NEW packages will be installed:
  fio
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
cr0x@server:~$ fio --name=randread --filename=/tmp/fio.test --size=256M --rw=randread --bs=4k --iodepth=16 --numjobs=1 --direct=1 --runtime=30 --time_based
randread: (groupid=0, jobs=1): err= 0: pid=2123: Mon Feb  5 10:23:01 2026
  read: IOPS=1450, BW=5664KiB/s (5800kB/s)(166MiB/30001msec)

Signification : ~1450 IOPS en lectures aléatoires 4k est correct pour beaucoup de cartes ; certaines seront bien pires.
Décision : Si vous voyez des IOPS à deux chiffres ou une bande passante minuscule, attendez‑vous à des démarrages lents et des timeouts sous charge. Remplacez la carte ou passez au SSD.

Task 13: Check for aggressive logging and persistent journald writes (Pi)

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.

Signification : Journald a consommé un demi‑gigaoctet.
Décision : Sur SD, limitez‑le. Si ce Pi est un kiosque ou un capteur, vous n’avez probablement pas besoin de logs persistants illimités.

Task 14: Cap journald persistence to reduce SD wear (Pi)

cr0x@server:~$ sudo sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=64M/' /etc/systemd/journald.conf
cr0x@server:~$ sudo systemctl restart systemd-journald
cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.

Signification : Les logs sont maintenant plafonnés à 64 Mo.
Décision : Si vous avez besoin d’une rétention plus longue, exportez les logs hors‑site. La SD n’est pas votre SIEM.

Task 15: Confirm swap usage and disable swap on SD if appropriate (Pi)

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/var/swap file  512M   0B   -2
cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.2Gi       5.8Gi        92Mi       0.9Gi       6.3Gi
Swap:          512Mi          0B       512Mi

Signification : Un swap existe mais n’est pas utilisé ; vous avez beaucoup de RAM.
Décision : Désactivez‑le pour éviter l’usure et les pics de latence. Si vous êtes contraint en mémoire, déplacez le swap sur SSD ou acceptez le compromis en connaissance de cause.

Task 16: Disable swap (Pi)

cr0x@server:~$ sudo dphys-swapfile swapoff
swapon: /var/swap: swapoff failed: Invalid argument
cr0x@server:~$ sudo swapoff -a
cr0x@server:~$ sudo systemctl disable --now dphys-swapfile
Removed "/etc/systemd/system/multi-user.target.wants/dphys-swapfile.service".

Signification : Le swap est désactivé et le service est désactivé.
Décision : Surveillez la mémoire. Si des OOM kills apparaissent, vous avez fait le mauvais choix pour cette charge ; réactivez le swap sur un stockage de meilleure qualité.

Task 17: Spot a filesystem that remounted read-only (Pi)

cr0x@server:~$ dmesg -T | tail -n 20
[Mon Feb  5 11:02:41 2026] EXT4-fs error (device mmcblk0p2): ext4_journal_check_start:83: Detected aborted journal
[Mon Feb  5 11:02:41 2026] EXT4-fs (mmcblk0p2): Remounting filesystem read-only

Signification : ext4 a détecté un journal interrompu et s’est protégé en remontant en lecture seule.
Décision : Arrêtez les services intensifs en écriture, capturez les logs, et planifiez un fsck contrôlé ou une reconstruction. Continuer à fonctionner transformera le « récupérable » en « viande mystérieuse ».

Blague n°2 : La carte SD n’a pas « mouru aléatoirement ». Elle a lu votre objectif d’uptime et a choisi la violence.

Playbook de diagnostic rapide

Quand le Pi est lent, instable ou corrompt des données, vous n’avez pas le temps pour un debugging philosophique.
Vous avez besoin d’une courte séquence qui trouve le goulot d’étranglement avec une forte probabilité. Voici le playbook que j’utilise.

Premier : alimentation et sous‑tension (le plus rapide à prouver, le plus commun)

Exécutez vcgencmd get_throttled. Si non‑zéro, corrigez l’alimentation en premier.
Vérifiez dmesg -T | grep -i voltage pour des avertissements de sous‑tension (pas toujours présents selon la configuration).
Décision : échangez PSU et câble avant d’échanger des cartes SD. Les problèmes d’alimentation peuvent corrompre une carte neuve en quelques heures.

Second : erreurs de stockage (timeouts I/O, remounts, lecture seule)

Exécutez dmesg -T | egrep -i 'mmc|I/O error|timeout|ext4'.
Exécutez findmnt -no OPTIONS / pour voir si vous êtes en ro.
Décision : si vous voyez des timeouts mmc ou des aborts ext4, arrêtez de traiter ça comme un « problème logiciel ». Planifiez de réimaginer ou migrer.

Troisième : goulot de performance (démarrages lents, timeouts de services)

Mesurez avec fio (lecture/écriture aléatoire, dataset petit).
Vérifiez les gros émetteurs d’écriture : sudo iotop (si installé), ou utilisez sudo journalctl --disk-usage et les logs d’application.
Décision : si l’I/O aléatoire est catastrophique, remplacez la carte ou migrez vers SSD ; on ne peut pas régler un contrôleur lent par magie.

Quatrième : intégrité du système de fichiers (seulement après vérification de l’alimentation et du hardware)

Vérifiez l’état ext4 avec tune2fs -l.
Si vous devez réparer : faites‑le hors ligne ou depuis un mode recovery quand possible, pas alors que le système est à moitié en marche.
Décision : si la corruption revient, rebuild le système et corrigez la cause en amont (alimentation, média, charge d’écritures). Refaire fsck en boucle n’est pas une stratégie.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: “Filesystem is read-only” after a reboot

Cause racine : journal ext4 avorté à cause d’erreurs I/O ou d’une coupure de courant soudaine ; le noyau a remonté la racine en lecture seule pour prévenir d’autres dégâts.
Correctif : Vérifiez dmesg pour des erreurs ext4/mmc ; réparez l’alimentation ; lancez fsck hors ligne ; remplacez la carte SD si des erreurs I/O existent.

2) Symptom: Pi boots sometimes, hangs on others

Cause racine : contacts/lecteur SD marginaux, carte contrefaite, ou alimentation limite provoquant des échecs de timing durant l’initialisation SD.
Correctif : Essayez une autre carte et un lecteur connu bon ; réduisez les périphériques ; utilisez PSU/câble officiels ; confirmez les drapeaux de sous‑tension.

3) Symptom: “Kernel panic” or “VFS: unable to mount root fs”

Cause racine : système de fichiers racine corrompu, image incorrecte (mismatch 32‑bit vs 64‑bit est plus rare maintenant), ou erreurs de lecture SD.
Correctif : Reflashez et vérifiez avec cmp ; vérifiez avec sha256sum si vous avez un hash de référence ; remplacez la carte si la vérification échoue.

4) Symptom: apt updates are painfully slow and sometimes fail

Cause racine : mauvaises performances en écritures aléatoires ; la carte SD bride dpkg unpack et les opérations fsync.
Correctif : Utilisez une meilleure carte A1/A2 ou endurance ; déplacez la racine sur SSD si c’est un appareil de service ; réduisez les écritures en arrière‑plan.

5) Symptom: SD card suddenly shows smaller capacity or weird partitions

Cause racine : carte contrefaite à capacité falsifiée, ou table de partitions endommagée par un retrait non sécurisé.
Correctif : Reflashez depuis zéro ; validez la capacité avec un outil d’écriture complète sur une station ; achetez auprès de sources réputées.

6) Symptom: Performance degrades over weeks, then errors begin

Cause racine : wear leveling épuisant les blocs de rechange ; le contrôleur lutte, provoquant des pics de latence puis des défaillances.
Correctif : Remplacez la carte de manière proactive ; gardez plus d’espace libre ; passez à du média endurance ; déplacez les charges d’écriture lourdes sur SSD.

7) Symptom: Database corruption (SQLite, etc.) after outages

Cause racine : perte de puissance pendant des transactions d’écriture ; parfois aggravée par des paramètres fsync inadaptés ou un caching agressif du contrôleur.
Correctif : Corrigez l’alimentation ; utilisez un UPS ou un HAT supercap si nécessaire ; ajustez la durabilité de la DB en connaissance de cause ; envisagez de déplacer la DB sur SSD.

8) Symptom: “No space left on device” even though you think you have space

Cause racine : croissance des logs, du journal, ou blocs réservés ; les petites cartes se remplissent silencieusement puis échouent bruyamment.
Correctif : Inspectez l’utilisation disque ; plafonnez journald ; faites de la rotation des logs ; redimensionnez le système de fichiers ; utilisez des cartes plus grandes et gardez de la marge.

Listes de vérification / plan pas à pas

Checklist A: Reliable SD card install workflow (workstation)

Insérez le lecteur SD ; exécutez lsblk ; identifiez le périphérique amovible par la taille et HOTPLUG.
Démontez les partitions : sudo umount /dev/sdX*.
Optionnel si vous avez eu des bizarreries : sudo wipefs -a /dev/sdX.
Flashez :
- Préféré : Raspberry Pi Imager avec vérification activée.
- Manuel : sudo dd if=image.img of=/dev/sdX bs=4M conv=fsync status=progress.
Flush : sync.
Vérifiez : sudo cmp -n $(stat -c%s image.img) image.img /dev/sdX (ou calculez des hashes si vous avez une référence connue).
Éjectez proprement ; puis retirez.

Checklist B: First boot survival hardening (Pi)

Confirmez la santé de l’alimentation : vcgencmd get_throttled.
Vérifiez les erreurs de stockage : dmesg -T | egrep -i 'mmc|I/O error|ext4'.
Mettez à jour les paquets (oui, faites‑le) : sudo apt-get update et sudo apt-get upgrade. Puis redémarrez.
Plafonnez journald : définissez SystemMaxUse=64M (ou similaire) si les logs persistants ne sont pas essentiels.
Décidez du swap : si vous avez de la RAM, désactivez le swap SD ; sinon, gardez‑le et acceptez l’usure, ou déplacez‑le sur SSD.
Gardez de la marge : ne laissez pas la racine à 95% et soyez surpris quand elle se comporte mal.

Checklist C: Operational posture for “this must not die” Pis

Choisissez du média endurance ou migrez vers le démarrage SSD.
Achetez deux cartes identiques ; conservez-en une comme spare image testée que vous pouvez interchanger.
Mettez en place des sauvegardes (même un simple rsync des données critiques vers un autre hôte).
Surveillez les drapeaux de sous‑tension et les événements de remontage du système de fichiers.
Planifiez le remplacement : traitez les cartes SD comme des consommables avec un cycle de vie.

Trois mini-récits du monde de l’entreprise (anonymisés, plausibles et pédagogiques)

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe a déployé une flotte de Raspberry Pis comme collecteurs en edge pour des capteurs environnementaux. Le logiciel était solide : CPU modeste, petit buffer local,
et uploads périodiques en amont. Ils ont fait un pilote avec cinq appareils et ça a tourné pendant des semaines.

Le déploiement à quelques dizaines d’unités a bien commencé. Puis, deux semaines plus tard, des unités aléatoires ont commencé à tomber hors ligne. Pas toutes en même temps. Une ici, une là.
La rotation d’astreinte a eu la bonne tâche d’aller sur site re‑flasher des cartes SD.

L’hypothèse erronée était subtile : « Si le Pi démarre, l’alimentation est OK. » Ils avaient utilisé des blocs d’alimentation USB commodity et de longs câbles passés dans des boîtiers.
Sous charge normale le Pi allait bien. Lors de rafales de transmission du modem cellulaire (et un comportement des câbles au froid), la tension tombait juste assez pour provoquer des interruptions d’écriture.
Le replay du journal ext4 a masqué une partie ; d’autres fois il remontait en lecture seule.

La solution n’a pas été exotique : PSUs officiels, câbles plus courts, et un contrôle basique dans leur script de provisioning qui loggait vcgencmd get_throttled et refusait le statut « green » si jamais un drapeau apparait.
Les cartes SD ont arrêté de « tomber en panne ». Le logiciel a cessé d’être accusé d’ingénierie électrique.

La leçon : considérez l’alimentation comme faisant partie du sous‑système de stockage. Parce que c’en est.

Mini‑récit 2 : L’optimisation qui s’est retournée contre eux

Un autre groupe exploitait des Pis comme terminaux kiosque. Ils voulaient des temps de boot plus rapides et moins « d’usure disque », alors quelqu’un a proposé de monter la racine avec des options agressives :
intervalles de commit plus longs, barrières réduites, et quelques autres réglages empruntés à un post de forum écrit sur le ton assuré d’une personne qui n’a jamais porté de pager.

Les kiosques démarraient plus vite. Ils étaient plus réactifs. L’équipe a déclaré victoire et a déployé la modification massivement.
Puis la première micro‑coupure est arrivée. Une partie des kiosques est revenue avec un état applicatif incohérent, et quelques‑uns avec des systèmes de fichiers non nettoyés nécessitant une intervention manuelle.
« Mais nous avons réduit les écritures », dirent‑ils. Oui. Et vous avez aussi réduit la durabilité.

Le postmortem a été gênant mais productif. L’optimisation n’était pas malveillante ; elle était mal appliquée.
Tuner ext4 pour la performance en relâchant les garanties de flush est un compromis. Si vous avez aussi une alimentation imprévisible, vous venez d’échanger l’intégrité contre la vitesse sans acheter l’autre moitié du deal (stabilité électrique).

Ils ont annulé les options de montage les plus risquées, déplacé les plus gros caches générateurs d’écriture vers tmpfs, et travaillé sur la qualité d’alimentation.
Le temps de boot a légèrement augmenté ; le taux d’incidents a chuté drastiquement.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une petite équipe plateforme maintenait quelques Raspberry Pis pour l’automatisation de laboratoire : bancs d’essai, systèmes hardware‑in‑the‑loop, et quelques sondes réseau.
Rien de glamour, mais des gens en dépendaient. L’équipe avait une politique qui paraissait presque comiquement démodée : chaque Pi avait une carte SD « golden image » connue‑bonne,
et chaque changement d’OS était capturé dans un court script de provisioning.

Un lundi, après un événement de maintenance électrique du bâtiment, plusieurs Pis de labo n’ont pas démarré. La panique habituelle a commencé : « Est‑ce que la mise à jour a cassé quelque chose ? »
Mais l’équipe n’a pas débattu. Ils ont interchangé les cartes golden, restauré la dernière configuration via leur script, et étaient à nouveau en service rapidement.

Les cartes corrompues ont ensuite été analysées calmement. Il s’est avéré que c’était un mélange : une carte SD réellement usée et quelques systèmes de fichiers nécessitant réparation.
Le point clé : la récupération a été rapide parce que l’installation était reproductible. Ils n’ont pas eu besoin d’héroïsme ou de génie forensique à 9 h.

La pratique ennuyeuse était simplement : spare testés, provisioning scripté, et acceptation que les cartes SD sont des consommables.
Cela a sauvé la mise précisément parce que ce n’était pas ingénieux.

FAQ

1) Should I use Raspberry Pi Imager or dd?

Utilisez Raspberry Pi Imager sauf si vous avez une raison de ne pas le faire. Il gère la personnalisation et peut vérifier les écritures.
Utilisez dd quand vous avez besoin d’automatisation et que vous êtes discipliné sur la vérification et la sélection des périphériques.

2) What filesystem does Raspberry Pi OS use, and should I change it?

Généralement ext4 pour la racine, FAT32 pour le boot. ext4 convient et est bien testé. Changer de système de fichiers ne sauvera pas une mauvaise alimentation ou un mauvais média,
et ajoute souvent de la complexité sans bénéfice mesurable sur SD.

3) Is A2 always better than A1 for Raspberry Pi?

Pas toujours. Les cartes A2 peuvent nécessiter des fonctionnalités hôtes pour atteindre leurs meilleures performances, et certaines combinaisons se comportent étrangement sous I/O mixte.
Les cartes A1 endurance sont souvent le choix « ennuyeux et bon ». Si ça vous importe, faites des benchmarks sur votre modèle de Pi réel.

4) How do I know if my SD card is counterfeit?

Signes : reporting de capacité incohérent, échecs de vérification après flash, erreurs I/O aléatoires tôt dans la vie, et performances bien en dessous des attentes.
La mitigation la plus fiable est d’acheter auprès de sources réputées et de vérifier les images écrites avec cmp.

5) Why does my Pi suddenly remount root as read-only?

Parce que le noyau a vu des erreurs rendant les écritures risquées : journal ext4 avorté, erreurs I/O, ou timeouts.
Traitez‑le comme un symptôme soit d’une défaillance du média soit d’une alimentation instable, pas comme une « humeur Linux ».

6) Can I just run fsck and keep going?

Parfois oui. Mais si la corruption se répète, fsck soigne la blessure pendant que vous continuez à frapper au même endroit.
Corrigez l’alimentation, réduisez la charge d’écriture, et remplacez la carte si des erreurs I/O apparaissent.

7) What’s the single best way to avoid SD corruption?

Ayez une alimentation stable et évitez les écritures inutiles. Si vous voulez une seule « amélioration », passez au démarrage sur SSD USB sur les modèles Pi supportés.
Cela change tout le profil de fiabilité.

8) Should I disable journaling to reduce writes?

Non, pas sur des systèmes qui comptent. Désactiver le journaling peut réduire les écritures mais augmente le risque d’incohérence catastrophique après un crash.
Mieux : plafonnez les logs, déplacez les caches en RAM, et utilisez du média endurance.

9) How much free space should I keep on the SD card?

Gardez au moins 20–30% d’espace libre sur la racine pour la santé et les performances à long terme. Les systèmes de fichiers presque pleins se comportent mal,
et le wear leveling de la flash profite d’espace libre.

10) My workload is “light.” Do I still need endurance cards?

Si « light » signifie un capteur headless qui écrit un petit fichier une fois par heure, probablement non.
Si « light » signifie « il tourne Linux avec des logs, des mises à jour et une base de données », alors oui, l’endurance paie.

Prochaines étapes que vous pouvez réellement faire aujourd’hui

Si vous voulez un Pi basé sur SD qui se comporte comme une appliance, faites les actions suivantes dans l’ordre :

Achetez un média sensé : microSD endurance, 64–128 Go, source réputée. Votre temps coûte plus que la différence de prix.
Flashez et vérifiez : utilisez Raspberry Pi Imager avec vérification, ou dd + cmp. Aucune exception.
Corrigez l’alimentation : PSU officiel et bon câble ; confirmez que vcgencmd get_throttled reste propre sous charge.
Réduisez les écritures : plafonnez journald, désactivez le swap SD si possible, gardez de l’espace libre, et ne faites pas tourner des services bavards dont vous n’avez pas besoin.
Préparez la défaillance : conservez une carte spare testée (golden image) et une procédure de restauration qui ne demande pas d’inspiration.

Faites ça, et les cartes SD cessent d’être mystérieuses. Elles redeviennent ce qu’elles ont toujours été : un composant consommable dans un système que vous exploitez délibérément.