Votre agent IA fonctionne. Mais profite-t-il encore des meilleurs modèles ?

Un agent IA peut continuer à tourner sans être encore réglé de la meilleure façon. Les messages arrivent, les automatisations se déclenchent, les comptes rendus sont produits. Rien ne semble cassé. Pourtant, le modèle, ses capacités et ses recommandations d’usage évoluent. Une installation laissée telle quelle risque de conserver des instructions devenues inutiles, de s’interrompre trop tôt ou de payer plus cher que nécessaire pour le même travail. Ce sont des hypothèses à tester, pas des défauts que l’on peut déduire d’une annonce.

Le guide publié par Anthropic pour Opus 5.5 en donne un exemple concret. L’éditeur recommande de confier une tâche complète au modèle, de préciser ce qui constitue un résultat terminé et d’indiquer les cas où il doit s’arrêter pour demander une décision. Il conseille aussi de retirer les consignes génériques du type « réfléchis étape par étape », puisque le modèle gère déjà son effort de réflexion, et de revoir la manière de piloter les exécutions longues.[1] Ce sont des recommandations propres à ce modèle et à ses outils, pas une règle universelle à copier dans tous les systèmes.

Le risque discret des installations qui ne sont plus suivies

Une installation d’agent IA n’est pas figée le jour de sa mise en production. Elle dépend de plusieurs éléments : le modèle choisi, les instructions, les outils auxquels il a accès, les règles d’arrêt, les contrôles et la façon dont son travail est évalué. Quand un de ces éléments évolue, les autres méritent d’être réexaminés.

Prenons un agent chargé de traiter des demandes entrantes. Ses instructions ont peut-être été écrites pour obtenir de bonnes réponses sur un ancien modèle, en découpant chaque tâche en petites étapes et en imposant des points d’arrêt fréquents. Si un modèle plus récent tient mieux une tâche longue, conserver exactement le même dispositif peut multiplier les interruptions inutiles. À l’inverse, laisser le nouvel agent poursuivre sans validation sur une action sensible peut créer un risque. On ne tranche pas cela à la lecture d’une annonce : on le teste sur des dossiers représentatifs, avec les mêmes critères de qualité.

C’est ainsi qu’une équipe peut manquer une information utile sans voir de panne. Son système reste opérationnel, mais il n’a pas forcément le bon modèle, les bons réglages ou le bon coût pour le travail demandé. Il faut distinguer une dégradation mesurée, par exemple davantage de dossiers repris à la main, d’une occasion d’amélioration manquée. La publication d’un modèle ne prouve, à elle seule, ni que votre agent est devenu moins bon ni qu’une migration l’améliorera.

La veille n’a de valeur que si elle débouche sur des tests

À chaque évolution importante, la question utile n’est pas « faut-il basculer tout de suite ? ». Il faut d’abord identifier les agents concernés. Une nouvelle capacité de lecture de documents ne change rien à un agent qui ne lit que des données structurées. Une meilleure autonomie sur des tâches longues peut, en revanche, intéresser un système qui s’arrête aujourd’hui trop souvent avant de terminer un dossier.

Ensuite, on compare l’existant et le candidat sur les mêmes cas, dans un environnement maîtrisé. Le bon échantillon comprend des tâches ordinaires, des exceptions et des situations où l’agent doit dire qu’il ne sait pas. On observe ce qui compte pour le client : dossiers correctement terminés, corrections humaines, demandes de validation pertinentes, délais, coût par dossier et incidents. Une démonstration impressionnante ou une note de benchmark ne remplace pas ce test sur les données et les outils du client.

Enfin, on ajuste avant de déployer. Parfois, il suffit de retirer une instruction devenue inutile ou de mieux définir le résultat attendu. Parfois, il faut changer le modèle d’une seule étape du processus, sans toucher au reste. Et parfois, les tests montrent qu’il vaut mieux garder l’installation actuelle. Un « meilleur modèle » sur une annonce n’est pas nécessairement le meilleur choix pour chaque tâche, chaque budget ou chaque niveau de risque. La mise à jour doit pouvoir être expliquée, surveillée et annulée.

Ce que Levolia apporte après la mise en service

Notre travail ne s’arrête pas à l’installation d’un agent. La méthode Levolia inclut une phase d’amélioration après la mise en service. Nous suivons les évolutions des modèles et des outils, puis nous regardons ce qu’elles changent pour les systèmes déjà en place. Cette veille doit aboutir à une recommandation vérifiable : ce qui mérite un test, ce qui ne concerne pas le client et ce qui demanderait une validation avant modification. Nous ne changeons pas de modèle pour afficher une nouveauté sur un tableau de bord.

Le suivi porte aussi sur l’installation elle-même, comme le montre notre retour d’expérience sur Hermes Agent en production. Un agent qui classe des documents doit continuer à les ranger au bon endroit, sans doublons. Un agent qui prépare une réponse doit laisser visibles ses incertitudes et respecter les validations prévues. Un rapport « terminé » n’a de sens que si l’objet attendu existe dans le système de référence. Ces contrôles permettent de repérer un écart réel plutôt que de confondre activité et résultat.

Quand une évolution vaut la peine d’être essayée, nous proposons un changement circonscrit, un état de référence et un contrôle après déploiement. Nous pouvons ainsi expliquer au client ce qui a changé, pourquoi, quel résultat a été observé et comment revenir en arrière si nécessaire. Le conseil consiste aussi à déconseiller une migration quand le gain attendu n’est pas démontré.

Le guide d’Anthropic sur la vérification des résultats recommande de contrôler les résultats des sous-agents, de demander à l’agent ce qu’il n’a pas pu confirmer et de lire d’abord ce qu’il attend de l’utilisateur à la fin d’une longue exécution.[1] Ces principes rejoignent une exigence simple pour tout système durable : le travail doit rester lisible, vérifiable et gouvernable par l’équipe qui l’utilise.

Un agent IA utile dans la durée demande plus qu’une installation réussie. Il faut savoir quand le retester, quand modifier une consigne, quand comparer un autre modèle et quand ne rien changer. Si votre entreprise utilise déjà des agents, parlons d’un flux existant : ce qui fonctionne, ce qui mérite d’être mesuré et les évolutions à tester sans interrompre le service.

Sources

[1] Getting the most out of Opus 5.5 in Claude and Claude Code, https://claude.dev/blog/getting-the-most-out-of-opus-5-5