[opinon] une remise en question existentielle du métier de programmeur

**Mat.M** · 14/04/2014, 18h35

bonjour comme le titre le suggère je suis donc en pleine remise en question de ma fonction d'analyste-programmeur.
désolé si 'est un peu long ou pas assez exhaustif il y a cependant beaucoup de matière à développer.

permettez-moi de parler de moi...
comme tous les post-ados sortant de formation ou de l'université, j'étais un "génie de l'informatique" et je bricolais des trucs en assembleur et en langage C pour programmer des jeux vidéos..

puis arriva par diverses expériences professionnelles , la confrontation inévitable avec les réalités de l'entreprise et du monde du travail.
Je me suis rendu compte qu'en entreprise on n'aime pas trop les "génies de l'informatique" on préfère des gens qui finissent la demande du client dans la journée qui suit si c'est pas tout juste d'être fini pour la veille.

Sauf que ma conception des choses a totalement évolué depuis le moment où j'ai commencé à travailler pour ce secteur il y a plus d'une dizaine d'années si c'est pas quinze ans maintenant.

Je suis en recherche d'emploi les employeurs,SSII et éditeur et autres entreprises veulent "basiquement" des développeurs avec + de 3ans d'expérience sur NET ou Java
Pour le candidat qui sort du cursus universitaire passe encore c'est parfaitement compréhensible et légitime.
Mais pour un "routier" comme moi difficile de rester dans la fonction de développeur classique.

impressions et analyses diverses

Suite à une large réflexion ( conséquente à un projet de migration VB6 vers VB.NET s'étant avéré un fiasco total) , j'ai l'impression que les employeurs, les entreprises en France et celles qui constituent le secteur de l'Informatique ont pour la plupart un manque de vision globale des choses.

Que les entreprises françaises ont mal compris les enjeux de la mondialisation, sauf les grosses entreprises du CAC40 évidemment qui ont les moyens d'avoir des marchés à l'étranger.

La Mondialisation c'est avant tout la rationalisation tous azimuts,pousser à l'optimisation extrême des flux de productions quant ce n'est pas la réalisation de services ( cf production offshore de services informatiques)..bref ce qu'on appelle communément économie d'echelle...tout ça pour que ça rapporte économiquement.

Evidemment on va me rétorquer, pour faire simple que le service en informatique ou l'édition logicielle c'est pas du tout comme produire des chemises à 1millions d'exemplaires au Bangladesh ou en Chine..

Mais tout projet logiciel a un coût logiciel et les coûts de développements des projets logiciels sont en train d'exploser est-ce que je me trompe ?
Sans compter les projets de plusieurs millions qui se plantent carrément mais je ne reviendrai pas là dessus.
Là où je veux en venir , j'en reviens à mon idée de départ c'est que les entreprises en France manquent de vision à long terme des choses, de la conceptualisation des services à l'entreprise, de l'économie en général.

Manque de vision globale qu'est ce que c'est ?
Une lapalissade , une phrase qui ne veut rien ou tout et n'importe quoi certes...

ceci dit en quelques mots, avoir une vision globale c'est suite à toute l'analyse d'un projet informatique, ce qu'il apporte au client,s'il a un intérêt commercial évident...
à votre niveau ça peut être apporter des fonctionnalités intéressantes,construire une architecture de projet.
Mais ça peut être toute une logique de refactorisation, de construction de noyau ou briques logicielles.

Un exemple si vous éditez et commercialisez un logiciel de comptabilité, au bout de 5ans si vous êtes toujours dessus c'est que soit vous serez dépassé commercialement et techniquement , soit que le produit vivote.
L'intérêt est de capitaliser sur le produit ; en d'autres termes si vous êtes capable de faire un logiciel de compta vous pouvez faire un logiciel pour d'autres métiers.
Maintenant on ne s'emballe pas faut voir si c'est pertinent de se lancer dans une autre voie.

Qu'elle est le rapport avec la choucroute ?
Lorsque je vois des petites annonces ou je vais en entretien d'embauche on demande toujours la même chose : être un expert avant tout.
Je crois que c'est se tromper totalement.
Enfin j'ai tort parce qu'à court terme non ; c'est évident il y a les demandes clients ou les travaux de développement à finir.
Mais sur le long terme un expert Java ou .NET n'apportera pas grand chose parce que si il a trop le nez sur le guidon comme on dit familiérement et qu'il est concentré sur les aspects techniques il ne pourra pas faire avancer les choses, ne pourra pas faire preuve de créativité

La faute notamment aux éditeurs de solution logicielle et de développement qui commercialisent des outils trop complexes et trop diffus pour mener à bien un projet informatique..
alors le développeur que je suis ou que vous êtes au quotidien se perd dans le dédale de SDK ou d'API, de méthodes de classes et n'a pas une vision abstraite et plus orientée "métier" des choses...
Faire des experts Java ou .NET c'est une bonne chose mais cela représente une partie du problème.
Attention je m'entends , si vous avez une certification Java c'est tout bénéfice pour l'entreprise qui vous embauche.

Mais un projet constitué d'experts techniques peut s'avérer être un projet inutile qui conduit à l'échec si on ne sait pas où le mener et comment le mener à bien , ceci sans cette vision globale des choses que j'ai évoquée précédemment
Et puis être expert sur un langage informatique c'est quelque part dépassé parce que la sous-traitance offshore est là maintenant qu'un indien de Bangalore ou un Tunisien fera du code aussi bien que vous.
Pas aujourdhui peut-être mais demain c'est certain.
Sans compter les codes sources de l'Open Source qui apportent quelque part une dévaluation du code que vous produisez...
parce que l'écran de gestion des clients que vous êtes en train de développer , quelque part il a été fait des dizaines de fois par d'autres entreprises...
ah zut raté c'est l'essence même d'un ERP sensé simplifier les choses( ne refaites pas le débat ERP versus client serveur s'il vous plait )

