Dans l'énergie, la question n'est pas de savoir si le cloud est permis, mais quelle brique on accepte d'y mettre quand l'essentiel de la conduite reste local. SecNumCloud est une qualification que l'ANSSI délivre à des prestataires de services cloud : elle porte sur le service que vous achetez, pas sur votre exploitation. Elle vous aide donc à choisir un hébergeur pour une supervision, une historisation ou un service d'identité — elle ne dit rien de la façon dont un mainteneur se connecte à un poste à trois heures du matin.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. La qualification étant volontaire, son caractère opportun ou nécessaire pour un système donné dépend de votre analyse de risque et des régimes qui vous sont applicables, à confirmer avec vos conseils.
Le cadre, en version courte
Un référentiel d'exigences techniques et organisationnelles, un audit mené par un évaluateur, puis une décision de qualification prononcée par l'ANSSI sur un service précis. Il insiste notamment sur le contrôle d'accès et l'authentification des accès d'administration du prestataire, le cloisonnement, la journalisation, la localisation des données et des opérations, et la protection face à des législations extra-européennes à portée extraterritoriale. Son usage comme critère d'achat est traité dans l'article dédié à SecNumCloud et à l'authentification. Le reste part de vos installations.
Ce que l'on externalise vraiment dans l'énergie
Les projets cloud du secteur portent rarement sur la conduite elle-même, mais sur les couches qui l'entourent et qui pourtant décident d'accès :
- l'historisation et les données de conduite exportées vers une plateforme d'analyse, qui révèlent la topologie du réseau et les régimes de fonctionnement des ouvrages ;
- la GMAO et la gestion des interventions, qui déterminent qui se rend sur quel site et pour y faire quoi ;
- le portail d'accès des prestataires, souvent la première brique réellement externalisée ;
- le service d'identité et de MFA, point de passage de toutes les connexions, y compris celles des équipes d'astreinte ;
- les sauvegardes et les journaux, dont dépend votre capacité à reconstituer un incident.
La dernière mérite une attention particulière. Externaliser les journaux d'accès à un environnement industriel revient à confier à un tiers la preuve dont vous aurez besoin devant un auditeur. La qualification rend cette externalisation défendable ; elle ne dispense pas de vérifier que ces journaux sont récupérables dans un format exploitable.
Le point de bascule : la conduite dépend-elle d'un service distant ?
Dès qu'une fonction hébergée conditionne une ouverture de session sur un poste d'ingénierie ou une console de téléconduite, vous avez créé une dépendance de disponibilité entre un contrat cloud et une capacité d'exploitation. Un service qualifié ne supprime pas cette dépendance : il en réduit le risque de compromission, pas le risque d'indisponibilité.
Deux conséquences pratiques. D'abord, tout dispositif d'authentification externalisé doit avoir un mode dégradé documenté et testé, sans quoi le contournement improvisé deviendra la procédure réelle. Ensuite, ce mode dégradé doit rester exigeant : un secours qui retombe sur un compte générique local annule la démarche. Sur un site isolé sans couverture mobile, les méthodes qui survivent sont celles qui ne supposent aucune réception de message sur le terminal de l'agent. C'est la logique d'un enrôlement hors ligne comme celui de HIAsecure, qui dote l'utilisateur d'une méthode de résolution personnelle ; HIAsecure est engagée dans une démarche de qualification SecNumCloud, aujourd'hui en cours.
| Brique candidate à l'externalisation | Ce que la qualification du prestataire couvre | Ce qui reste sous votre responsabilité | Clause à prévoir au contrat |
|---|---|---|---|
| Service d'identité et de MFA | Hébergement, exploitation, accès d'administration du fournisseur | Politique de méthodes, comptes d'administration client, récupération de compte | Mode dégradé documenté, engagement de restitution des annuaires |
| Historisation et données de conduite | Cloisonnement, localisation, protection des données | Filtrage de ce que vous exportez réellement de la zone industrielle | Interdiction de transfert hors périmètre, notification de sous-traitance |
| Portail d'accès des prestataires | Sécurité de la plateforme | Cycle de vie des comptes fournisseurs, fenêtres d'intervention | Remontée d'information au départ d'un intervenant |
| GMAO et gestion des interventions | Exploitation du service | Cohérence entre habilitation métier et droits techniques | Export périodique des habilitations |
| Collecte des journaux et sauvegardes | Conservation, intégrité, localisation | Ce que vous êtes capable d'exploiter et de produire | Format d'export, délai de restitution, test de restauration |
Astreintes, sites isolés, interconnexions
L'énergie ajoute trois contraintes que le référentiel ne traite pas, parce qu'elles vous appartiennent. L'astreinte impose un parcours rapide : c'est le moment où une salve de notifications finit par être validée par réflexe, comme l'a montré le cas Uber en 2022. Les sites isolés imposent des méthodes fonctionnant sans connectivité côté utilisateur. Les interconnexions avec les gestionnaires de réseau créent des accès croisés dont la traçabilité doit rester lisible de bout en bout. Pour la partie locale de ces accès, voyez NIS2 et l'énergie.
Réversibilité : la clause qui décide vraiment
La réversibilité est le sujet le plus négligé des marchés cloud du secteur, et le plus coûteux. Pour une brique d'authentification, elle tient en quelques questions : récupérez-vous la liste des identités et de leurs habilitations, et dans quel format ? Vos utilisateurs devront-ils tous recommencer un enrôlement ? Les journaux historiques restent-ils exploitables après la sortie ? Une réponse floue transforme une dépendance contractuelle en dépendance opérationnelle.
Par où commencer ce trimestre
- Cartographiez les fonctions hébergées qui conditionnent un accès à la zone industrielle.
- Identifiez celles dont l'indisponibilité empêcherait une intervention, et écrivez le mode dégradé correspondant.
- Vérifiez ce que vous exportez réellement vers vos plateformes d'analyse : la donnée de conduite part souvent plus largement que prévu.
- Confrontez la liste des accès prestataires aux contrats de maintenance actifs.
- Contractualisez la restitution des identités, des habilitations et des journaux avant la signature.
- Testez une bascule : coupez le service d'identité en conditions maîtrisées et observez ce que font les équipes.
FAQ
Peut-on externaliser l'authentification des accès de conduite ?
Cela relève de votre analyse de risque et des régimes applicables, à confirmer avec vos conseils. Le point déterminant n'est pas la qualification du prestataire mais la dépendance de disponibilité créée : si aucune intervention n'est possible sans le service distant, le mode dégradé devient une exigence d'exploitation.
Que se passe-t-il pendant une astreinte si le service distant ne répond pas ?
C'est le scénario à écrire avant de signer. Un secours indisponible se transforme immédiatement en contournement, et le contournement devient la norme. Prévoyez une méthode fonctionnant sans connectivité côté agent, avec une traçabilité équivalente.
La qualification du fournisseur couvre-t-elle les accès de nos intégrateurs ?
Non. Elle porte sur l'hébergement et l'exploitation du service, pas sur le cycle de vie des comptes utilisés par vous ou vos prestataires. Nominativité, fenêtres d'intervention et remontée d'information au départ d'un intervenant relèvent de vos contrats de maintenance.
Faut-il exiger la qualification pour toutes les briques ?
Rarement de manière uniforme. Le tri se fait par conséquence en cas de compromission : une brique qui arbitre une décision d'accès ou qui contient des données de conduite justifie un niveau d'exigence supérieur à une application de gestion.
Aller plus loin : le pilier : authentification cognitive · SecNumCloud comme critère d'achat · dépendance technologique extra-européenne · l'AiTM dans l'énergie