Cet article est une libre adaptation de celui de Meilir Page-Jones publié en 98 enrichi de ma perspective personnelle. Cela fait quelques années déjà que je suis tombé sur cet article et ma réaction a immédiatement été: « Hé, ça explique bien des choses ».

J’y reviendrai.

L’idée fondamentale, et très générale, c’est que tout apprentissage exige de passer par différentes étapes correspondant aux progrès dans la connaissance. Les initiés reconnaîtrons ici une variation sur le modèle d’acquisition des compétences de Dreyfus proposé en 1980.

Pour mettre l’accent sur la généralité des concepts – et histoire de s’éloigner un peu de l’informatique – Meilir Page-Jones l’a illustré par le type de progrès en compétence auxquelles on pourrait s’attendre dans le domaine de la Chasse à l’Ours.

N’ayant rien contre les ours j’aurai pour ma part été plus naturellement porté à choisir un exemple du type apprentissage des arts martiaux ou encore pratique de alpinisme, l’essentiel étant de sortir du domaine technique. Mais la Chasse à l’Ours est devenue une référence, et l’illustration est amusante et fonctionne très bien.

Niveau 0: le Naïf

Cet article étant destiné d’abord à un public d’informaticiens, nous avons logiquement décidé de commencer la numérotation à 0. Ceux qui ne l’ont pas encore fait peuvent lire l’article d’Edger Djikstra consacré au sujet pour comprendre en quoi c’est logique.

Un Naïf n’a jamais vu d’Ours, ou même n’en a jamais entendu parler. S’il en rencontrait un, il ne lui viendrait pas à l’idée que cette bête puisse être chassée. Il ne se rendrait pas non plus compte qu’un ours est une source potentielle de danger. Le mot ours lui évoque probablement des peluches pour les enfants ou des bonbons colorés ou en guimauve recouverte de chocolat.

Niveau 1: Curieux

Au niveau 1, la personne a déjà vu des Ours, par exemple au zoo. Il aime peut-être se promener dans les parcs nationaux canadien et sait qu’on peut y rencontrer des ours. Il sait peut-re qu’une poignée d’entre eux survit péniblement dans les Pyrénées et pose des difficultés avec les bergers. Il sait qu’il en existe de différentes couleurs, vivant dans diverses parties du monde.

Il est peut-être tombé par hasard sur un documentaire consacré à la vie des ours à la télé, ou a vu le film l’Ours de Jean-Jacques Anaud. Il a peut être des amis canadien ayant participé à des chasses à l’Ours. Il a aussi appris quelques faits étonnants sur les Ours, comme pratique de la pêche au saumon au moment de la fraie ou encore qu’ils hibernent en hiver. Il est motivé pour en apprendre plus.

Niveau 2: Novice

Un niveau 2 a sauté le pas en participant à un séminaire de formation de 5 jours consacré à la chasse à l’Ours. Au cours de ce séminaire, les participants – en équipes de trois ou quatre – ont essayé de capturer des Oursons, sous l’oeil vigilant d’un instructeur.

Malgré quelques coups de griffes et évasions, le vendredi soir chaque équipe avait réussi à piéger son ours. L’instructeur leur a donc décerné un certificat de chasse à l’Ours attestant de leurs compétences professionnelles en matière de chasse à l’Ours.

On peut toutefois émettre quelques doutes sur le fait qu’ils soient convenablement préparés à chasser l’ours sauvage. Certains d’entre eux en sont généralement persuadés, ce qu’on nomme Effet Dunning-Kruger : en savoir tellement peu sur un sujet qu’on est persuadé le maîtriser. Un novice qui souffre de cet effet est potentiellement un danger pour lui-même et pour les autres par excès de confiance.

Niveau 3: Praticien

Le chasseur de niveau 3 à suivi de véritables cours de Chasse à l’Ours. Il est en confiance et prêt à transcender les techniques de chasse à l’ourson apprises en stage pour se lancer à l’assaut des vrais ours, de gros ours, des ours féroces.

Son manager exulte en le voyant suivre les pistes en courant et installer ses pièges en utilisant les techniques de chasse les plus modernes. Le consommateur réclame de la fourrure et il la veut pour hier!

Hélas, dans la précipitation il arrive bien suivant que l’impatient chasseur de niveau 3, parte sans carte ni boussole, avec des cartouches du mauvais calibre pour son fusil. Dans la fièvre de la lutte d’homme à ours, le niveau 3 interprète parfois mal les conseils de son
instructeur et court au désastre.

Bien-sûr certains chasseur de niveau 3 parviendront à capturer leur ours… mais il est a peu près aussi fréquent que ce soit l’ours qui gagne et s’échappe, parfois après avoir réduit le chasseur en charpie.

