Cela fait plus de six ans que j'écris du code, c'est-à-dire que je construis des sites internet, des applications et des programmes pour gagner ma vie. Assez longtemps pour avoir vu passer des modes, livré des projets dont je suis fier, et d'autres qui me réveillent encore la nuit.

Quand j'apprenais ce métier, je lisais les mêmes contenus que tout le monde. Les histoires de reconversion qui finissent bien. Les vidéos YouTube du genre « une journée dans la vie d'un développeur », où une personne prépare un café à 9h30, échange quelques minutes avec son équipe, puis travaille tranquillement dans un appartement ensoleillé. Les discours des recruteurs. Les promesses des écoles de programmation.

Tout cela était vrai. Mais vrai à la manière dont une photo d'annonce immobilière est vraie : techniquement exacte, stratégiquement cadrée, et omettant discrètement les défauts.

Voici donc, avec un peu de recul, ce qu'on m'a raconté sur ce métier, et ce que cela voulait vraiment dire.

Premier mensonge : « Tu vas résoudre des problèmes intéressants toute la journée »

Techniquement vrai. À condition de donner au mot « intéressant » un sens très large.

Oui, on résout des problèmes en permanence. Mais la proportion entre les énigmes passionnantes et les questions du type « pourquoi ce site ne fonctionne plus depuis ce matin alors que personne n'y a touché » n'est pas du tout celle que les recruteurs sous-entendaient.

La vérité, c'est que l'essentiel de la journée se passe à comprendre pourquoi quelque chose qui fonctionnait hier ne fonctionne plus aujourd'hui. Le problème n'est presque jamais où l'on croit. Il vient souvent d'un outil utilisé par un autre outil, lui-même utilisé par celui que vous utilisez. La correction tient parfois en une seule ligne. Mais la trouver peut prendre six heures, un café, une promenade, et une conversation un peu humiliante avec un collègue qui vous dira l'air de rien : « Ah oui, ça. On a eu le même souci il y a trois mois. »

Les problèmes vraiment passionnants existent, bien sûr. Mais ils vivent à l'intérieur d'un environnement beaucoup plus large, fait de petits soucis techniques, d'incompatibilités entre outils, et de réunions sur les raisons pour lesquelles ces petits soucis prennent autant de temps à régler.

Ce que j'aurais aimé qu'on me dise plus tôt : la vraie compétence d'un développeur expérimenté, ce n'est pas de résoudre des problèmes difficiles. C'est d'avoir la patience de traverser douze problèmes ennuyeux pour identifier le seul qui compte vraiment. Les débutants qui abandonnent sont ceux qui s'attendaient à ce que chaque journée ressemble à un puzzle stimulant. Ceux qui restent finissent par trouver une satisfaction calme, presque artisanale, dans le travail bien fait.

Deuxième mensonge : « Le code est un métier créatif »

Là, je veux être prudent, parce que ce n'est pas entièrement faux. Il y a une vraie créativité dans la programmation. Concevoir un bon logiciel demande un sens du goût, comparable à celui d'un architecte ou d'un écrivain. Réorganiser un programme confus pour en faire quelque chose de clair, procure presque la même satisfaction que de retravailler un texte.

Mais l'expression « métier créatif » vend une image qui ne correspond pas tout à fait à la réalité quotidienne. Un peintre n'a personne pour lui demander, en plein milieu de l'après-midi, pourquoi son tableau met du temps à s'afficher sur tel ou tel téléphone. Un romancier n'a pas à justifier en réunion pourquoi son dernier chapitre a pris deux semaines au lieu d'une.

La créativité, dans ce métier, est encadrée. Elle s'exerce à l'intérieur de contraintes posées par les besoins de l'entreprise, par le travail déjà existant, par les délais, par les préférences de l'équipe, par les limites des outils, et par les choix de la personne qui a écrit le programme original il y a sept ans et qui n'est plus là pour les expliquer.

Ce que j'ai fini par comprendre, c'est que la part créative du métier tient surtout de la négociation. On ne part jamais d'une page blanche. On propose des modifications à un système que quelqu'un d'autre a construit, et on défend ses choix. La vraie créativité, c'est de trouver des solutions qui respectent l'existant tout en l'améliorant.

Troisième mensonge : « Tu seras bien payé pour tes compétences »

On est bien payé. C'est vrai et j'en suis reconnaissant. Le mensonge réside dans l'idée que le salaire serait directement lié au niveau technique.

En réalité, il dépend surtout du moment. De l'entreprise dans laquelle on entre, et de la période à laquelle on y entre. De la capacité à négocier, qui est une compétence en soi, et qui a très peu à voir avec la capacité à écrire du bon code. J'ai connu des développeurs brillants qui gagnaient nettement moins que des collègues moyens, simplement parce qu'ils avaient rejoint leur entreprise deux ans trop tard, ou parce qu'ils n'avaient pas su insister lors de la discussion salariale.

