Le Cloud pour les administrations

La doctrine de l’État Cloud au centre poursuit un objectif principal : inscrire durablement le virage Cloud dans la stratégie numérique des administrations. Cette doctrine complète engage les administrations sur la voie de la transformation et leur donne accès aux ressources nécessaires.
Nous vous recommandons ici 5 étapes à suivre pour bien démarrer avec la doctrine et ainsi faciliter sa mise en œuvre au sein de vos services.

L’adoption du cloud est une transformation majeure et, comme dans tout processus de cette nature, la description de la cible importe moins que la réflexion accompagnant des modifications culturelles, l’acquisition de nouveaux savoir-faire et l’adaptation des modes de fonctionnement. Plutôt que de prescrire « où aller ? » ou « comment y aller ? », nous préférerons donner quelques pistes pour expliquer « par quoi commencer ? » - qui encouragent la réflexion avec de bonnes questions à se poser qui mériteront à un moment ou un autre, de trouver une réponse.

Définir ses enjeux et choisir ses objectifs

Cette étape cruciale doit être traitée au plus haut niveau afin que les objectifs et orientations retenus soient soutenus par la chaîne hiérarchique :

• En quoi l’adoption du Cloud computing est-elle associée aux enjeux de modernisation de l’organisation – et pas seulement des activités informatiques ?
• Quels sont les domaines clés dans lesquels la poursuite de cet objectif d’excellence impose d’investir ? Le Cloud computing en fait-il partie ? Qu’en est-il pour la partie infrastructure ? Et sur la manière dont le service est rendu (DevOps, mode produit…) ?
• Quelles opportunités d’influencer le schéma directeur d’infrastructure ?
• Quelle trajectoire et quel pilotage de la transformation : en visant la conversion d’une proportion des effectifs ou des fonctions de l’organisation, ou au contraire d’un pourcentage des actifs techniques, applications ou serveurs ?
• Quelle gouvernance de transformation, et quelle implication de la hiérarchie ?

Établir le champ du possible

Il s’agit de décider du type de Cloud le plus adapté à son application à partir d’une cartographie exhaustive de son SI et des contraintes s’y appliquant : applications métier avec un équivalent en SaaS, contraintes réglementaires et de sécurité, flux inter-applications, licences logicielles, contrats d’hébergement et d’infogérance – sans que cette liste soit limitative.

Il en ressort une matrice d’emploi qui indique pour chaque segment de son système d’information le socle qui lui est permis.

Quelques exemples :

• Une application avec des données sensibles et essentielle au service rendu sera conservée sur le Cloud interne ou sur un Cloud commercial de confiance (SecNumCloud), hors de portée du droit extra-européen et conforme au RGPD ;
• Une application essentielle au service rendu avec des données non sensibles sera hébergée sur un Cloud commercial avec une redondance sur deux régions et l’étude préalable contiendra une analyse des risques ;
• Les activités des Startups d’État sans données sensibles, ou avec des données sensibles mais au stade du prototype, seront hébergées sur le Cloud de leur choix. Le jour où elles passent à l’échelle, la bascule sur un hébergeur conforme à sa sensibilité devient requise.

Il faut également quantifier le volet économique de cette transformation, qui même si elle est associée à des objectifs stratégiques de modernisation, ne doit pas être à l’origine d’une dérive incontrôlée de la dépense. En ce sens, le suivi fin des dépenses de bureautique des administrations, qui constituent encore un volet majeur de leur budget informatique, ne doit pas donner lieu à une nouvelle approche qui aggraverait sensiblement cette dépense, sous couvert de modernité et sous la pression des fournisseurs.

Identifier et traiter les prérequis majeurs

L'informatique en nuage correspond à un nouveau mode de consommation de ressources techniques : il impose une transformation profonde du fonctionnement de la direction du numérique et l’adaptation d’un certain nombre de règles techniques jugées hier indispensables. Toutes ces mutations ne sont pas à envisager au premier jour de la démarche d’adoption, mais certaines sont à considérer comme des prérequis, pas seulement pour laisser entrevoir l’accès aux bénéfices liés au fonctionnement selon les principes du « Cloud native » mais également pour ne pas compromettre le fonctionnement du SI.

Quelques exemples :

• Gouvernance de la dépense : le commissionnement de nouvelles ressources pouvant être engagées par les chaînes automatisées, une dérive de coût peut survenir du fait d’une mauvaise appréciation ou d’une erreur. Des garde-fous doivent être prévus comme l’étiquetage systématique des ressources et le paramétrage de seuils d’alertes – tout comme doit être permis l’engagement de ressources par les équipes opérationnelles dans des limites données ;
• Sécurité : l’implémentation de la sécurité repose pour partie sur la sécurisation de composants a priori, et pour partie sur une implémentation par les équipes de développement. Ces travaux préalables tout comme la mise en place de contrôles continus de conformité et le raccordement au SOC doivent être réalisés ;
• Réseau : un nouveau composant du SI développé dans un Cloud commercial peut engager des flux importants sur la connexion internet partagée qui, dépourvue de bande passante garantie, sera associée à des risques de contention et de baisse de performance. La question du raccordement au Cloud via un lien dédié et supervisé sera également posée dès le démarrage ;
• Pratique d’architecture : les standards traditionnels étant différents des principes d’architecture d’une application Cloud, il convient de ne plus y soumettre les nouvelles conceptions. Cela peut concerner les standards techniques, la persistance, la résilience mais aussi les pratiques de revue d’architecture qui doivent s’insérer dans l’organisation de l’équipe produit ;
• Ségrégation des opérations : les règles de fonctionnement préexistantes peuvent interdire à un développeur de manipuler un environnement de production, ou la connexion d’outils de déploiement ou de gestion de configuration directement à des instances de production. Il sera désormais nécessaire d’adapter le modèle opérationnel existant afin d’exploiter au mieux le potentiel des pratiques DevOps.

Nous insistons sur le fait que ces premiers prérequis ne fonderont pas une politique Cloud industrielle mais qu’ils permettront le démarrage des expérimentations sans être remis en cause par la suite.

Mettre en place le moteur de la transformation

L’adoption du Cloud est un processus d’acculturation. Il demande du temps et de l’accompagnement. Il convient de s’entourer d’une équipe d’experts sur le sujet qui sauront apporter une aide opérationnelle – c’est-à-dire ne pas se limiter aux concepts mais maîtrisant les outils que devront s’approprier les équipes et pouvant transmettre les bonnes pratiques par l’exemple.

Différents modes d’engagement existent, abondamment documentés dans la littérature Cloud : front office Cloud, centres d’excellence Cloud, coaching, services professionnels des fournisseurs Cloud, sont les plus répandus. Il est possible également de partir de zéro et que les premières équipes de développement ouvrent la voie et intègrent ces compétences.

À noter que la DINUM collabore avec la direction des achats de l’État (DAE) et l’UGAP pour identifier les marchés de prestations existants et à venir, donnant accès à ces dispositifs externes. Il est possible notamment d’accéder aux services professionnels (accompagnement opérationnel, bonnes pratiques) et aux formations proposés par les fournisseurs du marché de Cloud commercial ainsi qu’aux services du front office de l’offre Cloud interne Nubo.

Débuter avec un ou plusieurs pilotes

Une fois ces étapes franchies, il est possible de rentrer dans le vif du sujet, en débutant les opérations de développement de services en mode nativement cloud ou de migration de l’existant.

Le choix des pilotes doit respecter plusieurs critères : l’environnement doit être représentatif en termes de taille et de standards techniques et offrir la garantie de pouvoir pousser l’expérience jusqu’à la production (ce qui le distinguera de la preuve de concept). Concernant la représentativité, il est important de noter que les standards de sécurité ne doivent pas être dégradés. La sécurité dans le cloud, qui impose des mesures spécifiques et une attention particulière de la part des équipes de développement, ne peut être « remise à plus tard ».

Enfin, les enseignements qui en seront tirés doivent être de portée générale.