Créez votre premier agent IA sans code

Le mois dernier, un responsable marketing d’une PME SaaS a utilisé Claude et Zapier pour construire un agent qui triait les e-mails du support client, les classait par urgence et rédigeait des réponses. Aucune requête API. Pas de Python. L’ensemble de la configuration a pris six heures. Dès la deuxième semaine, il gérait 40% des entrées. Ce n’est pas de l’automatisation de façade — c’est un véritable agent qui effectue un travail qui aurait nécessité une embauche.

Un agent IA n’est pas ChatGPT avec une mémoire plus longue. C’est un système capable d’observer son environnement, de décider quoi faire, d’agir et d’apprendre du résultat. La plupart des constructeurs d’agents no-code cachent cette complexité derrière des interfaces glisser-déposer, mais la logique sous-jacente est la même : percevoir → décider → agir → observer. Comprendre ce flux est ce qui sépare un agent fonctionnel d’un agent défectueux.

Ce guide vous accompagne dans la création d’un agent. Pas de théorie. Pas de discours inspirant inutile. L’arbre de décision réel dont vous avez besoin, les plateformes qui fonctionnent pour différents cas d’utilisation, les erreurs qui tuent la plupart des premiers agents, et un exemple fonctionnel réel que vous pouvez dupliquer dès aujourd’hui.

Ce qu’est réellement un agent IA (et ce qu’il n’est pas)

Commencez par la définition que vos outils ne vous donneront pas. Un agent est un système qui :

• Reçoit une entrée (e-mail, soumission de formulaire, message Slack, enregistrement de base de données)
• Décide quoi faire en fonction de cette entrée — y compris décider de demander des clarifications ou de refuser
• Effectue une action externe à lui-même (envoyer un e-mail, créer un ticket, récupérer des données, mettre à jour une feuille de calcul)
• Observe le résultat et ajuste sa prochaine action en fonction de ce qui s’est passé

Ce qu’il n’est pas : Un chatbot. Un chatbot répond à des questions. Un agent fait des choses. Lorsque vous cliquez sur « envoyer » dans ChatGPT, la conversation se termine. Lorsque vous déployez un agent, il continue de fonctionner après la fermeture de votre ordinateur portable.

La distinction no-code est importante ici. La plupart des plateformes no-code ne vous permettent pas de créer de véritables agents — elles vous permettent de créer des flux de travail avec une logique conditionnelle. La différence est subtile mais critique. Un flux de travail dit « si X, alors Y ». Un agent dit « étant donné X, que dois-je faire, quel est mon niveau de confiance, que se passe-t-il si j’ai tort, et que fais-je alors ? »

Les vrais agents no-code existent, mais ils sont plus rares. La plupart tombent dans une zone grise : ils sont suffisamment puissants pour un travail en production, mais ils exigent que vous compreniez la logique sous-jacente, pas seulement que vous cliquiez sur des boutons.

Les trois architectures d’agents que vous rencontrerez

Avant de choisir une plateforme, comprenez la structure sous-jacente. Chaque agent que vous construirez suivra l’un de ces modèles :

1. Agent de routage (le plus simple)

Décision : « À quelle catégorie cela appartient-il, et quelle est la prochaine étape ? »

L’agent lit l’entrée, la classe et la route quelque part. Un e-mail de support est classé comme facturation/technique/feedback et envoyé à la bonne file d’attente. Un rapport de dépenses est classé comme voyage/bureau/équipement et déclenche le flux d’approbation approprié.

Pourquoi c’est le plus facile : Vous n’avez pas besoin d’une prise de décision complexe. La classification est un problème résolu. Claude et GPT-4o sont incroyablement doués pour cela. La plupart des plateformes no-code gèrent cela nativement.

Quand ça casse : Lorsque la sortie nécessite un raisonnement au-delà de la catégorisation. « Cet e-mail mentionne plusieurs sujets » ou « la réponse dépend de données que je dois d’abord récupérer. »

2. Agent de récupération (le plus courant)

Décision : « J’ai besoin d’informations pour répondre correctement. Où puis-je les obtenir ? »

