Vos agents collaborent.
Vous gardez la main.

La réponse traverse.
Le propriétaire décide.

Guillaume veut savoir si le dépôt de Julie gère le mode sombre. Son agent pose la question via une capacité publiée par Julie. Elle autorise la demande et relit la réponse avant qu’elle parte.

1. Une question et une raison. L’agent choisit dans les capacités publiées. La demande reçue est une donnée non fiable, validée avant exécution.
2. Un accord pour cette demande. Le propriétaire peut autoriser une fois, refuser ou répondre plus tard.
3. Une exécution encadrée. Les outils, le budget et la forme de la réponse sont fixés par la capacité avant l’appel au modèle.
4. Une relecture quand c’est sensible. Le propriétaire relit le résultat avant son envoi. Une sortie invalide est rejetée.
5. Une réponse et une trace. Le demandeur reçoit le résultat autorisé. Un reçu signé conserve des empreintes et des métadonnées.

Quatre niveaux d’échange.
Un cinquième exclu.

Chaque niveau a ses propres contrôles. Seul le niveau 3 existe aujourd’hui ; l’ordre de livraison prévu est 3, puis 1, 2 et 4.

Un propriétaire sans agent

Il peut répondre à la main dans le panneau, par un texte ou un fichier texte, avec le même consentement et le même reçu (existant, T4.3). Laisser un agent inclus répondre après accord, avec un modèle choisi par le propriétaire, reste à faire (T4.8).

Un contexte partagé, sans index central

Chaque fait publié reste chez son propriétaire, signé, daté, avec son public (existant, T4.4). Reste à faire (T4.12) : un catalogue de sujets sans contenu, pour savoir à qui demander, et une boîte de suggestions que l’humain valide. Personne n’écrit chez un autre.

Deux confirmations pour les agents compatibles.

Ce parcours existe dans le panneau local (T3.3, T4.5). Il passe ses tests sur fixtures ; la recette humaine sur un Mac neuf reste à faire (T3.4). Aucun modèle ni abonnement n’est nécessaire pour raccorder un agent ou consulter l’équipe.

1. Analyser ce Mac. Lecture locale des configurations connues. Aperçu des agents compatibles, des destinations et des modifications proposées ; aucune valeur de secret affichée et aucun serveur découvert exécuté.
2. Connecter les agents sélectionnés. Validation de la sélection, sauvegarde des configurations et ajout des outils drop. Chaque agent reçoit son propre résultat : connecté, absent, non pris en charge ou en erreur.

Treize clients MCP sont détectés, avec leurs configurations globales et par projet (T4.5). Sept sont raccordés automatiquement : Claude Code, Claude Desktop, Cursor, Codex, Gemini CLI, VS Code et Cline. Pour OpenCode, Devin Desktop (ex-Windsurf), Zed, goose, Roo Code et JetBrains AI, le panneau donne la configuration à copier. La détection est déterministe : aucun modèle ne fouille la machine.

ChatGPT n’accepte qu’un serveur MCP distant en HTTPS. La passerelle publique qu’il lui faudrait n’est pas livrée (T2.13) : c’est une option cloud mise de côté, que le profil privé refuse. Une entreprise peut aussi interdire toute passerelle par sa politique (T4.10).

Ce qui reste une étape séparée

Installer l’app, accorder une permission système, rejoindre une équipe par invitation, choisir un modèle ou en télécharger un ne sont pas inclus dans les deux confirmations. Une équipe hors ligne n’empêche pas le raccordement local : le panneau affiche cet état à part.

Revenir en arrière

Le parcours sauvegarde les configurations et évite les doublons si l’on recommence. Un fichier modifié depuis l’analyse ou illisible est refusé sans être écrasé. Le retrait d’un agent enlève seulement l’entrée ajoutée par drop, même si un autre outil a modifié le fichier entre-temps. Chaque agent a son propre résultat. Ces comportements sont vérifiés par des tests, pas encore par une recette humaine.

Le consentement et le suivi sont accessibles dans la barre de menus du Mac. Windows (T3.7) viendra ensuite, puis Linux (T3.8), avec une validation propre à chaque plateforme.

Trois façons de se connecter.

Chaque machine utilise un Node drop avec sa propre identité. Le runner exécute la capacité chez son propriétaire, dans le cadre prévu. A2A suppose des adresses HTTPS joignables : il ne fournit ni découverte locale ni traversée des pare-feu domestiques. drop doit donc fournir la connexion.

Par défaut, aucun relais de secours. Le panneau permet de choisir un relais iroh : le vôtre, celui de l’équipe, ou un relais de test d’un tiers, refusé en profil privé. Sans relais, deux pairs derrière un routeur ne se joignent pas, et l’app le dit. Le chiffrement de bout en bout reste actif dans tous les modes.

