Voici quelques années déjà que je retourne périodiquement chez mon ancien employeur pour jouer le rôle d’expert aux travaux pratiques en vue de l’obtention du titre de bachelor ou parfois de master. C’est un exercice qui me permet de garder le contact avec d’anciens collègues, et aussi avec la technologie qui a motivé mon parcours professionnel tout au long de mon existence. Les travaux pratiques consistent en un petit projet dont le déroulement s’étend sur une demi-année au total, pour un travail correspondant à trois centaines d’heures comptables environ. Certains candidats sont brillants, voire même hors normes; d’autres sont nettement en retrait ou n’ont carrément pas le niveau requis. Dans ce dernier cas, il faut également se questionner sur les raisons qui ont permis de faire parvenir le candidat jusque là, sans être parvenu à l’éliminer auparavant : il s’agit clairement d’une perte de temps et de ressources pour tout le monde.

J’ai pu remarquer au fil des années une évolution constante des travaux en informatique et en télécommunications. Les travaux se complexifient dans les fonctionnalités demandées, mais paradoxalement se simplifient dans leur architecture et leur réalisation. Alors qu’il y a quelques années, une grosse partie d’un rapport résidait en une description du problème et de la solution envisagée, ainsi que de la manière d’y parvenir, on tend actuellement à passer davantage de temps à décrire les outils que l’on entend mettre en œuvre pour parvenir à un produit dont on perd parfois un peu de vue la pertinence et l’adéquation au problème. Des outils de plus en plus complexes, et de plus en plus performants font que l’on passe désormais davantage de temps à essayer de comprendre ce que fait l’outil que de tenter de maîtriser les implications du problème que l’outil est censé aider à résoudre…

Ainsi, ces dernières années, le développement informatique s’est tourné vers des méthodes dites agiles, basées sur l’utilisation de frameworks sophistiqués. Ces méthodes tendent à postuler que l’étape dite de spécification fonctionnelle de la solution est inutilement chronophage, et prônent une implication très rapide du client dans le processus de développement. On utilise pour ce faire du prototypage rapide, des itérations nombreuses permettant au client de donner un avis sur la solution très tôt dans le processus de développement. Des frameworks _ cadres de travail- complexes et très sophistiqués permettent de modifier les détails d’une solution par simple paramétrage, mais sans toutefois autoriser des changements profonds dans la logique de la solution. Bien adaptées à la solution de problèmes relativement simples, comme les sites web, ces méthodologies peinent toutefois à convaincre dans le cas de problèmes plus sensibles. Ainsi, un atelier de coiffure pourra mandater un petit groupe de développeurs informatiques, parfois peu expérimentés, pour la réalisation d’un site web comprenant photos et système de réservation; en revanche, on est moins convaincu que ce groupe de développeurs soit en mesure de mettre sur pied le site d’une compagnie d’assurances correctement sécurisé avec des méthodes similaires (et -a fortiori- des connaissances à l’unisson).

Je n’ai a priori aucune objection à l’utilisation de méthodes agiles ou de frameworks; mais les développeurs qui travaillent dans cet environnement sont trop souvent poussés à une productivité à tout prix, en raison de la concurrence très forte sur ce segment de marché informatique. Il est vrai que c’est le principe de base d’une société capitaliste, mais un capitalisme intelligent et responsable chercherait à améliorer sa productivité sur le court, moyen et long terme, par exemple en prévoyant des possibilités de formation de ses employés en prévision de nouvelles méthodologies de développement; or dans le cas qui nous préoccupe, ce n’est que le court terme qui est visé. En d’autres termes, les développeurs, souvent privés de toute possibilité de post-formation, sont utilisés pendant quelques années, et lorsqu’ils sont dépassés par de nouvelles technologies, ils doivent s’adapter comme ils peuvent ou chercher du travail ailleurs. D’ailleurs, c’est plus intéressant pour l’employeur qui peut réengager des programmeurs novices, tout juste sortis de l’école et au fait des dernières nouveautés, qu’il paiera moins cher qu’un informaticien expérimenté, ou susceptible de demander une augmentation en raison de son ancienneté !

