Claude API : comment construire un assistant IA sur-mesure pour votre TPE en 2026

ChatGPT connaît tout. Il ne connaît pas votre entreprise. Il ne sait pas que votre délai de livraison standard est de 5 jours ouvrés, que votre remise maximale accordée sans validation est de 8 %, ou que le contact chez votre principal fournisseur s'appelle Marc et répond mieux le matin. Ces informations sont dans vos fichiers, vos emails, vos habitudes. Pas dans un modèle généraliste entraîné sur internet.

L'API Claude d'Anthropic permet de construire un assistant qui, lui, connaît votre contexte. Pas par fine-tuning (coûteux, complexe, rarement utile), mais par des approches bien plus accessibles : injecter votre contexte métier directement dans chaque requête, connecter Claude à vos outils via des fonctions, ou déployer un agent qui maintient une mémoire entre les sessions. Trois niveaux d'implémentation, trois profils de budget et de complexité.

Dans cet article, je détaille ces trois niveaux avec des exemples concrets tirés de projets réels, un comparatif de coûts entre les modèles Claude disponibles, et les erreurs que j'observe le plus souvent chez les équipes qui se lancent seules. Objectif : vous permettre de choisir le bon niveau pour votre situation, sans vous retrouver avec un prototype qui ne tient pas en production.

Niveau 1 : le system prompt avancé, sans une ligne de code

Le point d'entrée le plus rapide pour personnaliser Claude, c'est le system prompt : une instruction que vous rédigez une fois, qui s'injecte automatiquement au début de chaque conversation. Claude lit ce contexte avant chaque échange et adapte ses réponses en conséquence.

Un system prompt bien construit pour une TPE peut contenir :

• La description de l'entreprise et de ses produits ou services
• Le ton à adopter (formel, décontracté, technique)
• Les règles métier clés (délais, politiques de retour, remises autorisées)
• Les contacts internes et leurs responsabilités
• Les documents de référence collés directement dans le prompt (tarifs, CGV, FAQ interne)

Concrètement : une agence immobilière avec laquelle j'ai travaillé a construit un assistant pour ses négociateurs en collant 12 pages de leur règlement interne, leur grille de commissions et les clauses-types de leurs mandats dans un system prompt de 8 000 tokens. Setup : 45 minutes. Résultat : les négociateurs posent leurs questions à Claude au lieu de déranger le directeur toutes les heures.

Ce niveau fonctionne directement dans Claude.ai (pas d'API nécessaire) ou via l'API avec le paramètre system. La limite à connaître : le contexte est stateless. Claude ne se souvient de rien d'une session à l'autre. Si vous avez besoin de mémoire persistante, il faudra passer au niveau 3.

Ce que vous pouvez faire sans développeur

Claude.ai Pro (20$/mois) permet de créer des "Projects" avec un system prompt dédié. Chaque membre de l'équipe invité au projet bénéficie du même contexte. C'est suffisant pour un cas d'usage interne limité à une équipe de moins de 10 personnes. Au-delà, ou pour exposer l'assistant à des clients, il faudra passer par l'API.

Niveau 2 : Claude + tool use, connecté à vos vrais outils

Le system prompt a une limite évidente : il ne peut pas aller chercher des données en temps réel. Si vous voulez que Claude consulte l'état d'une commande, mette à jour une fiche client dans votre CRM ou ajoute une ligne dans un Google Sheet, il faut lui donner des outils.

Le "tool use" (aussi appelé function calling) est le mécanisme par lequel Claude peut appeler des fonctions que vous définissez. Vous déclarez les fonctions disponibles, Claude décide lesquelles appeler selon la question posée, et votre code exécute l'appel puis renvoie le résultat à Claude, qui formule sa réponse.

Exemple concret : assistant support client connecté à Airtable

Pour un client dans la formation professionnelle, j'ai construit un assistant qui répond aux questions des stagiaires. Quand un stagiaire demande "Quand commence ma prochaine session ?", Claude appelle la fonction get_trainee_schedule, qui interroge Airtable en temps réel et renvoie les données exactes du stagiaire identifié. Claude répond avec les dates précises, pas avec un "vérifiez auprès de votre organisme".

Les fonctions les plus utiles que je déploie :

1. Lecture Google Sheets : consulter tarifs, stocks, planning en temps réel
2. Écriture Google Sheets : enregistrer une demande, mettre à jour un statut
3. Recherche Notion : interroger une base de connaissance interne
4. Requête CRM : consulter l'historique d'un client par son email
5. Envoi email ou SMS : déclencher une notification après une action

Ce niveau nécessite du code côté serveur (Node.js ou Python, quelques centaines de lignes) pour gérer la boucle API. Délai de mise en place : 2 à 5 jours selon la complexité des connexions.

Niveau 3 : Managed Agents, avec mémoire persistante entre les sessions

Les deux premiers niveaux sont stateless : Claude repart de zéro à chaque conversation. Pour des cas d'usage où la continuité compte (un assistant commercial qui suit l'avancement de chaque prospect, un support client qui se souvient des échanges précédents), il faut de la persistance.

Anthropic propose depuis 2026 une API Managed Agents en beta. Le principe : vous créez un agent une fois (avec son system prompt, ses outils, ses paramètres), Anthropic l'héberge avec un identifiant stable, et chaque session utilisateur s'y connecte. L'historique de la session est maintenu côté Anthropic. Entre les sessions, vous pouvez injecter une mémoire résumée.

Ce niveau est adapté à trois types de situations :

• Un assistant client qui reconnaît les utilisateurs récurrents et reprend le fil
• Un agent de recherche qui accumule des notes sur un dossier sur plusieurs jours
• Un outil interne qui suit l'avancement de projets longs (semaines, mois)

Attention : Managed Agents est encore en beta au moment où j'écris. La fiabilité est bonne pour des sessions de moins d'une heure, moins prédictible pour des agents qui tournent en continu. À éviter en production critique pour l'instant, mais excellent pour des environnements internes où une erreur occasionnelle est acceptable.

Combien ça coûte vraiment en 2026 ?

Le tarif Claude se calcule en tokens (environ 750 mots = 1 000 tokens). Voici un comparatif entre les deux modèles que j'utilise le plus souvent en production :

Pour 1 000 requêtes par mois avec un contexte moyen de 2 000 tokens input et 500 tokens output :

• claude-haiku-4-5 : environ 4,50 $ par mois. Adapté à un assistant de support client ou FAQ interne.
• claude-opus-4-8 : environ 22 $ par mois. Justifié si la qualité de raisonnement est critique (analyse juridique, rédaction commerciale, décisions structurées).

Dans la majorité des projets TPE que je construis, je commence avec Haiku et je passe à Opus seulement si les résultats ne sont pas suffisants pour le cas d'usage. La différence de qualité n'est perceptible que sur des tâches complexes.

Ce qui va souvent mal (et comment le corriger)

L'erreur la plus fréquente que je vois : injecter trop de contexte dans le system prompt sans structure. Un dirigeant colle 40 pages de documentation en vrac, Claude répond de façon approximative, et la conclusion est "l'IA ne comprend pas notre métier". Ce n'est pas un problème de modèle, c'est un problème de structure.

Claude fonctionne mieux avec du contexte structuré. Comparez ces deux approches :

Version non structurée : "Notre politique de retour est de 30 jours sauf pour les articles soldés qui sont 14 jours mais si le client est fidèle depuis plus de 2 ans on peut faire une exception et le délai de traitement est de 5 jours ouvrés mais en août c'est plutôt 10 jours..."

Version structurée :
POLITIQUE DE RETOUR :
- Délai standard : 30 jours
- Articles soldés : 14 jours (pas d'exception)
- Exception client fidèle (+2 ans) : délai étendu à 30 jours sur validation manuelle
- Traitement : 5 jours ouvrés (août : 10 jours)

La deuxième version donne des réponses deux fois plus précises dans mes tests. La règle générale : plus le contexte est structuré (titres clairs, listes, règles explicites), plus Claude l'exploite correctement.

Deuxième erreur fréquente : utiliser Opus quand Haiku suffit, ce qui multiplie les coûts par 5 sans gain de qualité mesurable pour des cas simples. Commencez toujours par Haiku, mesurez, montez en gamme seulement si nécessaire.