Cloud
Quand 15 règles précisent la doctrine «cloud au centre» de l’État
Par Thierry Derouet, publié le 22 juin 2023
C’est le 31 mai dernier qu’une version actualisée de la doctrine d’utilisation du cloud au centre par l’État a été publiée au Journal officiel. Objectif de cette mise à jour : préciser le recours — ou pas — à des solutions SecNumCloud. Mais aussi faire le point sur le « move to cloud » de notre pays.
C’était presque passé sous silence. La circulaire n° 6404/SG a mis à jour la doctrine « cloud au centre » de l’État français en établissant 15 règles que l’État et les organismes sous sa tutelle, y compris les établissements de santé publics, doivent respecter. Si cette note apporte quelques précisions dont certaines sont d’ordre sémantique, il faut lire entre les lignes pour y voir du bon sens, des précisions comme quelques entorses au SecNumCloud.
Cloud au centre : des précisions sémantiques
Faut-il s’en étonner ? Mais l’actualisation de la circulaire entend simplifier le jargon du cloud en se concentrant sur deux concepts : le cloud pour les équipes informatiques (IaaS + PaaS) et le cloud pour les utilisateurs (SaaS). Utile, elle réaffirme également les cercles de confiance établis en 2018, distinguant le cloud « interne », géré par l’État, et le cloud « commercial », géré par un fournisseur et soumis à divers niveaux de sécurité dont notre fameux SecNumCloud local ou son équivalent à venir européen, l’EUCS, toujours en discussion (European Cybersecurity Certification Scheme for Cloud Services).
Un cloud commercial « accompagné »
Côté « move to cloud » de l’État, l’actualisation de la circulaire indique que plus « de 200 projets ont exprimé leur intérêt pour les offres de cloud commercial et ont entamé leur transition ». La qualification par l’Ugap de plusieurs offres, dont certaines labellisées SecNumCloud (Outscale SAS, OVHCloud, Cloud Temple, Oodrive et Worldline), aurait facilité l’acquisition de solutions clés en main par l’État comme par les collectivités. Fournisseurs comme administrations partenaires sont même encouragés à continuer à développer ces offres sur les plans fonctionnels, sécuritaires et d’interconnexion avec le Réseau interministériel de l’État (RIE). Comprendre ici que des discussions ont bien lieu entre la DINUM et les fournisseurs pour définir ensemble les priorités souhaités et souhaitables. Une très bonne chose.
À LIRE AUSSI :
Un « cloud au centre » en bonne évolution
La note signée d’Elisabeth Borne précise également que plusieurs projets de grande envergure ont été déployés ou sont en cours de déploiement sur le cloud interne de l’État. Un cloud interne maitrisé pour le ministère de l’Intérieur (Cloud PI) dès lors où les données requièrent un niveau de sécurité dit de « diffusion restreinte » comme par Bercy (Cloud NUBO), quand le standard SecNumCloud est requis. Chez Elisabeth Borne on tient ici à saluer la taille critique suffisante d’un cloud interne reposant sur la solution open source OpenStack pour sa « viabilité », son « ouverture aux besoins interministériels » et même ses coûts et performances « qui, sans atteindre encore le niveau des acteurs industriels spécialistes, rendent l’usage acceptable pour les besoins dont le niveau de sécurité le justifie ». Tout en précisant que des évolutions sont toutefois à venir « aussi bien en termes de résilience, de richesse des éléments PaaS que de qualité de la relation client » avec notamment le projet d’y inclure une offre d’orchestration de containers.
Un service public, la tête dans les nuages ?
Enfin, il est rappelé que l’adoption croissante de logiciels en mode SaaS (Software as a Service) par les services de l’État se poursuit. Rappelons que la DINUM a amorcé une offre de services numériques interministériels basée sur des plateformes cloud avec des services collaboratifs. Avec en pointillé le souhait d’en optimiser toutefois « l’ergonomie, la sécurité, la protection des données et la maitrise des dépenses, tout en identifiant les opportunités de mutualisation ».
Des exceptions concernant SecNumCloud
Pour Elisabeth Borne, il était également « nécessaire de mieux délimiter le périmètre des données d’une sensibilité particulière ». Si la neuvième règle ne souffre d’aucune interprétation quant au respect de la qualification SecNumCloud pour les données « à caractère personnel ou non, d’une sensibilité particulière et dont la violation est susceptible d’engendrer une atteinte à l’ordre public, à la sécurité publique, à la santé et la vie des personnes ou à la protection de la propriété intellectuelle », elle autorise toutefois certaines exceptions. Ainsi des dérogations sont acceptées pour l’ensemble des projets déjà engagés « sous la responsabilité du ministre dont relève le projet, et après validation du Premier ministre, sans qu’elle ne puisse aller au-delà de 12 mois après la date à laquelle une offre de cloud acceptable (c’est-à-dire, dont les éventuels inconvénients sont supportables ou compensables) sera disponible en France. » Mais également pour des projets de moindre importance qui peuvent, eux, échapper au cloud (la septième règle mériterait d’être plus explicite).
Certaines voix se font déjà critiques, car si la circulaire mentionne l’hébergement de données de santé, elle ne prend en revanche pas de position claire sur les services non européens qui bénéficient de la certification HDS et qui pour autant ne sont pas (pour l’heure) SecNumCloud. Le député de la première circonscription de Vendée, Philippe Latombe, a d’ailleurs souligné dans un communiqué début mai essentiel de vouloir continuer à « pointer les incohérences entre l’objectif affiché par le gouvernement d’œuvrer pour la souveraineté numérique de notre pays, et la mise en pratique de cette volonté…/… Procrastination, quand tu nous tiens ! ». Procrastination ou embarras au plus haut niveau de l’État ?
Les 15 règles du « cloud au centre »
[R1] Du cloud sinon rien
Pour tout nouveau projet numérique, quelle que soit sa taille, une solution cloud doit être recherchée : si le « cloud pour les utilisateurs » ne permet pas de remplir le besoin, une solution dédiée doit être envisagée sur une plateforme du « cloud pour les équipes informatiques ». Dans les deux cas, le mode produit doit être privilégié, incluant l’autonomie des équipes, la prise en charge continue des opérations, la confrontation rapide avec les utilisateurs du produit et un jalonnement par l’impact permettant d’arrêter, d’infléchir ou d’accélérer la trajectoire du produit en fonction des résultats constatés.
[R2] Acculturation et formation
Le recrutement et la formation continue doivent comprendre un volet cloud. Les équipes novices en matière de cloud bénéficieront d’un accompagnement spécifique de la part de leur ministère et de la DINUM.
[R3] Un “move” généralisé
Chaque administration doit mettre en place des processus pour encourager l’adoption du cloud, identifier les obstacles et élaborer un plan d’action pour les surmonter.
[R4] Conformité et réversibilité
Tout projet utilisant le cloud commercial doit prévoir des conditions de fin de contrat et de réversibilité viables, provisionner les ressources nécessaires dès le début du projet et rechercher la conformité avec les règles de GAIA-X.
[R5] Cybersécurité non négociable
Tout projet numérique utilisant le cloud doit adhérer aux meilleures pratiques en matière de résilience, en s’appuyant sur des services déployés dans diverses régions pour garantir la continuité ou la reprise d’activités, selon le niveau de criticité. L’offre cloud utilisée doit offrir des garanties en termes de mises à jour de ses composants susceptibles d’être affectés par des failles de sécurité, ainsi que de transparence et de réactivité en cas d’incidents. Si une offre cloud commerciale est envisagée, l’administration doit prendre des mesures de détection et d’isolation pour prévenir la propagation d’une compromission de sécurité.
[R6] Cloud first
Pour tout nouveau projet informatique, l’État et ses prestataires doivent par défaut utiliser le cloud, interne ou commercial, pour gérer tout le cycle de production des applications. Les ministères déterminent leur choix de cloud en fonction de divers critères, tels que le niveau de sécurité, le coût total, l’expertise en ressources humaines, les besoins techniques et fonctionnels, et les choix d’urbanisation précédents. Cette règle s’applique également aux produits numériques existants subissant une évolution majeure, comme un changement de prestataire ou des évolutions coûtant au moins 50 % du coût initial du produit.
[R7] Dérogations possibles pour de petits projets
Les équipes souhaitant déroger à la règle [R6] doivent documenter leur choix auprès de la DINUM pour tout projet coûtant au moins un million d’euros, en fournissant une analyse comparative des scénarios.
[R8] Contrôle de l’État pour les gros projets
Le contrôle de la doctrine « cloud au centre » est intégré à la procédure de contrôle de conception des grands projets informatiques de l’État, pour les projets de plus de neuf millions d’euros. En dessous de ce seuil, le contrôle est à la charge des ministères.
[R9] Conformité RGPD
Lors de l’utilisation d’une offre de cloud commerciale, les systèmes informatiques traitant des données à caractère personnel doivent être conformes au RGPD, y compris en ce qui concerne les transferts de données hors de l’UE. Pour les données de santé, l’hébergeur doit respecter la législation spécifique. Si les données sont particulièrement sensibles (par exemple, liées à la sécurité nationale ou la santé publique), l’offre de cloud doit avoir une qualification SecNumCloud ou équivalent et être immunisée contre tout accès non autorisé par des autorités publiques d’État tiers. Une dérogation à cette règle peut être accordée temporairement pour les projets en cours, sous certaines conditions.
[R10] Portabilité quasi obligatoire
Il est essentiel de garantir la portabilité entre différents environnements de cloud. Ainsi, les équipes informatiques doivent veiller à ce que les dépendances techniques et fonctionnelles liées à la plateforme cloud choisie ne nuisent pas significativement à cette capacité de réversibilité et de changement de fournisseur de cloud. Si ces dépendances sont néanmoins justifiées par des avantages opérationnels immédiats, les coûts supplémentaires de la réversibilité doivent être couverts par ces gains.
[R11] Collaboratif pour tous les agents de l’État
La DINUM, en collaboration avec les DNUM, est chargée de superviser la conception et la mise en œuvre des outils collaboratifs interministériels. Ces outils doivent être accessibles à tous les agents de l’État à la demande.
[R12] Mutualisation obligatoire
Les ministères peuvent offrir à leurs agents des services logiciels supplémentaires à ceux disponibles dans la suite collaborative interministérielle. Ces offres doivent répondre aux attentes des utilisateurs, tout en respectant les ressources humaines et financières dont disposent les ministères. Ils sont encouragés à mutualiser leurs ressources pour cela, avec le soutien de la DINUM, sans empêcher les agents d’accéder à la suite collaborative interministérielle.
[R13] Le SaaS à préférer au sur mesure
Les administrations ne doivent pas chercher à créer et maintenir de nouveaux logiciels sur mesure qui existent déjà dans les sphères publiques ou privées ou parmi les communs numériques contributifs. Elles doivent répondre aux besoins de leurs agents et des citoyens en privilégiant les solutions existantes, soit par le biais d’un abonnement à un logiciel à la demande (offres SaaS commerciales), soit en intégrant, adaptant et déployant ces solutions sur le cloud interne de l’État (offres SaaS internes). En l’absence de solutions prêtes à l’emploi, elles peuvent se lancer dans un développement sur mesure limité au périmètre spécifique en question.
[R14] RGPD toujours et encore
Pour les services mentionnés en [R11] et [R12], la conformité des infrastructures et des services de l’éditeur à la règle [R9] est obligatoire.
[R15] Mise en concurrence systématique
En respectant les règles de la commande publique, il faut rechercher la diversité des fournisseurs à l’échelle de l’État pour chaque segment des services aux utilisateurs, afin d’éviter la création de marchés captifs. Les administrations doivent, chaque fois que possible, évaluer plusieurs offres couvrant leurs besoins, en particulier dans les domaines de la micro-informatique, de la bureautique, de la messagerie et des solutions collaboratives.