Niveau 4: Vétéran

Le niveau 4 a survécu aux traumatismes du niveau 3. Il a vu l’ours mort a ses pieds. Plus question pour lui d’en vendre la peau avant de l’avoir tué.

Le niveau 4 utilise les techniques de chasse moderne avec naturel et de manière quasi instinctive. En fait il n’imagine même plus comment on pourrait s’en passer. Il est précis et productif. Le comité de pilotage lui désigne à peine l’ours et il le chasse, qui
plus est en respectant le budget et dans les délais impartis.

Le chasseur de niveau 4 est l’exemple même du chasseur moderne dont parlent les commerciaux lors des séminaires de chasse à l’ours.

Niveau 5: Expert

Les chasseurs de niveau 5 ne se sont pas contenté d’assimiler la mécanique de la chasse à l’ours, ils en ont aussi compris les principes sous-jacents. Les chasseur de niveau 5 vont au delà des règles : ils savent pourquoi ces règles existent et à quels moments il est acceptable de les enfreindre.

Par exemple, un chasseur de niveau 3 ou 4 se placera toujours à contrevent pour éviter d’effrayer accidentellement sa cible. Un chasseur de niveau 5 saura peut-être qu’en se frottant au préalable de purin d’élan il pourra avancer sous le vent sans être repéré et ainsi surprendre l’ours depuis un angle plus facile.

Grâce à leurs connaissances approfondies, les Expertss sont tout à fait en mesure d’enseigner à leurs collègues les techniques de chasse à l’ours, d’où le choix du terme désignant ce niveau.

Niveau 6: Gourou

Le Gourou sait tout ce qu’il y a à savoir sur la chasse à l’Ours et il est en train d’élargir le domaine en inventant régulièrement de nouvelles techniques Ursocynégétiques.

On demande aux chasseurs de niveau 6 d’écrire des livres sur la chasse à l’ours ou de donner des conférences sur ce sujet. Le Gourou fabrique souvent ses propres pièges, armes et appâts. Ils s’intéressent aux façon d’étendre et de généraliser les techniques de chasse à l’ours pour résoudre de nouveaux problèmes.

Par exemple un niveau 6 peut adapter les techniques de chasse à l’ours à la chasse au Yeti ou rédigera le manuel de dressage ultime pour les prendre vivants, les faire se reproduire en captivité, voire leur apprendre à danser ou à faire l’acteur. De l’extérieur les pratiques et objectifs des niveaux 6 peuvent apparaître comme assez surprenants et inutiles aux autres niveaux.

Application à l’ingénierie informatique

Revenons au monde de l’ingénierie du logiciel et voyons comment s’appliquent ces niveaux d’expertise.

Mais d’abord une remarque préalable qui s’écarte un peu du propos de l’article d’origine. Il me semble clair que cette progression existe simultanément, quoique de manière probablement couplée, pour chacune des technologies ou méthodologies du domaine considéré. L’informatique est un domaine très large ou cohabitent de nombreux éco-systèmes, donc inutile de s’attendre à ce qu’un Javaiste possède le même niveau d’expertise en C++ (ou en Haskell, ou en Python), ni qu’il brille autant comme programmeur que comme DevOps ou Administrateur Système.

Par exemple le mythique Développeur Full-Stack – nous avons déjà parlé du Yéti – aura probablement des niveaux d’experise différents pour le back-end et le front-end. S’il est Vétéran dans toutes les technologies recherchées c’est déjà un miracle.

Il est clair aussi qu’un de Chef de projet formé au Cycle en V sera probablement mal à l’aise dans une équipe Agile. Passer d’un cycle de développement très hiérarchisé et découplé à une approche incrémentale basée sur le TDD et le refactoring continu n’a en effet rien de naturel, etc. Dans de tels cas on peut sans doute s’attendre à une baisse de niveau. On peut imaginer la détresse psychologique lors d’une régression de Vétéran, voire d’Expert dans une méthodologie – aussi pesante soit-elle – à un niveau de simple Praticien.

Cette vision de la multiplicité des niveaux simultanés m’en a donné une autre que je développerait sans doute dans un autre billet: s’appuyer sur les catégories de niveaux en « Chasse à l’Ours » pour réaliser un bilan de compétences personnalisé. La bonne nouvelle c’est qu’il existe évidemment des passerelles et que l’expert d’un domaine ne revient pas au niveau zéro lorsqu’il s’écarte de sa zone de confort. Mon idée c’est qu’une carte permettrait de s’y retrouver. Nous reviendrons sur le sujet.

