MASTAR
Concevoir un assistant IA personnel, 100 % local et privé : de la façade unique à un système multi-agents digne de confiance.
MASTAR est un assistant IA personnel que je conçois et pilote : un « second cerveau » qui tourne entièrement sur ma machine, sans cloud ni dépendance externe. Ce qui a commencé comme une expérimentation technique est devenu un vrai terrain de design produit : comment rendre un système multi-agents compréhensible, sûr et digne de confiance pour un humain, quand l'IA agit vraiment sur ses fichiers, sa mémoire et ses outils.
En bref
La plupart des assistants IA sont des boîtes noires dans le cloud : on ne sait pas ce qu'ils font vraiment, ni où vont nos données. J'ai voulu l'inverse, un assistant qui vit sur ma machine, qui ne fait jamais rien dans mon dos, et dont chaque action est traçable.
Le défi de design : des modèles locaux plus faibles que le cloud, une surface fonctionnelle qui grandit vite, et une exigence de confiance absolue dès qu'on laisse une IA toucher à de vrais fichiers.
Ma réponse tient en trois partis pris : faire de MASTAR une façade unique vers tous mes outils, rendre chaque décision de l'IA lisible (qui fait quoi, avec quelle preuve) et transformer la sécurité en expérience plutôt qu'en garde-fou caché.
Le tout construit de façon incrémentale et guidée par l'évaluation, pour prouver que chaque itération améliore le système sans le casser.
Le problème
Trois tensions à résoudre, identifiées dès le cadrage.
Confiance
Un assistant cloud est opaque. Dès qu'une IA peut supprimer un fichier, envoyer un mail ou modifier une config, l'utilisateur doit pouvoir comprendre et autoriser. Sinon c'est inutilisable.
Confidentialité
Mes notes, mon travail, mes projets clients ne doivent jamais quitter ma machine. Le local-first n'est pas une contrainte, c'est la promesse produit.
Fragilité des modèles
Un modèle local raisonne moins bien que le cloud. Le design doit compenser : clarifier au lieu de deviner, ancrer chaque réponse dans du réel, éviter l'hallucination par construction.
Comment donner à un utilisateur le contrôle et la lisibilité d'un système agentique, avec des modèles imparfaits, sans jamais sacrifier la vie privée ?
Trois principes directeurs
Avant toute interface, j'ai posé les règles non négociables qui cadrent chaque décision produit.
Jamais dans le dos
Toute action irréversible (supprimer, envoyer, payer) passe par une confirmation explicite. La détection se fait AVANT l'exécution, pas après : un verrou, pas une étiquette.
Façade unique
Tout outil branché (coffre de notes, Figma, demain mail et agenda) doit être actionnable depuis MASTAR. Une échelle d'accès claire : lire → écrire → ouvrir → piloter.
Local-first hybride
Tout reste local par défaut. On n'escalade vers une API que si la difficulté l'exige ET si la sensibilité de la donnée l'autorise. En cas de doute : on traite comme privé.
Mon rôle & la méthode
Sur ce projet, je porte la vision produit, l'architecture d'information, les parcours, le design system et la direction technique. Je conçois, je priorise, j'arbitre ; j'orchestre l'implémentation via des agents de code, et je fais la QA finale sur l'interface réelle.
Une méthode « preuve par le vrai chemin »
Règle de fer du projet : aucune fonctionnalité n'est « validée » sur une démo. On prouve sur le vrai flux d'exécution, avec des sorties brutes. Cette discipline a attrapé plus d'un faux positif, dont une sécurité qui semblait marcher mais ne protégeait rien.
Un design guidé par l'évaluation
Chaque changement du cœur de raisonnement est mesuré contre un jeu d'évaluations (cas de routage, mémoire, sécurité) rejoué à chaque itération. C'est ce qui m'a permis de faire évoluer le système en profondeur sans régressions silencieuses, et de chiffrer l'impact de mes décisions plutôt que de les supposer.
Défis de conception & décisions UX
Passer du mot-clé au raisonnement
La première version routait les demandes par une cascade de déclencheurs mots-clés. Fragile : « note ça dans le coffre » marchait, « garde une trace de ça » ratait.
J'ai repensé l'architecture autour d'un planificateur qui raisonne sur l'intention et choisit des outils déclarés, avec la clarification comme action de premier rang : face à une demande ambiguë, MASTAR pose une question au lieu de deviner. Un vrai geste de design pour compenser la fragilité des modèles locaux : rassembler du signal avant de s'engager.
Badge d'exécution réelle + trace d'agents
Rendre l'IA lisible et non-hallucinante
Le pire d'un assistant, c'est qu'il prétende avoir agi. J'ai conçu plusieurs dispositifs de traçabilité : un badge qui distingue une exécution réelle d'une réponse théorique ; une trace d'agents visible en direct (qui a routé, quel agent a répondu, en combien de temps) ; et des chiffres ancrés dans le code, recopiés verbatim depuis la sortie réelle plutôt qu'interprétés par le modèle.
Toute action sur un fichier affiche son chemin absolu : une preuve auto-vérifiable.
La sécurité comme expérience
Plutôt qu'un blocage sec, j'ai conçu un système de confirmation à trois niveaux (information, décision, autorisation) qui adapte la friction à l'enjeu. Une action irréversible est interceptée avant l'exécution et renvoie une demande d'autorisation explicite ; l'utilisateur confirme, et seulement alors l'action part.
J'ai doublé ça d'une console 360° : santé du système, consommation, journal d'audit complet, et surtout une file de validation où l'on approuve ou rejette ce que l'IA veut faire. Le contrôle devient visible et tangible.
Confirmation à 3 niveaux / console 360°
Mémoire & projets, sans surcharge
MASTAR se souvient sur cinq couches (session, historique, projet, faits durables, préférences) avec une logique propose → confirme : rien de durable n'entre en mémoire sans validation, et chaque fait est ancré sur un message réel, donc impossible à inventer.
Un système de projets à contexte isolé garantit que le spécifique d'un client ne fuit jamais vers un autre. Un besoin concret quand on mélange perso, portfolio et travail.
Un dashboard adaptatif
L'interface est une coquille modulable : un dashboard d'accueil (santé des services, briefing du jour, veille, métriques) qui se replie dès qu'on écrit pour laisser place à la conversation, des widgets activables par configuration, et un responsive complet (drawers sur mobile, cibles tactiles, safe-areas iOS).
J'ai maquetté sous Figma avant l'implémentation, pour arbitrer la densité et la hiérarchie visuelle en amont.
Du web à l'appareil : un client natif
Notifications qui n'arrivent pas, accès aux rappels bancal, push capricieux, écran de verrouillage purement cosmétique. Quatre irritants traités séparément pendant des semaines, jusqu'à ce que je les mette côte à côte : ils partageaient une seule racine. MASTAR était une application web servie par une machine sans écran, donc chaque capacité native de l'appareil devait être simulée. Aucun de ces irritants n'était réparable isolément.
La décision : traiter la cause. Le cerveau reste sur la machine (un téléphone ne fait pas tourner le modèle) et un client natif prend en charge ce que seul l'appareil sait faire : notifications, rappels et calendrier système, capture depuis n'importe quelle app, raccourcis vocaux.
Avant d'engager quoi que ce soit, j'ai dé-risqué à coût zéro : quatre capacités à prouver dans le simulateur, critère fixé à l'avance, aucune signature ni compte développeur. Une fois validées, la parité fonctionnelle avec la version web a suivi à l'itération suivante. La PWA reste en parallèle jusqu'à parité complète, sans bascule brutale.
L'architecture, comme différenciateur
Concevoir ce système m'a demandé de raisonner comme un designer et comme un architecte technique. Sans entrer dans le code, voici la structure que ces décisions produit ont façonnée.
Un cerveau local, une façade, des rails sûrs
Ce socle n'est pas de la plomberie : c'est ce qui rend les promesses produit (privé, sûr, traçable) vraies plutôt que déclaratives.
Résultats
En repensant le routage autour du raisonnement et de garde-fous déterministes, la précision d'intention est passée de 75,8 % à 86,7 % : plus intelligente et plus rapide. La bascule vers une vision unifiée a supprimé un modèle séparé, et ses plantages mémoire.
La boucle staging → validation → production est prouvée de bout en bout : MASTAR peut désormais évoluer en sécurité. Côté usage, il gère déjà tâches, rappels, capture rapide, briefing matinal, coffre de notes et recherche sémantique, accessibles depuis une app web et une app iOS native.
Ce que j'en retire
Sur un système agentique, la lisibilité et la confirmation ne sont pas des détails d'UX : elles conditionnent l'usage tout court.
Faire clarifier plutôt que deviner, ancrer les chiffres, afficher les preuves : autant de décisions de conception qui rendent utilisable un modèle imparfait.
Comprendre la RAM, le contexte des modèles, les rails de déploiement m'a permis de prendre des décisions produit réalistes et ambitieuses à la fois.
Prochaines étapes
La vision longue : un vrai second cerveau créatif, multimodal et connecté, toujours sous garde-fous.
Voix
Wake word, transcription et synthèse locales pour un mode ambiant mains-libres.
Intégrations
Mail, agenda, apps macOS, navigation web, avec une sécurité par intention, générique.
Agent de code
Un agent local qui améliore MASTAR sur les rails de staging, sous validation humaine.
Génération d'UI
Des réponses génératives : MASTAR compose ses propres widgets à la demande.