J’ai échappé au piège du nouveau cadre d’agent brillant

D’accord, les amis, Leo Grant ici, de retour avec une autre exploration approfondie du monde sauvage du développement d’agents. Aujourd’hui, je veux parler de quelque chose qui me taraude, quelque chose que j’ai vu apparaître dans forum après forum, et honnêtement, quelque chose avec lequel j’ai moi-même eu du mal il y a à peine quelques mois : Le piège du “Nouveau Cadre d’Agent Brillant”. Nous avons tous été là, n’est-ce pas ?

C’est 2026, et on a l’impression qu’un nouveau SDK ou cadre d’agent apparaît chaque semaine. Chacun d’eux promet d’être plus rapide, plus intelligent, plus évolutif, ou tout simplement plus facile pour créer des agents autonomes. Et en tant que personne qui vit et respire ce domaine, ma réaction initiale est toujours un mélange d’excitation et de FOMO. “Est-ce celui-là ? Est-ce l’outil qui rend enfin mon projet de cœur une réalité sans des semaines de code boilerplate ?”

Je me souviens qu’en octobre, je travaillais sur un agent d’assistant financier personnel. L’idée était simple : un agent capable de surveiller mes dépenses, d’identifier les services d’abonnement que je pourrais ne pas utiliser, et même de négocier de meilleurs tarifs en mon nom. J’avais un script Python de base en cours d’exécution, utilisant un bus de messages personnalisé et de nombreux `if/else`. C’était gauche, c’est sûr, mais ça fonctionnait.

Puis j’ai vu l’annonce pour “Aether”, un nouveau cadre d’agent basé sur Rust qui vantait une incroyable concurrence et un langage de définition d’agent déclaratif. Mon cerveau reptilien a immédiatement crié : “Réécris-le ! Rust est l’avenir ! Mon bazar Python est une honte !” Alors, j’ai passé deux bonnes semaines à porter tout mon projet vers Aether. Et devinez quoi ? Bien qu’Aether soit en effet performant et élégant, j’ai fini avec un projet qui était fonctionnellement identique à ma version Python, mais maintenant je devais apprendre tout un nouvel écosystème d’outils de construction, de gestion des dépendances, et de gestion des erreurs spécifiques à Aether.

C’était une leçon précieuse, et que je veux partager avec vous aujourd’hui. Le plus grand obstacle dans le développement d’agents n’est pas toujours de trouver le cadre “le meilleur” ; c’est de comprendre quand utiliser un cadre, et plus important encore, quand il vaut mieux s’en tenir à ce que vous savez et construire à partir de principes de base. Aujourd’hui, nous allons parler d’adopter l’état d’esprit du “build”, spécifiquement en ce qui concerne la communication et la gestion d’état de base de vos agents, plutôt que de s’approprier aveuglément le dernier SDK.

Le Problème Principal : Sur-ingénierie de la Communication

La plupart des cadres d’agents, au fond, essaient de résoudre deux problèmes principaux :

1. Communication Inter-Agent : Comment les agents communiquent-ils entre eux ? Files de messages, RPC, état partagé ?
2. Gestion d’État de l’Agent : Comment un agent garde-t-il une trace de ce qu’il sait, de ce qu’il a fait, et de ce qu’il doit faire ensuite ?

Et ce sont des problèmes critiques, sans aucun doute. Mais souvent, les cadres offrent une solution tellement complète et opinionnée qu’elle devient exagérée pour des projets plus simples ou introduit une complexité inutile. Mon agent financier, par exemple, avait uniquement besoin de communiquer avec un autre “agent” (une API bancaire fictive) et son propre état interne. Un bus de messages complet avec un routage complexe, c’était comme utiliser un lance-roquettes pour écraser une mouche.

Alors, et si nous simplifions ? Et si nous réfléchissons au strict minimum dont vous avez besoin pour faire communiquer les agents et se souvenir des choses ? Il ne s’agit pas de renier les cadres pour toujours, mais de construire une base solide d’abord, de comprendre les mécanismes sous-jacents, puis de décider si un cadre ajoute vraiment de la valeur plutôt que simplement des charges supplémentaires.

Messaging Simple : Le Baseline HTTP/JSON

Soyons brutalement honnêtes : pour un grand nombre de cas d’utilisation d’agents, en particulier ceux interagissant avec des services web ou d’autres systèmes externes, HTTP et JSON sont vos meilleurs amis. Ils sont omniprésents, bien compris, et incroyablement flexibles. Vous n’avez pas besoin d’un protocole personnalisé ou d’un courtier de messages complexe si vos agents envoient principalement des requêtes et reçoivent des réponses.

