Questions fréquentes
Comprendre le protocole commence par comprendre ses principes.
Le World Skills Protocol introduit des concepts souvent peu familiers au premier abord : identifiants canoniques, définitions logiques, représentations, Knowledge Graphs, résolution d'identité, réidentification, et plus encore.
Cette page répond aux questions les plus fréquemment posées par les lecteurs, les développeurs, les intégrateurs et les organisations qui découvrent le protocole.
Chaque réponse reflète le protocole publié.
Là où un détail supplémentaire existe, des liens pointent vers les Records ou les ressources techniques correspondants.
Section 1 — À propos du protocole
Qu'est-ce que le World Skills Protocol ?
Le World Skills Protocol est un protocole ouvert pour publier, identifier, relier et vérifier de l'information sur les compétences professionnelles.
Il définit des concepts, des identifiants et des relations partagés afin que des systèmes indépendants puissent échanger de l'information professionnelle sans perdre le sens ni la traçabilité.
Ce n'est pas un produit logiciel.
C'est une spécification.
À qui s'adresse le protocole ?
Le protocole s'adresse :
- —aux développeurs ;
- —aux éditeurs de logiciels ;
- —aux organismes de certification ;
- —aux organisations éducatives ;
- —aux employeurs ;
- —aux systèmes d'IA ;
- —aux institutions publiques ;
- —et à toute organisation qui a besoin de données interopérables sur les compétences professionnelles.
Le protocole remplace-t-il les plateformes existantes ?
Non.
Le protocole est conçu pour relier des systèmes indépendants.
Les applications existantes restent responsables de leurs propres utilisateurs, interfaces et données opérationnelles.
Le protocole fournit un langage commun entre elles.
Le protocole est-il ouvert ?
Oui.
Ses concepts publiés, ses Records et sa gouvernance ont vocation à être documentés ouvertement.
Chaque implémentation reste libre de choisir ses propres licences et modèles économiques.
Section 2 — À propos des Records
Qu'est-ce qu'un Record ?
Un Record est un document publié qui établit un ou plusieurs éléments normatifs du protocole.
Les Records définissent des concepts, des relations, des règles ou des décisions de gouvernance.
Ils constituent la source faisant autorité pour le sens du protocole.
Les Records sont-ils des spécifications ?
Oui.
Un Record est la spécification normative des concepts qu'il établit.
Tout le reste en dérive.
Quel document fait autorité ?
Les Records.
Le matériel d'accompagnement peut expliquer le protocole.
Seuls les Records publiés l'établissent.
Un logiciel peut-il être en désaccord avec un Record ?
Un logiciel peut se comporter différemment.
Le protocole, non.
Lorsqu'une implémentation entre en conflit avec un Record publié, le Record fait foi.
Section 3 — Identité
Pourquoi le protocole n'utilise-t-il pas les URL comme identifiants ?
Parce que les emplacements changent.
L'identité doit rester stable même lorsque le stockage, l'hébergement ou les mécanismes de publication évoluent.
Les identifiants canoniques identifient l'objet publié.
Les mécanismes de découverte localisent sa représentation courante.
Qu'est-ce qu'un identifiant canonique ?
Un identifiant canonique est l'identité stable attribuée à un objet publié du protocole.
Il reste indépendant :
- —des noms de fichiers ;
- —des URL ;
- —des bases de données ;
- —des formats de publication ;
- —et des technologies de stockage.
Qu'est-ce que la résolution d'identité ?
La résolution d'identité est le processus qui consiste à localiser la représentation courante associée à un identifiant canonique.
Elle relève de la couche de lecture du protocole.
Elle ne change pas l'identité elle-même.
Un identifiant peut-il changer ?
Le protocole distingue l'identité de la représentation.
Si l'identité elle-même doit être corrigée, le protocole publie une réidentification plutôt que de modifier en silence les publications historiques.
Section 4 — Versioning
Pourquoi existe-t-il plusieurs sortes de version ?
Parce que des choses différentes évoluent indépendamment.
Le protocole distingue :
- —le versioning documentaire ;
- —le versioning normatif ;
- —le versioning de représentation.
Chacun répond à une question différente.
Chaque nouvelle version de document change-t-elle le protocole ?
Non.
De nombreuses révisions documentaires améliorent la formulation, la structure ou la présentation sans changer le sens normatif.
Qu'est-ce qu'une version de représentation ?
Elle identifie une expression publiée particulière d'une définition logique.
Changer une représentation ne change pas nécessairement le sens.
Deux représentations peuvent-elles décrire la même définition ?
Oui.
Des représentations canoniques différentes peuvent préserver la même définition logique.
Section 5 — Knowledge Graph
Qu'est-ce que le Knowledge Graph ?
Le Knowledge Graph est la projection canonique des concepts et relations publiés établis par le protocole.
Il aide les lecteurs et les logiciels à naviguer dans l'architecture du protocole.
Le Knowledge Graph fait-il autorité ?
Non.
Le graphe est généré à partir des Records.
Les Records restent la source faisant autorité.
Le graphe contient-il des données de base de données ?
Non.
Le graphe projette des concepts.
Il ne projette pas d'instances opérationnelles.
Le graphe peut-il inférer des relations ?
Non.
Chaque relation affichée par le graphe doit d'abord avoir été publiée par le protocole.
Le graphe n'invente jamais de sémantique.
Pourquoi une relation n'est-elle pas visible ?
Parce qu'elle n'a pas encore été établie par un Record publié.
Le graphe ne peut pas projeter une connaissance non publiée.
Section 6 — Concepts et instances
Quelle est la différence entre un concept et une instance ?
Un concept appartient au protocole.
Une instance appartient à une implémentation.
Le protocole publie des définitions.
Les applications stockent des occurrences de ces définitions.
Pourquoi le graphe ne montre-t-il pas chaque fait opérationnel ?
Parce que les faits opérationnels appartiennent aux implémentations.
Le graphe ne représente intentionnellement que la connaissance publiée du protocole.
Les implémentations peuvent-elles étendre le protocole ?
Oui.
Elles peuvent introduire des concepts et des comportements locaux.
Ces extensions restent propres à l'implémentation jusqu'à ce que le protocole les publie formellement.
Section 7 — Réidentification
Qu'est-ce que la réidentification ?
La réidentification préserve la continuité d'une définition publiée lorsque son identité ou sa représentation canonique doit être corrigée.
Le sens reste inchangé.
La réidentification est-elle la même chose que la succession ?
Non.
La succession introduit un objet normatif distinct.
La réidentification préserve la même définition logique à travers une identité ou une représentation corrigée.
Pourquoi les deux relations sont-elles nécessaires ?
Parce qu'elles répondent à des questions différentes.
La succession explique l'évolution sémantique.
La réidentification explique la continuité.
Section 8 — Implémentations
Chaque implémentation doit-elle utiliser la même base de données ?
Non.
Le protocole spécifie le sens.
Les implémentations restent libres de choisir leur propre technologie.
Les implémentations doivent-elles exposer tous les concepts du protocole ?
Non.
Elles peuvent n'implémenter que les concepts pertinents pour leur objet.
Une implémentation peut-elle ajouter des champs locaux ?
Oui.
À condition que ces champs ne soient pas représentés comme s'ils étaient des concepts du protocole.
La conformité au protocole concerne-t-elle l'architecture logicielle ?
Non.
La conformité concerne la préservation du sens publié, non l'implémentation interne.
Section 9 — IA
Les systèmes d'IA peuvent-ils utiliser le protocole ?
Oui.
Les concepts et relations explicites du protocole le rendent adapté à la récupération et au raisonnement structurés.
Le protocole garantit-il que les réponses d'une IA sont correctes ?
Non.
Le protocole garantit l'origine et la structure de l'information publiée.
L'interprétation correcte reste la responsabilité du système qui la consomme.
Une IA peut-elle inventer des relations du protocole ?
Non.
Les interprétations générées doivent rester distinguables des faits publiés du protocole.
Section 10 — Gouvernance
Comment le protocole évolue-t-il ?
Par des processus de gouvernance publiés et de nouveaux Records.
Les changements ne font partie du protocole qu'une fois formellement établis.
Les faits publiés peuvent-ils être réécrits ?
Non.
Les publications historiques restent partie intégrante de l'historique documentaire.
L'évolution se fait par de nouvelles publications, non par modification silencieuse.
Pourquoi préserver les états historiques ?
Parce que la reproductibilité, la traçabilité et l'auditabilité exigent que l'historique de publication du protocole reste observable.
Section 11 — Interopérabilité
Qu'est-ce qui rend deux implémentations interopérables ?
Elles préservent le même sens publié.
Elles n'ont pas besoin d'architectures logicielles identiques.
L'interopérabilité exige-t-elle des API identiques ?
Non.
Elle exige une interprétation compatible des concepts du protocole.
L'interopérabilité exige-t-elle des bases de données identiques ?
Non.
Le protocole standardise la sémantique, non le stockage.
Que se passe-t-il si des implémentations sont en désaccord ?
Le protocole publié fournit la référence commune utilisée pour résoudre les différences sémantiques.
Conclusion
Si vous découvrez le protocole, commencez par les Records publiés.
Si vous l'implémentez, poursuivez avec la documentation Développeurs.
Si vous voulez comprendre comment les concepts se connectent, explorez le Knowledge Graph.
Les concepts présentés dans ce guide sont définis par les Records publiés du World Skills Protocol. Des ressources terminologiques supplémentaires deviendront disponibles à mesure que la gouvernance terminologique du protocole progressera.
Ensemble, ces ressources expliquent le protocole sous des angles complémentaires, tout en restant ancrées dans le même corpus canonique.
Continuer à explorer le protocole
Choisissez la ressource qui correspond le mieux à votre objectif.