Qu'est-ce que Strands Agents ? Le SDK d'agents open source piloté par modèle d'AWS

Si vous avez déjà construit un agent IA avec une grande chaîne if/else, vous savez que cette approche devient vite fragile. Strands Agents propose un modèle plus simple : laisser le LLM planifier, pendant que vous fournissez une invite système et une liste d’outils. C’est un SDK open source d’AWS, publié en mai 2025 sous la licence Apache 2.0, déjà utilisé dans des contextes de production comme Amazon Q Developer et AWS Glue.

Essayez Apidog aujourd’hui

Ce qu’est réellement Strands Agents

Strands Agents est un SDK pour construire des agents IA avec trois éléments :

1. un modèle ;
2. une invite système ;
3. une liste d’outils.

Le modèle lit l’invite, choisit les outils à appeler, analyse les résultats, puis continue jusqu’à ce que la tâche soit terminée. Vous n’écrivez pas toute la logique de contrôle à la main : vous exposez les capacités, et le modèle orchestre les étapes.

Strands est disponible pour Python et TypeScript. Le nom fait référence aux deux “brins” qui composent un agent : le modèle et les outils. AWS l’a rendu open source après l’avoir utilisé en interne, ce qui explique son orientation production plutôt que démonstration.

Depuis son lancement en prévisualisation, le SDK a dépassé les 150 000 téléchargements sur PyPI et a atteint une version 1.0 avec des primitives multi-agents et la prise en charge du protocole Agent-to-Agent, ou A2A.

Si vous connaissez déjà LangGraph ou Google ADK, Strands se place dans la même famille, mais avec une différence importante : le flux de contrôle est davantage piloté par le modèle que par un graphe que vous devez définir explicitement.

Modèle piloté par le LLM vs orchestration codée en dur

Dans beaucoup de frameworks d’agents, vous définissez à l’avance :

• des nœuds ;
• des arêtes ;
• des conditions ;
• du routage ;
• des chemins d’erreur.

Cela fonctionne bien pour les workflows déterministes, mais chaque nouvelle capacité ajoute du graphe à maintenir.

Avec Strands, vous décrivez l’objectif et vous donnez au modèle les outils disponibles. Le modèle décide ensuite de la séquence d’actions.

Approche	Vous définissez	Le flux de contrôle réside dans	Coût d’une nouvelle capacité
Orchestration codée en dur	Nœuds, arêtes, conditions, routage	Votre code de graphe	Modifier le graphe et retester les chemins
Axée sur le modèle avec Strands	Invite + liste d’outils	La boucle de raisonnement du modèle	Ajouter un outil et ajuster l’invite

Le compromis est clair : Strands accélère la construction et l’évolution d’un agent, mais réduit le déterminisme. Pour un workflow qui doit suivre exactement le même chemin à chaque exécution, vous pouvez ajouter de la structure avec des hooks ou une architecture multi-agents. Mais vous n’êtes pas obligé de commencer par un graphe.

Créer un agent Strands minimal

Un agent Strands utile peut tenir en quelques lignes.

from strands import Agent, tool

@tool
def word_count(text: str) -> int:
    """Compte les mots dans un bloc de texte."""
    return len(text.split())

agent = Agent(
    system_prompt="Vous êtes un assistant de rédaction concis.",
    tools=[word_count],
)

response = agent("Combien de mots y a-t-il dans cette phrase ?")
print(response)

Ce code fait trois choses :

1. @tool expose une fonction Python au modèle.
2. La docstring décrit l’outil.
3. Les annotations de type définissent le schéma d’entrée.

Vous n’avez pas besoin d’un registre séparé. Quand vous appelez agent(...), Strands exécute la boucle agentique : le modèle raisonne, sélectionne éventuellement un outil, lit le résultat, puis produit une réponse finale.

Ajouter des outils à un agent

Un outil Strands peut être :

• une fonction Python locale ;
• un outil packagé par la communauté ;
• un outil exposé par un serveur MCP ;
• une API interne encapsulée dans une fonction @tool.

Exemple avec un outil qui appelle une API HTTP :

import requests
from strands import Agent, tool

