pour la création de la plateforme «____________________»

sur les 44 pages

Vous pouvez télécharger le document sur le lien

Historique des modifications du document

SOMMAIRE

Liste des abréviations, symboles, unités et termes

1 Informations générales

1.1 Nom du système et son abréviation

Nom complet : _______ 

Nom abrégé (désignation conventionnelle) : Plateforme.

1.2 Liste des documents sur la base desquels le développement est effectué

1.2.1 Liste des documents sur la base desquels le système est créé

1. _______ 

2. _______

3. _______ 
4. _______ 
5. _______ 
6. _______ 

1.2.2 Liste des documents pris en compte lors de la création du système

2 Objectifs et buts de la création du système

2.1 Objectif du système

La plateforme est destinée à la numérisation des procédures _______ et assure une large intégration avec les systèmes externes et internes, ainsi que la mise en œuvre du concept de gestion documentaire sans papier.

2.2 Objectifs de la création du système

L'objectif de la création de la Plateforme est d'assurer la création, la consultation, l'envoi, la réception, la collecte, l'introduction, l'accumulation, le stockage, le traitement, l'utilisation, l'examen, la conservation, la protection, l'enregistrement et la fourniture d'informations dans le domaine ____________, ainsi que l'interaction électronique entre __________________________ dans le but d'obtenir des services administratifs dans le domaine _______________________. 

Les services administratifs qui doivent être fournis via la Plateforme dans le domaine ________________________ comprennent les services suivants :

1. _______ 
2. _______ 
3. _______ 
4. _______ 
5. _______ 
6. _______ 
7. _______ 
8. _______ 

3 Caractéristiques de l'objet d'automatisation

3.1 Brèves informations sur l'objet de l'automatisation

L'objet de l'automatisation est l'ensemble des processus définis au point 2.2. Objectifs de la création du système dans le domaine ____________________.

Le sujet de l'automatisation est constitué des processus de traitement des demandes en ligne provenant d'institutions, d'organisations, d'établissements et de spécialistes travaillant dans le domaine  ___________, à savoir :

• _______ 
• _______ 
• _______ 
• _______ 
• _______ 
• _______ 

4 Exigences fonctionnelles

4.1 Exigences relatives au système dans son ensemble

Les fonctionnalités de la plateforme doivent garantir :

1. une procédure d'identification et d'authentification électroniques à l'aide d'un système intégré d'identification électronique des utilisateurs ;

2. l'autorisation des utilisateurs ;

3. l'accès aux documents électroniques et aux informations relatives à leur enregistrement lors de l'obtention de services administratifs dans le domaine __________________ ;

4. la préparation et la soumission de documents électroniques via le bureau électronique ;

5. la soumission d'une demande pour obtenir des services ;

6. obtention du résultat de la prestation du service administratif dans l'interface de la Plateforme ;

7. réception et examen par les responsables des autorités publiques des documents électroniques soumis via le bureau électronique (à l'exception de ceux qui sont traités automatiquement), avec enregistrement automatique de l'heure d'envoi et de réception, ainsi que la garantie de l'intégrité et de l'authenticité des documents électroniques ;

8. saisie d'informations (enregistrement) dans les registres par les utilisateurs ;

9. envoi automatique par des moyens logiciels d'une notification sur l'état d'avancement de l'examen des documents électroniques et sur la décision prise à l'issue de cet examen à l'adresse électronique et au bureau électronique ;

10.   interaction électronique avec d'autres ressources d'information électroniques publiques ;

11.   vérification automatique par des moyens logiciels de l'exhaustivité des informations contenues dans les documents électroniques soumis pour obtenir des services dans le domaine _____________ ;

12.  contrôle automatique du contenu et confirmation de l'intégrité des documents électroniques ;

13.  enregistrement automatique et saisie des informations correspondantes dans les registres ;

14.  la mise en œuvre de procédures et de mesures visant à contrôler et à vérifier les informations, à surveiller les modifications des informations individuelles, à protéger les informations et les logiciels, y compris contre tout accès non autorisé ;

15.  le cryptage et le décryptage des documents électroniques lors de leur transmission ;

16.  gestion des droits d'accès à l'information ;

17.  la protection des informations traitées sur la Plateforme, conformément aux exigences de la législation en matière de protection des informations ;

18.  accessibilité des informations pour les utilisateurs malvoyants ;

19.  enregistrement des actions des utilisateurs des services électroniques ;

20.    possibilité de collecter des données statistiques sur les indicateurs suivants : nombre de brouillons créés, nombre de demandes soumises, nombre de demandes approuvées, nombre de demandes refusées ;

21.  évolutivité de la solution tant horizontalement que verticalement.

Le traitement des demandes reçues via la plateforme doit être effectué dans le bureau électronique du fonctionnaire habilité à cet effet. L'accès au bureau électronique doit se faire à l'aide de l'eID de l'employé concerné.

L'accès aux services électroniques créés doit être fourni aux utilisateurs externes à partir de postes de travail automatisés basés sur des ordinateurs personnels, des ordinateurs portables, des tablettes ou des smartphones connectés à Internet. Pour utiliser les services électroniques, les utilisateurs externes doivent disposer d'un navigateur web moderne installé et configuré.

Tout utilisateur de services électroniques est une personne physique ou morale qui agit en tant que client des services.

4.2 Exigences relatives à la structure et au fonctionnement du système 

4.2.1 Exigences relatives à la structure du système 

La plateforme doit comprendre les composants suivants :

• Systèmes d'identification et d'authentification électroniques ;

• Cabinet électronique de l'utilisateur ;

• Système de gestion des processus métier ;

• Système de tenue des registres ;

• Système de génération de messages ;

• Systèmes de connexion. 

4.2.1.1 Exigences relatives au système d'identification et d'authentification électroniques 

Le système d'identification et d'authentification électronique est un module technologique autonome (microservice) qui assure l'enregistrement/l'autorisation de l'utilisateur, selon le protocole oAuth 2.0, pour travailler avec les services du client. Le système remplit la fonction d'autorisation à l'aide de l'eID. Le système d'identification et d'authentification doit être construit selon les principes SPA.

Le système d'identification et d'authentification doit assurer :

• l'autorisation de l'utilisateur selon le protocole oAuth 2.0 ;

• l'autorisation à l'aide de l'eID ;

• la conservation des informations sur l'utilisateur (profil utilisateur) en tenant un registre des utilisateurs enregistrés et en leur attribuant un identifiant unique ;

• l'identification de l'utilisateur par le le numéro d'identification, la carte d'identité ou la série et le numéro du passeport.

L'architecture SPA du système d'identification et d'authentification doit garantir l'indépendance du module d'affichage des informations par rapport au module de stockage et de gestion des informations. Une API REST est prévue pour l'administration de ce système. 

4.2.1.2 Exigences relatives au compte utilisateur électronique 

Le compte électronique est construit selon les principes SPA, ce qui permet aux utilisateurs d'obtenir des services administratifs, de soumettre des documents, etc. L'accès aux fonctionnalités est réparti en fonction des droits et garantit la fiabilité et l'authenticité de l'affichage des informations. L'accès aux fonctions est réparti à l'aide de rôles définis.

Le compte électronique doit permettre :

• la soumission de demandes pour obtenir des services électroniques ;

• un accès distribué en fonction du rôle de l'utilisateur ;

• la fonctionnalité des messages entrants ;

• l'attribution des tâches à accomplir par l'utilisateur ;

• la réattribution des tâches à d'autres utilisateurs du même groupe ;

• interface de formulaires interactifs générés par l'interpréteur, sur la base d'un modèle de document dans le système de gestion des processus métier ;

• création de pages uniques du portail ;

• signature de documents et de données à l'aide de l'eID ;

•  possibilité d'apposer une signature multiple sur un document ;

• cryptage et décryptage des données eID de l'utilisateur ;

• interface de gestion des registres se trouvant dans le système de gestion des registres ;

• fourniture d'éléments de gestion des flux documentaires pour l'échange entre l'utilisateur et l'utilisateur autorisé du système ;

• accès au profil de l'utilisateur ;

• fonctionnalité de confirmation de l'adresse électronique et du numéro de téléphone ;

• fonctionnalité d'exécution des paiements ;

• intégration avec les services de paiement ;

• intégration avec le système de gestion des registres ;

• intégration avec le système d'identification et d'authentification électroniques ;

• intégration avec le système de gestion des processus métier.

4.2.1.3 Exigences relatives au système de gestion des processus métier 

    La création de services électroniques est mise en œuvre sur la Plateforme via le système de gestion des processus métier.

    Chaque service sur la Plateforme est un processus métier qui est décrit à un niveau supérieur à l'aide de la notation BPMN dans le constructeur de processus de la Plateforme. L'objectif principal de cette étape est de décrire les flux de données et de donner une idée générale de l'algorithme de mise en œuvre du service.

    Le processus métier se compose de blocs logiquement complets. Chacun des blocs, en fonction de son type, remplit la fonctionnalité suivante :

• début et fin du processus ;

• remplissage du formulaire utilisateur et création d'un document ou d'une demande signé(e) à l'aide de l'eID ;

• passerelle pour l'exécution d'opérations logiques ;

• messagerie ;

• intégration des processus métier à la plateforme.

    Le système de gestion des processus métier doit être développé sur la base d'une plateforme universelle dotée d'outils d'automatisation des processus métier et de propriétés d'interopérabilité. Le système doit être compatible avec les normes de modélisation des processus métier dans la notation BPMN, assurant la mise en œuvre d'une modélisation pratique de l'algorithme de traitement des services électroniques et d'autres processus.

    Le système de gestion des processus métier doit garantir :

• la compatibilité avec la norme de notation BPMN pour la conception des processus métier ;

• la création/modification/stockage/exportation/importation de schémas BPMN ;

• la possibilité de concevoir des formulaires visuels interactifs avec lesquels l'utilisateur interagit via le Cabinet électronique, en utilisant les formats de données JSON et XML ;

• la prise en charge du multilinguisme, notamment la traduction des noms des processus métier, des tâches, des messages et des éléments des formulaires, le stockage de versions multilingues des processus et la possibilité de changer la langue de l'interface utilisateur ;

• configuration de formulaires interactifs à l'aide du glisser-déposer ;

• création/édition/enregistrement/exportation/importation de formulaires visuels ;

• prise en charge de la spécification technique ASiC container pour l'échange de documents avec d'autres systèmes ;

• prise en charge des versions des processus métier ;

• outils pour le débogage visuel des processus métier ;

• création et suivi des tâches assignées qui font partie des étapes des schémas BPMN ;

• présence d'un courtier de messages (file d'attente de messages) qui assure l'exécution des processus et l'intégration avec d'autres services ;

• génération d'événements automatiques liés au passage des étapes des schémas BPMN ;

• présence d'un journal des événements générés par les processus métier ;

• intégration avec le système d'identification et d'authentification ;

• accès distribué au système grâce à la création de rôles distincts ;

• possibilité pour l'utilisateur d'appartenir simultanément à plusieurs rôles ; 

• possibilité de gérer l'accès au service des registres ;

• journal des modifications des droits d'accès ;

• journal d'autorisation ;

• fonctionnalité permettant d'ajouter un rôle aux utilisateurs non autorisés, qu'ils (les utilisateurs) acquièrent après leur première autorisation ;

• attribution de tâches à des utilisateurs non autorisés dans le système, l'identification se faisant par le numéro d'identification, la carte d'identité ou le numéro et la série du passeport ;

• recherche et consultation des journaux d'exécution des processus ;

• module d'analyse et de visualisation des journaux des processus et des connexions ;

• présence d'un module de chiffrement et de déchiffrement des données à l'aide d'eID ;

• présence d'un module d'apposition d'une signature électronique sur les objets de données ;

• présence d'un module « gateway » assurant le routage du processus métier ;

• présence d'un module « task » assurant l'interaction avec l'utilisateur via le bureau électronique ;

• présence d'un module « événement » assurant l'exécution d'événements planifiés tels que l'envoi de requêtes à un autre système, etc. ;

• possibilité de redémarrer les processus métier depuis n'importe quel endroit ;

• présence d'un module générateur de documents au format PDF. Le module doit être intégré à des formulaires visuels qui génèrent les modèles nécessaires pour le format PDF ;

• prise en charge de la génération de codes QR par tant comme élément distinct que comme partie intégrante d'un document PDF, le document PDF pouvant contenir un code QR qui renvoie vers lui-même ou vers une page web publique contenant un extrait d'informations limitées destinées à être partagées ;

• présence d'un module de génération de liens ouverts permettant d'accéder aux fichiers sans autorisation ;

• détermination de la durée d'exécution des tâches ;

• traitement des documents à l'aide d'une signature électronique ;

• présence d'un module de codification automatique du document avec garantie d'unicité et possibilité de personnaliser le modèle de codification du document ;

• l'accès aux fichiers stockés dans le référentiel de fichiers pour le téléchargement doit être mis en œuvre au moyen d'un lien spécialement généré, délivré sous forme de jeton dont la validité est limitée dans le temps ;

• présence d'un service d'intégration avec d'autres services ; 

• possibilité de personnaliser et de modéliser les processus métier sans avoir besoin d'intégrations réelles, ce qui permet de concevoir des processus dans les cas où les registres externes sont temporairement inaccessibles ou où les intégrations ne sont pas encore mises en œuvre ;

• utilisation automatique des données utilisateur validées obtenues à partir de l'eID lors de la formation de requêtes vers des systèmes d'information et des registres externes ;

• présence d'une API REST pour l'administration du système ;

• intégration avec le registre national unique des personnes morales, des entrepreneurs individuels et des organisations publiques ;

• interaction avec les systèmes automatisés et les ressources d'information et d' s de l'État ;

• application instantanée des modifications dans le processus métier dans le bureau électronique de l'utilisateur sans avoir à redéployer ou à mettre à jour manuellement l'application ;

• prise en charge de l'appel des processus métier entre différents environnements ou plateformes, notamment :

  • lancement asynchrone du processus sur une autre plateforme ;

  • attente des résultats d'exécution ;

  • traitement des réponses reçues en vue de la prise de décisions ultérieures dans le cadre du processus en cours ;

• possibilité de construire des scénarios inter-environnements dans lesquels, par exemple :

  • la demande est soumise dans un environnement externe (pour les utilisateurs publics) ;

  • elle est ensuite transférée vers un environnement interne (pour les personnes autorisées) ;

  • la décision est prise dans l'environnement interne ;

après quoi le résultat (par exemple, le statut ou l'extrait) est automatiquement renvoyé à l'environnement externe et affiché au demandeur.

• assurer l'interopérabilité, qui comprend des interfaces d'interaction logicielle pour garantir l'obtention d'informations à partir des sources disponibles.

4.2.1.4 Exigences relatives au système de tenue des registres

    Le système de tenue des registres doit assurer l'unification de la structure des registres et des bases de données, l'élimination des doublons et l'utilisation irrationnelle des fonds publics pour la collecte et l'accumulation d'informations similaires à différents endroits. 

    Le système de gestion des registres doit garantir l'accès des systèmes externes conformément à la politique de sécurité et à l'accord du client. Objectif principal : mise en place d'un système unique de stockage et de gestion centralisés des registres.

    Le système de gestion des registres doit assurer :

• le stockage de données structurées sous forme de tableaux relationnels utilisant le format JSON ;

• l'établissement de liens entre les registres à l'aide d'identifiants uniques pour la construction de structures de données complexes et interconnectées ;

• l'enregistrement des modifications apportées aux données et la possibilité de consulter ces modifications ;

• le stockage des données avec une signature électronique apposée ;

• garantie de l'accès aux données via l'API REST ;

• module d'indexation et de recherche d'informations en temps quasi réel ;

• recherche d'informations en texte intégral tenant compte des particularités morphologiques ;

• module de stockage de fichiers assurant un stockage distribué des fichiers et une grande évolutivité ;

• pour le stockage des fichiers, il convient d'utiliser un stockage de fichiers compatible S3 ;

• l'accès aux fichiers stockés dans le module de stockage de fichiers pour le téléchargement doit être mis en œuvre via un lien spécialement généré, qui est émis sous forme de jeton dont la validité est limitée dans le temps ;

• consolidation des données de base – consolidation et vérification centralisées des données de base provenant de différents systèmes. Identification des liens entre ces données dans différents systèmes et suppression des doublons ;

• synchronisation des données – possibilité d'échanger en permanence des données avec des systèmes externes ;

• sauvegarde, téléchargement, importation et exportation des configurations et des données des registres, y compris à l'aide du format XLSX ;

• présence d'un éditeur pour la création et la gestion des registres dans le système de gestion des registres ;

• possibilité de créer, à l'aide de l'éditeur, des champs supplémentaires pour la description d'un élément du répertoire, d'apporter des modifications aux champs existants ;

• prise en charge du mécanisme « drag and drop » pour créer et modifier la structure des registres sans avoir à écrire de code ;

• intégration avec le Cabinet électronique pour permettre le remplissage et la gestion des registres via l'interface visuelle du Cabinet électronique ;

• mise en œuvre de la sécurité au niveau des lignes (row-level security) – accès des groupes d'utilisateurs à une partie des enregistrements d'une entité distincte du registre ;

• cryptage des données enregistrées afin d'en garantir la confidentialité ;

• accès à l'information selon la règle CRUD ;

• possibilité d'utiliser directement les enregistrements des registres dans les processus métier, y compris les opérations de création, de mise à jour et de vérification des données dans le cadre du processus ;

• fourniture d'un accès via des outils visuels et des fichiers de configuration.

4.2.1.5 Exigences relatives au système de génération de messages

    Le système de génération de messages met en œuvre la fonctionnalité d'envoi d'un grand nombre d'e-mails et de SMS afin de garantir des moyens efficaces d'informer rapidement les utilisateurs.

    Le système permet d'informer les utilisateurs de l'état d'avancement du service et d'informer les clients des transactions/modifications dans le registre. Le système offre la possibilité de personnaliser les modèles de messages. Pour utiliser ce service, il faut utiliser l'API REST. Le système peut être intégré à différents services et jouer le rôle de « bus/fournisseur » pour l'envoi d'e-mails et de SMS.

    Le système d'envoi de messages doit assurer :

• l'envoi d'e-mails.

• l'envoi de SMS ;

• la diffusion massive d'e-mails et de SMS ;

• l'intégration avec les fournisseurs nationaux de services de téléphonie mobile ;

• l'intégration avec le service d'envoi de SMS ;

• possibilité de créer des modèles de messages ;

• possibilité d'envoyer un message paramétré à l'aide d'un modèle ;

• utilisation d'une file d'attente pour l'envoi de messages ;

• intégration avec d'autres systèmes via l'API REST ;

• intégration avec le système d'identification et d'authentification électroniques ;

• intégration avec le compte utilisateur électronique ;

• possibilité de configurer l'envoi de messages uniquement vers le bureau électronique de l'utilisateur ;

• journalisation de l'envoi des messages.

4.2.1.6 Exigences relatives au système de journalisation

Le système de journalisation doit assurer et permettre une recherche rapide dans les journaux de tous les modules de la Plateforme. 

    Le système de journalisation doit assurer :

1. la collecte des journaux :

   • de tous les modules de la Plateforme en temps réel ;

   • les journaux doivent inclure des informations sur les erreurs, les avertissements, les messages d'information et les informations de débogage ;

2. le traitement des journaux :

   • prendre en charge le traitement des journaux provenant de différentes sources et formats ;

   • assurer le filtrage et la normalisation des journaux avant leur stockage ;

3. stockage des journaux :

   • stockage dans Elasticsearch pour permettre une recherche et une analyse rapides ;

   • prendre en charge la mise à l'échelle horizontale pour le stockage de grands volumes de journaux ;

4. recherche dans les journaux :

   • recherche rapide et efficace dans les journaux selon différents critères (heure, module, niveau de journalisation, message, etc.) ;

   • prise en charge des requêtes de recherche complexes et du filtrage ;

5. visualisation des journaux :

   • l'interface web pour la visualisation des journaux doit être intégrée au système de journalisation ;

   • prise en charge de la création de tableaux de bord pour la surveillance et l'analyse des journaux en temps réel ;

6. sécurité et contrôle d'accès :

   • protection contre les accès non autorisés ;

   • contrôle d'accès basé sur les rôles (RBAC) pour les différents utilisateurs  de la plateforme ;

7. archivage et stockage :

   • prise en charge des politiques de stockage et d'archivage des journaux pour le stockage à long terme ;

   • archivage automatique des journaux après une période donnée.

Le système doit être hautement disponible et résilient. Le système doit assurer la surveillance de ses performances et de l'utilisation des ressources.

Toutes les modifications de la configuration du système de journalisation doivent être consignées.

4.3 Exigences relatives aux fonctions exécutées par le système

5 Exigences non fonctionnelles

5.1 Exigences relatives à l'interaction avec les systèmes adjacents

Dans le cadre de son développement, la plateforme doit assurer l'intégration avec le SIE.

Afin de permettre la configuration de l'interaction électronique avec le SIE, il est nécessaire de prévoir :

• la présence de mécanismes d'échange d'informations/de données entre la Plateforme et le SIE ;

• la mise à disposition par la Plateforme, à l'intention du SIS, de certaines fonctions de traitement, de stockage et de visualisation des informations pour l'utilisateur, dans les limites des capacités déclarées de la Plateforme ;

• l'existence d'un contrôle de la qualité du fonctionnement du SIR et de l'échange de données.

Les mécanismes de configuration de l'interaction électronique avec le SIR doivent correspondre au niveau actuel de développement des technologies de l'information.

Dans le cadre de l'interaction électronique des composants de la Plateforme, il doit être possible d'utiliser un outil unifié de collecte et d'analyse des journaux et des métriques pour l'analyse en ligne de la performance des composants. Dans le cadre de l'échange de données, un agent de collecte des journaux doit être mis en place pour assurer la collecte des journaux. Un agent de collecte des métriques doit également être mis en place :

• charge des processeurs ;

• charge de la mémoire opérationnelle ;

• charge des disques physiques ;

• charge des interfaces réseau.

La plateforme doit permettre l'interaction, en particulier l'échange d'informations, avec les systèmes d'autres organisations (tableau 4.1).

Tableau 4.1 ⎼ Interaction de la plateforme avec d'autres systèmes

La plateforme peut interagir avec d'autres systèmes via leurs services d'interaction existants (API).

Il convient d'utiliser des formats modernes d'échange d'informations entre le client et le serveur basés sur le protocole HTTPS (XML, JSON). L'interaction entre le serveur d'applications et le client utilisateur doit s'effectuer via le protocole HTTPS.

5.2 Exigences relatives aux modes de fonctionnement du système

La Plateforme doit fonctionner en continu (24/7), à l’exception des périodes d’interruption dues aux travaux de maintenance planifiés ou aux arrêts d’urgence.

L’interruption temporaire du fonctionnement pour la maintenance est autorisée uniquement en dehors des heures ouvrables (sauf en cas d’urgence).

• le mode principal, dans lequel toutes les fonctions essentielles de la Plateforme sont exécutées ;

• le mode de maintenance, dans lequel la Plateforme n’exécute pas ses fonctions.

En mode de fonctionnement principal, la Plateforme doit assurer : 

• le travail des utilisateurs : le logiciel client et les moyens techniques permettent un fonctionnement 24 heures sur 24, 7 jours sur 7 (24x7) ; 

• l'exécution de ses fonctions.

Pour assurer le mode de fonctionnement principal, la Plateforme doit : 

• le logiciel serveur et les moyens techniques des serveurs doivent assurer un fonctionnement 24 heures sur 24, avec des interruptions pour la maintenance ; 

• le bon fonctionnement des logiciels système, de base et d'application du système ; 

• respecter les exigences et les conditions d'utilisation des logiciels et des moyens techniques du système, telles que spécifiées dans les documents correspondants (documentation technique, manuels d'utilisation, etc.). 

