CPAM

La Caisse nationale de l’Assurance Maladie définit les politiques de gestion du risque et pilote le réseau des caisses primaires (CPAM) chargées de les mettre en œuvre sur le territoire. Elle est ainsi l’actrice centrale d’un système de soins qui repose, de plus en plus, sur des infrastructures numériques dont elle cherche à garder la maîtrise.

L’Assurance Maladie et l’open source, la dynamique

Le 1er avril 2026, la Cnam a signé avec la direction interministérielle du numérique une convention qui l’engage dans le déploiement de LaSuite, la suite collaborative open source de l’État, auprès de plus de 80 000 agentes et agents. L’accord ne se limite pas à un usage : il prévoit le développement de fonctionnalités propres aux besoins de l’Assurance Maladie, une intégration renforcée dans ses processus métiers et une contribution active à la feuille de route technique de la solution. En rejoignant le Club LaSuite, la Cnam passe du statut d’utilisatrice à celui de co-financeuse et de contributrice.

Ce n’est pas un point de départ. L’institution publie du code depuis plusieurs années. Son organisation GitHub héberge le design system de l’Assurance Maladie, diffusé sous licence MIT et toujours actif en 2026, ainsi que des briques plus spécifiques comme la validation du NIR ou des outils d’analyse statique. Le code de l’application mobile Mon espace santé, propriété de l’Assurance Maladie et du ministère de la Santé, est quant à lui publié sous licence CeCILL 2.1. Côté données, la CNAM figure parmi les productrices de référence sur data.gouv.fr et diffuse les jeux open data issus du Système national des données de santé.

On se projette, quels usages de l’open source ?

Le terme « open source » recouvre deux réalités que les organisations gagnent à distinguer, parce qu’elles n’appellent pas les mêmes réponses :

• L’open source comme solution, c’est-à-dire comme une brique applicative complète que l’on choisit, déploie et exploite. Les questions sont alors celles d’un choix d’outillage durable : qui maintient réellement le projet, et avec quelle gouvernance ? La communauté est-elle assez large pour survivre au départ de son éditeur principal ? Quel support professionnel est disponible, et à quelles conditions ? Que coûte la réversibilité si le projet s’arrête ou change de licence ? Faut-il contribuer pour peser sur la feuille de route, et à quel prix ? Ces questions ne sont pas techniques, elles sont stratégiques, et une organisation de la taille de l’Assurance Maladie les tranche pour dix ans.
• L’open source comme composant granulaire, ensuite (et c’est le cas le plus lourd à cadrer) : chaque application, y compris propriétaire, embarque des centaines ou des milliers de dépendances tierces, souvent transitives et rarement inventoriées. Les questions changent de nature : sait-on ce que l’on utilise ou distribue réellement ? Les licences des composants sont-elles compatibles entre elles, et avec le mode de mise à disposition retenu ? Quelles obligations se déclenchent au moment de la distribution, et sont-elles honorées ? Comment est organisée la veille sur les vulnérabilités, et en combien de temps une correction se propage-t-elle en production ? Ici, la réponse passe par un inventaire outillé, la nomenclature logicielle (SBOM), et par une capacité d’audit répétable plutôt que par une décision ponctuelle.

La publication du code de Mon espace santé en donne une illustration parlante : sa notice précise que la liste des bibliothèques tierces avec lesquelles l’application est compilée a été retirée avant diffusion, pour des raisons de sécurité. Le choix se défend. Il montre surtout que l’inventaire des composants est un objet à part entière, distinct du code lui-même, avec ses propres règles de production, de diffusion et de mise à jour.

À ces deux usages s’ajoute un troisième cas, celui dans lequel la Cnam est désormais engagée : publier et contribuer. Une organisation qui ouvre son code assume une responsabilité d’éditrice. Choix de licence et compatibilité avec les composants intégrés, propriété intellectuelle des développements réalisés par des prestataires, traitement des contributions reçues de l’extérieur, réponse aux signalements de vulnérabilités, engagement de maintenance vis-à-vis des personnes qui réutiliseront le code. Contribuer à un projet amont ajoute encore une couche : il faut articuler ses propres règles avec celles de la communauté d’accueil (dite upstream).

Pourquoi formaliser tout cela dans une politique

Tant que ces arbitrages se prennent au cas par cas, ils dépendent des personnes présentes ce jour-là. Ils ne sont ni reproductibles, ni transmissibles, ni auditables. Une politique Open Source sert précisément à les sortir de l’implicite. Elle tranche, une fois pour toutes et par écrit :

• qui décide, et à quel niveau, de l’intégration d’un composant ou de l’ouverture d’un code ;
• quelles licences sont autorisées, lesquelles demandent un examen, lesquelles sont exclues, et selon quel critère ;
• comment un composant entrant est qualifié, documenté et suivi tout au long de son cycle de vie ;
• quelles obligations s’appliquent au moment de la distribution, et qui en répond ;
• dans quelles conditions les équipes peuvent publier, contribuer et consacrer du temps de travail à un projet externe ;
• comment sont traités les signalements de sécurité, par qui et dans quels délais ;
• quels outils rendent tout cela vérifiable, plutôt que déclaratif ;
• etc.

L’exercice a cessé d’être facultatif. Le Cyber Resilience Act impose de documenter les composants logiciels et de signaler les vulnérabilités activement exploitées dans des délais courts. La directive NIS2 vise directement les acteurs du secteur de la santé. La refonte du régime de responsabilité du fait des produits défectueux étend désormais celui-ci aux logiciels. Dans les trois cas, ce qui est attendu n’est pas une déclaration d’intention mais une chaîne de preuves, et cette chaîne se construit en amont.

Le marché de support open source de la CNAM

En 2019, le CNLL publiait une enquête nationale sur les grands marchés de support open source des administrations. Le constat était sévère : ces marchés sont souvent inaccessibles aux PME qui détiennent l’expertise réelle sur les logiciels concernés, ils dégradent le support offert aux donneurs d’ordre, et ils ne rétribuent pas les éditeurs, donc ne financent pas l’écosystème dont ils dépendent. L’enquête recommandait deux choses : privilégier la relation directe entre les organisations clientes et les éditeurs, et favoriser des groupements à la gouvernance saine.

Open Source Experts est né de ces recommandations en juin 2024, fondé par Arawa, BlueMind, FactorFX, inno³ et Worteks. Le groupement forme un guichet unique auquel les donneurs d’ordre s’adressent pour accéder aux meilleures compétences françaises, tout en garantissant que les expertes et experts qui développent les logiciels accèdent à ces marchés et que la contribution amont soit financée. Il a par la suite remporté avec Atos le marché de support Open Source de la CNAM.

Au sein de ce groupement, inno³ est associée au marché de support open source de la Caisse nationale de l’Assurance Maladie.

Les expertises que nous y mobilisons sont celles que nous portons auprès de l’ensemble de nos clientes et clients publics :

• Gouvernance open source : construction de la politique elle-même, définition des rôles et des processus de décision, accompagnement à sa mise en œuvre.
• Transparence de la chaîne logicielle : audit de conformité des licences, production et maintien des SBOM, outillés par Hermine, notre logiciel libre de gestion de la conformité.
• Formation Open Source et cybersécurité, dont le module audit de code et SBOM, pour rendre les équipes internes autonomes.
• Études et cadrage réglementaire sur le CRA, NIS2, l’AI Act et le contrôle des exportations.
• Communs numériques : gouvernance et modèles de soutenabilité des projets ouverts mutualisés entre administrations.

Voir nos références ou réserver un échange.

Métadonnées