Interrogez un chatbot sur une commande tardive et il vous donnera quelques conseils. Demandez à un agent IA, et il pourra consulter la commande, vérifier le retard, appliquer un bon et faire un rapport. La différence est qu’un agent peut entreprendre des actions et réagir à ce qui se passe, au lieu de produire une seule réponse.

Le terme étant étendu en marketing, ce guide s’en tient au fonctionnement réel de ces systèmes. Pour que cela soit concret, nous avons construit une petite boucle d’agent dans Python 3.13 et l’avons exécutée, et le résultat ci-dessous provient de ces exécutions. Notre « modèle » est une fonction scriptée, pas un véritable modèle d’IA, afin que la boucle puisse être exécutée et testée par n’importe qui. Cela montre la structure de contrôle, pas l’intelligence. Vous débutez avec les bases ? Lisez d’abord qu’est-ce qu’un grand modèle de langage.

Qu’est-ce qu’un agent IA ?

Il n’existe pas de définition unique convenue. Dans la pratique actuelle, un agent IA est un logiciel qui poursuit un objectif en décidant à plusieurs reprises quoi faire ensuite, en utilisant des outils pour agir sur le monde et en s’ajustant en fonction des résultats. Habituellement, la prise de décision provient d’un grand modèle de langage.

Pensez à la différence entre une personne qui donne des directions et une personne qui fait les courses. Le premier répond une fois. Le second part, trouve le magasin fermé, en essaie un autre et ne revient que lorsque le travail est terminé.

Chatbot, workflow ou agent ?

Ceux-ci existent sur un spectre, et de nombreux systèmes utiles sont un mélange. La question clé est de savoir quelle part du chemin est décidée au moment de l’exécution.

Qu’y a-t-il à l’intérieur d’un agent

La boucle des agents

1. Décider. Le modèle examine l’objectif et l’historique, et choisit une action ou décide qu’elle est terminée.
2. Act. Votre code exécute l’outil demandé.
3. Observer. Le résultat est ajouté à l’historique.
4. Répétez, jusqu’à ce que l’objectif soit atteint ou qu’une limite soit atteinte.

C’est le cœur de la plupart des agents. La sophistication réside principalement dans le modèle, les outils et les garde-fous autour de cette boucle.

Une boucle que vous pouvez exécuter

Notre petit agent gère les commandes retardées. Il dispose de deux outils, et l’un d’eux nécessite l’approbation humaine car cela coûte de l’argent :

ORDERS = {
    "A100": {"status": "delayed", "days_late": 6},
    "B200": {"status": "shipped", "days_late": 0},
}

def get_order(order_id):
    return ORDERS.get(order_id, {"error": "order not found"})

def issue_voucher(order_id, amount):
    return {"voucher": f"V-{order_id}", "amount": amount}

TOOLS = {"get_order": get_order, "issue_voucher": issue_voucher}
NEEDS_APPROVAL = {"issue_voucher"}

Et voici la boucle elle-même. Il s’agit d’un code ordinaire, et chaque règle de sécurité réside ici plutôt que dans le modèle :

def run_agent(goal, model, approve, max_steps=5):
    history = []
    for step in range(1, max_steps + 1):
        decision = model(goal, history)
        if "finish" in decision:
            return decision["finish"]

        name, args = decision["tool"], decision["args"]
        if name in NEEDS_APPROVAL and not approve(name, args):
            result = {"denied": True}
        else:
            result = TOOLS[name](**args)

        history.append({"tool": name, "result": result})
    return None   # stopped: step limit reached

Pour utiliser un modèle réel, vous remplaceriez la fonction model par un appel à une API LLM, en lui transmettant le but, l’historique et les descriptions de vos outils. La boucle reste presque la même.

Que s’est-il passé lors de nos courses

Nous avons essayé cinq situations avec la fonction de décision scriptée et enregistré chaque étape.

Une commande retardée, avec le bon approuvé

step 1: get_order({'order_id': 'A100'}) -> {'status': 'delayed', 'days_late': 6}
step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'voucher': 'V-A100', 'amount': 200}
step 3: finish -> Sorry for the delay. Voucher V-A100 issued.

Chaque étape utilisait le résultat de la précédente. Le bon n’a été pris en compte qu’une fois le retard confirmé.

La même ordonnance, avec approbation refusée

step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'denied': True}
step 3: finish -> Your order is late. A person will review compensation.

L’humain a dit non, l’outil n’a jamais fonctionné et l’agent a adapté sa réponse.

Une commande inconnue

step 1: get_order({'order_id': 'Z999'}) -> {'error': 'order not found'}
step 2: finish -> I could not find that order.

