Créer une plateforme type Doctolib avec Wix Studio : ce qui est vraiment possible

« Est-ce qu'on peut faire un Doctolib avec Wix ? » On nous pose la question presque chaque mois, et la réponse honnête tient en deux temps.

Oui, Wix Studio permet de construire une plateforme multi-professionnels : un annuaire, des fiches, des comptes clients et praticiens, des agendas, de la réservation et du paiement. Non, ce ne sera pas Doctolib, qui est d'abord un logiciel médical avec dossier patient, ordonnances et téléconsultation.

Ce qui rend le projet possible, ce n'est pas un outil miracle : c'est la combinaison de plusieurs briques Wix, dont certaines existent déjà et n'ont pas à être redéveloppées. Voici lesquelles, dans quel ordre, et où sont les vraies limites.

L'essentiel en six points

• Wix Studio construit l'interface, Velo construit la logique métier. Séparer les deux est la clé du sujet.
• La partie annuaire, comptes, agendas et réservation est à la portée de Wix. Le dossier médical ne l'est pas.
• Wix Bookings n'est pas un obstacle, c'est un moteur. On peut s'en servir derrière une interface entièrement sur mesure.
• Cent praticiens n'est pas un problème de volume. Ce qui compte, c'est le trafic, la simultanéité et les règles métier.
• La sécurité ne se joue pas dans l'interface : cacher un bouton ne protège rien.
• Un projet de santé demande une étude du périmètre de données avant toute promesse.

La réponse, tout de suite

Ce que vous voulez construire n'est probablement pas Doctolib, mais une place de marché de services : d'un côté des clients qui cherchent, de l'autre des professionnels qui proposent, et au milieu une plateforme qui gère la recherche, les profils, la réservation, le paiement et les règles.

Cette mécanique-là, Wix Studio la couvre, à condition de combiner les bons éléments plutôt que de tout recoder. C'est exactement la même architecture pour une plateforme de coachs, de consultants, de thérapeutes, de formateurs ou de prestataires.

La vraie question n'est donc pas « Wix en est-il capable », mais « qu'est-ce qui reste natif, qu'est-ce qui passe par une interface de programmation, et qu'est-ce qui se développe ».

Ce qu'on appelle « plateforme type Doctolib »

Le terme recouvre en général ceci, et Wix le gère raisonnablement :

• un annuaire de professionnels, avec recherche et filtres ;
• une fiche détaillée par professionnel ;
• des comptes clients et des comptes professionnels ;
• des disponibilités, un calendrier, de la réservation, de l'annulation, du déplacement de rendez-vous ;
• des prestations, des tarifs, du paiement ;
• des notifications ;
• un tableau de bord pour le client et un autre pour le professionnel.

Le vrai Doctolib, lui, comporte aussi le dossier patient, les informations médicales, les ordonnances, les documents de santé, la téléconsultation, la messagerie médicale et toute une infrastructure réglementaire. Ce n'est pas le même produit, et confondre les deux fait démarrer les projets sur un malentendu coûteux.

Un exemple concret

Prenons une entreprise qui veut réunir cent praticiens sur une même plateforme.

Un visiteur arrive. Il cherche un professionnel, filtre par spécialité et par ville, ouvre une fiche, consulte les prestations et les disponibilités, choisit un créneau, crée son compte, réserve, reçoit sa confirmation et retrouve son rendez-vous dans son espace.

Le praticien, lui, se connecte à son propre espace. Il modifie son profil, gère ses prestations et ses tarifs, déclare ses disponibilités, consulte son planning, et déplace ou annule un rendez-vous selon les règles prévues.

Point important pour l'expérience : le professionnel n'a jamais à entrer dans le tableau de bord de Wix. Il utilise votre plateforme, à vos couleurs. C'est ce qui sépare un vrai produit d'un site avec un module de réservation.

Les briques, et à quoi sert chacune

Une image utile pour s'y retrouver : Wix Bookings est le moteur, le tableau de bord sur mesure est le poste de pilotage, le Custom Element est l'écran, le CMS contient les données, Wix Members porte l'identité, et Velo est ce qui relie l'ensemble.

Comment on le construit, concrètement

Étape 1, les données métier dans le CMS

