Le développement assisté est-il plus encadré en santé ou en finance ?

Introduction

La santé et les services financiers concentrent les exigences les plus élevées en matière de maîtrise du développement logiciel. L’usage d’outils génératifs y appelle une organisation renforcée.

Le secteur de la santé

Un logiciel destiné par son fabricant à être utilisé à une finalité médicale relève de la réglementation des dispositifs médicaux.

Sont notamment visées les finalités de diagnostic, de prévention, de contrôle, de prédiction, de pronostic, de traitement ou d’atténuation d’une maladie.

Cette qualification emporte des conséquences substantielles.

Une procédure d’évaluation de la conformité, dont l’intensité dépend de la classe du dispositif.

Un système de gestion de la qualité documenté.

Une documentation technique complète, incluant le cycle de vie du logiciel.

Une gestion des risques, révisée tout au long du cycle de vie.

Une surveillance après commercialisation.

Les exigences relatives au cycle de vie

Elles sont le point d’attention pour un développement assisté.

Le processus de développement doit être défini et documenté.

Les exigences doivent être tracées jusqu’aux tests et à la validation.

Les revues doivent être formalisées et enregistrées.

La gestion des changements doit comporter une analyse d’impact et une revalidation.

Les composants tiers doivent être identifiés, évalués et suivis.

Aucune de ces exigences n’interdit un outil : toutes imposent une traçabilité incompatible avec un usage non encadré.

Les données de santé

Elles relèvent des catégories particulières de données, dont le traitement est interdit par principe, sauf exception.

Leur soumission à un outil externe est donc à proscrire, y compris dans des jeux de test.

L’hébergement de données de santé pour le compte de tiers suppose en outre une certification de l’hébergeur.

Ce point conditionne le choix des outils et des environnements de développement.

Le règlement européen sur l’intelligence artificielle

Certains systèmes destinés à la santé relèvent des domaines à haut risque, notamment lorsqu’ils constituent des composants de sécurité de dispositifs réglementés.

Ils sont alors soumis aux obligations correspondantes : gestion des risques, gouvernance des données, documentation, journalisation, transparence, contrôle humain, exactitude et robustesse.

Ces obligations se cumulent avec celles de la réglementation des dispositifs.

Le secteur financier

Il n’impose pas une réglementation du logiciel comparable à celle des dispositifs médicaux.

Il impose en revanche une maîtrise des risques opérationnels et informatiques.

Gouvernance des systèmes d’information, avec des responsabilités identifiées.

Gestion des changements, avec autorisation, test et traçabilité.

Gestion des incidents, avec des obligations de signalement.

Maîtrise des prestataires et des dépendances critiques, avec des exigences contractuelles renforcées.

Tests de résilience.

Ces exigences s’appliquent au développement interne comme aux prestations externalisées.

Les conséquences pour un prestataire

Un éditeur servant ces secteurs subit les exigences de ses clients.

Questionnaires détaillés sur les méthodes de développement.

Droits d’audit sur le processus.

Engagements contractuels de conformité.

Obligation d’information préalable en cas de changement significatif de méthode.

Restrictions sur le recours à des outils externes, parfois assorties d’une interdiction.

Ces exigences se répercutent en cascade jusqu’aux sous-traitants.

Les systèmes d’IA en accès aux services essentiels

Le règlement européen sur l’intelligence artificielle vise notamment les systèmes utilisés pour évaluer la solvabilité ou établir un score de crédit, ainsi que ceux utilisés pour l’évaluation des risques et la tarification en matière d’assurance vie et santé.

Ces systèmes relèvent des domaines à haut risque, avec les obligations correspondantes.

Un éditeur développant de tels systèmes doit conduire cette qualification avant toute mise sur le marché.

La démarche recommandée

Qualifier le produit au regard des réglementations sectorielles avant le développement.

Formaliser le processus conformément aux exigences applicables.

Adopter une politique d’usage des outils cohérente avec ces exigences : outils validés, revue formalisée, traçabilité, interdiction des données réelles.

Documenter l’ensemble, ces réglementations reposant sur la démonstration.

Anticiper les exigences contractuelles des clients, souvent plus strictes.

Qualifier avant de développer

Un produit qualifié après coup se régularise difficilement. Notre expertise en droit du numérique conduit ces qualifications.

En résumé

• Un logiciel à finalité médicale relève de la réglementation des dispositifs médicaux.
• Les exigences de cycle de vie imposent traçabilité, revue formalisée et gestion des changements.
• Les données de santé ne doivent pas être soumises à un outil externe, jeux de test compris.
• Le secteur financier impose une maîtrise des risques opérationnels couvrant le développement.
• Les exigences contractuelles des clients se répercutent en cascade jusqu’aux sous-traitants.