Considérons un scénario où vous avez un “Agent Scrapeur” qui récupère des données d’un site web et un “Agent Processeur” qui les nettoie et les analyse. Comment communiquent-ils ?

# scraper_agent.py (simplifié)
import requests
import json

def scrape_data(url):
 response = requests.get(url)
 if response.status_code == 200:
 return response.text
 return None

def send_to_processor(data):
 headers = {'Content-Type': 'application/json'}
 payload = {'raw_data': data}
 try:
 response = requests.post('http://localhost:8001/process', headers=headers, data=json.dumps(payload))
 response.raise_for_status() # Provoque une exception pour les erreurs HTTP
 print(f"Données envoyées au processeur : {response.json()}")
 except requests.exceptions.RequestException as e:
 print(f"Erreur d'envoi des données au processeur : {e}")

if __name__ == "__main__":
 url_to_scrape = "https://example.com/some_data" # Remplacer par une véritable URL
 raw_content = scrape_data(url_to_scrape)
 if raw_content:
 send_to_processor(raw_content)

# processor_agent.py (simplifié utilisant FastAPI)
from fastapi import FastAPI, Request
from pydantic import BaseModel
import uvicorn

app = FastAPI()

class DataPayload(BaseModel):
 raw_data: str

@app.post("/process")
async def process_data(payload: DataPayload):
 # Dans un scénario réel, vous feriez un traitement réel ici
 print(f"Données brutes reçues pour traitement : {payload.raw_data[:50]}...")
 processed_result = f"Traité : {payload.raw_data.upper()}" # Exemple de traitement
 return {"status": "success", "processed_data": processed_result}

if __name__ == "__main__":
 uvicorn.run(app, host="0.0.0.0", port=8001)

C’est basique, je sais. Mais c’est aussi incroyablement puissant. Vous avez deux agents, fonctionnant comme services séparés, qui communiquent entre eux. Pas de SDK spécial, pas de format de message personnalisé. Juste des pratiques web standards. La beauté ici est que vous pouvez les mettre à l’échelle indépendamment, les déployer n’importe où, et les déboguer avec des outils HTTP standards. Cette approche couvre une quantité surprenante des besoins de communication agent à agent sans aucune dépendance à un cadre.

Gestion d’État : Embrasser la Persistance

Le deuxième grand point est l’état. Un agent n’est pas vraiment un agent s’il oublie tout entre les exécutions. De nombreux cadres proposent un état en mémoire ou des machines à états complexes. Mais souvent, ce dont vous avez vraiment besoin, c’est d’une persistance simple et fiable.

Pour mon agent financier, je devais stocker des éléments tels que :

• Mes abonnements actuels (nom, coût, date de renouvellement)
• Mes catégories de dépenses
• Les tentatives de négociation historiques

Au début, j’ai essayé d’utiliser certains mécanismes d’état en mémoire offerts par un cadre, mais dès que l’agent a redémarré (ce qui arrive pendant le développement, croyez-moi), toutes ces précieuses données avaient disparu. Frustrant !

La solution ? Une simple base de données. Pour de nombreux projets personnels ou même des systèmes de production plus petits, SQLite est un excellent choix. C’est basé sur un fichier, ne nécessite pas de serveur séparé, et Python dispose d’un excellent support intégré.

# agent_state.py
import sqlite3
import json

class AgentState:
 def __init__(self, db_path='agent_data.db'):
 self.conn = sqlite3.connect(db_path)
 self._create_table()

 def _create_table(self):
 cursor = self.conn.cursor()
 cursor.execute('''
 CREATE TABLE IF NOT EXISTS agent_knowledge (
 key TEXT PRIMARY KEY,
 value TEXT
 )
 ''')
 self.conn.commit()

 def set(self, key, data):
 cursor = self.conn.cursor()
 value = json.dumps(data) # Stocker des objets complexes en tant que chaînes JSON
 cursor.execute('INSERT OR REPLACE INTO agent_knowledge (key, value) VALUES (?, ?)', (key, value))
 self.conn.commit()

 def get(self, key):
 cursor = self.conn.cursor()
 cursor.execute('SELECT value FROM agent_knowledge WHERE key = ?', (key,))
 row = cursor.fetchone()
 if row:
 return json.loads(row[0])
 return None

 def close(self):
 self.conn.close()

