Créer des plugins d’agent : un guide pratique de démarrage rapide

Introduction : La puissance des plugins d’agent

Dans le domaine en évolution rapide de l’intelligence artificielle, les modèles de langage large (LLMs) deviennent de plus en plus sophistiqués. Cependant, même les LLMs les plus avancés ont des limitations inhérentes : ils fonctionnent sur leurs données d’entraînement, manquent d’accès à des informations en temps réel et ne peuvent pas interagir directement avec des systèmes externes ou effectuer des actions spécifiques. C’est là que les plugins d’agent entrent en jeu. Les plugins d’agent permettent aux LLMs d’étendre leurs capacités, agissant comme des ponts vers le monde extérieur. Ils permettent à un agent IA d’effectuer des tâches pour lesquelles il n’a pas été explicitement formé, d’accéder à des données propriétaires, d’interagir avec des API et d’exécuter des actions dans le monde réel.

Pensez à un LLM comme à un esprit brillant avec une vaste connaissance mais sans mains ni yeux au-delà de ses données internes. Un plugin lui donne ces mains et ces yeux. Il transforme une IA conversationnelle en une IA actionnable, capable non seulement de comprendre mais aussi de faire. Dans cet article, nous explorerons les aspects pratiques de la création de plugins d’agent, en nous concentrant sur une approche de démarrage rapide avec des exemples concrets pour vous aider à démarrer.

Comprendre le concept de base : LLM, agent et plugin

Avant de commencer à coder, consolidons notre compréhension des composants clés :

• Modèle de langage large (LLM) : L’IA fondamentale qui comprend et génère le langage humain. C’est le cerveau de notre agent. Exemples : GPT-4, Claude, Llama 2.
• Agent : Une entité intelligente qui utilise un LLM pour raisonner, planifier et exécuter des tâches. Le rôle de l’agent est de décider quand et comment utiliser les outils disponibles (plugins) pour atteindre l’objectif d’un utilisateur. Cela implique souvent une boucle de réflexion et de raisonnement.
• Plugin (ou outil/fonction) : Un morceau de code que l’agent peut appeler pour effectuer une action spécifique ou récupérer une information précise. Chaque plugin a un objectif bien défini, des paramètres d’entrée et une sortie attendue.

Le flux d’interaction se déroule généralement comme suit : L’utilisateur pose une question → L’agent interprète la demande → L’agent décide si un plugin est nécessaire → L’agent appelle le plugin avec les paramètres appropriés → Le plugin s’exécute et renvoie les résultats → L’agent traite les résultats et répond à l’utilisateur.

L’anatomie d’un plugin d’agent

Bien que des frameworks et des plateformes spécifiques puissent avoir leurs propres conventions, les composants fondamentaux d’un plugin d’agent sont remarquablement similaires :

1. Nom : Un identifiant unique et descriptif pour le plugin (par exemple, getCurrentWeather, searchWikipedia, sendEmail).
2. Description : Une explication claire et concise de ce que fait le plugin et quand il doit être utilisé. Cela est crucial pour que le LLM comprenne son objectif et décide s’il doit l’invoquer.
3. Paramètres (Schéma) : Une définition des entrées que le plugin attend. Cela est souvent décrit à l’aide d’un schéma JSON, spécifiant les noms des paramètres, les types, les descriptions et s’ils sont requis.
4. Mise en œuvre (Code) : Le code réel qui exécute l’action désirée lorsque le plugin est invoqué. Cela pourrait être l’appel à une API externe, l’interrogation d’une base de données, l’exécution d’un calcul local ou l’interaction avec une interface utilisateur.
5. Sortie : Les données renvoyées par le plugin après exécution.

Démarrage rapide : création d’un simple plugin météo

Explorons un exemple pratique. Nous allons créer un plugin qui récupère la météo actuelle d’une ville donnée. Pour simplifier, nous allons utiliser une API fictive, mais les principes s’appliquent directement aux API réelles.

Étape 1 : Définir le but et l’interface du plugin

Nom : get_current_weather
Description : « Récupère les conditions météorologiques actuelles pour une ville spécifiée. Utile pour répondre à des questions sur la température, l’humidité et l’état général de la météo dans un endroit précis. »
Paramètres : Nous avons besoin de la city. Supposons qu’il s’agisse d’une chaîne et qu’elle soit requise.

