Aller au contenu

Présentation de l'écosystème

En une phrase

L'écosystème Gerege est un écosystème de services numériques ancré dans un noyau eID/PKI national, relié par une couche SSO et issu d'un modèle unique, construit en parallèle sur deux lignes en miroir : le secteur public (*.dgov.mn) et le secteur privé (*.gerege.mn).

Pourquoi cette construction ?

Traditionnellement, chaque service numérique est monté séparément, avec sa propre authentification, son propre modèle de droits et son propre niveau de sécurité. Résultat :

  • le citoyen se connecte différemment à chaque service,
  • chaque organisation réinvente la PKI,
  • le niveau de sécurité diffère d'un service à l'autre,
  • un même correctif doit être répété dans de nombreux systèmes.

L'écosystème Gerege part du bout opposé : l'identité, la sécurité, l'IA et le socle applicatif sont résolus une seule fois, et l'on n'ajoute au-dessus que la valeur métier propre à chaque secteur. Le développeur écrit un produit, pas une infrastructure.

C'est la traduction en code de la mission de Gerege Systems ХХК : « délivrer simplement aux citoyens les services publics comme privés ». Sur un seul socle se montent aussi bien les services d'un organisme public que les produits du privé — banque, assurance, fintech, santé, éducation — avec le même niveau de vérification d'identité et la même sécurité.

Trois idées porteuses

1. L'identité est une infrastructure, pas l'affaire de chaque application

Connexion, signature, certificats : tout cela est résolu une fois pour toutes dans eID Mongolia. Les applications ne stockent pas de mots de passe et n'écrivent pas de code PKI ; elles se raccordent simplement en tant que relying party (RP).

  • La clé privée de signature n'existe entièrement nulle part — ECDSA à seuil 2-of-2 (une part sur le téléphone, une part sur le serveur).
  • Chaque citoyen possède deux certificats : Authentication (PIN1, connexion) et Signing (PIN2, signature juridiquement valable).

2. Le SSO est le seul chemin de l'identité vers l'application

Les applications n'accèdent jamais directement à l'eID. Entre les deux se trouve la couche SSO — un fournisseur OAuth2/OIDC standard. Elle :

  • centralise l'authentification et offre le même flux à tous les RP,
  • joue le rôle de proxy eID : ne transmet les services eID autorisés qu'aux applications enregistrées,
  • garde les identifiants en un seul endroit, ce qui écarte tout risque de divergence entre deux systèmes.

3. La plateforme est elle-même un produit

La Template Platform n'est pas un exemple de code : c'est un socle prêt pour la production. Backend Go en Clean Architecture + frontend Next.js BFF + pipeline Gemini AI, durci côté sécurité et testé. Ring, Khurdan, Wallet et le Developer Portal en sont tous issus.

Deux lignes en miroir

Couche Public (dgov.mn) Privé (gerege.mn)
Identité eID Mongolia (commun) eID Mongolia (commun)
SSO sso.dgov.mn sso.gerege.mn
Template template.dgov.mn open.gerege.mn
Developer developer.dgov.mn developer.gerege.mn
Verticaux Ring · Khurdan Gerege Platform · Wallet

Les deux lignes partagent la même filiation de code : même architecture, mêmes conventions, même socle de sécurité. Les différences ne portent que sur la marque, le cadre juridique et le périmètre d'intégration.

Pourquoi deux lignes ?

Les services publics et privés diffèrent par les exigences légales, la gouvernance des données et le régime d'audit. Les servir depuis un seul déploiement brouillerait la frontière. D'où : un code, deux déploiements.

Quatre grandes bascules

1. Fragmentation → consolidation. Les dépôts eID séparés ont été réunis dans le monorepo eid-platform-mn, avec une branche et une marque uniques ; plusieurs marques sont servies par des variantes d'application.

2. Sortie de la dépendance à un tiers. Ory Hydra a été retiré de tous les projets SSO et les mécanismes nécessaires réécrits en code Go maison ; la base de données Hydra distincte a été fusionnée avec la base principale. La tendance générale est de réduire les dépendances externes.

3. Plateforme → écosystème. Le Template est devenu un produit à part entière ; au-dessus sont apparues de véritables plateformes d'administration, et en dessous la couche d'échange de données X-Road.

4. Fork → upstream (2026-08). Gerege Nexus est apparu en couche 3 — un nouveau socle bâti comme un monolithe modulaire doté d'un app store. Là où un nouveau produit signifiait un fork du modèle, il signifie désormais écrire un module ou, pour une marque, forker l'upstream et se rafraîchir par fusion. Les deux premiers forks sont Gerege SSO et Eduge.mn. La transition étant en cours, les plateformes de 1re génération restent en production.

Ensuite

  • Architecture en couches


    Le contenu de chaque couche et les dépendances entre elles, schéma complet.

    Voir

  • Cartographie des domaines


    Quel domaine pointe vers quelle plateforme, et ce qui tourne déjà en production.

    Voir