Le routage entre modèles selon le coût : cinq approches

IBM lance Bob pour sécuriser le codage IA en production, via routage multi-modèles et contrôles humains

IBM a lancé hier à l'échelle mondiale Bob, sa plateforme de développement logiciel propulsée par l'intelligence artificielle. L'outil, conçu pour écrire, tester et gérer du code tout au long du cycle de développement, est déjà utilisé par plus de 80 000 employés d'IBM après avoir démarré avec seulement 100 utilisateurs internes à l'été 2025. Bob repose sur un routage multi-modèles : il peut s'appuyer sur les modèles Granite d'IBM, les modèles Claude d'Anthropic, ou encore ceux de la société française Mistral, ainsi que sur des modèles distillés plus légers. Les modèles open source comme Qwen d'Alibaba sont explicitement exclus. Selon IBM, certaines équipes ont économisé jusqu'à 70 % du temps sur certaines tâches, soit en moyenne dix heures par semaine. Neal Sundaresan, directeur général de l'automatisation et de l'IA chez IBM, résume la philosophie de la plateforme : « La capacité du modèle seule ne suffit pas. La façon dont vous le déployez, dont vous structurez le contexte, et dont vous maintenez les humains dans la boucle détermine si l'IA tient réellement ses promesses. » Ce qui distingue Bob de concurrents comme Cursor ou Claude Code, c'est le niveau de contrôle et de gouvernance qu'il impose sur les workflows agentiques. Là où d'autres outils placent le développeur au début de la tâche pour qu'il enchaîne les étapes manuellement, Bob introduit des points de contrôle humains structurés à intervalles réguliers, tout en permettant à des agents IA d'accomplir des tâches complexes en plusieurs étapes. Cette approche répond directement aux besoins des grandes entreprises, qui craignent les failles de sécurité et les défaillances d'orchestration lorsque des agents autonomes accèdent à des données en production. Pour les directions techniques et les équipes d'audit, la traçabilité et la capacité à intervenir à tout moment priment sur la vitesse. Cette annonce s'inscrit dans une tension croissante dans l'industrie entre deux visions de l'IA agentique. D'un côté, des systèmes ouverts et autonomes comme OpenClaw ou NemoClaw de Nvidia, qui poussent les limites de l'automatisation dans des environnements bac à sable. De l'autre, des plateformes comme Bob qui privilégient la fiabilité, l'auditabilité et la supervision humaine. OpenAI a récemment ajouté dans son Agents SDK un support pour des implémentations en bac à sable, tandis que Kilo lançait Kilo Claw centré sur la sécurité des agents autonomes. IBM, fort de ses décennies d'expérience dans les systèmes d'entreprise critiques, choisit délibérément la prudence. Sundaresan le dit sans détour : « Il vaut mieux ouvrir la grille lentement que de dire, 'oups, comment je la referme maintenant ?' »

Omio accélère son développement produit voyage avec les modèles OpenAI

