Sur la qualité

Dans ce chapitre, nous commencerons par évoquer l’équivocité de la qualité avant de se pencher les liens entre qualité, profitabilité et mise en tension.

Equivocité de la qualité
Qualité et mise en tension des ingénieurs
Qualité et profitabilité

Loic : le sujet de la qualité je le trouve un peu ambigu parce qu’on ne sait pas trop ce qui se cache derrière la qualité. Des fois on va dire qu’est-ce que c’est la qualité c’est quoi la qualité ? Est-ce que c’est faire beaucoup de test, est-ce que c’est faire des tests vraiment bien ciblés, est-ce que ce n’est pas on va dire ton projet est de qualité si tu lui accordes je ne sais pas quoi plus de temps est-ce que c’est parce que tu vas faire X formations ? Plus ça va plus j’ai du mal à voir ce que c’est vraiment la qualité. Est-ce qu’au final la qualité ce n’est pas arriver justement à faire quelque chose le plus simple possible mais le plus facilement testable et qui réponde aux besoins ? En se fixant des contraintes de temps… je ne sais pas je suis très partagé là-dessus. Plus on avance plus j’ai du mal avec cette notion de qualité, c’est peut-être parce que j’ai oublié ce que c’était. J’ai l’impression effectivement que les différentes couches de management veulent faire… veulent faire de la qualité quand même mais ils n’ont pas tous la même notion de la qualité. Certains vont te dire la qualité d’un projet c’est si il est dans les temps, la qualité d’un projet c’est si il est vendu cher, la qualité des développeurs ils vont dire la qualité d’un projet c’est quand il est bien développé. Ça se trouve le développeur, le développeur il est super content de ce qu’il a fait, il a tout commenté, c’est hyper propre etc. il s’y retrouve et machins mais que il a juste balancé l’application et oublié de vérifier que cela fonctionnait. Lui il va dire la qualité c’est bien, le client lui va dire la qualité c’est zéro. Qu’est-ce que c’est que la qualité, n’est-ce pas au final le point de vue du client ? Qu’une application fonctionne, qu’elle réponde aux besoins, que quand tu veux intervenir dessus si tu ne veux pas être trop dans la merde etc. la qualité c’est un ensemble de choses.

Loic introduit très bien la problématique de la qualité d’un projet informatique. La difficulté première que les membres d’une équipe rencontrent, du chef de département aux ingénieurs d’étude et aux managers de proximité, est qu’il ne partage pas la même définition de la qualité. Les interprétations diffèrent selon leurs positionnements dans l’équipe. Le client peut avoir également sa propre définition avec des attentes particulières et un goût prononcé pour certaines choses.

Cette équivocité de la qualité n’est pas adressée alors qu’il semblerait nécessaire de parvenir à une définition univoque et partagée par tous. Chacun possède sa propre définition, tous ont une vision claire de ce que serait un projet réussi et de qualité, mais bien souvent ces visions diffèrent et parfois s’excluent : l’ingénieur veut développer une application facilement maintenable, évolutive, bien commentée, etc. Le chef de projet souhaite que le projet soit livré à l’heure due et qu’il fonctionne comme spécifié, le manager et le client pensent déjà à demain, aux fonctionnalités à créer et à celles à supprimer. En caricaturant, on pourrait voir notre ingénieur consacrait trop de temps à l’évolutivité d’une fonctionnalité, entrainant un retard du projet et le décalage de la livraison alors que cette fonctionnalité était condamnée à disparaitre lors de la prochaine version.

La possibilité de cette gabegie est dommageable et pourtant il n’est pas certain que l’on souhaite dissiper le flou entourant la qualité.

Martin : Moi les fois où je communiquais avec des managers, sur ce que tu as fait ce genre de choses, au niveau plus technique je ne pense pas que c’était des choses qui les intéressaient. Eux ce qu’ils vont voir c’est… que la démo client elle a marché, où il y a eu tant de bugs qui ont été relevés. Après que tu aies fait du bon taf ou tu que tu n’avais pas eu assez de temps, que tu as passé plus de temps sur les tests, ce n’est pas des choses, j’ai l’impression que les managers ne vont pas aller voir dans le détail de ce que tu as fait, c’est juste… le retour client qui va juger de ce que tu as fait.