L’agent sait qu’il peut récupérer des données d’une base de données, d’une base de connaissances ou d’une API. Il décide quoi récupérer, l’obtient, et utilise cette information pour décider d’une action. Un client demande « Combien de commandes ai-je en attente ? » L’agent interroge votre base de données, obtient la réponse et la renvoie. Une demande de support nécessite du contexte — l’agent récupère l’historique du compte client et l’utilise pour rédiger une meilleure réponse.

Pourquoi c’est puissant : L’agent apprend quand demander des informations externes, pas seulement quand agir sur ce que vous lui avez donné. La plupart des agents du monde réel en ont besoin. Vous n’êtes plus limité aux données d’entraînement intégrées au modèle.

Quand ça casse : Lorsque la récupération est lente ou que la base de données est peu fiable. Si votre agent doit récupérer des données qui n’existent parfois pas, il hallucine. Si la récupération prend 30 secondes, votre utilisateur attend 30 secondes. La complexité de l’intégration s’accumule rapidement.

3. Agent d’utilisation d’outils (le plus difficile, le plus puissant)

Décision : « Je dois effectuer plusieurs actions en séquence pour résoudre cela. Dans quel ordre ? »

L’agent ne se contente pas de récupérer ou de classer. Il a accès à plusieurs outils — envoyer un e-mail, créer un événement de calendrier, récupérer des données, mettre à jour un enregistrement, envoyer un message Slack — et décide lesquels utiliser et dans quel ordre. Il peut créer un ticket, récupérer des données du ticket, envoyer une notification et enregistrer l’interaction, le tout de manière autonome.

Pourquoi c’est important : C’est là que les agents deviennent véritablement utiles pour les flux de travail complexes. La plupart des processus métier complexes nécessitent plusieurs étapes, plusieurs outils et une prise de décision à chaque étape.

Quand ça casse : Presque constamment, au début. L’agent doit bien comprendre vos outils pour les utiliser correctement. Il doit gérer les erreurs d’un outil avant de passer au suivant. Si une étape échoue, toute la séquence s’effondre à moins que vous n’ayez mis en place une gestion des erreurs. La plupart des échecs des premiers agents se produisent ici.

Comparaison des plateformes : Qu’est-ce qui fonctionne pour les agents no-code

L’évaluation honnête : Si vous voulez le chemin le plus rapide vers un agent fonctionnel, Dify est la seule plateforme conçue avec les agents comme unité principale. Zapier et Make sont des outils de flux de travail qui peuvent simuler des agents — ils fonctionnent, mais ils exigent que vous construisiez en fonction de leurs contraintes. n8n est plus flexible mais nécessite une aisance avec JSON et les API. Bubble est puissant mais fonctionne dans un paradigme complètement différent.

Pour votre premier agent, Dify ou Make est le choix le plus solide. Dify si vous voulez une véritable logique d’agent. Make si vous devez vous intégrer à une douzaine d’outils métier et que la théorie des agents ne vous préoccupe pas.

Étape par étape : Créer votre premier agent de routage

Créons quelque chose de réel. Un classificateur et répondeur d’e-mails de support utilisant Dify (niveau gratuit disponible, aucune carte de crédit requise).

Le scénario : Vous recevez des e-mails de support. Certains concernent la facturation (demandes de remboursement, problèmes de facturation). D’autres sont des bugs produit. D’autres encore sont des demandes de fonctionnalités. Chacun nécessite un modèle de réponse différent et une gestion différente. Actuellement, vous les triez manuellement. Nous automatisons la première étape : classification et réponse automatique.

Étape 1 : Configurer Dify et créer un nouvel agent

• Allez sur dify.ai, inscrivez-vous, créez un espace de travail
• Cliquez sur « Créer une nouvelle application » et sélectionnez « Agent »
• Nommez-le « Classificateur d’e-mails de support »
• Choisissez Claude 3.5 Sonnet comme modèle (il est moins cher que Claude Opus et suffisant pour la classification)

Étape 2 : Définir la tâche de votre agent

Dans le champ de l’invite système, entrez :

