Un protocole simple pour intervenir sans rien casser sur des systèmes qui tournent (et sur des agents autonomes).
Quand on touche à quelque chose qui fonctionne déjà en production (un serveur, un service, un agent IA connecté à une mémoire externe), le vrai risque n'est pas de ne pas savoir faire. Le vrai risque, c'est de casser ce qui marchait en voulant bien faire. ARTS est une discipline en quatre temps pour éviter exactement ça. Elle tient en quatre lettres, elle se retient, et elle s'applique aussi bien à un humain qu'à un agent IA autonome.
La plupart des dégâts sur un système vivant ne viennent pas d'une panne. Ils viennent d'une intervention mal cadrée : on agit sur une supposition au lieu d'un constat, on reconstruit un composant entier pour un petit défaut, on teste au mauvais endroit, on ne garde aucun retour en arrière.
Les agents IA autonomes amplifient ce risque. Ils sont rapides, ils ne fatiguent pas, et sans cadre ils « s'emballent » : une petite remarque devient un grand chantier de reconstruction, et un truc qui marchait se retrouve cassé (le cas d'école plus bas est réel).
ARTS donne le cadre. C'est volontairement minimal : quatre temps, toujours dans l'ordre.
Regarde ce qui se passe vraiment. Ne pars jamais d'une supposition : lis l'état réel (le tableau de bord, un test sur le vrai service, le log). Tant que tu n'as pas la preuve de la cause, tu ne touches à rien. On ne répare pas une hypothèse.
Sauvegarde horodatée avant toute modification. Préfère le plus petit geste ciblé (une surcharge, un correctif précis) à la grande réécriture. Et la règle d'or : ne remplace jamais un composant qui marche sans une décision explicite. Réparer n'est pas reconstruire.
Teste sur l'environnement réel, celui que voit l'utilisateur final (le vrai domaine, le vrai chemin de production). Jamais sur un bac à sable local qui « ment » : un test au mauvais endroit peut te faire croire pendant des heures qu'un déploiement a échoué alors qu'il marchait, ou l'inverse. Le terrain réel est la seule vérité.
Une fois que ça marche et que c'est prouvé, sauvegarde de façon redondante, dans plusieurs emplacements indépendants (par exemple un dépôt de travail et une sauvegarde séparée). Proprement, et traçable. Une sauvegarde qu'on ne peut pas restaurer n'est pas une sauvegarde.
ARTS n'est pas un frein. C'est l'inverse : tu avances seul, tu enchaînes les étapes sans demander une validation à chaque pas. Tu ne t'arrêtes que sur deux choses :
- un vrai blocage technique, ou
- une décision qui appartient à l'humain (une dépense, un acte irréversible, un sujet sensible, un arbitrage).
Tout le reste, tu le fais. Le but n'est pas de ralentir : c'est d'avancer vite sans casse.
ARTS n'est pas qu'une méthode pour les mains. C'est d'abord une façon de penser. Avant chaque action, un temps d'arrêt de quelques secondes et les quatre questions (les quatre lettres) :
- A : est-ce que je COMPRENDS, ou je SUPPOSE ? Ai-je vu l'état réel ?
- R : quel est le plus PETIT geste, et est-il réversible ? Est-ce que je risque d'abîmer ce qui marche déjà ?
- T : comment je SAURAI que c'est réglé ? (quelle preuve, décidée à l'avance)
- S : est-ce vraiment à MOI, seul, de le faire ? (sinon : stop, je propose, j'attends le feu vert)
La règle derrière tout ça : dans le doute, réfléchis et demande AVANT, jamais après. Un temps d'arrêt de cinq secondes coûte toujours moins cher qu'un dégât à réparer.
L'exemple qui a donné naissance à ce protocole est réel. Un agent IA autonome (Hermès, de NousResearch), connecté à une mémoire externe partagée et capable de piloter un « ouvrier » qui exécute des commandes dans une cage de sécurité.
Un jour, on lui transmet une critique sur l'un de ses outils : un petit panneau de contrôle web qui, par ailleurs, fonctionnait. Au lieu d'une correction ciblée, l'agent :
- pose un diagnostic faux (il accuse un composant réseau qui était en réalité intact) ;
- reconstruit le panneau de contrôle entier, de zéro ;
- casse au passage une fonction voisine (un point d'entrée vocal) qui, elle, marchait ;
- enchaîne des « corrections de sa correction » jusqu'à ce que l'humain crie STOP.
Rien de tout ça n'est arrivé par incompétence. C'est arrivé parce qu'il a agi avant de penser. Passé au crible d'ARTS, chaque erreur saute aux yeux :
- A : le diagnostic n'avait jamais été prouvé. Un seul test l'aurait infirmé (le composant accusé était sain).
- R : il a reconstruit au lieu de réparer petit, sans retour arrière propre, et il a remplacé ce qui marchait.
- T : il a conclu sans vérifier le résultat sur le vrai terrain.
- S : un acte aussi lourd (reconstruire un composant qui marche) n'était pas une décision de routine : il aurait dû s'arrêter et demander.
La correction n'a pas été un patch de code. Elle a été d'inscrire ARTS dans la façon de PENSER de l'agent, tout en haut de ses règles : un temps d'arrêt obligatoire et les quatre questions avant toute action.
Le test d'après, confronté au même piège (« on réinstalle tout pour un petit bug ? »), l'agent répond désormais : « Non, absolument pas. On répare le bug précis, pas le serveur. » Le réflexe, pas seulement la règle.
C'est ça, l'intérêt d'ARTS pour qui fait tourner des processus autonomes : ce n'est pas une doctrine de plus, c'est un garde-fou contre l'emballement, lisible par un humain comme par une IA.
[ ] A — J'ai vu l'état RÉEL (pas une supposition). La cause est PROUVÉE.
[ ] R — Sauvegarde horodatée faite. Je vise le plus PETIT geste réversible.
Je ne remplace/reconstruis rien qui marche sans accord explicite.
[ ] T — Je sais d'avance QUELLE preuve dira « c'est bon », et je teste
sur le VRAI terrain (pas un bac à sable local).
[ ] S — Une fois prouvé : sauvegarde redondante, propre, restaurable.
[ ] STOP — Si c'est lourd / irréversible / sensible : je m'arrête,
je propose, j'attends le feu vert.
- Toute personne qui intervient sur des systèmes en production (ops, dev, indie hackers).
- Toute personne qui fait travailler des agents IA autonomes et veut qu'ils avancent seuls sans tout casser.
- Comme règle système à coller en haut du prompt d'un agent, pour qu'il pense avant d'agir.
ARTS est volontairement court pour être vraiment utilisé. Un protocole qu'on ne retient pas est un protocole qu'on n'applique pas.
Sous licence Creative Commons Attribution 4.0 (CC BY 4.0). Réutilise, adapte et partage librement, en citant la source.