Le manager apprécie la qualité du projet à la satisfaction du client, peu lui importe le degré de qualité que les ingénieurs vont mettre dans le projet. Plus précisément le flou entourant la qualité d’un projet vient déporter sur l’ingénieur la responsabilité de ce choix alors qu’il n’a qu’une vision parcellaire du projet, de ses contraintes et de ses attentes. Sans oublier les nombreux impondérables des projets informatiques sur lesquels il n’a aucune prise. Un projet mal vendu aux délais trop court heurtera l’ingénieur qui devra arbitrer seul le degré de qualité à injecter dans le projet afin de trouver un équilibre entre des contraintes projets et la satisfaction d’un travail bien fait.

Mathieu par son témoignage nous permet de mieux appréhender cette difficulté :

Mathieu : j’ai un directeur de projet qui me dit les chiffres sont trop chers on a divisé par deux, je le regarde comme ça, je lui ai dit à José, mais attends José il y a un truc que je ne comprends pas, tu me dis que tu casses les chiffrages que l’on fait par deux mais comment veux-tu que cela se passe au niveau des développements après… comment veux-tu que cela passe au niveau de la qualité du code, comment veux-tu que cela se passe au niveau des tests unitaires, de ce que vous nous demandez de faire, il y a un moment où cela ne passe pas. Donc si vous nous demandez de faire un effort au moins dites-le nous de faire un effort mais ne nous le cachez pas, parce là vous nous le cachez. Là tu casses les chiffrages, l’autre il casse les chiffrages en deux, tu dis ça au chef de projet qui nous redonne ça, mais personne ne dit que les chiffrages ont été cassés en deux et tout le monde est là à ronchonner et à faire des trucs à l’arrache à faire des trucs de merde. Je veux dire que si à un moment on doit faire un effort, fait une réunion, prend tout le monde et dit on doit faire un effort.

Dans l’extrait précédent, Mathieu nous présente brièvement et de manière lacunaire comment nous passons de la réponse à un appel d’offre à la réalisation d’un projet par un ingénieur. En ajoutant les quelques éléments manquants, le scénario pourrait être le suivant :

Le directeur de projet sollicite des ingénieurs architectes pour estimer le nombre de jour nécessaire à la réalisation du projet
Le directeur de projet en concertation avec son équipe commerciale arbitre les estimations des architectes. Le directeur juge le nombre de jours estimé trop important, le projet est trop cher, afin d’avoir une chance de le gagner il est nécessaire de diviser les chiffrages par deux
Le directeur de projet soumet la réponse à l’appel d’offre
La réponse est sélectionnée par le client, le projet est gagné
Le projet arrive sur la table du chef de projet qui ne sait pas que le chiffrage initial des architectes était deux fois plus important
Le chef de projet répartit les tâches à faire. Le périmètre de l’application est constant depuis le début, il n’a pas évolué

L’ingénieur se retrouve seul face à un développement pour lequel il n’est pas au courant que le temps estimé par un architecte était bien supérieur au temps alloué par le chef de projet.

Cette situation place l’ingénieur face à plusieurs options où il devra arbitrer seul le degré de qualité qu’il souhaite mettre dans un projet en possédant une connaissance limitée de ses contraintes qui ne sont pas toujours explicites. Dans l’exemple de Mathieu, l’ingénieur ne sait pas qu’une personne plus expérimentée que lui, un architecte, a évalué une charge de travail deux fois supérieure à celle qu’on lui accorde pour développer une fonctionnalité.

Le premier cas de figure est celui décrit par Mathieu : l’ingénieur ne pense pas qu’il soit possible de réaliser le développement proprement et dans les temps. Cette situation nourrit sa grogne et l’incite à prendre ses distances et à se protéger du projet. Confronté alors à la difficulté de concilier qualité technique d’un projet et délai de livraison, l’ingénieur privilégiera la contrainte temporelle en réalisant vite et mal les choses^[1].

