Agent LLM en production : le rôle d'un lead dev IA

Un agent qui répond bien à trois questions en réunion n’est pas un agent en production. La démo marche parce qu’on choisit les cas. La production doit tenir ceux qu’on n’a pas choisis : un ticket mal rédigé, une API qui répond en erreur, une donnée sale un vendredi soir.

À l’agence, nous branchons des modèles de langage sur de vraies applications, chez Animalink comme dans nos propres outils. Le modèle est rarement le problème. Ce qui prend du temps, c’est tout ce qui l’entoure.

Ce qu’une démo ne montre pas

Quatre questions reviennent sur chaque projet. Aucune ne se règle dans le prompt.

Évaluation : comment savoir que l’agent a bien fait son travail, et le savoir encore après le prochain changement de modèle ?
Garde-fous : que peut-il faire, sur quelles données, et que se passe-t-il quand il se trompe ?
Coût : combien coûte une exécution, et combien coûte un mois de cas tordus ?
Observabilité : que s’est-il passé exactement pour une exécution donnée, et qui le voit avant le client ?

Évaluer avant de faire confiance

Un agent se juge sur des cas réels, pas sur une impression. Avant la mise en production, nous constituons un petit jeu d’exemples tirés des données de l’équipe, avec le résultat attendu, et nous le rejouons à chaque changement de prompt, de modèle ou d’outil. Quelques dizaines de cas bien choisis valent mieux qu’une démo de dix minutes.

Il faut aussi mesurer ce que l’équipe gagne réellement : temps par tâche, taux d’erreur, coût par exécution. Si ces chiffres n’existent pas au bout de trois semaines de prototype, l’automatisation n’est pas encore décidée, quel que soit l’enthousiasme autour.

Des garde-fous, pas des promesses

Le modèle se trompera. La question utile est ce que son erreur peut toucher. Le Top 10 OWASP pour les applications LLM, dans son édition 2025, recense les risques les plus courants. Trois sont, au quotidien, ceux que nous surveillons le plus :

L’injection de prompt (LLM01, premier de la liste) : tout texte que le modèle lit peut contenir des instructions. Un scraper qui ingère des pages écrites par n’importe qui en est le cas d’école.
Le pouvoir excessif (LLM06) : l’agent n’a que les droits de sa tâche, pas ceux de la personne qui l’a lancé. Lecture large, écriture étroite, et validation humaine sur toute action qui engage quelqu’un.
La consommation illimitée (LLM10) : une boucle qui se relance sans fin, c’est une facture. Plafonds par exécution et par jour.

Concrètement : droits limités, trace de chaque action pour pouvoir revenir en arrière, et une étape humaine sur ce qui sort de l’entreprise, comme un envoi de mail ou une écriture dans le CRM.

Maîtriser les coûts

Le coût d’un agent se joue sur trois leviers : le modèle choisi par tâche (un petit modèle suffit souvent à classer, un grand à rédiger), la taille du contexte envoyé à chaque appel, et le nombre d’appels par exécution. Nous mesurons le coût par exécution dès le prototype. Un flux peut coûter peu en test et beaucoup plus en production, quand une boucle multiplie les appels.

Pour les données qui ne doivent pas quitter l’entreprise, un modèle local avec Ollama évite le sujet, au prix d’une puissance moindre. C’est un arbitrage à faire au cadrage, pas après coup.

Observabilité : lire les logs, pas le récit

Un agent qui affirme « c’est fait et testé » se trompe parfois. Dans Ponos, notre outil qui fait jouer les tickets par Claude Code, la règle est simple : on ne se fie qu’à la sortie des commandes dans les logs de session. Les tests, le lint et la vérification des types tournent à l’intérieur de la session, avant l’ouverture de la pull request. L’agent corrige ses propres erreurs tant qu’il a encore le contexte en tête.

Côté plateforme, le principe est celui d’une API classique : journaux structurés, trace par exécution, alertes sur les erreurs et sur les dépassements de coût. Chez Animalink, l’application est observée avec une stack ELK. Un agent doit y laisser la même trace qu’un utilisateur humain, sans passe-droit.

Cas réels

Animalink : des agents qui consomment l’API comme un client. Des flux n8n lisent et écrivent dans l’API Symfony, au même titre qu’un utilisateur. Une API bien conçue, avec des droits vérifiés côté serveur et un contrat décrit, est déjà une API pilotable par un agent. L’analyse documentaire et les embeddings passent par Mistral, et un chatbot produit complète le dispositif.

Ponos : un ticket Notion joué par Claude Code. Un ticket entre dans la colonne « à faire ». Une session Claude Code part dans un worktree git jetable, et une pull request en sort. Les questions que l’agent ne peut pas trancher arrivent à un humain sur Telegram ou Slack. Ce qui a marché : une session par ticket, jamais une session longue qui mélange les sujets. Ce qui n’a pas marché : les tickets vagues, qui produisent un diff plausible et inutile. Le cadrage n’a pas disparu, il s’est déplacé dans le ticket.

Leadz : scraping puis rangement par IA. Un scraper autonome parcourt le web et archive les contenus bruts. Une étape d’IA, en sortie structurée et avec un repli déterministe, les range ensuite dans une base d’entreprises qualifiées. Le point délicat n’est pas le scraping, mais la séparation entre ce que le modèle lit et ce qu’il a le droit de faire.

Whisper Desk : transcription hors ligne. Notre outil de dictée tourne hors ligne sur Linux, WSL et macOS. Le même raisonnement vaut pour un service interne qui traite de l’audio : si la donnée ne doit pas sortir, le modèle tourne chez vous.

Ce qu’apporte un lead dev IA en régie

Pour une équipe qui a déjà ses développeurs, le rôle n’est pas de faire de l’IA à leur place. Il tient en quatre points :

Choisir le cas d’usage sur une tâche mesurable, et dire non aux automatisations qui ne rapportent rien.
Garder l’API et les droits propres, pour que l’agent ne devienne pas un contournement.
Tenir l’évaluation, les coûts et les traces, puis les transmettre. À la fin, l’équipe sait relire un prompt, surveiller une dépense et faire évoluer le flux sans nous.
S’intégrer aux pratiques existantes : revue de pull request, intégration continue, tickets. Un agent qui sort du processus de l’équipe finit par être contourné.

Par où commencer

Pour une entreprise qui veut intégrer l’IA sur un cas précis, sans budget ouvert, la démarche tient en trois étapes :

Un atelier d’une demi-journée pour lister les tâches répétitives, les classer par valeur et par risque, et en choisir une.
Deux à trois semaines de prototype sur de vraies données, avec des mesures dès le premier jour.
La mise en production : droits, journalisation, supervision, documentation.

Le détail de l’offre est sur la page Intégration IA. Les outils cités sont présentés sur la page Projets.

Source : OWASP, Top 10 for LLM Applications 2025.