Une collection Praticiens : nom, photo, description, spécialité, ville, adresse, modalité, statut, plus les identifiants qui le relient à son compte et à son agenda. Une collection Prestations : titre, description, praticien, durée, prix, modalité. Puis, selon le projet, les spécialités, les avis, les favoris, les demandes d'inscription, les diplômes.

Tout n'a pas à vivre dans le CMS : les rendez-vous peuvent rester gérés par Wix Bookings pendant que le CMS conserve les données métier autour.

Étape 2, une seule page pour cent fiches

Une page modèle suffit à générer automatiquement la fiche de chaque praticien, à sa propre adresse. Cent professionnels ne demandent donc pas cent pages à créer à la main, et chacun dispose d'une adresse propre, avec un vrai potentiel de référencement local.

Étape 3, les comptes et les rôles

Wix Members sert de couche d'identité. Par-dessus, on construit les espaces : côté client, ses rendez-vous, ses informations, ses favoris, son historique ; côté praticien, son profil, ses prestations, ses tarifs, ses disponibilités, son agenda.

Les rôles se distinguent : client, praticien, administrateur, modérateur. Un praticien modifie son profil et pas celui du voisin, un client voit ses réservations et pas celles des autres, un administrateur a la vue d'ensemble.

Étape 4, la sécurité côté serveur

C'est le point que beaucoup ratent. Cacher un bouton ne sécurise rien. Masquer « Modifier » quand l'utilisateur n'est pas le propriétaire améliore l'expérience, mais n'empêche personne de déclencher l'action autrement.

La vérification doit se faire côté serveur : la personne connectée est-elle bien propriétaire de cette donnée, avant d'autoriser quoi que ce soit. L'interface gère le confort, le serveur gère les droits.

Étape 5, le parcours d'inscription des professionnels

Créer un compte, compléter son profil, ajouter ses prestations et ses justificatifs, puis passer en attente de validation, et enfin être publié après contrôle. C'est typiquement ce qui distingue une plateforme d'un simple site, et ça se construit entièrement.

Des statuts clairs aident : brouillon, en attente, validé, refusé, suspendu pour un praticien ; en attente, confirmé, annulé, terminé, absence pour un rendez-vous.

Wix Bookings : un moteur, pas un obstacle

On lit souvent qu'il faudrait « refaire l'agenda parce que Bookings est trop limité ». C'est faux, et c'est un mauvais réflexe qui coûte cher.

Wix Bookings gère déjà les services, les professionnels, les horaires individuels, les disponibilités, les réservations, les ressources, les règles, le déplacement et l'annulation. Il traite aussi la question de deux personnes qui réservent le même créneau au même instant, ce qui est un problème nettement moins simple qu'il n'y paraît.

Et surtout, il peut servir de moteur derrière une interface entièrement différente. Le visiteur voit votre interface ; derrière, c'est l'API de Bookings qui calcule les disponibilités et enregistre les réservations. Vos utilisateurs ne verront jamais l'apparence native de Wix Bookings.

Pourquoi c'est une bonne affaire

Calculer un créneau libre, ce n'est pas « le praticien travaille lundi à 14 heures ». Il faut croiser les horaires, les rendez-vous existants, la durée de la prestation, les indisponibilités, les pauses, les ressources, les règles de réservation, les exceptions et parfois le lieu. Réécrire cette logique représente des semaines de développement, et autant de bugs à découvrir en production.

Quand Wix Bookings suffit tel quel

Un indépendant, une petite équipe, des services simples, des horaires standards, une réservation classique et l'envie d'être en ligne vite : dans ce cas, n'inventez rien. Bookings fait le travail, et le budget part ailleurs.

Quand le développement sur mesure devient intéressant

Quand la plateforme accueille beaucoup de professionnels, plusieurs rôles, un parcours de validation, des tableaux de bord particuliers, une recherche avancée, des règles métier propres, ou une expérience entièrement à vos couleurs.

Les phrases qui annoncent ce basculement, entendues en rendez-vous :

• chaque professionnel doit gérer ses propres tarifs ;
• chacun ne doit voir que son agenda ;
• je veux un espace client personnalisé ;
• je veux une recherche à plusieurs filtres ;
• je veux connecter la plateforme à mon logiciel métier ;
• je veux valider chaque professionnel avant publication ;
• je veux plusieurs types de comptes, avec des affichages différents.

Un moteur de réservation entièrement sur mesure ne se justifie, lui, que si votre logique est réellement atypique : réservation combinant plusieurs professionnels, ressources complexes, priorités, mise en relation automatique. Il coûte plus cher à construire, et surtout à maintenir.

L'interface complexe : le Custom Element

Un Custom Element permet d'intégrer un composant développé en HTML, CSS et JavaScript. Le cas idéal, c'est l'agenda : vue semaine, vue jour, vue mois, couleurs, glisser-déposer, détails au clic, création d'indisponibilité.

Deux précautions. Il n'est pas obligatoire : beaucoup de projets s'en passent très bien. Et il ne doit pas contenir le contenu à référencer. Le nom, la spécialité, la ville, la description et les prestations restent dans la page et le CMS, donc lisibles par Google. Le Custom Element gère l'interactif, pas le contenu.

Les automatisations et les connexions

Les enchaînements utiles s'installent sans développement lourd : un nouveau praticien s'inscrit et l'administrateur est prévenu, un profil est validé et le praticien reçoit son accès, une réservation est créée et les deux parties reçoivent leur confirmation, un rappel part la veille, une demande d'avis part après le rendez-vous.

Et contrairement à une idée tenace, Wix ne parle pas qu'aux applications Wix. Le back-end peut appeler des interfaces extérieures : CRM, envoi de SMS, visioconférence, facturation, cartographie, votre logiciel métier.

Cent praticiens, est-ce trop ?

Non, et le raccourci « cent praticiens, Wix sera trop petit » ne veut rien dire. Cent profils, c'est très peu de données.

Les vrais sujets sont ailleurs : le trafic, le nombre de rendez-vous, la simultanéité, le volume d'appels aux interfaces, les automatisations, les permissions et l'historique accumulé. Ce sont ces chiffres-là qu'on regarde, pas le nombre de fiches.

Une erreur à éviter, en revanche : créer dans le CMS un enregistrement par créneau, pour tous les praticiens et tous les jours à venir. On arrive vite à des millions de lignes inutiles. Le bon modèle garde les horaires, les exceptions et les réservations, et calcule les créneaux. Ou laisse Bookings les calculer.

Combien ça coûte, et combien de temps ?

Nous ne chiffrons pas ce que nous n'avons pas regardé. Sur ce type de projet, la faisabilité est étudiée avant tout engagement : on liste les fonctions, on sépare ce qui est natif de ce qui demande du développement, et le budget en découle.

Ce qui fait vraiment varier le prix, ce n'est pas le nombre de pages, c'est le nombre de règles métier et de rôles. Un annuaire avec réservation standard n'a rien à voir avec une plateforme à validation, matching et tableaux de bord.

Le conseil qui fait gagner le plus d'argent : commencez par une première version utile. Annuaire, profils, réservation, espaces membres. Puis ajoutez les avis, les favoris, les paiements, la messagerie, les statistiques, les abonnements. Vouloir recréer Doctolib d'emblée est la meilleure façon de ne jamais rien mettre en ligne.

Quelles sont les limites de Wix ?

Wix est une solution possible, pas la réponse universelle. Les limites se situent autour des besoins extrêmement spécifiques, d'une complexité importante côté serveur, de certaines architectures distribuées, d'un besoin de contrôle total sur l'infrastructure, ou d'une pile technique imposée.

Dans ces cas-là, nous vous le dirons. Construire sur un outil qui ne convient pas coûte toujours plus cher que d'en changer au départ.

Le cas particulier de la santé

C'est le point sur lequel il faut être précis, parce que les raccourcis y sont dangereux dans les deux sens.

Cas courant. Une plateforme de réservation pour des coachs, des consultants, des professionnels du bien-être, des formateurs, des prestataires. Les données sont administratives : nom, adresse électronique, rendez-vous, prestation, prix, horaire. L'architecture est classique, le RGPD s'applique comme pour tout site.

Cas médical. Dès qu'il est question de diagnostic, de pathologie, d'ordonnance, de résultat d'examen, de dossier ou de compte rendu, on entre dans les données de santé, avec des obligations d'hébergement et de sécurité propres au secteur.

Deux choses que nous n'écrirons jamais. Que Wix serait certifié pour héberger des données de santé en France : Wix dispose de plusieurs certifications et dispositifs de sécurité, ce qui ne signifie pas qu'une architecture Wix réponde d'office aux exigences françaises en la matière. Et l'inverse, qu'un médecin sur la plateforme rendrait tout impossible : c'est la nature des données traitées qui décide, pas la profession de l'utilisateur.

