Est-il possible de sanctionner un salarié pour non-livraison ?

Bonjour,

Préambule : vous aurez remarqué que ces derniers temps j’ai du mal à être actifs sur tous les sujets, souvent on me répond et je n’ai pas le temps de faire de même… Il est prévu dans mon agenda que je réponde à vos messages, tous topics/billets/MP confondus. La situation est compliquée ces temps-ci de mon côté.

Contexte

Le Super Client

Nous avons un nouveau client (extrêmement) important pour la startup d’un point de vue financier et stratégie à court et moyen termes. Mon dev est prêt depuis quelques mois donc c’est cool. Il s’agit d’un import de données d’un fichier Excel vers notre db.

Le Super Fichier

• Vendredi dernier : Ce client devait nous fournir le fichier de données il y a 2 semaines, il ne l’a fourni que vendredi dernier. Le CTO m’en a parlé à 17h10 (je finis à 17h le vendredi, donc j’ai pas regardé, d’autant que j’avais un rdv perso). A noter que la semaine précédente j’étais déjà resté vendredi jusqu’à 17h20 et qu’au cours des deux dernières semaines je suis déjà resté plus tard que mes horaires, une fois je suis même revenu à 23h (bien qu’en tout j’aie travaillé 1h de plus seulement que la durée normale quotidienne.)

• Aujourd’hui (lundi) :

  • Ce matin, lundi donc, j’apprends du CTO qu’il est absolument impératif de procéder à l’import des données en local, puis dev, puis sur la prod. Le CTO doit s’absenter pour une raison perso à partir de 16h donc je devrai me débrouiller seul ou avec le Lead Dev.

  • Le matin, je passe mon temps à cleaner les données du fichier Excel ainsi qu’à faire des micro-ajustements dans mon script d’imports car certaines données sont incohérentes.

  • Fin d’après-midi, je tombe sur des erreurs "PHP Memory Limit Exceeded" côté serveur de dev (et de prod probablement), or nous n’avons pas la main pour modifier ces données. Le fichier Excel est en effet volumineux et la représentation en RAM avant insertion en DB doit l’être tout autant.

  • L’après-midi toujours : le framework d’import de données que j’utilise n’était pas connecté à MySQL, ce qui résultait en une erreur, dont je pouvais m’apercevoir uniquement si j’avais lancé les imports quand je testais en mode "Asynchrone" (job queued d’import) et non "Synchrone" (= import exécuté tout de suite en CLI). J’avais oublié de faire ça durant ma phase de dév des imports et ne m’en n’étais aperçu que cette après-midi durant le lancement des imports en local puis sur dev. Cette erreur de configuration du framework, je l’ai résolue rapidement.

• Il ne m’a jamais été demandé de lancer un import avec un gros fichier, sauf vendredi après 17h10 (mais comme déjà expliqué je l’ai pas fait). Ainsi, même si on avait évité l’erreur de config du framework, on aurait de toutes façons eu la Memory Limit puisque je n’aurais jamais été en mesure de tester avec le gros fichier volumineux que le client nous a donné très en retard, vendredi, pour un import en prod lundi.

On m’a fait comprendre qu’on allait me passer une soufflante demain matin au daily. D’autant qu’ils auraient été obligés, apparemment, de faire appel à un ancien freelance ayant bossé pour nous, en urgence.

Il faut comprendre, de leur côté, que :

• Ce client est d’une importance cruciale pour la boîte, pour qu’elle puisse progresser financièrement, même si ses finances sont OK actuellement.

• Le CTO a été extrêmement clair, ce lundi uniquement, sur le fait que la livraison en prod était impérative pour ce soir. (Par message Slack uniquement, et aucune forme de compensation annoncée).

Il faut comprendre, de mon côté, que :

• Le dev des imports est OK depuis plusieurs mois

• On a commencé à me parler de ce gros fichier à importer vendredi car le client l’a livré en retard

