alterlibriste

D’un côté on nous présente les développeurs comme les maîtres du monde, ceux qui tiennent les rênes des sacro-saints algorithmes tous puissants qui régissent l’univers, de l’autre, dans le monde de l’informatique la même personne est un pisseur de code placé en mission par un marchand de viande. Plus qu’un avis tranché sur la vérité qui doit se trouver quelque part entre les deux, je voulais partager cette constatation afin que chacun puisse se faire sa propre idée.

Tous ceux qui connaissent un peu l’informatique que ce soit à titre de loisir ou professionnel savent à quel point on peut passer pour des extra-terrestres pour ceux qui n’y comprennent rien. On ne cesse de rabâcher dans les médias que le numérique est partout et gère toute notre vie, si les non-utilisateurs se résument à une frange de plus en plus faible de la population, la proportion de ceux qui comprennent comment cela fonctionne ne semble pas augmenter même (et surtout) parmi les jeunes qui n’ont jamais eu à taper une ligne de commande pour faire démarrer un jeu ou un logiciel (et comprendre pourquoi ça ne marchait pas).

Alors forcément, quand on ne comprend pas, on remet (littéralement) sa vie entre les mains de ceux qui comprennent et font tourner. On en serait presque arrivé au point où "l’informaticien" serait le guérisseur, le prêtre ou le chaman des civilisations anciennes. Celui qui sait et peut faire quelque chose pour notre sort. Mais je m’égare du sujet principal, le code. Pour avoir exercé dans le métier quelques années, j’ai un peu vu l’envers du décor. On nous parle de génies qui créent des révolutions ou des empires (tous les systèmes d’exploitation et services ont le leur) mais cela vient souvent uniquement de l’idée géniale de départ et de la façon de la mettre en place.

Si certains développeurs se font plaisir à monter de nouveaux projets et d’autant plus dans le monde du logiciel libre où cela peut être à leurs heures perdues et mis à disposition de tous, le boulot en lui-même n’est pas toujours palpitant : trouver des bugs, apporter des modifications ou des améliorations, essayer de tout faire tenir ensemble jusqu’au moment où il faut tout réécrire parce que les nouvelles fonctionnalités ou les nouveaux outils nécessitent une refonte complète.

Lorsque je suis entré dans ce métier (au début des années 2000), c’était après quelques mois de formation afin d’aller faire les modif nécessaires dans les systèmes obsolètes mais toujours utilisés par les grandes entreprises (et pas des moindres puisqu’elles étaient les premières à avoir informatisé leur production dans les années 70-80 comme les industries ou les banques) afin de pouvoir passer à l’Euro. Est-ce que cela a changé ? Pas sûr puisque maintenant des écoles comme Simplon.co transforment en quelques mois un chômeur en développeur d’appli mobiles. Les objectifs ont changé mais il y a toujours des besoins à pourvoir pour pisser du code.

Hormis quelques développeurs plus géniaux que d’autres qui trouvent des algorithmes bien chiadés, le code se résume à utiliser des morceaux qui font déjà ce qu’on souhaite, à accéder à des bases de données, à faire des tests pour garder celles que l’on souhaite, à faire des tris, à calculer, à afficher, à enregistrer dans les bases... reste ensuite à tester pour voir si ça fait bien ce qu’on veut.

Car il ne faut pas se leurrer, ce genre de boulot, s’il requiert de reconvertir en quelques mois des gens qui cherchent du boulot, c’est qu’il n’est pas intéressant (techniquement et/ou financièrement) pour les développeurs fraîchement émoulus des écoles spécialisées et qui ne jurent que par d’autres technologies (dont l’espérance de vie ne dépassera peut-être pas la décennie). Et lorsque l’on commence à bien se débrouiller pour faire de la maintenance et un peu de développement, on passe vite au niveau architecture : écrire ce que d’autres devront coder. Si on le fait correctement, ça prend autant de temps que de le faire en code, sauf qu’on n’a pas à le tester et voir qu’on avait oublié un ou deux détails qui compliquent les choses, nécessitent des contournements, voire ne marchent pas (à non, cette donnée-là n’est plus renseignée, on fait autrement).

Finalement, les développeurs (ainsi que les administrateurs systèmes) sont comme les artisans : plombiers, électriciens, mécaniciens... Ils ouvrent le capot pour voir ce qu’il y a dessous et pour brancher ou réparer des tuyaux, des fils ou des moteurs. Ils ont un savoir-faire et une compréhension pour savoir comment ça doit marcher et trouver où il faut intervenir. Cette capacité, tout le monde ne l’a pas et n’en a pas besoin au quotidien, il faut juste que ça marche et que chacun fasse son boulot. Mais elle n’est pas plus ésotérique ou plus compliquée (sauf qu’elle est dématérialisée puisque numérique). Et quand l’artisan monte en expérience, il fait les devis (parce qu’il sait ce qu’il faut faire et la complexité de la chose) et il supervise et/ou fait faire par ses ouvriers. Il est bon car il sait comment ça marche et a une vision d’ensemble ; il saura détecter là où il y aura des problèmes et comment corriger un problème.

Alors, certes, le codeur fait des choses dont dépendent la plupart de nos activités quotidiennes mais au même titre que les artisans. Ils n’ont ni à être loués ni à être dénigrés, on a besoin d’eux si on ne sait pas faire. La question ensuite est de savoir à quel point on dépend d’eux et les technologies que l’on utilise pour savoir si elles sont ouvertes ou pas. Changer un phare sur une voiture devient parfois une véritable épreuve tout comme modifier un paramètre de son environnement de bureau. Peut-être que ça mérite réflexion ?