Retirer Algolia d'un logiciel de santé, la dépendance qui ne se justifiait plus

Sur ORIGAMI, le logiciel métier de santé que je développe pour SOS Médecins (voir le case study), la recherche de patients tournait sur Algolia. Un service de recherche hébergé, rapide, tolérant aux fautes de frappe. La semaine dernière, je l’ai débranché entièrement. Le bilan de la modification tient en deux chiffres : 33 lignes ajoutées, 331 supprimées. Et côté utilisateur, personne n’a rien remarqué. C’est exactement le résultat que je visais.

Pourquoi Algolia était là

Le réflexe est connu. On a besoin d’une « vraie » recherche, instantanée, qui pardonne les fautes de frappe, qui remonte le bon patient même quand on tape trois lettres de travers. On regarde Postgres, on se dit que ce sera compliqué, et on branche un service spécialisé. Algolia fait très bien ce travail. En quelques heures, la recherche est fluide et l’affaire semble réglée.

Sauf que « brancher Algolia » ne se résume jamais à une ligne. Dans le code, ça voulait dire : une gem côté Ruby, un paquet npm côté front, un initializer à configurer, des clés d’API exposées au navigateur, un job qui réindexait les patients en parallèle de la base à chaque modification, et trois contrôleurs Stimulus qui parlaient directement au client Algolia. Une dépendance, ce n’est pas un bouton qu’on active : c’est une surface qu’on adopte, qu’on met à jour, qu’on surveille et qu’on facture tous les mois.

Le vrai besoin, une fois posé à plat

La question que je ne m’étais pas reposée depuis longtemps : de quelle recherche ai-je réellement besoin, ici ?

La réponse est modeste. On cherche des patients dans le périmètre d’une structure de soins. Le jeu de données se compte en centaines de milliers d’enregistrements, pas en dizaines de millions. Les champs sont simples : un nom, un prénom, quelques identifiants. Le besoin réel, c’est de retrouver « Dupont » quand on tape « dupon », et de le retrouver vite.

Pour ça, Postgres suffit largement, y compris à cette échelle. L’extension pg_trgm calcule une similarité par trigrammes : elle absorbe la faute de frappe et le préfixe incomplet sans qu’on écrive le moindre algorithme de distance à la main. Une table dédiée matérialise le document de recherche de chaque patient, un job l’alimente à la modification, et la recherche s’exécute dans la même base, dans la même transaction, sans aller-retour réseau vers un tiers. Ce backend interne existait déjà et tournait par défaut depuis quelques semaines. Algolia n’était plus qu’un second moteur qu’on trainait par prudence.

Le vrai argument : de la donnée de santé qui voyage

Le KISS est une bonne raison. Ce n’est pas la meilleure ici.

Envoyer des noms de patients vers un index de recherche hébergé à l’étranger, c’est faire sortir de la donnée de santé de son infrastructure. Ça engage l’hébergement des données de santé, le RGPD, le principe de minimisation. Même quand tout est contractuellement carré, c’est une surface de gouvernance de plus : un endroit supplémentaire où de la donnée sensible transite, un sous-traitant de plus à auditer, une clause de plus à défendre le jour où quelqu’un pose la question.

Retirer Algolia, ce n’est donc pas seulement supprimer une dépendance et une facture de 250 € par mois. C’est retirer une raison de s’inquiéter. La donnée patient ne quitte plus la base. Il n’y a plus d’index externe à sécuriser, plus de clés d’API à faire fuir depuis le front, plus de contrat de sous-traitance à surveiller pour une fonctionnalité qu’on savait déjà faire en interne.

Le vrai enjeu de la bascule : que personne ne sente rien

Basculer d’un moteur de recherche à un autre sur un logiciel utilisé en production, ça ne se fait pas d’un coup de commutateur global. Le critère était clair : côté utilisateur, les temps de réponse de la recherche devaient rester rigoureusement identiques. Pas « à peu près aussi rapide », identique. Une recherche patient qui traîne d’un dixième de seconde de plus, sur un poste de régulation, ça se remarque tout de suite.

Pour valider ça sans risque, j’avais ajouté un booléen par utilisateur, internal_patient_search, qui activait le nouveau moteur pour quelques comptes seulement. Un mécanisme d’activation sélectif, pas un drapeau oublié : le temps de faire tourner les deux backends côte à côte, de comparer les temps de réponse en conditions réelles, et de confirmer que le passage à Postgres ne se sentait nulle part.

Une fois cette validation faite, le flag avait fait son travail. Je l’ai retiré en même temps qu’Algolia, dans la même passe : la colonne en base, la case dans les réglages, les paramètres autorisés du contrôleur, les libellés en deux langues et trois tests devenus sans objet. Un seul booléen touche déjà six endroits du code ; la discipline, ce n’est pas de ne jamais en ajouter, c’est de le démonter dès qu’il a fini de servir.

Ce que ce n’est pas

Ce n’est pas une charge contre Algolia. C’est un excellent produit, et il y a des contextes où je le rebrancherais sans hésiter : un gros catalogue e-commerce, une recherche grand public en façade, une tolérance à la faute de frappe à l’échelle de millions de documents. Le sujet n’est pas l’outil.

Le sujet, c’est la question qu’on se pose avant de l’adopter. Ce n’est pas « quelle est la meilleure recherche ? », c’est « de quelle recherche ai-je besoin, pour ce jeu de données, dans ce contexte ? ». Quand on prend le temps d’y répondre honnêtement, on évite souvent d’importer une dépendance, une facture récurrente, et, dans le cas de la santé, une donnée sensible qui n’avait aucune raison de voyager.

La simplicité est une décision

Absorber la complexité côté prestataire pour que le logiciel reste simple côté client, ça vaut aussi pour la complexité qu’on s’inflige à soi-même. Le meilleur code n’est pas celui qu’on écrit avec le plus d’élégance : c’est celui qu’on retire parce qu’on n’en a plus besoin, et qu’on n’aura plus jamais à maintenir. 331 lignes en moins, une dépendance de moins, une donnée de santé qui reste chez elle, et une interface strictement identique pour l’utilisateur, temps de réponse compris. C’est ça, un bon jour.

Si vous avez sous le capot une dépendance externe qui vous coûte tous les mois sans que vous sachiez vraiment ce qu’elle vous apporte, on peut regarder ensemble ce qui mérite d’y rester et ce qui peut rentrer à la maison.