Les registres papier des cimetières sont à la fois un patrimoine juridique réel et un point de fragilité évident. Un dégât des eaux, un incendie, voire simplement les décennies qui passent suffisent à rendre une information illisible. Pour les communes rurales situées en zone blanche, le problème se double d’une contrainte pratique. En effet, sans connexion Internet stable, les solutions cloud classiques ne sont tout simplement pas envisageables.

Les registres papier des cimetières sont à la fois un patrimoine juridique réel et un point de fragilité évident. Un dégât des eaux, un incendie, voire simplement les décennies qui passent suffisent à rendre une information illisible. Pour les communes rurales situées en zone blanche, le problème se double d’une contrainte pratique. En effet, sans connexion Internet stable, les solutions cloud classiques ne sont tout simplement pas envisageables.

C’est là qu’un micro-serveur Edge local sous Raspberry Pi devient une vraie nécessité. Ce n’est pas une promesse technologique abstraite, mais un dispositif qu’on peut tenir dans la main, brancher dans le bureau du secrétaire de mairie et qui tourne en autonomie complète.

Ce que dit le CGCT et pourquoi ça compte vraiment

La responsabilité du maire, au-delà du symbolique

La gestion d’un cimetière municipal engage la responsabilité personnelle du maire. C’est inscrit noir sur blanc dans le Code Général des Collectivités Territoriales (CGCT). L’article L. 2223-1 lui confie la police des funérailles et des lieux de sépulture, ce qui inclut la tenue d’un registre de cimetière consultable à tout moment. L’article L. 2223-3 encadre les conditions d’inhumation dans les cimetières communaux.

Concrètement, si une famille conteste une inhumation parce que les données enregistrées sont incomplètes ou erronées, la commune est exposée. Ce n’est pas hypothétique. Des contentieux de ce type arrivent, surtout dans les petites communes où les registres n’ont pas toujours été tenus avec la même rigueur d’une décennie à l’autre.

Vos agents devraient pouvoir retrouver une concession en quelques clics, depuis leur poste, sans devoir aller fouiller dans des cartons. C’est une question de qualité de service, mais aussi de sécurité juridique.

Reprises de concessions : un terrain miné sans traçabilité

Les procédures de reprise de concession, encadrées par les articles L. 2223-17 et suivants du CGCT, exigent une traçabilité rigoureuse à chaque étape. Chaque concession à terme doit être suivie, son état d’abandon documenté, et les ayants droit contactés selon un protocole précis.

Sans registre numérique, c’est une source permanente d’erreurs : 

• une sépulture reprise par confusion avec une autre, 
• une famille non prévenue, 
• une date mal reportée. 

Avec un système bien structuré, ces confusions disparaissent presque entièrement; parce que la fiche numérique associe directement la tombe, le défunt, les coordonnées des ayants droit et les dates critiques.

L’architecture technique : ce que le Raspberry Pi 5 change vraiment

Pourquoi pas simplement un vieux PC de bureau ?

Un ordinateur inutilisé traîne souvent dans un coin de mairie. Cependant, un Raspberry Pi 5 consomme environ 5 watts en charge, contre 60 à 100 watts pour un ordinateur de bureau. Sur une année, ça représente une différence notable. Il est silencieux, tient dans un tiroir et redémarre proprement après une coupure électrique, ce qui, dans une commune rurale, n’est pas un détail anodin.

Son vrai avantage dans ce contexte est le traitement des données localement, sans dépendance permanente au réseau. Une coupure de fibre ne bloque pas l’accès aux fiches de sépultures.

Ce qu’on met dedans

Pour une utilisation en production, c’est-à-dire, pas juste un test, voici la configuration recommandée :

• Raspberry Pi 5 avec 8 Go de RAM : la version 4 Go fonctionne, mais la base de données respire mieux avec 8 Go, surtout si on ajoute une interface cartographique
• SSD NVMe via le bus PCIe intégré, et non une carte microSD : la différence de durabilité et de vitesse est significative . En effet, le Pi 5 atteint des débits supérieurs à 400 Mo/s en lecture sur ce type de stockage.
• Boîtier aluminium avec dissipateur thermique actif : une pièce qu’on a tendance à négliger, mais qui fait toute la différence pour une machine allumée en permanence dans un local parfois mal ventilé