Et pendant ce temps-là en entretien d'embauche on me rabâche sans arrêts la question combien d'années d'expérience en C# ?

Evidemment en informatique on a toujours à apprendre des langages de programmation ,des méthodologies mais je me répète c'est pas ça qui fait un projet informatique.
Sans compter que les techs deviennent vite obsolètes cf les différents frameworks .NET , pour ça l'éditeur que je ne citerai pas sait parfaitement bien gérer l'obsolescence programmée des technologies informatiques.

Le problème de "mettre en avant"
Tout ça c'est bien joli des paroles et pas d'actions,tout le monde est capable de "refaire le monde".
Ceci dit je ne sors pas de formation non plus j'ai des années derrière-moi donc j'ai bien un avis sur la question.

Si demain je commence sur un projet il n'est pas question d'arriver et de dire que le projet est mal fichu, il faut tout jeter et recommencer.
Là je vais me vautrer en beauté si ce n'est par se faire éjecter de l'entreprise..

Mais...au bout d'un an voire plus sur un projet s'il n'y a pas une remise en question des choses établies, vous serez dans la même situation que moi :
vous allez vous ennuyer terriblement sur un projet parce que votre quotidien sera de pondre bêtement des lignes de code, faire du support client ou de la Tierce Maintenance Applicative.

"Se mettre en avant" et évoluer,ceci dit, demeure un exercice périlleux.
Beaucoup de gens ne le font pas parce qu'ils ne veulent pas avoir de responsabilités et de travailler 50heures par semaine...
Sans compter que les salariés en entreprise sont souvent mal considérés..et qu'il n'y a pas forcément une augmentation de salaire au bout..

Donc voilà tout le dilemme auquel je me sens confronté..

**GuillaumeJ** · 14/04/2014, 20h36

Envoyé par Mat.M

Donc voilà tout le dilemme auquel je me sens confronté..

Si je te suis : au début, tu pars sur "Expertise technique sans vision métier = échec", il me semble, et je suis d'accord. Puis du coup, tu te plains que ton poste est trop technique et pas assez fonctionnel ? Ou que la technique est trop abstraite ? (raison de l'echec de ta conversion VB6-VBNet ?)

Pour ma part, ça fait quelques mois/années que je me demande si je devrait pas tenter de séparer mon métier de ma passion : autrement dit, faire au jour le jour un boulot moins de programmeur ( peut-être administrateur réseau, au sens large, histoire de faire du scripting), et du coup garder l'essentiel de mon énergie de développement sur des projets persos. Plutôt que de devoir recoder le soir après avoir déjà codé pas mal la journée...

