Il existe deux types de migrations cloud en Afrique.
Celles qui se passent bien : continuité de service totale, réduction de coûts au rendez-vous, équipes qui adoptent les nouveaux outils en quelques semaines. Et celles qui déraillent : interruption non planifiée un vendredi soir à 22h, perte de données découverte trois semaines après la bascule, dépassement de budget qui fait sauter les plombs au CODIR.
La différence entre les deux n'est pas une question de chance. Elle tient à une méthode appliquée dans le bon ordre. Après des dizaines de migrations menées dans 7 pays africains, voici ce que l'équipe ST Digital a appris y compris sur les erreurs qu'on ne fait qu'une fois.
Étape 1 : L'audit de l'existant - la fondation que personne ne veut faire
C'est l'étape la plus résistée. Elle semble fastidieuse, sans valeur ajoutée immédiate, chronophage. Elle est pourtant la seule chose qui vous évitera de découvrir, au moment de la bascule, qu'une application métier critique dépend d'un serveur que vous pensiez pouvoir éteindre.
L'audit doit répondre à quatre questions précises.
- Quelles
applications sont hébergées où ? Sur quelle infrastructure physique ou
virtuelle ? Qui les administre ? Quelle version logicielle tourne
en production
- Quelles
données sont critiques ? Impossible à
perdre (financières, clients, contrats) vs importantes (à restaurer en moins de
4 heures) vs archivables (récupérables en 24 à 72 heures). Cette
classification détermine toute l'architecture de migration.
- Quelles
dépendances existent entre les systèmes ? Quelle application appelle quelle
autre, sur quel port, avec quelle fréquence ? C'est ici que se cachent les
mauvaises surprises. Un ERP qui appelle une API interne sur un serveur que vous
migrez en phase 1 peut planter en phase 3.
- Quels sont les SLA contractuels actuels ? Avec vos clients, vos partenaires, vos régulateurs. La migration doit les respecter ou des dérogations doivent être négociées avant la bascule.
ST Digital réalise cet audit gratuitement pour ses prospects. En interne, comptez 3 à 10 jours selon la taille de l'organisation. Ne passez pas à l'étape 2 sans réponses documentées à ces quatre questions.
Étape 2 : Choisir le bon modèle - cloud public, privé ou hybride ?
La réponse n'est jamais absolue. Pour la quasi-totalité des entreprises africaines de taille intermédiaire, le modèle hybride est la réponse optimale mais « hybride » ne veut rien dire sans préciser quoi reste où.
La règle empirique que ST Digital applique : les données critiques vont en cloud privé souverain africain. Les données confidentielles (clients, financières, RH, contrats) ne sortent pas du continent. Les outils collaboratifs, messagerie, visioconférence, suite bureautique, gestion de projet peuvent aller en cloud public. Cette segmentation respecte les obligations réglementaires de localisation sans sacrifier la productivité ni les fonctionnalités des grands éditeurs.
Pour les banques, assurances, administrations et structures de santé soumises à des obligations sectorielles strictes, le cloud privé souverain est la seule option conforme. Pour une PME sans contrainte réglementaire forte, un modèle plus ouvert peut suffire, à condition d'accepter consciemment les implications juridiques.
Étape 3 : Planifier la migration dans le bon ordre
Règle d'or : on migre d'abord ce qu'on peut se permettre de casser, on affine la méthode sur des systèmes à faible enjeu, et on aborde les systèmes critiques en dernier, avec une équipe qui a déjà de l'expérience sur la nouvelle infrastructure.
La séquence recommandée par ST Digital :
Phase 1 : Archivage et sauvegarde. Données froides, archives documentaires. Zéro impact opérationnel en cas de problème.
Phase 2 : Outils collaboratifs. Messagerie, partage de fichiers, agenda. Impact limité, réversible rapidement.
Phase 3 : Applications métier secondaires. Intranet, outils de reporting, bases de connaissances.
Phase 4 : Applications métier critiques. ERP, CRM, bases de données clients. Cette phase migre en dernier, après que l'équipe a validé son niveau de maîtrise sur l'infrastructure cible.
Phase 5 : Infrastructure réseau et sécurité. Active Directory, DNS, firewalls. Toucher à ça en premier, c'est la façon la plus efficace de paralyser tout le reste.
Chaque phase suit le même schéma : déploiement de l'environnement cible en parallèle de l'existant, tests de charge à 100 % du trafic de production en environnement isolé, validation par l'équipe métier, bascule hors heures de pointe avec plan de rollback documenté et testé.
Étape 4 : La bascule - le moment où les migrations ratées échouent
La bascule, c'est le moment où on passe le trafic de production sur le nouvel environnement. C'est là que les projets mal préparés s'effondrent. Deux conditions non négociables avant d'activer quoi que ce soit.
Condition 1 : le plan de rollback doit permettre un retour à l'état antérieur en moins de 2 heures. Ce plan doit être documenté, testé, et connu de deux personnes minimums. Pas d'un seul expert qui dort pendant la bascule.
Condition 2 : les sauvegardes du dernier état stable doivent être validées en restauration. Pas vérifiées sur leur statut de sauvegarde, restaurées avec succès sur un environnement de test. Un backup qui n'a pas été restauré au moins une fois n'est pas un backup. C'est un espoir.
La bascule elle-même se fait lors d'une fenêtre de maintenance planifiée, communiquée à l'avance aux utilisateurs, avec une équipe technique complète disponible pendant les 4 heures qui suivent. Ces 4 premières heures concentrent 80 % des incidents potentiels.
Étape 5 : Stabilisation - les 30 premiers jours ne sont pas de tout repos
La migration n'est pas terminée le jour de la bascule. Les 30 premiers jours sont la période de stabilisation, là où les comportements réels de production révèlent ce que les tests n'ont pas capturé.
Monitoring renforcé sur toutes les métriques critiques : latence, disponibilité, utilisation CPU, mémoire, stockage. Revue hebdomadaire avec l'équipe métier pour identifier les points de friction. Optimisation progressive de la configuration réseau et des ressources allouées.
ST Digital assure un support dédié pendant cette période dans tous ses contrats de migration, c'est contractuel, pas une option qu'on vous vend après. À 90 jours, une revue formelle de performance compare les indicateurs post-migration avec le baseline pré-migration.
Dans les projets ST Digital, la réduction de coûts infrastructure observée est en moyenne de “28 à 42 %” à 90 jours. C'est la fourchette réelle, pas le chiffre marketing.
Les 4 risques qui font rater une migration cloud en Afrique
Perte de données. Les backups n'ont pas été validés avant la migration. La restauration qui semblait fonctionner ne fonctionne pas sur le nouvel environnement.
Interruption non planifiée. Les dépendances applicatives n'ont pas été cartographiées à l'étape 1. Une application en phase 4 appelle un service migré en phase 1 qui n'a pas été recréé correctement.
Dépassement de budget. Les coûts de transfert de données (egress) n'ont pas été anticipés. AWS et Azure facturent entre 0,08 et 0,15 USD par Go de données sortantes sur une migration de plusieurs To, ça chiffre vite.
Non-conformité réglementaire. Les contraintes de localisation des données ont été ignorées lors du choix du modèle cible. Le régulateur local (COBAC, BCEAO, ANRTIC) identifie le problème 6 mois après la migration. La remédiation coûte beaucoup plus cher que de l'avoir fait correctement dès le départ.
Obtenez votre plan de migration personnalisé
ST Digital réalise l'audit de votre infrastructure et vous remet un plan de migration détaillé sous 5 jours ouvrés, sans engagement.