Le tout fonctionne sous Docker, c’est-à-dire, chaque service (base de données, interface web, synchronisation) tourne dans son propre conteneur. Ça simplifie les mises à jour et évite les conflits entre applications. C’est bien utile quand personne ne veut toucher à un système qui « fonctionne déjà ».

La synchronisation : ni tout-cloud, ni tout-local

Le serveur enregistre toutes les modifications en local d’abord. Les fiches de sépultures, les dates de concession, les coordonnées des ayants droit sont tous stockés sur le SSD en mairie. Si Internet tombe pendant une semaine, le travail continue normalement.

Quand la connexion revient, une synchronisation automatique met à jour la copie hébergée sur cloud souverain. Un journal horodaté trace chaque opération, ce qui permet de retracer exactement ce qui s’est passé en cas de doute.

Cette architecture hybride n’est pas de la sophistication pour le plaisir. Elle répond à une contrainte réelle. Les communes rurales ne peuvent pas dépendre d’un système qui s’arrête dès que la fibre est coupée.

Du registre papier au SIG funéraire : comment ça se passe sur le terrain

La première étape : marcher dans le cimetière

Avant de numériser quoi que ce soit, on commence par un audit physique. Un technicien relève les sépultures existantes, les croise avec le registre papier, et note les divergences. Il y en a presque toujours : 

• une stèle sans registre correspondant, 
• une date d’inhumation mal reportée, 
• une concession dont personne ne sait plus très bien si elle est encore active.

Ces écarts ne sont pas gênants en soi, ils font partie de l’histoire de toute commune. Ce qui compte, c’est de les identifier avant de les transférer dans le système numérique, pas après.

Chaque sépulture reçoit ensuite sa fiche individuelle avec le nom du défunt, la date d’inhumation, le type de concession et les coordonnées des ayants droit. La position dans le plan est géolocalisée, et des photographies des stèles s’y ajoutent pour un suivi visuel de l’état du monument. Ce dernier point est souvent sous-estimé. Repérer visuellement qu’une stèle se dégrade permet d’anticiper les procédures d’abandon, plutôt que d’attendre qu’une famille revienne après vingt ans d’absence.

Pour une commune de taille moyenne, l’ensemble de la démarche tient en moins de trois mois.

Le suivi des échéances : là où le numérique fait vraiment la différence

Gérer manuellement les échéances de concession est un vrai parcours du combattant pour la mairie, et le logiciel de cimitière répond parfaitement à ce besoin. Les alertes se perdent, les courriers s’oublient, et une procédure mal engagée expose la commune.

Le système génère automatiquement des notifications à 24 mois, 12 mois, puis 6 mois avant l’expiration d’une concession. Si la famille ne répond pas, la commune peut engager la procédure légale d’état d’abandon conformément au CGCT. Ceci est accompagné d’un historique complet des tentatives de contact disponible en quelques clics. Ce journal est une protection réelle devant le tribunal administratif si une famille conteste ultérieurement.

Ce que ça coûte et comment protéger ce qu’on construit

Le matériel

Quatre composants suffisent à monter un serveur opérationnel en mairie. Rien de superflu, mais rien d’oublié non plus.

Composant	Rôle	Coût indicatif
Raspberry Pi 5 (8 Go RAM)	Serveur Edge principal	85 €
SSD NVMe 512 Go	Stockage local haute vitesse	70 €
Boîtier aluminium + refroidissement	Stabilité thermique	55 €
Alimentation officielle + accessoires	Installation complète	40 €
Total matériel		~250 € HT

Pour une commune qui n’a pas les moyens d’investir dans un serveur dédié à plusieurs milliers d’euros, c’est un point d’entrée réaliste.

La stratégie de sauvegarde

Un investissement de 250 € ne vaut rien si les données disparaissent avec la machine. La règle 3-2-1 s’applique ici sans exception, c’est-à-dire, trois copies des données, deux supports physiques distincts, une copie hors site.

Copie	Support	Localisation	Fréquence
Copie 1	SSD NVMe (Raspberry Pi)	Mairie	Continue
Copie 2	Disque dur externe USB	Coffre ignifugé en mairie	Quotidienne
Copie 3	Cloud souverain	Hébergement distant	Quotidienne

Si le Raspberry Pi tombe en panne, les données sont sur le disque dur externe. Si la mairie brûle, elles sont dans le cloud. Ce n’est pas du pessimisme, c’est plutôt la condition minimale pour que le projet ait un sens sur la durée.