Vous êtes un classificateur d'e-mails de support client. Votre travail consiste à :
1. Lire l'e-mail entrant
2. Le classifier comme l'un des : FACTURATION, BUG, DEMANDE_FONCTIONNALITE, AUTRE
3. Fournir une brève réponse accusant réception du problème

Règles :
- Si facturation : mentionnez que quelqu'un du service de facturation fera un suivi dans les 24 heures
- Si bug : reconnaissez le bug et demandez des étapes de reproduction
- Si fonctionnalité : remerciez-les pour leur suggestion et indiquez qu'elle a été enregistrée
- Si autre : demandez poliment des clarifications

Soyez toujours professionnel et empathique. Gardez les réponses en dessous de 100 mots.

Format de sortie :
CLASSIFICATION : [catégorie]
RÉPONSE : [votre texte de réponse]
CONFIANCE : [élevée/moyenne/faible]

Étape 3 : Ajouter des variables d’entrée

Créez une variable d’entrée appelée « corps_email ». C’est là que le texte de l’e-mail proviendra lorsque l’agent s’exécutera.

Étape 4 : Tester avec de vrais e-mails

Dans le panneau de test, collez les e-mails de support réels que vous avez reçus :

Test Entrée 1 :
« Bonjour, j'ai été facturé deux fois pour mon abonnement le mois dernier. Puis-je obtenir un remboursement ? »

Sortie attendue :
CLASSIFICATION : FACTURATION
RÉPONSE : Merci de nous avoir contactés. Nous nous excusons pour le double débit. Notre équipe de facturation examinera votre compte et vous contactera dans les 24 heures avec une solution.
CONFIANCE : élevée

Exécutez-le. Si la classification est correcte et que la réponse est appropriée, passez à l’étape 5. Si elle est incorrecte, ajustez l’invite système — soyez plus précis sur ce qui constitue un « bug » par rapport à « autre », par exemple.

Étape 5 : Connecter à votre e-mail

C’est là que le no-code devient réel. Vous devez connecter l’agent à votre système de messagerie afin qu’il reçoive automatiquement les e-mails entrants. Vos options :

• Zapier + Gmail : Créez une automatisation Zapier qui se déclenche lorsqu’un nouvel e-mail arrive dans une étiquette spécifique, envoie le corps de l’e-mail à votre agent Dify via webhook, et stocke la réponse dans une feuille Google ou la renvoie sous forme de brouillon
• n8n + n’importe quel e-mail : Plus flexible mais nécessite plus de configuration
• Manuel pour MVP : Copiez-collez les e-mails dans Dify manuellement pendant la première semaine. Sérieusement. C’est bien et cela vous permet de valider que l’agent fonctionne avant de l’intégrer à votre système de messagerie

Pour votre premier agent, je recommande les tests manuels pendant une semaine. D’ici la deuxième semaine, vous comprendrez ce que l’agent fait réellement bien et mal, et vous intégrerez la messagerie une fois que vous saurez que l’invite de classification est solide. Cela vous évite de construire une plomberie d’intégration autour d’un agent défectueux.

Les trois erreurs qui détruisent les premiers agents

Erreur 1 : Faire trop confiance au modèle

Vous créez un agent qui semble correct en test, le déployez, et le regardez donner avec assurance de mauvaises réponses sur des données réelles. Cela se produit parce que vos cas de test étaient trop similaires, trop propres, ou manquaient des cas limites qui apparaissent réellement en production.

Correction : Déployez avec vérification humaine au début. Faites examiner chaque décision de l’agent par un humain pour les 50 à 100 premières exécutions. Ce n’est pas éternel — vous collectez des données sur les échecs de l’agent, et il échouera. Une fois que vous voyez le schéma (« l’agent classe mal les e-mails avec plusieurs problèmes 15 % du temps »), vous corrigez l’invite ou le flux de travail, pas seulement l’espoir que le modèle s’améliore.

Erreur 2 : Construire l’utilisation d’outils avant que le routage ne fonctionne

