Concepts et architecture

Bromure Agentic Coding exécute des agents de code IA dans des machines Linux virtualisées par le matériel sur votre Mac, et applique chaque contrôle de sécurité en un point que l'agent ne peut pas contourner. Ce chapitre définit les mots sur lesquels s'appuie le reste du manuel — session, machine, salle, branche, hôte et invité, la frontière du fil — et explique comment les pièces s'assemblent. Si vous ne lisez qu'un chapitre en plus du Démarrage rapide, lisez celui-ci.

Sessions, machines, salles et branches

Quatre objets composent presque tout ce que vous faites dans l'application.

Session

Une session est une conversation avec un agent, dans un dossier, sur une machine. Vous la démarrez depuis l'écran de nouvelle session ; elle a un titre (l'agent en choisit un d'après votre premier message, et vous pouvez le renommer), un agent (Claude Code, Codex, Grok, Kimi Code ou Oh My Pi), une machine et un dossier de travail dans cette machine. Ce sont les sessions que liste la barre latérale et qu'affiche le chat.

Dans la machine, une session est un agent qui tourne dans son propre onglet de terminal. Vous avez rarement besoin de voir cet onglet, mais vous le pouvez : la pastille Linux de la barre d'outils (⌥⌘U) ou Ouvrir dans le terminal Linux dans le menu de la session y bascule, et la pastille (qui indique alors Session) vous ramène.

Une session survit au processus de l'agent. Quand l'agent se termine, ou que sa machine s'éteint, la session reste dans la barre latérale avec sa conversation, et votre prochain message relance l'agent sur la même conversation. Voir L'accueil des sessions.

Machine

Une machine est une VM Linux isolée avec ses réglages et son stockage durable. La fenêtre principale dit machine ; l'éditeur de réglages, plusieurs menus (Nouvel espace de travail…, Espaces de travail) et la ligne de commande disent espace de travail (en interne, et dans des noms de fichiers comme profile.json, un profil). Les trois mots désignent la même chose.

Une machine définit les identifiants, les dossiers partagés, l'environnement, les serveurs MCP, les garde-fous, les remplacements de modèles, l'apparence et la taille de VM qui s'appliquent à chaque session qui y tourne — tout ce que vous modifiez dans l'éditeur de réglages. Chaque agent est disponible sur chaque machine. Une machine existe qu'elle tourne ou non, et de nombreuses sessions peuvent tourner sur une même machine en même temps, chacune dans son dossier et son onglet de terminal.

L'usage courant est une machine par projet ou par périmètre d'identifiants : les sessions d'une même machine partagent son disque, ses identifiants et son identité réseau. Les machines sont listées sous Machines virtuelles dans la barre latérale ; voir Machines.

Une exécution de machine est une période continue pendant laquelle la VM d'une machine est allumée : elle commence quand la machine démarre ou reprend, et se termine quand elle s'éteint ou se suspend. Certains états appartiennent à l'exécution, pas à la machine : les autorisations d'identifiants que vous accordez vivent en mémoire et sont révoquées à la fin de l'exécution, et les partages de configuration par démarrage sont reconstruits à chaque démarrage.

Salle

Une salle regroupe des sessions qui travaillent sur la même chose. Ouvrir une salle affiche ses sessions côte à côte sous forme de grille de chats en direct, avec un compositeur qui peut écrire à l'une d'elles ou à toutes à la fois. Une salle peut avoir son propre Standard, une session qui suit les sessions de cette salle et seulement elles. Les sessions d'une salle peuvent tourner sur des machines différentes. Voir Salles.

Session de branche

Une session de branche est une session démarrée depuis une autre session sur sa propre branche git, dans une extraction séparée (un worktree git) du même dépôt sur la même machine. Elle travaille sans toucher au dossier de la session d'origine, et quand le résultat vous convient, vous le relisez et le fusionnez. Voir Branches et revue.

Les sessions que d'autres sessions démarrent

Deux types de sessions sont démarrées pour vous plutôt que par vous :

