Cloud souverain au Maroc : qui contrôle réellement les domaines, le DNS et les certificats ?

Le Maroc accélère le développement de ses infrastructures numériques critiques, de son cloud et de ses capacités en intelligence artificielle. Mais la souveraineté ne dépend pas uniquement de l’emplacement des serveurs. Elle se joue également dans la maîtrise des noms de domaine, du DNS, des certificats, des comptes administrateurs et des mécanismes de récupération.

Le Maroc vient de franchir une nouvelle étape dans sa stratégie numérique.

Le ministère de la Transition numérique et de la Réforme de l’administration et l’entreprise Vertiv ont signé, le 27 juillet 2026 à Rabat, un mémorandum d’entente portant sur le développement des infrastructures numériques critiques, du cloud computing et de l’intelligence artificielle.

L’accord prévoit notamment des échanges d’expertise, des études techniques et l’exploration de solutions liées aux centres de données, à l’alimentation électrique, au refroidissement et aux infrastructures nécessaires au cloud et au calcul intensif.

Cette coopération s’inscrit dans la stratégie Maroc Digital 2030, dans la feuille de route AI Made in Morocco et dans le projet de développement d’un centre de données souverain de 50 MW à Rabat.

L’ambition est claire : renforcer les capacités nationales, soutenir la numérisation de l’administration, héberger des services publics numériques, développer l’intelligence artificielle et positionner le Royaume comme un hub numérique régional.

Cette orientation est stratégique.

Mais elle conduit à une question plus profonde :

où se trouve réellement le contrôle d’une infrastructure numérique lorsque les serveurs sont installés au Maroc, mais que ses domaines, son DNS, ses certificats ou ses accès administrateurs dépendent d’acteurs extérieurs ?

Héberger localement ne signifie pas tout contrôler

La souveraineté numérique est encore trop souvent réduite à la localisation physique des données.

Un centre de données situé sur le territoire national apporte des garanties importantes :

• une meilleure maîtrise de l’hébergement,
• une réduction de certaines dépendances internationales,
• une plus grande proximité avec les utilisateurs,
• une capacité d’intervention locale,
• une meilleure prise en compte du cadre juridique marocain,
• un développement des compétences et de l’écosystème national.

Ces éléments sont indispensables. Ils ne suffisent pourtant pas à répondre à toutes les dimensions de la souveraineté.

Une infrastructure numérique repose sur plusieurs couches.

La première est physique : bâtiments, énergie, refroidissement, équipements et connectivité.

La deuxième est logicielle : systèmes d’exploitation, virtualisation, stockage, plateformes cloud et applications.

La troisième est identitaire : domaines, sous-domaines, DNS, certificats, clés cryptographiques, API et comptes administrateurs.

La quatrième est juridique et contractuelle : contrats, juridictions applicables, sous-traitants, licences, accès aux données et conditions de sortie.

La cinquième est opérationnelle : compétences humaines, supervision, réponse aux incidents, continuité et récupération.

Une organisation peut contrôler les deux premières couches tout en restant dépendante sur les trois suivantes.

Elle peut posséder ses serveurs, mais ne pas maîtriser le compte qui administre son domaine principal. Elle peut héberger ses applications à Rabat, mais dépendre d’un fournisseur DNS étranger sans solution de secours. Elle peut conserver ses données au Maroc, mais utiliser des certificats, des outils d’administration ou des services d’authentification dont la continuité dépend d’une autre juridiction.

La souveraineté numérique ne se mesure pas uniquement à l’adresse du serveur. Elle se mesure à l’endroit où se trouvent les leviers de décision, d’administration et de récupération.

Le domaine est la porte d’entrée de l’infrastructure

Un service numérique ne commence pas dans le centre de données.

Pour l’utilisateur, il commence presque toujours par un nom.

Ce nom peut être celui d’un portail administratif, d’une banque, d’un opérateur télécom, d’un ministère, d’une application, d’une interface de programmation ou d’un service d’intelligence artificielle.

Le nom de domaine constitue le point de rencontre entre l’organisation et son infrastructure.

Il permet notamment de diriger les utilisateurs vers les serveurs, d’organiser la messagerie, de créer des sous-domaines techniques, d’identifier les API et de délivrer des certificats de sécurité.

Lorsqu’un domaine est détourné, mal renouvelé, suspendu ou placé sous le contrôle d’un tiers, les serveurs peuvent continuer à fonctionner parfaitement. Le service devient pourtant inaccessible ou peut être redirigé vers une infrastructure frauduleuse.

La maîtrise du domaine principal suppose donc de connaître précisément :

• l’entité juridiquement titulaire du domaine,
• le registrar chargé de son administration,
• les personnes disposant des accès,
• les mécanismes d’authentification utilisés,
• les procédures de renouvellement,
• les dispositifs de verrouillage,
• les contacts de récupération d’urgence,
• la juridiction applicable à la relation contractuelle.

Un domaine stratégique enregistré au nom d’un collaborateur, d’une agence ou d’un prestataire constitue une faiblesse de gouvernance.

Un compte protégé par un simple mot de passe constitue une faiblesse de sécurité.

Une procédure de récupération qui dépend de l’adresse électronique associée au domaine concerné constitue une faiblesse de résilience.

Pour les services publics, les infrastructures critiques, les banques et les grandes entreprises, le domaine ne doit plus être considéré comme une dépense administrative. Il doit être traité comme un actif critique.

Le DNS décide de la direction prise par les utilisateurs

Le Domain Name System traduit les noms compréhensibles par les humains en informations utilisables par les machines.

Lorsqu’un internaute saisit l’adresse d’un service marocain, le DNS lui indique vers quelle infrastructure il doit être dirigé.

Cette fonction paraît simple. Elle conditionne pourtant l’accès aux sites Internet, aux messageries, aux API, aux plateformes cloud et à une grande partie des mécanismes d’authentification.

Une infrastructure souveraine peut donc devenir indisponible si son DNS ne répond plus.

Elle peut être détournée si ses enregistrements sont modifiés frauduleusement.

Elle peut dépendre d’un acteur unique si tous ses serveurs DNS, ses comptes et ses interfaces d’administration sont concentrés chez le même fournisseur.

La résilience exige notamment :

• plusieurs serveurs DNS faisant autorité,
• une véritable diversité technique et opérationnelle,
• une séparation entre DNS autoritatif et DNS récursif,
• une surveillance permanente des modifications,
• des accès administratifs fortement sécurisés,
• une procédure documentée de restauration des zones,
• l’utilisation de DNSSEC lorsque les conditions opérationnelles sont réunies.

DNSSEC permet de vérifier l’origine et l’intégrité des informations DNS grâce à une chaîne de confiance cryptographique. Il ne chiffre pas les requêtes et ne résout pas tous les risques, mais il limite la possibilité de présenter aux utilisateurs des réponses DNS falsifiées.

Des référentiels comme KINDNS et des outils ouverts comme Zonemaster permettent déjà d’évaluer une partie de ces bonnes pratiques : qualité de la délégation, disponibilité des serveurs, cohérence des réponses, diversité des adresses et fonctionnement de DNSSEC.

Le Maroc dispose également, à travers la Direction générale de la sécurité des systèmes d’information, de recommandations relatives à la configuration et à la sécurisation des protocoles DNS et BGP.

La question n’est donc plus de savoir si le DNS est important. Elle est de déterminer comment intégrer sa gouvernance dans la stratégie nationale des infrastructures critiques.

Certificats, API et identités machines

À mesure que l’administration, les banques, les opérateurs et les entreprises interconnectent leurs systèmes, une part croissante des échanges ne s’effectue plus directement entre des personnes.

Elle s’effectue entre des machines.

Une application appelle une API. Un serveur vérifie l’identité d’un autre serveur. Une plateforme cloud communique avec un service de paiement. Un agent d’intelligence artificielle accède à une base documentaire ou déclenche une action automatisée.

Ces échanges reposent sur des identités techniques :

• noms d’hôtes,
• sous-domaines,
• certificats TLS,
• clés cryptographiques,
• jetons d’accès,
• comptes de service,
• secrets applicatifs.

Le certificat permet notamment à un service de présenter une identité associée à un nom de domaine et d’établir une communication chiffrée.

Mais cette confiance dépend d’une chaîne opérationnelle complète.

Qui peut demander un certificat ? Qui contrôle la validation du domaine ? Où se trouvent les clés privées ? Qui peut les renouveler ou les révoquer ? Que se passe-t-il lorsqu’un certificat expire ? Existe-t-il un inventaire centralisé des certificats et des identités machines ?

Une administration peut disposer d’un centre de données sécurisé tout en laissant des centaines de certificats, de sous-domaines et de comptes de service échapper à toute gouvernance centralisée.

Avec la progression du cloud, de l’IA et de l’automatisation, cette dette identitaire deviendra de plus en plus dangereuse.

Les dépendances juridictionnelles et contractuelles

Le recours à un fournisseur international ne signifie pas nécessairement une perte de souveraineté.

La souveraineté numérique ne consiste pas à exiger que chaque composant soit marocain. Une telle approche serait irréaliste et pourrait même limiter l’accès aux meilleures technologies.

Elle consiste à conserver la capacité de choisir, d’auditer, de négocier, de protéger, de remplacer et de poursuivre l’activité.

La dépendance devient problématique lorsque l’organisation ignore :

• dans quel pays le contrat est exécuté,
• quelle juridiction peut imposer une décision au fournisseur,
• quels sous-traitants interviennent dans le service,
• où sont conservées les sauvegardes et les métadonnées,
• qui peut accéder aux consoles d’administration,
• quelles conditions permettent une suspension,
• comment les données et configurations peuvent être récupérées.

La DGSSI rappelle depuis plusieurs années que l’externalisation des systèmes d’information présente des avantages, mais également des risques qu’il convient d’évaluer, notamment lorsque les spécifications contractuelles sont incomplètes.

Cette vigilance doit désormais être étendue à l’ensemble des actifs de nommage.

Un contrat cloud peut prévoir la restitution des données sans organiser la récupération des zones DNS, des certificats, des journaux, des clés, des configurations d’API et des identités techniques.

L’organisation récupère alors ses fichiers, mais pas nécessairement la capacité de remettre rapidement son service en fonctionnement.

La réversibilité doit être testée, pas seulement promise

La réversibilité est souvent traitée comme une clause juridique placée à la fin d’un contrat.

Elle devrait être conçue comme une capacité opérationnelle.

Une organisation réellement souveraine doit pouvoir répondre à plusieurs scénarios :

• la disparition soudaine d’un fournisseur,
• le blocage d’un compte administrateur,
• la compromission du registrar,
• une panne prolongée du fournisseur DNS,
• l’expiration ou la révocation d’un certificat critique,
• une modification réglementaire ou juridictionnelle,
• la nécessité de migrer rapidement vers une autre infrastructure.

Pour cela, il ne suffit pas de posséder des sauvegardes.

Il faut conserver des copies exploitables des zones DNS, documenter les dépendances entre domaines et applications, séparer les rôles administratifs, tester les procédures de récupération et maintenir des contacts d’urgence auprès des registrars, registres, fournisseurs DNS et autorités de certification.

La réversibilité doit faire l’objet d’exercices réguliers.

Une procédure qui n’a jamais été testée reste une hypothèse.

Un cloud n’est véritablement souverain que lorsque l’organisation peut rester identifiable, accessible et administrable même si un fournisseur ou un compte critique devient indisponible.