IBM Bob : développer avec l’IA sans faire sortir son code de l’entreprise

IIBM annonce une version auto-hébergée de Bob, sa plateforme de développement agentique, pour les infrastructures internes, les clouds privés ou souverains et les environnements isolés d’Internet.[1] Cette possibilité répond à un obstacle concret : certaines applications contiennent un code, des données ou une logique métier que l’entreprise souhaite conserver dans son environnement. Encore faut-il vérifier où les modèles exécutent réellement leurs traitements.

L’assistant rejoint l’environnement de travail de l’entreprise

Selon IBM, Bob accompagne la compréhension des applications, la planification des tâches, l’exécution des changements et leur validation. L’offre auto-hébergée conserve notamment une expérience dans l’environnement de développement et l’outil BobShell.[2] L’ambition dépasse donc la suggestion de quelques lignes de code.

Pour une équipe qui maintient un logiciel ancien, l’intérêt potentiel serait de préparer une évolution en tenant compte du fonctionnement existant. Les règles de facturation, les interfaces avec d’autres systèmes ou les traitements particuliers constituent souvent une partie importante de la valeur du logiciel. Leur confidentialité peut peser autant que celle du code lui-même.

Auto-héberger Bob ne signifie pas toujours exécuter le modèle localement

IBM distingue les modèles installés et administrés par le client des configurations hybrides utilisant un service externe compatible. Dans une configuration locale prise en charge, le code, le contexte de développement et les artefacts de compilation peuvent rester dans l’environnement du client.[2]

Le choix décisif porte sur l’inférence, c’est-à-dire l’exécution du modèle lorsqu’il traite une demande. Héberger l’assistant dans son infrastructure ne suffit donc pas à établir que toutes les données y restent. Il faut également examiner les modèles utilisés et les connexions nécessaires au fonctionnement retenu.

IBM cite NVIDIA Nemotron et Poolside Laguna parmi les modèles auto-hébergés compatibles au lancement. Le client doit fournir l’accès à un modèle pris en charge ; certaines licences existantes peuvent être réutilisées sous conditions.[2] La compatibilité et les droits d’usage font ainsi partie du projet.

Quatre décisions qui déterminent le contrôle réel

Cette grille propose les questions à examiner avant un déploiement. Elle ne constitue pas une certification de sécurité de Bob.

Garder les données à l’intérieur ne supprime pas les erreurs

Un environnement isolé d’Internet, souvent appelé « air-gapped », peut répondre à une exigence de séparation des réseaux. IBM annonce la prise en charge de ce type de déploiement avec des modèles compatibles.[1] Cette propriété concerne l’architecture ; elle ne démontre pas à elle seule la qualité du code produit.

L’équipe doit toujours vérifier les modifications, les dépendances ajoutées et les conséquences sur les applications. Un agent autorisé à agir dans un périmètre trop large peut provoquer des changements indésirables même sans connexion externe. Les permissions, les tests et les possibilités de restauration restent des décisions d’exploitation.

Pour une PME, évaluer la valeur sur un projet délimité

Une PME qui développe un logiciel propriétaire pourrait commencer par une tâche circonscrite, par exemple documenter un module ou préparer sa modernisation dans une branche dédiée. Ce scénario constitue une proposition de pilote, pas un résultat client publié par IBM.

L’évaluation devrait mesurer le temps gagné après relecture et correction, la pertinence des tests proposés et les défauts détectés avant intégration. Le budget doit aussi inclure les licences, les ressources de calcul, l’administration et la maintenance. Les deux annonces consultées ne fournissent ni coût complet type ni comparaison indépendante des performances selon les configurations.

Le développeur garde la maîtrise des changements

Cette évolution renforce l’importance de la Programmation et Gestion Web. Comprendre le code, ses dépendances et les besoins métier permet de formuler une tâche que l’agent peut traiter, puis de juger si sa proposition respecte réellement les exigences du projet.

La revue de code reste centrale. Le développeur doit repérer une hypothèse incorrecte, une bibliothèque inadaptée ou un test qui confirme seulement le fonctionnement imaginé par l’agent. Il lui revient de confronter les changements aux usages réels et aux contraintes de maintenance.

Son rôle comprend également l’organisation du travail délégué : préciser le périmètre, sélectionner le contexte utile, contrôler les actions et décider de l’intégration. L’hébergement interne rapproche l’outil du patrimoine logiciel, mais la responsabilité de faire évoluer ce patrimoine reste humaine.

La souveraineté se vérifie dans la configuration choisie

L’annonce ouvre une possibilité pour les organisations dont les contraintes limitent le recours à des assistants externes. Sa valeur dépendra de l’ensemble du dispositif : modèles compatibles, flux de données, accès autorisés et capacité à exploiter le service. La décision devrait reposer sur un pilote documenté, avec des gains mesurés et des responsabilités clairement attribuées.

L’Actu IT à 360°, décrypter la technologie pour comprendre les métiers de demain.

Découvrir CCCLX →