• Les délégués. Un agent peut confier une tâche à une nouvelle session enfant — sur sa propre branche ou sur une autre machine — et attendre le résultat. L'enfant est listé sous la session qui l'a démarré. Un agent peut aussi envoyer une demande à une session existante via son @surnom. Voir Des agents qui travaillent ensemble.
• Le Standard. Une session Claude Code qui suit toutes les autres. Il apparaît dans la barre latérale dès que deux sessions ou plus sont en cours, travaille dans le dossier ~/.bromure/switchboard sur la dernière machine utilisée, et peut lire des sessions, y répondre et en démarrer pour vous selon des règles strictes. Le Standard propre à une salle travaille dans ~/.bromure/rooms/<room> et ne voit que cette salle. Voir Standard et messagerie.

Les exécutions d'automatisations et les tâches de code tournent aussi sous forme de sessions, archivées quand elles se terminent ; voir Automatisations et Tâches de code.

États des sessions

La barre latérale regroupe les sessions selon ce qu'elles attendent de vous, jamais selon la machine sur laquelle elles tournent :

Deux autres endroits contiennent des sessions hors de ces groupes :

• Archivées est un repli en bas de la liste des sessions pour les conversations que vous avez rangées. Une session archivée reste lisible, et un message suffit à la faire revenir. Les sessions terminées depuis plus de trois jours sont archivées automatiquement, sauf celles d'une salle et les Standards. Les délégués, les tâches de code et les exécutions d'automatisations sont archivés dès qu'ils se terminent.
• Une session dont la machine ou le dossier n'existe plus s'affiche en grisé, avec « Machine supprimée » ou « Dossier supprimé ». Les sessions de machines supprimées sont regroupées sur une ligne en fin de liste, avec un bouton Supprimer.

L'hôte garde une copie de la conversation de chaque session (dans ~/Library/Application Support/BromureAC/transcripts/), actualisée pendant que l'agent tourne, si bien qu'une session en pause, terminée ou archivée peut être lue sans démarrer sa machine.

L'hôte et l'invité

Tout dans Bromure Agentic Coding se trouve d'un côté d'une ligne infranchissable :

• L'hôte est votre Mac — macOS 14 ou ultérieur sur Apple Silicon — et l'application Bromure Agentic Coding qui y tourne. L'hôte détient tout ce qui est sensible : vos vrais identifiants (chiffrés avec une clé maîtresse dans le trousseau macOS), vos connexions, le proxy MITM qui parle à Internet pour l'agent, la clé privée de l'AC racine Bromure, la trace et la chronologie de sécurité, ainsi que les fenêtres, chats et terminaux de l'application. Le chat et les terminaux dans lesquels vous tapez sont dessinés sur l'hôte, pas dans la VM.
• L'invité est la VM Linux où l'agent tourne réellement — Claude Code, Codex, Grok, Kimi Code, Oh My Pi ou de simples outils shell, avec tout ce qu'ils installent et touchent : dépôts clonés, caches de paquets, conteneurs Docker, virtualenvs. L'invité est considéré comme non fiable par conception. Il ne détient aucun vrai secret, seulement des identifiants factices volontairement invalides, et son trafic web sortant passe par le proxy de l'hôte.

Les deux côtés communiquent par deux canaux étroits : vsock (sockets virtio, un canal hôte-invité qui ne nécessite aucun réseau) pour le contrôle, les terminaux, les serveurs MCP et le chemin du proxy ; et un réseau virtuel privé pour le trafic IP ordinaire. Les deux sont décrits plus bas.

Cette séparation rend l'affirmation de sécurité concrète : un agent victime d'une injection de prompt ou qui se comporte mal peut faire ce qu'il veut à l'intérieur de l'invité, mais il ne peut ni lire une vraie clé d'API, ni signer avec un vrai secret AWS, ni extraire une clé privée SSH — rien de tout cela n'existe de son côté de la ligne.

L'architecture en un coup d'œil

Lisez le schéma de bas en haut : l'agent travaille dans la VM de la machine ; son HTTPS sort par vsock vers le proxy de l'hôte, seul endroit où les identifiants factices deviennent réels ; l'application se rattache aux terminaux de la VM par des ponts vsock distincts ; et une VM de navigateur jetable facultative partage le même réseau privé, pour pouvoir charger les serveurs de développement de l'agent.

En plus des machines et des VM de navigateur, l'application peut exécuter trois types de VM gérées qui lui sont propres, toutes sur le même réseau privé : les nœuds de cluster Kubernetes et un registre de conteneurs (voir Clusters Kubernetes et registres), et le connecteur de messagerie qui relie le Standard à Signal, WhatsApp ou Slack (voir Standard et messagerie). Elles sont listées sous Machines virtuelles dans la barre latérale, mais ce ne sont pas des machines : aucun agent n'y tourne.