La bonne démarche est donc une étude du périmètre de données avant toute promesse. C'est aussi ce qui distingue un prestataire sérieux d'un vendeur.

Faut-il le faire soi-même ou passer par un professionnel ?

Un annuaire simple avec Wix Bookings est à la portée de quelqu'un de patient et méthodique. Vous y arriverez.

La bascule se fait sur trois points : les rôles et ce que chacun a le droit de voir, la sécurité côté serveur, et le choix entre natif, interface de programmation et développement. C'est précisément là qu'un projet mal parti devient impossible à rattraper, parce que les mauvaises décisions se prennent au début et se paient à la fin.

Notre travail sur ce type de projet n'est pas de tout coder, c'est de décider ce qui doit rester natif, ce qui passe par une API, et ce qui mérite d'être développé. Le reste en découle.

Étudier la faisabilité de votre plateforme

En résumé

• Une plateforme multi-professionnels, oui. Un clone de Doctolib, non, et la différence est le dossier médical.
• La force de Wix ici, c'est l'assemblage : Studio, CMS, Members, Bookings, Velo, back-end et automatisations.
• Wix Bookings sert de moteur derrière votre propre interface, et vous évite de réécrire le calcul des créneaux.
• La sécurité se joue côté serveur, jamais dans l'affichage.
• Commencez par une première version utile, puis enrichissez.
• Un projet de santé impose d'étudier les données avant de promettre quoi que ce soit.

Questions fréquentes

Peut-on créer une plateforme comme Doctolib avec Wix ?

On peut construire une plateforme qui reprend ses mécaniques d'annuaire, de profils, d'agendas et de réservation. On ne reconstruit pas son volet médical : dossier patient, ordonnances, téléconsultation, messagerie de santé.

Peut-on créer un espace membre vraiment personnalisé ?

Oui. Wix Members fournit l'identité et la connexion, et l'espace lui-même se construit ensuite : vous décidez de ce que chaque type d'utilisateur voit et peut faire. Le professionnel n'a jamais besoin d'ouvrir le tableau de bord de Wix.

Peut-on utiliser Wix Bookings uniquement comme moteur ?

Oui, c'est même souvent la meilleure décision du projet. L'interface est entièrement à vous, et l'API de Bookings s'occupe des disponibilités, des règles et des réservations.

Peut-on connecter Wix à notre logiciel métier ?

Oui. Le back-end peut appeler des interfaces extérieures : CRM, facturation, SMS, visioconférence, ERP. La question n'est pas la faisabilité, mais ce que l'autre outil expose de son côté.

Peut-on gérer cent praticiens ?

Oui. Cent profils représentent très peu de données. Ce sont le trafic, le nombre de rendez-vous et la simultanéité qui demandent à être regardés, pas le nombre de fiches.

Et pour un projet de santé, est-ce que c'est possible ?

Ça dépend entièrement des données traitées. Une prise de rendez-vous administrative n'a rien à voir avec un dossier médical. C'est la première chose qu'on étudie, avant tout engagement.

Peut-on faire développer ce genre de plateforme par une agence Wix ?

Oui, et c'est notre métier. Nous construisons des espaces membres, des tableaux de bord, des agendas, des connexions à des interfaces extérieures et des logiques métier avec Wix Studio et Velo. C'est le cadre de notre offre de développement Wix sur mesure, dont la faisabilité est étudiée sans engagement. Le sujet est également abordé sous un autre angle dans notre article sur ce que Velo permet vraiment d'automatiser.

Le mot de la fin

La bonne réponse n'est ni « Wix fait tout » ni « il faut un développement classique ». Elle est plus ennuyeuse et plus utile : le travail consiste à trancher, fonction par fonction, entre ce qui existe déjà, ce qui se pilote par programmation et ce qui se développe.

C'est ce tri qui fait la différence entre un projet livré en quelques semaines et un projet qui s'enlise pendant un an à réécrire ce que la plateforme savait déjà faire.

Vous avez une plateforme en tête ? Décrivez-nous simplement qui l'utilise et ce que chacun doit pouvoir y faire. On vous dira ce qui est natif, ce qui demande du développement, et si Wix est le bon choix pour vous. Il nous arrive de dire que non.