À VivaTech, IBM a fait de Bob plus qu’une démonstration d’agent IA appliqué au développement. En présentant un outil capable d’accompagner tout le cycle logiciel, de la planification au déploiement en passant par les tests, la modernisation et la sécurité, le groupe pose une question devenue centrale pour les DSI, CTO et développeurs : comment passer d’une IA qui aide à coder plus vite à une IA qui transforme, sans le fragiliser, tout le processus de production applicative ?
Jusqu’ici, l’IA appliquée au développement logiciel a surtout été racontée comme une histoire de productivité individuelle. Un développeur demande une fonction, l’assistant propose du code. Un métier décrit une idée, l’outil génère une maquette. Un consultant prépare une démonstration en quelques heures au lieu de plusieurs jours. L’effet est spectaculaire, parfois bluffant, et il explique l’enthousiasme autour de GitHub Copilot, Cursor, Claude Code ou Codex.
Mais dans une entreprise, le logiciel ne se résume pas à produire du code. Il faut comprendre l’existant, documenter, tester, sécuriser, intégrer, déployer, maintenir. Il faut aussi composer avec du legacy, des architectures hybrides, des applications critiques, des contraintes réglementaires et des budgets qui, avec l’IA générative, peuvent vite devenir difficiles à prévoir.
IBM avait déjà présenté Bob comme un agent IA de développement pensé pour accompagner l’ensemble du cycle logiciel, de la planification au déploiement, en passant par les tests, la modernisation applicative et la sécurité. Mais la séquence VivaTech permettait d’aller au-delà de la fiche produit : derrière Bob, IBM défend surtout une thèse plus large sur la manière dont l’IA agentique va transformer la fabrique logicielle des entreprises.
À VivaTech, Béatrice Kosowski, présidente d’IBM France, Alex Bauer, directeur général d’IBM Consulting France, et Bruno Aziza, vice-président data, analytics and AI chez IBM, ont défendu une même idée : l’IA agentique ne prendra vraiment sa place dans l’entreprise que si elle permet de produire mieux, pas seulement plus vite. Cela suppose de garder la main sur les coûts, la sécurité, les compétences et la mise en production.
Le « vibe coding » ne suffit pas à faire tourner une entreprise
Bruno Aziza résume le sujet avec une formule simple : « Construire du code pour du code, c’est bien, mais c’est aussi le déployer en production qui est important. » Derrière cette phrase se trouve l’une des grandes limites du moment. Le « vibe coding » donne l’impression qu’il suffit de décrire une application pour la voir apparaître. Pour un prototype, c’est souvent vrai. Pour un système d’entreprise, c’est beaucoup plus compliqué.
Un prototype peut tolérer l’imperfection. Une application de production, beaucoup moins. Elle doit fonctionner dans la durée, respecter des règles de sécurité, être comprise par les équipes, être testée, s’intégrer au SI, être maintenable et parfois auditable. L’IA peut accélérer certaines étapes, mais elle ne supprime pas ces exigences. Elle les rend même plus importantes, car elle permet de produire plus vite et donc, potentiellement, de produire plus vite des erreurs.
C’est ici que Bob veut se distinguer des assistants de code classiques. IBM ne le présente pas seulement comme un outil capable de générer une fonction ou de compléter une ligne. Bob doit intervenir sur plusieurs moments de la chaîne logicielle : analyse de l’existant, création de spécifications, génération de code, production de tests, modernisation applicative, détection de vulnérabilités et préparation du déploiement.
Pour un développeur, cela signifie que l’IA peut devenir un partenaire de travail plus complet. Pour un CTO, cela pose la question de l’architecture et de l’intégration de ces agents dans les processus existants. Pour un DSI, l’enjeu est encore plus large : comment industrialiser ces usages sans créer une nouvelle zone de désordre dans le SI ?
L’agentique avance, mais le passage à l’échelle reste difficile
Alex Bauer apporte ici des chiffres utiles. Selon les observations partagées par IBM, 64 % des CIO déclareraient déjà utiliser des apports de l’IA agentique pour nourrir des décisions stratégiques. Dans les deux ans, la part de l’IA agentique dans les budgets IT devrait plus que doubler. Et trois dirigeants sur quatre considéreraient, à horizon 2030, que l’IA agentique deviendra un moteur majeur de croissance et de transformation.
L’appétit est donc réel. Mais Alex Bauer souligne aussi le décalage entre ambition et réalité : seuls 10 % des entreprises auraient aujourd’hui réellement intégré des agents dans leur cœur business. Le paradoxe est là. Les directions générales croient à l’IA agentique, les budgets progressent, les expérimentations se multiplient, mais peu d’entreprises ont vraiment franchi le cap de l’industrialisation.
La raison est assez simple. Tester un agent est facile. L’intégrer durablement dans une organisation l’est beaucoup moins. Il faut définir les bons cas d’usage, former les équipes, choisir les modèles, contrôler les coûts, documenter les décisions, vérifier la sécurité, adapter les méthodes de travail et mesurer la valeur créée.
Alex Bauer insiste sur un point de bon sens : la productivité n’est pas une finalité. Elle n’est qu’un moyen. Si le temps gagné par l’IA ne sert pas à créer de meilleurs produits, de nouveaux services, une meilleure relation client ou une meilleure qualité logicielle, il risque de se diluer dans l’organisation. Aller plus vite n’a d’intérêt que si l’on sait pourquoi.
Le coût devient un vrai sujet technique
Dans beaucoup de discussions sur l’IA, la question du coût arrive tard. Avec les agents, elle doit arriver beaucoup plus tôt. Un chatbot répond à une question. Un agent peut planifier, découper une tâche, interroger plusieurs modèles, générer du code, relire, corriger, tester, documenter, recommencer. Chaque étape peut consommer des tokens. À grande échelle, la facture peut devenir difficile à anticiper.
C’est l’un des sujets les plus concrets autour de Bob. Bruno Aziza explique qu’IBM a travaillé sur deux mécanismes pour réduire cette dérive. Le premier est le choix du bon modèle selon la tâche. Certaines opérations nécessitent un modèle très puissant. D’autres peuvent être confiées à un modèle moins coûteux. L’objectif est donc de ne pas utiliser systématiquement le modèle le plus cher pour toutes les actions.
Le second mécanisme est la condensation du contexte. Lorsqu’un agent travaille, il accumule de l’information. Or, plus le contexte grossit, plus la consommation augmente. IBM affirme donc travailler à réduire ce contexte pour éviter de payer inutilement pour des informations qui ne sont pas utiles à la tâche en cours.
IBM revendique jusqu’à 40 % d’économies de coûts grâce à cette optimisation. Béatrice Kosowski a cité un exemple issu d’un hackathon client, sans nommer l’entreprise : dans une comparaison avec d’autres technologies de développement logiciel, Bob aurait coûté quelques centaines d’euros ou de dollars, contre environ 1 600 dollars avec Claude pour des équipes en concurrence. Ce n’est pas une règle générale, mais cela illustre bien le sujet.
Pour les CTO et DSI, la conclusion est directe : demain, il ne suffira pas de choisir l’agent qui produit le meilleur résultat. Il faudra aussi choisir celui dont le modèle économique reste maîtrisable. L’IA agentique fait entrer le développement logiciel dans une nouvelle forme de FinOps.
La sécurité doit être intégrée dès le départ
L’autre point majeur concerne la sécurité. Plus l’IA produit vite, plus le risque de faire entrer en production du code insuffisamment contrôlé augmente. Bruno Aziza avertit : si le développeur est sorti de la boucle, l’usage agentique peut devenir dangereux.
Ce point est essentiel. L’IA peut générer du code qui fonctionne en apparence, mais qui introduit une dépendance fragile, une vulnérabilité, un problème de droits, une mauvaise gestion des données ou une logique difficile à maintenir. Le danger ne vient pas seulement de l’erreur visible. Il vient aussi de l’erreur invisible.
IBM affirme donc vouloir intégrer la sécurité dès la création du code, et non en bout de chaîne. C’est une évolution importante pour les équipes de développement. Dans beaucoup d’organisations, la sécurité est encore vécue comme un contrôle final, parfois comme un frein. Avec l’IA agentique, elle doit devenir une partie du processus de génération et de validation.
Le rôle du développeur évolue alors. Il ne disparaît pas. Il devient celui qui garde la main, vérifie, arbitre, comprend les propositions de l’agent et valide ce qui peut réellement passer en production. L’IA ne réduit pas nécessairement le besoin de compétence. Elle déplace la compétence vers la revue, l’architecture, la qualité, la sécurité et la compréhension du système.
Former les équipes autrement
Cette transformation pose évidemment la question des compétences. Alex Bauer estime que, dans les deux ans, environ 50 % des métiers devront être renforcés en compétences pour tirer parti de l’IA. Il ajoute qu’un tiers des métiers devront être recomposés. La question n’est donc pas seulement de former quelques développeurs à un nouvel outil. Elle touche plus largement les métiers, les consultants, les architectes, les chefs de projet, les équipes sécurité et les directions IT.
Chez IBM Consulting France, Alex Bauer explique que la formation ne peut pas être seulement théorique. Les collaborateurs sont placés dans des dispositifs pratiques, de type « garages », où ils travaillent sur des cas réels avec des outils IA. L’objectif est de faire pratiquer, pas seulement d’expliquer.
Le chiffre avancé est significatif : 80 % des collaborateurs d’IBM Consulting France utiliseraient déjà les plateformes IA internes. Au niveau mondial, IBM évoque 80 000 utilisateurs de Bob. Bruno Aziza précise que ces utilisateurs ne sont pas uniquement des développeurs, mais aussi des profils finance et des « power users ». IBM affirme également que 40 % de Bob aurait été construit avec Bob, et revendique 45 % de gain de productivité sur son propre processus de développement logiciel.
Ces chiffres servent évidemment la communication d’IBM. Mais ils montrent une chose : l’entreprise veut faire de Bob la preuve de sa propre transformation. Elle ne présente pas seulement un outil à ses clients. Elle raconte aussi comment elle l’utilise pour modifier ses propres méthodes de travail.
Béatrice Kosowski évoque également le « What’s Next Challenge », un hackathon interne mondial ouvert aux collaborateurs d’IBM. Les équipes y proposent des cas d’usage destinés à améliorer leur quotidien, puis certains projets peuvent être industrialisés. Cette logique est importante : l’adoption de l’IA ne se décrète pas uniquement depuis le haut. Elle se construit par l’usage, par les cas concrets et par la mise en production des idées utiles.
L’IA transforme aussi le rapport au travail
La question sociale est revenue dans l’échange avec Béatrice Kosowski, à propos du plan de départ volontaire annoncé puis annulé chez IBM France. La présidente d’IBM France insiste d’abord sur le terme : il s’agissait, selon elle, d’un plan de départ volontaire, non d’un plan social. Elle rappelle que ce type de dispositif ne force personne et peut répondre à des choix individuels de collaborateurs.
IBM France a finalement décidé de l’annuler. Béatrice Kosowski explique cette décision par un environnement très changeant et par la nécessité de réévaluer les besoins en compétences, les métiers et les modélisations. Autrement dit, même une entreprise avancée dans l’usage de l’IA doit encore ajuster sa lecture des impacts.
La dirigeante replace ensuite le sujet dans la doctrine d’IBM : l’IA doit augmenter l’humain. Les tâches simples, répétitives ou encadrables peuvent être automatisées. Les activités plus complexes, à plus forte valeur ajoutée, doivent être renforcées par l’IA. Elle rappelle aussi l’analyse formulée depuis plusieurs années par Arvind Krishna : sur près de 300 000 collaborateurs dans le monde, environ 10 % travaillent dans les fonctions support, et 30 % de leurs tâches pourraient être automatisables à trois, quatre ou cinq ans.
La conséquence n’est pas, selon IBM, de cesser de recruter, mais de recruter différemment. L’entreprise continuera à embaucher, mais pas nécessairement de façon massive dans les fonctions dont une part importante des tâches peut être automatisée.
Pour les DSI et CTO, c’est un point clé. L’impact de l’IA sur le travail ne se résume pas à une question de suppression de postes. Il porte sur les tâches, les compétences, les trajectoires professionnelles et les rythmes de transformation. Certaines activités seront automatisées. D’autres deviendront plus importantes. De nouveaux rôles apparaîtront autour de l’orchestration des agents, de la validation, de la gouvernance et de la sécurité.
Du slide au prototype : une autre relation avec les métiers
Alex Bauer insiste aussi sur un effet plus immédiat de Bob : la capacité à passer plus vite d’une idée à une démonstration. Les dirigeants et consultants d’IBM l’utilisent pour maquetter, prototyper et montrer concrètement ce qu’un projet pourrait donner. Il donne l’exemple d’un client travaillant sur la refonte d’un site web : à partir des informations disponibles, Bob a permis de présenter une version concrète du futur site.
Ce changement est important. Dans la relation entre DSI, métiers et prestataires, les slides ont longtemps servi à expliquer une cible. L’IA permet désormais de montrer plus vite une première version. Cela peut accélérer la compréhension et les décisions. Cela peut aussi créer une confusion : un prototype rapide n’est pas une application prête pour la production.
C’est l’un des nouveaux défis. L’IA raccourcit le temps entre l’idée et la démonstration. Mais elle ne supprime pas le temps nécessaire pour sécuriser, tester, intégrer et maintenir. Les métiers verront plus vite ce qu’ils pourraient obtenir. Les équipes IT devront expliquer encore plus clairement ce qui sépare une maquette séduisante d’un service robuste.
Ce que Bob dit aux DSI, CTO et développeurs
Bob est donc plus qu’un outil de code. Il symbolise l’arrivée de l’IA agentique dans la fabrique logicielle. Pour les développeurs, il annonce une évolution du métier vers davantage de validation, de contrôle et de compréhension système. Pour les CTO, il pose la question de l’architecture des outils d’IA, du choix des modèles et de leur intégration dans les chaînes existantes. Pour les DSI, il oblige à regarder l’ensemble : valeur, coûts, sécurité, compétences, gouvernance et responsabilité.
La première vague de l’IA générative a montré que l’on pouvait produire plus vite. La vague agentique pose une question plus difficile : comment produire plus vite sans perdre la maîtrise ?
C’est là que Bob trouve son intérêt. Non parce qu’il serait un agent de plus dans un marché déjà très actif, mais parce qu’il oblige à poser les bonnes questions. Quels agents autoriser ? Pour quelles tâches ? Avec quels modèles ? À quel coût ? Avec quelle validation humaine ? Sur quels environnements ? Avec quels contrôles de sécurité ? Et comment mesurer la valeur autrement qu’en lignes de code ou en heures gagnées ?
L’IA ne rendra pas le développement logiciel magique. Elle peut le rendre plus rapide, plus assisté, parfois plus fiable. Mais seulement si l’entreprise accepte de traiter le sujet comme une transformation de sa chaîne de production, et non comme un simple achat d’outil.
Le « vibe coding » a ouvert l’imaginaire. La production logicielle, elle, réclame toujours de la méthode.
Le chandelier quantique d’IBM, ou pourquoi il ne faut pas attendre un « PC quantique »
Exposé à VivaTech, le « chandelier » quantique d’IBM illustre la réalité matérielle de l’ordinateur quantique : une architecture cryogénique complexe, conçue pour maintenir les qubits à des températures proches du zéro absolu. IBM insiste toutefois sur un point : il ne faut pas imaginer demain un « PC quantique » sur chaque bureau. Comme le GPU est devenu une ressource spécialisée dans la chaîne de calcul, le quantique devrait s’intégrer progressivement aux plateformes et bibliothèques logicielles pour traiter certains problèmes d’optimisation, de simulation ou de modélisation.
Interrogé à VivaTech sur la perspective d’un ordinateur personnel quantique, Jerry Chow, CTO of Quantum-Centric Supercomputing chez IBM a d’ailleurs récusé cette image. Le quantique ne remplacera ni le CPU ni le GPU. Il viendra plutôt s’ajouter à la chaîne de calcul, comme une capacité spécialisée, appelée seulement lorsque certains types de problèmes le justifient. L’enjeu n’est donc pas de placer une machine quantique dans chaque entreprise, mais d’abstraire progressivement sa complexité dans des bibliothèques et des plateformes utilisables par les développeurs, comme c’est déjà le cas avec les GPU.
À VivaTech, IBM mettait notamment en avant ses travaux avec des industriels européens, comme l’énergéticien allemand E.ON, afin d’explorer les futurs usages de cette puissance de calcul dans l’énergie et les systèmes complexes. Le message rejoint, par un autre chemin, celui porté autour de Bob : l’innovation ne devient utile pour l’entreprise que lorsqu’elle s’intègre dans une chaîne de production maîtrisée.
____________________________
puis