On transforme un script Python en agent IA en exposant ses fonctions comme des outils appelables par le modèle. L’intérêt, c’est de garder le code qui marche déjà, puis de laisser l’agent décider quoi appeler, dans quel ordre, et comment résumer le résultat.
Besoin d'aide ? Découvrez les solutions de notre agence d'agents IA.
Pourquoi garder le script Python ?
Je garde le script Python parce qu’il contient déjà la logique métier utile, testée, souvent suffisante. Mon premier réflexe, ce n’est pas de tout réécrire avec un framework agentique ou de repartir sur une architecture propre sur le papier. Je regarde d’abord ce qui marche déjà. Souvent, la valeur est là, dans une fonction un peu brute, mais fiable.
Dans un projet client, j’ai déjà vu un script de supervision web tourné depuis des mois dans un coin. Pas sexy. Pas “IA”. Mais il faisait le boulot. La bonne question, c’était plutôt : quelles fonctions peuvent devenir des outils que l’agent appelle quand il en a besoin ?
Prenons une fonction simple : check_website(url). Elle envoie une requête HTTP, mesure la latence, retourne le statut HTTP, l’état de réussite et le temps de réponse. C’est exactement le genre de brique qu’il faut garder.
import time
import requests
def check_website(url: str) -> dict:
'Vérifie un site web et retourne son statut HTTP et sa latence en millisecondes.'
started_at = time.perf_counter()
try:
# On limite le temps d’attente pour éviter qu’un site bloqué fige le script
response = requests.get(url, timeout=10)
latency_ms = round((time.perf_counter() - started_at) * 1000, 2)
return {
'url': url,
'status_code': response.status_code,
'ok': response.ok,
'latency_ms': latency_ms
}
except requests.RequestException as error:
# Même en erreur, on retourne une structure propre pour que l’agent puisse l’exploiter
latency_ms = round((time.perf_counter() - started_at) * 1000, 2)
return {
'url': url,
'status_code': None,
'ok': False,
'latency_ms': latency_ms,
'error': str(error)
}
if __name__ == '__main__':
result = check_website('https://www.python.org')
print(result)Ce script est utile. Mais il est rigide. Il sait vérifier un site, pas décider quels sites comparer. Il ne sait pas quoi faire si un site répond en 4 secondes. Il ne sait pas non plus produire une synthèse lisible pour quelqu’un qui veut juste savoir quoi corriger.
Comment améliorer votre visibilité IA ?
Si je veux comparer trois sites, détecter le plus lent et expliquer le résultat, je dois coder la boucle, le tri, les règles métier et la réponse finale. C’est exactement là qu’un agent devient intéressant. Je garde la fonction Python comme outil fiable, et je laisse l’agent orchestrer les décisions autour.
Comment préparer le projet agent IA ?
Je prépare un petit projet Python propre, j’installe le SDK Agents d’OpenAI et je configure ma clé API. Le SDK sert à relier quatre choses sans monter une usine à gaz : un modèle IA, des outils Python, un orchestrateur d’exécution et du tracing, c’est-à-dire une trace lisible de ce qui s’est passé pendant l’exécution.
Je pars toujours d’un dossier isolé. Ça évite les dépendances qui traînent, les versions bizarres, et les “chez moi ça marche” qu’on regrette deux jours plus tard.
mkdir website-monitor-agent
# Crée le dossier du projet.
cd website-monitor-agent
# Entre dans le dossier du projet.
python -m venv .venv
# Crée un environnement virtuel Python local.
source .venv/bin/activate
# Active l’environnement virtuel sur macOS ou Linux.
pip install openai-agents requests
# Installe le SDK Agents d’OpenAI et requests pour appeler des pages web.Sur Windows, l’activation change juste un peu :
.venvScriptsactivateEnsuite je configure la clé API OpenAI avec une variable d’environnement. Je ne mets jamais la clé en dur dans le code, ni dans un exemple, ni dans un dépôt Git. C’est une mauvaise habitude qui finit souvent en incident.
export OPENAI_API_KEY='votre_cle_api_openai'
Comment HubSpot utilise les agents IA ?
Sur Windows, je peux utiliser :
setx OPENAI_API_KEY 'votre_cle_api_openai'Les briques du SDK sont assez simples à comprendre. Agent sert à décrire le rôle de l’agent, ses instructions, son comportement attendu. function_tool sert à exposer une fonction Python au modèle, comme “vérifie si ce site répond”. Runner exécute la boucle entre le modèle et les outils. Tracing permet d’observer les appels, les décisions et les résultats. Le SDK sait aussi gérer des handoffs, quand un agent passe la main à un autre, et des sessions, pour garder du contexte, mais on n’a pas besoin de partir là-dessus tout de suite.
Pour l’instant, ma structure reste volontairement simple :
website-monitor-agent/
agent_monitor.py
requirements.txt
.env éventuel si l’équipe utilise un chargeur de variablesLe plus important maintenant, c’est d’avoir une fonction claire, typée, avec une docstring lisible. Le SDK va s’en servir pour décrire l’outil au modèle, donc si la fonction est floue, l’agent le sera aussi.
Comment transformer la fonction en outil ?
Je transforme la fonction en outil en ajoutant le décorateur @function_tool au-dessus de la fonction Python. C’est le pont entre mon code existant et l’agent IA. La fonction reste une fonction Python normale, testable, réutilisable, mais le modèle peut maintenant demander à l’appeler quand il en a besoin.
Le point important, surtout si vous êtes pressé : le SDK génère le schéma JSON de l’outil à partir de la signature de la fonction et de sa docstring. Le schéma JSON, c’est simplement la description lisible par le modèle : quels paramètres existent, leurs types, et ce que l’outil est censé faire. Je n’ai donc pas besoin d’écrire à la main un gros bloc de paramètres si ma fonction est proprement typée et documentée.
Voilà la fonction transformée en outil. Ici, l’agent donnera une URL, et la fonction gardera toute la logique technique : appel HTTP, mesure de latence, gestion des erreurs.
import time
import requests
from agents import function_tool
@function_tool
def check_website(url: str) -> dict:
'Vérifie un site web et retourne son statut HTTP, son état et sa latence en millisecondes.'
started_at = time.perf_counter()
try:
# L’agent fournit l’URL, la fonction garde la logique technique
response = requests.get(url, timeout=10)
latency_ms = round((time.perf_counter() - started_at) * 1000, 2)
return {
'url': url,
'status_code': response.status_code,
'ok': response.ok,
'latency_ms': latency_ms
}
except requests.RequestException as error:
latency_ms = round((time.perf_counter() - started_at) * 1000, 2)
return {
'url': url,
'status_code': None,
'ok': False,
'latency_ms': latency_ms,
'error': str(error)
}Je garde quelques règles simples quand je crée un outil comme ça :
- Je choisis un nom de fonction explicite, comme check_website plutôt que tool_1.
- Je type les paramètres, ici url: str, pour aider le SDK à décrire correctement l’outil.
- J’écris une docstring utile, pas une phrase vague du style “fait un check”.
- Je retourne un dictionnaire structuré, parce que l’agent peut comparer des champs comme ok, status_code ou latency_ms.
- Je capture les erreurs proprement, sinon l’agent se retrouve avec une exception brute et ne sait pas toujours quoi en faire.
Chez les clients, je vois souvent le même problème : les agents deviennent vite confus quand les outils ont des noms vagues ou renvoient du texte libre impossible à comparer. Un retour structuré change tout. Maintenant que l’outil existe, il faut créer l’agent qui va décider quand l’utiliser.
Comment créer l’agent IA ?
Je crée l’agent IA en lui donnant un nom, un modèle, des instructions claires et la liste des outils qu’il peut appeler.
L’agent ne remplace pas la fonction Python. Il l’orchestre. Ça change tout. Votre fonction fait le vrai travail technique, ici tester un site web. L’agent, lui, reçoit une demande en langage naturel, décide quels sites tester, appelle l’outil plusieurs fois si besoin, compare les résultats, puis formule une réponse lisible.
Voici le fichier complet agent_monitor.py, prêt à exécuter. Il faut juste que la clé API soit disponible dans votre environnement, généralement via la variable OPENAI_API_KEY.
import time
import requests
from agents import Agent, Runner, function_tool
@function_tool
def check_website(url: str) -> dict:
"""Vérifie un site web et retourne son statut HTTP, son état et sa latence en millisecondes."""
started_at = time.perf_counter()
try:
response = requests.get(url, timeout=10)
latency_ms = round((time.perf_counter() - started_at) * 1000, 2)
return {
"url": url,
"status_code": response.status_code,
"ok": response.ok,
"latency_ms": latency_ms
}
except requests.RequestException as error:
latency_ms = round((time.perf_counter() - started_at) * 1000, 2)
return {
"url": url,
"status_code": None,
"ok": False,
"latency_ms": latency_ms,
"error": str(error)
}
website_monitor = Agent(
name="Website Monitor",
model="gpt-4.1-mini",
instructions=(
"Tu es un agent de monitoring web. "
"Quand on te demande de tester des sites, utilise l’outil check_website. "
"Compare les temps de réponse, signale les erreurs HTTP ou réseau, "
"puis réponds avec une synthèse courte et actionnable."
),
tools=[check_website]
)
if __name__ == "__main__":
result = Runner.run_sync(
website_monitor,
"Teste https://www.python.org, https://github.com et https://openai.com. "
"Dis-moi quel site est le plus lent et résume les résultats."
)
print(result.final_output)Les imports chargent les briques nécessaires. requests fait les appels HTTP. Agent, Runner et function_tool viennent du SDK d’agents.
- @function_tool transforme une fonction Python classique en outil appelable par le modèle.
- check_website mesure le statut HTTP, l’état de réussite et la latence du site.
- Agent définit le nom, le modèle utilisé et le comportement attendu.
- instructions sert de brief opérationnel. C’est là que je cadre ce que l’agent doit faire, et surtout comment répondre.
- tools=[check_website] donne explicitement à l’agent le droit d’utiliser cette fonction.
- Runner.run_sync lance l’agent en mode synchrone, donc le script attend la réponse finale avant de continuer.
Pour l’exécuter, je lance simplement cette commande dans le terminal.
python agent_monitor.pyLe comportement attendu est simple. L’agent comprend qu’il doit tester trois URLs, déclenche les appels nécessaires à l’outil, récupère les dictionnaires de résultats, compare les latences et produit une réponse finale structurée. Je ne mets pas de chiffres fixes ici, parce qu’ils changent selon le réseau, le serveur, le moment du test, parfois même d’une seconde à l’autre.
À ce stade, ce n’est plus juste un script, c’est une boucle où le modèle décide des actions utiles.
Que fait la boucle agentique ?
La boucle agentique laisse le modèle décider des appels d’outils nécessaires, pendant que Runner orchestre les échanges jusqu’à obtenir assez d’informations pour répondre. C’est la vraie différence avec un script classique. Dans un script, j’écris l’ordre exact des opérations. Dans un agent, j’écris les fonctions disponibles, puis le modèle choisit quand les utiliser selon la demande.
Le cycle est assez simple. L’utilisateur pose une demande en langage naturel. Le modèle analyse ce qu’il doit faire. Il choisit un outil, par exemple une fonction Python. Le SDK exécute cette fonction. Le résultat revient au modèle. Le modèle peut décider d’appeler un autre outil, ou produire la réponse finale.
Avec l’exemple des trois sites, l’agent peut appeler check_website trois fois, une fois par URL. Il récupère les statuts HTTP, les latences, les erreurs éventuelles. Puis il compare. Il peut dire quel site répond le plus vite, lequel est en erreur, lequel mérite une alerte. Le script classique aurait besoin qu’on code cette logique à l’avance. Là, l’agent construit son raisonnement autour des résultats disponibles.
| Script classique | Agent IA |
| Logique fixe, écrite à l’avance dans le code. | Décision dynamique selon la demande utilisateur. |
| Paramètres codés ou passés dans un format précis. | Demande formulée en langage naturel. |
| Sortie brute, souvent technique. | Synthèse lisible, avec explication et conclusion. |
| Combiner plusieurs actions demande plus de code. | Plusieurs appels d’outils peuvent être enchaînés naturellement. |
Ce modèle se prolonge bien. On peut ajouter une fonction qui vérifie le contenu d’une page, une fonction qui envoie une alerte, une fonction qui écrit dans un fichier ou une base, une fonction qui historise les temps de réponse. L’idée n’est pas de donner tous les pouvoirs à l’agent. Je préfère lui donner des outils précis, fiables, limités, observables. Comme ça, on sait ce qu’il peut faire, et surtout ce qu’il ne peut pas faire.
Sur des projets client, ce qui marche le mieux, ce n’est pas l’agent magique avec 40 outils. C’est souvent 3 à 6 fonctions métier très propres, bien nommées, avec des retours structurés. Le modèle combine mieux les résultats, et l’équipe garde le contrôle. C’est moins spectaculaire sur le papier, mais beaucoup plus solide en production.
Ce pattern peut s’appliquer à beaucoup d’automatisations Python : monitoring, reporting, enrichissement de données, contrôle qualité, SEO technique, support interne. Le principe reste le même : je garde les fonctions métier, et je laisse l’agent choisir quand les appeler.
Et si votre prochain agent était déjà dans vos scripts ?
Transformer un script Python en agent IA, ce n’est pas repartir de zéro. Je garde la fonction utile, je la rends appelable avec @function_tool, puis je crée un agent capable de l’utiliser au bon moment. Le SDK Agents apporte la couche d’orchestration avec Agent, Runner, les outils et le tracing. Le vrai gain, c’est la souplesse : au lieu de coder toutes les branches à la main, vous laissez l’agent choisir les appels nécessaires et produire une synthèse claire. Vous capitalisez sur votre code existant, avec moins de friction et plus d’automatisation utile.
FAQ
- Faut-il réécrire toute une application Python pour créer un agent IA ?
Non, l’approche la plus simple consiste à garder les fonctions existantes et à les exposer comme outils. L’agent peut ensuite les appeler selon la demande utilisateur, sans casser le code métier déjà en place. - À quoi sert @function_tool dans le SDK Agents ?
Le décorateur @function_tool rend une fonction Python disponible pour l’agent. Le SDK utilise la signature et la docstring pour comprendre les paramètres attendus et générer le schéma de l’outil. - Quel est le rôle de Runner ?
Runner orchestre la boucle entre le modèle et les outils. Il transmet la demande au modèle, exécute les appels d’outils demandés, renvoie les résultats au modèle, puis récupère la réponse finale. - Pourquoi un agent IA est plus souple qu’un script classique ?
Un script classique suit une logique codée à l’avance. Un agent peut décider dynamiquement quelles fonctions appeler, combien de fois, dans quel ordre, puis combiner les résultats pour produire une synthèse. - Quels types de scripts Python peuvent devenir des agents IA ?
Les meilleurs candidats sont les scripts qui font déjà une action claire : vérifier un site, enrichir une donnée, générer un rapport, contrôler une qualité, envoyer une alerte ou interroger une API. Plus la fonction est précise, mieux l’agent l’utilise.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation. Si vous voulez transformer vos scripts, workflows ou process métier en agents utiles, je peux vous aider. Contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.