Bonne année 2021 !

Bonjour à toutes et à tous ! Et bonne année 2021 !

Cette année a été difficile pour tout le monde et, comme d’habitude, je n’ai pas été très productif sur ce blog – un seul article pour l’année 2020. J’avais pourtant entamé des brouillons d’article mais j’ai eu du mal à trouver comment organiser les idées que j’avais. Ou alors, ces idées ne me semblaient finalement pas très intéressantes, parce que le sujet abordé était soit beaucoup trop connu – et je n’avais donc pas grand chose à dire dessus qui n’a pas déjà été dit et redit ailleurs -, soit trop peu connu voire désuet.

Je compte donc explorer une autre approche. Mais je vais y revenir.

L’année 2020 a également marqué mon retour au chômage après plus d’un an au sein d’une SSII du Mans dans laquelle j’ai passé la plupart de mon temps sans activité. De plus, les seules activités que l’on m’a données étaient, pour la majeure partie, franchement inintéressantes. Cette énième période en entreprise, ainsi que la gestion très chaotique de la crise du(1) COVID-19, m’ont amené à m’interroger sur ma situation professionnelle – c’est le cas pour beaucoup de gens d’après ce que j’ai pu entendre. Tout d’abord, je suis fatigué et très frustré de devoir travailler pour des gens qui ne comprennent absolument rien à mon métier mais prennent très souvent des décisions qui m’empêchent de faire mon travail correctement… D’autre part, je me trouve dans une situation assez compliquée, notamment géographique.

Sans rien dévoiler de gênant concernant ma vie, je me situe dans un coin de la France qui ne m’offre quasiment aucune perspective d’emploi dans mon domaine d’activité. Je ne peux pas changer de région avant très très longtemps, car je suis soumis aux aléas de l’Éducation Nationale. En effet, ma compagne est professeure de mathématiques et les mutations académiques se font par un système de points assez retors. Il se trouve qu’avec les quelques points dont elle dispose, le choix des académies de mutation est très restreint, et les points sont délivrés au compte-gouttes… Par ailleurs, l’écrasante majorité de ces académies ne m’offre pas plus d’opportunités professionnelles, voire moins. Et il est bien évidemment hors de question pour moi d’aller travailler indéfiniment loin de chez moi – je tiens à le préciser parce qu’apparemment ce n’est pas du tout évident pour tout le monde – surtout pour un emploi qui ne m’offre aucune perspective d’avenir ou qui est particulièrement inintéressant.

J’ai donc envisagé plusieurs solutions :

  • insister davantage en espérant trouver, par miracle, un emploi convenable dans ma branche et dans la région où je vis ;
  • devenir indépendant ;
  • changer de carrière.

Je ne vous cache pas que ces trois solutions sont loin d’être optimales. Les opportunités dans ma région étant vraiment très minces, quasiment nulles à vrai dire, j’ai peu de chances de retrouver un emploi par la voie normale. Les deux autres solutions me trottent dans la tête depuis un moment mais il faut admettre que se lancer en tant qu’indépendant, tout comme se reconvertir alors qu’on a une carrière déjà entamée, c’est un pari très risqué.

Dans ce genre de situations où je n’arrive pas à choisir entre plusieurs solutions, j’adopte un certain comportement : j’essaye tout !

Tout en cherchant de nouveaux recruteurs potentiels à démarcher, je réfléchis à des idées pour me lancer dans une activité à mon propre compte et j’essaye de me former à d’autres domaines. Ce n’est pas évident, mais j’espère bien qu’une voie finira par se tracer, qui me permettra de faire un choix parmi ces trois solutions et pouvoir continuer à gagner ma vie.

Comme support de ces essais, je compte utiliser ce blog comme une sorte de journal de bord, notamment pour retracer mes avancées dans mon auto-formation et pour explorer les idées de projet que je serai amené à exploiter. Pour l’instant, je me suis déjà pas mal intéressé au développement de jeu vidéo, avec Godot Engine notamment, à la modélisation 3D avec Blender, à la MAO avec LMMS et Ardour, ou encore au montage vidéo avec Kdenlive – j’ai d’ailleurs un projet vidéo qui s’étale sur l’année 2021. Concernant mon domaine d’activités, il s’est retrouvé pas mal en retrait à cause d’une très grosse perte de motivation – je ne vous cache pas que la frustration professionnelle y est pour beaucoup – mais j’essaie de m’y ré-intéresser petit à petit. Après tout, c’est certainement ce que je sais faire de mieux, c’est donc évidemment la voie qui a normalement le plus de chances d’aboutir à quelque chose.

