Trois idées fausses sur l’expertise

Que signifie "être un expert" ? Voilà une question dont je ne peux faire l'économie, considérant les services que je vends.

Opérons d'emblée une distinction entre l'expert qui, selon Le Robert, "a acquis une grande habileté par l'expérience, par la pratique" et cet autre personne, "choisie pour ses connaissances éprouvées et chargée de faire des examens, constatations ou appréciations de fait". C'est bien cette seconde définition qui nous intéresse aujourd'hui.

Rapporté au contexte du logiciel, nous laisserons ainsi de côté ce très bon développeur qui, de fait, possède une réelle expertise (architecture, langage, technologie) et la mobilise pour créer un logiciel au service d'un client, pour nous concentrer sur celui ou celle qui décide de vendre ses services en tant qu'expert.

Ces services, quels sont-ils ? Les experts en qualité logicielle sont convoqués par des organisations pour porter un regard extérieur et neutre sur l'architecture et le code d'un produit logiciel. Il peut s'agir de l'audit d'un actif informatique dans le cadre d'un rachat d'entreprise comme d'une étape préalable à un accompagnement de plus long terme  visant à pallier des dysfonctionnements techniques ou organisationnels.

Afin d'appréhender ce qu'est un tel expert, étudions trois idées fausses à son sujet.

Ce serait trop simple, ce serait trop beau : il suffirait d'interroger un expert pour avoir la réponse. Malheureusement, il y a besoin d'expertise justement parce qu'aucune certitude n'est possible.

En mathématiques, on effectue des preuves. En physique, en biologie et même en sciences humaines, l'expérience est reine (les conditions de sa réalisation peuvent être contestées, mais pas son interprétation). En sciences, le consensus est donc possible, jusqu'à ce qu'une théorie plus large invalide la précédente. Et l'on n'a pas besoin d'experts : il n'y a pas d'expert en mathématiques, il n'y a que des mathématiciens.

Qu'en est-il de la création logicielle ? Il ne s'agit pas d'une science, mais d'une pratique, une pratique qui mobilise des sciences (informatique théorique, ergonomie, sociologie des organisations, voire psychologie). La création logicielle  n'est donc pas une science.

C'est pourquoi il y a une place pour l'appréciation personnelle et, in fine, besoin d'expertise. Si les bienfaits de pratiques telles que le Test-driven development  sont largement reconnus, chacun est libre de s'en servir ou non , seul le résultat prime. Il n'y a pas de vérité, pas une seule bonne façon de travailler. Et il n'y a rien à démontrer, rien à prouver. Ainsi, chacun peut y aller de son opinion personnelle et de son pouvoir d'influence, pour le meilleur (Robert C. Martin, Martin Fowler, Alistair Cockburn, Sandi Metz…) et pour le pire (je tairai les noms).

Enfin, un donneur d'ordres peut vouloir organiser la confrontation de plusieurs experts (expertise/contre-expertise), pour plus de contradiction et plus de neutralité, comme cela se fait dans les domaines assurantiel et psychiatrique. Si l'on fait intervenir plusieurs experts, c'est bien qu'il y a débat, un débat qu'aucune expérience ne suffirait à trancher.

Tout cela pour dire une chose : un expert peut se tromper. Dommage.

Le développement d'une expertise va nécessairement avec le rétrécissement du champ de cette expertise. Dit autrement, pour devenir expert, il faut accepter de se focaliser sur un sujet au détriment de tous les autres, parce qu'on ne peut pas être expert en tout.

Le problème, c'est que posséder une expertise forte vous confère en bien des cas une position d'autorité. Ce statut élevé est très agréable, si agréable que l'expert oublie parfois que ce statut n'a cours qu'au périmètre de son expertise. Il en vient ainsi parfois à s'exprimer avec le même degré de certitude sur des sujets qu'il ne maîtrise pas ou peu*.

Cette tendance, que nous connaissons tous, c'est l'ultracrépidarianisme , mot provenant de la locution latine "Cordonnier, pas plus haut que la chaussure !", le fameux "je ne suis pas médecin, mais…" de la crise du coronavirus. L'ultracrépidarianisme est, au fond, la conséquence de l'effet Dunning-Kruger , car il faut en savoir déjà beaucoup pour savoir qu'on ne sait rien.

C'est peut-être la limite la plus évidente de l'expertise : elle se périme. Tout champ de savoir évolue, l'état de l'art change, du fait du partage des fruits de la recherche entre membres de la communauté qui fait vivre ce savoir. Un expert doit donc consacrer une part significative de son temps et de son énergie à sa propre formation pour rester à la page, le mieux étant encore si possible de contribuer à écrire la prochaine page.

L'immixtion de l'intelligence artificielle dans le développement en est un exemple d'actualité. Voilà un outil qui ouvre à des façons entièrement nouvelles de développer des logiciels, mais dont les usages restent encore à déterminer . Et pour déterminer ces usages, quoi de mieux qu'une pratique quotidienne et intensive de la chose ? Il me paraît difficile de vendre ses services sur le long terme en tant qu'expert d'une chose sans entretenir une pratique régulière de la chose (cf. la notion de penseur-faiseur ).

Ces réflexions relatives à l'expertise font émerger une question plus pressante : quelle est mon expertise ? Je me suis longtemps défini comme expert en création logicielle : architectures, méthodologies, paradigmes de langages, tout cela constituait le cœur de mon expertise. Pourtant, si ce savoir est bien sûr nécessaire, il est très loin d'être suffisant pour assurer la réussite de mes missions aujourd'hui.

Ce qui fait que mes missions réussissent, c'est bien la capacité à observer, écouter, faire parler, convaincre, accompagner, pour, in fine, insuffler le changement. Là se trouve peut-être l'expertise que je développe aujourd'hui.