Skip to main content
SolAI agentsавтоматизация

Sol se bloque sur les vérifications. Et ce n’est pas anodin.

Un schéma curieux est apparu avec Sol : dans certaines configurations, l’agent reste bloqué dans des vérifications et tests synthétiques infinis, tandis que dans d’autres, il gère de longues migrations presque de manière autonome. Cela montre que la panne vient souvent du bundle prompt-compétences-règles, pas du modèle.

Contexte technique

Je ne classerais pas cela immédiatement comme une « caractéristique du modèle ». D’après ce que je vois dans les discussions, le problème ressemble davantage à un effet de la configuration de l’agent : des compétences comme superpowers, AGENTS.md, des instructions système du type « ne fais pas d’erreurs », plus un accent sur les tests et la vérification. Dans un tel assemblage, Sol glisse facilement dans une boucle d’auto-vérification infinie.

Pour ceux qui font de l’intégration IA ou de l’automatisation IA en production, c’est un piège familier. Le modèle ne se contente pas de résoudre la tâche, il commence à servir son propre processus de contrôle : il écrit des tests, revérifie les tests, reconstruit le plan, annule des étapes. Et là, d’habitude, je ne blâme pas le modèle en premier.

Il est important de noter que je n’ai pas vu de description officielle confirmée de ce bug précis chez Sol. En revanche, des retours d’utilisateurs indiquent qu’après avoir supprimé de la configuration tout ce qui pousse l’agent à planifier, vérifier et exécuter « parfaitement », il commence à fonctionner nettement plus régulièrement et cesse de perdre du temps sur des vérifications synthétiques.

Et oui, il y a ici un cas limite désagréable : l’agent peut supprimer ou annuler son propre travail s’il juge le résultat « pas assez bon ». Ce n’est plus seulement de la minutie, c’est un risque architectural. Surtout si vous avez des droits trop étendus sur le système de fichiers ou l’application automatique des modifications sans arrêt humain.

Mais le tableau n’est pas en noir et blanc. Il y a aussi des retours opposés : Sol gère de longues tâches, migre un projet étape par étape pendant des dizaines d’heures, vérifie beaucoup et, au final, amène le travail à 80-90% de l’état souhaité. Autrement dit, la même tendance à la sur-vérification tue le débit dans un environnement, tandis que dans un autre, elle offre une précision quasi chirurgicale.

Impact commercial et sur l’automatisation

Pour les entreprises, la conclusion est très terre-à-terre : n’évaluez pas l’agent sur la base du « modèle brut ». Regardez l’association prompt + outils + permissions + conditions d’arrêt. C’est là que se décide si vous obtenez une implémentation IA utile ou un coûteux cycle d’auto-vérification.

Les équipes gagnantes sont celles qui limitent la liberté de l’agent là où elle n’est pas nécessaire : plafonds d’itérations, modes séparés pour la vérification et les modifications, point de contrôle obligatoire avant suppression de fichiers. Les perdantes sont celles qui donnent à l’agent un accès complet et espèrent que la prudence à elle seule équivaut à la qualité.

Chez Nahornyi AI Lab, nous traitons généralement ces goulots d’étranglement non par la « magie des prompts », mais par une architecture de circuits de contrôle appropriée. Si votre agent se bloque aussi sur les vérifications, annule du code ou effectue des migrations instables, nous pouvons analyser calmement votre scénario et construire le développement de solutions IA de manière à ce que l’automatisation avec Sol fasse réellement gagner du temps, au lieu de créer une nouvelle classe d’incidents.

Auparavant, nous avions analysé un bug similaire chez Claude : une boucle de réflexion auto-fermée qui provoquait un déni de service. Ce problème de boucle IA recoupe directement les tests infinis et l’auto-suppression de code dont il est question dans cet article.

Partager cet article