Vous l’aurez compris, beaucoup de choses en perspective pour cette année 2021. J’espère que tout cela donnera quelque chose de concret et de satisfaisant.

Sur ce, je vous laisse, et vous souhaite une bonne année et, surtout, une bonne santé.

Nicolas SAN AGUSTIN

(1) Oui, je dis LE Covid. Contrairement à ce qu’on peut croire, l’Académie Française n’a aucune légitimité pour pouvoir décider ce que l’on a droit de dire ou non. Pour plus de détails, voyez cette vidéo très intéressante de Linguisticae sur l’Académie Française. Dans les faits, vous pouvez dire LE ou LA Covid, ce n’est pas important. Le Québec a tranché la question dès le début de l’épidémie en adoptant le féminin, tant dans l’usage qu’officiellement, mais en France l’usage s’est tourné principalement vers le masculin et l’Académie Française s’est prononcée très tard (trop tard) en voulant suivre l’exemple du Québec.

Faire tout et (surtout) n’importe quoi avec le préprocesseur

Bonjour à toutes et à tous !

Je souhaiterais aborder une fonctionnalité du langage C – et du C++ entre autres – que je vois souvent mal comprise et/ou mal utilisée : le préprocesseur. Pour ce faire, je vais détailler les différents mots-clés spécifiques au préprocesseur, en donnant quelques exemples d’utilisation et quelques pièges à éviter.

Mais avant toute chose…

Qu’est-ce que le préprocesseur ?

On désigne généralement par préprocesseur les instructions qui sont exécutées avant la compilation proprement dite. Pour rappel, un compilateur procède en plusieurs étapes pour compiler un programme à partir d’un code source, notamment en procédant à plusieurs analyses pour retirer les commentaires, isoler les mots-clés, vérifier la syntaxe et la sémantique des instructions, puis à la transformation en un code intermédiaire avant de lier le tout en un exécutable ou une bibliothèque.

Contrairement aux instructions du programme en C, les directives de préprocesseur sont exécutées pendant la compilation – et UNIQUEMENT pendant la compilation. Ces directives ne sont pas nombreuses mais permettent beaucoup de choses.

Définir des macros

Lorsqu’on définit une macro en C/C++, on cherche généralement à remplacer un bout de code par un mot-clé plus compréhensible.

Par exemple, la macro suivante permet de définir une macro nommée NB_PATTES_ARAIGNEE pour la remplacer lors de la compilation par la valeur 8.

#define NB_PATTES_ARAIGNEE    8
...
int i = NB_PATTES_ARAIGNEE;

Il y a de nombreux avantages à procéder ainsi :

  • Plutôt que d’utiliser une valeur brute dans un code sans indication claire de ce à quoi elle correspond, nous avons un mot-clé qui explicite la signification de cette valeur, sans devoir rajouter un commentaire à chaque endroit où cette valeur est utilisée ou, pire, laisser cette valeur sans explication au risque de ne pas pouvoir connaître sa signification lors de la relecture ;
  • Si la valeur de cette macro est susceptible de changer, il suffit de la modifier là où elle est définie. On évite ainsi d’avoir à modifier la valeur partout où elle est utilisée.

Il existe une autre façon d’utiliser les macros : les macros fonctions. Le principe reste le même, sauf que cette fois la macro peut recevoir des arguments.

#define ma_macro_fonction(x)    x + 2
...
int i = NB_PATTES_ARAIGNEE;
int n = ma_macro_fonction(i);

Ce code définit une macro fonction qui prend un argument quelconque appelé x puis ajoute 2 à sa valeur. Au moment de la compilation, le code sera remplacé par ceci :

int i = 8;
int n = i + 2;

En effet, le principe d’une macro est qu’elle sera remplacée telle quelle par sa valeur partout dans le code. Une macro fonction représente un gain par rapport à une fonction classique. Là où cette dernière nécessite un espace dédié dans la pile pour y stocker ses arguments et s’exécuter, la macro fonction se contente de placer uniquement les instructions dans le code comme si on les y avait placées nous-mêmes.

