Ce que j’ai appris en construisant une RegTech pour la santé

Connaître un problème ne signifie pas connaître son marché

C’est probablement l’un de mes premiers grands apprentissages.

Lorsqu’on possède une expertise métier, on peut identifier très précisément les limites d’un système existant.

On sait ce qui devrait fonctionner autrement. On imagine les outils, les processus et les architectures qui permettraient de faire mieux.

Mais avoir raison sur un problème ne suffit pas à construire une entreprise.

Il faut aussi comprendre qui est prêt à payer pour le résoudre, à quel moment, avec quel budget et dans quelles conditions.

Dans la santé, cette réalité est particulièrement marquée.

Les cycles de décision peuvent être longs. Les priorités changent avec les financements, les échéances réglementaires et les phases de développement. Et les entreprises ne disposent pas toutes de la même maturité pour adopter de nouveaux outils.

J’ai appris à distinguer trois choses qui me semblaient auparavant beaucoup plus proches : un besoin réel, une proposition de valeur pertinente et une opportunité commerciale concrète.

Ces trois éléments ne se rencontrent pas toujours au même moment.

La technologie ne résout pas un problème d’organisation

En venant de l’ingénierie logicielle, j’ai naturellement tendance à chercher comment les systèmes peuvent être améliorés.

Lorsqu’une information est saisie plusieurs fois, je pense intégration.

Lorsqu’une traçabilité est maintenue manuellement, je pense automatisation.

Lorsqu’un processus devient difficile à piloter, je pense architecture et circulation de l’information.

Mais en accompagnant des entreprises, j’ai compris que les difficultés les plus importantes ne sont pas toujours techniques.

Une équipe peut disposer d’excellents outils et rencontrer malgré tout des problèmes de coordination.

Une organisation peut produire une documentation conforme sans que les responsabilités soient réellement comprises.

Un projet peut accumuler des procédures alors que les décisions essentielles ne sont pas prises.

La technologie peut faciliter une organisation. Elle ne peut pas, à elle seule, remplacer la clarté de ses décisions.

C’est une leçon qui a profondément influencé ma manière de travailler.

Avant de chercher à automatiser un processus, je préfère désormais comprendre pourquoi il existe, qui l’utilise et quelle décision il doit permettre de prendre.

Construire un produit et construire une entreprise sont deux métiers différents

C’est une distinction qui paraît évidente lorsqu’on la formule.

Elle l’est beaucoup moins lorsqu’on la vit.

Construire un produit demande de comprendre les utilisateurs, de définir une architecture, de faire des choix techniques et d’améliorer continuellement ce que l’on développe.

Construire une entreprise demande aussi de vendre, recruter, financer, prioriser, négocier, anticiper les risques et parfois renoncer à des projets auxquels on croit profondément.

Les deux activités se nourrissent, mais elles ne suivent pas toujours les mêmes temporalités.

Une équipe peut avoir besoin de plusieurs mois pour construire une fonctionnalité structurante, tandis que l’entreprise doit assurer sa trésorerie dans les semaines qui viennent.

Un produit peut être techniquement prometteur sans avoir encore trouvé les conditions économiques de son développement.

Et une dirigeante doit apprendre à regarder ces réalités simultanément.

Je crois que c’est l’un des aspects les plus exigeants de l’entrepreneuriat : accepter que toutes les bonnes idées ne puissent pas être poursuivies, même lorsqu’elles sont pertinentes.

Apprendre à regarder au-delà de son expertise

J’ai longtemps considéré ma capacité à comprendre des sujets complexes comme l’une de mes principales forces.

La biologie m’a appris à observer et à rechercher des preuves.

Le développement logiciel m’a appris à modéliser, construire et tester.

La réglementation m’a appris à évaluer les risques, documenter les décisions et travailler dans des environnements exigeants.

L’entrepreneuriat m’a appris quelque chose de différent.

Il m’a obligée à accepter que certaines décisions ne disposent jamais de toutes les informations nécessaires.

Que les contraintes humaines, commerciales et financières sont aussi réelles que les contraintes techniques.

Et que diriger ne consiste pas seulement à trouver la meilleure solution, mais à choisir celle qui permet à l’organisation d’avancer avec les moyens dont elle dispose.

Cette expérience a changé mon regard sur les entreprises que j’accompagne.

Je ne regarde plus uniquement leurs enjeux de conformité ou leurs choix technologiques.

Je cherche à comprendre ce qui conditionne réellement leur capacité à avancer.

Ce que je conserve de cette aventure

QARA PULSE a représenté bien davantage qu’un projet technologique.

Cette aventure m’a permis de réunir des disciplines qui avaient longtemps constitué des étapes distinctes de mon parcours.

Elle m’a aussi confrontée à la réalité de l’entrepreneuriat, avec ses réussites, ses difficultés, ses décisions parfois inconfortables et ses apprentissages.

Je ne crois pas qu’une expérience entrepreneuriale se résume à la trajectoire d’une entreprise.

Elle se mesure aussi à ce que l’on a construit, aux personnes avec lesquelles on a travaillé, aux problèmes que l’on a contribué à résoudre et à ce que l’on devient en chemin.

Aujourd’hui, je continue à explorer cette intersection entre réglementation, technologie et stratégie.

À travers le conseil, mais aussi en développant des outils open source avec QARAWORK.

Avec une conviction renforcée par l’expérience : une innovation ne progresse pas uniquement parce qu’elle est techniquement possible. Elle avance lorsque les conditions humaines, économiques, organisationnelles et réglementaires permettent de la faire exister.

C’est à cet endroit que j’ai envie de continuer à travailler.