La VM de la machine

La VM de chaque machine est un invité Ubuntu 24.04 qui tourne sous Virtualization.framework d'Apple, lequel exige Apple Silicon et ne prend en charge que les invités ARM64. Elle démarre avec 4 vCPU et la quantité de mémoire définie dans le panneau Ressources de la machine, à partir de deux disques virtuels :

• disk.img — le disque système. Au premier démarrage de la machine, il est créé comme clone APFS en copie sur écriture de l'image de base Ubuntu partagée et signée (voir Installation et premier lancement) : le clone apparaît instantanément et n'utilise aucun nouvel espace disque tant que l'invité n'y écrit pas. Les démarrages suivants réutilisent le même clone, si bien que les paquets installés avec apt install, les images Docker récupérées et les autres modifications au niveau du système survivent.
• home.img — un disque ext4 privé qui contient /home/ubuntu, attaché comme second disque. Il fait 16 GiB par défaut mais n'occupe de l'espace qu'à mesure qu'il se remplit, et il rétrécit sur l'hôte quand des fichiers sont supprimés dans l'invité. Le dossier personnel survit à Réinitialiser le disque : c'est pourquoi vos dépôts, vos dotfiles, votre historique du shell et le dossier de chaque session survivent à une réinitialisation du disque système.

L'invité monte aussi de petits partages par démarrage : un partage méta en lecture seule qui porte la configuration de ce démarrage (fichiers d'environnement d'identifiants factices, réglages du proxy, certificat de l'AC Bromure, agents invités, configuration MCP) et une boîte d'envoi inscriptible que l'invité utilise pour rendre compte à l'hôte (son adresse IP, ses onglets de terminal, l'état des agents). Les deux sont reconstruits à chaque démarrage et ne contiennent aucun état durable. Jusqu'à 8 dossiers de votre Mac peuvent aussi être partagés dans l'invité ; ils apparaissent dans le dossier personnel.

Persistant par conception — le contraste avec Bromure (Web)

Bromure Agentic Coding partage sa base de code avec son application sœur, Bromure, le navigateur web, et les deux font volontairement des choix opposés en matière de durée de vie :

Le code a besoin d'un état durable — dépôts clonés, caches de paquets, virtualenvs, historique du shell — et jeter la VM après chaque session rendrait les agents inutiles. Au lieu de contrôler l'état de la VM, Bromure Agentic Coding contrôle ce que la VM a le droit de contenir : aucun vrai secret, et aucun chemin non médiatisé vers Internet. Les machines jetables restent une option : Réinitialiser le disque reclone le disque système depuis l'image de base, Rembobiner le dossier personnel… ramène le dossier personnel à un point de contrôle antérieur, bromure-cli vm run --rm crée une machine jetable supprimée à son arrêt, et la procédure de compromission efface un disque et un dossier personnel contaminés tout en conservant vos réglages et vos clés.

La VM du navigateur

Un morceau de Bromure (Web) survit dans Bromure Agentic Coding : le navigateur intégré à côté d'une session. Quand vous (ou l'agent) l'ouvrez, la machine obtient une seconde VM, jetable, qui exécute Ubuntu et Chromium, clonée dans un dossier temporaire et supprimée à la fermeture du navigateur. L'état de navigation est jeté par défaut, sauf si la machine active Rester connecté aux sites web, qui conserve le profil de Chromium sur un disque chiffré propre à la machine. La VM du navigateur se trouve sur le même réseau privé que les machines, pour pouvoir charger un serveur de développement que l'agent vient de lancer. Voir Le navigateur intégré.

États des machines : éteinte, suspendue et en marche

Chaque machine est toujours dans l'un de trois états durables. Vous verrez aussi brièvement Démarrage… pendant qu'une machine démarre.

Dépliez Machines virtuelles en bas de la barre latérale pour voir vos machines. Cliquer sur une machine affiche son tableau de bord : processeur, mémoire, disque et temps de fonctionnement en direct quand elle tourne, ou sa spécification et sa configuration quand elle est éteinte, avec un bouton Démarrer ou Reprendre. Démarrer une session sur une machine éteinte la démarre pour vous.

