Après Solimut, ce que tout DSI européen doit faire avant la prochaine attaque

# Après Solimut, ce que tout DSI européen doit faire avant la prochaine attaque

Solimut Mutuelle a été frappée. Des données de santé — parmi les plus sensibles qui soient — ont été compromises. Ce qui aurait dû rester une affaire interne est devenu, le temps d'une attaque, un problème de souveraineté nationale. Car derrière chaque incident de ce type se cache une même question que trop peu de DSI se posent en amont : où mes données étaient-elles réellement stockées, traitées, sauvegardées — et sous quelle juridiction ?

En 2026, la réponse est souvent inconfortable. La majorité des PME et ETI européennes du secteur mutualiste, médical ou assurantiel ont leur SI partiellement ou totalement posé sur des infrastructures opérées par des acteurs soumis au droit américain. Le Cloud Act n'a pas disparu. Les clauses contractuelles de sous-traitance restent opaques. Et les garanties de réversibilité, inexistantes dans les faits.

Ce guide n'est pas une autopsie de Solimut. C'est un plan d'action pour ne pas être le prochain.

Étape 1 — Cartographiez votre exposition réelle, pas votre exposition supposée

La première erreur des DSI face à ce type d'incident : croire qu'ils savent où sont leurs données parce qu'ils ont signé un contrat avec un prestataire européen. Ce prestataire, lui, a peut-être externalisé ses sauvegardes, son monitoring ou sa couche d'authentification à un acteur américain.

Ce que vous devez faire concrètement :

• Exigez de chaque prestataire IT actif un registre de sous-traitants à jour, avec la nationalité juridique de chaque entité impliquée dans le traitement ou le stockage de vos données.
• Identifiez les briques de votre SI soumises à une juridiction extra-européenne : messagerie, CRM, outils collaboratifs, sauvegardes cloud, outils de monitoring, solutions de visioconférence.
• Classez vos données par niveau de sensibilité réglementaire (données de santé, données RH, données financières) et croisez cette classification avec la localisation effective des traitements.

Ce travail est pénible. Il révèle souvent qu'une proportion significative de vos flux passe par des infrastructures que vous ne contrôlez pas. C'est précisément le point de départ.

Étape 2 — Lisez vos contrats cloud comme un avocat, pas comme un client

Les verrouillages ne sont pas que techniques. Ils sont avant tout contractuels. Et c'est là que la dépendance s'installe durablement, bien avant qu'une cyberattaque ne révèle le problème.

Ce que vous devez faire concrètement :

• Localisez dans chaque contrat cloud actif la clause de loi applicable et de juridiction compétente. Si c'est le droit de l'État du Delaware ou de Californie, vous n'êtes pas sous droit européen, quelle que soit la localisation physique des serveurs.
• Vérifiez l'existence — et la praticabilité — d'une clause de réversibilité : dans quel format vos données vous sont restituées, dans quel délai, à quel coût réel. Les formats propriétaires sont un verrou technique autant qu'un verrou commercial.
• Identifiez les clauses d'audit : avez-vous contractuellement le droit de vérifier où et comment vos données sont traitées ? Beaucoup de contrats avec des acteurs dominants ne l'autorisent pas, ou l'autorisent sous des conditions qui le rendent impraticable.
• Notez les clauses de modification unilatérale des conditions : certains acteurs se réservent le droit de modifier les termes du contrat avec un préavis court. Vous êtes captif si vous ne pouvez pas migrer rapidement.

Si votre DSI ne peut pas répondre à ces quatre points pour chacun de ses prestataires critiques, vous avez un angle mort de risque, pas seulement de conformité.

Étape 3 — Évaluez votre capacité réelle à sortir, aujourd'hui

La souveraineté numérique n'est pas un état, c'est une capacité opérationnelle. Pouvez-vous, en cas d'incident, de rupture contractuelle ou de décision politique unilatérale d'un acteur américain, basculer vers une alternative en un délai acceptable pour votre activité ?

Ce que vous devez faire concrètement :

