- Un chatbot bus est un assistant conversationnel déployé par un réseau de bus ou de cars (urbain, scolaire, interurbain) pour répondre aux questions des voyageurs : prochains passages, perturbations, itinéraires, titres et abonnements, fonctionnement du réseau. Il vit là où le voyageur pose la question : le site du réseau, puis WhatsApp le jour du déplacement.
- Le bus n’est pas un transport comme les autres côté données : depuis la loi d’orientation des mobilités, les autorités organisatrices doivent rendre leurs données statiques et dynamiques accessibles et réutilisables (article L. 1115-1 du code des transports). Au 5 octobre 2026, le Point d’Accès National recense 221 jeux de données temps réel pour les transports en commun, dont 200 qui diffusent les prochains passages.
- Les réseaux français le font déjà, dates à l’appui : un chatbot Messenger côté RATP dès septembre 2017, le connecteur Bonjour RATP sur ChatGPT (relevé le 5 octobre 2026), le NomadCarBot de Nomad Normandie le 3 novembre 2025, le chatbot WhatsApp d’AuxR’M le bus à Auxerre le 28 mai 2026.
- Quatre architectures se suffisent pour couvrir tous les cas : FAQ éditoriale, branchement du flux temps réel, itinéraires porte à porte, titres et réservation. Le routeur au milieu de l’article tranche 72 situations réelles (réseau × besoin × volumétrie × canal).
- Le coût tient en trois lignes : la licence (dès 39 € par mois hors taxes sur la grille Botnation relevée le 5 octobre 2026), les crédits IA (25 € les 1 000), et la construction, gratuite en autonomie ou sur devis via l’offre Entreprise de Botnation.
Le chatbot bus fait surtout l’objet d’annonces : un réseau en lance un, un éditeur vante le sien, et l’histoire s’arrête là. Rien sur la façon de construire le service, sur ce que la loi met déjà à disposition d’un réseau, ni sur ce que ça coûte sur une grille publique. C’est exactement l’objet de cet article.
Car le bus concentre des difficultés que le train ne connaît pas : des centaines de réseaux d’autorités organisatrices différentes, des horaires qui changent aux vacances et à la rentrée, des voyageurs qui n’installent pas une application par réseau, et un pic de questions le matin même du déplacement. Un chatbot bus bien construit répond à ces quatre contraintes à la fois, et les exemples datés plus bas montrent que ce n’est plus de la théorie.
Le plan suit l’ordre qui compte : ce que le voyageur demande, les preuves françaises datées, ce que l’open data réglementaire fournit déjà, les quatre architectures possibles avec un routeur pour choisir, la méthode, les canaux, le droit, et les prix publics du jour. Botnation y intervient des deux côtés qui comptent : éditeur de la plateforme no-code, et prestataire de création sur mesure via son offre Entreprise.
Ce que le voyageur demande à un chatbot bus, mission par mission
Un voyageur ne demande jamais « un chatbot ». Il demande si son bus passe, s’il est en retard, combien coûte le trajet, et comment rejoindre la gare. Voici les six missions qui reviennent sur tous les réseaux, avec pour chacune la condition concrète qui la rend automatisable. C’est la condition, pas la technologie, qui sépare une démonstration d’un service.
| Mission | Exemple de question | Ce qui la rend automatisable |
|---|---|---|
| Prochains passages | « Quand passe le prochain bus pour la gare ? » | Un flux temps réel par arrêt (GTFS-RT ou SIRI), sinon le bot annonce les horaires théoriques et le dit |
| Perturbations et travaux | « Ma ligne est-elle déviée ce soir ? » | Une alimentation de l’état du réseau, et une règle écrite : que dit le bot quand il ne sait pas |
| Itinéraires porte à porte | « Comment aller de chez moi à la zone commerciale ? » | Un moteur d’itinéraire interrogé par le bot, souvent celui que le réseau expose déjà |
| Titres, tarifs, abonnements | « Quel abonnement pour un étudiant ? » | Des réponses validées par le service commercial, puis la billettique pour vendre ou renvoyer |
| Comprendre le réseau | « Où acheter un ticket, la ligne dessert-elle l’école ? » | Une FAQ éditoriale tenue à jour : points de vente, accessibilité, règlement, rentrée scolaire |
| Réclamations et objets trouvés | « J’ai oublié mon sac dans le bus de 17 h » | Un circuit défini : déclaration, collecte des informations, transmission au bon service |
Sur presque tous les réseaux, les deux premières lignes du tableau (passages et perturbations) pèsent plus de la moitié des questions : c’est par elles qu’un chatbot bus commence, et c’est là que l’open data, un peu plus bas dans cet article, change tout. Les quatre dernières demandent du contenu éditorial validé, pas de la plomberie technique : c’est un travail de rédaction avec les services du réseau, pas un projet d’intégration.
Reprenez les questions réellement posées au réseau sur les trois derniers mois : boîte mail, appels, réseaux sociaux, file du guichet. C’est la matière première. Un chatbot bus qui répond aux questions qui arrivent vaut mieux qu’un chatbot qui devine.
Trois réseaux français l’ont fait : les preuves, datées
L’histoire commence mal, et c’est utile de le savoir. Dès septembre 2017, la RATP lance un chatbot sur Facebook Messenger, développé avec la start-up Minsday : itinéraires personnalisés, horaires de passage en stations favorites, alertes perturbations. Le cabinet de conseil mc2i l’a testé fonctionnalité par fonctionnalité en mai 2020, pendant le confinement : sur cinq fonctions évaluées, aucune ne dépasse 2 sur 3, la recherche d’itinéraire tombe à 1 sur 3, et le constat revient comme un leitmotiv : le parcours utilisateur se disloque, le bot renvoie vers le site pour ce qu’il devrait afficher lui-même. La leçon tient en une phrase : un chatbot qui redirige n’est pas un chatbot.
Six ans plus tard, la même ambition est servie par d’autres canaux et de vraies données, et cette fois sur des réseaux de bus et de cars :
- Bonjour RATP sur ChatGPT (page relevée le 5 octobre 2026) : le service francilien propose un connecteur à activer dans ChatGPT, puis à appeler avec @BonjourRATP. La page du service le présente comme donnant accès aux « itinéraires, trafic en temps réel et titres de transport en Île-de-France, directement dans vos échanges », métro, RER, Transilien, bus et tramway compris. Le voyageur obtient un itinéraire, l’état d’une ligne ou un conseil tarifaire sans quitter sa conversation.
- NomadCarBot, réseau Nomad (Normandie) : dans son annonce du 3 novembre 2025, pour le cinquième anniversaire du réseau de cars NOMAD Car, la région présente un assistant disponible sur son site 24 heures sur 24, 7 jours sur 7, et un module « Prochains passages » qui affiche les horaires théoriques des cars à un arrêt donné, pour les lignes commerciales, à n’importe quelle date. L’annonce précise expérimenter la diffusion des horaires en temps réel, travaux et déviations compris, d’abord sur un premier lot de lignes.
- AuxR’M le bus (Agglomération de l’Auxerrois) : le 28 mai 2026, le réseau annonce un chatbot intégré à WhatsApp. Le texte de l’annonce mérite citation, car il liste le périmètre réel : « accompagnement pour comprendre le réseau, recherche d’un horaire, recherche d’un tarif, prendre rendez-vous en agence virtuelle ou encore vous rediriger vers les réservations Flexibus ». Soit trois des six missions du tableau ci-dessus, plus la prise de rendez-vous et le transport à la demande, sur le canal que le voyageur a déjà dans sa poche.
Le triptyque est parlant : un opérateur national multi-réseaux passe par ChatGPT, un réseau régional de cars met l’assistant sur son site, un réseau urbain moyen choisit WhatsApp. Trois canaux, un même mouvement. Et pour le rail, notre panorama du chatbot transport documente un déploiement régional à plus grande échelle, avec ses 23 millions de messages échangés ; le présent article reste volontairement sur le bus et le car.
L’open data change l’équation : ce que la loi met déjà à disposition
Voici le point que les pages commerciales ne disent pas : depuis la loi d’orientation des mobilités du 24 décembre 2019, le branchement d’un chatbot sur les données d’un réseau n’est plus une négociation commerciale avec l’exploitant, c’est un droit posé par le code des transports. L’article L. 1115-1 (créé par l’article 25 de la loi, version en vigueur relevée le 5 octobre 2026 sur le texte consolidé) impose aux autorités organisatrices et à leurs écosystèmes de rendre leurs données accessibles. Le texte est explicite : les détenteurs de données « mettent à jour et rendent accessibles et réutilisables » les données « statiques et historiques observées ainsi que les données dynamiques concernant les déplacements et la circulation ». Et pour lever toute ambiguïté sur qui fournit quoi, le texte dit : « Pour les services de transport qu’elles organisent, les autorités mentionnées au 1° du présent article sont responsables de la fourniture des données », la charge pouvant être confiée aux opérateurs de transport ou aux opérateurs des systèmes d’aide à l’exploitation et à l’information des voyageurs.
Concrètement, ces données atterrissent sur le Point d’Accès National, transport.data.gouv.fr, dont la page d’accueil le rappelle aux producteurs en ces termes : « vous êtes tenus de publier vos données relatives à l’information voyageur sur le Point d’Accès National ». Son tableau de bord, relevé le 5 octobre 2026, donne l’état réel du réservoir :
Les formats ne sont pas exotiques : les horaires théoriques arrivent en GTFS ou NeTEx, le temps réel en GTFS-RT ou SIRI. Ces flux sont exactement ce qu’un chatbot interroge pour répondre à « quand passe le prochain bus » sans inventer : position des véhicules, prochains passages à l’arrêt, messages d’info trafic. Si le réseau du lecteur figure parmi les 362 autorités organisatrices dont les horaires théoriques sont publiés, la question technique n’est pas d’obtenir la donnée, mais de la consommer proprement : fréquence d’interrogation, réponse aux arrêts sans flux, repli sur l’horaire théorique assumé comme tel.
Le compteur du Point d’Accès National compte des jeux de données, pas des engagements de fraîcheur. Avant d’écrire « temps réel » sur la page du réseau, vérifiez sur le tableau de bord que votre réseau diffuse bien les prochains passages en GTFS-RT ou SIRI, et testez le flux un jour de travaux : c’est le jour où la réponse compte.
Quatre architectures de chatbot bus, et un routeur pour choisir
Tous les projets réussis s’empilent sur la même échelle : on commence par ce qui ne bouge pas (la FAQ du réseau), on branche ce qui bouge (le flux temps réel), on ajoute le calcul d’itinéraire, et seulement ensuite la vente et la réservation. Chaque marche se justifie seule, et c’est le rôle du routeur ci-dessous de dire laquelle commence votre projet.
Quelle architecture pour votre chatbot bus ?
Quatre réponses, un verdict, la règle qui l’emporte. Ou chargez un cas réel depuis le tableau placé en dessous.
1. Votre réseau, c’est plutôt
2. Le besoin dominant des voyageurs
3. Volumétrie de questions par mois
4. Canaux visés
Niveau 2 : brancher le flux temps réel
Le cœur d’un chatbot bus : le prochains passages à l’arrêt demandé, et l’état de la ligne en cas de travaux. Si le réseau publie sur le Point d’Accès National, ce niveau est surtout un travail d’intégration propre : fréquence d’interrogation du flux, repli assumé sur l’horaire théorique, et formule fixe quand le flux ne répond pas. C’est le niveau d’AuxR’M le bus depuis le 28 mai 2026.
Niveau 1 : la FAQ éditoriale, tenue à la main
Tarifs, points de vente, accessibilité, règlement, fonctionne du réseau : tout ce qui change deux fois par an, aux vacances et à la rentrée. Pour un petit réseau à moins de mille questions par mois, ce niveau rend déjà un service mesurable, sans aucun branchement de données. La condition : une personne du réseau relit les réponses à chaque changement de période.
Niveau 3 : l’itinéraire porte à porte
« Comment aller de chez moi à la gare » ne se répond pas avec une FAQ : il faut un moteur qui croise horaires, correspondances et marche à pied. La bonne nouvelle : la plupart des autorités organisatrices en exposent déjà un. Le chatbot devient alors un front conversationnel sur ce calculateur, et c’est exactement ce que fait le connecteur francilien relevé le 5 octobre 2026. Le piège du niveau précédent, constaté dès 2020 : un itinéraire non ajusté aux perturbations en cours décrédibilise tout le reste.
Niveau 4 : titres, abonnements, réservation
Vendre un titre, gérer un abonnement, réserver un transport à la demande : le bot entre dans la commande et dans les données personnelles. Ce niveau suppose la billettique du réseau en API, un compte voyageur, et les règles de droit qui encadrent la vente : notre article consacré au chatbot de billetterie détaille ces règles, qui valent pour un ticket de bus comme pour une place de spectacle.
Réseau scolaire : le calendrier avant la technologie
Sur un réseau scolaire ou périurbain à vraie volumétrie, tout se joue sur quelques semaines : inscriptions de rentrée, affectations, desserte de l’établissement, premiers jours de septembre. L’architecture gagnante croise la FAQ de rentrée, les alertes de ligne (travaux, neige, grève) et WhatsApp, où se trouvent les parents. C’est le choix du réseau d’Auxerre annoncé le 28 mai 2026, qui renvoie aussi vers la réservation du transport à la demande.
La cascade s’applique dans l’ordre : vendre ou réserver d’abord (niveau 4), puis l’itinéraire (niveau 3), puis le temps réel (niveau 2), la FAQ tenant le bas de l’échelle. Le cas scolaire dérogue : quand la rentrée fait la volumétrie, le calendrier choisit l’architecture. Un réseau, une marche : recopiez cette table dans votre cahier des charges.
| Question réelle | Réseau | Volumétrie | Verdict | Charger |
|---|---|---|---|---|
| « Quand passe le prochain bus pour la gare ? » | Urbain | 1 000 à 10 000 | Niveau 2 | |
| « Ma ligne est-elle déviée à cause des travaux ? » | Urbain | Plus de 10 000 | Niveau 2 | |
| « Quel abonnement pour un étudiant ? » | Urbain | 1 000 à 10 000 | Niveau 4 | |
| « Je n’arrive pas à réserver mon transport à la demande » | Interurbain | Moins de 1 000 | Niveau 4 | |
| « Où acheter un aller-retour pour la ligne 40 ? » | Interurbain | 1 000 à 10 000 | Niveau 4 | |
| « La ligne dessert-elle le lycée depuis la rentrée ? » | Scolaire | 1 000 à 10 000 | Réseau scolaire | |
| « Inscription transport scolaire : quels documents ? » | Scolaire | Plus de 10 000 | Réseau scolaire | |
| « Comment aller de chez moi à la zone commerciale ? » | Urbain | Moins de 1 000 | Niveau 3 | |
| « Le réseau est-il accessible en fauteuil roulant ? » | Urbain | Moins de 1 000 | Niveau 1 | |
| « Horaires de la ligne 40 le dimanche ? » | Interurbain | Moins de 1 000 | Niveau 1 |
Pour mémoire, la même échelle en une table, avec ce qui coince le plus souvent à chaque marche :
| Niveau | Ce que le voyageur obtient | Ce qu’il faut brancher | Ce qui coince souvent |
|---|---|---|---|
| 1. FAQ éditoriale | Tarifs, points de vente, règlement, accessibilité | Rien : du contenu rédigé et validé par le réseau | Le contenu vieillit aux vacances : prévoir la relecture |
| 2. Temps réel | Prochains passages à l’arrêt, état de la ligne | Flux GTFS-RT ou SIRI du réseau ou de l’autorité organisatrice | Le repli sur l’horaire théorique doit être dit, jamais caché |
| 3. Itinéraires | Parcours porte à porte avec correspondances | Le calculateur existant du réseau, interrogé par le bot | Un itinéraire ignorant les perturbations en cours dessert mal le voyageur |
| 4. Vente et réservation | Acheter un titre, gérer un abonnement, réserver un transport à la demande | Billettique en API, compte voyageur | Le droit de la vente et les données personnelles, à cadrer dès le cahier des charges |
La méthode en six étapes, du flux au premier passage annoncé
- Relever les questions réelles. Trois mois de sollicitations du réseau : mail, téléphone, réseaux sociaux, guichet. On les conserve avec leurs mots exacts, y compris les fautes de frappe sur les noms d’arrêts : elles serviront de tests de reconnaissance plus tard.
- Vérifier l’existant côté données. Sur le Point d’Accès National, chercher le réseau : horaires théoriques en GTFS ou NeTEx, flux temps réel en GTFS-RT ou SIRI. Cette vérification de dix minutes décide si le projet démarre au niveau 1 ou au niveau 2 de l’échelle.
- Choisir la marche de départ avec le routeur. Réseau, besoin dominant, volumétrie, canaux : le verdict ci-dessus donne l’architecture de départ et son périmètre réel. On n’annonce jamais plus que la marche ne tient, surtout pas « temps réel » sans flux.
- Rédiger les réponses avec les services du réseau. Tarifs par le service commercial, règlement par le service juridique, accessibilité par le service concerné. Le bot est l’assemblage de ces validations, pas leur substitut.
- Brancher, tester un jour de travaux. Le flux temps réel se juge quand il est utile : interrogation à des heures différentes, arrêts sans flux, ligne déviée. Le comportement de repli fait partie des exigences, au même titre que la réponse nominale.
- Mesurer et faire grandir l’échelle. Questions traitées sans reprise humaine, temps de réponse, top des questions non comprises : ces trois chiffres décident du passage à la marche suivante. La reprise humaine se règle avant la mise en ligne, pas après.
Ces six étapes sont la déclinaison bus d’une méthode générale décrite dans notre article sur le chatbot transport, qui traite du sujet sans se limiter au bus : c’est là que se trouvent le panorama des missions, l’arbitrage entre construction en interne et prestation, et le détail des cas d’usage transport par type de réseau.
Web, WhatsApp : le canal suit le voyageur, pas l’inverse
Le choix du canal n’est pas esthétique, il est calendrique. Avant le déplacement, la question naît sur le site du réseau, en consultant les horaires : le widget vit sur la page d’accueil et sur la page horaires. Le jour du déplacement, le voyageur est dehors, sur son téléphone, et n’installera pas une application pour un réseau qu’il prend deux fois par semaine : c’est là que WhatsApp gagne, et c’est le choix explicite du réseau d’Auxerre le 28 mai 2026. Un même scénario vit sur les deux canaux, l’historique suivant la conversation.
L’argument n’est pas nouveau, mais il a changé d’échelle : dès 2017, le chatbot Messenger francilien avait montré qu’on peut toucher le voyageur sans application dédiée, avec les limites d’alors ; en 2026, le même raisonnement se déploie sur WhatsApp pour un réseau urbain moyen, sur le site pour un réseau régional de cars, et jusque dans ChatGPT pour le multi-réseaux francilien. Nos pages consacrées aux canaux de déploiement détaillent ces intégrations, et le témoignage Hello Scoot montre une autre mobilité, partagée celle-là, qui a automatisé ses questions récurrentes sur les réseaux sociaux avec la même plateforme.
IA et données personnelles : le minimum, sans texte fantôme
Trois obligations encadrent un chatbot bus, et aucune n’est décorative. La première vient du règlement européen sur l’intelligence artificielle, en application depuis le 2 août 2026 : son article 50, paragraphe 1, impose que les systèmes d’IA destinés à interagir directement avec le public soient conçus pour que « les personnes physiques concernées soient informées qu’elles interagissent avec un système d’IA », sauf si cela ressort clairement du contexte (texte du règlement (UE) 2024/1689 sur EUR-Lex). Pour un chatbot bus, l’application est simple : le premier message annonce l’agent automatique, puis le bot fait son travail.
La deuxième est le RGPD, dès que le bot touche à des données personnelles : une réclamation d’objet perdu, un dossier scolaire, un compte voyageur au niveau 4 de l’échelle. Finalité affichée, durée de conservation, base légale : rien de spécifique au bus, mais cela s’écrit dans le cahier des charges. La troisième tient dans un renvoi : vendre des titres dans une conversation ajoute les règles propres à la billetterie (rétractation, revente, preuve d’achat), que notre article sur le chatbot de billetterie documente règle par règle avec les textes consolidés. Enfin, l’obligation d’open data vue plus haut n’est pas une contrainte pour le chatbot, c’est son aliment : c’est elle qui met les flux à portée de main.
Combien coûte un chatbot bus : trois lignes, pas trente
Le décompte se fait toujours sur les trois mêmes lignes : la licence de la plateforme, les crédits consommés par l’IA, et la construction. La grille publique de Botnation, relevée le 5 octobre 2026, fixe les deux premières :
| Ligne de coût | Relevé du 5 octobre 2026 | Ce qui la fait varier |
|---|---|---|
| Licence plateforme | Gratuit 0 €, Basic 39 € par mois, Pro 59 € par mois, Entreprise sur mesure (hors taxes) | Le nombre d’utilisateurs à servir et les fonctions avancées ; l’offre Entreprise inclut littéralement des « Services création de chatbot » |
| Crédits IA | Packs de 1 000 crédits à 25 €, 5 000 à 100 €, 15 000 à 250 €, 60 000 à 900 € ; utilisateur hors forfait 0,05 € par mois | Le volume de requêtes IA (les réponses sur données branchées du réseau, type horaires théoriques, ne consomment pas d’IA générative) |
| Construction | En autonomie sur la plateforme : le temps de l’équipe ; confiée à l’équipe Botnation : sur devis | Le périmètre : nombre de contenus à valider, branchements de flux, canaux, reprise humaine à organiser |
Pour la construction déléguée, la FAQ publique de la grille donne elle-même l’ordre de grandeur de marché : hors solution d’abonnement, il en coûte « en général entre 5000€ et 30000€, voir bien plus » selon les fonctionnalités nécessaires. Cette fourchette est celle des prestataires du marché, pas un tarif Botnation : le devis se construit sur le périmètre réel, et rien d’autre. C’est aussi là que le positionnement double de Botnation prend son sens : l’équipe qui construit est celle qui édite la plateforme, donc sans intermédiaire à reprendre, et le réseau garde la main sur son compte, ses scénarios et sa base dans l’éditeur no-code après la livraison. Une agence tierce reste légitime quand un intégrateur connaît déjà le système d’information du réseau : ce qui compte est que le choix se fasse en connaissance de cause.
Questions fréquentes
Qu’est-ce qu’un chatbot bus, exactement ?
Un assistant conversationnel déployé par un réseau de bus ou de cars, joignable sur le site du réseau, sur WhatsApp ou les messageries, qui répond aux questions des voyageurs : prochains passages, perturbations, itinéraires, titres et abonnements, fonctionnement du réseau. Sa spécificité, par rapport à un bot à scénario figé, est de pouvoir se brancher sur les données du réseau, théoriques comme temps réel.
Un petit réseau a-t-il les moyens de se lancer ?
Oui, et c’est même là que le retour est le plus visible : quelques centaines de questions par mois suffisent à mesurer le service rendu. Le niveau 1 de l’échelle (la FAQ éditoriale) ne demande aucun branchement de données, et la licence gratuite de la plateforme permet de construire avant de payer. La vraie dépense de départ est le temps de rédaction des réponses avec les services du réseau.
Faut-il obligatoirement le temps réel pour être utile ?
Non, mais il ne faut pas le prétendre sans l’avoir. Un réseau sans flux temps réel rend déjà service avec les horaires théoriques, à condition de le dire : « horaires théoriques, relevés du planning en vigueur ». Le pire est l’ambiguïté : une réponse présentée comme temps réel qui vient d’un fichier théorique décrédibilise le service entier. Avant de promettre, vérifiez ce que votre réseau publie sur le Point d’Accès National.
Combien de temps faut-il pour déployer un chatbot bus ?
Le premier parcours utile, FAQ horaires et transfert vers un humain, se monte en une demi-journée sur une plateforme no-code. La version qui tient la route, avec flux temps réel, contenus validés par les services du réseau et reprise humaine organisée, se compte en semaines. Le calendrier dépend presque entièrement de la disponibilité des données et de la validation des réponses, pas de la technique.
Le chatbot remplace-t-il l’application du réseau ?
Il ne la remplace pas, il la précède. Beaucoup de voyageurs ne téléchargent pas une application pour un usage occasionnel : le chatbot les sert là où ils sont déjà, sur le web et dans WhatsApp. Pour les usages lourds (billettique nominative, notifications poussées), l’application garde ses avantages ; pour la question du moment, la conversation gagne. Les deux se rejoignent au niveau 4 de l’échelle, derrière un compte voyageur unique.
Qui répond quand le chatbot ne sait pas ?
La reprise humaine se décide avant la mise en ligne : transfert vers un agent avec l’historique complet, ou ouverture d’un dossier transmis au service concerné. Trois choses se définissent par écrit : les horaires de couverture, le délai de réponse annoncé au voyageur, et qui vérifie que le dossier est complet. Un chatbot bus qui échoue silencieusement est pire qu’absent : il décourage la seconde question.
Votre réseau a déjà ses questions : commencez par les vingt premières
Reprenez les demandes des trois derniers mois, classez-les sur l’échelle des quatre architectures, et construisez le premier scénario en autonomie sur la plateforme ; ou confiez la création à l’équipe qui l’édite, dans le cadre de l’offre Entreprise, sur devis.
Demander un devis pour la création de votre chatbot ou échanger avec nos experts en création de chatbot.
Sources. Code des transports, article L1115-1 (créé par l’article 25 de la loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, modifié par la loi n° 2025-391 du 30 avril 2025), version en vigueur relevée le 5 octobre 2026 sur le texte consolidé ; transport.data.gouv.fr, page d’accueil et état de l’ouverture des données, relevés du 5 octobre 2026 ; règlement (UE) 2024/1689 du 13 juin 2024, article 50 paragraphe 1, texte français du Journal officiel de l’Union européenne sur EUR-Lex, en application depuis le 2 août 2026 ; RATP et Minsday, chatbot Messenger lancé en septembre 2017, testé par le cabinet mc2i en mai 2020 (page relevée le 5 octobre 2026) ; Bonjour RATP, page du connecteur ChatGPT relevée le 5 octobre 2026 ; Nomad (réseau NOMAD Car, Normandie), annonce du chatbot NomadCarBot et du module « Prochains passages », 3 novembre 2025 ; AuxR’M le bus (Communauté d’Agglomération de l’Auxerrois), annonce du chatbot WhatsApp, 28 mai 2026 ; grille tarifaire et FAQ de botnation.ai, relevées le 5 octobre 2026.