Cette première option d’arbitrage apparait comme la plus simple et pourtant elle peut rapidement se retourner contre l’ingénieur. Autant il peut être facile pour certains de s’immuniser contre certains effets de la réalisation d’un travail médiocre^[2] ; on pense par exemple aux répercussions qu’un travail de mauvaise qualité pourrait avoir sur l’estime de soi, sur la remise en cause de ses compétences et de sa place dans une organisation ; autant les conséquences plus globales d’un travail mal fait sont fréquemment sous estimées. Martin nous apporte des éléments de compréhension de cette difficulté :

Martin : cela me fatiguait que l’on soit toujours à la bourre quoi. Alors même si au final nous ne l’étions pas tant que ça, tu as cette impression-là, tu as l’impression que tout le monde est toujours un peu sur les nerfs et qu’il faut finir cela vite et que tu n’as jamais le temps pour faire une tâche proprement. Moi ce que j’aimais bien, je n’ai pas forcément la qualité, quand tu livres un truc, que tu sois sûr de ce que tu livres, que cela marche et tout, et cela tu n’avais jamais le temps de le faire. Au final tu avais toujours un projet qui est en production et qui va marcher, mais tu n’as jamais un moment ou à part la fin ou tu sais que cela marche. Tu as l’impression que c’est fait de telle manière que tout le monde est en stress permanent, ou en tension permanente pour travailler au maximum, je pense que c’est des stratégies, mais qu’au final tu n’es jamais tranquille en fait à travailler sur ton projet parce qu’on veut cette tension permanente pour essayer de maximiser le rendement ou je n’en sais rien.

Martin décrit très bien comment la sous-estimation du temps nécessaire à la réalisation d’une tâche parvient à mettre l’ingénieur constamment en tension. Il est évidemment plus rapide de développer une fonctionnalité sans se soucier de la documenter, de la tester, de la penser pour sa maintenabilité future etc. mais cette manière de faire fait peser des risques supplémentaires sur le projet qui sont inhérents à cette sous qualité et qui sont portés par l’ingénieur uniquement. Ce dernier est maintenu constamment dans l’appréhension du crash, du bug et de l’erreur de ses propres développements pour lesquels il est responsable tout en étant conscient que le temps consacré à son développement ne fut pas suffisant.

L’ingénieur joue à l’équilibriste avec des chaussures de plomb, il est au cœur du paradoxe d’une organisation du travail qui attend de lui le bon fonctionnement d’une fonctionnalité sans lui donner le temps de la développer correctement. Toutes les phases du projet sont alors vécues comme des épreuves éprouvantes et stressantes. On intègre des morceaux d’application sans vraiment savoir s’ils s’emboitent correctement jusqu’à la mise en production qui peut marquer le début d’un chemin de croix où l’on vient payer toutes ses négligences.

Louis complète la description de cette situation :

Louis : Disons on a deux jours / homme pendant un mois sur un projet, mais au final si on a fait de la merde il y a une équipe de quatre personnes qui va bosser en permanence dessus pour reboucher les trous et pour écoper et mettre du scotch. Qu’est-ce que je voulais dire ? Et du coup comment ce coût est absorbé en fait ? C’est par la bonne volonté des gens qui vont s’en occuper. C’est par la sûr implication, c’est parce que les gens ils ont envie de faire de la qualité, on ne leur donne pas l’occasion d’en faire, à la phase de build, donc ils se rattrapent un peu en essayant d’écoper, il y a le syndrome du pompier, du coup comme nous ne pouvons pas le faire pendant la phase du build, on va le faire pendant la phase de run, et donc on va écoper le surplus de travail qui n’est pas vendu. Cela tourne à la bonne volonté des gens. Qui vont se défoncer pour… pour faire marcher le projet mais ils vont se défoncer souvent trop tard et ils vont dépenser une énergie peut-être trois fois plus d’énergie que si ils l’avaient fait en amont lors de la phase de conception, lors de la phase de réalisation

