Written by:
Last Published:
29 octobre 2026
•
Un logiciel d'essais cliniques est toute application utilisée pour planifier, mener ou analyser un essai clinique. Pour bien le concevoir ou l'évaluer, commencez par déterminer ce qu'il contiendra : des enregistrements étayant des données d'essai ou une soumission réglementaire, ou des données personnelles. Cette réponse détermine comment il doit être validé, sécurisé, hébergé et audité, ainsi que le coût en cas d'erreur.
Ce guide s'adresse aux CTO, responsables produits et responsables technologiques au sein d'organismes de recherche sous contrat (CRO), de promoteurs et de fournisseurs de technologies de santé (HealthTech). Si vous développez, achetez ou évaluez des logiciels d'essais cliniques pour des CRO, ce guide vous aide à évaluer trois points : les questions réglementaires, le coût des erreurs et la décision de développer en interne ou d'acheter.
Notre analyse s'appuie sur un projet réel. Aurora Analytica s'est associé à nous pour créer le Geo Matrix Decision Engine, un outil de planification de scénarios d'essais cliniques qui aide les CRO à simuler des situations avant de s'engager. Nous abordons ce que disent les règles, les décisions techniques qui méritent une attention particulière et le coût d'une mauvaise orientation.
Une précision sur le périmètre. Nous ne prétendons pas que le Geo Matrix détient une quelconque certification. Nous ne décrivons pas les données que ses utilisateurs y chargent et nous ne publions pas les chiffres de performance du projet. Nous l'utilisons pour montrer où commencent les questions. Ceci ne constitue pas un conseil juridique, et votre conseiller réglementaire aura le dernier mot.
La réglementation commence là où le logiciel d'essais cliniques crée, modifie ou stocke des enregistrements qui étayent des données d'essai ou une soumission réglementaire, ou lorsqu'il traite des données personnelles. Ce champ d'application couvre tout, de la capture électronique de données à la planification de scénarios. Les outils de planification se situent souvent juste à la limite, mais pas toujours.
Imaginez une frontière douanière. Un outil peut fonctionner juste à côté toute la journée sans jamais la franchir. Chargez-le avec la mauvaise cargaison, comme des enregistrements alimentant une soumission ou des données au niveau des participants, et il se retrouve soudainement dans la file d'inspection. Le code n'a pas changé. La cargaison, si.
Nous utilisons une question pour structurer le reste de cet article, que nous appelons le « test de la cargaison ». Quelle cargaison l'outil transporte-t-il ? Comment cette cargaison entre-t-elle et sort-elle ? Et quelle documentation prouve qu'elle a été traitée correctement ?
La cargaison représente les données et les enregistrements. Les passages correspondent aux connexions, aux intégrations, aux importations et aux exportations. La documentation désigne la validation, les pistes d'audit et les justificatifs.
Aurora Analytica asked us to build the Geo Matrix Decision Engine, the first decision engine in its Aurora Suite. It lets CROs run scenarios with custom data and see the results on a world map, so they can predict outcomes virtually before real-world implementation, for example when answering requests for information and requests for proposals (RFIs and RFPs).
The wider Aurora Suite is a web application that covers areas such as trial design, country and site selection and clinical operations. Aurora Analytica developed 11 Decision Engines that perform more than 14 assessments for planning, designing and running clinical trials. The Geo Matrix was the first.
Day to day, the engine offers:
Under the hood, the front end uses Next.js, React and Redux (plus Papa Parse for CSV handling), with authentication through Auth0 by Okta. The back end runs on Nest.js and Prisma, with PostgreSQL as the database and AWS for hosting.
We worked through a minimum viable product (MVP) approach, where product owners, developers and UX/UI designers agree the core features first. Under our Managed Project Working Model, we supplied the whole team: front-end and back-end developers, designers and project managers. You can read the full story in the Aurora Analytica case study.
What does a tool like this do? It moves a costly decision earlier, to a point where changing your mind is cheap. A simulation does not replace a trial. It helps you decide which trials are worth running.
Le retard est ce qui coûte cher. Le Tufts Center for the Study of Drug Development (Tufts CSDD) estime le coût direct d'une journée de retard à environ 23 700 $ pour un essai de phase II et 55 700 $ pour une phase III, auxquels s'ajoutent environ 800 000 $ par jour en pertes potentielles de ventes sur ordonnance. Le logiciel n'est qu'un facteur parmi d'autres, mais c'est celui que vous maîtrisez.
Ces chiffres sont exprimés en dollars américains de 2023 et s'appuient sur des données de ventes pour 645 médicaments et des données budgétaires pour 447 protocoles d'essais. Considérez-les comme des points de référence, et non comme des prévisions.
Les décisions de planification ont un poids similaire. Une étude du Tufts CSDD de 2012, décrite dans Applied Clinical Trials, a porté sur près de 16 000 sites dans 151 essais mondiaux de phase II et III menés entre 2008 et 2010. Elle a révélé que 11 % des sites prêts à recruter n'ont inclus aucun patient, et que 41 % de ces sites activés n'ont pas atteint leurs objectifs de recrutement. C'est pourquoi la faisabilité des essais cliniques et la sélection des sites font l'objet d'une telle attention, et pourquoi des outils de simulation et d'analyse d'essais cliniques existent.
Pour un PDG, un directeur des opérations ou un directeur financier, notre vision de la valeur est simple. Un bon outil se rentabilise de trois manières :
Quatre décisions sont primordiales : comment les utilisateurs sont authentifiés et ce que chaque rôle peut faire, où les données sont hébergées et qui en est responsable, comment les données entrent et sortent du système, et ce que le système enregistre concernant les modifications. Chacune est peu coûteuse à concevoir au début, mais onéreuse à modifier par la suite. Les régulateurs et les clients posent des questions sur ces quatre points.
Le Geo Matrix gère l'authentification via Auth0, un fournisseur d'identité géré. L'identité est une spécialité, et peu d'équipes produit devraient la développer à partir de zéro.
La directive sur les systèmes informatisés et les données électroniques dans les essais cliniques de l'Agence européenne des médicaments (EMA) exige des contrôles garantissant que seules les personnes autorisées ont accès à un système, avec des noms d'utilisateur uniques, des comptes individuels et un accès basé sur le principe du moindre privilège. Aux États-Unis, la norme 21 CFR Part 11 définit des exigences connexes. Il s'agit de la règle de la Food and Drug Administration (FDA) sur les dossiers et signatures électroniques, figurant dans le titre 21 du Code of Federal Regulations (CFR). Elle impose de limiter l'accès au système aux personnes autorisées et exige des signatures électroniques propres à chaque individu.
Faire appel à un fournisseur géré délègue le travail, mais pas la responsabilité. La directive de l'EMA est claire à ce sujet : s'appuyer sur un prestataire de services ne transfère pas la responsabilité de l'intégrité, de la sécurité et de la confidentialité des données.
L'hébergement sur AWS est une pratique courante, et les directives de l'EMA traitent les systèmes cloud et sur site de la même manière. Les attentes sont identiques et la partie responsable doit s'assurer que le fournisseur est qualifié. Le modèle mental utile est celui du modèle de responsabilité partagée d'AWS: le fournisseur sécurise le cloud lui-même, et vous restez responsable de ce que vous y placez et de la manière dont vous le configurez.
Pour un stockage relationnel tel que PostgreSQL, ajoutez une question supplémentaire dès le départ. Quelle est la règle de conservation pour chaque type de données, et la suppression à un endroit laisse-t-elle une copie ailleurs ?
Tout flux CSV constitue en soi un passage de frontière. Pour un outil doté de fonctions d'importation et d'exportation, nous poserions ces questions lors d'une revue de conception :
(Ce sont des questions valables pour tout flux de travail CSV. Elles ne constituent pas un verdict sur la Geo Matrix.)
Une piste d'audit est l'enregistrement par le système de qui a créé, modifié ou supprimé des données, et à quel moment. C'est sur ce point que les travaux réglementés sont les moins tolérants.
ICH E6(R3), la directive sur les bonnes pratiques cliniques du Conseil international pour l'harmonisation (troisième révision), exige que les modifications apportées aux enregistrements sources soient traçables sans masquer l'entrée originale. La directive de l'EMA est plus précise : une piste d'audit doit être activée pour la création et la modification de toutes les données électroniques, et les utilisateurs normaux ne doivent pas pouvoir la désactiver. La partie 11 exige des pistes d'audit sécurisées, générées par ordinateur et horodatées, bien que les orientations de la FDA de 2003 indiquent qu'elle fera preuve de discrétion dans l'application de cette exigence et de celle relative à la validation, et recommande une évaluation des risques justifiée et documentée.
Pour un moteur de scénarios, nous considérons que la reproductibilité est la version pratique de ce principe. Si un résultat contribue à justifier une décision dans un appel d'offres, quelqu'un finira par demander quelles données d'entrée l'ont produit. Un outil capable de répondre à cette question est plus facile à valider et plus facile à acquérir.
Quatre sources font l'essentiel du travail : l'ICH E6(R3) pour les bonnes pratiques cliniques, la directive de l'EMA sur les systèmes informatisés pour les essais dans l'UE, la partie 11 du 21 CFR de la FDA pour les enregistrements et signatures électroniques, et le Règlement général sur la protection des données (RGPD) pour les données personnelles. Celles qui s'appliquent à votre logiciel dépendent de son emplacement, des enregistrements qu'il crée et de ses utilisateurs.
| Source | Ce qu'il couvre | Ce que cela implique pour les logiciels |
|---|---|---|
| ICH E6(R3) | Bonnes pratiques cliniques, y compris la gouvernance des données et les systèmes informatisés. En vigueur dans l'UE depuis le 23 juillet 2025 (principes et annexe 1). | Les systèmes doivent être adaptés à leur usage, avec une validation proportionnée au risque. Les modifications des enregistrements sources doivent être traçables, et l'accès doit être sécurisé et attribuable. |
| Directive de l'EMA sur les systèmes informatisés | Systèmes informatisés, y compris le logiciel en tant que service, utilisés pour créer ou saisir des données cliniques électroniques ou pour contrôler d'autres processus de l'essai. Applicable depuis le 9 septembre 2023. | S'applique aux promoteurs, aux investigateurs et à leurs prestataires de services. Couvre la validation, les pistes d'audit, la gestion des utilisateurs et les fournisseurs de cloud. |
| 21 CFR Part 11 | Enregistrements électroniques et signatures électroniques au titre des exigences de la FDA en matière d'enregistrement, ainsi que les enregistrements électroniques soumis à la FDA. La FDA en interprète le champ d'application de manière restrictive. | Validation, pistes d'audit sécurisées, limitation des accès et signatures électroniques uniques. |
| RGPD | Données personnelles, les données concernant la santé étant considérées comme une catégorie particulière au titre de l'article 9. | S'applique lorsque vous ou vos clients traitez des données personnelles dans son champ d'application territorial, y compris les données des participants à l'essai et, oui, les comptes de vos propres utilisateurs. |
Dans l'UE, le Règlement sur les essais cliniques est applicable depuis le 31 janvier 2022, et les essais approuvés sous l'ancienne directive devaient être mis en conformité avant le 31 janvier 2025.
Tout cela s'applique-t-il à un outil de planification ou d'aide à la décision ? Selon nous, généralement pas directement. Les documents utilisés uniquement pour la planification interne ne sont souvent pas ceux demandés par un inspecteur, bien que les décisions relatives à la faisabilité et à la sélection des sites puissent finir dans le dossier permanent de l'essai.
Cependant, vos clients sont responsables des systèmes qu'ils utilisent et vous demanderont donc de les aider à en apporter la preuve. Les questionnaires destinés aux fournisseurs reprennent le langage de ces règles, que celles-ci vous concernent formellement ou non.
Le RGPD mérite une mention particulière. Même un outil qui n'a jamais accès au dossier d'un participant traite des données personnelles : les noms d'utilisateurs, les adresses e-mail professionnelles et l'activité de connexion sont tous concernés.
Achetez lorsqu'un produit mature fait déjà le travail et que votre avantage concurrentiel réside ailleurs. Développez lorsque le flux de travail vous est spécifique, comme pour la planification de scénarios sur vos propres données, ou lorsque vous devez interconnecter plusieurs systèmes. Dans les deux cas, vérifiez comment l'outil s'intègre à vos systèmes d'essai existants et gardez la validation et la qualification des fournisseurs dans votre périmètre.
La plupart des piles technologiques pour les essais cliniques incluent quatre types de systèmes qu'il est utile de connaître :
Les logiciels de CRO pour la planification de scénarios ou l'analyse viennent généralement en complément de ces systèmes, et non en remplacement. C'est pourquoi l'intégration est la question déterminante pour savoir si l'outil est adapté. S'il peut lire ou écrire dans votre EDC ou votre CTMS, l'intégration devient un point de contrôle supplémentaire.
Lorsque vous comparez les options, qu'il s'agisse de produits commerciaux ou du développement de logiciels d'essais cliniques sur mesure, nous recommandons d'évaluer chaque solution selon six critères :
Les fournisseurs pratiquent des tarifications variées, par exemple par étude, par site, par utilisateur ou par abonnement ; demandez-leur donc une ventilation complète des coûts. Une solution sur mesure est facturée en fonction de son périmètre. Quel que soit votre choix, considérez la validation et le contrôle des changements comme faisant partie intégrante du coût, et non comme des options supplémentaires.
Si vous décidez de développer votre propre solution, commencez petit. Choisissez un flux de travail, convenez des fonctionnalités essentielles avec les futurs utilisateurs et lancez une première version, comme l'a fait le projet Aurora avec son MVP.
Avant d'écrire la moindre ligne de code, déterminez ce que le logiciel contiendra et quels enregistrements il créera. Abordez ensuite l'accès, l'hébergement, le transfert de données, l'audit et la validation, dans cet ordre. La liste ci-dessous transforme le test de charge en questions auxquelles une revue de conception peut répondre en une heure.
Il s'agit de toute application utilisée pour planifier, mener ou analyser un essai clinique. Les principaux types sont l'EDC, le CTMS, l'eTMF, l'IRT, les outils de résultats rapportés par les patients et les outils d'analyse ou d'aide à la décision tels que l'Aurora Analytica Geo Matrix. Le degré de réglementation de chacun dépend des enregistrements qu'il crée et des données qu'il contient.
Il n'existe pas de produit idéal unique. Le bon choix dépend de vos phases d'essai, de votre région, des systèmes que vous utilisez déjà et du niveau de support de validation dont vous avez besoin. Comparez les options en fonction de la conformité réglementaire, de l'intégration, du support de validation, de l'hébergement, de l'auditabilité et du coût total, en utilisant les six critères ci-dessus, et exigez des preuves de la part de chaque fournisseur, pas seulement des promesses.
Un EDC est l'outil où sont enregistrées les données cliniques. Un CTMS est l'outil utilisé pour gérer l'essai : sites, jalons, visites de monitoring et budgets. De nombreux promoteurs et CRO utilisent les deux, souvent en complément d'un eTMF pour les documents essentiels.
Cela dépend du périmètre, il n'y a donc pas de chiffre unique honnête. Cinq facteurs déterminent la majeure partie du coût : le nombre de rôles utilisateurs, le nombre d'intégrations, la profondeur de la validation, le modèle d'hébergement et le choix entre l'achat d'une licence ou le développement en interne. Prenez en compte la validation, la gestion des changements et le support dès le départ.
Commencez par définir ce que le logiciel contiendra, car cela détermine le périmètre réglementaire. Concevez l'accès, les pistes d'audit et les intégrations dès le premier jour, planifiez la validation parallèlement au développement et n'ajoutez des modules qu'une fois les bases stabilisées. La section « développer ou acheter » ci-dessus explique comment commencer petit.
S'il s'agit d'un système informatisé utilisé dans un processus d'essai réglementé, oui, et la partie responsable reste comptable même lorsqu'elle s'appuie sur la documentation du fournisseur. L'ICH E6(R3) préconise une validation adaptée à l'usage et basée sur les risques ; la profondeur de la validation dépend donc du niveau de risque. Un outil de planification de scénarios nécessite une justification documentée de sa profondeur. Un système capturant des données d'essai en nécessite davantage.
Pas automatiquement. La Part 11 couvre les enregistrements électroniques créés, modifiés ou stockés conformément aux exigences de la FDA en matière d'enregistrement, ainsi que les enregistrements électroniques soumis à la FDA. Le propre guide de la FDA sur le champ d'application et l'application de la norme indique qu'elle interprétera la Part 11 de manière restrictive et que les enregistrements électroniques non requis par les règles fondamentales de la FDA ne sont pas des enregistrements au titre de la Part 11. Un outil dont les résultats ne deviennent jamais de tels enregistrements peut ne pas être concerné. Pour les investigations cliniques, le guide de la FDA sur les questions-réponses concernant les systèmes et enregistrements électroniques daté d'octobre 2024 constitue la référence actuelle.
Si les résultats alimentent une soumission ou si l'outil est utilisé dans le cadre d'un processus réglementé, la réponse change. Confirmez ce point avec votre équipe réglementaire.
Oui. Les mêmes attentes s'appliquent que pour les systèmes sur site ; ce qui compte, c'est la preuve : un fournisseur qualifié et une répartition écrite des responsabilités. La responsabilité de l'intégrité, de la sécurité et de la confidentialité des données vous incombe.
Oui, dès lors qu'il traite des données personnelles. Les données des participants constituent le cas à haut risque, car une grande partie concerne la santé et relève d'une catégorie particulière au titre de l'article 9. Les noms, adresses e-mail et journaux de connexion de vos propres utilisateurs comptent également, de sorte que la plupart des outils sont concernés.
Un logiciel d'essai clinique se définit par son contenu, et non par son nom. Commencez par tester la cargaison : ce que l'outil transporte, comment les données entrent et sortent, et quels documents prouvent que le traitement a été effectué correctement. La Geo Matrix d'Aurora Analytica montre comment un outil de planification se rapproche des processus réglementés, et pourquoi l'identité, l'hébergement, le transfert de données et les pistes d'audit sont les premiers éléments vérifiés par les auditeurs. Les retards coûtent cher ; concevez ou achetez donc en fonction de l'adéquation, de l'intégration et de la validation, et documentez votre raisonnement, surtout lorsque la réponse est « hors périmètre ». En procédant ainsi, vous passerez beaucoup plus rapidement les contrôles.
If you are planning HealthTech software, or reviewing a product that sits close to a regulated process, we are happy to talk it through. Imaginary Cloud has been building healthcare technology since 2010, and our healthcare page lists more than 300 healthcare solutions delivered.
See how we work with healthcare teams on our healthcare technology solutions page. If your product also handles US patient data, our guide to HIPAA compliant software development covers the architecture checklist.
Ready to talk? Contact us and tell us what you are building. We will help you work out where the regulatory questions start and what a sensible first version looks like.
Alexandra Mendes est Senior Growth Specialist chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction sur le développement logiciel, l'IA et la transformation numérique. Après avoir suivi une formation en développement frontend, Alexandra a acquis des compétences pratiques en programmation et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la manière dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
People who read this post, also found these interesting:
.webp)
.webp)
