Achat de LLM à l’université en 2026 : déployer l’IA

Une université ne devrait pas avoir à relancer une procédure d’achat chaque fois qu’un meilleur modèle de langage apparaît. Le principe central de l’achat de LLM à l’université consiste donc à dissocier le contrat institutionnel des modèles utilisés en arrière-plan.

Une API unifiée offre à l’université une couche contractuelle, sécuritaire et de gouvernance unique, tout en permettant aux applications approuvées d’utiliser des modèles provenant de plusieurs fournisseurs. Le choix des modèles peut ainsi évoluer en fonction du coût, des capacités, de la localisation des données et de la classification des risques, sans nécessiter un nouveau contrat pour chaque modèle.

Ce guide explique comment les établissements européens d’enseignement supérieur peuvent acheter et déployer des services LLM en 2026, notamment en ce qui concerne :

• les marchés publics et les accords-cadres proposés par les NREN ;
• les évaluations HECVAT et les contrôles d’accessibilité ;
• les exigences relatives à l’AIPD et à l’analyse d’impact sur les droits fondamentaux ;
• les modèles de coûts par utilisateur et par pool de tokens ;
• les politiques de routage fondées sur les risques ;
• les protections contractuelles ;
• le SSO, les quotas, la journalisation et le déploiement progressif.

Le modèle d’achat d’IA à l’université en 2026

L’achat d’IA dans l’enseignement supérieur se distingue d’un achat classique de logiciel d’entreprise sur trois aspects.

Obligations en matière de marchés publics

Les universités publiques peuvent être considérées comme des pouvoirs adjudicateurs au titre de la directive 2014/24/UE sur la passation des marchés publics. Au-dessus du seuil européen applicable, l’établissement doit recourir à une procédure de mise en concurrence appropriée. En dessous de ce seuil, les règles nationales de passation des marchés et les politiques internes d’achat continuent de s’appliquer.

Les seuils applicables en 2026 dépendent du type de pouvoir adjudicateur et de la nature du contrat. Les universités doivent vérifier le seuil en vigueur et les règles nationales de transposition auprès de leur service des achats, plutôt que de supposer qu’un projet pilote d’IA peut faire l’objet d’une attribution directe.

Une justification de fournisseur unique reposant uniquement sur le nom d’un modèle privilégié reste fragile. Le cahier des charges devrait plutôt décrire des exigences fonctionnelles telles que :

• les cas d’usage pris en charge ;
• la latence et la disponibilité ;
• les lieux de traitement situés en Europe ;
• les exigences de conservation nulle des données ;
• la fédération des identités ;
• la journalisation et l’auditabilité ;
• la portabilité des modèles ;
• l’accessibilité ;
• l’interopérabilité avec les applications existantes.

Cette approche évite de construire un appel d’offres autour d’un seul produit commercial.

Accords-cadres et services des NREN

Les universités européennes peuvent souvent raccourcir leur processus d’achat en passant par les réseaux nationaux de recherche et d’éducation ou par des accords-cadres cloud existants.

L’accord-cadre GÉANT OCRE 2024 est entré en vigueur le 3 février 2025 et restera applicable jusqu’en février 2030. Il couvre des centaines d’offres IaaS, PaaS et SaaS dans 39 pays participants. Les établissements de recherche et d’enseignement éligibles peuvent acheter des services par attribution directe, mini-concours ou mini-concours sur dossier, sous réserve des modalités nationales de mise en œuvre.

L’infrastructure d’authentification peut être fournie séparément du canal d’achat commercial :

• DFN-AAI fournit des services fédérés d’authentification et d’autorisation aux établissements allemands de recherche et d’enseignement et participe à eduGAIN ;
• la Fédération Éducation-Recherche de RENATER propose une fédération d’identités basée sur SAML 2 pour l’enseignement supérieur et la recherche en France ;
• d’autres NREN proposent des services équivalents en matière d’achat, de réseau ou d’identité dans leurs pays respectifs.

GÉANT, DFN-AAI et RENATER ne remplissent pas la même fonction. GÉANT OCRE constitue principalement un accord-cadre d’achat, tandis que les services de fédération de DFN-AAI et de RENATER concernent l’identité et la confiance numérique. Une architecture universitaire peut utiliser les deux.

Gouvernance institutionnelle distribuée

Les décisions d’achat d’une université sont rarement contrôlées par un seul service. Un déploiement en production peut nécessiter l’approbation ou la contribution des parties prenantes suivantes :

