IA en entreprise ·
IBM Bob disponible en déploiement autohébergé : le code reste-t-il vraiment sur place ?
IBM Bob est disponible en déploiement autohébergé sur OpenShift. Le point clé : si le backend reste sur le cluster, un modèle cloud, dans le compte de l’organisation, reçoit tout de même les requêtes et leur contexte de code.
Le 1er octobre 2026, IBM a présenté dans un communiqué le déploiement autohébergé d’IBM Bob. Le service peut tourner sur un cluster Red Hat OpenShift exploité par l’organisation, sur site ou dans son propre compte cloud. Selon le billet de version d’IBM Bob, ce déploiement est en disponibilité générale depuis le 24 septembre (communiqué IBM ; billet de version IBM Bob). L’accès passe par la vente : IBM invite à contacter un représentant ou un partenaire commercial pour obtenir une démonstration ou lancer une preuve de concept.
Deux configurations, deux parcours de données
Le déploiement comprend le backend, l’identité, la passerelle d’inférence, les journaux d’audit et le suivi d’utilisation. L’organisation peut le relier à un service de modèles cloud qu’elle utilise déjà, ou exécuter un modèle à poids ouverts sur ses propres GPU. IBM liste actuellement deux modèles pour cette dernière configuration : NVIDIA Nemotron 3 Ultra et Poolside Laguna S 2.1 (billet de version IBM Bob).
Dans la configuration hybride, les composants de Bob et ses journaux restent sur le cluster du client, mais les requêtes envoyées au modèle transportent le contexte de code. Ce contexte est transmis au service de modèle choisi, dans le compte cloud de l’organisation et selon les accords qu’elle a déjà conclus (billet de version IBM Bob). L’autohébergement du backend ne signifie donc pas que toutes les données restent dans le réseau interne.
En mode air-gapped, IBM indique que l’inférence s’appuie uniquement sur des services exécutés sur site. Les images du produit peuvent être transférées vers un registre interne. La documentation précise que la télémétrie est désactivée dans les installations air-gapped; elle est activée par défaut pour une installation connectée, mais peut être désactivée (documentation d’installation IBM).
Ce que les équipes doivent vérifier
Avant de choisir une configuration, les responsables techniques peuvent cartographier les éléments transmis à chaque modèle, examiner les règles de conservation et d’accès du fournisseur, puis vérifier séparément les journaux et la télémétrie. Il faut aussi chiffrer les exigences d’OpenShift, de capacité GPU et d’exploitation. Un essai sur un dépôt non critique peut aider à mesurer la qualité des changements, le temps de revue, les incidents et le coût d’usage.
Ce sont des points de contrôle à établir par l’équipe, pas des garanties apportées par le seul choix d’un déploiement autohébergé. Les capacités et modalités décrites ici proviennent des documents d’IBM; ceux-ci ne présentent pas de comparaison indépendante des résultats ni de gains mesurés pour les entreprises. La valeur du dispositif dépendra du modèle, des permissions de l’agent et des contrôles appliqués au dépôt.