Le choix de privilégier la livraison du projet au détriment de la qualité des développements finit par rattraper les ingénieurs. Une fois en production et que le bateau prend l’eau, on peut dans un premier temps rafistoler l’avarie pour éviter de sombrer, mais on se lasse d’écoper les fonds de cale, il faudra tôt ou tard changer de bateau. Il faut bien comprendre comme le souligne de manière imagée Louis que le sous-investissement lors des phases de développement vient alimenter la phase d’exploitation de tickets d’incidents rébarbatifs et ennuyants. Face à cette situation, les ingénieurs d’exploitations ; ils sont souvent les mêmes que les ingénieurs de développement pour un projet donné ; vont prendre le temps de réparer l’application correctement, de la repenser afin qu’elle fonctionne et qu’elle soit exploitable en production. Le temps nécessaire à ces développements est fréquemment un temps que l’on consacre gratuitement au client, on lui offre car on lui doit évidemment une application qui fonctionne et qui ne coûte pas trop cher à exploiter. Parfois c’est également un temps que l’on offre à sa direction par frustration qui vient déborder sur son temps personnel^[3].

Non-sens d’une organisation qui privilégie la minimisation des coûts de développement lors de la phase de conception alors que cela aura pour conséquence d’augmenter de manière exponentielle ceux de la phase de production. On retrouve ici le problème que nous posions initialement sur la difficulté à définir la qualité d’un projet. Dans cet exemple le chef de projet ayant encadré la phase de développement est satisfait : le projet a été livré dans les délais, aucune erreur critique n’a été remontée par le client. La qualité est donc au rendez-vous. A l’opposé l’équipe d’exploitation vit un véritable calvaire, elle considère le projet comme très médiocre, inexploitable et se tire les cheveux à longueur de journée. La qualité escomptée n’est évidemment pas là.

Dans ce premier cas de figure dans lequel l’ingénieur accepte de dégrader la qualité de son travail afin de le rendre dans les délais, quatre conséquences et une conclusion ont été tirées de notre analyse : il appauvrit le travail de développement de l’ingénieur en ne lui permettant pas de faire correctement son travail. Il place l’ingénieur en tension permanente comme nous le montrions précédemment. Il vient dégrader les missions des ingénieurs d’exploitation en générant de nombreux tickets d’incident lors de la mise en production. Il génère un surtravail qui devra être supporté par les équipes de production. Finalement il entraine des surcoûts de développement qui rendent le choix initial de minimiser les temps de développement lors de la phase de conception paradoxal.

Dans le second cas de figure l’ingénieur ne parvient pas forcément à concilier son exigence de qualité et la contrainte temporelle forte imposée par son management. Cette situation peut naître de la difficulté pour estimer le temps nécessaire à la réalisation d’une fonctionnalité répondant à une certaine qualité. L’ingénieur ne saura pas forcément adapter son travail et sa manière de faire à cette contrainte. L’équilibre à trouver est instable, il est fréquent que l’ingénieur bascule dans sa propre mise en tension où il doit à présent courir pour réaliser sa tâche conformément à la qualité qu’il a lui-même définie. La qualité a toujours un coût, elle se paye en temps qui est souvent un temps personnel. Le témoignage de Romane en atteste :

Romane : Ce qu’il attendait et ce que faisaient beaucoup de gens c’était d’augmenter ses horaires pour pallier un problème qui a été rencontré pendant la semaine afin que cela passe inaperçu.

Plus simplement, les ingénieurs peuvent se retrouver dans cette situation de leur propre chef. Ils vont volontairement fournir un travail de qualité supérieure tout en sachant qu’il ne sera pas possible de le réaliser dans le temps imparti. Ils sont conscients que leur choix va les contraindre à travailler au-delà de leur horaire légal et bien souvent bénévolement. Leur souci de la qualité vient donc directement mordre sur leur vie et leur temps personnel.

L’extrait suivant de l’entretien de Jean nous permet de mieux comprendre leurs motivations :

Jean : Toutes les problématiques j’étais autonome dessus et du coup j’ai abattu beaucoup de boulot ou je suis resté tard méga souvent à essayer de faire un truc qui fonctionnait bien. Parce que c’était des technologies que je ne connaissais pas du tout, c’était une manière de travailler que je ne connaissais pas du tout, et j’ai kiffé aussi. Cela m’a vraiment motivé, j’étais à fond dessus, c’était un truc qui me plaisait bien au final, je m’en suis rendu compte, je m’investissais encore plus. Ça a duré huit mois à bosser beaucoup.

