J ’ai lu avec intérêt le billet suivant: http://blog.infine.com/conseils-a-un-jeune-developpeur-java-2133

Je suis sur le fond entièrement d ’accord avec l ’auteur mais la forme pose problème, ce qui est aussi relayé par certains commentaires. La question de la responsabilité de la formation est forcément soulevée.

Le développeur est-il seul responsable de sa formation? Dans la plupart des corps de métier, la réponse est évidemment non. Sous prétexte qu ’il y a tonnes de tutoriels sur le web et/ou que le développeur doit forcément être un passionné, il devrait passer son temps libre à s ’auto-former… Soulignons au passage que si tout travailleur doit savoir *apprendre*, tout le monde n ’est pas censé être pédagogue et l ’auto formation ne sera jamais aussi efficace qu ’un échange avec un instructeur qui a la pédagogie innée.

Le cas du débutant

Le développeur (souvent ingénieur, ce n ’est pas rien) sort de l ’école avec une base plus ou moins bonne, théorique, rarement pragmatique. Souvent en stage de dernière année pré embauche il sera directement vendu comme ingénieur au client (et non comme stagiaire). Certes, c ’est plutôt formateur comme première approche s ’il est au contact de coachs qui ont le temps de le former. Ce n ’est pas souvent le cas, après une introduction d ’une demi journée il sera en face de son IDE et devra pondre des lignes. La qualité du code produit laissera forcément à désirer. Peu importe, le client délègue souvent la technique et ne sera donc pas en mesure de capter la pauvre qualité produite. Le développeur débutant n ’est clairement pas responsable de cette situation. L ’effet papillon d ’une telle production est qu ’un second développeur non formé intervenant sur ce code bancal par la suite se dira « tiens c ’est comme ça qu ’on fait ici? » puis le copier/coller fera son oeuvre. De temps à autre un presta tiers spécialisé dans la revue de code (le bon rôle) pointera du doigt le problème et les développeurs s ’en prendront forcément plein la figure par le client et par leur chef de projet.

En passant qu ’elle est la différence entre un développeur et une personne qui fait de la revue de code? L ’un est facturé avec un TJM à la ramasse et peut ne disposer que de très peu de jours pour implémenter un cas d ’utilisation complexe alors que l ’autre, pour le coup reconnu pour ses compétences techniques, dispose en proportion de plus de temps pour revoir le code produit et l ’incriminer. Au final, il se pourrait très bien que les 2 disposent des mêmes compétences, ils n ’ont simplement pas les mêmes moyens.

Coder c ’est facile!

Bizarrement, lorsque l ’on parle d ’informatique d ’entreprise, on a le sentiment que la compétence peut facilement être acquise. Hors les outils, frameworks, standards, buzz se multiplient à une vitesse trop élevée pour que les choix de production finaux suivent. Le développeur doit alors constamment jongler entre les oldies (struts, frameworks faits maison,…), les standards de fait et bonnes spécifications (Spring, JPA, JSF 1), les nouvelles specs (JPA 2, JSF 2, CDI)  mais aussi les *nouveautés* (ce terme étant plus ou moins faussé et très relatif) (NoSQL, Scala, …). Les managers, clients et autres RESPONSABLES n ’imaginent pas combien il est éprouvant de passer d ’une techno à l ’autre, c ’est intellectuellement épuisant. Car utiliser une techno ne se limite pas à en maîtriser la syntaxe ou même les fichiers de configuration , c ’est surtout en comprendre la philosophie et pourquoi/quand l ’utiliser et en connaître ses bonnes pratiques et limites.

Administrer des systèmes et gérer des projets c ’est difficile sensible

Il est encore plus étrange à mon sens, et je pèse mes mots, que les budgets formations et certifications soient si pauvres voire nuls en comparaison aux mêmes budgets de formations et certifications des administrateurs dans leur ensemble. Pour avoir accès à certains chiffres éloquents, un administrateur OS, DB, réseau et Serveur d ’application se verra proposer régulièrement des formations pour mise à jour de ses compétences. Celles-ci se verront validées, mais surtout mises en valeur par l ’obtention d ’une certification. Pourquoi ce grand écart entre les admins et les développeurs? La réponse super naïve est de dire que les admins flirtent avec le réseau, l ’hardware dans son ensemble mais aussi et surtout la sécurité. En effet, un mauvais admin pourrait laisser ouvertes des failles de sécurité , il plantera une config routeur qui bridera à 10% la capacité réseau ou plantera le DNS, quand à l ’admin serveur d ’application il pourra planter son clustering en le paramétrant en UDP là où de toute évidence, seule la config TCP est autorisée…

