Abrux

L'enjeu humain derrière le projet : Le bruxisme (grincement ou serrement des dents) touche 8 à 10% de la population, soit environ 6 millions de Français. Mais seulement 30% sont diagnostiqués, car les symptômes sont souvent attribués à tort à d'autres pathologies (migraines, douleurs cervicales, usure dentaire "normale").

Avant Abrux, un patient pouvait errer pendant des années entre médecins généralistes, kinésithérapeutes et dentistes avant qu'on identifie le bruxisme comme cause racine. Dr. Etienne Suerinck, chirurgien-dentiste spécialisé en bruxisme, était sollicité 10 à 15 fois par semaine par des confrères désemparés face à des cas complexes.

Le lien avec la santé mentale : Le bruxisme n'est pas qu'un problème dentaire. Il est souvent déclenché ou aggravé par le stress, l'anxiété, voire des troubles du sommeil liés à des facteurs psychologiques. Traiter le bruxisme nécessite donc une approche multifactorielle, proche de celle de la santé mentale : comprendre le patient dans sa globalité, pas juste ses symptômes.

La situation d'Etienne :

• Quel problème rencontrait-il ? Il voulait partager son expertise du bruxisme à ses collègues dentistes, car on lui demandait souvent de l'aide dans ce domaine et c'est une spécialité rare. Il voulait créer un système de recommandation où, à partir d'un questionnaire patient, un algorithme prédise des recommandations accessibles au dentiste, avec des tests à faire pour valider ou non les recommandations et les donner aux patients, ainsi que des fiches informatives pour les aider.
• Quelle était sa situation avant le projet ? Il recevait des mails de ses confrères sur des cas qu'ils recevaient pour savoir s'il y avait ou non du bruxisme et obtenir ses recommandations. Il était frustré de faire ça et voulait automatiser la chose.
• Pourquoi a-t-il fait appel à moi ? Etienne m'a découvert sur LinkedIn grâce à mon profil "Spécialiste IA en santé mentale". Ce qui peut sembler paradoxal (pourquoi un dentiste contacte un expert en santé mentale ?) avait du sens pour lui : il cherchait quelqu'un qui comprenne que la santé ne se réduit pas à la technique, mais nécessite une approche empathique et systémique. Mon passage chez Capgemini, où j'avais touché à de nombreux domaines (IA, backend, gestion de données sensibles), combiné à ma sensibilité aux enjeux psychologiques, en faisait un profil rare : capable de coder ET de comprendre les nuances cliniques.

Nous avons défini 4 objectifs progressifs, chacun validant l'étape suivante :

1. Valider la faisabilité technique (POC) : Le premier objectif a été de faire un POC (Proof of Concept) pour valider qu'on pouvait, à partir d'un questionnaire, générer des recommandations cliniquement pertinentes.
2. Intégrer la logique d'expertise : Le second a été d'intégrer la logique de recommandation et de détection du bruxisme d'Etienne dans le but de créer des données qui serviraient ensuite dans l'entraînement d'un réseau de neurones.
3. Garantir la conformité réglementaire : Le troisième était que le système soit certifiable comme système de santé, notamment en lien avec la protection des données de santé (RGPD, HDS).
4. Assurer l'évolutivité : Enfin, le projet devait être évolutif en permettant l'ajout de nouvelles fonctionnalités tous les 2 mois via des sprints agiles.

J'ai structuré le projet en 4 phases itératives, avec des livrables concrets à chaque étape :

Phase 1 : Cadrage (2 mois - POC inclus)

L'objectif de cette phase était double : comprendre comment le spécialiste proposait ses recommandations et ce qu'il voulait faire du projet.

Nous avons fait des ateliers où il me présentait des études de cas en m'expliquant ce qu'il avait recommandé, pourquoi et comment. Nous avons construit une série de règles d'abord basiques pour le POC, puis plus complexes lors des différents sprints pour structurer et utiliser son savoir via un système de règles.

Nous avons aussi fait des ateliers pour comprendre comment l'utilisateur final allait interagir avec le système, notamment avec Thomas et son équipe, développeurs qui s'occupait de la partie front-end via WordPress.