Ce cours extrait souligne 3 points importants pour les ingénieurs :

Travailler bien au-delà de son temps de travail peut se justifier par la découverte d’un monde scientifique inconnu. Un peu à la manière d’un explorateur qui viendrait larguer son ancre au large d’une île vierge, l’ingénieur est tout excité à l’idée de trouver un trésor caché. Une nouvelle technologie, un nouvel outil ou bien une nouvelle manière de faire sont autant de pépites à sortir de terre : il faut les apprivoiser, les dompter jusqu’à pouvoir les utiliser correctement comme un ornement que l’on viendrait ajouter à sa parure. Etancher sa soif de curiosité scientifique est suffisant pour amener Jean à travailler beaucoup plus qu’il ne devrait. Il veut comprendre comment cela fonctionne, il veut maîtriser la technologie complétement, « à fond ». La qualité supérieure du travail qu’il réalise est la conséquence de cette curiosité.
Travailler bien au-delà de son temps de travail est « naturel » et ne pose pas de problème dès lors que l’on prend du plaisir. C’est le cas de Jean qui « kiffe » réellement de devoir réaliser une tâche avec des outils inconnus. Cette situation entremêle le plaisir de la découverte mais aussi l’excitation du challenge car on ne sait jamais si l’on parviendra à atteindre son but. Un projet informatique est toujours un chemin semé d’embuche, d’autant plus lorsque l’on ne maîtrise pas les technologies à utiliser. Jean se protège en travaillant beaucoup pendant plusieurs mois jusqu’à tard dans la soirée car il veut y arriver. Il y a un goût pour le challenge chez les ingénieurs, la réussite n’a pas de prix même si elle se paye en temps personnel. La qualité supérieure du travail qu’il réalise est la conséquence du plaisir qu’il prend à travailler dans ces conditions.
L’autonomie évoquée dans la première phrase de cet extrait est un élément clé. Elle renforce notre analyse précédente qui lie autonomie, plaisir et surinvestissement.

Des expériences similaires à celle de Jean sont nombreuses^[4]. De notre analyse nous pouvons en conclure que le flou entourant la qualité d’un projet permet de responsabiliser l’ingénieur dans son développement. Il s’impose à lui-même un degré de qualité souvent bien supérieur à la qualité possible dans le temps imparti. Cette responsabilisation est la meilleure manière de le mettre en tension car l’organisation n’apparait pas comme la première responsable de cette situation : C’est d’abord le salarié qui décide de fournir un travail d’une qualité supérieure à celle qu’une organisation pourrait lui imposer. Cette mise en tension ne se traduit pas nécessairement par des difficultés, elle peut être vécue sereinement avec plaisir même si elle entraîne souvent un débordement du temps de travail sur le temps privé.

Pour conclure, dans les deux cas de figure, nous constatons que l’organisation facilite la mise en tension des ingénieurs jouant sur le flou de la qualité escomptée et le poids des contraintes temporelles pour arriver à cette fin.

[1] Nombreux sont les entretiens attestant de cette solution. Dorian par exemple : c’était en mode tu vois, ils te donnaient un temps très court pour que tu le fasses ton travail, toi tu auras envie de prendre ton temps, de le faire correctement et tout, et tu te retrouves obligé à faire en mode Quick and Dirty.

[2] Dorian : « si je dois faire de la merde je le dis à mon chef, J’arrive vachement maintenant à me désolidariser de cela »

[3] Voir plus bas dans ce chapitre et dans la troisième partie, au chapitre consacré au cercle vertueux des exemples plus précis sont donnés de cette situation

[4] Voir la troisième partie et le chapitre consacré au cercle vertueux