• On va me reprocher des problèmes d’imports alors qu’il y a du memory limit côté serveur, sur quoi je n’ai pas la main.

  • On va me dire : tu n’avais qu’à refaire tout ce dev et réutiliser des parties de ce que tu as déjà fait, sans utiliser le framework de l’import : ainsi tu n’aurais peut-être pas eu de memory limit.
    • Oui mais c’est pas sûr en fait, et puis de toute façon ça prendrait trop de temps : j’aurais probablement travaillé plus de 10h ce soir (je suis déjà à 8h au minimum car 39h et j’ai déjà dépassé d’1h). De plus ils sont relous pour la compensation : pas d’heure supp, mais toujours 15min ou max 30min à récupérer par-ci par-là, car ça se verrait trop par rapport aux autres collègues, qui sont tous au forfait jour sauf moi.

• Je n’ai ainsi pas l’impression d’avoir causé de problème au niveau de mon dev. Je n’ai pas l’impression que l’impossibilité d’importer soit ma faute. Ce n’est pas non plus ma faute si le client envoie son fichier avec énormément de retard, un vendredi après-midi, pour un import en prod prévu lundi.

Question

Au vu de ces informations, je sais déjà que demain matin on va me pourrir au daily, on me l’a fait comprendre, mais vous : pensez-vous qu’on puisse me chercher de sérieuses noises à cause de ça ?

Fallait-il vraiment que je n’aille pas à ma séance de JuJitsu ce soir, et que je bosse plus de 9h voire plus de 10h ? En étant sûr que ce ne sera pas compté en heures supp, et en étant sûr que, si jamais ils acceptaient de compenser, ce serait à raison de 15min et 30min max parfois ?

Merci… Je suis un peu perdu dans cette boîte… J’ai passé en toute fin de semaine dernière un entretien dans lequel ils se disaient très satisfaits mais que je devais prendre confiance en moi, et ils m’avaient expliqué en quoi ce client était d’une importance cruciale… Comme pour me préparer psychologiquement à accepter tout et n’importe quoi pour bichonner ce client et, surtout : pour que tout puisse sortir dans les temps quitte à ce que je bosse 999 heures par jour (quasiment gratuitement donc, ou au mieux avec un système de compensation super chiant à coups de 15min / 30min max sur tels ou tels jours de la semaine).

Mais oui c’est absolument vrai. D’ailleurs dans ma boîte précédente, les imports avaient été plannifiés beaucoup plus larges (bien que des erreurs d’organisation et de devis avaient aussi eu lieu).

Edit : je pense qu’ils avaient vendu une semaine ou deux d’imports au client (j’espère), mais comme le client a livré en retard son truc bah ils n’ont pas voulu reporter la date de livraison de la durée du retard…

PS : en fait je ne suis même pas sûr que ce travail a été vendu, nous ne gagnons a priori de l’argent que grâce aux abonnements à notre logiciel. Et cet import sert juste à initialiser les données dans notre logiciel.

A noter cependant que les imports réels d’aujourd’hui sont (légèrement) simplifiés, une version (légèrement) plus complète aurait lieu dans une semaine ou deux (mais bon, avec très très peu de modifications donc cette précision peut être ignorée).

Concernant l’erreur Memory Limit ce n’est définitivement pas ma faute, c’est une erreur côté serveur, il aurait fallu que je lance un import sur un énorme fichier en dev, et rien de tout ça n’était prévu par la hiérarchie donc bon. Je devais juste faire les devs en local et tester en local. Du coup bah j’avais fait ça et ensuite il fallait que je passe à d’autres tâches quoi. Là les tests sur dev on me les a demandé aujourd’hui jour de l’import en prod. Et ce n’est pas mon dev qui est en erreur je le précise, mais visiblement plutôt la représentation en ram du framework d’import ou bien du fichier lui-même.

Concernant l’erreur de configuration que j’ai mentionnées dans l’op :

J’avais anticipé ça durant le dev, tout était prêt. Mais je n’avais pas pensé à lancer mes tests en mode asynchrone. Or cela était nécessaire pour trouver cette erreur de configuration, qui a été résolue en vingt minutes.

Pourquoi n’y avaisje pas pensé ? Par manque d’anticipation (mais au niveau du code c’était ready). Et aussi parce qu’on ne m’a jamais demandé de tester sur un gros fichier.