La plateforme doit assurer l'entrée/sortie de données, la réception de commandes et l'affichage des résultats de leur exécution en mode interactif. 

En mode de maintenance, le système doit permettre l’exécution des travaux suivants :

• la maintenance technique ;

• la modernisation du complexe matériel et logiciel.

5.3 Exigences relatives au nombre et à la qualification du personnel du système

La liste et le nombre de catégories spécifiques d’utilisateurs de la Plateforme et d’unités de personnel permanent, leur effectif, leurs qualifications et leurs fonctions, leur mode de fonctionnement et leur mode d’interaction doivent être définis par les documents réglementaires appropriés (règlements, instructions, etc.) et peuvent être précisés au cours de l’exploitation.

Les utilisateurs doivent disposer des informations relatives à la Plateforme dans le cadre de la documentation d’exploitation.

Le personnel chargé de l’exploitation de la Plateforme doit posséder les compétences nécessaires pour travailler avec les équipements informatiques et avec les logiciels généraux.

5.4 Exigences relatives aux indicateurs de destination

Les indicateurs de destination suivants sont sélectionnés :

1. la capacité de la Plateforme à assurer la réalisation de sa mission (voir section 2 : Mission et objectifs de la création du système) ;

2. l’exhaustivité fonctionnelle de la liste des fonctions mises en œuvre (voir section 4.3).

En outre, la Plateforme doit garantir les indicateurs quantitatifs suivants :

1. travail simultané des utilisateurs :

   • prise en charge du travail simultané de jusqu’à 5 000 utilisateurs sans perte de productivité ;

   • temps moyen de réponse ≤ 2 secondes, taux d’erreurs ≤ 1 % ;

   • en cas de dépassement du niveau de charge admissible → statut HTTP 429. (Too Many Requests) ;

2. soumission de demandes et traitement des documents :

   • traitement correct de plus de 5 000 demandes simultanées ;

   • temps de traitement d’une demande ≤ 5 secondes sous charge standard ;

   • téléchargement stable de fichiers (jusqu’à 10 Mo) avec plus de 100 demandes simultanées ;

   • en cas de charge élevée → aucune perte de données ni blocage de transactions.

3. requêtes vers des intégrations externes (API) :

   • les appels API vers des registres externes doivent supporter plus de 50 RPS (requêtes par seconde) ;

   • toutes les réponses API doivent respecter un temps de réponse ≤ 5 secondes dans 95 % des cas ;

4. mise à l'échelle et résilience :

   • en cas de charge élevée, la plateforme doit s'adapter automatiquement (adaptation horizontale des serveurs) ;

   • en cas de panne critique, la charge doit être redistribuée vers les serveurs de secours sans perte de données ;

   • la Plateforme doit rétablir correctement son fonctionnement dans un délai ≤ 5 minutes après une charge d’urgence ;

5. journalisation et surveillance :

   • tous les événements critiques (pannes, blocages, délais d'attente) doivent être enregistrés en temps réel ;

   • les données de surveillance doivent afficher le CPU, la RAM, le temps de réponse et le RPS en temps réel.

Dans le cadre de son développement, la plateforme doit garantir la conformité aux caractéristiques suivantes :

• possibilité de stocker les journaux des opérations pendant toute la durée d'utilisation des modules de la plateforme (si les capacités matérielles le permettent) ;

• possibilité de mettre à jour n'importe quel composant du système sans interruption du service ;

• capacité de mise à l'échelle horizontale en temps réel sans interruption du service ;

• la génération HTML de toutes les pages doit se faire selon le principe MVC (Model-View-Controller) sur la partie serveur ;

• la recherche d'informations doit être effectuée à l'aide d'index de recherche prenant en charge la langue officielle du client ;

• le framework utilisé pour la partie serveur de la plateforme doit être défini par les développeurs comme LTS (Long-term-support) ;

• le logiciel serveur doit fonctionner sous des systèmes d'exploitation open source et sous licence libre, définis par les développeurs comme LTS (Long-term-support) ;

• avoir son propre dépôt de code ouvert utilisant le système de contrôle de version Git ;

• les bases de données relationnelles doivent prendre en charge les transactions et le traitement des schémas JSON lors des requêtes SQL ;

• les modules de la Plateforme doivent être construits selon le principe de l'architecture client-serveur en utilisant exclusivement des technologies Open Source (y compris les systèmes d'exploitation, les langages de programmation et les SGBD) qui ne nécessitent pas de licence supplémentaire ;

• pour les index de recherche qui font partie de la plateforme et qui nécessitent une interaction en temps réel à haut débit, il est recommandé d'utiliser des bases de données orientées objet (NoSQL) open source comme base de données ;

• l'authentification des utilisateurs doit se faire via le protocole OAuth 2.0, avec prise en charge de l'authentification par eID. Les outils logiciels de vérification et d'apposition de la signature électronique  doivent être certifiés conformément à la législation en matière de protection des informations ;

• le système de recherche doit être utilisé pour l'indexation et la recherche de tout type de documents/informations, en fournissant une recherche évolutive, proche du temps réel ;

• possibilité de créer des copies de sauvegarde à froid de tous les composants, en garantissant l'intégrité des données et la possibilité de déployer tous les composants du système à partir de copies à froid dans un état complet et opérationnel ;

• la disponibilité de la plateforme doit être garantie à au moins 99,9 %, sans tenir compte des temps d'arrêt planifiés et de l'indisponibilité des capacités serveur principales et de secours et des moyens de communication. L'indisponibilité de la plateforme en mode de maintenance (0,1 %) ne doit pas dépasser 45 minutes par mois;

• la résilience de la solution doit être assurée automatiquement. La solution projetée doit garantir :

  • le bon fonctionnement de la Plateforme en cas de défaillance ou de panne de l'un des composants logiciels ou matériels ;

  • la conservation des informations au moment de la défaillance ou de la panne d'un des composants, quelle que soit sa fonction, avec une restauration ultérieure après les travaux de réparation et de remise en état ;

