IBM Bob passe derrière le pare-feu, et c’est tout l’intérêt

IBM a commencé à proposer sa plateforme agentique de développement logiciel, IBM Bob, en version auto-hébergée. Les déploiements sur site, en cloud privé, en cloud souverain et en environnement isolé (air-gapped) sont tous au menu. Les clients choisissent leur propre configuration de modèle, gardent le code source et le contexte applicatif à l’intérieur de leur réseau, et conservent le contrôle de la résidence des données et de la politique de sécurité.

Cela ressemble à une note de bas de page sur le déploiement. C’est plutôt une thèse sur qui peut utiliser des agents de codage, tout court.

L’écart que l’auto-hébergement comble

Les agents de codage ont progressé vite. Ils lisent un dépôt, proposent des modifications, exécutent des tests et ouvrent des pull requests. Pour une start-up, en intégrer un à un service cloud est l’affaire d’un après-midi. Pour une entreprise de défense, une banque ou un système hospitalier, la même manœuvre échoue dès la première revue juridique. Le code source ne peut pas quitter les murs. Le contexte interne, ce savoir institutionnel désordonné qui rend une base de code compréhensible, ne peut pas sortir non plus. Les environnements isolés n’ont aucune voie vers le cloud, par conception.

Cela laisse une large part de l’économie observer l’ère des agents derrière une vitre. IBM vend à cette part, et ce n’est pas le premier. La catégorie est petite aujourd’hui, surtout parce que les agents auto-hébergés ont besoin de poids de modèles, de matériel et d’une couche d’orchestration qu’un fournisseur cloud fournirait normalement. L’entreprise qui résout la plomberie obtient une base de clients que les laboratoires « API-first » ne peuvent pas atteindre.

Pourquoi c’est plus difficile qu’il n’y paraît

Un agent est plus facile à comprendre comme une boucle que comme une chose unique : planifier, agir, observer, ajuster. Dans le cloud, les outils qu’il appelle sont des services, et les modes de défaillance sont le problème de quelqu’un d’autre. Derrière un pare-feu, l’agent doit atteindre les mêmes dépôts, les mêmes outils de suivi de tickets, les mêmes systèmes de build, sauf que désormais le réseau est segmenté, les identifiants sont renouvelés selon un calendrier, et la moitié des services ont été mis à jour pour la dernière fois avant que le mot « agent » ne veuille dire quoi que ce soit.

L’argumentaire d’IBM s’appuie sur le fait qu’elle vend déjà dans ces environnements. Ses clients exploitent des mainframes et des systèmes hérités que personne d’autre ne veut toucher. Faire fonctionner un agent là-dedans est peu glamour, lent, et exactement le genre de travail qui crée un fossé concurrentiel.

Il y a aussi un angle de gouvernance, et c’est celui qui revient sans cesse. Un agent auto-hébergé produit des journaux qui vous appartiennent. Lors d’un audit réglementaire, vous pouvez montrer exactement quel modèle a tourné, ce qu’il a lu et ce qu’il a modifié. Dans une configuration cloud, ces preuves sont réparties entre la console d’un fournisseur et un contrat de service. Quand quelque chose tourne mal, la différence entre « nous avons les journaux » et « nous avons demandé les journaux » est la différence entre un incident clos et un trimestre de production de preuves.

La question sous-jacente du modèle

Auto-héberger un agent signifie auto-héberger un modèle, ou du moins en choisir un que vous pouvez installer sur votre propre silicium. IBM laisse les clients sélectionner des configurations prises en charge, ce qui en pratique signifie un mélange de modèles à poids ouverts et de modèles IBM. Les options à poids ouverts comptent ici. Un modèle de classe 70B exécuté sur un cluster privé est plus lent et moins capable que le meilleur modèle hébergé. Il est aussi disponible quand le réseau est coupé, quand le fournisseur augmente ses prix, ou quand le fournisseur décide que votre cas d’usage enfreint une politique que vous n’avez jamais lue.

L’économie n’est pas la même derrière un pare-feu

Les agents de codage cloud sont facturés au token, ce qui signifie que le coût évolue avec la quantité de code que l’agent lit et écrit. Pour une start-up, c’est une ligne budgétaire prévisible. Pour une grande entreprise, où un seul dépôt peut contenir des décennies d’historique et où l’agent doit ingérer bien plus de contexte avant de pouvoir aider, le compteur s’emballe.

