Le formulaire a été soumis avec succès.
Vous trouverez de plus amples informations dans votre boîte aux lettres.
Nous recruterSélection de la langue
À propos
ServicesTechnologiesProjets
Vous l'avez probablement vu vous-même : donnez à GPT un selfie, demandez un document de type passeport et, en quelques minutes, vous obtenez quelque chose qui peut passer les contrôles visuels de base. Ajoutez à cela le clonage de la voix et la vidéo synthétique, et la “vivacité” commence à ressembler à du théâtre. C'est là que se situe la véritable rupture dans l'identité numérique en Europe. 2026. Le modèle KYC basé sur la photo est lui-même en train de s'épuiser. Si la preuve d'identité dépend toujours d'images difficiles à falsifier, on construit sur du sable.
Où cela nous mène-t-il ? Un changement assez évident : l'abandon du stockage des données d'identité au profit d'une vérification cryptographique des demandes. Au lieu de collecter un scan de passeport et de le stocker dans une autre base de données, le système demande des preuves : avez-vous plus de 18 ans, avez-vous passé le KYC, êtes-vous autorisé à effectuer cette transaction, et... ? Pouvez-vous le prouver sans révéler quoi que ce soit d'autre ?
Mais qu'est-ce qui change exactement ? Pourquoi parlons-nous soudain de DID et de références vérifiables ?
En effet, dans un modèle basé sur la DID, la confiance ne dépend pas de l'apparence d'un objet. Elle dépend de la personne qui l'a signé et du fait que vous pouvez prouver que vous en avez le contrôle. Un faux selfie n'est d'aucune utilité si le vérificateur s'attend à un titre signé par un émetteur de confiance et lié à vos clés cryptographiques. Vous n'essayez plus d'avoir l'air réel. Vous prouvez que vous êtes en possession d'un document valide et signé. Les images cessent d'être la source de confiance. Les signatures prennent le relais.
C'est l'objet de ce guide : Je montrerai comment ce modèle fonctionne, pourquoi il est en train de devenir la voie à suivre, et où la blockchain s'inscrit dans ce modèle.
Un identifiant décentralisé, ou DID, est un identifiant basé sur un URI conçu pour être contrôlé par des clés cryptographiques plutôt que d'être émis et géré par un répertoire central. Dans le cadre de la Consortium World Wide Web (W3C) DID, un DID se résout en un document DID qui informe d'autres systèmes sur la manière de vérifier les signatures, d'authentifier le contrôleur ou de découvrir les points d'extrémité des services associés à cet identifiant. En clair, un DID n'est pas votre profil, votre passeport ou votre dossier de compte. C'est le pointeur que les autres parties utilisent pour vérifier que vous contrôlez un identifiant spécifique et les clés qui le sous-tendent.
C'est là que les gens se contentent souvent de dire qu'il s'agit d'une “autre carte d'identité”. Ce n'est pas le cas.
Une adresse électronique est en fait un localisateur dans le système de quelqu'un d'autre. Si le fournisseur suspend le compte, l'identifiant disparaît. Un numéro de sécurité sociale est un identifiant délivré par l'État, mais il n'a pas de couche de preuve cryptographique intégrée ; quiconque obtient le numéro peut le rejouer. Les jetons OAuth sont encore différents : il ne s'agit pas du tout d'identifiants d'identité, mais d'artefacts d'accès délégués émis par un serveur d'autorisation pour qu'un client puisse appeler une ressource protégée. Utile, oui. Couche d'identité portable, non.
La DID fonctionne différemment. Elle est censée être résolue, et non pas simplement recherchée dans une base de données de fournisseurs. Le contrôle appartient au sujet par le biais du matériel clé et des règles de la méthode DID, et non à un fournisseur de courrier, à une plateforme SaaS ou à un courtier en identité. Cette distinction est importante dans la pratique. Si vous créez des informations d'identification réutilisables, des connexions basées sur un portefeuille ou des flux de vérification qui doivent fonctionner au-delà des frontières organisationnelles, un identifiant d'utilisateur spécifique à un courrier électronique ou à une application n'apportera pas suffisamment de sémantique de confiance. Un DID peut l'être.
Au niveau de la syntaxe, le modèle du W3C est simple : un DID comporte trois parties : le schéma DID, un nom de méthode et un identifiant spécifique à la méthode. En d'autres termes : did:méthode:identifiant.
Prendre did:web:exemple.com comme exemple concret.
Avec did:web, La résolution d'un domaine est généralement liée à un document DID publié sur un site HTTPS bien connu de ce domaine. Avec quelque chose comme did:ethr, La résolution du problème dépend des règles de la méthode liée à Ethereum. Même syntaxe DID, modèle de confiance et de mise à jour différent.
C'est le point essentiel : la chaîne DID elle-même n'est qu'une poignée. La méthode vous indique comment la résoudre. Le document DID vous donne le matériel de vérification. Une fois que vous l'avez obtenu, vous pouvez vérifier les signatures, authentifier un titulaire ou valider la présentation d'un titre sans traiter l'identifiant comme une ligne de plus dans la table des utilisateurs de quelqu'un d'autre.
Jusqu'à présent, nous avons considéré les DID et les références vérifiables comme des structures de données : identifiants, documents, signatures. Mais ce n'est qu'une partie d'un système d'identité fonctionnel. Dans les déploiements réels, le problème le plus difficile est celui de l'interaction : comment les titres sont émis, comment ils sont présentés et comment les vérificateurs décident de leur accorder ou non leur confiance.
Dans les systèmes de production tels que le Portefeuille d'identité numérique de l'UE ou Permis de conduire mobile américain (mDL) Les pilotes, les portefeuilles et les vérificateurs ne se contentent pas de “résoudre un DID” et de s'arrêter là. Ils communiquent par le biais de protocoles définis et de formats de justificatifs :
La distinction importante réside dans le fait que les DID et les références vérifiables définissent ce que est vérifié. Ces protocoles définissent comment il circule entre l'émetteur, le détenteur et le vérificateur dans les systèmes réels.
Sans cette couche, les DID restent un mécanisme de résolution. Avec cette couche, ils font partie d'une infrastructure d'identité fonctionnelle.
L'identité décentralisée est un modèle dans lequel les identifiants, les références et les flux de vérification ne sont pas contrôlés par un fournisseur unique. Au lieu de cela, l'identité est ancrée dans des clés cryptographiques (via des DID), et les revendications relatives à cette identité sont émises et vérifiées indépendamment de l'endroit où elles sont utilisées. Une façon utile d'y penser : l'identité cesse d'être un compte stocké dans la base de données de quelqu'un d'autre et devient un ensemble de déclarations vérifiables que vous contrôlez et réutilisez.
Comparons cela aux modèles avec lesquels vous travaillez déjà.
L'identité centralisée est toujours la solution par défaut. Une plateforme possède le dossier de l'utilisateur, stocke vos données et fait office d'autorité de vérification. Si vous voulez avoir accès, vous vous authentifiez auprès de ce système. Tout, y compris la connexion, les autorisations, la récupération, passe par ce système.
Le problème n'est pas seulement la sécurité (bien que les brèches soient un problème constant). Il s'agit de l'architecture :
L'identité décentralisée renverse cette situation. Le système n'a pas besoin de stocker vos données. Il n'a besoin que de vérifier les affirmations que vous présentez. La confiance passe de “nous avons vos données” à “nous pouvons vérifier cette preuve cryptographique”.”
L'identité fédérée (OAuth, SAML, OpenID Connect) a tenté de résoudre la fragmentation en introduisant des fournisseurs d'identité, tels que Google, Microsoft ou Apple, qui se portent garants des utilisateurs à travers les services.
Cela fonctionne, jusqu'à un certain point. Mais l'identité fédérée a toujours une dépendance centrale :
L'identité décentralisée supprime cette dépendance. Il n'y a pas d'émetteur unique qui doit être en ligne au moment de la vérification. Les justificatifs sont vérifiés par le biais de signatures, et non d'appels d'API. Cela signifie que :
Le fonctionnement est plus proche de celui des titres de compétences physiques : vous n'appelez pas le bureau des passeports chaque fois que quelqu'un vérifie votre carte d'identité.
Ces termes sont souvent confondus. Le SSI est plutôt une philosophie de conception : l'individu contrôle son identité, choisit ce qu'il veut partager et n'est pas lié à un fournisseur. L'identité décentralisée est la pile technique qui rend cela possible :
Vous pouvez mettre en œuvre des systèmes d'identité décentralisés qui ne sont pas totalement “autosouverains” (par exemple, des portefeuilles contrôlés par l'entreprise ou des réseaux autorisés). Et vous pouvez parler de SSI sans spécifier l'infrastructure. Dans les systèmes réels, les deux convergent généralement, mais il est utile de garder la distinction claire lorsque vous concevez des architectures.
Les portefeuilles sont l'endroit où l'identité décentralisée rencontre les contraintes du monde réel. En théorie, le contrôle de l'identité passe par le contrôle des clés cryptographiques. En pratique, cela pose un problème que les systèmes traditionnels n'ont pas : que se passe-t-il lorsque l'utilisateur perd son accès ?
Si une DID est liée à une clé privée et que cette clé est perdue, il n'y a pas de mécanisme de récupération par défaut. Il n'y a pas de flux de “réinitialisation du mot de passe” à moins que le système ne soit explicitement conçu pour le supporter. La perte de la clé peut entraîner une perte de contrôle sur l'identifiant et les informations d'identification qui lui sont liées.
C'est pourquoi les systèmes de production introduisent des modèles de récupération et de conservation en plus de la couche DID :
Le compromis est inévitable : plus le contrôle passe à l'utilisateur, plus la responsabilité de la gestion des clés augmente. C'est pourquoi la plupart des déploiements dans le monde réel équilibrent l'autosouveraineté et la facilité d'utilisation au lieu de confier la propriété totale des clés à l'utilisateur.
Cela vaut la peine de s'arrêter ici, car l'identité basée sur la DID n'est vraiment efficace que lorsque l'on sépare ses primitives de base. L'identifiant n'est pas la carte de crédit, la carte de crédit n'est pas le portefeuille, et le marqueur sur la chaîne n'est pas l'identité elle-même. Chaque couche a une fonction distincte, et c'est cette séparation qui permet au modèle de fonctionner.
Ces deux composants constituent le cœur du modèle d'identité décentralisé. Dans certains systèmes, en particulier dans les environnements Web3, des mécanismes supplémentaires sur la chaîne sont utilisés pour renforcer l'accès ou les rôles.
Jetons d'âme (SBT) en sont un exemple. Il s'agit de jetons non transférables liés à un portefeuille et utilisés pour des choses telles que le contrôle KYC, l'accréditation ou les autorisations de protocole. Les contrats intelligents peuvent les vérifier directement.
Cependant, les SBT ne font pas partie de la pile d'identité elle-même. Il s'agit d'une couche d'application facultative construite au-dessus des signaux d'identité, et ils s'accompagnent de compromis : visibilité publique sur la chaîne, portabilité limitée, et défis liés à la révocation et à la récupération des clés.
Les systèmes d'identité traditionnels échouent parce qu'ils traitent la confiance comme un problème de stockage. Chaque plateforme collecte les mêmes preuves brutes, telles que les scans de passeport, les selfies et les justificatifs de domicile, puis les stocke à l'intérieur de son propre périmètre de conformité. Cela crée le même désordre partout : duplication des IIP, faible portabilité, vastes surfaces d'infraction et flux d'intégration qui s'alourdissent sans s'améliorer.
Dans le modèle traditionnel, les systèmes d'identité accumulent les risques au fil du temps. Les fournisseurs de services KYC, les bourses, les applications fintech, les plateformes RH et les places de marché finissent tous par stocker à peu près le même ensemble de preuves : pièce d'identité gouvernementale, scan du visage, données d'adresse et métadonnées de la session de vérification elle-même.
Du point de vue de la mise en œuvre, le problème est généralement aggravé par la prolifération des copies. Les mêmes données utilisateur se retrouvent dans les systèmes d'accueil, les outils de lutte contre la fraude, les couches CRM, les outils d'assistance, les entrepôts de données et les archives de conformité. Même si la pile de vérification primaire est verrouillée, les systèmes environnants ne sont souvent pas soumis à la même norme.
L'identité traditionnelle ne donne à l'utilisateur pratiquement aucun contrôle sur l'état de la vérification. La plateforme contrôle l'enregistrement, la politique de conservation, le calendrier de revérification et les règles de réutilisation.
Cela signifie que l'utilisateur ne peut pas transférer sa confiance d'un contexte à l'autre. Le fait de passer le KYC sur la plateforme A ne sert à rien sur la plateforme B, car le résultat de la vérification est piégé à l'intérieur du périmètre de conformité de la plateforme A. L'affirmation sous-jacente peut toujours être valable, mais il n'y a pas d'artefact cryptographique portable sur lequel le prochain vérificateur puisse s'appuyer.
C'est là que le modèle commence à se casser la figure sur le plan économique. Chaque plateforme paie pour reconstruire la confiance à partir de zéro parce que l'identité est stockée en tant que données internes, et non pas émise en tant que preuve réutilisable.
Le modèle hérité révèle également trop de choses par défaut. Pour prouver un fait précis, les utilisateurs sont généralement invités à divulguer l'intégralité du document source qui le sous-tend.
Il s'agit là d'un mauvais modèle de protection de la vie privée, mais aussi d'un mauvais modèle de système. Une fois que l'identité est liée à des enregistrements basés sur des comptes et à la soumission répétée de documents, la corrélation devient facile entre les services, les sessions et les contreparties. Le vérificateur obtient plus de données qu'il n'en a besoin, en stocke plus qu'il ne le devrait et augmente sa responsabilité sans améliorer proportionnellement la qualité de la confiance.
Il s'agit de la taxe opérationnelle que tout le monde connaît déjà. La même personne remplit le formulaire KYC à plusieurs reprises parce que chaque plateforme utilise sa propre pile de confiance et ne peut pas utiliser la vérification comme un justificatif portable.
Si vous avez travaillé sur la tokenisation, l'onboarding des bourses ou les flux de portefeuilles réglementés, vous avez vu à quel point cette situation est source de gaspillage. Le goulot d'étranglement est dû au fait que la confiance ne peut pas circuler proprement entre les systèmes, de sorte que chaque institution reconstruit le même pipeline de vérification autour de la limite de sa propre base de données.
Et même des références vérifiables ne suffisent pas à résoudre ce problème. Une signature valide prouve seulement qu'une revendication a été émise par une partie spécifique. Elle ne prouve pas que cette personne avait le pouvoir d'émettre cette déclaration. C'est cet aspect que de nombreux pilotes DID sous-estiment. Les vérificateurs doivent savoir quels émetteurs sont légitimes, quels schémas d'identification sont acceptés et selon quelles règles on peut se fier à une demande.
En production, cela est géré par des cadres de confiance : eIDAS 2.0 listes de confiance dans l'UE, Style VICAL coordination de la confiance pour les permis de conduire mobiles selon la norme ISO 18013-5, Fédération OpenID les chaînes de confiance et les registres nationaux de prestataires de services de confiance.
Sans cette couche, il n'y a pas d'identité réutilisable. Vous obtenez des références qui se vérifient mathématiquement mais qui ne signifient rien sur le plan opérationnel. La signature est valide. La confiance est absente.
"Pourquoi le modèle d'identité décentralisée fonctionne-t-il ? Parce que chaque partie a moins à stocker, moins à exposer et moins à revérifier. L'utilisateur réutilise une preuve de confiance, le vérificateur n'obtient que la déclaration dont il a besoin et la plateforme évite de devenir un autre coffre-fort d'informations confidentielles. À Innowise, cela signifie généralement des références hors chaîne pour la portabilité, des attestations sur chaîne pour le contrôle d'accès et une divulgation sélective pour les vérifications sensibles à la vie privée."
Expert en blockchain et analyste DeFi
Assez de définitions. Ce qui importe ici, c'est le chemin de vérification : comment un DID devient résoluble, comment un émetteur y associe une revendication et comment cette revendication est vérifiée ultérieurement sans passer par un registre central. Examinons le processus de bout en bout.
Un DID ne devient utile que lorsqu'il peut être résolu. Il est généré avec des clés et publié selon une méthode DID. La résolution renvoie le document DID, qui expose les clés publiques et les méthodes de vérification utilisées par d'autres pour valider les signatures.
Une fois que le sujet dispose d'un DID, un émetteur peut y attacher une créance signée en tant que justificatif vérifiable. L'émetteur effectue d'abord ses vérifications, puis signe un titre qui lie la demande à l'identifiant du sujet. Ce qui progresse n'est pas une preuve brute, mais un résultat attesté.
Le détenteur conserve le titre, généralement dans un portefeuille, et le présente lorsqu'une preuve est requise. Selon la pile, il peut s'agir du titre complet ou d'une preuve dérivée. Il s'agit d'une réutilisation : le titulaire présente une demande déjà vérifiée au lieu de recommencer l'onboarding.
Le vérificateur vérifie la signature de l'émetteur, confirme la liaison avec le sujet et évalue l'état du titre, comme l'expiration ou la révocation. Pour ce faire, il résout le DID de l'émetteur et récupère la clé publique du document DID. Aucun rappel de l'émetteur n'est nécessaire.
Un DID ne devient utile que lorsqu'il peut être résolu. Il est généré avec des clés et publié selon une méthode DID. La résolution renvoie le document DID, qui expose les clés publiques et les méthodes de vérification utilisées par d'autres pour valider les signatures.
Une fois que le sujet dispose d'un DID, un émetteur peut y attacher une créance signée en tant que justificatif vérifiable. L'émetteur effectue d'abord ses vérifications, puis signe un titre qui lie la demande à l'identifiant du sujet. Ce qui progresse n'est pas une preuve brute, mais un résultat attesté.
Le détenteur conserve le titre, généralement dans un portefeuille, et le présente lorsqu'une preuve est requise. Selon la pile, il peut s'agir du titre complet ou d'une preuve dérivée. Il s'agit d'une réutilisation : le titulaire présente une demande déjà vérifiée au lieu de recommencer l'onboarding.
Le vérificateur vérifie la signature de l'émetteur, confirme la liaison avec le sujet et évalue l'état du titre, comme l'expiration ou la révocation. Pour ce faire, il résout le DID de l'émetteur et récupère la clé publique du document DID. Aucun rappel de l'émetteur n'est nécessaire.
Une fois que le flux est clair, les vraies questions de conception apparaissent : comment les identificateurs sont utilisés et comment les clés sont gérées dans le temps.
Une DID publique est stable et découvrable. Les émetteurs l'utilisent généralement parce que les vérificateurs ont besoin d'une méthode cohérente pour résoudre les clés et valider les signatures. Un DID par paire, en revanche, est généré par relation. Le même utilisateur présente des identifiants différents à des vérificateurs différents, ce qui empêche la corrélation entre les services.
Ce choix n'est pas superficiel. La réutilisation d'un DID unique entre les services rend le lien trivial. Les DID par paire rompent ce lien au niveau de l'identifiant.
Ensuite, il y a la gestion des clés, et c'est là que la plupart des systèmes rencontrent des difficultés en production. La fiabilité d'un DID dépend de celle des clés qui le sous-tendent :
Dans la pratique, c'est là que réside la complexité. La vérification des signatures est simple. Le problème technique le plus difficile est de faire en sorte que les identifiants restent utilisables, récupérables et non corrélables dans le temps.
Une fois le flux passé, la question suivante est de savoir comment les identifiants sont effectivement résolus et maintenus. Cela se résume à deux choses : les Structure du document DID et les Méthode DID qui définit comment il est créé, mis à jour et résolu.
Un document DID est le résultat de la résolution d'un DID. Il indique aux vérificateurs les clés, les contrôleurs et les points de service autorisés pour cet identifiant. En pratique, il ne s'agit pas d'un profil d'utilisateur. Il s'agit d'un descripteur de vérification.
Les domaines de base qui vous intéressent généralement :
Le point de mise en œuvre de la clé reste le même : un vérificateur résout le DID, sélectionne la méthode de vérification appropriée et vérifie si la clé est autorisée pour l'opération effectuée.
Jusqu'à présent, nous avons surtout parlé de l'identité comme d'un élément contrôlé par une personne. Dans les systèmes B2B, le sujet clé est souvent une organisation. Les banques, les prestataires de services logistiques et les plateformes RWA doivent vérifier non seulement l'identité d'une personne, mais aussi celle d'une organisation. qui Il s'agit de savoir si cette personne était autorisée à agir pour le compte d'une entreprise.
C'est là que les DID organisationnels deviennent plus complexes. Le contrôle est réparti entre les rôles, les systèmes de garde, les politiques de signature et les règles de délégation. Une installation de production doit définir qui peut signer, ce qu'il peut signer et comment cette autorité est révoquée.
Dans la pratique, cela peut impliquer vLEI de GLEIF pour l'identité des personnes morales, des portefeuilles d'entreprise avec Signature soutenue par HSM, et des chaînes de capacités d'autorisation telles que ZCAP-LD.
Les documents DID ne sont pas statiques. Les clés expirent, les appareils sont perdus, l'infrastructure de signature change et les clés de l'émetteur doivent être renouvelées. Une conception sérieuse de la DID doit prendre en compte ces éléments sans compromettre les informations d'identification existantes.
La rotation des clés signifie généralement l'ajout d'une nouvelle méthode de vérification, la modification de la clé autorisée pour une relation donnée et le retrait de l'ancienne clé. Mais le détail qui compte est objectif. Rotation d'un l'authentification affecte les flux de connexion ou de réponse à un défi. La rotation d'une méthode d'assertion affecte la délivrance et la vérification des titres.
Le chemin de mise à jour dépend de la méthode DID. Avec la méthode did:web, vous mettez à jour le document DID hébergé. Avec did:ethr, vous publiez une transaction dans le registre. La difficulté réside dans la continuité : les vérificateurs doivent savoir quelle clé était valide lorsqu'un titre a été délivré et si ce titre a été révoqué, a expiré ou a été remplacé depuis.
Cela nous amène aux méthodes DID, car la méthode définit exactement comment la création, la résolution, les mises à jour et la désactivation fonctionnent dans le système réel.
Une méthode DID est la couche d'implémentation derrière la syntaxe DID standard.
Il définit les règles pour :
En d'autres termes, la syntaxe DID est standard (did:méthode:identifiant), mais la méthode façonne l'ensemble du modèle d'infrastructure derrière le DID.
Ces trois méthodes couvrent la plupart des cas d'utilisation dans le monde réel :
Le tableau vous donne maintenant les mécanismes. La partie la plus difficile consiste à décider du mode de défaillance que vous pouvez accepter : Dépendance au DNS, coût de la chaîne, pas de rotation, auditabilité publique ou portabilité plus faible. Voici donc mon point de vue sur la manière de choisir.
Avant de faire votre choix, posez les questions les plus délicates en matière de production :
Dans les déploiements réels, vous mélangez généralement les méthodes. Les émetteurs utilisent souvent did:web ou did:ethr; les détenteurs utilisent des identifiants par paire ou éphémères. Cette répartition permet de maintenir la confiance de l'émetteur tout en réduisant le risque de corrélation pour les utilisateurs.
Soyons clairs : vous n'avez pas besoin d'une blockchain pour mettre en œuvre une identité décentralisée. La spécification DID Core du World Wide Web Consortium ne l'exige pas, et de nombreux systèmes de production fonctionnent entièrement hors chaîne.
Alors pourquoi la blockchain fait-elle l'objet d'une conversation ? Parce qu'elle résout très bien un problème spécifique : confiance partagée sans propriétaire central. Non pas le stockage, non pas l'identité elle-même, mais la coordination autour des clés, des identifiants et du statut.
Dans les systèmes basés sur le DID, la blockchain joue le rôle de Registre public et inviolable. Selon la méthode, il peut être utilisé pour :
Le point clé : la blockchain ne vérifie pas l'identité. Elle fournit une point de référence commun sur lequel les vérificateurs peuvent s'appuyer sans faire confiance à une seule partie.
Par exemple, avec did:ethr, le DID se réfère aux données de la chaîne. Le vérificateur se fie à l'état de la chaîne et non à l'infrastructure de l'émetteur.
C'est là que de nombreuses mises en œuvre de DID se trompent. La blockchain est utile pour les états partagés, mais c'est un endroit terrible pour les données d'identité brutes. Vous ne mettez pas de passeports, de données biométriques, d'informations d'identification complètes ou de dossiers personnels sur la chaîne. Vous utilisez la chaîne pour le matériel de preuve et les données de coordination, puis vous gardez les données sensibles d'identité en dehors de la chaîne.
Une séparation nette se présente généralement comme suit :
En chaîne :
Hors chaîne :
La raison en est simple : la confidentialité et le coût. Les blockchains sont publiques, permanentes et coûteuses à mettre à jour. Les données d'identité ont besoin de confidentialité, de suppression, de correction et de contrôle d'accès. Ces deux aspects ne font pas bon ménage.
La blockchain est généralement utilisée pour l'ancrage et non pour le stockage. Vous intégrez une petite preuve d'état à la chaîne, telle que le hachage d'un document DID, la mise à jour du registre de l'émetteur, la référence à l'état d'un titre ou un événement de rotation des clés, tandis que les données d'identité réelles restent en dehors de la chaîne.
Cela confère aux vérificateurs trois propriétés utiles :
La contrepartie est la permanence. Si vous mettez les mauvaises données sur la chaîne, vous ne pouvez pas les supprimer proprement. C'est pourquoi les systèmes DID matures ancrent des hachages, des références et des transitions d'état, et non des informations d'identification complètes, des documents ou des données personnelles.
La blockchain n'est pas le bon outil lorsqu'elle ne supprime pas une dépendance fiduciaire. Si la même organisation contrôle l'émetteur, le vérificateur et l'application, la mise en place de l'état DID sur la chaîne ne fait généralement qu'ajouter des frais, des temps de latence et du bruit opérationnel.
Sauter la blockchain quand :
C'est pourquoi did:web fonctionne si bien pour de nombreux flux d'identité d'entreprise. Il conserve le modèle DID, mais utilise l'infrastructure web existante au lieu de forcer chaque mise à jour à travers une transaction blockchain.
Utilisez la blockchain lorsque des parties indépendantes ont besoin d'un état partagé qu'elles peuvent vérifier sans faire confiance à votre serveur. Dans le cas contraire, gardez-le en dehors de la chaîne. Plus de décentralisation sur le papier ne signifie pas automatiquement une meilleure architecture d'identité.
Dans des systèmes tels que le portefeuille d'identité numérique de l'UE ou les permis de conduire mobiles (ISO 18013-5), l'ICP a été choisie en grande partie parce que les réseaux publics L1/L2 ne répondent pas aux exigences fondamentales en matière d'identité : protection de la vie privée, souveraineté des données et contrôle réglementaire. Les données d'identité ne peuvent pas être reproduites publiquement, et les juridictions doivent exercer un contrôle strict sur l'endroit où les données sont traitées et stockées.
Mais les nouvelles architectures offrent une troisième option : Systèmes zk-L2 autorisés. Ceux-ci combinent :
L'idée clé est la séparation des préoccupations au niveau de l'infrastructure :
Cela permet d'éviter une limitation essentielle des chaînes publiques : l'exposition des données. En même temps, elle évite une limitation de l'ICP pure : la dépendance à l'égard de hiérarchies de confiance fermées sans possibilité d'audit partagé.
Une autre propriété importante est architecture multi-domaine. Différents acteurs - ministères, régulateurs, banques ou régions - peuvent opérer dans des zones d'exécution distinctes avec leurs propres limites de conformité, tout en contribuant à un état vérifiable partagé grâce à des preuves.
Cela élargit l'espace de conception des systèmes d'identité. Au lieu de choisir entre une ICP centralisée et une blockchain publique, les nouveaux déploiements peuvent combiner la confidentialité, la conformité et la confiance partagée dans un modèle unique.
D'accord, il devrait maintenant être clair que les DID diffèrent du KYC standard. Mais la question la plus pratique est la suivante : Qu'est-ce que cela change pour moi ? C'est une bonne question. D'après ce que j'ai vu dans des mises en œuvre réelles, l'impact dépend beaucoup du côté où l'on se trouve, il vaut donc la peine de le décomposer.
Pour les utilisateurs, le changement le plus important est le contrôle sur quand et comment l'identité est partagée.
En pratique, l'identité n'est plus quelque chose que l'on soumet à nouveau en permanence, mais quelque chose que l'on être présent en cas de besoin.
Pour les organisations, il s'agit moins d'UX que de risque et structure des coûts.
Ce qui change sur le plan opérationnel, c'est que l'on cesse d'être un dépositaire de données pour devenir un vérificateur des créances.
Pour les développeurs, la valeur est dans comment la logique de l'identité est structurée.
D'un point de vue technique, on passe de la “gestion des utilisateurs et des sessions” à la "gestion de l'information". vérification des preuves et application des conditions.
Laissons de côté la théorie pendant une seconde et examinons la question comme nous le ferions dans un système réel. Qu'est-ce que DID se sentir comme dans la pratique ? Où cesse-t-il d'être un diagramme pour devenir quelque chose que l'on expédierait ?
Vous remarquerez une chose au fur et à mesure que nous avançons : les objets changent - diplôme, historique de l'emploi, statut KYC - mais le flux, lui, ne change pratiquement pas.
Imaginons que vous veniez d'obtenir votre diplôme et que vous deviez le prouver à un futur employeur. La procédure habituelle est maladroite : téléchargez un PDF, joignez un scan, attendez peut-être que quelqu'un envoie un courriel à l'officier d'état civil. Cela fonctionne, mais à peine. L'ensemble du processus repose sur une confiance manuelle.
Dans le cas d'un titre basé sur la DID, l'université délivre un titre vérifiable lorsque vous obtenez votre diplôme. Il se trouve dans votre portefeuille, signé par une clé publiée dans le document DID de l'université.
Quelques mois plus tard, vous postulez à un emploi. L'employeur n'a pas besoin de contacter l'université. Vous présentez vos références et le système vérifie :
C'est là toute la beauté du modèle : l'université signe une fois, vous réutilisez la preuve et chaque vérificateur peut la vérifier indépendamment.
Quelle est la valeur réelle d'un CV ? Les titres sont gonflés. Les dates sont floues. L'expression “diriger une équipe” peut signifier n'importe quoi, de la gestion de dix personnes à l'organisation de réunions d'information.
Maintenant, inversez le modèle. Lorsque vous quittez une entreprise, celle-ci vous délivre un titre de compétence :
La prochaine fois que quelqu'un vous demandera “Pouvez-vous prouver que vous avez fait X ? Vous présentez. Et non, cela ne signifie pas qu'il faille à chaque fois exposer l'ensemble de ses antécédents professionnels. Avec le bon format de justificatif, le détenteur peut prouver une allégation plus restreinte, comme par exemple :
... sans fournir l'historique complet de l'emploi. C'est une attitude très différente de celle qui consiste à dire “envoyez-nous votre CV complet et vos références”.”
C'est là que l'identité réutilisable devient évidente. Vous effectuez une vérification une fois auprès d'un fournisseur de confiance : vérification du passeport, contrôle des sanctions, confirmation de la juridiction. Le fournisseur délivre un certificat KYC à votre portefeuille.
Prochaine plateforme ? Vous présentez les informations d'identification au lieu de télécharger à nouveau les mêmes documents. La plateforme vérifie :
Certaines équipes de tokenisation utilisent également jetons liés à l'âme comme marqueurs KYC sur la chaîne : cette adresse a passé le contrôle requis. Les données relatives à l'identité restent en dehors de la chaîne ; la chaîne ne transmet que le signal d'éligibilité.
Utile, mais seulement si le marqueur est large, révocable et ne constitue pas une fuite permanente de la vie privée.
Dans le domaine de la santé, l'architecture DID a besoin d'une laisse courte. Supposons qu'une clinique vous délivre un certificat de vaccination, qu'un laboratoire signe le résultat de votre analyse sanguine et que votre médecin vous délivre une ordonnance. Vous les gardez dans votre portefeuille au lieu de laisser chaque enregistrement disparaître dans un autre portail.
Puis vous changez de médecin. Faut-il attendre qu'un système communique avec un autre ? Chassez les PDF ? Non. Vous partagez le titre spécifique dont le nouveau prestataire a besoin. Il vérifie l'émetteur, la signature et le statut.
Et pour être clair : rien de tout cela n'exige de mettre les données médicales dans la chaîne. La chaîne est destinée aux identifiants, aux clés et peut-être aux registres d'état. Les données sensibles restent en dehors de la chaîne. Si cette limite n'est pas respectée, la conception est défaillante.
Éloignons-nous maintenant des gens. Prenez un produit - disons une bouteille d'huile d'olive. Une étiquette de qualité supérieure, un bel emballage. Est-ce bien réel ? Au lieu de faire confiance à la marque, vous tapotez votre téléphone sur une étiquette NFC. Derrière cette étiquette se trouve un DID lié au lot de produits.
Ce que vous obtenez en retour, ce sont des données signées :
Vous pouvez littéralement suivre le produit de la source à l'étagère. Cela résout-il tout ? Non. Si la première entrée de données est erronée, tout ce qui suit ne fait que préserver l'erreur. Mais au moins, vous savez maintenant qui a signé chaque étape. C'est une grande amélioration par rapport à “faites-nous confiance”.”
C'est au niveau gouvernemental que l'identité de type DID quitte la bulle cryptographique. Un point de référence majeur est le portefeuille d'identité numérique de l'UE dans le cadre d'eIDAS 2.0, une initiative à grande échelle visant à fournir des portefeuilles aux citoyens, aux résidents et aux entreprises dans tous les États membres.
Mais le paysage est plus diversifié. Certains des systèmes d'identité numérique les plus importants et les plus matures au monde ne sont pas strictement basés sur la DID, mais suivent des schémas similaires autour de justificatifs réutilisables et de données contrôlées par le détenteur :
Le changement commun à tous ces systèmes est le même : passer d'enregistrements d'identité centralisés à des preuves réutilisables, présentées par l'utilisateur. En même temps, il est important de séparer les modèles de confiance. Les systèmes comme eIDAS reposent sur une ICP fédérée et des listes de services de confiance, tandis que les systèmes basés sur la DID s'appuient sur des identifiants cryptographiques et des justificatifs vérifiables. Dans la pratique, ces modèles coexistent souvent plutôt qu'ils ne se remplacent.
Jusqu'à présent, tout fonctionne bien à l'intérieur d'un système unique. Mais que se passe-t-il lorsque les informations d'identification franchissent les frontières du système ? C'est là que les choses deviennent strictes. Il faut des normes communes pour que les données aient un sens partout, et une gouvernance pour que les vérificateurs sachent à quels émetteurs faire confiance. Voici les normes et les niveaux de gouvernance les plus importants.
Les normes rendent les informations d'identification interopérables. La gouvernance les rend acceptables. Sans normes, rien n'est analysé. Sans gouvernance, rien n'est fiable. Les systèmes réels ne fonctionnent que lorsque les deux couches sont définies ensemble.
Les normes vous indiquent comment un système DID doit se comporter. La production vous indique où les choses se gâtent. Aujourd'hui, la plupart des risques ne proviennent pas de la syntaxe DID ou des algorithmes de signature eux-mêmes. Ils apparaissent autour des portefeuilles, de la récupération des clés, de la révocation, de l'interopérabilité et de la question de savoir si suffisamment d'émetteurs et de vérificateurs acceptent d'utiliser le même modèle de confiance.
Dans les systèmes DID, l'identité dépend du contrôle des clés. C'est un système puissant, mais qui ne pardonne pas. Si un utilisateur perd la clé, la récupération n'est pas automatique. Si un pirate obtient la clé, il peut se faire passer pour le détenteur. C'est pourquoi les implémentations sérieuses s'appuient rarement sur une phrase de semence brute seule. Elles ont généralement besoin de MPC, de récupération sociale, de clés adossées à du matériel ou d'un modèle de conservation hybride.
Les références vieillissent. Le KYC expire, les employés partent, les licences sont suspendues. La vérification ne peut donc pas s'arrêter à la question “la signature est-elle valide ?”. Le vérificateur vérifie le statut du titre au moment de son utilisation. Il s'agit généralement de listes d'état, de registres de révocation ou de titres de courte durée. Si cette étape n'est pas respectée, les anciens titres continueront à paraître valides.
Les normes sont utiles, mais elles ne rendent pas magiquement tous les portefeuilles, émetteurs et vérificateurs compatibles. Une pile peut utiliser des informations d'identification JSON-LD, une autre peut préférer les méthodes JWT. Méthodes DID. Les protocoles de présentation diffèrent. Alors oui, l'écosystème évolue vers l'interopérabilité, mais les projets réels nécessitent encore un travail d'intégration et des choix de profils stricts.
La partie la plus difficile est la coordination. Un système DID a besoin d'émetteurs en qui les gens ont confiance, de vérificateurs prêts à accepter les identifiants, d'utilisateurs capables de gérer les portefeuilles et de règles de gouvernance comprises par tous. Jusqu'à ce que ces éléments s'alignent, l'adoption se fait par poches : la finance réglementée, la tokenisation, les justificatifs d'identité des travailleurs, l'identification gouvernementale et les écosystèmes fermés d'abord.
La plupart des systèmes DID actuels reposent sur la cryptographie à courbe elliptique : Ed25519, secp256k1, ou P-256. Ces systèmes sont largement déployés, mais ils ne sont pas sécurisés au niveau post-quantique. Un ordinateur quantique suffisamment puissant pourrait les casser avec l'algorithme de Shor, faisant de la falsification de signature un véritable risque à long terme.
C'est important, car les titres d'identité ont souvent une durée de vie de plusieurs années. Les diplômes, licences et attestations légales délivrés aujourd'hui peuvent encore devoir être vérifiés longtemps après que la cryptographie qui les sous-tend soit devenue obsolète.
Les normes évoluent déjà dans cette direction. Le NIST a finalisé des schémas de signature post-quantique tels que ML-DSA (Dilithium) et SLH-DSA (SPHINCS+), tandis que l'écosystème DID/VC explore les signatures hybrides et la crypto-agilité.
Les systèmes DID devraient prendre en charge plusieurs méthodes de vérification, de nouvelles suites de signatures et des chemins de rotation des clés clairs dès le premier jour. Les signatures post-quantiques sont beaucoup plus grandes que les signatures Ed25519 ou ECDSA, ce qui affecte les présentations QR, les registres et les mécanismes de statut sur la chaîne. Mais pour une identité gouvernementale et d'entreprise de longue durée, la crypto-agilité est indispensable.
L'erreur la plus fréquente est de considérer le DID comme quelque chose que l'on “ajoute” à une pile d'identité existante. En pratique, il s'agit d'un changement dans la manière de modéliser la confiance, le flux de données et la responsabilité. Les éléments techniques sont rarement la partie la plus difficile. La plupart des projets réussissent ou échouent grâce à la coordination, à la gouvernance et à l'intégration.
Commencez par identifier les endroits où vous stockez des données d'identité afin de les vérifier ultérieurement : statut KYC, âge, emploi, licences, accréditations et droits d'accès. L'objectif est de stocker moins de données brutes et de vérifier davantage de déclarations signées. Cela permet de réduire la responsabilité, de simplifier la conformité et de rendre l'identité transférable d'un système à l'autre.
Avant de choisir des outils, il faut définir le modèle de confiance en termes concrets. Dans les projets réels, cela se traduit généralement par :
Sans cela, vous obtenez des informations d'identification qui sont vérifiées correctement mais qui ne sont pas acceptées par les vérificateurs.
Choisissez maintenant la pile technique. Choisissez la méthode DID, le format des justificatifs, le flux du portefeuille et le modèle de révocation. did:web s'adapte généralement aux flux des entreprises et des SaaS. did:ethr s'adapte à l'exécution des contrats intelligents et à l'identité sur la chaîne. did:key correspond à des identifiants locaux ou de courte durée.
Ne choisissez pas l'option la plus “décentralisée”. Choisissez celle qui correspond à votre périmètre de confiance.
Ne commencez pas par une “identité pour tout”. Commencez par un flux où la douleur est évidente. Les bons projets pilotes sont les suivants :
Établissez un cadre strict : un seul type de justificatif, un ou deux émetteurs, un seul flux de vérification, des règles de révocation claires. Évitez de commencer par :
Prouvez le flux de bout en bout, puis développez.
Une fois que l'on passe d'un projet pilote à la production, l'émission d'identifiants ne représente que la moitié du problème. La question la plus difficile est de savoir ce qui se passe lorsqu'un titre n'est plus digne de confiance : un contrôle KYC expire, un employé quitte l'entreprise, une licence est suspendue ou un portefeuille est compromis.
Il n'existe pas d'approche standard unique, et chaque modèle s'accompagne de compromis :
Les écosystèmes adoptent des approches différentes. Par exemple, les permis de conduire mobiles ISO 18013-5 s'appuient sur la validation de l'émetteur et sur des listes de confiance plutôt que sur une révocation de type W3C. En l'absence d'une stratégie de révocation claire, le modèle des “titres réutilisables” se brise. Un titre compromis peut continuer à être présenté si son état n'est pas activement vérifié.
Un projet DID/VC typique se déroule en plusieurs phases. Un projet pilote prend généralement 3-4 mois et valide un cas d'utilisation de bout en bout, généralement dans la fourchette suivante $150K–$300K, en fonction du champ d'application. Une mise en production prend 9-12 mois et s'étend à de multiples émetteurs, vérificateurs et types de titres, allant généralement de $800K à $2M+, selon la complexité de l'intégration et les exigences de conformité.
Une équipe type comprend
Dans la pratique, la complexité réside rarement dans la cryptographie. Elle réside dans l'intégration, la gouvernance et l'expérience de l'utilisateur.
Pour conclure, faisons un petit zoom arrière. L'identité basée sur la DID n'est pas une pile finie. Elle évolue encore, principalement autour des systèmes de preuve, de l'infrastructure des portefeuilles, des couches d'interopérabilité et de l'intégration réglementaire. D'après ce que je vois dans les mises en œuvre réelles, quelques directions se dessinent clairement.
L'identité réutilisable est la finalité évidente, mais le goulot d'étranglement n'est pas la vérification de la signature. Cette partie fonctionne déjà. Ce qui est plus difficile, c'est la confiance de l'émetteur, les schémas d'identification et les règles d'acceptation.
À l'avenir, un certificat KYC émis dans un environnement réglementé devrait pouvoir être réutilisé sur les bourses, les plateformes de tokenisation, les produits de prêt et les interfaces DeFi conformes, à condition que le DID de l'émetteur puisse être résolu, que le schéma soit compris et que le vérificateur accepte l'émetteur dans son cadre de confiance. C'est là que réside le véritable travail : il ne s'agit pas de prouver qu'une signature est valide, mais de se mettre d'accord sur la signification réelle de la demande signée.
Aujourd'hui, de nombreux systèmes révèlent encore des attributs. À l'avenir, il s'agira de prouver les conditions. Au lieu d'indiquer votre date de naissance, vous prouvez que vous avez plus de 18 ans. Au lieu d'exposer l'intégralité des données KYC, vous prouvez que vous avez satisfait à une politique de conformité définie. Au lieu de partager un champ de compétence, vous prouvez votre éligibilité à une transaction.
D'un point de vue technique, il s'agit de signatures BBS+ pour la divulgation sélective et de zk-SNARKs ou zk-STARKs pour les preuves de prédicats. Le vérificateur vérifie la preuve par rapport aux clés publiques contrôlées par l'émetteur, tandis que les données personnelles sous-jacentes restent cachées. Le modèle de protection de la vie privée passe ainsi de “partager moins de données” à “ne pas partager du tout les données lorsqu'une preuve suffit”.”
L'interopérabilité déterminera si l'identité décentralisée reste fragmentée ou si elle devient une infrastructure utilisable.
Les points faibles sont toujours familiers : JSON-LD vs JWT credentials, différentes méthodes DID, différents protocoles de portefeuille, différents flux de présentation. C'est pourquoi les systèmes de production définissent de plus en plus souvent des profils stricts : formats d'identifiants approuvés, méthodes DID prises en charge, émetteurs de confiance et protocoles de présentation acceptés.
Avec le temps, je m'attends à une plus grande convergence autour des flux de portefeuilles vers les vérificateurs, des échanges de présentations et des registres de confiance. Sans cela, chaque projet DID devient un autre îlot d'identité. Grâce à cela, les informations d'identification peuvent être transférées d'une plateforme à l'autre sans qu'il soit nécessaire de procéder à une intégration personnalisée à chaque fois.
La réglementation fait de l'identité décentralisée non plus une option technique, mais une infrastructure publique.
Dans l'UE, eIDAS 2.0 et le portefeuille d'identité numérique de l'UE constituent le grand signal. Les États membres sont tenus de fournir une infrastructure de portefeuille, avec des références pour les attributs d'identité, les licences, les qualifications et les cas d'utilisation du secteur public-privé. Cela crée une couche d'identification réglementée dans toute l'Europe.
Aux États-Unis, le National Institute of Standards and Technology (NIST) met à jour les directives relatives à l'identité numérique (par exemple, NIST 800-63) afin de prendre en compte les références cryptographiques, les niveaux d'assurance et la vérification de la préservation de la vie privée. Les États-Unis conserveront probablement un modèle davantage axé sur le marché, tandis que l'Union européenne préconise un cadre coordonné pour les portefeuilles.
Quelle est donc la direction à prendre ? Vers moins de téléchargements de documents, plus d'identifiants réutilisables, plus de vérifications cryptographiques locales et une divulgation plus sélective. Les gagnants ne seront pas les systèmes qui stockent le plus de données d'identité. Ce seront ceux qui pourront vérifier la bonne demande avec le moins d'exposition possible.
Un identifiant décentralisé est un identifiant unique et résoluble qui pointe vers un document DID contenant des clés publiques et des méthodes de vérification. Il permet aux entités de prouver leur identité ou leur contrôle sans dépendre d'une autorité centrale. En pratique, il remplace les consultations de bases de données par une vérification cryptographique.
Un DID se résout en un document DID avec des clés publiques. Un émetteur signe un titre, un détenteur le stocke et un vérificateur vérifie la signature et le statut à l'aide du DID de l'émetteur. Aucun appel direct à l'émetteur n'est nécessaire. Cela rend la vérification portable et indépendante de tout système unique.
L'identité décentralisée est le modèle global d'émission et de vérification des demandes sans stockage central. La DID n'est qu'un élément de ce modèle. Il sert de couche d'identification utilisée pour résoudre les clés et vérifier les signatures. Sans DID, le système ne disposerait pas d'un moyen cohérent de localiser les éléments de vérification et de s'y fier.
Pas nécessairement. Certaines méthodes DID utilisent des blockchains pour la résolution ou l'ancrage, mais beaucoup, comme les did:web, Les DID, en revanche, reposent sur une infrastructure web standard. Le DID lui-même est une référence et non un enregistrement de données. Ce qui peut être stocké sur la chaîne, ce sont des clés, des hachages ou des références d'état, et non des données d'identité.
Ils sont utilisés pour lier les identités aux clés cryptographiques, permettre des références vérifiables, soutenir le KYC réutilisable, la vérification de la main-d'œuvre, les identités numériques et le contrôle d'accès dans les systèmes basés sur le web et la blockchain. Leur rôle est de rendre la vérification d'identité portable entre les systèmes.
Vous générez une paire de clés et créez un DID selon une méthode choisie. Ensuite, vous le publiez ou l'enregistrez pour qu'il puisse être résolu en un document DID. Le processus exact dépend de la méthode DID (par exemple, web, blockchain ou basée sur une clé). La méthode détermine comment le DID est ancré, mis à jour et résolu.
Expert en blockchain et analyste DeFi
Andrew traduit les concepts décentralisés en outils financiers sécurisés et fonctionnels. Il navigue dans le paysage volatile de DeFi pour construire des infrastructures blockchain évolutives qui répondent à l'utilité du monde réel, dépassant les mots à la mode pour offrir une valeur technique.