Donner aux outils des messages d’erreur clairs est utile. Un vrai modèle peut les lire et réagir de manière judicieuse, plutôt que de deviner.

Un modèle qui coince

Nous avons également remplacé une fonction de décision défectueuse qui répétait indéfiniment la même action :

step 1: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 2: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 3: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
stopped: step limit reached

Les agents peuvent vraiment tomber dans des boucles comme celle-ci, et chaque étape avec un modèle réel coûte de l’argent. Sans max_steps, celui-ci n’aurait jamais pris fin.

Comment fonctionnent les outils

C’est la partie la plus mal comprise. Un modèle de langage ne peut rien exécuter par lui-même. Il produit un texte structuré indiquant quel outil il souhaite, avec quels arguments. Votre code décide de l’exécuter ou non. C’est pourquoi la boucle est le bon endroit pour les autorisations, la validation et la journalisation.

Les fournisseurs de modèles proposent un outil ou une fonction nécessitant cela. Le Model Context Protocol (MCP) est un standard ouvert permettant de connecter des modèles à des outils et des données, et notre article sur Playwright MCP présente une utilisation. Écrivez des noms et des descriptions clairs des outils, car le modèle s’appuie sur eux pour choisir correctement.

Mémoire

Les tâches longues peuvent dépasser la fenêtre contextuelle d’un modèle, de sorte que les systèmes résument souvent les étapes plus anciennes. Les résumés peuvent perdre des détails, ce qui est l’une des raisons pour lesquelles les agents en activité depuis longtemps peuvent dévier de leur cap.

Systèmes multi-agents

Certains systèmes répartissent le travail entre plusieurs agents spécialisés, comme un planificateur, un chercheur et un évaluateur. Cela peut aider avec des tâches volumineuses qui sont clairement divisées. Cela ajoute également des coûts, davantage de possibilités d’échec et un débogage plus difficile. Essayez d’abord un seul agent doté de bons outils et divisez-le uniquement lorsqu’il y a une raison claire.

Risques et limites

• De mauvaises actions. L’erreur d’un chatbot est une mauvaise phrase. L’erreur d’un agent peut être un e-mail envoyé ou un enregistrement supprimé.
• Injection rapide. Une page Web ou un e-mail lu par l’agent peut contenir des instructions cachées. Traitez toutes les sorties de l’outil comme des données non fiables, et non comme des commandes.
• Erreurs cumulées. Une petite erreur au début peut envoyer chaque étape ultérieure dans la mauvaise direction.
• Coût et latence. Chaque étape peut être un autre appel de modèle, de sorte qu’une tâche peut être beaucoup plus lente et plus coûteuse qu’une seule invite.
• Incohérence. Le même objectif peut prendre un chemin différent à chaque exécution, ce qui rend les tests plus difficiles.
• Responsabilité. Les gens restent responsables de ce que fait le système, alors gardez des registres.

Des garde-corps qui comptent

1. Moins de privilèges. Donnez à chaque agent uniquement les outils et l’accès dont il a besoin.
2. Approbation humaine pour tout ce qui est coûteux, irréversible ou externe, comme le fait notre démo.
3. Limites strictes sur les étapes, le temps et les dépenses.
4. Validez les entrées de l’outil dans le code et ne vous fiez pas aux instructions du modèle.
5. Enregistrez chaque étape afin de comprendre pourquoi quelque chose s’est produit. Voir surveillance vs observabilité.
6. Testez avec des scénarios réels, y compris des échecs. Vérifiez les résultats finaux ainsi que les réponses individuelles. Notre guide des bonnes pratiques des agents IA va plus loin sur le déploiement.

Quand utiliser un agent

Les assistants de codage sont aujourd’hui l’un des exemples les plus aboutis, car ils peuvent lire des fichiers, exécuter des tests, détecter les échecs et réessayer, avec un humain examinant le résultat. Une suite de tests leur donne un signal clair de réussite. Notre guide sur l’ingénierie des invites s’applique également à la rédaction de bonnes instructions pour les agents. Commencez par la chose la plus simple qui puisse fonctionner, car un seul appel bien lancé bat souvent un agent compliqué.

Pour conclure

Un agent IA est moins mystérieux qu’il n’y paraît : un modèle, des outils et une boucle avec des limites. Le plus difficile, c’est la confiance, pas le code. Pour savoir comment ils se comportent, prenez notre petite boucle, connectez-la à un modèle réel avec des outils en lecture seule et observez les journaux pendant son fonctionnement. Vous verrez bientôt où il brille et où il a besoin d’un humain.

Questions fréquentes

Continuez à apprendre