Quelques règles à connaître :

• La suspension est un instantané mémoire, pas une sauvegarde. Le restaurer exige que la configuration de la VM soit la même qu'au moment de l'enregistrement. Si vous modifiez quelque chose dont dépend l'instantané — par exemple la taille de la mémoire ou les dossiers partagés — la machine démarre à neuf, et aucun fichier n'est touché. Le journal de l'application indique ce qui a changé.
• Un instantané ne survit jamais à son disque. Réinitialiser ou effacer le disque système supprime aussi tout instantané mémoire enregistré, car un disque neuf avec une mémoire périmée serait aussitôt corrompu.
• Éteinte ne veut pas dire effacée. Une machine éteinte garde indéfiniment son disque système et son dossier personnel. La suppression effective est toujours explicite (Réinitialiser le disque, Rembobiner le dossier personnel…, Supprimer l'espace de travail) ou imposée par la procédure de compromission.

Actions de fermeture

Ce qui se passe quand vous fermez la fenêtre d'une machine est un choix propre à chaque machine (À la fermeture de la fenêtre dans le panneau Général) : Continuer en arrière-plan (la machine continue de tourner sans fenêtre), Suspendre, Éteindre ou Demander — le choix par défaut, qui pose la question à chaque fois. Voir Machines.

La frontière du fil

La frontière du fil est l'idée centrale du produit : tout le trafic web sortant de l'invité passe par un proxy de type « homme du milieu » (MITM) côté hôte, et chaque protection — garder les secrets, restreindre les identifiants, analyser la chaîne d'approvisionnement, détecter l'injection de prompt, protéger les données personnelles, tracer — est appliquée en ce seul point. L'agent ne peut pas la contourner, car il n'y a rien d'utile de son côté de la ligne.

Le flux, de bout en bout :

1. L'invité ne détient que des leurres. Quand une machine démarre, l'hôte écrit dans la VM des identifiants de substitution volontairement invalides — variables d'environnement comme ANTHROPIC_API_KEY, et fichiers comme ~/.git-credentials, ~/.docker/config.json et ~/.kube/config. Les leurres gardent la forme des vrais (sk-ant-api03-brm-…, en forme de ghp_…, brm_…) pour que les vérifications côté client les acceptent, et ils sont stables pour une installation donnée, si bien que les outils ne voient jamais une clé changer d'une exécution à l'autre. Les vraies valeurs correspondantes sont chargées dans la mémoire du proxy sur l'hôte, chacune liée à l'hôte auquel elle appartient.
2. Le TLS de l'invité se termine au proxy. Chaque shell de l'invité exporte HTTPS_PROXY=http://127.0.0.1:65534, un point de terminaison dans la VM qui passe par un tunnel vsock (port 8443) jusqu'au proxy de l'hôte. En outre, le commutateur réseau virtuel de l'hôte détourne vers ce même proxy les connexions sortantes de l'invité vers les ports 80 et 443 ; un outil qui ignore les variables de proxy passe donc quand même par lui. Le proxy présente un certificat par hôte signé par l'AC racine Bromure, inspecte la requête et la rechiffre vers le vrai serveur.
3. Les leurres ne deviennent réels qu'à la sortie. Le proxy remplace chaque leurre par sa vraie valeur — substitution d'en-tête pour les clés d'API et les jetons, les clés de substitution derrière les connexions aux abonnements, re-signature SigV4 complète pour AWS (l'invité signe avec un faux secret ; l'hôte retire cette signature et signe à nouveau avec le vrai) et signature ssh-agent via vsock pour SSH. Les substitutions ne s'appliquent qu'à l'hôte enregistré et à ses sous-domaines, jamais à un sosie : un identifiant enregistré pour api.anthropic.com n'est jamais injecté vers un autre domaine.

Une machine peut désactiver la redirection transparente dans son panneau Garde-fous ; les variables de proxy, la substitution des identifiants, le traçage et les garde-fous s'appliquent toujours. Voir Identifiants et la frontière du fil.

L'autorité de certification racine Bromure

Le proxy ne peut lire le TLS de l'invité que parce que l'invité lui fait confiance. Au premier lancement, l'application crée une autorité de certification propre à l'installation — l'AC racine Bromure Agentic Coding — dont le certificat public est installé dans le magasin de confiance de chaque VM au démarrage via le partage méta. La clé privée ne quitte jamais l'hôte (elle vit sous ~/Library/Application Support/BromureAC/ca/, lisible par vous seul). Rien en dehors de vos VM Bromure ne fait confiance à cette AC : elle ne peut pas servir à intercepter le trafic propre de votre Mac, et supprimer le dossier ca/ crée simplement une nouvelle AC au lancement suivant.

À défaillance sûre par construction

La conception échoue en mode fermé : si du trafic de l'invité passe un jour à côté du proxy — un socket brut sur un port inhabituel, une tentative délibérée de contournement — le seul identifiant qu'il peut présenter est un leurre qu'aucun serveur n'accepte. AWS renvoie InvalidSignatureException ; les fournisseurs d'API rejettent la clé de substitution. Contourner la frontière ne rapporte rien à un attaquant, car la frontière n'est pas l'endroit où les secrets sont vérifiés — c'est le seul endroit où les secrets existent.

Le détecteur de compromission

La frontière surveille aussi l'abus inverse : l'exfiltration. Le proxy analyse chaque requête sortante à la recherche de l'un des jetons factices enregistrés pour la machine. Un leurre n'a qu'une seule destination légitime — l'hôte pour lequel il a été créé — donc un leurre qui part ailleurs est la signature d'un agent qui tente de faire fuiter des identifiants. Le proxy arrête la requête, met la machine en pause et vous alerte, avec le choix d'éteindre la machine, de bloquer la requête ou d'autoriser cette destination pour le reste de la session. Comme seul un leurre est sorti, le vrai identifiant n'a jamais besoin d'être renouvelé. Le modèle complet des identifiants, y compris les demandes d'approbation par identifiant et les autorisations limitées dans le temps, se trouve dans Identifiants et la frontière du fil.

Ce qui persiste et ce qui ne persiste pas

Bromure Agentic Coding est explicite sur ce qui dure. Les fichiers de chaque machine vivent dans ~/Library/Application Support/BromureAC/profiles/<uuid>/ ; vos sessions vivent à côté, dans le dossier de support.

Persistant — survit aux arrêts et aux redémarrages de l'application :

Temporaire — reconstruit ou supprimé automatiquement :

Deux conséquences en découlent. D'abord, fermer une fenêtre ou mettre fin à une session ne supprime jamais rien à elle seule — les actions destructrices sont toutes explicites et confirmées. Supprimer une session retire sa conversation de l'application mais laisse son dossier sur la machine. Ensuite, quand vous voulez repartir de zéro, vous avez un éventail d'options : Rembobiner le dossier personnel…, Réinitialiser le disque (le dossier personnel survit), supprimer la machine, ou une machine jetable avec bromure-cli vm run --rm.

Remarque : Les dossiers partagés depuis votre Mac sont des dossiers ordinaires sur votre disque, hors du stockage de Bromure. Aucune action de Bromure ne les supprime jamais — pas même l'effacement après compromission — et la demande d'effacement le précise.

Ponts hôte–invité (vsock)

Tout ce qui est interactif entre le Mac et l'invité passe par des sockets virtio — des canaux directs entre hôte et invité qui existent indépendamment du réseau de la VM. Vous ne les configurez jamais, mais savoir qu'ils existent aide à lire les traces ou le Dépannage. Chaque pont utilise un port vsock numéroté :

Ponts de la VM de machine :

Serveurs MCP intégrés — des outils que l'hôte offre à chaque agent de la machine, chacun joint par une petite cale dans l'invité :

Ponts de la VM du navigateur : configuration (5000), transfert de fichiers (5100), Chrome DevTools Protocol (5200), relais de liens (5300), webcam (5400), barre d'onglets (5810) et trace réseau (5900).

Presse-papiers

Les onglets de terminal n'ont pas de service de presse-papiers séparé — le presse-papiers passe par le terminal lui-même. Copier dans l'invité (une sélection tmux, ou tout programme utilisant OSC 52) arrive dans le presse-papiers macOS ; ⌘C copie la sélection dans un terminal ; ⌘V colle dans l'invité. Dans le navigateur, un agent de presse-papiers invité assure le copier-coller entre le Mac et Chromium.

Transfert de fichiers

Les fichiers circulent entre le Mac et une machine de trois façons, toutes couvertes dans Machines : les dossiers partagés (le chemin normal pour les fichiers de projet qui vivent sur votre Mac), le panneau Fichiers (glisser vers et depuis, via le pont shell sur le port 5800), et les pièces jointes — tout fichier jusqu'à 512 MB déposé ou collé dans un chat ou un terminal est copié dans la machine, et son chemin est transmis à l'agent.

Réseau

Mode NAT (par défaut)

Toutes les machines en mode NAT se connectent à un seul commutateur réseau logiciel dans l'application, qui atteint Internet par une unique interface NAT vmnet de macOS. En conséquence :

• Un seul sous-réseau privé. Une nouvelle installation choisit au hasard un /24 privé dans 172.16.0.0/12 et le conserve, en évitant tout réseau 172.x sur lequel se trouve déjà votre Mac (comme celui de Docker). L'interrupteur dans Préférences › Ressources (Sous-réseau de l'espace de travail — Utiliser un sous-réseau privé (évite les conflits entre instances distantes)) affiche le sous-réseau, et Tirer au hasard en choisit un nouveau ; les changements s'appliquent au prochain démarrage de vos machines. Interrupteur désactivé, l'application utilise 192.168.64.0/24, ou un autre 192.168.x.0/24 libre si votre réseau local utilise déjà cette plage.
• L'application exécute son propre serveur DHCP sur ce commutateur, et les baux sont conservés dans dhcp-leases.sqlite. Chaque machine a une adresse MAC stable (dans profile-macs.json), si bien qu'elle garde en général la même adresse IP d'un redémarrage à l'autre. Copier l'adresse IP dans le menu de la machine et le tableau de bord de la machine affichent l'adresse actuelle.
• Les VM peuvent se joindre entre elles. Les machines, les VM de navigateur, les nœuds de cluster et le registre sont sur le même réseau par conception : le navigateur peut charger un serveur de développement qui tourne sur une machine, et deux machines peuvent utiliser leurs services respectifs. La liste des ports en écoute du tableau de bord affiche chaque service joignable sous la forme <IP>:<port> à laquelle vous vous connecteriez depuis le Mac.
• Isolées de l'extérieur. Les VM sont joignables depuis votre Mac mais pas depuis votre réseau local physique, et rien d'autre ne peut s'y connecter à moins que vous ne publiiez explicitement un service (par exemple via un tunnel rapide Cloudflare depuis la liste des ports en écoute).
• IPv4 uniquement. IPv6 est désactivé dans l'invité, et localhost se résout en 127.0.0.1.

