flowchart LR A[Environnement évalué] --> B[Mise à jour] B --> C[Nouvelles capacités] B --> D[Nouvelles dépendances] C --> E[Profil de risque modifié] D --> E F[Nouvelles attaques] --> E G[Changement contractuel] --> E E --> H[Réévaluation nécessaire]
Chapitre 2 : Données sensibles et environnements : choisir des compromis explicites
Intégrité contextuelle, environnements de confiance et discernement infrastructurel
Toutes les IA ne se ressemblent pas : comment choisir un environnement cohérent avec la sensibilité des données, les finalités de l’usage et les garanties réellement disponibles, sans tomber dans l’illusion d’un outil « 100 % sécurisé » ?
Mots-clés
Intégrité contextuelle Environnement IA Risque résiduel Asymétrie informationnelle Discernement infrastructurel Governance-by-design Réversibilité Données sensibles
Ce chapitre prolonge directement le Volume 2, chapitre 1 en vous aidant à :
- Passer de la question « qu’est-ce que mon usage expose ? » à « dans quel environnement ces informations peuvent-elles circuler de manière appropriée ? » ;
- Mobiliser la minimisation des données comme acquis, sans la confondre avec une garantie suffisante de sécurité ;
- Comprendre qu’une donnée n’est pas « sensible » indépendamment de son contexte, de ses destinataires, de sa finalité et de ses conditions de circulation ;
- Déplacer le regard de l’interface vers l’infrastructure : fournisseur, hébergement, contrats, dépendances, maintenance, audit et réversibilité ;
- Déconstruire deux raccourcis symétriques : « cloud = dangereux » et « local = sécurisé » ;
- Remplacer la recherche du risque zéro par une culture de l’arbitrage explicite entre utilité, confidentialité, performance, simplicité, souveraineté et capacité institutionnelle ;
- Construire un discernement infrastructurel permettant de justifier pourquoi un environnement est adapté à une situation donnée.
Repères essentiels
Notions essentielles du chapitre
Ces sept notions structurent la lecture du chapitre. Les autres notions restent accessibles dans le corps du texte et dans le glossaire du chapitre.
| Notion | Définition courte | Question professionnelle associée |
|---|---|---|
Intégrité contextuelle |
Approche selon laquelle un flux d’information est approprié lorsqu’il respecte les normes, acteurs, finalités et conditions légitimes du contexte. | Cette information circule-t-elle vers les bons acteurs, pour la bonne finalité et selon des conditions attendues ? |
Environnement IA |
Ensemble formé par le modèle, l’interface, l’hébergement, les contrats, les dépendances logicielles, les règles d’accès et les mécanismes de gouvernance. | Qu’y a-t-il réellement derrière l’interface que j’utilise ? |
Risque résiduel |
Risque qui demeure après la mise en place de mesures de protection. | Quel risque reste-t-il et qui accepte de l’assumer ? |
Asymétrie informationnelle |
Situation dans laquelle l’utilisateur ou l’institution dispose de moins d’informations que le fournisseur sur le fonctionnement réel du système. | Quelles garanties pouvons-nous réellement vérifier ? |
Discernement infrastructurel |
Capacité à relier usage, données, environnement, dépendances et responsabilités pour justifier un choix. | Pourquoi cet environnement est-il acceptable ici, et pas nécessairement ailleurs ? |
Governance-by-design |
Intégration des mécanismes de contrôle, d’audit et de gouvernance dès la conception de l’environnement. | Les garde-fous sont-ils ajoutés après coup ou intégrés à l’architecture ? |
Réversibilité |
Capacité à suspendre, remplacer ou faire évoluer une solution sans perdre de manière disproportionnée données, continuité ou autonomie. | Pouvons-nous suspendre ou remplacer la solution sans perte disproportionnée ? |
Introduction
Le Volume 2, chapitre 1 a déplacé la question des données : une interaction avec une IA ne se réduit pas au contenu volontairement saisi. Elle produit des traces, permet des inférences et peut exposer davantage que ce que l’utilisateur croit transmettre.
Cette prise de conscience ne suffit pourtant pas à décider.
Une même information ne présente pas les mêmes enjeux selon qu’elle est traitée :
- dans une interface publique ;
- dans un service cloud contractualisé ;
- dans un environnement institutionnel authentifié ;
- dans une infrastructure locale ;
- dans un dispositif expérimental isolé.
Le problème change donc de nature.
Après avoir appris à regarder ce que l’usage expose, il faut regarder où, comment, par qui et sous quelles garanties cette information est traitée.
La simplicité de l’interface masque des infrastructures, des chaînes de dépendance et des modèles de gouvernance différents. Un point est décisif : aucun environnement n’est intrinsèquement « 100 % sécurisé ». Le local déplace une partie du risque vers l’institution ; le cloud peut présenter des niveaux de garanties très différents ; un contrat réduit certains risques sans supprimer l’asymétrie informationnelle ; un système robuste aujourd’hui peut être affecté demain par une mise à jour, une dépendance vulnérable ou une nouvelle attaque.
Le centre de gravité du chapitre n’est donc plus la prudence individuelle. Il devient l’arbitrage situé.
Continuité avec le chapitre sur les données et la vie privée
| Acquis du chapitre précédent | Apport de ce chapitre |
|---|---|
| Identifier données explicites, traces et inférences. | Relier ces informations aux acteurs, finalités et conditions de circulation. |
| Minimiser les informations transmises. | Reconnaître que même une donnée minimale peut être inadaptée à certains environnements. |
| Pseudonymiser et tester sans exposer. | Évaluer ce que l’environnement permet encore d’inférer et quelles garanties il offre. |
| Choisir consciemment ce que l’on donne. | Choisir où on le donne et sous quelles responsabilités. |
| Préserver un recours humain effectif. | Intégrer aussi audit, réversibilité, maintenance et gouvernance. |
| Passer de la prudence individuelle à la souveraineté informationnelle. | Comprendre que la souveraineté suppose des capacités techniques et organisationnelles réelles, pas seulement un hébergement local. |
Le parcours en trois mouvements
| Mouvement | Intention pédagogique |
|---|---|
| 1 - Toutes les IA ne se ressemblent pas | Passer de la sensibilité intrinsèque des données à l’intégrité contextuelle et regarder l’infrastructure derrière l’interface. |
| 2 - Le mythe de l’outil « 100 % sécurisé » | Comprendre pourquoi local, cloud et contractualisation déplacent les risques au lieu de les supprimer. |
| 3 - Choisir son IA, c’est choisir ses compromis | Construire une décision proportionnée, explicite et soutenable pour l’utilisateur comme pour l’institution. |
Activité : Auto-test de sensibilisation
1 - Toutes les IA ne se ressemblent pas : de la donnée au contexte
Essentiel Recommandé Approfondissement
Dans cette partie, vous allez :
| Comprendre | Repérer | Agir |
|---|---|---|
| Pourquoi la sensibilité dépend aussi des conditions de circulation. | Les différences entre interface, infrastructure, acteurs et finalités. | Décrire une situation avant de choisir l’environnement qui la traitera. |
Situation ESR
Un enseignant souhaite utiliser une IA pour préparer trois tâches :
- générer des idées d’exercices à partir d’un programme public ;
- reformuler le feedback d’une copie étudiante ;
- résumer un document transmis par un partenaire industriel sous accord de confidentialité.
Peut-il raisonner de la même manière dans les trois cas simplement parce que l’outil proposé est « l’IA de l’établissement » ?
Derrière la même interface, des environnements différents
Le Volume 2, chapitre 1 invitait à ne pas confondre l’interface et l’infrastructure lorsqu’on raisonne sur la conservation des traces. Cette distinction devient ici centrale.
Un environnement IA ne se résume pas au nom du modèle.
| Couche | Questions à poser |
|---|---|
| Interface | Qui peut se connecter ? Quels réglages sont visibles ? Quelle mémoire est activée ? |
| Modèle | Modèle propriétaire, ouvert ou open-weight ? Quelle version ? Quelles capacités ? |
| Hébergement | Où le traitement est-il exécuté ? Qui opère l’infrastructure ? |
| Données | Sont-elles journalisées, conservées, réutilisées ou transférées ? |
| Contrat | Quelles garanties sont formalisées ? Quelles finalités sont exclues ? |
| Dépendances | Quelles bibliothèques, API, composants ou fournisseurs tiers interviennent ? |
| Gouvernance | Qui audite, met à jour, autorise, suspend et répond en cas d’incident ? |
| Réversibilité | Peut-on changer de solution sans perdre le dispositif, les données ou les compétences ? |
Deux services peuvent donc sembler équivalents à l’utilisateur tout en présentant des conditions de traitement très différentes.
L’intégrité contextuelle : une donnée n’est pas seule
Helen Nissenbaum propose la théorie de l’intégrité contextuelle (Nissenbaum, 2010).
L’idée est particulièrement utile pour prolonger Volume 2, chapitre 1 : la question n’est pas seulement de savoir si une information est « publique » ou « privée », mais si son flux est approprié au contexte.
Un flux peut être analysé à partir de plusieurs dimensions :
- le contexte : enseignement, recherche, administration, accompagnement ;
- les acteurs : étudiant, enseignant, laboratoire, partenaire, fournisseur ;
- l’information : publique, interne, personnelle, stratégique, confidentielle ;
- la finalité : reformuler, analyser, classer, résumer, entraîner, archiver ;
- les conditions de transmission : consentement, contrat, authentification, limitation de réutilisation, confidentialité.
De la sensibilité de la donnée à la sensibilité de la situation
Le terme « donnée sensible » est utile, mais il peut conduire à une fausse simplicité si on imagine qu’il existe deux boîtes : données sensibles / données non sensibles.
Dans l’ESR, la décision doit aussi tenir compte de la situation.
| Situation | Question déterminante |
|---|---|
| Contenu pédagogique déjà public | L’usage ajoute-t-il une exposition nouvelle significative ? |
| Copie ou production étudiante | La personne reste-t-elle identifiable ou inférable ? |
| Données administratives | L’opération envisagée et l’environnement sont-ils autorisés ? |
| Recherche non publiée | L’information a-t-elle une valeur scientifique ou stratégique avant publication ? |
| Recherche sous NDA | Le transfert vers un tiers constitue-t-il une divulgation incompatible avec l’accord ? |
| Manuscrit en relecture | Les engagements de confidentialité autorisent-ils un traitement externe ? |
| Données liées à la santé ou au handicap | L’usage est-il réellement nécessaire et l’environnement suffisamment encadré ? |
Le bon objet d’analyse n’est donc pas seulement la donnée : c’est le triplet situation - finalité - environnement.
une classification graduée plutôt qu’un oui/non
Recommandé
Des matrices distinguant plusieurs niveaux de sensibilité permettent de construire une approche institutionnelle graduée. Elles fournissent un principe d’analyse, pas une nomenclature universelle.
Une matrice locale peut par exemple distinguer :
| Niveau indicatif | Exemples | Orientation générale |
|---|---|---|
| P1 - Public | Programme public, texte publié, données ouvertes validées. | Environnements autorisés pour usages à faible risque. |
| P2 - Interne | Documents de travail non sensibles, contenus pédagogiques internes. | Environnement authentifié et cadre connu. |
| P3 - Protégé | Productions étudiantes, données personnelles, documents administratifs non publics. | Environnement validé avec garanties renforcées. |
| P4 - Hautement sensible / stratégique | Santé, handicap, NDA, brevet, données critiques de recherche. | Traitement fortement restreint, environnement dédié ou absence d’usage selon le cadre applicable. |
Important : cette matrice est un outil pédagogique d’arbitrage, pas une classification réglementaire universelle. Les catégories opérationnelles doivent être alignées sur la politique et la charte de l’établissement.
l’environnement modifie les acteurs du flux
Approfondissement
Passer d’un outil local à un service cloud n’est pas seulement changer de serveur. Cela peut modifier :
- les acteurs ayant techniquement accès au traitement ;
- les sous-traitants impliqués ;
- les juridictions pertinentes ;
- les finalités permises contractuellement ;
- les mécanismes d’audit ;
- la possibilité de suspendre ou de modifier le service.
C’est pourquoi la question « où sont les données ? » reste insuffisante.
Il faut aussi demander :
qui peut faire quoi avec elles, dans quel but, pendant combien de temps, avec quelle possibilité de contrôle et de recours ?
Activité : le même prompt dans trois contextes
2 - Le mythe de l’outil « 100 % sécurisé » : déplacer plutôt que supprimer le risque
Essentiel Recommandé Approfondissement
Dans cette partie, vous allez :
| Comprendre | Repérer | Agir |
|---|---|---|
| Pourquoi aucun environnement ne supprime tous les risques. | Les risques propres au local, au cloud et aux dépendances techniques. | Remplacer l’opposition « sûr / dangereux » par une analyse du risque résiduel et des capacités réelles de maîtrise. |
Situation ESR
Une équipe propose de déployer un modèle open-weight sur un serveur interne afin de pouvoir affirmer : « les données ne quittent plus l’INSA, donc l’outil est sécurisé ».
L’argument est rassurant.
Mais qui audite le modèle ? Qui vérifie les dépendances ? Qui applique les correctifs ? Qui contrôle les accès ? Qui surveille les journaux ? Qui décide lorsqu’une vulnérabilité est publiée ?
Le risque a-t-il disparu ou a-t-il changé de propriétaire ?
Le local ne constitue pas une solution magique
L’hébergement local peut apporter des avantages importants :
- limitation de certains transferts externes ;
- contrôle accru sur l’infrastructure ;
- possibilité de segmenter les accès ;
- adaptation aux contraintes de recherche ou de confidentialité.
Une limite demeure : la proximité technique n’est pas la maîtrise effective.
Une infrastructure locale peut dépendre :
- de modèles pré-entraînés externes ;
- de bibliothèques tierces ;
- de formats d’importation ;
- de composants logiciels vulnérables ;
- d’une configuration réseau ;
- de procédures de maintenance ;
- de compétences rares.
La souveraineté déplace alors une partie de la responsabilité vers l’établissement.
Paradoxe de la souveraineté technique : reprendre le contrôle d’une infrastructure peut augmenter la maîtrise, mais aussi augmenter la responsabilité et la surface opérationnelle à maintenir.
Open-weight n’est pas synonyme de transparent
Un modèle open-weight donne accès à ses poids, mais cela ne signifie pas nécessairement que l’institution dispose :
- de toutes les données d’entraînement ;
- de toute la documentation du processus ;
- d’une capacité complète d’audit ;
- d’une maîtrise de chaque dépendance ;
- d’une garantie sur l’absence de vulnérabilités.
L’ouverture d’une composante ne rend pas automatiquement l’ensemble de la chaîne transparent.
Le cloud n’est pas un environnement unique
Le raccourci inverse est tout aussi problématique : « le cloud est externe, donc il faut l’exclure ».
Il faut notamment distinguer :
- services grand public, dont les garanties peuvent être insuffisantes pour certains usages ;
- offres professionnelles ou Enterprise, avec authentification, clauses spécifiques et restrictions possibles sur la réutilisation ;
- services contractualisés par l’institution, dans lesquels les flux sont davantage gouvernés.
Un cloud contractualisé peut donc être acceptable pour certaines situations sans devenir acceptable pour toutes.
| Environnement | Atout possible | Risque ou limite à examiner |
|---|---|---|
| Grand public | Simplicité, performance, disponibilité. | Réutilisation, garanties insuffisantes, compte personnel, faible maîtrise. |
| Cloud contractualisé | Garanties formalisées, administration institutionnelle, performance. | Asymétrie d’audit, dépendance fournisseur, évolution du service. |
| Local / on-premises | Maîtrise accrue de certains flux, segmentation. | Maintenance, sécurité interne, dépendances, compétences et coûts. |
| Sandbox institutionnelle | Expérimentation encadrée, observation, apprentissage collectif. | Périmètre limité, gouvernance et maintenance nécessaires. |
Contractualiser restaure des garanties, pas une omniscience
Les garanties peuvent notamment porter sur les accords de traitement des données, clauses de non-réutilisation, restrictions d’entraînement ou garanties de résidence.
Ces mécanismes sont importants parce qu’ils permettent de rendre certains flux plus compatibles avec le contexte académique.
Mais ils ne suppriment pas l’asymétrie informationnelle.
L’établissement peut obtenir des engagements sans être capable de vérifier en temps réel chaque mécanisme interne de filtrage, journalisation ou traitement.
La contractualisation réduit et redistribue le risque ; elle ne transforme pas un fournisseur externe en système totalement transparent.
Un risque qui évolue dans le temps
Le profil de risque d’un environnement n’est pas figé.
Il peut évoluer avec :
- une nouvelle version du modèle ;
- une mise à jour logicielle ;
- une vulnérabilité découverte ;
- une nouvelle technique d’attaque ;
- une modification contractuelle ;
- un changement de sous-traitant ;
- une nouvelle fonctionnalité activée par défaut.
La sécurité devient donc un processus de gouvernance, pas un label acquis une fois pour toutes.
remplacer « sécurisé » par quatre questions
Essentiel
Au lieu de demander « cet outil est-il sécurisé ? », demander :
- Sécurisé pour quel usage ?
- Avec quelles données ?
- Sous quelles garanties techniques, contractuelles et organisationnelles ?
- Quel risque résiduel reste-t-il et qui est en capacité de l’assumer ?
le compromis à six dimensions
Recommandé
Aucun environnement ne maximise simultanément toutes les dimensions.
| Dimension | Question |
|---|---|
| Performance | Le modèle répond-il suffisamment bien au besoin ? |
| Confidentialité | Les flux et réutilisations sont-ils compatibles avec les données ? |
| Souveraineté | Quelle marge de décision l’institution conserve-t-elle ? |
| Simplicité | L’usage est-il accessible aux publics concernés ? |
| Maintenance | Qui possède les compétences et ressources nécessaires ? |
| Coût / soutenabilité organisationnelle | Le dispositif peut-il être maintenu dans le temps ? |
Le choix professionnel consiste à rendre visible la hiérarchie entre ces critères, pas à prétendre qu’ils sont tous maximisés.
dépendance et réversibilité
Approfondissement
La dépendance au fournisseur, ou vendor lock-in, concerne aussi la continuité des usages.
Lorsqu’un dispositif pédagogique dépend fortement :
- d’une API ;
- d’un format propriétaire ;
- d’une tarification ;
- d’un modèle spécifique ;
- de fonctionnalités impossibles à reproduire ailleurs,
un changement de fournisseur peut affecter la continuité du dispositif.
Cette question sera approfondie dans le Volume 2, chapitre 4, consacré aux plateformes et dépendances, après le chapitre sur les responsabilités. Ici, elle intervient comme critère de sécurité organisationnelle : être protégé ne signifie pas seulement éviter une fuite de données, mais conserver la capacité de continuer, migrer ou renoncer.
Activité : démonter l’étiquette « sécurisé »
3 - Choisir son IA, c’est choisir ses compromis
Essentiel Recommandé Approfondissement
Dans cette partie, vous allez :
| Comprendre | Repérer | Agir |
|---|---|---|
| Pourquoi l’arbitrage devient une compétence professionnelle. | La fatigue de gouvernance, les conflits de critères et les responsabilités du choix d’environnement. | Construire une cartographie des usages et documenter les garanties nécessaires. |
Situation ESR
Une équipe pédagogique compare deux environnements pour préparer des activités. Le premier est performant et simple, mais ses conditions de conservation et de réutilisation des données restent difficiles à vérifier. Le second, institutionnel, offre des garanties identifiées mais répond moins bien à certaines tâches.
L’équipe doit préciser les données réellement nécessaires, les garanties attendues et les limites acceptables avant de choisir.
Quel est le « bon » outil ?
La réponse ne peut pas être déduite d’un classement de performance.
La charge cognitive de gouvernance
Une difficulté très concrète apparaît : les personnels doivent arbitrer entre des exigences multiples dans un environnement qui change rapidement.
Ils doivent simultanément :
- gagner du temps ;
- préserver la qualité pédagogique ;
- protéger les données ;
- comprendre les règles ;
- suivre l’évolution des outils ;
- maintenir l’accessibilité ;
- éviter de créer une dépendance ;
- respecter les capacités réelles de l’établissement.
Cette fatigue d’arbitrage peut produire deux réponses symétriques :
- l’usage par défaut : « tout le monde utilise l’outil le plus simple » ;
- l’interdiction par défaut : « on ne prend aucun risque ».
Or les deux évitent précisément le travail professionnel recherché : construire un compromis explicite.
Du jugement professionnel au discernement infrastructurel
Le Volume 1, chapitre 4 faisait du jugement professionnel une capacité à choisir, justifier et reprendre la main.
Le Volume 2 lui ajoute une dimension :
le discernement infrastructurel consiste à savoir dans quelles conditions techniques et organisationnelles un usage peut rester compatible avec ses finalités pédagogiques.
| Jugement professionnel | Discernement infrastructurel |
|---|---|
| Pourquoi utiliser l’IA ici ? | Dans quel environnement ? |
| Quelle activité doit rester humaine ? | Quelles données peuvent circuler ? |
| Comment vérifier la production ? | Quelles garanties sont disponibles ? |
| Comment préserver l’autonomie ? | Quelle dépendance créons-nous ? |
| Puis-je reprendre la main ? | Puis-je migrer, suspendre ou proposer une alternative ? |
Lorsque le choix d’environnement engage autrui
Un environnement adapté aux données ne suffit pas à rendre sa prescription équitable. Dès qu’un outil est demandé aux étudiants, il faut aussi examiner les contraintes qu’il leur impose et leur possibilité réelle de participer ou de refuser.
Le chapitre suivant, consacré aux responsabilités, approfondit les questions de compte personnel, d’accessibilité, d’offre freemium, d’alternative équivalente et de transparence de la prescription. Ici, l’analyse reste centrée sur les garanties de l’environnement et leur adéquation à la situation.
Cartographier les usages avant de choisir les outils
Une politique d’usage devient plus lisible lorsqu’elle part des situations plutôt que d’une liste de marques.
| Usage | Données | Exigence principale | Environnement à rechercher |
|---|---|---|---|
| Générer des idées à partir de contenus publics | Faible sensibilité | Simplicité, qualité | Outil autorisé pour usage courant |
| Aider à reformuler une copie | Données étudiantes | Confidentialité, minimisation | Environnement institutionnel adapté |
| Synthétiser un dossier RH | Données personnelles / administratives | Protection forte, autorisation | Environnement explicitement validé ou absence d’usage |
| Explorer un document sous NDA | Données stratégiques | Confidentialité contractuelle | Environnement dédié compatible avec l’accord |
| Tester une méthode | Données non nécessaires | Expérimentation | Sandbox ou données synthétiques |
| Assistance d’accessibilité | Données potentiellement sensibles | Inclusion + confidentialité | Solution évaluée avec alternative disponible |
rendre le compromis explicite
Recommandé
Pour chaque usage institutionnel, documenter au minimum :
- la finalité ;
- la catégorie de données ;
- l’environnement choisi ;
- les garanties disponibles ;
- le risque résiduel accepté ;
- la personne ou instance responsable de l’arbitrage ;
- l’alternative en cas de refus, panne ou changement de fournisseur.
Le dernier point est essentiel : un choix réellement maîtrisé doit pouvoir être réversible.
governance-by-design
Approfondissement
La governance-by-design prolonge la simple évaluation a posteriori.
Au lieu de :
construire → déployer → découvrir les problèmes → ajouter des règles,
l’approche cherche à intégrer dès la conception :
- contrôle des accès ;
- journalisation maîtrisée ;
- segmentation ;
- mécanismes d’audit ;
- règles d’usage ;
- données de test ;
- possibilité de suspendre ;
- documentation des responsabilités.
Les sandboxes institutionnelles peuvent servir à cette logique : expérimenter dans un périmètre gouverné avant de généraliser.
Cela ne garantit pas l’absence de risque. Cela permet de transformer l’expérimentation en objet d’apprentissage collectif plutôt qu’en multiplication d’usages individuels opaques.
Activité : construire une matrice d’usage locale
Carte d’aide à la décision
Essentiel
Objectif : passer de « quel est le meilleur outil ? » à « quel environnement est proportionné à cette situation ? »
flowchart TD
A[Définir l'usage] --> B[Identifier données et contexte]
B --> C[Évaluer la sensibilité de la situation]
C --> D{Données réelles nécessaires ?}
D -->|Non| E[Données fictives / synthétiques]
D -->|Oui| F[Minimisation des données]
E --> G[Comparer les environnements]
F --> G
G --> H[Garanties techniques]
G --> I[Garanties contractuelles]
G --> J[Capacité de maintenance / audit]
G --> K[Accessibilité et justice pédagogique]
H --> L{Compromis acceptable ?}
I --> L
J --> L
K --> L
L -->|Non| M[Changer d'environnement ou renoncer]
L -->|Oui| N[Documenter le risque résiduel]
N --> O[Prévoir contrôle humain et alternative]
O --> P[Réévaluer dans le temps]
Règle de décision : le « meilleur » environnement n’existe pas indépendamment de l’usage. Un choix est défendable lorsqu’il rend explicites ses garanties, ses limites, son risque résiduel et sa possibilité de révision.
Étude de cas : un rapport de recherche sous NDA
Situation
Un chercheur doit résumer un rapport volumineux reçu d’un partenaire industriel sous accord de confidentialité. Trois options sont disponibles :
- un assistant grand public très performant ;
- un service cloud institutionnel contractualisé ;
- un modèle open-weight hébergé localement, moins performant mais administré par l’établissement.
Mauvais raisonnement n°1 : « je retire le nom de l’entreprise »
Le Volume 2, chapitre 1 suffit à montrer la limite : la confidentialité peut porter sur le contenu scientifique lui-même. La pseudonymisation ne supprime pas la valeur stratégique du document.
Mauvais raisonnement n°2 : « le local est forcément autorisé »
Le présent chapitre ajoute une seconde limite : héberger localement ne suffit pas à établir que le traitement est conforme à l’accord. Il faut examiner les conditions contractuelles, les accès, la maintenance et le cadre institutionnel.
Analyse située
| Critère | Grand public | Cloud contractualisé | Local |
|---|---|---|---|
| Performance | Potentiellement élevée | Potentiellement élevée | Variable |
| Confidentialité | Potentiellement insuffisante | Dépend des clauses | Potentiellement renforcée |
| Audit | Faible | Partiel / contractuel | Dépend des capacités internes |
| Maintenance | Fournisseur | Fournisseur + institution | Institution |
| Compatibilité NDA | À ne jamais supposer | À vérifier explicitement | À vérifier explicitement |
| Réversibilité | Variable | Variable | Variable |
Décision
Le chapitre ne permet pas d’affirmer abstraitement lequel des trois environnements est autorisé. Le NDA et le cadre institutionnel doivent trancher les conditions de traitement.
C’est précisément le point : le discernement ne remplace pas la règle applicable. Il permet de savoir quelles questions doivent être résolues avant l’usage.
Fiche action : choisir un environnement en 12 questions
Situation
Environnement
Institution
Réversibilité
En lien avec la Charte IA de l’INSA Lyon
Ce que prévoit la Charte : Repères C06, C29 et C30 : protéger les données dans un environnement adapté, examiner le bilan bénéfices-risques et préserver la réversibilité.
Ce que ce chapitre permet de comprendre : Le choix repose sur des garanties techniques, contractuelles et organisationnelles, ainsi que sur un risque résiduel explicite.
Point d’attention : Une étiquette « local » ou « sécurisé » ne suffit pas à établir que l’environnement convient à la situation. Ces repères relèvent du cadre institutionnel de l’INSA Lyon ; ils ne constituent pas une règle universelle.
Auto-positionnement final
Se situer après le chapitre
Répondez de 1 à 4 : 1 = pas du tout, 2 = rarement, 3 = souvent, 4 = systématiquement.
| Question | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| 1. Je distingue le modèle d’IA de l’environnement complet dans lequel il est déployé. | ||||
| 2. J’analyse la sensibilité d’une information en fonction de son contexte et de sa circulation. | ||||
| 3. Je ne considère pas l’hébergement local comme une garantie automatique de sécurité. | ||||
| 4. Je distingue service grand public, cloud contractualisé et environnement institutionnel. | ||||
| 5. Je cherche les garanties réellement vérifiables plutôt qu’une étiquette « sécurisé ». | ||||
| 6. Je prends en compte le risque résiduel et son évolution dans le temps. | ||||
| 7. Je mets en balance performance, confidentialité, souveraineté, simplicité et maintenance. | ||||
| 8. J’identifie les personnes ou services compétents pour valider les garanties et les usages de l’environnement. | ||||
| 9. Je prévois une possibilité de migration ou de fonctionnement dégradé. | ||||
| 10. Je peux justifier pourquoi un environnement est adapté à une situation précise. |
Analyser son positionnement
Repérez les réponses 1 et 2, puis observez dans quelles dimensions elles se concentrent. Les numéros ci-dessous correspondent à l’ordre des dix questions. Les regroupements suivent les trois mouvements du chapitre ; ils ne supposent pas que les items soient tous consécutifs.
| Dimension | Items | Question de lecture |
|---|---|---|
| Relier la donnée au contexte | 1, 2 et 4 | Ai-je identifié le contexte, les acteurs et les propriétés de l’environnement ? |
| Examiner les garanties et le risque résiduel | 3, 5 et 6 | Est-ce que je distingue une étiquette rassurante de garanties vérifiables et réévaluées ? |
| Choisir des compromis explicites | 7 à 10 | Puis-je justifier les critères du choix, les responsabilités et les possibilités de sortie ? |
Points de vigilance prioritaires : items 2 (contexte de circulation), 5 (garanties vérifiables) et 8 (validation des usages). Une réponse faible sur un item critique ne doit pas être compensée par des réponses élevées ailleurs. Elle invite à examiner la situation concernée avant de poursuivre l’usage.
Pour progresser :
- Pour les items 1, 2 et 4, reprendre Toutes les IA ne se ressemblent pas : de la donnée au contexte.
- Pour les items 3, 5 et 6, reprendre Le mythe de l’outil « 100 % sécurisé » : déplacer plutôt que supprimer le risque.
- Pour les items 7 à 10, reprendre Choisir son IA, c’est choisir ses compromis.
Choisissez une situation concrète, formulez une modification de pratique et identifiez une trace permettant d’en discuter les effets. Cette lecture sert à orienter la réflexion ; elle ne constitue ni une certification, ni un audit, ni une validation institutionnelle.
Conclusion
Le Volume 2, chapitre 1 apprenait à voir ce que l’usage expose. Le Volume 2, chapitre 2 montre pourquoi cette connaissance ne suffit pas : une même information change de statut selon l’environnement dans lequel elle circule.
Trois déplacements structurent la réflexion.
Le premier va de la donnée vers le contexte. L’intégrité contextuelle oblige à regarder les acteurs, la finalité et les conditions de circulation plutôt que de classer abstraitement les informations en « sensibles » ou « non sensibles ».
Le deuxième va de la sécurité vers le risque résiduel. Ni le local, ni le cloud, ni l’ouverture des poids, ni la contractualisation ne produisent une maîtrise totale. Ils distribuent différemment les risques, les responsabilités et les capacités de contrôle.
Le troisième va du choix d’un outil vers le discernement infrastructurel. Choisir une IA signifie arbitrer entre performance, confidentialité, souveraineté, simplicité, maintenance, inclusion et réversibilité.
Le paradoxe peut alors être formulé ainsi :
plus nous cherchons un environnement simple et performant, plus nous risquons d’invisibiliser les dépendances qui le rendent possible ; mais plus nous cherchons à tout maîtriser localement, plus nous devons assumer nous-mêmes la complexité de cette maîtrise.
La réponse n’est donc pas le risque zéro. Elle est la capacité à construire, documenter et réviser des compromis explicites.
Après avoir demandé ce que l’usage expose et dans quel environnement il peut avoir lieu, une nouvelle question apparaît : sommes-nous légitimes à transmettre ce contenu, à prescrire cet outil ou à déléguer ce jugement lorsque l’usage engage autrui ? Le chapitre suivant, consacré aux responsabilités, examine cette charnière avant l’étude des plateformes et des dépendances.
Glossaire du chapitre
| Notion | Définition |
|---|---|
Intégrité contextuelle |
Principe selon lequel la protection d’une information dépend de l’adéquation de son flux aux normes, acteurs, finalités et conditions du contexte. |
Environnement IA |
Ensemble du modèle, de l’interface, de l’hébergement, des contrats, des dépendances et des mécanismes de gouvernance qui rendent un service d’IA utilisable. |
Données sensibles |
Dans ce chapitre, expression générique pour désigner les informations nécessitant des précautions renforcées ; elle ne doit pas être confondue avec les seules catégories juridiques particulières du RGPD. |
Données stratégiques |
Informations dont la divulgation peut affecter les intérêts scientifiques, industriels, institutionnels ou contractuels d’un acteur. |
Cloud public |
Infrastructure informatique fournie à distance et mutualisée par un prestataire externe. |
Cloud contractualisé |
Service cloud dont l’usage est encadré par des engagements spécifiques négociés ou acceptés par l’institution. |
Hébergement local |
Déploiement sur une infrastructure opérée dans le périmètre directement maîtrisé par l’organisation. |
Modèle open-weight |
Modèle dont les poids sont accessibles, sans que cela implique nécessairement l’ouverture complète des données, du code, du processus d’entraînement ou de toute la chaîne technique. |
Asymétrie informationnelle |
Déséquilibre d’information entre les acteurs, notamment lorsque le fournisseur connaît mieux les traitements internes que l’organisation utilisatrice. |
Risque résiduel |
Risque qui demeure après application des mesures de protection et de réduction. |
Discernement infrastructurel |
Capacité à relier finalité, données, environnement, dépendances, garanties et responsabilités afin de justifier un choix d’usage. |
Governance-by-design |
Intégration de la gouvernance, des contrôles et de l’audit dans la conception même du dispositif. |
Réversibilité |
Capacité à suspendre, remplacer ou faire évoluer une solution sans perdre de manière disproportionnée données, continuité ou autonomie. |
Justice pédagogique |
Attention portée aux conditions équitables d’accès, de participation, d’alternative et de traitement dans un dispositif d’apprentissage. |
Bibliographie
- Almási, Z., Bleher, H., Bleher, J., Flores, R. T., Xuanyang, G., Pujszo, P., & Weuts, R. (2025). AI governance in Higher Education: A course design exploring regulatory, ethical and practical considerations. arXiv. DOI : 10.48550/arXiv.2509.06176.
- Commission Nationale de l’Informatique et des Libertés. (2025). IA : Garantir la sécurité du développement d’un système d’IA.
- Commission Nationale de l’Informatique et des Libertés. (2026). AI system development: CNIL’s recommendations to comply with the GDPR.
- Damarched, M. K. (2026). Agentic AI modernization: Transforming institutional infrastructure through orchestrated multi-agent LLM framework. Journal of Computer Science and Technology Studies, 8(4), 1-24. DOI : 10.32996/jcsts.2026.8.4.1.
- Ng, B. Y., Li, J., Tong, X., Ye, K., Yenne, G., Chandrasekaran, V., & Li, J. (2025). Analyzing security and privacy challenges in generative AI usage guidelines for Higher Education. arXiv. DOI : 10.48550/arXiv.2506.20463.
- Nissenbaum, H. (2010). Privacy in Context: Technology, Policy, and the Integrity of Social Life. Stanford University Press.
- Waseem, M., Islam, M. A., Shuvo, M. N. U., Hasan, M. M., Kemell, K.-K., Rasku, J., et al. (2026). Engineering a governance-aware AI sandbox: Design, implementation, and lessons learned. arXiv. DOI : 10.48550/arXiv.2603.03394.