Comment prouver une compétence ? Modèle à 6 niveaux de preuves

L’approche Skills First déplace l’attention des étiquettes formelles vers les compétences qu’une personne peut réellement démontrer. Cela ne résout toutefois pas automatiquement la question de leur évaluation.

L’OCDE décrit skills-first comme une approche dans laquelle les pratiques de recrutement et de gestion des talents sont adaptées afin d’évaluer les personnes à partir de compétences démontrées. Le rapport souligne également la nécessité de disposer d’outils d’évaluation et de référentiels de compétences appropriés. [1]

Remplacer une section "Education" par une section "Skills" plus longue ne suffit donc pas. Il faut aussi mieux expliquer pourquoi une compétence peut être considérée comme crédible.

Deux personnes peuvent indiquer exactement la même compétence tout en ayant une expérience pratique très différente.

Imaginons deux spécialistes qui déclarent :

Angular - avancé

La première personne a terminé une formation, créé quelques projets personnels et connaît les mécanismes de base du framework.

La seconde développe depuis trois ans une application en production, a pris en charge l’architecture d’une partie du système, réalisé des migrations entre différentes versions d’Angular et peut montrer des résultats concrets de ce travail.

Dans une liste classique de compétences, elles peuvent paraître très similaires.

Seules des preuves replacées dans leur contexte commencent à révéler la différence réelle.

Le modèle n’a pas pour objectif d’attribuer une note universelle aux personnes. Les professions ne produisent pas toutes les mêmes types de preuves et tous les projets ne peuvent pas être montrés publiquement.

Son objectif est de répondre à une question plus simple :

quelle est la solidité des éléments qui permettent de considérer une compétence comme présentée de manière crédible ?

Le niveau le plus simple est la déclaration de l’utilisateur.

Exemples :

• Angular
• Figma
• SEO
• management d’équipe
• négociation B2B

Cette information est utile pour la recherche et la découverte d’un profil, mais sa valeur probante reste faible.

Nous ne savons pas encore :

• où la compétence a été utilisée,
• pendant combien de temps,
• à quelle échelle,
• avec quel niveau de responsabilité,
• avec quel résultat.

La déclaration est un point de départ, pas la fin de l’évaluation.

La preuve devient plus solide lorsque nous savons où et dans quel contexte la compétence a été utilisée.

Au lieu de :

Angular

nous obtenons :

Angular utilisé pendant 2 ans pour développer une application SaaS dans le secteur de la logistique.

Cela ne prouve toujours pas la qualité du travail, mais apporte un contexte important :

• un projet réel,
• la durée d’utilisation de la compétence,
• le domaine d’application,
• la nature de l’environnement.

À ce niveau, la compétence cesse d’être uniquement une étiquette.

Le niveau suivant apparaît lorsqu’une déclaration et une expérience peuvent être reliées à un artefact réel de travail.

Selon la profession, il peut s’agir :

• d’une application fonctionnelle,
• d’un extrait de code,
• d’un dépôt,
• d’un design d’interface,
• d’un prototype,
• d’un rapport,
• d’une analyse,
• d’une campagne,
• d’un article,
• d’une documentation,
• d’un modèle financier,
• d’une photographie,
• d’un projet technique,
• d’un enregistrement du travail réalisé.

L’artefact répond à une question importante :

peut-on voir quelque chose qui a réellement été créé grâce à cette compétence ?

Cela ne signifie pas qu’un portfolio constitue un test formel de compétences. Les recherches sur la sélection du personnel indiquent néanmoins que les méthodes étroitement liées au travail réel, comme les work samples et les tests de connaissances professionnelles, peuvent être des prédicteurs utiles de la performance. Les auteurs soulignent également que les résultats doivent être interprétés selon le contexte, le coût et les limites de chaque méthode. [2]

Un artefact peut toujours laisser sans réponse l’une des questions les plus importantes :

qu’a exactement fait cette personne ?

C’est particulièrement important dans les projets d’équipe.

Une application peut avoir été créée par 20 personnes. Une campagne peut avoir mobilisé une équipe de 8 personnes. Un rebranding peut avoir impliqué une agence, un service marketing interne et des consultants externes.

