Solutions · Cliniques dentaires

La liste des services avec marquage de couverture par l’assurance obligatoire, modifiable par la réception — pas un PDF avec des prix envoyé par e-mail.

Un site de clinique dentaire se juge à une seule chose : si la personne trouve le service dont elle a besoin, avec son prix et son unité — par dent, par mâchoire, par séance — et si elle sait s’il est pris ou non dans l’assurance. Le reste est du décor. Nous construisons la structure qui tient cela et le panneau depuis lequel le personnel la modifie seul.

Discuter de votre scénario

Déjà construitLe travail peut être vérifié de l’extérieur dès maintenant : les données publiques d’un centre dentaire de district que nous administrons sont servies sous forme de fichier structuré — 89 services, chacun avec catégorie, sous-catégorie, dénomination, prix, unité de mesure et un indicateur d’éligibilité à l’assurance obligatoire, dont 27 marqués comme éligibles ; 7 catégories et 10 sous-catégories, vérifiées par nous le 06.09.2026. La deuxième partie de la preuve est la sécurisation, avec diff dans l’historique : lors de la prise en main, le mot de passe d’administrateur était comparé dans le navigateur et arrivait dans le paquet JavaScript public, et les écritures sur l’interface de programmation pouvaient être effectuées par n’importe qui sur internet. La précision correcte, pour ne pas nous attribuer plus que ce qui est à nous : la première version du site n’est pas à nous. La contribution qui peut être montrée avec diff est la prise en main, la sécurisation, les types, l’intégration continue et l’hygiène des dépendances.

Une clinique dentaire ne vend pas des « services ». Elle vend une très longue liste de positions tarifaires avec des unités qui ne ressemblent à rien d’autre dans un autre domaine : par dent, par mâchoire, par extraction, par cas traité, par séance, par visite, par intervention. La personne qui cherche sur internet ne cherche pas la clinique, mais sa position : combien coûte une extraction, est-ce payé par dent ou par visite, est-ce couvert par l’assurance. Un site qui répond à cela est utile ; un site qui a une page « Tarifs » avec un PDF en pièce jointe ne l’est pas.

La deuxième chose qu’exige la réalité d’une clinique, c’est que la liste soit modifiable sans programmeur. Les tarifs changent, les médecins changent, le programme des urgences est annoncé autrement en hiver. Si chaque modification passe par un développeur, la liste reste ancienne et, en quelques mois, les patients viennent avec le prix de l’année dernière. La structure que nous construisons garde les données publiques — services et équipe — dans des fichiers structurés lus à la fois par l’interface de programmation et directement par la partie visible du site, et le personnel les modifie depuis un panneau.

La troisième chose, que personne ne demande dans le brief et qui compte le plus, c’est qui peut écrire dans cette liste. Lors de la reprise du projet dont nous parlons ici, n’importe qui sur internet pouvait envoyer une écriture vers l’interface de programmation, et le mot de passe du panneau arrivait dans le paquet JavaScript servi au navigateur — parce que sa vérification se faisait dans le navigateur. Nous avons déplacé la vérification sur le serveur : le mot de passe ne quitte plus le serveur, un jeton signé valable douze heures est renvoyé, avec une limite de huit essais par quinze minutes par adresse IP et des comparaisons en temps constant ; l’interface n’écoute que sur l’adresse locale, donc le serveur web est la seule voie publique.

Le marquage de couverture par l’assurance obligatoire mérite une phrase séparée, car c’est le champ à la plus grande valeur pour le patient et au plus grand risque pour la clinique : c’est une affirmation avec des conséquences. C’est pourquoi il vit comme donnée modifiée par l’institution, et non comme texte rédigé par nous dans une page ; nous construisons le champ, l’affichage et la possibilité de le corriger en une minute.

Ce que cela comprend

Ce qui change concrètement dans les cliniques dentaires

Chaque service est une position avec son unité, et non une ligne dans un tableau de prix

La structure de données de chaque service comporte une catégorie, une sous-catégorie, une dénomination, un prix, une unité de mesure et un indicateur d’éligibilité à l’assurance obligatoire. Les unités sont celles réelles du domaine — dent, mâchoire, extraction, cas traité, séance, visite, consultation, anesthésie, procédure, examen, intervention — parce qu’un prix sans unité produit exactement la conversation que la réception veut éviter.

