Créez un assistant IA sans code : le workflow complet

Il y a six mois, vous pensiez probablement que la création d’un assistant IA nécessitait l’embauche d’un ingénieur ML et trois mois pour l’infrastructure. Ce n’est plus le cas. Le paysage des assistants IA sans code a tellement évolué que même un fondateur solo, un chef de produit ou un responsable des opérations peut déployer un assistant prêt pour la production qui gère de véritables tâches client, le tout sans jamais avoir à toucher à un terminal !

Le hic : savoir quel outil utiliser pour quelle tâche est plus difficile que jamais. Zapier, Make, Bubble, l’API Claude (dans des contextes sans code comme Retool), Firebase et une douzaine d’autres prétendent faire la même chose. Ils ne le font pas. Chez AlgoVesta, j’ai construit des assistants IA sur cinq piles technologiques différentes, j’en ai vu deux échouer complètement et trois gérer avec succès des milliers d’interactions quotidiennes. La différence entre l’échec et le succès n’était pas l’outil, mais la compréhension du compromis réel entre la facilité d’utilisation, la personnalisation, le coût et la fiabilité.

Ceci est un guide complet pour construire un assistant IA pour votre entreprise en 2025. Ce n’est pas une critique d’outils. C’est un workflow réel.

Ce que « assistant IA » signifie vraiment dans un contexte sans code

Avant de choisir un outil, définissez ce que vous construisez réellement. « Assistant IA » est suffisamment large pour être inutile. Un assistant qui répond aux FAQ n’a presque rien en commun avec un assistant qui transfère les tickets de support, qui lui-même n’a presque rien en commun avec un assistant qui génère des rapports personnalisés.

Pour cet article, nous nous concentrerons sur les assistants qui :

• Acceptent les entrées des clients, des utilisateurs ou des parties prenantes internes
• Traient cette entrée via un LLM (Claude, GPT-4o ou similaire)
• Accèdent à des données externes (votre base de données, CRM, base de connaissances ou API)
• Retournent une sortie pertinente (réponse, action ou décision)
• Journalisent les interactions à des fins de conformité ou de débogage

C’est la majorité des cas d’utilisation commerciaux réels. Les chatbots FAQ entrent dans cette catégorie. L’automatisation du support client aussi. La qualification des prospects aussi. La recherche dans les documents internes aussi.

Ce qui n’est pas couvert : les agents entièrement autonomes qui prennent des décisions sans supervision humaine, ou les workflows multi-étapes complexes qui nécessitent une logique de branchement sur des dizaines de conditions. Ceux-ci nécessitent du code personnalisé ou des plateformes de niveau entreprise (Salesforce Einstein, workflows HubSpot à grande échelle, etc.).

Les trois approches architecturales (et quand chacune fonctionne)

Chaque assistant IA sans code s’inscrit dans l’un des trois schémas. Votre choix ici détermine quels outils fonctionneront réellement pour vous.

Schéma 1 : LLM + Contexte + Réponse directe

Le schéma le plus simple. L’utilisateur envoie une question ou une requête → Votre système récupère le contexte pertinent (d’une base de connaissances, d’une base de données ou d’une API) → Vous envoyez l’entrée de l’utilisateur + le contexte à un LLM → Vous retournez directement la réponse du LLM.

Quand l’utiliser : Automatisation des FAQ, recherche documentaire, support client pour des questions simples, recommandations de contenu, qualification de base des prospects.

Exemple : Bot FAQ pour le support client

L’utilisateur demande : « Puis-je améliorer mon forfait de base en milieu de mois ? »

Étapes du système :

1. Recherchez dans votre base de connaissances les documents relatifs aux mises à niveau de forfait.
2. Récupérez les 2-3 articles les plus pertinents.
3. Envoyez à Claude : « En vous basant sur ce contexte, répondez à la question du client : Puis-je améliorer mon forfait de base en milieu de mois ? » + les articles récupérés.
4. Retournez la réponse de Claude à l’utilisateur.

C’est RAG (Retrieval-Augmented Generation) dans sa forme la plus simple. Le terme sonne complexe. Le schéma est trivial.

Qualité de sortie typique : 85-92 % des questions sont correctement répondues du premier coup, en fonction de la qualité de votre base de connaissances. Les 8 à 15 % restants nécessitent une clarification, impliquent des cas limites ou nécessitent une intervention humaine.

Schéma 2 : LLM + Contexte + Extraction + Action

L’utilisateur envoie une requête → Le système récupère le contexte → Vous l’envoyez à un LLM avec des instructions explicites pour extraire des données structurées → Le LLM renvoie du JSON ou des champs → Votre système effectue une action basée sur cette extraction (créer un enregistrement, envoyer un e-mail, mettre à jour une base de données).

Quand l’utiliser : Routage de tickets, automatisation de formulaires, saisie de données dans un CRM, planification de rendez-vous, traitement de factures – toute tâche où vous souhaitez que le LLM prenne une décision qui déclenche une action.

Exemple : Routage automatique des tickets de support

Le client envoie : « Mon intégration API a planté hier matin. Je reçois des erreurs 500 à chaque appel. »

Étapes du système :

1. Envoyez le message à Claude avec les instructions : « Extrayez la catégorie du problème (Facturation, Technique, Demande de fonctionnalité, Compte, Autre), l’urgence (critique, élevée, moyenne, faible) et le produit principalement mentionné. Retournez du JSON. »
2. Claude renvoie : {"category": "technical", "urgency": "critical", "product": "API"}
3. Votre système utilise ce JSON pour : créer un ticket, l’attribuer à l’équipe technique, définir la priorité sur critique, le marquer automatiquement avec « API ».
4. Envoyez une confirmation au client.

Pourquoi c’est important : Vous ne demandez pas au LLM d’effectuer l’action. Vous lui demandez de comprendre suffisamment l’entrée pour extraire les bons champs, puis votre outil sans code utilise ces champs pour déclencher la logique métier réelle. C’est là que se trouve 80 % de l’automatisation d’entreprise.

Qualité de sortie typique : 88-96 % en fonction de la clarté de vos catégories. La phase d’extraction est plus fiable que les réponses ouvertes car le LLM est limité à la sélection dans une liste.

Schéma 3 : Workflow LLM multi-étapes avec feedback

L’utilisateur envoie l’entrée → Le LLM prend une décision ou génère un brouillon → Le système le présente à un humain ou demande une approbation → Une fois approuvé, une autre étape LLM est exécutée ou un humain prend le relais.

Quand l’utiliser : Décisions à haut risque (revue de contrats, recommandations d’embauche, exceptions de politique), assurance qualité sur les réponses automatisées, scénarios où le coût d’une erreur est élevé.

Exemple : Qualification des prospects avec revue humaine

Un nouveau prospect remplit un formulaire → La première étape LLM extrait la taille de l’entreprise, le secteur, le budget, le cas d’utilisation → La deuxième étape du système vérifie si le prospect correspond à notre ICP (Profil Client Idéal) → S’il est qualifié, il est mis en file d’attente pour que les ventes le contactent ; sinon, il est assigné à une séquence de nurturing → Un responsable des ventes examine les cas limites avant qu’ils ne soient refusés.

Qualité de sortie typique : 92-98 % car vous avez un humain dans la boucle, mais le LLM prend 70 à 80 % des décisions automatiquement.

Comparaison des piles technologiques : Cas d’utilisation spécifiques

Maintenant que vous savez quel schéma vous convient, voici comment les principales plateformes sans code se comportent réellement. Je me concentre sur les outils que j’ai utilisés en production chez AlgoVesta ou que j’ai testés en profondeur, pas sur une revue superficielle.

Traduction concrète : Si vous créez un assistant orienté client et avez besoin d’une interface utilisateur personnalisée, optez pour Bubble ou Retool. Si vous automatisez des workflows internes et utilisez déjà des outils SaaS, utilisez Make. Si vous avez besoin des meilleures performances LLM et disposez d’un budget de développement web de base, optez pour l’API Claude + Vercel (en réalité, peu de code, pas sans code). Si vous êtes déjà chez Salesforce, utilisez Einstein, mais préparez-vous à des coûts plus élevés et à moins de personnalisation.

Étape par étape : Construisez votre premier assistant

