Ce que j'aurais aimé savoir dès le départ sur le développement Chatbots

Erik dirige une agence de développement de chatbots. Elle fournit des solutions de chatbot aux grandes entreprises, en particulier dans le domaine du service à la clientèle et du marketing.

Erik m'a dit que, d'une part, les affaires marchent très bien parce que le taux de conversion des propositions pour chatbots est extrêmement élevé. Cela s'explique peut-être par le fait qu'il est l'un des premiers à commercialiser cet espace.

En même temps, il s'efforçait de trouver les bons outils pour construire efficacement des sites chatbots de qualité.

Lorsqu'il a découvert les plateformes sans code telles que Chatfuel et Motion.ai, il était optimiste et pensait que ces outils résoudraient son problème. S'il a constaté qu'ils fonctionnaient bien pour le prototypage des bots, il a rapidement rencontré des problèmes.

De nombreux robots devaient être personnalisés d'une manière qui ne pouvait être représentée que par du code, et ces plateformes ne prenaient pas en charge le codage. Certains bots devaient être intégrés aux systèmes existants de son client, ce qui n'était pas possible.

Ces problèmes à eux seuls étaient rédhibitoires, mais même s'ils pouvaient être résolus, il n'était toujours pas à l'aise avec toute la logique et les données résidant sur un système tiers sur lequel il n'avait aucun contrôle. Ses clients insistaient souvent pour héberger eux-mêmes le bot pour des raisons de sécurité.

Il a donc décidé de faire coder les robots à partir de zéro en utilisant Microsoft Bot Framework et, dans la mesure du possible, de faire appel à des développeurs situés dans des pays à faible coût. Cette prévisibilité a engendré d'autres problèmes.

Bien qu'il soit désormais propriétaire du code et des données et qu'il puisse personnaliser le robot en fonction de ses besoins, les résultats sont mitigés.

Il s'est rapidement rendu compte que tous les robots avaient de nombreuses caractéristiques en commun, telles que la sécurité basée sur les rôles, les abonnements, la diffusion, la présence d'un humain dans la boucle, mais que ces caractéristiques étaient codées à partir de zéro par les développeurs, ce qui augmentait inutilement le temps de développement et réduisait ses marges de profit.

Les risques de développement étaient également inutilement élevés, car différents développeurs codaient les fonctionnalités de différentes manières et l'architecture globale évoluait de façon ad hoc. Certains développeurs avaient reconnu ce problème et commencé à créer des bibliothèques réutilisables pour les fonctionnalités communes, mais ces bibliothèques étaient loin d'être les bibliothèques de haute qualité sur lesquelles il aurait voulu bâtir son entreprise. Elles présentaient leurs propres risques et dépendances indésirables, en particulier lorsque la fonctionnalité requise était complexe. Il lui était difficile de vérifier la qualité, et encore plus de donner à ses clients l'assurance que tout ce qui était construit était d'un niveau suffisamment élevé.

Il a brièvement envisagé l'idée de créer sa propre plateforme, mais cela lui a semblé excessif. Cela engendrerait des coûts de développement et de maintenance inutiles, ainsi que des problèmes de vente potentiels si des cadres standard du marché, préférés par les clients, apparaissaient, ce qui, selon lui, se produirait. Ce n'était qu'une question de temps.

Dans son esprit, le problème était similaire à celui auquel les développeurs web étaient confrontés à l'aube de l'internet. À l'époque, il n'existait pas d'outils de gestion de contenu tels que Wordpress, de sorte que les sites web devaient être codés à partir de zéro à chaque fois. Il en résultait les mêmes problèmes d'augmentation des coûts de développement et de qualité variable du code et des résultats que ceux auxquels il était confronté aujourd'hui lorsqu'il créait des robots.

Lorsque Erik a trouvé Botpress.io en ligne, il ne lui a pas fallu longtemps pour reconnaître que Botpress offrait une solution potentielle à ses problèmes. Il aimait l'architecture modulaire en théorie et il lui semblait logique de construire l'équivalent d'un CMS pour les robots. C'était ce qu'il pensait être nécessaire. Il pourrait s'agir de la pièce manquante du puzzle, mais il devait d'abord répondre à certaines questions.

Tout d'abord, il devait s'assurer que la solution était robuste, sécurisée et fiable.

Deuxièmement, il devait s'assurer que toutes les caractéristiques critiques communes qu'il avait identifiées comme étant nécessaires étaient disponibles via le cadre de travail

Troisièmement, il devait s'assurer que l'économie fonctionnerait pour son agence.

Étant lui-même une personne pratique et technique, il a décidé de valider personnellement les deux premières questions en testant réellement le système. Il a rejoint la communauté Botpress et a travaillé sur certains des tutoriels vidéo en utilisant la version open source.

Le fait qu'il existait déjà une communauté importante et active de développeurs utilisant le logiciel signifiait qu'il avait été testé dans la bataille, ce qui était une bonne chose.

