IBM Bob

Bob V2 : Plus rapide, meilleur, plus intelligent

Tout ce qu'on a appris avec V1, reconstruit de zéro.

Bob V2 : Plus rapide, meilleur, plus intelligent

Auteurs

IBM Bob Team

Publié

Catégorie

release

Partager

Bob V2 : plus rapide, meilleur, plus intelligent

Bob V2 est disponible en disponibilité générale le 24 juin, et c'est une vraie avancée pour le quotidien : il est plus rapide, il peut exécuter des tâches en arrière-plan pendant que tu travailles sur autre chose, et il repose sur un agent unique qui se comporte de façon identique sur tous les clients. Cet agent est d'abord disponible dans Bob IDE, suivi bientôt par Bob Shell. La seule étape de mise à jour consiste à installer la nouvelle version ; les paramètres existants, les fichiers de règles et les serveurs MCP sont automatiquement repris.

Ce que couvre cet article :

  • En quoi consiste la nouvelle architecture
  • Les changements visibles au quotidien : performances, les nouveaux modes, les tâches en arrière-plan, le rollback, le travail avec des documents, et les subagents
  • Les workflows — un framework pour rendre les modifications volumineuses et multi-phases reproductibles

Testé sur IBM en premier

Le premier client de Bob, c'est IBM lui-même, où plus de cent mille développeurs sont intégrés, sur tout type de système, des mainframes aux services cloud natifs. V2 a été soumis à une large population interne bien avant la disponibilité générale. Les fonctionnalités présentées ici ont été déployées progressivement dès début mai, de sorte que chacune avait une utilisation réelle en production avant d'être livrée.

Un agent, un harness, plusieurs clients

L'extension IDE et le shell de Bob V1 reposaient sur deux fondations séparées. C'était un choix délibéré pour mettre Bob entre les mains des développeurs rapidement, mais cela signifiait devoir développer chaque amélioration deux fois — et les demandes évoquées plus haut sont exactement le type de changements qu'une base de code divisée rend longs à livrer.

V2 remplace tout ça par une architecture à trois niveaux qui sépare clairement le raisonnement de l'infrastructure et de l'interface :

ComposantRôle
The AgentLa boucle agentique. Tout le raisonnement et la génération de code se passent ici, de façon identique dans chaque client.
The HarnessL'infrastructure partagée : authentification, journalisation, feature flags, télémétrie.
The ClientsLes interfaces — IDE, shell, et d'autres à venir — sans logique dupliquée.

Ce qui change au quotidien

Avant d'aborder les fonctionnalités individuelles, la surface sur laquelle elles s'appuient a changé. Le chat de V2 est volontairement plus discret : les appels d'outils intermédiaires et les explorations sans issue se rétractent, de sorte que ce qui reste devant toi, c'est le travail et son résultat, pas les rouages qui tournent en coulisses.

Subagents : garder le contexte propre

Au fil du traitement d'une tâche complexe par Bob, la conversation se remplit de lectures de fichiers, de recherches et d'explorations sans issue. La plupart de ces détails n'ont pas d'importance pour la tâche principale, mais ils consomment tout de même de la fenêtre de contexte.

Les subagents gèrent ça. Quand Bob doit faire quelque chose d'autonome — « comprendre comment fonctionne l'authentification dans cette base de code » — il lance un subagent avec son propre contexte vierge. Le subagent lit les fichiers, trace les appels et détermine le schéma ; seul le résumé revient à l'agent principal, et les étapes intermédiaires sont effacées.

Appels d'outils parallèles et natifs

Dans V1, les appels d'outils s'exécutaient un par un : demander une lecture de fichier, attendre le résultat, puis demander le suivant. Sur une tâche qui se ramifie sur cinq lectures de fichiers et trois recherches, ce temps d'attente s'accumule vite. V2 permet au modèle de demander plusieurs outils en un seul tour et de les exécuter ensemble. Une tâche qui prenait environ 30 secondes dans V1 se termine souvent en moins de 10.

Les appels d'outils natifs suppriment aussi le XML verbeux que V1 enveloppait autour de chaque requête d'outil, de sorte que la même tâche consomme moins de tokens. La fenêtre de contexte est également plus grande — passant de 200k à 270k tokens — donc les tâches plus longues avancent davantage avant que la compaction n'intervienne.

Parallel tool calling in Bob 2.0.0

Trois modes : Agent, Plan, Ask

V2 regroupe les cinq anciens modes de Bob en trois :

  • Agent — Bob agit et mène la tâche à bien, avec toutes les capacités agentiques.
  • Plan — Bob suit un processus de planification structuré — recueil des besoins, exploration du contexte, vérification de sa compréhension — et produit un plan d'action à transmettre à Agent.
  • Ask — lecture seule. Bob explique l'architecture et la logique sans toucher à la base de code.

Le conseil n'a pas changé : sur du code inconnu, ou une modification avec une vraie surface d'impact, commence par Ask ou Plan et bascule vers Agent une fois que le travail est clair.

different_modes

Moins d'interruptions, même contrôle

Les opérations de lecture — lire des fichiers, lister des répertoires, chercher dans le code — sont approuvées par défaut maintenant, donc Bob peut rassembler du contexte sans s'arrêter pour demander. Tout ce qui modifie un état nécessite toujours une approbation explicite : modifications de fichiers, exécution de commandes, appels d'outils MCP, invocations de skills. L'approbation n'est qu'une couche parmi d'autres — elle coexiste avec le rollback, les règles personnalisées et les fichiers ignore — et peut être resserrée ou assouplie par classe d'outil.