Une raison pour laquelle on recherche des experts techniques qui ne savent que cela, c'est que le travail est souvent hyper-découpé : chacun sa fonction précise et limité, ce qui au final est une source connue d’insatisfaction au travail : je réalise que dans ma carriére atypique, j'ai beaucoup de bol de commencer (ou presque) dans une grosse PME ou je gérai toutes les étapes du dev, de la prise des besoins a la maintenance évolutive : si j'avais travaillé comme exécutant d'un cahier des charges sans lien avec le client.. ca m'aurait peut-être écoeuré, en tout cas nettement moins motivé..

**el_slapper** · 15/04/2014, 09h32

Plein de choses là-dedans...

Mais sans être sur de savoir ou Mat.M veut en venir, je suis d'accord avec l'analyse de GuillaumeJ : le surdécoupage des tâches est catastrophique.

Je ne parle pas du découpage "horizontal" par domaine : si il y a un gusse qui s'occupe du marketing, un autre de la finance, deux filles à la synthèse, et un dernier larron à la trésorerie, ça n'est pas un problème majeur(si ce n'est d'assurer des backups, mais bon, ça se gère).

Je parle du découpage "vertical" par étape du projet : j'ai passé (et lamentablement foiré, mais tant mieux) un entretien en début d'année, pour lequel j'aurais été "concepteur technique". Passant après le rédacteur de cahier des charges, le rédacteur de spécification fonctionnelles générales, la rédactrice de spécifications fonctionnelles détaillées, avant le rédacteur de spécifications techniques détaillées, les codeurs, les testeurs, les homologateurs, les intégrateurs, les gens qui mettent en prod, et les gens qui font la maintenance.

C'est une manière de penser qui vient de l'industrie. Ca tombe bien, moi aussi, je viens de l'industrie. Et ça n'a juste aucun sens de faire ce genre de découpage : l'industrie est une production de masse répétitive. Chaque projet informatique est une R&D différente de la précédente(sinon on réutilise). Dans l'industrie, spécialement dans l'automobile, j'ai constaté une grande autonomie des équipes de R&D, comparé aux fonctions de production. Le chercheur est généralement capable de faire du dessin industriel, papier ou electronique, de faire des bricolages pour tester ses idées, de concevoir le produit mais aussi sa fabrication, etc.....

Tout simplement parceque les différentes étapes de conception sont liées intellectuellement. Avoir en tête la conception de mon pare-chocs en tête, par exemple, mais aussi des raisons qui ont poussé à chaque choix de conception, aide beaucoup à concevoir le moule qui va fabriquer la pièce en masse. La dynamique intellectuelle est forte entre les différentes étapes d'une R&D. Elle est beaucoup plus faible entre les différentes étapes d'une production. Le gars qui monte le pare-chocs sur la voiture, peu lui chaut comment il a été fabriqué.

Quand on fait de l'exploitation informatique, on s'en moque de savoir comment les programmes ont été codés. Il n'y a pas de lien intellectuel fort. Mais jusqu'à la mise en prod du logiciel, la continuité intellectuelle est évidente. Tant qu'on a pas compilé une version définitivement validée, tout l'historique depuis la verbalisation informelle du besoin est utile pour mieux appréhender ou on va, et ce qu'il faut faire.

Après, il est difficille de maitreiser toutes les étapes du processus. Mais, à mon sens, en "vertical", il ne faut jamais dépasser 3 intervenants(les aller-retours sont permis, et même recommandés) : métier, technique, tests. Et c'est là que les visions industrialistes des managers informatiques sont abérrantes. Quand on a 3 intervenants "métier", 4 "techniques" et 2 "tests" qui se succèdent sur un domaine précis, plus personne ne sait vraiment à quoi ça sert, comment ça marche, ou ce qui reste à valider. On passe son temps à faire de la doc, ce qui est une tâche aliénante(si on ne fait que ça), inutile(les specs changeant rapidement, la spec détaillée est très vite fausse), et faussement sécurisant(en fait, les trucs importants à saisir sont souvent intangibles, et absents d'une spec,même "détaillée").

Je ne dis pas que la doc est inutile : un guide pour s'y retrouver est essentiel. Mais une doc exhaustive intermédiaire(par exemple entre le "métier" et le "technique", ou, pire, entre le "concepteur général" et le "concepteur détaillé") est une aberration(sauf en exploitation, ou les process sont sensés être strictement répétitifs), et baser un process sur une doc exhaustive pour passer la main de petite main en petite main est une torture inefficace, inutile, et fort couteuse. D'ou, le semble-t-il, la démotivation de Mat.M et l'echec de nombreux projets à 9 chiffres en euros.

