Prototype contrôlable · données fictives

Tester le parcours avant de promettre le produit.

DentiBot démontre un cockpit, un agenda local et des garde-fous d'orientation. La production reste verrouillée jusqu'aux validations techniques, HDS, RGPD et cliniques.

Voir mon dashboard test Voir le dashboard en direct

Démo lecture seule

0 donnée patient réelle

Preuves avant activation

Fail-closed en production

cabinet-des-lilas.dentibot.fr/app

Tableau de bord DentiBot — cockpit du cabinet

Le problème à valider sur le terrain

Le téléphone, l'agenda et les relances interrompent le travail du cabinet.

✕ Les appels arrivent aussi pendant les soins et hors accueil.
✕ Une réponse automatique incorrecte peut créer un risque clinique.
✕ Une intégration agenda partielle peut dupliquer ou perdre un rendez-vous.
✕ Les données de santé interdisent une mise en production improvisée.

2 états

Une démo qui fonctionne n'est pas encore un produit santé exploitable.

Démodonnées fictives

Piloterecette cabinet

Produitpreuves complètes

Fonctionnalités

Ce que le prototype sait réellement démontrer.

Chaque capacité est séparée de ce qui reste à contractualiser et à recetter.

Conversation simulée

Le prototype traite des scénarios téléphoniques de test. Aucun numéro de cabinet réel n'est raccordé à cette démo.

Moteur disponible en continu

Le logiciel peut fonctionner en continu ; la téléphonie réelle reste à contractualiser et à recetter.

Agenda local de démonstration

Création, modification et annulation sont testées sur l'agenda local. Aucun connecteur éditeur n'est revendiqué.

Garde-fous d'orientation

Des règles déterministes détectent des marqueurs urgents. Elles ne remplacent jamais un diagnostic ou une validation clinique.

Rappels simulés

Les parcours de rappel, liste d'attente et relance existent en test, sans promettre un résultat commercial.

Démo

Voyez le tableau de bord en action.

Explorez le cockpit avec des patients fictifs : agenda, appels simulés, alertes et relances de démonstration.

cabinet-des-lilas.dentibot.fr/app

Voir mon dashboard test

Comment ça marche

Trois étapes, sans confondre prototype et production.

Tester la démo

Le tableau de bord public utilise exclusivement des données fictives et reste en lecture seule.

Recetter un pilote

Agenda, téléphonie, transferts, stockage et scripts cliniques sont testés sur le cabinet pilote.

Ouvrir seulement sur preuves

Le mode produit reste bloqué tant que toutes les validations techniques, HDS, RGPD et cliniques manquent.

Phases de déploiement

Pas de tarif public avant de connaître les coûts réels.

Téléphonie, hébergement santé, connecteur agenda et accompagnement doivent être chiffrés sur un pilote. Les montants et garanties viendront ensuite dans une offre contractuelle.

Disponible

Démo

0 donnée réelle

Surface publique actuelle, isolée du cabinet.

Données entièrement fictives
Lecture seule
Agenda local
Blocages visibles
Aucun connecteur revendiqué

Explorer la démo

À préparer

Pilote

Sur cadrage

Recette limitée, uniquement après choix des prestataires.

Périmètre cabinet écrit
Tests agenda bidirectionnels
Téléphonie et transfert humain
Revue clinique
Mesures sans promesse de gain

Voir le cockpit

Verrouillé

Produit

Non ouvert

Activation conditionnée à toutes les preuves de disponibilité.

Hébergement santé validé
Revue RGPD signée
Stockage durable privé
Providers recettés
Offre commerciale approuvée

Consulter la démo

Démo explicitement séparée

Capacités recettées par contrat

Blocages visibles et fail-closed

Aucune donnée réelle avant validation

Le tableau de bord ROI est une simulation : ses hypothèses ne constituent ni une prévision ni une garantie. Explorer les données fictives →

Confiance & conformité

Aucune donnée patient réelle sur cette instance.

Les données de santé exigent un hébergement et des contrats adaptés. La démo ne constitue pas une preuve de conformité.

