D3 — Architecture cible et CRISalid

Durée : 45 minutes échanges compris, soit environ 31 minutes d’exposé et 14 minutes d’échanges.

Fil, en quatre temps : ce qui tourne aujourd’hui, ce qui manque pour une vitrine, la cible, puis exploiter et décider.

Registre technique : noms de composants à l’écran (Neo4j Community, IKG, Apollo, RabbitMQ, Ofelia, Docker Compose).

Ce deck est une annexe du deck de restitution. Les constats sur l’instance CRISalid viennent de son observation du 29 octobre 2026. Les faits qui dépendent d’une vérification portent leur date : les licences, vérifiées le 30 octobre, et les failles de LPI Projects, revérifiées le 30 octobre. Le POC de pertinence court du 9 novembre au 4 décembre 2026.

Prudence : ce support est publié sur le site. Il ne contient aucun détail des failles de LPI Projects ni des défauts de sécurité du code CRISalid. Le détail des failles est réservé au RSSI et à la DPO (deck D4, diffusion restreinte) ; celui des défauts du code, à l’équipe CRISalid.

Ce deck ne reprend ni le déroulé du POC, ses semaines et ses critères (deck D6), ni les coûts des deux parties et le comparatif LPI (deck de restitution).

Sources : 05-deck/catalogue, 06-audit-docs/00b-le-livrable-final

Le message unique de la séance : la vitrine publique ne lit jamais le graphe, elle lit un extrait daté, produit par requêtes figées dans le réseau CRISalid. Tout le reste du deck explique pourquoi c’est la seule architecture compatible avec ce que l’on a observé.

Les trois verdicts, avec leur portée exacte. Frontend Projects : NO-GO en l’état ; le verdict vise le frontend tel qu’il est, pas LPI comme partenaire. Socle CRISalid : GO conditionnel, à six conditions que l’on verra à la fin. Décision d’ensemble : PIVOT vers une vitrine publique découplée, synchronisée, en marque blanche, proposée comme brique de la suite CRISalid.

R1: garder les données, construire notre vitrine.

R2: socle CRISalid réutilisé, frontend Projects écarté, vitrine alimentée par un extrait contrôlé.

Sources : 02-analyse-lpi/03-audit-technique/02-arbitrage/00-avis-go-no-go, 03-crisalid/00-reperes/comprendre-crisalid

Une décision vous est demandée à la fin : une position commune de la DSI et de la DiBISO, en cinq points, à porter au comité de décision de la semaine du 7 décembre 2026, après le POC.

Chaque partie s’ouvre sur un intercalaire. Les titres énoncent la conclusion ; le détail, les chiffres exacts et leurs sources sont dans les notes.

Chaque constat porte son statut de preuve. Le badge « Observé sur instance (dev) » signale un constat fait sur l’instance de développement de la DiBISO, en lecture seule. Le badge « Confirmé » signale un constat établi dans le code.

Source : 04-prochaines-etapes/00-feuille-de-route

La règle qui gouverne tout le deck : aucun constat ne vaut conclusion de production.

Ce que l’audit a vu : le code des 21 dépôts CRISalid, à une révision figée du 21 octobre 2026 ; des scripts qui exécutent du code CRISalid réel sans lancer la pile ; l’instance de développement de la DiBISO, en lecture seule, le 29 octobre 2026. Aucune instance de production n’a été observée.

Le code prouve une implémentation : ce que le logiciel sait faire. L’instance prouve un déploiement de test : ce qui tourne sur une machine précise, avec ses données du moment. Aucun des deux ne prouve une production.

Ce qui n’a pas été vu : la planification réelle des traitements, la configuration interne, le chiffrement au repos, la journalisation. Les droits effectifs du compte fourni à l’audit n’ont pas été testés, par choix de méthode.

Ce qui reste non évalué n’est pas présumé conforme : c’est à prouver, avec une preuve rattachée à une version.

Sources : 03-crisalid/00-reperes/ce-qui-nest-pas-prouve, 03-crisalid/06-instance-saclay/00-ce-que-linstance-demontre

