Je garde le script Python existant, je l’expose comme outil, puis je laisse le modèle décider quand l’utiliser. C’est ça le vrai changement. On passe d’un workflow rigide à un agent IA Python capable d’orchestrer les appels et d’expliquer les résultats.
Quel script garde-t-on au départ ?
On garde une fonction Python simple qui vérifie une URL, son statut HTTP et sa latence. C’est exactement le genre de script qu’il ne faut pas jeter au moment où on ajoute un agent IA autour. Si le code fait déjà bien son boulot, je le garde. Je change seulement la façon de l’appeler.

Le point de départ, c’est une fonction check_website(url) basée sur requests. Elle lance une requête HTTP GET, récupère response.status_code, puis mesure le temps de réponse avec time.time() ou response.elapsed.total_seconds(). Rien de magique. C’est du Python classique, robuste, facile à tester.
Ce script est utile quand je veux tester une URL précise. Le problème, c’est qu’il reste rigide. C’est moi, développeur, qui décide à l’avance quelle URL tester, dans quel ordre, combien de fois, et comment interpréter le résultat. L’agent, lui, va surtout servir à piloter cette logique sans réécrire la fonction métier.
import time
import requests
def check_website(url, timeout=5):
# Je démarre le chrono juste avant la requête HTTP.
start_time = time.time()
try:
# Je lance une requête GET classique avec un timeout pour éviter de bloquer.
response = requests.get(url, timeout=timeout)
# Je calcule la latence en millisecondes.
response_time_ms = round((time.time() - start_time) * 1000, 2)
# Je récupère le code HTTP, par exemple 200, 404 ou 500.
status_code = response.status_code
# Je considère que le site répond correctement entre 200 et 399.
ok = status_code >= 200 and status_code < 400
return {
"url": url,
"status_code": status_code,
"response_time_ms": response_time_ms,
"ok": ok
}
except requests.exceptions.RequestException:
# En cas d'erreur réseau, DNS, timeout ou SSL, je retourne un résultat exploitable.
return {
"url": url,
"status_code": None,
"response_time_ms": None,
"ok": False
}
if __name__ == "__main__":
result = check_website("https://example.com")
print(result)Si je veux comparer trois sites et identifier le plus lent, je dois encore coder la boucle, stocker les résultats, trier par response_time_ms, ignorer les erreurs, choisir une règle de décision, puis générer le message final. Ça marche, mais tout est figé dans mon code.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le vrai sujet n’est donc pas de remplacer check_website. Je garde cette fonction telle quelle, parce qu’elle contient la logique fiable. Le but, c’est de la rendre appelable par un agent, pour que l’agent décide quand l’utiliser, avec quelles URLs, et comment expliquer le résultat.
Comment préparer le SDK Agents ?
Pour préparer le SDK Agents proprement, je fais simple : j’isole le projet Python, j’installe openai-agents et requests, puis j’expose la clé API OpenAI avec la variable d’environnement OPENAI_API_KEY. C’est exactement ce que je fais chez un client quand on veut tester vite, sans polluer le repo principal ni casser une dépendance existante.

Je commence par créer un dossier dédié. Rien de magique ici, l’idée c’est juste d’avoir un bac à sable propre.
mkdir agent-python-test
cd agent-python-testEnsuite, je crée un environnement virtuel Python. Un environnement virtuel, c’est une copie isolée de Python avec ses propres packages. Comme ça, si on installe une librairie pour ce test, elle ne vient pas modifier le reste de votre machine ou de votre projet principal.
python -m venv .venvPour l’activer sur macOS ou Linux, j’utilise cette commande.
source .venv/bin/activateSur Windows, c’est celle-ci.
.venvScriptsactivateUne fois l’environnement activé, j’installe les dépendances nécessaires. openai-agents sert à créer et exécuter l’agent IA. requests sert ici aux appels HTTP, par exemple pour vérifier un site web.
pip install openai-agents requestsLe package openai-agents fournit les briques principales : Agent, Runner et le décorateur function_tool. Agent décrit le comportement de l’agent, avec ses instructions. Runner lance la boucle d’exécution, c’est-à-dire les allers-retours entre le modèle et vos fonctions. function_tool permet de transformer une fonction Python en outil utilisable par le modèle, avec des entrées typées. Dit simplement, le modèle comprend qu’il peut appeler une fonction, lui passer des paramètres, récupérer le résultat, puis continuer son raisonnement.
Côté sécurité, je ne mets jamais la clé API en dur dans le code. Même pour un test rapide. Une clé oubliée dans Git, ça arrive plus vite qu’on pense, et après c’est pénible à nettoyer.
Sur macOS ou Linux, je définis la clé comme ça.
export OPENAI_API_KEY="votre_clé_api_openai"Sur Windows, je peux utiliser setx pour l’enregistrer côté utilisateur.
setx OPENAI_API_KEY "votre_clé_api_openai"Il faudra rouvrir le terminal après setx, sinon la variable ne sera pas forcément disponible dans la session courante.
À ce stade, le terrain est prêt. La prochaine étape consiste à transformer la fonction check_website en outil pour l’agent, sans toucher à sa logique métier.
Comment transformer la fonction en outil ?
On ajoute le décorateur @function_tool au-dessus de la fonction, on type les paramètres, on garde la logique existante et le SDK génère le schéma utilisable par le modèle. C’est ça la vraie valeur. Je ne réécris pas l’application, je rends juste une fonction Python compréhensible et appelable par l’agent.