• Les données saisies par l'utilisateur doivent être stockées dans le cache du navigateur, y compris les données des formulaires et des champs remplis par l'utilisateur.

5.5 Exigences relatives à la fiabilité

L'architecture de la plateforme doit garantir une infrastructure résiliente basée sur un cluster Kubernetes, évolutive avec une topologie à plusieurs nœuds maîtres, avec un cluster etcd externe. Un stockage en cluster distribué doit être déployé sur tous les nœuds de travail. L'équilibrage de charge entre les nœuds maîtres doit être assuré. Cette configuration doit garantir le maintien du fonctionnement du cluster en cas de défaillance d'un ou plusieurs nœuds maîtres.

La fiabilité du fonctionnement de la Plateforme, ainsi que le maintien de son fonctionnement et de ses données, doivent être assurés par :

• la réalisation en temps opportun des travaux de maintenance technique pendant toute la durée d'exploitation de la Plateforme ;

• la mise à jour périodique des versions du logiciel de la Plateforme ;

• la mise à jour périodique des moyens techniques de la Plateforme ;

• l'archivage et la sauvegarde systématique des données ;

• la surveillance de l’état actuel de la Plateforme (en temps réel) et le rétablissement de son fonctionnement conformément à la documentation d’exploitation ;

• la restauration des données à partir des copies d'archives en cas d'urgence (coupure de courant des équipements matériels, erreurs, pannes logicielles ou matérielles ou destruction des logiciels et/ou du matériel) sans compromettre l'intégrité des informations ;

• moyens de protection matérielle et logicielle contre la destruction intentionnelle (intervention matérielle et logicielle non autorisée par des tiers) et non intentionnelle des données résultant d'actions incorrectes des utilisateurs ;

• des moyens de protection matériels et logiciels contre la destruction intentionnelle (interventions non autorisées) et non intentionnelle des données (erreurs des utilisateurs) ;

• utilisation de technologies modernes de programmation et de tests de qualité ;

• la compatibilité des moyens techniques et des logiciels ;

• remplacement rapide des moyens techniques défectueux.

5.6 Exigences relatives à l’ergonomie et à l’esthétique technique

L’interaction de l’utilisateur avec la Plateforme doit être basée sur une interface graphique claire et intuitive, utilisant des icônes pour les fonctions, les modes et les opérations.

L'interface de la Plateforme doit être conçue selon les principes SPA sous forme de services et être une partie accessible de la Plateforme, permettant aux utilisateurs d'obtenir des services/de soumettre des documents/etc.

L'interaction des utilisateurs avec le logiciel doit s'effectuer à l'aide d'une interface graphique visuelle (GUI). 

La conception graphique de la Plateforme doit être réalisée sur la base d’un design approuvé par le Client.

La plateforme doit répondre aux exigences fondamentales suivantes :

• une interface utilisateur localisée doit être fournie (dans la langue officielle du client), à l’exception des messages système qui ne peuvent pas être traduits ;

• les interfaces doivent permettre la pagination des données affichées ;

• des info-bulles interactives doivent s'afficher lorsque le curseur est placé sur certains éléments de la page ;

• un message d'avertissement doit s'afficher avant l'exécution d'actions critiques ;

• lors de la saisie d'informations, la validité des données doit être vérifiée à l'aide de masques de saisie (nombre de caractères, absence de caractères incorrects, espaces superflus, etc.) et de conditions logiques ;

• des éléments de commande simples et compréhensibles, ne nécessitant aucune formation pour être utilisés ;

• uniformité du style visuel et des formulaires d'affichage ;

• uniformité des mécanismes de traitement des données (pour les champs de même type, pour les opérations de même type, etc.) ;

• utilisation minimale d'images graphiques afin d'accélérer leur chargement ;

• pour les opérations qui nécessitent une attente, un message indiquant la progression du processus doit être affiché.

• navigation claire sur toutes les ressources de la Plateforme accessibles aux utilisateurs ;

• nombre minimal d'actions pour résoudre les tâches principales du public cible ;

• quantité minimale d'informations que l'utilisateur doit saisir pour résoudre la tâche ;

• absence de fonctions inutiles pour résoudre les tâches principales ;

• lors de la conception de la plateforme, la possibilité de traduire l'interface dans une autre langue doit être prévue ;

• les fonctionnalités de l'interface web doivent répondre aux exigences actuelles (l'interface doit avoir un aspect familier pour l'utilisateur, un ensemble de commandes, etc.) ; 

• les couleurs de l'interface doivent être choisies dans un style unique et concis ;

• les messages d'erreur ou d'actions incorrectes doivent être accompagnés d'une suggestion sur les actions à entreprendre ; 

• les éléments de l'interface (boutons et liens) doivent avoir des noms qui permettent à l'utilisateur d'interpréter sans ambiguïté les actions qu'ils effectuent ;

• les formulaires de saisie d'informations doivent comporter des indications sur les champs obligatoires et le format à respecter pour les remplir

Dans le cadre du dialogue avec l'utilisateur : 

• possibilité de contrôler le déplacement dans les formulaires de l'interface à l'aide de la souris ou du clavier ; 

• il faut assurer le traitement correct des situations causées par des actions incorrectes des utilisateurs, un format incorrect ou des valeurs inadmissibles dans les données d'entrée. Dans ces cas, la Plateforme doit afficher les messages correspondants à l'utilisateur ;

• conformément aux recommandations internationales, l'interface doit être adaptée à l'utilisation par les personnes malvoyantes (accessibilité numérique)..

Les styles, polices et couleurs de la Plateforme doivent utiliser les feuilles de style en cascade (CSS) modernes actuellement utilisées pour la création de portails web modernes. 

L'interface doit être conforme au code de conception officiel défini pour les autorités exécutives :

• la largeur maximale d'une page web est de 1680 pixels. Si la résolution de l'appareil est supérieure, des champs sont ajoutés à la page web

• la taille minimale de l'écran d'un appareil mobile est de 320 pixels ;

• utilisation d'une grille adaptative à 12 colonnes ;

• les couleurs de l'interface doivent être contrastées et utilisées en combinaison avec la forme et le texte. La couleur ne doit pas être le seul moyen visuel de transmettre des informations indiquant une action ou distinguant un élément parmi d'autres ;

• longueur de la ligne de texte du contenu principal : pas plus de 800 pixels, alignement du texte sur le bord gauche de la page ;

• la page ne doit comporter qu'un seul titre de niveau h1 ;

• le nombre de niveaux de titres est limité à quatre : de h1 à h4 ;

• l'interligne du titre doit être 1,5 fois supérieur à la taille de la police ;

• les titres ne doivent pas se terminer par un point ;

• le texte doit avoir un coefficient de contraste d'au moins 4,5 : 1 par rapport à l'arrière-plan ;

• la police du texte principal doit être d'au moins 16 pixels ;

• le formatage de l'adresse e-mail doit se faire sous la forme d'un lien de type « mailto » ;

• le numéro de téléphone doit être formaté sous forme de lien de type « tel » ;

• le jour et le mois doivent être indiqués par deux paires de chiffres séparées par un point, l'année par quatre chiffres ;

• le point à la fin de la date n'est pas mis ;

• si le jour du mois ou le mois ne comporte qu'un seul chiffre, il faut le faire précéder d'un zéro ;

• les espaces entre les éléments de la liste doivent être 1,2 fois plus grands que la taille de la police.

S'il y a un menu latéral, il est situé dans la partie gauche de la page et peut contenir des sous-menus. 

Le menu latéral peut être composé des éléments suivants :

• titre du menu ;

• les éléments du menu, qui sont des liens vers les options correspondantes.

5.7 Exigences relatives à la cybersécurité

En cas d'interaction de la Plateforme avec d'autres systèmes d'information et de communication, les exigences en matière de protection des informations dans les systèmes doivent être coordonnées et approuvées dans les protocoles d'interaction correspondants. 

La Plateforme doit être conforme aux exigences de la législation en vigueur en matière de protection des informations.

La protection des informations contenues dans la Plateforme contre tout accès non autorisé est assurée à l'aide de mécanismes et de moyens de protection des informations, notamment par :

• l'identification et l'authentification des utilisateurs ;

• a différenciation des rôles et des privilèges des utilisateurs ;

• la gestion des droits d'accès des utilisateurs aux données ;

• la différenciation de l'accès des utilisateurs aux objets d'information ;

• configuration de l'interface utilisateur de manière à ce qu'elle ne contienne que les objets et les fonctions mis à la disposition de l'utilisateur ;

• tenue d'un journal dans lequel sont enregistrées les actions individuelles des utilisateurs.

La plateforme doit obligatoirement enregistrer : 

• les résultats de l'identification et de l'authentification des utilisateurs ; 

• les résultats des opérations de traitement de l'information effectuées par l'utilisateur ;

• les faits relatifs à l'attribution, à la modification et au retrait des droits d'accès des utilisateurs aux informations et à leur traitement.

La Plateforme doit contrôler l'intégrité des logiciels utilisés pour le traitement de l'information, empêcher toute modification non autorisée de ceux-ci et éliminer les conséquences d'une telle modification.

La mise en œuvre de mesures de protection des informations sur la Plateforme ne doit pas nuire de manière significative à ses caractéristiques essentielles en termes de performances, de fiabilité, de compatibilité, de gérabilité, d'évolutivité, de scalabilité, etc.

Afin d'assurer la protection des informations à toutes les étapes du cycle de vie de la Plateforme, les mesures et moyens de protection des informations suivants doivent être appliqués :

• mesures organisationnelles mises en œuvre en dehors du système informatique de la Plateforme ;

• mesures techniques et d'ingénierie mises en œuvre en dehors du système informatique de la Plateforme ;

• des moyens matériels, logiciels et matériels/logiciels combinés ;

• protection des informations contre tout accès non autorisé et protection antivirus ;

• protection cryptographique des informations (mise en œuvre dans le réseau de transmission de données via un environnement non sécurisé).

Afin de protéger les informations, la Plateforme doit garantir :

