@bridge connecte l’IA que vous utilisez déjà — Claude Desktop, Cursor, n’importe quel agent compatible MCP — aux e-mails que vous avez déjà. Il le fait localement, sans envoyer le moindre corps de message à un service cloud tiers. Et il est mesurablement plus sobre en jetons — et, sur les opérations directes, mesurablement plus rapide — que toutes les alternatives cloud.
Cette page explique les deux choix de conception qui produisent ces chiffres, à un niveau qui vous permet de raisonner sur l’architecture sans obtenir un plan reproductible.
Comment @bridge se compare aux deux alternatives courantes — un MCP cloud qui encapsule l’API d’un seul fournisseur (p. ex. Gmail MCP), et un client e-mail IA tout-en-un qui héberge votre boîte aux lettres :
| @bridge | Gmail MCP | Client e-mail IA cloud | |
|---|---|---|---|
| Vitesse par action directe | ~5 ms (local) | ~110 ms+ aller-retour | ~110 ms+ aller-retour |
| Fait transiter vos e-mails par le cloud d’un fournisseur | Non — direct et local | Oui — vers leur cloud | Oui |
| Fournisseurs d’e-mail | Tous (via Thunderbird) | Gmail seulement | En général Gmail / Outlook |
| Votre LLM, votre choix | Oui | Oui | Non — modèle imposé |
| Compositeur d’e-mails HTML de marque | Oui — @bridge E-mail de marque | Non | Non |
| Sobre en jetons (pas de surcharge HTML) | Oui — texte par défaut | Non — déverse le HTML complet | — |
| Fonctionne hors ligne | Oui | Non | Non |
Vous payez déjà pour Claude, GPT ou Gemini, et @bridge n’y applique jamais de majoration : aucuns frais d’API ajoutés, aucune majoration par appel, aucun quota propre en plus de ceux de votre fournisseur. @bridge est lui-même un simple abonnement forfaitaire, distinct de — et indépendant de — ce que votre fournisseur d’IA vous facture. Le reste de cette page explique les deux choix de conception derrière les chiffres de vitesse et de coût.
Les outils de messagerie médiatisés par le cloud — Gmail MCP, Microsoft Graph MCP et les clients e-mail IA tout-en-un — font transiter chaque opération par le cloud de leur fournisseur. Le corps de votre message voyage de votre ordinateur portable vers les serveurs de Google (ou de Microsoft, ou de quelqu’un d’autre), où il est traité, et le résultat revient par l’Internet public. Chaque opération paie un aller-retour réseau ; chaque e-mail récupéré paie un surcoût de jetons pour le balisage HTML que personne n’a demandé.
@bridge ne fait ni l’un ni l’autre.
@bridge exécute trois petits processus sur votre propre machine — un connecteur que votre IA appelle, un petit bridge qui écoute sur un port local uniquement, et une extension Thunderbird qui effectue le vrai travail sur les e-mails. Votre IA parle au connecteur ; le connecteur parle au bridge ; le bridge parle à l’extension ; l’extension parle au stockage de messages local de Thunderbird, déjà synchronisé depuis votre boîte de réception via les protocoles de messagerie que Thunderbird utilise déjà. Aucune partie de ce chemin ne passe par le cloud de qui que ce soit. La requête de votre IA traverse, au plus, un socket loopback et un pipe du système d’exploitation — deux transferts en mémoire internes au noyau — avant d’atteindre le même stockage de messages que Thunderbird lit lui-même.
Trois pièces, un bridge, tout en local — votre client IA d’un côté, Thunderbird de l’autre, et atbridge.ai entre les deux, sur votre machine :
Votre client IA
Claude Desktop, Cursor, Cline, Aider, ou votre propre agent — pilotant le modèle de votre choix. Il peut désormais lire, rechercher, écrire, envoyer et organiser vos e-mails, agendas, contacts, notes et tâches — comme n’importe quel autre outil qu’il utilise déjà.
atbridge.ai — le bridge local
L’extension Thunderbird plus un bridge local qui effectue le travail. S’installe en quelques minutes ; parle à votre IA via localhost — jamais Internet. Il ajoute aussi @bridge Notes, un espace de travail markdown local.
Thunderbird
Votre Thunderbird existant — libre et ouvert. Connectez n’importe quel compte (Gmail, Outlook, iCloud, IMAP) ; vos e-mails, agendas, contacts et tâches vivent tous ici. Le multicompte fonctionne d’emblée.
C’est l’effet architectural. Il existe parce que @bridge ne fait pas d’aller-retour réseau.
Quand un outil de messagerie cloud traite une requête, il paie :
Cet aller-retour réseau est le plancher de chaque opération, avant même que le fournisseur ne travaille. @bridge élimine tout cela. Chaque opération traverse une connexion TCP loopback — implémentée par le noyau du système d’exploitation comme un transfert en mémoire qui contourne entièrement la carte réseau — et un pipe entrée/sortie standard entre les deux processus locaux. C’est tout.
Nous l’avons mesuré. Les chiffres ci-dessous proviennent d’un run représentatif —
30 répétitions par opération, chronométrées avec l’horloge sur le fil de curl
(indépendante de la latence propre d’un modèle de langage ; le script se trouve dans
le dépôt). @bridge tournait contre son bridge loopback local ; la référence cloud est
l’aller-retour HTTPS vers l’API Gmail depuis la même machine :
| Opération | @bridge (local) | Plancher aller-retour cloud | Gain de vitesse |
|---|---|---|---|
| Lire le corps d’un message (par id) | ~5 ms | ~110 ms | ~22× plus rapide |
| Lister les dossiers | ~5 ms | ~110 ms | ~24× plus rapide |
| Lister les comptes | ~4 ms | ~110 ms | ~26× plus rapide |
| Ping de disponibilité | ~2 ms | ~110 ms | ~58× plus rapide |
Deux réserves pour rester honnêtes :
La formulation prudente et mesurée est donc : une opération @bridge directe se termine en quelques millisecondes — environ 20× plus rapide que l’aller-retour réseau qu’un outil cloud paie avant même de commencer à travailler. Et pour un agent interactif enchaînant une séquence d’opérations, cette économie se cumule sur chaque appel de la chaîne.
Pourquoi c'est important
Pour votre agent IA, « terminer le travail » signifie « produire la réponse suivante ». Supprimer l’aller-retour réseau de chaque appel d’outil transforme l’attente à l’indicateur « réflexion… » de plusieurs secondes en quelque chose qui paraît immédiat.
C’est l’effet de protocole. Il existe parce que le protocole filaire de @bridge est épuré par défaut.
Quand votre agent IA reçoit une réponse d’outil, cette réponse devient des jetons d’entrée pour le tour suivant du modèle. Le fournisseur du modèle — Anthropic, OpenAI, ou tout autre — vous facture par jeton d’entrée. Donc, moins la réponse coûte, moins la prochaine étape d’inférence coûte.
Les outils de messagerie cloud renvoient le corps HTML complet de chaque e-mail, y compris :
Sur un e-mail marketing typique, cela représente 6 000 jetons ou plus de contenu substantiellement inutile pour chaque e-mail récupéré.
Le protocole filaire de @bridge possède quatre fonctionnalités coopérantes qui éliminent cette surcharge :
Texte par défaut
La récupération du corps renvoie la représentation en texte brut du corps du
message. Le HTML n’est renvoyé que si le consommateur en fait explicitement la
demande (html: true). Pour les 90 % de flux d’agents qui n’ont pas besoin de
mise en forme rendue, cela seul supprime l’essentiel de la surcharge.
Aperçu d'extrait optionnel
Les opérations de recherche et de liste incluent un court extrait du premier fragment de corps non vide. Les agents peuvent trier et résumer les résultats sans récupérer chaque corps, éliminant un second aller-retour par message.
Déduplication par Message-ID
Les fils de discussion s’étendant sur plusieurs dossiers ne sont pas renvoyés plusieurs fois. Le bridge déduplique les résultats par Message-ID RFC-2822 avant même que le modèle ne les voie.
Aucune pagination automatique
Les résultats ne sont pas enveloppés dans des enveloppes de curseur ni du passe-partout de streaming. La réponse est le plus petit JSON lisible qui transmet les données.
Le résultat mesuré sur la même charge de trois messages : @bridge produit environ 3 711 jetons d’entrée dans les réponses d’outils contre environ 13 143 jetons d’entrée pour la référence cloud — une réduction d’environ 72 %.
Au tarif d’entrée d’Anthropic Claude Sonnet de $3 par million de jetons (juin 2026), le coût facturé de la charge tombe d’environ 3,94 ¢ à 1,11 ¢ — une amélioration de l’efficacité-coût de ~3,5×.
L’effet de coût et l’effet de vitesse découlent de choix de conception différents et ne dépendent pas l’un de l’autre — et ils reposent sur des types de preuves différents :
@bridge fait les deux. Quiconque veut construire quelque chose comme @bridge a besoin des deux.
Vous payez déjà pour Claude, GPT-5, ou le modèle que vous utilisez. @bridge n’ajoute rien à cette facture, dans deux sens :
Et le volet vie privée s’améliore : atbridge.ai n’ajoute aucun intermédiaire cloud — votre courrier n’est pas relayé par nos serveurs comme un MCP hébergé le fait par les siens. Avec un modèle local (Ollama), le contenu de votre courrier reste entièrement sur le poste de travail ; avec un modèle cloud, seul ce que vous demandez à l’IA de traiter est envoyé au fournisseur que vous avez choisi. Bien moins à divulguer dans un DPA, à négocier avec les achats, ou à attester dans un questionnaire SOC 2 — le chemin des données est le vôtre et celui du modèle que vous avez choisi, sans fournisseur supplémentaire au milieu.
Les chiffres de coût ci-dessus sont des données réelles issues d’une charge réelle, pas des micro-benchmarks synthétiques. Précisément :
caractères ÷ 4) et tarifés aux tarifs d’entrée
d’Anthropic Claude Sonnet ($3 / million de jetons, juin 2026).curl (pas l’auto-estimation
d’un modèle), et limités aux opérations directes — le chiffre cloud est un
plancher d’aller-retour et la recherche (un balayage local) est exclue. La
méthodologie complète figure dans le livre blanc technique, disponible
sur demande.Les chiffres varient selon la charge. Un court e-mail en texte brut donne un gain de coût plus faible qu’un long fil chargé en HTML ; l’avantage de vitesse architectural est plus uniforme — c’est le même aller-retour réseau économisé à chaque appel. Nous avons choisi ce mélange de trois e-mails parce qu’il reflète la charge de travail pratique d’un agent — et non parce qu’il produit le plus grand chiffre pour le marketing.
L’architecture d’atbridge.ai, le protocole filaire et la méthodologie de mesure derrière
les chiffres de cette page sont © atbridge.ai — tous droits réservés. La marque
@bridge / atbridge et la marque figurative du produit sont protégées séparément.
Le livre blanc technique complet est disponible sur demande.
Écrit par Nazar Kholboiev, créateur d’atbridge.ai — LinkedIn · nazar@atbridge.ai.
Was this page helpful?
Thanks for the feedback!