Le rôle de chaque brique. L’annuaire (crisalid-directory-bridge) charge unités, personnes et rattachements. Le moissonneur (svp-harvester) va chercher les publications dans les sources ouvertes pour chaque chercheur connu. Tous deux publient sur un bus d’événements RabbitMQ, en trois familles de messages : annuaire, publications, graphe. Le graphe IKG rapproche, fusionne et écrit dans Neo4j. Apollo expose le graphe en GraphQL à SoVisu+, l’espace des chercheurs, dont les corrections reviennent par le bus. L’assemblage crisalid-deployment lance le tout.

Dix dépôts sont hors périmètre de décision : six d’IA, trois d’historique et d’outillage, et CERIF-Core. Ils ne tournent pas sur l’instance et ne produisent pas la donnée d’une vitrine. Exception utile : crisalid-ai-skills contient treize requêtes prédéfinies en lecture seule, un bon modèle pour écrire le service d’export.

Les traitements sont asynchrones : une donnée n’est jamais à jour instantanément, la fraîcheur se mesure, elle ne se présume pas.

Sources : 03-crisalid/00-reperes/comprendre-crisalid, 03-crisalid/02-sous-projets/carte-des-sous-projets, 03-crisalid/01-donnees/contrats-api-evenements

Deux statuts sur cette diapositive. Observé sur instance (dev) : sur l’instance de développement, toute la pile tourne sur un seul hôte, sur site, partagé avec d’autres applications de la DiBISO. Les bases sont dans la pile : leur sauvegarde dépend de l’hôte. Neo4j est en édition Community. Les prototypes d’IA ne sont pas déployés.

Confirmé dans le code : Docker Compose est la seule voie de déploiement fournie. Kubernetes est annoncé mais pas fourni ; l’ancien dépôt svp-k8s est abandonné.

La colocalisation de Neo4j, d’IKG et de l’ordonnanceur Ofelia est imposée par le code : l’ordonnanceur pilote les conteneurs, et la sauvegarde lit les fichiers de Neo4j. Conséquence : un incident sur l’hôte arrête toute la chaîne. La haute disponibilité n’est pas prévue.

Mémoire : le socle occupe environ 20 Go, dont la moitié pour le graphe ; c’est une mesure ponctuelle, sur une machine partagée. Projection Saclay, en ordre de grandeur : un volume doublé tiendrait dans 35 à 45 Go. L’infrastructure d’une cible ne se chiffre pas d’après cette machine mutualisée.

Sources : 03-crisalid/06-instance-saclay/00-ce-que-linstance-demontre, 03-crisalid/03-fonctionnement-transversal/exploitation-et-gouvernance

La page System Overview de la documentation officielle de CRISalid affiche « Work in Progress — This page is coming soon ». Il n’existe donc pas de schéma d’architecture officiel auquel se référer.

Tous les schémas de ce deck sont reconstitués par l’audit, à partir du code des dépôts et de ce que montre l’instance de développement. Ils sont à faire valider par l’équipe CRISalid avant de servir de référence à un dossier d’architecture.

La documentation de déploiement décrit Docker Compose ; elle annonce Kubernetes sans le fournir, comme on vient de le voir.

Pour la DSI, la conséquence est pratique : le dossier d’architecture technique d’une cible de production reste à écrire, et il devra partir du code et de l’instance plutôt que d’une documentation de référence.

Capture : crisalid-esr.github.io/crisalid-deployment, consultée le 30 octobre 2026.

Source : 03-crisalid/02-sous-projets/carte-des-sous-projets

Le graphe observé compte 18,5 millions de nœuds et 53,9 millions de relations. Son modèle en trois étages, source, consolidé et référentiel, est conforme au code : 49 types de nœuds, 27 contraintes d’unicité, 2,2 millions de liens de traçabilité. Chaque entité consolidée garde le lien vers les notices dont elle est issue.

Étage source : 536 361 notices. Par source : OpenAlex 200 569, scanR 171 533, HAL 113 558, IdRef 50 701. Scopus n’alimente aucune notice.

Mise en garde de lecture : 833 195 personnes n’est pas le nombre de chercheurs de Paris-Saclay, car les coauteurs externes sont compris. Et 251 191 publications n’est pas la production de l’université.

Le rapprochement est actif : 336 777 rapprochements inférés, et 3 362 fusions en attente, qui reviendront avec la purge (Q20).

Source : 03-crisalid/06-instance-saclay/01-donnees-observees

