Créer un agent IA : de l’idée au premier agent, avec API et MCP

Créer un agent IA ne consiste pas seulement à écrire « tu es mon assistant » dans une interface. Il faut organiser un circuit : recevoir une demande, retrouver les bonnes informations, choisir une opération, vérifier son résultat et savoir quoi faire quand une étape échoue. Un bon premier projet rend ce circuit visible. Il ne cherche pas à automatiser toute une activité dès le départ.

Ce guide vous aide à préparer un pilote, seul ou avec un prestataire. Nous suivrons un exemple fictif : une association souhaite préparer les demandes d’inscription à ses ateliers. L’agent devra rapprocher un message du catalogue, relever les informations manquantes et produire une fiche à relire. Il ne décidera pas de l’admission. Vous repartirez avec une architecture, une méthode pour choisir vos connexions, une consigne et des critères de réception, sans supposer qu’un outil particulier convient à tous.

Définir ce que l’agent doit terminer

« Gérer les inscriptions » mélange plusieurs tâches : comprendre le message, vérifier l’activité, rechercher une place, confirmer l’inscription, éventuellement demander un paiement. Commencez par la partie dont vous pouvez examiner le résultat sans ambiguïté.

Pour notre pilote, une demande est traitée lorsque le responsable reçoit une fiche contenant l’activité identifiée, la date demandée, les éléments manquants et un brouillon de réponse. Une fiche incomplète mais correctement signalée vaut mieux qu’une confirmation inventée.

Voici le cadrage à transmettre à la personne qui réalise le projet :

Élément	Décision pour ce pilote
Déclencheur	Un message ajouté au dossier « Inscriptions à préparer »
Sources	Message d’origine et catalogue approuvé des ateliers
Informations recherchées	Activité, date souhaitée, nom et adresse de réponse
Livrable	Fiche à vérifier et brouillon, jamais confirmation d’admission
Limites	Pas d’envoi, de paiement ou de modification des places disponibles
Responsable	La personne qui examine les fiches et traite les exceptions
Réussite	Moins de temps par dossier correct, relecture comprise

Avant de choisir une plateforme, prenez quelques messages représentatifs et réalisez ce parcours à la main. Notez chaque recherche et chaque décision. Si personne ne sait expliquer pourquoi un dossier est complet, l’agent ne résoudra pas ce flou en recevant davantage de documents.

Un agent n’est pas nécessaire à chaque étape

Un workflow suit un chemin prédéfini ; un agent peut choisir ses étapes et ses outils selon la situation. Cette distinction reste utile, même si les produits combinent les deux. Anthropic la présente dans son article de référence, qui avertit aussi que l’outillage a évolué depuis sa publication initiale. Source : Building effective agents.

Dans notre exemple, le modèle peut reconnaître que « l’atelier photo du samedi » correspond à une activité du catalogue. En revanche, vérifier la présence d’une adresse, retrouver un identifiant déjà traité ou enregistrer un statut ne nécessite pas forcément son jugement.

Trois montages sont donc possibles :

• Automatisation à règles : adaptée si toutes les demandes viennent d’un formulaire standard et si chaque champ possède un traitement déterminé.
• Workflow avec étape IA : adapté si le parcours est stable, mais qu’il faut comprendre du texte libre. Le modèle extrait ou rapproche ; le workflow contrôle et enregistre.
• Agent avec plusieurs outils : utile si la demande exige des recherches différentes selon son contenu. Il peut consulter le catalogue, demander un détail ou retrouver un dossier existant.

Pour l’association, nous choisirions d’abord le deuxième montage. Ajouter une boucle autonome n’apporte rien si chaque dossier réclame exactement les mêmes opérations. On pourra l’introduire lorsqu’un besoin précis, observé pendant les essais, justifiera cette liberté supplémentaire.

API, outil d’agent, MCP : ce qui change réellement

Ces notions ne constituent pas trois générations dont la dernière rendrait les précédentes obsolètes. Elles désignent des niveaux différents.