Étape 2 : Mettre en œuvre la fonction du plugin

Nous utiliserons Python pour nos exemples, car il est largement adopté dans la communauté IA. Vous pouvez utiliser n’importe quel langage, mais les concepts restent les mêmes.

import json

def get_current_weather(city: str) -> dict:
 """
 Récupère les conditions météorologiques actuelles pour une ville spécifiée.
 
 Args:
 city (str): Le nom de la ville pour obtenir la météo.
 
 Returns:
 dict: Un dictionnaire contenant des informations météorologiques (par exemple, température, conditions, humidité).
 """
 # Dans un scénario réel, vous feriez ici un appel API,
 # par exemple, en utilisant requests.get('https://api.weatherapi.com/v1/current.json?key=YOUR_KEY&q={city}')
 
 # Pour cet exemple, nous renverrons des données fictives
 mock_weather_data = {
 "London": {"temperature": 15, "conditions": "Nuageux", "humidity": 80},
 "New York": {"temperature": 22, "conditions": "Ensoleillé", "humidity": 60},
 "Tokyo": {"temperature": 28, "conditions": "Pluvieux", "humidity": 90},
 "Paris": {"temperature": 18, "conditions": "Partiellement nuageux", "humidity": 70},
 }
 
 weather = mock_weather_data.get(city, {"temperature": "N/A", "conditions": "Inconnu", "humidity": "N/A"})
 
 return {"city": city, **weather}

Étape 3 : Décrire le plugin pour le LLM (Schéma d’appel de fonction)

C’est sans doute l’étape la plus critique. Le LLM n’exécute pas directement le code Python ; il a besoin d’une description structurée du plugin afin de générer l’appel de fonction correct. La plupart des fournisseurs de LLM (OpenAI, Google, Anthropic, etc.) proposent une capacité de « appel de fonction » ou « utilisation d’outil », où vous fournissez un schéma JSON décrivant vos fonctions. Voici comment notre plugin météo serait décrit :

{
 "type": "function",
 "function": {
 "name": "get_current_weather",
 "description": "Récupère les conditions météorologiques actuelles pour une ville spécifiée. Utile pour répondre à des questions sur la température, l'humidité et l'état général de la météo dans un endroit précis.",
 "parameters": {
 "type": "object",
 "properties": {
 "city": {
 "type": "string",
 "description": "Le nom de la ville (par exemple, Londres, New York, Tokyo)"
 }
 },
 "required": ["city"]
 }
 }
}

Éléments clés dans le schéma :

• type: "function" : Indique qu’il s’agit d’une définition de fonction.
• function.name : Correspond exactement à notre nom de fonction Python.
• function.description : C’est ce que le LLM lit ! Soyez clair et détaillé. Incluez des cas d’utilisation et des exemples si cela est utile.
• function.parameters : Un objet JSON Schema standard définissant les entrées.
• properties : Définit chaque paramètre (city dans notre cas).
• required : Liste des paramètres qui doivent être fournis.

Intégration avec un LLM (Exemple OpenAI)

Maintenant, voyons comment un agent LLM utiliserait ce plugin. Nous allons utiliser l’API d’appel de fonction d’OpenAI comme exemple, mais les concepts sont transférables à d’autres fournisseurs.

import openai
import os

# Supposons que OPENAI_API_KEY soit défini dans vos variables d'environnement
# openai.api_key = os.getenv("OPENAI_API_KEY") 

# Notre schéma d'outil défini
tools = [
 {
 "type": "function",
 "function": {
 "name": "get_current_weather",
 "description": "Obtient les conditions météorologiques actuelles pour une ville spécifiée. Utile pour répondre aux questions concernant la température, l'humidité et les prévisions météorologiques générales dans un lieu spécifique.",
 "parameters": {
 "type": "object",
 "properties": {
 "city": {
 "type": "string",
 "description": "Le nom de la ville (par exemple, Londres, New York, Tokyo)"
 }
 },
 "required": ["city"]
 }
 }
 }
]

