Plan de secours pour agent IA : que faire quand l’automatisation tombe

Un agent IA qui tombe en panne, ce n’est pas une question de « si ». C’est une question de « quand ». Et le jour où ça arrive, tu n’as pas besoin d’un debugger. Tu as besoin d’une procédure.

La plupart des solopreneurs que je vois traitent la panne d’agent comme un bug : ils ouvrent les logs, ils cherchent la ligne qui a cassé, ils bidouillent le prompt, ils relancent. Résultat : trente minutes plus tard, le fichier est dans un état pire qu’avant, et ils ne savent même plus ce que l’agent avait déjà modifié.

Le bon réflexe, c’est de traiter la panne comme un incident système. Tu ne cherches pas la cause tout de suite. Tu sécurises l’état, tu reviens à un point stable, et ensuite seulement tu analyses. C’est ce qu’on fait en ops depuis trente ans. C’est exactement ce qu’il faut faire avec un agent IA.

Communauté Kavyro

Le vrai sujet n’est pas d’ajouter un agent de plus.

Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.

Cas concrets Arbitrages utiles Questions réelles Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Ce qui peut casser (et ça cassera)

Un agent IA n’est pas un script déterministe. Il prend des décisions, il écrit des fichiers, il exécute des commandes. Et parfois, il se trompe. Parfois, le modèle répond n’importe quoi. Parfois, une mise à jour de l’outil change un comportement que l’agent utilisait. Parfois, le contexte devient trop long et l’agent perd le fil.

Ce qui casse le plus souvent, dans l’ordre : un fichier modifié de travers, une commande shell qui supprime plus que prévu, une boucle de retry qui s’emballe, un prompt qui dérive après vingt tours, ou une dépendance externe qui change sans prévenir.

Et le pire scénario, c’est l’agent qui continue de tourner après avoir cassé quelque chose. Il ne sait pas qu’il a cassé. Il continue, il empile les modifications, et au bout de dix minutes tu te retrouves avec un projet dans un état que même toi tu ne comprends plus.

La question n’est pas d’empêcher les pannes. C’est d’avoir un plan pour revenir en arrière quand elles arrivent. Dans la pratique, c’est ton plan de continuité d’activité appliqué aux agents IA, pour savoir quoi couper, quoi restaurer et quand reprendre.

Les 3 types de pannes

Toutes les pannes d’agent ne se ressemblent pas. J’en distingue trois, et la procédure n’est pas la même pour chaque.

Type 1 : la panne silencieuse. L’agent a produit un résultat, mais il est faux. Le fichier est là, le format est bon, le contenu est inutilisable. C’est le plus traître, parce que rien ne t’alerte. Tu le découvres en relisant. Le bon réflexe : rollback immédiat, pas de correction manuelle.

Type 2 : la panne destructive. L’agent a supprimé ou écrasé quelque chose qu’il ne devait pas toucher. Un fichier de config, un bout de code, un dossier entier. Là, tu le vois tout de suite. Le bon réflexe : ne touche à rien, ne relance pas l’agent, restaure d’abord.

Type 3 : la panne de boucle. L’agent est coincé dans une boucle. Il réessaie la même action, il génère la même erreur, il ne progresse plus. Il consomme du temps et des tokens sans avancer. Le bon réflexe : arrêter la session, restaurer le dernier état stable, comprendre pourquoi il bouclait.

Procédure de diagnostic rapide

Tu as arrêté l’agent. Maintenant, tu veux comprendre ce qui s’est passé, mais sans y passer ta matinée. Voici les trois questions à te poser, dans l’ordre.

Qu’est-ce que l’agent était en train de faire ? Regarde le dernier message que tu lui as envoyé, et les deux ou trois derniers tours de conversation. Est-ce que la tâche était claire ? Est-ce que le contexte avait dérivé ?

Qu’est-ce qui a été modifié ? Si tu utilises Hermes Agent avec les checkpoints activés, tape /rollback dans la session. Tu verras la liste des snapshots avec ce qui a changé à chaque étape. Si tu n’as pas de checkpoints, regarde git diff ou les dates de modification des fichiers.

