VN-Ch14-10AmirAI en détail

Texte de la pièce

Texte extrait du volume pour la lecture à l’écran, la recherche et la citation. Le PDF fait foi pour la mise en page des tableaux et des figures.

Complément du chapitre 14, section 14.5

14.9.2. Fournisseur, modèles et configuration

Le fournisseur est Anthropic, par son API Claude, appelée avec le SDK officiel dans l’API du serveur seulement ; le code n’en retient aucun autre. Trois modèles sont admis par la configuration, Opus 5.5, Sonnet 5.5 et Haiku 5.5. Le modèle par défaut du module est Opus 5.5, et un réglage par action le remplace, lui-même remplaçable par une variable d’environnement. Ces réglages résultent de mesures du code source : une évaluation de la relecture et des exercices sur vingt cours fictifs aux défauts plantés, avec une règle de choix écrite avant les mesures, puis 200 mesures sur dix thèmes pour les actions du second lot, la structure et le brouillon ayant été revus ensuite. Chaque évaluation a coûté environ dix dollars, juge compris. Nous citons ces évaluations comme motif de configuration et non comme preuve de qualité pédagogique, leurs jugements étant rendus par un modèle selon une grille. Le tableau VN-51 donne, par action, le rôle, le modèle et l’effort configurés et le statut.

Tableau VN-51 : Actions d’AmirAI : rôle, modèle et effort configurés, statut.

Note. Les modèles et efforts sont ceux du fichier de configuration du module d’assistant. « Présente dans le code » signifie qu’une action existe dans la branche décrite, non qu’elle soit activée sur le serveur.

14.9.3. Architecture et désactivation

L’appel est fait côté serveur : le navigateur ne communique qu’avec l’API de MANARA, qui appelle le fournisseur. L’assistant peut être désactivé ; désactivé, il est absent de l’interface. La dépense est bornée par un plafond mensuel global et par des quotas par compte, que l’administrateur peut régler.

La figure VN-49 résume le principe de fonctionnement : la requête du personnel traverse un filtre des identifiants avant d’atteindre le fournisseur du modèle par l’API de MANARA, et la réponse revient sous la forme d’une proposition que l’enseignant accepte, modifie ou rejette ; l’élève n’a aucun accès.

Figure VN-49 : Principe de fonctionnement d’AmirAI : requête du personnel, filtre des identifiants, appel côté serveur, fournisseur du modèle, réponse, proposition affichée dans l’éditeur et décision de l’enseignant ; l’élève n’a aucun accès.

Dans la figure VN-49, la décision revient toujours à l’enseignant, et le filtre est placé avant toute sortie vers le fournisseur : aucun chemin ne mène d’un compte d’élève à l’assistant.

14.9.4. Garde-fous, données et règle G5

L’élève n’ayant pas accès à l’assistant, il ne peut rien lui écrire ; la règle G5, qui interdit tout texte libre d’élève côté serveur, n’est donc pas mise en jeu par ce canal, et l’assistant ne lit ni progression, ni réponses, ni annotations. Ce qui part chez le fournisseur est limité : les cours des enseignants, les libellés d’obstacles, le programme, les consignes de l’assistant et les messages que le personnel tape ; jamais les données des comptes d’élèves ni les journaux. Un filtre retire les identifiants avant l’envoi au fournisseur.

La journalisation est volontairement réduite : le journal des appels ne garde que des compteurs d’usage, jamais le texte d’un cours ou d’une conversation, et l’historique d’une conversation n’est conservé que le temps de la séance. Les propositions sont conservées un temps limité. La couverture réglementaire du flux des cours vers un fournisseur tiers n’est pas établie.

14.9.5. État de déploiement et écarts avec la spécification

L’état d’AmirAI en production n’est pas établi par nous.

Les écarts avec la spécification se lisent contre les trois raisons qu’elle donnait pour écarter l’intelligence artificielle de la première version. La première, une variable non contrôlée pour l’étude de longue durée, n’est pas reprise par la justification consignée de l’écart, qui invoque l’aide à la rédaction et à la relecture des cours (tableau VN-49, ligne 6). La deuxième, la nécessité d’une connexion, demeure : AmirAI n’existe pas hors ligne. La troisième, la circulation de productions d’élèves mineurs vers un tiers non déclaré, est écartée par construction du côté de l’élève, qui n’a aucun accès, mais le flux des cours de l’enseignant vers le fournisseur subsiste. D’autres écarts s’ajoutent : le modèle unique initialement prévu a été remplacé par un réglage par action, retenu pour son rapport qualité prix ; le panneau de la maquette est devenu une fenêtre flottante ; la traduction attend des cours bilingues, les PDF ne sont pas admis, et les actions A8 à A11 ne sont pas livrées. Ces écarts s’ajoutent à la ligne 6 du tableau VN-49.

14.9.6. Usages pour l’enseignant et pour le chercheur, et place dans le dispositif

Pour l’enseignant, AmirAI est une aide à la conception de cours. Il relit un cours complet et signale une phase manquante ou un obstacle annoncé sans exercice ; il propose des exercices avec leurs relances et leurs indications, une structure en sept phases, le brouillon d’une activité, la transformation d’un texte collé en brouillon de cours, des termes de glossaire en français et en arabe, et le texte alternatif des images ; il répond aussi à des questions sur le cours. Toutes ces sorties sont des propositions que l’enseignant accepte, modifie ou rejette, et rien n’entre dans un cours sans son geste.

Pour le chercheur, l’assistant n’a pas d’usage direct : le chercheur n’y a aucun accès, et l’assistant n’a lui-même aucun accès aux données de recherche, traces et exports. L’assistance reste en revanche une variable de contexte pour toute analyse portant sur des cours d’enseignants, et le journal des appels, qui ne conserve que des compteurs, permet de savoir qu’il y a eu usage sans en garder le contenu.

Dans le dispositif, AmirAI s’inscrit du côté des gestes de l’enseignant, c’est-à-dire de la dimension praxéologique, et non du parcours de l’élève. Il applique à l’outil le principe de non-institutionnalisation, puisque l’autorité de valider reste humaine, et il ne remplace aucune des fonctionnalités de médiation du dispositif. Ce positionnement est une intention de conception : nous n’avons observé aucun usage de l’assistant en classe, et nous n’affirmons ni qu’il améliore les cours produits ni qu’il modifie les pratiques. Il reste à situer le dispositif actuel dans la suite des itérations qui l’ont précédé.