Build ou buy : développer ou acheter son callbot

Un arbitrage que peu de sources traitent sans intérêt

Cherchez « développer ou acheter un callbot » et vous tomberez, dans le désordre, sur des contenus publiés par des éditeurs de plateformes qui ont intérêt à vous vendre un abonnement, et par des agences de développement qui ont intérêt à vous vendre un projet. Les deux répondent avant d'avoir vraiment posé la question, et aucun des deux ne détaille sérieusement les coûts de l'option qu'il ne vend pas.

Cet article a la même contrainte, et autant le dire d'emblée. Call-bot.ai est édité par Nehos Groupe - KBC SOLUTIONS, une agence qui conçoit et développe des solutions conversationnelles sur mesure pour ses clients. Nous sommes donc économiquement intéressés à ce qu'un lecteur choisisse de développer plutôt que d'acheter — exactement à l'inverse d'un éditeur de plateforme, qui préfère vous voir signer un abonnement plutôt que financer un développement chez une agence. Aucun des deux camps n'a de raison structurelle de donner un avis équilibré, et nous ne prétendons pas y échapper par la seule vertu.

Ce que nous pouvons faire, en revanche, c'est refuser la conclusion la plus confortable pour notre propre activité. Cet article ne conclut pas que le sur-mesure est le choix le plus sûr : il présente les coûts réels du développement, y compris ceux qui jouent en sa défaveur, les limites réelles d'une plateforme, et une solution intermédiaire qu'aucun des deux modèles économiques n'a intérêt à mettre en avant en premier. La démarche suit la même logique que notre méthodologie de test : documenter la méthode et ses limites plutôt que promettre une neutralité qu'on ne peut pas prouver.

Si vous découvrez tout juste ce que recouvre un callbot, notre guide qu'est-ce qu'un callbot pose les bases avant d'aller plus loin.

Ce que coûte vraiment le développement sur mesure

Un devis de développement sur mesure ne se résume pas à un forfait de mise en route. Il recouvre au minimum quatre postes : la conception du scénario conversationnel (intentions à couvrir, cas limites, ton), l'intégration technique (reconnaissance vocale, moteur de langage, synthèse vocale, téléphonie, et leur orchestration), les tests en conditions réelles (accents, bruit de fond, reformulations), et la mise en production (hébergement, supervision, sécurité).

Le dernier poste change la nature du projet : développer sur mesure ne signifie pas s'affranchir des briques de reconnaissance vocale, de langage et de synthèse existantes, mais les assembler et les maintenir vous-même plutôt que de payer un éditeur pour le faire. Un projet sur mesure reste construit, la plupart du temps, sur les API d'un fournisseur de modèle de langage et de synthèse vocale : vous développez la couche qui orchestre ces briques, pas les briques elles-mêmes. La dépendance à un tiers ne disparaît donc pas, elle change de nature. La politique de dépréciation des modèles d'OpenAI prévoit par exemple un préavis d'au moins six mois pour les modèles généralement disponibles, et de trois mois seulement pour leurs variantes : un projet sur mesure hérite de cette contrainte sans la couche d'abstraction qu'une plateforme maintient de son côté pour l'absorber. Nous suivons ces évolutions dans notre pilier IA & modèles.

Pour donner un ordre de grandeur sur le coût du travail lui-même : les grilles de tarifs freelance observées en France en 2026 situent le TJM moyen tous profils confondus autour de 450 € par jour, et celui d'un profil confirmé à senior spécialisé en IA ou MLOps entre 650 € et 1 200 € par jour. Un premier callbot fonctionnel sur un seul scénario, intégré à une ligne téléphonique et à un agenda, mobilise généralement plusieurs semaines de travail à temps plein avant mise en production ; un périmètre couvrant plusieurs scénarios avec une intégration CRM profonde se compte en mois plutôt qu'en semaines. Sur cette seule base de calcul, hors infrastructure et maintenance, l'écart entre les deux se chiffre déjà en dizaines de milliers d'euros. Ce sont des ordres de grandeur pour cadrer une discussion, pas un devis : seul un chiffrage sur un périmètre précis donne un montant fiable.

À ce coût de construction s'ajoutent les postes détaillés dans les coûts cachés d'un projet callbot — téléphonie, préparation du corpus documentaire, supervision, dérive après mise en production — qui s'appliquent tout autant à un projet sur mesure qu'à une plateforme. Côté plateforme, une partie de ces postes est mutualisée et facturée par un fournisseur qui les opère à l'échelle de centaines de clients. Côté sur mesure, chacun retombe intégralement sur vous.