Omio, plateforme de voyage multimodale opérant avec plus de 3 000 transporteurs dans 47 pays, a intégré les modèles OpenAI à l'ensemble de ses opérations d'ingénierie pour accélérer radicalement le développement de ses produits. L'entreprise a d'abord déployé ChatGPT en accès libre à tous ses employés, avant d'embarquer OpenAI Codex directement dans le cycle de développement logiciel, de la recherche préliminaire à la maintenance système, en passant par la conception architecturale, le codage, les tests automatisés et la revue de code. Des connecteurs internes sur mesure relient les environnements de données propriétaires à ces outils, permettant aux développeurs de sauter l'étape de recherche d'information pour passer directement à l'exécution. En 2023, Omio a aussi lancé l'une des premières interfaces de réservation conversationnelle du secteur, en connectant les modèles OpenAI à son inventaire de transport en temps réel, trains, bus, ferries, vols, permettant aux utilisateurs de formuler des requêtes en langage naturel comme "le trajet le plus rapide de Rome à Florence" et d'obtenir des itinéraires directement réservables. L'impact sur la productivité est saisissant : selon les analyses internes d'Omio, l'effort technique nécessaire pour construire un produit donné ne représente plus que 20 % de ce qu'il était auparavant. Des projets qui mobilisaient plusieurs développeurs pendant un trimestre entier se réalisent désormais avec un seul ingénieur en un mois environ. Cette compression des délais transforme la façon dont l'entreprise alloue ses ressources : il est désormais possible de prototyper rapidement, de tester la demande réelle des utilisateurs à moindre coût, et d'éliminer les fonctionnalités non viables avant d'engager une production à pleine échelle. Les équipes techniques itèrent sur les produits existants à une cadence bien plus élevée, déployant mises à jour et nouvelles interfaces en production à un rythme accéléré. La démarche d'Omio illustre une ambition plus radicale que la simple adoption d'outils IA. Son directeur technique, Tomas Vocetka, impose à chaque fonction interne de repenser entièrement ses modes opératoires pour fonctionner comme une entreprise nativement IA, et non de se contenter d'ajouter une couche technologique à des processus existants inchangés. Cette philosophie s'étend désormais au-delà des équipes techniques : la direction déploie Codex dans les fonctions non-techniques de l'organisation. Dans un secteur du voyage historiquement fragmenté, où les utilisateurs devaient naviguer entre de multiples sites pour comparer modes de transport et assembler manuellement leurs itinéraires, l'intégration conversationnelle d'Omio positionne la plateforme comme un guichet unique capable d'interpréter l'intention du voyageur et de répondre avec des options ancrées dans les prix et disponibilités en temps réel.

Amazon Bedrock : comprendre le cycle de vie des modèles

Amazon Web Services a formalisé le cycle de vie des modèles de fondation (FM) disponibles sur sa plateforme Bedrock, en introduisant un cadre structuré en trois états distincts : Actif, Hérité (Legacy) et Fin de vie (EOL). Ce système vise à donner aux entreprises une visibilité suffisante pour planifier leurs migrations sans interruption de service. Concrètement, un modèle reste disponible au minimum 12 mois après son lancement, puis passe en état Legacy avec un préavis d'au moins 6 mois avant sa date de fin de vie. AWS a également introduit une nouvelle phase intermédiaire appelée "extended access" pour les modèles dont la fin de vie est postérieure au 1er février 2026 : après 3 mois en état Legacy, le modèle entre dans cette période d'accès étendu pendant laquelle les utilisateurs actifs peuvent continuer à l'utiliser au moins 3 mois supplémentaires. Durant cette fenêtre, les demandes d'augmentation de quota ne seront plus approuvées et les tarifs peuvent être ajustés par le fournisseur du modèle, avec notification préalable. Cet encadrement change concrètement la manière dont les équipes techniques doivent gérer leurs applications IA en production. Jusqu'ici, une fin de vie pouvait surprendre des équipes insuffisamment préparées, entraînant des pannes ou des migrations précipitées. Avec ce calendrier prévisible, les développeurs peuvent anticiper les transitions, tester les modèles de remplacement via la console Bedrock ou l'API, et adapter leur code sans urgence. L'état d'un modèle est désormais exposé directement dans les réponses API via le champ modelLifecycle, accessible lors d'appels GetFoundationModel ou ListFoundationModels. Il faut toutefois noter que les comptes inactifs en phase Legacy, c'est-à-dire n'ayant pas appelé le modèle pendant 15 jours ou plus, peuvent perdre l'accès prématurément. La migration vers un nouveau modèle reste une action manuelle : rien ne se fait automatiquement lorsqu'un modèle atteint sa date EOL. Cette politique s'inscrit dans un contexte où Amazon Bedrock multiplie les modèles disponibles, provenant de fournisseurs comme Anthropic, Meta, Mistral ou Cohere, chacun avec ses propres cycles de mise à jour. À mesure que ces modèles évoluent rapidement, l'accumulation de versions obsolètes pose des problèmes de maintenance et de sécurité pour AWS comme pour ses clients. En clarifiant les règles du jeu, AWS cherche à professionnaliser la gestion du cycle de vie des IA en entreprise, sur le modèle de ce que font déjà les plateformes cloud pour leurs APIs et services logiciels. La prochaine étape pour les équipes utilisant Bedrock sera d'intégrer ces états dans leurs processus de surveillance et d'alerte, afin de ne jamais être pris de court lors d'une transition de modèle.

