Toute équipe qui construit un produit réglementé en Arabie saoudite se heurte au même mur, la même semaine. Quelqu'un dit en réunion « il faut vérifier l'identité du client », tout le monde acquiesce, puis l'architecture part de travers pendant deux mois — parce que « vérifier l'identité » désigne trois services totalement différents, chacun opéré par un acteur distinct, avec son propre processus d'accès, son propre modèle de facturation et son propre régulateur.
Nous avons vu ce scénario se répéter sur des parcours d'ouverture de compte fintech, des moteurs de tarification en assurance et des places de marché B2B. Le schéma est toujours le même : une équipe intègre Nafath, met en production, puis découvre en revue de conformité que Nafath ne lui a jamais dit si le nom saisi par le client correspondait au registre d'état civil. Ou l'inverse : une équipe souscrit à Yakeen, bâtit un beau pipeline de rapprochement de données, et constate qu'elle n'a aucun moyen de prouver que la personne devant l'écran est bien le titulaire du numéro d'identité interrogé.
Ces services ne sont pas concurrents. Ce sont des couches distinctes. Voici comment les distinguer avant d'écrire la moindre ligne de code.
Les trois couches, énoncées simplement
Nafath (النفاذ الوطني الموحد) répond à : cette personne est-elle présente, maintenant, et consent-elle ?
Nafath est une couche d'authentification. C'est l'authentification unique nationale, opérée par Elm pour le compte de l'Autorité du gouvernement numérique. L'utilisateur est redirigé vers Nafath, approuve la demande dans l'application Nafath ou via un code SMS, et votre système reçoit une assertion signée via OAuth2/OIDC attestant qu'un titulaire précis d'identité nationale ou d'Iqama a activement approuvé cette transaction.
Ce que Nafath vous donne, c'est la présence et le consentement. Ce qu'il ne vous donne pas, c'est une vue structurée et complète du dossier d'état civil de cette personne.
Yakeen (يقين) répond à : les données fournies par cette personne correspondent-elles au registre officiel ?
Yakeen est une couche de vérification d'attributs. Opérée par Elm, elle interroge le Centre national d'information (NIC) — le registre d'état civil du ministère de l'Intérieur — ainsi que Saudi Post pour l'adresse nationale. Vous envoyez un identifiant (identité nationale pour les citoyens, Iqama pour les résidents, numéro de visa pour les visiteurs) accompagné d'un champ corroborant, et vous recevez le dossier officiel : nom complet en arabe et en anglais, date de naissance, sexe, nationalité, statut et date d'expiration du titre, adresse nationale, et pour les résidents les informations de sponsor et de profession.
Ce que Yakeen vous donne, c'est la véracité des données. Ce qu'il ne vous donne pas, c'est la preuve que la personne qui les fournit en est le titulaire.
Wathq (واثق) répond à : cette entreprise existe-t-elle, et cette personne peut-elle agir en son nom ?
Wathq est une couche de vérification d'entité, opérée par Thiqah en partenariat avec le ministère du Commerce. Elle transforme un registre de commerce (سجل تجاري) en statut d'entreprise, activités, capital et — surtout — liste des signataires autorisés et des dirigeants. C'est le pendant « entreprise » des deux services « personne » ci-dessus.
Nous avons traité en profondeur le volet vérification d'entreprise dans notre guide Maroof et Wathq pour la vérification des marchands ; cet article reste donc du côté des personnes physiques.
Le tableau qui met fin au débat
Placez votre besoin réel dans la colonne de gauche et la réponse s'impose.
| Votre besoin | Nafath | Yakeen | Wathq |
|---|---|---|---|
| Prouver que l'utilisateur est présent et consent | Oui | Non | Non |
| Confirmer que le nom et la date de naissance saisis sont réels | Partiellement | Oui | Non |
| Récupérer l'adresse nationale | Non | Oui | Non |
| Vérifier la validité d'une identité ou d'une Iqama | Non | Oui | Non |
| Vérifier un résident par numéro d'Iqama | Oui | Oui | Non |
| Vérifier un visiteur sous visa | Non | Oui | Non |
| Confirmer qu'une entreprise existe et est active | Non | Non | Oui |
| Identifier le signataire autorisé de l'entreprise | Non | Non | Oui |
| Fonctionne sans que l'utilisateur soit en ligne | Non | Oui | Oui |
Cette dernière ligne décide de la plupart des architectures. Nafath exige un humain présent qui valide une notification. Yakeen et Wathq sont des appels serveur à serveur qui fonctionnent dans un traitement nocturne, dans une file de revue back-office ou dans un job de scoring de fraude à trois heures du matin. Si votre cas d'usage est « rescanner notre portefeuille de 40 000 clients à la recherche de titres expirés », Nafath est structurellement le mauvais outil, et aucune ingénierie ne corrigera cela.
La plupart des produits réglementés ont besoin de deux couches, pas d'une
Le schéma mature dans l'onboarding fintech saoudien est une articulation entre les deux :
- Nafath établit la présence. L'utilisateur s'authentifie et consent. Vous détenez désormais une assertion signée liée à un numéro d'identité ou d'Iqama précis.
- Yakeen enrichit et valide. Avec l'identifiant que Nafath vient de prouver, vous récupérez le dossier officiel et préremplissez le formulaire — ou vous le comparez à la saisie de l'utilisateur et rejetez en cas d'écart.
- Wathq n'intervient que si le compte est un compte entreprise, pour résoudre le registre de commerce et confirmer que la personne de l'étape 1 figure parmi les signataires autorisés.
Notez l'ordre : Yakeen après Nafath, jamais avant. Lancer Yakeen d'abord, sur un identifiant simplement saisi dans un formulaire, vous apprend seulement que ce numéro appartient à une personne réelle — pas qu'il appartient à la personne en face de vous. C'est précisément cette distinction qu'exploite la fraude par usurpation d'identité, et c'est le défaut de conception le plus fréquent que nous rencontrons lors des revues d'onboarding en Arabie saoudite.
Le modèle d'accès est le vrai risque projet
C'est ici que budgets et calendriers dérapent réellement : aucun de ces services n'est en libre-service. Pas de page d'inscription, pas de paiement par carte, pas d'offre gratuite pour commencer à prototyper cet après-midi.
L'accès à Yakeen est intermédié et rattaché à l'entité. Vous l'obtenez soit directement auprès d'Elm, soit via un revendeur agréé tel que Rabet, et pour les structures plus petites via le package باقة رواد (Rowad) de la SDAIA et de Monshaat destiné aux startups et PME. Quel que soit le canal, trois contraintes en découlent :
- Les identifiants appartiennent à l'établissement, pas à vous. L'accès est délivré contre un registre de commerce et une finalité déclarée. Si vous êtes une agence qui construit pour un client, c'est le client qui souscrit et qui détient les identifiants. Vous ne pouvez pas revendre votre propre accès à plusieurs clients, et structurer le projet comme si vous le pouviez est la manière dont les intégrations sont coupées après le lancement.
- La facturation est à la requête. Les tarifs publiés chez les revendeurs pour des services de vérification Elm voisins tournent autour de 2 SAR par requête aboutie, avec des plafonds de l'ordre de 120 requêtes par minute. Quelle que soit votre offre exacte, la conséquence architecturale est fixe : chaque appel Yakeen est une ligne de coût. Mettez en cache agressivement, dédupliquez au niveau applicatif, et ne placez jamais une requête dans une boucle de reprise qu'un client peut déclencher.
- Le délai se compte en semaines. Dossier de souscription, justification de finalité et intégration technique précèdent tous votre premier appel en bac à sable. Prévoyez-le au planning plutôt que de le découvrir au troisième sprint.
Le protocole est plus ancien que votre stack. Yakeen est un service SOAP/XML. Les documents d'intégration en circulation décrivent des opérations du type informations citoyen par identité nationale, informations résident par Iqama, et des opérations d'adresse distinctes selon le type de titre — une opération par besoin de données, plutôt qu'une requête flexible unique. Presque toute intégration sérieuse place donc une façade REST interne devant, qui parle JSON à votre produit et XML à Elm. Budgétez cet adaptateur, son mapping de schéma et sa traduction d'erreurs : ce n'est pas un wrapper qu'on écrit en une après-midi.
Les contraintes de conformité que personne ne lit avant l'audit
La SAMA a rendu Yakeen optionnel et le consentement obligatoire. La circulaire de la Banque centrale saoudienne n° 371000018071 du 23 novembre 2015 autorise les banques à vérifier électroniquement l'identité de leurs clients via Yakeen. Deux conditions ont des conséquences architecturales directes : l'accord préalable du client doit être obtenu avant tout accès électronique aux informations d'identité, et le client ne supporte aucun frais supplémentaire. Si votre recueil de consentement est une case à cocher enfouie dans les conditions générales, vous n'avez pas le consentement visé par la circulaire.
Un appel Yakeen ne vous libère pas de la mise à jour périodique KYC. La même circulaire précise que l'usage du service ne doit pas porter atteinte aux exigences de mise à jour périodique de l'identité. Les équipes supposent souvent que pouvoir réinterroger le registre à la demande supprime le cycle de rafraîchissement planifié. Ce n'est pas le cas. Construisez quand même le job de rafraîchissement.
La PDPL s'applique à tout ce que vous récupérez. Extraire des attributs d'état civil constitue un traitement de données personnelles au sens de la loi saoudienne sur la protection des données personnelles. Il vous faut une base légale, une durée de conservation définie, et une vraie réponse à la question de savoir pourquoi vous stockez le dossier complet plutôt qu'un résultat de vérification. Notre recommandation pratique : conserver un résultat booléen, un horodatage et une référence de requête, puis supprimer la charge utile une fois le rapprochement tranché — vous gardez votre piste d'audit tout en réduisant votre surface de fuite. Lorsque le traitement traverse les frontières, les règles de transfert s'appliquent aussi ; nous les détaillons dans PDPL saoudienne et transferts de données transfrontaliers.
Une esquisse de conception, pas un contrat d'API
La forme ci-dessous est volontairement agnostique du protocole — considérez-la comme l'interface interne contre laquelle votre produit doit coder, les détails SOAP restant isolés derrière l'adaptateur. Les noms d'opérations et listes de champs exacts proviennent du pack d'intégration qu'Elm vous remet à la souscription.
// Votre façade interne — stable, JSON, cacheable.
interface IdentityCheck {
// Couche 1 : qui est présent (issu de l'assertion Nafath)
subjectId: string; // identité nationale ou Iqama, prouvée par Nafath
assertionRef: string; // référence du jeton OIDC signé
// Couche 2 : ce que dit le registre (Yakeen, via l'adaptateur)
registryMatch: boolean; // les champs déclarés correspondent-ils ?
idStatus: "valid" | "expired" | "not_found";
checkedAt: string; // horodatage pour la piste d'audit
}
// Stockez ceci. Ne stockez pas la charge utile brute du registre.La règle : votre produit ne devrait jamais importer un client SOAP. Il devrait appeler un seul point d'entrée interne qui renvoie l'objet ci-dessus, et tout ce qui est désagréable — enveloppes XML, codes de facturation, particularités par opération, politique de reprise, comptabilité des coûts — vit dans un service unique que vous pouvez limiter en débit et observer séparément.
Ce que cela implique pour votre feuille de route
Si vous cadrez un lancement en Arabie saoudite, trois décisions relèvent de la première semaine et non du troisième mois : quelles couches votre régulateur exige réellement, qui détient juridiquement la souscription Yakeen, et où se situe l'adaptateur dans votre architecture. Se tromper sur ces trois points n'est pas un bug que l'on corrige — c'est une reconstruction.
Ce raisonnement en couches vaut pour le reste des plateformes gouvernementales saoudiennes. Les systèmes de paie touchent à Mudad et WPS, les SIRH à Qiwa et Nitaqat, et les flux de résidence à Muqeem. Tous partagent le même schéma d'accès : identifiants intermédiés, facturation à la requête, protocole plus ancien que prévu, et une circulaire du régulateur qui change ce que votre code a le droit de faire.
Vous ne savez pas quelle couche de vérification votre produit exige réellement ? Nous confrontons le besoin à votre régulateur, à votre position sur la résidence des données et à votre stack existante, avant que quiconque n'ouvre une souscription — généralement en une seule séance de travail. Racontez-nous ce que vous construisez et nous vous dirons honnêtement lesquelles de ces trois couches vous sont nécessaires, et lesquelles ne le sont pas.