Note préliminaire :

Cet article avait initialement été rédigé au tout début du mois de février 2016, durant un burn-out qui a conduit à mon départ de la société en question, puisque je n’y était plus du tout à ma place comme vous allez pouvoir le constater. Je n’ai quasiment pas touché au texte, hormis retirer des passages trop « violents » après relecture à froid.

Cet article n’a pas vocation à jeter la pierre à mon ancienne société (malgré les quelques mois difficiles sur la fin, dus aux conditions de travail décrites ci-dessous et au burn-out qui se mettait en place). Elle m’a quand même apporté beaucoup de choses au final et reste très loin des SSII « pures et dures » qui peuvent défrayer l’actualité du domaine.

Ce texte a plutôt pour vocation à éclairer les futurs candidats sur les conditions qu’on peut rencontrer dans une SSII. Comme beaucoup maintenant, je considère qu’une SSII est un bon tremplin pour un jeune diplômé, mais qu’il faut aussi savoir tourner la page quand on sent que ça peut déraper.
La diversité des domaines permet de monter en compétence rapidement et de toucher à plein de sujets et de technos différentes, chose qu’il est beaucoup plus difficile de réaliser sur un poste fixe dans une société standard où votre poste n’évoluera que très peu. Mais les conditions de travail n’y sont pas toujours très roses, et il faut en avoir conscience, surtout si comme moi on a des difficultés à ne pas pouvoir faire son travail correctement (au sens de l’état de l’art).

Il était une fois la vie… d’un petit développeur !

2008. Encore en école d’ingénieur, je dois trouver un stage pour valider mon diplôme. Déjà à cette époque les SSII (devenues ESN par la suite) n’ont pas la cote, mais je fais quand même le choix d’en intégrer une petite de 200 personnes, très familiale, très axé industrie (ferroviaire, aéronautique, énergie…). L’expérience est plus que concluante et positive, et j’enchaîne donc avec un CDI avant même d’avoir terminé mon stage.

J’enchaîne immédiatement sur des projets intéressants, et cette société s’avère même être plutôt en avance technologique et technique sur son époque. La méthode Scrum n’est connue que depuis 4 ans, mais on a déjà en place en interne des méthodes agiles (daily meeting, peer review, backlog…), alors même qu’on continue à vendre du cycle en V aux clients en externe. Hudson (devenu Jenkins) date de 2005 mais est déjà déployé sur pas mal de projets, alors même qu’il n’est pas facturé explicitement aux clients.

On a de la relecture de code plus ou moins obligatoire, des tests unitaires avec une bonne couverture de code. On travaille sur des projets de grands envergures (équipes de 10 personnes et plus, 300, 500, 1000 voire 1200 jours-hommes…) et des technos intéressantes. On fait confiance aux équipes (fraîchement sorti de mon stage, ma hiérarchie a osé me faire confiance et j’ai pris le lead sur certains morceaux d’architecture de projets critiques), on a du matériel correct pour travailler.

Ça n’a certes pas empècher quelques projets de déraper (j’ai souvenir d’un soft qui avait régressé à 99% juste pour avoir chercher à inverser 2 couleurs dans les fichiers de sortie générés) et d’autres d’être difficile au niveau de la relation client, mais globalement les équipes techniques ont les moyens et le temps de faire leur travail correctement.

2012. L’année charnière. La crise est passée par là (même si elle a à mon avis bon dos), les relations clients deviennent plus difficiles. Les budgets ne sont plus là, les délais non plus. Les projets continuent à rentrer mais la concurrence entre SSII fait que les prix sont tirés vers le bas, chacun voulant rentrer des projets et les volent aux autres en massacrant les prix. Les clients n’ont plus les yeux en face des trous et en tout cas des moyens totalement décalés par rapport à leurs besoins.

Les clients ont commencé à inventer de nouveaux modes de gestion de projet, avec des notions de « POC (preuve de concept) » (comprendre du code kleenex que si ça marche on garde, si ça ne marche pas on jette, et que dans les 2 cas, on cherche à ne pas payer le fournisseur quand même), de « challenge » (comprendre qu’on sait que c’est infaisable ce qu’on demande mais que tu pourrais quand même faire un effort quoi).

Les méthodes agiles ont aussi eu le malheur de devenir le buzz-word du moment, et du coup sont apparues dans les plaquettes et propositions commerciales. Sauf qu’elles sont devenues la justification pour faire n’importe quoi, comme ne plus du tout faire de spécification, supprimer les tests unitaires ou la revue de code, ou encore livrer n’importe quoi très vite.

Les développeurs se retrouvent du coup avec des projets sous-vendus (50 à 100 jours max) et une qualité technique massacrée. L’intégration continue a disparu des écrans radars, tout comme la revue de code. Les équipes ne sont plus formées, le niveau technique global chute drastiquement, les « têtes » qui tenaient les projets à bouts de bras partent. Les chefs de projet senior sont remplacés par des juniors qui n’ont de chef ni la formation ni la volonté ni le charisme nécessaire pour tenir tête aux commerciaux et à la direction. Il n’y a même plus vraiment d’équipe projet, ou alors se résumant à un développeur débutant encadré par un développeur à peine plus senior propulsé chef de projet, tout étant dorénavant géré par les commerciaux en pratique.

2015. Le coup de grâce. Les buzz-words sont de retour. « Big-data », « cloud », « IoT », « cyber-sécurité ». Plus aucun appel d’offre ne sort sans en contenir plusieurs sinon tous. On fait n’importe quoi, et cette fois non seulement d’un point de vue commercial et technique, mais aussi, et c’est encore plus grave, d’un point de vue éthique. Les projets qui dépassent les 10 jours-hommes se comptent sur les doigts d’une main et ceux avec plus de 2 personnes affectées dessus aussi.

Trop c’est trop

Vous l’aurez compris, je ne me sens dorénavant plus à ma place. Je n’ai plus le temps ni les ressources pour faire correctement ce que j’estime être mon travail.

Techniquement, je n’ai plus le temps de faire de revue de code, de former les nouveaux arrivants ou de mettre en place les outils pour faire du code de qualité, parce que les commerciaux gardent la main sur l’ensemble des manettes et ont transformé les ingénieurs en techniciens voire en ouvriers. Pas étonnant que les Chinois ou les Indiens grignotent de plus en plus le marché, ils coûtent 10× moins chers pour une médiocrité équivalente.

Éthiquement, les projets réalisés sont de plus en plus en contradiction avec mes idéaux, avec des objets connectés où la sécurité est bien le dernier des soucis et où la vie privée n’existe plus, même en option. Parce que le discours commercial ambiant est en contradiction totale avec les nécessités techniques, surtout dans une ère post-Snowden.

Humainement parlant, les délais sont intenables, le stress élevé, la pression aussi. Les moyens ne sont plus suffisants pour travailler, j’en arrive même à devoir héberger des projets sur mes propres machines parce que ceux qui devaient faire cette partie ne veulent/peuvent/savent pas le faire, faute de moyens et de temps. Parce que la rentabilité ne peut être maintenue qu’en sur-exploitant le personnel.

J’ai déjà plusieurs fois alerté ma hiérarchie sur les problèmes rencontrés, ça a conduit au mieux à tenter de me retourner les neurones à coups de justification bullshitto-marketo-commercialo-financier, en général à aucune action sérieuse qui suit et au pire à des prises de bec de plus en plus violente.

J’ai aussi eu le droit à quelques remarques, du style que j’étais trop pessimiste ou trop utopiste. Pour le côté pessimiste, comme dit le proverbe, les pessimistes sont des optimistes avec de l’expérience, et malheureusement ma vie personnelle aussi bien que professionnelle n’a que trop rarement contredit ce fait. Pour le côté utopiste, le fait que je développe beaucoup de logiciel libre sur mon temps libre montre qu’il est parfaitement possible de faire du code propre avec des méthodes propres sans que ça ne coûte plus cher ou nécessite de délai supplémentaire, voire parfois le contraire. De plus, je ne demande pas non plus la perfection, juste de pouvoir faire ce que l’état de l’art actuel réclame : un peu de revue de code, de l’intégration continue, des tests unitaires, utiliser des bibliothèques, réfléchir a minima à une architecture, assurer une formation minimale des équipes… Mais c’est effectivement souvent en contradiction avec les impératifs commerciaux ou financiers…

Le travail en SSII est aussi un coup de roulette russe permanent, une épée de Damoclès. Si vous avez la chance de réussir à rester plus ou moins sédentaire au sein du bureau d’études pour réaliser les projets forfaitisés, vous pouvez contrôler a minima l’impact de votre vie professionnelle sur votre vie personnelle.
Mais si vous avez le malheur d’être envoyé en mission, parfois à l’autre bout de l’Île-de-France, vous pouvez être baladé tous les X temps (X variant de 3 mois à 10 ans) d’un client à l’autre, d’un lieu à l’autre, dans des conditions qui en plus sont théoriquement illégales au vu du Code du Travail (délit de marchandage et prêt de main d’œuvre illicite).
Si vous êtes parmi les chanceux du premier groupe, vous n’avez en plus pas intérêt à devenir le petit caillou dans la chaussure du service, sinon le second groupe vous tend rapidement les bras. Comme on dit, en SSII, le licenciement n’existe pas, on appelle ça « partir en mission »… :)
Dans mon cas, mon dernier départ en mission a aussi été synonyme du sacrifice de ma vie associative et collaborative. Il est en effet bien difficile de trouver du temps libre et de la motivation pour travailler sur des projets personnels quand vous faites 8h-20h « effectif » tous les jours, dont 3h de transport dans les bouchons (non comptés dans les temps de travail, merci la SYNTEC !). C’est à mon avis ce sacrifice qui a accéléré ma décision de partir.

Le temps du changement ?

Aujourd’hui, je n’ai plus réellement de points d’attache en lien direct avec cette société. J’y reste parce que c’est près de chez moi, parce que les collègues sont sympas, parce que j’ai le temps de travailler à l’extérieur sur des projets qui eux me tiennent à cœur et que je n’ai pas honte de publier. Alors que je préférerais y rester parce que les technos utilisés sont intéressantes, parce qu’on y fait de la qualité logicielle ou de la gestion de projet réellement agile. Et dans tous les cas, la situation tire fortement sur un truc où je n’y aurais plus du tout ma place, un projet vraiment pas éthique ou un gros projet bien bordélique de passage achèverait de m’achever.

Le temps pour moi d’aller découvrir le reste du monde ?