Quatre requêtes bornées, exécutées sur l’instance de développement le 29 octobre 2026. Fiche d’unité, avec libellé, identifiants et nombre de chercheurs : une unité de 761 chercheurs, quatre identifiants pérennes, 0,17 s. Cinq publications avec titre, date, type et accès ouvert : 0,25 s. Comptage des publications d’une unité : 3 933 publications, 0,23 s. Six agrégats globaux, dont une traversée de 222 072 publications : 4,5 s.

Les noms de relation, MEMBER_OF et HAS_CONTRIBUTION, sont observés sur l’instance ; les propriétés exactes restent à confirmer avec l’équipe CRISalid.

Ce que cela ne montre pas : la tenue en production, le respect champ à champ du contrat de la vitrine, ni l’existence d’un service d’export.

Une phrase sur le référentiel : 184 unités sur 235 n’ont aucun chercheur rattaché. C’est le risque principal du dossier, mais il est documentaire, pas d’architecture (Q9). Il est traité dans D6 et dans la restitution.

Sources : 03-crisalid/06-instance-saclay/00-ce-que-linstance-demontre, 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc, 03-crisalid/06-instance-saclay/01-donnees-observees

Neo4j en édition Community ne propose ni rôles ni droits par propriété : un compte « lecture seule » ne peut pas être contraint techniquement. C’est un fait de l’édition, confirmé et observé sur l’instance.

Apollo : une clé d’API unique ouvre les 60 requêtes et les 60 mutations du schéma GraphQL, sans lecture seule ni filtrage des champs. Ce constat vient de la génération du schéma et de tests locaux du 22 octobre 2026. Aucun quota ni pagination stable ne sont configurés.

Les droits effectifs du compte fourni à l’audit n’ont pas été testés, par choix de méthode : on ne présume donc rien de ce compte.

Ce point est l’un des trois défauts de sécurité confirmés dans le code de CRISalid ; les deux autres sont réservés à l’équipe CRISalid, qui en a le détail.

La parade vient en troisième partie : l’extraction dans le réseau CRISalid.

Sources : 03-crisalid/03-fonctionnement-transversal/securite-droits-donnees-personnelles, 03-crisalid/01-donnees/contrats-api-evenements, 03-crisalid/06-instance-saclay/00-ce-que-linstance-demontre

Les cas, un par un. Une personne ou une structure retirée de l’annuaire : l’annuaire envoie le statut « supprimée », IKG l’ignore, l’entité reste dans le graphe. Une notice retirée par une source : elle reste. Côté SoVisu+ : les structures supprimées sont ignorées, et il n’existe pas de traitement de suppression de personne. Une fusion ne publie pas d’alias.

Statut : le mécanisme est confirmé dans le code. Les 3 353 documents sont un constat distinct, observé sur l’instance : des suppressions décidées mais non appliquées, marquées « à supprimer » et jamais purgées ; 3 362 fusions sont aussi en attente (Q20). Le code ne traite pas les suppressions ; l’instance le montre.

Conséquence d’architecture : l’export ne peut pas être incrémental. Il est régénéré en entier à chaque cycle, et filtré sur une liste de personnes et de structures actives fournie par l’établissement. Le droit à l’effacement n’est pas outillé de bout en bout : la vitrine le garantit par ce filtrage, pas par CRISalid.

Sources : 03-crisalid/01-donnees/contrats-api-evenements, 03-crisalid/06-instance-saclay/01-donnees-observees

Dans le code. L’annuaire n’a pas de planification intégrée : il est lancé à la main ou par un ordonnanceur externe. Les DAG d’ingestion inspectés sont en schedule=None : le déclenchement réel est externe. Toutes les 2 minutes, l’ordonnanceur Ofelia relance le moissonnage d’une personne tirée au hasard. Ce tirage ne garantit pas qu’un corpus entier soit couvert dans un délai donné, et rien n’empêche deux exécutions simultanées.

Sur l’instance. Le calcul de l’accès ouvert horodate chaque article traité : c’est le seul indicateur de cadence lisible sans l’orchestrateur. 210 651 articles ont été calculés du 27 août au 7 septembre 2026, puis plus rien : sept semaines sans activité au 29 octobre. La liste des traitements exige une authentification que l’audit n’avait pas.

Conséquence : une synchronisation hebdomadaire au plus, jamais plus fréquente que l’enrichissement réel, et la date de mise à jour affichée sur chaque fiche.

