À la recherche du travail perdu :
une aventure commune
25 mai 2025
Version: mai2025
Licence Anti Gad Elmaleh : Fais ce que tu veux avec ce livre sauf dire
que tu l’as écris
25 mai 2025
Version: mai2025
Licence Anti Gad Elmaleh : Fais ce que tu veux avec ce livre sauf dire
que tu l’as écris
Jusqu’à présent, j’ai toujours vu la recherche d’emploi comme une période démoralisante « où tu fais ta pute ».
Tu vas voir quelqu’un qui va faire un bénéfice net sur ton cul, et son but et que tu lui coûtes moins cher que tu lui rapportes … sauf quand t’es une rock star, un super employé que l’on trouve en haut de la pyramide des budgets de l’entreprise où tu décides des enveloppes et bizarrement aussi de la tienne.
C’est de bonne guerre ; si tu étais si finaud, t’avais qu’à faire un MBA avant tes 40 ans, hériter à 50, et monter ta boîte.
Voilà, c’est pas compliqué, il suffit de travailler dur pour y arriver. Pour les autres, « y’a qu’à traverser la rue ». Moi, je traverse la rue en regardant à droite et à gauche avant de traverser. Et c’est ce que je vais vous conter. Pourquoi ? Parce que la recherche d’emploi, j’ai décidé que ce serait fun cette fois.
Manque de pot, les emplois que je vise sont « des centres de coûts ». Dans une entreprise tu as le muscle : celui qui va faire du porte à porte pour vendre ton produit, et la graisse : l’humain qu’on aimerait bien remplacer qui coûte de manière récurrente en masse salariale sans que l’on puisse estimer combien il rapporte. C’est la production et les opérations.
Exemple : un sysadmin qui au vu des offres actuelles vaut 50 000€/an brut n’a pas de valeurs quand il fait bien son boulot, car quand il fait bien son boulot tout marche « sans problèmes ». Pour estimer ta valeur, il est bien que l’entreprise ait une idée du coût de combien ça coûte quand ça foire.
Genre, ton serveur de commandes de produit tombe alors tes pertes en nouvelles commandes sont linéaires avec le temps (modulo la saisonnalité du business).
Et le mieux, c’est tu es un accident X jours par an (du point de vue du sysadmin) car ton patron peut lier ta valeur à combien ça coûte quand ça marche pas.
C’est ce que fait la profession (pas planter la prod, hein), elle estime ainsi sa valeur et en dérive deux valeurs essentiels qui sont l’alpha et l’oméga de la valeur du sysadmin : la SLA et la GTR.
La SLA c’est l’acronyme anglais pour disponibilité (Service Level Agreement) : combien une entreprise tolère de pouvoir avoir ses serveurs arrêtés volontairement ou non par an.
Il est à noter que par exemple pour faire tester des plans de reprises d’activités ou pour maintenance on peut volontairement vouloir arrêter ses serveurs.
La SLA magique visée dans le milieu est 99.999%. 0.1% d’indisponibilité c’est 4h.
La GTR c’est la Garantie de Temps de Rétablissement dans le cas le pire quand il y a une couille. Disons que si t’as GTR est de 4h, avec un incident par an sur un truc central, tu es déjà en SLA de 99.9%.
Alors je crois pas en la magie, quand on m’annonce ce niveau de disponibilité visé et que je postule pour une offre de sysadmin : je fuis sauf si le patron s’appelle google est a la caillasse à la hauteur de ses ambitions. Oui, ce niveau magique est atteignable, mais comme j’ai appris en science expérimentale, tout est possible, ça dépend juste de ton budget.
Vous voyez google est un spécialiste de l’infra distribuée, redondante. La plupart des entreprises aimeraient viser la place de google, mais ils ne sont pas prêts à développer leur propre hardware, système d’exploitation, protocole de routage réseau logiciels … vu qu’ils ont déjà des cactus dans les poches à embaucher du sysadmin. Je veux dire quand tu connais les salaires des googleurs, tu pleures ; on ne joue pas dans la même catégorie.
D’ailleurs, si (je ne citerais pas de noms) certains avaient un syndrome de l’imposteur avant d’entrer dans ce genre de boîte, un salaire à 6 chiffres le soigne vite et bien.
Donc, comme aucun sysadmin honnête qui a déjà eu à faire à des fournisseurs business notamment les telcos 1 avec des GTR souvent de 4h heures ouvrées 2 tu peux difficilement espérer dans le cas le pire qui pourrait impliquer un incident réseau opérateur une GTR inférieure à 4h.
Et encore, si tu veux une SLA de 99.9% avec ta GTR de 4h, il faut prendre en compte le temps de diagnostic nécessaire à mettre le nez dans le caca au BON fournisseur. En général, ça prend pas une demi heure. Donc, la SLA avec un truc centralisé qui a une panne réseau, en général c’est pas une solution d’avenir.
Le rôle d’un sysadmin n’est pas tant de s’assurer qu’il y ait pas de problèmes que de s’assurer que les problèmes ne se voient pas. En général, ça nécessite une infrastructure redondante, qui tel un avion moderne bi moteur est capable d’assurer 100% du service sur une partie des infras en attendant que la partie en panne soit rétablie pendant la période critique où les infras sont en mode dégradée.
C’est devenu une spécialisation à part entière du métier de sysadmin qui est SRE engineer (ingénieur de fiabilité des services). Ça pète moins en le disant en français c’est pour ça qu’on utilise l’acronyme anglais.
Bref, admin sys c’est un métier sympa de prod où les astreintes, les réponses sur incidents en urgence, les plans de reprise d’activité font partie de ton épée de Damoclès quotidienne.
La bonne façon de le gérer, c’est de se préparer au pire et de s’organiser AVANT les incidents pour répondre aux incidents. Voir même, parfois de faire des tests grandeurs natures pour vérifier qu’une solution miracle sensée améliorer cette fameuse SLA fort coûteuse et complexe tient bien ses promesses à petites échelles (temporelle et locale) avant d’être déployée. Tenir un laboratoire et y faire des déploiements de nouveaux services en faire la qualification et le recettage (de la mise en chantier quoi), fait aussi parti du métier.
C’est un métier, plus que développeur, où la sécurité informatique est prise au sérieux, notamment sa culture. En sysadmin, le ticket d’intervention est l’équivalent du commit du codeur.
Il est important de laisser des traces de ce que l’on fait et de les terminer à la fin de chaque jour ouvré, des fois que l’incident soit soi même qui se mange un bus en allant au travail le lendemain matin.
Pourquoi ? Parce qu’une infra au contraire du code est un objet fondamentalement mutable. Et qu’il faut pouvoir connaître l’état des mutations tant des infras que des opérations en cours et/ou récemment terminées.
Tiens le serveur de base de données est tombé à 16h00 ce vendredi, il y avait-il une intervention en cours ?
Et la culture sécurité n’est pas de documenter ses interventions pour blâmer le quidam, mais dans une culture « juste » pour corriger les erreurs. Par exemple si un quidam a commis une boulette sur un équipement où il était autorisé, la réponse logique RH3 consiste à lui proposer une formation si il est en manque de connaissance et peut être de modifier les processus RH
La sécurité c’est aussi de la paperasse. Je le dis d’une manière qui a l’air péjorative, mais de même que le codeur est structurés par des normes (IETF, 3GPP, unicode, ISO) qui évitent de réinventer la roue, le sysadmin lui est plus sensibilisé aux normes de « conformité ». Genre la ISO 27001 concernant la cybersécurité, ou la conformité RGPD concernant la protection et le recueil des données à caractère personnel.
On (rarement les sysadmins) identifie des risques, on identifie les coûts associés aux risques (genre fuite de données, interruption de services…) et le sysadmin se voit inclus dans la démarche de conformité. Ça peut être vu comme une lourdeur pour certains, car assez souvent les normes de conformité impliquent la traçabilité des actions et donc leurs documentations à la fois en amont (décrire comment tel ou tel problèmes est adressé) et au fil de l’eau : « faire ce que l’on dit, dire ce que l’on fait, et accepter d’être audité). Ça peut avoir un coté inconfortable que tous n’acceptent pas de vivre « dans une maison de verre ». Moi, tant que l’entreprise respecte la culture « juste » sécurité (la même qu’en aviation), ça me va.
C’est un super métier.
J’ai déjà décrit dans Loser du libre un autre de mes livres libre ma vision du développement python en disant des choses très méchantes sur les entreprises quant à la livraison du code.
Grand père était maçon, malgré ses aventures que je découvre au détour des conversation avec les voisins, il était discret, et ne m’a transmis qu’une chose de sa culture : un bon ouvrier se reconnaît au fait que son établi est toujours propre. La propreté est au cœur de tout les métiers. Et l’informatique n’y coupe pas.
Par exemple, là où en tant que sysadmin j’accepte que mon travail soit en « cours de mutation » (genre un backup peut prendre 2 jours dans des circonstances spéciales), en informatique, j’aime que ma paillasse soit propre en permanence.
Même si je ne pousse pas mes modifs, je les découpe en tâches qui tiennent dans une journée et m’arrange pour que quand je quitte mon poste de travail, il n’y ait pas de « code en cours ». J’appelle tout ce qui a un début et une fin : un chantier, et ce que je commence et termine dans une journée un « micro chantier ». Et je pense important de garder l’autonomie sur les micros chantiers (jalons) qui permettent de garantir un avancement du chantier global sans mauvaises surprises par rapport notamment aux délais.
Dans la pratique du code, les allers retours avec les clients par le truchement des « tickets » si chers aux sysadmins, mais pas autant appréciés des développeurs se sont généralisées. Perso, ça me va, même si ça peut interrompre quand c’est mal géré un tunnel de concentration pour coder.
En effet, quand on code, il faut remonter le contexte en mémoire avec des tas de paramètres et variables et c’est comme jongler : un souffle de bruit, d’interruption et hop : tout tombe.
Donc, en général j’apprécie les entreprises qui permettent de planifier sa journée en discutant autour d’un café (le mieux) ou d’un scrum meeting (avec un café) avec l’équipe pour préparer sa journée.
Il y a aussi une tâche pas très folichône à réaliser quand on est dev et que je conseille de faire TOUS les jours c’est « l’imputation de budget ». En général, un développeur travaille rarement sur un produit ou pour un client exclusivement. Et ce parfois sur une journée (ce qui est pas glop).
Je vous ai déjà dit qu’un sysadmin aussi c’est un centre de coût ? Un dev aussi. Comparé à du hardware, le temps homme coûte un bras. Externalisé il coûte 350-1500€/jours internalisé, je peux pas trop dire car c’est plus difficile d’avoir accès aux salaires qu’au tarif freelance (j’ai eu pratiqué le freelance). Mais en interne un dev coûte -salaires différés4 compris- bien moins qu’un externe. On considère que par exemple un Espace de Service Numérique (anciennement SSII, parfois appelés marchand de viande par les mauvais esprits) doit faire une culbute de x2.7 pour permettre aux non dévs de (bien) vivre.
Donc, si en tant que développeur vous voulez survivre longtemps, être sûr d’être imputé sur un « projet/budget » rentable n’est pas un truc dont il faut s’enquérir une fois en intégration chez le client. Je suggère quand vous êtes en entretien d’embauche de vous « intéresser » fortement aux projets sur lequel vous allez être non seulement techniquement, mais aussi en terme de viabilité à long terme. En général, le client/recruteur vous embauche pour un besoin spécifique, sur un projet.
Et dans la partie « mines », je développerais l’implication que ça a.
Face aux manque de fluidité d’avoir un métier résolument conservateur face à la prise de risque (les administrateurs systèmes) et un autre résolument en mode YOLO, on pète tout à chaque nouvelle version, le métier informatique a élaboré un espèce de métier hybride à l’interface entre les deux : le DevOPS.
C’est une méthodologie et un outillage qui diffère des deux métiers précédemment cités, mais sans apporter de disruption.
Le développeur est mis en contrôle d’un pipeline de production intégré qui lui permet idéalement d’avoir un espace de développement identique à la prod. Là où avant il y avait un passage de relais5 des produits finis par les dévs, testés … en recettage (parfois ignoré), puis une bascule en production de manière récurrente et programmées, on passe à une architecture en déploiement continu où les développeurs sont canalisés par les outils d’intégration continus à fournir test/recettage/validation systématiquement à chaque étape du développement.
En plus comme c’est bien fait les outils modernes, quand ça foire on a un bouton « rollback » (annuler) qui permet de revenir à l’état immuable précédent.
Ça demande un peu plus de compétences que simplement développeur, ou sysadmin car il faut s’intéresser à plus de parties traditionnellement dévolues à l’Assurance Qualité, l’administration système, et parfois même au support.
Dans ce contexte, le sysadmin est bien plus sollicité que dans une infrastructure classique quand il est internalisé, car les infrastructure devops sont bien moins stables que les infrastructures classiques en terme de publication de (base de données, serveurs web, équilibreurs de charges, DNS …) et cerise sur le gâteau devops il y a cette partie opaque qui est pour le moins plus compliquée qu’on appelle « le réseau défini par le logiciel » (Software Defined Networks) qui intègre non seulement le graph de connexion entre les services, mais aussi … tadam … la sécurisation des services.
Ce qui fait qu’en général, devops rime avec disparition des sysadmins hors -et je m’enquiers du sujet car il est important- DNS, gestion des identités (LDAP/AD/Oauth) et pour les domaines les plus critiques mails.
Pourquoi les mails me direz vous ?
Car de nos jours moults procédures de récupération de mots de passe passent par les emails. Et quand on est critique (nucléaire, défense, service public) c’est mieux de garder les services d’identifications directs et indirects proches et de pouvoir garantir leur intégrité. M’enfin, les gens vont ce qu’ils veulent.
Et pour le DNS, j’ai envie de sortir un proverbe sysadmin courant : « It’s always DNS »[^DNS]
Bref, devops c’est comme un développeur dont les infrastructures ont été pensé pour qu’il puisse déployer du logiciel « sans coutures ». J’entends par sans coutures qu’il n’y a pas besoin de faire une interruption programmée des infras pour dérouler le nouveau code et ça minimise en intégrant l’Assurance Qualité tout au long du processus les mauvaises surprises.
Moi, je trouve que c’est une chouette évolution du métier de développeur qui me convient :D
[^DNS] : c’est toujours de la faute du serveur de nom de domaine
Lol, le contrat journalier (donc tu refais ton entretien d’embauche tout les jours) payé 10€/h pour 7h30 théorique, 15h effectif à trimer comme un damné je ne dis pas que j’ai pas aimé, mais je dis que pour aller chercher ma fille à l’école c’est un peu tendax.
J’ai adoré être déménageur, c’était un autre monde, comme un voyage dans la société, avec des gens que j’ai pas mal aimé. Je me suis senti proche de mes collègues ; y’avait un vrai esprit d’équipe car on était tous à vouloir rentrer le plus tôt possible chez nous ; on était tous dans la même galère du patron abusif qui nous faisait enchaîner les chantiers au delà des heures alors que c’est pas la pratique.
Ça s’appelle la cohésion face à une menace réelle.
Pour moi, pour vous, être ouvert à autres choses, c’est une possibilité de découverte.
Le « voyage social » est aussi intéressant que le voyage tout court, moi je suis sur terre, et j’aime la vie, notamment car elle est capable de toujours nous montrer des choses nouvelles et je ne connais peu d’expériences qui soient désagréables.
Primo, la recherche d’emploi n’est pas « un métier à temps plein », pour deux raisons :
Je vous conseille de lire mon livre sur la vie palpitante d’homme au foyer sur le sujet :D
Oui écrire fais tu bien, ça permet d’objectiver ce que l’on fait, de le découper en rondelle et de bien le ranger dans le cerveau. Ça me permet de détourner des routines professionnelles obsessives en élan créatif. Lol.
Pour ne pas devenir chèvre il est important de ne pas laisser le temps de recherche d’emploi mordre sur les autres temps et de rythmer ses activités. Pas au métronome certes, mais à la louche.
Genre, je dédie ma matinée : à envoyer les machines à laver (linge et vaisselle) pour préparer l’après recherche d’emploi puis à la recherche d’emploi elle même. Comme ça je me retrouve pas sous un monceau de tâches à rattraper après.
La recherche d’emploi est découpée en 3 phases :
Vu que l’IA se développe, c’est plus que jamais le moment de chiader les lettres de motivations à la main. Ce qui veut dire que pour chaque offre d’emploi, vous avez intérêt à vous en souvenir et avec trop d’offres d’emplois vous allez oublier quelque chose qui était peut être votre petit plus.
En ce qui me concerne j’ai deux techniques pour réduire l’empreinte mémoire de chaque lettres de motivations :
Ne pas mentir me permet de ne pas avoir à me souvenir de ce que j’ai raconté me concernant et mes aspirations.
Bon, je dis pas tout, comme par exemple que j’ai une cervicale qui me scie un nerf et que j’aimerais bien retrouver un boulot pour éviter de terminer paralysé d’un bras car je trouve que c’est un peu anxiogène, et puis surtout ça pourrait me couper d’un job de développeur/déménageur qui pourrait voir le jour.
Mais restons concentrés ; on ne peut pas humainement se souvenir de TROP d’interactions, je me suis fixé une limite de 2/3 offres par jour auxquelles répondre, et une fois les réponses faites, je passe à vérifier si il y a pas des sources d’offres d’emplois que j’aurais négligées. La monoculture informationnelle est un piège :D
Revenons à l’IA : elle a les défauts de ses qualités.
Pour toutes ces raisons j’ai développé une routine d’écriture anti IA. Après tout, si il y a une fonction d’entreprise qu’elle menace de plein fouet dans sa capacité à « classifier » et « générer de la parlotte », c’est bien les ressources humaines.
J’ai testé le vibe coding (coder assisté par IA) et malheureusement pour l’IA elle s’est plantée : son point faible c’est le traitement du signal et l’acoustique. Je dis ça, mon pote ben a eu exactement les mêmes problèmes du fait que l’IA est à coté de la plaque dès qu’il s’agit d’intégrer le théorème de Shannon (sur échantillonage) ou celui de Nyquist (sous échantillonage).
Ça m’a fait plaisir de voir que d’une part mon temps sur les bancs de l’unif n’avait pas été en vain, et d’autre part que l’IA ne me menaçait pas directement tant que je sais où réside ma valeur : dans mon éducation scientifique.
C’est de cette expérience que j’en ai pondu mon accordeur de guitare en python
Donc ami RH, amie RHe, sache que je suis avec toi de tout mon cœur. Et voilà mes recettes pour tenter de concurrencer l’IA à l’écrit
Est-ce que ça marche ?
J’en sais rien, mais moi ça m’arrange, ça me permet de me distinguer de la concurrence.
Chaque réponse, chaque entretien est une occasion de s’apercevoir si le CV a été bien compris, en écoutant les questions posées en retour.
En ce qui me concerne une question est plutôt un échec : ça veut dire que quelque chose n’est pas clair. Et comme chaque item de mon CV est traité différemment je peux voir comme en A/B testing ceux qui ont plus de succès que les autres.
Vaut il mieux développer les expériences au risque d’avoir un CV de 5 pages ? Où comme je le faisais à une époque être suffisamment succint pour tenir sur 2 pages ?
La réponse vient de l’interaction la plus courante avec les recruteurs.
Je suis temporairement arrivé à la conclusion que les technos les plus récentes étant dans les expériences … récentes, ce sont celles à développer.
Cette concentration peut vous faire oublier le temps, mais l’heure d’amener et chercher ma fille à l’école, sortir le sac à puce, aller en biclou faire les courses au super marché moins cher à 5 km de là m’assurent une routine saine.
Finalement, la recherche d’emploi et être homme au foyer se combinent bien, l’une apportant la stimulation intellectuelle, et l’autre la routine rassurante qui évite de trop penser dans le vide dans l’attente des réponses.
En général, les recruteurs/ESN me rappellent dans la semaine, les employeurs directs mettent un peu plus de temps. Ça veut dire que si comme tout le monde vous privilégiez d’éviter LA mine actuelle du recrutement, il est préférable de rajouter un peu de lag (délai) dans vos réponses aux premiers.
Le rôle du RH est par sa fonction de vous amener à vous faire « dégonfler votre valeur » pour diminuer la masse salariale. La contre mesure logique est de faire la roue comme un paon.
Mais, moi, j’aspire juste à être moi même, ni au dessus, ni en deçà. Et le problème est que ça veut dire que soit je dois me mettre des plumes dans le cul, chose que je n’affectionne pas particulièrement, soit je dois partir en position de négociation tendue du slip ; j’ai pas envie de partir pour descendre la marge. Marge qui selon la convention syntec -celle du métier- interdit de payer moins qu’un certain montant au vu de mon expérience ~2400€/mois et des postes que je demande.
Et c’est heureux. Croyez moi dans le métier connaître la grille SYNTEC par cœur avant d’aller parler rémunération est une bonne chose.
Quand on me propose le minimum pour une fiche de poste qui est largement au dessus des attentes des coefficients SYNTEC, je tique. C’est pas comme si cette convention était la mieux disante. C’est même une des moins protectrice des salariés de France. Je préférerais être en convention métallurgie par exemple (fondeur de microprocesseur).
Mais, je fais comme si ne connaissais pas la convention collective. Histoire de séparer ceux qui tentent de me rouler dans la farine et ceux qui sont honnêtes.
La rémunération se discute une fois la fiche de poste bien établie.
Prenez un dev senior qui a du métier dans le pattes et qui coache ses padawans. On est plus dans l’éxecution propre au 2.1 (pour ceuzes qui ont plus de 26 ans) (2400€) mais dans le coeff 2.3 selon la classification des cadres SYNTEC et bizarrement le recruteur cherche aussi à vous embaucher en 2.1 pour vous vous faire du 2.3. Ce qui est pas gentil.
Mon conseil, surtout avec les intermédiaires est : « évitez de vous négocier avec un montant global, conditionnez vos exigences salariaux à la fiche de poste ».
Un mythe du métier c’est que nos heures de travail ne sont pas comptés et qu’en échange on récupère 1.5 jours de congés par mois en échange.
La vérité est que la charge hebdomadaire est de 48h max (OIT), 12h max journalière (OIT) et donne le droit à des récupérations. Et que sinon, on est sur du 35h/semaine + 3.5 soit 38.5h par semaine.
Une habitude que j’ai apprise chez mes amis déménageurs et d’avoir un cahier où je note mes heures comme pour aller voir Michel mon patron déménageur et lui dire : Kevin, les calculs sont pas bons. Je veux bien trimer comme un damné quelques fois, mais ni tout le temps, ni sans récupération. Ouais, moi je suis comme ça, mon oseille, c’est du temps de vie. Mon contrat me lit à une enveloppe hebdo : et j’évite qu’elle se déséquilibre de semaine en semaine. Ni débiteur, ni créditeur.
Dans la vraie vie, j’ai souvent donné du 50/60h par semaine pendant les crunchs et ça m’a rippé le cerveau et la vie. Je pense que l’intro de sherpa du code est probablement l’expérience la plus traumatisante que j’ai eu suite à une série de surmenage. Écoutez, j’ai plus envie de tuer un ami. J’ai plus envie de manquer d’énergie pour tendre la main à un pote car le boulot m’a rincé, et ce n’est plus négociable maintenant que j’ai une famille.
Moi, je suis un homme de contrat, c’est dans ma culture protestante.
Ça c’est une nouvelle mode dont on cause pas en informatique qui est assez foireuse. C’est de faire miroiter une embauche définitive à un gadjo pour au final le jeter à la fin d’un projet.
Ma mentalité « ouvrière » ne voit pas de problème à être en CDD à commencer une tâche et la terminer. Mais, j’aime pas quand on tente d’abuser la vulnérabilité intrinsèque à être en recherche d’emploi.
Le CDD coûtant 10% plus cher que le CDI, c’est pas qu’une question de tune. C’est aussi une question de faire prendre des vessies pour des lanternes. Et croyez le ou pas, certains « recruteurs » adorent ça.
En général parmi les red flags (signes annonciateurs) il y a la combo : période d’essai (renouvelée chez le recruteur) puis chez le client final. Rajouter l’illégale « je suis désolé, on pratique la reconduction automatique » et vous avez les signes clairs que l’on vous embringue dans cette arnaque. Ça m’est arrivé récemment, comme à d’autres qui étaient prévenus, et c’est toujours rageant de se faire avoir, d’autant plus qu’en général ce sont souvent les boîtes qui vantent pendant leur processus de recrutement « leur compagnie qui respectent l’humain ».
Alors, je vous enjoint à avoir une preuve écrite que la reconduction est automatique, car ça ça passe direct à l’inspection du travail ou aux prud’hommes sans avoir besoin de passer par la case triturage de neurones juridiques.
Alors, à force d’être un routard de la recherche d’emploi, maintenant quand je vois une accroche dans les offres d’embauche, je me méfie et fais la contraposée logique et me dit que c’est peut être la réalité RH de l’entreprise. Finalement, la culture étant du formel qui s’ignore, le slogan décrit non la culture mais un pot de miel. Et la culture, c’est tout sauf ce qui est décrivable. Tiens tentez de décrire la culture d’un groupe auquel vous appartenez (genre sport ou loisir) en quelques mots, je vous mets au défi d’y arriver.
Tenez ; je fais de la boxe française j’ai envie de dire que notre culture c’est de se faire mal, et pourtant, le nombre de traumas par adhérents est inférieur à des sports de vrais brutes comme le foot. Bon, j’en viens à la conclusion que si on prend la contraposée : « c’est se faire du bien » on arrive à un truc plus proche de la réalité (CQFD).
Être qualifié, c’est être autonome sur le choix de ses tâches, et comment les accomplir -toujours en étant autonome- dans le contexte d’un chantier.
Je me souviens de mes débuts en informatique : on était autonome sur notre chantier.
Genre chez easter eggs, un client voulait que ces murs d’écrans soient supportés sous linux.
Le directeur technique est venu me voir avec les spécifications techniques de l’architecture client et et son expression de besoin, m’a demandé comment le le sentais et m’a filé son travail préparatoire document d’architecture. J’ai fait mes recherches sur les technos envisagées, je suis venu avec des amendements à son architecture (j’ai pris une autre direction car la sienne était non maintenue dans le noyau) et il m’a fait confiance et laissé libre de choisir la voie et de coder la solution.
J’ai développé un driver linux pour une carte graphique, les outils pour aller avec le produit, patché un serveur X et étant short sur mes délais pour cause qu’une tâche de R et D6 est pas nature incertaine je suis allé le voir pour qu’il me file une ressource. Chose sur laquelle il m’a fait confiance, et on a livré … 15 minutes avant la démonstration produit.
Ok, j’ai pas été bon, mais c’était un de mes premiers jobs. Si j’avais été meilleur j’aurais mieux « estimer la charge », mais ça, croyez moi, ça vient avec l’expérience.
Aujourd’hui, ce genre de responsabilité sur un chantier ne serait plus possible.
Déjà, on ne m’aurait pas laissé autant capable de me déconnecté du client, rester SEUL et j’aurais eu la myriade de ticket en mode « où en est on, où en est on ? ». Les interruptions sont un vrai tueur de concentration, et certaine tâche exigent d’être immergé dans des tas de données abscons.
Ensuite, j’aurais pas eu la latitude de décider de faire les 3/4 du développement solo : trop risqué mon ami, que se passe t’il si tu as un accident ? Actuellement je développais avec Valéry, et on se causait pas mal.
Aussi, j’avais pas lieu de remplir d’imputation budget, car j’étais non stop sur un problème d’un client, ce qui me permettait d’acquérir la profondeur de vue nécessaire et l’expertise technique nécessaire à la tâche. Et ça me permettait de pouvoir répondre confortablement aux mails clients quand il y en avait.
Je n’avais pas de revue de code. Ça m’arrivait d’appeler Valery à la rescousse car j’étais paumé et l’on faisait du peer progamming sans le savoir avant que ce soit à la mode ; car c’est être autonome de savoir quand et qui appeler à l’aide quand on en a besoin.
À cette époque, le développeur se voyait confier des chantiers où il était autonome, et les clients qui me voyaient faire du vélo étaient toujours effrayé vu ma conduite que leur projet cane avec moi. C’était rigolo.
Jusqu’en 2007 à peu près (soit pendant ~10 ans de ma carrière officielle puisqu’on ne comptera pas les jobs au black et les trucs fait en loucedé pour aider les potes) c’était la norme.
Puis sont apparus les systèmes de tickets.
Outils que j’ai eu mis en place chez des telcos ou installés comme request tracker parce que j’étais orienté sysadmin. Mais c’était aussi les débuts de la généralisation d’outils comme redmine (que j’ai autant installés et configurés qu’utiliser, github … tout ce qu’on commençait appelait des forges.
Et request tracker, c’est un outil que j’aimais bien, en tant que sysadmin il était vraiment pratique pour suivre les interventions, les incidents à partir d’entrées mails.
Ne vous méprenez pas, j’ai installé et utilisé ces outils parce qu’ils étaient utiles, je ne critique pas leur existence, bien au contraire. Redmine7 était un de mes outils préférés en tant que codeur qui permettait de formaliser la découpe de projets en tickets, qui affichait les diagrammes de Pert et de Gantt. Ce qui vous vous en doutez implique que l’on pouvait saisir le temps passé par ticket et générer automatiquement les imputations.
Je suis toujours fan de redmine car il est vraiment bien fait, léger et aisé à personnaliser selon ses besoins.
Tant que ces outils était portés par les codeurs je les aimais bien.
Puis, ces outils de tickets ont échappé des mains des codeurs car certains ont vu que c’était bon. Et les longs mails structurés ont été remplacés par des myriades de tickets pour le codeur.
Le travail a été dépioté et l’ouverture, la fermeture de ticket changées de main et d’un seul coup pour terminer la déstructuration gastronomique du métier est arrivé le manifeste agile avec l’argument massu : tout ce qui fait que les métiers de l’informatique sont qualifiés et autonome c’est de la merde.
D’abord revenons à qui a écrit le manifeste agile en regardant l’histoire du manifeste : des rocks tars, des 10 x engineers, des consultants, catalystes, experts, conteurs pendant leurs vacances de luxe, pas des codeurs dans un piquet de grève en face de leurs bureaux.
Dans quel contexte ?
Celui de la montée des VCs 8 comme YCombinator, l’éditeur derrière HackerNews, un site qui censure tout commentaires et nouvelles sur tout ce qui peut être social comme étant dangereusement politique. Évidemment, Elon Musk y est adulé, comme l’Agile. J’imagine qu’il ne faut pas faire d’argument par association.
Le Manifeste Agile stipule une chose : casser tout ce qui fait le métier selon ses mots ; toujours opposer :
Au passage à l’air agile, les outils sont imposés, ils ne sont plus développés selon leurs besoins par les codeurs. Ce sont les entreprises qui ont la maîtrise des outils.
Les interactions sont celles de la bromance et de la meute de préférence à une approche arbitrée par processus quasi déterministes. Ce sont les interactions des rituels SCRUMs de savoir être qui remplacent des arbitrages basés sur l’argumentation selon des logiques claires … par exemple de coût.
La protection contractuelle et par processus des salariés est bazardée pour laisser le client faire ce qu’il veut comme il veut (le client roi). Il suffit de voir l’hostellerie restauration pour voir que ceci résulte dans des relations toxiques entre clients et « serviteurs »
La conduite opérationnelle du changement (mon domaine d’étude au CNAM) est mise en contrepied de la planification (hum, y’a une couille dans le potage), c’est l’arbitraire du « YOLO il faut changer sans raisons » de préférence à la discussion.
La documentation (qui inclut les spécs techniques et fonctionnelles) est jetée à la poubelle. Et je vais y revenir ces documentations étaient essentielles.
Oubliez le bullshit que j’ai dit sur une recherche saine dans une routine saine.
La vraie vie en a rien à foutre de vos intentions.
Ce matin, je devais emmener ma fille à l’hosto se faire retirer son plâtre, mais paf, cette nuit elle a eu une gastro, ma femme a besoin d’être aidée car sa main est cassée, et je suis la seule personne 70% fonctionnelle de la famille. Et quelque part, c’est un peu mon quotidien d’avoir des imprévus.
Avec ma fille à la maison, je n’ai pas d’autres choix par exemple que vu qu’elle est dans un état larvaire la laisser larver sur mon ordinateur avec tous mes identifiants pour la recherche d’emploi, et avec ma femme qui est dans sa phase rageuse garou, adieu la tranquillité nécessaire à l’exercice.
Et c’est là où je réalise que je ne suis pas à égalité avec ceux qui comme un tiers des parents de l’école élémentaire que fréquente ma fille ont des nounous. Je me rends compte aussi qu’être trop pauvre pour avoir une voiture me coupe de pas mal d’offres vu que les employeurs considèrent acquis comme discrimination à l’embauche qu’on a les moyens d’avoir une voiture pour atteindre leurs sièges sociaux loin des transports en commun, et je comprends mieux les questions récurrentes sur le fait d’avoir une voiture. Non, je n’ai pas de voitures, car en bon père de famille je gère le budget raisonnablement pour éviter les crédits et coûts récurrents ; donc je n’aurais pas de voiture.