Le risque n'est pas seulement budgétaire, et il ne s'arrête pas à la mise en production. Dans un communiqué du 25 juin 2025, Gartner estime que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, pour cause de coûts qui dérivent, de valeur métier non démontrée et de contrôles de risque insuffisants — des causes internes au projet, pas des défaillances de la brique conversationnelle elle-même. Sur un projet sur mesure, ce risque ne se limite pas à un abandon en cours de route : c'est aussi le développeur ou l'agence qui part, l'équipe interne qui change de priorités, ou la maintenance qui glisse discrètement au second plan une fois le projet livré — une dérive de même nature, côté organisationnel cette fois, que celle décrite côté technique et réglementaire dans le poste « dérive après mise en production » de notre article sur les coûts cachés d'un projet callbot. Un projet sur mesure porte l'intégralité de ce risque en interne, sans le filet qu'offre, la plupart du temps, une base de clients qui maintient la pression sur un éditeur de plateforme pour qu'il continue à faire évoluer son produit ; une plateforme le porte pour partie sur un produit déjà éprouvé ailleurs — même si ce filet peut lui aussi céder, comme le montre le cas Twilio détaillé plus loin. Nous suivons ces échecs de projets dans notre pilier agents IA.

Ce qu'on perd avec une plateforme

Acheter une plateforme ne se limite pas à payer un abonnement contre du confort : cela signifie aussi accepter des contraintes que le vendeur a fixées avant vous, sur quatre plans.

Le premier est le choix imposé de fournisseurs sous-jacents. Une plateforme sélectionne des modèles de reconnaissance vocale, de langage et de synthèse à votre place, et les facture avec sa propre marge — nous détaillons cette mécanique dans les coûts cachés d'un projet callbot. Les meilleures plateformes laissent choisir entre plusieurs modèles au sein de leur catalogue, mais ce catalogue reste défini par elles : vous choisissez parmi leurs options, pas parmi toutes les options du marché.

Le deuxième est la vitesse d'évolution du produit. Une fonctionnalité qui vous manque dépend de la feuille de route du vendeur, pas de la vôtre : vous pouvez la demander, vous ne pouvez pas la prioriser.

Le troisième est la structure tarifaire : la facturation à la minute et à la ligne simultanée fait qu'un pic d'appels imprévu ne coûte jamais le tarif affiché en moyenne, mais celui du dépassement, parfois deux fois plus élevé sur certaines grilles.

Le quatrième, enfin, est le plus structurant pour la suite de cet article : le risque commercial du vendeur devient le vôtre. Une plateforme peut changer de tarification, se faire racheter, réorienter sa stratégie ou disparaître — et le jour où cela arrive, la question n'est plus celle des fonctionnalités manquantes, mais celle du prix à payer pour partir.

Le coût de sortie : ce qui se passe si vous voulez changer de plateforme

C'est l'angle le plus systématiquement absent des comparatifs de callbots, parce qu'aucun vendeur n'a intérêt à le documenter : que se passe-t-il si, deux ans après avoir signé, vous voulez changer de plateforme ?

Trois briques doivent être reconstruites, pas simplement transférées.

Les scénarios conversationnels. Les intentions, les flux de dialogue et les règles de transfert vers un humain sont conçus dans l'éditeur propriétaire de la plateforme, sous un format qui lui est propre. Il n'existe pas de format d'échange standard entre plateformes de callbot, comparable à un export CSV pour un tableur : migrer un scénario d'un éditeur à un autre suppose, dans la plupart des cas, de le reconcevoir dans l'éditeur cible plutôt que de l'importer tel quel.

L'intégration technique. Téléphonie, CRM, agenda, système de paiement : chaque connecteur est configuré spécifiquement pour l'architecture de la plateforme quittée. Changer de fournisseur ne déplace pas cette configuration, il la refait, même quand la logique métier reste identique.

Les données d'entraînement et l'historique. C'est le point le plus mal compris. Les transcriptions d'appels et les journaux de conversation s'exportent en général sans difficulté majeure, au format CSV ou JSON, parfois via API. Ce qui ne s'exporte pas, c'est ce que la plateforme a appris de vos échanges : le réglage fin du modèle sur votre vocabulaire métier, les ajustements accumulés au fil des mois, la connaissance tacite que l'équipe support du vendeur a construite sur votre compte. Cette distinction entre journaux exportables et compréhension acquise non transférable figure jusque dans les guides d'évaluation du risque fournisseur publiés par des éditeurs d'IA conversationnelle eux-mêmes — une source qui n'a pourtant aucun intérêt à fragiliser la confiance dans le modèle SaaS dont elle vit, ce qui rend l'aveu d'autant plus crédible.

Deux cas réels illustrent l'ampleur du sujet, dans un sens et dans l'autre.