Données fictives

Lecture seule

Backend sur boucle locale

Production verrouillée

Transparence : nous ne revendiquons ni conformité RGPD complète, ni certification HDS, ni aptitude clinique. Ces éléments doivent être documentés avant tout pilote avec des données réelles.

Connecteurs envisagés, pas revendiqués

Chaque éditeur exige un accès autorisé et une recette bidirectionnelle sur le cabinet concerné.

Doctolib · à qualifierJulie · à qualifierLOGOSw · à qualifierAgenda local · démo Téléphonie · à recetterTransfert humain · à recetter

Garde-fou testé, validation clinique manquante. Le prototype contient des règles d'escalade et interdit le diagnostic. Le transfert réel et les scripts doivent être recettés puis signés avant production.

État vérifiable

Ce qui fonctionne, ce qui manque, qui doit valider.

Aucune comparaison concurrentielle ni promesse tarifaire non sourcée sur la surface publique.

Capacité	État actuel	Preuve exigée	Décision
Dashboard	Démo disponible	Tests + données fictives	Automatique
Agenda local	Testé	Tests de concurrence et intégrité	Automatique
Agenda éditeur	Non vérifié	Contrat frais lecture + écritures	Cabinet + éditeur
Téléphonie réelle	Non vérifiée	Entrant, sortant, statut, transfert	Provider + cabinet
Orientation urgente	Garde-fous testés	Revue et signature clinique	Professionnel de santé
HDS / RGPD	Non approuvé	Contrats et revue documentée	Responsables juridiques
Offre commerciale	Non approuvée	Coûts, prix, SLA et garanties écrits	Direction

Le service de disponibilité machine expose cette même séparation entre démo prête et produit bloqué.

Contrat de confiance

Une capacité n'existe commercialement que si sa preuve existe.

La démo sert à vérifier l'interface. Le pilote sert à mesurer le terrain. Seule une validation complète autorisera les données réelles.

Démo sans données réellesLa surface publique est explicitement isolée et en lecture seule.

Production verrouilléeLe service refuse les données patient tant que les preuves obligatoires manquent.

Connecteurs vérifiés par contratUne clé API ou un logo ne suffit jamais à déclarer une intégration.

Validation humaine obligatoireHDS, RGPD, scripts cliniques et information IA ne sont pas auto-certifiés.

État contrôlableUn endpoint de disponibilité expose les capacités et les blocages sans masquer les écarts.

Aucune garantie inventéeLes tarifs, économies et résultats seront publiés seulement après validation contractuelle.

FAQ

Les questions qu'on nous pose.

Réponses honnêtes, sans hype.

Est-ce déjà connecté à Doctolib, Julie ou LOGOSw ?

Non par défaut. Le prototype utilise un agenda local. Un éditeur n'est affiché comme connecté qu'après accord d'accès et recette fraîche en lecture, création, déplacement et annulation.

Puis-je y mettre de vrais patients ?

Non. Cette instance est une démonstration avec données fictives. Le mode produit reste techniquement bloqué tant que l'hébergement, le stockage, les prestataires et les revues humaines ne sont pas validés.

Un robot qui trie les urgences, c'est risqué pour ma responsabilité.

Les scénarios urgents sont couverts par des garde-fous déterministes et le bot ne doit pas diagnostiquer. Cela ne suffit pas pour la production : les scripts et le transfert humain doivent encore être signés et recettés avec un professionnel.

C'est conforme RGPD ? Et HDS ?

Pas encore pour des données réelles. Nous ne revendiquons ni conformité RGPD complète ni certification HDS sur cette instance. Ces validations, leurs contrats et leurs preuves sont des prérequis techniques au mode produit.

Quels gains et quel prix pouvez-vous garantir ?

Aucun à ce stade. Les résultats dépendent du volume, du cabinet, du prestataire téléphonique et du connecteur agenda. Une offre contractuelle devra séparer les coûts mesurés, les hypothèses et les résultats constatés.