Les certifications sont partout de nos jours.
On se certifie dans les sphères techniques chez Microsoft, Oracle, IBM ou encore Red Hat.
On se certifie comme expert Agile à la Scrum.org, la Scrum Alliance ou encore chez EXIN.
On se certifie comme formateur ou comme coach.
Certains programmes de certifications durent des mois, d’autres pas même une heure.

On peut se certifier pour [presque] tout, et [presque] partout. Et cela semble [presque] obligatoire, tant les certifications apparaissent comme un prérequis ou un « plus souhaité » dans les offres d’emploi que l’on peut croiser.

Mais une certification, qu’elle soit technique ou Agile, à quoi ça sert ?

Depuis le début de ma carrière en 2002, j’ai eu maintes fois l’occasion d’entendre cette question et encore plus souvent de me la poser.

Naturellement, LA réponse (la vraie, la seule) n’existe pas, mais par mon parcours, et mes questionnements, je vous propose de parcourir quelques perspectives de réponse et de réflexion.

Le jeune développeur (passionné)

Premier ordinateur (Olivetti M24, 8086) à 5 ans, premier programme en Basic à 6 ans (recopié) et premier vrai développement à 14 ans, en VBA.

Mais c’est à 18 ans, et en entrant dans une école d’informatique, que j’ai vraiment pris conscience que le « virus » des TI allait réellement faire partie de ma vie, après avoir passé des jours et des nuits sur des projets de fin d’étude, en C++.

Premier job en 2002, je me suis retrouvé dans une boîte qui voulait se lancer dans un nouveau langage sorti 2 mois plus tôt : Microsoft.NET. Pour moi, nouveau langage et nouveau paradigme : le Web.

Je me suis alors juré de tout apprendre, de tout comprendre. J’ai dévoré tous les ouvrages Wrox que j’ai pu trouver, les lisant in extenso, cherchant livre après livre ces petites phrases – presque anodines – cachées au milieu de ces pavés, et qui allait m’apprendre quelque chose de nouveau, me donner une nouvelle perspective sur les lectures précédentes.

Les certifications me faisaient rêver et représentaient la consécration du savoir. Comme un coureur qui rêve de franchir la ligne d’arrivée de son premier marathon. Un but en soi, représentant le niveau de connaissance atteint.

Le recruteur

Le recruteur est souvent dans la même perspective. On lui demande de recruter des développeurs, un monde que bien souvent il ne connait pas, travaillant dans des technologies qu’il ne connaît pas et ne comprend pas.

Je garderai longtemps le souvenir d’un collègue formulant des offres d’emploi pour un poste de développeur en « SilverFlash », mélangeant ainsi allègrement les deux technologies concurrentes de l’époque : Flash et Silverlight.

Un casse-tête pour un recruteur de faire correspondre CV et offre d’emploi et d’appliquer un premier filtre par rapport à ce qui est attendu. J’ai pu croiser toutes les techniques, la plus adéquate étant sans doute d’accepter son incompétence et d’avoir alors un binômage entre un recruteur technique et un recruteur en charge des aspects humains, collaboratifs, psychologique, etc. Mais au hasard des cultures d’entreprise, on peut croiser (et c’est du vécu) la technique du « comptage de buzzwords » : soit l’utilisation d’une personne « neutre » avec le moins de connaissance possible en TI, qui va se contenter de chercher les mots communs entre offre et CV (et attention… JS et JavaScript sont des mots différents).

À côté de cette technique sans doute un peu extrême (et j’espère rare), on retrouve des recruteurs qui s’appuient sur les certifications.

La certification démontre chez le candidat la volonté de s’évaluer (et donc de se mettre en danger) et donne une mesure objective du niveau de connaissance atteint (comparable entre deux candidats avec la même certification).

Ou en tout cas, c’est ce à quoi ils croient. Mais ce qu’on mesure, c’est ce que l’on obtient. Développeurs certifiés tu veux, développeur certifiés tu auras.