IEEE lance un cours de formation en ligne sur les grands modèles de langage

L'IEEE, l'organisation internationale des ingénieurs en électronique et en informatique, lance un programme de formation en ligne intitulé "Large Language Models Demystified", disponible sur son réseau d'apprentissage IEEE Learning Network. Développé en partenariat avec l'IEEE Computer Society, ce cursus de cinq cours s'adresse aux professionnels techniques qui souhaitent comprendre non seulement comment utiliser les modèles de langage, mais comment les concevoir et les intégrer dans des systèmes réels. Le programme couvre l'évolution des architectures transformer, les mécanismes d'attention, l'optimisation des modèles et des exercices pratiques. Ce lancement intervient alors que le marché des LLM est estimé à une croissance annuelle de 33 % jusqu'en 2030, selon le cabinet MarketsandMarkets, ce qui signifie que la maîtrise de ces technologies passe rapidement d'une compétence de niche à une exigence fondamentale pour tout professionnel du numérique. L'enjeu dépasse largement l'usage grand public des assistants conversationnels. Pour les ingénieurs et développeurs, les LLM sont devenus des composants architecturaux à part entière : ils identifient des vulnérabilités dans du code source, transforment des discussions de projet en spécifications techniques formalisées, et automatisent des tâches répétitives qui mobilisaient auparavant des heures de travail humain. Mais utiliser ces systèmes sans en comprendre la logique interne génère des risques concrets. Le phénomène des "hallucinations", où un modèle produit du code ou des faits d'apparence correcte mais fondamentalement erronés, représente un risque de fiabilité majeur en production. Des techniques comme la génération augmentée par récupération (RAG), qui force le modèle à consulter une base de données vérifiée avant de répondre, ou le déploiement d'instances privées pour protéger le code propriétaire des données d'entraînement publiques, sont désormais des compétences attendues des équipes techniques. Ce mouvement s'inscrit dans une transformation plus profonde de la profession d'ingénieur logiciel. L'architecture transformer, qui a remplacé le traitement séquentiel des données par des mécanismes d'attention parallèle capables d'ingérer des corpus massifs simultanément, a rendu possible une nouvelle génération d'outils de développement. Les API permettent aujourd'hui de connecter directement un LLM à des bases de données internes ou à des environnements d'exécution de code, dépassant largement la simple interface de chat. Face à cette mutation rapide, l'écart se creuse entre ceux qui utilisent l'IA comme un outil opaque et ceux qui savent en contrôler les paramètres, en sécuriser les accès et en garantir la cohérence des résultats. La formation proposée par l'IEEE vise précisément à combler ce fossé, en offrant aux professionnels une compréhension de fond qui transforme l'expérimentation en approche d'ingénierie rigoureuse.

💬 Honnêtement, c'est plus intéressant que ça en a l'air. L'IEEE sort le grand jeu avec ce programme de formation sur les grands modèles de langage, "Large Language Models Demystified". On parle pas juste d'utiliser ces outils, mais aussi de les concevoir et de les intégrer vraiment. C'est crucial, avec le marché des LLM qui grimpe à 33% par an jusqu'en 2030, on passe d'une compétence de spécialiste à une nécessité pour tout pro du numérique. Mais attention, utiliser ces modèles sans les comprendre crée des risques concrets : ces "hallucinations", c'est fondamentalement faux mais qui peut sembler correct. Techniques comme le RAG ou le déploiement d'instances privées, c'est devenu indispensable pour sécuriser le code et les données. L'IEEE met le doigt sur un vrai besoin : transformer l'expérimentation en ingénierie rigoureuse avec ces outils de plus en plus centraux dans notre boulot d'ingés logiciels.