Décret 26-07 : construire une structure SSI réellement indépendante de la DSI

Le décret 26-07 impose aux institutions publiques une structure de sécurité des systèmes d'information indépendante de la DSI. La difficulté n'est pas technique : c'est le mot « indépendante », et renommer un poste existant ne passera pas le premier audit.

Le décret présidentiel n° 26-07 du 7 janvier 2026 impose aux institutions publiques algériennes de se doter d'une structure dédiée à la sécurité de leurs systèmes d'information.

La lecture superficielle donne l'impression d'une formalité d'organigramme. C'est une erreur de lecture. Le texte contient un mot qui porte tout le reste, et ce mot est indépendante.

Note de méthode — à lire avant le reste. Notre compréhension détaillée de ce décret repose encore, pour partie, sur des sources secondaires. Les hôtes publiant le Journal officiel présentent des certificats TLS invalides et le texte primaire n'a pas pu être vérifié intégralement. Chaque numéro d'article et chaque citation littérale nécessaires sont signalés comme non vérifiés dans le corps du texte. Nous ne reconstituons pas un texte réglementaire de mémoire. Ce qui suit est solide sur le raisonnement organisationnel ; les références précises seront ajoutées après vérification.


1. Ce que le décret demande

Les obligations décrites par les sources secondaires disponibles s'organisent autour de cinq idées : une structure distincte, un rattachement hiérarchique qui ne passe pas par l'informatique, quatre fonctions nommées, une exigence de compétence pour la personne qui la dirige, et des clauses de sécurité dans les contrats.

Le reste de cet article part de ces cinq idées et traite la seule question qui décidera de votre conformité réelle : que faut-il faire pour que la structure soit réellement indépendante — et non indépendante sur le papier.


2. « Indépendante de la DSI » : le mot qui porte tout

La tentation est évidente et nous la voyons déjà : désigner le responsable de l'infrastructure comme responsable SSI, ajouter la ligne à l'organigramme, et considérer l'obligation satisfaite.

Cela ne tiendra pas au premier audit, pour une raison de fond : la sécurité des systèmes d'information contrôle, entre autres choses, le travail de la direction informatique. Quand la même personne produit et contrôle, il n'y a pas de contrôle.

L'indépendance, dans les faits, se démontre par trois éléments observables.

Une ligne de rattachement qui ne passe pas par la DSI

Le responsable SSI rend compte à la direction de l'institution, pas au directeur informatique. Un auditeur vérifie cela en une question : « qui évalue le responsable SSI, et qui décide de sa prime ? » Si la réponse est « le DSI », l'indépendance n'existe pas, quel que soit le dessin de l'organigramme.

Un budget qui lui est propre

Une structure dont les moyens sont arbitrés par l'entité qu'elle contrôle n'est pas indépendante. Elle est tolérée. Le budget n'a pas besoin d'être important ; il a besoin d'être distinct et de ne pas être le reliquat d'une enveloppe informatique.

L'autorité de dire non

C'est le test décisif, et il est simple à formuler : la structure SSI peut-elle bloquer une mise en production ?

Si elle peut seulement émettre un avis que la DSI est libre d'ignorer, elle est un organe consultatif. Si son opposition impose un arbitrage explicite au niveau de la direction générale, elle est une structure de contrôle. Le décret décrit la seconde.

Cela suppose une chose que peu d'institutions écrivent : une procédure formelle d'escalade et de dérogation. Qui peut passer outre un avis défavorable, à quel niveau, avec quelle trace écrite, et pour quelle durée. Sans cette procédure, l'autorité de dire non n'est pas opposable.


3. Les quatre fonctions nommées

Les quatre fonctions décrites forment une chaîne. Chacune n'a de valeur que si la précédente est faite.

La cartographie des risques. Pas un catalogue de vulnérabilités : un inventaire des actifs d'information, de ce qu'ils supportent comme mission, et de ce qui se passerait s'ils tombaient ou fuyaient. C'est le seul document qui permet de justifier une priorité.

