Un de vos clients ou un appel d'offres exige désormais un hébergement souverain, et votre application tourne sur AWS. La question n'est pas de savoir si c'est possible : nous l'avons fait. Elle est de savoir ce qui change réellement pour vous, et ce qu'AWS lui-même ne peut pas vous offrir.
Pourquoi cette demande arrive maintenant
La qualification SecNumCloud, délivrée par l'ANSSI, atteste qu'un hébergeur protège les données contre des lois étrangères comme le Cloud Act américain. Sa version actuelle, la 3.2, a ajouté des critères de souveraineté stricts en plus des critères de sécurité technique.
Pour les services de l'État, c'est une obligation. Pour une entreprise privée, ce n'est en général pas une obligation légale directe, mais c'est de plus en plus souvent une exigence contractuelle : un client public, une étude notariale, une banque ou une collectivité qui demande, dans son cahier des charges, que ses données soient hébergées sur une offre qualifiée SecNumCloud. C'est exactement la situation qui nous a amenés à migrer un éditeur de logiciel pour notaires d'AWS vers S3NS.
Le déclencheur est presque toujours le même, qu'on parle à un CTO ou à un DSI d'éditeur : un questionnaire de sécurité envoyé par un gros client, ou une clause ajoutée à un appel d'offres, qui nomme explicitement une exigence de souveraineté. À ce stade, la question n'est plus théorique. Elle a une date limite.
Comment savoir si c'est vraiment nécessaire pour vous
Toutes les entreprises qui hébergent sur AWS n'ont pas besoin de migrer. La question à se poser avant d'engager quoi que ce soit : est-ce qu'un client, un secteur ou un texte précis exige nommément une offre qualifiée SecNumCloud, ou est-ce une inquiétude générale sur la souveraineté sans contrainte formelle derrière ?
Dans le premier cas, la migration a un horizon concret et un responsable qui la demande : c'est le moment d'avancer. Dans le second, un audit de votre hébergement actuel suffit souvent à clarifier la situation, sans engager tout de suite une migration complète. Nous le disons même quand cela réduit la taille de la mission que nous aurions pu vendre : partir sur une migration sans exigence précise derrière coûte du temps et de l'argent, pour un bénéfice qui reste largement à démontrer.
AWS European Sovereign Cloud n'est pas SecNumCloud
AWS a lancé sa propre réponse à la souveraineté : l'AWS European Sovereign Cloud (ESC), une infrastructure séparée physiquement et logiquement du reste d'AWS, avec un personnel européen et une gouvernance européenne pour cette partition.
C'est une vraie avancée sur l'isolement des données et des opérations. Mais ce n'est pas la même chose que SecNumCloud, et la différence n'est pas un détail :
« SecNumCloud 3.2 exige que le prestataire soit détenu majoritairement par des capitaux européens, ce qui exclut structurellement AWS, même avec l'ESC. » (Sylvain Bruas)
Concrètement : si votre client exige nommément un hébergement qualifié SecNumCloud, dans son cahier des charges ou dans un audit de sécurité, l'AWS ESC ne cochera pas cette case, aussi solide soit son architecture. La question à poser n'est donc pas « ce cloud est-il sécurisé ? », mais « qui, précisément, exige quoi, et quelle offre y répond ? ». Les deux réponses ne se recouvrent pas toujours.
Qui migre vraiment, et comment choisir la cible
Nous intervenons en tant qu'intégrateur, jamais en tant qu'opérateur : la qualification SecNumCloud porte sur l'offre de l'hébergeur, pas sur nous. Nous vous aidons à choisir la cible et nous migrons votre application et vos données vers elle.
Plusieurs destinations sont qualifiées ou en cours de qualification SecNumCloud selon leur offre : S3NS (coentreprise de Thales et Google Cloud), Outscale (Dassault Systèmes), Cloud Temple, Numspot, et une partie des offres d'OVHcloud et de Scaleway. Le choix dépend de votre architecture actuelle, du catalogue de services dont vous avez besoin, et des contraintes propres à vos clients. Pour une application déjà construite sur des briques proches de Google Cloud, S3NS réduit en principe les écarts à combler. Pour une application sur AWS, c'est faisable aussi : c'est exactement ce que nous avons fait.
Notre méthode pour migrer sans interruption
Une migration mal préparée coûte en interruptions et en dette technique, quelle que soit la cible. Notre façon de procéder commence toujours par un audit : quels services, quelles dépendances, quel volume de données, quelle tolérance réelle à l'indisponibilité pendant la bascule.
Pour l'éditeur destiné aux notaires, cet audit a conduit au choix de S3NS comme cible qualifiée SecNumCloud. La migration a porté sur l'application complète et ses données, avec un passage sur Kubernetes au cours du projet plutôt qu'avant ou après : conteneuriser en migrant évite de refaire deux fois le travail de préparation. La bascule finale s'est faite sans interruption de service perçue par les utilisateurs. L'ensemble a pris trois semaines.
Nous ne prétendons pas qu'une migration se résume à ces quelques lignes : chaque application a ses propres contraintes de données, de dépendances et de tolérance au risque. Ce que nous pouvons dire, c'est que l'audit initial est ce qui rend le planning tenable, pas une étape qu'on saute pour aller plus vite.
Ce que nous ne faisons pas
Nous n'accompagnons pas la démarche de certification ou l'instruction réglementaire auprès de l'ANSSI : ce n'est pas notre métier, et un cabinet spécialisé y répondra mieux que nous. Notre rôle s'arrête à la partie technique : choisir la cible avec vous, migrer votre application, et construire une infrastructure propre une fois arrivés.
Concrètement, cela veut dire une infrastructure décrite en Infrastructure as Code, c'est-à-dire dans des fichiers versionnés plutôt que configurée à la main au fil des besoins, avec Kubernetes quand c'est pertinent pour votre application, des sauvegardes vérifiées et des accès nominatifs et révocables. Rien de spécifique à la cible : c'est la même rigueur que sur n'importe quelle infrastructure que nous reprenons ou construisons.
Et nous ne sommes, nous-mêmes, qualifiés par rien : la qualification SecNumCloud s'applique à un hébergeur et à son offre, jamais à un prestataire qui y migre des applications pour ses clients.
Retour d'expérience
La difficulté, sur ce projet, n'était pas de choisir une cible qualifiée : la liste des offres SecNumCloud est publique. Elle était de migrer une application en production, utilisée au quotidien par des études notariales, sans qu'aucune d'entre elles ne s'en aperçoive pendant la bascule.
Passer sur Kubernetes au même moment aurait pu doubler le risque. Dans les faits, cela a simplifié la suite : une fois l'application conteneurisée et décrite en Infrastructure as Code sur la nouvelle cible, la bascule du trafic est devenue une opération maîtrisée plutôt qu'un copier-coller d'une infrastructure à une autre. Trois semaines plus tard, l'application tournait sur un cloud qualifié SecNumCloud, sans qu'aucun utilisateur n'ait eu à changer ses habitudes.
C'est le même principe que sur nos autres missions de reprise ou de migration : le risque ne vient presque jamais de la technologie cible, il vient du temps qu'on ne prend pas pour comprendre ce qui existe avant d'y toucher. Un audit rapide en amont coûte quelques heures. Une bascule improvisée sur une application en production peut coûter bien plus, en interruption comme en confiance perdue auprès des utilisateurs finaux.