Twilio a mis fin à sa plateforme conversationnelle Autopilot : selon l'avis officiel de fin de vie publié par Twilio, le support technique a cessé de traiter les nouvelles demandes le 25 février 2023, et les API ont définitivement cessé de fonctionner le 25 août 2023. Twilio n'a proposé aucun produit de remplacement maison — les entreprises concernées ont dû migrer vers des solutions tierces, notamment Amazon Lex ou Google Dialogflow, sur le calendrier de Twilio, pas sur le leur. C'est le scénario le plus dur : une plateforme qui disparaît et impose sa propre date limite.

Le second cas est plus favorable, et pourtant tout aussi révélateur. Google propose un outil de migration officiel pour faire passer un agent de l'ancienne génération Dialogflow ES vers la nouvelle génération Dialogflow CX — un changement chez le même vendeur, avec un outil dédié. Or, selon la documentation officielle de Google Cloud, cet outil ne copie que les types d'entités personnalisés et les phrases d'entraînement des intents, et génère par ailleurs une liste d'éléments à traiter manuellement. Autrement dit : même la migration la mieux outillée, chez le même fournisseur, ne se fait pas en un clic.

Il n'existe pas de statistique publique sur le coût moyen d'une migration de callbot spécifiquement — personne n'a intérêt à la publier. La donnée la plus proche disponible vient d'une enquête plus large : le DevOps Migration Index 2025 de CloudBees, mené par l'institut TrendCandy auprès de plus de 300 dirigeants IT et technologiques d'entreprise, mesure un coût moyen de 1,75 million de dollars et un dépassement budgétaire moyen de 18 %, soit environ 315 000 $ de dérapage, sur des projets de migration de plateforme tous secteurs confondus. Ce chiffre ne porte pas sur les callbots : il donne un ordre de grandeur du risque de migration logicielle en entreprise en général, pas un devis transposable à votre projet.

Ce que cela signifie concrètement avant de signer : demandez, par écrit, dans quel format vos scénarios et vos données sont exportables, ce que devient le réglage fin du modèle en cas de départ, et si le contrat prévoit un accompagnement à la migration ou seulement un accès en lecture aux données brutes. Une plateforme sérieuse répond à ces trois questions par un document, pas par une assurance orale.

Critères de décision

Il n'existe pas de réponse universelle, et toute méthode qui en propose une déguise un choix commercial en conseil neutre. Sept facteurs, en revanche, permettent de faire pencher la décision selon votre situation.

Facteur	Plutôt acheter une plateforme	Plutôt développer sur mesure
Nature du besoin	Cas d'usage standard (prise de RDV, FAQ, qualification d'appel)	Logique métier propriétaire, au cœur de votre différenciation
Volume d'appels	Faible à moyen, ou encore incertain	Élevé, stable, justifiant l'investissement
Délai souhaité	Mise en route en semaines	Plusieurs mois acceptés
Ressources internes	Pas d'équipe technique dédiée à maintenir dans la durée	Équipe capable d'opérer et de faire évoluer le système en continu
Contraintes réglementaires	Standards, couvertes par les garanties du fournisseur	Spécifiques (hébergement souverain, secteur régulé) et non couvertes par une offre existante
Structure budgétaire	Dépense récurrente (opex), prévisible mois par mois	Investissement initial plus lourd (capex), assumé et amorti
Horizon du projet	Valider rapidement un cas d'usage avant d'aller plus loin	Pari stratégique de long terme sur ce canal

Deux précisions sur ce tableau. D'abord, il n'attribue aucun poids aux facteurs : sur votre projet, un seul d'entre eux — l'hébergement des données dans un secteur régulé, par exemple — peut suffire à trancher, indépendamment des autres. Nous suivons ces obligations spécifiques dans notre rubrique réglementation & confiance. Ensuite, la colonne « plateforme » n'est pas homogène : les huit critères détaillés dans comment choisir un callbot — hébergement des données, latence réelle, coût par appel résolu, SLA — servent à départager les plateformes entre elles, une fois que vous avez déjà tranché en faveur de l'achat.

Solution intermédiaire : ni tout sur mesure, ni plateforme fermée

Entre les deux extrêmes, une option existe, structurellement désavantagée dans le débat : ni un éditeur de plateforme pure ni une agence de développement pure n'a intérêt à la mettre en avant en premier, puisqu'elle réduit ce que chacun facture. Elle prend deux formes concrètes.