@tool
def get_issue_status(issue_id: str) -> dict:
    """Retourne le statut d'un ticket interne à partir de son identifiant."""
    response = requests.get(
        f"https://api.example.com/issues/{issue_id}",
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

agent = Agent(
    system_prompt=(
        "Vous êtes un assistant support. "
        "Utilisez les outils disponibles pour vérifier les informations avant de répondre."
    ),
    tools=[get_issue_status],
)

print(agent("Quel est le statut du ticket INC-1042 ?"))

Ce modèle est pratique, mais il rend la qualité de vos API critiques. Si get_issue_status retourne un JSON incohérent, un code HTTP inattendu ou une erreur non gérée, l’agent peut produire une mauvaise réponse même si le modèle fonctionne correctement.

Choisir un fournisseur de modèle

Par défaut, Strands utilise Amazon Bedrock. Dès l’installation, un agent utilise un modèle Claude Sonnet dans la région us-west-2. L’identifiant exact du modèle par défaut a changé selon les versions du SDK : vérifiez donc votre version installée au lieu de coder cette valeur en dur.

Strands peut aussi être dirigé vers d’autres fournisseurs :

• les modèles Amazon Bedrock compatibles avec l’utilisation d’outils et le streaming ;
• Claude via l’API Anthropic ;
• les modèles Llama via l’API Llama ;
• Ollama pour le développement local ;
• d’autres fournisseurs, comme OpenAI, via LiteLLM.

L’intérêt est que vous changez l’objet modèle, pas toute l’architecture de l’agent. Vos outils et votre invite restent stables.

Un flux courant consiste à :

1. développer localement avec Ollama ;
2. tester les outils avec des mocks ;
3. valider les appels réels en staging ;
4. déployer sur Bedrock ou un autre fournisseur managé.

Utiliser MCP avec Strands

Le Model Context Protocol, ou MCP, est un standard ouvert pour connecter des modèles à des outils et à des sources de données.

Avec Strands, vous pouvez connecter un agent à des serveurs MCP existants et transmettre leurs outils à l’agent comme n’importe quelle autre liste d’outils.

C’est utile si vous avez déjà des intégrations MCP pour :

• des bases de données ;
• des systèmes de fichiers ;
• des dépôts Git ;
• des outils internes ;
• des services SaaS ;
• des API métier.

L’avantage est que vous évitez d’écrire du code d’intégration spécifique pour chaque service. L’inconvénient est que votre agent dépend directement du comportement de ces serveurs MCP. Vous devez donc tester les points d’accès sous-jacents, pas seulement l’agent final.

Construire une architecture multi-agents

Un seul agent suffit pour beaucoup de cas d’usage, mais certains systèmes gagnent à être découpés en plusieurs agents spécialisés.

Strands 1.0 ajoute des primitives multi-agents, notamment :

• le modèle Agent-as-Tool, où un agent appelle un autre agent comme un outil ;
• des mécanismes de coordination de type Swarm ;
• la prise en charge du protocole A2A, pour communiquer avec des agents construits sur d’autres frameworks.

Un découpage simple peut ressembler à ceci :

Agent principal
├── Agent recherche documentaire
├── Agent analyse API
└── Agent rédaction réponse

Dans ce modèle, l’agent principal ne fait pas tout lui-même. Il délègue certaines tâches à des agents spécialisés, puis synthétise le résultat.

Utilisez cette approche si :

• les tâches sont clairement séparables ;
• chaque sous-agent a ses propres outils ;
• vous voulez isoler les responsabilités ;
• vous devez faire évoluer certaines capacités sans modifier tout l’agent.

Déployer un agent Strands

Strands est un programme Python ou TypeScript classique. Vous pouvez donc le packager comme n’importe quel autre service.

Cibles de déploiement possibles :

• Amazon Bedrock AgentCore pour un runtime d’agent managé ;
• AWS Lambda pour des agents courts et déclenchés par événement ;
• AWS Fargate ou Amazon EKS pour des services conteneurisés ;
• Docker sur toute infrastructure capable d’exécuter un conteneur.

Un chemin de déploiement pragmatique :

1. créer l’agent localement ;
2. écrire ou connecter les outils ;
3. tester les réponses des API utilisées par les outils ;
4. ajouter les variables d’environnement ;
5. conteneuriser l’application ;
6. déployer sur Lambda, Fargate, EKS ou AgentCore ;
7. tracer les appels modèle et les appels outils en production.

AWS documente aussi des hooks d’observabilité pour comprendre quelles décisions le modèle a prises et quels outils ont été appelés.

Où Apidog s’insère dans le workflow

Strands construit et exécute l’agent. Il ne valide pas automatiquement les API que votre agent appelle.

Or un agent Strands dépend généralement de deux types d’API HTTP :

1. l’API du fournisseur LLM ;
2. les API appelées par vos outils @tool ou vos serveurs MCP.

Si ces API échouent, retournent un schéma incorrect ou changent de comportement, le problème peut ressembler à une erreur de raisonnement du modèle alors qu’il s’agit d’un problème d’intégration.

Apidog sert d’établi pour tester, simuler et documenter ces API avant que l’agent ne les utilise.

Cas d’usage concrets :

• Simuler le modèle ou un endpoint d’outil pendant le développement, pour éviter de consommer des tokens ou d’atteindre les limites de débit. Le guide sur la construction d’un harnais de test d’agent IA avec Apidog montre ce pattern.
• Valider les formes de réponse afin de détecter un JSON mal formé ou un champ manquant avant la production. Consultez le guide des assertions API.
• Créer une API factice pour reproduire les réponses d’un service réel, y compris les erreurs que votre agent doit gérer.
• Gérer les clés API par environnement pour séparer développement, staging et production sans stocker les secrets dans le code.

Apidog n’est pas un framework d’agent et ne remplace pas Strands. Strands reste responsable de la boucle agentique. Apidog vous aide à fiabiliser la plomberie API que l’agent utilise.

Vous pouvez télécharger Apidog et créer rapidement des mocks pour vos endpoints d’outils.

Tester un outil avant de le donner à l’agent

Avant d’ajouter un outil à tools=[...], testez-le comme une dépendance normale.

Checklist minimale :

• le code HTTP attendu est-il bien retourné ?
• le schéma JSON est-il stable ?
• les champs obligatoires sont-ils présents ?
• les erreurs 4xx et 5xx sont-elles gérées ?
• les timeouts sont-ils configurés ?
• les secrets sont-ils chargés depuis l’environnement ?
• les réponses de staging et production sont-elles cohérentes ?

Exemple de garde-fou côté outil :

import requests
from strands import tool

@tool
def get_customer_plan(customer_id: str) -> dict:
    """Retourne le plan d'abonnement d'un client."""
    try:
        response = requests.get(
            f"https://api.example.com/customers/{customer_id}/plan",
            timeout=5,
        )
        response.raise_for_status()
        data = response.json()

        if "plan" not in data or "status" not in data:
            raise ValueError("Réponse API invalide : champs manquants")

        return data

    except requests.Timeout:
        return {"error": "timeout"}
    except requests.HTTPError as exc:
        return {"error": "http_error", "status_code": exc.response.status_code}
    except Exception as exc:
        return {"error": "unexpected_error", "message": str(exc)}

Ce type de validation évite de transmettre au modèle une réponse ambiguë ou inutilisable.

Quand utiliser Strands Agents

Strands est un bon choix si :

• vous voulez construire rapidement un agent ;
• vous acceptez que le modèle planifie les étapes ;
• vous êtes déjà sur AWS ou Bedrock ;
• vous voulez commencer avec un agent simple puis évoluer vers du multi-agent ;
• vous voulez utiliser des outils MCP sans écrire beaucoup de code d’intégration.

Il est moins adapté si :

• chaque branche du workflow doit être prédéfinie ;
• vous avez besoin d’une exécution strictement déterministe ;
• l’audit du chemin exact est plus important que la flexibilité ;
• votre logique métier ressemble déjà à un graphe explicite.

Dans ces cas, un framework orienté graphe peut être plus direct. Les deux approches ne s’excluent pas : elles répondent à des contraintes différentes.

Questions fréquentes

Strands Agents est-il gratuit et open source ?

Oui. Strands Agents est open source sous licence Apache 2.0, avec le code source disponible sur GitHub. Le SDK n’a pas de coût de licence. Vous payez en revanche les modèles et les ressources cloud utilisées, comme l’inférence Bedrock, Lambda ou les services conteneurisés.

Dois-je utiliser Amazon Bedrock avec Strands ?

Non. Bedrock est le fournisseur par défaut, mais Strands prend aussi en charge l’API Anthropic, l’API Llama, Ollama pour les exécutions locales et d’autres fournisseurs via LiteLLM. Vous changez l’objet modèle sans réécrire vos outils ni votre invite.

Quelle est la différence entre Strands et un framework basé sur des graphes ?

Strands est piloté par le modèle : vous fournissez une invite et des outils, puis le modèle décide des étapes. Un framework basé sur des graphes vous demande de définir le flux de contrôle avec des nœuds et des arêtes. Strands favorise la rapidité et l’adaptabilité. Les graphes favorisent la prédictibilité.

Comment tester les API dont dépend mon agent Strands ?

Testez-les séparément de l’agent. Simulez les endpoints, validez les schémas de réponse et exécutez ces contrôles en CI. Un outil comme Apidog permet de gérer les mocks et les assertions. Le guide sur le test de l’API ChatGPT avec Apidog couvre aussi l’authentification, le streaming et les appels d’outils.

Conclusion

Strands Agents propose une manière directe de construire des agents IA : définissez un modèle, une invite et des outils, puis laissez le modèle exécuter la boucle. Le SDK prend en charge les agents simples, les architectures multi-agents, MCP, A2A et plusieurs cibles de déploiement AWS.

La partie critique reste l’intégration. Vos outils appellent des API, et ces API doivent être fiables. Testez-les, simulez-les et validez leurs réponses avant de les connecter à l’agent. Strands gère le raisonnement ; Apidog vous aide à fiabiliser les endpoints que ce raisonnement utilise.