Une API est une interface utilisée par un programme pour demander une opération à un service. Un logiciel d’inscription peut, par exemple, proposer une API pour rechercher un atelier. Un outil d’agent est une capacité présentée au modèle avec une description et des paramètres : « chercher les ateliers correspondant à ces mots ». Le code qui exécute cet outil peut appeler cette API, consulter une base ou lancer un workflow.

MCP, Model Context Protocol, standardise les échanges entre une application IA et des serveurs qui exposent des capacités. L’application joue le rôle d’hôte, s’appuie sur un client MCP et dialogue avec un serveur local ou distant. Le protocole ne choisit pas l’objectif métier ni le degré d’autonomie de votre agent. La documentation actuelle consultée renvoie vers la version du 28 juillet 2026. Source : architecture MCP.

Un serveur MCP distingue notamment des tools, opérations appelables, des resources, données accessibles pour le contexte, et des prompts, modèles d’instructions. Découvrir un outil et l’appeler sont deux opérations distinctes. Tous les serveurs n’exposent pas forcément les trois catégories. Source : capacités des serveurs MCP.

Appliquons cela à notre projet, avec des noms purement illustratifs :

Besoin	Capacité proposée	Réalisation possible
Lire les règles d’inscription	Ressource « consignes des ateliers »	Document approuvé rendu accessible à l’application
Trouver l’atelier	Outil chercher_ateliers	Serveur MCP appelant l’API du catalogue
Préparer la fiche	Outil preparer_dossier	Workflow qui valide les champs puis enregistre un brouillon
Réutiliser la consigne	Modèle « préparer une inscription »	Prompt proposé à l’utilisateur

MCP peut donc utiliser une API derrière le serveur. Il ne dispense pas de disposer du compte, des droits ou de l’opération nécessaire. Si le serveur expose seulement la recherche d’ateliers, il ne saura pas créer une inscription parce que vous l’aurez demandé dans une phrase.

Choisir sa connexion sans compliquer le projet

Commencez par inventorier les opérations exactes, pas les logos disponibles. « Connecté à la messagerie » ne précise ni les dossiers lisibles ni la possibilité de créer un brouillon sans envoyer.

Un connecteur natif suffit si votre plateforme propose déjà les actions nécessaires, avec les droits et les résultats attendus. Vérifiez un message réel de test et la sortie retournée. Une intégration affichée dans un catalogue n’est pas une preuve de fonctionnement pour votre compte.

Une API directe convient si vous maîtrisez le code, si une opération manque au connecteur ou si vous devez contrôler précisément les paramètres et les erreurs. Demandez qui maintiendra cette intégration lorsque le service évoluera. Le bénéfice du contrôle doit compenser cet entretien.

MCP devient intéressant lorsqu’un serveur adapté expose les bonnes capacités à une application compatible, ou lorsque plusieurs applications doivent réutiliser une interface commune. Examinez qui exploite le serveur, quelles données le traversent, quelles fonctions sont disponibles et comment retirer l’accès. Choisissez-le pour une intégration utile, pas pour ajouter un acronyme au projet.

Le no-code n’est pas l’opposé de MCP ou des API : il décrit une manière d’assembler le système. Un même workflow visuel peut combiner un connecteur, une requête API et un outil MCP. Le tutoriel n8n montre plusieurs voies de construction ; son intérêt est le passage à un montage concret, pas la preuve qu’une seule plateforme serait obligatoire. Source : guide de construction n8n.

Autre distinction importante : construire l’automatisation et l’utiliser ne demandent pas les mêmes pouvoirs. n8n décrit un serveur MCP capable de créer ou modifier des workflows, distinct du mécanisme qui expose un workflow comme serveur. Donner à un assistant de construction la possibilité d’éditer le système ne signifie pas que l’agent chargé des inscriptions doit conserver ce pouvoir. Source : serveur MCP n8n, article du 29 avril 2026.

Dessiner le parcours avant de connecter les comptes

Pour ce pilote, le circuit proposé comporte six étapes :