Fermons la parenthèse pour le moment.

Dans l’optique de ce que je viens de dire plus haut, plutôt que d’évoquer une vague « méthodologie » qui ne serait qu’une redite de la chasse à l’Ours, je vais choisir une technologie concrète, l’apprentissage des techniques de refactoring.

Il serait certainement instructif d’appliquer le même exercice à d’autres domaines comme par exemple la connaissance de Python, ou encore la programmation Javascript. Celà pourrait donner quelques jolis articles.

Niveau 0: Naïf

Un naïf n’a probablement jamais entendu parlé de refactoring. Il sait probablement que des informaticiens créent des programme et n’ignore pas que ces logiciels ont parfois des bugs. Mais il se fait une idée extrêmement vague de ce en quoi cela consiste.

Pour lui il n’y a guère de différence entre pirater un serveur, écrire un logiciel ou réparer un PC. S’il apprend que son voisin est informaticien, avoir vaguement entendu qu’il est spécialisé dans l’exploitation statistique de Big Data ne l’empêchera probablement pas de lui demander de dépanner son notepad Windows 10 (au plus grand agacement du dit voisin).

L’étendue de l’ignorance des non-informaticiens est parfois difficile à concevoir pour les geeks. Et en 2020 les Naïfs constituent toujours l’immense majorité de la population.

Inversement il est difficile pour quelqu’un d’extérieur d’imaginer le nombre de sous domaines spécialisés que comporte désormais l’informatique. Jusque dans les années 1990 il était encore concevable de connaître (plus ou moins précisément) la majorité de ces domaines. Dans son article de 1998 Meilir Page-jones évoquait déjà le phénomène: de l’intérieur les ingénieurs ne se rendent pas vraiment compte de cette complexification progressive qu’il estimait à 3 ordres de magnitude (x1000) depuis les années 70.

Comme depuis lors, l’évolution a continué dans la même direction. Mesurer l’évolution de cette complexité à travers le temps, par exemple en évaluant le nombre de bibliothèques logicielles tierce partie et de composants système utilisés par un programme donné, conduirait sans doute à extrapoler une nouvelle variante de la loi de Moore, par exemple « La complexité des logiciels double tous les deux ans ».

Aujourd’hui la majorité des experts se sentent comme un poisson sur la berge hors de leurs domaines de prédilection… et ils le savent. Les Naïfs par contre les croient toujours omniscients.

Niveau 1: Curieux

Le niveau 1 travaille dans l’informatique et il sait ce qu’est un programme, mais il n’est pas lui-même programmeur. Il est peut-être Administrateur Réseau, Technicien de support, Testeur QA, Administrateur de Base de Donnée, Designer Web, etc.

On pourrait bien entendu écrire le même paragraphe dans l’autre sens et évoquer le programmeur qui ne comprend rien aux réseaux ou aux bases de données, ou incapable de parler avec un client. J’ai choisi de consacrer mon analogie au refactoring, donc un sous-domaine de la programmation.

Le curieux sait grosso-modo ce qu’est un programme. Il sait qu’il existe différents langages de programmation. Il sait certainement qu’un programme peut contenir des bugs et que dans ce cas il faut un correctif.

Peut-être s’est-il essayé à la programmation (ou même a-t’il suivi des cours dans le cadre de sa formation). Peut-être a-t’il écrit des scripts permettant d’automatiser ses tâches habituelles.

Le sujet l’intéresse, mais le niveau 1 ne se rend pas compte de l’ampleur de la tâche, ni de l’abnégation qu’implique le bon fonctionnement d’un logiciel de plusieurs milliers de lignes. Ni des pratiques permettant de maîtriser sa complexité.

OK, j’exagère sans doute un peu. Mais si en tant que programmeur je n’insiste pas sur
la difficulté de ma tâche qui va le faire à ma place? Qui saura que les programmeurs sont des héros anonymes?

Niveau 2: Novice

Les niveaux 2 ont franchi le pas, ils se sont lancés dans la programmation.

Ils ont lu « Apprenez à programmer en PHP en 21 jours » ou « C++ pour les nuls », ou suivi un tutorial sur le Web consacré à Java. Ils ont peut-être suivi un MOOC sur Coursera ou Khan Academy consacré à la programmation Web « Full Stack ».

Plus rarement ils auront suivi un stage de formation de 5 jours payé par l’entreprise
(ça c’était l’approche du millénaire d’avant, on la rencontre de moins en moins en matière de programmation, un peu plus souvent dans d’autres domaines techniques de l’informatique).

