Ce que pose le Décret 25-320
Le 30 décembre 2025, l’Algérie a publié le Décret Présidentiel n° 25-320 instituant un cadre national de gouvernance des données. D’après le suivi du registre de Digital Policy Alert et du guide CMS sur l’Algérie, le décret articule trois piliers :
- Classification des données — une taxonomie structurée pour les données détenues par les administrations publiques, couvrant les niveaux de sensibilité (public, interne, restreint, confidentiel) et les domaines métier.
- Catalogage des données — chaque administration publique doit tenir un catalogue de ses actifs de données, en les décrivant de manière à permettre la réutilisation et le partage encadré.
- Interopérabilité sécurisée — les administrations publiques doivent pouvoir échanger des données entre elles via des canaux sécurisés et normalisés, alignés sur les règles de cybersécurité et de protection des données personnelles.
Ce décret se place à côté d’instruments déjà en place : la Loi 18-07 sur la protection des données personnelles (amendée par la Loi 25-11), la loi cybersécurité de 2024, et la réglementation cloud appliquée par l’ARPCE. Le Décret 25-320 est la couche qui dit aux organismes publics comment organiser leurs données pour que les autres lois puissent opérer au-dessus.
Cet article est un guide explicatif pour les éditeurs, intégrateurs et architectes cloud qui vendent au secteur public algérien ou bâtissent pour lui — et non une critique du décret ou des administrations qui le mettent en œuvre.
Pour qui cela compte
Même si le décret s’adresse directement aux administrations publiques, l’impact opérationnel se diffuse à tout l’écosystème fournisseurs :
- Éditeurs SaaS au service des ministères, agences, collectivités, hôpitaux ou universités publiques — leurs plateformes devront s’adapter au modèle classification/catalogue.
- Intégrateurs qui construisent ou modernisent les SI publics — les appels d’offres citeront de plus en plus le décret.
- Architectes cloud concevant des landing zones pour les clients publics — leurs architectures de référence devront supporter stockage classifié, hooks vers le catalogue et APIs d’interopérabilité par défaut.
- Cabinets conseil qui accompagnent la transformation numérique publique — les évaluations de maturité en gouvernance des données deviendront une mission récurrente.
Les entreprises privées ne sont pas directement liées par le Décret 25-320, mais celles dont les produits sont consommés par les administrations publiques (ou qui échangent des données avec elles) en hériteront de fait les exigences.
Classification : la couche de tags que tout produit doit exposer
La classification est la fondation. Sans elle, ni le catalogage ni l’interopérabilité ne peuvent fonctionner proprement. Une implémentation conforme aux attentes du Décret 25-320 nécessite :
- Un schéma de classification avec des critères clairs pour chaque niveau (par exemple données publiques du site de l’administration, données internes d’usage quotidien, données restreintes sur les citoyens, données confidentielles liées à la sécurité de l’État).
- Un mécanisme d’étiquetage au niveau des données — tags dans les bases, métadonnées dans les dépôts documentaires, attributs de classification dans les en-têtes de fichiers, labels sur les buckets de stockage objet.
- Une règle de propagation — quand une donnée se déplace d’un système à l’autre, la classification suit. C’est là que la plupart des implémentations échouent : un rapport exporté en Excel perd son étiquette de sensibilité sauf si la plateforme l’impose.
Pour les éditeurs, l’implication de conception est claire : les plateformes vendues à des clients publics algériens en 2026 doivent exposer un champ de classification par défaut et permettre aux administrateurs de configurer la taxonomie.
Publicité
Catalogage : du tableur à l’API
Un catalogue, c’est plus qu’un inventaire. Dans le cadre du décret, chaque administration doit pouvoir décrire ses jeux de données — qui les possède, comment ils ont été créés, à quelle fréquence ils sont mis à jour, qui peut y accéder, dans quelles conditions ils peuvent être partagés.
Les exigences pratiques à anticiper côté éditeurs :
- Standards de métadonnées — prise en charge des standards usuels (DCAT-AP est une base raisonnable) pour rendre la découverte inter-administrations possible.
- Événements de cycle de vie — le catalogue doit refléter création, mises à jour, archivage et suppression.
- Contrôles d’accès liés à la classification — les entrées du catalogue ne doivent être visibles qu’aux personnes autorisées.
- Interfaces lisibles par machine — un catalogue public est utile aux citoyens, une API de catalogue est utile aux autres administrations.
Une équipe projet qui prépare un appel d’offres ministériel doit traiter l’« API catalogue » comme une exigence de premier plan, pas comme une option.
Interopérabilité sécurisée : le vrai travail d’ingénierie
L’interopérabilité est l’endroit où la discipline architecturale paie. Le décret encadre les échanges entre administrations publiques comme un canal sécurisé et documenté — pas un CSV envoyé par e-mail entre ministères.
Une pile d’interopérabilité conforme ressemble à ceci :
- Endpoints authentifiés — TLS mutuel entre systèmes d’administrations, avec certificats issus d’une hiérarchie reconnue.
- Identité et autorisation — chaque requête est signée par une administration connue et cadrée sur un niveau de classification précis.
- Sécurité du transport et du payload — chiffrement en transit obligatoire ; chiffrement au repos suivant le niveau de classification.
- Journalisation et audit — chaque échange est journalisé avec une piste inviolable pour audit ultérieur, cohérent avec les obligations cybersécurité.
- Alignement protection des données — lorsque l’échange porte sur des données personnelles, il doit respecter les principes de licéité et de minimisation de la Loi 18-07 / Loi 25-11.
Les architectes cloud qui conçoivent des landing zones pour clients publics doivent intégrer ces contrôles dans le design de référence, de sorte que chaque nouveau workload les hérite sans débat sécurité à chaque fois.
Un cadre de conformité en trois piliers pour les éditeurs
Le Décret 25-320 crée une séquence de préparation prévisible pour tout éditeur ou architecte cloud qui souhaite être compétitif dans le secteur public algérien. Les trois piliers correspondent directement à la structure du décret et peuvent être adressés en un seul cycle de roadmap produit.
Pilier 1 : Classification — Taguer chaque objet de données à la source
La taxonomie de classification du décret est le prérequis de tout le reste. Les éditeurs doivent implémenter la classification comme attribut de premier niveau dans les couches stockage, GED et base de données — pas comme une étiquette post-traitement appliquée par un administrateur une fois les données existantes. Le pattern de design pratique : exposer un menu ou un champ API de classification dans chaque workflow de création de données, imposer la propagation pour que les exports et copies héritent du label source, et journaliser chaque reclassification avec timestamp et identité utilisateur. Les quatre niveaux standard (public, interne, restreint, confidentiel) s’alignent avec les frameworks ANSSI français et NIS2 de l’UE, ce qui signifie que les éditeurs ayant des déploiements secteur public européen existants peuvent adapter leurs schémas de classification plutôt que de tout reconstruire. Documenter ce schéma dans les supports commerciaux : les responsables achats sous le Décret 25-320 demanderont si le produit supporte la taxonomie avant toute évaluation technique.
Pilier 2 : Catalogue — Exposer une API d’actifs de données machine-readable
Un catalogue de données sous le Décret 25-320 n’est pas un portail de documentation utilisateur — c’est un registre machine-readable que d’autres administrations peuvent interroger pour découvrir des jeux de données, comprendre leur structure et demander un accès. Le standard DCAT-AP (Data Catalog Vocabulary Application Profile), utilisé sur les portails de données du secteur public UE, est la ligne de base la plus répandue. Les éditeurs doivent implémenter un endpoint API compatible DCAT-AP dans toute plateforme servant des clients publics, exposant au minimum : identifiant du jeu de données, administration propriétaire, tags domaine, classification de sensibilité, conditions d’accès et fréquence de mise à jour. Pour les intégrateurs, l’API catalogue devient un livrable dans chaque appel d’offres — son absence disqualifiera une candidature une fois les équipes achats opérationnelles sur les attentes du décret, estimé à débuter en masse au second semestre 2026.
Pilier 3 : Interopérabilité — TLS mutuel et journalisation d’audit structurée par défaut
La couche d’interopérabilité sécurisée est là où les choix architecturaux d’aujourd’hui créent soit une aptitude à l’audit, soit une dette de conformité. Les landing zones cloud pour clients publics doivent implémenter le TLS mutuel comme défaut non négociable entre toutes les frontières de services. Chaque échange inter-administrations doit porter un enregistrement de log structuré avec : timestamp de l’échange, identité de l’émetteur (avec référence certificat), identité du destinataire, niveau de classification des données et hash du payload. Ce pattern de journalisation est requis pour les pistes d’audit inviolables sous le Décret 25-320 et la loi cybersécurité, et est le plus économique à implémenter au moment du design de l’infrastructure plutôt qu’en retrofit.
Ce qui vient ensuite
Le Décret 25-320 est la couche cadre, pas la couche d’implémentation. Les 12 prochains mois produiront les décrets d’application, les circulaires ministérielles et les lignes directrices techniques de l’ARPCE qui traduiront les trois piliers en exigences techniques et contractuelles spécifiques. Les fournisseurs et architectes cloud qui traitent ce moment comme une période d’attente seront désavantagés : les organisations qui commencent dès maintenant à aligner leurs roadmaps produit et architectures de référence rencontreront la première vague d’appels d’offres avec une capacité documentée ; celles qui attendent les lignes directrices finales devront adapter leur gouvernance sous la pression des délais d’appel d’offres.
Trois développements méritent un suivi attentif. Premièrement, les orientations techniques de l’ARPCE sur les exigences de classification cloud — le régulateur est l’organe le plus susceptible de spécifier exactement quels niveaux de classification doivent être appliqués à quelle couche de stockage. Deuxièmement, la position de l’ANPDP sur les droits d’accès au catalogue de données — en tant qu’autorité de protection des données personnelles, l’ANPDP déterminera comment les entrées de catalogue couvrant des données personnelles sont délimitées et sous quelle base légale. Troisièmement, l’extension du cadre aux entreprises publiques à mandat commercial — le décret s’adresse aux administrations publiques, mais le texte d’application clarifiera si des entités comme Sonatrach, Algérie Télécom et les grandes banques d’État entrent dans son périmètre.
Les fournisseurs déjà investis dans la conformité au secteur public européen sous NIS2 et l’Acte européen sur la gouvernance des données trouveront que le cadre algérien est structurellement similaire. Cette similitude n’est pas accidentelle — l’Algérie a historiquement aligné son architecture de gouvernance numérique sur le modèle français, et le Décret 25-320 reflète cet alignement. L’implication pratique est que les fournisseurs déjà conformes au secteur public européen peuvent adapter plutôt que reconstruire.
Questions Fréquemment Posées
À qui s’applique le Décret 25-320 ?
Le Décret 25-320 s’applique aux administrations publiques algériennes — ministères, agences, établissements publics et collectivités locales. Les entreprises privées ne sont pas directement liées, mais les éditeurs et intégrateurs qui travaillent avec des clients publics verront ses exigences cascader via les appels d’offres et les contrats.
Comment le Décret 25-320 s’articule-t-il avec la Loi 18-07 / Loi 25-11 ?
Le Décret 25-320 porte sur la façon dont les administrations publiques organisent, cataloguent et échangent leurs données. La Loi 18-07 (amendée par la Loi 25-11) régit le traitement des données personnelles. Lorsqu’un échange inter-administrations inclut des données personnelles, les deux cadres s’appliquent : l’échange doit être classifié, catalogué et sécurisé (Décret 25-320), et également licite, minimisé et respectueux des droits (Loi 25-11).
Qu’un architecte cloud doit-il changer dans ses designs pour les clients publics algériens ?
Faire des tags de classification un attribut de première classe des services de stockage, intégrer un hook d’API de catalogue dans les pipelines de données, imposer TLS mutuel plus journalisation centralisée pour tout échange inter-administrations, et aligner les réglages de chiffrement sur le niveau de classification. Traiter ces contrôles comme des défauts, pas des options.
