IBM souhaite que son assistant de programmation dépasse le simple rôle de générateur de fragments de code. La société a enrichi IBM Bob avec des sous-agents, une exécution parallèle d’outils, un contrôle du coût de l’intelligence artificielle et des flux de travail spécialisés pour moderniser les applications d’entreprise construites sur IBM Z, IBM i et Java.

L’approche vise un problème que rencontrent de plus en plus d’entreprises utilisant l’IA pour le développement logiciel : accélérer la rédaction du code ne garantit pas une livraison plus rapide en production. Les revues, tests, analyses de dépendances, sécurité et validation peuvent devenir de nouveaux goulets d’étranglement. Bob cherche à couvrir l’ensemble du processus par des méthodes reproductibles impliquant modèles, outils automatisés et intervenants humains.

IBM Bob : les points clés en 20 secondes

• IBM Bob intègre des sous-agents opérant dans des contextes distincts.
• Il peut exécuter plusieurs outils en parallèle pour une même tâche.
• Bobalytics permet de monitorer l’utilisation, la performance et les coûts liés à l’IA.
• Les workflows structurent les projets de modernisation avec des étapes auditées.
• IBM propose des packages spécifiques pour IBM Z, IBM i et les applications Java.
• Le package Java facilite la planification de migrations jusqu’à Java 25.
• Sur IBM i, il peut travailler avec RPG, COBOL, CL, DDS et Db2 for i.
• Pour IBM Z, il intègre des connaissances sur COBOL, PL/I, JCL et dépendances mainframe.
• Les actions modifiant fichiers ou exécutant des commandes requièrent toujours une autorisation.
• Ces améliorations ciblent les équipes d’entreprise, pas seulement les développeurs individuels.

IBM Bob V2 a été mis à disposition générale le 24 juin 2026, avec une architecture redéfinie. La nouvelle version dissocie le raisonnement de l’agent, l’infrastructure partagée et les interfaces utilisateur. IBM indique que plus de 100 000 employés de la société utilisent déjà la plateforme, allant des équipes mainframe aux projets cloud-native.

Le problème ne se limite plus à écrire du code

Les premiers assistants de programmation basés sur l’IA se concentraient sur la complétion de fonctions, l’explication de fragments ou la génération de tests. Ce modèle est utile pour des tâches précises, mais ses limites apparaissent quand il faut traiter une application composée de milliers de fichiers, de plusieurs bases de données et de plusieurs décennies de logique métier.

Mettre à jour une plateforme Java de Java 8 à Java 25 nécessite plus que de modifier la syntaxe. Il faut identifier des bibliothèques incompatibles, revoir la configuration, mettre à jour les dépendances, ajuster les pipelines et exécuter des tests pour s’assurer que le comportement global demeure intact.

La difficulté s’accroît dans les environnements IBM Z et IBM i. De nombreuses applications gèrent des processus critiques dans les secteurs de la banque, des assurances, de la distribution ou de l’industrie, et combinent des codes écrits à différentes époques, une documentation incomplet, ainsi qu’un savoir souvent détenu par des professionnels proches de la retraite.

IBM présente Bob comme une plateforme capable de planifier, exécuter, valider et gouverner ces changements. L’agent peut analyser le dépôt de code, proposer une stratégie, appliquer des modifications et s’arrêter à des points où une intervention humaine est requise pour la revue ou l’approbation.

Ce qui différencie cet assistant d’un système classique, c’est son étendue. Il ne se limite pas à répondre à une demande isolée, mais maintient l’état d’une tâche comportant plusieurs étapes et coordonne différents ressources pour la mener à terme.

Sous-agents pour éviter le bruit dans le contexte

Une innovation clé est l’introduction des sous-agents. Lorsqu’il doit investiguer une partie spécifique du système, Bob peut ouvrir un contexte distinct pour cette tâche.