# La fonction Python réelle que nous avons définie plus tôt
def get_current_weather(city: str) -> dict:
 # ... (même implémentation que ci-dessus) ...
 mock_weather_data = {
 "London": {"temperature": 15, "conditions": "Nuageux", "humidity": 80},
 "New York": {"temperature": 22, "conditions": "Ensoleillé", "humidity": 60},
 "Tokyo": {"temperature": 28, "conditions": "Pluvieux", "humidity": 90},
 "Paris": {"temperature": 18, "conditions": "Partiellement nuageux", "humidity": 70},
 }
 weather = mock_weather_data.get(city, {"temperature": "N/A", "conditions": "Inconnu", "humidity": "N/A"})
 return {"city": city, **weather}

# Une simple boucle d'agent
def run_agent_with_tools(user_query: str):
 messages = [{
 "role": "user", 
 "content": user_query
 }]

 # Premier appel au LLM avec la requête de l'utilisateur et les outils disponibles
 response = openai.chat.completions.create(
 model="gpt-4o", # Ou gpt-3.5-turbo, etc.
 messages=messages,
 tools=tools,
 tool_choice="auto" # Permet au LLM de décider s'il veut appeler un outil
 )

 response_message = response.choices[0].message
 messages.append(response_message)

 # Vérifiez si le LLM a décidé d'appeler un outil
 if response_message.tool_calls:
 for tool_call in response_message.tool_calls:
 function_name = tool_call.function.name
 function_args = json.loads(tool_call.function.arguments)
 
 if function_name == "get_current_weather":
 # Exécutez l'outil et obtenez le résultat
 tool_output = get_current_weather(city=function_args.get("city"))
 
 # Ajoutez la sortie de l'outil à l'historique de conversation
 messages.append({
 "tool_call_id": tool_call.id,
 "role": "tool",
 "name": function_name,
 "content": json.dumps(tool_output)
 })
 
 # Deuxième appel au LLM avec la sortie de l'outil
 final_response = openai.chat.completions.create(
 model="gpt-4o",
 messages=messages
 )
 print(final_response.choices[0].message.content)
 else:
 print(f"Erreur : Outil inconnu appelé : {function_name}")
 else:
 # Pas d'appel d'outil, juste une réponse directe du LLM
 print(response_message.content)

# Cas de test
print("--- Requête 1 : Météo à Londres ---")
run_agent_with_tools("Quel temps fait-il à Londres ?")

print("\n--- Requête 2 : Météo à New York ---")
run_agent_with_tools("Dites-moi la température actuelle à New York.")

print("\n--- Requête 3 : Question générale ---")
run_agent_with_tools("Quelle est la capitale de la France ?")

print("\n--- Requête 4 : Météo dans une ville inconnue ---")
run_agent_with_tools("Quel temps fait-il à Atlantis ?")

Explication de la boucle d’agent :

1. Requête de l’utilisateur : L’utilisateur pose une question (par exemple, « Quel temps fait-il à Londres ? »).
2. Premier appel LLM : La requête de l’utilisateur et la liste des outils disponibles (notre get_current_weather schéma) sont envoyés au LLM. Le LLM analyse la requête et les descriptions des outils.
3. Décision du LLM : Le LLM, en fonction de sa compréhension, décide s’il doit appeler un outil.
• S’il décide d’appeler un outil, il générera un objet tool_calls spécifiant le nom de l’outil et les paramètres qu’il souhaite passer (par exemple, {"name": "get_current_weather", "arguments": {"city": "London"}}).
• S’il n’y a pas d’outil pertinent, il générera une réponse textuelle directe.
4. Exécution de l’outil : Si le LLM génère un appel d’outil, notre code d’agent intercepte cela, extrait le nom de la fonction et les arguments, puis exécute la fonction Python réelle (get_current_weather("London")).
5. Deuxième appel LLM (avec sortie de l’outil) : Le résultat de l’exécution de l’outil est ensuite envoyé de nouveau au LLM, avec l’intégralité de l’historique de conversation. Le LLM a maintenant la requête originale de l’utilisateur, sa propre décision d’appeler un outil et le résultat concret de cet outil.
6. Réponse finale : Le LLM utilise ces informations pour formuler une réponse en langage naturel à l’utilisateur, intégrant la sortie de l’outil.

Concepts avancés des plugins et meilleures pratiques

Gestion des erreurs et solidité

Les API du monde réel échouent. Vos plugins doivent gérer les erreurs avec aisance (problèmes de réseau, entrées invalides, limites de taux d’API, etc.). Retournez des messages d’erreur informatifs depuis votre plugin, et le LLM peut souvent les utiliser pour informer l’utilisateur ou même tenter une nouvelle tentative avec des paramètres corrigés.