• Définissez votre RTO de souveraineté : combien de temps pouvez-vous fonctionner si l'accès à votre principale brique cloud américaine est coupé, suspendu ou compromis ?
• Testez la réversibilité réellement : tentez une extraction partielle de vos données depuis votre outil le plus critique. Mesurez le temps, le coût, la complétude des données récupérées.
• Identifiez les dépendances en cascade : souvent, la dépendance à un acteur dominant en entraîne d'autres. Votre solution de SSO est liée à votre annuaire, lui-même lié à votre messagerie. Migrer l'un sans l'autre est impossible.

Cet exercice est inconfortable parce qu'il révèle souvent que la réponse honnête est : non, nous ne pouvons pas sortir facilement. C'est une information stratégique, pas un aveu d'échec.

Étape 4 — Priorisez le rapatriement par la valeur des données, pas par la facilité technique

Face à des ressources limitées, la tentation est de commencer par ce qui est simple à migrer. C'est souvent une erreur. La priorité doit être dictée par la valeur réglementaire et stratégique des données, pas par la facilité technique de la migration.

Ce que vous devez faire concrètement :

• Données de santé, données RH, données de clients sensibles : traitement prioritaire. Ce sont les données dont la compromission ou l'accès par une juridiction étrangère a les conséquences les plus lourdes — réglementaires, réputationnelles, opérationnelles.
• Pour ces données, exigez un hébergement certifié HDS (Hébergeur de Données de Santé) pour les données médicales, et vérifiez que le prestataire est qualifié SecNumCloud par l'ANSSI si vous traitez des données critiques pour l'État ou des opérateurs d'importance vitale.
• Pour les données moins sensibles, évaluez le coût/bénéfice d'une migration versus le renforcement des contrôles contractuels et techniques en place.

Deux acteurs à connaître dans cet espace : **Oodrive pour la gestion documentaire souveraine (qualifié SecNumCloud), et Cegedim** côté hébergement de données de santé — deux exemples d'alternatives européennes qui existent, sont matures, et sont souvent ignorées par réflexe ou par habitude d'achat.

Étape 5 — Intégrez la souveraineté dans votre gouvernance du risque, pas dans vos projets IT

C'est le point le plus souvent manqué. La dépendance technologique à des acteurs extra-européens n'est pas un sujet IT. C'est un sujet de gouvernance du risque, et il doit être traité comme tel.

Ce que vous devez faire concrètement :

• Intégrez un indicateur de souveraineté numérique dans votre cartographie des risques SI : pour chaque processus critique, quelle est la part des traitements exposés à une juridiction non-européenne ?
• Portez ce sujet au COMEX ou au Conseil d'Administration : l'incident Solimut n'est pas qu'un problème technique, c'est un problème de responsabilité d'entreprise. Les dirigeants doivent comprendre que la localisation des données est une décision stratégique, pas un choix d'infrastructure.
• Incluez des critères de souveraineté dans vos appels d'offres IT : localisation des données, nationalité juridique du prestataire, existence d'une certification reconnue (HDS, SecNumCloud, ISO 27001 audité en Europe), clauses de réversibilité auditables.
• Nommez un référent souveraineté numérique dans votre équipe — qu'il soit interne ou externe. Ce rôle n'existe pas encore dans la plupart des PME/ETI. Il devrait.

Ce que l'incident Solimut révèle vraiment

Une cyberattaque est toujours un révélateur. Elle révèle les fragilités techniques, oui. Mais surtout, elle révèle les dépendances contractuelles et juridiques que personne n'avait cartographiées parce que tout fonctionnait.

En 2026, un DSI européen responsable ne peut plus se permettre d'ignorer où ses données résident juridiquement. Pas uniquement pour des raisons de conformité RGPD — mais parce que la géopolitique numérique s'est invitée dans les salles serveurs. Les tensions commerciales transatlantiques, les décisions unilatérales d'acteurs dominants, les injonctions extra-territoriales : ce ne sont plus des scénarios théoriques.

Solimut a payé le prix d'une attaque. D'autres pourraient payer le prix d'une dépendance — lentement, silencieusement, sans qu'aucune alarme ne se déclenche.

La différence entre les deux, c'est que la dépendance, elle, se corrige avant l'incident.