Comment nous avons conçu OWL, la nouvelle architecture derrière notre navigateur basé sur ChatGPT, Atlas

Par Ken Rockot, membre de l’équipe technique et Ben Goodger, responsable ingénierie, ChatGPT Atlas

La semaine dernière, nous avons lancé ChatGPT Atlas⁠, une nouvelle solution pour naviguer sur le Web avec ChatGPT à vos côtés. En plus d’être un navigateur web doté de toutes les fonctionnalités habituelles, Atlas vous ouvre la porte du futur : un univers où ChatGPT peut vous accompagner sur Internet pour poser des questions, faire des suggestions et réaliser des tâches pour vous. Dans cet article, nous levons le voile sur l’un des aspects techniques les plus complexes du produit : comment nous avons transformé ChatGPT en un navigateur qui gagne en pertinence au fil de son utilisation.

Transformer ChatGPT en véritable copilote sur le Web a nécessité de réinventer complètement l’architecture du navigateur et de séparer Atlas du runtime Chromium. Cette mise au point nécessaire d’une nouvelle méthode d’intégration de Chromium nous a permis d’atteindre nos objectifs : démarrage instantané du produit, réactivité maintenue même en cas d’ouverture de nouveaux onglets et création d’une base solide pour les cas d’utilisation agentiques.

Chromium constituait un bloc de construction naturel, fournissant un moteur web de premier ordre avec un modèle de sécurité et des performances solides, mais aussi une compatibilité web inégalée. Par ailleurs, il est développé par une communauté mondiale qui y apporte constamment des améliorations. Il est fréquemment utilisé de nos jours dans les navigateurs web sur ordinateur.

Notre talentueuse équipe de conception avait fixé des objectifs ambitieux en matière d’expérience utilisateur, avec notamment des animations et effets visuels complexes pour des fonctionnalités agentiques notamment. Notre équipe d’ingénierie a donc dû s’appuyer sur les frameworks natifs les plus modernes pour notre interface utilisateur (SwiftUI, AppKit et Metal), au lieu de se contenter de remodeler l’interface open source de Chromium. L’interface utilisateur d’Atlas est donc le fruit d’une refonte complète de l’expérience utilisateur de l’application.

Nous avions également d’autres objectifs en tête, comme un délai de démarrage plus court et la prise en charge de centaines d’onglets sans réduction des performances. Ces objectifs étaient difficiles à atteindre avec une version Chromium prête à l’emploi, et ses nombreuses contraintes sur la séquence de démarrage, le modèle de threading et les modèles d’onglets. Nous avons envisagé d’importantes modifications, mais nous souhaitions conserver notre ensemble de correctifs afin de pouvoir intégrer rapidement les nouvelles versions. Pour gagner en rapidité, il nous fallait une nouvelle approche pour tirer pleinement parti de Chromium.

La solution devait non seulement permettre d’accélérer l’expérimentation, l’itération et la livraison de nouvelles fonctionnalités, mais surtout de préserver un élément essentiel de notre culture d’ingénierie : la livraison en une journée. Chaque nouvel ingénieur réalise et fusionne une petite modification dès le jour de son arrivée chez nous. Nous devions préserver cette possibilité, même si l’extraction et le build avec Chromium peut prendre des heures.

En réponse à ces défis, nous avons mis au point une nouvelle couche d’architecture que nous appelons OWL, pour OpenAI’s Web Layer (couche web d’OpenAI). OWL est notre intégration de Chromium, qui passe par l’exécution du processus de navigation Chromium en dehors du principal processus de l’application Atlas.

Vous pouvez voir les choses de cette façon : Chromium a révolutionné les navigateurs en déplaçant les onglets vers des processus distincts. Nous poussons cette idée plus loin en déplaçant Chromium lui-même hors du processus principal de l’application vers une couche de service isolée. Cette évolution présente de nombreux avantages.

• Une application plus simple et plus moderne : Atlas est fondé quasi entièrement sur SwiftUI et AppKit. Un seul langage, une seule pile technologique, une base de code propre.
• Un démarrage plus rapide : Chromium démarre de manière asynchrone en arrière-plan. Plus de temps d’attente avec Atlas, les informations s’affichent presque instantanément à l’écran.
• Protection contre les bugs et les plantages : Chromium est un moteur web puissant et complexe. Un blocage du thread principal de Chromium n’entraîne pas de blocage d’Atlas. En cas de plantage de Chromium, Atlas reste opérationnel.
• Simplification de la fusion : Notre recours limité à l’interface utilisateur open source de Chromium réduit la gestion des écarts entre les deux et simplifie la maintenance.
• Des itérations plus rapides : La plupart des ingénieurs ne réalisent jamais de build Chromium localement. OWL étant disponible en interne sous forme de binaire précompilé, les builds d’Atlas prennent quelques minutes et non plus des heures.

Le fait que la plupart des ingénieurs de notre équipe n’aient pas à réaliser régulièrement de builds Chromium à partir du code source accélère considérablement le développement : même les nouveaux embauchés peuvent fusionner des modifications simples dès leur premier jour dans l’équipe.

À un niveau élevé, le navigateur Atlas est le client OWL et le processus du navigateur Chromium est l’hôte OWL. Ils communiquent via IPC, plus précisément Mojo⁠(ouverture dans une nouvelle fenêtre), le système de transmission de messages propre à Chromium. Nous avons écrit des liaisons Swift (et TypeScript) personnalisées pour Mojo, pour que notre application Swift puisse appeler directement les interfaces côté hôte.

La bibliothèque cliente OWL propose une API Swift publique simple, qui reprend plusieurs concepts clés exposés par la couche de service de l’hôte :