Ils ont réussi à compiler ou exécuter leur code en suivant pas à pas les exemples. Ils sont restés perplexe des heures devant des erreurs triviale, mais ont fini par parvenir à déboguer l’exemple avec l’aide de Stack Overflow ou des forums de Comment ça marche.

Ils sont finalement très fier de leur de leur application Androïd ou de leur site web perso en PHP et Javascript assemblé à grands renforts de copier/coller depuis le web.

Le résultat obtenu leur a donné une certaine confiance et ils se sentent capable de se lancer dans des projets d’envergure, ou d’expliquer au programmeur de la société que son travail est « très simple ». C’est bien entendu l’effet Dunning-Kruger à l’oeuvre dans toute sa splendeur. Les débutants dans domaine ont une confiance en eux sans rapport avec leurs capacités. En fait ils n’ont pas encore saisi la complexité de la tâche. Le problèmes qu’ils est qu’ils s’expriment souvent haut et fort comme s’ils étaient des experts car ils ne se rendent pas compte de leurs lacunes… et un Naïf, voire un Curieux, peuvent fort bien ne pas faire la différence entre les différents niveaux d’expertise.

Si un Novice a parfaitement assimilé un cours en ligne ou un livre d’autoformation, il pourra éventuellement se lancer dans un vrai projet avec quelque réussite.

Malheureusement le cas le plus fréquent sera qu’il n’aura pas tout compris dans son cours et aura des difficultés à transposer les techniques présentées à son cas particulier. Il arrivera peut-être à écrire une application, voire à la mettre en production dans son entreprise… mais probablement pas à la déboguer. Quand aux problématiques de maintenance ou d’évolution… on ne peut que plaindre celui ou celle à qui serait confiée cette tâche.

On pourrait dire qu’il en sait juste assez pour être dangereux et qu’il écrit des programmes fondamentalement jetables.

Niveau 3: Praticien

Le rite de passage du niveau 3 c’est la programmation et le refactoring en vue de maintenance d’une application conséquente. Quelque chose comme une dizaine de milliers de lignes (bien entendu la ligne de code reste une très mauvaise mesure qui varie énormément selon le style du programmeur et son langage de prédilection). Surtout, sachant qu’il devra mettre le code en production pour un client et en assurer la maintenance et l’évolution pendant quelques temps après sa mise en production.

Il commencera à comprendre qu’il est préférable de découper un programme en fonctions et en classes et que celles-ci ne devraient pas être trop longues. Il aura peut-être saisi l’utilité des tests automatisés pour éviter les régressions.

De toutes les transitions le passage de Novice à Praticien est probablement le plus difficile. On demande au Novice de mettre en œuvre une pratique de programmation (comme le refactoring) encore jamais essayée (par lui) et de l’appliquer à un projet réel, soumis à toutes les contraintes habituelles: politique, dates de livraison arbitraires, changements des spécifications arbitraires, corrections de bugs dans l’urgence.

Simultanément il tente de se rappeler ce qu’il a appris et d’extrapoler les exemples à des cas dix fois plus complexes et plus gros. Il a constamment besoin d’appuis et de conseils, car il faut s’attendre à ce qu’il rencontre quantités de difficultés, petites ou grosses.

A ce stage il y a beaucoup d’appelés et peu d’élus. Beaucoup de programmeurs jettent l’éponge et retombent dans leurs vielles ornières. Le TDD, ou même simplement écrire les tests unitaires c’est trop de boulot en plus, c’est trop dur à maintenir, c’est du temps perdu. Il suffit d’écrire le code ça ira bien comme ça.

Si tous les intervenants du projet en sont à ce stade, alors le projet lui-même a de forte chance d’être un échec et que le Refactoring de code soit publiquement remis en cause puis abandonnés: le Refactoring continu, nous avons essayé, ça ne marche pas!

Niveau 4: Vétéran

Les Vétérans ont passé le cap. Pour eux la pratique du TDD et le Refactoring continu sont devenues naturelles et il y a peu de chance qu’ils retournent en arrière.

Un programme bien écrit comporte des tests unitaires. Point. Et la protection offerte par les tests permet un refactoring facile de larges portions du programme, sans régression ni introduction de bugs. Le Vétéran maîtrise aussi les outils du test et les framework xUnit ou les bibliothèques de Mocks n’ont plus de secrest pour lui.

Les commerciaux les félicitent, le programme fonctionne, les clients sont contents, ils y a très peu de bugs. Les quelques correctifs sont précis et livrés rapidement. Et chaque projet réussi renforce un peu plus leurs bonnes habitudes. Un Vétéran est autonome, il donne plus souvent des conseils qu’il n’a besoin d’aide.

