Strands et IoT : trois architectures pour trois usages

Un agent IoT construit avec Strands Agents peut surveiller des capteurs, traiter des tâches sur un appareil local ou coordonner des robots en réseau. Strands Agents est un kit open source pour Python qui permet de créer des agents d’IA capables d’utiliser des outils. Le choix de l’architecture détermine quelles tâches fonctionnent sans connexion au cloud.

AAIF répartit le travail entre modèles locaux et cloud

Dans l’Adaptive Agentic Intelligence Framework (AAIF), AWS décrit trois niveaux : l’orchestration locale, le traitement local et l’analyse dans le cloud avec Amazon Bedrock. L’orchestration consiste à choisir quel outil ou modèle exécutera une tâche. Le petit modèle de langage (SLM) llama3.2:1b joue ce rôle dans l’exemple ; llama3.2-vision analyse localement des images, tandis qu’un outil d’analyse spécialisée peut envoyer une demande à Bedrock.

La télémétrie de cette démonstration ne vient pas de capteurs réels. La fonction get_device_telemetry choisit un appareil dans un dictionnaire Python de valeurs simulées. Pour suivre l’exemple, AWS indique notamment Python 3.10 ou plus, Ollama, Strands Agents, Boto3 et des identifiants AWS donnant accès à Bedrock. AWS précise aussi que les appels aux modèles Bedrock entraînent des frais par requête.

AWS décrit deux autres options : une configuration entièrement cloud, où Bedrock exécute l’inférence, et une configuration entièrement locale, où llama3.2:3b traite aussi des tâches plus complexes. Cette dernière réduit la profondeur de raisonnement sur les requêtes les plus difficiles. Le code Bedrock de l’exemple AAIF ne s’exécute pas tel quel : l’identifiant du modèle est un espace réservé et les commentaires // ne sont pas une syntaxe valide en Python.

Greengrass fait fonctionner les capteurs au plus près de l’appareil

Dans son exemple agricole, AWS place un agent Strands et un tableau de bord dans des composants AWS IoT Greengrass sur un Raspberry Pi 5. Le montage décrit utilise Raspberry Pi OS 64 bits, Python 3.9 ou plus, un capteur numérique d’humidité du sol sur la broche GPIO 17 et un module caméra v2 ou v3. GPIO désigne les broches d’entrée et de sortie qui relient le Pi à des composants électroniques.

Les échanges entre l’agent et le tableau de bord passent par MQTT, un protocole de messagerie léger pour les appareils connectés. L’exemple utilise les sujets gg/monitor/request et gg/monitor/response. Le tableau de bord garde la main sur la caméra et expose les instantanés via localhost:8080/snapshot, ce qui évite que les deux composants tentent de contrôler la caméra en même temps.

AWS indique que les lectures du capteur et les vérifications de l’état de l’appareil continuent sans accès au cloud. L’analyse des images de plantes, qui dépend d’Amazon Bedrock, nécessite une connexion. La différence est concrète : une coupure réseau n’empêche pas les contrôles locaux, mais suspend l’analyse d’image confiée au service cloud.

Strands Robots coordonne des appareils en réseau

Strands Robots vise une autre tâche : faire découvrir des robots ou des appareils connectés entre eux et coordonner leurs actions. Le projet décrit Zenoh comme transport par défaut pour les échanges entre pairs sur un réseau local, et AWS IoT Core pour les flottes réparties entre plusieurs réseaux ou gérées depuis le cloud.

L’exemple de robot utilise un bras Universal Robots UR10e simulé dans MuJoCo. Cette simulation ne requiert ni GPU ni robot physique. Pour les interactions avec le matériel, le projet décrit le Model Hardware Standard (MHS), une interface fondée sur des opérations de lecture et d’écriture, avec limites déclarées, interverrouillages et arrêts d’urgence. L’intégration MHS dans Strands Robots est présentée comme une préversion de recherche limitée, et non comme une fonction de production généralement disponible.

Choisir selon la tâche et la connexion