Les managers pensant comme celà sont, et je jette un pavé dans la marre, irresponsables, naïfs et eux-même incompétents. Incompétents car ils n ’ont pas conscience que tous ces éléments critiques (sécurité, engorgement hardware, scalabilité) peuvent être mis en péril au niveau de l ’application elle-même. La plus petite des webapps peut provoquer des désastres. Un mauvais développeur mal formé pourra en 3 classes pourrir votre SI, ouvrir un faille de sécurité béante vers votre BDD (SQL injection) et monopoliser votre réseau inutilement (requêtes faites à la va vite sans réellement comprendre ce qu ’il se passe derrière). Vous pensez ces symptômes d ’un autre âge? Avez-vous entendu de la dernière grosse faille Yahoo? C ’était cette année: http://www.windstreambusiness.com/blog/2012/07/learn-from-yahoo-password-security-breach , cause: SQL injection, chose que l ’on peut créer dans n ’importe quelle application en utilisant mal JPA, JDBC, iBatis. Etre admin système requiert à mon sens des compétences solides, certaines pas évidentes mais pas vraiment d ’un niveau de complexité plus élevé que le développeur.

Passons maintenant aux chefs de projet. Pourquoi m ’en prendre à eux? Parce que justement je ne m ’en prends à personne, simplement dans beaucoup de domaines, les qualités d ’un chef de projet sont reconnues en opposition à celles du développeur que l ’on trouve banales, normales, aisées à acquérir. Alors certes, un chef de projet doit impérativement avoir un bon relationnel, être un bon communiquant et posséder un sens de l ’organisation et de gestion des *ressources* et compétences _sick!_ de son équipe la plus pertinente possible. En option premium il possédera des bases sur le métier du client et des bases techniques de surface. Une fois écarté le stéréotype du développeur geek qui ne sait aligner 2 mots et qui vit en ermite devant son dual screen, le développeur ne possède t ’il pas aussi les qualités que l ’on loue au chef de projet? Ou tout du moins une partie commune? Chacun sera libre de répondre.

Après 2 ans en TMA sur une appli delphi, swing ou struts, le pauvre développeur n ’a aucune motivation/raison pour aller de lui même se mettre techniquement à jour, pourtant on a tendance à estimer que c ’est implicite dans nos domaines. Comment l ’empêcher de vouloir se reconvertir/évoluer vers un poste de chef de projet? Un poste qui n ’est pas simple certes mais qui au moins ne sous-entends pas de constamment revoir ses compétences techniques et surtout un poste reconnu.

Checkpoint: dans la chaîne de responsabilité de l ’informatique, les chef de projets et sysadmins auraient tendance à voir leurs compétences reconnues alors que les développeurs non.

Tout le monde y trouve son compte … sauf le développeur

Les formations ça coûte de l ’argent. Dans un domaine hyper concurrentiel, une SSII qui formerait officiellement ses équipes devrait répercuter ces coûts sur les clients. Elle serait moins compétitive. Ainsi on ne peut rendre les directeurs de marché responsables de ce système.

Si j ’étais pour la théorie du complot et je ne le suis pas, j ’avancerai l ’argument suivant:

• un développeur correctement formé voire certifié produit plus vite mais surtout mieux
• il en résulte des coûts de maintenance corrective moins élevés
• mais aussi et surtout des coûts de maintenance évolutive réduits
• donc globalement moins de business à moyen terme

Le client qui *pense* qu ’écrire une application coûte ce qu ’elle coûte avec les TJM (ou forfaits, les proportions restent respectées) constatés de nos jours devraient se poser la question suivante: « et si je demandais à chaque profil qui est amené à travailler sur mes applis qu ’il possède dans ses bagages une vraie formation et/ou certification? ». Peut être devrait-il supporter une hausse des tarifs sur le court terme mais il se rendrait compte qu ’au final il a tout à y gagner.