Créez un Assistant IA Sans Code : Le Workflow Complet

Il y a six mois, vous pensiez probablement que construire un assistant IA impliquait d’embaucher un ingénieur ML et de passer trois mois sur l’infrastructure. Ce n’est plus vrai. Le paysage des assistants IA sans code a tellement mûri que même un fondateur solo, un chef de produit ou un responsable des opérations peut déployer un assistant de niveau production capable de gérer de vrais travaux clients, le tout sans toucher à un seul terminal !

Le hic : savoir quel outil utiliser pour chaque 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. Ce n’est pas le cas. J’ai construit des assistants IA sur cinq piles technologiques différentes chez AlgoVesta, j’en ai vu deux échouer complètement et trois réussir à gérer des milliers d’interactions quotidiennes. La différence entre les échecs et les succès n’était pas l’outil, mais la compréhension du compromis réel entre facilité d’utilisation, personnalisation, coût et fiabilité.

Ceci est un guide complet pour construire un assistant IA pour votre entreprise en 2025. Ce n’est pas une revue d’outils. C’est un vrai workflow.

Ce que « Assistant IA » Signifie Réellement dans un Contexte Sans Code

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

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

• Prennent des entrées d’un client, d’un utilisateur ou d’un intervenant interne
• 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)
• Enregistrent les interactions pour la conformité ou le débogage

C’est la majorité des cas d’utilisation commerciaux réels. Les bots FAQ entrent ici. L’automatisation du support client aussi. La qualification des leads 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 complexes à plusieurs étapes nécessitant une logique de branchement à travers 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 entre 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 demande → 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 utilisateur + 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 leads.

Exemple : Bot FAQ pour le support client

Utilisateur demande : « Puis-je mettre à niveau mon plan Basic en cours de mois ? »

Étapes du système :

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

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

Qualité de sortie typique : 85-92 % des questions répondues correctement du premier coup, selon la qualité d’organisation de votre base de connaissances. Les 8-15 % restants nécessitent une clarification, impliquent des cas limites ou nécessitent un humain.

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