Un sous-agent peut analyser le fonctionnement de l’authentification, suivre les appels entre modules ou rechercher toutes les dépendances d’une classe. Ensuite, il fournit une synthèse à l’agent principal, tout en rejetant les étapes intermédiaires qui ne sont plus nécessaires.

Ce découpage répond à une limitation commune des modèles de langage. Chaque lecture, recherche ou test occupe de l’espace dans la fenêtre de contexte. Dans de grands projets, l’agent peut accumuler des informations non pertinentes et perdre de vue l’objectif initial.

IBM indique que Bob V2 étend sa fenêtre de contexte de 200 000 à 270 000 tokens. Mais le changement le plus précieux pourrait être justement de ne pas la saturer avec tout ce qui se passe durant une recherche.

Ces capacités sont intégrées dans une vision évolutive vers les systèmes multi-agents. Néanmoins, il convient de préciser que Bob utilise déjà des sous-agents spécialisés, et que la gestion autonome de plusieurs agents en une seule tâche reste un axe de développement à suivre chez IBM.

Ce qui change avec IBM Bob V2

Bob V2 permet également de solliciter plusieurs outils dans une seule interaction. Au lieu de lire un fichier, attendre, en ouvrir un autre, puis lancer une recherche, le modèle peut exécuter toutes ces opérations simultanément. Selon les mesures internes d’IBM, certaines tâches qui prenaient environ 30 secondes dans la version précédente peuvent désormais se terminer en moins de dix. Il s’agit d’une évaluation du fabricant, non d’un benchmark indépendant applicable à tous les projets.

Les opérations de consultation d’information restent plus rapides, tandis que celles qui modifient l’état du projet, comme éditer des fichiers ou lancer des commandes, demeurent sous contrôle d’autorisation explicite.

Bobalytics : le coût de l’IA intégré au processus

Choisir un modèle moins coûteux ne garantit pas que la tâche sera économique dans sa totalité. Un agent peut multiplier les recherches, lire en boucle les mêmes fichiers, ouvrir des contextes auxiliaires et activer plusieurs outils avant de répondre.

IBM a intégré Bobalytics pour donner de la visibilité sur la consommation d’IA. La fonction permet de suivre l’utilisation, d’allouer les ressources et de quantifier le coût par rapport à la productivité, la qualité ou la performance.

Ce contrôle devient crucial quand des centaines ou milliers de développeurs utilisent des agents quotidiennement. Une différence minime dans le nombre d’appels ou de tokens peut représenter une somme importante à l’échelle de toute une organisation.

L’objectif d’IBM est d’ajuster en totalité le système d’exécution : choix du modèle, affectation des tâches à chaque agent, outils sollicité, et volume de contexte utilisé. La finalité est d’éviter que chaque développeur doive manuellement sélectionner des modèles sans connaître l’impact financier réel.

Bobalytics répond aussi à des préoccupations budgétaires et de gouvernance de l’IA. Les entreprises doivent savoir qui utilise quels modèles, pour quels projets, avec quels budgets et quels résultats en retour.

Trois packages pour les environnements complexes ne se limitant pas à un simple prompt

La nouveauté notable concerne les packages premium. IBM a structuré son expertise en plateformes d’entreprise dans des workflows spécifiques, modulables selon chaque organisation.

IBM Z : analyser avant de modifier

Le package pour IBM Z s’appuie sur l’ancien watsonx Code Assistant for Z, en visant à analyser des applications complètes, pas seulement des programmes isolés. Il exploite données sur le langage, middleware, métadonnées et analyse statique pour construire une vue consultable des dépendances d’une application.

Une modification apparemment mineure dans une table peut impacter COBOL, batch, JCL, interfaces ou systèmes connexes. Bob tente d’identifier ces relations avant toute modification pour appliquer les normes organisationnelles durant tout le processus.

IBM estime que ses flux structurés peuvent réduire de 50 à 80 % l’effort dans certains scénarios et accélérer de 20 à 40 % des projets complexes. Ces estimations dépendent cependant de l’état du code, de la documentation et des tests disponibles, ainsi que de la préparation des équipes.

