Quand je serais grande, Je serais ingénieur en informatique

Il arrive de temps en temps de devoir parler de son métier, et souvent juste le libellé du poste permet de définir plus ou moins précisément un métier. J'aimerais que ce soit si simple avec ce que je fais. 

Pour commencer, mon poste a déjà changé de nom quatre ou cinq fois, mais celui que je retiens est "ingénieur d'études en informatique" ce qui pour moi est le plus parlant, parce que je fais principalement des études dans le domaine informatique. Mais souvent quand je réponds ça les gens posent la question fatidique "mais tu fais quoi exactement ?", et là se pose le problème : expliquer ce que je fais vraiment ou essayer de simplifier. 

J'ai tout d'abord essayé en simplifiant au maximum : "Je travaille sur les phases de conceptions des applications". Souvent j'ai eu le droit à "tu développes des applications pour smartphone alors ?".

J'ai donc essayé de développer un peu plus : "je participe à la rédaction des spécifications des fonctionnalités des applications diverses et variées".

Et les réactions se rejoignaient souvent par un "Ha. Ok.", qui veut tellement dire "Ok, on a rien compris, c'est le monde obscur des informaticiens, de toute façon vous passez vos journées à glander sur le net et à boire du café" 

Du coup je l'ai transformé en : "En gros, j'explique comment ça doit fonctionner, par exemple là quand tu dois mettre ta date de naissance dans un formulaire et que tu essayes de mettre le 32 mai ça bloque, ça veut dire qu'il y a quelqu'un derrière qui a dit "ici, on doit mettre un contrôle pour vérifier que la date est correcte" et ce quelqu’un c'est moi".

Mais j'ai toujours eu ce "Ha. Ok.", qui voulait toujours dire : "Ouais, c'est un truc facile quoi, en gros tu sers à rien, c'est cool d'être payée à rien faire ma veille".

Et puis j'en ai eu un peu marre et je me suis dit pourquoi pas aussi expliquer ce que je fais vraiment en listant à peu près les tâches qui me sont affectées : "Je participe à la conception des applications, surtout sur la partie expression de besoin et spécifications, mais je fais aussi un peu de développement et de recette, je prépare les supports de formation et les manuels d'utilisation (que personne ne lit)"

Et quand on me demande en quoi ça consiste exactement, j'essaye de simplifier.

"Alors on va prendre un exemple. Lorsque tu t'inscris sur un site tu as un formulaire à remplir, tu dois renseigner plusieurs données : ton nom, ton prénom, ton code postal, ta taille, etc...

- La première étape est de savoir quelles données vont être nécessaire pour le fichier client de l'entreprise : j'ai juste besoin du nom et d'un mail pour le contacter, ou j'ai aussi besoin de son adresse pour lui envoyer du courrier, ou ça serait bien de savoir s'il aime les chats, s'il préfère le vert ou le bleu ... Ça c'est expliquer le besoin (dit comme ça, c'est simple, mais je peux vous assurer que depuis que je bosse j'ai rarement vu une personne exprimer un besoin sans exprimer la solution).

- Une fois que le besoin est défini, on va spécifier avec les contrainte techniques :

   * Pour le nom, on a besoin d'un champ de saisie alphanumérique de 50 caractères, et le champ doit être renseigné correctement pour la validation du formulaire (c'est d'ailleurs pour ça que des fois les "Lee" ou "Tan" ne peuvent pas s'inscrire : parce que quelqu'un a spécifié qu'il fallait au minimum 4 caractères). Il faut penser à tout, à TOUT, même à Monsieur Lee ! (et ce n'est pas aussi facile que vous le pensez). 

   * Pour le code postal, on a besoin d'un champ de saisie numérique qui doit faire 5 caractères, la saisie doit correspondre à une valeur existante dans le fichier fourni par la poste (je vous passe la partie sur les tables de références et tout ça) et une fois que le champ est saisi, un autre champ est automatiquement alimenté avec le libellé de la ville fournit par le même fichier (et si plusieurs villes sont disponibles, alors une liste de valeur s'affiche pour permettre à l'utilisateur de sélectionner lui-même la ville).

- Quand la spécification est terminée, relue et validée par 50 million de personnes (généralement plus reloues les unes que les autres et qui auront toutes leur mot à dire, même la virgule mal placée), alors elle passe en développement. Le code, tout ça... vous savez, le truc obscur que personne ne comprend, mais qui fait que quand on appuie sur le bouton ça fonctionne.
Juste ce qu'il faut savoir c'est que c'est un véritable métier et que si on ne sais pas développer ça ne peut pas s'improviser (je dis ça parce qu'a mon boulot on m'a quand même dit "oui c'est simple quelqu'un sans aucune notion de développement va le faire parce que avec toi ça prend plus de temps", résultat le programme est passé en prod, ça a merdé grave et on est venu me voir : "je comprends pas ça ne fonctionne pas", là déjà faut expliquer ce que c'est un test unitaire (tu vérifies que ta fonction marche bien) et ensuite tu explique que si tu mets un si avec trois sinon à la suite sans expliquer "sinon quoi" ça ne peut pas fonctionner ( .... )

- En parallèle, un cahier de recette est rédigé. Il contient tout les tests que l'on va réaliser pas à pas pour vérifier que l'application fonctionne comme elle doit fonctionner. Dans notre exemple, on va avoir un cas pour dire essayer de valider le formulaire sans nom, essayer de saisir un nom de plus de 50 caractères, saisir un nom ...

- Et les supports de formation et manuels, on sait tous ce que ça veut dire, c'est comme les CGU, personne ne les lit jamais mais elles ont le mérite d'exister. (d'ailleurs j'ai glissé un "Charlie" (le personnage avec son bonnet et son t-shirt rayé) dans un de mes documents mais je crois que personne ne l'a jamais trouvé)

Au final, après toutes ces explications : soit je passe pour une grosse reloue avec un métier relou, soit je perd la moitié des gens en route.

Donc aujourd'hui je dis juste "je bosse dans l'informatique" et si on demande encore en quoi ça consiste, je répond "je m'occupe des ordinateurs", et maintenant j'ai le droit à un "Ha, ok !" avec  un regard plein d'admiration qui veut dire "Cool, comme ça je sais que si un jour j'ai un problème je pourrais te demander !" alors que non.

PS : Cela décrit une partie de mon activité, je ne vous parle pas des charges, délais, des clients, des fournisseurs et autres contraintes pour "faciliter" mon activité.