Accueil › À propos
À proposLuminisys est conçu et développé bénévolement pour les paroisses. J'y applique ce qui guide mon métier : partir du besoin réel, faire des choix durables et rester responsable du service jusqu'en production.
Tout est parti d'une question toute simple, posée par un curé à un paroissien développeur.
Don Henri, alors curé des paroisses du pays de Fayence, avait engagé une démarche de transformation pastorale. Dans ce cadre, il m'a demandé s'il serait possible de projeter les chants pendant la messe, pour que l'assemblée chante d'une seule voix sans chercher les paroles.
Je connaissais le piège : compiler chaque semaine tous les chants dans des fichiers PowerPoint est une corvée qui finit toujours par être abandonnée. Plutôt que de bricoler une solution fragile, je lui ai demandé trois ou quatre mois pour construire un véritable outil.
La première version était testée en conditions réelles, pendant une messe, et l'accueil a été immédiat et très chaleureux : les paroissiens levaient les yeux vers l'écran et chantaient. Au début, les équipes d'animation m'envoyaient le déroulé de leurs messes et je remplissais moi-même, semaine après semaine, la base de données du poste.
Le succès a vite fait apparaître une limite : tout passait par moi. J'ai donc mis un site web à la disposition des animateurs pour qu'ils préparent leurs célébrations en toute autonomie, depuis chez eux, à leur rythme.
L'application Windows avait été développée en WinDev, et le site en WebDev. Avant d'aller plus loin, j'ai fait le choix de migrer l'ensemble vers C# / .NET, une plateforme plus ouverte et plus pérenne. Cette refonte a permis de réunir les règles métier dans un cœur commun au site et à l'application, qui produisent désormais exactement le même résultat. C'est sur cette base que la synchronisation automatique a pu être construite.
Restait un dernier maillon : chaque dimanche, juste avant la messe, mon binôme ou moi récupérions le fichier de la célébration sur le serveur pour l'intégrer au poste avec une clé USB. Une clé oubliée, et la célébration pouvait se retrouver sans chants. J'ai alors rendu ce transfert automatique, sécurisé et redondant.
Sur une tablette, les chanteurs retrouveront tous les chants de la célébration sur une seule page, sans apporter chaque semaine une pile de feuilles.
Dans les églises où il n'est pas possible de projeter les chants, les paroissiens pourront les afficher sur leur téléphone en scannant un QR code.
Un site web et un logiciel Windows qui doivent produire exactement le même résultat : toute l'architecture découle de cette contrainte.
Les règles métier sont écrites une seule fois, dans une bibliothèque .NET commune.
Suppressions, fusions, doublons, format d'échange, génération des PDF : le site et l'application Windows n'en sont que des adaptateurs. L'un gère les droits et plusieurs paroisses, l'autre une paroisse unique sur un poste. Une règle ne se duplique jamais dans une interface.
WPF en MVVM, base locale SQLite, mode présentation piloté par télécommande.
Injection de dépendances, affichage des PDF par WebView2. Le mode présentation repose sur une machine d'état pilotée par les touches d'une télécommande (appuis courts, doubles, longs).
Blazor Server et Radzen, base MariaDB accédée par Dapper.
Gestion multi-paroisses et multi-utilisateurs, authentification à deux facteurs.
Les postes Windows se synchronisent avec le site par une API REST, avec un secours par mail.
Pages de changements avec curseur, versions de base pour détecter les conflits, fichiers comparés par empreinte SHA-256. Une modification faite des deux côtés n'écrase jamais rien : elle devient un conflit à arbitrer. Si l'API ne répond plus, un module asynchrone de secours par mail prend le relais ; seuls les messages signés avec la clé de l'église sont importés.
Authentification à deux facteurs, secrets chiffrés, échanges signés.
Mots de passe hachés (PBKDF2) et double authentification par code à usage unique sur le site. HTTPS imposé (HSTS) et débit limité par adresse IP sur l'API. Sur le poste Windows, les secrets de synchronisation sont chiffrés par DPAPI ; les messages de secours sont signés (HMAC-SHA256) et les installateurs signés (ECDSA).
Installateurs signés et retour arrière automatique en cas d'échec.
Les installateurs sont signés par un outil dédié. Un programme de mise à jour séparé sauvegarde la version en place, installe, vérifie le démarrage et revient en arrière si besoin. Un canal bêta permet de tester avant la diffusion générale.
Chaque projet a son projet de tests unitaires miroir (xUnit, Moq).
Les repositories SQLite sont testés sur une base temporaire réelle, le programme de mise à jour sur des dossiers temporaires.
Auto-hébergé sur un cluster Proxmox.
Une machine virtuelle pour IIS, une pour la base de données et une pour le pare-feu.
Luminisys