different_modes

Tâches en arrière-plan

Bob ne limite plus une session à une seule conversation. Un développeur peut lancer plusieurs tâches en même temps, les laisser tourner en arrière-plan et continuer à travailler. Chaque tâche conserve son propre fil et son propre contexte, donc passer de l'une à l'autre reprend là où tu en étais. Le panneau des tâches montre ce qui est en cours, ce qui est terminé et ce qui nécessite une attention ; les tâches terminées se nettoient d'elles-mêmes. Et Bob reste discret pendant leur exécution — une tâche qui se termine en arrière-plan ne captera pas ton attention ni ne changera l'onglet sur lequel tu travailles.

Rollback, repensé

V1 appelait ça des checkpoints et s'appuyait sur git, ce qui le contraignait : un dépôt sans git n'avait aucun checkpoint, et un historique très volumineux ralentissait tout. V2 simplifie l'ensemble et le renomme rollback. Il suit désormais l'état des fichiers directement — par tâche, par tour de conversation, par appel d'outil individuel — et n'importe lequel de ces points peut être restauré. Comme le rollback vit dans l'agent plutôt que dans un client, il fonctionne de la même façon partout où l'agent tourne.

new_checkpoints

Travailler avec des documents

Une grande partie du contexte d'une tâche se trouve en dehors de la base de code — un doc de conception, une spec rédigée, un tableur de cas de test. V2 lit nativement les fichiers .docx, .pdf et .xlsx : glisse-en un dans la conversation et Bob travaille directement à partir de lui, sans copier-coller ni étape d'extraction séparée.

Idem pour ce qui en ressort. À la fin d'une tâche d'analyse, Bob peut produire un résumé HTML autonome de ce qu'il a trouvé — une seule page, qui s'ouvre dans n'importe quel navigateur, sans outillage particulier pour la lire. Le résultat d'une investigation devient alors quelque chose que tu peux transmettre à quelqu'un qui n'était pas dans la session.

Les configurations existantes sont reprises

Le travail investi dans un autre outil de coding IA devrait pouvoir être réutilisé plutôt que de repartir de zéro. V2 lit les conventions existantes, les fichiers de règles, les commandes et les serveurs MCP, et ajoute la prise en charge du format de plugin devenu un standard de facto dans l'écosystème — de sorte que les collections d'outils courantes fonctionnent directement dans Bob. Les serveurs MCP avaient déjà leur propre onglet de paramètres dans V1 ; V2 ajoute un onglet dédié aux skills à côté, pour pouvoir ajouter, configurer et supprimer des skills de la même façon, sans modifier des fichiers à la main.

Workflows : rendre les modifications multi-phases reproductibles

L'IA est douée pour la résolution de problèmes ouverts et mauvaise pour faire la même chose deux fois. Demande-lui de « migrer ça vers Java 21 » à deux jours différents et elle peut retourner deux approches différentes et deux résultats différents. Pour un usage ponctuel, ça convient. Pour de grands travaux en entreprise — moderniser une application mainframe, refactoriser des milliers de fichiers, tout ce qui s'exécute en phases — cette variabilité est précisément le problème.

Les workflows donnent à ce type de travail une colonne vertébrale. Le point de départ est que toutes les étapes ne nécessitent pas l'IA, et toutes les étapes ne devraient pas être entièrement automatisées :

  • Certaines étapes sont de la simple automatisation — scanner les dépendances, exécuter les tests.
  • Certaines ont besoin de l'IA — transformations de code complexes, analyse de patterns.
  • Certaines ont besoin d'un humain — valider une stratégie, revoir les diffs avant un commit.

Un workflow définit où appartient chaque étape. Le moteur exécute les étapes dans l'ordre, conserve l'état, gère les erreurs et rend l'ensemble du processus reproductible.

C'est là qu'interviennent les packages premium d'IBM. Chacun embarque des workflows testés et structurés, construits sur des décennies de travail d'IBM dans son domaine, et chacun est une offre distincte avec son propre article à venir : l'IBM Bob Premium Package for Java Modernization, le Premium Package for IBM i, et le Premium Package for IBM Z. À la disponibilité générale, les workflows disponibles sont ceux fournis avec Bob et ces packages ; la création plus large s'ouvrira une fois que la surface de l'API se stabilise avec les premiers adoptants.

Pour la suite

La même architecture ouvre des perspectives qui n'étaient tout simplement pas envisageables avec l'ancienne fondation. Nous n'attachons délibérément pas de dates ni d'engagements à tout cela, mais les grandes directions que nous explorons incluent l'exécution d'agents à distance accessibles depuis n'importe quel client, la coordination de plusieurs agents sur une seule tâche, et l'apport de Bob sur davantage de clients au fil du temps. Là où tout ça atterrira vraiment sera façonné par ce dont les premiers adoptants ont le plus besoin.

Mise à jour le 24 juin

Bob V2 sera disponible le 24 juin sous forme d'une mise à jour de version ordinaire. Mettre à jour l'extension IDE la bascule vers la nouvelle architecture ; Bob Shell suit bientôt. Il n'y a aucune étape de migration ; les paramètres, les fichiers de règles et les serveurs MCP sont repris.

Une chose qui vaut la peine d'essayer dans la première semaine : lance une tâche en mode Plan, transmets le plan à Agent, et laisse-le tourner en arrière-plan en parallèle d'autre travail.

Liens