Sources : 03-crisalid/03-fonctionnement-transversal/exploitation-et-gouvernance, 03-crisalid/06-instance-saclay/01-donnees-observees, CONTEXT.md

CRISalid n’a aucune notion de ZRR ni de PPST : aucune référence dans les 21 dépôts. Il ne qualifie aucun champ comme public ou privé. Il n’y a donc qu’un seul point de filtrage possible : l’export.

Retirer une unité de l’annuaire ne suffit pas : une publication moissonnée peut toujours la citer dans ses affiliations. C’est pourquoi le filtre porte sur une liste blanche des unités, pas sur une liste d’exclusion.

Les propriétaires de chaque liste : le FSD pour les unités en ZRR, la DPO et la communication pour les champs publiables, la DSI et le RSSI pour l’exposition réseau et l’accès du service d’export, la DiBISO pour les rôles dans SoVisu+.

Hors du modèle : CRISalid ne porte ni projets, ni financements, ni dates d’affiliation. Ils sont hors du premier lancement et exclus de l’extrait.

Le détail des six règles de filtrage est dans D6 : on ne le reprend pas ici.

Sources : 03-crisalid/03-fonctionnement-transversal/securite-droits-donnees-personnelles, 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc

Supervision : les sondes de santé du graphe et d’Apollo renvoient une réponse constante, sans vérifier Neo4j ni le bus. Un conteneur peut se dire en bonne santé alors que la chaîne est arrêtée. Statut : Confirmé.

Sauvegarde : Neo4j est sauvegardé à l’arrêt. On arrête le graphe puis Neo4j, on copie, on redémarre : chaque sauvegarde interrompt l’ingestion. PostgreSQL se sauvegarde à chaud. La fréquence, la rétention et le test de restauration sont à confirmer avec l’exploitant.

Observabilité : aucune collecte de métriques ni centralisation des journaux n’est fournie dans le déploiement de référence.

Versions : les versions applicatives annoncées sont des valeurs par défaut ; les versions réellement déployées ne sont pas connues. Recommandation : épingler chaque image et suivre les notes de version.

Réseau : l’exposition des services de l’instance relève de la DSI et du responsable de l’instance. Une politique d’exposition est à écrire avant tout déploiement de production (Q23). Le détail n’est pas publié.

Sources : 03-crisalid/03-fonctionnement-transversal/exploitation-et-gouvernance, 03-crisalid/06-instance-saclay/00-ce-que-linstance-demontre

Licences vérifiées le 30 octobre 2026.

Le cœur de CRISalid est sous CeCILL 2.1. Neuf dépôts n’ont pas de fichier de licence, dont la passerelle d’annuaire, crisalid-directory-bridge, qui est requise : c’est elle qui charge unités, personnes et rattachements. C’est un point bloquant avant tout déploiement : il faut faire publier une licence pour ce dépôt.

Apollo porte CeCILL 2.1 dans son fichier LICENCE et ISC dans sa configuration. Le fichier de licence prévaut, mais la mention est à faire corriger en amont.

Composants tiers : Neo4j Community est sous GPL v3, RabbitMQ sous MPL 2.0.

Règle de conduite : ne pas créer de version divergente du cœur. Les correctifs, qu’il s’agisse de licences ou de code, se proposent en amont, à la communauté CRISalid.

Source : 03-crisalid/03-fonctionnement-transversal/exploitation-et-gouvernance

Projects, le produit de LPI, recopie personnes, structures et productions CRISalid dans Django et PostgreSQL. Ce read model est un actif réutilisable par un portail découplé.

Mais rien ne démontre que Keycloak, la collaboration ou le chatbot sortent du chemin critique d’une consultation anonyme.

Cache : cache: false et Cache-Control: no-store sur toutes les routes. Le CDN ne mutualise aucune réponse : chaque requête atteint Nitro.

Nuxt 3.21.8 est hors support standard depuis le 31 juillet 2026 (date à confirmer sur la politique de Nuxt) ; la migration vers Nuxt 4 n’est pas chiffrée.

La leçon d’architecture : servir une projection plutôt que le graphe, c’est juste. Un parcours public couplé au collaboratif et sans cache, non.

Sécurité, en formulation agrégée seulement : deux failles ouvertes au 30 octobre 2026, une critique, une élevée ; le détail est réservé au RSSI et à la DPO (D4). Les questions à LPI sont dans D2.

