Leçon 4 — La sécurité
Le modèle de responsabilité partagée
C'est le concept fondateur, et son incompréhension est à l'origine de la quasi-totalité des incidents.
Le fournisseur sécurise le cloud. Les centres de données, le matériel, l'hyperviseur, le réseau physique, la disponibilité des services. Ces éléments sont audités, certifiés, et généralement mieux protégés que ce qu'une entreprise ordinaire pourrait construire.
Vous sécurisez ce que vous mettez dans le cloud. La configuration des droits d'accès, le chiffrement de vos données, les règles réseau, la gestion des clés, ce que contiennent vos journaux, et qui a accès à quoi.
Les fuites de données dans le cloud proviennent presque toujours d'une erreur de configuration du client, pas d'une compromission du fournisseur. Un espace de stockage rendu public, une clé laissée dans un dépôt, des droits trop larges accordés « temporairement ».
La conséquence est encourageante : ces incidents sont évitables avec des pratiques élémentaires, et ils ne demandent pas d'expertise rare.
Les cinq erreurs les plus fréquentes
1. Un espace de stockage rendu public
Le classique absolu. Un jeu de données déposé dans un espace de stockage configuré en accès public « pour simplifier pendant le développement », puis oublié. Des outils d'indexation le trouvent.
Ce qu'il faut faire : bloquer l'accès public au niveau du compte, pas au niveau de chaque espace. Les trois fournisseurs le permettent, et c'est une case à cocher. Puis activer la journalisation des accès.
2. Une clé d'accès dans le code
Une clé écrite dans un notebook, puis le notebook poussé sur un dépôt. Même sur un dépôt privé, la clé est désormais dans l'historique Git, et elle y restera.
Ce qu'il faut faire : n'utiliser jamais de clé statique dans du code. Les plateformes fournissent des identités attachées aux ressources — rôles IAM, comptes de service, identités managées — qui donnent les droits sans secret à stocker. Pour les secrets inévitables, un gestionnaire de secrets dédié. Et un outil d'analyse qui refuse un dépôt contenant un secret.
3. Des droits trop larges
Le réflexe qui débloque tout : accorder des droits administrateur pour que « ça marche », avec l'intention de restreindre plus tard. Plus tard n'arrive jamais.
Ce qu'il faut faire : partir du moindre privilège et ajouter au fur et à mesure. C'est plus lent au début et cela évite qu'une clé compromise donne accès à tout. Et vérifier périodiquement les droits réellement utilisés : les plateformes fournissent des rapports qui révèlent les permissions accordées et jamais exercées.
4. Des données personnelles dans les journaux
Spécifique aux systèmes d'IA, et très fréquent. On journalise les entrées et les sorties du modèle pour pouvoir déboguer — ce qui est une bonne pratique de la surveillance — et ces journaux contiennent des noms, des adresses, des numéros de dossier, parfois des données de santé.
Les journaux sont souvent conservés longtemps, accessibles largement, et rarement inclus dans les analyses d'impact.
Ce qu'il faut faire : décider explicitement ce qui est journalisé ; pseudonymiser ou masquer les champs sensibles avant écriture ; appliquer une durée de conservation courte ; et restreindre l'accès aux journaux comme on restreint l'accès aux données sources.
5. Un réseau ouvert par défaut
Un point de terminaison d'inférence exposé sur internet sans authentification, parce que c'était plus simple pour tester. N'importe qui peut l'appeler, ce qui expose le modèle et fait grimper la facture.
Ce qu'il faut faire : par défaut, pas d'accès public. Un accès par réseau privé, ou une authentification obligatoire, avec limitation du débit par appelant.
Les risques propres au machine learning
Quatre risques que la sécurité informatique classique ne couvre pas.
L'empoisonnement des données. Si vos données d'entraînement proviennent d'une source que vous ne contrôlez pas — contributions d'utilisateurs, collecte web, données partenaires —, un acteur malveillant peut y injecter des exemples conçus pour dégrader le modèle ou y installer un comportement caché déclenché par un motif précis. Le remède : valider les sources, détecter les anomalies dans les données entrantes, et ne jamais réentraîner automatiquement sur des données non validées — c'est aussi la conclusion de la leçon sur la surveillance.
L'extraction de modèle. Un point de terminaison public interrogé massivement permet de reconstruire un modèle approchant : on utilise les réponses comme étiquettes pour entraîner un clone. Le remède : limitation du débit, authentification, et surveillance des motifs d'appel inhabituels.
L'inférence d'appartenance. Il est parfois possible de déterminer si un enregistrement précis figurait dans les données d'entraînement, ce qui constitue une atteinte à la vie privée même sans accès aux données. Le remède : éviter le surapprentissage, qui aggrave ce risque, et envisager la confidentialité différentielle sur les données très sensibles.
Les injections dans les systèmes génératifs. Traité en détail dans la leçon sur les agents : le contenu lu par un modèle peut contenir des instructions. Le remède est architectural : le moindre privilège sur les outils.
La localisation et la souveraineté des données
Sujet juridique autant que technique, et il faut le traiter en trois questions distinctes.
Où les données sont-elles stockées ? Le choix de la région détermine la localisation physique. Toutes les grandes plateformes offrent des régions européennes, et c'est la première décision à prendre — elle est difficile à changer après.
Où sont-elles traitées ? Plus subtil. Certains services managés, notamment d'IA, ne sont pas disponibles dans toutes les régions et peuvent traiter les données ailleurs. La journalisation et la supervision peuvent aussi transiter. À vérifier service par service, dans la documentation contractuelle, pas dans les pages marketing.
Qui peut y accéder juridiquement ? La question la plus débattue. Un fournisseur dont la maison mère est soumise à une législation extraterritoriale peut, en théorie, se voir demander des données stockées en Europe. Les fournisseurs ont répondu par des engagements contractuels, du chiffrement à clé client et des offres de souveraineté opérées par des partenaires locaux. Le débat juridique n'est pas clos.
Ce que cela donne en pratique :
- Pour des données ordinaires d'entreprise, une région européenne chez un grand fournisseur est une position solide et largement pratiquée.
- Pour des données de santé, des données publiques sensibles ou des secteurs régulés, un hébergeur qualifié localement est souvent la réponse la plus sûre juridiquement, même avec un catalogue de services plus restreint.
- Pour des données très sensibles, l'auto-hébergement d'un modèle ouvert reste l'option la plus défendable : rien ne sort.
Le cours sur l'éthique de l'IA traite les obligations relatives aux données personnelles et le règlement sur l'intelligence artificielle.
La liste de contrôle de sécurité
- L'accès public au stockage est bloqué au niveau du compte.
- Aucune clé statique dans le code ; identités attachées aux ressources et gestionnaire de secrets.
- Les droits suivent le moindre privilège, avec une revue périodique des permissions inutilisées.
- Le chiffrement au repos et en transit est activé, avec une gestion des clés définie.
- Ce qui est journalisé a été décidé explicitement, les champs sensibles sont masqués, la conservation est limitée.
- Les points de terminaison ne sont pas publics sans authentification, et le débit est limité.
- La région de stockage et de traitement est vérifiée pour chaque service utilisé.
- Les sources de données d'entraînement sont validées ; pas de réentraînement automatique sur données non contrôlées.
- Une analyse d'impact est faite si des données personnelles sont traitées.
- Les accès sont journalisés et les journaux protégés.
À retenir
- La responsabilité est partagée : le fournisseur sécurise le socle, vous sécurisez ce que vous y mettez.
- Les fuites viennent presque toujours d'une erreur de configuration client, donc elles sont évitables.
- Cinq erreurs dominent : stockage public, clé dans le code, droits trop larges, données personnelles dans les journaux, réseau ouvert.
- Risques propres au machine learning : empoisonnement, extraction de modèle, inférence d'appartenance, injections.
- La souveraineté se décompose en trois questions : où stocké, où traité, qui peut accéder juridiquement.
- Données ordinaires : région européenne chez un grand fournisseur. Données de santé ou sensibles : hébergeur qualifié ou auto-hébergement.
Leçon suivante — La dépendance : ce qui vous enferme réellement →