1. l'échange de données doit s'effectuer via des canaux de communication sécurisés, à l'aide du protocole HTTPS ;

2. une identification et une authentification fiables des utilisateurs de la Plateforme, l'octroi d'un accès aux objets protégés en fonction des rôles fonctionnels des utilisateurs ;

3. au niveau du code logiciel, une protection contre les injections SQL, les vulnérabilités XSS et les attaques CSRF doit être mise en œuvre ;

4. lors du remplissage et de l'interaction avec les formulaires ouverts sur le site web de la Plateforme qui effectuent le transfert de données, l’utilisation obligatoire de Google reCaptcha doit ;

5. une demande automatique de réautorisation de l'utilisateur après une période déterminée d'inactivité (session) de l'utilisateur dans la session de travail avec le système ;

6. limitation des actions non autorisées concernant l'accès à des informations confidentielles ou à des ressources logicielles et matérielles ;

7. protection de l'intégrité et de la disponibilité des informations ;

8. sauvegarde et possibilité de restauration des informations.

La plateforme doit être conforme à la version actuelle de la liste des vulnérabilités les plus critiques de l’OWASP Top 10, en vigueur au moment de la réalisation des travaux.

5.7.1 Exigences relatives à la rédaction du rapport sur les tests de sécurité de la Plateforme

Une fois les tests effectués, une analyse manuelle des vulnérabilités détectées est réalisée afin de réduire les faux positifs générés par les scanners automatiques. Après cette analyse, le prestataire prépare un rapport de test contenant les éléments suivants :

• Introduction. Cette section donne un aperçu du test de sécurité, en précise les objectifs et la portée, et explique l'importance du rapport de test pour assurer la sécurité du système ;

• Objet du test. L'objet du test de sécurité est défini, par exemple une application web, une application mobile ou une infrastructure réseau. Les principales caractéristiques du système testé sont décrites et les outils et méthodes utilisés sont indiqués ;

• Méthodologie de test. Cette section décrit les méthodes et approches utilisées pour les tests de sécurité. Elle indique les différents types de tests, tels que le scan de ports, l'interception de paquets, les tests d'intrusion, l'ingénierie sociale, etc. ;

• Vulnérabilités détectées. Cette section contient une liste de toutes les vulnérabilités détectées lors des tests. Chaque vulnérabilité est décrite en détail, en indiquant son type, son impact sur la sécurité du système, ses modes d'exploitation et les mesures correctives recommandées ;

• Classification des vulnérabilités. Les vulnérabilités peuvent être classées par catégories, telles que les vulnérabilités d'accès, l'authentification insuffisante, le contrôle d'accès insuffisant, l'interception de données, etc. Cette section aide à établir les priorités en matière de correction des vulnérabilités ;

• Recommandations de correction. Les mesures spécifiques à prendre pour corriger chaque vulnérabilité sont indiquées. Les mesures recommandées peuvent inclure des correctifs, des mises à jour logicielles, des modifications de configuration, un renforcement du contrôle d'accès, la formation du personnel, etc. ;

• Conclusions. Cette section présente les conclusions générales et le résumé des tests de sécurité. Elle met en évidence les principaux problèmes détectés au cours des tests et fournit des recommandations sur les mesures à prendre pour améliorer la sécurité ;

• Annexes. Si nécessaire, des documents supplémentaires peuvent être joints au rapport, tels que des captures d'écran, des journaux de test, des scripts, ou la liste des outils utilisés.

Si des vulnérabilités ont été détectées, des tâches sont créées pour les développeurs du prestataire sur la base du rapport de test de sécurité, afin qu’ils corrigent les vulnérabilités décrites.

5.8 Exigences relatives à la conservation des informations en cas d'urgence

La conservation des informations sur la Plateforme doit être assurée en cas d'accidents ou de défaillances de toute nature. Il doit être possible de rétablir intégralement le fonctionnement de la Plateforme et de restaurer les informations contenues dans les bases de données dans un délai de 12 heures à compter de la panne. Pour ce faire, il est nécessaire d'effectuer des sauvegardes des logiciels et des informations contenues dans les bases de données conformément à la politique de sauvegarde établie.

La sauvegarde doit s'effectuer selon deux modes :

• manuel – lancé par l'administrateur de la sécurité ;

• programmé – exécution automatique de la sauvegarde.

5.9 Exigences relatives à la protection contre les facteurs externes

Aucune exigence spécifique en matière de protection contre les facteurs externes n'est imposée.

5.10 Exigences relatives à la pureté brevet

La Plateforme ne doit inclure que des éléments logiciels ou matériels dont l'utilisation n'est soumise à aucune restriction juridique dans le pays du client (y compris l’open source).

L'appartenance des droits patrimoniaux et non patrimoniaux sur la Plateforme et ses composants est déterminée par des documents contractuels.

Au cours du développement de la plateforme, il convient d'utiliser :

1. des produits open source qui ont :

• un historique de développement suffisant ;

• une communauté active et développée ;

• un nombre significatif de mises en œuvre réussies au niveau industriel ;

• des mises à jour régulières ;

2. langages de programmation, selon l'analyse : 

• le potentiel de développement futur ;

• la complexité du codage et de la documentation ;

• la disponibilité d’un nombre suffisant de frameworks et de bibliothèques (principalement open source) ;

• le coût moyen d’une heure de travail d’un développeur ;

• la capacité et la maturité du marché national.

5.11 Exigences relatives à la normalisation et à l’unification

L'échange d'informations sur la plateforme doit être effectué à l'aide des protocoles et algorithmes d'échange prévus dans les normes et recommandations nationales et internationales.

La plateforme doit être basée sur des technologies industrielles courantes d'entrée, de stockage, de traitement, d'analyse et d'accès aux données.

Lors de la création de la plateforme, les exigences suivantes doivent être respectées :

• les décisions techniques (formats et protocoles de transmission des données, etc.) et organisationnelles (règlements, exigences, instructions, etc.) doivent être documentées ;

• les formulaires d'interface utilisateur à l'écran doivent être conçus en tenant compte des exigences d'unification ;

• lors de la conception du support informatique, il convient d'utiliser les normes internationales, nationales, sectorielles ou ministérielles (documents normatifs, classificateurs, dictionnaires) en vigueur et approuvées (recommandées) ;

• l'interaction entre les utilisateurs doit être basée sur des protocoles logiques unifiés d'échange de données (protocoles communs) ;

• l'interaction avec les systèmes externes doit être assurée à l'aide d'API.

5.12 Exigences relatives à la surveillance

Lors de la création de la Plateforme, un système de surveillance unique doit être mis en place, ainsi qu'un processus d'astreinte. Le système de surveillance doit être standardisé pour le suivi de toutes les ressources du cluster, et facilement extensible afin de permettre l’ajout de toute métrique métier permettant de détecter un problème avant qu’il n’affecte les processus opérationnels.

Pour la surveillance, il convient d'utiliser un système de surveillance développé pour la plateforme ou des mécanismes de surveillance fournis par une partie externe. Le système de surveillance doit utiliser un logiciel open source.

Le système de surveillance doit assurer l'autodiagnostic, la journalisation et l'enregistrement dans le journal des événements liés au fonctionnement de la Plateforme.

En cas d'urgence ou d'erreurs dans le fonctionnement de la Plateforme, les outils d'autodiagnostic doivent conserver un ensemble suffisant d'informations nécessaires à l'identification du problème.

L'autodiagnostic et le traitement des informations diagnostiques doivent être effectués pour chaque composant de la Plateforme, son processus métier et ses opérations. Chaque transaction doit avoir sa propre numérotation unique. En cas de traitement incorrect, le système de surveillance doit enregistrer l'erreur avec le numéro de transaction dans le journal des événements.

Un mécanisme de notification des administrateurs de la Plateforme doit être mis en place. Une procédure d'escalade des notifications à la direction de l'unité structurelle doit également être élaborée, conformément au processus établi pour les événements d'autodiagnostic en cas d'erreurs critiques ou de défaillance des composants de la Plateforme.

Les notifications doivent être divisées en :

• Avertissements informatifs relatifs aux situations limites :

  • avertissements de dépassement du temps de réponse spécifié des composants de la Plateforme ;

  • avertissements concernant l'approche des valeurs limites des paramètres de fonctionnement de la Plateforme ;

  • avertissements concernant l'atteinte de la capacité limite du canal ;

  • alertes concernant les erreurs critiques et les erreurs bloquant le fonctionnement.

• Avertissements relatifs aux situations critiques :

  • alerte en cas de défaillance des composants de la Plateforme ;

  • alerte en cas d'atteinte de la valeur limite des paramètres de fonctionnement de la Plateforme en raison d'un traitement en attente.

La Plateforme doit permettre d'envoyer des messages :

• par courrier électronique ;