Bon certains tests sont trop complexes ou trop longs et prennent du temps à maintenir. Lorsqu’il faut modifier la structure du programme les modifications peuvent aussi s’avérer problématique et nécessiter de modifier à la fois le code et les tests, ce qui normalement ne devrait pas arriver. Quelques portions du programme, par exemples celles ayant massivement recours aux entrées sorties ou aux appels systèmes sont peut être mal couvertes par les tests, mais on gère.

Niveau 5: Expert

Le niveau 6 est plus qu’un simple technicien. Non seulement il connaît les Code Smells classiques et comment y remédier, mais sait pourquoi ils ont été inventés et sait les hiérarchiser entre eux. Il sait quels sont les champs d’application où le refactoring sera la meilleure réponse et les alternatives classiques comme remplacer une fonction existante complexe par une bibliothèque.

Cette connaissance en profondeur l’autorise parfois à enfreindre une règle superficielle pour préserver un principe plus fondamental, comme allonger temporairement la liste de paramètres d’une fonction avant de créer un nouvel objet ou réduire les dépendances entre modules. Il connaît aussi les domaines où il faudra privilégier d’autres approches,  à quelles pratiques il faudra renoncer et lesquelles on pourra conserver.

Il sait aussi commencer organiser le code pour faciliter les tests et quelles classes intermédiaires créer pour rendre testables des portions délicates du code comme les entrées sorties.

L’Expert est aussi un bon formateur, ses connaissances à la fois théoriques et pratiques lui apportent le recul nécessaire pour répondre aux questions épineuses des élèves.

Niveau 6: Gourou

Le Gourou se préoccupe de prosélytisme. Il cherche à diffuser les dernières évolutions en matière de pratiques Agilesfor à une large audience. Il blogue régulièrement sur le sujet, participe à des groupes linkedin, participe et anime à des Meetup et des  conférences. Il écrit peut-être des livres consacrés aux méthodes de Refactoring et aux Code Smells. Il a peut-être même inventé le terme.

Il connaît et se préoccupe des défauts dont souffrent les méthodes aspects techniques des méthodes Agiles modernes et cherche à les améliorer ou les corriger. Un test unitaire doit non être maintenable, mais aussi lisible et pouvoir servir d’exemple. Il prend également en compte les aspects psychologiques des tests ou de l’organisation du code: un programme est d’abord fait pour être lu par des humains!

A l’époque où les autres se focalisaient sur le Cycle en V et les processus très formalisés, lui signait probablement le Manifeste Agile (voire l’écrivait) et posait les bases de scrum ou d’eXtreme Programming. Aujourd’hui il propose peut-être les aproches « No Estimates » ou promeut le « Trunk Based Developpement » plutôt que les branches de fonctionnalités. Il prépare l’avenir.

D’accord, mais à quoi ça sert ?

Ces septs niveaux d’expertise ont une valeur intrinsèque.

Lorsqu’on pense à un programmeur en particulier, il est éclairant de se poser la question de son niveau vis à vis d’une certaine technique. C’est bien entendu valable aussi pour soi-même. Une fois son niveau évalué, il devient plus facile de comprendre comment progresser. Inutile aussi de brûler les étapes.

Mais au delà des trajectoires individuelles, il existe des implications organisationelles derrière ces sept niveaux. On ne doit – ou devrait – pas gérer un Praticien comme un Vétéran ou un Expert.

La suite de l’article évoque différents sujets sur lesquels le modèle d’apprentissage a un impact :

• le recrutement,
• la diffusion des compétences,
• la courbe de productivité,
• les projets pilotes,
• le noyau d’employés critiques
• les technologies éphémères.

Mais d’abord récapitulons les niveaux de manière synthétique:

Niveau 0 – Naïf
Niveau 1 – Curieux
Niveau 2 – Novice : premier contact, pas autonome. A besoin d’un complément de formation, mais en sait peut-être assez pour l’acquérir seul avec les bons outils. Pour le moment c’est plus un poids qu’une aide. On peut s’attendre à une productivité négative de sa part.
Niveau 3: Praticien : commence à être autonome, a des connaissances théoriques, mais des trous, ne maîtrise pas l’écosystème, n’a pas encore développé d’instinct. Parfois très productif, mais aussi assez dangereux sans un référent expérimenté. C’est à son niveau que l’effet Dunning-Kruger (illusion de compétence) risque d’être le plus fort et de faire le plus de dégats.
Niveau 4: Vétéran : utilisateur expérimenté maîtrisant l’écosystème. Il a développé un instinct et s’oriente de lui-même vers les bonnes solutions, même s’il ne sait pas toujours epliquer pourquoi. S’il a des lacunes il s’en rends compte et peut les corriger pourvu qu’on lui en laisse le temps.
Niveau 5 Expert : il est capable de former sur cette technologie. Il a non seulement un instinct, mais aussi du recul et une vision des technologies voisines. Il connaît les limites et un certain nombre d’alternatives.
Niveau 6 Gourou : prépare l’avenir et la prochaine génération d’outils, fait franchir les limites et crée des alternatives.