• la DSI ou la direction de la transformation numérique ;
• le service des achats ;
• le DPO ;
• l’équipe de sécurité des systèmes d’information ;
• le service juridique ;
• les spécialistes de l’accessibilité ;
• les équipes pédagogiques ;
• les représentants du corps enseignant ;
• les représentants des étudiants ;
• les responsables de la gestion documentaire ;
• les comités d’éthique de la recherche ou d’intégrité académique.

EDUCAUSE a constaté que les équipes chargées des technologies, de la cybersécurité et de la protection de la vie privée participent fréquemment aux achats d’IA. En revanche, les professionnels de l’enseignement et de l’apprentissage n’étaient impliqués que dans 58 % des établissements interrogés, alors même qu’ils sont directement concernés par ces outils.

Un modèle de gouvernance opérationnel doit attribuer clairement les droits de décision avant le début de l’évaluation des fournisseurs. Le DPO ne devrait pas être chargé de définir la politique pédagogique, et les comités d’enseignants ne devraient pas avoir à approuver les contrôles techniques de sécurité.

Comparaison des parcours d’achat de LLM à l’université

Les délais présentés ci-dessous sont des estimations destinées à la planification. La durée réelle dépend de la valeur du contrat, du droit national, des seuils internes de l’établissement, de la disponibilité d’un accord-cadre et de l’exhaustivité de la documentation fournie par le prestataire.

Une API unifiée ne dispense pas l’établissement de respecter le droit des marchés publics. Son avantage est à la fois architectural et contractuel : l’appel d’offres peut porter sur une couche d’accès à l’IA gouvernée, plutôt que sur un modèle désigné.

Une fois la passerelle approuvée, l’université peut ajouter, retirer ou remplacer les modèles sous-jacents dans le respect de contrôles contractuels et de règles de gestion des risques prédéfinis. Le contrat reste stable, même lorsque le catalogue de modèles évolue.

Suggestion de schéma : diagramme horizontal comparant l’achat direct auprès d’un fournisseur, l’appel d’offres public, le recours à un accord-cadre NREN et l’achat d’une API unifiée. Le schéma indique, pour chaque parcours, le nombre de contrats, d’évaluations et d’autorisations nécessaires pour changer de modèle.

Texte alternatif : « Comparaison de quatre parcours d’achat de LLM à l’université, présentant la durée de la procédure, le nombre de contrats, les évaluations de conformité et la possibilité de changer de modèle d’IA. »

Évaluations HECVAT, ERAT et accessibilité

Utiliser le HECVAT comme dossier de preuves du fournisseur

Le Higher Education Community Vendor Assessment Toolkit, ou HECVAT, est un questionnaire d’évaluation des risques fournisseurs développé par la communauté de l’enseignement supérieur avec EDUCAUSE, Internet2 et REN-ISAC.

La version 4 du HECVAT couvre notamment :

• la cybersécurité ;
• la protection de la vie privée ;
• l’intelligence artificielle et le machine learning ;
• la gestion du cycle de vie des données ;
• les dépendances à des tiers ;
• l’accessibilité informatique ;
• la conformité réglementaire.

EDUCAUSE présente le HECVAT 4.1.6 comme la version actuelle et confirme que la quatrième version a ajouté des questions spécifiques sur la protection de la vie privée et l’intelligence artificielle.

Dans le cadre d’une intégration directe de plusieurs fournisseurs, l’université peut devoir examiner un questionnaire HECVAT, ou un dossier de preuves équivalent, pour chaque fournisseur de modèles sous contrat. Avec une API unifiée, l’établissement évalue une seule fois le fournisseur de la passerelle, puis vérifie la manière dont celui-ci sélectionne, contractualise et supervise ses sous-traitants ultérieurs.

La réponse HECVAT du fournisseur de la passerelle doit néanmoins préciser :

• chaque catégorie pertinente de sous-traitants ultérieurs ;
• la procédure d’ajout ou de retrait des sous-traitants ultérieurs ;
• les exigences de sécurité imposées aux fournisseurs ;
• les lieux de traitement des requêtes et des journaux ;
• les fournisseurs qui conservent les prompts ;
• la manière dont les incidents affectant un fournisseur sont signalés ;
• les obligations d’accessibilité applicables à l’interface de la passerelle.

« Une seule évaluation » ne doit pas signifier « aucune visibilité sur la chaîne de sous-traitance ».

ERAT et normes locales d’évaluation des risques

Certains établissements utilisent également un ERAT interne, un outil d’évaluation des risques d’entreprise ou un processus équivalent d’évaluation des risques technologiques. La signification exacte de l’acronyme et le modèle de notation peuvent varier d’un système universitaire à l’autre.