L’auto-hébergement inverse le modèle. Le coût devient matériel et exploitation, des dépenses d’investissement que l’organisation supporte déjà. Une banque disposant d’un centre de données ne paie pas plus quand l’agent lit un million de lignes de plus. Le coût marginal d’une tâche d’agent supplémentaire s’approche de l’électricité et du temps GPU, qui sont déjà engagés. C’est cette asymétrie qui fait mouche pour l’argument de l’auto-hébergement, même lorsque le produit cloud est objectivement meilleur.

Il y a toutefois un coût de conformité que le marketing oublie. L’auto-hébergement transfère au client la charge des correctifs, de la supervision et des mises à jour de modèles. Un fournisseur cloud pousse un correctif et c’est terminé. Un déploiement sur site doit planifier la mise à niveau, la tester contre les systèmes internes et survivre à un comité de contrôle des changements. L’outil est plus contrôlable et demande plus de travail, et ce compromis résume toute l’histoire du logiciel d’entreprise.

Le marché adjacent qui rend cela viable

Auto-héberger un agent ne fonctionne que s’il y a quelque chose qui vaut la peine d’être exécuté derrière le mur, et cette offre a grandi. Les modèles à poids ouverts de la gamme capable de faire du vrai travail de codage sont désormais courants, publiés sous des licences permissives par des laboratoires sur plusieurs continents. La pièce manquante n’a jamais été le modèle. C’était le harnais qui transforme un modèle en quelque chose auquel un développeur peut déléguer à l’intérieur d’un réseau contrôlé.

C’est la couche qu’IBM vend. Entraîner le meilleur modèle n’est pas le but. Être l’intégration qui rend un modèle existant utilisable là où un appel cloud n’est pas une option, voilà le but. La stratégie est l’image miroir des laboratoires « API-first ». Ils poussent la capacité vers l’extérieur et laissent quiconque se connecter. IBM tire la capacité vers l’intérieur et la fait survivre au périmètre.

Pour les acheteurs coincés dans ce périmètre, le choix est désagréable depuis deux ans : regarder la vague des agents de loin, ou enfreindre une règle de sécurité pour la rejoindre. Une option auto-hébergée ne rend pas la vague plus petite. Elle la rend simplement accessible, ce qui, pour une organisation réglementée, revient à la rendre réelle.

Ce qu’il faut surveiller

Les démos ne sont pas la vraie question à propos du codage agentique auto-hébergé. La vraie question est de savoir si les résultats tiennent sur une base de code avec quinze ans de dette technique, écrite par des personnes qui ont quitté l’entreprise. Les agents cloud y ont aussi du mal. La différence est qu’un agent auto-hébergé ne peut pas être amélioré du jour au lendemain par un fournisseur sans que le client fasse le travail. Chaque gain doit être gagné par l’équipe du client elle-même.

Cela rend l’adoption plus lente et plus fidélisante, ce qui convient à IBM. Elle construit pour des acheteurs qui mesurent le succès en années, pas en sprints, et qui préfèrent posséder un outil légèrement moins bon que louer un meilleur outil qu’ils ne peuvent pas inspecter. Pour un marché des agents de codage qui a passé deux ans à courir après les benchmarks, c’est un pari conservateur. C’est aussi un pari sur la partie du marché qui n’a pas encore été servie.

Il existe une version de cette histoire qui tourne mal. L’outillage auto-hébergé a la réputation d’être livré une fois puis de végéter, parce que le fournisseur n’a aucune incitation récurrente à l’améliorer et que le client n’a aucun pouvoir de négociation pour l’exiger. Si IBM Bob s’installe dans un produit stable qui ne s’améliore jamais vraiment, les acheteurs qu’il attire obtiendront exactement ce qu’ils ont demandé, et moins que ce qu’ils espéraient. L’alternative, où un agent auto-hébergé s’améliore selon un calendrier contrôlé par le client, est plus difficile à faire tourner et bien plus précieuse. Laquelle IBM livrera est ce qu’il faudra surveiller au cours de l’année à venir.