Impact sur le recrutement

Une question que devrait se poser un recruteur c’est de déterminer le niveau d’expertise effectif d’un candidats. Un vrai Praticien disposant de bases solides, et même s’il ne maîtrise pas tout, est beaucoup plus intéressant qu’un simple Novice, qui au départ ne sera qu’un poids mort.

Le profil qui fera la meilleure impression en recrutement est probablement le Vétéran. Les bons mots clés apparaissent sur son CV et il va se diriger instinctivement et immédiatement vers la solution attendue par le recruteur lors des tests techniques.

Un Expert ou un Gourou peuvent voir dans les problèmes proposés des difficultés cachées ou des cas limites invisibles pour le recruteur lui-même. En fait, l’Expert ou le Gourou vont autant évaluer le test lui-même qu’ils vont être évalués… et les tests ont toujours des défauts. C’est potentiellement le recruteur qui peut faire mauvaise impression et il risque parfois de ne pas se rendre compte du niveau d’expertise de son interlocuteur.

La courbe de productivité

Il y a un marché des nouvelles technologies logicielles: langages de programmation, librairies d’outils, frameworks, etc. Ces technologies sont promues par différents groupes suivant chacun son propre agenda. On peut assez simplement raisonner en terme d’écosystèmes. Certains outils sont créés pour des raisons commerciales, d’autres pour répondre à des besoins, les motivations sont rarement pures mais si on reste informé, il n’est pas si difficile de se faire une idée.

Des questions clés sont évidemment qui contrôle l’évolution d’une technologie et quels sont les besoins auxquelles elle répond. Si un écosystème rencontre un certain succès ces réponses peuvent d’ailleurs changer.

Prenons l’exemple du langage C. Il a été créé en tant qu’outil interne par des développeurs d’AT&T, le but étant de disposer d’un assembleur portable pour écrire un système d’exploitation. Par la suite c’est devenu un véritable standard de l’industrie et le contrôle a été transféré à un comité ISO.

C est désormais enseigné dans les cursus universitaires, mais il y a aussi des sociétés dont c’est le métier de former des programmeurs C ou de trouver des prestataires capables de programmer en C. Par contre il est aussi très clair que C est sur une pente descendante, sa niche de langage d’écriture d’applications a été largement érodée par des nouveaux venus (Java, C++, mais aussi Python, etc.). Il lui reste toutefois un fort écosystème en tant qu’assembleur portable, rôle que les remplaçant cité assurent imparfaitement pour des raisons variées.

Quel niveau de connaissances (et de compétences connexes) peut-on attendre d’un développeur C en fonction des niveaux. En pratique la manière dont il a appris le C est un élément déterminant.

Le problème c’est que si l’on cherche un développeur C aujourd’hui, il va être difficile de trouver sur le marché un vrai Praticien. Les jeunes sortis des filières de formation sont au mieux des Novices (dans la pratique on constate qu’une majorité de jeunes diplômés sont tout juste au niveau Curieux en matière de programmation C). Le même constat s’applique à d’autres langages comme Java tel qu’enseignés dans les écoles. Certaines filières ont adopté des enseignements très orientés « pratique » avec de nombreux projets de codage pour remédier à ce type de difficultés et y parviennent plutôt bien, mais pas non plus sans casse car il manque souvent des bases théoriques à ces élèves (par exemple en algorithmique) et un manque de base rend par la suite la progression plus difficile.

Remarquons surtout que les nouvelles technologies n’apparaissent pas par génération spontanées. Elles sont conçues à l’origine pour répondre à des besoins et par la suite elles ont des promoteurs, visant à leur diffusion. Même si aujourd’hui ces promoteurs sont moins souvent des vendeurs que dans les années 2000, les technologies ouvertes et souvent gratuites étant la norme, leur utilisation favorise les intérêts de différents groupes. Le framework Javascript dominant est par exemple un enjeu pour les grands réseaux sociaux.

Les promoteurs mettent en avant les gains de l’adoption de leur technologie: performance, simplicité, facilité de codage. Le problème c’est que cette présentation est trompeuse. Ces gains ne seront totalement effectifs qu’une fois atteint le stade de Vétéran par les utilisateurs. Malheureusement entre le stade de Novice et celui de Vétéran il y a un moment de flottement et de baisse de productivité, qui correspond au rite de passage du Novice au Praticien confirmé.

