Cloud DevOps au Maroc : 10 preuves avant de confier la production

Choisir un partenaire Cloud DevOps au Maroc ne consiste pas seulement à comparer des technologies ou un forfait mensuel. Avant de confier une production, l’entreprise doit vérifier qui surveille le service, qui peut modifier l’infrastructure, comment un incident est traité, comment une restauration est prouvée et ce qui est rendu à la fin du contrat.

La bonne décision repose sur des preuves opérationnelles : documents, accès, journaux, tests et responsabilités explicites. Cette grille aide une direction, une DSI ou une équipe produit à comparer des offres sur un périmètre commun, sans présumer d’un niveau de disponibilité ni d’une économie.

Réponse rapide : quelles preuves demander ?

Avant de confier la production, demandez dix éléments : un inventaire du périmètre, une matrice de responsabilités, des SLI et SLO mesurables, un plan d’astreinte et d’escalade, un exemple de rapport d’incident, une démonstration de l’observabilité, un compte rendu de restauration, la politique des accès privilégiés, un reporting coût-capacité et un plan de réversibilité. Une promesse commerciale n’équivaut pas à une preuve exploitable.

1. Un inventaire versionné du périmètre

Le contrat doit identifier les environnements, comptes cloud, applications, bases, réseaux, sauvegardes, pipelines et services tiers inclus. Pour chaque composant, précisez le propriétaire, la criticité, la fenêtre de service et les exclusions. Un inventaire figé à la signature devient rapidement faux ; il faut donc aussi définir qui l’actualise et comment un ajout entre dans le périmètre.

Cette première preuve évite de découvrir pendant un incident qu’une API, un certificat ou une base de données était hors contrat. Elle fournit aussi le point de départ d’une démarche d’Infrastructure as Code au Maroc, où la configuration peut être relue et reproduite.

2. Une matrice de responsabilités cloud

Le fournisseur cloud, le prestataire DevOps et le client n’assument pas les mêmes tâches. La documentation officielle d’AWS sur la responsabilité partagée rappelle que l’usage du cloud ne transfère pas automatiquement la responsabilité des données, des identités ou de la configuration au fournisseur.

La matrice doit nommer le responsable de chaque action : correctifs, sauvegardes, chiffrement, gestion des clés, renouvellement des certificats, validation des déploiements, réponse aux alertes et communication aux utilisateurs. Ajoutez la personne qui décide lors d’un arbitrage entre disponibilité, sécurité et rapidité de changement.

3. Des SLI et SLO reliés aux parcours utilisateurs

Un SLA contractuel ne suffit pas s’il n’indique pas comment le service est mesuré. Un SLI est l’indicateur observé, par exemple le taux de requêtes réussies ou la latence d’un parcours. Un SLO est la cible associée. Le chapitre de Google SRE sur les objectifs de niveau de service distingue ces mesures de l’accord commercial.

Demandez la formule, la source de données, la période de calcul, les exclusions et le tableau de bord. Choisissez des parcours métier plutôt qu’une simple disponibilité de machine : se connecter, créer une commande, envoyer un dossier ou terminer un paiement. Une cible doit être réaliste, justifiée et compatible avec les dépendances du système.

4. Une astreinte, une escalade et une communication testables

Le document d’exploitation doit répondre à des questions simples : qui reçoit l’alerte, dans quel ordre, selon quelle gravité et avec quel canal de secours ? Il doit distinguer la prise en compte, le diagnostic, le contournement et le rétablissement. Une disponibilité “24/7” sans équipe nommée, rotation, seuils et procédure n’est pas vérifiable.

Demandez un exercice de simulation : une API critique devient indisponible, une clé expire ou une base sature. Le prestataire doit montrer l’alerte, le routage, le journal des décisions et la mise à jour destinée aux parties prenantes. Cette preuve complète une stratégie d’observabilité cloud au Maroc.

5. Un modèle de rapport d’incident et de suivi des actions

Un rapport utile sépare les faits, l’impact observé, la chronologie, les décisions, les causes contributives et les actions correctives. Il ne sert pas à désigner un responsable individuel. Demandez un modèle anonymisé et vérifiez que chaque action possède un propriétaire, une échéance et un état.

Le cadre d’excellence opérationnelle de Google Cloud relie gestion des incidents, capacité, changement, automatisation et amélioration continue. Le contrat doit donc préciser comment les enseignements d’un incident modifient les alertes, les tests, les runbooks ou l’architecture.

6. Une observabilité démontrée sur un parcours réel

