Co-concevoir son logiciel en santé, c’est associer patients et soignants à la construction du produit avant que les choix soient faits, et pas seulement leur montrer une maquette pour recueillir un avis poli. Concrètement, cela veut dire choisir la bonne méthode de collecte terrain (entretien, wireframe, focus group, prototype, MVP) selon la maturité du projet, et creuser systématiquement derrière chaque demande formulée pour ne pas confondre un symptôme avec le vrai besoin.
C’est une nuance qui paraît petite sur le papier. Elle change pourtant tout le sort d’un produit de santé numérique : c’est elle qui décide si, le jour du lancement, les utilisateurs sont encore là pour l’adopter — ou si le logiciel reste, une fois de plus, à côté des pratiques réelles du terrain.
Co-conception : de quoi parle-t-on vraiment ?
Dans les dossiers d’investisseurs comme dans les pitchs de startups santé, la phrase revient presque à l’identique : « nous construisons notre application avec les usagers ». C’est un bon argument marketing. C’est aussi, très souvent, une case cochée plutôt qu’une méthode réellement appliquée.
Sur le terrain, j’entends l’envers de cette phrase de la bouche des patients et des soignants eux-mêmes : « ce logiciel, on n’a jamais été consulté, il ne colle pas à nos pratiques ». Entre les deux discours, il y a un fossé — et ce fossé se creuse presque toujours au même endroit : au moment de choisir entre faire valider une idée déjà arrêtée, et faire réellement participer les utilisateurs à sa construction.
À retenir : la co-conception d’un logiciel santé consiste à associer les usagers (patients, soignants, aidants) à la construction du produit pendant que tout est encore ouvert — pas à leur demander de valider une solution déjà pensée dans votre coin.
Faire valider n’est pas faire participer
Faire valider, c’est montrer une solution déjà pensée et demander un avis dessus. Faire participer, c’est associer l’usager à la construction de la solution en amont, avant que quoi que ce soit ne soit figé. Sur le papier, la nuance semble mince. Dans les résultats, elle est considérable.
L’erreur la plus fréquente, y compris chez les porteurs de projet qui viennent eux-mêmes du terrain (ancien patient, ancien soignant), consiste à penser que parce qu’ils savent ce qu’ils voudraient trouver dans l’application, tout le monde partage le même besoin. C’est rarement le cas : un contexte de soin libéral n’est pas un contexte hospitalier. Laisser s’exprimer des usagers extérieurs à votre propre expérience — sans exposer votre solution avant qu’ils aient parlé — évite de simplement valider ce que vous aviez déjà en tête.
Quelle méthode de co-conception choisir selon la phase de votre projet ?
Chaque étape de la conception d’un produit santé appelle un outil différent. Voici comment je les répartis, dans l’ordre où ils interviennent réellement sur un projet.
Les entretiens exploratoires, en tout début de projet. Avant même de parler fonctionnalités, l’objectif est de comprendre le quotidien réel de la personne : comment elle gère aujourd’hui son parcours de soin, avec quels outils de fortune (un carnet, un tableau Excel, rien du tout), et où ça coince vraiment. Avec des patients, cela suppose des questions ouvertes sur le vécu, sans jamais transformer l’entretien en consultation déguisée. Avec des soignants, l’enjeu est d’aller chercher la charge mentale et les contournements développés pour tenir dans un système qui ne facilite rien.
Les wireframes, en phase de cadrage. Une fois le problème compris, le wireframe sert à tester un parcours, pas un design — volontairement imparfait, pour signaler à l’usager qu’il peut encore tout changer. Trop abouti, il donne l’impression que tout est déjà décidé, et referme la porte à la critique constructive.
Le focus group, pour arbitrer, pas pour faire émerger. Utile pour trancher entre deux ou trois pistes déjà dégrossies. Beaucoup moins utile pour faire émerger un besoin, car la dynamique de groupe écrase les avis minoritaires — exactement ceux qu’on cherche à entendre en santé, comme le patient dans une situation atypique ou le soignant à l’usage différent du reste de l’équipe.
Le prototype, puis le MVP, pour observer l’usage réel. Sur un prototype, on observe plus qu’on ne demande un avis : est-ce que la personne comprend où cliquer, hésite, abandonne — idéalement avec un groupe qui n’a pas participé aux étapes précédentes, pour éviter un avis biaisé par la familiarité avec le projet. Le MVP, lui, est le dernier maillon, jamais le premier : il engage de vrais enjeux (un vrai suivi de traitement, une vraie donnée de santé), ce qui change la nature du retour obtenu par rapport à un simple prototype.
Cette hiérarchie de méthodes fait partie de ce que je transmets dans l’Accompagnement Produit Signature : une méthode complète pour cadrer la conception de votre logiciel santé, du premier entretien terrain jusqu’à la passation.
La technique des 5 pourquoi, pour ne pas construire la mauvaise fonctionnalité
Un usager formule presque toujours son retour sous forme de solution toute faite. Le réflexe du porteur de projet pressé est de développer exactement ce qui a été demandé. Le réflexe du bon concepteur produit est de creuser derrière la demande, avec la technique des 5 pourquoi empruntée au lean management : redemander « pourquoi » à chaque réponse, jusqu’à atteindre la cause réelle plutôt que le symptôme.
Un soignant qui réclame « un bouton pour exporter les constantes du patient en un clic » cache le plus souvent une contrainte organisationnelle, ou une peur de responsabilité juridique qu’il ne formule jamais spontanément sans la confiance nécessaire pour creuser. La fonctionnalité qui sort de ce travail n’a souvent plus grand-chose à voir avec la demande initiale — et c’est précisément ce qui la rend utile.
En santé, ce travail se joue avec une exigence supplémentaire : la relation de confiance qui lie un patient ou un soignant à quiconque prétend l’aider fausse naturellement le feedback recueilli, si le cadre de collecte n’est pas construit pour la neutraliser dès le départ.
Ce qu’il faut retenir
- Co-concevoir, ce n’est pas montrer un écran et attendre un hochement de tête : c’est associer les usagers assez tôt pour que leur parole compte encore.
- Faire valider une solution déjà pensée et faire participer les usagers à sa construction sont deux démarches différentes, avec des résultats très différents.
- La méthode de collecte terrain change selon la phase du projet : entretiens exploratoires, puis wireframes, focus group, prototype, et enfin MVP.
- Derrière chaque demande formulée par un usager se cache souvent un besoin différent : la technique des 5 pourquoi permet de le faire remonter.
- En santé, la relation de confiance biaise naturellement le feedback si le cadre de collecte n’est pas pensé pour ça.
Si vos retours utilisateurs vous semblent un peu trop positifs pour être vrais, c’est souvent le signe qu’il manque ce cadre. C’est exactement le sujet que je creuse avec les fondateurs que j’accompagne — prenez un Point Découverte de 30 minutes si vous voulez qu’on regarde où en est votre projet.
Ce sujet de la co-conception est aussi lié à un autre chantier que beaucoup de porteurs de projet sous-estiment : un logiciel mal co-conçu tient rarement dans un modèle économique solide. Si ce n’est pas encore clair pour vous, l’article sur les modèles économiques des startups en santé numérique complète bien celui-ci.
FAQ
Faut-il co-concevoir avec des patients, des soignants, ou les deux ?
Cela dépend du produit, mais dans la grande majorité des logiciels de santé, les deux publics ont un vécu et des contraintes différents. Un logiciel pensé uniquement avec des soignants risque de rater les usages réels des patients, et inversement.
Combien de personnes faut-il pour une co-conception sérieuse ?
Il n’y a pas de chiffre magique universel, mais la qualité prime largement sur le volume : quelques entretiens exploratoires bien menés, avec des profils volontairement variés (structures, environnements, degrés de gravité), apportent plus qu’un grand nombre d’entretiens redondants.
La co-conception retarde-t-elle le développement ?
Elle retarde le développement du mauvais produit, ce qui fait gagner du temps sur l’ensemble du projet. Un logiciel mal spécifié ne coûte pas cher à lancer ; il coûte cher à refaire une fois que l’étude clinique ou le lancement commercial a révélé le problème.
Peut-on utiliser l’IA pour co-concevoir un logiciel santé ?
Oui, notamment pour accélérer le prototypage rapide et tester plusieurs pistes de parcours en quelques jours plutôt qu’en plusieurs semaines. Cela ne remplace ni les entretiens exploratoires, ni la vigilance nécessaire quand les données recueillies touchent à l’intime ou à la maladie elle-même.
Cet article prolonge un numéro de ma newsletter Ça Se Soigne, consacrée aux mauvais réflexes produit en santé numérique. Si le sujet vous parle, abonnez-vous pour recevoir la suite.
