Construire un agent IA from scratch : pourquoi les frameworks vous mentent

Le problème avec les frameworks : la magie qui explose

Quand un développeur utilisé LangChain pour créer un agent, il ecrit quelque chose comme `initialize_agent(tools, llm, agent_type="zero-shot")`. Cinq lignes de code. L'agent fonctionne. Le dev est content. Le chef de projet est content. Tout le monde est content.

Jusqu'au jour ou l'agent répond n'importe quoi. Ou il boucle indefiniment et génère 200 euros d'appels API en 10 minutes. Ou il appelle le mauvais outil parce que la description d'un outil ressemble a celle d'un autre. Et la, personne ne sait ou regarder. Parce que personne ne comprend ce qui se passe entre `initialize_agent()` et la réponse.

Ce n'est pas un problème theorique. Une etude de Princeton (2024) a montre que les agents bases sur des frameworks produisent des résultats significativement moins fiables que des implementations sur mesure - précisément parce que les abstractions masquent les points de defaillance.

La metaphore est simple : utiliser un framework sans comprendre les mécanismes, c'est comme conduire une voiture sans savoir qu'elle a un frein a main. Ça marche tant que la route est droite. Au premier virage serre, vous comprenez la différence.

La boucle d'agent : le coeur de tout

Un agent IA, debarrasse de tout le marketing, c'est une boucle. Trois étapes qui se repetent :

1. Observer - l'agent lit son état actuel. Qu'est-ce que l'utilisateur a demande ? Quelles actions ont déjà été executees ? Quelles donnees sont disponibles ? 2. Decider - sur la base de ces observations, l'agent choisit la prochaine action. Appeler un outil ? Poser une question ? Generer une réponse finale ? 3. Agir - l'agent execute l'action choisie, met a jour son état, et la boucle recommence.

C'est tout. Pas de conscience artificielle, pas de "raisonnement émergent", pas de magie. Une boucle `while` avec des conditions d'arret.

Le projet Agents from Scratch implemente ça en deux fonctions : `agent_step()` qui execute un cycle, et `run_loop()` qui orchestre la sequence. Le tout en Python lisible par n'importe quel développeur junior.

La condition d'arret est critique - et c'est la que la plupart des implementations naives échouent. Sans `max_steps`, un agent peut tourner indefiniment. Sans vérification d'état, il peut répéter la même action en boucle. Les frameworks cachent ces mécanismes de sécurité. Quand vous construisez from scratch, vous les implementez consciemment.

La memoire : ce qui séparé un gadget d'un outil métier

Un chatbot a la memoire d'un poisson rouge dopamine. Chaque conversation repart de zero. Un agent IA, s'il est bien construit, se souvient.

La distinction cle n'est pas "memoire courte vs memoire longue" comme le vendent les slides marketing. C'est contexte vs memoire :

• Le **contexte**, c'est ce qui est visible dans la conversation en cours. Il est temporaire. Il disparaît quand la session se termine.
• La **memoire**, c'est ce qui persiste entre les sessions. Elle est chargee dans le contexte quand c'est pertinent.

En pratique, un agent de relance commerciale avec memoire sait que M. Dupont a déjà été contacte trois fois, que la derniere interaction portait sur le tarif, et qu'il prefere être appele le mardi matin. Un agent sans memoire lui reenvoie le même email générique pour la quatrieme fois. Devinez lequel génère des résultats.

L'implementation est etonnamment simple : un `memory.add()` pour stocker, un `memory.get_all()` pour charger, et une injection dans le prompt système. Le modele fait le reste. Pas besoin d'une base vectorielle a 500 euros par mois pour commencer. Un fichier JSON suffit pour un agent qui gère 50 clients.

Actions atomiques : l'art de ne pas tout casser

C'est le sujet que personne n'aborde dans les demos LinkedIn. Comment faire pour qu'un agent IA ne cause pas de degats quand il agit dans le monde réel ?

La réponse : des actions atomiques. Au lieu de donner a l'agent une instruction vague comme "gère la relance client", on decompose en opérations unitaires, typees et validees :

Chaque action a un nom, des parametres obligatoires, et des regles de validation. Si les parametres sont invalides, l'action ne s'execute pas. Pas de "je fais au mieux avec ce que j'ai" - soit c'est complet et correct, soit ça ne part pas.

Le principe est simple : plus l'action est petite, plus le système est sur. Un agent qui envoie un email, c'est verifiable. Un agent qui "gère la relation client", c'est incontrolable.

C'est exactement la différence entre un agent IA déployé en production et un prototype de hackathon. Le prototype impressionne. L'agent en production ne casse rien.

Les evals : le filet de sécurité que 90% des projets IA oublient

Vous modifiez un prompt. L'agent semble mieux répondre sur votre cas de test. Vous deployez. Et trois jours plus tard, un client signale que l'agent génère des devis avec des montants negatifs. Bienvenue dans le monde merveilleux de la regression silencieuse.

Les evals - tests de regression pour agents IA - ne sont pas un luxe. C'est le minimum vital. Le concept :

1. Vous creez un golden dataset : 10-20 cas d'utilisation réels avec les résultats attendus 2. A chaque modification, vous executez l'agent sur ce dataset 3. Si un cas échoue, vous corrigez ou vous revertez. Pas de négociation.

Deux types de vérification : - Hard : le JSON est validé, les champs obligatoires sont la, le bon outil est appele. Si ça échoue, c'est casse. Point. - Soft : la réponse est pertinente, le ton est correct, les chiffres sont plausibles. Si ça échoue, c'est a surveiller.

Le workflow est brutal de simplicite : modifier le prompt, lancer les evals, corriger ou reverter, commiter uniquement si ça passe. C'est du développement logiciel classique, applique a l'IA. Rien de revolutionnaire - sauf que 90% des projets IA ne le font pas.

Planification : un agent qui reflechit avant d'agir

Le dernier etage de la fusee. Un agent mature ne se lance pas tête baissee dans l'execution. Il planifie d'abord.

Concretement, face a une demande complexe comme "prepare le dossier de renouvellement Qualiopi", un agent planificateur va :

1. Generer une liste d'étapes structuree en JSON 2. Presenter ce plan pour validation (humaine ou automatique) 3. Executer chaque étape sequentiellement, en verifiant les résultats

Le plan est une structure de donnees, pas une pensee abstraite. Il est lisible, modifiable, auditable. Si l'étape 3 échoue, on sait exactement ou on en est et on peut reprendre.

C'est ce qui distingue un agent IA d'entreprise d'un jouet technique. L'agent planificateur montre son travail avant de le faire. Le dirigeant peut valider, ajuster, refuser. Le contrôle reste humain. L'execution est automatisée.

Ce que ça change pour votre PME

Vous n'avez pas besoin de construire un agent from scratch. Mais votre prestataire IA, lui, doit savoir le faire.

La question a poser lors de votre prochain achat IA : "Si votre framework plante demain, combien de temps pour reconstruire sans ?" Si la réponse est "on ne peut pas" ou un silence gene, vous avez votre réponse sur la solidite de la solution.

Les agents IA qui fonctionnent en production partagent tous les mêmes caracteristiques :

• **Boucle explicite** avec conditions d'arret documentees
• **Memoire persistante** adaptee au cas d'usage (pas surdimensionnee)
• **Actions atomiques** validees avant execution
• **Evals** executes a chaque modification
• **Planification** visible et auditable

Ces principes ne dependent d'aucun framework. Ils sont universels. Et ils sont exactement ce qui fait la différence entre un projet IA qui tient 6 mois et un qui tient 6 jours.