Migration Cloud au Maroc : Guide Complet pour PME 2026

Un DSI d'une entreprise de distribution basée à Salé nous a contactés en début d'année avec une situation fréquente : son serveur principal avait sept ans, son contrat de maintenance venait d'expirer, et son fournisseur lui avait remis un devis de remplacement à 120 000 MAD. "Est-ce qu'on migre vers le cloud ou on rachète un serveur ?" La réponse ne s'improvise pas. Une migration cloud mal planifiée peut coûter deux à trois fois son budget initial. Un rachat de matériel sans analyse peut vous placer dans la même situation dans cinq ans.

Ce guide traite la migration cloud au Maroc comme ce qu'elle est : un projet de transformation avec des phases précises, des coûts chiffrés en dirhams, des contraintes réglementaires spécifiques au territoire marocain, et des choix techniques qui dépendent de votre secteur, de vos applications, et de votre connectivité internet. Pas de formules génériques. Des décisions documentées.

Pourquoi migrer vers le cloud en 2026 : le contexte marocain

La pression vers le cloud est réelle au Maroc, mais elle vient de plusieurs directions en même temps. La comprendre permet d'éviter de se faire vendre une migration cloud pour de mauvaises raisons.

Les facteurs qui accélèrent la migration

Le vieillissement du parc on-premise. Les investissements en serveurs réalisés entre 2016 et 2020 arrivent en fin de vie en 2025-2026. Le remplacement matériel est l'occasion naturelle de poser la question : racheter ou migrer ? Pour beaucoup de PME marocaines, c'est la première fois que la question est posée sérieusement.

La pénurie de profils IT qualifiés. La stratégie Maroc Digital 2030 reconnaît un déficit structurel d'ingénieurs numériques : le Maroc formait environ 14 000 professionnels par an en 2022, bien loin des besoins du marché. Un serveur on-premise nécessite quelqu'un pour le gérer. Si cette personne quitte l'entreprise ou n'existe pas, le cloud devient une option sérieuse.

La généralisation du travail multi-sites. Trois bureaux, des commerciaux en déplacement, un directeur basé à Rabat et des opérations à Casablanca : l'infrastructure on-premise centralisée supporte mal ces configurations. Une PME qui gère aujourd'hui quatre sites physiques gère quatre fois les problèmes d'accès VPN, de synchronisation des données et de latence.

La croissance du marché cloud africain. Le marché cloud en Afrique devrait atteindre 14,7 milliards de dollars d'ici 2028 avec un taux de croissance annuel de 21 %. Le Maroc en capte une part croissante, avec une offre locale qui s'est densifiée : N+ONE Datacenters à Casablanca, Maroc Telecom Cloud, inwi Business, et les partenaires certifiés des hyperscalers internationaux.

Le décret 2-24-921 et la qualification DGSSI. Publié au Bulletin Officiel le 20 février 2025, ce décret encadre l'usage du cloud par les entités publiques et les infrastructures d'importance vitale (IIV). Son référentiel de qualification a été publié en août 2025. Pour les entreprises concernées, il crée une obligation de recourir à des prestataires qualifiés par la DGSSI. Pour les autres, il signale la direction que prend la politique numérique marocaine.

Ce qui freine encore la migration au Maroc

Trois obstacles réels ralentissent les projets de migration cloud dans les PME marocaines.

La qualité de la connectivité dans certaines zones. Les grandes villes (Casablanca, Rabat, Tanger, Marrakech) disposent de connexions fibre professionnelles avec SLA fiables. Dans les zones industrielles périphériques ou dans certaines villes de second rang, la qualité des connexions reste variable. Un ERP en mode cloud avec une connexion internet défaillante, c'est une entreprise à l'arrêt.

La latence des hyperscalers. Aucun des trois grands hyperscalers (AWS, Azure, Google Cloud) n'opère de datacenter sur le sol marocain en 2026. Azure France Central (Paris) affiche une latence de 28 à 40 ms depuis Casablanca. C'est imperceptible pour de la messagerie ou un CRM. Pour certains ERP avec des requêtes base de données très fréquentes, cela peut dégrader l'expérience utilisateur.

Les coûts cloud mal anticipés. La facturation à l'usage du cloud surprend régulièrement les équipes qui gèrent des environnements cloud sans formation spécifique. Des machines virtuelles allumées inutilement, des volumes de stockage non nettoyés, des transferts de données sortants facturés : la facture peut facilement dépasser les projections initiales si personne ne pilote l'optimisation.