L’utilisateur envoie une demande → 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 retourne 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, traitement de factures, toute tâche où vous avez besoin 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 sur 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, haute, moyenne, basse) et le produit principal mentionné. Retournez en JSON. »
2. Claude retourne : {"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é comme critique, le taguer automatiquement comme « 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 l’entrée suffisamment pour extraire les bons champs, et ensuite votre outil sans code utilise ces champs pour déclencher la vraie logique métier. C’est là que réside 80 % de l’automatisation des entreprises.

Qualité de sortie typique : 88-96 % selon la clarté de vos catégories. L’étape d’extraction est plus fiable que les réponses ouvertes car le LLM est limité à choisir parmi 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 attend l’approbation → une fois approuvé, une autre étape LLM est exécutée, ou un humain s’en charge.

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

Exemple : Qualification de leads avec revue humaine

Un nouveau lead remplit un formulaire → La première étape LLM extrait la taille de l’entreprise, l’industrie, le budget, le cas d’utilisation → La deuxième étape du système vérifie si le lead correspond à votre ICP (profil client idéal) → S’il est qualifié, il est mis en file d’attente pour le contact commercial ; sinon, il est attribué à une séquence de nurturing → Un responsable des ventes examine les cas limites avant qu’ils ne soient rejetés.

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

Comparaison des Piles Technologiques : Cas d’Utilisation Spécifiques

Maintenant que vous savez quel schéma vous avez besoin, voici comment les principales plateformes sans code se comparent 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 UI personnalisée, Bubble ou Retool. Si vous automatisez des workflows internes et utilisez déjà des outils SaaS, Make. Si vous avez besoin des meilleures performances LLM et avez un budget de développement web de base, API Claude + Vercel (en fait, peu de code, pas sans code). Si vous êtes déjà sur Salesforce, Einstein, mais préparez-vous à payer plus et à obtenir moins de personnalisation.

Étape par Étape : Construire Votre Premier Assistant

Passons en revue la construction d’un assistant de support client en utilisant 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 reçoit-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 supposons un formulaire sur votre site web. Un client remplit « Quel est votre problème ? » et clique sur envoyer.

Étape 2 : Récupérez le Contexte (Recherche dans la Base de Connaissances)

Vous avez besoin que votre base de connaissances soit interrogeable. Options :

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

Supposons que vous utilisiez Notion. Dans Make, ajoutez une étape de recherche Notion qui prend l’entrée client et retourne 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 réelle du prompt :

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

En vous basant sur la documentation suivante, répondez à la question du client de manière directe et utile.

Documentation :
{retrieved_docs}

Question du client : {customer_input}

Si vous ne pouvez pas répondre 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, c’est une seule étape « Appeler l’API Claude ». Vous passez trois variables : {retrieved_docs}, {customer_input}, et un prompt système fixe.

Coût à l’é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 $. Avec 1 000 interactions/mois, cela fait environ 4 $.

Étape 4 : Extrayez les Données de Routage (Optionnel)

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

Extrayez les informations suivantes du message client au format JSON :
{
  "issue_category": "un parmi : facturation, technique, demande_fonctionnalite, compte, autre",
  "urgency": "un parmi : critique, haute, moyenne, basse",
  "product_mentioned": "extraire le nom du produit ou 'general'"
}

Message client : {customer_input}

Le LLM retourne du JSON structuré. Make le transmet à votre système de ticketing (Zendesk, Freshdesk, Hubspot).

Étape 5 : Créez un Ticket et Répondez

Avec les données extraites, Make :

• Crée un ticket dans votre helpdesk avec la catégorie, l’urgence et les tags produit
• Envoie la réponse de Claude au client
• Enregistre l’interaction (entrée client, réponse IA, données de routage) dans une base de données pour référence future
• Si l’urgence = « critique », envoie une alerte à votre équipe de support de garde

Temps de configuration total : 2-4 heures si vous êtes familier avec Make et l’API de votre helpdesk. 6-10 heures si vous êtes nouveau sur les deux.

Quand (et Pourquoi) le Sans Code Échoue : Défaillances Réelles et Solutions

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

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 en utilisant Notion comme base de connaissances. Au cours du premier mois, la précision était de 87 %. Au troisième mois, elle est 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 profonde : L’intégration Notion de Make recherche des documents, mais l’API de recherche Notion ne retourne pas toujours la dernière version d’un document s’il a été mis à jour récemment. Il y a un décalage de 12 à 24 heures.

La solution : Passer à un outil de base de connaissances dédié (nous utilisons GitBook) avec une recherche garantie en temps réel. Alternativement, implémenter 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.

Défaillance 2 : L’Explosion du Budget de Tokens

Ce qui s’est passé : Nous avons construit un assistant interne pour notre équipe de trading en utilisant Retool + Claude Opus. Il a fonctionné à 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 profonde : Nous utilisions Claude Opus pour toutes les requêtes, même les plus simples qui auraient pu être traitées par Sonnet. Nous n’indiquions pas au LLM d’être concis ; certaines réponses faisaient 2 000 tokens alors que 300 auraient suffi.

La solution : Mettre en place un système à plusieurs niveaux. Orienter les requêtes simples vers Sonnet (moins cher, plus rapide). Orienter les requêtes complexes vers Opus. Ajouter une instruction « soyez concis » à chaque prompt. Le coût a été réduit à 0,14 $ par requête.

Défaillance 3 : Le Piège de l’Hallucination de Contexte

Ce qui s’est passé : Nous avons construit un assistant de qualification de leads qui extrayait la taille du deal des formulaires de saisie client. Claude extrayait avec confiance des tailles de deal qui n’existaient pas dans le formulaire. Exemple : un client a écrit « nous sommes une petite agence » et l’assistant a extrait « deal_size: $500,000 » (hallucination).

Cause profonde : Le prompt ne disait pas explicitement « extrayez uniquement les informations présentes dans le formulaire ». Le LLM inférait en fonction de la taille de l’entreprise et d’autres contextes, puis présentait l’inférence comme un fait.

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

Le Cadre de Décision : Choisir Votre Outil

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

Posez-vous ces questions dans l’ordre :

1. Est-ce orienté client ou interne ? S’il est orienté client, vous avez besoin d’un outil avec une bonne UI (Bubble, Retool, une construction personnalisée). S’il est interne, Make ou Zapier convient.
2. Utilisez-vous déjà une plateforme spécifique ? Si vous êtes déjà sur Salesforce, essayez Einstein en premier. Si vous utilisez déjà Make, restez sur 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 ? S’il s’agit de 2-3 étapes, Zapier. S’il s’agit de 5-10 étapes, Make. S’il s’agit de plus de 10 étapes ou nécessite du code personnalisé, construisez-le (Vercel + API Claude).
4. Quel est le coût de l’échec ? Si une erreur peut vous coûter un client, vous avez besoin d’une revue humaine (Schéma 3). Si ce n’est qu’une mauvaise réponse 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 $+). Les constructions personnalisées ont un coût initial élevé mais un faible coût par requête à 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 → Construisez-le (Vercel + API Claude)
• Intégration CRM → Salesforce Einstein ou Make connecté à votre CRM
• Pas sûr, 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 une rétention de données nulle, ce qui nécessite un plan d’entreprise). C’est acceptable pour les requêtes non sensibles. Pour les données personnelles identifiables (PII) ou financières, soit : (a) utilisez un LLM auto-hébergé (Mistral 7B, Llama 3, etc. sur votre propre infrastructure), soit (b) implémentez le masquage des données (supprimez les noms, e-mails, etc. avant de les envoyer au LLM).

Données au repos : Si vous enregistrez 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. Ceux de Retool aussi. Mais 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 de santé, dossiers financiers, données d’employés), masquez-les avant l’envoi ou utilisez un modèle auto-hébergé.

Vos 30 Premiers Jours : Ce qu’il Faut Vraiment Construire

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

Jours 1-2 : Choisissez votre cas d’utilisation

Choisissez quelque chose qui :

• Gère 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 peu risqué pour qu’un taux d’erreur de 10 % ne cause pas de tort

Exemple : FAQ client sur vos questions les plus courantes. Ou 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 pour 10 % de votre audience. 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 revue 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 %, auditez les échecs. Est-ce un problème de base de connaissances ? Un problème de prompt ? 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ût dans cette phase : 0-200 $ selon l’outil et le nombre de requêtes exécutées. Les coûts de l’API LLM sont minimes pour les tests.

La Seule Chose à Faire Aujourd’hui

Choisissez les 20 questions clients les plus fréquentes auxquelles votre équipe a répondu ce mois-ci. Copiez-les dans une feuille de calcul. À côté de chacune, notez combien de temps il a fallu pour répondre. Si le temps total dépasse 5 heures, vous avez votre premier cas d’utilisation d’assistant. Créez un compte Make ou Bubble aujourd’hui (les deux ont des niveaux gratuits) et consacrez 90 minutes à la construction d’un prototype qui répond à 5 de ces 20 questions. Vous n’avez pas encore 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é.