@function_tool sert à exposer une fonction Python comme un outil. Il donne au modèle le nom de la fonction, sa description, ses paramètres et son type de retour. Les annotations de type, comme url: str ou -> dict, aident le modèle à comprendre quoi envoyer et quoi attendre. La docstring compte aussi beaucoup. C’est le contexte métier de l’outil : ce que la fonction fait, ce qu’elle attend, ce qu’elle renvoie. J’ai déjà vu des agents faire n’importe quoi juste parce qu’une fonction était “techniquement correcte” mais mal décrite.
Voici un exemple directement copiable dans monitor_tools.py ou main.py. Il transforme une fonction classique de monitoring web en outil exploitable par un agent IA.
import time
import requests
from agents import function_tool
@function_tool
def check_website(url: str) -> dict:
"""
Vérifie si un site web répond correctement.
Paramètre:
url: URL complète du site à tester, par exemple "https://example.com".
Retourne:
Un dictionnaire structuré avec:
- ok: True si le site répond avec un code HTTP inférieur à 400
- status_code: Code HTTP retourné par le serveur
- response_time_ms: Temps de réponse en millisecondes
- error: Message d'erreur si la requête échoue, sinon None
"""
start_time = time.time()
try:
# On évite de bloquer l'agent trop longtemps avec un timeout raisonnable.
response = requests.get(url, timeout=10)
response_time_ms = round((time.time() - start_time) * 1000, 2)
return {
"ok": response.status_code < 400,
"status_code": response.status_code,
"response_time_ms": response_time_ms,
"error": None,
}
except requests.RequestException as error:
response_time_ms = round((time.time() - start_time) * 1000, 2)
return {
"ok": False,
"status_code": None,
"response_time_ms": response_time_ms,
"error": str(error),
}Si la fonction renvoie un texte flou du style “le site semble marcher”, l’agent aura peu de matière. Il pourra reformuler, oui, mais il décidera mal. Si elle renvoie un dictionnaire propre avec status_code, response_time_ms, error et ok, là il peut comparer, résumer, prioriser et déclencher une action derrière. C’est souvent là que la qualité d’un agent se joue, pas dans le prompt magique.
| Élément | Rôle | Bonne pratique |
| @function_tool | Expose la fonction comme outil pour l’agent | Le placer juste au-dessus de la fonction |
| Types | Aident le modèle à appeler l’outil correctement | Utiliser des types simples et explicites |
| Docstring | Donne le contexte au modèle | Décrire l’entrée, la sortie et le comportement |
| Retour structuré | Facilite l’analyse par l’agent | Renvoyer un dictionnaire clair et stable |
Comment créer l’agent Website Monitor ?
Dans ce découpage, je ne demande pas à l’IA de “faire du Python” à ma place. Je crée un agent avec un nom, des instructions et une liste d’outils disponibles. Puis je lance Runner.run_sync pour lui poser une demande en langage naturel.
L’agent ne remplace pas Python. Il orchestre vos fonctions Python. C’est une nuance importante. Le code fiable reste dans check_website. Le modèle décide quand l’appeler, dans quel ordre, quoi comparer, et comment répondre.
Voici un main.py complet. Je pars du principe que check_website existe déjà dans un fichier tools.py, et qu’elle vérifie une URL en retournant au moins son statut et son temps de réponse.
from agents import Agent, Runner
from tools import check_website
website_monitor = Agent(
name="Website Monitor",
instructions="""
Tu surveilles des sites web.
Quand tu dois vérifier une URL, appelle l'outil check_website.
Compare les temps de réponse entre les sites testés.
Identifie les sites lents ou indisponibles.
Ne devine jamais un résultat.
Si tu n'as pas appelé check_website pour une URL, dis que tu ne l'as pas vérifiée.
""",
tools=[check_website],
)
if __name__ == "__main__":
user_prompt = (
"Compare https://example.com, https://openai.com et https://python.org, "
"puis dis-moi lequel répond le plus lentement."
)
result = Runner.run_sync(website_monitor, user_prompt)
print(result.final_output)
Ce qui change ici, c’est que je n’ai plus besoin de coder toute la logique autour de plusieurs URLs.
- Je ne code plus la boucle pour parcourir les sites.
- Je ne code plus la comparaison des temps de réponse.
- Je ne code plus la synthèse en français.
- Je ne code plus la formulation finale pour l’utilisateur.
Je garde juste le métier dans une fonction claire : vérifier un site. C’est ça le bon équilibre. Sur des cas clients, ce découpage marche très bien. On garde le code fiable côté métier, là où on veut du déterministe, et on confie au modèle la partie plus souple : décider, comparer, expliquer.
Et franchement, c’est souvent là que l’agent devient utile. Pas parce qu’il “code mieux”, mais parce qu’il évite d’écrire toute la colle autour du code.
Que fait vraiment la boucle agentique ?
La boucle agentique laisse le modèle raisonner, choisir un outil, lire son résultat, recommencer si besoin, puis produire une réponse finale. C’est vraiment ça le cœur du sujet. On ne demande plus au modèle de répondre en une seule fois avec ce qu’il “pense savoir”. On lui donne accès à des fonctions Python, et il décide quand les utiliser.

