La question
Automatiser, c'est facile tant que rien ne tombe. Le jour où le process meurt au milieu d'un run — après l'étape 3, avant l'étape 4 — tout se joue : reprend-on à zéro (effets de bord rejoués) ou exactement où on s'était arrêté ? Les solutions classiques imposent une VM de replay et sa taxe de complexité. On cherchait plus simple.
Où on en est
Une automatisation est un graphe JSON déclaratif : un déclencheur, un filtre optionnel, des étapes ordonnées. Le déclaratif rend le rejeu gratuit — pas de VM à rembobiner. Un run tué reprend depuis sa dernière étape complétée ; retries avec backoff ; file de morts (dead-letter) ; versions épinglées, pour qu'un replay rejoue la logique de son époque tout en gardant l'autorité actuelle.
Trois réutilisations fondatrices, plutôt que de réinventer : les actions = les outils du Lab (filtrés par le propriétaire, comme à l'axe 01) ; les déclencheurs = les événements de monitoring ; l'exécution = la file durable. Et des étapes humaines : une automatisation peut se mettre en pause sur une approbation ou attendre un événement.
Ce qui reste ouvert
Décrire une automatisation en langage naturel. Les connecteurs externes. Et brancher davantage de modules comme sources d'événements — pour que le système finisse par réagir à lui-même.