Comment Créer Votre Premier Agent IA (+Modèle de Workflow Gratuit)
Eliott Ardisson
Founder & CEO - Basalt Studio
Comment créer un agent IA pour votre PME : architecture, audit des processus, outils recommandés et modèle de workflow concret à adapter.
Points clés
- Un agent IA efficace repose sur quatre composants fondamentaux : perception, prise de décision, action et mémoire. Comprendre leur rôle avant de construire évite la majorité des blocages.
- L’audit de vos processus actuels est la première étape, pas la dernière. Passer 2-3 jours à cartographier vos workflows avant tout développement vous économise plusieurs semaines de reprise.
- Trois approches techniques s’offrent à vous selon votre budget et vos compétences : développement sur mesure, frameworks existants ou automatisation via des outils comme n8n. Chacune a un profil de risque différent.
- Les projets d’agents IA échouent rarement à cause du choix d’outil. Ils échouent parce que les données sources sont mal structurées ou parce que les cas d’exception n’ont pas été anticipés.
- Un déploiement progressif (10% du trafic en premier, puis montée en charge) réduit les risques opérationnels et donne le temps à vos équipes de s’adapter.
Ce qu’un agent IA fait concrètement pour une PME
Un agent IA, c’est un système logiciel capable d’analyser des informations, de prendre une décision et d’exécuter une action, sans intervention humaine à chaque étape. Il ne s’agit pas d’un chatbot qui répond à des questions prédéfinies, ni d’un simple script d’automatisation. C’est un programme qui peut lire un email entrant, en extraire l’intention, mettre à jour votre CRM, et envoyer une réponse adaptée, le tout en quelques secondes.
Pour une PME de 20 à 100 personnes dans les services professionnels, l’immobilier ou la comptabilité, cela se traduit concrètement par : qualifier les leads entrants sans que personne ne touche un clavier, traiter les demandes de devis standardisées, ou mettre à jour des dossiers clients après chaque échange. Les gains de productivité que McKinsey et d’autres cabinets documentent depuis plusieurs années dans leurs recherches sur l’adoption de l’IA s’expliquent en grande partie par ce type d’automatisation décisionnelle, pas uniquement par la génération de texte.
Ce guide vous explique comment construire ce type d’agent, depuis l’audit initial jusqu’au déploiement opérationnel.
Comprendre les quatre composants d’un agent IA
Avant d’écrire une ligne de code ou de configurer un outil, il faut savoir ce qu’on assemble. Un agent IA bien conçu repose sur quatre briques distinctes.
La perception est la capacité de l’agent à recevoir des informations depuis son environnement. Cela peut être un email entrant, un formulaire web soumis, un webhook déclenché par votre CRM, ou un fichier déposé dans un dossier partagé. La qualité de la perception détermine tout ce qui suit : un agent qui reçoit des données mal formatées prendra de mauvaises décisions.
La prise de décision est le cœur du système. Deux mécanismes coexistent dans la plupart des agents réels : les règles explicites (si le montant est inférieur à 100 €, approuver automatiquement) et le raisonnement par modèle de langage (LLM) pour les situations ambiguës qui nécessitent de l’interprétation. En pratique, on combine les deux : les règles pour les cas clairs, le LLM pour le reste.
L’action est ce que l’agent fait après avoir décidé. Appeler une API, créer un enregistrement dans votre CRM, envoyer un email, déclencher un autre workflow, mettre en attente pour revue humaine. La liste des actions possibles est directement liée aux intégrations que vous avez construites.
La mémoire permet à l’agent de fonctionner avec du contexte. La mémoire à court terme conserve le fil d’une conversation ou d’un traitement en cours. La mémoire à long terme stocke les préférences utilisateurs, les historiques d’interaction, les bases de connaissances métier. Sans mémoire correctement structurée, chaque interaction repart de zéro.
Étape 1 : Auditer vos processus avant de construire quoi que ce soit
C’est l’étape que la majorité des équipes veulentt sauter. C’est aussi celle qui détermine si le projet aboutit ou non.
Commencez par lister tous les processus répétitifs de votre organisation. Dans un cabinet comptable, ça ressemble à : tri des emails entrants, relances clients, collecte de pièces justificatives, préparation de reporting périodique. Dans une agence de recrutement, c’est : tri de CV, planification d’entretiens, mise à jour des fiches candidats, communication avec les clients sur l’avancement.
Pour chaque processus candidat, documentez ces cinq éléments :
- Fréquence : combien de fois par jour ou par semaine ce processus se produit-il ?
- Durée : combien de temps prend une occurrence ?
- Complexité décisionnelle : les décisions sont-elles basées sur des règles simples ou nécessitent-elles du jugement ?
- Sources de données : les informations viennent-elles d’une ou plusieurs sources ? Sont-elles structurées ?
- Outils impliqués : quels logiciels sont touchés par ce processus ?
Une fois cette liste établie, priorisez selon deux critères : la fréquence multipliée par la durée (volume de temps récupérable), et la régularité des décisions à prendre (plus c’est prévisible, plus c’est automatisable). Les processus à fort volume et à décisions répétitives sont vos cibles prioritaires.
Un cabinet juridique, par exemple, pourrait identifier que 60% des emails entrants sont des demandes de rendez-vous ou des demandes de statut de dossier, deux catégories qui suivent des règles très prévisibles et qui consomment du temps de collaborateurs qualifiés.
Étape 2 : Choisir votre approche technique
Trois options s’offrent à vous, avec des niveaux de contrôle, de coût et de complexité différents.
Le développement sur mesure (TypeScript ou Python, avec une API comme Claude via Anthropic SDK ou OpenRouter, une base de données comme Convex ou PostgreSQL, et un serveur Next.js ou FastAPI) vous donne le contrôle total. Chaque comportement est explicitement codé. C’est l’approche recommandée si vos processus sont suffisamment spécifiques pour que les solutions génériques ne s’y adaptent pas, ou si vous disposez d’une ressource technique interne ou d’un prestataire dédié. La contrepartie : le temps de développement est plus long et les ajustements nécessitent du code.
Les frameworks d’orchestration (LangChain, LlamaIndex, CrewAI) fournissent des abstractions prêtes à l’emploi pour les patterns les plus courants : agents multi-étapes, mémoire vectorielle, appels d’outils. Utiles si vous avez des développeurs à l’aise avec Python et que vous voulez aller plus vite sans partir de zéro. La documentation de ces frameworks est souvent plus avancée que le code lui-même, donc anticipez du temps de débogage.
Les plateformes d’automatisation visuelle comme n8n permettent de construire des workflows agent sans écrire de code, en connectant des nœuds via une interface graphique. N8n est particulièrement adapté pour les PME qui veulent automatiser des processus bien définis sans maintenir une codebase complexe. L’outil supporte les appels LLM, la logique conditionnelle, et des centaines d’intégrations natives. C’est souvent le point d’entrée le plus rapide pour un premier agent opérationnel.
Le choix entre ces trois options dépend moins du budget que de la nature de votre besoin : complexité des décisions, nombre d’intégrations, et tolérance à la maintenance technique.
Étape 3 : Concevoir la structure de données de votre agent
Un agent IA ne vaut que ce que valent ses données d’entrée. Avant de configurer la logique de décision, assurez-vous que vos données sources sont exploitables.
Mémoire de session : pendant le traitement d’une demande, l’agent a besoin d’un contexte immédiat. Qui est le demandeur ? Quelle est l’action en cours ? À quelle étape du workflow sommes-nous ? Cette mémoire est éphémère et stockée en mémoire vive ou dans un cache comme Redis.
Mémoire persistante : les informations qui doivent traverser plusieurs interactions. Historique des échanges avec un client, préférences enregistrées, statut d’un dossier. Cette mémoire est stockée en base de données et consultée à chaque nouveau traitement.
Base de connaissances : les procédures métier, les politiques, les FAQ, la documentation produit. C’est ce que l’agent consulte pour répondre à des questions ou prendre des décisions contextuelles. Dans les implémentations modernes, cette base est souvent indexée sous forme vectorielle pour permettre une recherche sémantique efficace.
L’erreur la plus fréquente ici est de sous-estimer la qualité réelle des données existantes. Les emails non triés, les champs CRM remplis de façon incohérente, les documents en formats variés : tout cela crée des frictions à l’exécution. Nettoyez et structurez vos données sources avant de les brancher à un agent.
Étape 4 : Implémenter la logique de décision
La logique de décision d’un agent se construit en couches.
La première couche est celle des règles explicites. Ce sont les décisions qui ne nécessitent aucune interprétation : un remboursement en dessous d’un certain seuil est approuvé automatiquement, une demande de type “urgence” est escaladée immédiatement, un email provenant d’un domaine client connu est traité différemment d’un email inconnu. Ces règles doivent être documentées et codifiées avant de toucher au LLM.
La deuxième couche est celle du raisonnement par LLM. Elle intervient pour les situations ambiguës : classifier l’intention d’un message complexe, évaluer le sentiment d’une réclamation, reformuler une réponse en fonction du ton de la conversation. Le LLM travaille avec un prompt système qui définit son rôle, ses contraintes et le format de sa réponse.
La troisième couche est la planification pour les tâches multi-étapes. Quand un objectif nécessite plusieurs actions séquentielles (récupérer les informations du client, vérifier le statut du dossier, générer le document, envoyer la notification), l’agent doit décomposer cet objectif en sous-tâches et les exécuter dans l’ordre. C’est ce qu’on appelle un agent “agentic” à proprement parler, par opposition à un simple appel LLM unique.
Prévoyez systématiquement un mécanisme d’escalade vers un humain. Tout agent bien conçu doit savoir reconnaître les situations où il ne doit pas décider seul : score de confiance insuffisant, situation non prévue dans les règles, demande impliquant des données sensibles. En pratique, dans notre travail d’accompagnement de PME pour déployer ce type de système, c’est souvent l’absence de ce mécanisme d’escalade qui crée les premières frictions avec les équipes opérationnelles.
Étape 5 : Connecter vos outils existants
Un agent IA isolé ne produit aucune valeur. Sa valeur vient de sa capacité à agir sur vos systèmes existants.
Commencez par lister tous les outils que votre agent doit pouvoir lire ou modifier :
| Outil | Direction | Type de données | Fréquence estimée |
|---|---|---|---|
| Boîte email (Gmail, Outlook) | Lecture + écriture | Messages, pièces jointes | Temps réel |
| CRM | Lecture + écriture | Contacts, opportunités, activités | Continue |
| Agenda (Google Calendar, Outlook) | Lecture + écriture | Disponibilités, rendez-vous | À la demande |
| Outil de facturation | Lecture + écriture | Factures, statuts paiement | Quotidien |
| Messagerie d’équipe (Slack, Teams) | Écriture | Notifications, alertes | Événementiel |
Pour chaque connexion, vérifiez trois choses avant de commencer : est-ce qu’une API est disponible et documentée, quelles sont les limites de taux d’appel (rate limits), et quelles permissions sont nécessaires pour lire et écrire les données dont vous avez besoin.
Construisez un connecteur dédié par intégration, avec gestion des erreurs, retry automatique en cas de timeout, et logs structurés de chaque appel. Ne mélangez pas la logique métier et les appels API dans le même code : ça rend la maintenance et le débogage beaucoup plus difficiles.
Étape 6 : Tester avant de déployer
Les tests d’un agent IA se font à trois niveaux.
Tests unitaires : chaque composant séparément. Le module d’analyse de sentiment retourne-t-il les bons résultats sur un ensemble de messages tests ? Le connecteur CRM crée-t-il bien l’enregistrement avec les bons champs ? Ces tests s’écrivent et s’automatisent.
Tests d’intégration : le workflow complet de bout en bout. Une demande entrante de type X produit-elle bien les actions Y et Z dans les systèmes concernés ? Testez avec des données réalistes, pas des données parfaites. Les données réelles sont rarement propres.
Tests d’acceptation : des scénarios réels, exécutés par les personnes qui vont utiliser le système au quotidien. Pas les développeurs, les utilisateurs finaux. Quatre à six scénarios couvrant les cas les plus fréquents et au moins deux cas d’exception suffisent pour une première validation.
Définissez vos critères de succès avant de tester, pas après. Temps de réponse cible, taux d’erreur acceptable, actions correctement exécutées sur un échantillon de N requêtes. Sans critères prédéfinis, les tests deviennent subjectifs et la décision de déploiement est prise sur la base du ressenti, pas des données.
Étape 7 : Déployer progressivement et monitorer
Un déploiement en une seule fois sur l’ensemble du trafic est le moyen le plus sûr de créer une crise opérationnelle. Adoptez une approche par phases.
Phase 1 - Pilote : routez 10% du trafic réel vers l’agent pendant une semaine. Observez les métriques en temps réel. Corrigez immédiatement ce qui ne fonctionne pas. Recueillez le feedback des utilisateurs concernés.
Phase 2 - Montée en charge progressive : augmentez le pourcentage par paliers (25%, 50%, 75%) en validant les métriques à chaque étape. N’augmentez pas si un indicateur dépasse son seuil critique.
Phase 3 - Déploiement complet : bascule totale avec un plan de rollback documenté et prêt à activer si nécessaire.
Les métriques à surveiller en production :
- Temps de réponse moyen et percentiles (P95, P99)
- Taux de succès des actions (actions exécutées sans erreur / total)
- Taux d’escalade vers un humain (si ce taux monte, quelque chose change dans les données entrantes)
- Disponibilité du service
Structurez vos logs dès le début. Chaque interaction doit être traçable : identifiant de requête, actions exécutées, résultat, durée, erreurs éventuelles. Sans logs structurés, vous déboguez à l’aveugle.
Modèle de workflow : traitement automatisé des demandes entrantes
Voici un modèle adaptable à la plupart des PME de services. Le déclencheur est la réception d’un email sur une adresse de support ou de contact.
Étape 1 — Analyse : extraire l’intention, la catégorie, l’urgence et le sentiment du message entrant via un appel LLM avec un prompt structuré. Stocker le résultat dans la mémoire de session.
Étape 2 — Classification et routage : appliquer les règles métier. Si la catégorie est “demande de devis standard” et que le score de confiance dépasse le seuil défini, passer à l’étape 3. Sinon, router vers une file de traitement humain avec les informations extraites pré-remplies.
Étape 3 — Action automatisée : créer le ticket dans le CRM, générer une réponse personnalisée à partir d’un template adapté à la catégorie détectée, envoyer la réponse, mettre à jour le statut dans le système de suivi.
Étape 4 — Escalade conditionnelle : si l’urgence est critique, si le sentiment est très négatif, ou si le score de confiance est insuffisant à n’importe quelle étape, notifier immédiatement un membre de l’équipe avec le contexte complet de la demande.
Ce type de workflow, correctement configuré, peut traiter la grande majorité des demandes entrantes routinières sans intervention humaine, tout en laissant les cas complexes ou sensibles aux collaborateurs les mieux placés pour les gérer.
Erreurs courantes et comment les éviter
Commencer par l’outil plutôt que par le problème. Choisir n8n ou un framework d’agent avant d’avoir cartographié le processus à automatiser conduit invariablement à construire quelque chose qui ne correspond pas aux besoins réels.
Ignorer la qualité des données sources. Un agent qui lit un CRM rempli de façon incohérente produira des résultats incohérents. Nettoyez avant de brancher.
Ne tester qu’en conditions idéales. Les données réelles contiennent des fautes de frappe, des champs vides, des formats inattendus. Vos tests doivent en tenir compte.
Déployer sans escalade humaine. Tout agent en production doit avoir un chemin clairement défini pour les cas où il ne doit pas décider seul. L’absence de ce mécanisme érode rapidement la confiance des équipes.
Négliger la maintenance post-déploiement. Un agent IA n’est pas un projet qu’on livre et qu’on oublie. Les données changent, les processus évoluent, les modèles de langage sont mis à jour. Prévoyez du temps de revue mensuelle.
Construire un agent IA pour votre PME n’est pas un projet de recherche. C’est un projet d’implémentation qui suit des étapes connues et prévisibles, à condition de ne pas brûler les étapes. L’audit des processus, la qualité des données, les tests avec de vrais utilisateurs et le déploiement progressif : ces quatre points font la différence entre un agent qui tourne en production et un prototype qui reste sur une branche de développement.
Si vous voulez un regard extérieur sur vos processus avant de vous lancer, ou si vous avez déjà un projet en tête et que vous cherchez à valider votre approche, vous pouvez réserver un appel stratégie IA avec Eliott. Pas de présentation commerciale, juste une conversation sur ce qui a du sens pour votre situation.