Est-ce que le problème est reproductible ? Si tu relances la même tâche dans une session propre, est-ce que l’agent refait la même erreur ? Si oui, le problème est dans les instructions ou dans le comportement du modèle. Si non, c’était un aléa de contexte, et un rollback suffit.

Ce diagnostic prend cinq minutes. Pas plus. Si au bout de cinq minutes tu n’as pas identifié la cause, ce n’est pas grave. Tu as déjà l’essentiel : tu sais quel état est stable, et tu peux y revenir.

Rollback : revenir à l’état précédent

C’est la partie que la plupart des gens sautent, et c’est pourtant la plus importante. Un rollback, ce n’est pas un aveu d’échec. C’est une procédure standard. Tu reviens à un état connu, propre, et tu repars de là.

Avec Hermes Agent, le rollback est intégré. La commande /rollback liste tous les checkpoints automatiques pris avant chaque modification de fichier ou commande destructive. Tu choisis le numéro du checkpoint, tu fais /rollback 3, et tout revient à l’état d’avant. Même le contexte de conversation est restauré, pour que l’agent sache exactement où il en était.

Tu peux aussi restaurer un seul fichier : /rollback 3 src/config.py. Pratique quand l’agent a modifié trente fichiers mais qu’un seul est cassé.

Et si tu veux voir ce qui a changé avant de restaurer, /rollback diff 3 te montre le diff complet. Tu décides en connaissance de cause.

Ce système de checkpoints est natif dans Hermes. Il snapshot automatiquement avant chaque write_file, patch, ou commande shell destructive. Il ne touche jamais à ton vrai dépôt git. Tout est stocké dans un shadow repo dédié. Si tu veux comprendre comment ça marche en détail, lis la documentation officielle sur les checkpoints et rollback, puis la version opérationnelle côté Kavyro sur les approbations Hermes.

Le rollback, c’est ton filet de sécurité. Active-le, utilise-le, et ne t’excuse jamais de t’en servir.

Mode dégradé : ce que tu reprends à la main

Le rollback t’a ramené à un état stable. Maintenant, tu as deux options : relancer l’agent sur la même tâche, ou finir à la main. La décision dépend d’un seul critère : est-ce que le problème est reproductible ?

Si le problème est reproductible, relancer l’agent ne sert à rien. Il va refaire la même erreur. Tu passes en mode dégradé : tu fais la tâche toi-même, tu notes ce qui a coincé, et tu ajustes les instructions de l’agent plus tard, quand tu auras le temps.

Si le problème n’est pas reproductible, tu peux relancer. Mais relance dans une session propre, avec un contexte frais. Ne reprends pas la session qui a planté. Le contexte est peut-être corrompu, et tu vas perdre du temps à debugger un problème qui n’existe plus dans une session neuve.

Checklist de prévention

• Checkpoints activés. hermes chat --checkpoints ou enabled: true dans la config. Sans ça, pas de rollback.
• Un git commit propre avant de lancer l’agent. Les checkpoints Hermes sont une couche supplémentaire, pas un remplacement de git.
• Une tâche par session. Ne demande pas trois choses différentes dans la même conversation. Le contexte dérive, et le rollback devient plus compliqué.
• Un test de sortie. Demande à l’agent de valider son propre résultat avant de te le rendre. Un agent qui vérifie sa sortie est un agent qui détecte ses propres pannes silencieuses.
• Une limite de tours. Si l’agent dépasse 15 ou 20 tours sur une tâche simple, il est probablement en boucle. Arrête-le.

Un agent IA qui tombe en panne, ce n’est pas un drame. C’est un incident comme un autre. Tu as une procédure, tu l’appliques, tu reviens à un état stable, et tu continues. Le plan de secours, ce n’est pas un document que tu ranges dans un tiroir. C’est un réflexe que tu construis en l’appliquant. La prochaine fois que ton agent plante, ne cherche pas le bug. Fais un rollback. Rejoins Kavyro et construis ton équipe d’agents avec les bons filets de sécurité.