Le tableau suivant fourni les exigences liés à l'approche Cloud Native
| ID | Type | Exigence | Nature | Catégorisation |
| EX1 | 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. | Ministériel | Autres normes et standards |
| EX2 | P | Principe de non déviance et de non fragmentation des normes. Les éventuelles instructions de niveaux inférieurs ne peuvent prévaloir sur les présentes exigences. | Ministériel | Autres normes et standards |
| EX3 | P | Dans le cadre d’un appel d’offre en cas d’incohérence entre les documents, le cct et la liste des exigences sont supérieurs. Le lecteur est invité à vérifier s’il dispose de la version la plus à jour. | Ministériel | Autres normes et standards |
| EX4 | 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, l’absence de défaut de sécurité et de correction avant toute mise en production. | Ministériel | Modèle d'Opération |
| EX5 | P | Intégration technique de l’usine logicielle à la chaîne De SecOps, maintien par le développeur en condition de disponibilité et de sécurité du point de vérité du logiciel et code d’infrastructure. Exigence limitée à la durée du marché pour un opérateur économique, mais permanent pour la direction d’application. | Ministériel | Modèle d'Opération |
| EX6 | I | Conformité au modèle de responsabilité “you built it - you run it”Les développeurs/concepteurs sont responsables du bon fonctionnement de l’application en production. ( il collabore avec l’hébergeur le cas échéant) | Ministériel | Modèle d'Opération |
| EX7 | P | L’orchestration de la sauvegarde est de la responsabilité de l’application | Ministériel | Modèle d'Opération |
| EX8 | I | L’équipe projet 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 | Ministériel | Modèle d'Opération |
| EX9 | I | Couverture fonctionnelle des tests du front end permet de s’assurer de non-régression majeure. (exigence à affiner) | Ministériel | Modèle d'Opération |
| EX10 | I | La couverture fonctionnelle des tests unitaires du back end est de 100% | Ministériel | Modèle d'Opération |
| EX11 | I | Le développeur, usagers de la chaîne de livraison logicielle, 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é. | Ministériel | Modèle d'Opération |
| EX12 | P | Mise en place organisationnelle et technique de modalité de collaboration étendue continue intégrant (« shift-left ») le flux d’erreur de la chaîne de DevSecOps secondaire. La chaîne secondaire reconstruit les images à partir des codes sources et procède aux mêmes tests avec des outils complémentaires. L’orchestration du pipeline de la chaîne secondaire est supervisée par l’équipe et intègre obligatoirement les tests de vérification issue de la démarche d’homologation de l’application, test de qualité du code (et de couverture de test) et de vulnérabilité.note : **La chaîne secondaire bloque les déploiements si la qualité d’ensemble du code est en décroissance ou si l’ensemble porte des vulnérabilités critiques.**L’équipe de développement reçoit via l’interface “shift left” une notification des rapports qui doit être intégrée au flux de travail pour correction.Exigence limitée à la durée du marché pour un opérateur économique, mais permanente pour la direction d’application. | Ministériel | Modèle d'Opération |
| EX13 | P | Conformité au modèle de responsabilité Cloud Pi Native L'opérateur de la chaîne CI/CD est responsable du build, de l'exécution des tests fournis et du déploiement de l'application | Ministériel | Modèle d'Opération |
| EX14 | P | Le développeur prend en compte qu’aucune modification n’est effectuée directement en production. Il n’accède pas à l’API kubectl.Toute modification en production doit être effectuée via un versionning du point de vérité GitOps | Ministériel | Modèle d'Opération |
| EX15 | P | L'ensemble des éléments permettant de compilers / builder, tester et exécuter l'application ainsi que déployer l'infrastructure et ouvrir les flux réseaux doivent être fournis par le Développeur / Concepteur à l'opérateur de la chaîne CI/CD. L'ensemble de ces éléments sera soumis à un contrôle strict de la part de la chaîne CI/CD du Ministère, notamment pour vérifier que l'infrastructure et les flux réseaux sont en cohérence avec la politique de sécurité du Ministère. | Ministériel | Modèle d'Opération |
| EX16 | I | Intégration technique de l’usine logicielle à la chaine DevSecOps, maintien par le développeur en condition de disponibilité et de sécurité du point de vérité du logiciel et code d’infrastructure et du WebHook ”shift-left” par l’équipe de développement tout au long du contrat. | Ministériel | Modèle d'Opération |
| EX17 | I | L’agilité (à l’échelle) en tant que cadre de travail privilégié et mise en place d’un principe de livraison continue par lot de taille réduite. | Ministériel | Modèle d'Opération |
| EX18 | P | Mise en place d’un principe de collaboration étendue, continue et intégré des processus de livraisons, adéquation de la solution au besoin via l’observabilité, maintien de la qualité, de la disponibilité et de sécurité depuis le développement juste qu’à la production | Ministériel | Modèle d'Opération |
| EX19 | P | La disponibilité cible de l’application est de la responsabilité de la direction d’application qui définit l’architecture technique et organisationnelle en s’appuyant sur les services de l’opérateur et la disponibilité visée | Ministériel | Infrastructure |
| EX20 | I | Formation et de maintien réguliers des compétences des personnels à la technologie Cloud Native (kubernetes), l’agilité et au devsecops, intégration et contribution à la communauté de pratiques Cloud (pi) Native. | Ministériel | Modèle d'Opération |
| EX21 | I | Remontée des défauts, contribution à l’enrichissement de la chaîne DevSecOps et l’offre Cloud Native. | Ministériel | Modèle d'Opération |
| EX22 | P | Le code applicatif doit être testé avant d'être soumis à la chaîne CI/CD du ministère(fonctionnellement, techniquement et sécurité) | Ministériel | Code Applicatif & Image |
| EX23 | P | L’application déploie un collecteur de log (à partir des patterns/service disponibles) et l’intègre avec le collecteur “SIEM” du SOC. Une convention de service est établie. | Ministériel | Code Applicatif & Image |
| EX24 | P | Le concepteur/développeur est libre d'utiliser le langage de programmation de son choix issu de la liste des langages autorisés. ( principaux langages ) | Ministériel | Code Applicatif & Image |
| EX25 | P | L’application doit pouvoir être monitorable techniquement et fonctionnellement (dont healthcheck) au travers du service de télémétrie mis à dispositionMise à 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 | Ministériel | Code Applicatif & Image |
| EX26 | 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 la solution. | Ministériel | Code Applicatif & Image |
| EX27 | I | Couverture et capitalisation des tests, respect des métiers (non régression): La couverture des tests unitaires cible visée pour le back-end doit être de 100% code et significative sur le front end tel que par exemple vérifier des séquences d’usage principale, (login, actes métiers fréquents, etc… ). 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. | CloudNative | Code Applicatif & Image |
| EX28 | P | Les pods “stateless” doivent pouvoir être redémarrés à tout instant, très rapidement et sans perte de sessions, données ou de transactions. | Ministériel | Code Applicatif & Image |
| EX29 | P | Les sources d’OS servant à la constitution de images de l’application proviennent exclusivement de souche os ayant un support long terme (LTS) d’une communauté active qui maîtrise les packages par un processus organisationnel à révision contrôlé. (typiquement éviter Alpine). note : La liste est maintenue en interministérielle (Dinum et Anssi ) | Ministériel | Code Applicatif & Image |
| EX30 | I | Utilisation privilégiée de composants open-source avec une communauté active, suivi des versions maintenues. ( Politique & roadmap des versions, fréquence des commits, nb de contributeurs ou garantie ) | Ministériel | Code Applicatif & Image |
| EX31 | I | L’architecture de la solution est modulaire, le couplage organisationnel et technique est lâche entre les composants (ex APi)., les services de haut niveau ne dépendent pas de l’interface offerte de composants de niveau inférieur ( dépendance inversion principe) | Ministériel | Code Applicatif & Image |
| EX32 | P | Les conteneurs s'exécutent sans requérir à l’utilisateur root et les ports réseaux internes sont > 1024. ( l’exécution de conteneur non rootless est bloquée en production ) | Ministériel | Code Applicatif & Image |
| EX33 | I | 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 dont le Concepteur/Développeur s’assure régulièrement de sa capacité à restaurer. | Ministériel | Code Applicatif & Image |
| EX34 | P | La compilation et la certification des images est effectuée au sein de l’orchestrateur DevSecOps ministériel. Le développeur s’organise autour de cette contrainte. | Ministériel | Code Applicatif & Image |
| EX35 | P | Choix d’un hébergement adapté à la nature de la donnée manipulée et selon le cadre légal adapté. (Cloud public, Cloud Régalien référencé par la doctrine Cloud au centre, Dédié) | Ministériel | Infrastructure |
| EX36 | I | Les services applicatifs d'observabilité (logs et télémétrie), registre d'image et gestion des secrets mis à disposition doivent être utilisés. | Ministériel | Services Mutualisés |
| EX37 | I | Consommation systématique des données de référence ministérielles | Ministériel | Services Mutualisés |
| EX38 | I | Référencement des objets Métiers dans le catalogue des données Métier du MI | Ministériel | Services Mutualisés |
| EX39 | P | Les services applicatifs mis à disposition ne doivent pas être remplacés par un équivalentConsommation systématique des services socles à enrollment automatisés : IAM, service d’échange (ident/authent, preuve probante/non-répudiation, exposition de services, référentiels, pfs SIG, ...) | Ministériel | Services Mutualisés |
| EX40 | I | Le service de stockage objet doit systématiquement être utilisés pour les sauvegardes | Ministériel | Services Mutualisés |
| EX41 | P | Le bastion doit systématiquement être utilisé pour les activités d'administration | Ministériel | Services Mutualisés |
| EX42 | I | L’application minimise le besoin d’échange synchrone, les échanges asynchrones sont réalisés via un bus de message. | Ministériel | Intéractions & Flux |
| EX43 | Séparation des flux usagers, de services et d’administration, utilisation privilégiée du protocole http | Ministériel | Intéractions & Flux | |
| EX44 | I | Toute API exposée doit l'être via le service API management mis à disposition qui identifie + authentifie les consommateurs. L’application met en place la traçabilité en s’appuyant sur la solution d’observabilité disponible. | Ministériel | Intéractions & Flux |
| EX45 | I | Les objets et données métiers doivent systématiquement être exposés via le service d'API management fourni.Enrollement automatisé des objets métiers via API ( restful, GraphQL,gRPC) sur les passerelles API Cloud Native. La direction de programme fournit une description de son api et précise les conditions d’accès:La direction de programme fournit un kit de proxification de l’APi de son service avec une donnée libre d’usage (Ex: Données anonymisees ) permettant de dérouler des cas de tests significatifs. Le kit livré est déployable sous la forme d’un micro-service déployable dans Kubernetes via chart Helm qui est inscrit au catalogue du mi.. (Voir les exemples de service d’accélération) | Ministériel | Intéractions & Flux |
| EX46 | P | L’application est responsable de fournir un fichier de description (ex: open api / swagger ) qui respecte les standards, préalablement à l’enrôlement en production l’application une vérification est effectuée et l’application doit corriger les défauts. | CloudNative | Code Applicatif & Image |
| EX47 | P | Utilisation de la variabilisation des configuration d’environnement, des services de support (bdd, cache distribué,..), service externe, connectivités.. .la configuration de l’application ne doit jamais être codé en dur | CloudNative | Code Applicatif & Image |
| EX48 | I | Maximiser l'accès aux Services tiers et locaux au travers de chaînes de connexion standard (non spécifique au fournisseur de solutions pour favoriser les changements de Service sans impact utilisateur (Principe de d’architecture BackEnd) | CloudNative | Code Applicatif & Image |
| EX49 | P | L'application s'exécute sans état (Stateless). Ses 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) | CloudNative | Code Applicatif & Image |
| EX50 | P | Garantir l’idempotence des transactions en cas d'arrêt progressif des services (SIGTERM). | CloudNative | Code Applicatif & Image |
| EX51 | I | S’efforcer de minimiser le temps de démarrage du processus/service en limitant l’environnement au juste nécessaire. (principe Jetable) | CloudNative | |
| EX52 | I | L’application est prévue 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. | CloudNative | Code Applicatif & Image |
| EX53 | 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é) | CloudNative | Code Applicatif & Image |
| EX54 | P | Toutes applications mise en ligne doit fournir une API clairement définie et documentée, pour faciliter sa consommation future des contrats d’interface (Principe de Api first) | CloudNative | Code Applicatif & Image |
| EX55 | 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) | CloudNative | Code Applicatif & Image |
| EX56 | P | Identification utilisateur : L’application doit obligatoirement utiliser le SSO Agent disponible et/ou France connect pour les citoyens | CloudNative | Code Applicatif & Image |
| EX57 | I | 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. | Ministériel | Autres normes et standards |
| EX58 | P | L’équipe de développement respecte les règles suivantes permettant une qualité de code en progression et un maintien de la sécurité :- minimise la portion spécifique de code développés en s’appuyant sur le catalogue des services proposés. (revoir régulièrement) - met en place une couverture de test unitaire complète du back-end ( et fourni les moyens de vérification automatisé à la chaîne secondaire ) - mener une analyse de code systématique le plus tôt possible ( les langage et IDE modernes fournissent des fonctions de ce type ) - mener une analyse de CVE des dépendants importées. L’équipe projet met en œuvre une activité continue de refactoring du code produit. La qualité du code ne peut être décroissante. Elle 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. En s’appuyant notamment sur les logs des analyses des outils de la chaîne primaire. Elle fournit la preuve (ex: le document) des normes de développement et pratiques permettant de maîtriser la qualité du code produit. ( refactoring, peer review, etc.. ) | Ministériel | Modèle d'Opération |