Livrable : POC fonctionnel validé par 5 soignants testeurs, système de règles v1.0 avec 23 règles de base, schéma d'architecture technique validé.

Phase 2 : Co-conception UX avec l'équipe front-end (2 mois)

Bien que je ne maîtrisais pas suffisamment React à l'époque pour implémenter les interfaces moi-même, j'ai joué un rôle clé dans la co-conception UX aux côtés de Thomas (développeur WordPress/front-end) et de l'agence UX externe.

Mon rôle spécifique :

• Validation des parcours utilisateurs : Garantir que les workflows respectent les contraintes cliniques. Exemple : le questionnaire patient ne doit pas être interruptible (risque de données incomplètes qui fausseraient les recommandations).
• Feedback sur les wireframes : Lors des ateliers avec Etienne, Clémence (directrice commerciale) et Thomas, j'apportais la perspective technique ("Cette fonctionnalité est-elle faisable dans le backend ?") et clinique ("Est-ce que ce parcours a du sens pour un soignant en consultation ?").
• Interface d'administration : J'ai co-conçu l'interface permettant à l'administrateur de paramétrer le système de règles, en veillant à ce qu'elle soit utilisable sans compétences techniques.
• Itération sur les maquettes : Les premières maquettes Google Slides ont évolué vers des prototypes Figma professionnels grâce à l'agence UX.

Résultat : Une interface qui a été adoptée sans formation formelle par 60 soignants, preuve que le design était intuitif et cliniquement pertinent. Le taux d'abandon du questionnaire patient est inférieur à 5%, un signe que le parcours est fluide.

Phase 3 : Développement (4 mois de développement intensif après POC)

Ne m'occupant que de la partie infra et backend, j'ai mis en place le serveur avec au début LimeSurvey pour faire les questionnaires (en front), qui a été ensuite intégré lors d'un sprint suivant à l'interface de Thomas.

Stack technique et pourquoi ces choix :

• Python 3.12 avec FastAPI : Pour garantir des temps de réponse instantanés (< 200ms), crucial quand un soignant est en consultation avec un patient et ne peut pas attendre 5 secondes pour afficher des recommandations.
• Docker : Pour la portabilité et la certification HDS. Un container Docker garantit que l'environnement de production est strictement identique à celui de développement, éliminant les bugs du type "ça marche chez moi mais pas en prod".
• PostgreSQL : Pour gérer les relations complexes patient/soignant/recommandations/questionnaires avec intégrité référentielle. Un système de santé ne peut pas se permettre de perdre des données ou d'avoir des incohérences.
• Serveur dédié (pas de cloud public) : Pour le contrôle total de la sécurité et la conformité HDS. J'ai configuré le serveur de zéro : SSH par authentification à 2 facteurs, surveillance des logs en temps réel, scan automatique des vulnérabilités, backups chiffrés quotidiens.

Fonctionnalités développées par rôle :

Le patient peut : S'inscrire, remplir un questionnaire (plus de 50 questions), modifier son profil, choisir un soignant sur une carte interactive, voir les recommandations que le soignant partage avec lui.

Le soignant peut : Accepter ou refuser un patient, acheter des crédits (pour valider des patients et accéder au système de recommandation), voir les recommandations validées par les administrateurs, accéder aux données des patients qu'il suit, modifier ces recommandations en fonction du rendez-vous avec le patient (le système propose, le soignant valide et ajuste).

L'administrateur peut : Ajouter un soignant (pour éviter les faux comptes), superviser des soignants ou des patients (voir leurs écrans et agir à leur place si besoin de support technique), modifier les recommandations faites par le système et les partager au soignant, ajouter des fiches PDF (pour les soignants et patients), ajouter des produits dans la boutique, modifier le système de règles (135 règles actuellement) et le tester en environnement sandbox.

Il y a aussi un système de boutique avec facturation (intégration Monetico), un système de documents (pour gérer et récupérer des PDFs), et bien sûr le cœur du système : l'algorithme de règles qui définit les recommandations.

