L'attaque ChipSoft révèle la dépendance critique des hôpitaux à un fournisseur unique. Analyse d'expert sur le risque systémique du SaaS santé et les.

Le 7 avril 2026, un seul incident cyber a désorganisé 80 % des hôpitaux des Pays-Bas. Le ransomware contre ChipSoft — éditeur du DPI Hispeed utilisé par la grande majorité des établissements hospitaliers néerlandais — a forcé la coupure du Zorgportaal, le portail patient partagé. Admissions perturbées, dossiers médicaux inaccessibles, prescriptions à la main, chirurgies reportées. Pas une guerre, pas une catastrophe naturelle : un seul point de défaillance dans une chaîne d'approvisionnement logicielle. Ce n'est pas un accident, c'est une conséquence prévisible d'une concentration que tout le monde voyait venir et que personne n'a voulu casser parce que la mutualisation était trop confortable économiquement. Et la France n'a pas grand-chose à envier à ce modèle. Ce qui s'est passé à Amsterdam aurait pu se passer à Lille, Lyon ou Bordeaux. La seule variable, c'est le temps qui nous sépare du prochain incident de cette ampleur, et notre niveau de préparation collective ce jour-là.

CYBERSÉCURITÉ GÉNÉRALE Quand un éditeur paralyse 80% des hôpitaux : le risque ÉTAPES / CONTRÔLES 1 La concentration des DPI : un choix… 2 L'incident ChipSoft : autopsie d'un risque… 3 La fausse promesse du SaaS santé … 4 Trois défaillances organisationnelles qui… 5 Ce que les RSSI hospitaliers doivent faire… EXIGENCES CLÉS Défaillance 1 — L'absence de… ayinedjimi-consultants.fr

La concentration des DPI : un choix collectif aux conséquences systémiques

Quand un fournisseur de dossier patient informatisé équipe 80 % des hôpitaux d'un pays, ce n'est pas du hasard. C'est le résultat d'une décennie d'appels d'offres convergents, de migrations qui se ressemblent, et d'une logique d'efficience où la mutualisation prime systématiquement sur la résilience. Le calcul économique est froid mais compréhensible : un seul éditeur, c'est une seule équipe à former, un seul jeu d'API à maintenir, un seul interlocuteur en cas de problème fonctionnel. Sur le papier, c'est rationnel. Dans la réalité opérationnelle, ça crée un point de défaillance nationale que la cybersécurité ne peut pas neutraliser à elle seule.

En France, la situation est plus fragmentée mais le problème structurel est identique. Maincare, Dedalus, Softway Medical et quelques autres se partagent l'écrasante majorité des CHU et des CH. Dedalus seul gère les dossiers médicaux de plusieurs millions de patients français — sa compromission en 2021, qui avait exposé les données de santé de 500 000 patients de 12 laboratoires d'analyses français, avait déjà illustré ce risque de concentration. Une attaque ciblée sur l'un de ces grands éditeurs ne paralyserait peut-être pas 80 % du pays d'un coup, mais 30 % suffit déjà pour faire trembler la chaîne de soins nationale.

Le secteur pharmaceutique présente un risque similaire. Les grossistes répartiteurs — quelques acteurs qui distribuent 100 % des médicaments dans les pharmacies françaises — sont des points de concentration évidents. Une perturbation de leur SI suffit à créer des ruptures d'approvisionnement pour des médicaments critiques dans les 48 heures. Là encore, la concentration a été optimisée pour l'efficience logistique, pas pour la résilience cyber.

L'incident ChipSoft : autopsie d'un risque systémique déclenché

ChipSoft est le leader incontesté des systèmes d'information hospitaliers aux Pays-Bas. Hispeed, son DPI principal, équipe la majorité des hôpitaux généraux et universitaires du pays. Le Zorgportaal, sa plateforme de partage de données entre établissements, est l'infrastructure de communication du système de santé néerlandais.

Retour terrain