MCP pour les outils, A2A pour les agents

drop ne concurrence pas A2A : il l’implémente et s’y place comme couche de consentement humain. MCP raccorde l’agent à ses outils drop et permet des capacités fondées sur des sources déjà connectées. Les ponts A2A entrants et sortants existent dans le prototype ; ils ne remplacent pas les règles d’autorisation et de sortie.

Une capacité décrit l’entrée, la sortie, les outils utilisables, la sensibilité et le budget. La question reçue ne peut pas élargir ce contrat. Le résumé d’erreurs de production peut fonctionner sans modèle ; les questions sur un dépôt ou une source MCP nécessitent un modèle adapté.

Aucun service externe obligatoire

L’organisation garde la maîtrise du relais et des destinations autorisées. Un déploiement entièrement interne inclut aussi les modèles, les connecteurs et les agents A2A joints. Existant (T4.10) : une politique signée, déployée par l’informatique, fixe les clients et les fournisseurs de modèles autorisés, impose le relais interne et interdit les passerelles publiques. Le poste l’applique et le relais la vérifie à nouveau.

Garder le modèle que vous avez déjà.

La première option est votre endpoint existant, choisi explicitement : un modèle sur votre Mac ou un service interne d’entreprise. Une capacité déterministe évite tout appel à un modèle quand elle suffit.

Pour une équipe sans modèle, Ollama et Qwen3.5 4B ou 9B sont des candidats à évaluer. Leur téléchargement doit être consenti. Ils n’ont pas encore été mesurés pour les capacités drop : mémoire, latence, qualité des réponses et fiabilité des appels d’outils restent à qualifier (T3.2).

Un service cloud gratuit reste distant. Dans la cible privée, une panne du modèle doit produire une erreur visible ; aucun repli vers un fournisseur externe n’est autorisé.

Qui reçoit quoi ?

La confidentialité dépend de tout le chemin de la demande. drop contrôle ce qui passe par drop ; un connecteur MCP, un modèle ou un agent A2A choisi par le propriétaire peut avoir ses propres flux, que drop ne voit pas.

Le profil privé limite les destinations réseau du Node à des adresses privées explicites, sans DNS ni redirection. Sa recette (T3.1) a tourné avec Internet bloqué, sur fixtures. Le prototype n’envoie aucune télémétrie. Un vrai modèle et des agents réels restent à qualifier (T3.2).

Les outils fixés à l’avance, la validation de sortie, le scanner de secrets et la relecture forment plusieurs protections. Le journal local garde des reçus signés (empreintes et métadonnées), pas une copie de ce qui est sorti. Ils ne remplacent pas une revue de sécurité indépendante et ne permettent pas de promettre « zéro fuite ».

Le prototype actuel, côté développeur.

Le dépôt est public (github.com/memolabs-dev/drop). Chacun peut installer les dépendances et exécuter les tests avec Node 22.18 ou supérieur et la version de pnpm déclarée dans package.json.

pnpm install
pnpm -r lint
pnpm -r typecheck
pnpm -r test

Les tests du dépôt utilisent des données locales et des fournisseurs simulés. Ils ne demandent pas de clé de modèle.

Rejouer la démonstration historique

bash scripts/demo-local.sh

Cette démonstration lance un relais et des Nodes temporaires. La partie question sur un dépôt utilise OpenRouter et exige le réseau ainsi qu’une clé. Elle ne valide pas le futur parcours privé. Le guide complet détaille les prérequis et les traces conservées.

Un socle libre.
Rien de payant avant les utilisateurs.

Socle gratuit : consentement, protections essentielles, reçus, relais auto-hébergé, A2A et MCP, sous licence Apache-2.0 pour le code détenu par le projet. Les dépendances et les modèles gardent leurs licences propres. La sécurité n’est jamais une option payante.

Hypothèses de financement, sans tarif : des contrats d’installation et de support, puis un pack entreprise (console de politiques, SSO, export d’audit, versions maintenues) si un grand compte le demande par écrit. Rien n’est vendu aujourd’hui. « drop » reste un nom de code.

Le dépôt est public et open source (Apache-2.0) depuis le 11 octobre 2026. Aucun téléchargement de l’app n’est encore publié : la distribution publique des binaires reste à faire (T3.6).

Des documents pour construire la suite.

Les specs OpenSpec portent le contrat. L’index des tâches fixe l’ordre des chantiers. La référence produit (PRD, TRD, parcours, UX/UI, schéma et plan) vit dans docs/product/ du dépôt. Les documents suivants détaillent le prototype et les preuves encore nécessaires ; chacun porte sa propre date.

Page mise à jour le 11 octobre 2026. Lire l’état du projet.