Organisation agile : Nous avons fonctionné en méthode agile. Chaque fin de semaine, mon client recevait un mail avec ce qui avait été fait, les difficultés rencontrées, des questions en cas de doutes, et ce que je prévoyais de faire la semaine suivante. Je faisais des réunions uniquement si c'était nécessaire afin de valider avec le client des choix techniques importants (comme la structure de la base PostgreSQL).

À chaque fin de sprint (2 mois), nous faisions un bilan démo avec ce qui avait marché et moins marché, et comment être plus efficace le sprint suivant. Ensuite, je faisais une nouvelle proposition commerciale suite aux nouvelles fonctionnalités à développer dans le sprint suivant. Il y avait aussi des réunions avec Thomas d'abord pour un rétroplanning, puis lors des tests pour ajuster le back aux besoins front avant les démos clients.

Phase 4 : Déploiement & Formation (cycle continu)

Comme le produit est en développement continu, il y a un cycle de déploiement et formation à la fin de chaque sprint.

D'abord il y a 3 jours de tests (et de formations) sur le serveur de développement, puis une fois validé, on met le site en maintenance pour faire la mise à jour de la plateforme et du serveur (généralement entre 1h et 2h de maintenance, effectuée le mercredi soir pour minimiser l'impact).

Il arrive aussi de faire des ateliers spécifiques de formation sur un domaine très pointu comme le paramétrage du système de règles par exemple (formation de 2h avec l'équipe administrative d'Abrux).

Chaque projet a ses obstacles. Voici les 3 plus significatifs, et comment je les ai surmontés :

Après 2 ans de développement continu, Abrux est aujourd'hui une plateforme stable, adoptée par des dizaines de professionnels, et qui impacte concrètement la prise en charge du bruxisme.

Ce que ces chiffres signifient concrètement

Au-delà des métriques brutes, voici l'impact réel d'Abrux sur le terrain :