Les débutants sautent souvent le routage de l’agent et passent directement à « Je veux que mon agent récupère des données ET envoie des e-mails ET crée des tickets ET enregistre l’interaction ». Cinq outils, logique complexe, un point de défaillance au milieu de la séquence, et tout s’effondre. Vous construisez pendant trois semaines et n’avez rien qui fonctionne.

Correction : Commencez par un agent de routage. Rendez-le solide comme le roc. Une fois qu’il fonctionne parfaitement pendant deux semaines, ajoutez une étape de récupération. Une fois que c’est stable, ajoutez des outils. La progression est : classer → récupérer des données → agir. Pas tout à la fois.

Erreur 3 : Ne pas définir ce que signifie « fonctionner »

Vous déployez l’agent. Après une semaine, vous n’êtes pas sûr qu’il aide. Les métriques sont vagues (« semble plus rapide ») ou absentes (« j’ai juste l’impression que c’est mieux »). Vous ne pouvez pas améliorer ce que vous ne mesurez pas.

Correction : Définissez les métriques de succès avant le déploiement. Pour le classificateur d’e-mails : précision de la classification (quel pourcentage obtient-il ?), temps de réponse (combien de temps cela prend-il ?), taux de remplacement humain (à quelle fréquence quelqu’un modifie la classification de l’agent ?), réduction des tickets (cela fait-il réellement gagner du temps ?). Mesurez chaque semaine pendant le premier mois. Vous avez besoin de chiffres.

Quand vous êtes prêt à construire un véritable agent de récupération

Une fois que votre agent de routage est stable, le niveau supérieur consiste à lui donner accès à des informations. C’est là que les agents deviennent véritablement puissants.

Le schéma : Entrée → Décision de requête (« Ai-je besoin de données externes ? ») → Récupération → Décision → Action

Exemple : Un agent de support client qui prend les e-mails entrants, interroge votre base de connaissances pour la documentation pertinente, et l’utilise pour rédiger de meilleures réponses. Ou un agent commercial qui prend un prospect, interroge votre CRM pour l’historique du compte, et décide quelle offre proposer.

Pour construire cela, vous avez besoin :

• Une source de données : Base de connaissances (Notion, Confluence, base de données personnalisée), CRM (Salesforce, Pipedrive), ou tout système que vous pouvez interroger via API
• Une méthode de récupération : Embeddings vectoriels (recherche sémantique) ou recherche par mots-clés traditionnelle. La recherche vectorielle est plus précise mais nécessite une configuration. La recherche par mots-clés est plus rapide mais plus basique.
• Un moyen de transmettre ces données au LLM : La plupart des plateformes le font automatiquement — vous dites à l’agent « voici les données que vous avez récupérées, maintenant décidez quoi faire »

Dans Dify, vous pouvez ajouter cela en créant un nœud « Connaissance » — téléchargez des PDF, des documents, ou connectez-vous à une base de données externe. L’agent apprend à l’interroger si nécessaire. Dans Make ou Zapier, vous le faites avec une étape « récupérer des données » que l’agent peut appeler.

Le défi : s’assurer que l’agent récupère réellement des informations utiles, pas des déchets. Une recherche vectorielle mal configurée transmettra avec assurance des données non pertinentes à l’agent, et il les utilisera quand même. Vous devez tester et mesurer cela impitoyablement avant de vous y fier en production.

Exemple de travail réel : Le répondeur par e-mail + recherche CRM

Étendsons le classificateur d’e-mails. Désormais, lorsqu’un e-mail de support client arrive, l’agent doit :

1. Classifier l’e-mail
2. Rechercher le client dans votre CRM en utilisant son adresse e-mail
3. Utiliser son historique (problèmes précédents, niveau d’abonnement, date de la dernière interaction) pour rédiger une réponse plus personnalisée
4. Envoyer la réponse et l’enregistrer dans le CRM

Invite système pour cet agent :

Vous êtes un agent de support client ayant accès à un système CRM. Lorsque vous recevez un e-mail :