• par SMS (le coût de l'envoi des SMS est supporté par le Client, conformément aux tarifs du fournisseur).

5.12.1 Exigences relatives à la collecte des journaux

La Plateforme doit assurer la collecte des types de journaux suivants : 

1. Journaux des services :

• Systèmes d'identification et d'authentification électroniques ;

• Compte utilisateur électronique ;

• Systèmes de gestion des processus métier (notation BPMN) ;

• signatures des demandes ;

• examen des demandes soumises ;

• modification des registres ;

• changement du statut des demandes ;

• transfert et réception de données vers/depuis des systèmes externes ;

• Systèmes de tenue des registres ;

• Systèmes de génération de messages, entre autres.

2. Journaux système :

• Système d'exploitation ;

• NGINX ;

• Kubernetes ;

3. Métriques (à définir lors de la phase d'élaboration du cahier des charges techniques)

4. Journaux de sécurité :

• Autorisations sur la plateforme ;

• Autorisations sur le serveur.

5. Surveillance :

• État de fonctionnement des services de la plateforme ;

• État de fonctionnement des intégrations externes ;

La plateforme doit disposer d'une interface conviviale permettant de trouver rapidement et facilement les journaux nécessaires.

Toutes les opérations sur les enregistrements (création, modification, suppression) doivent être consignées avec la date et l'heure, l'utilisateur qui a effectué l'action et le type d'opération afin de garantir un audit complet des actions sur la Plateforme.

Le lieu d'enregistrement des journaux, les métriques et leurs détails doivent être consignés dans la documentation technique conformément au contrat. Pour chaque type de journal ou de métrique, des règles de nettoyage et d'archivage doivent être définies, précisant l’exécution par l’administrateur système des scripts de maintenance configurés.

5.12.2 Exigences relatives au système d'archivage des données et des journaux

La plateforme doit disposer d'outils de nettoyage et/ou d'archivage de certaines entités. Les détails correspondants doivent être indiqués dans la documentation technique.

L'archivage et le nettoyage doivent être prévus au moins pour :

• les données des registres ;

• les données des répertoires ;

• les données relatives aux processus métier ;

• les brouillons de processus créés par les utilisateurs ;

• les fichiers stockés dans le référentiel de fichiers (générés, provenant de sources externes, ajoutés par les utilisateurs en tant que pièces jointes) ;

• les données relatives aux utilisateurs ;

• les messages destinés aux utilisateurs ;

• les journaux ;

• les métriques.

Pour chaque entité, déterminer la possibilité et les règles de nettoyage ou d'archivage. L’exécution de ces scripts doit être décrite dans la documentation technique.

Le format attendu est un tableau indiquant pour chaque entité : la description des règles de détermination, le type d’action (nettoyage ou archivage), la fréquence et les scripts à exécuter (SQL).

L’exécutant doit configurer et/ou fournir les scripts de nettoyage et d’archivage.

5.13 Exigences relatives au système de collecte de statistiques

L'analyse des visites du site web de la Plateforme doit être effectuée à l'aide d'un système de collecte de statistiques. Le système de collecte de statistiques doit utiliser l'outil Google Analytics. Il est nécessaire de moderniser le système de collecte des données statistiques, qui suit les informations relatives au contenu et à la dynamique de mise à jour des données publiées sur le site web de la Plateforme.

L'accès au système de collecte d'informations statistiques doit être fourni en temps réel.

Le système de collecte de statistiques doit fonctionner en continu (24 heures sur 24, 7 jours sur 7) et disposer d'une interface utilisateur permettant de sélectionner la période et d'autres paramètres.

Dans l'ensemble, le système de collecte de statistiques doit collecter les informations statistiques suivantes sur les visiteurs du site web :

• nombre de visiteurs uniques ;

• nombre de visiteurs récurrents ;

• les régions (pays) d'où proviennent les visites sur le site web de la Plateforme ;

• appareils et systèmes d'exploitation utilisés par les visiteurs ;

• durée de la visite sur le site web ;

• temps passé sur chaque page du site web ;

• fréquentation des pages ;

• les ressources Internet à partir desquelles la transition vers le site Web a eu lieu ;

• les expressions de recherche qui ont conduit à la visite du site web ;

• à partir de quels moteurs de recherche la transition vers le site web a eu lieu.

5.14 Exigences relatives aux types de sécurité 

5.14.1 Exigences relatives au support mathématique

Aucune exigence spécifique n'est imposée en matière de support mathématique.

5.14.2 Exigences relatives au support informationnel

Les données de la Plateforme doivent être structurées. La structure des données doit définir les règles de stockage des informations afin de permettre leur identification précise dans la Plateforme. 

La Plateforme doit appliquer les principes suivants : intégrité, fiabilité, contrôle, protection contre les accès non autorisés, unité et flexibilité, standardisation et unification, adaptabilité, minimisation des erreurs d'entrée-sortie d'informations.

L'organisation des données de la plateforme doit garantir : l'unité et le stockage des informations nécessaires à la résolution des tâches ; l'unité des bases de données pour toutes les tâches des systèmes d'information ; la saisie unique des informations et leur utilisation polyvalente ; différentes méthodes d'accès aux données ; un faible coût de stockage et d'utilisation des données, ainsi que de modification.

Le traitement des informations sur la plateforme doit être effectué à l'aide d'une technologie sécurisée et inclure des mesures organisationnelles et des moyens techniques et logiciels de protection garantissant le respect des exigences générales en matière de protection des informations et du règlement général sur la protection des données (RGPD / GDPR).

Le modèle logique des données de la Plateforme doit assurer le stockage structuré des informations nécessaires à la résolution complète des tâches définies par les utilisateurs.

Les informations qui doivent être stockées sur la plateforme peuvent être divisées en plusieurs catégories :

• informations de référence ;

• données d'enregistrement ;

• informations technologiques.

Informations de référence et données d'enregistrement. La composante de référence du modèle de données doit assurer l'unification et la réduction des volumes de données stockées par la typisation et le codage des informations de même type qui sont fréquemment utilisées. De plus, tous les formulaires de saisie d'informations dans les comptes de la Plateforme doivent comporter un choix d'informations provenant du référentiel correspondant.

La liste des référentiels est établie lors de la conception et de la phase d'élaboration du cahier des charges. 

Données d'enregistrement. La plateforme doit stocker les données d'enregistrement des documents créés ainsi que les données relatives à la signature électronique apposée sur ceux-ci.

Informations technologiques. La plateforme doit stocker les informations technologiques liées à son fonctionnement (journalisation des actions des utilisateurs de la plateforme, des administrateurs, modifications apportées aux données d'enregistrement de la plateforme, durée d'accès, journaux d'enregistrement des événements de la plateforme, etc.).

Afin d'empêcher toute altération des données de la Plateforme (y compris les informations technologiques) par l'administrateur de la Plateforme, quel que soit son niveau d'autorisation, le logiciel doit appliquer un contrôle supplémentaire de l'intégrité des données selon la technologie suivante :

1. Calcul des hachages à partir des enregistrements du registre. Pour chaque enregistrement ajouté, modifié ou supprimé sur la Plateforme, y compris les informations technologiques, le hachage de cet enregistrement est calculé. La fonction de hachage prend les données de l'enregistrement, la date, l'heure, l'auteur et le type d'opération comme entrée et génère un code de hachage fixe, unique pour ces données.

2. Création d'un arbre de hachage (Merkle Tree). L'arbre de hachage est une structure de données composée de hachages qui sont combinés selon certaines règles. Dans ce cas, un arbre de hachage est créé pour calculer le hachage, qui est calculé sur la base de toutes les opérations effectuées dans le registre au cours d'une journée (hachage quotidien). L'arbre de hachage garantit que toute modification apportée à une entrée quelconque faussera les hachages de toute la hiérarchie, ce qui permet de détecter les modifications illégales.

3. Publication du hachage quotidien sur le portail web public , qui fait l'objet d'une automatisation . Chaque jour, à la fin de la journée, le hachage calculé pour la journée est publié sur le portail web public, qui fait l'objet d'une automatisation, dans la section technologique correspondante. Cela permet d'assurer la transparence et l'invariabilité du hachage, car il devient accessible à l'examen et à la vérification par les parties intéressées, y compris les auditeurs externes.

5.14.3 Exigences relatives au support linguistique 

L'interface utilisateur de la Plateforme doit être disponible dans la langue officielle du client. 

Les informations réglementaires et de référence, les classificateurs et les référentiels doivent être rédigés dans la langue officielle du client, et dans certains cas en anglais.

L'utilisation de l'anglais est autorisée uniquement dans le cadre des procédures réglementaires et techniques.

5.14.4 Exigences relatives aux logiciels

Le logiciel (SW) comprend :

• le logiciel système général (LSG) ;

• le logiciel applicatif (LA).

Le logiciel système comprend :

• les systèmes d'exploitation ;

• les systèmes de gestion de bases de données (SGBD) ;

• les logiciels bureautiques, etc.

Les serveurs d'applications (à l'exception, éventuellement, de la base de données principale) doivent fonctionner dans un environnement conteneurisé :

• Docker ou des solutions compatibles

• Kubernetes.

    La plateforme doit être compatible avec les accélérateurs Web et les proxys inversés populaires (tels que Nginx).

Tous les services de la plateforme (serveurs d'applications, base de données, équilibreurs de charge, bases de données clé-valeur, services de cache, etc.) doivent répondre aux exigences suivantes :

• haute disponibilité (HA) ;

• tolérance aux pannes ;

• redondance ;

• scalabilité – possibilité de mise à l'échelle verticale et horizontale.

L'infrastructure et l'automatisation doivent utiliser : 

• helm charts et/ou playbooks Ansible ;

• des politiques et procédures SDLC avec utilisation obligatoire d'un système de contrôle des versions, des pratiques d'intégration continue et de livraison continue, qui doivent inclure une vérification automatique du bon fonctionnement et la garantie de mises à jour sans interruption du service.

5.14.5 Exigences relatives à l'infrastructure et aux services de la plateforme

1. Environnement d'exécution

• Les serveurs d'applications (à l'exception, éventuellement, de la base de données principale) doivent fonctionner dans un environnement conteneurisé

• Docker ou des solutions compatibles

• Kubernetes.

2. Compatibilité

• La plateforme doit être compatible avec les accélérateurs web et les proxys inversés populaires, tels que Nginx.

3. Exigences générales pour les services de la plateforme
   Tous les services (serveurs d'applications, bases de données, équilibreurs de charge, bases de données clé-valeur, services de cache, etc.) doivent répondre aux exigences suivantes :

• Haute disponibilité (HA) ;

• tolérance aux pannes ;

• redondance ;

• scalabilité – possibilité de mise à l'échelle verticale et horizontale.

4. Infrastructure et automatisation

• Utilisation des graphiques Helm et/ou des playbooks Ansible.

• Respect des politiques et procédures SDLC, y compris :

• système de contrôle des versions ;

• pratiques d'intégration continue (CI) et de livraison continue (CD) ;

• vérification automatique du bon fonctionnement des services ;

• mises à jour sans interruption des services (zero-downtime updates).

Les services liés au déploiement sont à la charge du Prestataire. 

La création de la Plateforme doit inclure la création d'un système CI/CD basé sur l'approche GitOps pour la mise à jour continue du code avec la possibilité de revenir à la version précédente. Toutes les étapes du déploiement doivent se trouver dans le pipeline et toutes les mises à jour du code doivent se faire automatiquement, en suivant le processus GitFlow, à l'aide d'un outil offrant une interface conviviale pour suivre toutes les versions et la possibilité de revenir à l'état précédent des composants de la Plateforme.

La mise en œuvre de DevSecOps lors de la création de la plateforme doit fournir un mécanisme permettant d'ajouter au processus de déploiement une vérification supplémentaire de la sécurité des images Docker, afin de vérifier la sécurité de l'environnement dans lequel le déploiement a lieu. Si des vulnérabilités sont détectées, le déploiement doit être arrêté.

Exigences relatives aux logiciels SGBD et à la gestion des entrepôts de données :

• il convient d'utiliser des SGBD ayant une échelle industrielle de mise en œuvre et de support ;

• le SGBD doit inclure un module de sauvegarde et de sauvegarde avec la possibilité de démarrage automatique et de transfert des données vers le serveur de sauvegarde ;

• les bases de données relationnelles doivent être gratuites et open source, avec prise en charge des transactions et traitement des schémas JSON lors des requêtes SQL ;

• une protection contre les injections SQL et d’autres types d’attaques visant à perturber le fonctionnement continu du site web doit être mise en œuvre au niveau de la Plateforme logicielle.

Sur le plan technologique, l'architecture de la plateforme doit correspondre à une solution à trois niveaux : SGBD/BD, serveur d'applications, client léger pour les modules de la plateforme, ensemble d'API pour l'interaction avec le SIE.

La partie client de la plateforme doit être construite sur des technologies web standard qui ne nécessitent pas l'installation de composants supplémentaires sur l'ordinateur (l'utilisation de Flash ou d'applets Java n'est pas autorisée). Les pages de l'interface sont générées par le serveur selon la norme HTML5, la mise en page est réalisée à l'aide de feuilles de style CSS3, et l'interactivité des pages est assurée par des scripts Javascript et des requêtes asynchrones.

La partie client de la plateforme doit être prise en charge par les navigateurs Internet modernes, notamment Chrome, Safari et Microsoft Edge. Les navigateurs mobiles (smartphones, tablettes) doivent également être pris en charge.

Prise en charge de REST, SOAP/XML-RPC sur n'importe quel protocole de niveau applicatif, SMTP, FTP, HTTP, HTTPS, Web Services.

L'ensemble des systèmes doit avoir une architecture microservice, répartie sur des serveurs virtuels/physiques distincts, et interagir entre eux via l'API REST.

Les spécifications du logiciel, des technologies et des langages de programmation qui seront utilisés par le Prestataire pour fournir les services conformément à l'objet de l'achat sont indiquées à l'Annexe A). 

5.14.6 Exigences relatives à l’équipement technique 

La plateforme doit utiliser les éléments de l'infrastructure informatique générale du Client. 

Les solutions logicielles et techniques doivent garantir le fonctionnement des utilisateurs physiquement situés dans des divisions géographiquement dispersées et permettre aux utilisateurs distants d'interagir avec la Plateforme.

Les données peuvent être précisées au cours de l'élaboration du cahier des charges techniques et y être consignées.

5.14.7 Exigences relatives à l'équipement métrologique

Aucune exigence spécifique en matière de métrologie n'est imposée.

5.14.8 Exigences relatives à l’organisation

Afin de garantir la qualité des services fournis par les parties au contrat, les mesures suivantes sont prises pendant la période de prestation des services :

• Le prestataire dispose de tous les matériaux nécessaires à la création de services électroniques ;

• le fonctionnement du complexe logiciel et technique existant est assuré.

Les données peuvent être précisées au cours de l'élaboration du cahier des charges et y être consignées.

5.14.9 Exigences relatives au support méthodologique

Aucune exigence spécifique n'est imposée en matière de soutien méthodologique.

5.15 Exigences relatives à la protection des données à caractère personnel

La Plateforme doit mettre en œuvre des mesures techniques de protection des données à caractère personnel conformément à la législation en vigueur, notamment en garantissant l'intégrité des données à caractère personnel, le contrôle des droits d’accès à ces données, la durée de conservation définie par la réglementation, ainsi que la possibilité de modifier et/ou de supprimer les données à caractère personnel.

La plateforme peut disposer de mécanismes intégrés d'anonymisation et/ou de pseudonymisation des données à caractère personnel, c'est-à-dire de méthodes de modification des données à caractère personnel visant à rendre impossible l'identification d'une personne physique à partir des données obtenues.

5.16 Exigences relatives au courtier de messages

La création de la Plateforme comprend la mise en place d'un courtier de messages.

Le courtier de messages doit être utilisé pour la communication asynchrone entre les composants de la Plateforme en temps réel et pour éviter les blocages et les pannes en cas de charge élevée sur la Plateforme.

Le courtier de messages proposé à l’utilisation doit prendre en charge une architecture distribuée, être scalable horizontalement, pouvoir créer des structures résilientes, assurer un traitement rapide des données et être largement utilisé dans la pratique internationale.

Le courtier de messages doit fournir un modèle de transmission de données « producteur–abonné (publish–subscribe) ». Il doit également prendre en charge la possibilité de regrouper les abonnés.

Le courtier de messages doit permettre le stockage temporaire des messages en vue de leur traitement ultérieur par lots.

Dans la plateforme, le courtier de messages doit mettre en œuvre les fonctionnalités suivantes du système :

• Redondance : une même fonction peut être exécutée par plusieurs serveurs ; en cas de panne ou de maintenance technique, les routes de transmission des données peuvent être modifiées de manière dynamique, le système dans son ensemble continuera à fonctionner normalement.

• Mise à l'échelle : s'il est nécessaire de connecter des serveurs supplémentaires au système pour traiter des flux de données, un grand nombre de requêtes utilisateur ou des volumes de données très importants, le logiciel de la plateforme doit permettre de le faire facilement et sans mettre l'ensemble du système hors service.

• Flexibilité et extension : si, au fil du temps, il devient nécessaire d'implémenter des fonctionnalités supplémentaires ou de modifier les fonctionnalités existantes dans la plateforme, il doit être possible de le faire à moindre coût et avec un impact minimal sur le fonctionnement global du système.

5.17 Exigences relatives à la sécurité des systèmes d’information

La création d'un système complet de protection des informations n'est pas prévue par le contrat, mais des mesures de base doivent être mises en œuvre pour assurer la protection des informations et des informations technologiques relatives à la plateforme, ainsi que pour la création ultérieure d'un système complet de protection des informations pour le complexe logiciel.

Les mesures de protection de base suivantes doivent être mises en œuvre :

• organisationnelles et administratives ;

• matérielles et logicielles ;

• techniques et d'ingénierie.

Afin de garantir le calcul de la valeur eID utilisée dans la Plateforme et de protéger certains types d’informations dans le cadre de certains processus métiers, il convient d’utiliser un outil logiciel de protection cryptographique des informations ainsi qu’un outil logiciel de transformations cryptographiques conformes aux exigences des documents normatifs du système national de protection cryptographique des informations du pays du client.

Parallèlement, les exigences suivantes en matière de sécurité de l'information sont imposées à la plateforme et seront prises en compte lors de la mise en place ultérieure d'un système complet de protection de l'information, à savoir :

• assurer l'intégrité des informations accessibles au public sur l'interface web nécessite l'utilisation de technologies garantissant un accès contrôlé et autorisé aux informations et interdisant toute modification incontrôlée et non autorisée de celles-ci, ce qui doit être résolu au niveau du système d'exploitation du serveur, du système de gestion des bases de données et du logiciel en cours de développement ;

• les composants de la plateforme doivent être capables d'effectuer une identification initiale de tous les utilisateurs (non enregistrés et enregistrés) àpar leur adresse IP ;

• des privilèges minimaux doivent être définis pour les utilisateurs Internet lors de l'accès aux fichiers et aux répertoires du serveur d'applications, en limitant leur droit à « lecture seule » ;

• il faut interdire la possibilité de consulter la liste des répertoires et des fichiers du serveur d'applications depuis Internet (par exemple, en configurant le serveur d'applications) ;

• il est inadmissible qu'il soit possible d'accéder à un composant ou à une fonction de la plateforme en contournant l'autorisation (à l'exception de l'accès à la partie publique) ;

• un formulaire d'inscription/de connexion doit être mis en place pour les utilisateurs, en utilisant exclusivement le module d'authentification des utilisateurs par eID ;

• pour des raisons de sécurité, tous les fichiers appartenant au système doivent être stockés dans une structure de répertoires distincte au niveau du système d'exploitation et être protégés ; 

• les téléchargements non autorisés d'objets de fichiers sur le serveur d'applications doivent être bloqués ;

• les utilisateurs doivent être autorisés à télécharger uniquement les documents nécessaires à l'utilisation prévue ;

• les fichiers doivent être téléchargés dans un répertoire spécialement prévu à cet effet, à partir duquel l'exécution de scénarios et de scripts doit être interdite ;

• toutes les données et tous les paramètres reçus par la partie serveur du système via ses interfaces web doivent être vérifiés afin de s'assurer qu'ils correspondent aux types, tailles et plages de valeurs autorisées ;

• La plateforme doit contrôler les informations reçues afin de s'assurer qu'elles ne contiennent pas de code logiciel ou de séquences de commande nuisibles pour elle-même ou pour d'autres utilisateurs de la plateforme ;

• elle doit empêcher l'introduction de tout code malveillant dans le corps des messages destinés à être consultés publiquement ;

• le mécanisme empêchant l'introduction de composants nuisibles doit fonctionner non pas selon le principe de l'exclusion des données correspondant à certains modèles ou valeurs, mais selon le principe de l'exclusion de toutes les données qui ne correspondent pas aux valeurs ou modèles autorisés. Dans ce cas, les caractères de service doivent être convertis en code sécurisé, ce qui garantit leur affichage côté client ;

• lors du développement de la plateforme, les types d'erreurs possibles et les mécanismes de traitement des situations d'urgence doivent être définis ;

• en cas d'erreurs ou de situations d'urgence, le système doit en informer les utilisateurs sans fournir de données supplémentaires (par exemple, informations de débogage, vidages de mémoire, etc.) ;

• le message d'erreur ne doit pas contenir d'informations sur l'architecture et la structure interne de la Plateforme ;

• le logiciel d'application développé pour la Plateforme doit être capable d'intercepter toutes les exceptions ;

• une exception inconnue doit renvoyer un code d'erreur général ; 

• la Plateforme doit assurer l'enregistrement de tous les événements directement liés à la sécurité et leur stockage dans une base de données distincte de l'interface web ;

• il est interdit d'utiliser des moyens non certifiés pour apposer et vérifier la signature électronique ;

• avant le lancement de l'interface web, vérifier les codes sources afin de détecter les vulnérabilités résultant d'un filtrage (traitement) insuffisant et/ou incorrect des données entrantes (attaques de type JS-, SQL-injection, XSS et autres) ;

• les pages HTML transmises à l'utilisateur doivent contenir uniquement des hyperliens vers les ressources web officielles des autorités publiques ;

• tous les scripts JavaScript exécutés côté utilisateur doivent se trouver sur le serveur d'applications ;

• il est interdit d'utiliser des scripts hébergés sur des ressources web tierces ;

• l'accès anonyme à la base de données (à l’aide du compte « nobody ») doit être bloqué ;

• les processus du SGBD doivent être exécutés avec un UID/GID unique, qui n'est utilisé par aucun autre processus système ;

• la structure logique de la base de données doit être conçue en tenant compte de la mise en œuvre de la fonction SGBD avec une séparation des accès aux données ;

• tous les mots de passe stockés dans le SGBD doivent être conservés sous forme chiffrée ;

• la plateforme doit permettre la sauvegarde et la restauration des données système et utilisateur.

5.18 Exigences relatives à la garantie et à l’assistance technique

L’administration et le support de garantie des modules logiciels, des sous-systèmes et des services de la Plateforme doivent être définis et conformes aux conditions contractuelles.

Ces données peuvent être précisées au cours de l’élaboration du cahier des charges techniques et y être consignées.

5.19 Exigences relatives à la formation des utilisateurs

Pour une interaction efficace des utilisateurs avec la Plateforme, il est nécessaire d'assurer la formation et l'organisation d'ateliers pour le personnel du Client.

La formation doit couvrir différents groupes d'utilisateurs de la Plateforme. En particulier, pour les utilisateurs finaux (utilisateurs des services, fonctionnaires, etc.) et les administrateurs de la Plateforme, la formation doit comprendre au minimum :

• des cours pratiques sur les fonctions de la Plateforme (inscription, soumission de demandes, accès à l'information, exécution des opérations de base, etc.) ;

• l'accès à des supports de formation, des tutoriels vidéo et la documentation d'utilisation.

Les spécialistes impliqués dans la création de processus métier à l'aide de la plateforme (développeurs, analystes métier, etc.) doivent suivre :

• des programmes de formation certifiés de différents niveaux de complexité, du niveau de base au niveau avancé, visant à acquérir un niveau donné de compétences et de connaissances :

  • niveau de base – familiarisation avec les fonctionnalités de la Plateforme (espace personnel, partie administrative, rôles système, connexion). Recommandé pour tous les nouveaux utilisateurs ;

  • niveau intermédiaire – familiarisation approfondie avec le panneau administratif, acquisition de compétences en matière de création de processus métiers et de développement de services. Recommandé pour les développeurs ;

  • niveau avancé (analystes métiers) – maîtrise approfondie de la Plateforme et du panneau d’administration, ainsi que de leur utilisation dans le travail d’analyse et de conception de services ;

  • niveau expert – développement et configuration d’intégrations pour la Plateforme.

Chaque cours de certification doit inclure :

• des vidéos pédagogiques ;

• des supports textuels (notes de cours) ;

• des tests pour vérifier les connaissances ;

• des exercices pratiques ;

• vérification des tâches effectuées et retour d'information des mentors.

• des ateliers thématiques sur le développement d’un service à l’aide de la Plateforme « à partir de zéro » (de l’analyse métier au prototype fonctionnel) sous la supervision de mentors.

5.20 Exigences relatives aux outils d'automatisation intelligents basés sur l'intelligence artificielle

La plateforme doit prendre en charge l'utilisation d'outils basés sur l'intelligence artificielle pour automatiser le développement, la configuration et le support des processus métier. Ces outils doivent inclure :

• des mécanismes de transformation automatique des spécifications des exigences système (System Requirements Specification – SRS) en code source pour les processus métiers ;

• la prise en charge de recommandations automatisées pour l’optimisation du code et des processus métiers, la fourniture d’astuces et de fonctions de saisie automatique du code, etc. ;

• la capacité de fournir des réponses en mode dialogue aux questions des développeurs, en tenant compte du contexte de la documentation de la Plateforme ;

• la prise en charge du MCP (Model-Centric Process) pour la création automatique de processus métiers et l’obtention d’informations au nom de l’utilisateur via des agents d’IA.

Les exigences peuvent être précisées au cours de l'élaboration du cahier des charges techniques et y être consignées.

6 Exigences relatives à la documentation

La documentation doit comprendre :

• Le cahier des charges ;

• Description générale du logiciel ;

• Programme et méthodologie des essais ;

• Protocole d'essais ;

• Mode d'emploi ;

• Mode d'emploi de l'administrateur ;

• Instructions de déploiement et de restauration en cas de panne ;

• Règlement de maintenance technique.

Le cahier des charges doit inclure : 

• informations générales sur le projet ;

• une description détaillée des exigences fonctionnelles et non fonctionnelles, y compris les caractéristiques techniques, la structure du logiciel, les maquettes des interfaces ;

• la composition et le contenu des travaux ;

• la procédure de contrôle et d'acceptation du logiciel ;

• les exigences relatives à la composition et au contenu des travaux de préparation de l'objet d'automatisation avant sa mise en service ;

• exigences en matière de documentation.

La description générale du logiciel doit inclure :

• la destination du logiciel ;

• une description de la structure et des fonctions du logiciel ;

• une description des interactions avec d'autres systèmes.

Le programme et la méthodologie des essais doivent inclure :

• les dispositions générales et l'objet des essais ;

• la liste des travaux à effectuer dans le cadre des essais ;

• les conditions et la procédure des essais ;

• des cas de test pour vérifier les exigences relatives aux fonctions exécutées par le logiciel.

Le protocole des essais doit contenir :

• des informations générales sur la réalisation des essais ;

• les résultats des essais effectués conformément aux cas de test ;

• les conclusions relatives aux essais effectués et à l'état de préparation du logiciel à l'exploitation.

Le mode d'emploi doit contenir :

• la destination et les conditions d'utilisation du logiciel ;

• une description des travaux préparatoires ;

• une description des opérations nécessaires à l'exécution des fonctions du logiciel.

Le manuel de l'administrateur doit décrire :

• la destination et les conditions d'utilisation du logiciel ;

• la description des travaux préparatoires ;

• la description des opérations de gestion des accès des utilisateurs ;

• la description des opérations nécessaires à l'exécution des fonctions du logiciel par l'administrateur, y compris la gestion des rôles, la consultation des journaux et la surveillance du fonctionnement du système.

Les instructions de déploiement et de restauration en cas de panne doivent décrire :

• les informations générales sur le logiciel ;

• une description de l'infrastructure du projet, qui doit inclure une description de l'architecture de la plateforme, ses niveaux, ses composants, ses modules et leurs interconnexions ;

• la description des actions à effectuer lors de l'installation et du déploiement du logiciel ;

• la description des actions à effectuer pour configurer le logiciel ;

• la description des actions à effectuer pour configurer la sauvegarde des données (backup) et la restauration en cas de panne (plan de reprise après sinistre – Disaster Recovery Plan).

Règlement de maintenance technique de la plateforme, contenant la description des travaux et la fréquence d'exécution des procédures suivantes :

• mise à jour des logiciels supplémentaires (Redis, RabbitMQ, ELK, etc.) ;

• audit de sécurité du système ;

• mise à jour de la sécurité ;

• mise à jour des systèmes d'exploitation sur les nœuds (mise à jour automatique de la sécurité) ;

• mise à jour des certificats TLS ;

• renouvellement du domaine (effectué par le client) ;

• mise à jour des composants du cluster Kubernetes ;

• surveillance des ressources du cluster et ajout de ressources si nécessaire ;

• nettoyage et archivage des données et des journaux ;

• la sauvegarde des données.

La documentation relative à la Plateforme doit être complète, informative, compréhensible, structurée, facile à lire, suffisante, univoque et cohérente (les termes, définitions, identifiants, etc. doivent être identiques) afin de pouvoir être utilisée par les techniciens et les utilisateurs.

La documentation doit être fournie par le Prestataire sous forme papier et électronique (aux formats *.docx et *.pdf) et doit être rédigée dans la langue officielle du client.

7 Exigences relatives à la composition et au contenu des travaux de création du système

La plateforme est créée par étapes. Les délais d'exécution des différentes phases et étapes des travaux sont indiqués dans le tableau 1 où sont déterminés par les documents contractuels.

Tableau 1 - Composition et contenu des travaux

8 Préparation et réglage du matériel et des logiciels

Le Client fournit à l’Exécutant l’accès aux moyens techniques nécessaires au déploiement et à la configuration des composants logiciels requis pour le fonctionnement de la Plateforme.

Le Client garantit l’accès des spécialistes du Prestataire impliqués dans les processus de déploiement, de test et de réception/transfert de la Plateforme en exploitation pilote aux moyens logiciels et techniques susmentionnés, afin de procéder à la configuration finale et à l’ajustement opérationnel des composants de la Plateforme.

Annexe A

Spécification des logiciels, des technologies et des langages de programmation 

Le participant doit remplir le tableau ci-dessous en indiquant les informations relatives au produit, à la technologie ou au langage de programmation qu'il utilise comme composant correspondant du système.