Comment créer un agent IA : la carte complète pour bien choisir

La demande arrive chez BGT sous des formes variées, mais c’est toujours la même question : « on voudrait un agent qui fasse X, on s’y prend comment ? » Derrière le mot agent, il y a une réalité précise, que nous avons détaillée dans notre guide de l’IA agentique : un système qui perçoit une situation, décide, puis agit sur vos outils, sans qu’un humain pilote chaque étape. La bonne nouvelle : en 2026, construire son premier agent n’exige ni équipe de développeurs ni budget à six chiffres. La mauvaise : la plupart des projets échouent sur des décisions prises avant d’ouvrir le moindre outil. Voici la carte que nous utilisons, dans l’ordre des vraies questions : quoi confier, quel type de système, où le faire vivre, et qui le construit.

La décision qui compte se prend avant d’ouvrir un outil

Un agent réussi, c’est 80 % de cadrage et 20 % de construction. Trois questions à trancher par écrit avant tout le reste, littéralement sur une page.

Quelle tâche, exactement ? Un agent ne remplace pas « le service client » : il traite une tâche délimitée, récurrente, dont le succès se vérifie. Trier des emails entrants selon des règles métier. Surveiller des appels d’offres et pré-remplir une grille d’analyse. Relancer des devis sans réponse. Si vous ne pouvez pas décrire la tâche en trois phrases avec un critère de réussite, l’agent est prématuré ; c’est la première cause d’échec que nous constatons.

Quels accès ? Pour agir, un agent a besoin d’entrer dans vos outils : boîte mail, CRM, drive, agenda. Chaque accès est un pouvoir que vous lui déléguez, et la gestion de ces clés mérite la même rigueur qu’avec un prestataire humain : comptes dédiés, droits minimaux, révocables. C’est aussi là qu’intervient le protocole MCP, la prise standard qui branche une IA sur vos outils et qui a fait exploser ce que les agents savent toucher.

Quels garde-fous ? Décidez, avant la mise en route, ce que l’agent fait seul et ce qu’il propose sans exécuter. La règle que nous appliquons partout : les actions visibles de l’extérieur (envoyer un email, publier, payer) passent par une validation humaine tant que la confiance ne s’est pas installée. Un agent qui prépare et demande vaut mieux, les trois premiers mois, qu’un agent qui agit et surprend.

Workflow orchestré ou agent agentique : la ligne de partage

C’est la question que nous posons en premier sur chaque projet, parce qu’elle sépare deux familles de systèmes qui ne répondent pas au même besoin et ne produisent pas le même rendu.

Le workflow orchestré, c’est un chemin tracé d’emblée : un déclencheur, des étapes, des embranchements prévus, et de l’IA insérée là où elle apporte quelque chose (résumer, classer, extraire, rédiger un premier jet). Le parcours est écrit une fois pour toutes ; à chaque exécution, il suit les mêmes étapes et les mêmes règles. C’est le territoire de n8n ou Make, et c’est la bonne réponse dès que la tâche est répétitive, cadrée, à volume : le rendu est prévisible, chaque exécution se trace, et une dérive se voit immédiatement.

L’agent agentique, c’est l’inverse : on lui donne un objectif, des outils et des limites, et c’est le modèle qui décide du chemin, à chaque exécution, en fonction de ce qu’il rencontre. Il peut enchaîner des étapes imprévues, changer d’approche en cours de route, gérer le cas tordu qu’aucun embranchement n’avait anticipé. C’est le territoire des assistants outillés et des frameworks agentiques. Le rendu est plus riche et plus souple ; il est aussi moins reproductible d’une exécution à l’autre, ce qui exige des garde-fous plus sérieux et une supervision qui dure.

La règle de choix tient en une phrase : si vous pouvez dessiner le déroulé sur un tableau blanc, c’est un workflow ; si le déroulé dépend de ce que l’agent va découvrir, c’est de l’agentique. Et dans la pratique, les systèmes qui tournent bien sont souvent des hybrides : un workflow solide pour l’ossature, qui délègue à un agent la seule étape demandant du jugement, ou un agent qui déclenche des workflows éprouvés pour les actions sensibles. Le trieur d’emails est typiquement un workflow avec une étape d’IA ; l’assistant qui instruit un dossier complexe de bout en bout est un agent.

Où vit l’agent, et qui le construit

Une fois le type choisi, restent deux décisions plus simples qu’il n’y paraît.