Sources : 02-analyse-lpi/03-audit-technique/01-analyse-par-thematique/01-stack-architecture, 02-analyse-lpi/03-audit-technique/01-analyse-par-thematique/04-securite-rgpd, 02-analyse-lpi/03-audit-technique/02-arbitrage/00-avis-go-no-go

La cible : les sources ouvertes et CRISalid alimentent un service d’export dédié, qui produit une projection publique en liste blanche. La vitrine synchronisée est générée depuis cette projection, puis servie derrière un CDN et un WAF.

Keycloak, Apollo, Neo4j et l’administration restent en réseau privé : aucun n’est joignable depuis le public. Si la source tombe, la dernière version publiée reste servie.

Option déconseillée par l’audit, à acter au comité (Q5) : la lecture directe de l’API Apollo par la vitrine. Une seule clé, qui permet aussi d’écrire ; et la vitrine dépendrait de CRISalid à chaque page.

La vitrine est proposée comme brique de la suite CRISalid, en marque blanche, réutilisable par d’autres établissements.

Vocabulaire : dire « vitrine synchronisée », pas « site statique » ; les pages sont générées depuis l’extrait, mais le service vit.

Sources : 02-analyse-lpi/03-audit-technique/01-analyse-par-thematique/01-stack-architecture, 01-cadrage-saclay/02-scenarios/01-partie-1-vitrine-marque-blanche, 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc

C’est la parade au constat de tout à l’heure : puisque tout lecteur peut écrire, aucun lecteur ne sort du réseau. L’extraction tourne dans le réseau CRISalid, par requêtes figées, et seul l’extrait filtré en sort.

Une vitrine générée depuis un extrait ne lit jamais le graphe : la question de la lecture seule disparaît côté public.

Les alternatives ne sont à chiffrer que si l’on en a besoin : l’édition Enterprise de Neo4j, qui offre des rôles (Q22, DiBISO et DSI), ou une clé Apollo en lecture seule développée en amont, avec la communauté.

L’accès d’audit du 29 octobre ne sert pas à produire l’extrait : il a servi à observer, en lecture seule, et rien de plus.

Pour le POC, la DiBISO produit un extrait ponctuel dans son réseau ; le service d’export viendra ensuite.

Sources : 03-crisalid/06-instance-saclay/00-ce-que-linstance-demontre, 03-crisalid/03-fonctionnement-transversal/securite-droits-donnees-personnelles, 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc, 04-prochaines-etapes/grille-evaluation

L’extrait se compose de quatre fichiers : unités, chercheurs rattachés, publications et liens. Chacun est daté, porte une version de schéma et une empreinte. Les champs suivent une liste blanche proposée par l’audit.

Aujourd’hui, il n’existe aucun contrat d’échange unique et versionné qui mène jusqu’à une vitrine : il est à écrire avec le service d’export. Le numéro de version des chemins HTTP ne versionne ni le schéma GraphQL ni les messages du bus.

L’extrait est régénéré en entier à chaque cycle, à cause des suppressions non propagées. Le contrat se teste à chaque montée de version de CRISalid.

Le contenu champ à champ et les exclusions sont dans D6 : on ne les reprend pas.

Réversibilité : le format appartient à Paris-Saclay. Si CRISalid était abandonné, seule la production de l’extrait changerait, par exemple depuis HAL ou scanR ; la vitrine resterait. CERIF-Core inspire le modèle sans être implémenté.

Sources : 03-crisalid/01-donnees/contrats-api-evenements, 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc, 03-crisalid/02-sous-projets/carte-des-sous-projets

Le POC se contente d’un extrait lancé à la main. La vitrine synchronisée a besoin d’un service qui produit le même extrait chaque semaine, le contrôle et alerte en cas d’échec. Ce service n’existe pas.

Option proposée, en vert : livré avec la vitrine, exécuté dans le réseau CRISalid, exploité par la DiBISO. Le graphe ne sort pas du réseau.

DiBISO seule, en orange : proche des données, mais aucune charge prévue et un calendrier incertain.

Lecture directe de l’API, en rouge : une seule clé, qui permet aussi d’écrire, et la vitrine dépend de CRISalid à chaque page.

Charge de l’option proposée : 8–15 j.h, soit 4–11 k€ au taux mixte, en plus du chiffrage du lancement. C’est une estimation d’audit, pas un devis : la DSI la contre-expertise. À acter au comité (Q5).

Déclaration d’intérêt : le socle de la vitrine est le prototype de l’auteur de l’audit ; la même vitrine peut être réalisée par la DSI ou par un prestataire après consultation.

Sources : 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc, CONTEXT.md

Un extrait par semaine au départ, jamais plus fréquent que l’enrichissement réel. Chaque extrait est conservé, et la version active est désignée explicitement : le retour à la précédente est toujours possible. Si CRISalid est arrêté, l’export échoue et la vitrine sert la version précédente. Une génération échouée n’écrase jamais la dernière version valide. Un test de non-divulgation tourne à chaque export.

L’export est planifié hors de l’ordonnanceur interne de CRISalid et hors des fenêtres de sauvegarde, puisqu’une sauvegarde de Neo4j arrête l’ingestion.

Seuils de la Partie 1 : disponibilité utile d’au moins 99,5 %, TTFB d’au plus 800 ms au p75 par gabarit, Core Web Vitals au vert. Ce sont des cibles de travail, à calibrer sur T0. Runbooks attendus : panne source, cache incohérent, index indisponible, retour arrière. Restauration complète testée avant la mise en production.

Côté CRISalid : un hôte unique, sans haute disponibilité ni supervision réelle. La vitrine absorbe cette fragilité.

Sources : 01-cadrage-saclay/exploitation-pilotage, 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc, 03-crisalid/03-fonctionnement-transversal/exploitation-et-gouvernance

Le GO conditionnel sur le socle CRISalid tient à six conditions. Pour chacune, le porteur et la question du registre.

Le service d’export dédié : DiBISO, Q5. La liste blanche des champs : la DPO et la communication. Le filtrage ZRR : le FSD et la DiBISO, Q4. Le plan de peuplement des rattachements, pour les 184 unités sur 235 sans chercheur : la DiBISO et la direction de la recherche (DR à l’écran), Q9. La cadence d’enrichissement supervisée : DiBISO, Q10. Le cloisonnement réseau : la DSI et le RSSI, Q23.

Toutes sont en orange : aucune n’est levée aujourd’hui.

Une réponse orale ne lève pas une condition : il faut une preuve rattachée à une version, qu’il s’agisse d’une liste validée, d’un journal d’exécution ou d’une politique écrite.

Sources : 02-analyse-lpi/03-audit-technique/02-arbitrage/00-avis-go-no-go, 04-prochaines-etapes/grille-evaluation

Ce que l’on vous demande : une position commune de la DSI et de la DiBISO, à porter au comité de décision de la semaine du 7 décembre 2026.

1. La vitrine lit un extrait daté, jamais le graphe : aucun accès du public ni de la vitrine à Neo4j ou à Apollo.

2. L’extraction se fait dans le réseau CRISalid, par requêtes figées, faute de compte en lecture seule ; l’édition Enterprise n’est étudiée qu’en cas de besoin (Q22).

3. Service d’export : la DSI et la DiBISO recommandent l’option proposée, livrée avec la vitrine, exécutée dans le réseau CRISalid, exploitée par la DiBISO (Q5) ; la DSI contre-expertise les 8–15 j.h.

4. Une synchronisation hebdomadaire au plus, avec la date affichée sur chaque fiche (Q10).

5. Des porteurs nommés pour Q22, l’édition de Neo4j, et Q23, la politique d’exposition réseau, avant toute production.

En parallèle, hors architecture : le peuplement des unités (Q9), la licence de la passerelle d’annuaire, la purge (Q20).

Sources : 01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc, 04-prochaines-etapes/grille-evaluation, 04-prochaines-etapes/00-feuille-de-route

Rappel du message : le socle CRISalid est réutilisé, le frontend Projects écarté ; la vitrine découplée lit un extrait filtré, produit dans le réseau CRISalid, dont Paris-Saclay possède le format.

Pour aller plus loin sur le site : comprendre CRISalid ; ce que montre l’instance ; exploitation et gouvernance ; sécurité, droits et données personnelles ; extrait et comparatif du POC ; registre des questions Q1 à Q23.

Ouvrir les échanges, environ 14 minutes.

Source : 03-crisalid/00-reperes/comprendre-crisalid