Le no-code personnalisable. La plupart des plateformes de callbot sérieuses permettent aujourd'hui de connecter des fonctions ou des webhooks personnalisés à un moteur conversationnel par ailleurs géré par le fournisseur : reconnaissance vocale, synthèse, téléphonie et orchestration restent pris en charge par la plateforme, pendant qu'une logique métier spécifique — un calcul d'éligibilité, une règle de priorisation, une écriture particulière dans votre CRM — est développée à la marge. Vous gardez la vitesse de mise en route d'une plateforme sur l'essentiel du parcours, sans renoncer à la partie qui vous différencie réellement.

Le low-code ciblé sur les points critiques. Version plus poussée de la même logique : la plateforme reste le socle (voix, téléphonie, conformité de base), mais la partie qui compte le plus pour votre métier est développée et hébergée par vous, hors de l'éditeur, puis appelée depuis la plateforme via une API. Cette architecture a un avantage direct sur le coût de sortie détaillé plus haut : la logique différenciante, celle qui a le plus de valeur, vit dans votre propre code plutôt que dans l'éditeur de flux propriétaire d'un vendeur — elle reste donc portable même si vous changez un jour de plateforme pour la couche voix et téléphonie.

Cette approche ne supprime pas tous les coûts de sortie identifiés plus haut — la conversation elle-même resterait à reconcevoir chez le nouveau fournisseur — mais elle réduit la part irrécupérable, en isolant ce qui a le plus de valeur métier de ce qui est le plus commoditisé. C'est concrètement la voie la plus souvent recommandable pour une entreprise de taille intermédiaire qui n'a ni l'équipe pour un projet entièrement sur mesure, ni un besoin assez standard pour se satisfaire d'une plateforme fermée telle quelle. Précisons, dans le même souci de transparence que plus haut, que cette voie hybride implique elle aussi le plus souvent un développement payant — dont une agence comme la nôtre peut vivre. Le conflit d'intérêts ne disparaît donc pas complètement avec cette option intermédiaire, il est seulement moins total qu'avec un sur-mesure intégral.

Questions fréquentes

Combien coûte le développement d'un callbot sur mesure ?

Il n'existe pas de chiffre unique : le coût dépend du nombre de scénarios couverts, de la profondeur d'intégration et de la séniorité de l'équipe mobilisée. À titre d'ordre de grandeur, les TJM freelance IA observés en France en 2026 se situent entre 450 € et 1 200 € par jour selon le profil, et un premier scénario fonctionnel mobilise généralement plusieurs semaines de travail à temps plein avant mise en production. Seul un chiffrage sur un périmètre précis donne un montant fiable.

Peut-on changer de plateforme de callbot facilement après l'avoir déployée ?

Non, pas facilement. Les scénarios conversationnels sont conçus dans un format propriétaire à chaque éditeur, les intégrations techniques sont à reconfigurer, et le réglage fin accumulé par la plateforme sur vos échanges ne se transfère généralement pas vers un concurrent. Même une migration outillée chez le même fournisseur, comme celle de Dialogflow ES vers CX chez Google, laisse une partie du travail à faire manuellement.

Une agence de développement peut-elle donner un avis neutre sur ce choix ?

Pas totalement, et il faut le dire clairement : une agence qui vit de projets sur mesure a un intérêt économique à recommander le développement, tout comme un éditeur de plateforme a intérêt à recommander l'achat. C'est précisément la raison pour laquelle cet article déclare ce conflit d'intérêts dès son ouverture et documente les coûts réels des deux options, y compris ceux qui jouent contre le sur-mesure.

Quand privilégier une solution intermédiaire plutôt qu'un choix extrême ?

Dès que votre besoin combine une majorité de fonctionnalités standards (accueil, prise de rendez-vous, FAQ) et une minorité de règles propres à votre activité qui ne trouvent pas d'équivalent chez un éditeur. Dans ce cas de figure, le plus fréquent en pratique, garder une plateforme pour la voix et la téléphonie tout en développant uniquement la logique différenciante limite à la fois le coût initial et le coût de sortie.

En résumé

Développer un callbot sur mesure coûte plus cher à construire, mais garde la logique métier dans votre propre code ; acheter une plateforme coûte moins cher à démarrer, mais transfère au vendeur des décisions que vous ne maîtrisez plus — et expose à un coût de sortie rarement anticipé au moment de signer : scénarios à reconcevoir, intégrations à refaire, réglages fins qui ne voyagent pas d'un éditeur à l'autre. Aucune des deux options n'est neutre pour qui vous la recommande, y compris nous : cet article n'a pas conclu que le sur-mesure était la réponse la plus sûre, parce que ce n'est pas toujours vrai. Pour la plupart des projets, la question la plus utile n'est pas « développer ou acheter », mais « quelle part de mon besoin est vraiment différenciante, et mérite d'être développée à part ». Si vous voulez appliquer cette grille à votre propre projet, parlons-en.