Blog Arolla

Le projet où j’ai essayé le présentéisme

Workaholics, presentism for the win !

Spoiler alert : Le culte du temps de travail, c’est mal, la qualité de code, c’est bien

Du simple acte de présence à l’addiction au travail, le présentéisme peut prendre de nombreuses formes. En France plus qu’ailleurs, il est bien vu dans de nombreuses entreprises. La plupart d’entre vous a d’ailleurs déjà dû entendre la fameuse pique “Tu as pris ton après-midi ?” lancée à quelqu’un qui quitte le bureau à 17h30. LOL !

Dans une mes précédentes entreprises, on appelait cela “l’implication”. Du développeur tout juste intégré aux managers du plus haut niveau, c’était une des valeurs les plus importantes. Le nombre d’heures travaillées par jour pouvait faire la différence au moment d’être augmenté (ou non).

C’est comme ça qu’on gérait l’imprévisibilité. Pour livrer à l’heure, il fallait rester tard. Mais attention! On se gardait bien de prononcer les mots “heures supplémentaires”!

Après plusieurs missions sans être augmenté, car pas suffisamment “impliqué”, je me suis dit qu’après tout :

  • c’était une des plus grandes entreprises d’informatique de France, s’ils réussissaient, leur modèle n’était peut-être pas si mauvais
  • tous les gens que je respectais dans cette société fonctionnaient de cette manière
  • si c’est ce qu’il fallait pour réussir dans mon métier de développeur, alors j’allais au moins essayer.

Une success story

J’ai profité du fait d’être propulsé lead developer dans une équipe pour me lancer. En théorie, j’avais des horaires fixes : 7h30 de travail par jour. Mes collègues architectes en faisaient plus : 9h30 – 19h avec une courte pause déjeuner. J’ai commencé à les imiter. L’effet a été immédiat : mes managers ont été contents de moi pour la première fois depuis looooongtemps !

Avec l’arrivée de la première livraison et le rush des deux dernières semaines, je suis rapidement passé à du 9h-21h sans vraiment prendre de pause à midi pour tenir les délais. La dernière semaine avant la livraison on était même plus sur du 9h-23h. J’étais épuisé, mais j’avais vraiment l’impression de faire partie de l’équipe. Tout le monde travaillait dur et longtemps. Quand je partais à 23h après avoir livré en recette, je savais que le chef de projet et le directeur de projet allaient recetter de 1h à 4/5h du matin. Et le client était livré en temps et en heure. Après les rushs, j’avais parfois une ou deux journées de repos offertes et on repartait sur un rythme moins violent, mais ça revenait très vite.

Un an après, j’ai reçu des augmentations, les premières en 2 ans, et j’ai été mis sur la liste courte pour une promotion. Les managers de toute la division disaient du bien de moi et de ce projet. Victoire !

Macron Superstar.

Le revers de la médaille

J’ai fait plus de 400 heures supplémentaires non rémunérées, ce qui fait environ 50 jours de travail ou 2 mois et demi. Il va sans dire que je n’avais plus de vie personnelle, le weekend n’étant plus fait que pour dormir !

Les délais nous ont poussés à ne pas faire de revues de code, de binômage, de tests automatiques. Nous n’avons pas détecté l’apparition de graves failles de sécurité. Le code est devenu incompréhensible et impossible à maintenir, même par l’équipe. En conséquence, il est arrivé que le temps de correction des régressions soit 3 fois supérieur au temps de développement.

Le client se plaignait du coût des évolutions et a fini par geler le projet. Ce ne fut pas le meilleur investissement pour mon employeur…

Enfin, je n’ai pas beaucoup progressé en développement et je ne peux pas dire que je sois fier de ce projet.

Travailler moins pour gagner plus

Mais j’ai appris quelques choses et pris des décisions pour mes futurs projets. La pierre angulaire ? Il faut travailler moins.

Laziness is a synonym of efficiency

1. Au bout d’une certaine durée de travail, on cesse d’être productif.

Je l’ai constaté lors de mes plus longues journées, je n’arrivais plus à me concentrer et j’avais du mal à trouver les solutions aux problèmes. Pire, parfois mon travail dans ces moments-là créait des régressions que je devais corriger le lendemain. En 2004, une étude américaine, réalisé par Hemp, conclut qu’après 8h de travail, nous devenons contre-productifs. En 2014, Midori Consulting publie un baromètre* affirmant que le présentéisme coûterait même plus cher aux entreprises que l’absentéisme. pyramide-midori

De plus, nous avons tous un rythme de croisière au travail. Se pousser au-delà de ce rythme fait baisser notre endurance. Les projets sont des marathons de plusieurs mois à plusieurs années, pas des sprints. Pousser son rythme et réduire son endurance, c’est se précipiter vers le burn out.

2. Plus de pauses, plus de créativité

Le développement est un travail créatif. Nos capacités à résoudre nos problèmes de développement dépendent de notre habilité à associer nos problèmes à des solutions “classiques” (des patterns). Dans le pire des cas, nous devons trouver une nouvelle solution.