J’en profite pour préciser que le fichier fourni par le client n’est pas si énorme que ça, il contient quelques milliers de lignes pour chacune de ses trois sheets. Bon cette précision est inutile mais quand même.

Salut

Je ne vais pas me prononcer sur le fond, mais sur la forme.

Et là, j’espère sincèrement pour toi que tu as quelqu’un avec qui tu peux discuter en direct d’un peu tout et rien, mais aussi du travail, et peut-être surtout de cette situation. C’est ou ça deviendra vital, et je t’assure que je pèse extrêmement précisément mes mots là tout de suite.

Tu bosses toujours pour la même boite que dans tes messages précédents qui concernaient le monde de l’entreprise ?

Si oui, c’est clairement l’heure pour toi d’aller voir ailleurs.

Pour le cas que tu nous décris ici :

D’une part, l’organisation semble complètement défaillante. En particulier, on ne maintient pas une date de livraison impérative si le client ne livre pas ses parties en temps et en heure ; on impose pas une première livraison de données en moins d’un jour ouvré. Encore plus si le capitaine en profite pour abandonner le navire.

D’autre part, je vois deux choses qui pourraient t’être reprochées objectivement :

1. Ne pas avoir prévenu d’un problème assez tôt (tu ne dis pas que tu l’as fait, vu comment tu détailles je supposes que tu ne l’as pas fait). De ce que tu racontes de ce matin, personnellement j’aurais levé une alerte au moment où je me serais rendu compte que les données client sont pourries, une seconde en me rendant compte que le serveur n’était pas correctement dimensionné, une troisième à l’erreur de configuration. Pas besoin d’être bavard sur ce genre d’alerte, le premier truc à faire est de prévenir qui de droit pour qu’un éventuel plan de secours puisse être trouvé (communiquer le plus tôt possible avec le client – surtout si ses données sont pétées –, dégager du temps d’un dev plus expérimenté pour t’aider, etc). Par exemple, pour la première, un simple « Bonjour XXX, j’ai reçu les données de Client, mais elles ne sont pas au format attendu. Je fais ce que je peux pour les corriger mais je ne peux plus garantir la livraison à temps. Contacte-moi si besoin. » suffit.
2. Ne jamais avoir testé la volumétrie cible. C’est un problème ultra-classique : quand on développe un truc, on doit savoir quelle est la volumétrie cible parce que la solution en dépend complètement. Et on teste – pas forcément en dev, si les PC/environnements de dev ne le permettent pas, mais au moins avant d’avoir des vraies données client. Et ça, le lead dev aurait du le voir.

une fois je suis même revenu à 23h (bien qu’en tout j’aie travaillé 1h de plus seulement que la durée normale quotidienne.)

Étant donné que tu parles d’être revenu à 23 heures, je me permets de rappeler qu’il y a un temps de repos quotidien d’au moins 11 heures consécutives entre deux journées de travail, sauf dérogation. C’est bien d’essayer de garder ça en tête pour éviter des soucis, tant de santé que légaux.

Fallait-il vraiment que je n’aille pas à ma séance de JuJitsu ce soir, et que je bosse plus de 9h voire plus de 10h ?

Ça ne m’étonnerait pas que ton employeur puisse t’obliger à bosser plus sur une journée. Cela dit, ce genre de choses est encadré par la loi donc renseigne toi sur ce qu’il en ait dans la loi en fonction de ton contrat, ta branche, ta convention collective, etc.

pas d’heure supp, mais toujours 15min ou max 30min à récupérer par-ci par-là, car ça se verrait trop par rapport aux autres collègues, qui sont tous au forfait jour sauf moi
[…]
En étant sûr que ce ne sera pas compté en heures supp, et en étant sûr que, si jamais ils acceptaient de compenser, ce serait à raison de 15min et 30min max parfois ?
[…]
(quasiment gratuitement donc, ou au mieux avec un système de compensation super chiant à coups de 15min / 30min max sur tels ou tels jours de la semaine).

Idem que mon paragraphe précédent en ce qui concerne les heures supplémentaires ou le dépassement puis rattrapage d’heures, si tu veux pouvoir négocier avec ton employeur, il vaut mieux se renseigner sur tes droits et devoirs ainsi que ceux de ton employeur. Par contre, petit point d’attention, être rigide là-dessus peut pousser ton employeur à être rigide sur d’autres points où il est actuellement souple à ton avantage.

