Présentation
Agent Resilience regroupe un circuit breaker, une file de messages en échec adossée à Redis et un tampon MQTT hors ligne pour des agents et services qui ne peuvent pas supposer que chaque dépendance reste disponible.
Rôle et périmètre
J’ai conçu les interfaces du package, réalisé les modes de panne, écrit les tests et exemples d’utilisation, configuré le packaging et la CI, puis publié la version v0.1.0.
Problème et contraintes
Les agents distribués ont besoin d’un comportement prévisible lorsqu’une API échoue à répétition, qu’un broker est hors ligne ou qu’un message ne peut pas être traité immédiatement.
Architecture
Les composants restent indépendants et composables. Le circuit breaker contrôle les appels répétés, la file de messages en échec conserve le travail dans Redis et le tampon MQTT stocke les messages sortants jusqu’au retour de la connexion.
Choix et compromis
Le package privilégie des états explicites et de petites surfaces d’intégration. Il fournit des composants plutôt que d’imposer un framework d’agents ou de masquer la reprise derrière un état global du processus.
Contexte de sécurité
Ce projet démontre une ingénierie de fiabilité pour l’infrastructure d’agents. Il n’est pas présenté comme un audit de sécurité ni comme la preuve qu’une application intégrée est sécurisée.
Tests et vérification
La version publique comprend des tests automatisés, la construction du package et une CI couvrant les versions de Python prises en charge.
Résultats publics
La version v0.1.0 est publiée avec une installation documentée et des exemples pour chaque composant de résilience.
Ressources et liens
Le dépôt source, la release, les métadonnées du package, les tests et la configuration de CI sont publics.
Périmètre et état actuel
Il s’agit de composants d’intégration, pas d’une plateforme d’agents complète. Les utilisateurs en production doivent choisir les politiques de persistance, de nouvelle tentative, de supervision et d’exploitation adaptées à leur environnement.