Une preuve plus forte est donc une étude de cas qui identifie clairement la contribution individuelle.

Une bonne étude de cas devrait distinguer au minimum :

• le problème ou l’objectif,
• le périmètre global du projet,
• la responsabilité personnelle du spécialiste,
• les actions réellement réalisées,
• les compétences utilisées,
• la collaboration avec d’autres personnes,
• le résultat.

Au lieu de :

J’ai créé une plateforme e-commerce.

il vaut mieux écrire :

J’étais responsable de l’architecture frontend, de l’implémentation du checkout et de l’intégration du paiement. Le projet a été réalisé par une équipe de cinq personnes.

La seconde description est plus utile car elle n’attribue pas le travail de toute l’équipe à une seule personne.

La preuve devient encore plus forte lorsque le travail conduit à un résultat concret qui peut être décrit sans généralités.

Exemples :

Frontend
Réduire le temps de chargement de la vue principale de 4,2 s à 1,8 s.

UX
Réduire l’abandon du formulaire d’inscription après une refonte du parcours.

Marketing
Réduire le coût par lead tout en maintenant une qualité de trafic comparable.

Vente
Ouvrir un nouveau segment de clientèle et conclure un nombre défini de contrats.

Operations
Réduire un processus de plusieurs jours à quelques heures.

Toutes les professions ne peuvent ni ne doivent exprimer un résultat en pourcentage ou en valeur monétaire. Il ne faut pas inventer des métriques simplement pour rendre un profil plus impressionnant.

La bonne question est :

qu’est-ce qui a changé grâce à ce travail ?

Le niveau le plus fort du modèle apparaît lorsqu’au moins une partie des informations peut être vérifiée indépendamment de la déclaration de l’auteur du profil.

Cela peut inclure :

• un projet accessible publiquement,
• un dépôt avec historique des contributions,
• une publication publique,
• une participation confirmée à un projet,
• une référence client ou collègue pouvant être publiée légalement,
• un résultat pouvant être confirmé de manière indépendante,
• une certification officielle lorsqu’elle est réellement pertinente,
• une autre source confirmant un travail précis.

Cela ne signifie pas que tous les projets doivent être publics.

De nombreux projets de valeur sont couverts par un NDA, le secret des affaires ou d’autres obligations de confidentialité.

L’absence de preuve publique ne signifie donc pas l’absence de compétence.

Elle signifie uniquement que le degré de vérifiabilité indépendante est plus faible.

Niveau 1 - déclaration
Angular.

Niveau 2 - contexte
Angular utilisé pendant 3 ans dans des applications SaaS.

Niveau 3 - artefact
Une application publique, un dépôt ou un autre exemple de travail pouvant être montré.

Niveau 4 - contribution individuelle
Responsabilité de l’architecture de certains modules, des composants partagés et de la migration de l’application.

Niveau 5 - résultat
Une optimisation a réduit le temps de démarrage du module principal de 4,2 s à 1,8 s. Les valeurs sont illustratives.

Niveau 6 - vérification
Le résultat et la contribution peuvent aussi être confirmés par un projet public, un historique de modifications, une référence ou une autre source indépendante.

Deux preuves situées au même niveau peuvent avoir une valeur très différente. Cinq dimensions supplémentaires permettent d’en apprécier la qualité.

1. Pertinence - la preuve concerne-t-elle réellement la compétence évaluée ?

2. Actualité - quand la compétence a-t-elle été utilisée et quelle importance l’actualité a-t-elle dans ce domaine ?

3. Auteur et responsabilité - sait-on ce que la personne a réellement fait ?

4. Contexte - quelle était l’échelle, la complexité, la responsabilité, les ressources et les conditions de travail ?

5. Vérifiabilité - existe-t-il un moyen indépendant de confirmer au moins une partie des informations ?

Pertinence

Un projet dans lequel une technologie n’a été utilisée que marginalement constitue une preuve plus faible qu’un projet où cette compétence était centrale.

Actualité