Cependant, il s’agit d’une arme à double tranchant. Comme je l’ai dit précédemment, le préprocesseur remplace toute occurrence d’une macro par sa valeur telle quelle.

Je vous invite à jeter un œil au code suivant (il est correct, vous pouvez vérifier), à essayer de deviner les valeurs de i et n lors de leur affichage, puis à les comparer en les vérifiant à l’exécution.

#define ma_macro_fonction(x) i
#define ma_macro_vide(x)

int main() {
  int i = 1;
  int n = 2;

  ma_macro_function(n)++;
  printf("i = %d ; n = %d\n", i, n);

  ma_macro_function(n++);
  printf("i = %d ; n = %d\n", i, n);

  m_macro_vide(n++);
  printf("i = %d ; n = %d\n", i, n);
}

Bizarre, n’est-ce pas ? On peut remarquer plusieurs choses :

  • La première macro fonction n’a pour valeur que le caractère i ;
  • Les deux macros n’utilisent jamais leur argument ;
  • La première macro équivaut à i, il est donc tout à fait possible d’utiliser cette macro fonction – en lui passant n’importe quel argument puisqu’il sera de toute façon ignoré – comme substitut d’une variable i ;
  • Il est possible de définir une macro sans valeur. Ce qui peut avoir son utilité, notamment dans le cas où une fonction n’est pas implémentée mais est dispensable, auquel cas on déclare une macro fonction vide pour retirer simplement les appels à ces fonctions sans avoir à les rechercher.

Bien entendu, le code précédent n’a aucune utilité en soi, c’est juste pour illustrer la trop grande liberté que peut offrir la définition des macros. À la limite, cela pourrait servir pour obscurcir son code (c’est-à-dire le rendre difficilement lisible pour d’autres personnes), soit par esprit de sabotage, soit pour participer à une compétition comme l’IOCCC.

En tout cas, le langage C dispose, depuis C99, des fonctions inline qui permettent en gros d’effectuer la même chose que les macros fonctions, avec la sûreté des fonctions classiques. Dans la mesure du possible, privilégiez ces fonctions-là plutôt que les macros fonctions.

Une autre possibilité est d’utiliser quelques astuces pour protéger l’utilisation des macros. Pour une macro avec une valeur simplement numérique, il est généralement recommandé de définir sa valeur entre parenthèses pour forcer la priorité des opérateurs. En effet, dans l’exemple suivant :

#define MACHIN     2
#define TRUC       6
#define MACHINTRUC MACHIN + TRUC
...
int i = 2 * MACHINTRUC;

i sera égal à 2 * 2 + 6 = 10 au lieu de 2 * (2 + 6) = 16. Il vaut mieux donc placer, au moins, la valeur de MACHINTRUC entre parenthèses comme ceci :

#define MACHINTRUC (MACHIN + TRUC)

On ne peut cependant pas utiliser des parenthèses pour protéger des instructions. Pour cela, il existe une autre astuce, consistant à placer une suite d’instructions dans une structure do { … } while(0) qui aura pour effet d’exécuter une seule fois la série d’instructions avant de sortir de la boucle.

Enfin, pour dé-définir une macro, il existe la directive #undef :

#undef ma_macro

Très pratique pour délimiter la portée d’une macro ou redéfinir une macro déjà définie comme ceci :

#ifdef MACRO_EXISTANTE
#undef MACRO_EXISTANTE
#endif
#define MACRO_EXISTANTE

Les directives #ifdef et #endif servent à tester des conditions, ce que nous allons voir tout de suite.

Vérifier des conditions

Le préprocesseur permet de tester des conditions grâce aux directives #if, #ifdef, #ifndef, #elif, #else et #endif.

Chaque test de condition ouvert par une directive #if, #ifdef ou #ifndef doit se terminer par la directive #endif. #if permet de tester la valeur d’une macro, tandis que #ifdef et #ifndef testent respectivement la définition ou la non définition d’une macro.

#else délimite le comportement du préprocesseur dans le cas où le test de condition initié par #if, #ifdef ou #ifndef échoue. #elif permet la même chose en initiant un autre test de condition (l’équivalent du « sinon si »).

De base, ces directives permettent d’activer une partie du code source si certaines conditions sont réunies. C’est pratique, par exemple, pour assurer la portabilité d’un programme en activant une portion de code qui est propre à une plateforme ou un compilateur spécifique.

#ifdef _WIN32
// Cette portion de code ne s'exécutera que sur un système Windows
#elif defined __unix__ // defined permet la même chose que #ifdef
// Cette portion de code ne s'exécutera que sur un système Unix (Linux, BSD, etc).
#endif

Une variante de cette technique existe pour le cas où du code C est intégré dans du code en C++. Pour éviter que le compilateur C++ traite du code en C comme étant du C++, il convient de délimiter la portion de code en C comme ceci :

#ifdef __cplusplus
extern "C" {
#endif

// Portion de code en C

#ifdef __cplusplus
}
#endif

Ainsi, tout ce qui sera compris dans le bloc

extern "C" { ... }

sera considéré par le compilateur C++ comme étant du C et le compilera donc comme du C.

Un autre usage très courant du test de condition est pour éviter l’inclusion multiple de fichiers, que nous allons voir dans la partie suivante.

Inclure des fichiers

En C/C++, il est d’usage de séparer le code source en plusieurs fichiers : les fichiers sources avec l’extension .c et les fichiers d’entête avec l’extension .h (1). Pour un module dédié à une tâche particulière, par exemple gérer la configuration d’un programme, on séparera ce module en un fichier source config.c qui contiendra la définition des fonctions dédiées à la configuration et un fichier config.h qui contiendra les déclarations de ces fonctions (je dis « fonctions », mais c’est également valable pour des variables, des structures, etc).

Pour qu’un fichier puisse prendre connaissance du contenu d’un fichier .h, il existe une directive de préprocesseur appelée #include. Cette directive indique au préprocesseur qu’il doit rechercher un certain fichier dans les répertoires qu’il connaît et inclure le contenu de ce fichier à l’emplacement de la directive #include. À vrai dire, le préprocesseur ne vérifie pas le nom du fichier qu’il doit inclure – à part pour indiquer par une erreur que ce fichier n’existe pas – il est donc théoriquement possible d’inclure n’importe quel fichier texte – par opposition à un fichier binaire – pour peu que le contenu de ce fichier soit cohérent avec la syntaxe du C/C++. Il est même possible d’inclure un fichier avec l’extension .c.

Cependant, il est possible qu’à la compilation nous ayons des erreurs dues à des inclusions multiples. C’est-à-dire, si le fichier main.c inclue deux fichiers .h (fichier1.h et fichier2.h) mais que chacun de ces deux fichiers inclue un fichier en commun (fichier_commun.h), les fonctions, variables, etc de ce dernier fichier seront déclarées/définies plusieurs fois et le compilateur remontera à une erreur.

Pour éviter cela, la technique généralement utilisée est de définir dans chaque fichier .h une macro propre à ce fichier – généralement à partir du nom du fichier – en prenant soin de vérifier au préalable que cette macro n’a pas déjà été définie.

#ifndef FICHIER_COMMUN_H
#define FICHIER_COMMUN_H
// Tout ce qui est compris ici ne sera activé que si la macro FICHIER_COMMUN_H vient d'être définie
#endif /* FICHIER_COMMUN_H */

Ainsi, quand le préprocesseur inclura ce fichier, cette portion de code ne sera inclue que la première fois.

Générer des messages d’erreur

Il est possible de générer des messages d’erreur avec le préprocesseur en utilisant la directive #error.

Posons le cas d’un test de condition visant à vérifier la portabilité d’un programme. Si ce test de condition échoue, on est possiblement dans une situation où le programme risque de ne pas pouvoir être compilé ou de ne pas fonctionner comme prévu, voire ne pas fonctionner du tout. Face à ce genre de situation, il est avisé de signaler à l’utilisateur que ce programme ne peut pas être compilé et d’interrompre la compilation car il est inutile d’aller plus loin.

Par exemple, si nous avons un programme utilisant des fonctionnalités propres à la norme C99, il faudrait d’abord vérifier que le compilateur est configuré pour compiler selon cette norme. Une telle vérification se présente comme ceci :

#if __STDC_VERSION__ 199901L
#error Ce programme n'est pas supporté par les normes du C antérieures à C99
#endif

Notez que le message n’a pas besoin de guillemets pour être affiché. Tout ce qui figure sur une ligne commençant par #error est considéré comme un message d’erreur à afficher. Le seul moyen d’écrire un message sur plusieurs lignes est de terminer une ligne par un antislash (\) pour indiquer que la ligne courante se poursuit sur la ligne suivante.

Si vous préférez plutôt avertir l’utilisateur d’un risque sans interrompre la compilation, vous pouvez utiliser la directive #warning pour générer un avertissement plutôt qu’une erreur.

#warning Ce programme est susceptible de ne pas fonctionner correctement sur cette plateforme

Conclusion

Le préprocesseur C est un outil puissant à utiliser et largement sous-estimé, le plus souvent car il est mal compris. Le revers de la médaille est qu’il est très facile de faire n’importe quoi avec – c’est également valable pour le C/C++ en général. Il est important de maîtriser le préprocesseur pour l’utiliser de manière utile et sûre.

Certains maîtrisent le préprocesseur au point qu’ils parviennent à réaliser un interpréteur brainfuck écrit uniquement avec des directives du préprocesseur C. Je déconseille de l’utiliser car, comme le dit son créateur :

The preprocessor brainfuck interpreter is very very inefficient and will use around 16 GIGABYTES of memory and 15 to 20 minutes of processing time while running hello.bf.

Traduction : L’interpréteur brainfuck via le préprocesseur est très très inefficace et prendra environ 16 GIGAOCTETS de mémoire et 15 à 20 minutes de temps de calcul pour exécuter hello.bf (NdT: un simple « Hello World! »).

C’est particulièrement ridicule, mais il faut admettre que c’est une bonne performance – sans mauvais jeu de mots.

Je n’ai ici abordé que les directives les plus basiques du préprocesseur. Avec ça, vous avez déjà de quoi faire du code efficace et sécurisé, à la condition que vous l’utilisiez avec prudence. Je vous invite à vous renseigner davantage sur les différentes directives du préprocesseur C – et C++ – pour en apprendre toutes les subtilités.

La directive #pragma mériterait une attention particulière. Je ne l’ai pas abordée ici car je ne la maîtrise pas encore assez pour en parler dans un article de blog et ses possibilités sont bien trop vastes et spécifiques pour être intégrées dans un article qui essaye d’aborder le préprocesseur de manière générale.

Sur ce, je vous laisse et vous dis à bientôt.

Nicolas SAN AGUSTIN

(1) Cette façon de faire n’est pas systématique. L’essentiel du code d’un module figure dans un fichier .c et le fichier .h n’a d’utilité que si l’on souhaite que des fonctions, des variables, des structures, etc de ce module soit accessibles facilement depuis le reste du code sans avoir à les redéclarer dans chaque fichier où elles seront utilisées. Ne soyez donc pas étonnés de voir du code source ne comportant pas de fichier .h pour chacun de ses modules.

L’extrême start-up

« Un souverain peut être une cause de troubles pour l’armée de trois façons. Il entrave les opérations militaires quand il commande des manœuvres d’avance et de recul impraticables ; il trouble l’esprit des officiers quand il cherche à intervenir dans l’administration des trois armes alors qu’il en ignore tout ; il sème la défiance chez les hommes en cherchant à s’immiscer dans la distribution des responsabilités alors qu’il ne connaît rien à l’exercice du commandement. »

L’Art de la Guerre, Chapitre III, Sun Tzu, traduction de Jean Lévi

Bonjour à toutes et à tous.

La dernière fois je m’étais confié sur mes expériences professionnelles, sur mes impressions quant à ces dernières ainsi que sur ma situation actuelle et à venir. J’étais passé brièvement sur mon expérience chez une certaine startup parisienne. Bien que relativement brève (7 mois), cette expérience m’a profondément marqué et, encore aujourd’hui, elle joue beaucoup sur ma perception des entreprises et de mon métier.

Je n’étais pas entré dans les détails, principalement pour deux raisons : la première est que résumer sept mois de calvaire ne pouvait pas tenir au beau milieu d’un article déjà raisonnablement long, et la deuxième est que j’ai mis du temps à pouvoir trouver les mots pour expliquer en quoi ce que j’ai vécu dans cette entreprise était anormal.

