IBM Bob auto-hébergé : l’IA de développement entre dans le périmètre souverain
IBM a annoncé une option de déploiement auto-hébergé pour IBM Bob, sa plateforme de développement logiciel agentique. Elle permet d’exécuter des fonctions de développement et de modernisation dans des environnements sur site, de cloud privé, de cloud souverain ou isolés. Le signal est important pour les organisations qui ne peuvent pas faire sortir leur code, leurs données ou leurs workflows sensibles ; il ne transforme toutefois pas, à lui seul, un assistant de code en système souverain.
1. L’IA se rapproche du code plutôt que l’inverse
Selon IBM, Bob peut s’exécuter dans les environnements contrôlés par le client, avec des modèles compatibles auto-hébergés ou, dans une configuration hybride, connectés à des services externes. L’annonce vise les équipes qui gèrent du code propriétaire, des données réglementées ou des infrastructures critiques et doivent encadrer résidence des données, politiques de sécurité et gouvernance IA.
Cette option réduit une exposition évidente : déplacer le contexte applicatif et le code source vers un outil public. Mais elle ne documente pas, pour une mise en œuvre donnée, le modèle retenu, le plan de gestion, les services de télémétrie, les mises à jour ni les accès de support. Ces éléments restent déterminants pour qualifier le périmètre effectif de traitement.
2. L’auto-hébergement est une topologie, pas une preuve complète
Dans une chaîne de développement assistée par IA, le dépôt n’est qu’une partie des données sensibles. Les prompts peuvent contenir des secrets ou des incidents ; les index de code et embeddings, des éléments de propriété intellectuelle ; les journaux, des extraits de contexte et des identités. Il faut aussi examiner les images de conteneurs, dépendances, appels réseau, clés de licence et outils qui administrent la plateforme.
Une configuration « sur site » reste donc à vérifier avec la même rigueur qu’un service externe : où transitent les requêtes, qui peut lire les traces, quelles données sortent pour la qualité de service, et quelles mises à jour peuvent modifier les comportements. Lorsque des modèles externes sont connectés, l’architecture et le contrat doivent séparer explicitement ce qui demeure dans le périmètre contrôlé de ce qui le quitte.
3. Le contrôle opérationnel doit couvrir le cycle de livraison
Pour une entreprise belge ou française, la question utile n’est pas seulement « où est installé l’outil ? », mais « qui peut exécuter quoi, avec quelles données et quelle traçabilité ? ». Un pilote devrait isoler un dépôt non critique, appliquer des identités distinctes pour lecture, génération et déploiement, et bloquer par défaut les écritures vers une branche de production, Odoo, un ERP ou une chaîne CI/CD.
Les recommandations générées doivent rester soumises aux revues de code, aux tests et aux règles de sécurité existantes. Les équipes doivent pouvoir exporter les journaux, reconstituer le contexte d’une suggestion, révoquer rapidement un connecteur ou un jeton, et redéployer une version connue. Ces preuves sont plus utiles qu’une simple affirmation de localisation.
4. Passer d’une promesse de souveraineté à une décision de production
Avant la production, l’organisation devrait demander l’inventaire des composants et flux, une matrice de responsabilités pour l’exploitation et le support, ainsi qu’un scénario de sortie. Elle devrait également tester la coupure d’un accès modèle externe, la rotation des secrets, la suppression des index, la restauration d’un environnement et le maintien des contrôles humains lors des changements de code.
Recommandation opérationnelle : traiter l’assistant de code comme une chaîne de traitement à haut privilège. Cartographier dépôt, contexte, modèle, identités, journaux, mises à jour, support et sortie ; n’autoriser les connexions vers Odoo, un ERP ou la CI/CD qu’après des tests documentés d’accès minimal, de révocation et de reprise.
Évaluer une IA de développement souveraine