Récemment, j’ai suivi un cas tout à fait extrême à ce point de vue. Un étudiant qui a déjà passé plus de six ans dans l’école (ce qui va entraîner son exmatriculation), et qui parallèlement travaille pour une petite entreprise d’informatique de la région lémanique. Il s’agit d’une de ces entreprises qui travaille à flux tendu sur de petits projets orientés vers le web et les clients mobiles, d’une complexité suffisamment modeste pour lui permettre d’engager des gens peu qualifiés aimant bien programmer, et qui n’a guère les moyens d’investir dans la formation de ses employés : c’est dire si le diplôme de bachelor de l’un de ses employés a peu de signification. Le discours est plus que probablement « Tu as un job, tu gagnes de l’argent, que veux tu de mieux ? ». Un salaire qui paraît confortable à certains suffit parfois à démotiver un étudiant pour une formation dont il ne perçoit plus bien l’intérêt, puisqu’il a déjà un job ! En tous cas, c’est ce que notre étudiant a dû penser, car il n’avait pratiquement rien fait pour son travail de bachelor ! Son excuse était qu’il avait eu trop de travail chez son employeur, sur un projet très similaire d’ailleurs, bien que beaucoup plus simpliste. Il a de ce fait privilégié le travail chez son employeur, au risque (une réalité depuis quelques lors) de perdre le bénéfice de sa formation à la HES-SO; bien sûr, c’est son problème : mais que se passera-t-il lorsque son employeur le remerciera, ou plus probablement devra mettre la clé sous le paillasson ? Car il ne faut pas se leurrer : faire un site web simple, avec les outils disponibles est à la portée de presque n’importe qui, en particulier de générateurs de code automatiques que l’on devrait voir apparaître en production d’ici … pas très longtemps. Qui a parlé des intelligences artificielles génératives, au fond de l’auditoire ?

Que feront ces programmeurs peu formés lorsqu’ils seront en concurrence avec des générateurs de logiciels ? Question subsidiaire : que feront nos diplômés HES en informatique lorsqu’ils arriveront sur un marché du travail où sévissent des logiciels générateurs de code ultra-performants ? Leur formation leur permettra-t-elle de présenter encore un intérêt quelconque pour un employeur hypothétique ?

La faute n’est pas que du côté d’étudiants trop pressés d’entrer dans le monde du travail : elle est aussi du côté d’écoles trop fières de leur prestige académique. Pourquoi les Hautes Ecoles Spécialisées se sont-elles détournées de leur mission originelle qui les rendait proches de l’industrie et de la réalité du travail local ? Certaines institutions de la HES-SO n’acceptent plus que des professeurs munis d’un doctorat, au mépris de toute expérience industrielle préalable. Ces enseignants sont parfois brillants, mais le plus souvent aussi sur une voie de garage et totalement déconnectés de la réalité industrielle locale. Souvent recalés par de plus prestigieuses institutions, ils se rabattent sur les HES moins rémunératrices, mais aussi moins exigeantes envers les qualités des professeurs engagés. L’exigence du doctorat élimine par ailleurs nombre de personnes expérimentées et dotées d’un carnet de relations dont pourraient profiter les étudiants. Les professeurs engagés se contentent souvent de répéter des enseignements certes pertinents, mais purement théoriques, sans relation même lointaine avec la réalité professionnelle que ces écoles devaient à l’origine apporter !

Il n’y a pas si longtemps, certains professeurs d’informatique prônaient encore la supériorité d’un langage de programmation relativement à d’autres ! Un peu comme si il était impossible d’énoncer de manière correcte une vérité en allemand et qu’il fallait impérativement utiliser le français… Pendant plusieurs années, des étudiants avec un diplôme d’ingénieur en poche devaient avouer, lors de leur recherche d’emploi, qu’ils ne connaissaient aucun langage de programmation utilisable dans le monde réel (ce qui entre parenthèses, ne mettait guère en exergue l’enseignement dans l’école dont venait le candidat). L’ambition d’excellence académique est certes louable, mais pourquoi ne peut-elle être compatible avec une recherche d’efficacité dont notre tissu industriel a tant besoin actuellemnt ?

L’industrie manque cruellement d’informaticiens capables de gérer les projets qui se présentent actuellement. Faute de personnel adéquat, les projets sont sous-traités; en Europe de l’Est, en Russie, en Inde ou en Chine; est-ce le but ? « On cherche informaticiens ou programmeurs ». Mais on en trouve de moins en moins… Ou plutôt, on en trouve de moins en moins d’adéquats. L’intelligence artificielle pourra-t-elle répondre aux défis qui se posent à l’industrie actuellement ? Rien n’est moins sûr; mais faute de grives…