📢Mon système est-il une DPI?
Last updated
Last updated
L'écosystème des DPI est en pleine effervescence : les gouvernements construisent des DPI en partant de zéro, des projets open-source et des biens publics numériques (DPGs) développent des solutions de DPI, des bailleurs de fonds soutiennent la mise en œuvre de DPI et des fournisseurs privés commercialisent leurs projets de DPI.
Cependant, tout ce qui est étiqueté comme DPI n'est pas nécessairement fonctionnel en tant que tel. Comment identifier rapidement si un système ou une solution est une véritable architecture DPI ?
Avant d'entrer dans le vif du sujet, rappelons quelques points essentiels :
Open source ne signifie pas automatiquement DPI, et les implémentations DPI ne doivent pas s'appuyer uniquement sur des solutions open-source.
Les mises en œuvre de DPI doivent utiliser des API ouvertes, des normes ouvertes et des spécifications ouvertes pour parvenir à l'interopérabilité et à la réutilisation.
Toutes les mises en œuvre de DPI sont conçues pour être réutilisables par des institutions publiques et privées tierces, et ne pas profiter uniquement à l'institution qui les met en œuvre.
Chaque mise en œuvre de DPI doit respecter et internaliser cinq principes de design technique
Remarque : la question de savoir s'il s'agit ou non d'une DPI ne doit pas être envisagée comme un critère de liste de contrôle oui/non ; au contraire, un bien numérique peut gagner en maturité en tant que DPI pour l'écosystème en fonction de la valeur ajoutée et du potentiel d'innovation qu'il offre à des coûts abordables pour les cas d'utilisation publics et privés.
Cela dit, nous présentons ci-dessous quelques caractéristiques techniques essentielles qui peuvent contribuer à faire progresser certains systèmes ou actifs numériques clés vers la maturité, en vue de devenir une infrastructure numérique publique robuste pour l'écosystème.
Pour qu'un système d'identification numérique fonctionne comme une DPI, il doit être doté d'une couche d'authentification ID. Cela signifie que le système doit être en mesure de traiter les demandes et de renvoyer les réponses par oui/non pour les demandes de vérification.
Pour l'inclusion, la mise en œuvre peut également prendre en charge plusieurs modes d'authentification (connus sous le nom d'authentification multimodale) pour une plus grande inclusivité. Par exemple, les modes en ligne (API d'authentification, mot de passe unique par courriel), connecté 2G (mot de passe unique mobile) et hors ligne (QR vérifiable sur papier), plusieurs modes d'authentification biométrique tels que la correspondance des empreintes digitales, la correspondance du visage, la correspondance de l'iris, etc.
En outre, les systèmes d'identification les plus aboutis devraient permettre les fonctionnalités suivantes :
eKYC (Partage des données de profil basé sur l'API sur la base d'une authentification réussie pour faciliter l'accès à un service public ou privé externes)
Single Sign-On (permettre de se connecter à d'autres biens et services publics ou privés par l'intermédiaire de l'identifiant)
e-signature (le remplacement d'une signature manuscrite par une signature électronique avec identification), qui contribuent tous à la mise en place d'une économie numérique de haute confiance.)
Registres contenant des données à caractère personnel :
Les registres sont l'une des applications de numérisation les plus courantes, souvent considérées comme de simples bases de données.
Une implémentation de registre peut être considérée comme une DPI si elle stocke des données dans un format lisible par machine et signé numériquement, auquel des parties externes - publiques et privées - peuvent accéder
a. La première façon, et la plus simple, de permettre le partage des données en utilisant les registres pour générer des identifiants vérifiables pour le titulaire en tant que sortie naturelle des données stockées.
b. Les registres fonctionnant comme des DPI matures peuvent également permettre l'accès d'un système à l'autre directement via des API ouvertes. Ces normes d'API ouvertes peuvent provenir de normes nationales auto-définies ou dérivées de spécifications ouvertes bien acceptées comme les API G2P Connect/ DCI.
3. Infrastructure des paiements numériques :
a. Paiements Peer-to-Peer/Person-to-Merchant (P2P/P2M)
Souvent, les systèmes de paiement instantané de banque à banque sont présentés comme des implémentations de DPI. Toutefois, pour qu'une infrastructure de paiement P2P/P2M fonctionne véritablement comme une DPI, elle doit être
Inclusive: L'infrastructure doit pouvoir être utilisée par la majorité de la population sans obstacle technologique ou financier important.
Interopérable: Pour fonctionner en tant que DPI mature, un rail de paiement doit permettre les mouvements d'argent entre les pays :
Tout compte utilisé pour le paiement (banque, portefeuille, argent mobile, lignes de crédit)
Toute application utilisée pour payer (banque, portefeuille, Mobile Money, Fintech)
Tout appareil ou canal (téléphones fixes, machines PoS, smartphones, autocollants QR ; en ligne/hors ligne, QR dynamique)
Tout destinataire du paiement (P2P, P2M, P2G, G2P, etc.)
Cela représente l'état idéal (bien qu'évolutif) de la nature des paiements DPI. Les pays n'ont pas besoin de construire tout cela dès le premier jour - ils peuvent ajouter des capacités au fur et à mesure qu'ils construisent, mais l'architecture initiale doit être à l'épreuve du temps, programmable et facilement extensible pour permettre l'ajout aisé de nouvelles fonctionnalités.
Les prestations de gouvernement à personne (G2P) constituent un écosystème complexe comprenant de nombreux modules, notamment la gestion des régimes, la gestion des bénéficiaires, les systèmes de décaissement, les systèmes de règlement et les systèmes cash-in/cash-out sur le dernier kilomètre, tous répartis entre différents services.
La présence d'une infrastructure G2P numérisée n'implique pas automatiquement la mise en œuvre d'une DPI. Certains modules, tels que la gestion du régime de bénéficiaires, sont simplement des solutions numériques.
Les systèmes G2P peuvent fonctionner comme des DPI en utilisant une infrastructure réutilisable, telles que les registres, un mapper identifiant-compte, et les standards cash in cash out .
Les données collectées sur les bénéficiaires peuvent être converties en registre afin d'être réutilisées par d'autres services (voir le point 2 sur les registres).
Un mappeur identifiant-compte (un registre à quatre champs établissant une correspondance entre un numéro d'identification ou de téléphone vérifiable et un numéro de compte) peut être utilisé pour acheminer les paiements sans répétition.
4. Infrastructure de partage de données - Personnel :
a. Des identifiants vérifiables centrés sur l'utilisateur
L'émission numérique de certificats PDF dans une application ou une plateforme dédiée n'est pas considérée comme une approche DPI en soi. Les identifiants fonctionnent comme des DPI lorsqu'ils sont signés numériquement, lisibles par une machine et qu'ils peuvent être partagés avec n'importe qui et vérifiés par n'importe qui. L'ajout de QR signés à un certificat PDF est un moyen simple et rapide de convertir un certificat numérique en DPI. Pour les DPI de partage de données plus matures, les normes API pour le partage des identifiants et le schéma pour la définition du contenu devraient être harmonisés au niveau national.
b. Réseaux de partage de données en temps réel de système à système
Un entrepôt de données centralisé ou un répertoire de données à caractère personnel n'est généralement pas considéré comme une DPI (à moins qu'il ne soit décrit comme un registre ci-dessus). L'approche DPI consiste à créer des réseaux fédérés et ouverts de partage de données où tout consommateur ou fournisseur de données peut se connecter pour recevoir ou partager des données selon les règles du réseau. Il est fortement recommandé de recueillir le consentement de l'utilisateur dans le cadre de ce flux. Des normes API ouvertes (pour le partage des données) et des schémas devront être définis au niveau sectoriel/national.
Infrastructure de partage des données - Données anonymes :
Le chargement de PDF ou de fichiers Excel en masse pour la consommation publique n'est généralement pas considéré comme une DPI, en raison de son faible potentiel de réutilisation. Les données agrégées anonymisées doivent être mises à la disposition de tiers dans un format exploitable par machine, avec des interfaces de programmation (API) pour l'accès. Des autorisations et des conditions de licence peuvent être définies pour ces ensembles de données.
Unifier les services gouvernementaux :
De nombreux gouvernements utilisent une solution de type Enterprise Services Bus (ESB) pour unifier les différents services fournis par le gouvernement dans une application ou un portail à guichet unique. Si cette architecture est utile, elle est aussi très complexe, difficile à maintenir et à faire évoluer, et nécessite un consensus interdépartemental.
L'approche DPI serait que chaque département ouvre ses API pour un service et les publie pour que des tiers les consomment et les intègrent dans leurs flux de travail. Le département des TIC, par exemple, pourrait compiler toutes ces API ouvertes et les rendre facilement accessibles à des fins d'intégration.
Par ailleurs, les Services Bus gouvernementaux existants pourraient ouvrir collectivement les API pour tous les services qu'ils ont agrégés.
Remarque : cet article ne traite que des paramètres techniques ; une bonne gouvernance participative et des innovations de marché inclusives sont tout aussi cruciales pour la mise en œuvre d'une DPI.