La surveillance continue. « Continue » exclut l'audit annuel et exclut la revue manuelle hebdomadaire des journaux. Cela suppose une collecte centralisée, une détection automatisée et quelqu'un qui reçoit les alertes — les trois, pas seulement le premier. Une collecte sans destinataire est un coût de stockage, pas une surveillance.

L'audit. Périodique, selon une périodicité fixée par l'autorité.

Le signalement immédiat des incidents. Voir la section 6 : c'est la fonction dont la faisabilité technique est la plus souvent surestimée.


4. Les clauses de sécurité dans les marchés — la disposition qui sera manquée

C'est, à notre avis, l'obligation qui produira le plus d'écarts constatés, parce qu'elle ne relève pas de la direction informatique mais de la direction des achats.

Concrètement, cela veut dire qu'un cahier des charges ne peut plus se contenter d'une ligne « le prestataire respectera les règles de sécurité en vigueur ». Une clause opposable dit qui fait quoi, dans quel délai, et ce qui se passe en cas de manquement. Au minimum :

Point pratique : ces clauses doivent entrer dans les modèles de marchés, pas être négociées contrat par contrat. Une clause qui dépend de la vigilance d'un acheteur ne sera appliquée qu'une fois sur trois.


5. Qui supervise — et un avertissement de vocabulaire

Le dispositif est supervisé par l'ASSI, avec DZ-CERT dans le rôle du centre de réponse aux incidents.

⚠️ L'ASSI n'est pas l'ANSSI française. La ressemblance des sigles produit une confusion permanente, et elle est coûteuse : les deux organismes n'ont ni le même positionnement institutionnel, ni les mêmes pouvoirs, ni les mêmes référentiels. Un document de conformité algérien qui cite un guide de l'ANSSI française comme s'il faisait autorité localement se disqualifie tout seul.


6. Ce que « signalement immédiat » veut dire techniquement

« Immédiat » est un mot juridique. Traduit en ingénierie, il impose quatre capacités, et l'absence d'une seule fait tomber la chaîne :

  1. Détecter l'incident. Sans collecte centralisée et détection automatisée, la détection dépend de quelqu'un qui remarque quelque chose — délai non maîtrisé, non démontrable.
  2. Qualifier rapidement. Tout événement n'est pas un incident signalable. Il faut un critère écrit à l'avance, sinon la qualification prend des jours de discussion.
  3. Signaler par un canal connu. Le canal, le format et le destinataire doivent être établis avant l'incident. Chercher à qui écrire pendant une crise coûte des heures.
  4. Prouver la chronologie. C'est le point aveugle habituel : il faut pouvoir démontrer quand vous avez su. Cela ne se reconstitue pas après coup — cela suppose des traces horodatées, centralisées et non modifiables.

Ce quatrième point est exactement l'exigence de traçabilité que porte la loi 25-11 sur les données personnelles. Les deux textes visent des objets différents, mais ils convergent sur la même infrastructure : des traces fiables, centralisées, inaltérables et conservées. Une institution qui construit cela une fois répond aux deux.


7. Un plan de mise en place en 90 jours

Rien ici ne suppose un budget d'investissement. Tout suppose des décisions écrites.

Jours 1 à 30 — poser l'indépendance.

Jours 31 à 60 — voir avant de protéger.

Jours 61 à 90 — rendre le dispositif opposable.

À l'issue des 90 jours, vous n'aurez pas une structure mature. Vous aurez ce qui compte davantage face à un contrôle : une structure existante, datée, dotée, et capable de montrer ce qu'elle fait.


Où en êtes-vous réellement

La question qui décide de tout n'est pas « avons-nous une structure SSI ». C'est : si elle s'opposait demain à une mise en production, que se passerait-il ?

Si vous voulez confronter votre architecture existante à ces exigences — rattachement, traçabilité, capacité de signalement — nous proposons une revue d'architecture de 45 minutes, sans engagement.

Tous les articles