**Mat.M** · 15/04/2014, 13h02

Envoyé par GuillaumeJ

Si je te suis : au début, tu pars sur "Expertise technique sans vision métier = échec", il me semble, et je suis d'accord. Puis du coup, tu te plains que ton poste est trop technique et pas assez fonctionnel ? Ou que la technique est trop abstraite ? (raison de l'echec de ta conversion VB6-VBNet ?)
.

salut non je pense que mon message initial est un peu confus
Pour moi la technique n'est pas du tout abstraite c'est l'inverse , c'est trop terre-à-terre ce qui fait que ça peut être délocalisé

Je résume ce que j'ai voulu signifier: si au bout de 15ans tu est encore analyste-programmeur c'est que tu n'as pas su évolué
Au bout de 15ans tu devrais être patron d'une boite du CAC40

Non je n'ai pas fumé la moquette, après tout le PDG de Ryan Air a eu l'idée d'avions de ligne sans pilotes.
C'est ça la vision globale des choses.
Donc une entreprise dans 50ans ça se géra tout seul en appuyant sur un bouton
Je sais je caricature à l'extrême.
Et moi dans tout ça qu'est ce que je fais puisqu'on rationnalise à l'extrême l'Economie ?

Si tu montes une entreprise sans vision globale tu est foutu, tu ne pourras pas faire tourner l'entreprise..parce que la concurrence va te manger.
Le reproche que je faisais dans mon premier message c'est que tout ce que j'ai vu au niveau de l'entreprise c'est pas ou peu de vision globale.

Dans la revue économique Capital il y avait un article sur une grande chaine de distribution de vin , et que pour gérer tout le système...un outil informatique faisait 70% du travail ce qui est énorme.

**Miistik** · 15/04/2014, 13h35

C'est moi où ça part dans tous les sens ?

Une petite remarque :

Pour ma part, ça fait quelques mois/années que je me demande si je devrait pas tenter de séparer mon métier de ma passion : autrement dit, faire au jour le jour un boulot moins de programmeur ( peut-être administrateur réseau, au sens large, histoire de faire du scripting),

Tu sembles expérimenté mais ceci m'a interloqué.
L'administration réseau est un métier, comme celui que tu exerces actuellement.
Ce n'est pas si simple.

Ensuite, je vois pas trop où tu veux en venir ?

Après relecture, tu parles de manque de vision globale, d'abstraction, de capitalisation.
Pour lire régulièrement ce forum et étant non développeur de "métier" (je suis apprenti), on voit beaucoup de plaintes justifiées sur les deadlines intenables des projets informatiques.
Si la capitalisation était en paramètre non négligeable comme tu le conçois, vous (oui je dis vous les développeurs) auriez des deadlines encore plus serrées.

Ensuite pour la vision globale, l'abstraction, je dirais que ce n'est pas ton métier ou du moins pas ton rôle actuel dans l'entreprise.
Tu n'as donc pas à " t'encombrer " de cela pour faire les tâches qui te sont confiées.

Voilà ce que je peux dire en espérant avoir compris ton post qui est relativement confus.

**GuillaumeJ** · 15/04/2014, 14h28

Envoyé par Mat.M

Je résume ce que j'ai voulu signifier: si au bout de 15ans tu est encore analyste-programmeur c'est que tu n'as pas su évolué
Au bout de 15ans tu devrais être patron d'une boite du CAC40

Tu parles alors d'ambition, notamment personnelle..

Ca devient éminemment personnel (pardon pour la répétition) du coup. Et ca fait entrer pleins de choses : est ce que dans t avie, ton but c'est d'évoluer dans ton travail ?
Et aussi, des questions de sociétés : il est évident que l'informatisation est en train de détruire le travail (lu rapidement quelque part que pour 4 emplois détruits, un est créé) et que nos sociétés ne vont peut-être plus longtemps pouvoir fonctionner selon les normes du 20eme siecle.

Aprés, pour ma part, je me contenterai trés bien d’être analyste-programmeur au bout de 15 ans.. sauf que j aime avoir des responsabilités techniques et un pouvoir de décision (techniques toujours)...