Ces évolutions concernent la création de nouveaux services qui peuvent par exemple être une usine logicielle (CI/CD…), des services de sécurité (HSM, KMS, Log Lake…), des services PaaS (BDDaaS, orchestration de containers, OCRaaS…), amélioration des niveaux/plages de services existants (support 24/7, résilience longue distance).

La réalité du besoin sur ces évolutions doit se traduire obligatoirement par au moins un engagement formalisé d'un ministère tiers d’utiliser ces services une fois qu’ils seront disponibles.

1. Importance de l’application et bénéfices du projet pour les utilisateurs :

Le niveau de criticité de l’application, le niveau de sensibilité des données traitées, le nombre d’utilisateurs, les bénéfices apportés (comme par exemple la réduction des délais de mise à disposition de nouvelles fonctionnalités « time to market », ou la robustesse accrue de l’application (taux de disponibilité plus élevé et productivité des agents ou utilisateurs).

2. Réduction du niveau de risque sur les SI :

est attendue une démarche structurée d'analyse de prise en comptes des menaces et des risques SSI. Celle-ci consiste en la prise en compte à la fois des enjeux de mutualisation des infrastructures inhérents au Cloud, et de l'impact du Cloud sur le poste de sécurité, comme par exemple :

• L’amélioration de la résilience du SI, facilitée par la mise à disposition de plateformes d’hébergement Cloud homogènes dans des régions géographiques distinctes, avec du paiement à l’usage permettant d’avoir des coûts de fonctionnement contenus (continuité d’activité, reprise après sinistre majeur) ;
• L’amélioration de la disponibilité du SI, facilitée par la mise à disposition de multiples centres de données, avec des niveaux de redondance et de latences garantis, qui permettent de définir le taux de disponibilité de la solution grâce à l’architecture technique définie et de mécanismes de bascules automatiques ;
• L’amélioration de la réactivité sur incident et la réduction d’erreurs humaines, grâce à la systématisation des contrôles via l'autonomisation des opérations de maintenance et des actions de détection et de correction des évènements de sécurité
• La réduction des possibilités d’attaques et des erreurs humaines lors des opérations de configuration, grâce à la validation de l'intégrité et la conformité des socles techniques avant leur démarrage.
• L'amélioration du traitement de l'obsolescence et du suivi des éléments de configuration, grâce à la consommation des composants sur étagère dans le catalogue du fournisseur Cloud.

3. Capacité à réaliser le projet et, une fois achevé, à le gérer en interne : équipe projets et compétences réunies, planning, formation et acculturation des agents, organisation du maintien en conditions opérationnelles et de la gestion des évolutions (idéalement dans un mode DevOps et avec des agents)

4. Impact économique : présentation des différents postes de coûts du projet et des gains économiques ou des coûts évités, par exemple :</strong>

• Le coût plus faible des ressources Cloud par rapport à un hébergement existant ;
• Les gains de productivité des équipes numériques, aussi bien sur le maintien en conditions opérationnelles que sur les évolutions fonctionnelles, et ce grâce à l’automatisation, la standardisation et la capacité à itérer rapidement et avoir une boucle rétroaction écourtée ;
• Les gains métiers lié à l’amélioration de la disponibilité du service, ou la fréquence plus élevée de mise à disposition de services pertinents ;
• Les projets à mener pour se mettre en conformité avec les exigences de sécurité des métiers si le projet n’était pas lancé.

1. Qualité de la proposition de valeur pour les clients de l’offre Cloud :

les services développés devront avoir un impact réel sur l’utilisation des offres de cloud interne interministériel, notamment en termes de :

• Gain en réactivité des équipes utilisatrices des services afin d’améliorer la qualité perçu par l’usager du service numérique ;
• Réduction du niveau de risque sur les SI par l’amélioration de la résilience, de la disponibilité des services, la prise en charges des opérations liées au traitement de leur obsolescence ;
• Bénéfice économique à utiliser les services développés.

La cohérence entre les évolutions proposées et l’état de l’art chez les grands offreurs de Cloud externe sera par ailleurs une clé d’appréciation de la pertinence de ces évolutions.

2. Justification du « marché » identifié pour les évolutions : le dossier doit établir que les services sont attendus et seront utilisés par un large panel d’équipes/produits, hors ministère porteur du projet, avec des utilisateurs pilotes déjà candidats à une phase de pilote.

3. Capacité à réaliser le projet et, une fois achevé, à le gérer en interne : équipe projets et compétences réunies, planning, formation et acculturation des agents, organisation du maintien en conditions opérationnelles et de la gestion des évolutions (idéalement dans un mode DevOps et avec des agents).

4. Impact économique: investissement nécessaire pour mettre à disposition le service, impact de son évolution et de son maintien en conditions opérationnelles sur les budgets de fonctionnement, mode de refacturation du service, volume de clients et d’usages pour justifier son intérêt économique.