Et le marché des développeurs est nettement moins stable que ne le laissait croire le discours dominant il y a quelques années. Il y a eu une longue période où la demande paraissait sans fin, où les salaires proposés semblaient presque irréels. Cette période est terminée. Les licenciements existent. Des équipes entières sont parfois supprimées. L'idée que l'on serait « indispensable » parce que l'on construit ce que l'entreprise vend est, malheureusement, une illusion. On reste une ligne dans un budget.

Ce n'est pas du cynisme, c'est de la lucidité. Le jour où j'ai cessé de croire que mon salaire récompensait mes compétences techniques, et où j'ai commencé à le voir pour ce qu'il était — le résultat d'une négociation entre moi et une entreprise avec ses propres contraintes — j'ai pris de meilleures décisions. Je suis parti quand il fallait partir. Je suis resté quand rester avait du sens. J'ai arrêté de prendre les licenciements personnellement.

Quatrième mensonge : « Le télétravail, c'est la liberté »

Le télétravail est l'une des meilleures choses qui soit arrivée à ce métier, et je le défendrai jusqu'au bout. Mais la version qu'on nous a vendue, celle du voyageur qui travaille depuis une plage avec son ordinateur portable, ne correspond pas à la réalité.

Pour la plupart des développeurs, le télétravail signifie surtout que les murs du bureau ont déménagé à la maison. Il n'y a plus de trajet, et c'est précieux. Mais il n'y a plus non plus de séparation claire entre le travail et la vie personnelle. Et c'est plus difficile à gérer que ce que beaucoup veulent bien admettre.

La liberté est réelle, mais beaucoup plus limitée que promise. On peut choisir où s'asseoir. On ne peut pas vraiment choisir ses horaires, parce que les réunions existent toujours, et elles ont lieu selon le fuseau horaire de quelqu'un. On peut théoriquement participer à une réunion depuis un hamac. Mais dans la pratique, on ne le fait pas, parce que la connexion internet est mauvaise, la lumière est gênante, et on est en train de résoudre un problème compliqué.

Ce que le télétravail m'a vraiment apporté, en revanche, et c'est précieux, c'est la possibilité d'organiser ma journée selon mes propres rythmes. Je travaille mieux le matin. Je sors marcher en début d'après-midi. Je cuisine mon déjeuner au lieu de manger une salade triste devant un écran. De petites choses. Mais mises bout à bout, elles donnent une qualité de vie que je n'échangerais contre rien. Ce n'est pas « la liberté ». C'est simplement une version plus humaine d'un travail de bureau.

Cinquième mensonge : « Tu apprends en permanence »

C'est présenté comme un avantage. Et c'en est un. Mais c'est aussi un tapis roulant que personne ne reconnaît comme tel.

On apprend effectivement en permanence. Non pas par envie, mais par nécessité. Parce que les outils que l'on a mis trois ans à maîtriser finiront par être remplacés. Les bonnes pratiques d'aujourd'hui seront considérées comme dépassées dans cinq ans. Les technologies autour du métier changent constamment, parfois plus vite que l'on n'arrive à les apprendre.

Il y a une vraie joie dans cet apprentissage continu. Je la ressens encore, après toutes ces années. Le moment où un nouveau concept devient clair. La satisfaction de comprendre enfin pourquoi tel outil est conçu de telle façon. Cette partie-là est bien réelle.

Mais il y a aussi l'épuisement. La pression diffuse, constante, de devoir suivre le rythme. Le sentiment de ne jamais être tout à fait à la hauteur, parce qu'il y a toujours quelqu'un, quelque part, qui semble avoir trois longueurs d'avance. La prise de conscience, après quelques années, que l'on a oublié plus de choses que la plupart des gens n'en apprendront jamais.

Ce avec quoi j'ai fini par faire la paix : je n'essaie plus de tout apprendre. J'apprends ce qui est utile pour le travail en cours, et ce qui m'intéresse vraiment. Le reste, je le laisse passer. Je ne connais pas le dernier outil à la mode. Je l'apprendrai si j'en ai besoin. En attendant, cela me convient.

Et la réalité haïtienne dans tout cela ?

Tout ce que j'ai écrit jusqu'ici décrit le métier tel qu'il est présenté dans les publications étrangères. Mais pour un développeur en Haïti, ou pour un Haïtien qui travaille à distance pour des entreprises étrangères, il existe toute une couche de réalité que ces récits n'évoquent jamais.

Être développeur en Haïti

Ici, le « problème intéressant » de la journée n'est pas toujours dans le code. C'est parfois l'électricité qui s'arrête au moment précis où l'on s'apprêtait à enregistrer son travail. C'est la connexion internet qui décide, sans prévenir, de devenir instable pendant un appel important avec un client. C'est l'onduleur — l'appareil qui prend le relais quand le courant saute — qui rend l'âme au pire moment. C'est la génératrice du quartier qui s'éteint deux minutes avant une réunion.

On apprend à travailler avec des sauvegardes régulières, des onglets prêts à être rechargés, et une sorte de sixième sens qui prévient quand il faut enregistrer son travail avant que tout s'éteigne. On apprend aussi à expliquer à un client à l'étranger, sans trop s'excuser, pourquoi on répondra dans dix minutes au lieu d'une.

Le marché local est petit. Les véritables opportunités, celles qui paient correctement, sont rares. Beaucoup d'entreprises locales ne comprennent toujours pas ce que fait réellement un développeur, ni pourquoi un projet présenté comme « simple » demande plus d'une semaine de travail. On nous demande souvent d'être à la fois graphiste, programmeur, technicien réseau, support client, et accessoirement de réparer l'imprimante.

Être un développeur haïtien qui travaille pour l'étranger

Pour beaucoup d'entre nous, c'est une véritable bouée de sauvetage. On gagne en devises, on touche à des projets ambitieux, on côtoie des collègues du monde entier. Sur le papier, c'est le rêve.

Mais cela a un prix. On travaille souvent selon des horaires qui ne sont pas les nôtres. Les réunions tombent à des heures où le corps voudrait dormir, ou pire, à des heures où l'électricité du quartier disparaît habituellement. On finance des abonnements internet de secours, on investit dans des batteries, on construit une petite infrastructure personnelle juste pour avoir le droit de travailler comme n'importe quel collègue à Paris ou à Montréal.

Et puis il y a la partie invisible. On apprend à ne pas trop parler de la situation du pays pendant les réunions, pour ne pas y être réduit. On apprend à surveiller ce que la caméra montre en arrière-plan. On apprend à faire comme si tout allait bien, même quand ce qui se passe autour de soi n'a rien d'ordinaire. Ce silence professionnel a un coût émotionnel réel, dont personne ne parle dans les articles intitulés « comment devenir développeur indépendant à l'international ».

Et pourtant. Certains des meilleurs ingénieurs que je connais sont des Haïtiens qui ont appris leur métier dans ces conditions. Ils résolvent des problèmes sous pression d'une manière que peu de leurs collègues étrangers peuvent vraiment comprendre. Ils savent improviser, contourner les obstacles, livrer malgré tout. Cette résilience, mal nommée et rarement valorisée, est une compétence à part entière. Elle ne figure dans aucune offre d'emploi. Mais elle se voit dans la qualité du travail.

S'il y a un message pour les jeunes développeurs haïtiens qui lisent ces lignes : la difficulté du contexte ne diminue pas la valeur de votre travail. Elle l'augmente. Mais ne laissez pas cette difficulté devenir votre seule identité professionnelle. Vous êtes des ingénieurs. Le reste, c'est le décor.

Ce qui est vrai, finalement

Si je devais être honnête avec le jeune homme qui débutait dans ce métier, que lui dirais-je ?

Je lui dirais que c'est un bon métier. Vraiment. Intellectuellement stimulant la plupart du temps, suffisamment rémunéré pour construire une vie, et physiquement beaucoup moins exigeant que presque n'importe quelle autre profession demandant autant de réflexion.

Je lui dirais aussi que les aspects difficiles sont bien réels, et qu'il faut les prendre au sérieux. Les longues recherches de problèmes invisibles. La complexité humaine du travail en équipe. La façon dont l'industrie peut donner le sentiment d'être remplaçable. La façon dont les outils que l'on apprécie peuvent être abandonnés du jour au lendemain par une décision lointaine.

Et je lui dirais que la satisfaction est elle aussi bien réelle, mais qu'elle se trouve dans des endroits différents de ceux auxquels on s'attend. Pas dans le moment où l'on écrit un programme brillant. Mais dans le moment où l'on aide un collègue débutant à se débloquer. Dans une remarque qui rend vraiment meilleur le travail d'un autre. Dans la mise en service d'un outil qui sera vraiment utilisé par quelqu'un, quelque part.

Les mensonges, en réalité, n'en étaient pas vraiment. C'était de la communication. La réalité est plus désordonnée, plus lente, plus humaine, et finalement plus intéressante que la brochure.

Je referais ce choix sans hésiter. J'irais simplement avec les yeux ouverts.