Zoé : la direction […] dit voilà notre TJM c’est cela, souvent le TJM aussi ce que demande l’entreprise est plus que ce que l’on vend aux clients, parce que le client il va négocier. C’est-à-dire que moi une journée, une journée client, l’entreprise elle en veut plus. Elle en veut 1.1, je vais prendre un exemple, le TJM moyen pour une personne d’ATOS c’est 680€ et ce que l’on vend aux clients c’est 590€. Il te reste 90€ à faire. On te demande 10k à faire par personne. 10k par mois. Cela fait une petite différence et tu es obligé de jongler. Et tu as le manager qui est là, le chef qui n’est pas compté dans les propositions, dans les chiffrages. Donc lui, moi, le manager, il faut aussi que je me paye sur leur dos exactement. À un moment tu te dis ouah ! Cela commence à coûter cher tout cela. Là tu joues un peu, quand tu peux jouer, ce n’est pas toujours évident de jouer, voilà. […] c’est-à-dire faire tes plannings, si tu es toi-même honnête sur tes plannings, avec ton chiffrage, eh bien tu bosses, tu bosses tu bosses tu bosses, je ne veux pas dire que je ne veux pas bosser, mais tu as tout le temps la tête dans le guidon et tu ne peux pas la lever.

Cet extrait est intéressant à plusieurs titres. Tout d’abord Zoé décrit précisément comment la profitabilité est finalement l’élément essentiel d’un projet. C’est elle qui permettra d’apposer sur un projet le label qualité. Elle nous donne en détail les objectifs de chiffre d’affaire pour les équipes ainsi que les taux journaliers moyens pour les ingénieurs de Worldline. Amusons-nous à réaliser un petit calcul :

Un manager est responsable d’une équipe de 4 ingénieurs
Il doit atteindre chaque mois un chiffre d’affaires de 10 000€ pour chacun des ingénieurs auquel s’ajoute 10 000€ pour son chef et lui-même, soit un total de 60 000€.
Les ingénieurs sont facturés en moyenne 590€ pour une journée de travail. Considérons qu’il y a 22 jours de travail dans un mois, le manager a la possibilité de facturer au client pour un mois donné au maximum 52 000€ (590*22*4)
Il manque 8 000€ pour atteindre l’objectif fixé par la direction soit environ 13 jours.
Le manager consciencieux, souhaitant atteindre son objectif facture 101 jours de travail à son client, se décomposant en 88 jours pour les 4 ingénieurs plus les 13 jours manquant.
A cela s’ajoute fréquemment une diminution des chiffrages afin de satisfaire le client et d’ajouter des fonctionnalités dans une enveloppe budgétaire constante^[1]. Autrement dit alors que les ingénieurs avaient estimé le temps nécessaire à la réalisation de la fonctionnalité A à 20 jours, le manager la vendra 15, ce qui lui permettra d’ajouter la fonctionnalité B de 5 jours.
Les développements n’ayant pas encore commencé, les ingénieurs sont déjà en retard de 13 jours au minimum.

Dès le début c’est une véritable course, « tu bosses, tu bosses, tu bosses, tu bosses », tu ne sors pas la tête du guidon. Un rythme effréné est difficilement conciliable avec un travail de qualité. En sourdine, Zoé évoque la possibilité de jouer et d’apprendre à relever la tête, il y a peut-être des solutions que nous analyserons dans un second temps^[2] mais la situation reste néanmoins très délicate :

Maxime : nous sommes plus contraints vis-à-vis du client, il y a plus de pression, il faut aller plus vite, il faut toujours aller plus vite. Donc ce qui fait que nous avons l’impression de faire des choses qui sont toujours un peu bâclées. D’être plus performant, je pense qu’il faut faire plus avec moins de ressources, moins de budget.

Valentina : L’autre point négatif aussi c’était que les choses vont trop vite, on n’a pas le temps de prendre du recul, on n’a pas le temps de [silence] presque pas le temps de bien faire les choses. Ça c’est vrai, la sensation que c’est tout le temps le rush, le rush, le rush.

Maxime et Valentina précisent cette impression de course, il faut accélérer constamment, c’est « le rush, le rush, le rush ». Il faut faire vite avec moins, on ne sait plus comment faire les choses, on les bâcle, on ne prend plus de recul. La qualité du travail de l’ingénieur mise en péril par un manque de moyens et par un manque de temps.