Le MTU réseau de l'invité est fixé à 1280 par défaut — une valeur sûre derrière les VPN et les réseaux d'entreprise — et peut être relevé avec defaults write io.bromure.agentic-coding vm.mtu -int <valeur>.

Rappelez-vous que le trafic IP ordinaire n'est pas le chemin des identifiants : le trafic web est dirigé vers le proxy, et tout ce qui passe à côté ne transporte que des leurres — la propriété d'échec en mode fermé décrite plus haut.

Mode pont (par machine)

Une machine peut à la place rejoindre votre réseau local physique : réglez Réseau sur le mode pont dans son panneau Ressources et choisissez une interface ; la VM apparaît alors sur le réseau local avec sa propre adresse fournie par votre routeur (utile quand d'autres appareils doivent la joindre directement). Si l'interface choisie n'est pas disponible au démarrage, la machine se rabat sur le NAT. Voir Réglages › Ressources.

Des démarrages rapides

Deux choses permettent aux machines de démarrer vite :

• Des disques en copie sur écriture. Le disque système d'une nouvelle machine est un clone instantané de l'image de base plutôt qu'une copie, si bien que le premier démarrage n'attend pas l'écriture de plusieurs gigaoctets. Les démarrages à froid suivants sont des démarrages Linux ordinaires.
• Suspendre et reprendre. Une machine Suspendue saute entièrement le démarrage : son instantané mémoire est restauré et elle continue là où elle s'était arrêtée, onglets de terminal et agents compris.

Les machines ne sont ni mutualisées ni pré-démarrées : chaque machine est un ordinateur persistant à part entière, il n'y a donc rien d'interchangeable à garder au chaud. La VM de navigateur jetable fait exception ; elle provient du même mécanisme de pool que Bromure Web.