1. Extrayez l'adresse e-mail du client
2. Recherchez son compte dans le CRM
3. Classez son problème (FACTURATION, BUG, DEMANDE_FONCTIONNALITE, AUTRE)
4. Rédigez une réponse personnalisée qui :
   - Fait référence à l'historique de son compte si pertinent
   - Reconnaît son niveau d'abonnement
   - Propose des solutions basées sur ses interactions passées

Soyez toujours empathique. Si vous n'avez pas ses données CRM, reconnaissez-le et fournissez une réponse générale utile.

Format de sortie :
EMAIL_CLIENT : [e-mail]
CLASSIFICATION : [catégorie]
RÉSULTAT_RECHERCHE_CRM : [résumé de ce que vous avez trouvé, ou « aucun compte trouvé »]
RÉPONSE : [votre réponse personnalisée]
PROCHAINE_ÉTAPE : [enregistrer dans le CRM / escalader à la facturation / fermer le ticket]

Dans Dify, vous ajouteriez un nœud « Outil » qui se connecte à l’API de votre CRM (la plupart des CRM en ont une). L’agent apprend à l’appeler automatiquement. Dans Make/Zapier, vous utiliseriez une étape « Rechercher » dans votre action CRM qui transmet l’e-mail du client.

Testez cela avec 20 vrais e-mails de support passés. Mesurez la précision, la qualité de la réponse et si cela vous fait réellement gagner du temps. Si cela fonctionne 80 % du temps dans vos tests, déployez en production avec une revue humaine de chaque réponse pendant la première semaine.

Mesurer et itérer : La boucle de l’agent

Le déploiement n’est pas la fin. C’est le début.

Mettez en place la journalisation immédiatement. Chaque fois que l’agent s’exécute, enregistrez : l’entrée, la sortie, la classification, si un humain l’a remplacée, et le résultat réel. Dans Make ou Zapier, enregistrez dans une feuille Google. Dans Dify, exportez les analyses chaque semaine.

Après deux semaines de données de production, recherchez des schémas :

• Sur quelles classifications est-il erroné ? (Ajustez l’invite pour ces catégories.)
• Quel pourcentage de sorties nécessite une correction humaine ? (Objectif : moins de 5 % après itération.)
• Existe-t-il des cas limites courants que vous n’aviez pas prévus ? (Ajoutez-les à votre ensemble de tests.)
• Est-ce réellement plus rapide que de le faire manuellement ? (Sinon, pourquoi ? La vitesse n’est pas la seule métrique, mais elle doit en être une.)

Mettez à jour l’invite système de l’agent en fonction de ce que vous apprenez. Redéployez. Mesurez à nouveau. Ce cycle — déployer, mesurer, améliorer, répéter — est la seule façon pour les agents de s’améliorer.

La plupart des premiers agents nécessitent trois à quatre itérations avant d’être véritablement utiles. À l’itération trois, vous saurez ce dont vous avez réellement besoin de l’agent, et vous pourrez construire en conséquence.

Votre première action : Choisissez un petit problème et commencez

Pas demain. Pas la semaine prochaine. Aujourd’hui.

Trouvez une tâche récurrente qui vous prend 15 à 30 minutes par semaine. Pas votre travail le plus important. Pas quelque chose qui nécessite une sortie parfaite à chaque fois. Quelque chose qui est principalement routinier avec des exceptions occasionnelles.

Exemples qui fonctionnent pour les premiers agents : triage d’e-mails, qualification de prospects, classification des dépenses, routage des tickets d’assistance, résumé des notes de réunion, validation de la saisie de données.

Créez un compte Dify dès maintenant (cinq minutes). Construisez un agent de routage pour cette tâche unique (deux heures, peut-être trois). Exécutez-le manuellement pendant une semaine, en testant avec des données réelles. Mesurez la fréquence à laquelle il obtient le bon résultat.

S’il est précis à 80 % ou plus, intégrez-le à votre flux de travail réel. S’il est inférieur à 80 %, ajustez l’invite et retestez. Ne sur-ingénieriez pas. N’attendez pas la perfection. Atteignez le stade « utile » et itérez à partir de là.

C’est un agent IA qui fonctionne. C’est le début.