Concernant ce dernier point, un article paru il y a quelque temps sur le site developpez.com, concernant les impacts négatifs du harcèlement des patrons sur la productivité de leurs employés, m’a incité à partager brièvement mon expérience, histoire d’appuyer le propos de l’article. Cela m’a permis de faire le tri dans les points que je souhaitais aborder et à trouver une assez bonne formulation pour présenter mon vécu comme un témoignage et non une vulgaire plainte.

Témoignage

À la fin du mois de mai 2016, une startup m’a contacté pour passer un entretien pour un poste de développeur de systèmes embarqués. Le recruteur – Antoine – avait visiblement pris la peine de s’intéresser à mon profil. Le lendemain, je passais un entretien dans leurs locaux, où je rencontrais ledit Antoine mais surtout les deux patrons : Mike, directeur général, et Daniel, le président. Tout le monde était avenant, les locaux – un ancien appartement reconverti en bureaux et partagé avec une entreprise de communication – avaient l’air relativement agréables. J’ai également pu discuter par téléphone avec l’architecte du système à développer ; par la suite j’ai appris de la bouche d’Antoine que cette discussion pourtant assez sommaire était censée être l’évaluation de mes compétences techniques, quand bien même je ne me souviens pas avoir été interrogé sur des aspects techniques spécifiques. À l’issue de l’entretien, Daniel me demanda si je pouvais commencer dès le lendemain. Je ne voyais aucune raison de refuser, le cadre et le projet semblant en accord avec mon profil et mes attentes.

D’abord petite, l’équipe s’est peu à peu agrandie, assistée par des prestataires de tous horizons – notamment taïwanais, italiens et russes – et quelques coups de pouces officieux, comme celle d’un électronicien senior chargé de la conception des cartes électroniques durant son temps libre. Mais l’ambiance s’est également très vite dégradée et n’a fait qu’empirer au fil des mois. Beaucoup de facteurs sont en cause, mais on peut en isoler quelques principaux.

Sous les airs de leader charismatique qu’il essaie désespérément de se donner, Mike est un homme très égocentrique et entêté, qui a visiblement beaucoup de mal à faire confiance aux autres. Ce qui expliquerait pourquoi il insistait constamment pour avoir l’œil voire la main sur tout, même quand il n’avait pas les connaissances suffisantes pour juger correctement les situations et la qualité du travail effectué. Ce dernier aspect faisait qu’il comprenait souvent de travers ce qu’on venait de lui expliquer et prenait (trop) souvent des décisions contre-productives, voire carrément irrationnelles, nous faisant parfois perdre des semaines entières par simple caprice. Le seul qui parvenait à trouver le moyen de lui faire comprendre quelque chose, à force de patience et de pirouettes syntaxiques, était Antoine.

On aurait pu de Daniel qu’il contrebalance la personnalité de Mike, faute de la modérer. Ce ne fut pas le cas. Quand il ne laissait pas Mike faire, se disant que de toute façon il est impossible de le faire changer d’avis, il lui donnait carrément raison. Il avait également du mal à se familiariser avec les employés de sa propre boîte voire avec les termes concernant le projet, même les plus récurrents. Je me souviens encore de ma perplexité quand, au moment de me remercier au mois de décembre, il m’a dit qu’il avait espéré que l’électronicien senior de la boîte fût davantage présent pour me guider. Antoine m’a expliqué par la suite que Daniel avait tout simplement cru que j’étais électronicien, et non développeur…

Les sous-traitants russes n’étaient pas en reste, se permettant généralement d’être très critiques sur la qualité du travail des autres alors que celle du leur n’était clairement pas des plus exemplaires. De manière générale, l’entreprise a eu son lot de mauvais éléments, qui brillaient par leur incompétence et/ou par leur mauvaise volonté.

Cette ambiance toxique a eu plusieurs conséquences, en grande partie négatives.

Les éléments qui se donnaient du mal avaient tendance à être blâmés et rabaissés tandis que les mauvais éléments étaient, à l’inverse, félicités – il n’y a que ceux qui ne font rien qui ne font pas d’erreur.

Les décisions contre-productives toujours plus nombreuses faisaient qu’à partir d’un moment nous étions obligés de faire abstraction de toute conscience professionnelle et de toute rigueur. Personnellement, j’ai vécu cela comme une énorme frustration croissante.