La créativité a besoin de temps. La situation a déjà dû vous arriver, vous êtes coincés en fin de journée sur un sujet et en arrivant le matin, la solution vous paraît soudain évidente. Prendre du recul, du temps, penser à autre chose sont des éléments essentiels à un code de qualité.

3. Pas de qualité, pas d’évolutions

L’arrêt des lots d’évolution sur ce projet et mes expériences sur d’autres projets difficiles à maintenir m’ont montré que sans qualité de code, il n’y a pas d’évolution possible. La mauvaise qualité du code (et souvent de la documentation) augmentent le temps nécessaire pour le faire évoluer sans bugs de manière exponentielle.

4. On peut satisfaire tout le monde avec plus de qualité

En simplifiant grossièrement, pour réussir un projet, il faut satisfaire le client, le management et les développeurs :

  • Le client veut des fonctionnalités le plus vite possible et pour longtemps, un logiciel pérenne. Il pousse donc en général pour réduire les délais et payer moins cher.
  • Le management veut faire le plus de marge possible. Pour ce faire, il veut faire plaisir au client afin de continuer à vendre tout en minimisant les coûts.
  • Le développeur veut en général produire du code de qualité, dont il peut être fier, en souffrant moins de la dette technique et en conservant un certain équilibre avec sa vie personnelle.

Se focaliser sur la qualité de code permettrait de satisfaire tout le monde. En effet, un code de qualité, maintenable et bien documenté permet d’ajouter des fonctionnalités à un rythme bien plus élevé dans le temps. Dans mon cas, le logiciel a vécu pendant un an et demi avant de geler. Comme certains requins, un logiciel qui reste statique est condamné. Si nous avions pu ajouter des fonctionnalités sans ce risque élevé de régressions et des coûts prohibitifs, peut-être que ce projet aurait pu vivre plus longtemps. Dans ce cas, le client aurait eu son logiciel pérenne, le management en aurait tiré des bénéfices sur le long terme (sans compter l’effet bénéfique sur la réputation de l’entreprise) et les développeurs auraient été plus heureux.


Ces conclusions paraissent évidentes à de nombreux développeurs. Pourtant, même les plus convaincus ne les appliquent généralement pas.

Parfois je doute encore aussi. Je suis souvent tenté de faire plaisir au client en livrant vite. Je sacrifie la qualité ou mon temps personnel. A chaque fois que je l’ai fait, ça m’a créé des problèmes (régressions, élévation du coût de maintenance, etc.). D’autres fois, je pars dans l’autre direction, je deviens un nazi de la qualité de code et je tourne en rond. Un jour, je trouverai l’équilibre (binômage to the rescue).

Equilibre, Sapologie

Pour conclure, je vais paraphraser Clean Coder :

  • Il ne faut pas négocier sur la qualité ou les tests,
  • il faut négocier les fonctionnalités à coder dans le temps imparti.
  • Les heures supplémentaires sont à considérer :

    • en dernier recours
    • à un volume raisonnable (une heure ou deux par jour maximum)
    • pendant une durée prédéterminée (une ou deux semaines maximum)
    • avec une autre solution en cas d’échec

Et vous, comment gérez-vous la pression sur les délais de livraison ?

4 comments for “Le projet où j’ai essayé le présentéisme

  1. 1 juin 2017 at 9 h 42 min

    Cet article mériterait d’être partagé 100 000 fois 🙂
    Merci !

  2. 1 juin 2017 at 20 h 31 min

    100% d’accord, le présenteisme est tout simplement toxique sur le long terme

  3. grunk
    6 juin 2017 at 13 h 45 min

    C’est un problème typique des développeurs et/ou des SSII qui pour on ne sait trop quelles raisons acceptent ce genre de surcharge de travail.
    Dans n’importe quel autre domaine , personne n’accepterait de rester jusqu’à 23h au boulot sur des bases régulières. Et encore moins gratuitement. Une fois ok , ca peut arriver , tous les jours y’a un soucis.
    Perso en presque 10 ans dans ma boite actuelle , j’ai une fois du venir bosser un samedi pour respecter des délais , journée bien entendu payée …
    Le seul chambrage qui existe c’est quand on arrive à 9h au lieux de 8. Tu peux bien partir à 16h si ca te chante tant que ton taf est fait personne t’emmerdes.

    Si les délais sont pas tenu il y’a deux causes possibles :
    – Soit les dév se touchent la nouille et donc du coup doivent assumer leur retard => heures supp justifiées
    – Soit les manager ne sont pas capable de timer un projet correctement et déporte le problème sur les développeurs => il faut fuir ce genre d’entreprise (c’est pas le boulot qui manque dans notre domaine)

  4. HadrienMP
    7 juin 2017 at 14 h 27 min

    Je suis content que le contenu vous ait plu ! Je ne m’y attendais pas du tout alors je suis ravi !

    @grunk : Complètement d’accord avec ta conclusion. Il y a malheureusement encore des entreprises qui n’ont pas compris “un rythme soutenable ad vitam”. Ca me fait d’ailleurs penser à un de mes Diblert favoris : http://dilbert.com/strip/2014-11-11

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *