Construisez un Assistant IA Fonctionnel Sans Code. Voici la Stack

Il y a trois mois, une équipe marketing de 7 personnes dans une entreprise SaaS de taille moyenne a construit un assistant IA de support client en deux semaines. Pas d’ingénieurs. Pas de code personnalisé. Ils ont utilisé Make (anciennement Integromat) pour l’orchestration, Claude pour le cerveau, et Zapier pour le routage des données. Il a géré 40% du volume de support. Le coût de la configuration était inférieur à 200 $/mois en outils.

Ils n’ont pas commencé comme ça. Première tentative : ChatGPT encapsulé dans une interface web qu’ils ont louée. Il a halluciné la politique de l’entreprise, s’est contredit, et a fait des promesses que l’équipe ne pouvait pas tenir. La deuxième tentative : un bot de support prêt à l’emploi qui coûtait 1 500 $/mois et ne pouvait pas gérer 30% de leurs schémas de tickets.

La différence entre les approches échouées et celle qui a fonctionné n’était pas l’intelligence – c’était la structure. Un assistant IA n’est pas juste un modèle qui répond à des questions. C’est un système qui récupère le bon contexte, formate les réponses pour vos utilisateurs, et transmet à un humain au moment précis.

Ce pilier vous guide dans la construction de ce système. Pas de théorie. Pas de « l’IA transforme le support ». Des outils no-code concrets. Des schémas de flux de travail réels. Où ils échouent. Quand mettre à niveau. Ce que la plupart des équipes font mal.

Ce que votre assistant IA doit réellement faire

Avant de choisir les outils, définissez la portée. La plupart des assistants IA d’entreprise échouent car on leur demande de faire trop de choses sans assez de structure.

Commencez ici : notez les 10 questions ou cas d’utilisation clients les plus fréquents que votre assistant traiterait. Pas « répondre à tout sur notre produit ». Spécifique. « Les clients demandent le statut d’un remboursement » ou « les clients ont besoin de réinitialiser leur clé API ».

Pour chaque cas d’utilisation, définissez trois choses :

• Entrée requise : De quelles informations l’assistant a-t-il besoin pour répondre correctement ? (Exemple : identifiant client, historique des achats passés, tickets de support actuels)
• Connaissances requises : De quel contexte le modèle a-t-il besoin ? (Exemple : votre page de tarifs, document de politique de remboursement, documentation API)
• Action de sortie : Que doit-il se passer ensuite ? (Exemple : renvoyer le statut du remboursement, créer un ticket de support, envoyer un e-mail de confirmation)

Cet inventaire force la clarté. De nombreuses équipes réalisent à mi-parcours que leurs 3 principaux cas d’utilisation nécessitent un accès aux systèmes internes (CRM, base de données de facturation, plateforme de ticketing) qu’elles n’ont pas encore connectés. Mieux vaut le savoir maintenant.

Ensuite, définissez les limites de portée. Ce sont les questions auxquelles votre assistant ne devrait pas répondre :

• Tout ce qui nécessite des jugements (négociations de prix, gestion des exceptions)
• Demandes de données sensibles (informations d’autres clients, dossiers financiers)
• Demandes hors de votre domaine (conseils fiscaux, conseils juridiques, recommandations de produits pour les concurrents)

Rédigez un prompt système qui dit explicitement « Si l’utilisateur demande [X], refusez et expliquez pourquoi. Proposez de transférer à un humain. » Cette seule pratique réduit les taux d’hallucination de 30 à 50 % dans les déploiements réels car le modèle a des limites claires.

La Stack No-Code Qui Fonctionne Vraiment

Il existe des centaines de plateformes d’assistants IA. La plupart sont chères (500–2 000 $/mois), opaques sur leur fonctionnement, et rigides en matière de personnalisation.

Une alternative fonctionnelle : composer une stack à partir d’outils spécialisés. Chaque outil fait une chose bien. Vous les connectez.

Pourquoi cette structure fonctionne : Chaque outil est remplaçable. Si Pinecone devient cher, remplacez-le par Supabase. Si Make devient limitant, passez à n8n. Vous n’êtes pas enfermé dans les contraintes arbitraires d’un seul fournisseur.

