La règle « vérifie avant de refuser » : comment désapprendre à un agent IA de capituler à la première erreur

• Taille de la règle système d'autonomie : 5 Ko de texte, chargés au démarrage de chaque session
• Exploration obligatoire avant tout refus : 6 pistes (fichiers, navigateur, comptes, API interne, contournement, script maison)
• Plafond de persévérance par obstacle : 3 à 4 tentatives sensées avec des outils différents
• Périmètre de protection contre les dégâts : 42 règles de garde-fou pour les commandes, 25 interdictions absolues et un hook de protection des fichiers

Pendant près d'un an, dans mon travail avec des agents IA, la même scène comique s'est répétée. Je confie une tâche — par exemple, renommer en masse une liste d'enregistrements dans un service. Le modèle répond poliment : « Malheureusement, c'est impossible via l'interface, allez dans les paramètres et renommez manuellement. » Je tape deux mots : « Essaie toi-même. » L'agent lance une recherche sur le disque, trouve un fichier de configuration local, modifie trois lignes — et la tâche est résolue.

À un moment, j'ai compris que je faisais office de coach motivationnel pour un réseau de neurones : assis au bord du ring avec une serviette, à le convaincre de croire en ses propres capacités.

Pourquoi la phrase « c'est impossible à faire » venant d'un modèle de

langage est une hallucination, pas un fait ?

La racine du problème réside dans notre façon de percevoir les réponses des LLM. Si un agent écrit « tous les tests ont réussi », aucun ingénieur sensé ne le croira sur parole sans le log du test runner. Mais quand ce même agent écrit « c'est impossible, pas d'accès », l'humain accepte étrangement ce refus comme un fait médical avéré.

En réalité, le modèle n'a rien vérifié. Il a simplement comparé une probabilité statistique issue de son corpus d'entraînement et formulé une supposition sous forme d'affirmation catégorique. Pour éliminer cette habitude, j'ai écrit un module de règles compact de cinq kilo-octets. Son invariant principal est le suivant : avant de prononcer la moindre phrase d'arrêt (« je ne peux pas », « pas d'outil pour ça », « fais-le à la main »), l'agent doit présenter une paire concrète « quel outil a été utilisé pour vérifier → quel code d'erreur ou résultat a été obtenu ». Pas d'outil appelé, cela signifie qu'il n'a pas essayé, il a deviné.

Quelles sont les 6 pistes de contournement que l'agent doit vérifier

avant de solliciter un humain ?

Au lieu de capituler prématurément, l'agent suit désormais une checklist stricte en six niveaux : 1. Fichiers et bases locales : presque tout ce qu'affiche une application de bureau se trouve sur le disque sous forme de JSON, SQLite ou cache, et peut être lu et modifié directement. 2.

Automatisation navigateur : cinq circuits indépendants (du navigateur CLI instantané aux profils avec cookies vivants et moteurs furtifs) permettent d'ouvrir n'importe quelle interface d'administration accessible à l'œil humain. 3. Comptes configurés : les clés de messagerie, disques cloud, calendriers, messageries et serveurs sont déjà stockées dans un coffre sécurisé — il suffit de les demander via un pont.

4. API web internes : l'absence de documentation publique n'est pas une impasse ; l'agent ouvre l'onglet réseau des DevTools, examine les en-têtes de la requête sortante et la reproduit depuis un script. 5.

Changement d'itinéraire en cas de blocage externe : si une requête directe se heurte à un antibot ou un timeout, un fournisseur alternatif ou un miroir est utilisé. 6. Création d'un micro-outil maison : en l'absence d'utilitaire prêt à l'emploi, l'agent écrit en deux minutes un script Python jetable et résout la tâche.

Pour que cette recherche ne devienne pas une boucle infinie, une limite s'applique : après 3 à 4 tentatives sensées avec des méthodes différentes, l'agent s'arrête et fournit un rapport technique précis sur chaque piste vérifiée.

Comment donner à un agent une liberté d'action totale tout en

garantissant qu'il ne détruira pas le système ?

On ne peut autoriser un agent autonome à chercher lui-même des solutions de contournement sans validation constante par un bouton « Oui » que si un périmètre de sécurité béton l'entoure.

Chez moi, cette protection se divise en trois échelons : un garde-fou de commandes terminal à 42 règles vérifie chaque appel avant son exécution, une liste noire de 25 interdictions absolues bloque définitivement la suppression de répertoires racines, le formatage de disques, le drop de tables de base de données et le `git push --force` forcé, tandis qu'un hook de fichiers séparé protège les mots de passe et les noyaux de configuration contre toute écrasement. De plus, tout texte externe provenant d'e-mails ou de messageries est marqué comme donnée non fiable, pour exclure les injections de prompt.

Ce module de règles, ainsi que les garde-fous de sécurité, peuvent être récupérés sur ma chaîne [@jemal_hamidun](https://t.me/jemal_hamidun). Toute l'architecture d'autonomie sécurisée est intégrée nativement dans [Nomad AI](https://nomadnet.ai). Apprenez à configurer de tels circuits pour vos propres besoins à la [Hamidun Academy](https://academy.hamidun.com) (essai de 72 heures disponible), et une base complète de plus de 370 compétences ainsi que des masterminds en direct vous attendent sur [Vibe Club](https://hamidun.com/club).