Pourquoi IBM s'est tourné vers les agents
Un client d'entreprise achète rarement un modèle pour de belles démos. Il veut que le logiciel fasse quelque chose : traiter des tickets, rapprocher des factures, appeler des API internes, rédiger des synthèses de documents. C'est précisément cette niche qu'occupe la logique agentique — quand le modèle ne se contente pas de répondre à une question, mais décide lui-même quel outil appeler ensuite.
Granite 4.2 dans cette histoire n'est pas « encore un grand modèle », mais une tentative d'IBM de compléter sa gamme pour qu'elle fonctionne avec la même assurance dans le cloud et dans un environnement fermé chez le client. Le pari repose sur trois éléments : des poids ouverts, des exigences matérielles modestes et un comportement prévisible lors de l'appel de fonctions externes.
Ce que représente la gamme Granite
IBM développe une famille de modèles ouverts sous le nom commun Granite depuis plusieurs années. Au fil du temps, une philosophie reconnaissable s'est dessinée : les modèles sont déclinés en plusieurs tailles, orientés avant tout vers le code, le travail avec des tableaux, l'extraction de données à partir de documents et les scénarios d'entreprise, plutôt que vers la compétition dans les benchmarks de chat généraux.
La taille compte
La gamme est construite comme un escalier — des variantes très compactes qui tiennent sur une seule carte graphique ou fonctionnent même sur un processeur, jusqu'aux modèles de milieu de gamme. L'idée est de pouvoir choisir la taille minimale suffisante pour chaque tâche. Pour un agent qui se contente surtout de router des requêtes et d'appeler des fonctions, un modèle géant est souvent superflu : il coûte plus cher en inference et répond plus lentement.
Architecture hybride
Dans la quatrième branche de la famille, IBM est passé à un schéma hybride, où une partie des couches repose sur Mamba et une autre sur l'attention classique des transformeurs. Le gain pratique est prosaïque : un contexte long est traité à moindre coût, la mémoire est consommée plus économiquement, et le débit sur le même matériel est plus élevé. Pour les scénarios agentiques, c'est crucial, car le contexte est constamment alimenté par les résultats des appels d'outils, des fragments de documents et l'historique des étapes.
Une licence sans surprises
Les modèles Granite sont distribués sous licence Apache 2.0. Pour un juriste d'entreprise, c'est une nouvelle ennuyeuse, et c'est justement une bonne nouvelle : on peut affiner, intégrer dans un produit commercial, déployer à l'intérieur du périmètre et ne pas rendre de comptes au fournisseur sur ce que le produit a rapporté.
L'argument principal : on peut le garder chez soi
Les API cloud sont pratiques exactement jusqu'au moment où les données tombent sous des restrictions réglementaires. Une banque, une clinique, une entreprise industrielle ou une administration ne peuvent souvent physiquement pas envoyer certains documents à l'extérieur. C'est là que commence la discussion sur le « matériel maison ».
Ce qu'il faut réellement pour démarrer
L'essentiel ici n'est pas d'avoir des accélérateurs haut de gamme, mais un minimum raisonnable. Les petites versions de Granite tournent sur une seule carte grand public, dans un conteneur sur un serveur sans GPU ou sur un ordinateur portable de développeur. Les tailles moyennes nécessitent déjà plusieurs cartes ou de la quantification. Le lancement se fait généralement via des outils standards comme vLLM ou Ollama, ce qui élimine le problème de la dépendance à une stack exclusive du fournisseur.
Sécurité et prévisibilité
Le deuxième volet de l'argument, c'est le contrôle. Quand le modèle vit dans votre périmètre, vous décidez vous-même quels logs écrire, quelles données entrent dans le prompt, ce qui est mis en cache et combien de temps il est conservé. Pour les agents, c'est particulièrement important : ils savent exécuter des actions, pas seulement générer du texte, et chacune de ces actions gagne à passer par vos propres règles et votre audit.
IBM vend ici non seulement le modèle, mais aussi l'enveloppe : la plateforme watsonx, un ensemble de modèles « gardiens » pour filtrer les contenus indésirables et des outils d'affinage sur vos propres données. Le modèle dans ce schéma est un détail, central certes.
À quoi ressemble un scénario agentique en pratique
L'idée de l'agent est simple : le modèle reçoit une tâche, détermine de quelles données il manque, appelle l'outil nécessaire, lit la réponse et continue jusqu'au résultat. La différence entre « un simple chat » et un agent, c'est la présence d'une boucle et de droits.
Les rôles typiques pour lesquels ces modèles sont taillés :
- Routeur. Analyse la demande entrante et décide à quel scénario la transmettre.
- Extracteur. Récupère les champs des factures, contrats, relevés et les range dans une structure.
- Exécutant. Appelle les API des systèmes internes : crée une demande, met à jour un statut, envoie un courriel.
- Réviseur. Vérifie le résultat de l'étape précédente et décide s'il peut être accepté.
Un petit modèle à chacune de ces étapes est souvent plus avantageux qu'un seul grand : moins cher, plus rapide, plus facile à tester et, ce qui n'est pas négligeable, plus simple à remplacer si la qualité ne satisfait plus.
Ce qu'il faut regarder et où sont les limites
Les modèles ouverts ne sont pas une pilule magique, et une discussion honnête sur les limites est plus utile que le marketing.
Taille contre qualité de raisonnement
Les petits modèles sont économes, mais sur des tâches complexes à plusieurs étapes, ils restent en retrait face aux grands. Le compromis se cherche généralement au niveau architectural : on répartit les rôles entre plusieurs petits modèles, on ajoute des vérifications déterministes sur le code, on laisse à l'humain le droit de décision finale.
L'écosystème autour
Des poids ouverts signifient que le modèle se transpose facilement entre frameworks — de LangChain aux orchestrateurs maison. Le revers : les solutions « clés en main » pour un secteur précis sont moins nombreuses que chez les plateformes propriétaires, et une partie du travail d'intégration repose sur l'équipe du client.
Matériel et coût de possession
Le matériel maison, ce n'est pas seulement des économies sur l'API, mais aussi des dépenses d'investissement, de l'électricité, du refroidissement et des personnes pour tout maintenir. Pour une petite entreprise, le cloud sera presque toujours moins cher ; pour une grande avec des données sensibles, c'est l'inverse, et ce seuil se déplace en fonction des volumes.
Évaluation de la qualité
Le principal piège est de mesurer un agent avec des benchmarks généraux. Un agent qui fonctionne se vérifie sur ses propres scénarios : un ensemble de tâches réelles avec une réponse correcte connue, la résistance aux données d'entrée parasites et le comportement lorsqu'un outil appelé renvoie une erreur. Sans un tel ensemble, n'importe quel chiffre issu d'une note de version reste un chiffre issu d'une note de version.
Ce qu'il faut en retenir
La réaction d'IBM au moment actuel du marché semble logique. Pendant que certains courent après la qualité ultime dans le cloud, d'autres occupent une niche où comptent davantage le contrôle, le prix par token et la possibilité de tout déployer à l'intérieur du périmètre. Des poids ouverts, plus des exigences modestes en ressources, plus un accent sur l'appel d'outils — c'est exactement l'ensemble dont a besoin un client d'entreprise fatigué de faire valider l'envoi de données à l'extérieur.
La question clé n'est pas de savoir si la nouvelle version dépassera les leaders sur les tests généraux. La question est de savoir si l'équipe aura la discipline de construire autour du modèle un véritable circuit agentique : avec des droits limités, un audit, des tests et un retour arrière clair. Si oui — garder un tel agent sur son propre matériel devient une stratégie tout à fait viable, et non un compromis.