Coût total pour un système fonctionnel desservant 500–2 000 interactions clients/mois : 80–250 $/mois. Cela inclut les appels API LLM, la base de connaissances et la plateforme d’orchestration.

Étape par Étape : Construire Votre Premier Flux de Travail

Construisons un exemple concret : un assistant de support client qui répond aux questions de remboursement et transmet les cas complexes aux humains.

Étape 1 : Définir le Flux de Conversation

Cartographiez ce qui se passe à chaque point :

L'utilisateur envoie un message
  ↓
L'assistant récupère les documents pertinents de la base de connaissances
  ↓
L'assistant génère une réponse
  ↓
La réponse nécessite-t-elle un jugement humain ?
  → Oui : créer un ticket de support + notifier l'équipe
  → Non : envoyer la réponse à l'utilisateur

Cela semble évident. Les équipes le sautent et se retrouvent avec des assistants qui donnent des réponses partielles ou font des promesses qu’ils ne peuvent pas tenir.

Étape 2 : Préparer Votre Base de Connaissances

Rassemblez les documents dont votre assistant a besoin :

• Page FAQ (exportée en markdown ou PDF)
• Document de politique de remboursement
• Page de tarifs
• Documentation produit
• Problèmes ou limitations connus

Uploadez-les sur Pinecone, Weaviate ou Supabase Vector. Si vous n’avez jamais fait cela : la plupart des bases de données vectorielles ont des tutoriels. Celui de Pinecone dure 10 minutes.

Testez la récupération manuellement. Posez une question à votre assistant et vérifiez s’il a bien récupéré le bon document. C’est là que 40 % des déploiements IA no-code échouent – la récupération est faible, donc l’assistant invente des choses.

Étape 3 : Rédiger le Prompt Système

C’est ici que le comportement est verrouillé. Un prompt vague = réponses imprévisibles. Un prompt précis = comportement cohérent.

Mauvais prompt système :

Vous êtes un assistant de support client utile. Répondez aux questions sur nos produits et politiques.

Pourquoi cela échoue : Le modèle n’a pas de limites. Si un client demande « quels sont vos tarifs par rapport au Concurrent X », le modèle pourrait inventer des comparaisons. S’il demande « puis-je ignorer votre délai de remboursement », le modèle pourrait suggérer que c’est possible.

Prompt système amélioré :

Vous êtes un assistant de support client pour [Entreprise]. Votre rôle est de répondre aux questions concernant les remboursements, l'accès aux comptes et les problèmes techniques.

