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 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 directeur des opérations peut déployer un assistant de niveau production capable de gérer de vrais travaux clients, le tout sans toucher une seule ligne de code !

Le truc : 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 en gérant 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 véritable compromis entre la facilité d’utilisation, la personnalisation, le coût et la fiabilité.

Voici 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 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 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 stakeholder 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)
• Journalisent 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 en plusieurs étapes nécessitant une logique de branchement à travers des dizaines de conditions. Ceux-ci nécessitent un 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 leads.

Exemple : Bot FAQ pour le Support Client

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

Étapes du système :

1. Recherchez dans votre base de connaissances des documents sur les mises à niveau de forfait.
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 améliorer mon forfait Basic 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 répondues correctement du premier coup, selon la manière dont votre base de connaissances est organisée. Les 8-15 % restants nécessitent une clarification, impliquent des cas limites ou un humain.

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 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 échoué 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, élevée, moyenne, faible) 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, l’étiqueter 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 suffisamment l’entrée pour extraire les bons champs, puis 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 % en fonction de 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 soumet à un humain ou attend l’approbation → une fois approuvé, une autre étape du LLM est exécutée, ou un humain s’en charge.

Quand l’utiliser : Décisions à haut risque (examens 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 des leads avec révision humaine

Un nouveau prospect remplit un formulaire → La première étape du 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 prospect correspond à notre 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 écarté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 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 disposez d’un budget de développement web de base, API Claude + Vercel (en réalité, peu de code, pas sans code). Si vous utilisez déjà Salesforce, Einstein, mais préparez-vous à payer plus et à obtenir moins de personnalisation.

Étape par Étape : Construisez Votre Premier Assistant

Passons en revue comment construire 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 du 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, il s’agit d’une seule étape « Appel API Claude ». Vous passez 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 1000 tokens d’entrée et 0,015 $ pour 1000 tokens de sortie. Une interaction de support typique : ~800 tokens d’entrée (message client + extraits de la base de connaissances), ~150 tokens de sortie. Coût par interaction : ~0,004 $. Avec 1000 interactions/mois, cela représente 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_de_fonctionnalite, compte, autre",
  "urgency": "un parmi : critique, elevee, moyenne, faible",
  "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 étiquettes 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 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 dans les deux.

Quand (et Pourquoi) le Sans Code Échoue : Vrais Échecs 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.

Échec 1 : Le Problème de la Dérive de la Base de Connaissances

Ce qui s’est passé : Nous avons construit un assistant FAQ sur 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élai de 12 à 24 heures.

La solution : Passer à un outil de base de connaissances dédié (nous avons utilisé 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.

Échec 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 soit 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’avions pas instruit le LLM d’être concis ; certaines réponses faisaient 2000 tokens alors que 300 auraient suffi.

La solution : Mettre en place un système à plusieurs niveaux. Diriger les requêtes simples vers Sonnet (moins cher, plus rapide). Diriger 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.

Échec 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 se basant sur la taille de l’entreprise et d’autres contextes, puis présentait l’inférence comme un fait.

La solution : Modifier 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 sur 20 exemples réels avant de le déployer. Ajoutez une étape de révision humaine pour toutes les valeurs extraites 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émos.

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 conviennent.
2. Utilisez-vous déjà une plateforme spécifique ? Si vous utilisez déjà Salesforce, essayez Einstein en premier. 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 ? 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 si cela 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 révision 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, risque élevé → Construisez-le (Vercel + API Claude)
• Intégration CRM → Salesforce Einstein ou Make connecté à votre CRM
• Je ne suis 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 rétention de données zéro, qui nécessite un plan d’entreprise). C’est acceptable pour les requêtes non sensibles. Pour les données personnellement 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 l’obfuscation des données (supprimez les noms, e-mails, etc., avant de les envoyer au LLM).

Données au repos : Si vous stockez des interactions dans Make ou Retool, elles sont enregistrées dans la base de données de cet outil. Les serveurs de 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 sujets publics, envoyez les données directement à Claude. Pour les données sensibles (informations de santé, dossiers financiers, données d’employés), obfusquez avant d’envoyer 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 :

• 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 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 révision 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, re-testez. Si la précision est supérieure à 85 %, passez à 100 % des utilisateurs. Ensuite, construisez le workflow suivant.

Coût à ce stade : 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

Choisissez les 20 questions clients les plus fréquentes que votre équipe a répondues 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 sur Make ou Bubble dès aujourd’hui (les deux ont des niveaux gratuits) et passez 90 minutes à construire un prototype qui répond à 5 de ces 20 questions. Vous n’avez pas encore besoin d’une précision parfaite, juste 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é.