Les 6 stratégies de migration cloud (les 6R)

Avant de parler de planning ou de coûts, il faut choisir la bonne stratégie de migration pour chaque application. Le cadre des "6R" est la méthode standard utilisée par les équipes d'architecture cloud. Il s'applique application par application, pas à l'entreprise en bloc.

Vue d'ensemble des 6R

Rehost : le lift & shift

Le rehost migre l'application sur le cloud exactement comme elle tourne sur le serveur actuel. Vous prenez votre serveur Windows 2019 avec son instance SQL Server et son application métier, et vous en faites une machine virtuelle Azure ou AWS.

Avantage : c'est la stratégie la plus rapide. Une PME peut migrer un serveur en quelques jours. Inconvénient : vous n'optimisez pas l'application pour le cloud, donc vous payez souvent plus qu'avec une VM taillée pour votre charge réelle. Et vous transportez éventuellement les dettes techniques de l'ancienne infrastructure.

Quand l'utiliser au Maroc : pour les applications internes sans dépendance forte à la latence, où l'objectif est de se débarrasser d'un serveur en fin de vie rapidement. Souvent utilisé comme première étape avant une optimisation ultérieure.

Replatform : la modernisation légère

Le replatform modifie la couche infrastructure sans réécrire l'application. Exemple concret : votre ERP tourne sur SQL Server 2014. Vous migrez vers Azure SQL Database (service managé), ce qui vous libère de la gestion des mises à jour SQL et vous donne de la scalabilité automatique, sans toucher une ligne de code de l'application.

Quand l'utiliser au Maroc : pour des applications bien maintenues avec une base de données vieillissante, ou pour des applications qui tournent sur des OS en fin de support (Windows Server 2012, par exemple). C'est le bon compromis entre rapidité et bénéfice cloud.

Refactor : la réécriture cloud-native

Le refactoring réécrit tout ou partie de l'application pour tirer parti des services cloud-native : conteneurs, fonctions serverless, bases de données managées, microservices. C'est l'investissement le plus lourd, mais il produit les meilleures performances et les coûts d'exploitation les plus bas à long terme.

Quand l'utiliser au Maroc : pour des applications développées sur mesure qui sont des actifs stratégiques de l'entreprise, où les performances et l'évolutivité sont critiques. Rarement pertinent pour les PME de moins de 100 employés, sauf si l'application est le coeur de leur modèle commercial.

Repurchase : le passage au SaaS

Le repurchase remplace une application hébergée en interne par un SaaS équivalent. Vous avez un serveur Exchange pour votre messagerie ? Vous migrez vers Microsoft 365. Vous avez un CRM développé sur mesure en 2012 ? Vous le remplacez par Zoho ou HubSpot.

Quand l'utiliser au Maroc : pour les applications non différenciatrices (messagerie, bureautique, CRM standard, paie). Le SaaS vous libère de la gestion de l'infrastructure et des mises à jour. Microsoft 365 est déjà utilisé par environ 70 % des entreprises marocaines, ce qui montre que cette stratégie est déjà en cours sans être formalisée.

Retire : le décommissionnement

L'inventaire révèle souvent des applications que personne n'utilise plus mais qui tournent sur un serveur, consomment des ressources et représentent une surface d'attaque. Les retirer simplifie l'architecture, réduit les coûts et améliore la sécurité.

Quand l'utiliser : après l'inventaire initial, systématiquement. En pratique, 10 à 20 % des applications identifiées dans un inventaire de PME marocaine peuvent être retirées sans impact opérationnel.

Retain : la conservation on-premise