• 311 recommandations générées = 311 patients qui ont reçu un plan de traitement personnalisé (sans plusieurs semaines d'attente pour consulter un spécialiste comme Etienne).
• 60 soignants formés = Démocratisation d'une expertise rare. Des dentistes généralistes peuvent désormais traiter des cas de bruxisme complexes sans dépendre d'Etienne.
• 95,6% d'uptime = Une fiabilité critique en santé. Les soignants peuvent compter sur le système en consultation, sans risque de panne en plein rendez-vous patient.

Impact business pour le client : Abrux a permis à CIREUS de passer d'un modèle "expertise personnelle non scalable" à un modèle "plateforme SaaS" avec un potentiel de croissance exponentiel. Le projet a été présenté dans 3 salons professionnels dentaires, générant de nombreuses demandes de démo.

Livrables finaux

• Infrastructure de production sécurisée : Serveur dédié configuré from scratch, certifiable HDS, avec backup automatique chiffré quotidien et monitoring 24/7. Les données de 311 patients sont protégées selon les standards les plus stricts.
• API backend performante : Temps de réponse < 200ms pour toutes les requêtes, permettant une utilisation fluide en consultation. Capacité de traiter 20+ questionnaires simultanés sans ralentissement.
• Système de règles évolutif : 135 règles de recommandation paramétrables via interface d'administration, permettant à l'équipe d'Abrux d'ajuster le système sans intervention technique de ma part.
• Documentation technique complète : 50 pages couvrant l'architecture, les choix de conception, les procédures de déploiement et de maintenance. Permet à un développeur externe de reprendre le projet si nécessaire (pérennité).
• Produit en développement continu : 8 sprints réalisés sur 2 ans, nouvelles fonctionnalités tous les 2 mois, preuve de la pérennité et de l'évolutivité du projet.

18 mois après le déploiement initial, Abrux continue d'évoluer et d'impacter positivement la prise en charge du bruxisme :

• Utilisation quotidienne : 20 questionnaires remplis par des patients chaque mois, soit environ 1 nouveau patient par jour ouvré.
• Partage de recommandations : 30 partages de recommandations par mois entre soignants et patients, preuve que le système facilite la communication clinique.
• Visibilité professionnelle : Solution présentée dans 3 salons dentaires majeurs, avec 20+ demandes de démo qualifiées.
• Développement continu : Sprint 9 en cours, avec l'ajout d'un mini questionnaire pour permettre aux utilisateurs d'avoir une idée de leur risques de bruxisme.

Vision future : L'objectif d'Etienne est d'étendre Abrux en ajoutant des fonctionnalités en réutilisant l'infrastructure existante. C'est exactement ce pour quoi j'ai conçu le système : scalable et modulaire.

Deux ans sur Abrux, c'est bien plus qu'un projet technique. C'est une école de rigueur, de patience, et d'humilité. Voici les 4 apprentissages majeurs qui façonnent aujourd'hui ma pratique.

1. Maîtrise technique : Construire un serveur de santé from scratch

Avant Abrux, je n'avais jamais géré une infrastructure complète en production, encore moins avec les contraintes d'un serveur de santé. J'ai dû apprendre :

• La sécurisation avancée (authentification SSH par clé, surveillance des logs, scan de vulnérabilités)
• La certification HDS (Hébergeur de Données de Santé) : comprendre les exigences techniques ET légales
• La gestion des backups chiffrés et de la haute disponibilité (95,6% d'uptime, ça ne se fait pas tout seul)
• Docker en production : pas juste un "docker-compose up", mais de la vraie orchestration avec rollback automatique

Leçon clé : En santé, la technique n'est pas un "nice to have", c'est une responsabilité éthique. Un serveur qui plante, ce ne sont pas des données perdues, ce sont des patients non traités.

2. Transformation d'expertise : De la connaissance tacite au système de règles

Le défi le plus fascinant n'était pas technique, mais épistémologique : comment extraire 15 ans d'expertise clinique d'Etienne et la transformer en algorithme ?

Les premiers ateliers étaient frustrants. Etienne me disait : "Je regarde le patient et je sais." Mais un système ne peut pas "juste savoir". J'ai appris à :

• Poser les bonnes questions : "Qu'est-ce qui te fait dire ça ?" plutôt que "Comment tu fais ?"
• Décomposer des raisonnements intuitifs en arbres de décision explicites
• Valider chaque règle avec des cas réels (nous avons testé le système sur 50 dossiers patients anonymisés)
• Accepter l'incomplétude : le système ne remplacera jamais le jugement clinique, il l'augmente

Leçon clé : La vraie IA en santé n'est pas dans les réseaux de neurones, mais dans la capacité à modéliser l'expertise humaine avec rigueur et humilité.

3. Gestion de projet : Collaborer avec un client non-tech pendant 2 ans

Etienne est chirurgien-dentiste, pas développeur. Pendant 2 ans, j'ai dû adapter ma communication, mes outils, ma pédagogie. J'ai appris que :

• Les mails hebdomadaires (bilan + questions + prévisions) créent une confiance durable, même sans réunions
• Les démos valent mieux que les specs : montrer un prototype imparfait > envoyer un document de 20 pages
• La transparence sur les échecs est payante : quand j'ai sous-estimé le Sprint 2 de 2 mois, j'ai assumé et continué à mes frais. Résultat : Etienne continue de me faire confiance pour continuer le développement.
• Les rétrospectives de sprint ne sont pas que du Scrum corporate, c'est un outil d'amélioration continue réel

Leçon clé : Un projet technique réussi, c'est 30% de code et 70% de relation humaine. La confiance se gagne en étant clair, honnête, et en livrant ce qu'on promet.

4. Éthique et responsabilité : Construire pour de vrais humains

Abrux n'est pas un side project, c'est un outil utilisé par 311 patients réels qui souffrent de bruxisme. Chaque ligne de code a un impact clinique. Cette responsabilité m'a appris :

• À tester obsessionnellement (chaque nouvelle fonctionnalité passe par 3 jours de tests avant production)
• À documenter pour l'auditabilité (si une recommandation est contestée, on doit pouvoir expliquer pourquoi le système l'a générée)
• À prioriser la sécurité sur les features (j'ai refusé une demande client qui aurait compromis la protection des données)
• À accepter la lenteur : en santé, on ne "move fast and break things". On avance méthodiquement.

Leçon clé : En santé mentale (et physique), la technologie n'est jamais neutre. Chaque choix technique est un choix éthique. C'est ce qui rend ce métier passionnant.