Demandez une démonstration sur un parcours représentatif : une requête traverse l’application, l’API, la base et éventuellement un service tiers. L’équipe doit pouvoir corréler métriques, logs et traces sans exposer inutilement de données personnelles. Vérifiez la durée de conservation, les droits d’accès, le masquage des secrets et les règles d’alerte.

Une capture d’écran d’un tableau de bord ne suffit pas. La preuve attendue est la capacité à partir d’un symptôme utilisateur, localiser le composant concerné et produire une action. Les alertes doivent être hiérarchisées pour limiter le bruit et rester exploitables.

7. Un test de restauration avec résultat et durée observée

Une sauvegarde prouve qu’une copie a été créée ; elle ne prouve pas que le service peut repartir. Demandez le dernier compte rendu de restauration ou prévoyez un test avant la prise en charge : ressource restaurée, point récupéré, contrôles d’intégrité, durée observée et écarts.

La documentation AWS sur les tests de récupération recommande un processus répétable. Les objectifs RTO et RPO doivent venir des besoins métier et être vérifiés dans le cadre d’un plan de reprise d’activité cloud, pas copiés depuis une offre standard.

8. Une politique d’accès privilégié et de gestion des secrets

Listez les comptes administrateurs, les rôles, les approbations et les accès d’urgence. Les identifiants individuels, l’authentification forte, la journalisation et la révocation doivent remplacer les comptes partagés permanents. Les secrets d’application ne doivent pas rester dans le code, les tickets ou les fichiers de configuration non protégés.

Vérifiez aussi qui possède le compte cloud principal et les domaines. L’entreprise cliente doit conserver une voie de contrôle compatible avec la continuité et la réversibilité. Une démarche de gestion des secrets au Maroc donne un cadre pour la rotation et l’audit.

9. Un reporting qui relie coût, capacité et fiabilité

Un rapport mensuel utile ne se limite pas à la facture. Il rapproche dépenses, capacité, incidents, changements, consommation des objectifs de service et ressources sans propriétaire. Chaque recommandation doit préciser son hypothèse et le risque associé : réduire une ressource peut diminuer le coût, mais aussi réduire la marge de capacité.

Cette lecture conjointe prolonge le FinOps au Maroc. Demandez qui valide les engagements tarifaires, les suppressions, les changements de taille et les projets de migration. Aucun gain ne doit être annoncé avant mesure sur le périmètre réel.

10. Un plan de réversibilité exécutable

Le plan de sortie doit préciser les comptes, dépôts, configurations, états d’infrastructure, journaux, sauvegardes, clés, documentation et runbooks remis au client. Il doit indiquer le format, le délai, les coûts éventuels, la période de coopération et la suppression finale des copies détenues par le prestataire.

Lorsque des données personnelles sont traitées, la CNDP rappelle que la sous-traitance doit être encadrée par un contrat et que le sous-traitant agit sur instruction du responsable du traitement. Le lieu d’hébergement, les sous-traitants ultérieurs et les transferts éventuels doivent donc être examinés avec les conseils compétents.

Comment comparer deux offres Cloud DevOps au Maroc

• Comparez le même inventaire et les mêmes heures de couverture.
• Demandez une preuve pour chaque engagement important.
• Séparez exploitation courante, projets, licences et interventions exceptionnelles.
• Évaluez la qualité de la sortie autant que celle de l’entrée.
• Faites valider les exigences juridiques et sectorielles applicables.

Une courte phase de transition peut servir à compléter l’inventaire, vérifier les accès, tester l’alerte et exécuter une restauration. Elle produit une base factuelle avant d’étendre le périmètre. Pour cadrer ce travail, consultez le service Cloud & DevOps de Kanteek ou décrivez votre environnement à l’équipe.

Questions fréquentes

Un SLA élevé garantit-il une production fiable ?

Non. Il faut vérifier les indicateurs, la méthode de calcul, les dépendances, les procédures d’incident et les tests de récupération. Le SLA est un engagement contractuel ; la fiabilité dépend aussi de l’architecture et de l’exploitation.

Le prestataire doit-il posséder le compte cloud ?

Le modèle doit préserver le contrôle et la réversibilité du client. Les rôles du prestataire peuvent être délégués et journalisés sans lui transférer définitivement la propriété des comptes, domaines ou dépôts.

Quelle est la première preuve à demander ?

Commencez par l’inventaire versionné et la matrice de responsabilités. Sans eux, les autres engagements restent difficiles à rattacher à un périmètre précis.

Faut-il tester la réversibilité avant la fin du contrat ?

Oui, au moins par un exercice documentaire et technique limité : export de configuration, restitution d’un accès, restauration d’une sauvegarde et revue des dépendances. Le résultat révèle les éléments manquants avant une situation urgente.