flowchart LR A[Ressources et infrastructures] --> B[Modèles] B --> C[Plateformes et API] C --> D[Intégrations institutionnelles] D --> E[Pratiques et routines] E --> F[Contenus et compétences] F --> G[Dépendance accrue] G --> H[Coût de sortie]
Chapitre 3 : Plateformes et dépendances : préserver les missions de l’université
Infrastructures, coûts de dépendance, souveraineté et soutenabilité universitaire
À partir de quel moment un outil d’IA cesse-t-il d’être un simple service pour devenir une infrastructure qui façonne durablement les pratiques, les coûts et les marges de décision de l’université ?
Mots-clés
Infrastructure numérique Plateforme Dépendance de plateforme Vendor lock-in Coût de sortie Réversibilité Souveraineté numérique Captation de valeur Coûts cachés Soutenabilité Interdépendance Capacité d’arbitrage
Ce chapitre prolonge directement les chapitres 2.1 et 2.2 en vous aidant à :
- Passer de la protection des données et du choix d’un environnement à l’analyse de ce qui se produit dans la durée ;
- Comprendre comment un outil devient progressivement une infrastructure par l’accumulation des usages, contenus, intégrations, compétences et routines ;
- Identifier les coûts visibles et invisibles d’une plateforme, y compris ceux qui apparaissent au moment de la migration ou de la sortie ;
- Distinguer dépendance, interdépendance et perte de capacité d’arbitrage ;
- Examiner la gratuité comme un modèle de circulation et de captation de valeur plutôt que comme une absence de coût ;
- Déplacer l’évaluation d’un outil de la seule performance vers sa compatibilité avec les missions, les valeurs et la capacité future de décision de l’université ;
- Faire de la réversibilité un critère de conception et non une question posée seulement lorsqu’il devient nécessaire de changer d’outil.
Repères essentiels
Notions essentielles du chapitre
| Notion | Définition courte | Question institutionnelle associée |
|---|---|---|
Infrastructure numérique |
Ensemble de ressources techniques, organisationnelles et contractuelles devenues nécessaires au fonctionnement d’activités. | Que se passe-t-il si cette ressource devient indisponible demain ? |
Dépendance de plateforme |
Situation dans laquelle pratiques, données, compétences ou processus deviennent difficiles à dissocier d’une plateforme. | Jusqu’où pouvons-nous encore changer de solution ? |
Vendor lock-in |
Dépendance qui augmente le coût ou la difficulté d’un changement de fournisseur. | Quels éléments rendent la sortie difficile ? |
Coût de sortie |
Ressources techniques, humaines, financières et organisationnelles nécessaires pour quitter ou remplacer une solution. | Avons-nous évalué le coût de quitter l’outil autant que celui d’y entrer ? |
Captation de valeur |
Mécanisme par lequel une plateforme transforme usages, données, attention, contenus ou dépendances en valeur économique ou stratégique. | Que reçoit réellement le fournisseur en échange du service ? |
Souveraineté numérique |
Capacité à conserver des choix effectifs sur les infrastructures, données et conditions de fonctionnement. | Restons-nous capables de décider et de changer ? |
Soutenabilité |
Capacité d’un dispositif à rester compatible dans la durée avec les ressources, finalités et valeurs de l’institution. | Pourrons-nous maintenir ce choix sans fragiliser nos missions ? |
Capacité d’arbitrage |
Capacité à comparer, choisir, contester et modifier les solutions en fonction des finalités institutionnelles. | L’institution garde-t-elle réellement plusieurs options ? |
Introduction
Le chapitre 2.1 posait une première question : qu’est-ce que l’usage expose ?
Le chapitre 2.2 en ajoutait une deuxième : quel environnement est acceptable pour cette situation et ces données ?
Ce troisième chapitre déplace encore l’échelle :
que devient ce compromis lorsqu’un environnement est utilisé chaque jour, intégré aux systèmes, enseigné aux personnels, prescrit aux étudiants et incorporé aux routines de l’établissement ?
Un outil peut être choisi de manière raisonnable à un instant donné et produire néanmoins, au fil du temps, une dépendance difficile à inverser.
Ce phénomène ne concerne pas seulement l’IA. Les infrastructures numériques universitaires reposent depuis longtemps sur des plateformes, services cloud, logiciels et fournisseurs. L’IA générative rend cependant la question particulièrement visible parce qu’elle s’insère rapidement dans des activités très différentes : recherche documentaire, production de contenus, programmation, accompagnement pédagogique, administration, analyse et communication.
Le problème n’est donc plus seulement la sécurité de l’environnement. Il devient celui de la trajectoire institutionnelle créée par son adoption.
Continuité avec 2.1 et 2.2
| Acquis | Déplacement dans 2.3 |
|---|---|
| 2.1 : identifier ce que l’usage expose. | Observer aussi ce que l’accumulation des usages produit comme actif et comme dépendance. |
| 2.1 : préserver la souveraineté informationnelle. | Étendre la souveraineté à la capacité institutionnelle de choisir ses infrastructures. |
| 2.2 : choisir un environnement proportionné. | Examiner ce qui arrive lorsque cet environnement devient progressivement difficile à remplacer. |
| 2.2 : considérer le risque résiduel. | Ajouter les risques de dépendance, de continuité et de perte de marge de manœuvre. |
| 2.2 : intégrer la réversibilité dans le choix. | Faire de la réversibilité un objet de conception et de gouvernance dans le temps. |
| 2.2 : rendre les compromis explicites. | Observer comment les compromis initiaux peuvent devenir invisibles une fois l’outil routinisé. |
Le parcours en trois mouvements
| Mouvement | Intention |
|---|---|
| 1 - Quand l’IA devient infrastructure | Comprendre comment simplicité, intégration et accumulation transforment un outil en dépendance structurelle. |
| 2 - Le gratuit est-il vraiment gratuit ? | Identifier les formes de valeur échangées et les coûts différés ou invisibles. |
| 3 - De la performance à la soutenabilité | Évaluer un outil à partir des missions universitaires et de la capacité future à conserver des choix. |
Auto-test initial
1 - Quand l’IA devient infrastructure : la fluidité a un prix
Essentiel
| Comprendre | Repérer | Agir |
|---|---|---|
| Comment un outil devient une infrastructure. | Les dépendances techniques, organisationnelles et cognitives qui s’accumulent. | Identifier ce qui deviendrait difficile à remplacer avant de généraliser un usage. |
Situation ESR
Une université commence par proposer un assistant d’IA facultatif. Quelques enseignants l’utilisent pour préparer leurs cours. Puis des formations sont créées, des guides sont rédigés, des API sont intégrées, des étudiants apprennent à travailler avec l’outil et des processus administratifs commencent à s’appuyer sur ses fonctionnalités.
Aucune décision unique n’a transformé l’outil en infrastructure.
Pourtant, quelques années plus tard, son indisponibilité perturberait de nombreuses activités.
À quel moment le choix ponctuel est-il devenu une dépendance institutionnelle ?
L’infrastructure est ce que l’on cesse de voir
Une infrastructure réussie tend à devenir invisible. Tant qu’elle fonctionne, l’utilisateur ne pense plus aux serveurs, contrats, API, formats ou chaînes de fournisseurs qui rendent son activité possible.
Cette invisibilité explique en partie le paradoxe de la fluidité infrastructurelle :
plus un service est simple à utiliser, plus il peut devenir facile d’oublier les dépendances qui rendent cette simplicité possible.
Dans l’IA générative, la dépendance ne repose pas seulement sur le modèle. Elle peut se construire autour de plusieurs couches.
| Couche de dépendance | Exemple |
|---|---|
| Technique | API, formats, connecteurs, authentification, automatisations. |
| Informationnelle | Historique, bases documentaires, configurations, contenus. |
| Organisationnelle | Procédures et workflows conçus autour de l’outil. |
| Compétentielle | Formation des personnels à un environnement particulier. |
| Pédagogique | Activités et consignes supposant l’accès à une plateforme. |
| Économique | Tarification, quotas, coûts d’intégration et de migration. |
| Contractuelle | Conditions d’accès, durée, garanties et possibilités de sortie. |
La dépendance est donc cumulative. Chacune de ces couches peut sembler faible isolément, mais leur combinaison augmente progressivement le coût de sortie.
De l’usage à la chaîne de valeur
Les documents d’ancrage du chapitre invitent également à replacer l’IA dans une chaîne de valeur.
La réponse produite dans l’interface repose sur une succession de ressources : infrastructures de calcul, modèles, données, logiciels, intégrations, compétences et services.
L’utilisateur voit une réponse. L’institution doit apprendre à voir l’écosystème qui la rend possible.
La donnée comme actif stratégique
Le chapitre 2.1 examinait les données sous l’angle de l’exposition et de la vie privée.
Dans une logique de plateforme, une autre dimension apparaît : les données, interactions, configurations et usages peuvent aussi constituer des actifs.
Ce déplacement ne signifie pas que toute interaction est nécessairement exploitée de la même manière par tous les fournisseurs. Il oblige plutôt à poser la question économique et stratégique :
quelle valeur est produite par nos usages, et qui est en mesure de la capter ?
La valeur peut provenir des données elles-mêmes, mais aussi de l’apprentissage des routines, de la fidélisation, des intégrations ou de l’installation progressive d’un standard de fait.
Dépendance n’est pas interdépendance
Toute infrastructure implique des dépendances. Une université n’a ni vocation ni capacité à fabriquer seule l’ensemble de ses logiciels, matériels et réseaux.
L’enjeu n’est donc pas l’autarcie.
La question utile est de distinguer :
- une interdépendance gouvernée, dans laquelle plusieurs acteurs coopèrent tout en conservant des possibilités de négociation et de sortie ;
- une dépendance verrouillée, dans laquelle les coûts techniques, organisationnels ou économiques réduisent fortement la possibilité de changer.
La souveraineté ne signifie alors pas « tout faire soi-même », mais préserver une capacité effective d’arbitrage.
La réponse européenne : autonomie, interopérabilité et capacité de choix
Les ancrages du chapitre replacent ces dépendances dans les débats européens sur la souveraineté numérique.
L’objectif pertinent pour l’enseignement supérieur n’est pas de substituer un réflexe géographique à un réflexe de marque. Un fournisseur européen ne garantit pas automatiquement la réversibilité, pas plus qu’un fournisseur extra-européen ne peut être évalué uniquement à partir de son origine.
Les critères institutionnels restent notamment :
- la maîtrise des conditions d’usage ;
- l’interopérabilité ;
- la portabilité ;
- la transparence des dépendances ;
- la capacité de négociation ;
- l’existence d’alternatives ;
- la possibilité de sortir du dispositif.
Activité : test de disparition
2 - Le gratuit est-il vraiment gratuit ?
Essentiel
| Comprendre | Repérer | Agir |
|---|---|---|
| Pourquoi prix nul et coût nul ne sont pas synonymes. | Les coûts différés, la captation de valeur et les coûts de sortie. | Évaluer un service sur son coût complet et sa trajectoire, pas seulement sur son prix d’entrée. |
Situation ESR
Un service d’IA gratuit est largement adopté par les étudiants avant même que l’établissement ait choisi une solution institutionnelle.
Lorsqu’une alternative est proposée, les étudiants ont déjà leurs habitudes, certains enseignants leurs prompts et plusieurs équipes leurs ressources.
Le prix initial était nul.
Le coût de changement, lui, ne l’est plus.
La gratuité décrit un prix, pas un modèle économique
Dire qu’un service est gratuit signifie seulement que l’utilisateur ne paie pas directement l’accès à un moment donné.
Cela ne dit rien :
- des coûts d’infrastructure ;
- de la stratégie d’acquisition ;
- des données ou usages valorisés ;
- des effets de réseau ;
- de l’évolution future des tarifs ;
- des coûts supportés par l’utilisateur ou l’institution pour s’adapter.
Le raisonnement doit donc passer de « combien coûte l’abonnement ? » à « comment la valeur circule-t-elle ? ».
Les coûts cachés de l’adoption
| Coût | Exemple |
|---|---|
| Temps | Formation, paramétrage, vérification, accompagnement. |
| Compétences | Apprentissage d’un environnement spécifique. |
| Intégration | Développement de connecteurs et automatisations. |
| Migration | Export, conversion, reconstruction des workflows. |
| Dépendance | Difficulté croissante à remplacer le fournisseur. |
| Gouvernance | Évaluation, contractualisation, audit, documentation. |
| Pédagogique | Refonte d’activités devenues dépendantes de fonctionnalités particulières. |
Un outil peut donc être peu coûteux à adopter et très coûteux à quitter.
Les routines comme mécanisme de verrouillage
Le verrouillage ne dépend pas nécessairement d’une clause contractuelle.
Il peut résulter de la répétition :
utilisation → familiarité → intégration → spécialisation → coût de changement.
Les utilisateurs apprennent les particularités de l’outil. Les documents sont adaptés. Les collègues s’entraident. Les formations se standardisent. Les procédures deviennent plus fluides.
Ces gains sont réels. Mais ils produisent simultanément un capital spécifique à la plateforme.
Le paradoxe est donc que ce qui rend l’outil efficace aujourd’hui peut rendre son remplacement plus coûteux demain.
Le coût de sortie comme indicateur avancé
Une décision d’achat classique compare souvent le coût d’entrée et les bénéfices attendus.
Une politique de soutenabilité ajoute une autre question dès le départ :
combien coûterait la sortie si les conditions devenaient incompatibles avec nos missions ?
Tester la réversibilité avant d’en avoir besoin :
- Peut-on exporter les contenus dans des formats exploitables ?
- Les workflows sont-ils documentés indépendamment de la plateforme ?
- Les compétences sont-elles transférables ?
- Les API utilisées ont-elles des alternatives ?
- Une solution dégradée permet-elle de poursuivre l’activité ?
- Le contrat prévoit-il les conditions de fin de service ?
Gratuité et justice pédagogique
La gratuité apparente peut aussi déplacer les coûts vers les étudiants : équipement, compte personnel, données, temps d’apprentissage ou dépendance à une offre susceptible de devenir payante.
Un outil « gratuit pour l’établissement » n’est donc pas nécessairement gratuit pour la communauté.
Cette question prolonge la justice pédagogique introduite en 2.2 : qui supporte le coût réel du choix ?
Activité : calculer le coût complet
3 - De la performance à la soutenabilité : choisir des outils compatibles avec les valeurs de l’université
Essentiel
| Comprendre | Repérer | Agir |
|---|---|---|
| Pourquoi la performance n’est pas une finalité universitaire. | Les conflits entre efficacité immédiate, dépendance et missions académiques. | Évaluer une solution à partir des finalités à préserver dans le temps. |
Situation ESR
Deux solutions sont comparées.
La première obtient de meilleurs résultats sur plusieurs benchmarks et propose davantage de fonctionnalités. Elle est propriétaire, très intégrée et difficile à remplacer.
La seconde est moins performante sur certaines tâches, mais offre davantage de portabilité, de contrôle et de possibilités d’adaptation.
Quelle solution est « meilleure » pour l’université ?
La performance n’existe pas sans finalité
Un benchmark peut mesurer une capacité technique. Il ne peut pas déterminer seul ce qu’une université doit préserver.
Le jugement doit repartir des missions :
- enseigner et faire apprendre ;
- produire et partager des connaissances ;
- préserver la liberté académique ;
- maintenir l’intégrité scientifique ;
- garantir des conditions équitables d’accès ;
- conserver des capacités professionnelles et institutionnelles de jugement.
Un gain de performance n’a donc de valeur que rapporté à une finalité.
Quand les outils façonnent les pratiques
Les plateformes ne se contentent pas de soutenir des pratiques existantes.
Leurs fonctionnalités, formats, interfaces et métriques rendent certaines actions faciles, d’autres difficiles, et certaines presque invisibles.
À mesure qu’une plateforme s’installe, l’institution peut finir par adapter :
- ses activités à ce que l’outil sait faire ;
- ses formats aux formats acceptés ;
- ses procédures aux automatisations disponibles ;
- ses critères de qualité aux métriques proposées.
Le risque n’est pas seulement d’être dépendant d’un fournisseur. Il est de confondre progressivement les possibilités de l’outil avec les finalités de l’institution.
Sept axes pour évaluer la soutenabilité
| Axe | Question |
|---|---|
| 1. Pertinence pédagogique et scientifique | L’outil sert-il une finalité explicite ? |
| 2. Données et confidentialité | Les conditions de traitement restent-elles compatibles avec les usages ? |
| 3. Autonomie et réversibilité | Peut-on changer, suspendre ou renoncer ? |
| 4. Interopérabilité | Les données, formats et processus restent-ils transférables ? |
| 5. Soutenabilité économique et organisationnelle | Les coûts directs et indirects sont-ils supportables dans le temps ? |
| 6. Équité et accessibilité | Le dispositif reste-t-il accessible sans créer d’obligation disproportionnée ? |
| 7. Alignement avec les missions universitaires | Le choix renforce-t-il ou fragilise-t-il la capacité de l’université à enseigner, rechercher et décider selon ses propres finalités ? |
Ces axes ne constituent pas un classement universel. Leur intérêt est de rendre visibles les critères que la seule performance technique tend à écraser.
Répartir les responsabilités
Le choix soutenable ne peut pas reposer uniquement sur l’enseignant.
| Niveau | Responsabilité principale |
|---|---|
| Utilisateur | Choisir un usage proportionné et signaler les difficultés. |
| Équipe pédagogique / métier | Définir les finalités et besoins réels. |
| Services numériques | Évaluer architecture, intégration, sécurité, maintenance et réversibilité. |
| Protection des données / juridique | Examiner les conditions applicables aux traitements et contrats. |
| Institution | Arbitrer les dépendances acceptables et préserver des alternatives. |
Cette distribution évite deux écueils : faire porter toute la responsabilité sur l’individu ou considérer que le choix technique suffit à régler la question pédagogique.
Préserver des alternatives
Une infrastructure soutenable n’est pas nécessairement celle qui évite toute dépendance.
C’est celle qui évite qu’une dépendance devienne irréversible.
Préserver des alternatives peut signifier :
- privilégier des formats ouverts ;
- documenter les workflows ;
- éviter les intégrations inutilement spécifiques ;
- maintenir des compétences transférables ;
- tester périodiquement la portabilité ;
- conserver une voie non automatisée lorsque la mission l’exige ;
- diversifier certaines dépendances critiques.
La capacité à dire non comme indicateur de maîtrise
Le critère le plus exigeant n’est peut-être pas : « savons-nous utiliser cet outil ? »
Il est :
sommes-nous encore capables de décider de ne plus l’utiliser ?
Une institution réellement capable d’arbitrer doit pouvoir refuser une fonctionnalité, suspendre un usage, migrer ou accepter une performance moindre lorsqu’un autre enjeu est jugé prioritaire.
C’est ici que souveraineté et soutenabilité se rejoignent : préserver la capacité future de choisir.
Activité : le benchmark inversé
Carte d’aide à la décision
flowchart TD
A[Besoin institutionnel] --> B[Finalité explicite]
B --> C[Évaluer l'environnement selon 2.2]
C --> D[Projeter l'adoption dans le temps]
D --> E[Identifier dépendances]
E --> F[Évaluer coût complet]
F --> G[Tester réversibilité]
G --> H[Examiner missions et valeurs]
H --> I{Compromis soutenable ?}
I -->|Non| J[Alternative / limitation / non-usage]
I -->|Oui| K[Déploiement gouverné]
K --> L[Réévaluation périodique]
Règle de décision : ne pas seulement demander « cet outil fonctionne-t-il ? », mais « que devrons-nous préserver pour rester capables de le remplacer, de le limiter ou d’y renoncer ? »
Étude de cas : généraliser un assistant d’IA à l’échelle d’un établissement
Situation
Après une expérimentation réussie, un établissement envisage de généraliser un assistant d’IA à tous les personnels et étudiants.
Les retours sont positifs : simplicité, qualité des réponses et gains de temps.
Première analyse : 2.2
L’environnement a été évalué : contrat, données, authentification et usages autorisés.
Cette étape est nécessaire, mais elle ne répond pas encore aux questions de 2.3.
Projection à trois ans
L’établissement doit maintenant anticiper :
- les formations créées ;
- les contenus et assistants configurés ;
- les intégrations dans le LMS et les outils métier ;
- les processus qui pourraient dépendre de l’API ;
- les habitudes des étudiants ;
- les coûts de licence après montée en charge ;
- les conditions d’export ;
- les compétences nécessaires à une migration.
Question décisive
Si les tarifs, le modèle ou les conditions contractuelles changent dans trois ans, l’établissement disposera-t-il encore d’un choix réel ?
Décision soutenable
La généralisation peut être pertinente, mais elle doit être accompagnée dès le départ d’un plan de réversibilité : formats exportables, documentation, limitation des dépendances spécifiques, alternatives et réévaluation périodique.
Fiche action : tester la soutenabilité avant de généraliser
Finalité
Dépendances
Coût complet
Réversibilité
Missions
Auto-positionnement final
Répondez de 1 à 4 : 1 = pas du tout, 2 = rarement, 3 = souvent, 4 = systématiquement.
| Question | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Je distingue usage ponctuel et dépendance infrastructurelle. | ||||
| J’identifie les dépendances techniques, organisationnelles et compétentielles créées par un outil. | ||||
| J’examine la circulation de valeur derrière une offre gratuite. | ||||
| J’évalue les coûts de sortie autant que les coûts d’entrée. | ||||
| Je considère la réversibilité avant la généralisation d’un outil. | ||||
| Je distingue souveraineté et autarcie technique. | ||||
| Je rapporte la performance aux missions pédagogiques, scientifiques et institutionnelles. | ||||
| Je prends en compte les coûts supportés indirectement par les étudiants et personnels. | ||||
| Je préserve des formats, compétences ou alternatives permettant de changer de solution. | ||||
| Je peux expliquer quelles dépendances l’institution accepte et pourquoi. |
Analyser son positionnement
Additionnez vos réponses sur 40.
| Score | Lecture | Priorité |
|---|---|---|
| 10 à 19 | L’analyse reste principalement centrée sur l’usage immédiat et les fonctionnalités. | Cartographier les dépendances d’un outil déjà utilisé et réaliser le « test de disparition ». |
| 20 à 29 | Les dépendances sont perçues, mais rarement intégrées dès la décision initiale. | Ajouter coût de sortie, réversibilité et coût complet aux critères de choix. |
| 30 à 35 | La soutenabilité est généralement intégrée aux arbitrages. | Formaliser les responsabilités, scénarios de migration et réévaluations périodiques. |
| 36 à 40 | La capacité future d’arbitrage devient un critère explicite de gouvernance. | Transformer cette maturité en politique collective : interopérabilité, alternatives et gouvernance des dépendances. |
Ce score n’évalue pas une conformité réglementaire. Il sert à repérer si le raisonnement porte seulement sur la performance actuelle ou également sur la capacité future à choisir.
Conclusion
Le chapitre 2.1 demandait ce que nous exposons. Le chapitre 2.2 demandait dans quel environnement nous pouvons raisonnablement le faire.
Le chapitre 2.3 ajoute le temps.
Un environnement acceptable aujourd’hui peut devenir une dépendance demain lorsque s’accumulent contenus, compétences, intégrations, habitudes et investissements.
Trois déplacements en résultent :
- de l’outil à l’infrastructure : regarder l’écosystème qui rend l’usage possible ;
- du prix au coût complet : intégrer les coûts différés, organisationnels et de sortie ;
- de la performance à la soutenabilité : juger un outil selon les missions qu’il doit servir et la marge de décision qu’il laisse à l’institution.
Le paradoxe devient alors :
plus une plateforme s’intègre parfaitement à nos pratiques, plus elle peut devenir coûteuse à quitter ; or une université ne peut préserver ses missions que si elle reste capable de réinterroger les infrastructures qui les soutiennent.
La souveraineté pertinente n’est donc pas l’indépendance absolue. Elle est la capacité organisée de choisir, négocier, contester, migrer et parfois renoncer.
Cette conclusion prépare le dernier chapitre du Volume 2. Après les données, les environnements et les infrastructures, il reste à examiner le lieu où ces transformations deviennent concrètes : le travail lui-même.
Le chapitre 2.4 demandera donc comment préserver la capacité d’agir lorsque l’IA transforme les tâches, redistribue la vérification et modifie les compétences attendues.
Glossaire du chapitre
| Notion | Définition |
|---|---|
Infrastructure numérique |
Ressources techniques et organisationnelles devenues nécessaires au fonctionnement durable d’activités. |
Plateforme |
Environnement numérique organisant l’accès à des services, contenus, acteurs ou interfaces et structurant leurs interactions. |
Dépendance de plateforme |
Dépendance créée lorsque pratiques, données, compétences ou intégrations deviennent fortement liées à une plateforme. |
Vendor lock-in |
Situation dans laquelle changer de fournisseur devient techniquement, économiquement ou organisationnellement difficile. |
Coût de sortie |
Ensemble des ressources nécessaires pour migrer, remplacer ou abandonner une solution. |
Réversibilité |
Capacité à modifier ou quitter un dispositif sans perte disproportionnée de continuité, de données ou d’autonomie. |
Souveraineté numérique |
Capacité à conserver des choix effectifs sur les infrastructures et leurs conditions d’usage. |
Captation de valeur |
Transformation d’usages, données, attention ou dépendances en valeur économique ou stratégique. |
Coûts cachés |
Coûts indirects ou différés qui ne figurent pas dans le prix d’accès : formation, intégration, gouvernance, migration ou dépendance. |
Soutenabilité |
Capacité d’un choix à rester compatible dans la durée avec les ressources, valeurs et missions de l’institution. |
Interdépendance |
Dépendance réciproque entre acteurs pouvant rester gouvernable lorsqu’existent négociation, alternatives et capacité de sortie. |
Capacité d’arbitrage |
Capacité institutionnelle à comparer, décider, contester et modifier ses choix technologiques. |
Bibliographie indicative à consolider
Cette version reprend les concepts et orientations des documents d’ancrage 2.3 fournis. Les références bibliographiques exactes doivent être reprises depuis les sources primaires et harmonisées dans references.bib.
À consolider avant publication :
- références relatives aux plateformes, infrastructures numériques et dépendances ;
- travaux mobilisés dans 2.3.1 sur la souveraineté numérique et les chaînes de valeur ;
- références mobilisées dans 2.3.2 sur la gratuité, les coûts cachés, les effets de réseau et le verrouillage ;
- références mobilisées dans 2.3.3 sur la soutenabilité, l’interopérabilité, la réversibilité et l’alignement des infrastructures avec les missions universitaires ;
- références institutionnelles européennes citées dans les ancrages ;
- métadonnées exactes des travaux cités dans les trois Podcast Design 2.3.
Principe de validation : aucune référence ne doit être ajoutée à references.bib sur la seule base d’un nom ou d’une mention secondaire. Vérifier titre, auteurs, année, éditeur ou revue, DOI/URL et correspondance avec l’affirmation soutenue.