Instructions :
1. Utilisez UNIQUEMENT les informations de la base de connaissances ci-dessous. N'utilisez pas de connaissances externes.
2. Si l'utilisateur pose une question sur les remboursements, vérifiez d'abord son statut de compte (via la recherche CRM). Indiquez-lui son statut spécifique.
3. Si l'utilisateur pose des questions sur les prix ou les comparaisons de produits, ne spéculez PAS. Dites : « Nos tarifs dépendent de votre cas d'utilisation. Je vais vous mettre en relation avec le service commercial. »
4. Si l'utilisateur vous demande d'ignorer une politique de remboursement ou de faire une exception, refusez poliment et transférez à [équipe d'escalade].
5. Pour chaque réponse, incluez une phrase expliquant ce qui se passe ensuite (par exemple, « Je vais créer un ticket pour notre équipe » ou « Vous devriez recevoir un e-mail de confirmation dans 2 minutes »).

Base de connaissances :
[insérer vos documents ici]

Si vous ne pouvez pas répondre à une question avec les informations ci-dessus, dites : « Je n'ai pas cette information. Je vais transmettre cela à notre équipe. » Créez ensuite un ticket de support.

La deuxième version est plus longue. Elle est aussi 60 % plus efficace car le modèle sait exactement ce qui est dans son champ d’application et ce qui ne l’est pas.

Étape 4 : Configurer l’Orchestration dans Make (ou Zapier/n8n)

C’est là que le flux de travail réside. Voici le schéma réel :

Déclencheur : Nouveau message dans Slack (ou e-mail, ou formulaire web)
  ↓
Action 1 : Extraire l'ID client du message (correspondance de modèle ou recherche)
  ↓
Action 2 : Interroger le CRM pour les données client (optionnel mais puissant)
  ↓
Action 3 : Envoyer le message + contexte client à l'API Claude
  ↓
Action 4 : Analyser la réponse de Claude pour le drapeau [ESCALADE]
  ↓
Si [ESCALADE] : Créer un ticket + notifier l'équipe
Si PAS [ESCALADE] : Renvoyer la réponse au client

Pourquoi le drapeau [ESCALADE] ? Parce que vous avez besoin d’un moyen pour que le modèle dise « c’est au-delà de mon champ d’application ». Dans le prompt système, dites à Claude d’inclure [ESCALADE] en haut de sa réponse s’il a besoin d’un humain. Ensuite, dans Make, recherchez cette chaîne.

Exemple :

Claude génère : « [ESCALADE] Ce client demande une exception de remboursement. Il est client depuis 3 ans. Je ne suis pas autorisé à approuver les exceptions. »

Make voit [ESCALADE], crée un ticket et envoie l'explication à l'équipe de support.
Le client reçoit : « J'ai transmis votre demande à notre équipe. Vous aurez une réponse sous 2 heures. »

Étape 5 : Configurer une Interface Simple

Ne construisez pas encore de site web. Commencez avec ce que vous avez :

• Slack : Si vos clients sont déjà dans un espace de travail Slack, les formulaires natifs de Slack + l’intégration Make = fait en une heure.
• E-mail : Configurez une adresse e-mail de support dédiée. Zapier surveille la boîte de réception et déclenche votre flux de travail.
• Widget de chat web : Intégrez un widget connecté à Slack (Slackmoji, Orion, ou similaire) sur votre site web. Conversation client → va sur Slack → votre flux de travail s’en occupe.

Les widgets de chat web coûtent 50–200 $/mois. L’intégration native Slack est gratuite. L’intégration e-mail via Zapier est gratuite. Commencez pas cher, mettez à niveau quand vous en avez besoin.

Comment Gérer le Contexte et la Mémoire

Une interaction unique est facile. Un assistant réel doit se souvenir de la conversation.

C’est là que la plupart des approches no-code échouent. La solution : stocker l’historique de conversation dans une base de données.

Schéma :

• Chaque fois qu’un utilisateur envoie un message, enregistrez-le dans une base de données (Airtable, Supabase, même une feuille Google).
• Lorsque l’assistant doit répondre, récupérez les 5 à 10 derniers messages pour cet utilisateur.
• Incluez cet historique dans l’appel API Claude comme contexte de conversation.
• Enregistrez la réponse de Claude dans la base de données.

Cela coûte presque rien mais donne l’impression que la conversation est continue au lieu d’isolée.

Exemple d’appel API avec Make :

POST https://api.anthropic.com/v1/messages
{
  "model": "claude-opus",
  "max_tokens": 1024,
  "system": "[votre prompt système ici]",
  "messages": [
    {"role": "user", "content": "J'ai perdu ma clé API"},
    {"role": "assistant", "content": "Je peux vous aider à la réinitialiser. Êtes-vous connecté à votre compte ?"},
    {"role": "user", "content": "Oui"}
  ]
}

Make peut construire cela automatiquement en récupérant les 10 dernières lignes de l’historique de conversation de votre base de données. Prend 5 minutes à configurer.

Quand Cette Approche Échoue

Le no-code fonctionne jusqu’à ce qu’il ne fonctionne plus. Connaissez les limites :

Problème 1 : Logique de Données Complexe

Si votre flux de travail doit interroger plusieurs systèmes, traiter des données conditionnellement et prendre des décisions basées sur la logique métier, Make devient finalement ingérable. Vous écrirez 150 étapes et ce sera impossible à maintenir.

Solution : Déplacez la logique vers un backend léger (Node.js, Python, même une Google Cloud Function). Gardez Make simple – laissez Make orchestrer, laissez le code gérer la logique.

Problème 2 : Latence de Réponse

Si vos clients ont besoin de réponses en moins de 2 secondes, les flux de travail no-code (qui enchaînent plusieurs appels API) peuvent expirer. À 500+ utilisateurs simultanés, la latence devient critique.

Solution : Passez à une plateforme dédiée (comme Voiceflow, Langchain, ou un backend personnalisé). Ou optimisez sans relâche : mettez en cache les requêtes de base de connaissances, pré-calculez les embeddings, utilisez un LLM plus rapide (Mistral 7B au lieu de Claude).

Problème 3 : Limites de Fenêtre de Contexte

Claude Opus a 200K tokens de contexte. GPT-4o a 128K. Mistral 7B a 32K. Si vos conversations deviennent longues ou votre base de connaissances est énorme, vous atteindrez les limites.

Solution : Implémentez une récupération plus intelligente. Au lieu de déverser toute votre base de connaissances dans chaque requête, interrogez votre base de données vectorielle pour les 3 à 5 documents les plus pertinents. Cela maintient les tokens bas et les réponses rapides.

Problème 4 : Conformité et Gestion des Données

Si vos clients sont dans des industries réglementées (finance, santé, juridique), les politiques de gestion des données de Make et Zapier pourraient ne pas répondre aux exigences de conformité. Vous pourriez avoir besoin d’une infrastructure personnalisée avec une résidence des données garantie.

Solution : Utilisez des outils auto-hébergés (n8n, bases de données vectorielles open-source) ou passez à un backend que vous contrôlez entièrement.

Comparaison des Modèles pour les Tâches d’Assistant

Tous les LLM ne sont pas aussi efficaces pour les assistants d’entreprise. Voici ce qui compte vraiment :

Que choisir : Pour la plupart des assistants d’entreprise (support, qualification de vente, connaissances internes), Claude Sonnet 4 est le juste milieu. Meilleur suivi des instructions que GPT-4o, moins cher qu’Opus, et la fenêtre de contexte de 200K permet d’intégrer des conversations entières plus de grandes bases de connaissances.

Mistral devient compétitif si vous gérez un volume élevé (plus de 10 000 interactions/mois) et pouvez tolérer des taux d’hallucination légèrement plus élevés. La différence de coût (2 $/mois sur 1 000 appels) est importante à grande échelle.

Évitez Llama 3 pour les assistants, sauf si vous l’exécutez localement et que le coût est la priorité absolue. La fenêtre de contexte plus petite et le taux d’hallucination plus élevé rendent plus difficile la mise en œuvre de garde-fous.

Échecs Courants et Comment les Éviter

Nous avons construit et débogué suffisamment de ces systèmes pour savoir où ils cassent généralement.

Échec 1 : Base de Connaissances Désynchronisée

Vous mettez à jour votre page de tarifs. Votre assistant ne le sait pas pendant trois jours car personne n’a pensé à re-uploader les documents sur Pinecone.

Correction : Mettez en place une synchronisation automatisée des documents. Si vos documents résident dans Notion, utilisez l’API Notion + Make pour extraire automatiquement les mises à jour. S’ils sont dans un CMS, même schéma. Une fois par semaine, ré-intégrez et mettez à jour votre base de données vectorielle. Make le fait en 10 étapes.

Échec 2 : L’Assistant Répond à des Questions Qu’il ne Devrait Pas

Un client demande « pouvez-vous m’envoyer les tarifs de mon concurrent ? » L’assistant invente le site web et les tarifs d’un concurrent.

Correction : Soyez agressif avec les limites du prompt système. Listez les catégories de questions spécifiques auxquelles l’assistant ne doit PAS répondre. Ajoutez un filtre de récupération : si la requête correspond à certains mots-clés (« concurrent », « autre entreprise », « alternative à »), n’interrogez pas la base de connaissances. Transférez immédiatement.

Échec 3 : Les Conversations Deviennent Confuses ou en Boucle

Les conversations multi-tours échouent car l’historique de conversation n’est pas correctement passé à l’API.

Correction : Enregistrez chaque appel API. Dans Make ou Zapier, ajoutez une étape qui enregistre ce que vous envoyez à Claude. Chaque requête. Chaque réponse. Quand les choses cassent, examinez les logs. Habituellement, vous verrez que l’historique de conversation est vide ou mal formé.

Échec 4 : Les Transmissions ne Fonctionnent Pas

L’équipe de support ne voit jamais les demandes transmises. Les clients ne sont jamais informés qu’un humain prend le relais.

Correction : Testez le chemin de transmission avant le lancement. Créez une conversation de test qui déclenche [ESCALADE]. Vérifiez que (1) un ticket est créé, (2) la bonne équipe est informée, (3) le client est informé de ce à quoi s’attendre. Faites cela 10 fois. La plupart des échecs se situent dans la logique de notification, pas dans l’assistant lui-même.

Votre Plan d’Implémentation de 30 Jours

N’essayez pas de construire le système parfait dès le premier jour. Livrez quelque chose de petit et itérez.

Semaine 1 : Planification et Configuration

• Définissez vos 5 principaux cas d’utilisation (30 min)
• Rédigez les limites de portée (30 min)
• Rassemblez les documents de la base de connaissances (2 heures)
• Inscrivez-vous à Pinecone, Make/Zapier, API Claude (1 heure)

Semaine 2 : Base de Connaissances et Prompt Système

• Uploadez les documents sur Pinecone (1 heure)
• Testez la récupération manuellement (1 heure)
• Rédigez et itérez sur le prompt système (2 heures)
• Testez le prompt système sur vos 5 cas d’utilisation (2 heures)

Semaine 3 : Orchestration et Tests

• Construisez le flux de travail Make (4–6 heures)
• Connectez-vous à votre interface (Slack ou e-mail) (2 heures)
• Testez 20 conversations manuellement (2 heures)
• Déboguez les échecs (2 heures)

Semaine 4 : Raffinement et Lancement

• Examinez tous les échecs de la semaine 3 (1 heure)
• Mettez à jour le prompt système et la base de connaissances (2 heures)
• Configurez le monitoring (logs, suivi des transmissions) (2 heures)
• Lancez auprès d’un groupe d’utilisateurs limité (1 heure)
• Itérez en fonction des retours (en cours)

Total : ~25 heures de travail concentré. Vous pouvez diviser cela entre 4 personnes et terminer en une semaine. Ou une personne sur un mois.

Ce qu’il faut faire en premier, aujourd’hui : Notez vos 5 principales questions de support. Pas des sujets généraux. Des questions spécifiques. Ensuite, pour chacune d’elles, notez les données dont l’assistant aurait besoin pour y répondre correctement. Cet exercice de 30 minutes clarifie plus qu’une semaine de planification générique.

Quand Mettre à Niveau au-delà du No-Code

Vous avez construit un MVP. Il gère 30 % de votre volume de support. Et maintenant ?

Passez à un backend personnalisé lorsque :

• Vos flux de travail dépassent 80 étapes dans Make (ils deviennent ingérables)
• Vous avez besoin de temps de réponse inférieurs à 1 seconde de manière constante (le no-code ajoute de la latence)
• Vous dépensez 500 $/mois et plus en outils d’orchestration
• Vos exigences de conformité exigent une résidence des données que vous ne pouvez pas garantir avec des outils SaaS
• Vous avez besoin d’intégrer des systèmes que Make ne prend pas en charge

À ce stade, passez à Langchain (Python ou TypeScript), déployez sur votre propre infrastructure ou Replit/Modal, et construisez à partir de là. Vous avez déjà prouvé le concept. Maintenant, vous optimisez.

Mais voici le truc : 80 % des entreprises n’ont pas besoin de cette mise à niveau. Le no-code fonctionne. C’est moins cher, plus rapide à déployer, et maintenable par des non-ingénieurs. Utilisez-le sauf si vous avez une raison spécifique de ne pas le faire.