# Exemple d'utilisation :
if __name__ == "__main__":
 state = AgentState()

 # Stocker un abonnement
 state.set('subscription:netflix', {'name': 'Netflix', 'cost': 15.99, 'renewal': '2026-04-01'})
 state.set('subscription:spotify', {'name': 'Spotify', 'cost': 10.99, 'renewal': '2026-03-25'})

 # Récupérer un abonnement
 netflix_sub = state.get('subscription:netflix')
 print(f"Abonnement Netflix : {netflix_sub}")

 # Mettre à jour un abonnement
 if netflix_sub:
 netflix_sub['cost'] = 16.99 # Augmentation de prix !
 state.set('subscription:netflix', netflix_sub)
 
 print(f"Abonnement Netflix mis à jour : {state.get('subscription:netflix')}")

 # Stocker une liste de catégories de dépenses
 state.set('spending_categories', ['courses', 'divertissement', 'services publics'])
 print(f"Catégories de dépenses : {state.get('spending_categories')}")

 state.close()

Cette classe `AgentState` est super basique, mais elle fournit un magasin de paires clé-valeur qui persiste entre les redémarrages de l’agent. Vous pouvez stocker des dictionnaires, des listes, des chaînes – tout ce qui peut être sérialisé en JSON. Pour des relations plus complexes, vous définiriez davantage de tables, mais pour de nombreux agents, un simple magasin clé-valeur est tout ce dont vous avez besoin pour leur “mémoire”.

Rassembler le Tout : L’Agent “Basique”

Alors, si nous combinons ces idées, à quoi ressemble un agent “basique” ? C’est un processus qui :

1. Peut recevoir des commandes (par exemple, via un point de terminaison HTTP ou une simple file de messages).
2. Peut effectuer des actions (par exemple, faire des requêtes HTTP, exécuter des scripts locaux).
3. Peut se souvenir des choses (par exemple, en utilisant un magasin d’état persistant comme SQLite).
4. A une boucle principale ou un planificateur pour décider quoi faire ensuite.

Imaginons notre Agent Scrapeur d’avant, mais maintenant avec un peu de mémoire. Il doit se souvenir des URL qu’il a déjà grattées et quand, pour éviter de faire du travail redondant ou de réessayer les tentatives échouées.

# smart_scraper_agent.py
import requests
import json
import time
from datetime import datetime, timedelta
from agent_state import AgentState # Supposons que agent_state.py est dans le même répertoire

# Nous allons utiliser FastAPI pour recevoir des commandes de démarrage du scraping
from fastapi import FastAPI, BackgroundTasks
from pydantic import BaseModel
import uvicorn

app = FastAPI()
agent_state = AgentState(db_path='scraper_agent_data.db')

class ScrapeRequest(BaseModel):
 url: str
 target_processor_url: str

def _perform_scrape_and_send(url: str, target_processor_url: str):
 """Fonction interne pour effectuer le scraping et l'envoi."""
 last_scraped_info = agent_state.get(f'last_scraped:{url}')
 if last_scraped_info:
 last_scrape_time = datetime.fromisoformat(last_scraped_info['timestamp'])
 # Ne gratter que si plus d'une heure s'est écoulée (exemple)
 if datetime.now() - last_scrape_time < timedelta(hours=1):
 print(f"Saut de {url}, récemment gratté à {last_scrape_time}")
 return

 print(f"Grattage de {url}...")
 try:
 response = requests.get(url, timeout=10)
 response.raise_for_status()
 raw_content = response.text

 # Envoi au processeur
 headers = {'Content-Type': 'application/json'}
 payload = {'raw_data': raw_content}
 processor_response = requests.post(target_processor_url, headers=headers, data=json.dumps(payload))
 processor_response.raise_for_status()
 print(f"Données de {url} envoyées au processeur : {processor_response.json()}")

 # Mettre à jour l'état avec un grattage réussi
 agent_state.set(f'last_scraped:{url}', {
 'timestamp': datetime.now().isoformat(),
 'status': 'success',
 'processor_response': processor_response.json()
 })

 except requests.exceptions.RequestException as e:
 print(f"Erreur lors du grattage ou de l'envoi pour {url} : {e}")
 # Mettre à jour l'état avec un échec
 agent_state.set(f'last_scraped:{url}', {
 'timestamp': datetime.now().isoformat(),
 'status': 'failed',
 'error': str(e)
 })
 finally:
 agent_state.close() # Important de fermer la connexion si elle n'est pas gérée globalement

