C’est quoi un « bullshit job » ? 

Pour donner suite à son article publié en 2013 dans le magazine britannique “Strike !” dans lequel il théorisait le principe des bullshit jobs (jobs à la con), l’anthropologue David Graeber a écrit en 2016 “Bullshit job”, livre dans lequel il analyse les témoignages recueillis de centaines de travailleurs. 

Après plusieurs tentatives, sa définition d’un job à la con est la suivante : 

Un job à la con est une forme d’emploi rémunéré qui est si totalement inutile, superflu ou néfaste que même le salarié ne parvient pas à justifier son existence, bien qu’il se sente obligé, pour honorer les termes de son contrat, de croire qu’il n’en est rien. 

Cette définition et les témoignages reçus lui permettent de catégoriser les jobs à la con. Il identifie ainsi : 

• Le larbin : job qui permet à un employé de mettre en valeur son chef, 
• Le petit chef : job qui permet à un supérieur hiérarchique de suivre le travail des collègues autonomes,  
• Le porte flingue : job qui permet à une entreprise de justifier son importance en créant des postes que les autres entreprises ont, 
• Le cocheur de case : job qui permet à une entreprise de prétendre faire des activités qu’elle ne fait pas en réalité, 
• Le rafistoleur : job qui permet à une entreprise de régler des problèmes qui ne devraient pas exister et qui auraient pu être évités en changeant d’organisation. 

Pour illustrer le rafistoleur, David Graeber utilise le témoignage de testeurs, dont le travail était d’identifier et corriger ce qui avait été mal fait en amont. 

Le testeur en informatique a-t-il sa place dans cette catégorie ?

Il fait quoi le testeur en informatique ? 

Tester est une activité récurrente dans les projets informatiques que l’on retrouve dans toutes les phases des projets informatiques. L’activité de test peut être aussi bien réalisée par une personne dont le métier est de tester, ou par un acteur du projet qui endosse le rôle de testeur (développeur, AMOA). Dans cet article sera utilisé le terme générique de « testeur » pour tous les acteurs du test. 

Ce qui est bien dans les activités de test, c’est que le travail a toujours un seul objectif : participer à l’assurance qualité du projet et permettre, en clôturant une phase, le passage d’une phase de projet à une autre. Dans un projet informatique, un testeur va intervenir dans toutes les phases-clés : 

• Lors de la phase d’ingénierie des exigences (IE), le testeur participe à la rédaction/relecture des exigences pour assurer qu’elles soient conformes aux critères qualité (critères SMART[1] par exemple). 
• Lors de la phase de développement et d’intégration, le testeur participe à la vérification des exigences logicielles, i.e. que le produit est conforme à ce qui a été spécifié, 
• Lors de la phase d’acceptation (recette), le testeur participe à la validation des exigences métier, i.e. que le produit est conforme à ce qui est attendu. 

Par rapport à la définition du job à la con, et compte-tenu des exemples ci-dessus, tester ne semble a priori pas être une activité « totalement inutile, superflu ou néfaste » et n’est pas du « rafistolage ».  

Tout dépend du projet ! 

Cependant, dans des projets idéaux où personne n’est sujet aux erreurs et tout est conforme du premier coup, il n’est, par définition, pas nécessaire de tester. L’activité de test devient inutile. Testeur est un job à la con ? Oui, mais ce n’est pas du rafistolage. Nous avons le choix entre le « larbin » qui est là pour gonfler la taille de l’équipe et le « porte flingue » qui est là parce que les autres projets « réels » (non idéaux) font des tests. 

Dans les projets réels, dans lesquels l’erreur est humaine, on fait appel, pour assurer la qualité, à des testeurs. Dans le bon projet réel, le testeur, sur un périmètre d’intervention connu, sait ce qu’il a à tester. Il produit des livrables qui sont utiles à la qualité du projet. Dans le mauvais projet réel, le testeur, sur un périmètre d’intervention flou, ne sait pas ce qu’il a à tester. Et là, aussi compétent qu’il soit, il se lance dans une obscure activité de devin dont les livrables ne garantiront pas un quelconque niveau de qualité. Il devient alors « cocheur de case », celui qui dit qu’il fait sans faire ! 

Il existe du coup le testeur « rafistoleur » dont parle David Graeber dans son livre ? 

Retournons dans un projet réel et rappelons que l’activité de test contribue à clore la phase en cours pour permettre de lancer la suivante. Imaginons qu’une phase ait commencé sans que la précédente ait été terminée. Aussi clair que soit son périmètre d’intervention, le testeur peut se retrouver par exemple à vérifier/valider une exigence fumeuse comme : « l’utilisateur doit accéder facilement à la page d’accueil ». Ainsi, dans le cas d’un projet qui ne termine pas ses phases (la phase d’ingénierie des exigences dans cet exemple), le testeur va bien se retrouver à faire du rafistolage, car ce problème aurait pu être évité (« facilement » aurait été corrigé par « en deux clic »).  

NB : En informatique, rafistoler n’est pas le terme consacré. Ainsi, on versionnera les documents en phase d’ingénierie des exigences, on patchera le code en phase de développement, on contournera les solutions en phase d’acceptation. 

Mais quelle que soit l’expression, ce travail du testeur est profondément utile à la qualité du projet et, bien que de classable dans la catégorie « rafistolage », ne constitue en rien un job à la con. 

Verdict ? 

En attendant que les projets idéaux existent, le testeur en informatique est un métier utile, qui n’est donc pas le moins du monde un bullshit job ! 

Testeur, un métier d’expert 

Tester est une activité indispensable de l’assurance qualité. Il est même, lors de la phase d’acceptation, le dernier maillon avant la production. Et en tant que dernier maillon, son activité ne pourra pas empiéter sur la suivante sans retarder les échéances du projet. 

Alors si vous ne souhaitez pas risquer votre réputation à chaque nouvelle version logicielle, faites appel à des experts du test indépendants pour vos projets stratégiques.  

La qualité a un coût, la non-qualité aussi !