Cette courbe d’évolution conduit plus d’un manager à abandonner de nouvelles techniques d’ingénierie logicielle car il s’attend à une augmentation de la productivité avec l’expérience… et au contraire il constate qu’elle baisse! Pour ces managers ce n’est pas un simple problème d’impatience, mais que personne ne les a prévenus que cette baisse temporaire de l’efficacité est normale et sera suivie d’une hausse. Un Manager non averti risque d’imaginer que cette technologie tant vantée n’est en définitive qu’une arnaque.

Des entreprises utilisant ce modèle de compétences ont mesuré le temps nécessaire pour évoluer du niveau Novice au niveau Vétéran dans une technologie donnée. Selon l’individu, le passage de Novice à Praticien prend de 6 à 18 mois (souvent la durée d’un projet), l’évolution de Praticien à Vétéran est plus lente et dure de 18 à 36 mois (évaluation très vague la classification des niveaux de compétences par pallier n’ayant rien d’une science exacte).

À l’exception de quelques individus particulièrement brillants, passer du niveau d’un Novice sortant de stage de formation à celui de Praticien efficace prend au moins deux ans.

Lorsqu’un manager attend trop d’une formation initiale à une technologie et dit qu’il ne peut pas attendre aussi longtemps, l’unique réponse qu’on puisse lui donner c’est que ces deux ans passeront quoi qu’il fasse. La seule urgence sur laquelle il a la possibilité d’agir agir c’est de démarrer le cycle de formation initiale et de mise en pratique aussi vite que possible.

Remarquez aussi que les Gourous ont une plus faible productivité quand ils sont impliqués dans les projets que les Experts. L’explication en est qu’une partie de l’énergie d’un Gourou est dirigé vers autre chose que les objectifs spécifiques du projet, comme des recherches méthodologiques plus générales. On peut également observer le même type d’effet chez les Experts dans des technologies dont le rythme de changement est très rapide: une partie de leur énergie est consacrée à simplement se tenir à jour des avancées. Il va sans dire que cette aptitude à rester à jour de manière autonome est précieuse.

Les projets pilotes

La courbe en J cache des difficultés plus graves qu’un simple délai au niveau de la productivité. C’est l’histoire de « Qui accrochera le grelot au cou du chat ». Dans la fable un groupe de souris qui ont été persécutées par un chat décident de lui accrocher un grelot autours du cou. Ainsi elles seront prévenuées de son approche. Toutes s’accordent pour dire qu’il s’agit d’une excellent idée… il n’y a qu’une difficulté mineure: aucune des souris ne veut prendre le risque de s’approcher du chat qui dors pour lui accrocher un grelot autours du cou. Cette difficulté est connue formellement sous le nom de « Piège Technologique ».

La majorité des Managers s’accordent pour dire que c’est une bonne chose que les employés maîtrisent les dernières avancées technologiques. Mais aucun d’entre eux, confrontés aux dates de livraisons et aux corrections de bugs attendues par les clients, ne veut que leur équipe ne subisse la perte de productivité liée à l’apprentissage d’une nouvelle technologie. Finalement beaucoup de managers d’une intelligence tout à fait normale semblent être des dinosaures parce que le piège technologique les retiens en 2010.

Si pour vous mettre le grelot au chat est un problème, alors je vous recommande d’expérimenter d’abord les nouvelles approches sur un projet pilot. Le pilote permettra de découvrir toutes sortes de chausses-trappes dans lesquelles tomberont Novices et Praticiens, mais aussi des problèmes plus fondamentaux liés à la technologie elle-même. Le projet pilote devrait être limité dans le temps (six mois) et concerner un système non critique. Vous devriez en apprendre autant que possible sur la mise en œuvre d’une technologie données grâce à un projet pilote: dans un tel projet l’objectif est d’abord l’apprentissage de la technologie, plus même que le produit réalisé.

Un projet pilote ne va pas permette de transformer la courbe d’apprentissage. Les développeurs devront toujours laborieusement évoluer de Novice à Praticien. Mais cela aura tendance à aplatir un peu la courben certaines des causes du minimum de productivité sont en effet neutralisées.

En effet, même si le système réalisé est le résultat le plus important pour la majorité des projets, vous ne devriez jamais négliger l’effet apprentissage des projets.Faites donc le point sur ce qu’un projet vous a appris lorsqu’il s’achêve (ou de temps à autre dans le cadre des rétrospectives pour les agilistes) et partagez cette information avec les autres. Dans un sens traitez tous les projets comme des projets pilotes.

Le Noyau de compétences critiques

Une des recettes les plus sures d’un désastre c’est de confier un projet à un groupe de Novices. C’est pourtant quelque chose d’assez fréquent. De nombreux managers envoie un groupe de développeurs en formation. Disons une semaine sur les technologies Cloud, puis leur confient un projet critique dans le domaine à leur retour.

Chaque projet devrait avoir avoir accès à au moins un Vétéran, dans l’idéal intégré à l’équipe. Vous devriez cultiver vos Vétérans et vos Experts internes dans une politique de développement des compétences à long terme, et les mettre en relation avec les équipes projet. Si vous manquez des ressources nécessaires en interne, n’hésitez pas à faire appel à des consultants, évitez simplement de devenir dépendants d’eux, continuez à développer la pyramide de compétence interne. Disposer d’Experts maisons capable de former en interne et qui se maintiennent à jour, garantira une maîtrise technologique à long terme.

Temps d’apprentissage et durée de vie des technologies

Les managers se plaignent parfois de ce qu’au moment ou leurs ingénieurs ont enfin assimilé une nouvelle technologie celle-ci a déjà été remplacée par un autre plus moderne. Même si cette constatation a un fond de vérité, il est tout aussi vrai que « plus ça change, plus c’est la même chose ».

Si vous achetez une voiture électrique pour remplacer votre vieux diesel, les principes de la conduite automobile n’auront pas changé pour autant. La plupart des évolutions en ingénierie logicielle reposent sur des principes sous-jacents similaires. Qu’ilk s’agisse de changer de Framework Web, d’ORM ou autre.

Développez une large capacité à intégrer des Experts dans votre organisation. Celà vous permettra de lisser  les sauts technologiques à haute-fréquence. Ces personnes seront en mesure d’absorber rapidement les caractéristiques des nouvelles technologies et d’évaluer leur applicabilité aux besoins de l’entreprise. Ils seront aussi en mesure de comparer les nouvelles techniques aux anciennes et de calmer la transition des anciennes techniques aux nouvelles. En effet beaucoup de « nouveautés » dans le domaine du logiciel sont de simples raffinements d’anciennes approches déjà connues des Novices, Praticiens et Vétérans.

La difficulté principale est le plus souvent de s’en rendre compte.

Le modèle de diffusion des compétences

En tant que Manager, soyez conscient de l’existence des septs niveaux d’expertise et de la effet sur la productivité individuelle pour une technique d’ingénierie logicielle particulière. Réconciliez vos attentes avec la réalité des individus.

Sachez où vous en êtes au niveau des équipes.  Discutez avec chaque individu pour évaluer son niveau d’expertise dans les techniques utilisées dans l’entreprise.

Discutez aussi avec les développeurs pour définir leurs buts à moyen et long terme pour la maîtrise des différentes compétences techniques. Proposez leur un plan permettant d’atteindre ces buts.

De la même façon vous pouvez établir un profil de compétence global désiré au niveau d’une équipe, ou même pour la société toute entière. Chaque développeur amenant sa pierre à l’édifice. Définissez le mélange optimal de compétences au sein des équipe, et un plan permettant d’atteindre cet objectif. Il peut s’agir de formations, mais aussi de temps disponible, ou de transferts de compétences internes par osmose (code review, pair programming, etc.).

Recommandations Finales

Evitez surtout de vous lancer dans un projet critique en impliquant uniquement des Praticiens. Chaque projet critique doit impliquer au moins un Vétéran, de préférence avec le support, éventuellement externe à l’équipe, d’un Expert. Si vous n’avez pas accès à au moins un Expert, empruntez-en un, volez-en un, achetez-en un ou kidnappez-le. Plus sérieusement des consultants externes peuvent être une option, au moins à court terme.

Stabilisez les effets des sauts technologiques· en entretenant un Gourou maisonau moins pour les technologies fondamentales et les principes. Reformulez autant que possible les stratégies de développement en termes non technologiques. Une stratégie et une technologie permet de définir une tactique.

Définissez un objectif permanent, qui ne deviendra jamais obsolte. Par exemple la mission de Wayland Systems (employeur de Meilir Page-Jones) est la « Maîtrise de l’ingénierie Logicielle ». En d’autre termes l’objectif est d’aider leurs clients à devenir autonomes jusqu’au niveau Expert. Ce n’est pas une mission qui risque de disparaître dans la mesure où l’ingénierie logicielle ne fait que se complexifier tout en devenant de plus en plus critique à l’activité. Même les Experts et les Gourous doivent continuellement se mettre à jour pour conserver leurs compétences tant il y a à apprendre.