Note: le terme développeur est générique et fait référence à l’individu ou l’organisation pluridisciplinaire qui est chargée de produire et maintenir : la base de code, le corpus de tests et les fichiers de description d’infrastructure et les documentation technique et usager.
Il est responsable de l'adéquation et de la qualité de la solution au besoin des usagers en collaborant de manières étendues avec les autres acteurs impliqués.
Tableau converti vers MarkDown : https://tabletomarkdown.com/convert-spreadsheet-to-markdown/. into vs code ctrl+k + v or Remplacer ctrl par cmd on a Mac to show the markdown preview.
| ID | Type | Exigence | Catégorisation |
|---|---|---|---|
| Version | Version : liste des exigences, mise à jour au 27.5.2024 change management : liste dé-doublonée, triée, renumérotée ajout exigence MCS et variabilité du déploiement Précision sur les exigences de la construction des images "from" Précision sur les exigences liés à la résilience intra cluster Ajout respect des 12 factors Exigence P : primordiale, le non respect entraîne un rejet administratif de l'offre lors d'un appel d'offre et un plan de remédiation obligatoire lors de l'exécution du marché Exigence I : importante, permet de maximaliser la qualité de la solution |
- | |
| --- | |||
| EXI-G-1 | I | Dans le cadre d’un appel d’offre, en cas d’incohérence entre les documents et hors mentions explicites, le cct et la liste des exigences associées sont de niveaux supérieures. | hiérarchie des normes |
| EXI-G-2 | I | Le respects des exigences du CCT sont limitées à la durée du marché pour un opérateur économique, mais permanent pour la direction d’application métier. | applicabilité |
| EXI-G-3 | I | Respect des standards et des normes applicables industrielles, européennes et étatiques, pour la conception de solutions numériques hébergées dans le cloud native (kubernetes), Design Système de l’État, RGAA, RGS, RGI, doctrine Cloud au centre. cf paragraphe du volet de CCT : Les normes industrielles, institutionnelles applicables |
Cadre de normes |
| EXI-G-4 | I | Respect du guide d'éco-conception. La conception frugale vis à vis des ressources d’infrastructures consommées et l'impact vis-à-vis du terminal de l'usager. | Qualité de la solution |
| EXI-G-5 | P | Choix d’un hébergement adapté à la nature des données manipulées ( usuel / DR ) et selon le cadre légal adapté. Cloud Pi (on-prem), Cloud public, Infrastructure dédiée ou mixte. |
Infrastructure |
| EXI-G-6 | P | Si l'application est exposée sur internet un service de CDN / anti-ddos externalisé sera mis en place. | Infrastructure |
| --- | |||
| EXI-ORG-1 | P | Conformité au modèle de responsabilité Cloud Pi Native : les développeurs/concepteurs sont responsables de la partie développement, du maintien en continu d’une qualité constante de la solution et l’absence de vulnérabilités exploitables notamment avant toute mise en production. | Modèle d'Opération |
| EXI-ORG-2 | I | Les équipes contribuent à la remontée et à l’enrichissement de la chaîne l’offre Cloud Native. Signale les éventuels défauts ou besoin d’évolution, il soumet le cas échéant une rectification ou une évolution sur le dépôt de code après l’avoir testé | Modèle d'Opération |
| EXI-ORG-3 | P | Conformité au modèle de responsabilité “you built it - you run it - you secure it - you support it” de l’offre cloud pi native. Les développeurs/concepteurs sont responsables d’organiser le bon fonctionnement de l’application en production et du soutien aux usagers. Un modèle de collaboration est établi dans la convention d’utilisation de l’offre avec l’hébergeur avec le modèle de responsabilité de chacun des acteurs. Cela peut inclure la mise en place d’autres conventions avec d'autres service tels que la supervision applicative et le SOC ministériel. ( les norme d'interfaces sont à demander lors de la contractualisation de l'hébergement ) |
Modèle d'Opération |
| EXI-ORG-17 | I | L’équipe est formée aux bonnes pratiques des technologies Cloud Native (kubernetes), à la construction et au maintien en qualité d’une base de code, à l’agilité et au devsecops, à l’intégration continue. (fournir les certifications en preuve) | Compétence |
| EXI-ORG-16 | I | L'équipe s'appuie de préférence sur un ou plusieurs coachs & experts certifiés Cloud Pi Native pour l'initialisation du programme et une revue régulière des pratiques | Compétence |
| EXI-ORG-6 | I | Intégration technique de l’usine logicielle primaire (responsabilité du développeur) à la chaine DevSecOps, maintien par le développeur en condition de disponibilité et de sécurité du point de vérité du logiciel et du code d’infrastructure. |
Modèle d'Opération |
| EXI-ORG-7 | P | Le développeur est responsable du pipeline de la chaîne secondaire de construction applicative. ( pipeline gitlab ) Il s'appuie sur les outils et les exemples proposés par la documentation. Il met en œuvre les vérifications nécessaires portant sur la qualité du code, les vérifications fonctionnelles automatiques, les mesures spécifiques de sécurité issues de la démarche d'homologation. |
Modèle d'Opération |
| EXI-ORG-8 | P | Seul le mode de déploiement en GitOps est mis en oeuvre. Le développeur versione son code applicatif et d’infrastructure. Les déploiements par manifest "à la main" ne sont pas autorisés. | Modèle d'Opération |
| EXI-ORG-9 | I | Le développeur met en place un principe de livraison continue et par lot de taille réduite. | Modèle d'Opération |
| EXI-ORG-10 | I | Couverture et capitalisation des tests, respect des métiers (non régression): La couverture des tests unitaires du code visé pour le back-end doit être de 100% du code. La mise en place d'une approche test drive developpement est fortement recommandée. |
Code Applicatif & Image |
| EXI-ORG-11 | I | La couverture fonctionnelle des tests du front end permet de s’assurer de non-régression majeure. Elle permet de vérifier des séquences d’usage principale, (login, actes métiers fréquents, etc… ) | Qualité de la solution |
| EXI-ORG-12 | I | Les bugs détectés donnent lieu d’abord à l’implémentation d’un test automatique avant l’écriture du correctif. Cela permet d’augmenter la base des cas de tests et de renforcer la performance des tests de non régression. | Qualité de la solution |
| EXI-ORG-13 | P | L’équipe produit intégrée s’engage à monitorer les nouvelles vulnérabilités qui seraient susceptibles d' être découvertes et d’y remédier après le dernier déploiement stable. Elle met en œuvre les plans d’exploitation de sécurité et de maintien en condition de sécurité décrite notamment dans le dossier d’homologation. L'équipe prend en compte que la chaîne de construction applicative est susceptible de bloquer les déploiements si la qualité d’ensemble du code est en décroissance ou si des vulnérabilités critiques sont détectées L’équipe prend en compte que si le suivi des plans d’action n’est pas mis en oeuvre et que de surcroît des vulnérabilités critiques sont détectées depuis le dernier déploiement stable et que l’équipe projet n’a pas pris en compte les injonctions de correction, l’application sera susceptible d’être suspendu jusqu'à la remédiation pour garantir l’intégrité et la protection de ses données. Pour améliorer le "signal sur bruit" sur le plan des cve se référer à l'exigence sur la construction des images. |
Modèle d'Opération |
| EXI-ORG-14 | P | L’équipe projet ou équipe produit met en œuvre une activité continue de refactoring du code produit et réserve une capacité d'environ de 20% de la capacité d'ensemble avec des principes organisationnels tel que le peer review, un processus de maîtrise des changements (ex: lors des pull requests). La qualité du code mesurée ne peut pas être décroissante dans le temps. L'équipe fournit les preuves que des tests de sécurité, de qualité, de robustesse des algorithmes ont été mis en œuvre, et qu'ils n'ont pas remonté de vulnérabilités ou d'erreurs majeures. Ces preuves seront annexées au dossier d'homologation, et les actions suivies au sein du plan d'action. |
Qualité de la solution |
| EXI-ORG-15 | I | Dans l'objectif que le développeur soit notifié au plus tôt de défauts en modalité ”shift-left”, alerte de supervision l'équipe de développement mettra à disposition un point d'interface automatisé compatible avec les capacités d'alerting de la solution kibaba. | Modèle d'Opération |
| EXI-ORG-16 | I | Sont proposés des intégrations avec Mattermost et Tchap. S'il souhaite aller loin dans l'automatisation par exemple pour l'intégration dans les flux de travail, le développeur peut également proposer la mise en place d'un WebHook. | Modèle d'Opération |
| EXI-ORG-17 | P | L’orchestration de la sauvegarde est de la responsabilité de l’équipe de développement application | Modèle d'Opération |
| EXI-ORG-18 | I | L’équipe projet ou équipe produit teste régulièrement sa capacité à restaurer l’ensemble de l’architecture et des données de l’application avec un scénario de test connu à l’avance | Modèle d'Opération |
| --- | |||
| EXI-ARCH-1 | I | Choix du langage et du framework : Sauf mention explicite dans le cahier des charges, il est recommandé d'utiliser le ou les langages de programmation notés au sein de la liste des langages suivants : - Typescript / nodejs, python, Java(attention à la licence Oracle, privilégier OpenJDK) - Ruby ( normalisation ISO, framework de test et modules), Php ( point d'attention sur le déploiment dans une image conteneurisée car nécessite un server web ) - Go (pour l'automatisation de service cloud fortement supporté par Google) - RUST pour le typage / performance mémoire - Scala pour la performance en datascience / bigdata. - Variante de C Lors du choix de langage, il est conseillé de prendre en compte la capacité de maintien de la base de code, le maintien des compétences nécessaires sur le temps long > 5 ans. Le choix et la pertinence du ou des frameworks utilisées doit prendre en compte la couverture d'utilisation réelle du framework. Typiquement un framework entraine un couplage fort de la base de code avec celui-ci et entrainer un coût non négligeable de refactoring à chaque montée de version. Si un framework est faiblement utilisé il sera préférable d'isoler la fonction utilisée et de ne pas dépendre du framework. Sont préférés les écosystèmes de langages qui limitent les erreurs de programmation (typage et framework de test) avec des IDE et scan de qualité. supportés par une communauté large et active dans le domaine d'application visé. Pensez à vous appuyer sur des libraires ou des domaine de langage spécifique (DSL en anglais ) qui permettent la prise en compte de fonctionnalités complexes uniquement par du paramétrage de fichier et non par de l'algorithmie de codage pur. Dans le cas de conception de système à haute intensité transactionnelle, des langages compilés ayant une gestion efficace de la mémoire seront préférés. (typiquement Rust et C) Lors de la candidature à un appel d'offre, la motivation d'utilisation de tel ou tel langage sera argumentée. |
Langages |
| EXI-ARCH-2 | P | L'architecture interne de l'application et l'organisation sont conçus pour s'assurer que la durée maximale d'interruption acceptable (DMIA) désirée par le métier est atteinte, en combinant des mesures telles qu'un déploiement sur 2 datacenters ( résilience assurée au niveau applicatif), une architecture modulaire avec des principes de "graceful degradation" et les mesures organisationnelles. Pour la résillience intra datacenter, mettre des règles d'anti-afinités lors de la constitution des manifests / charts afin que les composants de la solutions sont bien distribués sur des AZ différentes. ( lorsque le cluster commandé le permet ) Vérifier que les composants de résillience de la solutions sont bien distribués au sein du cluster étendu sur des AZ différentes lors des déploiements. L'équipe doit confirmer que ses processus et les mesures en place atteignent l'objectif visé par des exercices réguliers. *notes: - lors de la contractualisation avec l'hébergeur par défaut seront proposés 2 environnements de production, 1 environnement hors production et 2 buckets S3 (prod/hors production) - la résilience applicatif est assurée au niveau applicatif actif / passif ou actif-actif selon le besoin métiers - utilisation de composant tel que https://cloudnative-pg.io/ permettent facilement la mise en place de HA pour la persistance de donnée - utilisation du S3 permet de mettre en place une disponibilité entre datacenter - gracefull dégradation est un mécanisme qui permet à un module, lorsqu'une dépendance n'est pas accessible de fournir une expérience dégradée mais restant acceptable à un usager, généralement une valeur par défaut basée sur un historique ou bien un affichage dégradé pour un navigateur ancien. |
Architecture |
| EXI-ARCH-3 | I | L’architecture de la solution est modulaire, le couplage organisationnel et technique est lâche entre les composants par l'usage d'une interface normée et documentée (ex: API). Les composants peuvent être déployés indépendamment les uns des autres sans nécessiter une coordination entre les équipes. Les services de haut niveau ne dépendent pas de l’interface offerte de composants de niveau inférieur ( principe d'inversion de dépendances). |
Architecture |
| EXI-ARCH-4 | P | Le point de présence et de vérité de la sauvegarde est assuré par un service de type S3 indépendant et résilient de l’architecte de production | Architecture |
| EXI-ARCH-5 | P | Pour l'usage de composants d'insfrastructure logicielle open source (ex: nginx, keycloak, airflow, https://quarkus.io/, etc... ) il est reccommandé de s'appuyer sur un repository communautaire de templacte ayant un cycle de mco/mcs fréquents et les charts helms et des images doivent être compilées rootless et de préférence multiarchitectures (cela augmente la surface de test ). Vérifiez systématique la date de dernière mise à jour et des vulnérabilités portées et l'accès au code source. Quelques principes fortement recommandés : - La configuration (valeur & secret) doivent être traités dans des fichier à part, géré en version tel que le mécanisme values.yaml des charts helm. Une façons pratique (et testé) consiste à placer les secrets et valeur de configuration liées à l'environnement directement au sein du namespace pour qui surcharge les valeurs par défauts, via une configMap ou un secret. Un exemple illustratif sur le service nginx https://github.com/bitnami/charts/blob/main/bitnami/nginx/values.yaml : Les paramètres de nginx du "serveurblock" peuvent être surchargée au runtime par un volume monté au lancement du pod. ( deploymentset ) - name: nginx-server-block mountPath: /opt/bitnami/nginx/conf/server_blocks Tip: comme les pod tourne en readonly fs par défaut, pensez à monter explicitement un volume /tmp emptydir : - name: empty-dir mountPath: /tmp subPath: tmp-dir |
Code Applicatif & Image d'infrastructure applicatif |
| EXI-ARCH-6 | P | Le choix d'image de base est un élément important et structurant pour le projet, plus l'image est 'fine' plus vous augmenterez le "signal sur bruit" de la détection de vulnérabilité spécifique à votre code. Pour du code "custom", il est recommandé d'utiliser des images de base (FROM) dans l'ordre : - Images custom à partir d'une distribution sans aucun tooling installé ( distroless ou minideb par exemple ) - Images issues de communautés reconnues, régulièrement mises à jour, et adapté à un usage sécurisé OpenShift (rootless, readonly FS, securityContext, etc.) comme bitnami pour les composants d'infrastructures (ex:nginx) ou si aucune image distroless n'est disponible. - Pour faciliter les travaux d'intégration, il peut être utile pour l'équipe de disposer d'une version "débug" incluant quelques outils courants tel que curl, tail, vi + un shell avancé. Dans ce cas 2 versions d'images sont maintenues : "version" et "version-debug". Lors de la construction des images custom, vous pouvez utiliser la methode de construction à 2 containers qui ne recopie que les fichiers utiles # exemple pour créer une image python/flask en production à 2 étapes. FROM python:3.8-slim as builder # Set the working directory WORKDIR /app # Copy the current directory contents into the container at /app COPY app.py /app # Install the dependencies RUN pip install --no-cache-dir flask boto3 gunicorn # Use a distroless Python image as a base FROM gcr.io/distroless/python3:nonroot # Set the working directory WORKDIR /app # Copy the dependencies and the app from the builder stage COPY --from=builder /app /app COPY --from=builder /usr/local/lib/python3.8/site-packages /app/site-packages COPY --from=builder /usr/local/bin/gunicorn /usr/local/bin/gunicorn ENV PYTHONPATH /app/site-packages VOLUME ["/tmp"] # Command to run the application CMD ["/usr/local/bin/gunicorn", "-b", "0.0.0.0:5000", "app:app"] Note / tips : - Les conteneurs fonctionnent en rootless et readonly, il impératif de placer un volumeMount "empty dir" aux emplacements clés ou l'application est succeptible d'écrire, tel que /tmp ( à voir en fonction de votre framework/langage ) volumeMounts: - name: empty-dir mountPath: /tmp subPath: tmp-dir Pour le débogage, il n'est pas possible "d'écouter" le traffic au sein de l'infrastructure. Pour faciliter l'intégration pensez à mettre en place dans votre code custom un loggin avancé, vous pouvez envisager de mettre en place des composants d'intermédiation (temporaire?) tel qu'un reverse proxy pour produire ces logs cf. article sur le build en multi-stage : https://docs.docker.com/build/building/multi-stage/. |
Services Mutualisés |
| EXI-ARCH-7 | P | Les certificats racines "CA" des PKI internes à l'organisation ou autres nécessiare doivent être intégrés aux images, afin que les services consommant des end-points https puissent valider les certificats de celui-ci. (le certificat du end point ne doit pas être intégré puisqu'ils est amenés à être renouvelé, et généralement au mauvais moment ) Tips : L'ensembles des langages et frameworks mette en oeuvre des comportements différents sur l'usage des CA racines, il a été constaté 2 cas généraux : - Le cas idéal : les runtimes ou applications permettent de monter les CA depuis fichier ou un répertoire au lancement. Dans ce cas les fichiers ou volumes contenant les certs .crt ou .pem peuvent être montés via un volume à partir d'un objet configmap ou d'un secret. - Le cas complexe : le service utilise le CA-bundle de l'os, nécessitant que la commande "update-ca-certificates" soit être utilisée pour inclure les CA de l'organisation. Cette action ne peut qu'être réalisée à la création de l'image, par exemple par un processus multi-build. ( cf exigence sur la construction des images custome ) |
|
| EXI-ARCH-8 | I | Le déploiement est réalisé via gitops ( argoCD) L'architecture de déploiement d'application est organisée pour déployer indépendamment les modules de l'application, sans couplage entre-eux. Typiquement l'application est découpée en une application maître d'ensemble référençant le déploiement de sous-applications. L'ensemble est géré en version dans un git. Chaque changement est réalisé via un git push ou via pull request si l'équipe a mis en place une relecture collective du code de version |
|
| EXI-ARCH-9 | P | L'équipe met en place une stratégie gitops et "d'immutability" de la configuration de l'infrastructure Chaque nouveau déploiement recrée un environnement nouveau ("écrase" l'ancien). Le déploiement met en oeuvre une stratégie de reprise de données applicative à chaque nouveau déploiement. (la sauvegarde des données applicatives doit être effectuée régulièrement, juste avant le nouveau déploiement ) A titre d'exemple, l'opérator cnpg de postgres (https://cloudnative-pg.io/) permet de mettre en place ce type de pratique. |
|
| EXI-ARCH-10 | P | Consommation systématique des services socles. (chaîne de service, IAM, Vault, etc...) Dans le cas où plusieurs services sont susceptibles d’être utilisés, privilégier les services dont l'enrôlement est automatisé. |
Services Mutualisés |
| EXI-ARCH-11 | P | Identification utilisateur : l’application doit obligatoirement utiliser le SSO Agent disponible et/ou France connect pour les citoyens | Architecture |
| EXI-ARCH-12 | P | L’application doit pouvoir être monitorée techniquement et fonctionnellement (dont healthcheck) au travers de service de télémétrie mis à disposition par l'application. ( obligatoire sous kubernetes ) Mise à disposition obligatoire au sein de la solution des API de supervision auto descriptive /health (json+problem) et /metrics (prométheus) et Intégration obligatoire de la solution dans la (ou les) chaîne(s) de supervision |
Code Applicatif & Image |
| EXI-ARCH-13 | I | Les services applicatifs d'observabilité (logs et télémétrie), registre d'image et gestion des secrets mis à disposition par l'offre Cloud Pi Native doivent être utilisés. | Services Mutualisés |
| EXI-ARCH-14 | I | L’application prend en compte dans sa conception : la séparation des flux usagers, de services et d’administration, l’utilisation privilégiée du protocole https et l’authentification mutuelle des composants. Pour minimiser les spofs et la surcharge de trafic inutiles des équipements de protection, l’interconnexion entre applications mutuellement connues au sein d’un même niveau de sensibilité ne requiert pas, le transit des fluxs via une passerelle ou un composant d’APi management. (ex: chaine de service ) |
Architecture |
| EXI-ARCH-15 | I | Les modules de l'application permettent un fonctionnement en mode dégradé, si une dépendance ne devait plus être disponible (ex arrêt d'un autre module). "Graceful degradation" | Architecture |
| EXI-ARCH-16 | P | L'architecture et les développements garantissent l’idempotence des transactions | Architecture |
| EXI-ARCH-17 | I | L’application minimise le besoin d’échange synchrone. Les échanges asynchrones sont réalisés via un bus de message favorisant de découplage les modules et l'ajout facilité de service en écoute. | Architecture |
| EXI-ARCH-18 | P | Les images de conteneurs sont conçues pour s'exécuter “rootless” sur des ports réseaux internes sont > 1024 et ne nécessite pas d'élévation de privilèges. L’image est minimaliste, concentrée sur une fonction primaire ou atomique du système. Elles sont conçues pour démarrer très rapidement avec le moins de dépendance possible ( dans l'intérêt de la résilience et du bon fonctionnement de l'orchestrateur) L’image n'embarque pas de services exposant des services réseau non essentiels à son fonctionnement tel que SSHD. L’image ne se modifie pas elle-même au lancement. ( ce qui souvent nécessite des élévations de privilèges ) L’écriture dans les pods n’est possible qu’avec le montage d’un volume. (note : L’exécution du pod bloquée si ces règles ne sont pas respectées ). cf. https://docs.openshift.com/, et en particulier https://docs.openshift.com/container-platform/4.15/openshift_images/create-images.html ( toujours vérifier la dernière version ) |
Code Applicatif & Image |
| EXI-ARCH-19 | P | Les pods applicatifs stateless doivent pouvoir être redémarrés rapidement et à tout instant, sans affinité de session par l'orchestrateur. L’application est conçue pour minimiser les pertes de données, de transactions en cours ainsi que l’idempotence de celle-ci en cas de bascule de noeuds. |
Code Applicatif & Image |
| EXI-ARCH-20 | P | Les modules de l'application s'exécutent sans état (Stateless) et s'appuient sur la résolution de nom interne de kubernetes pour communiquer entre-eux. Les processus/microservices sont indépendants les uns des autres. Les états sont stockés dans un magasin de données centralisé. Cela pour garantir un mise à l'échelle et continuité de service de l’application (Principe Stateless) |
Architecture |
| EXI-ARCH-21 | I | L’application est conçue pour un déploiement en continu, la conception du modèle de données permet à la version future et l’actuelle de coexister sans impact fonctionnel. | Architecture |
| EXI-ARCH-22 | P | **La configuration de l’application ne doit jamais être codé en dur**. La configuration de l'application doit provenir de l'environnement (principe Config des 12 facteurs : https://12factor.net/config). note : l'utilisation de charts helm avec un fichier values.yaml permet de couvrir l'exigence. |
Déploiement |
| EXI-ARCH-23 | I | L’ensemble des services applicatifs/processus de l’application, et ses services de supports génèrent leurs propres flux d'événement bruts pour apporter une visibilité sur son comportement. La norme de nommage des fluxs d'événement est, sans condition, respectée. (Principe d’observabilité) Les logs doivent obligatoirement être redirigés vers la sortie standard. |
Architecture |
| EXI-ARCH-24 | P | La performance de toutes les transactions réalisées par l’application doit être mesurable en temps réel pour contrôler la qualité de services et soutenir les investigations en cas de dysfonctionnement. Il est préconisé d’assurer la surveillance de l’application à minima au travers de : Flux d'événement de performance applicative, flux d'événement et donnée pour analyse et reporting métier, journaux d’intégrité et du système (Principe de Télémétrie) | Architecture |
| EXI-ARCH-25 | I | L'application doit respecter dans sa conception les 12 facteurs d'une application Cloud Native : https://12factor.net/fr | Architecture |
| EXI-ARCH-26 | I | Les déploiements au sens kubernetes ne doivent pas imposer d'élements sur les sécurityContexts. Sont notamment interdits : runAsUser, runAsGroup, fsGroup, allowPrivilegeEscalation, add capabilities, etc. De la même façon, il n'est pas autoriser de monter des ressources depuis le node (hostPath par exemple) |
Architecture |
| EXI-ARCH-27 | P | Si spécifié, le paramètre imagePullPolicy doit être positionnée sur la valeur IfNotPresent. ( permet de découpler le cluster de la registry ) Le tag des images sélectionnées doit une valeur explicite de version. La valeur "latest" est à proscrire. Cf. https://kubernetes.io/docs/concepts/containers/images/ ou https://docs.openshift.com/container-platform/4.8/openshift_images/managing_images/image-pull-policy.html | |
| --- | |||
| EXI-DATA-1 | I | L’application privilégie une architecture en micro service et expose systématiquement les objets métiers principaux. La direction de programme fournit une description de son api et précise les conditions d’accès. L’application fournit à minima un fichier valide de description d'Open API et des exemples de données libre d’usage (Ex: Données anonymisées ) permettant de dérouler des cas de tests significatifs. |
Données |
| EXI-DATA-2 | P | Pour la persistance de données personnelles soumises au RGPD, le modèle de données intègre dès la conception, un tag RGPD, des champs dupliqués dédiés à l’anonymisation et des règles et processus d’anonymisation ainsi qu’une politique de droits associés. | Données |
| EXI-DATA-3 | I | Consommation systématique des données de référence ministérielles | Données |
| EXI-DATA-4 | I | Référencement des objets métiers dans le catalogue des données métiers | Données |