Dans mes missions d'audit, je rencontre régulièrement la même configuration à risque : des règles de firewall héritées depuis 5 à 10 ans, que personne n'ose supprimer par crainte de casser quelque chose. J'ai développé une méthode de nettoyage progressive — analyser les logs de connexion sur 90 jours, identifier les règles sans trafic, les désactiver sans supprimer pendant 30 jours, puis valider avec les équipes métier. Sur un parc de 340 règles dans un groupe logistique, nous en avons supprimé 218 sans incident.

L'attaque du 7 avril 2026 a suivi un schéma classique de ransomware sophistiqué : intrusion probablement via un prestataire tiers ou une vulnérabilité non patchée, latéralisation dans le réseau de ChipSoft pendant plusieurs semaines, exfiltration de données avant déclenchement du chiffrement. ChipSoft a pris la décision — correcte du point de vue de la containment — de couper le Zorgportaal pour éviter la propagation via les connexions inter-hospitalières. Résultat : des dizaines d'hôpitaux simultanément privés de leur DPI principal, sans accès aux antécédents médicaux des patients, aux prescriptions en cours, aux résultats d'examens récents.

La résilience opérationnelle des établissements touchés a varié considérablement. Ceux qui avaient testé récemment leur procédure de mode dégradé (paper-based, fonctionnement local uniquement) s'en sont sortis avec des perturbations sérieuses mais gérables. Ceux qui n'avaient jamais réellement pratiqué le mode dégradé ont connu des situations chaotiques — personnel soignant sans aucune information sur les patients admis, décisions cliniques prises à l'aveugle sur des cas critiques.

La fausse promesse du SaaS santé : souveraineté transférée sans filet

Le glissement vers le SaaS hospitalier — portails patients hébergés, modules cloud, échanges via des plateformes centralisées — a été vendu comme une modernisation. C'en est une, sur le plan fonctionnel. Sur le plan de la résilience, c'est aussi un transfert de souveraineté opérationnelle que peu d'établissements ont mesuré avant de signer.

L'établissement ne maîtrise plus ni la disponibilité de son outil principal ni la confidentialité de ses propres données. ChipSoft a coupé le Zorgportaal en quelques heures pour contenir l'attaque. Les hôpitaux clients n'ont pas eu leur mot à dire. Ils ont découvert en même temps que leurs utilisateurs que le portail était inaccessible. C'est le modèle SaaS tel qu'il fonctionne réellement en situation de crise : l'éditeur prend les décisions, le client subit les conséquences.

Et là où ça fait mal vraiment, c'est dans les contrats. Les contrats fournisseurs en santé n'imposent que rarement des SLA cyber sérieux : pas d'obligation de notification dans des délais courts (24 heures devrait être le standard, 72 heures est souvent considéré comme acceptable), pas de droits d'audit de sécurité technique, pas d'engagement contractuel sur les modes dégradés, pas de clause de réversibilité facilitant la migration vers un autre éditeur en cas de défaillance. Le client paye, le fournisseur opère, et en cas de crise, le client encaisse — en espérant que son fournisseur agisse dans l'intérêt de ses clients plutôt que dans l'intérêt de sa réputation commerciale.

Trois défaillances organisationnelles qui aggravent le risque

Au-delà de la concentration des fournisseurs, trois défaillances organisationnelles récurrentes amplifient le risque dans les établissements hospitaliers français.

Défaillance 1 — L'absence de cartographie précise des dépendances. La plupart des établissements que j'audite ne savent pas précisément ce qui "tombe" si leur DPI tombe. Ils savent que c'est critique. Ils ne savent pas exactement quels processus cliniques sont bloqués, quels processus peuvent fonctionner en mode dégradé, et lesquels doivent être réorientés vers d'autres établissements. Cette cartographie doit être exhaustive et tenue à jour — non pas dans un PowerPoint de présentation de direction, mais dans un document opérationnel testé trimestriellement.

Défaillance 2 — Le mode dégradé existe sur papier, pas dans les têtes. Le mode dégradé — fonctionnement paper-based, accès aux dernières données synchronisées localement, communication inter-services par moyens alternatifs — est souvent décrit dans un plan de continuité d'activité. Ce plan a souvent été écrit il y a cinq ans, lors d'une certification, et n'a jamais été réellement exercé. Le personnel soignant recruté depuis n'a jamais été formé à ces procédures. Au moment de la crise, personne ne sait où sont les formulaires papier, qui a les accès aux sauvegardes locales, ou quel médecin est référent pour les décisions en situation dégradée.

Défaillance 3 — La sécurité de l'éditeur est supposée, jamais vérifiée. Quand un RSSI hospitalier me montre son contrat avec son éditeur DPI, la section "sécurité" est invariablement soit absente soit remplie de formulations vagues — "l'éditeur s'engage à maintenir un niveau de sécurité approprié". Aucun droit d'audit, aucune obligation de divulguer les incidents de sécurité dans un délai défini, aucune certification exigée. L'éditeur est traité comme un partenaire de confiance par défaut, jamais comme un fournisseur critique dont la posture de sécurité mérite une vérification indépendante.

Ce que les RSSI hospitaliers doivent faire maintenant

Première chose : arrêter de considérer la dépendance fournisseur comme un sujet d'achat et la traiter comme un risque cyber de premier rang. Cartographier précisément ce qui tombe si l'éditeur DPI tombe : dossier patient, portail de partage inter-établissements, mobilité soignants, échanges avec le laboratoire, prescription connectée, résultats d'imagerie. Pour chaque brique, écrire le mode dégradé — pas en théorie, mais en protocole opérationnel avec les ressources nécessaires identifiées et disponibles.

Deuxième chose : exiger contractuellement le droit d'auditer la posture de sécurité du fournisseur. Pas un questionnaire de 200 lignes une fois par an — un vrai audit technique avec accès aux logs, aux configurations réseau et aux résultats des derniers tests d'intrusion. Si le fournisseur refuse catégoriquement tout audit, c'est une donnée à intégrer dans le risque résiduel et à remonter au directeur de l'établissement et au COMEX.

Troisième chose : documenter et tester la procédure de bascule en mode local. La plupart des DPI conservent une capacité de fonctionnement isolée avec des données synchronisées localement. Cette bascule n'est jamais répétée en conditions réelles. Un exercice par an — simuler la perte du DPI central et mesurer le temps de bascule en mode local — révèle systématiquement des lacunes qu'aucun plan théorique ne capture.

Quatrième chose : travailler avec les autorités de tutelle sur la diversification. Un établissement hospitalier ne peut pas seul rompre sa dépendance à un éditeur dominant. Mais les ARS, le ministère de la Santé et l'ANSSI peuvent inciter à la diversification via les appels d'offres, les certifications, et les exigences de portabilité des données. Cette démarche collective est nécessaire pour traiter le risque systémique à sa racine.

Position d'expert — Ayi NEDJIMI

Le SaaS santé, tel qu'il est vendu et tel qu'il est acheté aujourd'hui, est une bombe à retardement. Pas parce que le SaaS est mauvais — c'est un modèle techniquement et économiquement pertinent. Mais parce qu'on l'a déployé sans poser les garde-fous contractuels et opérationnels qui vont avec. Les établissements hospitaliers ont externalisé leur souveraineté opérationnelle sans mesurer ce que ça signifie en cas de défaillance de l'éditeur.

La question que tout RSSI hospitalier devrait pouvoir répondre en cinq minutes : "Si votre éditeur DPI tombe demain matin à 6h, vous tenez combien de temps, dans quelles conditions, et quel est le premier soin que vous ne pouvez plus assurer ?" Si la réponse prend plus de cinq minutes, ou si elle est vague, ou si elle dit "on trouvera bien", l'incident ChipSoft se reproduira chez vous. Probablement avec des conséquences cliniques, pas seulement organisationnelles.

Et je vais être direct sur un point que les discussions polies évitent généralement : les éditeurs de DPI n'ont pas d'intérêt économique immédiat à permettre à leurs clients de fonctionner longtemps sans eux. La réversibilité et le mode dégradé robuste réduisent leur pouvoir de négociation. C'est pourquoi ces questions doivent être réglées contractuellement avant la signature, pas négociées en urgence le jour de l'incident.

Conclusion

