Le 6 juin 2026, je n’ai pas commencé ma journée en découvrant un service arrêté et une liste de messages urgents. C’est justement ce qui a rendu l’épisode intéressant. Un incident est arrivé, mais les trois IA qui font tourner une partie de mon système avaient déjà une feuille de route claire pour ce cas précis.
Comment trois agents IA se coordonnent-ils sans humain ?
Atos a détecté le problème. Portos a relancé ce qui devait l’être. Aramis a surveillé la suite. De mon côté, je n’ai pas eu à courir derrière chaque étape. J’ai regardé, j’ai vérifié que le cadre était respecté, et j’ai gardé la main sur ce qui méritait une vraie décision humaine.
Ce n’est pas l’histoire d’une machine devenue magique. Ce n’est pas non plus une promesse selon laquelle tout peut fonctionner sans personne. C’est une expérience plus simple et, à mes yeux, plus utile : laisser les tâches prévisibles se dérouler seules, tout en conservant un humain pour les choix lourds. Bienvenue dans l’épisode 2 de la série Construction de l’Empire.
Le problème : un incident ne prévient pas
Un service qui tombe, ce n’est jamais agréable. Même lorsque la cause paraît simple, le vrai risque est rarement le premier problème. Le risque, c’est ce qui vient après : on voit l’alerte trop tard, on cherche quoi faire dans l’urgence, on relance dans le désordre, puis on oublie de vérifier si la situation est vraiment redevenue normale.
Quand on travaille seul ou avec une petite équipe, ce genre de moment peut casser toute une journée. On abandonne ce qui était prévu. On se met à répondre à des messages. On essaie de reconstituer ce qui s’est passé. Et, souvent, on prend une décision rapide juste parce qu’on veut que le souci disparaisse.
Le problème n’était donc pas seulement le fait qu’un service soit indisponible. Le problème était la dépendance à ma présence pour des gestes connus d’avance. Si la procédure est toujours la même, pourquoi faudrait-il la réinventer au moment où la pression monte ?
Cette question est importante, parce qu’il existe deux types de situations. Il y a celles qui reviennent et dont la réponse est connue : vérifier l’état d’un service, tenter une relance prévue, puis surveiller ce qui se passe. Et il y a les situations qui demandent du jugement : arrêter une action, accepter un risque, changer une règle, prévenir des personnes, ou décider qu’un problème est assez grave pour modifier le plan.
Confondre les deux fait perdre du temps. Si l’humain intervient dans chaque micro-action, il devient le goulot d’étranglement. Si on laisse les systèmes prendre seuls les décisions lourdes, on crée un autre danger : personne ne porte vraiment la responsabilité du choix.
Je voulais donc un fonctionnement plus calme. Pas une autonomie totale. Une autonomie surveillée.
La solution : écrire la feuille de route avant l’urgence
La décision a été de préparer un runbook. Le mot peut sembler compliqué, mais l’idée est très simple : c’est une feuille de route écrite à l’avance pour un incident précis. Au lieu de réfléchir sous stress, on suit des étapes décidées quand tout va bien.
Dans ce cas, la feuille de route concernait un service indisponible. Elle ne disait pas : « faites tout ce qui vous semble utile ». Elle décrivait une suite limitée, avec des rôles clairs. Atos audite, Portos relance, Aramis surveille.
Atos est le premier regard. Son travail est de constater qu’il y a bien un problème et de vérifier la situation avant qu’une action soit lancée. Cette étape compte beaucoup. Sans elle, on peut relancer quelque chose qui n’est pas réellement en panne, ou agir à partir d’un mauvais signal.
Portos intervient ensuite. Sa mission est concrète : relancer selon la procédure prévue. Il ne choisit pas une nouvelle stratégie. Il n’improvise pas. Il exécute l’action autorisée par la feuille de route. Cette limite est rassurante. Une IA peut être rapide, mais la rapidité n’a de valeur que si le terrain de jeu est bien délimité.
Aramis prend le relais pour surveiller. Relancer n’est pas la fin de l’histoire. Il faut encore observer ce qui se passe après l’action : est-ce que le service revient ? Est-ce que le problème semble se calmer ? Est-ce qu’un signe oblige à remonter le sujet à un humain ? Aramis est là pour éviter le faux soulagement du « c’est relancé, donc c’est réglé ».
Mon rôle n’a pas disparu. Il a changé. Je n’avais pas à déclencher chaque geste connu, mais je restais responsable du cadre. Les décisions lourdes devaient toujours être validées par moi. C’est la règle qui protège le système : l’autonomie s’arrête là où le choix peut avoir des conséquences importantes ou inhabituelles.
Concrètement, cela veut dire qu’une feuille de route doit être précise sur deux choses. D’abord, ce qui est autorisé sans demander. Ensuite, ce qui exige un arrêt et une validation humaine. Cette deuxième partie est souvent la plus importante. Elle évite qu’un assistant, humain ou IA, dépasse son mandat parce qu’il essaie simplement d’être utile.
Le 6 juin, cette préparation a été mise à l’épreuve. Le runbook « Service DOWN » a été exécuté sans intervention humaine : Atos a audité, Portos a relancé, Aramis a surveillé. Ce n’était pas un spectacle. C’était exactement l’objectif : une réponse sobre à un problème connu.
Le résultat : moins de bruit, plus de contrôle
Le résultat principal n’est pas de dire que je n’ai plus besoin de surveiller quoi que ce soit. Ce serait faux. Le résultat, c’est que je n’ai plus besoin d’être le bouton de démarrage de chaque action prévisible.
Cette différence paraît petite, mais elle change le quotidien. Au lieu de recevoir un problème brut auquel je dois répondre immédiatement, je peux suivre une situation déjà prise en charge dans les limites prévues. Je garde de l’attention pour ce que personne ne peut décider à ma place.
Il y a aussi un effet sur la qualité des décisions. Pendant un incident, la fatigue et l’urgence poussent facilement à faire trop vite, trop large, ou trop tard. Une feuille de route enlève une partie de cette pression. Les premières actions ne dépendent plus de mon humeur, de mon niveau d’énergie ou de ma disponibilité exacte à cet instant.
Ce fonctionnement rend également le système plus lisible. Chaque IA a un rôle. Atos ne relance pas à l’aveugle. Portos ne se transforme pas en décideur. Aramis ne prétend pas que son observation remplace une décision humaine. Quand les rôles sont séparés, on sait mieux ce qui a été fait et pourquoi.
Le point le plus important reste la supervision minimale. « Minimale » ne veut pas dire absente. Cela veut dire que l’humain n’est appelé que lorsqu’il apporte une vraie valeur : arbitrer, accepter ou refuser une conséquence, décider d’un changement, ou traiter un cas qui sort de la feuille de route.
Pour moi, c’est une définition honnête de l’autonomie. Les IA peuvent gérer des gestes prévisibles. Elles peuvent suivre une procédure. Elles peuvent signaler ce qui mérite une attention. Mais elles ne remplacent pas la personne qui fixe les règles et assume les choix importants.
La leçon pour toi
Tu n’as pas besoin d’avoir trois IA ni un grand système pour appliquer cette idée. Commence par regarder les petites situations qui reviennent dans ton travail. Celles qui t’interrompent souvent, qui demandent toujours les mêmes vérifications, ou qui te font perdre du temps alors que la réponse est déjà connue.
Choisis un seul scénario simple. Par exemple : un outil ne répond plus, un dossier attendu manque, une demande arrive sans les informations nécessaires, ou une publication doit passer par une vérification habituelle. Ne cherche pas à tout automatiser d’un coup. Écris plutôt ce que tu fais aujourd’hui, étape par étape.
Ensuite, sépare les gestes des décisions. Un geste, c’est vérifier, classer, relancer, rappeler une règle ou signaler un écart. Une décision, c’est modifier un engagement, accepter une exception, publier une information sensible, dépenser de l’argent ou changer une priorité. Les gestes répétitifs peuvent souvent être délégués. Les décisions qui engagent vraiment quelque chose doivent rester chez toi.
Ta feuille de route peut tenir en quelques phrases. Elle doit répondre à des questions très simples : comment sait-on qu’il y a un problème ? Quelle première action est autorisée ? Que faut-il surveiller après ? À quel moment faut-il s’arrêter et te prévenir ? Si tu ne peux pas répondre clairement à ces questions, la tâche est probablement trop floue pour tourner seule.
Il faut aussi accepter que la première version sera imparfaite. C’est normal. Une procédure s’améliore avec les cas réels. L’important est de commencer avec un périmètre modeste et des limites nettes. Tu pourras élargir plus tard, après avoir compris ce qui se passe vraiment.
Les erreurs à éviter
Premier piège : vouloir automatiser une situation mal comprise. Si tu ne sais pas exactement ce qui déclenche le problème ni quelle action est sûre, tu ne gagnes rien à déléguer. Tu déplaces simplement le risque. Commence par observer, puis écris une réponse simple pour les cas réellement connus.
Deuxième piège : confier une décision lourde à une procédure. Une relance prévue est une chose. Décider d’un changement qui peut avoir des conséquences plus larges en est une autre. Quand une action peut toucher des clients, de l’argent, une réputation, une règle importante ou une relation humaine, il faut une validation claire. Ne masque pas une décision derrière le mot « automatisation ».
Troisième piège : oublier la surveillance après l’action. Beaucoup de systèmes savent déclencher une action. Moins savent vérifier le résultat. Pourtant, c’est là que les ennuis se cachent. Une action peut sembler terminée sans avoir résolu le problème. Prévois toujours quelqu’un, ou quelque chose, qui regarde la suite et qui sait quand alerter.
Conclusion
L’épisode du 6 juin 2026 m’a confirmé une idée simple : l’autonomie utile n’est pas celle qui enlève l’humain du tableau. C’est celle qui lui évite les gestes prévisibles pour lui laisser les décisions qui demandent du recul.
Atos a détecté. Portos a relancé. Aramis a surveillé. Et moi, j’ai gardé la main là où elle devait rester : sur les choix importants. Le vrai progrès n’est pas d’avoir tout laissé tourner seul. Le vrai progrès est d’avoir écrit les règles avant d’en avoir besoin.
Si tu veux construire ton propre empire, ne commence pas par chercher une machine qui décide à ta place. Commence par une feuille de route claire pour un problème qui revient. Puis protège tes limites. C’est moins impressionnant qu’un grand discours sur l’IA, mais c’est beaucoup plus solide dans la vraie vie.
Sources
Ledger interne, jalon du 06/06/2026 : exécution sans intervention humaine du runbook « Service DOWN » ; Atos audite, Portos relance et Aramis surveille. Le même jalon précise que les décisions lourdes restent validées par l’humain.
Adoptez l'Arsenal 2026 : https://grands-destins.com/arsenal-2026
© 2026 Arsenal — Serge. Tous droits réservés. Le système Arsenal — protocoles, méthodes, contenus — est exclusif : toute reproduction, adaptation ou diffusion sans autorisation écrite est interdite. Partage des articles autorisé avec mention de la source et lien vers l'original.
Pour aller plus loin
Construction de l'Empire — Prologue : LMP, le protocole mémoire perpétuelle
Le logiciel devient facile à construire. Alors qu'est-ce qui se vend vraiment ?
Construction de l'Empire #1 — Le jour où j'ai coupé mes abonnements IA payants
## 🛡️ Vérification OSINT - Source vérifiée (WHOIS/Domaine) : [Lien] - Image vérifiée (Reverse Search) : [Lien] - Méthode de validation : framework OSINT