Avec toutes les situations que tu racontes dans cette boîte, ça fait environ la 12e fois que tu aurais dû être viré sur le champ. Ce n’est toujours pas le cas :

• Boîte mal gérée
• Difficulté de recrutement

Ces deux points font que c’est plus important pour eux de te garder malgré quelques retards et petits soucis plutôt que de se retrouver avec 1 développeur en moins pendant 6 mois. Parce que malgré tes problèmes de stress (liés à des problèmes psychiatrique très probablement) et de confiance en toi, bah tu dois probablement faire le travail correctement.

Des erreurs, tout le monde en fait, des retards, il y en a toujours, des ratés de livraison, tout le monde en a vécu. Bref la situation raconté n’a rien d’extraordinaire et tous ceux qui ont quelques années d’expérience professionnelle ont probablement déjà vécu ça.
Et même si on peut toujours reprocher une erreur à une personne en particulier, le travail en groupe (ou avec des responsables) fait qu’il n’y a jamais qu’un seul responsable.

Dans ta situation :

• Le client a 2 semaines de retard sur l’envoi de son livrable —> est-ce qu’un commercial a relancé le client ? le client a-t-il été prévenu que cela engendrerait du retard dans le développement interne ? est-ce que l’équipe de dév a été prévénue ?
• Taille de fichier volumineuse surprise —> as-tu eu une information avant le dév sur la taille de la BDD ? quelles sont les specs d’entrée ?

Bref des erreurs il n’y a pas que toi qui en a fait. Il y a eu des ratés partout, tout le temps. C’est NORMAL. Si les projets se passaient bien, on se feraient un peu chier.

Tu devrais probablement consulter un psychiatre ou psychologue car les situations de stress que tu vis ne sont pas "normales". Imaginer le pire sur une situation comme celle-ci (et toutes celles que tu décris) c’est vraiment pas courant.
Et changer de boite pour trouver un environnement de travail un peu plus carré et moins stressant ne ferait pas de mal par rapport à ta condition.

Ça a donné quoi finalement ?

Bonjour tout le monde,

Excusez-moi du retard avec lequel je vous réponds. Il faudra d’ailleurs que je fasse un tour sur les autres topics et mes MPs sous peu (peut-être ce weekend).

Tout d’abord, merci BEAUCOUP pour vos avis / suggestions / explications / réponses + en général.

Au final :

• J’ai fait part de ma propre initiative de ma faute : n’ayant pas testé mon dév d’import de fichier, avec un fichier rempli de données fake que j’aurais généré, sur les environnement de dev et de préprod, au lieu de le faire avec un mini fichier en local.

• Le CTO a juste dit qu’il ne faudrait pas que ça réarrive (en visant plus large qu’une tâche d’import je pense), sinon "ça ne serait pas la même chanson", mais il ne m’a pas engueulé. Il a dit que pour cette fois, ça passe.

• Mon collègue lead dev a dû lui-même indiquer en réunion avec l’équipe que mon dev fonctionnait bien (ce que le CTO n’avait pas dit), mais que c’était juste sur les environnements de serveurs dev/préprod que ça ne passait pas (problème de mémoire vive insuffisante).

• J’ai précisé que mon dev était bien compatible avec les gros fichiers (j’utilisais les chunks par exemple). J’ai dû rappeler à une autre réu que le client avait livré très en retard. On m’a expliqué (enfin, ré-expliqué, car j’étais déjà au courant avant ma fameuse "livraison ratée") que ce client serait le plus gros de l’agence si on arrivait à faire l’import en temps et en temps, même s’il a livré son fichier en retard. Quand je dis "plus gros" c’est qu’en gros, à lui seul il rapporte 1500x<un objet-métier de nos abos, en fonction duquel est calculée une "rente" pour nous>. Sachant qu’il appartient à un énorme groupe, ce qui fait qu’en fait c’est potentiellement des dizaines ou centaines de milliers d’objets-métier. Alors que notre plus gros client actuel c’est juste 250 objets-métier. Donc, le CTO et le PO m’ont dit qu’on n’aurait pas pu décaler la date de livraison, les enjeux étant bien trop importants. Ce sera comme ça avec d’autres gros clients à venir. Mais ils ont précisé : que ça ne deviendra pas la norme, et qu’à un moment on pourra en effet décaler en cas de retard de la part du client.