La taxonomie sur deux niveaux, pour que la longue liste reste parcourable

Catégorie et sous-catégorie, pas une liste plate. Dans l’étude dont nous parlons : 7 catégories et 10 sous-catégories pour plus de 89 services. L’ordre de grandeur compte — en dessous d’une centaine de positions, une taxonomie à deux niveaux suffit ; au-delà de quelques centaines, la structure devient une autre discussion, et nous le disons avant, pas après.

Le marquage de couverture par assurance, comme donnée de l’institution

L’indicateur d’éligibilité figure sur chaque service, dans les données publiques, et il est modifiable par la clinique. Dans l’étude citée, 27 des 89 services sont marqués comme éligibles. Nous n’écrivons pas nous-mêmes ce qui entre dans l’assurance et nous ne le déduisons pas : c’est une affirmation de l’institution, avec des conséquences pour le patient, et elle doit pouvoir être corrigée par elle à tout moment.

Écrans séparés pour les urgences, l’orthodontie, les implants, la pédodontie

Pas une seule page « Services ». Le site comporte 22 écrans, des services et tarifs jusqu’aux urgences, à l’orthodontie, aux implants, à la pédodontie, à la transparence et au feedback. La raison est pratique : celui qui cherche « urgence dentaire » un dimanche soir ne veut pas une page générale, et une page de section a des informations à donner sur l’horaire et sur ce qu’on y fait.

Le personnel modifie, le développeur n’est pas dans la boucle

Les services et l’équipe se modifient depuis un panneau, et les écritures exigent un jeton valide ; les lectures restent publiques, pour que le site fonctionne sans authentification. La conséquence pour la clinique : une modification de tarif entre en vigueur le même jour, et non à la prochaine itération de développement.

Le mot de passe ne quitte pas le serveur, et les tentatives sont limitées

L’authentification se fait sur le serveur et renvoie un jeton signé en HMAC-SHA256, valable 12 heures, avec au maximum 8 tentatives par 15 minutes et par adresse IP, et des comparaisons en temps constant. Le secret de signature est généré automatiquement, dans un fichier aux droits restreints, conservé en dehors du dépôt. Ce sont des chiffres du code, et non des principes généraux — ils peuvent être lus et contestés.

L’interface de programmation n’est pas exposée directement sur internet

Elle n’écoute que sur l’adresse locale, donc le serveur web en façade est la seule voie publique ; la liste des domaines autorisés est explicite, et le corps des requêtes est plafonné à 1 MB. Les écritures exigent un jeton, les lectures non. C’est une configuration habituelle — le problème, c’est que lorsqu’elle manque, elle ne se voit pas de l’extérieur avant le jour où quelqu’un la découvre.

L’intégration continue rejette le paquet si elle y trouve un secret

La vérification qui compile et vérifie les types fait aussi quelque chose que peu de projets font : elle cherche des secrets dans le paquet construit et échoue si elle en trouve. C’est directement lié au défaut corrigé à la reprise — un mot de passe était arrivé dans le paquet public justement parce que rien ne vérifiait cela. Par-dessus cela, des mises à jour de dépendances au rythme hebdomadaire.

Ce qu’un site de clinique dentaire ne fait pas

Il ne confirme pas seul un rendez-vous : il collecte la demande, et la confirmation exige soit une personne, soit une connexion au système de prise de rendez-vous de la clinique — un travail distinct, avec ses propres conditions. Il ne publie pas d’information clinique rédigée par nous : le contenu sur les traitements relève de la responsabilité des spécialistes. Et il ne décide pas ce qui est couvert par l’assurance.

Traseul

Comment une demande passe par le système.

Nous inventorient la nomenclature avant le design

La première livraison est la liste des postes tarifaires avec l’unité de chacun et avec le marquage de couverture, dans la forme dans laquelle la clinique la tient. Si la liste n’existe pas sous une forme structurée — et, en général, elle existe sous forme de fichier de calcul ou de document — nous la structurons, puis la clinique la confirme. Le design vient après, car il dépend du nombre de postes.

Nous construisons la structure publique et le panneau, dans la même étape