@app.post("/scrape")
async def start_scrape(request: ScrapeRequest, background_tasks: BackgroundTasks):
 """Point de terminaison pour déclencher une action de grattage."""
 background_tasks.add_task(_perform_scrape_and_send, request.url, request.target_processor_url)
 return {"message": f"Grattage de {request.url} initié."}

if __name__ == "__main__":
 # Vous pourriez également avoir une tâche planifiée ici qui interroge l'état pour des URLs à gratter
 # Pour le moment, nous allons simplement exécuter le serveur FastAPI.
 # Pour exécuter : uvicorn smart_scraper_agent:app --reload --port 8000
 uvicorn.run(app, host="0.0.0.0", port=8000)

Ce `smart_scraper_agent.py` combine notre communication HTTP de base avec un état persistant. Il empêche le grattage redondant dans une fenêtre temporelle définie et stocke le résultat de chaque grattage. C'est encore simple, mais cela commence à montrer un comportement "agentique" – se souvenir, décider et agir en fonction de son état interne et des stimuli externes.

Quand envisager un framework (et pourquoi)

Maintenant, je ne dis pas que les frameworks sont mauvais. Loin de là. Ils ont absolument leur place. Vous devriez commencer à les envisager quand :

• Coordination complexe : Vous avez des dizaines ou des centaines d'agents qui doivent coordonner des tâches complexes, former des équipes ou se découvrir dynamiquement. Ici, un solide bus de messages, la découverte de services, et potentiellement une couche d'orchestration d'agents deviennent inestimables.
• Comportements standardisés : Vos agents doivent mettre en œuvre des comportements communs comme la planification, la définition d'objectifs ou la compréhension avancée du langage naturel. Les frameworks fournissent souvent des abstractions ou des intégrations pour cela.
• Besoins en scalabilité : Vous traitez un très haut débit de messages ou un grand nombre d'agents concurrents, et vous avez besoin de protocoles de communication hautement optimisés ou d'une gestion d'état distribuée prête à l'emploi.
• Communauté et écosystème : Vous souhaitez utiliser une large communauté, des plugins existants et des modèles éprouvés pour des architectures d'agents spécifiques (par exemple, des agents conformes à la norme FIPA).

Même alors, les principes d'une communication claire et d'une gestion d'état solide dont nous avons discuté aujourd'hui restent fondamentaux. Un bon framework s'appuie sur ces principes, il ne remplace pas la nécessité de les comprendre.

Points à retenir

Mon espoir pour vous aujourd'hui est que vous repartiez avec un nouveau sentiment d'autonomisation et un regard critique sur la prochaine annonce de SDK d'agent "révolutionnaire". Voici ce que je veux que vous reteniez :

1. Commencez simple : Avant de vous plonger dans un framework complexe, définissez les besoins de communication et d'état absolus pour votre agent. Pouvez-vous résoudre 80 % de cela avec HTTP/JSON et une base de données simple comme SQLite ? Probablement.
2. Comprenez les primitives : Même si vous utilisez finalement un framework, passez un peu de temps à comprendre comment fonctionne le passage de messages et la persistance d'état à un niveau fondamental. Cette connaissance fera de vous un meilleur débogueur et architecte.
3. Itérez, ne réécrivez pas : Construisez d'abord la fonctionnalité de votre agent. Faites-le fonctionner. Si vous rencontrez un véritable mur de scalabilité ou de complexité qu'un framework résout de manière évidente, envisagez alors de l'adopter. Évitez l'impulsion de "tout réécrire".
4. Concentrez-vous sur la logique de l'agent : La véritable valeur de votre agent réside dans sa prise de décision, son raisonnement et les tâches uniques qu'il effectue. Ne laissez pas les préoccupations d'infrastructure éclipser le développement de cette logique de base.
5. Choisissez les outils avec soin : Ce n'est pas parce qu'un framework existe qu'il s'agit du bon outil pour votre tâche spécifique. Évaluez ses coûts par rapport à ses avantages.

La prochaine fois que vous commencerez un projet d'agent, essayez de développer vous-même la communication de base et la gestion d'état, même si ce n'est que pour un proof of concept. Vous apprendrez beaucoup, construirez un agent plus résilient et probablement vous éviterez beaucoup de maux de tête par la suite. Continuez à construire, continuez à expérimenter, et n'ayez pas peur de vous salir les mains avec les fondamentaux. Leo out.

🕒 Published: March 26, 2026