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.

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