Les écrans publics et le panneau à partir duquel on édite ne sont pas faits séparément, car sinon apparaissent des champs affichés qui ne peuvent pas être modifiés. Nous livrons le site avec les vraies données chargées, et non avec du contenu de remplissage — un site de clinique rempli de texte provisoire ne peut être évalué par personne.

Nous verrouillons les écritures et vérifions de l’extérieur

Authentification sur le serveur, jeton signé, limite d’essais, interface de prise de rendez-vous seulement sur l’adresse locale, liste de domaines autorisés, plafond sur le corps des requêtes. Nous livrons le résultat d’une vérification faite de l’extérieur : ce qui peut être lu sans authentification et ce qui ne peut pas être écrit.

Nous livrons avec une formation pour la personne qui édite, pas seulement avec des mots de passe

Nous remettons les accès, le document de mise en service et une courte formation pour la personne qui va modifier les tarifs et l’équipe. La livraison n’est pas considérée comme terminée tant que quelqu’un de la clinique n’a pas fait, seul, une modification qui apparaît sur le site.

4 straturi

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les règles diffèrent d’un secteur à l’autre. Voici celles qui s’appliquent aux cliniques dentaires.

Ce qui est public et ce qui ne l’est pas, sur un site de clinique: Public : la liste des services avec l’unité et le marquage de couverture, l’équipe, les horaires, les contacts de l’institution. Non public : tout ce qui arrive depuis un formulaire. La distinction semble évidente jusqu’au moment où quelqu’un met sur la page de retour un message avec son nom et son problème — c’est pourquoi les formulaires et l’affichage public ne partagent jamais la même source.
La demande de rendez-vous contient des données de santé: « J’ai mal à la dent de sagesse inférieure gauche » est une information sur la santé d’une personne identifiable, relevant d’une catégorie soumise à un régime plus strict. Les conséquences pratiques sont établies lors de l’implémentation : qui a accès aux messages reçus, combien de temps ils sont conservés, par quel canal ils arrivent et ce qui ne doit jamais être demandé dans le formulaire.
Les prix et le marquage de couverture appartiennent à l’institution: Nous les construisons comme structure et comme panneau ; leur contenu appartient à la clinique et change selon sa décision. Nous ne publions aucun chiffre de tarif comme exemple dans nos documents, même à titre illustratif — un tarif sorti de son contexte devient une déclaration sur la clinique.
Qui peut écrire dans les données publiques: Seulement celui qui dispose d’un jeton valide, obtenu par authentification sur le serveur, avec une limite de tentatives. Les lectures sont publiques parce qu’elles doivent l’être. La différence entre ces deux phrases est exactement le défaut que nous avons corrigé lors de la reprise du projet cité.
Ce qui reste dans l’historique du dépôt: Un historique de projet contient, presque toujours, des données que personne n’y a mises intentionnellement : un numéro de téléphone, une adresse e-mail, le nom de l’administrateur de contenu. Nous les traitons comme telles — elles ne sont pas reprises dans les supports publics et sont retirées du contenu à la demande du client.

Un cas

Un mot de passe administrateur qui arrivait dans le paquet servi au navigateur

La situation

Lors de la reprise d’un site de centre dentaire, le panneau d’administration présentait deux problèmes visibles uniquement de l’intérieur. Premier : le mot de passe était comparé dans le navigateur, donc il arrivait dans le paquet JavaScript public. Deuxième : les requêtes d’écriture vers l’interface de programmation pouvaient être faites par n’importe qui sur Internet, et le port était exposé directement.

Ce que nous avons construit

Nous avons déplacé la vérification sur le serveur : l’authentification renvoie un jeton signé avec HMAC-SHA256, valable 12 heures, avec une limite de 8 tentatives toutes les 15 minutes par adresse IP et des comparaisons en temps constant ; le secret de signature est généré automatiquement, avec des droits restreints, en dehors du dépôt. L’interface de programmation est restée à l’écoute uniquement sur l’adresse locale, avec le serveur web en frontal, une liste de domaines autorisés et un corps de requête plafonné à 1 MB. Les écritures sur les services et sur l’équipe exigent un jeton ; les lectures sont restées publiques. Au-dessus de tout, une intégration continue qui compile, vérifie les types et refuse le paquet si elle y trouve un secret.

Ce qui en est sorti