Lorsqu’un processus ERAT existe, les équipes chargées des achats doivent rapprocher les preuves fournies par la passerelle des familles de contrôles utilisées par l’établissement, plutôt que de recommencer une évaluation indépendante depuis le début.

Les correspondances concernent généralement :

• la gestion des identités et des accès ;
• le chiffrement ;
• la continuité d’activité ;
• la réponse aux incidents ;
• la gestion des fournisseurs ;
• la protection de la vie privée ;
• l’accessibilité ;
• la conservation des données ;
• la gestion des changements.

Le HECVAT fournit les preuves relatives au fournisseur. Le processus ERAT ou d’évaluation des risques de l’établissement détermine si ces preuves correspondent à son niveau de risque acceptable.

L’accessibilité est une exigence contractuelle

L’accessibilité doit être évaluée avant l’attribution du marché, et non ajoutée ultérieurement au backlog de mise en œuvre. Le HECVAT 4 comprend une section consacrée à l’accessibilité, et EDUCAUSE recommande aux fournisseurs de respecter ou de dépasser le niveau AA des WCAG 2.1, ou toute norme plus récente applicable.

Pour un achat principalement destiné à l’Union européenne, l’appel d’offres doit mentionner les exigences d’accessibilité applicables dans l’État membre concerné, notamment la norme EN 301 549 et les critères WCAG.

Pour les établissements américains, le cadre juridique correspondant peut inclure l’Americans with Disabilities Act, la Section 504 et la Section 508. Les exigences de l’ADA constituent l’équivalent américain et ne font pas partie du processus d’achat européen.

L’université doit demander :

• un rapport de conformité en matière d’accessibilité à jour ou, le cas échéant, un VPAT ;
• la version des WCAG testée et le niveau de conformité atteint ;
• les résultats des tests au clavier et avec des lecteurs d’écran ;
• des informations sur l’accessibilité des fichiers générés et des exports ;
• une feuille de route de mise en conformité ;
• des délais contractuels de correction ;
• une notification préalable en cas de modification de l’interface susceptible d’affecter l’accessibilité.

Classer les cas d’usage de l’IA avant de sélectionner les modèles

Une université ne devrait pas appliquer la même procédure d’approbation à la synthèse de notes de cours et à la notation automatisée des candidatures. Le modèle à trois niveaux présenté ci-dessous constitue un point de départ pratique pour classer les cas d’usage selon leur niveau de risque.

Les politiques de routage doivent appliquer techniquement la classification des risques.

Par exemple :

• un routage à faible risque peut autoriser plusieurs fournisseurs internationaux ;
• un routage à risque moyen peut autoriser uniquement les fournisseurs appliquant une politique de non-conservation des données dans des régions approuvées ;
• un routage à haut risque peut imposer une version précise d’un modèle validé et bloquer tout mécanisme de fallback automatique ;
• les prompts contenant des données relevant de catégories particulières peuvent être rejetés ou redirigés vers un déploiement privé ;
• chaque application peut disposer de ses propres clés API, budgets et listes de modèles autorisés.

Cette approche est plus fiable que de demander à chaque utilisateur de sélectionner manuellement un modèle conforme.

AIPD pour les déploiements d’IA

En vertu de l’article 35 du RGPD, une analyse d’impact relative à la protection des données, ou AIPD, doit être réalisée avant tout traitement susceptible d’engendrer un risque élevé pour les droits et libertés des personnes, notamment lorsqu’il implique l’utilisation de nouvelles technologies.

Toutes les expérimentations impliquant un LLM ne nécessitent pas automatiquement une AIPD complète. L’établissement doit d’abord effectuer et documenter une analyse préliminaire visant à déterminer si une AIPD est nécessaire.

Une évaluation complète est davantage susceptible d’être requise lorsque l’application implique :

• une évaluation systématique ou un profilage ;
• des personnes vulnérables, notamment des étudiants ;
• un traitement à grande échelle de données personnelles ;
• des données relevant de catégories particulières ;
• une activité de surveillance ;
• des décisions automatisées ou assistées par l’IA ;
• de nouvelles combinaisons de jeux de données institutionnels ;
• des conséquences sur l’accès à l’éducation ou la progression des étudiants.

Les orientations du Contrôleur européen de la protection des données sur l’IA générative et le règlement européen relatif à la protection des données s’adressent officiellement aux institutions, organes et organismes de l’Union européenne. Elles ne sont pas directement contraignantes pour les universités ordinaires relevant des États membres, mais constituent une référence utile pour la gouvernance de l’IA générative dans le secteur public.

