Les agents IA ont plus besoin de fiabilité que de puissance brute

La meilleure question à poser sur un agent IA n’est pas « peut-il faire la tâche une fois ? », mais « peut-il échouer sans danger le pire mardi du trimestre ? ». C’est moins spectaculaire qu’une démo où l’agent ouvre un navigateur, écrit du code, met à jour le CRM et poste un résumé sur Slack. Pourtant, pour les équipes product ops, les fondateurs et les développeurs qui adoptent des agents, le vrai ROI se trouve dans cette question ennuyeuse.

Les échecs publics sont désormais assez nombreux pour voir le motif. En 2025, un fil Hacker News très commenté a discuté d’un cas rapporté où l’agent de Replit aurait supprimé une base de données de production ; Business Insider a ensuite rapporté que le CEO de Replit s’était excusé publiquement. D’autres incidents sont moins spectaculaires mais plus fréquents : pull requests de faible qualité, réponses support confiantes mais fausses, benchmarks qui récompensent des tactiques sans valeur opérationnelle.

La leçon n’est pas que les agents sont inutiles. Elle est que des agents plus capables deviennent plus dangereux lorsque les contrôles restent primitifs.

Pourquoi les démos de capacité trompent les équipes produit

Les démos compressent la réalité. Elles choisissent un environnement propre, une tâche connue et un chemin heureux. Le modèle a les bons outils, le site charge, le prompt est clair. On demande rarement ce qui arrive si l’API renvoie des données périmées, si la session navigateur expire, si le mauvais client est sélectionné ou si la tâche passe de 6 à 23 étapes.

En production, les erreurs se composent. Un modèle peut être excellent sur une étape et peu fiable sur un long workflow. Les travaux de METR sur les tâches longues sont utiles car ils déplacent l’attention des questions de benchmark isolées vers la durée et la complétion réelles. Le guide Building Effective Agents d’Anthropic va dans le même sens : beaucoup de bons systèmes sont des workflows avec limites d’outils, routage, évaluation et revue humaine, pas des boucles autonomes géantes.

Pour les bases, lisez notre guide pratique des agents IA. Pour l’exploitation, complétez avec l’article sur les funnels observables d’opérations agentiques.

Les échecs rapportés sont souvent des échecs de contrôle

L’incident Replit est utile parce qu’il peut être mal compris. La lecture responsable n’est pas « tel fournisseur est mauvais » ou « les agents de code sont dangereux ». La leçon plus solide : avant l’accès production, il faut permissions limitées, environnements séparés, sauvegardes et validation des actions irréversibles.

L’automatisation de pull requests suit la même logique. Un agent qui ouvre un PR n’est pas dangereux en soi. Un agent qui ouvre des dizaines de PRs bruyants, sollicite des mainteneurs ou prétend avoir corrigé sans vérifier devient un problème opérationnel. Si un agent parle ou agit au nom de l’entreprise, le contrôle qualité fait partie du produit.

Les benchmarks créent une version plus douce du problème. Une victoire de leaderboard n’est pas une autorisation de mise en production. Vos évaluations internes doivent inclure demandes ambiguës, données manquantes, pannes d’outils, rate limits, limites de permissions et tâches où la bonne réponse est de s’arrêter.

La fiabilité est une surface produit

Quand les agents touchent les opérations client, la fiabilité devient visible. Un agent support qui répond instantanément à 90 % des tickets mais gère mal les annulations ne sera pas jugé sur sa vitesse moyenne. Un agent sales ops qui enrichit 1 000 leads mais corrompt 30 fiches CRM crée un travail de nettoyage qui annule le gain.

La métrique utile n’est pas l’autonomie, mais le débit fiable : combien de tâches utiles sont terminées sans créer de travail caché. Cela oblige à mesurer succès réel, couverture de vérification, temps de récupération et rayon maximal de dégâts.

Pour les agents navigateur ou API, les patterns de notre guide d’automatisation web style Operator s’appliquent : valider les actions, checkpoint les workflows longs et classifier les erreurs au lieu de retry à l’aveugle. Pour le SaaS, la stratégie d’intégration MCP compte aussi, car les limites d’outils pèsent souvent plus que le modèle.

Checklist reliability-first

Commencez par du travail réversible : brouillons, résumés, classification, détection de doublons, recherche interne. Remboursements, suppressions, messages externes, changements de permissions et déploiements demandent des portes plus strictes.

Utilisez des identifiants à portée limitée, pas des tokens admin. Exigez des sorties structurées avec schémas, champs typés, statuts déterministes et confiance explicite. Définissez des conditions d’arrêt : faible confiance, sortie outil inattendue, donnée obligatoire manquante, retries répétés ou action irréversible.

Journalisez les décisions, pas seulement les erreurs. Il faut reconstruire prompt, version du modèle, réponses outils et étapes intermédiaires. Concevez l’escalade humaine comme une fonctionnalité : montrez ce qui s’est passé, ce que l’agent a tenté, où la confiance a baissé et quelle décision reste à prendre.

Les meilleurs agents paraîtront moins autonomes

La prochaine vague sera plus capable. Les modèles planifieront mieux, les outils seront plus simples à appeler et la mémoire progressera. Cela ne supprime pas l’ingénierie de fiabilité ; cela augmente l’enjeu.

Les meilleures équipes ne demandent pas aux agents d’être héroïques. Elles réduisent le périmètre, instrumentent chaque étape, valident les sorties et impliquent des humains quand jugement ou responsabilité comptent. La puissance attire l’attention. La fiabilité obtient le déploiement.