Les premiers retours sont tombés vers le sixième mois. Des boîtiers qui ne redémarraient plus, ou qui repartaient figés en lecture seule, incapables d’écrire la moindre ligne. Pas un, pas deux. Une série entière s’y mettait, par vagues, sur un parc d’un millier d’unités installées en façade de points de vente. Chaque panne, c’était un déplacement sur site, le boîtier à démonter et une carte à remplacer. Le genre de défaut qui ne coûte presque rien à l’unité et très cher à la flotte.
On a d’abord soupçonné les cartes
Le premier réflexe a été de mettre en cause le stockage lui-même, et il était raisonnable. Une carte bas de gamme qui meurt, ça existe, et un lot défectueux expliquerait des pannes groupées. On a vérifié le fournisseur, les références, on a même chiffré le passage à de l’eMMC industrielle pour tout le parc (une mémoire flash soudée à la carte, plus endurante qu’une carte SD).
Un détail résistait. Les unités ne lâchaient pas au hasard : elles lâchaient toutes autour du même âge, six mois, quelle que soit leur position sur le terrain, quel que soit le lot. Un défaut de fabrication ne se synchronise pas aussi proprement. Quand toutes les pièces meurent au même âge, ce n’est pas la pièce le problème, c’est ce qu’on lui fait subir.
Ce que le système écrivait sans qu’on le regarde
En relevant les compteurs d’usure de la flash sur quelques unités encore vivantes, le constat était sans appel : un volume d’écritures sans rapport avec ce que l’application produisait. Ces boîtiers affichaient un média en boucle. Ils n’avaient quasiment rien à stocker. Et pourtant la flash encaissait des écritures jour et nuit, sans interruption.
La source, c’était le système d’exploitation. systemd-journald, le journal système, consignait ses entrées en continu sur la partition. Ajoutez les fichiers temporaires, quelques services qui touchent au disque par habitude, des caches qui se réécrivent, et vous obtenez un filet d’écritures qui ne se tarit jamais. Une cellule de mémoire flash supporte un nombre fini de cycles d’écriture. À ce régime, sur un support non durci, six mois suffisent à épuiser les zones les plus sollicitées. L’objet ne stocke rien d’utile, et il s’use quand même : pour ces cellules, seules comptent les heures sous tension, l’activité applicative n’y change rien.
Sortir la flash de la boucle
La correction ne se trouvait pas dans le catalogue des fabricants de cartes. Elle était dans l’image système. Il fallait que l’exploitation cesse, purement, d’écrire sur la flash.
Passer un objet embarqué en lecture seule, c’est monter sa partition racine en read-only et rediriger toute écriture courante (journaux, fichiers temporaires) vers la mémoire vive, au moyen d’un overlayfs. La flash ne reçoit alors plus que les rares mises à jour volontaires, et son usure cesse d’être proportionnelle au temps de fonctionnement.
Concrètement, on a reconstruit le firmware Linux des boîtiers. La racine passe en overlayfs, avec une couche d’écriture en tmpfs, c’est-à-dire en RAM. Les répertoires qui doivent absolument écrire y sont déportés. journald bascule en mode volatile, en mémoire, sans rien déposer sur le support. Au redémarrage, la couche RAM repart vierge, ce qui n’a aucune conséquence pour un objet dont l’état utile vit ailleurs, sur le serveur.
On a écarté l’autre piste, plus coûteuse et moins saine : remplacer tout le parc par de l’eMMC à haute endurance. Elle aurait reculé l’échéance sans toucher à la cause. Un support qui encaisse dix fois plus de cycles meurt en cinq ans au lieu de six mois ; pour un objet prévu pour tenir bien plus longtemps, on n’aurait fait que déplacer la panne dans le temps, en la payant au passage.
Six mois plus tard, le compteur ne bougeait plus
La mesure qui tranchait, c’était le compteur d’écritures du support. Après bascule, il restait plat en exploitation : la flash ne voyait plus que les mises à jour qu’on poussait nous-mêmes, quelques fois par an. Les unités reconstruites ont passé le cap des six mois, puis de l’année, sans une seule panne de stockage. Les séries suivantes sont sorties de production directement dans cette configuration.
Je retiens une chose de cet épisode, et je la pose désormais en ouverture de projet, pas en correctif. Un objet allumé en permanence qui laisse son système écrire ses journaux sur sa flash finira en panne. La seule inconnue, c’est le nombre de mois. Le mode lecture seule n’est pas une option qu’on ajoute quand le planning le permet. C’est le réglage par défaut d’un embarqué destiné à tourner des années sans qu’une main vienne le toucher. Ça se décide avant de figer l’image système.