La cybersécurité hospitalière ne se joue plus seulement dans les SOC et les pare-feu. Elle se joue dans les contrats, dans la diversification des fournisseurs, et dans la capacité à fonctionner en mode dégradé pendant le temps nécessaire à la remédiation. ChipSoft est un avertissement pour toute l'Europe de santé numérique. L'incident n'est pas une question de "si" il se reproduira mais de "où" et avec quel niveau de préparation.

Les établissements qui se préparent maintenant — exercices de mode dégradé, clauses contractuelles de sécurité, cartographie des dépendances — seront ceux qui traverseront la prochaine crise sans mettre en danger leurs patients. Les autres feront comme toujours : improviser dans l'urgence, constater les dégâts, et promettre de s'y préparer mieux la prochaine fois.

À retenir

  • • ChipSoft a paralysé 80 % des hôpitaux néerlandais via un seul point de défaillance — le risque systémique de concentration DPI existe en France avec Maincare, Dedalus, Softway Medical.
  • • Le SaaS hospitalier transfère la souveraineté opérationnelle à l'éditeur sans garanties contractuelles adéquates dans la plupart des contrats.
  • • Trois défaillances récurrentes : absence de cartographie précise des dépendances, mode dégradé jamais testé en conditions réelles, posture de sécurité de l'éditeur supposée jamais vérifiée.
  • • Le droit d'audit de la sécurité du fournisseur DPI est un prérequis contractuel non négociable — si l'éditeur refuse, c'est un signal d'alarme à remonter à la direction.
  • • Un exercice de mode dégradé par an — simuler la perte totale du DPI et mesurer la résilience réelle — est la mesure la plus impactante à déployer immédiatement.

Pour aller plus loin : Extorsion SaaS : vos intégrations tierces, vecteur numéro un · SaaS-mageddon : vos fournisseurs deviennent votre maillon faible · La santé, cible parfaite en 2026

Besoin d'un regard expert sur votre exposition fournisseurs ?

Cartographie des dépendances, clauses contractuelles de sécurité, exercices de mode dégradé : discutons de la réalité de votre résilience hospitalière.

Prendre contact

Environnement de test et laboratoire pratique

La maîtrise des techniques de sécurité offensive et défensive requiert un environnement de pratique dédié. L'installation d'un laboratoire virtuel sur votre poste (VMware Workstation, VirtualBox, ou Proxmox pour une infrastructure plus élaborée) permet de tester les concepts présentés dans cet article sans risque pour les systèmes de production.

Configuration recommandée du lab

Pour reproduire les scénarios décrits, une configuration minimale comprend : un hyperviseur disposant d'au moins 16 Go de RAM et 4 cœurs CPU, un réseau virtuel isolé (host-only ou internal network sans accès Internet pour les VMs malveillantes), et un snapshot de base avant chaque manipulation pour faciliter le retour arrière. Les distributions spécialisées Kali Linux (offensive) et Parrot OS Security Edition couvrent l'ensemble des outils nécessaires sans configuration manuelle. Pour l'aspect défensif, Security Onion déploie en une seule VM un stack complet (Zeek, Suricata, Elasticsearch, Kibana) qui permet de visualiser l'impact des techniques testées.

Ressources de formation complémentaires

Les plateformes d'entraînement permettent de consolider la pratique dans des environnements légaux et structurés. HackTheBox et TryHackMe proposent des machines virtuelles sur lesquelles appliquer les techniques décrites, avec des difficultés progressives adaptées aux débutants comme aux experts. Pour les scénarios d'entreprise (Active Directory, Cloud, applications web complexes), les labs Pro de HackTheBox ou les modules DFIR/SOC de Blue Team Labs Online offrent des cas réalistes. Les CTF compétitifs (Hack The Box CTF, DEFCON CTF, PicoCTF) développent la créativité et l'adaptabilité face à des challenges inédits. La régularité de pratique (1-2 heures hebdomadaires minimum) prime sur l'intensité ponctuelle pour développer des réflexes durables.

Indicateurs de maturité et métriques de sécurité

Mesurer l'efficacité des mesures de sécurité implémentées est indispensable pour justifier les investissements et guider les priorités. Les métriques suivantes constituent un tableau de bord de sécurité applicable aux organisations de toutes tailles.