Les institutions de l’Union européenne doivent respecter le règlement 2018/1725 relatif à la protection des données au sein des institutions européennes, plutôt que le RGPD dans les mêmes conditions qu’une université nationale. Les orientations du CEPD insistent notamment sur l’implication précoce du DPO, la documentation tout au long du cycle de vie, la base juridique, la limitation des finalités et la réalisation d’une AIPD pour les traitements susceptibles de présenter un risque élevé.

Une AIPD universitaire doit documenter les éléments suivants.

1. Finalité et base juridique : Définir la finalité pédagogique ou administrative, le responsable du traitement, les sous-traitants et la base juridique applicable.
2. Système et flux de données : Identifier l’application, la passerelle, le fournisseur du modèle, les régions d’hébergement, les sous-traitants ultérieurs, les journaux et les accès accordés aux équipes d’assistance.
3. Catégories de données : Distinguer les données personnelles ordinaires, les données relevant de catégories particulières, les données de recherche confidentielles et les contenus ne contenant pas de données personnelles.
4. Nécessité et proportionnalité : Expliquer pourquoi l’utilisation d’un LLM est nécessaire et déterminer si une méthode moins intrusive permettrait d’obtenir le même résultat.
5. Risques pour les personnes : Prendre en compte les risques de divulgation, de génération de données personnelles erronées, de biais, d’exclusion, de perte de confidentialité, de surveillance excessive et de décisions incorrectes.
6. Mesures d’atténuation : Prévoir notamment la minimisation des données, la non-conservation des données, le routage régional, le chiffrement, le contrôle des accès fondé sur les rôles, la supervision humaine, les limites de conservation et les procédures de gestion des incidents.
7. Risque résiduel et consultation : Consigner l’avis du DPO et déterminer si une consultation préalable de l’autorité de contrôle est nécessaire.

Pour obtenir davantage d’informations sur la mise en œuvre, ajoutez un lien vers la page de l’établissement ou du fournisseur consacrée à la sécurité, au DPA et à la politique ZDR d’Eden AI.

FRIA pour les systèmes d’IA à haut risque dans l’éducation

Une AIPD et une analyse d’impact sur les droits fondamentaux, ou FRIA, sont liées, mais ne sont pas interchangeables.

Dans le cadre du règlement européen sur l’intelligence artificielle 2024/1689, l’Annexe III classe comme systèmes à haut risque certains systèmes utilisés dans les domaines de l’éducation et de la formation professionnelle.

Il s’agit notamment des systèmes utilisés pour :

• déterminer l’accès ou l’admission à un établissement ;
• affecter des personnes à des établissements ou à des programmes éducatifs ;
• évaluer les acquis d’apprentissage lorsque le résultat influence le parcours éducatif ;
• évaluer le niveau d’éducation approprié ;
• surveiller ou détecter des comportements interdits pendant des examens.

Lorsqu’une université de droit public déploie un système d’IA à haut risque relevant de ces dispositions, l’article 27 peut imposer la réalisation d’une analyse d’impact sur les droits fondamentaux avant sa première utilisation. La FRIA doit alors être réalisée parallèlement à l’AIPD.

Les deux documents peuvent partager :

• la description du système ;
• la finalité prévue ;
• les utilisateurs et les groupes concernés ;
• les schémas des flux de données ;
• les informations sur le fournisseur et le déploiement ;
• les mécanismes de supervision humaine.

Ils doivent toutefois conserver des registres de risques distincts. Un outil utilisé pour la notation ou les admissions peut donc nécessiter à la fois une AIPD et une FRIA, même lorsqu’une grande partie de la description factuelle du système est réutilisée dans les deux évaluations.

Modèles budgétaires : licences par utilisateur ou pool de tokens

Le coût n’est pas une question secondaire. Dans le QuickPoll 2025 d’EDUCAUSE, 32 % des répondants ont identifié le coût ou l’absence de budget comme un obstacle majeur à l’achat de solutions d’IA, tandis que 21 % ont cité le manque de transparence des conditions contractuelles des fournisseurs.

Les estimations publiées pour la planification budgétaire dans l’enseignement supérieur situent généralement le coût des licences d’IA d’entreprise entre 140 et 300 dollars par utilisateur et par an, selon le produit, les fonctionnalités incluses, les engagements minimaux et les conditions négociées.

Au bas de cette fourchette :

