Une IA service client maison coûte « quelques centimes par ticket »… tant qu'on ne compte que la facture de l'API. Depuis deux ans, nous entendons la même question chez les e-commerçants et les scale-ups que nous rencontrons : pourquoi acheter une solution quand un LLM, un peu de RAG et un développeur motivé semblent suffire ? La question est légitime. Plusieurs de nos interlocuteurs ont d'ailleurs construit quelque chose qui marche.
Mais quand on pose les chiffres complets sur la table, le calcul change. Une responsable service client nous a donné ses coûts unitaires : 4 € par ticket pour un conseiller en CDI, 1,80 € pour un agent offshore, environ 2 centimes pour l'IA interne. Sur le papier, le make écrase tout. Dans les faits, cette IA ne traitait que 2 % des tickets.
Cet article reprend ce que nos clients et prospects nous ont dit, avec leurs mots, sur quatre enjeux que le coût d'API ne montre pas : le setup, la maintenance, le maintien en condition opérationnelle et la maîtrise des coûts.
Le premier coût du make, c'est le temps d'une personne qualifiée pendant plusieurs mois, avant le premier ticket traité. Ce coût n'apparaît presque jamais dans les comparatifs.
Un responsable produit et tech d'une marque de beauté nous a montré un assistant impressionnant : un LLM branché à leur entrepôt de données, à Notion, à Slack et à Airtable, capable de répondre à des questions complexes. Il en explique lui-même la condition : « On a quelqu'un à la data qui est ultra calé, et qui a la chance d'avoir le temps d'avoir pu mettre tout ça en place. » Et il ajoute : « Ça prend un peu de temps de ranger, de donner l'accès aux données et tout. »
C'est le schéma que nous retrouvons partout :
Le prompt est la partie facile. Ce qui prend des mois, c'est de brancher l'IA aux outils où vivent les tickets et les données. Pour un e-commerçant typique sur Shopify et Gorgias, la liste ressemble à ceci :
| Connector | Ce qu'il faut construire | Pour répondre à quoi |
|---|---|---|
| Helpdesk (Gorgias, Zendesk, Freshdesk…) | Lecture des tickets et de l'historique, écriture d'un brouillon ou d'une réponse, tags, statuts, escalade vers un agent | Tout : c'est là qu'arrivent les demandes |
| Boutique (Shopify, PrestaShop…) | Authentification, lecture des commandes, clients, produits, remboursements | « Où en est ma commande ? », « Puis-je être remboursé ? » |
| Logistique (ShippingBo, transporteurs) | Numéros de suivi, statuts de livraison, incidents | Le suivi de colis, souvent la première cause de contact |
| Base de connaissances (Notion, FAQ, centre d'aide) | Import, découpage, mise à jour quand un article change | Les questions produit et les politiques |
| Outils métier internes (back-office, ERP, data warehouse) | Un endpoint d'API, des droits d'accès par client | Les cas spécifiques : abonnements, garanties, rémunérations… |
Chaque ligne demande une authentification sécurisée, la gestion des quotas d'appels, des webhooks pour réagir en temps réel et des tests sur de vrais tickets. Une start-up de l'énergie qui a construit son IA nous l'a dit : le plus difficile, ce sont les données de production des clients, « qui sont dans un outil interne » que personne n'a branché.
Chez Klark, ces connecteurs existent déjà : Gorgias, Zendesk, Freshdesk, Salesforce, Intercom, Front, HubSpot et Crisp côté helpdesk, Shopify et PrestaShop côté boutique, ShippingBo en natif, et un connecteur universel pour les outils internes. Le client fournit un accès, et la mise en production se fait en quelques jours.
Le vrai prix du setup, c'est donc un salaire d'ingénieur data ou IA sur trois à huit mois, et tout ce que cette personne ne fait pas pendant ce temps. C'est exactement le calcul que nous nous faisons nous-mêmes pour nos propres outils : est-ce que je peux y consacrer assez de temps pour être assez loin dans six, huit ou douze semaines, et qu'est-ce que je retarde ailleurs ?
Une IA maison ne s'arrête pas à la mise en production : chaque nouveau process, canal ou type de demande redevient un ticket pour l'équipe tech. Et c'est là que la dette technique s'accumule.
Un responsable chez un acteur du reconditionné, qui dispose pourtant de sa propre infrastructure IA dans le cloud, résume l'arbitrage : développer en interne, « au risque d'après, il faut les maintenir, et c'est un vrai sujet, qui n'est pas forcément simple, si déjà pour la mise en place on n'est pas très nombreux ». Ou faire appel à un partenaire dédié : « Si ça tombe en panne, c'est vous qui assurez la maintenance. »
L'e-commerçant sport qui a fait le choix du make le reconnaît aussi : « Si demain on doit changer les choses, il faut qu'on passe par nos développeurs, et là, ça peut prendre un peu de temps. » Ajouter WhatsApp, les réseaux sociaux ou les avis clients à son périmètre ? « Il y a peut-être des choses pour lesquelles on ne va pas avoir la bande passante ou pas savoir faire. »
Les connecteurs eux-mêmes se périment. Shopify publie une nouvelle version de son API chaque trimestre et retire les anciennes au bout d'environ un an : un connecteur fait maison doit donc être mis à jour régulièrement, sous peine de cesser de fonctionner. Il en va de même quand un helpdesk change ses champs, quand on change de transporteur ou quand on migre de Gorgias vers Zendesk : chaque changement d'outil remet le chantier des connecteurs sur la table.
Le deuxième risque est humain. Un client qui fait tourner une IA interne en parallèle de Klark nous l'a dit sans détour : « Aujourd'hui, on a une personne en particulier qui gère 80 % du sujet IA. Même s'il a fait des docs, on est quand même assez dépendant. » Cette personne partait en congé de plusieurs mois peu après. Dans une autre entreprise, la responsable service client ne sait pas combien de développeurs travaillent sur l'IA : « J'ai l'impression que c'est un peu une équipe fermée et que je n'ai pas accès à toute l'information. »
Enfin, beaucoup de solutions « achetées » reproduisent le problème du make : il faut dessiner et entretenir des workflows en si/alors/sinon. Le responsable service client d'une plateforme de stationnement l'a formulé ainsi en évaluant les solutions : quand on calcule le ROI, « il faut aussi prendre le coût humain » du temps passé à construire et maintenir ces règles.
Une IA maison est généralement bâtie sur un seul modèle et un seul outil : elle vieillit à la vitesse du marché des LLM. La faire tourner correctement demain demande un travail que personne n'a budgété.
Les architectures que nous voyons sont souvent mono-modèle. Une start-up de l'énergie a construit son assistant sur « une API Gemini, qu'on prompte en interne ». La marque de beauté citée plus haut compare elle-même deux briques de sa stack : l'un des modèles « est plus fort » que l'autre, mais l'outil le plus adapté à son cas « n'est pas fait pour ça », et l'utiliser à grande échelle reviendrait à « cramer les tokens à la vitesse de l'espace ».
Maintenir une IA en condition opérationnelle, cela veut dire au minimum :
C'est la raison pour laquelle Klark est agnostique : nous sommes branchés aux principaux fournisseurs (OpenAI, Anthropic, Mistral, Amazon Bedrock) et nous sélectionnons le modèle en temps réel selon la tâche, le coût et la latence. Ce travail, une équipe interne devrait le refaire seule, en plus de son vrai métier.
Le make paraît moins cher parce qu'on ne compte que la ligne d'API ; dès qu'on ajoute les salaires et le taux d'automatisation réel, l'écart se resserre ou s'inverse.
L'échange le plus clair vient d'un client qui fait tourner les deux solutions. Son responsable nous a d'abord dit qu'en interne, « ça nous coûte beaucoup de fois moins », pour une qualité « relativement similaire ». Puis notre CSM lui a demandé ce qu'il mettait dans ce coût. Sa réponse : les coûts des modèles, « assez dérisoires », et c'est tout. « On n'a pas vraiment pris en compte le salaire des gens qui travaillent dessus en interne, parce que c'est assez difficile de mesurer combien de temps ils y passent réellement. »
| Poste | Ce qu'on voit dans le make | Ce qu'on oublie souvent |
|---|---|---|
| AI models | Facture d'API, quelques centimes par ticket | Hausse de consommation quand on étend le périmètre ou qu'on passe à un modèle plus puissant |
| Setup | Rien, c'est « du temps interne » | 3 à 8 mois d'un profil data ou IA, et les projets décalés |
| Maintenance | Nothing | Chaque nouveau canal ou process, dépendance à une personne |
| Quality | Nothing | Relecture par les team leads, mesures à construire soi-même |
| Volume traité | Coût par ticket automatisé | Un taux d'automatisation bas : 2 % dans un cas rencontré |
Le dernier point est décisif. Une IA à 2 centimes le ticket qui n'en traite que 2 % ne résout pas le problème de staffing. La responsable concernée le dit : même avec 10 %, « ça ne me suffit pas à avoir mon staffing ».
Côté buy, tous les modèles ne se valent pas non plus. Les mêmes prospects pointent les tarifs « complètement démesurés » de certaines offres, un forfait de 3 000 € par mois chez un prestataire, ou un engagement de trois ans demandé par un grand éditeur de helpdesk sans période de test. Une responsable GenAI le résume : « Si on achète des outils qui font de la GenAI pour toutes les équipes, ça va nous coûter trop cher. » Ce qui rend le buy maîtrisable, c'est un coût qui suit la valeur produite : chez Klark, un abonnement fixe et un prix par ticket réellement résolu, après une période de test sans engagement.
Acheter une IA service client, ce n'est pas acheter un accès à un LLM : c'est acheter la compréhension de vos règles métier, sur chaque canal, à un prix aligné sur votre réalité. C'est ce qui fait le ROI, et ce qui fait que la solution dure.
Un modèle généraliste sait rédiger. Il ne sait pas qu'un remboursement au-delà de 30 jours passe par un responsable, qu'un client VIP ne reçoit jamais de réponse automatique, ou que tel transporteur connaît des retards cette semaine. Ces règles sont rarement écrites : elles vivent dans la façon dont vos conseillers traitent les tickets.
C'est là que se joue l'expertise. Klark apprend vos règles à partir de votre historique de tickets, sans workflow à dessiner, puis une série d'agents de contrôle vérifie chaque réponse avant envoi : le sujet est-il éligible à l'automatisation, la réponse est-elle conforme à vos process, répond-elle vraiment à la question ? Les sujets sensibles que vous désignez restent en brouillon pour un conseiller. Une réponse qui ne passe pas ces contrôles n'est pas envoyée : elle reste en brouillon pour un conseiller.
Vos clients ne choisissent pas leur canal en fonction de votre stack. Ils écrivent par mail, remplissent un formulaire, ouvrent le chat, appellent, commentent sur les réseaux. Une IA maison couvre en général un canal, celui par lequel le projet a commencé. L'e-commerçant sport cité plus haut l'avoue : WhatsApp, les réseaux sociaux et les avis sont justement ce que son équipe n'aura peut-être pas la bande passante de construire.
| Canal | Ce que fait l'IA | Ce que cela change |
|---|---|---|
| Brouillons pour les conseillers, puis réponses automatiques sur les sujets validés | Productivité des conseillers, délai de réponse | |
| Formulaire | Qualification et réponse dès l'envoi | Moins d'allers-retours pour compléter la demande |
| Chatbot | Résolution en direct, escalade documentée vers un humain | Réponse immédiate, 24 h/24 |
| Voix | En bêta : prise en charge des appels récurrents | Moins d'attente au téléphone |
| Réseaux sociaux et messageries | Réponses automatiques puis reprise en main par un conseiller | Couverture des canaux souvent laissés de côté |
Le même socle, nourri de vos règles métier, sert tous les canaux. Une règle corrigée une fois s'applique partout.
Une IA maison suit la roadmap de votre équipe tech. Une IA intégrée à votre helpdesk suit celle de l'éditeur, et vous enferme dans son écosystème : changer d'outil, c'est tout reconstruire. Klark fait un choix inverse : une roadmap 100 % consacrée à l'IA pour le service client, et aucune dépendance à un fournisseur.
C'est aussi ce qui garantit la pérennité : votre IA service client ne dépend ni de la disponibilité d'un développeur, ni de la stratégie commerciale d'un éditeur.
Automatiser pour automatiser dégrade la satisfaction. Le client qui fait tourner son IA interne et Klark en parallèle l'a mesuré : sur la même période, la satisfaction des réponses Klark est légèrement au-dessus de celle de son IA interne. L'objectif n'est pas de remplacer les conseillers, mais de leur retirer les demandes à faible valeur pour qu'ils se concentrent sur le conseil, les cas complexes et la vente.
Le ROI d'une IA service client dépend d'un prix qui suit la valeur produite. Chez Klark :
Si l'IA ne résout pas, vous ne payez pas. C'est cet alignement qui rend la solution pérenne : elle reste rentable au pic de Black Friday comme en période creuse, sans renégociation ni surprise sur la facture.
Le make a du sens quand l'IA est votre métier ; le buy l'emporte dès que votre service client doit avancer plus vite que votre roadmap tech. Plusieurs de nos interlocuteurs en arrivent à la même conclusion. Le responsable du service client d'une marque outdoor, après en avoir parlé à son DSI : « Si demain on veut vraiment augmenter à la fois notre capacité de réponse et notre qualité de réponse, on ne pourra pas le faire seuls. »
| Le make ne tient que si vous cochez tout… | Le buy s'impose dès que… |
|---|---|
| Une équipe IA dédiée à plein temps, avec un remplaçant formé : ni un développeur entre deux projets, ni un alternant. Y compris dans 6 mois, et dans 1 an | La personne qui porte le sujet a d'autres priorités, ou peut partir demain |
| Vous acceptez au moins 3 mois sans résultat avant le premier ticket automatisé, en mobilisant fortement vos équipes métier pour transférer leurs règles et leur savoir-faire | Vous avez besoin de résultats avant le prochain pic : Black Friday, soldes, Noël |
| Vous savez construire, puis réparer à chaque mise à jour d'API, chaque connecteur : helpdesk, Shopify, transporteurs, avis clients | Votre stack repose sur des outils du marché : Gorgias, Zendesk, Shopify… |
| Vous testez chaque nouveau modèle d'IA et savez basculer en quelques heures en cas de panne ou de hausse de prix | Vous ne voulez pas dépendre d'un seul fournisseur d'IA |
| Vous mesurez vous-même la qualité : erreurs, réouvertures, satisfaction, et vous assumez chaque mauvaise réponse envoyée à un client | Vous voulez un contrôle qualité avant chaque envoi automatique |
| Votre budget absorbe le coût complet : salaires, API, maintenance, et le risque d'un projet abandonné en cours de route | Vous voulez un coût prévisible, payé uniquement au résultat |
Il suffit qu'une seule case manque à gauche pour que le projet maison cale : un départ, un pic d'activité, une API qui change. Plusieurs des entreprises citées ici en ont fait l'expérience.
Le confort du buy, au fond, c'est de ne plus porter ces quatre chantiers. Vous fournissez un accès à votre helpdesk et à vos outils, vous testez sur vos vrais tickets sans engagement, et vous ne payez que ce qui est réellement résolu. Vos équipes tech restent sur votre produit, et vos conseillers sur les demandes qui ont besoin d'un humain.
Et si vous avez déjà une IA maison, la question n'est pas forcément de la remplacer. Plusieurs de nos clients font tourner les deux en parallèle pour comparer, chiffres à l'appui. C'est la meilleure façon de trancher.