Les données publiques de la clinique peuvent être vérifiées de l’extérieur aujourd’hui aussi : 89 services, chacun avec catégorie, sous-catégorie, prix, unité et indicateur de couverture par assurance, dont 27 marqués comme éligibles. Ce qui a changé, c’est qui peut y écrire.

Ce que le cas ne dit pas

Nous n’avons pas construit la première version du site. D’après l’historique du dépôt, une partie des commits appartiennent à des développeurs externes. La contribution que nous pouvons montrer avec diff est la reprise : sécurité, intégration continue, types, dépendances.

Questions

Ce que demande quelqu’un des cliniques dentaires

Pouvons-nous changer nous-mêmes les prix, sans vous appeler ?

Oui — c’est la moitié du travail. Les services et l’équipe se modifient depuis un panneau ; les écritures exigent une authentification, les lectures restent publiques. Notre recommandation : à la livraison, la personne qui s’en occupera fait la modification devant nous, pour que nous sachions que cela marche de sa main, et non de la nôtre.

Comment montrer ce qui entre dans l’assurance obligatoire ?

Comme un indicateur sur chaque service, dans les mêmes données que vous éditez. Dans le travail que nous citons, 27 services sur 89 sont marqués comme éligibles. Nous construisons le champ et l’affichage ; ce qui est éligible ou non est l’affirmation de l’institution, parce qu’elle a des conséquences pour le patient et pour la clinique.

Pourquoi l’unité de mesure compte-t-elle pour un prix ?

Parce qu’en dentisterie le prix n’est pas par visite. C’est par dent, par mâchoire, par extraction, par cas traité, par séance. Un prix affiché sans unité produit exactement la conversation que la réception a dix fois par jour et, pire, le sentiment du patient qu’on lui a dit autre chose au téléphone.

Le site peut-il faire des programmations ?

Il peut collecter la demande. La confirmation d’un horaire exige soit une personne qui consulte l’agenda, soit une connexion au système de programmation de la clinique — c’est un travail séparé, avec vérification de compatibilité au préalable. Nous n’appelons pas « programmation en ligne » un formulaire qui envoie un e-mail.

Qui rédige les textes sur les traitements ?

Les spécialistes de la clinique. Nous ne rédigeons pas d’information clinique et nous ne l’« optimisons » pas pour la recherche, car cela reviendrait à formuler des affirmations médicales au nom d’une institution médicale. Nous structurons, nous posons les questions auxquelles le texte doit répondre et nous le publions après confirmation.

J’ai déjà un site fait par quelqu’un d’autre. Pouvez-vous le reprendre ?

Oui, et le travail dont nous parlons ici est exactement cela. Ce que nous faisons d’abord lors d’une reprise : nous regardons ce qui peut être écrit de l’extérieur, où se trouvent les mots de passe et ce qui arrive dans le paquet servi au navigateur. Dans le cas cité, le mot de passe administrateur arrivait dans le paquet public, et les écrits pouvaient être faits par n’importe qui. Nous avons déplacé la vérification sur le serveur et nous avons fermé les écritures.

À quelle vitesse une modification de tarif est-elle visible ?

Dès qu’elle est enregistrée, car les données publiques sont lues à partir de la même source que celle que vous éditez. Ce que nous ne promettons pas, c’est la vitesse à laquelle les résultats des moteurs de recherche sont mis à jour — cela ne dépend pas de nous et nous ne pouvons pas le garantir.

Que se passe-t-il avec les données du formulaire de contact ?

Cela se définit lors de l’implémentation : où elles vont, qui les voit, combien de temps elles sont conservées et ce qui n’est jamais demandé dans le formulaire. Dans une clinique, le message contient souvent une description d’un problème de santé, donc ce n’est pas « un lead », c’est une catégorie de données à régime strict — et son traitement est décrit dans la politique publiée de la clinique.

Le site indiquera-t-il qu’il est fait par vous ?

Seulement si vous le souhaitez. Certaines de nos réalisations portent une attribution dans le pied de page, d’autres non — cela dépend du client. Nous le mentionnons parce que c’est une question que posent les cliniques et parce que, lorsque le site ne porte aucune attribution, nous ne nous présentons pas non plus comme auteurs sans leur accord.

Le service, en détail Tous les scénarios

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons