Si nous fermons,
voici le manuel.
Chaque service de QR vend du « à vie ». Presque aucun ne définit ce qui se passe si l'entreprise disparaît. Nous le faisons. Douze mois de préavis. Code source publié au mois six. Exports par compte livrés au mois neuf ; dans la même fenêtre, les codes marqués en opt-in sont publiés dans un dump public pour qu'un tiers puisse remettre le resolver en service sur son propre domaine à partir de la version open-source. Fermeture définitive au mois douze. heldqr.io en tant que tel n'est pas transmis à un successeur — les codes qui doivent survivre devraient utiliser un domaine personnalisé pour que le QR imprimé pointe vers un domaine que le client possède.
Cette page est la version publique de cet engagement. La spécification d'ingénierie qui la sous-tend se trouve dans docs/03-continuity-plan.md de notre dépôt — mise à jour en parallèle avec cette page. En cas de divergence, le dépôt l'emporte.
L'engagement, en termes simples.
Si Heldqr cesse son exploitation en continu — pour quelque raison que ce soit : fermeture, insolvabilité, rachat qui modifie les conditions, incapacité du fondateur à poursuivre — voici ce qui se produit, dans l'ordre. C'est le contrat. Tout ce qui se trouve à partir du §3 est l'ingénierie qui rend chacune de ces étapes exécutable sans héroïsme.
Ce qui est publié, et ce qui ne l'est pas.
Un engagement pris dès le premier jour, qui devient du code et des données aux mois six et neuf. Le dépôt placeholder existe dès aujourd'hui pour que chacun puisse vérifier que nous avons planifié cela avant d'en avoir eu besoin.
Le resolver — et seulement le resolver. Une surface délibérément réduite : router, controller, le schéma Ecto des codes, un cache ETS en read-through, la configuration runtime, et un Dockerfile qui démarre l'ensemble en une seule commande à partir du dump opt-in publié.
La vie privée est structurelle, pas décorative.
Le plan de continuité contraint dès le départ ce que nous pouvons collecter. Nous ne pouvons pas publier un dump de base de données qui contient des e-mails de clients, des adresses IP ou des journaux de scans détaillés — nous concevons donc le produit pour que ces éléments soit n'existent pas, soit soient trivialement séparables de la table de redirection. Les target_urls sont les données du client : nous les collectons parce que la redirection en a besoin, mais nous ne les publions jamais sans un consentement par code.
Ce n'est pas une conformité GDPR vue comme une case à cocher. C'est la contrainte d'ingénierie qui rend exécutables le dump public opt-in du mois neuf et les exports par compte sans revue juridique.
Ce que cela ne promet pas.
Des engagements honnêtes exigent des limites honnêtes. Trop promettre sur la continuité irait à l'encontre du but recherché. Ces limites figurent dans les Conditions d'utilisation, énoncées clairement, pour que les clients sachent exactement ce qu'ils achètent.
>Un plan de continuité que personne ne teste est une œuvre de fiction.
— Heldqr · 2026-04-22
Ces revues trimestrielles sont ce qui distingue ceci du marketing.