Où il vit. Trois habitats existent : une plateforme d’automatisation visuelle (n8n, Make, Copilot Studio), du code (scripts et SDK des éditeurs de modèles), ou l’environnement d’un assistant IA lui-même (un Claude outillé de vos accès, qui exécute sa mission en session). Le critère de choix n’est pas technique, il est organisationnel : qui pourra maintenir l’agent dans six mois, et où saura-t-il le faire ? Une équipe ops à l’aise avec le visuel maintiendra un n8n ; un système intégré à un produit à fort volume justifie du code ; une mission souple et évolutive vit bien dans l’assistant.

Qui le construit. Voilà la vraie nouveauté de 2026, et elle traverse tous les habitats : l’IA sait construire avec vous. Chez BGT, Claude Code nous sert à assembler les workflows n8n que nous livrons, à écrire nos outils Python, et à porter lui-même certains agents. La frontière entre « no-code » et « code » perd de son importance quand l’assistant écrit et explique le code ; ce qui compte, c’est que le résultat vive dans un endroit où quelqu’un de chez vous peut le comprendre et le reprendre.

Un mot d’honnêteté, parce que le marché survend ce point : l’IA constructrice abaisse la barrière du code, pas celle de la rigueur. Décrire le besoin sans ambiguïté, écrire des consignes qui tiennent, vérifier ce qui a été construit, comprendre pourquoi l’agent dévie, itérer : c’est un savoir-faire qui s’apprend en semaines de pratique, pas en une démo, même dans le parcours pas à pas que nous avons documenté. Comptez une demi-journée pour un prototype qui impressionne, et plusieurs semaines de rodage pour un système auquel vous confiez de vraies tâches sans le surveiller. Quiconque vous promet le second au prix du premier vous vend le prototype.

Les deux premiers agents qui marchent presque toujours

Le meilleur premier projet rend un service visible chaque semaine sans mettre personne en danger. Deux candidats sortent du lot dans nos déploiements, et ce sont tous deux des hybrides à dominante workflow, ce qui n’est pas un hasard : on apprend le métier sur du prévisible.

Le trieur de flux entrant. Emails, candidatures, demandes de contact : le workflow lit, une étape d’IA qualifie selon vos règles, range et prépare les réponses types, un humain valide l’envoi. Faible risque, gain immédiat, et un excellent terrain pour apprendre à écrire des consignes qui tiennent.

Le veilleur qui pré-mâche. Le système surveille une source (appels d’offres, mentions, tarifs concurrents), filtre selon vos critères, et une étape agentique instruit les cas retenus avant de livrer une synthèse à heure fixe. C’est ce que nous avons construit pour la veille d’appels d’offres d’un client : la sélection humaine du matin est passée d’une heure à dix minutes, et le système ne décide rien, il prépare.

Dans les deux cas, la même trajectoire : deux à quatre semaines en mode « il propose, vous validez », puis l’autonomie s’élargit à mesure que le taux de reprise baisse. Quand vous ne corrigez presque plus rien pendant plusieurs semaines, sur des cas suffisamment variés, le système est prêt pour la suite ; c’est la version opérationnelle de la logique cas d’usage avant technologie qui fait réussir les projets d’IA en entreprise.

Ce qui fait échouer, et comment l’éviter

Trois pièges reviennent dans les projets que nous reprenons.

Le périmètre gonflé : l’agent devait trier les emails, on lui a ajouté la facturation, il ne fait plus rien correctement. Un agent, une tâche ; le deuxième agent est un autre projet.

L’absence de journal : personne ne sait ce que l’agent a fait la semaine dernière, la confiance s’érode au premier incident. Exigez une trace lisible de chaque action dès le premier jour, et c’est doublement vital sur la partie agentique, celle dont le chemin change à chaque exécution.

L’agent orphelin : construit par un stagiaire parti en septembre, il tourne sans propriétaire jusqu’à la première casse. Nommez un responsable avant la mise en route ; si personne ne veut l’être, le sujet n’était pas mûr.

Le fil rouge de ces trois pièges : la réussite d’un agent est une affaire d’organisation au moins autant que d’outil. Cadrer petit, choisir le bon type de système, tracer tout, nommer un propriétaire, élargir ensuite. C’est le savoir-faire qui s’apprend sur le premier agent et qui rend les suivants sensiblement plus rapides à déployer.

FAQ : créer son premier agent IA