Tarik précise la difficulté qu’il rencontre pour réaliser un travail de qualité, il lui semble qu’au-delà des moyens c’est la compréhension même de la qualité d’un travail pour un ingénieur qui n’est plus accessible et compréhensible par la Direction. Chacun porte une qualité sur des plans distincts qui ne se recoupent plus. La qualité des uns est imperméable à celle des autres, ils ne parlent plus le même langage, leurs qualités n’ont plus de point de contact. Un projet profitable ne sait plus ce qu’est un projet « élégant » :

Tarik : Quand tu fais du code, il y a aussi une notion de style et d’élégance dans la chose, […] c’est là qu’il faut se servir d’opportunité pour piloter des nouvelles choses. Mais les gens n’ont aucune perception, adresse aucune valeur à des sujets dont le retour sur investissement n’est pas formalisable. Parce qu’ils n’ont pas le ressenti, ils n’ont pas le feeling, ils n’ont pas la sensation, ils ne sont pas dedans, et cela c’est chiant. […] Je suis souvent amené à proposer de faire des choses qui ont un intérêt pour l’amélioration, qui sont techniques dont l’intérêt financier n’est pas forcément perceptible tout de suite par la boîte, l’intérêt est difficile à évaluer, cela va faire monter des gens en compétence par exemple, comment évaluer le ROI de cet investissement? Je me rends compte effectivement que le management du temps des personnes est très orienté par les projets.

La profitabilité s’immisce partout, elle dicte ses choix et impose son rythme : cela va vite mais cela ne voit pas très loin. La Direction place la profitabilité au cœur de la qualité et elle ne comprend plus rien à l’importance de disséminer l’investissement et la nouveauté au sein de toutes les équipes dès qu’on le peut, dès qu’une opportunité se présente. Elle ne perçoit plus que la qualité du travail d’un ingénieur informaticien passe par la nouveauté, par l’excitation du challenge, par l’exploration de nouvelles pistes.

La profitabilité des projets impose des retours sur investissement rapides qui s’opposent au temps plus long lié à l’investissement sur une technologie ou sur une nouvelle manière de faire. Les ingénieurs sont mobilisés intégralement sur le projet, sur des fonctionnalités vendues au client, 22 jours de travail dédiés à des fonctionnalités facturées, sans possibilité de prendre du recul, d’améliorer, de progresser. Mathieu nous explique comment cette course en avant peut être nuisible à l’organisation dans son ensemble :

Mathieu : au bout d’un moment à force de revoir les mêmes conneries, de refaire les mêmes bêtises, tu vois il y a un moment où je me dis merde, moi je ne suis pas là pour rester sur place, je ne suis pas là pour faire du surplace, il y a un moment on a fait la même connerie il y a deux ans, je t’ai dit que c’était une connerie, on refait la même connerie maintenant, je te dis que c’est une connerie, mais pourquoi ça persiste ? Des fois je le prends vraiment mal parce que il y a un moment où je me dis merde, putain fait chier quoi… lui ça l’intéresse de stagner mais moi cela ne m’intéresse pas de stagner quoi il y a un moment ou je n’ai pas envie, et cela m’énerve. […] Le chef qui a déjà fait cette connerie il y a cinq ans sur un projet et c’était à peu près pareil, même lui eh bien j’essaye de lui faire comprendre que ce n’est pas une bonne idée, là je me dis j’ai atteint les limites du gars que j’ai en face de moi. Je vais lui dire tu refais les mêmes conneries que tu as faites avant, tu ne veux pas que nous arrêtions de faire ces conneries là ? Et que nous allions plus loin ? Et il a refait les mêmes conneries, comme si cela lui plaisait de refaire les mêmes conneries, les mêmes choses encore et encore car c’est ce qu’il sait faire.

Mathieu nous montre comment en pensant aller vite on finit souvent par revenir au point de départ, on tourne en rond, on tombe dans les mêmes erreurs, on stagne. La sous qualité technique est satisfaisante pour la profitabilité, on s’en contente car c’est ce que l’on sait faire, cela va vite, on ne prend pas de risque. Et finalement l’ingénieur désabusé perd patience.

[1] Voir la troisième partie

[2] Voir la troisième partie