Passons à la construction d’un assistant de support client avec Make + Claude. Cela combine le schéma 1 + le schéma 2 : récupérer le contexte, obtenir une réponse, extraire des données de routage et créer un ticket.

Étape 1 : Définissez votre source d’entrée

Où l’assistant recevra-t-il les requêtes ? Options :

• Un formulaire sur votre site web (Typeform, Jotform)
• E-mail (via Zapier ou Make)
• Un canal Slack
• Un widget de chat web dédié
• Votre système de helpdesk (Zendesk, Freshdesk, etc.)

Pour cet exemple, nous supposerons un formulaire sur votre site web. Un client saisit « Quel est votre problème ? » et clique sur envoyer.

Étape 2 : Récupérer le contexte (recherche dans la base de connaissances)

Vous avez besoin d’une base de connaissances consultable. Options :

• Google Docs + une API de recherche
• Notion + API Notion
• Airtable + API Airtable
• Un outil dédié de base de connaissances (Slite, GitBook, etc.)

Supposons que vous utilisiez Notion. Dans Make, ajoutez une étape de recherche Notion qui prend l’entrée du client et renvoie les 3 documents les plus pertinents. L’intégration Notion de Make gère cela automatiquement.

Étape 3 : Envoyez à Claude avec le contexte récupéré

Voici l’architecture de prompt réelle :