Dans ce schéma, Runner joue le rôle d’orchestrateur. Il fait passer les messages entre l’utilisateur, le modèle et vos outils Python. Le modèle dit “J’ai besoin d’appeler cette fonction avec ces paramètres”. Runner exécute la fonction, récupère le résultat, puis le renvoie au modèle. Le modèle relit ce résultat, ajuste son raisonnement, et continue si nécessaire.
Prenons un cas simple. L’utilisateur demande de comparer trois sites web. Le modèle comprend qu’il ne peut pas répondre proprement sans vérifier chaque URL. Il demande donc à Runner d’exécuter check_website pour la première URL. Runner lance la fonction Python, récupère par exemple le temps de réponse, le code HTTP, une erreur éventuelle, puis renvoie tout ça au modèle. Le modèle recommence pour la deuxième URL, puis pour la troisième. Quand il a assez de données, il rédige une conclusion claire : le site le plus lent, l’éventuelle erreur HTTP, et une recommandation courte.
| Sujet | Script classique | Agent IA Python |
| Décision | Je code toutes les conditions à l’avance. | Le modèle choisit quoi faire selon la demande. |
| Appels de fonctions | Le script appelle les fonctions dans un ordre fixe. | Runner exécute les outils demandés par le modèle. |
| Interprétation des résultats | Je prévois les règles d’analyse. | Le modèle lit les résultats et formule une réponse. |
| Demande imprévue | Le script casse souvent ou répond à côté. | L’agent peut s’adapter si les outils suffisent. |
| Maintenance | J’ajoute du code dès que le besoin change. | Je garde mes fonctions et j’améliore surtout les outils et les consignes. |
Il ne faut pas vendre ça comme de la magie. L’agent dépend directement de la qualité des outils, des instructions, des données renvoyées et des permissions qu’on lui donne. Si check_website renvoie des infos floues, l’agent fera une analyse floue. Si je lui donne un outil qui supprime des fichiers ou envoie des emails sans garde-fous, je prends un vrai risque.
Le même modèle marche très bien pour d’autres automatisations Python : analyse de CSV, contrôle de données, monitoring d’API, extraction de métriques, génération de rapport. Le modèle mental à garder est simple : je garde mes fonctions métier, je les expose comme outils, puis l’agent décide comment les utiliser pour répondre à la demande.
Et maintenant vous automatisez quoi ?
Transformer un script Python en agent IA, ce n’est pas refaire toute l’application. Je pars d’une fonction utile, je la rends appelable avec @function_tool, je crée un agent avec des instructions claires, puis Runner gère les échanges entre le modèle et les outils. Le vrai gain est simple : vous gardez votre logique métier fiable, mais vous sortez du workflow figé. L’agent peut comparer, relancer, synthétiser et expliquer. Pour du monitoring, du CSV, de l’API ou du reporting, le bénéfice est le même : vous automatisez plus vite, avec moins de code de décision à maintenir.
FAQ
- Qu’est-ce qu’un agent IA Python ?
Un agent IA Python est un modèle capable d’utiliser des fonctions Python comme outils. Au lieu d’écrire toute la logique de décision dans le code, je donne des outils au modèle et il décide quand les appeler, dans quel ordre, et comment interpréter les résultats. - Faut-il réécrire son script Python pour créer un agent ?
Pas forcément. L’idée est justement de garder la fonction métier existante, par exemple check_website(), puis de l’exposer comme outil avec un décorateur comme @function_tool. On ajuste surtout les types, la docstring et le format de retour pour que l’agent comprenne bien quoi faire. - À quoi sert le SDK OpenAI Agents ?
Le SDK sert à créer des agents, déclarer leurs instructions, leur donner des outils Python et exécuter la boucle entre le modèle et ces outils. Il évite de tout câbler à la main, surtout quand un agent doit appeler plusieurs fonctions avant de répondre. - Pourquoi utiliser un agent plutôt qu’une boucle Python classique ?
Une boucle Python classique marche très bien quand le scénario est fixe. L’agent devient intéressant quand la demande varie : comparer plusieurs sites, identifier le plus lent, expliquer une erreur, relancer un contrôle. Le code métier reste stable, mais l’orchestration devient plus souple. - Quels autres scripts peut-on transformer en agents IA ?
On peut appliquer le même principe à des scripts d’analyse CSV, de monitoring d’API, de contrôle qualité de données, d’extraction de métriques ou de génération de rapports. Le point commun : une fonction Python fiable, un retour structuré, et un agent qui orchestre son usage.
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. J’accompagne des équipes qui veulent connecter leurs données, leurs scripts et leurs outils IA sans empiler des usines à gaz. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez industrialiser ce genre d’automatisation dans votre business, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’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 propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, 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.





