Comment créer un agent IA utile ?

Trois tâches revenaient chez cette PME :

• rédiger les comptes rendus de réunion,
• relancer les devis,
• et qualifier les demandes entrantes.

Pour cet exemple, nous garderons la troisième, parce qu’elle coche les trois critères d’un bon agent : elle revient tous les jours, elle suit des règles, et son résultat est vérifiable.

C’est le même réflexe que partir de l’usage plutôt que de la technologie : on ne cherche pas « où mettre de l’IA », on cherche quelle tâche coûte cher et se laisse cadrer.

Un agent lit quelque chose de réel.
Voici deux demandes reçues le même matin.

Demande A

Bonjour, j’ai besoin d’un devis pour 15 radiateurs acier réf. R-450, livrés à Lyon avant fin octobre. Compte client 4471. Atelier Perrin

Demande B

Bonjour, vous proposez quel catalogue de produits exactement ?
envoyé depuis une adresse gmail, sans nom d’entreprise

La A est nette. La B est floue.
Un bon agent doit traiter la première et reconnaître qu’il ne doit pas trancher la seconde.

C’est l’étape que tout le monde saute et pourtant, celle qui décide de tout.

« Créer l’agent », concrètement, c’est écrire les instructions qu’on donne au modèle.

Les voici, en clair :

Classe la demande. Réponds uniquement par un JSON :
categorie, priorite, destinataire, reponse_suggeree, a_valider

Règles :
- référence produit + compte client connus   → "commande", priorité haute, "ADV"
- besoin précis, nouveau contact              → "devis", priorité haute, "commerce"
- hors catalogue                              → "hors_scope", priorité basse, "archive"
- demande vague OU sans identité              → a_valider = true, destinataire "humain"

Ces quelques lignes sont le cœur de l’agent.

Pas de code obscur : des règles métier, lisibles par n’importe qui dans l’entreprise et modifiables quand un cas nouveau apparaît.

La question tombe tout de suite.
La réponse honnête : pour une tâche de tri, les quatre en sont capables.

Le choix se joue sur trois critères qui comptent plus que les classements du moment.

Confidentialité et hébergement

Vos demandes contiennent des données clients.
Deux exigences : que le fournisseur n’entraîne pas ses modèles sur vos données (une option à activer sur l’API), et, si les données sont sensibles, un hébergement en Europe.
Sur ce point, Mistral (éditeur français) a l’argument le plus direct ; Claude et OpenAI proposent aussi des offres européennes/entreprise.

Coût au volume

Un tri de mails n’a pas besoin du modèle le plus puissant.
Les versions « légères » (Haiku chez Claude, Flash chez Gemini, Mini chez OpenAI, Small chez Mistral) font ce travail pour une fraction du prix : à ce volume, quelques euros par mois.

Fiabilité des sorties

Un agent piloté par règles doit renvoyer une sortie structurée sans broder.
Claude est réputé pour son respect strict des instructions et la régularité de ses réponses structurées (plutôt utile !).
Les autres y arrivent aussi : l’écart se teste (étape 7), il ne se suppose pas.

Un dernier critère, pratique : si l’entreprise vit déjà dans Google Workspace, Gemini s’intègre naturellement ; dans un environnement Microsoft, OpenAI via Azure.

Notre parti pris : nous ne sommes attachés à aucun.
Nous choisissons selon vos contraintes, et c’est pour cela que nous travaillons avec les quatre.
Ce qui ne change pas, ce sont les critères ; les modèles, eux, évoluent tous les trimestres.

On donne les deux emails au modèle (Claude, GPT ou équivalent), avec les instructions ci-dessus.
Réponse en une seconde.

Pour la demande A :

{ "categorie": "qualifié", "priorite": "haute", "destinataire": "commerce",
  "reponse_suggeree": "Bonjour, merci pour votre commande. Un de nos…",
  "a_valider": false }

Pour la demande B :

{ "categorie": "à_qualifier", "priorite": "basse", "destinataire": "humain",
  "reponse_suggeree": "", "a_valider": true }

Une sortie structurée, pas un paragraphe : c’est ce qui permet à l’étape suivante d’aiguiller automatiquement.

Reste à relier tout ça.

Dans un outil d’automatisation de type n8n, cela tient en quatre blocs :

Nouveau mail sur contact@   →   Modèle IA (les règles de l'étape 3)
      →   Aiguillage selon "destinataire"
      →   Fiche créée dans le CRM + alerte au commerce
   (si a_valider = true   →   mise en file pour validation humaine)

On ne monte pas tout d’un coup : on prend une source et une catégorie, et on fait tourner ce périmètre réduit de bout en bout.

C’est le travail qu’un ingénieur boucle en quelques jours quand il vient installer cette première version directement auprès de vos équipes, au lieu de lancer un projet.

Un agent ne se valide pas « à l’œil ».
Nous lui construisons un jeu d’épreuve : cinquante demandes déjà traitées, dont on connaît la bonne réponse.
Nous les rejouons et nous comparons.

Demande                          Agent           Attendu         Verdict
Devis 15 radiateurs, client 4471 commande/haute  commande/haute  ✓
"Vous faites quoi ?" (gmail)     à_valider       à_valider       ✓
Relance d'un client mécontent    hors_scope      humain/haute    ✗  coûteux
Publicité d'un fournisseur       hors_scope      hors_scope      ✓

Point clé : toutes les erreurs ne se valent pas :

• Un client mécontent classé « hors_scope » est une erreur coûteuse (relation abîmée),
• Une pub envoyée « à valider » est bénigne (dix secondes d’un humain).

Nous corrigeons d’abord les coûteuses.
Nous ajustons les règles, nous rejouons le même jeu, jusqu’à ce que les erreurs coûteuses tombent à zéro.
Et nous gardons ce jeu d’épreuve : à chaque modification future, nous le rejouons pour vérifier que tout est en place.

Un agent en production n’est pas « posé et oublié ».
Trois filets, du plus immédiat au plus régulier :

La file « à valider » est le signal en temps réel. Si elle se remplit anormalement, c’est que l’agent bute sur un type de demande nouveau → une règle à ajouter.

La journalisation. Chaque décision est enregistrée (la demande, la classification, l’orientation). Quand un humain rattrape un cas mal classé, la correction est notée : ces corrections sont la matière première du réglage suivant.

La revue mensuelle. Une fois par mois, on reprend les erreurs et les cas « à valider » récurrents, et on affine les règles. C’est ce point régulier qui maintient l’agent juste dans le temps, à mesure que l’activité évolue.

Les indicateurs que l’on suit :

• la part traitée en autonomie (vs validée à la main),
• le taux d’erreur coûteuse (visé à zéro),
• le temps gagné.

Un signe de dérive typique : les « à valider » qui remontent > l’activité a changé, les règles doivent suivre.

Ces trois filets : valider, tracer, revoir, sont la gouvernance de l’agent au quotidien.

Résultat : les cinq heures de tri quotidien tombent à environ quarante-cinq minutes, le temps de valider ce que l’agent a mis de côté.

Le gain n’est pas une promesse, c’est un chiffre que l’on suit : la même mécanique qui a permis chez LionSourcing de ramener un devis de trois à cinq heures à vingt minutes.

Une fois ce premier agent stable, nous passons à la catégorie suivante, puis à la tâche d’après. Une à la fois.

Beaucoup d’agents IA sont développés… mais peu sont réellement utilisés.
Nous observons souvent :

• des agents trop complexes,
• des périmètres mal défini,
• des usages peu clairs.

À l’inverse, les agents efficaces sont souvent simples.
Ils répondent à un besoin précis, et ils s’intègrent naturellement dans le quotidien des équipes.