Christophe Vercellone (Min. Intérieur) : « tous les SI de l’État ont vocation à être sur un cloud »

Pouvez-vous nous présenter le Ministère de l’Intérieur ?

Comme l’expliquait Mathieu Weil, Directeur de la Transformation Numérique, SGA et AMDAC au Ministère de l’Intérieur, le Ministère de l’Intérieur est le ministère du quotidien par excellence avec évidemment une dimension d’ordre public et de sécurité des citoyens (police, gendarmerie, sécurité civile…) mais aussi d’autres missions tout autant importantes : titres d’identité, étrangers en France, associations, vie démocratique (élections…), etc. Nous avons 300 000 agents sur l’ensemble du territoire français dont 150 000 policiers et 100 000 gendarmes.

Pouvez-vous nous rappeler brièvement ce qu’est la doctrine « Cloud au Centre » et ce que cela implique ?

Cette doctrine affirme un principe simple : tous les SI de l’État ont vocation à être dans un cloud au sens de choix technologique, que ce cloud soit interne ou externe. Il y a un régime de dérogation si quelque chose n’est pas compatible mais le principe est le cloud, l’exception le non-cloud.

Sur la question de la sécurité et de la souveraineté, nous avons défini trois niveaux comme trois cercles concentriques. Pour le non-sensible, nous pouvons recourir à un cloud commercial, y compris américain ou chinois. Ensuite, nous avons le cloud SecNumCloud qui est externe mais qui nous garantit la sécurité et l’immunité vis-à-vis des lois extra-territoriales telles que les lois américaines ou chinoises qui permettent aux autorités de ces pays d’accéder aux datas stockées sous leurs entreprises. Enfin, nous avons le cloud interne, hébergé par les soins d’une administration. Il en existe deux à vocation interministérielle. Le premier est Nubo, hébergé par le Ministère des Finances, le second est Pi. Il existe aussi un cloud interne au Ministère des Armées mais réservé à la Défense.

Les personnels du Ministère de l’Intérieur supervisent à la fois Pi et Nubo. En ce qui le concerne, Pi comporte une offre « diffusion restreinte » et est supervisé 24/24, 365 jour/an.

Pourquoi avoir adopté un cloud interne ?

L’histoire commence en 2014. Avec l’aide de HP, le ministère se lance dans l’aventure du Cloud. A l’époque, notre architecture repose largement sur du Vmware. L’idée est de remplacer la virtualisation simple par du cloud, notamment pour démontrer que nous ne sommes pas un client captif. Nous utilisons alors HPOS comme système.

En 2017, HP annonce la fin de HPOS, revendu à Solucom puis à Suse. Le produit sera totalement arrêté en 2019. En 2019, la solution n’a plus évolué depuis deux ans mais, à notre demande, HP garantit le support sur notre installation jusqu’à fin 2022. HPOS était basé sur OpenStack.

Au 1^er janvier 2020, nous créons, au ministère, la Direction de la Transformation Numérique. Et nous nous posons la question de la pertinence de disposer d’un cloud interne plutôt que de recourir à de l’hébergement externe SecNumCloud. Nous remettons tout à plat, notamment le coût. Nous avons rapidement la conviction que, d’une part, le Ministère de l’Intérieur ne peut pas se passer d’un hébergement interne et que, d’autre part, le cloud est l’avenir technique. C’est d’autant plus vrai que nous pensons que les éditeurs ne fourniront plus, à terme, que des solutions Cloud. Certaines part de notre SI ne peuvent en aucun cas avoir un hébergement délégué, par exemple le SI des élections.

La question posée n’était pas sur faire/pas faire mais sur « combien ça coûte » et pour quels usages. Nous n’avons pas la nécessité de tout héberger en interne. Typiquement, le site web public est public !

Nous avons calculé que Pi serait rentable avez un taux de remplissage de 70 %, ce qui correspond à la limite haute de la zone de fonctionnement optimale de l’infrastructure. Au regard des besoins propre du ministère, il était évident qu’il nous fallait ouvrir à l’interministériel. Mais nous n’avions pas non plus besoin d’héberger en interne tout notre SI.

Après six mois d’études et de validation, notre plateforme sous HPOS a évolué vers RedHat : le IaaS sous OpenStack et le PaaS avec OpenShift (orchestration de conteneurs). Toute l’architecture a ainsi évolué.

Notre logique est aujourd’hui l’automatisation, le DevSecOps et la vérification de la sécurité. Nous avons également un cloisonnement entre la production hébergée et le cas échéant des développements opérés sur un hébergement pouvant être externe.

Où en est Pi aujourd’hui ?

Nous disposons aujourd’hui de deux datacenters avec une cinquantaine de baies physiques représentant plus de mille serveurs et dix mille machines virtuelles. Nous avons plus de 500 applications hébergées dont environ 10 % « Pi Natives » sur OpenShift.

Comment facturez-vous l’hébergement à d’autres ministères ?

Le principe est bien rodé : c’est celui de conventions budgétaires, équivalentes à un contrat dans le privé, précisant quelles lignes budgétaires sont impactées. Deux fois par an, la Direction du Budget assure les transferts.

Il y a deux types de droits : le souscripteur a le droit de demander des ressources, le responsable technique a le droit d’utiliser les ressources. Parfois, il y a des dépassements mais ça se gère en bonne intelligence. Normalement, on estime le besoin et on demande le paiement de 75 % et, en complément, le reliquat de la période budgétaire précédente.

De toutes manières, le ministère de l’intérieur est obligé de faire et donc d’assumer les coûts. Mais, non, nous n’arrêterons pas un service qui dépasserait sa consommation prévue. Au pire, il y aura une escalade hiérarchique pour arbitrer.

Quelles sont les évolutions prévues pour Pi et les défis que vous avez à relever ?

Je vois trois points.

Le premier est au niveau des infrastructures pures. Aujourd’hui, nous avons deux datacenters qui sont comme deux « régions », ce n’est pas de l’actif-actif natif. Quand nous avons besoin d’actif-actif, c’est géré au niveau applicatif. Nous allons passer à trois datacenters avec la capacité à subir une destruction totale d’un site, en full actif-actif natif, avec une réplication gérée par OpenShift d’ici 2026.

Nous allons aussi regarder d’autres solutions qu’OpenShift pour éviter d’être client captif de cette solution. Ce n’est jamais bon d’être client captif.

Deuxièmement, nous allons réaliser une véritable bascule cloud. Dès 2019, nous avions prévu le « cloud first » avec une règle : toute application qui évolue bascule sur le cloud aussitôt. Mais, parfois, c’était juste un lift & shift. Or, comme vous le savez, le lift & shift n’est pas idéal. Ce qui va permettre de bénéficier réellement du cloud, c’est l’automatisation avec la prédictibilité des effets d’un déploiement.

Nous avons eu beaucoup de scories liées au lift & shift et la bascule HPOS/OpenStack-OpenShift n’a pas été aussi simple que prévu. Actuellement, nous préférons mettre en œuvre des applications nativement cloud et conçues pour être « Pi Natives », sous OpenShift. Concernant le Legacy, nous effectuons des migrations module par module. Le défi est la bonne appropriation des technologies par les développeurs.

Enfin, troisième et dernier point, nous allons mettre en place une infrastructure pour l’IA, avec des GPU, courant 2025. Nous allons en effet être obligés d’héberger nos IA en interne. Il nous faut donc intégrer les GPU dans notre cloud. Et ce n’est pas trivial…