Pourquoi j'ai construit mon propre helpdesk IA au lieu d'en payer un

Chaque site SaaS a besoin d'un chat de support. Un visiteur arrive sur votre page de tarifs, se pose une question, et si personne n'est là pour y répondre à cet instant, il s'en va. La conversion meurt en silence.

La solution évidente, c'est Intercom. Ou Zendesk. Ou Crisp, Drift, HelpScout, Tidio -- il y a des dizaines d'options, toutes facturées entre 29 et 99 dollars par mois et par siège. Pour un fondateur solo qui gère six produits depuis Abidjan, le calcul ne tient pas. Cela représente entre 174 et 594 dollars par an pour un widget de chat sur un seul site marketing.

Mais le prix n'était pas la vraie raison pour laquelle j'ai construit le mien. La vraie raison, c'est que j'avais déjà tout ce qu'il me fallait.

L'infrastructure était déjà en place

sh0.dev dispose d'un assistant IA. Il alimente le chat du tableau de bord -- connecté au serveur de l'utilisateur via MCP, avec accès à 25 outils pour gérer les déploiements, les applications, les bases de données et les sauvegardes. Il a aussi un mode documentation pour le site marketing : un assistant plus simple qui recherche dans la documentation, consulte les endpoints d'API et génère des fichiers de configuration.

Le mode documentation est exactement ce dont un helpdesk a besoin. Un visiteur demande « Combien coûte sh0 ? » -- l'IA a les données tarifaires dans son prompt système. Un visiteur demande « Comment déployer une application Next.js ? » -- l'IA parcourt la documentation et renvoie un guide étape par étape avec des liens.

L'infrastructure de streaming était construite. Le format SSE était défini. Le pipeline d'exécution des outils était testé. Le système de facturation suivait les tokens. Il ne me manquait qu'un endpoint public sans authentification et un widget flottant pour consommer le flux.

Quelques heures de travail. Pas un abonnement à 50 $/mois.

Le cadre de décision

J'ai une règle pour les décisions construire-ou-acheter : si le coût marginal de construction est inférieur à un mois d'abonnement, on construit. Le coût récurrent devient alors nul (ou quasi nul), et on est propriétaire de la fonctionnalité pour toujours.

Voici la ventilation réelle des coûts :

C'est le coût d'exécution qui rend le modèle viable à grande échelle. Haiku 4.5 coûte 1,20 $ par million de tokens en entrée et 6,00 $ par million de tokens en sortie (avec notre marge de 20 %). Une conversation helpdesk typique utilise environ 2 000 tokens en entrée et 500 en sortie. Soit 0,0024 $ pour l'entrée et 0,003 $ pour la sortie. Disons 0,005 $ par échange. La plupart des visiteurs posent une ou deux questions.

À 1 000 conversations par mois -- bien plus que ce qu'un nouveau produit génère -- le coût total est de 5 $. Intercom facture 29 $/mois pour le même volume, sans aucune IA qui connaisse réellement votre produit.

Ce que l'IA sait et qu'Intercom ignore

C'est la partie qui change complètement l'équation économique. Un helpdesk traditionnel exige l'une de ces deux choses :