• 4 000 étudiants disposant d’une licence coûtent environ 560 000 dollars par an ;
• 10 000 utilisateurs disposant d’une licence coûtent environ 1,4 million de dollars par an ;
• 20 000 utilisateurs disposant d’une licence coûtent environ 2,8 millions de dollars par an.

Cela explique pourquoi l’attribution d’une licence à l’ensemble des étudiants peut dépasser 500 000 dollars par an, avant même de prendre en compte les coûts d’intégration, d’assistance, de formation et de gouvernance. EDUCAUSE souligne également que de nombreux établissements ne peuvent pas financer des licences d’IA à l’échelle de toute l’organisation et envisagent donc les API comme une solution alternative.

Licence par utilisateur

Modèle : l’établissement paie une licence mensuelle ou annuelle fixe pour chaque utilisateur autorisé.

En utilisant le milieu de la fourchette de référence : 5 000 utilisateurs × 220 dollars par utilisateur et par an = 1 100 000 dollars de licences annuelles. Le contrat réel peut également inclure des volumes minimaux, des frais de mise en œuvre, différents niveaux d’assistance ou des frais supplémentaires pour l’utilisation d’API premium.

Achat d’un pool de tokens

Modèle : l’établissement achète un volume partagé d’utilisation des API ou reçoit une facture correspondant à sa consommation. Les départements et les applications utilisent un pool commun soumis à des règles de gouvernance.

Exemple de calcul pour un pool de tokens

Les chiffres Eden AI ci-dessous sont fournis à titre illustratif. Ils ne constituent ni un devis ni une garantie d’économies. Les tarifs des fournisseurs et la disponibilité des modèles évoluent. La composition finale des modèles doit donc être vérifiée dans le catalogue en temps réel et sur la page [Tarifs d’Eden AI].

Hypothèses :

• 500 enseignants utilisateurs ;
• 25 % d’utilisateurs actifs lors d’une journée ouvrée moyenne ;
• 40 000 tokens d’entrée et 10 000 tokens de sortie par utilisateur actif ;
• 22 jours ouvrés par mois.

125 utilisateurs actifs par jour × 50 000 tokens au total × 22 jours = 137 500 000 tokens par mois.

Supposons que le routage produise un coût fournisseur moyen indicatif de :

• 2,50 dollars par million de tokens d’entrée ;
• 10 dollars par million de tokens de sortie ;
• 80 % de tokens d’entrée et 20 % de tokens de sortie.

Entrée : 110 millions × 2,50 dollars par million = 275 dollars
Sortie : 27,5 millions × 10 dollars par million = 275 dollars

Coût fournisseur indicatif : 550 dollars par mois.
Coût fournisseur annuel indicatif : 6 600 dollars.

Ce calcul ne comprend pas la mise en œuvre, l’assistance, le développement d’un portail, l’utilisation de modèles premium, l’infrastructure de recherche documentaire ni les niveaux de service contractuels.

Pour un déploiement en production, un budget prudent pourrait fixer un plafond nettement plus élevé, par exemple entre 2 500 et 5 000 dollars par mois, jusqu’à ce que les habitudes réelles d’utilisation soient établies.

L’objectif n’est pas d’affirmer que chaque université dépensera 550 dollars par mois. L’intérêt est que la consommation de tokens peut être mesurée directement, tandis qu’une licence est facturée même lorsque l’utilisateur ne l’utilise pas.

Prévisibilité : la principale objection à la tarification par tokens

Les fournisseurs proposant une tarification fixe avancent que les licences par utilisateur sont plus sûres, car le budget est connu à l’avance. Cette préoccupation est légitime. Un déploiement fondé sur un pool de tokens sans mécanisme de contrôle peut générer des factures imprévisibles.

La solution n’est pas d’autoriser une consommation illimitée, mais d’appliquer les mêmes contrôles que pour une infrastructure cloud :

• un plafond mensuel de dépenses pour l’établissement ;
• un quota par utilisateur ;
• un quota par département ;
• des limites distinctes pour les étudiants, les enseignants et les applications ;
• une limite maximale de tokens de sortie ;
• des limites de débit ;
• des plafonds de coûts propres à chaque modèle ;
• un processus d’approbation pour les modèles premium ;
• des alertes lorsque 50 %, 75 % et 90 % du budget sont atteints ;
• un routage automatique vers un modèle moins coûteux au-delà d’un certain seuil ;
• un blocage automatique lorsque le plafond approuvé est atteint.

Par exemple :