Métriques de couverture et de détection

Les indicateurs clés à suivre mensuellement : taux de couverture MITRE ATT&CK (pourcentage des techniques adversariales couvertes par des règles de détection actives) ; Mean Time To Detect (MTTD) pour les incidents de sécurité confirmés ; Mean Time To Respond (MTTR) depuis l'alerte jusqu'à la résolution ; taux de faux positifs sur les alertes SIEM (objectif : moins de 5% pour les règles de haute priorité) ; pourcentage de systèmes avec agents EDR installés et actifs (objectif : 100% des endpoints gérés). Ces métriques, compilées dans un rapport mensuel pour la direction, permettent de démontrer la valeur des investissements sécurité et d'identifier les domaines nécessitant des ressources supplémentaires.

Amélioration continue par les exercices

Les organisations les plus matures en matière de cybersécurité organisent régulièrement des exercices pour tester et améliorer leurs capacités. Les exercices tabletop (simulation de crise sur table, sans activation des systèmes techniques) développent la coordination des équipes et valident les procédures de communication de crise. Les tests de pénétration (pentest) annuels fournissent une évaluation objective de la résistance technique de l'infrastructure. Les exercices Red/Blue/Purple Team (1-2 fois par an pour les organisations matures) permettent d'aligner les équipes offensive et défensive autour d'objectifs communs d'amélioration. Chaque exercice doit donner lieu à un plan d'action formalisé avec des jalons de correction mesurables, intégré dans la feuille de route sécurité de l'organisation.

Bonnes pratiques et recommandations complémentaires

Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.

Veille et mise à jour continue

La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).

Documentation et partage de connaissances

La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.

Checklist de mise en œuvre et points de contrôle

La mise en pratique des recommandations de cet article nécessite une approche structurée. Cette checklist synthétise les points de contrôle essentiels pour évaluer l'état d'avancement de votre déploiement et identifier les actions prioritaires.

Phase de préparation et d'inventaire

Avant toute action technique, constituer un inventaire précis est indispensable. Les éléments à recenser : cartographie exhaustive des actifs concernés (systèmes, applications, flux de données) avec leur criticité métier associée ; identification des propriétaires techniques et fonctionnels pour chaque actif ; évaluation du niveau de maturité actuel à partir des référentiels reconnus (CIS Controls, ISO 27001, NIST CSF) ; et documentation des dépendances entre composants pour anticiper les impacts des modifications. Un inventaire incomplet génère des angles morts qui deviennent des vecteurs d'attaque exploitables par des acteurs malveillants disposant d'informations accessibles publiquement (OSINT, Shodan, LinkedIn).

Phase de déploiement et validation

Le déploiement progressif réduit les risques d'interruption de service et facilite la détection des régressions. Adopter un modèle de déploiement par vagues (wave deployment) : d'abord les environnements de développement et de test pour valider les configurations, ensuite les systèmes non-critiques en production, enfin les systèmes critiques lors de fenêtres de maintenance planifiées. Chaque vague s'accompagne d'une validation fonctionnelle complète et d'une période d'observation des métriques de performance et de sécurité. Un plan de retour arrière documenté et testé est obligatoire avant toute opération sur un système critique. Les critères de succès doivent être définis avant le déploiement, non après — un taux de faux positifs inférieur à 5% pour les alertes de sécurité, une disponibilité maintenue au niveau SLA contractuel, et l'absence d'incidents de sécurité liés aux modifications.

Phase de supervision et d'amélioration continue

La mise en place d'indicateurs de suivi permet de mesurer l'efficacité des mesures déployées et de justifier leur maintien auprès de la direction. Tableau de bord mensuel recommandé : nombre d'alertes générées par catégorie (critique, majeur, mineur) avec tendance sur 6 mois ; taux de couverture des actifs critiques par les contrôles de sécurité ; délai moyen de remédiation des vulnérabilités par sévérité CVSS ; et résultats des tests de régression mensuels sur les règles de détection. Ce tableau de bord, présenté en comité de sécurité, constitue la base d'un dialogue constructif entre les équipes techniques et le management sur les priorités d'investissement en cybersécurité.