uAgents : des agents Python qui s'enregistrent sur la blockchain Fetch.ai

Le problème : un agent qui n'a pas d'adresse n'est joignable par personne

Un script Python qui tourne en boucle et journalise un message est facile à écrire. Le rendre joignable par un autre programme, sur une autre machine, sans annuaire central à maintenir, est une autre affaire. uAgents prend en charge cette partie : au démarrage, selon le README, chaque agent rejoint le réseau en s'enregistrant sur l'Almanac, présenté comme un contrat intelligent déployé sur la blockchain Fetch.ai. L'agent obtient ainsi une identité vérifiable et un point de rendez-vous. La cible est donc l'équipe qui construit un service logiciel autonome et veut que d'autres agents puissent le découvrir et lui parler, plutôt que de coder à la main un registre de services et une couche d'authentification. Le README insiste sur la sécurité des messages et des portefeuilles, décrits comme protégés cryptographiquement. C'est la promesse centrale du projet, et elle implique un coût : l'identité de votre agent n'est plus un détail d'implémentation, c'est une clé.

Ce que fait réellement le décorateur on_interval

Le README donne un exemple complet. On instancie un objet Agent avec un nom, on décore une fonction asynchrone avec on_interval(period=2.0), et la fonction est appelée toutes les deux secondes avec un objet Context en paramètre. Le Context porte au minimum ctx.agent.name et ctx.logger, tous deux utilisés dans l'exemple. Le lancement se fait par alice.run(), appelé sous la garde if __name__ == "__main__". Ce que la documentation du dépôt ne détaille pas dans le matériel fourni, c'est la boucle d'exécution sous-jacente : comment les intervalles sont ordonnancés, ce qui se passe si une tâche dépasse son intervalle, ou comment plusieurs handlers cohabitent. Le README mentionne aussi que l'agent peut agir sur des événements, mais l'exemple d'événement n'est pas fourni ici. Autrement dit, le chemin le plus documenté reste le minuteur. Pour un agent qui doit réagir à des messages entrants, il faudra consulter la page Communication des guides officiels, absente de ce que nous avons.

Identité : seed, private_keys.json et adresses instables

Trois cas distincts apparaissent dans le README, et le troisième est un piège classique. Si vous passez seed=os.getenv("ALICE_SEED_PHRASE"), l'adresse de l'agent est fixe et reproductible : c'est le mode à utiliser dès qu'un autre agent doit mémoriser votre adresse. Si vous instanciez Agent(name="alice") sans seed, la clé privée est stockée localement à côté du nom, dans private_keys.json. Si vous instanciez Agent() sans nom, le README précise qu'une nouvelle adresse est générée à chaque exécution. Ce dernier comportement rend l'agent inutilisable comme destinataire stable, ce qui est cohérent avec l'idée d'un agent éphémère, mais dangereux si on l'ignore. Le fichier private_keys.json mérite une attention particulière : il contient de quoi reconstituer l'identité de l'agent, et le README ne décrit ni son format exact ni les permissions recommandées. Un dépôt Git qui l'embarque par accident expose cette identité. Le README ne traite pas ce cas.

Installation et périmètre de compatibilité Python

L'installation tient en une commande : pip install uagents. Le README annonce la prise en charge de Python 3.10 à 3.13. Cette plage est étroite dans les deux sens : pas de 3.9, ce qui exclut certaines images de base encore répandues, et pas de 3.14, ce qui signifie qu'un environnement récent devra être épinglé. Le dépôt se divise en deux paquets visibles : la bibliothèque Python dans le dossier python, et uagents-core dans python/uagents-core, décrit comme contenant les définitions et fonctionnalités de base pour construire un logiciel de type agent capable de s'intégrer à l'écosystème Fetch.ai et à la place de marché d'agents. Les versions publiées confirment cette séparation : la release v0.25.5 du 20 août 2026 côtoie une étiquette core@0.4.9 du 6 août 2026. Les deux composants n'avancent donc pas au même rythme, et un projet qui dépend de uagents-core directement devra suivre ses propres versions. Le README ne dit pas si l'API de core est stable.

Le point de friction : une dépendance à une chaîne et à un opérateur

L'enregistrement sur l'Almanac est présenté comme automatique au démarrage. C'est pratique, et c'est aussi le principal argument contre le projet dans certains contextes. Un agent qui s'enregistre sur un contrat déployé sur la blockchain Fetch.ai dépend d'un réseau externe, de l'existence de ce contrat, et des conditions d'accès à ce réseau. Le README ne décrit ni les frais éventuels, ni le comportement en cas d'indisponibilité du réseau, ni s'il existe un mode purement local pour le développement. Ces questions ne sont pas traitées dans le matériel fourni, et je ne peux pas affirmer qu'elles ont une réponse dans la documentation complète. Si votre agent doit fonctionner dans un environnement sans accès sortant, ou si vous ne voulez pas qu'un tiers puisse observer son existence, ce mécanisme d'enregistrement est un obstacle, pas une fonctionnalité. Le README ne propose pas de variante hors ligne.

Face à un simple serveur HTTP et à une file de messages

L'alternative la plus directe pour un agent Python joignable reste un serveur HTTP ou gRPC avec une file de messages. La différence de conception est nette. Avec HTTP, vous définissez vous-même le schéma des messages, l'authentification, la découverte des pairs et la persistance. Vous héritez de toute la complexité, mais aussi de tout le contrôle, et vous ne dépendez d'aucune chaîne. uAgents déplace ces responsabilités vers le framework et vers l'Almanac : l'identité devient une paire de clés, la découverte passe par un registre on-chain, et les messages circulent entre agents identifiés. Le compromis est explicite. Si vos agents sont trois processus sur la même machine, l'écosystème Fetch.ai n'apporte rien et ajoute une dépendance externe. Si vos agents doivent être découverts par des inconnus et interagir avec d'autres acteurs du réseau, la bibliothèque évite de réinventer un annuaire. Le second cas est celui pour lequel le projet est conçu.

Maintenance, versions et licence Apache-2.0

Le dépôt n'est pas archivé et le dernier push est daté du 7 septembre 2026. Les publications sont rapprochées : v0.25.5 le 20 août 2026, v0.25.4 le 7 août 2026, core@0.4.9 le 6 août 2026. Ce rythme a deux conséquences pratiques. D'une part, la numérotation 0.x indique que l'API n'est pas déclarée stable, et un projet en production devra épingler une version exacte plutôt que suivre la branche principale. D'autre part, la séparation entre uagents et uagents-core signifie deux calendriers de mise à jour à surveiller, avec le risque qu'une montée de version de l'un impose une montée de version de l'autre. Le README ne documente pas de politique de compatibilité entre les deux. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence, ainsi qu'une clause de brevets. Le README inclut par ailleurs une clause de non-garantie explicite. Ce paragraphe n'est pas un conseil juridique : pour un usage en entreprise, faites relire la licence et cette clause.

Conclusion éditoriale

uAgents convient à ceux qui veulent un agent Python identifiable et joignable par d'autres agents via l'écosystème Fetch.ai, et qui acceptent qu'une clé privée soit le pivot de cette identité. Ceux qui cherchent une orchestration locale de LLM sans blockchain, ou qui ne veulent pas gérer de seed en production, devraient regarder ailleurs. Avant d'adopter, vérifiez deux points précis : le contenu de private_keys.json après un premier lancement, et ce que le paquet uagents-core expose réellement dans la version que vous installez.

Sources officielles

1. fetchai/uAgents on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases