dimanche 30 mars 2014

Pourquoi ai-je voulu faire partie de la liste http://jesuisundeveloppeur.io/

Pourquoi ai-je voulu faire partie de la liste je suis un développeur ?

Pour deux raisons essentiellement.


Un bon rapport certes, qui aurait mérité à être plus percutant


La première pour réagir au rapport de Tariq Krim remis à Fleur Pellerin, il y a quelques jours. Faire la promotion des développeurs et les présenter comme un atout pour la France, c'est bien. Il s'agit même d'une très belle initiative, car pour une fois, le développement logiciel est présenté comme un levier et non comme une contrainte. En dresser la liste du top 100 est en revanche une vision trop réductrice à mon humble avis. M. Krim ne pensait pas à mal, d'autant qu'il reconnaît lui-même la subjectivité de la dite-liste, mais dans ce cas, quel est l'objectif recherché ? Si elle permet en effet de valoriser les travaux de nombreux développeurs Français, elle n'est pas représentative de toute la population existante de développeurs, codeurs, architectes, programmeurs. J'ai pour ma part, eu la chance de rencontrer certaines personnes dans ma vie professionnelle, qui ont fait de moi ce que je suis aujourd'hui : un amoureux du code.

Ces développeurs sont pourtant anonymes, n'ont pas de blog ou bien n'ont pas le temps de les maintenir car trop occupés déjà à faire leur travail avec passion et professionnalisme. Je pense à Stéphane dans le Pas-de-Calais, mon mentor, autodidacte et pourtant meilleur programmeur que j'ai connu : il avait ce don pour écrire des algorithmes sortis des sentiers battus, plus performants, plus courts et plus élégants aussi (oui, le code peut être beau !). Il y a aussi Laurent, mon professeur en DESS (il y a donc plus de dix de cela) qui m'a ouvert les yeux et surtout l'esprit sur une autre vision du métier de développeur. Il m'a donné l'envie de créer, d'innover, de réfléchir à ce que je fais : pourquoi programmer comme ça, pourquoi tel pattern, est-ce que telle fonction peut être implémentée autrement, etc. Ils sont inconnus, et il y en a plein d'autres que nous connaissons tous.

A la place d'une liste, j'aurais souhaité que le rapport aille plus loin dans les recommandations car 6 mesures proposées seulement, même si certaines sont des plus pertinentes, c'est un peu décevant.

Pour rappel, les 6 mesures en question sont :
  1. Prendre en compte le rôle essentiel des développeurs : Il s'agit du point le plus important à mon avis. Ce qui m'a plu  : "L’univers des développeurs bénéficie en France d’une faible reconnaissance. Ils sont souvent considérés comme des exécutants." et "Les développeurs sont dans un angle mort : on ignore leur nombre. On ne sait pas grand chose sur leurs trajectoires, leurs qualifications.". Et c'est malheureusement tout. La mesure ne précise pas comment changer cet état de fait.
  2. Une feuille de route technologique pour l’État, les ministères et les opérateurs publics : M. Krim présente le phénomène de rupture(s) technologique(s) que nous connaissons - la mobilité, les objets connectés, le cloud et le Big Data - et propose de renforcer les secteurs impactés par ce phénomène comme la santé, l'éducation et l'énergie à l'aide d'une feuille de route à destination des DSI précisant quelques axes technologiques et aussi la mise à disposition de briques logicielles ouvertes, standardisées et réutilisables sur ce qui serait un "Github Français". Sur ce point, et travaillant qui plus est dans le secteur de la santé, je trouve cette mesure des plus pertinentes.
  3. Promouvoir les développeurs dans l'administration en cessant de considérer les projets de développement logiciel comme "autonomes et non évolutifs" en faisant notamment la promotion des méthodes agiles et en diminuant la "sous-traitance aveugle" aux grosses SSII/ESN et autres prestations coûteuses d'assistance à MOA, qui lorsqu'elles sont invoquées sur des domaines stratégiques, conduisent régulièrement à l'échec des projets IT. Si je suis d'accord sur ce point, je suis plus timoré sur sa conclusion lorsque M. Krim propose "de promouvoir les développeurs aux postes de responsabilité pour la conduite des projets numériques" car tous les bons développeurs ne font pas nécessairement de bons managers. En revanche, il faut que les développeurs, notamment ceux qui travaillent sur le cœur de métier de leur Entreprise soient plus écoutés, et qu'ils soient plus sollicités concernant les choix techniques ; je n'ai que trop connu le nombre de solutions choisies pour des considérations purement marketing sans tenir compte du vrai besoin utilisateur, et cela même au détriment de la valeur ajoutée fonctionnelle.
  4. Adapter les conditions d’investissement pour soutenir les projets technologiques en octroyant une quote-part de "20% des projets financés en les ouvrant aux startups disruptives". Là, rien à redire, il s'agit d'une proposition qui pourrait faire bouger les lignes.
  5. Formation des développeurs : L'auteur présente un stock de compétences important mais aussi "des recruteurs qui ont souvent du mal à trouver des candidats adaptés aux postes à pourvoir" et de l'autre côté "des ingénieurs qualifiés à des tâches de techniciens informatiques faute de candidats employables à ce niveau de formation". Le manque de développeurs adaptés aux postes à pourvoir pourrait passer également selon l'auteur par la mise en place d'un "visa de travail pour les développeurs venant en France" . (c'est la 6ème mesure).
Fin du rapport.

Et je suis un peu déçu car à la place de ces 6 mesures et d'une liste de 100 développeurs (- pourquoi pas mais je ne comprends pas à quoi cette dernière peut bien servir... -), j'aurais préféré plus de recommandations encore, un rapport peut-être un peu plus percutant telle qu'une proposition de réforme des SSII/ESN qui reposent toutes sur un modèle économique aux conséquences dévastatrices car elles ne participent pas à la promotion du rôle du développement logiciel en tant que levier. Le mode de fonctionnement de nos SSII limite la possibilité de doter notre pays d'une réserve de compétences pointues car expérimentées donc plus chères et par conséquent plus difficiles à placer chez les clients. Car ces SSII cherchent avant tout à placer des jeunes sans expérience sur des missions là où il faudrait un développeur sénior ; faire un maximum de profit pour un minimum de coûts. En effet, les SSII sont selon moi une des causes majeures de la mauvaise image du métier de développeur en France.

Enfin, je n'ai pas vu dans le rapport un phénomène inquiétant pour les séniors : celui des développeurs de plus de 35 ans qui veulent continuer à coder et qui, s'ils veulent le faire, ne le peuvent qu'en devenant indépendant. Car à cet âge, il est très difficile de trouver un employeur pour faire du développement logiciel ! C'est un fait !


Dénoncer le fait qu'à 35 ans, en France, on n'a plus le droit de coder


C'est aussi pour cette deuxième raison que j'ai donc souhaité faire partie de la liste : parce que j'ai 35 ans et que je suis développeur !

Par conséquent cela signifie aux yeux du monde professionnel de l'IT en France, que j'ai raté ma vie de chef de projet !! Et si cela était à refaire, je ferai en sorte d'échouer de la même manière :)

Il n'y a pas longtemps, un chasseur de têtes pour le compte d'une grosse SSII (vous avez ces boîtes d'intérim de luxe !) m'a indiqué "votre profil technique est très intéressant, mais on aurait préféré que vous évoluiez vers un poste de Direction de Projet, avec une compétence commerciale... plus forte". Et bla bla bla...

Serait-ce une gageure que d'aimer vouloir continuer à coder après 35 ans, continuer à apprendre, créer, améliorer ?

Là, où je travaille, mes supérieurs me considèrent comme un geek... Mais pourquoi tant de haine ? Pourquoi faut-il sans cesse essayer de faire entrer les gens dans des cases ? Sommes-nous des marginaux ?

Je voudrais pouvoir espérer qu'il en soit tout autre... Tous les matins, je me lève avec la question suivante : que vais-je apprendre aujourd'hui, et que vais-je partager avec les autres ? Est-ce un crime ? Pourquoi suis-je considéré comme un simple exécutant par ma hiérarchie alors que j'ai un bon retour de la part des utilisateurs (qui sont finalement mes vrais clients) ? Ces derniers sont satisfaits de mon travail, ne me considèrent pas comme un extra-terrestre pour autant. Je comprends leur langage, je m'adapte, et finalement, j'en sais plus sur le fonctionnement de la boîte que mes chefs. Peut-être vous reconnaissez-vous aussi ?

Il existe, je pense, un problème plus général encore dans notre pays qui touchent tous les métiers d'ingénierie : une forme de dédain ou un désintéressement pour tous les métiers à composante technique ou scientifique

Aujourd'hui, nos administrations et autres sociétés du secteur privé sont de plus en plus "managées" (il y a quelques années, on auraient "gérées" mais "managées" est un terme plus hype) par des personnes issues de telle école de commerce ou de marketing qui pourtant, ne connaissent rien au cœur de métier, voire ne veulent pas s'y intéresser. Ces mêmes personnes ne sont malheureusement là avant tout que pour quelques années (3 à 4 ans maximum en général) en pensant que leur carrière a plus de valeur que leurs devoirs. C'est aussi vrai pour des mandats dans certaines administrations publiques ; les présidents ne sont nommés que pour cinq ans en général, ce qui laisse peu de place pour appliquer une stratégie sur le long terme. Difficile dans ces conditions de faire évoluer les mentalités.


Le non rôle du management intermédiaire


Il y a aussi ces "managers" dans certaines directions qui ne veulent pas faire progresser leurs collaborateurs en ne les associant que très peu aux projets cœur de métier de leur Entreprise. En effet, c'est bien connu, on préfère faire appel à des boîtes externes qui ne connaissent pas le métier et qui doivent pourtant rédiger tel cahier des charges à la place de la MOA qui n'a pas le temps pour cela... Et après, on s'étonne de voir que les projets dérapent. Et puis, on fait appel à d'autres consultants pour assurer la réalisation du projet car les informaticiens, eux, qu'ils soient développeurs, DBA ou administrateurs systèmes, ne savent pas travailler correctement...

Combien de chaînes intermédiaires inutiles et coûteuses dans la réalisation d'un projet informatique ? Pourquoi ne pas proposer d'investir dans la gestion de la connaissance et son partage au sein de l'Entreprise, à chercher à limiter la dette technique ? Combien de talents (développeurs ou autres) sont mal ou non utilisés ? Dans le management par le Lean, il s'agit même d'une des 8 formes de gaspillage.

Alors, j'ai une proposition à faire à ces mêmes "managers", si vous voulez vous montrer dignes de ceux que vous gouvernez : accordez-leur plus de confiance, ces gens sont issus du terrain, ils se lèvent le matin pour un idéal, pour faire avancer la boîte, pensent "collaboratif" et non pas "individuel", bref, ils représentent un potentiel non négligeable de "création de valeur"... laissez-les s'exprimer ! Vous n'avez rien à perdre... A moins que...

Et si, au lieu d'externaliser ces personnes, ces informaticiens, ces scientifiques (qui continuent de déserter nos contrées parce qu'il n'y a pas de place pour la recherche), au motif qu'il faille réduire les dépenses dans un contexte de crise économique, on externalisait, à la la place, ces managers, ces strates intermédiaires, qui coûtent cher ? Après tout, quel est leur apport concrètement ? Je le cherche encore...

1 commentaire:

  1. Custom software development often comes to the aid of business houses that are looking to either automate or IT-enable their manual processes.The process can also be effectively used to enhance or extend the existing IT infrastructure that is currently in use, to cater to growing businesses requirements.


    développement sur mesure .net

    RépondreSupprimer