Certaines applications ne doivent pas migrer, soit pour des raisons techniques (latence critique, volume de données trop important pour les coûts d'egress), soit pour des raisons réglementaires (données classifiées imposant une résidence sur territoire marocain), soit parce que la migration n'est pas rentable.

Quand l'utiliser : pour les applications industrielles avec des contraintes de latence en dessous de 5 ms, pour les applications soumises au décret 2-24-921 niveau 2 pour les entités concernées, et pour les applications qui ont moins de 2 ans à vivre avant d'être remplacées.

Le processus de migration cloud étape par étape

Une migration cloud structurée suit cinq phases. Chacune a des livrables précis. Sauter une phase, c'est s'exposer aux problèmes classiques : découverte tardive d'incompatibilités, coûts dépassés, rollback coûteux.

Phase 1 : Inventaire et classification (2 à 4 semaines)

L'inventaire est la phase la moins glamour et la plus critique. Son objectif : savoir exactement ce que vous avez avant de décider ce que vous migrez.

L'inventaire couvre :

• Serveurs physiques et virtuels (OS, version, date de fin de support)
• Applications et leur version (liste des applications, éditeur, date de dernière mise à jour)
• Volumes de données (total stocké, taux de croissance mensuel, fréquence d'accès)
• Dépendances entre applications (quelle application communique avec quelle autre, sur quel port, avec quel protocole)
• Contraintes réglementaires par application (données personnelles loi 09-08, données sensibles décret 2-24-921, données financières DGI)
• Qualité de la connectivité internet actuelle (mesures réelles de bande passante et de disponibilité, pas les débits théoriques du contrat)

Sans cet inventaire, vous ne pouvez pas choisir la bonne stratégie 6R pour chaque application, ni établir un plan de migration réaliste.

Livrable attendu : un tableau d'inventaire avec une ligne par application, incluant la stratégie 6R recommandée, les dépendances identifiées, et le niveau de priorité de migration.

Phase 2 : Architecture cible et sélection du fournisseur (1 à 2 semaines)

Sur la base de l'inventaire, cette phase définit l'architecture cloud cible : quelles applications migrent chez quel fournisseur, selon quel modèle (IaaS, PaaS, SaaS), avec quelle redondance et quelle sécurité.

La sélection du fournisseur cloud suit des critères précis pour le marché marocain :

Pour une PME marocaine qui utilise déjà Microsoft 365 et qui n'est pas soumise au décret 2-24-921 (pas une administration ou une IIV), Azure est généralement le choix le plus cohérent. L'intégration native avec Microsoft 365, la présence d'un bureau régional Microsoft à Casablanca, et l'écosystème de partenaires locaux certifiés facilitent le déploiement et le support.

Pour les entités soumises à une obligation de résidence des données sur le territoire marocain, N+ONE Datacenters à Casablanca (Tier III, ISO 27001) est aujourd'hui l'option la plus solide, en attendant que son processus de qualification DGSSI aboutisse.

Livrable attendu : un document d'architecture cible avec les schémas réseau, le plan d'adressage IP, les politiques de sécurité, et les spécifications des services cloud retenus.

Phase 3 : Préparation et migration par vagues (4 à 16 semaines selon la taille)

La migration ne se fait jamais en une seule fois. Les applications sont regroupées en "vagues" de migration, de la moins critique à la plus critique.

Vague 1 - Applications non critiques (semaines 1-4) : Messagerie interne de test, outils de collaboration secondaires, sites web de présentation. Ces applications peuvent être migrées sans impact si quelque chose se passe mal. Elles servent de validation de l'approche technique.

Vague 2 - Applications de support (semaines 3-8) : CRM, outil RH, outil de gestion de projet, stockage de fichiers (si passage à SharePoint/OneDrive). Ces applications ont de l'importance mais une interruption courte est tolérable.

Vague 3 - Applications critiques (semaines 8-16) : ERP, base de données comptable, applications de production. Chaque migration de cette vague nécessite un plan de rollback documenté, une fenêtre de migration en dehors des heures ouvrées, et des tests de validation complets avant de basculer le trafic de production.

Pour chaque application critique, la procédure standard inclut :

1. Migration en environnement de test (copie complète dans le cloud)
2. Tests fonctionnels avec les utilisateurs-clés pendant 1 à 2 semaines
3. Basculement en production pendant une fenêtre de maintenance (week-end ou nuit)
4. Rollback maintenu pendant 2 semaines post-migration (l'ancien serveur reste allumé)
5. Décommissionnement de l'ancien serveur après validation de la stabilité

Livrable attendu : des comptes-rendus de migration pour chaque vague, avec les tests effectués, les incidents rencontrés, et la validation par les utilisateurs-clés.

Phase 4 : Sécurisation de l'environnement cloud (parallèle aux vagues)

La sécurité d'un environnement cloud ne s'improvise pas après la migration. Elle se configure pendant la migration. Les erreurs de configuration sont la première cause d'incidents de sécurité dans le cloud, devant les attaques externes.

Les points à configurer systématiquement :

• Authentification multifacteur (MFA) obligatoire pour tous les accès cloud et administrateurs
• Politiques de réseau virtuel (VNet/VPC) pour isoler les ressources entre elles
• Chiffrement des données au repos et en transit
• Journalisation centralisée (Azure Monitor, CloudWatch, ou équivalent)
• Gestion des identités et des droits d'accès (principe du moindre privilège)
• Sauvegardes automatisées avec tests de restauration documentés
• Plan de réponse aux incidents

Notre équipe cybersécurité intervient en parallèle des projets de migration pour s'assurer que ces configurations sont en place dès le premier jour de production cloud. Un environnement cloud non sécurisé est plus exposé qu'un serveur on-premise bien maintenu, parce que sa surface d'attaque est accessible depuis internet 24h/24.

Phase 5 : Optimisation des coûts et formation (2 à 4 semaines post-migration)

La migration vers le cloud est terminée quand le basculement est fait. L'optimisation, elle, commence ensuite et continue en permanence.

Les postes d'optimisation immédiats après migration :

• Rightsizing des VM : les machines virtuelles surdimensionnées dans le cloud coûtent cher. Un audit des métriques d'utilisation CPU et mémoire sur les 30 premiers jours permet souvent de réduire la taille (et le coût) de 20 à 40 %.
• Réservations d'instances : pour les charges de travail stables, les instances réservées 1 an ou 3 ans coûtent 30 à 40 % moins cher que les instances à la demande.
• Nettoyage du stockage : les snapshots oubliés, les disques non attachés et les données de logs non archivées génèrent des coûts invisibles qui s'accumulent.
• Formation des équipes : un technicien qui ne connaît pas Azure Monitor ou AWS Cost Explorer ne peut pas piloter les coûts. La formation cloud est un investissement qui se rentabilise rapidement.

Livrable attendu : un rapport d'optimisation avec les actions réalisées, les économies générées, et un tableau de bord de suivi des coûts cloud mensuel.

Coûts réels d'une migration cloud au Maroc en 2026

Le budget d'une migration cloud se décompose en deux parties distinctes : les coûts ponctuels de migration (accompagnement, outils, formation) et les coûts récurrents d'exploitation cloud (abonnements, licences, services managés).

Budget de migration par profil de PME

Ces budgets couvrent l'inventaire initial, l'architecture cible, l'exécution de la migration, les tests de validation, et la formation des équipes. Ils excluent les coûts récurrents cloud.

Pour référence, le taux journalier des architectes cloud certifiés (Azure Architect, AWS Solutions Architect) au Maroc se situe entre 1 200 et 2 500 MAD par jour selon l'expérience et la complexité du projet. Pour comparer le coût d'exploitation cloud avec une infogérance complète post-migration, notre calculateur de coût d'infogérance chiffre les deux scénarios en 30 secondes.

Coûts cloud récurrents : exemples chiffrés en MAD

Voici des exemples réalistes de coûts cloud mensuels pour des configurations courantes de PME marocaines, calculés sur la base des tarifs Azure (en EUR converti en MAD à 11,0 MAD/EUR) :

Configuration A - PME de 20 utilisateurs (messagerie + stockage + 1 VM ERP) :

Configuration B - PME de 50 utilisateurs (ERP + CRM + messagerie + 2 serveurs) :

Configuration C - Infogérance cloud managée (PME 50 utilisateurs, tout inclus) : Si vous externalisez la gestion de cet environnement Azure à un prestataire d'infogérance, ajoutez entre 4 000 et 8 000 MAD/mois selon le niveau de service et les SLA.

Économies à attendre sur 3 ans

Des études de marché sur les migrations Azure de PME comparables montrent des économies de 20 à 40 % sur les coûts IT totaux sur 3 ans, une fois les coûts de migration amortis. Ces économies viennent principalement de :

• La fin des investissements matériels (serveurs, UPS, climatisation)
• La réduction des coûts d'administration IT (maintenance moins lourde)
• La réduction des interruptions de service et de leur coût opérationnel
• L'optimisation progressive des coûts cloud (rightsizing, réservations)

Ces économies ne se matérialisent que si la migration est bien planifiée et si l'environnement cloud est activement piloté. Une migration mal gérée peut au contraire augmenter les coûts.

Conformité et souveraineté des données au Maroc

La question réglementaire est souvent le premier frein cité par les dirigeants marocains sur la migration cloud. Il faut distinguer les obligations réelles des arguments commerciaux.

Le décret 2-24-921 : qui est vraiment concerné ?

Le décret 2-24-921 du 22 octobre 2024 (publié au BO le 20 février 2025) encadre le recours aux prestataires cloud par les entités publiques et les infrastructures d'importance vitale (IIV). Il impose deux niveaux de qualification DGSSI pour les prestataires cloud :

Niveau 1 : prestataire constitué au Maroc, avec tous les systèmes opérationnels et commerciaux sur le territoire national.

Niveau 2 : majorité du capital détenue par des Marocains, traitement et stockage sur le sol marocain, gestion et supervision depuis le Maroc. Ce niveau est requis pour les données "sensibles" au sens de la loi 05-20.

Pour une PME du secteur privé hors IIV : ce décret ne s'applique pas directement. Vous pouvez héberger vos données sur Azure Paris sans contrevenir à ce texte. Les prestataires qui utilisent le décret 2-24-921 comme argument commercial pour vendre du cloud local à des PME non concernées font de la vente forcée.

Pour une entreprise des secteurs IIV (énergie, eau, télécoms, finance, santé, transport, administration) : le décret s'applique. Vous devez utiliser un prestataire cloud qualifié DGSSI. La période de transition est de 24 mois à compter de la publication du BO, soit jusqu'à février 2027. Nos services GRC incluent l'analyse de votre qualification au regard de ce décret et l'accompagnement de mise en conformité.

La loi 09-08 et les transferts de données personnelles

La loi 09-08 sur la protection des données personnelles s'applique à toute entreprise marocaine qui traite des données de personnes physiques - ce qui inclut toutes les PME avec des employés et des clients personnes physiques.

Son article 43 encadre les transferts de données personnelles vers des pays tiers. Pour héberger des données personnelles (fichier clients, données RH, données de paie) sur Azure France Central ou AWS Paris, deux options :

• Le pays destinataire offre un niveau de protection adéquat (l'Union Européenne est reconnue comme telle par la CNDP)
• Ou vous obtenez l'autorisation préalable de la CNDP

En pratique, la grande majorité des PME marocaines hébergent leurs données sur des infrastructures cloud européennes sans déclaration formelle à la CNDP. C'est une situation de non-conformité latente. Elle ne fait pas l'objet de sanctions systématiques à ce jour, mais elle peut exposer l'entreprise en cas d'incident ou de litige. Un contrat de sous-traitance cloud incluant des clauses de protection des données conformes à la loi 09-08 est la protection minimale.

Données de paie et obligations CNSS/CIMR

Les données de paie (salaires, cotisations CNSS, AMO, CIMR, déclarations DGI) sont particulièrement sensibles. Elles impliquent à la fois la loi 09-08 (données personnelles) et les obligations fiscales et sociales marocaines. Si votre ERP ou logiciel de paie migre vers le cloud, vérifiez que les rapports CNSS, les déclarations de TVA, et les états de paie DGI continuent à être générés conformément aux formats en vigueur. Un changement de version ou de configuration lors de la migration peut interrompre ces flux.

Erreurs fréquentes lors d'une migration cloud au Maroc

Ces erreurs reviennent régulièrement dans les projets que nous observons ou reprenons après une migration chaotique.

Erreur 1 : Migrer sans inventaire préalable

La pire erreur, et la plus fréquente. Des équipes qui migrent leur serveur principal dans Azure sans avoir cartographié les dépendances découvrent en production que l'application ERP communique sur un port non ouvert dans le réseau virtuel Azure, que le logiciel de paie pointe sur l'IP locale du serveur source, ou que la base de données utilise un collation SQL incompatible avec Azure SQL. Ces problèmes auraient été identifiés en deux heures d'inventaire. Ils prennent plusieurs jours à résoudre en urgence.

Erreur 2 : Sous-dimensionner la connexion internet

Une PME qui migre son ERP vers Azure avec une connexion ADSL professionnelle de 10 Mbps ne peut pas faire travailler 30 utilisateurs simultanément sur cet ERP. La bande passante disponible par utilisateur descend à 0,3 Mbps en charge, ce qui rend l'application inutilisable. La migration cloud doit être accompagnée d'une montée en gamme de la connexion internet vers de la fibre professionnelle avec un SLA garantissant la disponibilité et le débit.

Erreur 3 : Migrer sans plan de rollback

Un basculement en production qui se passe mal, c'est 15 à 30 % des migrations cloud. Pas forcément un échec total, mais des problèmes découverts en production qui nécessitent un retour arrière temporaire. Si l'ancien serveur a été éteint ou supprimé dès le basculement, le rollback est impossible ou très coûteux. Règle de base : l'ancien serveur reste opérationnel pendant au moins deux semaines après le basculement en production.

Erreur 4 : Ignorer la formation des équipes

Un technicien IT qui connaît parfaitement Windows Server et n'a jamais administré Azure va passer du temps à comprendre les interfaces, à chercher les équivalents des outils qu'il connaît, et à faire des erreurs de configuration. Le budget formation (Azure Administrator, Azure Security Engineer, ou des sessions pratiques avec le prestataire de migration) n'est pas optionnel. Il conditionne la qualité opérationnelle de l'environnement cloud dans la durée.

Erreur 5 : Négliger le pilotage des coûts cloud

Le cloud facture à l'usage. Contrairement à un serveur on-premise dont le coût est connu d'avance, la facture cloud varie selon ce que vous consommez réellement. Des machines virtuelles inutilement allumées, un volume de stockage qui grossit sans surveillance, des snapshots accumulés depuis la migration : en six mois, une PME peut facilement se retrouver avec une facture cloud 40 à 60 % plus haute que les estimations initiales. L'installation d'Azure Cost Management dès le premier jour de production, avec des alertes sur les seuils de dépense, n'est pas optionnelle.

Erreur 6 : Traiter la sécurité comme une étape ultérieure

"On sécurisera après." C'est la phrase la plus coûteuse de la migration cloud. Un environnement Azure ou AWS ouvert sur internet sans politiques de réseau, sans MFA, sans journalisation, est compromis en quelques heures. Les attaques automatisées scannent en permanence les plages d'adresses des hyperscalers à la recherche de ressources mal configurées. La sécurisation doit être la première tâche dans le portail cloud, avant même de déployer la première machine virtuelle.

Choisir son fournisseur cloud au Maroc : comparatif détaillé

Le choix du fournisseur cloud dépend de quatre facteurs : les contraintes de résidence des données, l'intégration avec vos outils existants, la qualité du support local, et les coûts.

Azure vs AWS pour les PME marocaines

Pour les PME qui utilisent déjà Microsoft 365 (et c'est la majorité des entreprises marocaines formalisées), Azure est l'extension logique. La même identité Azure Active Directory gère à la fois Microsoft 365 et les ressources cloud, ce qui simplifie l'administration et renforce la sécurité.

Les fournisseurs locaux : quand les choisir

N+ONE Datacenters (Casablanca, Tier III, ISO 27001) est la meilleure option locale en 2026 pour les entreprises qui ont une obligation contractuelle ou réglementaire d'hébergement sur le territoire marocain. Son catalogue IaaS couvre les besoins courants (VM, stockage, réseau, sauvegardes), mais il n'a pas l'étendue d'Azure ou AWS pour les services avancés (intelligence artificielle, serverless, services de données managés).

Maroc Telecom Cloud et inwi Business proposent des offres packagées plus simples, adaptées aux PME qui cherchent un hébergement basique avec facturation en dirhams et support en arabe et français, mais avec des capacités techniques plus limitées.

Notre offre de services cloud hybride couvre les déploiements sur Azure, les fournisseurs locaux, et les architectures mixtes selon vos contraintes réglementaires et opérationnelles.

L'approche RMG Solutions

Basée à Hay Riad, Rabat, notre équipe infrastructure accompagne des PME marocaines de 15 à 200 employés dans leurs projets de migration cloud depuis plusieurs années, principalement dans les secteurs de la distribution, de l'industrie manufacturière, du BTP, des services professionnels et de l'import-export.

Notre méthode commence toujours par un inventaire technique de l'existant avant de recommander quoi que ce soit. Nous produisons pour chaque client un tableau d'inventaire applicatif avec la stratégie 6R recommandée par application, les dépendances identifiées, les contraintes réglementaires applicables (loi 09-08, décret 2-24-921, obligations DGI/CNSS), et un chiffrage de la migration par vague.

Nous n'avons pas de préférence commerciale entre Azure, AWS, et les fournisseurs locaux. Notre recommandation dépend de votre secteur, de vos outils existants, de vos contraintes de résidence des données, et de votre budget. Pour une PME de distribution de 40 personnes sur Microsoft 365, Azure est presque toujours le bon choix. Pour un établissement de santé soumis à des contraintes de données, nous recommandons un hébergeur local qualifié.

RMG Solutions déploie également nos services managés pour assurer la supervision et l'optimisation continues de votre environnement cloud après migration. Cela inclut le pilotage des coûts, les mises à jour de sécurité, les sauvegardes, et le reporting mensuel.

Pour une évaluation gratuite de votre situation - inventaire rapide, estimation de budget de migration, et recommandation de stratégie - laissez vos coordonnées ci-dessus ou contactez-nous directement.

Questions Fréquentes

Combien de temps dure une migration cloud pour une PME marocaine de 30 employés ?

Pour une PME de 30 employés avec un ERP, une messagerie, et un stockage de fichiers à migrer, la durée réaliste est de 8 à 14 semaines. La phase d'inventaire prend 2 à 3 semaines, la migration des applications non critiques (messagerie vers Microsoft 365, fichiers vers SharePoint) prend 2 à 4 semaines, et la migration de l'ERP avec tests et validation prend 4 à 6 semaines supplémentaires. Des délais plus courts sont possibles si le parc applicatif est simple et les dépendances limitées, mais accélérer la migration des applications critiques sans tests suffisants est une prise de risque qui coûte cher.

Est-ce que le décret 2-24-921 m'oblige à héberger mes données au Maroc ?

Non, sauf si vous êtes une administration publique, un établissement public, ou un opérateur d'infrastructure d'importance vitale au sens de la loi 05-20 (énergie, eau, télécoms, finance, santé, transport). Pour une PME du secteur privé en dehors de ces secteurs, le décret 2-24-921 ne s'applique pas directement. Vous pouvez héberger vos données sur Azure Paris ou AWS Paris. La loi 09-08 impose des garanties sur le transfert de données personnelles vers des pays tiers, mais l'Union Européenne est reconnue comme offrant un niveau de protection adéquat par la CNDP.

Quelle est la différence entre un rehost et un replatform ?

Un rehost (ou "lift & shift") migre l'application sans aucune modification dans le cloud. Vous prenez votre serveur Windows avec ses applications exactement telles qu'elles sont et vous en faites une VM Azure. Un replatform modifie la couche infrastructure sans réécrire l'application. Par exemple, vous migrez votre base de données SQL Server vers Azure SQL Database (service managé), ce qui vous libère de la gestion des mises à jour SQL et vous donne de la scalabilité automatique, sans toucher une ligne de code de votre application. Le replatform demande plus de travail à la migration mais réduit les coûts d'exploitation à long terme.

Ma connexion internet actuelle est-elle suffisante pour migrer vers le cloud ?

C'est une question à mesurer, pas à estimer. La règle de base : chaque utilisateur actif sur un ERP cloud consomme en charge normale entre 0,5 et 2 Mbps de bande passante selon l'intensité d'utilisation. Pour 30 utilisateurs simultanés, il faut une connexion fibre professionnelle d'au moins 50 Mbps en upload et download, avec un SLA garantissant la disponibilité (99,5 % minimum). Une connexion ADSL ou une fibre grand public sans SLA ne convient pas pour un ERP en production dans le cloud. La montée en gamme de la connectivité doit être planifiée et facturée dans le budget de migration.

Peut-on garder certaines applications on-premise et migrer les autres vers le cloud ?

Oui, c'est le modèle hybride, et c'est la configuration que la majorité des PME marocaines finissent par adopter. L'approche 6R inclut précisément la stratégie "Retain" pour les applications qui ne doivent pas ou ne peuvent pas migrer. Un ERP avec des contraintes de latence critique peut rester on-premise pendant que la messagerie, les fichiers collaboratifs, et les outils secondaires migrent vers le cloud. Notre guide sur les serveurs on-premise vs cloud au Maroc détaille les critères de décision pour chaque type d'application.

Comment éviter les mauvaises surprises sur la facture cloud ?

Trois actions à prendre dès le premier jour de production. Premièrement, activez Azure Cost Management ou AWS Cost Explorer et configurez des alertes budgétaires sur des seuils définis (par exemple : alerte à 80 % du budget mensuel). Deuxièmement, revoyez les métriques d'utilisation CPU et mémoire de vos VM après 30 jours et redimensionnez celles qui sont sous-utilisées (rightsizing). Troisièmement, achetez des instances réservées 1 an pour les charges de travail stables une fois que vous avez validé le dimensionnement : l'économie est de 30 à 40 % par rapport à l'on-demand. Un prestataire de services managés cloud peut aussi prendre en charge ce pilotage pour vous.