L’importance de l’actualité dépend du domaine. Dans certains secteurs, une expérience datant de dix ans peut rester très précieuse. Dans d’autres, les outils et pratiques évoluent si vite que l’utilisation récente compte beaucoup.

Auteur et responsabilité

Plus le projet et l’équipe sont importants, plus il est essentiel de distinguer le résultat global de la contribution individuelle du spécialiste.

Contexte

Un même résultat peut avoir un poids différent selon l’échelle du projet, les contraintes de temps, les ressources, le niveau de responsabilité et la complexité du problème.

Vérifiabilité

Une vérification indépendante n’est pas toujours possible et ne devrait pas toujours être obligatoire. Lorsqu’une source indépendante peut confirmer le résultat ou la contribution, elle renforce toutefois la crédibilité de la preuve.

Une personne peut très bien réaliser sa partie d’un projet qui échoue finalement sur le plan commercial.

Elle peut aussi participer à un projet très réussi tout en ayant une influence limitée sur son succès final.

Il faut donc distinguer trois éléments :

1. Compétence
La personne sait-elle réaliser un type de travail donné ?

2. Contribution
De quelle partie était-elle réellement responsable ?

3. Résultat
Qu’est-ce qui a changé grâce à ce travail ?

La combinaison de ces éléments donne une vision plus complète.

Un certificat ou une autre attestation formelle peut constituer une preuve utile, mais sa valeur dépend de ce qu’il confirme réellement et de la manière dont il a été obtenu.

Il peut confirmer par exemple :

• la fin d’une formation,
• l’atteinte de résultats d’apprentissage définis,
• la réussite d’une évaluation donnée,
• la connaissance d’un standard,
• le respect d’exigences formelles.

La Commission européenne décrit les micro-certifications comme des attestations de résultats d’apprentissage acquis dans le cadre d’une courte expérience d’apprentissage. L’approche européenne insiste notamment sur la transparence et la qualité. [3]

Il ne faut pas automatiquement assimiler un certificat à la preuve qu’une personne peut réaliser de manière autonome un travail complexe dans un environnement professionnel réel.

Une attestation est donc un élément de preuve possible, dont la valeur dépend du contexte.

L’impossibilité de montrer publiquement un projet ne devrait pas effacer une expérience de valeur.

Dans le même temps, les NDA, obligations de confidentialité, secrets d’affaires, droits d’auteur et règles de protection des données priment sur le souhait de montrer un portfolio.

Un spécialiste ne doit décrire un projet que dans la mesure permise par ses contrats, le droit applicable et les droits des autres personnes et organisations. Supprimer le nom du client ne suffit pas toujours si les autres informations permettent encore d’identifier le projet, le client, la technologie, les résultats ou des méthodes confidentielles.

Lorsque la divulgation est autorisée, il peut être possible de décrire :

• le secteur à un niveau suffisamment général,
• la nature du problème sans dévoiler d’informations confidentielles,
• son rôle et ses responsabilités,
• les compétences utilisées,
• l’échelle du travail seulement dans la mesure où elle peut être révélée,
• le type de résultat sans publier de données protégées,
• l’approche à un niveau de détail approprié.

En cas de doute sur la possibilité de publier une information, la solution la plus sûre est de ne pas la divulguer avant d’avoir vérifié le contrat ou obtenu l’autorisation du titulaire des droits.

Un système de preuves de compétences ne devrait pas être conçu comme si tous les métiers étaient du développement logiciel.

Un designer peut montrer son processus, ses décisions de conception, un prototype et un résultat.

Un développeur peut montrer un produit, du code, une architecture ou un périmètre de responsabilité technique.

Un marketeur peut présenter une campagne, son approche, ses responsabilités et l’évolution des résultats.

Un commercial peut décrire un segment de marché, le processus de vente, son rôle et le résultat sans révéler de données confidentielles de clients.

Un Project Manager peut montrer le périmètre du projet, l’organisation du travail, les contraintes et son influence sur la livraison.

Un photographe peut présenter ses réalisations sans inventer de KPI artificiels.