IBM i : exploiter la connaissance RPG accumulée

Le package IBM i permet une connexion directe aux environnements, membres source et applications. Il peut lire, écrire et compiler sans obliger à déplacer le code dans une autre plateforme.

Les workflows comprennent l’explication de programmes RPG et COBOL, la conversion de RPG fixe en RPG libre, la refonte d’applications monolithiques, la génération de documentation et la création de tests unitaires.

Il propose également un mode spécifique pour analyser SQL, DDS et requêtes sur Db2 for i, aidant à préserver le savoir dans des bases de code souvent peu documentées.

Java : de versions anciennes à Java 25

Le package Java couvre trois axes principaux : migration vers Java 11, 17, 21 ou 25 ; modernisation des interfaces basées sur JSF ou Struts vers des architectures web modernes ; migration d’applications WebLogic, Tomcat ou WebSphere Traditional vers WebSphere Liberty.

Les flux comprennent l’analyse de dépendances, l’identification d’incompatibilités, des modifications de code et de configuration, la validation, la documentation et un processus d’approbation humaine.

IBM cite un cas fictif où une modernisation de Java 11 à Java 25 aurait été réalisée en trois jours — contre plus de 30 jours en mode traditionnel. IBM estime une réduction de 90 % du délai, mais il reste à vérifier ces chiffres dans le contexte réel, puisqu’il s’agit d’un exemple fourni par IBM.

L’évaluation ne sera pas dans la quantité de code généré, mais dans la qualité des tests

L’évolution d’IBM Bob traduit une tendance du marché : les assistants de code jouent de moins en moins sur la rapidité d’écriture et de plus en plus sur la capacité de travailler dans des processus complexes en conservant contrôle, traçabilité et sécurité.

La génération automatique peut augmenter la volumétrie de logiciel soumis à examen, mais si les tests, l’analyse de sécurité et la validation n’évoluent pas au même rythme, cela risque d’accumuler les goulots d’étranglement en fin de processus.

Les workflows de Bob cherchent à réduire cette variabilité en définissant précisément quand une automatisation doit intervenir, quand un modèle est utile et à quels moments une intervention humaine est indispensable. Le système maintient l’état, gère les erreurs et reproduit la séquence pour d’autres applications.

Cette démarche s’inscrit dans la logique métier d’IBM, qui maîtrise parfaitement les environnements mainframe, IBM i et Java, où les assistants généralistes ont souvent moins de contexte et où une erreur peut avoir des impacts critiques.

Reste à voir dans quelle mesure ces résultats pourront être généralisés. Un code bien documenté, avec des tests automatiques et des dépendances maîtrisées, sera plus simple à moderniser qu’une application patrimoniale sans couverture de tests.

Bob facilite la recherche d’informations, propose des modifications et coordonne les tâches. La décision finale sur la mise en production revient toujours à l’équipe. Dans les systèmes critiques, la distinction entre autonomie et supervision sera d’autant plus cruciale que la sécurité et la traçabilité sont prioritaires.

Questions fréquentes

Qu’est-ce qu’IBM Bob ?
Une plateforme logicielle alimentée par l’IA pour planifier, exécuter, valider et gouverner les tâches tout au long du cycle de vie d’une application.

IBM Bob utilise-t-il plusieurs agents ?
Oui, avec des sous-agents travaillant dans des contextes séparés, et IBM développe également la gestion multi-agents plus large.

Qu’est-ce que Bobalytics ?
Une fonction d’analyse d’usage et de coûts, permettant de superviser consommation, performance et allocation des ressources IA.

Pouvons-nous moderniser COBOL et Java ?
Oui, IBM propose des packages dédiés pour IBM Z, IBM i et Java, dont l’efficacité dépendra notamment de l’état du code, des dépendances et des tests existants.

Source : newsroom.ibm