Gérer les accès élèves et les limites

Donner accès sans perdre le contrôle

Ouvrir ChatGPT aux élèves est une décision d’établissement, pas un réglage technique. Elle engage un cadre pédagogique — que fait-on de l’outil et pourquoi — et un cadre technique — qui accède à quoi, dans quelles limites, sous quelle supervision. Les deux tiennent ensemble : un projet ambitieux sans gestion des accès produit du désordre, des accès verrouillés sans projet produisent un outil que personne n’utilise.

Une précision de cadre d’abord. ChatGPT n’est pas destiné aux moins de 13 ans, et les 13-18 ans doivent avoir l’accord de leurs parents. Pour les élèves, la CNIL indique qu’un outil grand public ne devrait pas les contraindre à créer un compte individuel, ce compte restant possible pour les outils déployés par le ministère, notamment via le GAR ; tout autre déploiement relève du chef d’établissement, avec le délégué à la protection des données, et le cadre d’usage du ministère limite l’usage par les élèves à la classe à partir de la 4e, puis à l’autonomie au lycée. Cette leçon concerne donc d’abord le supérieur et la formation d’adultes ; au collège et au lycée, elle sert à instruire la décision avec la direction.

Provisionner les comptes élèves

Trois voies de création de comptes coexistent dans ChatGPT Edu. Le SSO, ou authentification unique, fait entrer l’utilisateur avec son compte d’établissement, géré par le fournisseur d’identité de l’établissement — Microsoft Entra ID, Okta ou un autre fournisseur compatible SAML — et administré de façon centralisée ; c’est la voie à privilégier, car elle n’ajoute aucun mot de passe à retenir ni à réinitialiser. L’invitation par email ou par import d’un fichier CSV, adressée aux adresses institutionnelles, reste pratique pour un déploiement pilote. Le provisionnement automatique, via le protocole SCIM — avec Okta, Microsoft Entra ID ou Google Workspace, entre autres —, synchronise le workspace avec l’annuaire de l’établissement et se justifie dès que les mouvements d’élèves sont fréquents.

Quatre habitudes évitent les ennuis courants : n’utiliser que des adresses institutionnelles, que l’établissement maîtrise ; retirer les accès en fin d’année, en sachant que le retrait de l’espace ne supprime ni le compte OpenAI de la personne ni son espace personnel ; créer les comptes par lots, classe par classe ; documenter la procédure afin que le service informatique la reproduise sans vous.

Calibrer les limites

Tous les utilisateurs n’ont pas besoin du même accès, et l’égalité mal comprise coûte cher. Dans les paramètres de l’espace, les permissions se règlent rôle par rôle : modèles disponibles — les plus puissants, comme GPT-6 Pro, se réservent aux rôles qui en ont l’usage —, mémoire, partage de liens, projets, applications connectées. Observez ensuite la consommation réelle dans la console d’administration pendant un trimestre avant de resserrer ou d’ouvrir : personne ne devine juste du premier coup.

Restent les fonctionnalités, qui se décident selon le contexte, par les permissions de l’espace quand elles le permettent, sinon par la consigne. La recherche web est précieuse dans un projet documentaire et distrayante pendant un cours. La génération d’images se justifie pour les projets créatifs. L’analyse de fichiers devient indispensable dès que les exercices s’appuient sur des documents. La mémoire, enfin, doit être écartée lors des évaluations individuelles, sans quoi un étudiant arrive avec un contexte accumulé que ses camarades n’ont pas.

Ce que vous voyez, ce que vous ne voyez pas

La transparence sur la supervision conditionne la confiance des utilisateurs, et cette confiance conditionne l’honnêteté de leurs usages. La console d’administration affiche des statistiques d’usage — utilisateurs actifs, messages, projets —, ventilées par groupe et exportables par utilisateur. Les conversations n’y apparaissent pas, mais elles ne sont pas pour autant hors de portée : l’organisation peut y accéder à des fins de conformité, par la plateforme prévue pour les espaces Enterprise et Edu, dans la limite de la durée de conservation qu’elle a fixée. Et dans un projet partagé, les membres voient les conversations du projet.

Dites-le explicitement plutôt que de les laisser l’imaginer : ce que l’établissement peut voir, et dans quels cas, les conséquences d’un usage abusif annoncées avant qu’il ne survienne, la personne à qui signaler un problème technique ou éthique, leur droit d’accès et de suppression au titre du RGPD. Une classe à qui l’on a présenté ces règles en dix minutes les respecte mieux qu’une classe qui soupçonne une surveillance générale.

Quand ça dérape

Prévoyez la procédure avant l’incident. Une réponse graduée, conforme au règlement intérieur, fonctionne bien : au premier manquement, un rappel des règles et une discussion ; au deuxième, une restriction temporaire de l’accès ; au troisième, la suspension du compte assortie d’un entretien avec l’élève et sa famille. Annoncer cette gradation à l’avance en supprime la plupart des occasions. Les pannes techniques réclament un référent identifié, capable de réinitialiser un accès bloqué, de résoudre les incidents de SSO et d’escalader vers le support OpenAI — sans lui, tout remonte au professeur qui a introduit l’outil, ce qui le décourage vite.

Faire évoluer le cadre

Les limites posées en septembre n’ont pas vocation à durer trois ans. La progression naturelle va de limites strictes avec supervision active et formation des élèves au premier trimestre, à un assouplissement et davantage d’autonomie au deuxième, puis à un usage mature au troisième, où les limites deviennent minimales parce que l’auto-régulation a pris le relais. Un établissement encore en phase initiale en juin devrait s’interroger : soit la formation a manqué sa cible, soit personne n’a osé desserrer l’étau.

À vous de jouer

Justifier chaque réglage.

1. Reprenez le tableau de permissions d’un de vos groupes
2. Justifiez chaque ligne — modèle, fonction, accès — par une phrase d’objectif pédagogique
3. Supprimez ou corrigez les lignes qui ne résistent pas : elles recopient un réglage par défaut
4. Rédigez la note de dix lignes qui dit aux utilisateurs ce que l’établissement peut voir
5. Faites-la relire par le délégué à la protection des données

Sources officielles : Is ChatGPT safe for all ages? · Managing workspace settings in ChatGPT Enterprise · Workspace analytics for ChatGPT Enterprise and Edu · OpenAI Compliance Platform for Enterprise and Edu customers · Projects in ChatGPT · Single sign-on (SSO) setup for OpenAI products · SCIM provisioning and management · Managing members, workspace roles, and seats in ChatGPT Enterprise and Edu (centre d’aide OpenAI) · Enseignant : comment utiliser un système d’IA dans le cadre de vos missions ? (CNIL) · Les intelligences artificielles et leurs usages en éducation (éduscol)

Points clés à retenir

• Le SSO avec le fournisseur d’identité de l’établissement est la voie à privilégier
• Selon la CNIL, un outil grand public ne devrait pas contraindre l’élève à créer un compte individuel
• Réglez les permissions rôle par rôle, puis ajustez-les à la consommation réelle
• Dites clairement ce que l’établissement peut voir, y compris par ses outils de conformité
• Faites évoluer les limites progressivement selon la maturité d’usage