Le modèle peut être commun au niveau des principes tout en restant flexible quant au type de preuve.

1. Vérifiez où la compétence a réellement été utilisée.

2. Recherchez un artefact de travail ou un exemple concret de réalisation.

3. Séparez la contribution du spécialiste du travail de toute l’équipe.

4. Examinez le résultat lorsqu’il peut être décrit de manière pertinente.

5. Évaluez l’actualité et la proximité de l’expérience passée avec le problème à résoudre.

6. Recherchez une confirmation indépendante lorsque cela est possible et pertinent.

L’évaluation se déplace ainsi des mots-clés du profil vers l’adéquation réelle entre les compétences démontrées et un besoin concret.

Le modèle sert à organiser l’information et à soutenir le jugement humain. Il ne doit pas être traité comme un verdict automatique pour recruter, rejeter un candidat ou commencer une collaboration professionnelle.

Il n’est pas nécessaire de disposer d’une preuve de niveau 6 pour chaque compétence.

Il est plus utile de revoir ses compétences principales et de se demander :

• où ai-je utilisé cette compétence ?
• quel problème cherchais-je à résoudre ?
• qu’ai-je fait exactement ?
• ai-je un artefact de ce travail ?
• quel a été le résultat ?
• puis-je le décrire sans violer la confidentialité ?
• une personne ou une source peut-elle confirmer ma contribution ?

Le simple passage de :

Figma - avancé

à :

J’ai conçu le parcours d’onboarding d’une application B2B et j’étais responsable de la recherche, du prototypage, des tests d’utilisabilité et du design system final

améliore nettement la qualité des informations disponibles pour la personne qui consulte le profil.

L’approche Skills First n’a de sens que si le mot "skill" représente davantage qu’un simple tag.

Si les compétences doivent devenir l’un des principaux moyens de découvrir et comparer des spécialistes, elles doivent être reliées au meilleur contexte disponible :

expérience -> portfolio -> contribution individuelle -> résultat -> vérifiabilité.

Toutes les compétences n’atteindront pas le niveau le plus élevé, et elles ne devraient pas y être obligées.

L’objectif n’est pas de créer une bureaucratie obligatoire autour de chaque élément du profil.

L’objectif est de permettre aux spécialistes d’expliquer pourquoi une compétence devrait être crédible, et d’aider ceux qui recherchent une expertise à prendre une décision mieux informée.

1. Le concret plutôt que la déclaration - montrez où et comment la compétence a été utilisée.

2. La contribution individuelle plutôt que le succès de toute l’équipe - distinguez votre travail du résultat de l’organisation entière.

3. Le résultat plutôt que la liste des tâches - lorsque c’est possible, montrez ce qui a changé grâce au travail.

4. Le contexte plutôt qu’un nombre isolé - une métrique sans conditions peut mener à de mauvaises conclusions.

5. La vérification lorsque c’est possible - une confirmation indépendante renforce la crédibilité, mais son absence n’annule pas la compétence.

Un profil professionnel ne devrait pas obliger le lecteur à deviner ce qui se cache réellement derrière une liste de compétences.

La déclaration permet de découvrir une compétence. La preuve permet de la comprendre.

Les six niveaux peuvent être résumés simplement :

1. Je dis que je sais faire.
2. Je montre où je l’ai utilisé.
3. Je montre ce que j’ai créé.
4. J’explique ce que j’ai réellement fait.
5. Je montre le résultat.
6. Je rends possible une confirmation indépendante lorsque c’est possible.

Plus nous pouvons répondre à ces questions, moins nous dépendons d’une simple déclaration.

C’est à ce moment que Skills First devient plus qu’un simple changement d’ordre des informations dans un profil.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Ouvrir la source

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
Ouvrir la source

[3] European Commission - A European approach to micro-credentials
Ouvrir la source

Note méthodologique : les sources [1]-[3] fournissent un contexte plus large sur Skills First, l’évaluation des compétences et les certifications. Le Modèle à 6 niveaux de preuves de compétences est un modèle conceptuel original décrit dans ce document et n’est pas présenté comme un résultat de ces publications.