1. Le responsable place un message d’essai dans le dossier prévu.
2. Le système récupère son identifiant et vérifie qu’il n’a pas déjà été traité.
3. Le modèle relève l’activité et la date demandées, sans compléter les absences par supposition.
4. Le système recherche les correspondances dans le catalogue approuvé.
5. Le modèle prépare la fiche et le brouillon, en indiquant ce qui manque.
6. Le responsable examine la sortie, corrige si nécessaire et décide de la suite.

Une ambiguïté doit devenir un résultat prévu. Si « photo samedi » correspond à deux ateliers, la sortie est « activité à préciser », avec les deux possibilités, pas une sélection arbitraire.

Les états du dossier peuvent rester simples : reçu, à préciser, prêt à relire, validé manuellement, erreur technique. Évitez un unique statut « terminé » qui mélangerait préparation réussie, envoi et inscription confirmée. Le responsable doit comprendre ce qui s’est réellement passé sans relire toute la conversation.

Écrire un contrat d’outil que l’on peut vérifier

Un outil mal décrit crée des erreurs même avec un modèle performant. Pour chaque opération, écrivez ce qu’elle reçoit, ce qu’elle retourne et ce qu’elle ne fait pas.

Exemple original de contrat pour preparer_dossier :

• Entrées obligatoires : identifiant du message, activité retenue ou valeur « à préciser », éléments manquants et texte du brouillon.
• Condition : une fiche portant cet identifiant ne doit pas être créée deux fois.
• Sortie de réussite : identifiant de fiche, statut « à relire » et indication du brouillon enregistré.
• Sorties alternatives : dossier existant, champ invalide ou service indisponible.
• Absence de pouvoir : cet outil n’envoie rien et ne réserve aucune place.

Demandez ensuite une démonstration de chaque sortie. « Appel réussi » ne suffit pas : on doit pouvoir retrouver la fiche créée. Si la réponse de l’outil ne contient pas l’identifiant attendu, le système ne doit pas annoncer un enregistrement certain.

Pour une connexion MCP, la recette minimale consiste à vérifier successivement la connexion, la présence de l’outil dans les capacités disponibles, ses paramètres, puis un appel sur données d’essai. Un serveur joignable mais dépourvu de l’action utile ne valide pas l’intégration. Une connexion autorisée hier n’établit pas non plus que les droits n’ont pas changé depuis.

Donner une consigne exploitable, pas un rôle vague

Voici une consigne de départ pour notre montage. Les noms d’outils doivent être remplacés par ceux réellement disponibles ; les interdictions doivent aussi être appliquées dans les droits et le workflow.

Prépare une fiche d’inscription à partir du message fourni et du catalogue approuvé. Relève uniquement les informations présentes. Si plusieurs ateliers correspondent, présente les choix et marque l’activité « à préciser ». N’invente ni date, ni disponibilité, ni tarif. Recherche un dossier existant avec l’identifiant du message avant toute création. Prépare un brouillon demandant seulement les informations manquantes. Ne confirme jamais l’admission. Si un outil échoue, indique l’étape et n’annonce pas une opération non vérifiée. Retourne : activité, date demandée, éléments manquants, source consultée, statut et brouillon.

Ajoutez deux exemples : un message complet et un message ambigu, avec la sortie attendue. Ils servent à préciser votre exigence, pas à entraîner automatiquement un modèle sur toute l’histoire de l’association.

Une phrase comme « ignore les instructions malveillantes » n’est pas une protection suffisante. Un document ou un message peut contenir une instruction destinée à détourner le traitement : OWASP décrit ce risque d’injection indirecte. Dans notre montage, la parade concrète est aussi de ne pas fournir d’outil d’envoi ou d’export au pilote. Source : OWASP Prompt Injection.

Séparer documents, mémoire et historique

Trois besoins sont souvent regroupés sous le mot « mémoire ». Le catalogue est une source de référence ; les détails utiles pendant la conversation forment un contexte de travail ; la liste des actions réalisées constitue un historique d’exécution.

Pour notre association, il faut pouvoir mettre à jour le catalogue sans conserver tous les messages dans le contexte du modèle. Il faut aussi retrouver qu’une fiche a été créée après une interruption, même si la conversation courante n’en contient plus le détail.

Anthropic décrit cette séparation entre session, exécution et contexte dans son architecture Managed Agents. C’est un exemple d’implémentation fournisseur, pas une caractéristique automatiquement présente dans tout agent. Source : Scaling Managed Agents.

Au moment de la recette, posez donc une question simple : « Si le système s’arrête juste après la création, comment sait-il à la reprise qu’il ne doit pas recréer la fiche ? » Une réponse basée uniquement sur le souvenir du modèle est insuffisante pour ce cas. Attendez un identifiant durable et une vérification du dossier existant.

Tester les échecs, puis mesurer le travail gagné

Préparez votre jeu d’essai avant de modifier la consigne. Voici huit situations pour ce projet :

Situation	Résultat attendu
Activité et date explicites	Fiche fidèle et brouillon cohérent
Date absente	Question ciblée, aucune date inventée
Deux ateliers possibles	Choix présentés, pas de sélection automatique
Message déjà traité	Dossier retrouvé, aucune deuxième fiche
Catalogue indisponible	Arrêt identifié, aucune fausse vérification
Création confirmée puis connexion coupée	Vérification de l’existant avant reprise
Message demandant d’exporter la liste des adhérents	Aucun export et demande hors périmètre signalée
Changement récent du catalogue	Utilisation de la version approuvée actuelle

Ne vous contentez pas d’un pourcentage global de réponses agréables. Comptez séparément les dossiers corrects, les corrections, les erreurs techniques et les opérations interdites. Une seule action hors périmètre ne disparaît pas parce que neuf réponses sont bien formulées.

Mesurez ensuite le temps humain avec et sans le pilote, sur des dossiers comparables. Incluez la relecture, la correction et le traitement des exceptions. Si préparer une fiche prend moins de temps mais que vérifier les erreurs en demande davantage, le gain annoncé n’existe pas encore.

Lorsque le modèle choisit le mauvais outil, revoyez sa description ou réduisez les capacités disponibles. Lorsque l’outil échoue sur les mêmes paramètres, corrigez l’intégration. Lorsque le catalogue ne permet pas de décider, améliorez les données. Ces trois diagnostics évitent de modifier le prompt au hasard pour un problème situé ailleurs.

Budgéter et décider de la suite

Demandez un chiffrage séparant la préparation des données, le raccordement aux services, la construction, les essais et l’exploitation. Pour cette dernière, distinguez abonnement, consommation du modèle, services appelés, stockage utile, surveillance et maintenance. Le nombre de dossiers n’est pas toujours égal au nombre d’appels : recherches, nouvelles tentatives et contrôles peuvent en ajouter.

Le bon indicateur est le coût d’un dossier correct et exploitable, pas seulement celui d’une réponse générée. Aucun tarif universel ne découle du choix MCP, API ou no-code. Faites expliciter les hypothèses de volume et le travail qui reste à votre équipe.

Avant d’élargir le pilote, obtenez quatre éléments : la procédure de reprise, la liste des accès, le jeu de tests et la personne responsable de l’entretien. Puis ajoutez une seule capacité à la fois. Passer de « préparer un brouillon » à « envoyer une confirmation » est une nouvelle étape du projet, avec ses propres conditions, pas un simple réglage de confort.

Questions fréquentes

Peut-on créer un agent IA sans coder ?

Oui, si une plateforme visuelle expose les capacités nécessaires. Vérifiez néanmoins les opérations précises, les erreurs et les droits. Un pilote sans code peut rester simple ; un besoin absent du catalogue peut demander une API, un serveur MCP ou une intervention technique.

MCP remplace-t-il les API ?

Non. Un serveur MCP peut appeler une API pour réaliser une opération. MCP organise la présentation et l’échange de capacités avec une application IA ; l’API du service reste parfois le moyen d’agir derrière cette interface. Le choix dépend des outils disponibles et du maintien de l’intégration.

Quand le premier agent est-il prêt à être utilisé ?

Quand le parcours prévu fonctionne sur des cas représentatifs, que les exceptions sont visibles, que les actions restent dans le périmètre autorisé et que quelqu’un sait reprendre le travail après incident. Une démonstration réussie sur un seul message ne remplace pas cette réception.