Ricursive lance Ripple-65B : le modèle atteint 80,5% sur Terminal-Bench 2.1

Lorsqu’un agent corrige un bug, le temps et l’argent se dépensent sur l’ensemble du parcours : lire les fichiers, trouver la cause, apporter une correction, lancer les tests et comprendre la nouvelle erreur. Ricursive propose Ripple-65B Preview pour ce type de travail. L’intérêt pratique est clair : vérifier si le modèle peut intervenir sur votre dépôt avec une latence et un coût acceptables. Par exemple, peut-il réparer seul un gestionnaire d’API défaillant et valider le résultat par un test ?

Il s’agit d’un modèle à poids ouverts de 65 milliards de paramètres. Dans l’évaluation publiée par ses développeurs, il a obtenu 80,52% sur Terminal-Bench 2.1. Reflection Beam affiche 80,1% dans le même tableau. L’écart est faible : un titre annonçant une victoire incontestable serait donc excessif. Le plus intéressant est la possibilité de disposer d’un candidat supplémentaire pour un agent de programmation. Source : Ricursive.

Ce qui a été publié

Ripple repose sur une architecture dense : contrairement aux modèles à mélange d’experts, il mobilise tous ses paramètres pour traiter chaque token. Une comparaison fondée uniquement sur la taille totale peut donc être trompeuse. Dans un modèle à mélange d’experts plus volumineux, seule une partie des paramètres est active à un instant donné ; un nombre plus petit dans le nom ne garantit pas, à lui seul, une réponse moins coûteuse.

Les développeurs annoncent une fenêtre de contexte allant jusqu’à 1 048 576 tokens. Les poids sont publiés sous Apache 2.0, avec des versions BF16 et NVFP4. Pour une équipe soumise à des contraintes d’hébergement du code, cela élargit les possibilités : elle peut envisager un déploiement sur sa propre infrastructure. Mais la taille du contexte ne dit pas encore avec quelle fiabilité l’agent retrouvera la dépendance pertinente parmi des centaines de fichiers. Source : fiche du modèle.

Il est utile de distinguer ici deux tâches. La première consiste à héberger le modèle et à obtenir une vitesse de réponse acceptable. La seconde consiste à construire un agent qui utilise correctement la recherche, le terminal et les tests. Réussir la première ne garantit pas de réussir la seconde. Un contexte long ne dispense pas non plus de choisir les fichiers à transmettre au modèle.

Pourquoi le score au benchmark ne se transpose pas directement à votre dépôt

Les auteurs décrivent eux-mêmes la sensibilité des évaluations d’agents aux conditions d’exécution. La fiche indique que des changements du logiciel de pilotage et des paramètres de contexte ont fait varier les résultats sur Terminal-Bench. Leur tableau comparatif réunit les scores officiels d’autres laboratoires et leurs propres mesures lorsque les données publiées étaient insuffisantes. Cela limite la précision d’une comparaison directe. Méthodologie d’évaluation.

Prenons un bug courant : après la mise à jour d’une dépendance, la connexion des utilisateurs ne fonctionne plus. L’agent doit lire le message d’erreur, repérer l’appel qui a changé, corriger le gestionnaire et lancer le test approprié. Une réponse élégante expliquant la cause ne suffit pas. Il faut une correction fonctionnelle qui préserve le comportement des autres scénarios.

Ajoutons maintenant les conditions réelles : la base de données de test est indisponible, la documentation est obsolète et l’erreur ne se reproduit qu’avec une configuration particulière. C’est précisément là que les différences entre les modèles et les configurations de l’agent apparaissent. L’un aura besoin d’une indication humaine, un autre commencera à modifier des fichiers superflus, un troisième indiquera correctement les données qui lui manquent. Le score global d’un benchmark ne remplace pas cette vérification.

Comment évaluer l’intérêt pour votre équipe

Je commencerais par une petite sélection de tâches déjà résolues : corriger une erreur, ajouter un test, modifier une API et intervenir sur un module inconnu. Pour chacune, il faut disposer de l’état initial du projet et d’un critère de réussite clair. Il convient ensuite de donner à Ripple et au modèle actuellement utilisé les mêmes outils, les mêmes limites de temps et le même accès à l’environnement.

Mieux vaut calculer le coût d’une modification acceptée. Il comprend les nouvelles tentatives, le temps d’exécution des commandes et la vérification humaine. Des tokens bon marché sont de peu d’utilité si un développeur passe ensuite une demi-heure à supprimer des changements inutiles. Il faut aussi consigner séparément les cas où l’agent a déclaré la tâche résolue alors que le résultat n’a pas pu être vérifié.

Pour le produit, cette démarche permet de prendre une décision concrète : Ripple convient-il à la catégorie de tâches retenue, faut-il prévoir une vérification supplémentaire et à quel moment passer le relais à un humain ? Les poids ouverts rendent cette expérimentation plus accessible en donnant davantage de contrôle sur le déploiement. La décision de changer de modèle doit reposer sur les résultats obtenus sur votre code, en tenant compte du temps, des dépenses et de la qualité des modifications.