Le recruteur (technique)

À 26 ans, on m’a inclus dans le cercle du recrutement. J’ai donc rencontré des dizaines de développeurs, de tout âge, de tout niveau et de toute motivation.

De ces rencontres, j’en garde des moments de challenge extraordinaire, de belles surprises, mais aussi une incroyable désillusion que je n’imaginais pas pensable un ou deux ans auparavant.

La plus belle gifle de ma jeune carrière remettait en cause mes croyances : les pires candidats que j’ai rencontrés avaient tous de multiples certifications. Ils montraient tous une absence étonnante (et presque magique) de savoir, de compréhension, d’analyse, de remise en question.

Et les meilleurs quant à eux ? Certains étaient certifiés, d’autres non, mais brillaient tous par leur savoir-être, leur curiosité ou leur humilité.

La certification sert surtout à mettre un tampon sur le CV (parfois trop court). Un monde de bachotage ou de triche où les vrais/faux examens en ligne s’échangent parfois, se monnayent souvent, parmi les torrents.

Un commerce juteux, abreuvé par des recruteurs/clients qui cherchent une fausse garantie de connaissance qu’ils sont incapables de challenger, et les développeurs qui sont bien obligés de répondre à la demande.

L’Agiliste (naissant)

En 2005, je découvre l’Agilité et je suis en plein questionnement dans ce nouveau monde qui me bouscule et m’excite.

Je découvre alors le CITCON (conférence sur l’intégration continue et le testing) et, pendant 3 ans, à Bruxelles, Paris et Amsterdam, le même sujet revient dans les salons des Open Spaces : « Is Scrum Evil ? » On m’y dépeint alors une vision ultra-commerciale de Scrum, des cours, des certifications.

Les certifications [Agiles]… un commerce juteux faisant naître à tout va des personnes certifiées sans expérience, recherchées à prix d’or par des sociétés qui ne savent pas exprimer ce dont ils ont besoin.

Une vision d’un monde qui livre à tour de bras des Scrum Masters certifiés après deux jours de cours (et sans même un examen) et qui chaque année, contre monnaie sonnante et trébuchante, renouvellent leur « garantie » d’expert.

Le développeur passionné

On a décidé que je devais me certifier alors que j’avais 15 ans d’expérience. Certes, je donnais des cours ou des conférences, mais tout ça ne vaut pas un beau tampon, et puis cela ouvre la voie du monde du partenariat. C’est donc devenu un « mal nécessaire ».

Objectif : Certification de base C#. Challenge inexistant, tout en dilettante.

Certification en groupe : Niveaux différents, parcours différents. Et mes collègues cherchent en moi une sorte de « coach technique » pour les aider dans leur préparation.

Direction : Les livres de préparation. On creuse tous les sujets, on discute haut niveau, pattern, bas niveau, code IL… et je retrouve la même dévorante envie de découvrir ligne après ligne, le détail inconnu ou oublié. (Quoi? Il existe un cas où un « finally » n’est pas appelé ?)

J’ai alors découvert une nouvelle perspective où la certification devient annexe ; la valeur étant transférée à la préparation en soi.

La certification en soi est accessoire, c’est la préparation à la certification qui possède toute la valeur.

Comme un coureur de marathon qui, en franchissant la ligne d’arrivée, se met à penser à la course suivante. Seule la course compte !

L’Agiliste convaincu

Quand j’ai joint la famille Pyxis, cela faisait 10 ans que j’amenais l’Agilité au sein de mes projets et des équipes et 5 ans que je donnais des conférences et des formations sur le sujet. Autant d’années de questionnement et de remise en question.

Comme cela se faisait au Canada, nous avons alors introduit les trois certifications Agiles de Scrum.org en Belgique (« Professional Scrum Master », « Professional Scrum Product Owner » et « Professional Scrum Developer »).

Elles sont données par Christian Lapointe et Tremeur Balbous : 40 ans d’expérience à eux deux, formateurs certifiés, coachs en développement intégral et facilitateurs professionnels. Croiser leur chemin a toujours été un plaisir et un enrichissement personnel. Alors, naturellement, j’ai saisi l’occasion de suivre leurs cours et de me certifier comme Scrum Master et Product Owner.
Et je les ai suivies encore, et encore.

La certification Agile est avant tout un chemin exploratoire, poussant à confronter la vision, l’expérience ou les certitudes de chacun, soit du coach-formateur et des participants, venant tous avec leur vérités, leurs problématiques et leurs expériences.

Chaque cours est ainsi l’occasion d’ouvrir une nouvelle porte vers l’acceptation d’une nouvelle perspective, donnant un autre regard sur son rôle de facilitateur, de Scrum Master ou de Product Owner et une autre façon de l’interpréter.

Le formateur

Derrière beaucoup de certifications, on retrouve des cours spécifiques. Et derrière ces cours, des formateurs certifiés.

Et ces formateurs nous présentent deux facettes de ce monde de la certification. On retrouve parfois un monde assez commercial où les formateurs deviennent des ambassadeurs de la marque et payent – parfois très cher – ce droit d’utiliser un nom, un label.

Mais Christian et Tremeur m’ont offert une autre vision de ce monde de formateurs certifiés. Une vision partagée aussi dans les cours de facilitation graphique que nous amenons aujourd’hui en Belgique avec Bikablo.

Et cette réalité, c’est celle du mentorat, où les formateurs sont accompagnés dans leur apprentissage, pendant lequel ils vont être accompagnés par des formateurs aguerris.

C’est celle de l’excellence et de la critique, où les formateurs se rencontrent plusieurs fois par an, de par le monde, pour discuter des cours et les faire évoluer. Pour travailler sur les supports ou les examens.

La certification de formateur promet une constance et une qualité du cours, quel que soit le formateur, la langue ou le pays. Elle tient également la promesse de l’amélioration continue et de la remise en question.

Le chef d’entreprise

Aujourd’hui, je suis chef d’entreprise et, d’une certaine façon, je me retrouve complice des côtés pervers des certifications, poussant mes collègues à se certifier, permettant ainsi de rassurer certains recruteurs ou clients frileux.

Mais avant tout, c’est l’accomplissement de chacun que nous prônons, et l’apprentissage – qu’il mène à une certification ou non – y joue un rôle.

La certification doit être un moyen et non un but.

Et pour contribuer à changer la donne, nous avons l’objectif de former les recruteurs et les responsables d’entreprise afin de les aider à mieux comprendre l’Agilité et à définir leurs besoins. Un des objectifs étant de mettre un terme à cette offre d’emploi absurde et paradoxale, mais au combien classique de « Scrum Master-chef de projet avec expertise ITIL et Prince 2 ».

Et vous dans tout ça ?

Et vous alors, qui êtes peut-être certifié ou qui avez la volonté ou la nécessité de le devenir… Quelle est votre perspective et votre objectif ? Quel est votre moteur, et qui a pris la décision ?

Le seul conseil que je peux donner, c’est surtout de se certifier pour soi-même, et non pour un autre (client, responsable hiérarchique, …). La certification ne doit pas être l’atteinte de l’objectif, mais un simple jalon, une étape.

Billet précédent

Le Bracket Show — épisode 1

Billet suivant

La facilitation au service de votre organisation

Pierre-Emmanuel Dautreppe

Pierre-Emmanuel est passionné par le développement logiciel. Spécialisé en .NET depuis 2002, il a découvert l'Agilité en 2005 et est persuadé que c'est non seulement une façon de développer des logiciels exceptionnels, mais aussi la voie qui amène le plus de satisfaction et de plaisir en ce faisant.

Depuis 2009, il travaille comme développeur et architecte, mais aussi comme formateur et conseiller Agile et .NET. Il assiste fréquemment les équipes dans la mise en place des pratiques d'ALM, de TDD ou encore de tests en général.

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *