Comp AI : la conformité-as-code open source à l'épreuve du dispositif médical

« SOC 2 en quelques semaines. » C’est la promesse des plateformes de conformité automatisée, et Comp AI en propose une version open source. L’idée est séduisante pour un éditeur médical qui doit rassurer ses clients hospitaliers sans y noyer son équipe : traiter la conformité comme du code, collecté et vérifié en continu. Voici ce que cette automatisation fait vraiment gagner à un SaaS médical — et pourquoi le dossier MDR est précisément la partie qu’elle ne peut pas absorber.

Qu’est-ce que la « conformité-as-code » et que promet un outil comme Comp AI ?

Définition : la conformité-as-code consiste à traiter les contrôles, les politiques et les preuves comme du code — versionnés, collectés automatiquement depuis vos systèmes et re-vérifiés en continu, plutôt que ressaisis à la main dans un tableur avant chaque audit. Comp AI (dépôt trycompai/comp) en est une implémentation open source ; d’après son dépôt, il automatise la collecte de preuves, la gestion des politiques et la mise en œuvre des contrôles pour SOC 2, ISO 27001, HIPAA et RGPD.

Il est publié sous licence AGPLv3, sur un modèle open-core, disponible en auto-hébergement ou en cloud managé sur trycomp.ai. Techniquement, c’est du Next.js avec Trigger.dev pour les tâches de fond et Prisma pour la donnée. Un point à connaître avant de forker : l’AGPLv3 impose de publier le code source de toute version modifiée que vous exposez sur un réseau — neutre pour un usage interne, structurant si vous en faites un service pour des tiers.

SOC 2, ISO 27001 : une porte commerciale, pas une autorisation de mise sur le marché

C’est la distinction que je martèle à chaque fondateur médtech qui me parle de SOC 2. SOC 2 n’est pas une certification : c’est une attestation produite par un cabinet d’audit (CPA) au regard des Trust Services Criteria de l’AICPA — Type I sur la conception des contrôles à un instant donné, Type II sur leur efficacité dans la durée. ISO 27001, elle, est bien une certification de SMSI. Les deux prouvent une chose : que vous tenez votre sécurité de l’information.

Ce que ni l’une ni l’autre ne fait, c’est vous autoriser à mettre un dispositif médical sur le marché. Ça, c’est le marquage CE au titre du MDR, ou l’autorisation de la FDA. La confusion est fréquente parce que les deux mondes parlent de « conformité » — mais ils ne répondent pas à la même question.

Autrement dit : SOC 2 vous fait signer des clients, le marquage CE vous donne le droit d’exister sur le marché. Un outil comme Comp AI accélère le premier. Il ne touche pas au second.

Ce que l’automatisation fait vraiment gagner : la preuve continue plutôt que l’audit ponctuel

Le gain réel n’est pas cosmétique. Sans automatisation, un audit SOC 2 ou ISO 27001 se prépare dans la douleur : on reconstitue à la main des mois de preuves — accès, revues, sauvegardes, correctifs — juste avant le passage de l’auditeur. La conformité-as-code inverse la logique : les preuves sont collectées en continu depuis vos systèmes, l’écart à la cible est visible en permanence, et l’audit devient une photo d’un état déjà tenu.

Mon retour d’expérience : c’est là que ces outils méritent leur place — ils suppriment le sprint documentaire et rendent l’état de conformité observable au quotidien. Mais gardez la frontière nette : l’automatisation collecte et trace la preuve, elle ne remplace pas l’analyse. Un contrôle coché parce qu’un script l’a vu passer n’est pas un contrôle jugé pertinent.

HIPAA, RGPD : le volet données de santé qu’elle adresse

Comp AI référence aussi HIPAA et RGPD, les deux cadres de protection des données de santé. Attention au périmètre : HIPAA est une loi américaine (supervisée par le Department of Health & Human Services), qui encadre les Protected Health Information des covered entities et de leurs sous-traitants. Un éditeur européen n’y est pas soumis par défaut — elle ne devient un sujet que s’il sert le marché américain de la santé. Le RGPD, lui, s’applique dès que vous traitez des données de personnes dans l’UE. Sur ces deux cadres, l’outil aide à structurer les preuves, quel que soit par ailleurs le statut « dispositif médical » du logiciel.

Ce qu’elle n’automatisera pas : le dossier IEC 62304 / MDR

Voici la limite, et elle est nette. Un pipeline peut générer une partie des artefacts d’un logiciel médical : traçabilité, rapports de tests, journaux de release alimentent le dossier IEC 62304 — c’est même la bonne pratique, développée dans automatiser 80 % de sa doc IEC 62304. Mais un outil de collecte de preuves de sécurité SI ne connaît pas votre logiciel médical. Il ne produira ni votre architecture au sens de l’IEC 62304:2006+A1:2015, ni votre dossier de gestion des risques ISO 14971:2019, ni votre évaluation clinique, ni la documentation technique MDR des annexes II et III.

Et il reste la part irréductible : le jugement. La classification d’un logiciel, l’analyse de ses risques cliniques, l’appréciation du pire scénario raisonnablement prévisible — rien de tout cela ne se scrape depuis un système. Le recouvrement utile se situe sur la cybersécurité, où structurer ses preuves sert aussi l’IEC 81001-5-1. Le reste du dossier se construit, il ne se collecte pas.

La conformité-as-code collecte la preuve ; elle ne produit pas le jugement. Un dossier médical se juge, il ne se scrape pas.

Comp AI ou une suite GRC comme Unicis ?

Les deux sont open source et s’arrêtent à la même frontière MDR ; ils ne visent simplement pas le même goulot. Comp AI est automation-first : sa force est la vélocité SOC 2 et la preuve continue, pour un SaaS dont le blocage est commercial. Une suite comme Unicis Platform CE est governance-first : registre des risques, RoPA, contrôles, à poser chez soi quand l’enjeu est de posséder sa gouvernance SI. Choisissez par votre goulot du moment : fermer un SOC 2 pour vendre, ou tenir votre SMSI en interne. Dans les deux cas, le dossier dispositif médical reste un chantier distinct.

FAQ

Comp AI permet-il d’obtenir le marquage CE d’un logiciel médical ?

Non. Il adresse SOC 2, ISO 27001, HIPAA et RGPD — la sécurité de l’information et les données personnelles. Le marquage CE repose sur le MDR, l’IEC 62304 et l’ISO 14971, hors de son périmètre. Les deux démarches sont utiles, elles ne se remplacent pas.

SOC 2 est-il obligatoire pour vendre un logiciel médical ?

Non, ce n’est pas une obligation réglementaire. C’est une exigence d’achat fréquente, réclamée par les DSI hospitalières et les grands comptes dans leur processus de sélection. Utile commercialement, sans rapport avec l’autorisation de mise sur le marché.

La licence AGPLv3 pose-t-elle un problème ?

Elle impose de publier le code source de toute version modifiée que vous exposez sur un réseau. Pour un usage interne standard, c’est neutre ; si vous forkez l’outil pour en faire un service ouvert à des tiers, pesez cette obligation au regard de l’offre commerciale du projet.

Un SOC 2 à ouvrir, un dossier MDR à cadrer en parallèle ? Réservez un appel — on sépare ce qui accélère la vente de ce qui conditionne la mise sur le marché.