• plafond annuel de l’établissement : 120 000 dollars ;
• plafond opérationnel mensuel : 10 000 dollars ;
• quota des enseignants : 20 dollars par mois ;
• quota des étudiants : 5 dollars par mois ;
• accès aux modèles premium : réservé aux projets approuvés.

La dépense annuelle maximale devient alors aussi prévisible qu’avec une licence fixe, tandis que les dépenses réelles attendues restent inférieures, puisque les allocations inutilisées ne sont pas automatiquement facturées.

Une université peut également négocier un plafond annuel fixe accompagné d’un rapport mensuel sur la consommation. Cette approche associe la prévisibilité budgétaire nécessaire aux achats institutionnels à une allocation fondée sur l’usage réel.

Checklist des fournisseurs et des clauses contractuelles

Le contrat doit couvrir la passerelle, les fournisseurs de modèles sous-jacents et les applications institutionnelles comme une seule chaîne de services.

Comment évaluer le modèle de DPA unique d’Eden AI

Eden AI présente sa plateforme comme une API et une couche de facturation uniques permettant d’accéder à des centaines de modèles. Sa documentation tarifaire publique indique que les clients en libre-service paient les tarifs des fournisseurs auxquels s’ajoutent 5,5 % de frais de plateforme. Les contrats Advanced peuvent inclure une facturation personnalisée, des limites plus élevées, des déploiements privés et une assistance dédiée.

Pour une université, un DPA unique doit signifier que :

• Eden AI est le principal sous-traitant contractuel de l’établissement pour le service de passerelle ;
• les fournisseurs de modèles concernés sont documentés comme sous-traitants ultérieurs ou se voient attribuer un rôle juridique clairement défini ;
• le DPA précise comment sont appliquées les restrictions propres à chaque fournisseur en matière de conservation, de localisation des données et d’utilisation pour l’entraînement ;
• les changements de sous-traitants ultérieurs déclenchent la procédure de notification convenue ;
• l’université peut limiter la liste des fournisseurs autorisés ;
• l’université peut exporter ses données d’utilisation et de configuration ;
• la résiliation du contrat déclenche les obligations de suppression et de transition.

L’établissement doit vérifier ces points dans le contrat proposé plutôt que de se fier uniquement à l’expression « DPA unique ».

Architecture de déploiement : du pilote à la production

Phase 1 : pilote contrôlé, mois 1 à 3

Périmètre : 10 à 20 enseignants et utilisateurs administratifs issus de plusieurs départements.

Tâches :

• définir deux ou trois cas d’usage autorisés ;
• exclure la notation, les admissions et les décisions relatives à la progression des étudiants ;
• réaliser une analyse préliminaire afin de déterminer si une AIPD est nécessaire ;
• sélectionner deux ou trois modèles autorisés ;
• configurer des quotas par utilisateur ;
• établir des règles de traitement des prompts et des réponses ;
• journaliser les coûts, la latence, le taux d’erreur et les modèles sélectionnés ;
• recueillir les retours des utilisateurs à l’aide d’une grille d’évaluation commune ;
• interdire les données relevant de catégories particulières et les données de recherche confidentielles, sauf autorisation explicite.

Le pilote doit répondre à des questions d’achat et de déploiement, et non simplement démontrer qu’un LLM est capable de générer du texte.

Les indicateurs à suivre comprennent :

• le nombre d’utilisateurs actifs ;
• le nombre de tokens par utilisateur actif ;
• le coût par tâche accomplie ;
• le taux d’échec des modèles ;
• le temps de correction humaine ;
• le taux d’abandon par cas d’usage ;
• les violations des règles relatives aux données ;
• les problèmes d’accessibilité ;
• le volume de demandes d’assistance.

Exemple fonctionnel de routage en Python

L’exemple suivant utilise le format de chat completions compatible avec l’API OpenAI proposé par Eden AI. Les identifiants des modèles doivent être vérifiés dans le catalogue en temps réel avant tout déploiement.

import os
from typing import Final

import requests
from requests import Response

API_URL: Final = "https://api.edenai.run/v3/chat/completions"
API_KEY: Final = os.environ["EDENAI_API_KEY"]

# The application chooses a policy route.
# End users do not select arbitrary providers.
MODEL_ROUTES: Final = {
    "low_risk_general": "openai/gpt-4o-mini",
    "structured_writing": "anthropic/claude-sonnet-4",
    "multilingual": "google/gemini-2.5-flash",
    "eu_restricted": "mistral/mistral-small-latest",
}

MAX_OUTPUT_TOKENS: Final = {
    "low_risk_general": 800,
    "structured_writing": 1_500,
    "multilingual": 1_000,
    "eu_restricted": 800,
}


def call_university_llm(
    route: str,
    prompt: str,
    user_reference: str,
) -> dict:
    """Send a request through an institution-approved model route."""

    if route not in MODEL_ROUTES:
        raise ValueError(f"Unapproved route: {route}")

    payload = {
        "model": MODEL_ROUTES[route],
        "messages": [
            {
                "role": "system",
                "content": (
                    "Do not infer sensitive personal data. "
                    "Flag uncertainty and require human review for decisions."
                ),
            },
            {"role": "user", "content": prompt},
        ],
        "max_tokens": MAX_OUTPUT_TOKENS[route],
        "temperature": 0.2,
        "metadata": {
            # Use a pseudonymous internal reference, not a student name.
            "institution_user_reference": user_reference,
            "policy_route": route,
        },
    }

    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }

    response: Response = requests.post(
        API_URL,
        headers=headers,
        json=payload,
        timeout=60,
    )

    try:
        response.raise_for_status()
    except requests.HTTPError as exc:
        raise RuntimeError(
            f"LLM request failed with status {response.status_code}"
        ) from exc

    return response.json()


result = call_university_llm(
    route="structured_writing",
    prompt="Draft a rubric for a first-year economics presentation.",
    user_reference="faculty-7f18c2",
)

print(result)

‍

Les applications en production doivent également intégrer :

• une gestion sécurisée des secrets ;
• une journalisation d’audit structurée ;
• une validation de la taille des prompts ;
• une détection des données personnelles lorsque cela est pertinent ;
• des règles de nouvelle tentative et de fallback ;
• une attribution des coûts ;
• une authentification au niveau de chaque application ;
• une modération des réponses ;
• des contrôles de conservation ;
• une surveillance du retrait des modèles.

Pour les cas d’usage à haut risque, le fallback automatique doit généralement être désactivé. Un modèle de secours peut ne pas présenter le même comportement validé, la même documentation ou le même statut de conformité que le système principal.

Phase 2 : déploiement à l’échelle d’un département, mois 4 à 6

Périmètre : environ 100 à 300 utilisateurs ou plusieurs applications approuvées.

Tâches :

• intégrer SAML ou OIDC au fournisseur d’identité de l’université ;
• se connecter à DFN-AAI, RENATER ou à une autre fédération, lorsque cela est applicable ;
• mettre en place un accès aux modèles fondé sur les rôles ;
• attribuer des budgets aux différents départements ;
• créer des clés API distinctes pour chaque application ;
• réaliser une AIPD complète lorsque cela est nécessaire ;
• documenter le registre des fournisseurs autorisés ;
• ajouter des routes limitées à l’Union européenne et des routes ZDR ;
• intégrer le suivi des coûts et de la sécurité ;
• créer des procédures de gestion des incidents et de retrait des modèles ;
• former les administrateurs locaux et les équipes d’assistance.

L’université doit également définir qui est autorisé à déployer des applications LLM. Fournir une clé API à chaque enseignant sans procédure d’examen des applications revient à recréer du shadow IT derrière une facture centralisée.

Phase 3 : déploiement à l’échelle de l’établissement, mois 7 à 12

Périmètre : enseignants, personnel, étudiants éligibles et applications en production.

Tâches :

• intégrer Moodle, Canvas ou un autre LMS lorsque cela est justifié ;
• appliquer des politiques distinctes aux usages étudiants, administratifs, pédagogiques et liés à la recherche ;
• ajouter un routage automatisé en fonction des coûts pour les tâches à risque faible ou moyen ;
• conserver des versions fixes des modèles pour les systèmes à haut risque ;
• organiser une revue trimestrielle des fournisseurs et des modèles ;
• publier un catalogue des cas d’usage autorisés ;
• définir une procédure de dérogation ;
• réexaminer l’AIPD après toute modification importante ;
• réaliser une FRIA pour les déploiements à haut risque concernés ;
• auditer les contrôles d’accessibilité et de supervision humaine ;
• tester les procédures de sortie et de portabilité ;
• comparer le coût réel de chaque cas d’usage aux solutions fondées sur des licences.

Exigences propres aux déploiements dans l’Union européenne

Localisation des données et transferts internationaux

Le RGPD n’interdit pas systématiquement le traitement des données en dehors de l’Espace économique européen. Il impose toutefois un mécanisme de transfert licite et des garanties appropriées lorsque des données personnelles sont transférées vers un pays tiers.

L’équipe chargée des achats doit donc poser les questions suivantes :

• Où sont traités les prompts, les fichiers, les embeddings, les journaux et les sauvegardes ?
• La région de traitement est-elle garantie contractuellement ou seulement sélectionnée dans un tableau de bord ?
• Les équipes d’assistance peuvent-elles accéder aux données depuis l’extérieur de l’EEE ?
• Quel mécanisme de transfert est appliqué ?
• L’établissement a-t-il réalisé l’évaluation d’impact sur les transferts éventuellement requise ?
• Un mécanisme de fallback peut-il envoyer les requêtes vers une autre région ?
• L’API peut-elle rejeter une requête lorsqu’aucune route européenne n’est disponible ?

La simple mention d’un « endpoint européen » ne constitue pas une preuve suffisante. Le schéma des flux de données doit couvrir l’ensemble de la chaîne de services.

Exigences du règlement européen sur l’IA dans l’éducation

Le règlement européen sur l’intelligence artificielle repose sur une approche fondée sur les risques. La qualification juridique dépend de la finalité prévue du système, et non du simple fait qu’il utilise un LLM.

Un assistant général de rédaction n’est pas automatiquement considéré comme un système à haut risque. En revanche, un système qui influence de manière significative l’admission, l’évaluation, la progression ou l’accès à l’éducation peut relever de l’Annexe III.

Pour les systèmes d’IA à haut risque utilisés dans l’éducation, le dossier d’achat doit obtenir ou attribuer clairement la responsabilité des éléments suivants :

• la documentation relative à la gestion des risques ;
• les informations sur la gouvernance des données ;
• la documentation technique ;
• les instructions d’utilisation ;
• la journalisation ;
• la supervision humaine ;
• l’exactitude, la robustesse et la cybersécurité ;
• la surveillance après la mise sur le marché ;
• la notification des incidents ;
• les obligations du déployeur ;
• l’assistance à la réalisation d’une FRIA lorsque cela est nécessaire.

L’université doit distinguer le fournisseur du modèle, le fournisseur de la passerelle, le développeur de l’application et le déployeur. Chacun peut assumer un rôle juridique différent au titre du règlement européen sur l’IA.

FERPA comme équivalent américain

Le FERPA ne doit pas être intégré au processus RGPD d’une université européenne, sauf si l’établissement traite également des dossiers éducatifs américains ou fournit des services à une entité située aux États-Unis.

Pour les établissements américains, le FERPA constitue le cadre fédéral applicable à la confidentialité des dossiers scolaires. Il représente l’exigence équivalente aux États-Unis, aux côtés des lois des États sur la protection de la vie privée et des politiques internes des établissements.

Un cahier des charges européen doit se référer en priorité au RGPD, au droit national de la protection des données et au règlement européen sur l’IA.

La place d’une API unifiée

Le marché de l’IA évolue plus rapidement que les cycles d’achat des universités. Un cahier des charges construit autour d’un seul modèle peut devenir obsolète avant même la signature du contrat.

Une API unifiée modifie l’objet de l’achat. L’université achète :

• un accès authentifié aux services d’IA ;
• une API standardisée ;
• une facturation consolidée ;
• une gouvernance des modèles et des fournisseurs ;
• des mécanismes de routage ;
• un suivi de l’utilisation ;
• des contrôles de localisation des données ;
• des contrôles de conservation ;
• la portabilité des modèles ;
• une assistance opérationnelle.

Elle n’a pas besoin de s’engager durablement auprès d’un seul modèle.

Eden AI constitue un exemple de cette architecture. Son offre doit être évaluée selon les mêmes critères neutres que toute autre passerelle :

• Prend-elle en charge les modèles requis par l’établissement ?
• L’université peut-elle restreindre les fournisseurs et les régions ?
• Les conditions ZDR peuvent-elles être imposées techniquement ?
• Existe-t-il un canal d’assistance unique et clairement responsable ?
• Les coûts sont-ils visibles par modèle, application et département ?
• L’université peut-elle appliquer des plafonds stricts ?
• Les changements de modèles sont-ils communiqués ?
• L’établissement peut-il exporter ses données et ses configurations ?
• Des déploiements privés ou dédiés sont-ils disponibles lorsque cela est nécessaire ?
• Le DPA décrit-il clairement les fournisseurs en aval ?

L’argument d’achat le plus solide n’est pas l’accès à un plus grand nombre de modèles. Il réside dans la possibilité de changer de modèle sans devoir reconstruire le contrat institutionnel, la couche d’identité, les contrôles de coûts et le processus de gouvernance.

FAQ sur l’achat de LLM à l’université