this post was submitted on 22 Jul 2025
25 points (96.3% liked)

Technologie - 🤖

844 readers
7 users here now

Ici concerne le champs de domaine large de la technologie : actualités sur l'informatique, partage de programme informatique et de code, montrer vos projets Arduino, ect.

Mégafil ici

founded 2 years ago
MODERATORS
top 9 comments
sorted by: hot top controversial new old
[–] Bad@jlai.lu 8 points 2 days ago* (last edited 2 days ago) (1 children)

Ce n'est pas nouveau, ils le disent ouvertement depuis longtemps, on a même déjà légiféré sur cette impossibilité de garantir la protection des données au niveau européen (la fin du Privacy Shield). Ce qui est nouveau c'est que c'est devant le sénat français.

En 2019 j'ai basculé le run d'une très grosse entreprise d'AWS vers Azure, les ingés Microsoft qui nous aidaient devaient délimiter la protection des données qu'ils pouvaient garantir (pour que l'entreprise garde sa certification ISO 27001), une des garanties impossibles de leur part était que les données des clients soient protégées du gouvernement américain, vu qu'ils ont leur loi CLOUD Act à respecter.

En théorie ça ressemble à une brèche du RGPD, mais entre temps il y a eu l'arrêt Schrems II côté UE qui dit comment rendre ça RGPD compatible : c'est aux entreprises de chiffrer toutes les données considérées "sensibles" qui sont stockées dans un cloud. Comme ça, même si les USA mettent leur nez dedans, ils n'en tireront que des données impossibles à exploiter. Donc on part du principe que les clouds américains sont incompatibles avec l'Europe… mais qu'on peut s'adapter à leur usage, et qu'il y a donc une compatibilité possible.

Bien entendu, ce n'est pas fait par la majorité des entreprises, ne serait-ce que parce que l'impact du chiffrage sur les performances des recherches parmi les données sensibles serait lourd, or le business de beaucoup d'entreprises inclut l'exploitation des données sensibles qu'elles ont sous la main (rappel que chaque info que vous donnez à une entrerpise va être exploitée). Par expérience de la façon de fonctionner dans le monde de la tech, trouver une façon de faire semblant de respecter le RGPD (par ex. une pseudonymisation foireuse) est plus attirant que de trouver une façon de chiffrer les données sensibles tout en conservant la performance lors de leur exploitation. Donc l'illégalité sera généralement préférée pour faire des économies d'efforts. Les amendes ne sont pas assez élevées pour dissuader (elles le sont en théorie mais jamais en pratique).

TL;DR: Ça fait longtemps que les données sensibles sont impossibles à protéger quand un cloud américain est utilisé.

[–] RelativityRanger@jlai.lu 1 points 2 days ago* (last edited 2 days ago)

rendre ça RGPD compatible : c’est aux entreprises de chiffrer toutes les données considérées “sensibles” qui sont stockées dans un cloud. Comme ça, même si les USA mettent leur nez dedans, ils n’en tireront que des données impossibles à exploiter.

Pour la nuance Récolter maintenant, déchiffrer plus tard 🌈
Le chiffrement actuel est basé sur des problèmes difficiles pour les ordinateurs classiques, mais faciles à résoudre pour un ordinateur quantique avec l’algorithme de Shor. Si un responsable est assez stupide pour choisir MS de nos jours alors il l'est suffisamment pour utiliser un chiffrement asymétrique (ou pire).

[–] Professeur_Falken@jlai.lu 6 points 2 days ago* (last edited 2 days ago)

Pas des amis, pas des partenaires. Des ennemis.

[–] marud@piefed.marud.fr 6 points 2 days ago

J'en parlais hier à un des commerciaux à mon boulot et j'avais pas remis la main sur un article, je vais m'empresser de lui montrer de ce pas !

[–] mat@jlai.lu 5 points 2 days ago (1 children)

Ce qui me choque un peu avec le chmilblik :

  • ça fait un mois que l'audition a été diffusée
  • si Microsoft se retire, le hub de santé est dead de chez dead (évidemment c'est du propriétaire)
[–] marud@piefed.marud.fr 3 points 2 days ago (1 children)

Ca serait un bon argument pour forcer une obligation de compatibilité de format de données pour ce genre de choses

[–] mat@jlai.lu 2 points 2 days ago (1 children)

Sur un cloud comme ça, le problème est même plus au niveau de la donnée, mais juste d'un lock in au niveau du code. Tout ce que tu peux dev c'est du spécifique que tu peux pas porter ou alors le choix d'Azure est largement surdimensionné. La grosse question que je me pose, c'est quels sont les besoins réels pour le hub de santé pour qu'openstack ne soit pas suffisant (ou alors capg et orange sont complices du mauvais choix)

[–] marud@piefed.marud.fr 3 points 2 days ago (1 children)

C'est intéressant ce que tu dis et ça dépasse mon domaine de connaissance (je suis pas dev et pas utilisateur du hub de santé).

Forcer d'avoir son code de traitement de données de santé en opensource serait l'étape qui manque alors ?

[–] mat@jlai.lu 2 points 2 days ago

Là tu viens toucher à mon côté libriste et je pense que tous les logiciels d'État se doivent d'être publié en open source (voire domaine publique). Mon opinion suivante c'est que aucun argent publique ne devrait aller vers des solutions propriétaires (coucou Pronote, les big esns, les deals avec microsoft).

Après, openstack n'est pas azure, il manquerait le côté saas, mais quitte à monter un opérateur azure, pourquoi ne pas se tourner vers l'Open source ça me termine