Death Plan Switch : un automate d'alerte décès pour développeurs indépendants
Sommaire
En bref
- Un outil auto-hébergé qui envoie une notification hebdomadaire. Si le développeur ne répond pas, il demande d'abord à ses proches, puis contacte ses clients et associés selon un calendrier prédéfini.
- Le créateur, développeur solo en Australie, l'a conçu pour protéger ses clients si quelque chose lui arrivait : domaines, serveurs, accès.
- C'est du PHP 8.1+, MIT, sans comptes ni service tiers, juste des emails.
Ce que dit la source
Un développeur solo gère les sites, domaines et hébergement de plusieurs clients. S'il meurt demain, personne ne sait où sont les ressources ni qu'il faut les chercher. Il a écrit ce plan : un document chiffré, le mot de passe chez un développeur backup, une copie chez son avocat. Ce qui manquait : un système qui détecte son silence et alerte la bonne personne au bon moment, sans affoler la famille pour une absence de trois jours.
- Fréquence hebdomadaire : un bouton à cliquer dans un email chaque lundi, ouvrir le lien ne suffit pas (les antivirus l'ouvriraient)
- Escalade prédéfinie : après 24h de silence, rappel aux deux adresses. À 48h, dernier rappel. À 72h, demande au proche de famille. À 120h (5 jours), notification aux autres contacts
- Pas de stockage de documents ni mots de passe, juste des messages disant où trouver les informations et qui appeler
- Nécessite un serveur PHP 8.1+, un compte SMTP, un cron qui demande l'URL toutes les 15 minutes, et HTTPS ; séparé des sites qu'il protège pour éviter une panne commune
- Installation via navigateur en quelques minutes, le créateur a testé sur lui-même pendant une semaine avec son proche et son développeur backup
Dans les commentaires
Débat partagé sur l'utilité réelle et les limites pratiques. Plusieurs commentateurs soulignent que la charge mentale d'une vérification hebdomadaire toute la vie n'est pas négligeable, et que Google Inactivity Manager propose depuis 2018 une fréquence beaucoup plus espacée. Autres objections : le marché visé est étroit (solo devs très autonomes), les accounts app store ne se transfèrent pas, l'outil repose sur la stabilité de son propre serveur et de son infrastructure mail.
- Plusieurs commentateurs suggèrent une fréquence mensuelle ou trimestrielle plutôt que hebdomadaire, notamment pour réduire la fatigue de vérification régulière et les faux positifs
- Prise en compte du 'bus factor' : un commentaire note que c'est un vrai besoin, mais d'autres pointent que le système suppose une maintenance éternelle de l'infrastructure auto-hébergée, ce qui contredit son objectif de pérennité
- Un commentateur relève que Google propose depuis longtemps une solution de ce type (Inactivity Manager), avec une fréquence trimestrielle, et demande pourquoi ce choix local plutôt que d'utiliser un service existant
- Objection majeure : même si l'outil notifie les contacts, cela ne résout pas l'accès aux comptes app store (Apple, Google Play) liés personnellement, ou l'hébergement mutualisé. Le 'what it is not' reconnaît qu'il ne peut garantir que ses serveurs fonctionnent à jamais
- Un commentateur suggère un modèle 'passif' (receive keep-alives au lieu de répondre à des emails) pour réduire la charge mentale de maintenance
- Débat sur le chiffrement : si les messages sont chiffrés de bout en bout, comment les destinataires les décryptent-ils après la mort du créateur ?
Alternatives citées : Google Inactivity Manager (fréquence trimestrielle, gratuit dans les comptes Google)
Notre lecture
Intéressant pour des solo devs très autonomes qui gèrent des clients et craignent un vide opérationnel, mais plusieurs points limitent son adoption réelle. Un : la fréquence hebdomadaire engendre une fatigue sur la durée et crée des faux positifs (vacances, email perdu). Deux : la solution ne couvre qu'une partie du problème, les contacts seront avertis, mais ils ne pourront pas accéder aux comptes app store ou à l'hébergement tiers sans une vraie planification d'entreprise (procédures documentées, tests annuels, accès délégués) que l'outil ne remplace pas. Trois : cela suppose que son propre serveur et son système de mail fonctionnent à jamais, ce qui est un pari techniquement hasardeux. Le produit adresse une vraie douleur pour un petit segment de marché, mais les alternatives existantes (Inactivity Manager de Google, planification manuelle avec avocat et tiers de confiance) offrent souvent un bon compromis coût-bénéfice sans technologie supplémentaire. À surveiller pour les solo devs avec vraiment aucune succession opérationnelle, mais pas une priorité pour la plupart.