Vous êtes un assistant de support client pour [Nom de l'entreprise]. 

En vous basant sur la documentation suivante, répondez directement et utilement à la question du client.

Documentation :
{retrieved_docs}

Question du client : {customer_input}

Si vous ne pouvez pas répondre à la question en vous basant sur la documentation, dites : « Je n'ai pas d'informations à ce sujet dans notre documentation. Laissez-moi vous mettre en relation avec un membre de l'équipe. »

Répondez en moins de 3 phrases.

Dans Make, il s’agit d’une seule étape « Appeler l’API Claude ». Vous transmettez trois variables : {retrieved_docs}, {customer_input} et un prompt système fixe.

Coût à grande échelle : Claude Sonnet 4 (mi-mars 2025) coûte environ 0,003 $ pour 1 000 tokens d’entrée et 0,015 $ pour 1 000 tokens de sortie. Une interaction de support typique : ~800 tokens d’entrée (message client + extraits de base de connaissances), ~150 tokens de sortie. Coût par interaction : ~0,004 $. Pour 1 000 interactions/mois, cela représente environ 4 $.

Étape 4 : Extraire les données de routage (facultatif)

Si vous souhaitez que l’assistant route également le ticket :

Extrayez les informations suivantes du message client au format JSON :
{
  "issue_category": "un parmi : Facturation, Technique, Demande de fonctionnalité, Compte, Autre",
  "urgency": "un parmi : Critique, Élevé, Moyen, Faible",
  "product_mentioned": "Extrayez le nom du produit ou 'general'"
}

Message client : {customer_input}

Le LLM renvoie des données JSON structurées. Make les transmet à votre système de ticketing (Zendesk, Freshdesk, Hubspot).

Étape 5 : Créer le ticket et répondre

Avec les données extraites :

• Make crée un ticket dans votre helpdesk avec la catégorie, l’urgence et les tags de produit.
• Envoie la réponse de Claude au client.
• Journalise l’interaction (entrée client, réponse IA, données de routage) dans une base de données pour référence ultérieure.
• Si l’urgence = « critique », envoie une notification à votre équipe de support d’astreinte.

Temps d’installation total : 2 à 4 heures si vous êtes familier avec Make et l’API de votre helpdesk. 6 à 10 heures si vous êtes nouveau dans les deux.

Quand (et pourquoi) le sans code échoue : Modes de défaillance réels et solutions

J’ai vu trois assistants IA prêts pour la production construits avec des outils sans code échouer complètement. Voici ce qui s’est passé et ce que nous avons fait à la place.

Mode de défaillance 1 : Le problème de la dérive de la base de connaissances

Ce qui s’est passé : Nous avons construit un assistant FAQ dans Make + Claude avec Notion comme base de connaissances. Au cours du premier mois, la précision était de 87 %. Au troisième mois, elle était tombée à 61 %. Le problème : notre équipe produit mettait à jour la documentation dans Notion, mais ces mises à jour ne se reflétaient pas dans les réponses de l’assistant.

Cause première : L’intégration Notion de Make recherche des documents, mais l’API de recherche Notion ne renvoie pas toujours la dernière version d’un document s’il a été mis à jour récemment. Il y a un délai de 12 à 24 heures.

La solution : Passez à un outil dédié de base de connaissances (nous utilisons GitBook) avec une recherche garantie en temps réel. Alternativement, mettez en œuvre une tâche de synchronisation hebdomadaire qui exporte vos documents Notion vers une base de données et recherche dans cette base de données à la place.

Mode de défaillance 2 : Explosion du budget de tokens

Ce qui s’est passé : Nous avons construit un assistant interne pour notre équipe de trading avec Retool + Claude Opus. Il fonctionnait à merveille, mais coûtait 1,80 $ par requête. À grande échelle (notre équipe effectue ~300 requêtes/jour), cela représente 540 $/jour ou 162 000 $/an.

Cause première : Nous utilisions Claude Opus pour toutes les requêtes, même les plus simples qui auraient pu être traitées par Sonnet. Nous n’avons pas demandé au LLM d’être concis ; certaines réponses faisaient 2 000 tokens alors que 300 auraient suffi.

La solution : Mettez en œuvre un système à plusieurs niveaux. Dirigez les requêtes simples vers Sonnet (moins cher, plus rapide). Dirigez les requêtes complexes vers Opus. Ajoutez l’instruction « Soyez concis » à chaque prompt. Les coûts ont été réduits à 0,14 $ par requête.

Mode de défaillance 3 : Le piège de l’hallucination contextuelle

Ce qui s’est passé : Nous avons construit un assistant de qualification des prospects qui extrayait la taille de l’accord des formulaires d’entrée client. Claude extrayait de manière convaincante des tailles d’accord qui n’étaient pas présentes dans le formulaire. Exemple : un client a écrit « Nous sommes une petite agence », et l’assistant a extrait « deal_size: 500 000 $ » (hallucination).

Cause première : Le prompt n’indiquait pas explicitement « Extrayez uniquement les informations présentes dans le formulaire ». Le LLM a déduit en fonction de la taille de l’entreprise et du contexte, puis a présenté la déduction comme un fait.

La solution : Modifiez le prompt en : « Extrayez la taille de l’accord UNIQUEMENT si elle est explicitement indiquée dans le formulaire. Si elle n’est pas indiquée, renvoyez null. » Testez le prompt avec 20 exemples réels avant de le déployer. Ajoutez une phase de revue humaine pour toutes les valeurs extraites pendant la première semaine.

Le cadre de décision : Choisissez votre outil

Utilisez ce cadre pour choisir le bon outil sans perdre de temps en démonstrations.

Posez-vous ces questions, une par une :

1. Est-ce orienté client ou interne ? Si orienté client, vous avez besoin d’un outil avec une bonne UI (Bubble, Retool, développement personnalisé). Si interne, Make ou Zapier conviennent.
2. Utilisez-vous déjà une plateforme spécifique ? Si vous êtes déjà chez Salesforce, essayez d’abord Einstein. Si vous utilisez déjà Make, restez avec Make. Changer d’outil pour une petite fonctionnalité coûte plus cher que l’outil lui-même.
3. Quelle est la complexité de la logique ? Si c’est 2-3 étapes, Zapier. Si c’est 5-10 étapes, Make. Si c’est plus de 10 étapes ou que cela nécessite du codage personnalisé, construisez vous-même (Vercel + API Claude).
4. Quel est le coût d’une erreur ? Si une erreur peut vous coûter un client, vous avez besoin d’une revue humaine (Schéma 3). S’il s’agit simplement d’une mauvaise réponse à une FAQ, vous pouvez gérer le Schéma 1.
5. Quel est votre budget ? Zapier et Make sont les moins chers pour commencer (10-50 $/mois). Retool est dans la fourchette moyenne (600 $+). Le développement personnalisé a des coûts initiaux élevés, mais des coûts par requête faibles à grande échelle.

Arbre de décision :

• Outil interne, workflow simple → Make ou Retool
• Orienté client, simple, faible risque → Bubble ou Make
• Orienté client, haut risque → Développer soi-même (Vercel + API Claude)
• Intégration CRM → Salesforce Einstein ou Make avec connexion à votre CRM
• Incertain, je veux essayer → Make (moins de friction)

La réalité de la sécurité et de la conformité

Avant de déployer, comprenez ce qu’il advient de vos données.

Données en transit : Lorsque vous envoyez des données client à Claude ou GPT-4o, Anthropic et OpenAI les voient (sauf si vous utilisez Claude avec zéro rétention de données, ce qui nécessite un plan d’entreprise). C’est acceptable pour les requêtes non sensibles. Pour les informations personnellement identifiables (PII) ou les données financières : (a) Utilisez un LLM auto-hébergé (Mistral 7B, Llama 3, etc. sur votre propre infrastructure) ou (b) implémentez le masquage des données (supprimez les noms, e-mails, etc. avant de les envoyer au LLM).

Données au repos : Lorsque vous stockez des interactions dans Make ou Retool, elles sont stockées dans la base de données de cet outil. Les serveurs Make sont conformes au RGPD. Les serveurs Retool aussi. Cependant, vérifiez leurs politiques spécifiques de résidence des données si vous opérez dans l’UE ou sous d’autres réglementations.

Approche pratique : Pour les assistants de support client sur des questions publiques, envoyez les données directement à Claude. Pour les données sensibles (informations sur la santé, dossiers financiers, données des employés), masquez-les avant de les envoyer ou utilisez un modèle auto-hébergé.

Vos 30 premiers jours : Ce que vous devriez réellement construire

Ne commencez pas par construire l’assistant de vos rêves. Commencez par choisir un workflow petit et spécifique et lancez-le.

Jours 1-2 : Choisissez votre cas d’utilisation

Choisissez quelque chose qui :

• Traite plus de 50 requêtes répétitives par mois (vous avez besoin d’un volume suffisant pour mesurer l’impact)
• A une métrique de succès claire (par exemple, « % de requêtes répondues sans escalade humaine »)
• Est suffisamment à faible risque qu’un taux d’erreur de 10 % ne cause pas de dommages

Exemple : FAQ client sur vos questions les plus fréquentes. Ou le routage des requêtes internes (notes de frais, demandes de congés, etc.).

Jours 3-5 : Construisez un prototype

Utilisez Make ou Bubble. Ne réfléchissez pas trop. Commencez par le schéma 1 (LLM + Contexte) et mesurez la précision sur 20 exemples réels.

Jours 6-14 : Testez avec de vrais utilisateurs

Déployez l’assistant auprès de 10 % de votre public. Mesurez :

• Précision de la réponse (l’IA a-t-elle donné la bonne réponse ?)
• Taux d’escalade (% de requêtes nécessitant une intervention humaine)
• Taux de résolution (% de requêtes entièrement résolues par l’IA)
• Satisfaction utilisateur (note de 1 à 5)

Jours 15-30 : Itérez

Si la précision est inférieure à 75 %, examinez les erreurs. S’agit-il d’un problème de base de connaissances ? D’un problème de prompt ? D’un problème de modèle ? Corrigez une chose à la fois, testez à nouveau. Si la précision est supérieure à 85 %, passez à 100 % des utilisateurs. Ensuite, construisez le workflow suivant.

Coûts pendant cette phase : 0-200 $, selon l’outil et le nombre de requêtes exécutées. Les coûts des API LLM sont minimes pour les tests.

La seule chose à faire aujourd’hui

Sélectionnez les 20 questions client les plus fréquentes que votre équipe a répondues ce mois-ci. Copiez-les dans une feuille de calcul. Notez à côté le temps nécessaire pour y répondre. Si le temps total dépasse 5 heures, vous avez trouvé votre premier cas d’utilisation d’assistant. Créez un compte Make ou Bubble dès aujourd’hui (les deux ont des plans gratuits) et consacrez 90 minutes à la création d’un prototype qui répond à 5 de ces 20 questions. Vous n’avez pas besoin d’une précision parfaite, vous avez juste besoin de preuves que l’idée fonctionne. Si c’est le cas, vous avez trouvé quelque chose qui vaut la peine d’être développé davantage.