Il s'est d'abord inquiété du fait que Botpress était une source ouverte que ses clients pourraient considérer (à juste titre dans de nombreux cas) comme un risque pour la sécurité. Il a cependant découvert que Botpress disposait d'une version d'entreprise protégée qui était maintenue séparément de la version open source, spécifiquement pour résoudre les problèmes de sécurité.

Bien sûr, la version open source offrait certains avantages, car elle était gratuite et, dans de nombreux cas, idéale pour développer des robots en dehors des cas d'utilisation en entreprise. Cela signifie que les composants et l'approche ont été largement utilisés et validés par de nombreux développeurs différents.

Bon nombre de ses clients ont exigé qu'ils hébergent le chatbot sur place et qu'ils contrôlent les données pour des raisons de sécurité et des raisons commerciales, ce que Botpress leur a permis de faire. En outre, Botpress permet une personnalisation complète du code et une intégration avec les systèmes internes, ce qui était le problème initial qu'il rencontrait avec les plateformes "sans code".

La plupart des fonctionnalités qu'il souhaitait étaient disponibles. Il s'agit notamment de la sécurité basée sur les rôles, de la gestion multi-utilisateurs et des interfaces utilisateur pour la gestion des bots après le déploiement. Il pouvait facilement ajouter ce qui manquait sous la forme d'un module.

En fait, l'architecture modulaire et les interfaces graphiques du système ont permis de comprendre très facilement où tout s'insérait. Cela signifiait que même s'il changeait de développeur à mi-parcours d'un projet ou si quelqu'un devait reprendre le code après une longue interruption, la personne concernée ne mettrait pas longtemps à se mettre au diapason. Jusqu'à présent, tout va bien.

La question économique était évidemment aussi importante. L'utilisation de Botpress réduirait-elle ses coûts de développement globaux ? Les marges bénéficiaires étaient étroites. Il s'attendait à ce que l'utilisation d'un cadre comme Botpress réduise les coûts de développement tout en augmentant la qualité et les fonctionnalités.

Il s'est avéré que ses attentes étaient justes. Le coût de fonctionnement de Botpress ne représentait qu'une petite fraction du coût de construction de certaines fonctionnalités par lui-même et la qualité était supérieure à celle d'une solution propriétaire.

L'avantage caché de cette approche est qu'il peut consacrer plus de temps à l'interface utilisateur et aux fonctionnalités du chatbot, ce qui lui permet d'améliorer considérablement l'expérience du client final.

Il avait observé que beaucoup de chatbots sur le marché n'étaient pas très bons. On pourrait même dire qu'en tant qu'industrie, les fabricants de chatbots ne répondent pas aux attentes de leurs clients.

On peut penser que cela est dû au fait que les entreprises n'étaient pas prêtes à allouer des fonds raisonnables au développement de chatbots parce qu'elles n'étaient pas sûres des résultats.

Un autre argument est que le processus de développement de chatbots a été très inefficace jusqu'à présent parce que les fabricants de chatbots ne disposaient pas d'outils efficaces pour développer chatbots et que, par conséquent, une grande partie du coût de développement a été concentrée sur ce qui est essentiellement de l'infrastructure.

L'émergence de frameworks tels que Botpress a eu le potentiel d'améliorer massivement la qualité de chatbots , étant donné qu'un budget de développement plus important est consacré à l'expérience de l'utilisateur.

Pour mémoire, Erik n'est pas une personne en chair et en os, mais un ensemble de propriétaires d'agences qui nous ont contactés pour nous faire part de leurs problèmes, de leurs besoins et de leur intérêt pour les possibilités offertes par le site chatbots . De diverses manières, ils ont partagé leur version de "Ce que j'aurais aimé savoir dès le départ sur le développement de chatbots pour mes clients".

Si nous pouvions résumer les principales questions, elles seraient les suivantes :

• La construction d'un excellent site chatbots nécessite l'accès au code et aux données.
• Les développeurs doivent personnaliser la logique commerciale et l'intégrer aux systèmes internes. Il n'est pas possible de créer un excellent site chatbots sans développeurs.
• De nombreuses entreprises clientes ont des préoccupations en matière de sécurité et veulent donc faire fonctionner leur chatbot dans leurs locaux. Ils souhaitent également bénéficier de la même sécurité basée sur les rôles et de la même gestion des utilisateurs que celle qu'ils attendent de tout logiciel qu'ils utilisent.
• Le cadre choisi par une agence doit offrir un large éventail de caractéristiques communes.
• Il n'est pas plus logique pour une agence (ou un atelier de développement) de construire son propre cadre de chatbot pour son usage interne que de construire ses propres bases de données à partir de zéro. Non seulement cela ne serait pas rentable et engendrerait d'importants coûts de maintenance, mais leurs clients préféreraient probablement qu'ils utilisent des produits d'infrastructure établis, bien compris et conçus à cet effet, plutôt que d'essayer de construire eux-mêmes une infrastructure non essentielle.
• Le secteur a besoin de cadres de travail afin de consacrer davantage d'argent au développement de l'expérience utilisateur plutôt qu'à l'infrastructure.