Ce que la stratégie algérienne de cybersécurité 2025-2029 change pour les entreprises

Ce qui a été publié et ce qui ne doit pas être extrapolé

L’Agence de la sécurité des systèmes d’information, relevant du ministère de la Défense nationale, a dévoilé le 3 mars 2026 la première édition de la stratégie nationale de la sécurité des systèmes d’information 2025-2029. L’information a été relayée par l’Algérie Presse Service et par l’École nationale supérieure de cybersécurité, qui renvoie vers la publication institutionnelle.

Une stratégie nationale fixe une orientation, des priorités et une trajectoire. Elle ne doit pas être présentée comme une nouvelle obligation juridique uniforme pour toutes les entreprises. Les obligations réelles dépendent toujours des textes applicables, du secteur, des contrats, de la nature des données et du rôle de l’organisation dans une chaîne de service essentielle.

La décision utile consiste donc à traduire cette orientation en questions de gestion: quels services doivent continuer en cas d’incident, qui arbitre un risque, quels fournisseurs peuvent interrompre une opération et quelles preuves démontrent que les mesures annoncées fonctionnent réellement?

Six décisions à prendre au niveau de la direction

La cybersécurité devient efficace lorsque les décisions ont un propriétaire, une échéance et un niveau de risque accepté. Une direction n’a pas besoin de gérer les consoles techniques, mais elle doit définir les services prioritaires, le niveau d’interruption tolérable et les responsabilités en cas de crise.

• Gouvernance: désigner un sponsor, un responsable opérationnel et un circuit d’escalade qui ne dépend pas d’une seule personne.
• Actifs: relier applications, données, comptes, équipements et fournisseurs aux processus métier qu’ils supportent.
• Identités: réduire les comptes partagés, renforcer les accès privilégiés et retirer rapidement les droits devenus inutiles.
• Continuité: fixer des objectifs de reprise et de perte de données acceptables, puis tester la restauration dans des conditions réalistes.
• Incident: préparer qui décide, qui communique, qui conserve les éléments techniques et comment l’activité fonctionne en mode dégradé.
• Tiers: exiger des engagements vérifiables sur la sécurité, les incidents, la sauvegarde, la sous-traitance et la réversibilité.

Prioriser par impact métier, pas par peur technique

Une liste de vulnérabilités ne suffit pas à fixer l’ordre de travail. Le même défaut peut être secondaire sur un outil isolé et critique sur une application de commande, de paiement, de production ou de relation client. La priorité combine vraisemblance, impact, exposition, détectabilité et capacité de récupération.

Commencez par trois scénarios concrets: indisponibilité d’un service central, compromission d’un compte à privilèges et fuite d’un ensemble de données sensibles. Pour chacun, décrivez les conséquences sur le chiffre d’affaires, les engagements clients, la sécurité physique, la conformité et la réputation. Cette formulation rend les arbitrages budgétaires compréhensibles au-delà de l’IT.

Un plan réaliste sur 90 jours

Les trente premiers jours servent à rendre le risque visible. Recensez dix à vingt services essentiels, leurs propriétaires, leurs données, leurs dépendances et leurs comptes administrateurs. Vérifiez les sauvegardes existantes sans supposer qu’un statut vert signifie qu’une restauration aboutira.

Entre le jour 31 et le jour 60, traitez les expositions les plus simples à réduire: authentification renforcée, suppression des comptes dormants, correctifs critiques, protection des interfaces publiques, centralisation des journaux essentiels et coordonnées d’urgence des fournisseurs. Chaque action doit produire une preuve exploitable.

Entre le jour 61 et le jour 90, organisez un exercice de crise sur table, réalisez une restauration test, révisez un contrat critique et présentez à la direction les risques résiduels. Le résultat attendu n’est pas une certification improvisée, mais un registre vivant et une cadence de contrôle.

Exemple anonymisé: une plateforme B2B dépendante de trois tiers

Une entreprise de distribution exploite un portail de commande, une base de stock et un service de livraison externe. L’analyse révèle que l’application est sauvegardée, mais que la restauration de la base n’a jamais été testée. Les comptes administrateurs sont protégés de manière inégale et le contrat du prestataire de livraison ne définit pas de procédure d’incident.

Le plan prioritaire ne commence pas par remplacer toute l’architecture. Il impose l’authentification renforcée, documente les dépendances, teste une restauration, ajoute une file de reprise pour les échanges avec le transporteur et établit un contact d’escalade contractuel. Le risque devient plus mesurable sans bloquer l’activité.