“Ton employeur te sous-utilise !”. C’est la remarque que m’a fait un jeune chef d’entreprise alors que nous discutions. Il est vrai que ma réponse est étonnante. Combien de temps, moi informaticien, je passe à écrire des programmes ? La réponse la plus évidente serait plutôt 100 %, pauses comprises. Alors comment en suis-je arrivé à moins de 10 % ?
Si vous me lisez, vous savez déjà que le métier d’informaticien ne se limite pas à coder. L’objectif est d’apporter une application qui répondra à la sollicitation des clients. La réalisation de l’application nécessite d’écrire des lignes de code dans un langage et dans un cadre adaptés au besoin de l’utilisateur.
Dans la série de l’été 2020, j’ai décrit les différentes étapes dans la création d’une application. Le codage est l’une de ces 7 étapes. Les autres phases semblaient ignorées par mon interlocuteur. Et pourtant, elles restent indispensables.
Peut-être que dans une autre organisation je passerai mon temps à écrire des programmes.
Mais pour cela il faudrait :
- qu’un analyste définisse les composants qu’il me faut créer ou modifier.
- qu’un architecte mette en place les environnements où déployer les composants.
- qu’un testeur valide mes applications dans un environnement complet.
- …
Je pourrais multiplier les étapes autour de l’acte de codage, ou même intégrer les activités communes à toute entreprise qui encadrent le domaine. Mais j’entends les critiques : “Un architecte doit scripter ses environnements. Un testeur doit automatiser ses cas de tests. C’est un peu du codage ? Non ? ”
Non ! Définir une configuration pour créer une plateforme, l’architecture, ce n’est pas du codage. C’est le développeur et non le testeur qui réalise le code des tests unitaires. Au mieux, le testeur configure un automate pour reproduire des actions. Ils utilisent surtout Word, Excel et Powerpoint. Pourtant architectes et testeurs sont des informaticiens.
Vous pouvez considérer que configurer un outil c’est programmer. C’est le principe du no-code. Mais cela fera sourire les forçats du clavier qui connaissent les promesses et les limites de ces outils. Aucun outil n’est parfait et un peu de réflexion est nécessaire face à une situation inconnue.
La remarque de mon interlocuteur reste intéressante. Elle permet de définir nos centres d’intérêts. Préférons-nous travailler sur un projet unique ou sur de nombreux projets ? Acceptons-nous d’être au contact des utilisateurs ou dans notre domaine entre spécialistes ? Devons-nous être pointus sur un domaine technique ou adaptables à tout contexte ?
Je travaille sur un pool de projets. Mon quotidien : recueillir le besoin, proposer et présenter les solutions techniques, définir les contrats d’interfaces, répondre aux sollicitations des utilisateurs, expliquer mes choix aux responsables de projets, empaqueter mes développements pour qu’ils soient déployés sur les serveurs (dont la production), …
Oui je code lorsque je réalise des maquettes et prototypes ou lorsque je finalise l’application attendue. Mais sans les activités périphériques, le risque de raté est considérable. Je pourrais demander une autre organisation de l’équipe pour ne réaliser que des activités de codes. Mais la multiplication de projets rend l’exercice périlleux. Et qui a envie de faire toujours la même chose.
Certes, il existe des génies qui savent travailler sans support. Ils produiront une application à jour des dernières technologies mais souvent mal adaptée au besoin du client. Et les nouvelles méthodes de gestion de projet ne pallient pas à ces manques. Au contraire, elles multiplient les interlocuteurs ou les étapes.
Mon erreur est de me présenter comme informaticien. Imaginez un ingénieur en BTP se présentant comme technicien de son entreprise. Dans les faits, il est un exécutant technique et le client n’attend que la réponse à son besoin. Les corps de métiers sont multiples et tous nécessaires au projet. Pourquoi ajouter un titre ronflant ?
S’il permet la concrétisation du projet, le code n’est pas la seule activité de l’informaticien.