Tribalbyte
Accueil / Projets

Organiser le quotidien / Logigramme fonctionnel

Locker — coffre personnel synchronisé

Retrouver ses identifiants sur plusieurs appareils, y compris hors connexion, tout en gardant le contenu du coffre chiffré et la décision de synchronisation sous contrôle.

Cadre
Projet personnel / exploration professionnelle
État
Prototype avancé ; distribution Windows en préparation
Outils
Flutter / Dart · Go · C# / WinForms · libsodium · Windows et Android · MSIX

Le besoin

Retrouver ses identifiants sur plusieurs appareils, y compris hors connexion, tout en gardant le contenu du coffre chiffré et la décision de synchronisation sous contrôle.

L’analyse

Le besoin initial associe mobilité, confidentialité et continuité : un téléphone et deux ordinateurs doivent pouvoir modifier un coffre sans dépendre en permanence du serveur. L'analyse distingue le contenu métier, détenu par les clients, de l'autorisation des appareils et des révisions, gérées par le serveur.

Le travail fonctionnel porte particulièrement sur les situations difficiles : modifications concurrentes, perte de confirmation, révocation et restauration. Une évolution vers des coffres d'équipe a ensuite été cadrée séparément. La distribution Windows a également nécessité une décision de disponibilité : pour la première variante Store, le serveur fonctionne durant une session Windows ouverte, y compris verrouillée.

Le processus documenté

Du besoin au résultat

Logigramme fonctionnel
Parcours fonctionnel de Locker — coffre personnel synchroniséDéverrouiller le coffre local puis Associer l’appareil localement puis Modifier les fiches hors ligne puis Récupérer la révision distante puis Résoudre les conflits et envoyer puis Sauvegarder puis verrouiller. Point de contrôle : Modifications concurrentes ?. Confirmation perdue : retrouver le reçu avant tout nouvel envoi.01 Déverrouiller le coffre local02 Associer l’appareil localement03 Modifier les fiches hors ligne04 Récupérer la révision distanteModifications concurrentes ?À traiterConfirmation perdue : retrouverle reçu avant tout nouvelenvoi.Suite du parcours05 Résoudre les conflits et envoyer06 Sauvegarder puis verrouiller
Vue fonctionnelle du parcours. Le bloc latéral rend explicite le cas nécessitant un contrôle ou une intervention.

Règles de gestion

Ce que l’outil doit respecter.

  1. RG-01La phrase maître et les mots de passe en clair restent sur les clients ; le serveur conserve des coffres chiffrés.
  2. RG-02La récupération et l'envoi sont explicites ; deux modifications concurrentes sont conservées jusqu'au choix de l'utilisateur.
  3. RG-03L'association d'un appareil est autorisée localement sur le PC serveur par un jeton à usage unique valable 30 secondes.
  4. RG-04Une reprise d'envoi ne doit pas créer une deuxième révision lorsque le premier envoi a déjà été accepté.
  5. RG-05La date de sauvegarde n'est actualisée qu'après une copie persistée et vérifiée par le portable désigné ; un rappel intervient après 30 jours.
  6. RG-06Un appareil révoqué ne peut plus effectuer de nouveaux échanges ; la révocation ne supprime pas ses anciennes copies hors ligne.

Ce que ce projet démontre.

Formalisation d'exigences avec critères d'acceptation pour l'association, les conflits, les sauvegardes et le verrouillage.

Distinction entre version personnelle livrée, préversion d'installation et cible future de partage par équipe.

Arbitrage documenté entre disponibilité du serveur, contraintes de distribution et coût de déploiement.

Le niveau de réalisation ci-dessous distingue les fonctions présentes des vérifications qui restent à mener.

L’outil en images

Un parcours visible.

Consulter une fiche du coffre, secret masqué
Consulter une fiche du coffre, secret masquéCapture authentique du 7 octobre 2026, issue d’un test de l’interface Flutter de la version personnelle 0.1. Identifiants fictifs. Réutilisée ici ; l’application native n’a pas été relancée lors de cette revue.

État au 13 octobre 2026

Une réalisation, un périmètre précis.

Ce qui est réalisé

Clients Windows et Android, serveur de synchronisation, édition hors ligne, gestion des conflits et sauvegarde/restauration.

Console d'administration graphique et assistant d'installation pilote compilés.

Variante Store 0.3.0 préparée et contrôlée au niveau de l'empaquetage.

Ce qui a été vérifié

Le suivi du 7 octobre rapporte 15 tests Flutter et 6 tests Go réussis, ainsi qu'une intégration locale de deux clients avec coupure, conflit, révocation et restauration. Les nouveaux contrôles de distribution du 13 octobre sont documentés séparément.

Limites actuelles

Le MSIX Store 0.3.0 reste non signé et non installable ; validation du compte éditeur, certification et recette Windows réelle sont en attente. Les essais sur appareils physiques et les fonctions d'équipe restent à réaliser. La version personnelle n'a pas fait l'objet d'un audit indépendant.

Prochaine étape

Achever la distribution Store puis exécuter la recette sur les appareils réels avant d'engager le partage par équipe.

Exemples de critères de recette

Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.

  1. Modifier la même fiche hors ligne sur deux appareils, rétablir le réseau et constater que les deux variantes sont conservées jusqu'au choix explicite.
  2. Perdre la confirmation d'un envoi accepté puis relancer : retrouver le reçu sans double révision et restaurer une sauvegarde dans un coffre vide.

Parlons de votre projet

Un besoin concret.
Une première discussion.

Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.

Échanger avec Loïc