• Ils m’ont retiré de toute tâche relative à ce gros client. Visiblement ils ont vu que je n’étais pas prêt à rester plus tard que 18h40 ni à enchaîner plus de 10h de travail en une soirée pour réécrire tout un dev. Et, malgré les apparences, je pense que ça les ennuie. Pour rappel, ils voulaient que je sois au forfait jour au début mais ce n’était pas légal (ils le savaient déjà avant de m’embaucher), donc ils m’ont passé aux 39h, en me disant qu’ils auraient aimé que je sois comme au forfait jour (ça a été dit à l’oral lors de mon entretien où j’ai signé le CDI). Ils ne le disent pas explicitement mais je sens bien que le fait que je respecte à peu près mes durées de travail quotidiennes les ennuie beaucoup (beaucoup d’indices en ce sens). (je dis "à peu près" car il m’arrive assez souvent de rester 5 à 30 voire 40min de plus chaque jour sans pouvoir compenser). ("souvent" = 1 à 3 fois par semaine, mais plutôt 2 que 3).

Globalement :

• Les gens se sont montrés compréhensifs et très sympas, même s’ils n’assument pas vraiment leur part de responsabilité (pas autant que moi en tout cas).

• Je n’ai pas de souci avec la charge de travail, ils me ménagent, comparé au lead dev qui a énormément de tâche (mais le salaire va avec son forfait jour, environ 80k, contrairement à moi).

• J’apprécie l’équipe, le PO et mon CTO, humainement et professionnellement. Je ne pense pas qu’il y ait de manipulation de leur part, mais vraiment de la bonne volonté. Sauf au niveau de ce qui touche à ces histoires de durées de travail en surplus qui s’accumulent sans compensation (je me souviens, et c’est lié, que le CTO avait demandé à un candidat au poste de Lead que je connais bien (le candidat) s’il avait des enfants, et quand il a dit "oui", le ton de l’entretien avait changé… le candidat en question m’a dit que ce n’est pas légal de la part du CTO d’avoir posé cette question, et qu’il avait ressenti d’autres trucs négatifs sur lesquels je ne vais pas m’étendre faute de temps). (Du coup, je garde une certaine "petite méfiance" vis-à-vis du CTO et du PO).

Très globalement : grâce à la venue du Lead, je me sens plus serein et détendu, et je me plais davantage dans ma société. Même si certains événements, très ponctuels finalement, sont stressants, et s’il subsiste toujours un fond de "tu dois travailler plus que tes 8h par jour, gratuitement" (parfois à moitié à la demande du CTO, même si ce qu’il me demande après mes horaires prendrait généralement juste 20min à être fait, alors que je passe déjà moi-même 5 à 20min de ma propre initiative à rester au taff).

Le hic c’est qu’en soirée je suis très occupé, j’ai un sport de combat, la salle, une vie sociale bien remplie et je dois faire des courses, etc.

Je ne peux pas dépasser tout le temps allègrement les 8H par jour. Et parfois je dois finir à 18h pile….. sinon c’est tout simplement impossible d’enchaîner sur ce que j’ai à faire après le travail dans la soirée.

Je compte demander un passage aux 35h après 1 an dans cette société, si mon salaire n’est toujours pas augmenté. ("toujours" car apparemment, après les grandes vacances, les salaires ont pour la plupart augmenté à cause de l’inflation, mais pas le mien).

Je me rends aussi compte que j’ai des potes qui voudraient me voir après 18h mais c’est impossible pour moi si je veux continuer d’aller un jour au sport de combat et le jour d’après à la salle, conjugué aux courses et à la préparation des repas, le ménage etc. Il faudrait absolument que je finisse à 17h.

Ou alors qu’ils me fassent rester aux 39h (mais augmentation du salaire quand même) et me laissent commencer plus tôt pour finir à 17h.