Le déploiement auto-hébergé mène la version de ce mois

Depuis le 24 septembre 2026, IBM Bob est disponible pour le déploiement auto-hébergé. Le backend Bob s'exécute sur les clusters Red Hat OpenShift que l'organisation opère elle-même, on-premises ou dans son propre compte cloud. Le modèle est soit un frontier model provenant d'un service de modèles cloud que l'organisation utilise déjà, soit un modèle open-weight sur ses propres GPU. Les développeurs continuent d'utiliser les mêmes Bob IDE et Bob Shell qu'ils connaissent déjà. La version de ce mois ajoute également des processus en arrière-plan, un client MCP mis à jour et de nouveaux contrôles pour les administrateurs.

Le service cloud Bob reste le choix par défaut idéal pour la plupart des équipes d'ingénierie : aucune infrastructure à gérer, des mises à jour automatiques et un backend opéré par ceux qui l'ont construit. Pour de nombreuses grandes organisations d'ingénierie, ce choix par défaut n'est pas envisageable car leur code source ne peut pas quitter l'infrastructure qu'elles contrôlent. Sous les règles de résidence des données, Bob peut utiliser un frontier model via le propre compte cloud de l'organisation. Sur un réseau air-gapped, Bob utilise un modèle open-weight sur les propres GPU de l'organisation.

Déploiement auto-hébergé

Ce qu'un déploiement auto-hébergé inclut

Le déploiement auto-hébergé packagise le backend Bob pour Red Hat OpenShift. Il comprend la gestion de l'identité, l'inference gateway, les logs d'audit et la mesure de l'utilisation (metering), le tout géré par un operator qui prend en charge l'installation, les mises à niveau et les opérations de jour 2. Bob s'exécute comme une charge de travail ordinaire dans un namespace, de sorte qu'il peut partager un cluster existant avec d'autres applications.

Les développeurs continuent de travailler dans Bob IDE et Bob Shell comme auparavant. L'endpoint auto-hébergé est généralement distribué via une group policy, de sorte que les clients se connectent au cluster interne sans aucune configuration du côté du développeur. L'agent harness sous-jacent est identique à celui qui fonctionne avec le service cloud.

Les packages premium fonctionnent également dans un déploiement auto-hébergé : IBM Bob Premium Package for Java Modernization, IBM Bob Premium Package for IBM i et IBM Bob Premium Package for Z (PP4Z). Un administrateur Bob les attribue aux utilisateurs dans la même Admin UI que dans le service cloud. PP4Z apporte ses propres composants backend, notamment Z Understand, et l'administrateur du cluster décide lors de l'installation s'il souhaite les déployer.

Deux façons de connecter un modèle

Bob auto-hébergé se connecte à un modèle de deux manières différentes.

Frontier models via le compte cloud de l'organisation. Bob peut utiliser des frontier models via AWS Bedrock, Azure OpenAI, Google Vertex AI ou tout autre service de modèles compatible OpenAI. Le backend Bob, l'identité, les logs d'audit et le metering restent sur le cluster. Les requêtes de modèle, y compris le contexte de code qu'elles transportent, vont vers le propre compte cloud de l'organisation selon les accords dont elle dispose déjà. Cette option convient aux organisations qui disposent déjà d'un accès approuvé à un service de modèles cloud mais ont besoin de garder tout le reste sous leur propre contrôle.

Entièrement auto-hébergé. Pour les réseaux sans connexion sortante, le modèle s'exécute sur les propres GPU de l'organisation. Deux modèles open-weight sont pris en charge pour cette option : NVIDIA Nemotron 3 Ultra et Poolside Laguna S 2.1. L'agent harness de Bob a été ajusté et évalué pour chacun d'entre eux. Le dimensionnement matériel suit les recommandations de chaque fournisseur, car il dépend de la quantification, de la longueur de contexte et du nombre de développeurs servis simultanément. Un petit modèle de guardrail filtre les entrées et les sorties sur cette option, et Bob IDE et Bob Shell le prennent automatiquement en compte une fois configuré.

Une installation en deux étapes

L'installation est gérée par bobctl, le CLI d'installation de Bob pour les déploiements auto-hébergés, et se déroule en deux étapes. La première crée les éléments au niveau du cluster : définitions de ressources, permissions et l'operator. Elle nécessite des droits cluster-admin et, dans la plupart des entreprises, passe par la revue de modifications de l'équipe plateforme. La seconde étape installe Bob lui-même dans un namespace et ne nécessite qu'un accès au niveau du namespace.

Cette séparation signifie que l'équipe plateforme examine et approuve l'empreinte au niveau du cluster une seule fois. Ensuite, l'équipe responsable de Bob peut l'installer, le mettre à niveau et le reconfigurer sans détenir de droits cluster-admin ni ouvrir de ticket pour chaque modification.

Les clusters entièrement air-gapped constituent un chemin d'installation pris en charge. bobctl réplique les images de Bob dans un registre privé, y compris dans le cas où les images sont téléchargées sur une machine connectée, transférées à travers le gap et poussées depuis le côté isolé.

Une installation OpenShift sur un seul nœud suffit pour un proof of concept. Le dimensionnement pour la production et les prérequis sont détaillés dans la documentation d'installation.

Identité via l'annuaire d'entreprise

Un déploiement auto-hébergé inclut son propre service d'identité, basé sur Keycloak, qui peut être connecté au LDAP ou à l'Active Directory de l'organisation. Une fois connecté, les développeurs s'authentifient avec leurs identifiants d'entreprise et les accès suivent l'annuaire : les personnes ajoutées sont provisionnées dans Bob, et celles supprimées perdent automatiquement leur accès. Les installations plus modestes et les proofs of concept peuvent gérer les utilisateurs directement dans le service d'identité à la place.

Comment obtenir Bob auto-hébergé

Le déploiement auto-hébergé est géré par l'équipe commerciale. Pour assister à une démo ou démarrer un proof of concept, contacte un représentant IBM ou un Business Partner, ou utilise Contact Sales sur bob.ibm.com. L'équipe de compte configure les droits d'accès (entitlement) pour l'organisation, y compris les éventuels packages premium.

Commence par un proof of concept OpenShift sur un seul nœud pointant vers un endpoint de modèle que l'organisation utilise déjà, et connecte le Bob IDE d'une équipe à celui-ci. La documentation sur le déploiement auto-hébergé couvre le parcours complet jusqu'à la production, y compris l'installation air-gapped, la sauvegarde et la restauration.

Plus dans la version de ce mois

Client MCP mis à jour vers v2

Le client MCP prend désormais en charge la spécification MCP 2026-07-28, y compris le transport stateless Streamable HTTP, tout en conservant la compatibilité avec les serveurs MCP 2025 Streamable HTTP et stdio. La gestion du protocole OAuth passe côté client.

Breaking change : La prise en charge du transport HTTP+SSE a été supprimée, et Bob rejette les configurations HTTP+SSE au démarrage. Les serveurs MCP utilisant encore HTTP+SSE doivent être mis à jour vers Streamable HTTP avant de mettre à niveau Bob.

Pour les administrateurs

Group policy RequiredExtensions. La group policy qui distribue l'endpoint auto-hébergé peut désormais également installer des extensions VS Code. Les administrateurs listent les identifiants d'extension dans la nouvelle policy RequiredExtensions, et Bob les installe depuis la marketplace au démarrage, sans aucune action requise de la part du développeur. La policy utilise les mêmes templates ADMX/ADML, le mobile device management et les mécanismes de fichiers de policy qui régissent déjà les propres paramètres de Bob.

Répertoires de plugins. Les skills, modes, fichiers de règles et configurations MCP peuvent désormais être placés sous .bob/plugins/<plugin-name>/ au niveau du workspace, ou ~/.bob/plugins/<plugin-name>/ de manière globale, et Bob les charge au démarrage. Une équipe peut distribuer un mode personnalisé, les règles qu'il référence, les skills qu'il invoque et une configuration MCP ensemble dans un seul répertoire de plugin. La disposition existante à la racine continue de fonctionner.

Pour les développeurs

Processus en arrière-plan. Les builds, watchers, dev servers et autres commandes de longue durée démarrent désormais en arrière-plan au lieu de bloquer la conversation. Un indicateur dans la vue de chat montre ce qui est en cours d'exécution ; clique dessus pour inspecter la sortie ou arrêter le processus.

Récupération de pages web (expérimental). Bob peut récupérer une page de documentation, une référence d'API ou une autre URL connue et la lire au format Markdown ou texte brut. Active d'abord web_fetch dans Settings → Chat.

Lifecycle hooks de compaction. PreCompact s'exécute avant la compaction du contexte et peut la bloquer ; PostCompact s'exécute une fois celle-ci terminée. /compress dans le champ de saisie du chat déclenche la compaction manuellement.

Largeur de chat configurable. Settings → Chat → Appearance propose Default, Wide et Full width, et ce choix persiste entre les sessions.

Également dans cette version

Les événements de hooks peuvent être envoyés à des endpoints HTTPS. Les gestionnaires de hooks HTTP sont désormais configurables dans l'interface Bob Settings.
watsonx Governance est désormais disponible dans le Bob Marketplace.
Les questions de suivi (follow-up) apparaissent désormais une par une plutôt que par lot.
Les noms des serveurs MCP sont conservés dans les identifiants d'outils (tool IDs), ce qui facilite le traçage du serveur d'origine d'un appel d'outil donné.
Le watching de fichiers et la découverte de skills fonctionnent désormais dans les workspaces Remote SSH.
Les noms de répertoires de skills non valides affichent un avertissement au démarrage.

Essaie la dernière version

Avant de procéder à la mise à niveau, migre tout serveur MCP utilisant encore HTTP+SSE vers Streamable HTTP. Démarre ensuite un dev server dans une session et continue de travailler pendant qu'il s'exécute en arrière-plan.

Pour partager la configuration d'une équipe, place un mode personnalisé, les règles qu'il référence et les skills qu'il invoque sous .bob/plugins/<plugin-name>/ et commite le répertoire dans le repository. Bob charge le plugin au démarrage pour toute personne qui ouvre le workspace. Avec web_fetch activé, pointe Bob vers la référence d'API d'une bibliothèque avant de lui demander d'écrire du code l'utilisant.