• Session : configuration et contrôle global de l’hôte
• Profil : gestion de l’état du navigateur pour un profil utilisateur spécifique
• WebView : contrôle et intégration des contenus web individuels (rendu, entrée, navigation, zoom…)
• WebContentRenderer : transmission des événements d’entrée au pipeline de rendu de Chromium et réception du feedback du moteur de rendu
• LayerHost/Client : échange d’informations de composition entre l’interface utilisateur et Chromium

Il existe aussi de nombreux points de terminaison de service pour gérer des fonctionnalités de haut niveau comme les signets, les téléchargements, les extensions et le remplissage automatique.

Les WebViews, qui partagent un espace de présentation mutuellement exclusif dans l’application client, sont échangés dans et hors d’un conteneur de composition partagé. Par exemple, une fenêtre de navigateur comporte souvent un seul conteneur partagé visible et la sélection d’un onglet dans la barre d’onglets permute le WebView de cet onglet dans le conteneur. Du côté Chromium, ce conteneur correspond à un gfx::AcceleratedWidget associé au final à un CALayer. Nous présentons l’identifiant de contexte de cette couche au client, où un NSView l’intègre en utilisant l’API privée CALayerHost.

La même approche est utilisée pour certains cas particuliers, comme les listes déroulantes de type ou les sélecteurs de couleurs, que Chromium affiche dans des widgets contextuels distincts. Ils n’ont pas de content::WebContents, mais ils ont une content::RenderWidgetHostView avec leur propregfx::AcceleratedWidget, ce qui permet d’appliquer le même modèle de rendu délégué.OWL assure en interne la synchronisation de la géométrie de la vue avec Chromium, afin que le compositeur du GPU puisse être mis à jour en conséquence et produire systématiquement des contenus de couche d’une taille et d’une échelle adaptée pour l’appareil.Nous réutilisons aussi cette technique pour projeter de manière sélective des éléments de l’interface utilisateur native de Chromium dans Atlas (ceci permet aussi de démarrer rapidement des fonctionnalités comme les invites d’autorisation sans avoir à créer de remplacements à partir de zéro dans SwiftUI). Cette technique s’inspire largement de l’infrastructure existante de Chromium pour les applications web installables sur macOS.Événements d’entrée : Craquage et transfertL’interface utilisateur Chromium traduit les événements de la plateforme (comme les événements NSEvents de macOS) dans le modèle WebInputEvent de Blink avant de les transmettre aux moteurs de rendu. OWL exécutant Chromium dans un processus masqué, nous effectuons cette traduction nous-mêmes dans la bibliothèque cliente Swift et transmettons les événements déjà traduits à Chromium.Ils suivent ensuite le même cycle de vie que des événements d’entrée réels, y compris le renvoi des événements au client chaque fois qu’une page indique que l’événement n’a pas été traité. Dans ce cas, nous resynthétisons un NSEvent et donnons au reste de l’application la possibilité de traiter l’entrée.Mode agent : Cas particuliersLes fonctionnalités de navigation agentique d’Atlas posent des défis spécifiques pour nos approches en matière de rendu, de transfert des événements d’entrée et de stockage des données.Notre modèle d’utilisation prévoit une seule image de l’écran en entrée. Mais certains éléments d’interface utilisateur, comme les listes déroulantes (), s’affichent en dehors des limites de l’onglet dans des fenêtres séparées. En mode agent, nous recomposons ces fenêtres contextuelles dans l’image de la page principale, au bon endroit, afin que le modèle puisse voir l’intégralité du contexte dans une seule image.

Pour l’entrée, nous appliquons le même principe : les événements générés par l’agent sont dirigés directement vers le moteur de rendu, sans passer par la couche privilégiée du navigateur. Cette approche permet de respecter les limites de la sandbox, même sous contrôle automatisé. Nous ne souhaitons par exemple pas que cette classe d’événements synthétise des raccourcis clavier qui permettraient au navigateur d’effectuer des actions sans rapport avec le contenu web affiché.

La navigation de l’agent peut aussi s’effectuer dans un contexte « déconnecté » éphémère. Au lieu de partager le profil Incognito existant de l’utilisateur, ce qui pourrait se traduire par la divulgation d’informations confidentielles, nous utilisons des partitions de mémoire distinctes grâce à l’infrastructure StoragePartition de Chromium. Chaque session d’agent démarre de zéro, et lorsqu’elle se termine, tous les cookies et toutes les données du site sont supprimés. Il est possible d’exécuter plusieurs sessions d’agent « déconnectées », chacune dans son propre onglet de navigateur, et totalement isolée des autres.

Rien de tout cela ne serait possible sans la communauté Chromium mondiale et son rôle majeur dans la création de fondations pour le Web moderne. OWL s’appuie sur cette base d’une manière nouvelle : en dissociant le moteur de l’application, en combinant une plateforme web de première ordre avec des frameworks natifs modernes, et en proposant une architecture plus rapide et plus flexible.

En repensant la manière d’intégrer Chromium dans un navigateur, nous créons un espace propice à de nouvelles expériences : démarrages plus fluides, interface utilisateur plus riche, intégration plus étroite avec le reste du système d’exploitation et adaptation du cycle de développement au rythme accéléré des idées. Si ce type de défi vous intéresse, consultez nos offres d’emploi pour travailler sur Atlas comme Ingénieur logiciel, Atlas⁠, Ingénieur logiciel, iOS⁠, ou nos autres offres⁠.

Essayez Atlas, sur chatgpt.com/atlas⁠⁠(ouverture dans une nouvelle fenêtre).