Développer un logiciel de récupération hors ligne qui divise un secret en fragments

## Construire le logiciel de récupération pour qu'il fonctionne des années plus tard, dans les moments difficiles Considérez le logiciel de récupération comme une infrastructure qui peut rester intacte pendant des années avant que quelqu’un en dépende dans un moment difficile. Un défaut peut apparaître lorsqu’aucune personne chargée de la maintenance n’est disponible ; privilégiez donc une correction durable plutôt qu’un achèvement rapide. - Comprenez le système existant avant de le modifier, y compris les raisons de ses limites et de ses conventions. - Respectez les modèles et les normes établis au lieu d’introduire une exception qui ne serait pratique que localement. - Concevez des instructions, des messages et des interfaces pour des personnes qui peuvent manquer de connaissances techniques, être dépassées ou traverser un deuil. - Vérifiez le résultat réel, et non uniquement l’achèvement de la modification attribuée. Le soin, l’empathie, la portabilité et l’exploitabilité à long terme sont des exigences d’ingénierie, pas des finitions facultatives. ## Suivre tout ce qui est lié avant de modifier ou retirer une fonctionnalité Effectuez une recherche avant d’ajouter une constante, une fonction auxiliaire, un type, une liste ou une source de configuration. Localisez la définition de référence et faites-en dériver les autres éléments afin que des copies parallèles ne divergent pas. - Avant de modifier ou de retirer une fonctionnalité, suivez chaque élément lié dans le code, les styles, les traductions, les types, les tests, les commentaires, la documentation et la configuration de compilation. - Retirez complètement le comportement obsolète. Ne le mettez pas en commentaire, ne le masquez pas au moyen du style et ne le laissez pas derrière une condition. - Après la modification, recherchez à nouveau les identifiants et les notions associées afin de trouver délibérément les références restantes, plutôt que de les découvrir par surprise. - Examinez les différences finales pour repérer les modifications sans rapport, la logique dupliquée, le code mort et le nettoyage incomplet. Une fonctionnalité n’est pas retirée tant que l’ensemble de son graphe de dépendances et de références n’a pas été traité. ## Partager un seul cœur cryptographique entre la ligne de commande et le navigateur Conservez les opérations cryptographiques et les autres comportements essentiels dans une implémentation partagée utilisée par les chemins de ligne de commande et de navigateur. Les adaptateurs légers peuvent différer, mais la logique sensible pour la sécurité, les constantes, les formats et les règles de validation doivent avoir une seule source de référence. - Avant toute modification, déterminez quel environnement d’exécution prend en charge la création, la récupération, la mise en paquet, le comportement de l’interface utilisateur et le déploiement. - Utilisez le code natif du navigateur pour un chemin léger de récupération hors ligne lorsque cela convient, et un module de navigateur compilé pour la création lorsque cette limite améliore la réutilisation ou la portabilité. - Produisez des variantes hors ligne et assistées par le réseau au moyen d’indicateurs de fonctionnalité à la compilation, afin que l’artefact hors ligne ne contienne aucun code réseau inutilisé. - Exposez les fonctions compilées au moyen d’une petite passerelle explicite au lieu de dupliquer leur comportement dans le langage hôte. - Maintenez des choix cohérents d’environnement d’exécution et de modules entre les paquets. Lorsque des ressources intégrées créeraient une dépendance circulaire, chargez le module généré au démarrage de l’application et injectez ses octets au moyen d’une interface explicite au lieu de forcer le cycle. ## Récupérer entièrement hors ligne et n'utiliser qu'un chiffrement éprouvé Les artefacts de récupération autonomes doivent pouvoir s’ouvrir localement sans installation et achever la récupération sans serveur ni connexion réseau. Chaque paquet distribué doit rester autonome et indépendant du référentiel d’origine. - N’autorisez l’accès au réseau que pour des variantes limitées et documentées, comme un artefact à déverrouillage programmé qui consulte brièvement une balise externe ou une page auto-hébergée qui récupère son archive sur le même serveur. - Maintenez chaque artefact autonome destiné à un destinataire entièrement hors ligne, même lorsqu’une variante facultative avec serveur existe. - Veillez à ce qu’un nombre de fragments de clé inférieur au seuil requis ne révèle aucune information sur le secret, y compris par l’intermédiaire de métadonnées ajoutées. - Utilisez des mécanismes établis de chiffrement, de partage de secret à seuil et de verrouillage temporel ; n’inventez jamais de primitives cryptographiques personnalisées. - Maintenez toute couche de verrouillage temporel à l’intérieur de la couche de chiffrement principale pour assurer une défense en profondeur. - Exigez des tests, une revue et une justification claire pour chaque modification cryptographique. N’ajoutez au chemin de récupération aucune télémétrie, analyse, police distante ni dépendance de distribution de contenu ni autre exigence réseau dissimulée. ## Garder stable le format des paquets et y intégrer tout ce qu'il faut pour récupérer Traitez l’agencement du paquet, le format de la charge chiffrée, l’encodage des fragments de clé et les étapes de récupération comme des éléments du protocole. Leur modification exige une planification de migration, des données de test mises à jour, des tests de compatibilité et une raison documentée. - Faites fonctionner l’expérience de récupération sur différentes plateformes, différents navigateurs et dans différentes langues. - Intégrez les scripts, les styles, les modèles et les autres ressources nécessaires au lieu de dépendre de services externes ou de formats éphémères. - Incluez dans le paquet de chaque destinataire des instructions claires en texte et sous une forme imprimable, les métadonnées de l’archive chiffrée et une page de récupération personnalisée. - Lorsque le manifeste chiffré fait 10 MB ou moins, intégrez-le à la page personnalisée afin que la récupération fonctionne sans fichier séparé ; respectez toute option explicite qui désactive cette intégration. - Laissez la création depuis le navigateur intégrer automatiquement les manifestes admissibles lorsqu’aucun réglage distinct ne remplace ce comportement. - Évitez que les personnes qui créent ou récupèrent des paquets dépendent à l’exécution d’outils de développement. Ne promettez pas de révocation après la distribution des fragments de clé et n’affirmez pas que le système est garanti de fonctionner éternellement. Recherchez la durabilité sans exagérer la certitude. ## Écrire d'abord un test qui échoue et ajouter des tests navigateur pour les pages modifiées Écrivez d’abord un test qui échoue, observez cet échec, puis faites réussir le test. Un test dont l’échec n’a jamais été observé ne vérifie peut-être pas le comportement prévu. - Ajoutez un test au niveau du navigateur pour chaque modification qui touche une page de récupération ou de création dans le navigateur. - Utilisez des tests unitaires et d’intégration ciblés pour la logique essentielle, le traitement des archives, la configuration et le comportement des commandes. - Exécutez des tests de navigateur de bout en bout lorsque vous modifiez la structure HTML, le code du navigateur, des styles qui influent sur la disposition ou la visibilité, ou des liaisons compilées du navigateur. - N’exigez pas de tests de navigateur lents pour des modifications limitées aux traductions, à la documentation, aux ajustements de texte ou à la seule logique interne lorsque celle-ci ne peut pas affecter le comportement du navigateur. - Exécutez vous-même les tests pertinents avant d’annoncer la fin du travail ; ne laissez pas la vérification à quelqu’un d’autre. Après toute modification, recherchez les termes associés, reconstruisez les artefacts concernés, exécutez les tests appropriés et examinez le résultat. ## Utiliser les commandes de compilation et de test du dépôt plutôt que des outils improvisés Comprenez toute la chaîne de compilation, depuis la compilation du code de l’interface, en passant par les modules du navigateur, jusqu’au binaire final de ligne de commande. Les scripts générés et les modules compilés peuvent être intégrés à des étapes ultérieures ; l’ordre des commandes fait donc partie de la correction. - Utilisez les commandes canoniques du référentiel pour la compilation, les tests, la commande lint, les sites statiques et les serveurs de développement. - Utilisez la commande d’encapsulation des tests du projet au lieu d’appeler directement l’exécuteur de tests du langage lorsque les ressources générées doivent exister avant la compilation ou l’intégration. - N’exécutez la commande documentée plus ciblée pour un test individuel que lorsque ses prérequis ont déjà été produits. - Réservez les ensembles de tests dépendant du réseau aux modifications qui nécessitent ces intégrations. - Si une dépendance ou un outil de compilation est indisponible, entrez dans l’environnement de développement reproductible déclaré par le référentiel au lieu de le remplacer par un exécuteur de paquets improvisé. Créez les artefacts statiques à partir de sources intégrées et maintenez les artefacts privés de récupération hors du déploiement du site public, sauf si la conception de la version les inclut explicitement. ## Écrire des textes calmes et clairs pour des personnes face à une tâche stressante Rédigez les textes destinés au public comme si chaque mot avait été choisi pour une personne confrontée à une tâche lourde de conséquences et stressante. La bienveillance doit venir de la clarté, du rythme et de l’anticipation plutôt que d’un réconfort mis en scène. - Préférez une langue humaine et directe aux formulations techniques : décrivez l’action suivante sans obliger la personne à déchiffrer l’implémentation. - Adressez-vous directement aux personnes et évitez les instructions passives lorsqu’une phrase active et claire est possible. - Employez des termes cohérents et adaptés au public. Dans les textes destinés au public externe, préférez « personnes en qui vous avez confiance » et « fragments » ; dans les instructions destinées aux bénéficiaires, des termes relationnels comme « amis » peuvent convenir. - Évitez les points d’exclamation, les mots de remplissage, les grandes déclarations, les formulations mécaniques et l’enthousiasme forcé. - Utilisez des tirets cadratins entourés d’espaces plutôt que des doubles traits d’union ou des tirets sans espaces. - Gardez les messages d’état concis mais humains, et communiquez la réussite avec calme au lieu de la passer sous silence. Privilégiez un langage visuel doux, chaleureux et non institutionnel, avec un contraste modéré. Centralisez les valeurs de la palette, évitez le noir pur, le rouge vif et le bleu institutionnel, et maintenez toute exception visuelle délibérée isolée et documentée. ## Mettre à jour la documentation et rédiger l'historique selon ce que l'utilisateur remarque Lorsqu’un comportement change, mettez à jour la documentation, les consignes pour les contributeurs et les instructions opérationnelles concernées dans la même modification. Les notes d’architecture doivent expliquer les limites d’exécution, les ressources générées, les exceptions réseau et les commandes nécessaires pour reproduire les résultats. - Maintenez les instructions de configuration et de compilation synchronisées avec l’implémentation. - Mettez à jour les données de test et les consignes de migration lorsqu’un format stable change. - Rédigez les entrées du journal des modifications en fonction de ce qui change pour la personne qui utilise le logiciel. - Commencez par le résultat visible pour le public et n’ajoutez que le contexte d’implémentation nécessaire à sa compréhension. - Omettez les remaniements internes et la réorganisation du code, sauf s’ils modifient le comportement observable. Lisez les entrées voisines avant d’en rédiger une nouvelle afin de préserver la cohérence de la voix et du niveau de détail. ## Laisser le contributeur relire et soumettre lui-même ce qui part vers l'extérieur Avant toute action qui écrit dans un outil externe de suivi des problèmes ou un service d’hébergement de code, lisez la politique de contribution du projet. Lorsque cette politique exige une responsabilité humaine, arrêtez-vous avant la publication et expliquez que la personne contributrice est responsable de chaque ligne de code et de texte. - Présentez la différence proposée, le message de commit ou la description de la contribution pour une revue humaine. - Demandez à la personne contributrice de modifier le contenu avec ses propres mots, de remplir honnêtement les attestations et d’effectuer elle-même le commit, le push et la soumission. - Retirez avant la soumission les pieds de page générés, les lignes de coauteur, le contenu de remplissage et l’attribution automatisée. - N’effectuez pas l’écriture externe, sauf si la personne contributrice insiste explicitement après avoir reçu l’explication de l’exigence de responsabilité. - Si elle insiste tout de même, gardez le message concis et direct, n’ajoutez aucune attribution automatisée et répétez une seule fois l’exigence de revue humaine. L’aide à la modification locale et l’inspection en lecture seule ne déclenchent pas ces restrictions d’écriture externe. L’automatisation des versions doit continuer à exécuter des compilations, des tests, des contrôles lint, des vérifications de navigateur, un empaquetage multiplateforme et des sommes de contrôle, ainsi qu’à générer des artefacts représentatifs avant publication.