def get_current_weather_solid(city: str) -> dict:
 try:
 # Simuler un appel API avec des erreurs potentielles
 if city == "Error City":
 raise ValueError("L'appel API a échoué pour Error City : Service non disponible.")
 # ... reste de la logique de données mock réussie ...
 return {"city": city, **weather}
 except Exception as e:
 return {"error": str(e), "city": city}

Multiples plugins et orchestration d’outils

Le véritable pouvoir d’un agent réside dans l’utilisation de plusieurs plugins. Imaginez un agent « planificateur de voyages » avec des plugins pour :

• search_flights(origin, destination, date)
• book_hotel(city, check_in, check_out)
• get_attractions(city)

Le LLM, par son raisonnement, peut enchaîner ces outils. Par exemple, si un utilisateur demande, « Planifiez un voyage à Paris le mois prochain et trouvez des choses à faire », le LLM pourrait d’abord appeler search_flights, puis book_hotel (si confirmé par l’utilisateur), et enfin get_attractions.

Lors de la fourniture de plusieurs outils, il suffit d’ajouter plus de schémas JSON à la liste tools dans votre appel LLM.

Raisonnement et réflexion des agents

Les agents sophistiqués n’exécutent pas simplement des outils ; ils raisonnent sur leurs actions. Des frameworks comme LangChain et LlamaIndex fournissent des abstractions pour cela, impliquant souvent :

• Planification : Décomposer des objectifs complexes en sous-tâches.
• Sélection des outils : Choisir l’outil le plus approprié pour chaque sous-tâche.
• Génération de paramètres : Extraire les arguments nécessaires à partir du contexte de conversation.
• Exécution : Exécuter l’outil.
• Observation : Interpréter la sortie de l’outil.
• Réflexion : Évaluer si l’objectif a été atteint ou si d’autres actions/corrections sont nécessaires.

La description de votre plugin par le LLM est centrale à ce raisonnement. Une description vague conduit à une sélection d’outils médiocre.

Considérations de sécurité

• Validation des entrées : Validez toujours les entrées reçues par votre plugin, même si le LLM les a générées. Des entrées malveillantes ou inattendues peuvent entraîner des vulnérabilités.
• Moindre privilège : Assurez-vous que votre plugin n’a accès qu’aux ressources dont il a absolument besoin.
• Données sensibles : Soyez extrêmement prudent lors de la manipulation d’informations sensibles. Évitez d’exposer directement des secrets dans les descriptions de plugins ou les journaux.
• Contrôle d’accès/Limitation de taux : Protégez vos systèmes backend contre les abus en mettant en œuvre des limites de taux appropriées et une authentification pour les API sous-jacentes de votre plugin.

Opérations asynchrones

De nombreuses actions de plugin du monde réel (par exemple, envoyer des e-mails, requêtes longues de base de données) sont asynchrones. Votre agent pourrait avoir besoin de gérer cela en retournant un ID de travail et en ayant un autre plugin pour vérifier l’état du travail, ou en utilisant des webhooks.

Conclusion

Construire des plugins d’agent est une compétence transformative pour quiconque travaille avec des LLM. Cela va au-delà de la simple conversation, permettant aux systèmes d’IA de devenir véritablement interactifs et actionnables. En suivant le guide de démarrage rapide, vous avez appris les composants fondamentaux : définir l’objectif du plugin, mettre en œuvre sa logique et, de manière cruciale, le décrire efficacement à l’aide d’un schéma JSON pour le LLM. Le pouvoir de ces descriptions ne peut être exagéré : elles sont le pont entre la compréhension linguistique d’un LLM et sa capacité à interagir avec le monde réel.

En avançant, n’oubliez pas de vous concentrer sur des descriptions claires, une gestion des erreurs solide et une orchestration réfléchie de plusieurs outils. L’avenir des agents IA réside dans leur capacité à s’intégrer harmonieusement avec le vaste écosystème de logiciels et de données, et les plugins sont la clé pour débloquer ce potentiel. Commencez à expérimenter, construisez vos propres outils personnalisés et regardez vos agents IA prendre vie !

🕒 Published: March 27, 2026