IBM Bob en déploiement local : une IA de développement installée dans l’entreprise
IBM fait évoluer Bob au-delà du service accessible depuis le cloud public. Avec son déploiement local, l’agent de développement logiciel peut être installé sur les serveurs d’une organisation, dans un cloud privé ou souverain, et même dans un environnement isolé d’Internet. Le principe est simple : au lieu d’envoyer le code vers une plateforme distante, l’entreprise rapproche l’outil des systèmes qu’elle veut faire analyser ou modifier.
Cette option intéresse particulièrement les secteurs où le code source révèle des informations sensibles sur les opérations, les produits ou les dispositifs de sécurité. Une banque peut, par exemple, vouloir moderniser une application de paiement sans transmettre à un prestataire externe des éléments décrivant ses règles antifraude. Un hôpital peut chercher à automatiser la maintenance de logiciels internes tout en protégeant les informations liées à ses infrastructures et à ses flux de données.
Bob est présenté comme une IA agentique plutôt que comme un simple assistant qui suggère une ligne de code. L’utilisateur peut lui confier un objectif plus large : examiner une application, repérer les composants à modifier, proposer une démarche, effectuer des changements et lancer des vérifications. Cette capacité à enchaîner des étapes rapproche l’outil d’un collaborateur technique, même si les développeurs restent responsables de la revue, des décisions d’architecture et de la validation finale.
Des infrastructures adaptées aux contraintes de sécurité
Le logiciel peut fonctionner sur des serveurs détenus par l’entreprise, dans un cloud privé réservé à un client ou dans un cloud souverain soumis à des règles locales. Pour les organisations les plus contraintes, un environnement « air-gapped » permet de couper physiquement les machines des réseaux extérieurs. Cette configuration réduit les possibilités d’échange avec Internet, mais implique aussi une gestion rigoureuse des mises à jour, des dépendances et des procédures de support.
Pour les équipes de développement, IBM cherche à préserver une expérience familière. Bob s’intègre à l’environnement de programmation et propose notamment BobShell, des modes spécialisés et la possibilité de faire intervenir plusieurs outils. Une équipe peut donc répartir le travail entre l’analyse d’un module, la préparation de tests et l’examen d’une modification, sans nécessairement changer toute son organisation.
Le déploiement sur site ne transforme toutefois pas automatiquement un système en solution sûre. Il faut contrôler les droits d’accès, isoler les projets selon leur sensibilité, surveiller les actions automatisées et définir qui peut approuver une modification. Une installation locale déplace le périmètre de contrôle vers l’entreprise ; elle lui transfère aussi une part du travail opérationnel et de la responsabilité.
IBM justifie cette orientation par les difficultés rencontrées par les entreprises en matière de résidence des données. Son Institute for Business Value indique que 68 % des dirigeants interrogés peinent à satisfaire les exigences de souveraineté et de localisation d’une région à l’autre. L’enjeu ne se limite donc pas à choisir un outil de programmation : il consiste à déterminer où résident le code, les requêtes et les résultats produits par l’IA.
La proposition de Bob prend ainsi son sens dans les organisations qui veulent rapprocher l’IA de leurs applications critiques. Mais l’emplacement de l’agent ne suffit pas à établir le degré réel de souveraineté : le modèle qui l’alimente compte tout autant.
IA souveraine et données sensibles : ce que le choix de l’hébergement garantit
Le terme IA souveraine recouvre plusieurs exigences qu’il vaut mieux distinguer. Une entreprise peut vouloir conserver ses données sur un territoire précis, garder la maîtrise de son infrastructure, limiter l’accès d’acteurs tiers ou contrôler les modèles utilisés. Le déploiement local de Bob répond directement à une partie de ces objectifs, en donnant à l’organisation la possibilité d’exécuter la plateforme dans un environnement qu’elle administre.
Cette maîtrise est utile lorsqu’un dépôt de code contient des éléments qui ne doivent pas sortir du réseau interne : algorithmes propriétaires, interfaces avec des partenaires, détails de configuration ou composants liés à la sécurité. Même si un extrait paraît anodin, son association avec d’autres fichiers peut révéler l’architecture d’un service. Le traitement local réduit alors le nombre de transferts à autoriser et simplifie parfois l’analyse des flux de données.
Il reste essentiel de distinguer le lieu où fonctionne Bob de celui où s’effectuent les calculs du modèle. La plateforme peut être hébergée sur les serveurs de l’entreprise tout en sollicitant un modèle distant par une connexion privée. Dans ce scénario hybride, les requêtes et le contexte transmis au fournisseur externe doivent être examinés avec attention. Une connexion sécurisée protège le transport, mais ne signifie pas nécessairement que le contenu reste sous le contrôle exclusif du client.
Un exemple de segmentation selon la sensibilité
Une banque fictive, appelée ici Banque Atlas, pourrait classer ses projets en plusieurs niveaux. Les changements portant sur le système bancaire central seraient réservés à un modèle exécuté en interne, dans un environnement isolé. Les outils de gestion des ressources humaines pourraient, après une analyse de risque, utiliser une configuration hybride. Des prototypes sans données réelles pourraient enfin être traités avec une plus grande variété de services externes.
Cette approche au cas par cas évite de transformer la souveraineté numérique en règle uniforme impossible à appliquer. Elle oblige néanmoins à documenter les critères de classement : nature du code, conséquences d’une fuite, obligations contractuelles, localisation des utilisateurs et durée de conservation des échanges. Les équipes de sécurité peuvent ainsi définir des politiques précises au lieu de se contenter d’autoriser ou d’interdire l’IA de manière générale.
La gouvernance doit aussi porter sur les actions de l’agent. Si Bob peut modifier des fichiers, lancer des tests ou mobiliser des outils, il faut savoir quels privilèges lui sont accordés et comment ses interventions sont enregistrées. Une organisation prudente peut commencer par autoriser l’analyse et la génération de propositions, puis exiger une validation humaine avant toute modification ou intégration dans une branche principale.
Les environnements isolés apportent un niveau de confinement supplémentaire, mais ils ne suppriment pas les risques internes. Une erreur de configuration, un accès trop large ou une dépendance introduite sans contrôle peuvent compromettre un projet même en l’absence de connexion extérieure. La sécurité dépend donc autant des procédures et des équipes que de l’emplacement des serveurs.
Pour Banque Atlas, le critère déterminant ne serait pas seulement « Bob est-il local ? », mais « quelles données sont traitées par quel modèle, avec quels droits et quelles traces ? ». C’est à cette échelle que la promesse de souveraineté devient vérifiable.
Modèles d’IA compatibles avec IBM Bob : un choix encore limité en local
Bob n’est pas, à lui seul, le modèle qui comprend et génère le code. IBM fournit la plateforme agentique, tandis que le client doit sélectionner et raccorder un modèle parmi les options prises en charge. Il peut, dans certains cas, réutiliser des licences déjà détenues, mais la disponibilité d’un modèle dépend de son mode d’accès et de son aptitude à fonctionner dans l’infrastructure choisie.
C’est là que se situe la principale réserve à la promesse d’une IA souveraine. Pour une exécution entièrement locale, IBM cite notamment Nemotron de NVIDIA et Laguna de Poolside. En revanche, plusieurs modèles populaires mentionnés dans l’offre, dont Claude Sonnet 5.0 et Claude Opus 4.8 d’Anthropic, Gemini 3.7 Flash de Google et GPT 5.6 Sol d’OpenAI, sont présentés comme utilisables dans une configuration hybride, avec des calculs réalisés chez un fournisseur externe.
Le catalogue doit donc être lu en tenant compte de la différence entre compatibilité et hébergement. La présence d’un modèle dans la liste de Bob ne signifie pas nécessairement que l’entreprise peut l’exécuter sur ses propres machines. Pour conserver le code et son contexte dans son périmètre, elle doit choisir une option réellement auto-hébergée et disposer des ressources matérielles nécessaires.
Comparer les modes de fonctionnement avant de choisir
| Configuration | Lieu principal des calculs | Conséquence pour l’entreprise |
|---|---|---|
| Modèle auto-hébergé | Infrastructure contrôlée par le client | Meilleure maîtrise du code et du contexte, avec des besoins matériels et d’exploitation à assumer |
| Mode hybride | Modèle accessible auprès d’un fournisseur externe | Accès à davantage de modèles, sous réserve d’encadrer les données transmises et les conditions de service |
| Environnement air-gapped | Réseau interne déconnecté | Réduction des échanges extérieurs, mais mises à jour et maintenance plus complexes |
Dans l’exemple de Banque Atlas, le modèle local serait affecté aux dépôts les plus sensibles, tandis qu’un modèle distant pourrait servir à des tâches moins risquées. Cette séparation permet d’arbitrer entre confidentialité, performances et diversité des capacités disponibles. Elle suppose toutefois que les projets soient correctement classés et que les développeurs sachent quel modèle traite chaque demande.
Le choix limité en local peut également influencer la qualité des résultats. Les modèles ne se distinguent pas seulement par leur réputation : ils varient selon la taille des contextes qu’ils peuvent traiter, leur aptitude à comprendre des bases de code anciennes et leur comportement face aux langages spécialisés. Une entreprise doit donc tester les modèles sur ses propres dépôts et ses cas d’usage, plutôt que de se fier uniquement à des comparaisons générales.
IBM annonce vouloir élargir les modèles compatibles et ajouter un aiguillage automatique vers celui qui conviendrait à chaque tâche. Sans calendrier ferme indiqué, cette perspective ne peut pas être considérée comme une capacité déjà disponible. Pour le moment, la liberté promise par la plateforme reste encadrée par un catalogue et des conditions techniques qui ne sont pas identiques entre le local et l’hybride.
Le point à retenir est concret : la souveraineté ne dépend pas de l’étiquette apposée sur Bob, mais du modèle effectivement branché et de l’endroit où celui-ci traite les informations.
Développement logiciel avec Bob : moderniser le code sans automatiser à l’aveugle
IBM positionne Bob comme un agent capable d’accompagner plusieurs étapes du développement logiciel. Il peut examiner une application existante, décomposer une demande en tâches, proposer des changements et vérifier certains résultats. Ce fonctionnement est particulièrement pertinent pour la maintenance de systèmes anciens, où les équipes doivent souvent comprendre des dépendances établies sur plusieurs années avant de toucher au code.
Imaginons une société d’assurance qui souhaite faire évoluer un service Java utilisé pour calculer des contrats. Avant toute modification, Bob peut être chargé d’identifier les modules concernés et de décrire leurs relations. Les développeurs peuvent ensuite comparer ce diagnostic à la documentation, préparer des tests et demander une proposition de changement limitée à un composant précis. L’agent accélère alors l’exploration, sans remplacer la connaissance métier des spécialistes.
IBM propose également des packs Premium optionnels, sous licence, orientés vers des environnements de modernisation particuliers. L’un vise les applications Java ; d’autres concernent IBM i, héritier des systèmes AS/400, et les mainframes IBM Z. Ces plateformes restent importantes dans des banques, des assurances et de grandes organisations, où une migration complète peut présenter un risque opérationnel supérieur à celui d’une modernisation progressive.
Une méthode de travail qui garde une validation humaine
Une mise en œuvre prudente peut commencer par une tâche d’analyse en lecture seule. Bob cartographie un dépôt et relève les fichiers concernés ; un développeur vérifie la pertinence de ses observations. Dans un second temps, l’équipe peut autoriser la génération de modifications sur une branche isolée, puis comparer les changements aux tests et aux exigences métier.
Cette progression répond à une difficulté souvent sous-estimée : une modification qui compile n’est pas nécessairement correcte. Un agent peut proposer un changement cohérent sur le plan syntaxique tout en ignorant une règle métier implicite, une contrainte de performance ou une interaction avec un système externe. Les revues humaines et les tests automatisés restent donc indispensables, notamment pour les applications critiques.
Bob peut aussi répartir certaines tâches entre plusieurs sous-agents ou outils. Par exemple, un processus peut analyser la structure d’un programme pendant qu’un autre examine les tests disponibles. Cette parallélisation peut réduire le temps d’investigation, mais elle ne garantit pas que les résultats convergent : les développeurs doivent contrôler les hypothèses et arbitrer les propositions contradictoires.
Pour une équipe qui maintient un système IBM Z, la valeur ne se mesure pas uniquement au nombre de lignes produites. Elle peut résider dans la capacité à rendre un code ancien plus compréhensible, à repérer des zones de dépendance ou à préparer une migration par étapes. L’intérêt est alors de diminuer le coût d’exploration, sans confier à l’agent la décision finale sur l’architecture.
- Commencer par l’analyse : demander une cartographie et une explication du code avant d’autoriser des changements.
- Isoler les modifications : faire produire les propositions dans une branche dédiée afin de faciliter la comparaison et le retour arrière.
- Valider les résultats : confronter le code aux tests, aux exigences de sécurité et aux règles métier connues.
- Limiter les accès : accorder à Bob uniquement les permissions nécessaires au projet concerné.
Dans ce cadre, l’agent devient un accélérateur d’investigation et de maintenance, non un substitut à l’expertise. La qualité du processus dépend de la discipline appliquée autour de chaque modification autant que des capacités du modèle.
Coûts, matériel et gouvernance : les conditions d’adoption de Bob en local
Une installation locale peut répondre à des contraintes de confidentialité, mais elle implique des dépenses que l’usage d’un service distant rend moins visibles. IBM n’a pas communiqué publiquement les tarifs de l’offre dans les informations fournies, ni les caractéristiques matérielles requises pour exécuter chaque modèle en interne. Les entreprises doivent donc établir leur budget en considérant la licence, les serveurs, le stockage, l’administration et la maintenance.
Le matériel est particulièrement important pour les modèles qui réclament une capacité de calcul élevée. Une organisation déjà équipée pour héberger des charges d’intelligence artificielle pourra réutiliser une partie de son infrastructure. Une autre devra comparer le coût d’investissement à celui d’un accès hybride, en intégrant les exigences contractuelles et les conséquences d’un transfert de code hors de son environnement.
Le calcul économique ne se réduit pas au prix par requête. Il doit intégrer le volume d’utilisation, les périodes de pointe, le temps consacré à l’exploitation et le coût des contrôles de sécurité. Un modèle local peut donner davantage de maîtrise, mais exiger une équipe capable de le déployer, de suivre ses performances et de planifier les mises à jour. Le mode hybride, lui, peut accélérer l’accès à certains modèles tout en créant une dépendance envers les conditions du fournisseur.
Évaluer les usages avant de généraliser
Une organisation peut commencer par un projet pilote limité à un dépôt non critique. Elle mesure alors le temps nécessaire pour comprendre le code, la qualité des suggestions, le nombre de corrections manuelles et les ressources consommées. Cette expérimentation fournit des repères plus utiles qu’une promesse générale de gain de productivité, car les résultats dépendent fortement du langage, de l’état de la documentation et de la qualité des tests.
Il faut également prévoir des règles de gouvernance compréhensibles par les développeurs. Chaque projet devrait indiquer les modèles autorisés, les données transmissibles, les permissions accordées à l’agent et les validations obligatoires. Si une équipe ignore qu’une tâche passe par un modèle distant, la politique de souveraineté reste théorique, même lorsque l’interface de Bob est hébergée en interne.
IBM évoque une progression des déploiements hybrides et en périphérie, proches des données, qui pourraient représenter 44 % du marché des infrastructures d’IA en 2030, contre 46 % pour le cloud public selon les perspectives citées. Il s’agit d’une projection de marché, non d’une mesure des usages actuels ni d’une garantie sur l’évolution de chaque entreprise. Elle illustre néanmoins l’intérêt croissant pour des architectures répartissant les traitements entre plusieurs lieux.
La promesse de Bob repose précisément sur cette flexibilité : conserver certains traitements dans l’entreprise, tout en permettant des usages hybrides lorsque les règles le permettent. Pour en tirer parti, les décideurs doivent comparer les capacités disponibles aujourd’hui, et non fonder leur stratégie sur l’arrivée annoncée de futurs modèles ou d’un aiguillage automatique qui n’est pas encore assorti d’un calendrier ferme.
La décision d’adopter Bob en local se joue donc sur trois vérifications : la sensibilité des projets, la disponibilité réelle des modèles auto-hébergés et le coût complet de l’exploitation. Lorsque ces paramètres sont établis, le déploiement local cesse d’être un argument de communication et devient un choix d’architecture mesurable.
