La soirée qui a suivi ma visite au cabinet était l’une de ces soirées où l’on n’a, en vérité, plus envie de rien faire. J’étais chez moi, avec devant moi un carnet dans lequel j’avais, le matin, tenu des petits bâtons. Combien de fois Mala avait-elle cherché une fiche ? Combien de fois avait-elle recopié le même numéro de téléphone ? Combien de fois la doctoresse avait-elle dû écrire deux fois une phrase de l’ordonnance parce que le premier papier n’était pas lisible à la pharmacie ?
Je me méfie des chiffres que je n’ai pas mesurés proprement, et ceux-ci, je ne les ai pas mesurés proprement. C’étaient trois heures d’observation, un crayon et mon intuition. Mais l’intuition était claire. Au fil de la journée, dans ce petit cabinet, plusieurs heures partaient dans des tâches qu’un ordinateur règle en quelques secondes : chercher, recopier, rapprocher, réécrire. Plusieurs heures, chaque jour, payées à quelqu’un qui est en réalité là pour autre chose.
Pourquoi ne pas simplement acheter quelque chose
C’était ma première réaction, et c’est la bonne. En vingt ans, j’ai appris que construire son propre logiciel est presque toujours la réponse la plus chère à un problème. J’ai donc regardé ce qui existait. Le monde des logiciels de cabinet se divise grosso modo en trois sortes, du moins tel que je l’ai vécu à l’époque.
La première sorte est trop grosse. Ce sont des systèmes pour des cliniques dotées d’un service informatique, avec des formations et des projets de déploiement de plusieurs mois. Pour trois médecins et une secrétaire, c’est comme acheter un camion pour aller chercher le pain.
La deuxième sorte est trop vieille. Des programmes qui ont été bons un jour, mais dont l’écran donne l’impression que personne n’y a touché depuis quinze ans, et dont on se demande qui les entretient encore.
La troisième sorte est bonne, mais vient d’un autre monde. Les produits modernes dans le cloud sont le plus souvent excellents, mais ils sont faits pour un marché qui n’est pas celui de ce cabinet : une autre monnaie, d’autres formats fiscaux, un autre internet. Je l’ai raconté en détail dans ma comparaison avec Cliniko, donc je ne veux pas le répéter ici. Je dirai seulement que je n’ai pas écarté ces produits parce qu’ils sont mauvais. Je les ai écartés parce qu’ils étaient faits pour d’autres pièces.
La règle que je me suis donnée
Avant d’écrire la première ligne de code, j’ai noté une règle : je ne construis que ce qui est utilisé tous les jours dans ce cabinet. Rien qui ait seulement l’air joli. Rien que je construise seulement parce que je sais le faire.
Cela paraît évident. En réalité, c’est la discipline la plus difficile que je connaisse, parce qu’en tant que développeur on a des idées en permanence. Un tableau de bord avec de beaux graphiques. Une fonction de rappel. Une statistique. J’ai mis toutes ces idées dans une liste que j’ai appelée « plus tard » et je n’y ai pas touché tant que l’essentiel ne fonctionnait pas.
L’essentiel, d’après mes petits bâtons, c’était cinq choses.
Ce que j’ai construit d’abord
Le patient. Un formulaire avec ce que Mala demande de toute façon au téléphone : nom, date de naissance, sexe, téléphone, adresse. Et des éléments qu’une doctoresse veut connaître avant de prescrire : groupe sanguin, allergies, antécédents. J’ai longtemps hésité à faire des allergies un champ à part ou une partie des antécédents. J’ai choisi un champ à part, parce que je ne voulais pas qu’elles se perdent au milieu de vingt lignes de texte.
Le rendez-vous. Un rendez-vous appartient à un patient et à un médecin, a une date, une heure, un type (par exemple consultation ou contrôle) et un statut. Sur l’écran d’accueil figure la liste des rendez-vous du jour. Cela paraît banal, mais c’est précisément cette liste que Mala recopiait chaque matin depuis l’agenda.
La consultation. C’est le cœur. La doctoresse note ce qu’a la patiente, les plaintes et les symptômes, le diagnostic, ce qu’elle prescrit, si elle recommande des analyses, et quand la patiente doit revenir. Tout est rattaché au rendez-vous et à la patiente.
Le laboratoire. Une demande d’analyse, un statut, un résultat. Rien de plus. Mais cela remplace la pile de photos qui arrivaient sur la messagerie du cabinet.
La facture. Une facture comporte des lignes pour la consultation, les médicaments, le laboratoire et autres, une remise, un total, le montant payé, le mode de paiement et un statut. S’y ajoute une liste de pharmacie simple avec le stock, le minimum et la date de péremption, parce que le cabinet délivre lui-même quelques médicaments.
C’est tout. Pas de miracle, mais c’est ce qui se passe réellement un jour ordinaire.
Pourquoi une application de bureau
La question que me pose tout développeur : pourquoi pas une application web ? Ce serait aujourd’hui le chemin naturel. La réponse tient au cabinet, pas à moi.
Une application web a besoin d’un serveur et d’une connexion internet. Celui qui fait tourner le serveur doit l’entretenir, le sauvegarder, le mettre à jour. Un petit cabinet n’a personne pour cela. Celui qui le loue confie les données des patients, et c’est exactement ce que la doctoresse ne voulait pas. Et quand internet tombe, tout s’arrête.
J’ai donc construit un programme Windows qui fonctionne sans internet. Les données sont dans un seul fichier SQLite sur l’ordinateur du cabinet. En interne, c’est du VB.NET, et l’écran est une vue web dans la fenêtre Windows, parce que j’obtiens ainsi plus vite un aspect propre. Pour le cabinet, cela veut simplement dire : ouvrir le programme, travailler, copier le fichier.
Cela a un prix, et je ne veux pas le cacher. Un programme local signifie que le cabinet est responsable de ses sauvegardes. Plusieurs ordinateurs utilisant les mêmes données en même temps, c’est plus difficile qu’avec une solution cloud. Et quelqu’un doit installer les mises à jour. J’ai pesé ces inconvénients contre l’avantage de permettre au cabinet de continuer à travailler même quand la lumière vacille et que le réseau disparaît, et j’ai choisi le programme de bureau. Pour un autre cabinet, le calcul peut être différent.
Ce qui m’a surpris
Je pensais que les plus grands défis seraient techniques. Ils l’ont à peine été. Les plus grandes surprises sont venues de Mala et de la doctoresse.
Mala voulait que, en créant un rendez-vous, on voie tout de suite si la patiente était déjà venue. Je ne l’avais pas prévu. C’était un petit souhait, mais il m’a montré ce que regarde quelqu’un qui coince le téléphone entre l’épaule et l’oreille. Je l’ai mis sur la liste.
La doctoresse voulait fixer la date du prochain contrôle directement dans la consultation, pas dans une fenêtre de rendez-vous à part. Elle a dit : « Si je l’écris là où j’écris de toute façon, je ne l’oublie pas. » C’est pourquoi la consultation comporte un champ pour cela.
Ce qui m’a le plus frappé : elles ne m’ont presque jamais dit ce qui leur plaisait. Elles m’ont dit ce qui gênait. C’est le meilleur retour qu’on puisse recevoir, et j’ai appris à guetter les soupirs, pas les compliments.
Les semaines où j’ai douté
Il y a eu une phase, environ après le premier mois, où j’ai sérieusement pensé à tout jeter. Pas parce que ce n’était pas faisable techniquement, mais parce que je me suis posé la plus honnête des questions : qui a vraiment besoin d’un logiciel de cabinet de plus ?
Il y en a des dizaines. Certains sont très bons. Pendant deux semaines, j’ai eu le sentiment de réinventer une roue déjà parfaitement ronde. Le soir, je m’asseyais devant les lignes de code et je pensais : tu aurais pu simplement conseiller un abonnement à la doctoresse, et l’affaire serait réglée.
Ce qui m’a retenu, au bout du compte, ce n’est pas un grand objectif, mais une observation petite et peu romantique. Chaque fois que je passais au cabinet, l’agenda était encore sur la table, mais Mala regardait de plus en plus souvent l’écran en premier. Pas parce que je l’y poussais, mais parce que la liste y était plus rapide. C’est une phrase que j’ai retenue : personne ne change pour un bon argument, les gens changent parce que quelque chose est plus simple.
Ce que j’ai choisi de ne pas construire
Une liste de ce qui n’y est pas en dit plus sur un produit qu’une liste de ce qui y est. Voici la mienne.
Je n’ai pas intégré d’intelligence artificielle qui propose des diagnostics. On le demande souvent, et je trouve que c’est une mauvaise idée dans un programme qu’un seul développeur construit et ne peut pas valider cliniquement. Une erreur ne serait pas là un défaut esthétique.
Je n’ai pas intégré de base de médicaments avec contrôle des interactions. Le texte de l’ordonnance dans la consultation est un champ de texte. La doctoresse écrit ce qu’elle prescrit. Le programme ne réfléchit pas avec elle, et je ne veux pas le présenter autrement. Une base de médicaments vérifiée est un projet de plusieurs années avec des spécialistes, pas quelque chose qu’on ajoute en passant.
Je n’ai pas construit de comptes utilisateurs avec rôles et droits au sens des grands systèmes. Pour trois médecins et une secrétaire qui se connaissent, ce n’était pas le problème le plus urgent. Pour un cabinet plus grand, ce le serait, et il faudrait alors que je rattrape cela.
Et je n’ai pas construit de connexion avec les assurances. Dans ce cabinet, la plupart des patients paient eux-mêmes, et chaque connexion serait un pays différent avec ses propres règles.
Une matinée avec le programme
Imaginez qu’il est huit heures et demie. Mala allume l’ordinateur et ouvre le programme. Sur l’écran d’accueil figurent les rendez-vous du jour, triés par heure. Le premier est un contrôle, le deuxième un nouveau patient.
Le nouveau patient entre. Mala l’enregistre : nom, date de naissance, téléphone, une phrase sur les allergies qu’il mentionne quand on lui demande. Cela prend une minute. La doctoresse ouvre le rendez-vous, note les plaintes, écrit le diagnostic, tape l’ordonnance et fixe la date du contrôle. Si elle veut une prise de sang, elle crée une demande de laboratoire.
À la fin, le patient se rassoit près de Mala. Elle établit la facture : consultation, médicaments, laboratoire, peut-être une remise, paiement en espèces ou autrement. Terminé.
Rien de tout cela n’est spectaculaire, et c’est le but. En tant que développeur, on aimerait parfois que quelqu’un dise « waouh ». Ici, ce serait mauvais signe. Quand le logiciel est bon, personne ne dit rien. Il est simplement là, et la matinée passe plus vite.
Ce que tout cela m’a coûté
Je veux être honnête sur le temps et l’effort, parce que je crois que beaucoup de développeurs enjolivent sur ce point.
Un programme comme celui-ci n’est pas l’affaire de quelques week-ends. La première version qu’on peut montrer est prête en quelques jours. La version sur laquelle quelqu’un s’appuie au quotidien demande des mois, et surtout la patience de retourner sans cesse au cabinet, d’observer et de jeter des choses qu’on croyait intelligentes. J’ai passé plus de temps à observer qu’à programmer, et je referais pareil.
Et puis il y a la responsabilité. Quand un cabinet confie ses rendez-vous et ses dossiers à un programme, une erreur n’y est plus un jeu. J’ai donc appris à être prudent avec les promesses, et j’ai pris l’habitude de dire, dans chaque texte comme celui-ci, ce qui ne fonctionne pas.
Ce qui manque encore, et pourquoi je ne le cache pas
ClinicPlusPlus n’est pas terminé. Je ne l’écris pas par modestie, mais parce que c’est vrai.
Certains écrans sont encore des prototypes. L’accueil et les rapports ne sont pas encore partout reliés aux données réelles. Il n’y a pas de sauvegarde automatique, seulement la copie manuelle du fichier. Une facture conforme à la fiscalité indienne, avec la GST, est sur ma liste et n’est pas encore construite. Les patients ne peuvent pas réserver en ligne et il n’y a pas de rappels par SMS. Il n’existe pas non plus de protection automatique contre les rendez-vous en double ; j’en parlerai dans un article à part.
Qui a besoin d’une solution terminée ne devrait pas attendre mon programme, mais regarder les produits mûrs. Je le dis sérieusement.
Ce que j’en retiens
Avec le recul, la phrase la plus importante de toute cette histoire n’était pas technique. C’était la question que je me suis posée ce soir-là, avec le carnet : est-ce que je résous un problème que quelqu’un a vraiment, ou est-ce que je construis quelque chose parce que je le peux ?
Je ne sais pas si ClinicPlusPlus deviendra un jour un grand produit. Je sais qu’il a commencé par un problème que j’ai vu de mes propres yeux, et que chaque fonction qu’il contient y est parce que quelqu’un en a besoin chaque jour. C’est un bon début, même si ce n’est pas une fin.
Si vous dirigez un cabinet et que vous vous reconnaissez dans une partie de cette histoire, écrivez-moi. Je m’intéresse moins à savoir si le programme vous plaît qu’à ce qui, chez vous, gêne.
Cet article décrit l’état du développement au moment de sa publication.