1. Un agent humain qui connaît le produit (coûteux, pas disponible 24 h/24)
2. Un chatbot entraîné sur votre documentation (nécessite un entraînement séparé, de la maintenance et un fournisseur d'IA tiers)

Le helpdesk IA de sh0 n'a besoin ni de l'un ni de l'autre. Il dispose déjà d'un prompt système de 4 000 mots contenant :

• Chaque fonctionnalité et capacité de sh0
• La structure complète de navigation de la documentation
• La grille tarifaire complète
• La référence des commandes CLI
• La référence des endpoints d'API (consultable via outil)
• Les liens vers chaque page de documentation

Quand un visiteur demande « Est-ce que sh0 peut déployer une application Django ? », l'IA ne devine pas. Elle appelle search_docs("deploy django"), trouve la page de documentation pertinente et répond avec une réponse concise et un lien. Quand un visiteur demande « Quelle est la différence entre Pro et Business ? », elle lit la grille tarifaire depuis son propre prompt et fournit une comparaison claire.

Ce n'est pas un chatbot générique. C'est la même IA qui a conçu l'architecture du produit, en train d'expliquer le produit qu'elle a construit.

L'architecture en 30 secondes

Le visiteur tape dans le widget
    |
    v
POST /api/ai/helpdesk (sans auth, avec limitation de débit)
    |
    v
buildHelpdeskPrompt() = buildDocsPrompt() + surcouche de persona chat
    |
    v
Anthropic API (Haiku 4.5, streaming)
Outils : search_docs, get_api_reference, suggest_actions, web_search
    |
    v
Flux SSE -> le widget rend le markdown en temps réel
    |
    v
Sauvegarde des messages dans PostgreSQL, déduction des tokens du portefeuille du propriétaire du site

Le widget est un seul composant Svelte 5. 490 lignes. Un bouton flottant en bas à droite, qui s'ouvre sur un panneau de chat de 380x520 px. Rendu markdown via marked avec assainissement DOMPurify. Persistance de session via localStorage. Suggestions interactives après chaque réponse.

Le tableau de bord admin affiche chaque conversation : informations sur le visiteur, transcription complète, utilisation des tokens, coût estimé. Gestion du statut (ouvert, résolu, spam) en un clic.

Ce que je n'ai pas construit

Ce que j'ai délibérément laissé de côté est tout aussi important :

• Pas de formulaire de collecte d'e-mail. Le visiteur peut facultativement fournir son nom et son adresse e-mail, mais ce n'est pas une barrière. La friction tue la seule raison d'être du chat helpdesk : répondre à la question immédiatement.
• Pas de transfert vers un humain. Si l'IA ne peut pas répondre, elle suggère d'envoyer un e-mail à [email protected]. Je suis un fondateur solo -- je n'ai pas d'agents en attente dans une file.
• Pas de personnalité de chatbot. Le prompt système dit « sois chaleureux, concis et conversationnel ». Il ne dit pas « sois amusant », « utilise des emojis » ou « aie un prénom ». L'IA est un agent de support, pas un personnage.
• Pas de tableau de bord analytique. La page admin affiche les conversations et les coûts. Je n'ai pas besoin d'analyse de tunnel de conversion ni de score de sentiment. J'ai besoin de savoir ce que les visiteurs demandent et si l'IA a répondu correctement.

Chaque fonctionnalité que je n'ai pas construite est une fonctionnalité que je n'ai pas à maintenir.

La sécurité

Un endpoint IA public et non authentifié sur un site marketing est une surface qui nécessite un durcissement. Trois couches de protection :

Limitation de débit : 30 messages par tranche de 10 minutes par session. 60 par tranche de 10 minutes par IP. 5 nouvelles conversations par heure et par IP. En mémoire, pas Redis -- acceptable pour le volume de trafic d'un nouveau produit.

Validation des entrées : Messages limités à 2 000 caractères. Identifiants de session limités à 100 caractères. Nom du visiteur, e-mail et URL de la page tronqués à des limites raisonnables. Conversations limitées à 200 messages au total.

Protection de la facturation : Vérification du solde avant chaque appel API. Si le portefeuille du propriétaire du site est vide, le helpdesk renvoie « temporairement indisponible » -- il ne continue pas à streamer en accumulant un solde négatif.

Les deux sessions d'audit ont trouvé deux problèmes critiques que j'avais manqués :

1. XSS via {@html} : le widget rendait le markdown généré par l'IA sans assainissement. Une attaque par injection de prompt pouvait amener l'IA à produire <img onerror="...">. Corrigé avec DOMPurify.
2. Aucune vérification du solde : l'endpoint appelait deductTokens() après le streaming mais ne vérifiait jamais le solde avant. Corrigé en ajoutant checkBalance() avant l'appel API.

Les deux étaient évidents avec du recul. Les deux étaient invisibles pendant l'implémentation. C'est pour cela que la méthodologie d'audit multi-session existe.

Le véritable avantage

Le widget helpdesk est passé du plan à la production en une seule session, suivie de deux sessions d'audit. Neuf fichiers modifiés. Migration appliquée. Le build passe.

Mais le véritable avantage n'est pas la vitesse. C'est que l'agent de support IA ne donnera jamais une mauvaise réponse sur les tarifs de sh0, ne dira jamais à un visiteur que sh0 prend en charge une fonctionnalité qu'il ne prend pas en charge, et ne tombera jamais en panne parce qu'un fournisseur SaaS a changé son API.

La connaissance réside dans le prompt système. Quand j'ajoute une fonctionnalité à sh0, je mets à jour la documentation. Le helpdesk IA lit la documentation. La connaissance se propage automatiquement.

Pas de pipeline d'entraînement. Pas de fine-tuning. Pas de mises à jour manuelles de FAQ. Juste un prompt système qui reste synchronisé avec le produit qu'il décrit.

Cela vaut bien plus que n'importe quel widget à 50 $/mois.

Prochain article de la série : Du chatbot de documentation à l'agent de support en direct -- L'architecture technique : comment nous avons transformé un assistant IA de documentation existant en un helpdesk public avec 9 fichiers et zéro nouvelle dépendance.