Cela a également impacté l’avancement du projet, qui prenait toujours plus de retard au fil des mois, si bien que le prototype présenté en fin d’année lors du salon Trustech n’était en fin de compte qu’un artifice grotesque qui n’a réussi à convaincre que les visiteurs les plus candides.

Physiquement, nous étions éprouvés par le stress et par la soi-disant flexibilité de Mike, pour qui ce terme signifiait que nous devions arriver à 9:00 pile le matin mais rester jusqu’à pas d’heure le soir – il nous engueulait copieusement si on avait le malheur d’avoir plus de cinq minutes de retard le matin ou si nous quittions le boulot à l’heure prévue. Si ça ne tenait qu’à lui, Mike aurait très probablement exigé de nous que nous passions notre vie entière à travailler, quitte à abandonner toute vie privée, le tout sans rémunération des heures supplémentaires ni repos compensatoire.

Cette ambiance a également eu un impact sur notre moral. Au fil des mois, notre patience et notre volonté ont été mises à rude épreuve, si bien que lorsque Mike et Daniel ont décidé de mettre fin à ma période d’essai, je songeais déjà à partir de l’entreprise. Je confiais à Antoine que je faisais des cauchemars où Mike refusait de me laisser partir, m’obligeant à en venir aux mains pour pouvoir m’enfuir. Vers la fin je ne pouvais plus supporter quoi que ce soit venant de lui : rien que le voir, l’entendre ou le savoir pas loin me plombait le moral et me faisait déprimer.

Mon licenciement fut un soulagement pour moi mais a visiblement eu pour conséquence de miner encore plus le moral de mes collègues, tant et si bien que le fossé s’est davantage creusé entre employés et employeurs et la tension entre eux s’est accentuée. L’ambiance était telle que, lors de mon dernier jour, alors que nous allions déjeuner entre collègues, Mike et Daniel ont demandé à Antoine si quelque chose était prévu pour mon départ. Il leur a ouvertement – sans perdre de son flegme exceptionnel – expliqué que nous sortions manger, sans préciser où, et qu’ils n’étaient pas invités. Leur asséner cela lui a procuré, d’après lui, une très grande satisfaction, presque jouissive.

Je suis resté en contact avec mes collègues. D’après ce qu’ils m’ont raconté, la suite ne fut qu’un enchaînement de revendications toujours plus exigeantes en termes de salaires et d’avantages pour tenter de contrebalancer l’ambiance toujours plus néfaste. L’un après l’autre, mes anciens collègues sont partis de la boîte, si bien qu’après un peu plus d’un an il ne restait plus personne de l’équipe d’origine.

La fin n’est pas complètement heureuse pour autant. J’ai vécu ce licenciement comme une délivrance, certes. Mais, encore aujourd’hui, je garde des traces de cette époque. Quelques souvenirs heureux mêlés dans une foule de souvenirs désagréables. Même si je sais pertinemment que cela n’arrivera jamais, j’ai toujours la crainte de recevoir un hypothétique coup de téléphone de Mike pour exiger quelque chose de moi, ce à quoi j’espère trouver les mots pour lui faire comprendre à quel point nous avons souffert à cause de lui et que je ne souhaite que l’oublier définitivement, faute de pouvoir l’empêcher de nuire.

J’ai cité Sun Tzu en début d’article, car je trouve ce passage parfaitement à propos. Il illustre très bien le problème majeur de cette entreprise, à savoir une direction chaotique, perpétrée par des gens sans respect pour la condition humaine, sans aucune confiance ni reconnaissance envers les gens qui travaillent pour eux et sans qui ils ne seraient rien, même s’ils ne s’en rendent pas compte.

D’un autre côté, je trouve également cet extrait relativement triste. Si un texte de l’Antiquité présentait déjà ce genre de problèmes, que dire du fait que ce problème soit toujours d’actualité ? D’autant qu’il ne s’agit pas d’un cas isolé, il suffit de fouiller les témoignages d’expériences en entreprise pour s’en rendre compte. Cela n’a malheureusement pas l’air d’aller en s’arrangeant, surtout en sachant que des gens comme Mike agissent en toute impunité, et je redoute d’autant plus ce que l’avenir me réserve.

Sur ce, je vous laisse et vous dis à bientôt.

Nicolas SAN AGUSTIN