À 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 et 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 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. Hors on a une base de référence : les salaires minimum de la SYNTEC. À condition de travail égal (pas de personnes sous les ordres) on est sur la fiche de poste qui correspond à l’indice ~2.1 de la SYNTEC ce qui donne en prenant l’approximation suivante
100€/jours auquel il faut ajouter les coûts des fonctions supports (RH, DAF, immobilier, …) soit 50% à la louche.
Soit un taux journalier de 175€.
Si on applique un multiplicateur de rentabilité propre à la commercialisation/marketing/infra lié au centre de coût informaticien (on prendra celui des SSII de 2.7), le développeur/sysadmin doit rapporter 405€/jour à l’entreprise. Il est plutôt vendu 500€/jours.
Les freelances ont en plus leurs inter-contrats à supporter sur leurs finances personnelles. Ceci étant une fonction de la variable aléatoire on l’estimera à quelque chose entre 0 et 50% du temps.
Soit 25% (à comparer aux 10% de primes de précarité des CDD) à la louche (et je n’évoque pas les crédits à prendre pour les retards de factures, quand les factures sont réglées (c’est courant dans le monde des freelances)).
Ce qui nous fait un taux équivalent pour les freelance de 220€/jour. Et ça c’est pour un freelance qui n’a pas de démarchages commerciaux à entreprendre (réseautage), ni de frais (achat de consommable, matériel, comptables).
Dîtes vous que les tarifs journaliers des freelances sont calibrés au plus juste et qu’ils ne sont pas « bien » payés. Been there, seen this, le monde des freelance est rempli d’aléas qui ne se limite pas à la facturation, mais inclus aussi les années où les organismes vous réclament des sommes indues (genre à mon époque le RSI était fameux pour ça). Je ne soulignerais jamais assez que pour se lancer en freelance il faut avoir la trésorerie, même quand on est à 100% de jours travaillés pour tenir « une années blanche » (sans revenus) tout en en subvenant à ses besoins de travailleur.
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 évidemment 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. Mais le contrat n’est plus en vogue.
Ç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).
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.
Ê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 et des processus.
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 importantes, mais le sont elles encore ?
Les filières d’ingénieurs de formation française étaient largement inspirée des bureaux d’études en BTP, plus aptes à livrer des usines et des bâtiments que des logiciels. Ce qui explique en tout cas en France le fort héritage procédural et de vocabulaire du métier. Par exemple à l’époque on parlait beaucoup plus qu’aujourd’hui d’Assistance à Maîtrise d’Œuvre/Assistance à Maîtrise d’Ouvrage. Des termes fortement connotés à des chantiers de BTP où il y a séparation de l’étude et de l’exécution.
Seulement un logiciel n’est pas une maison ; pour prendre une allégorie qui vaut ce qu’elle vaut, quand on construit une usine sur 5 ans, les normes de constructions, les matériaux, l’état de l’Art ne varient pas trop.
En informatique, sur 5 ans, le modèle en V qui était la norme se montrait inadéquat. Déjà un des gags récurrents étaient que les normes en sécurité informatique sur les fonctions de hachage cryptographiques existante étaient leur obsolescence entre la conception et la livraison.
J’ai longtemps eu à utiliser à mon grand dam RC4, MD5, SHA1 alors même que les cryptanalystes avertissaient de ne plus les utiliser à cause des attaques par collisions.
Le modèle était inadéquat non par essence, mais par découpage.
Chacune des cases de chaque colonnes pouvaient être confiées traditionnellement à des équipes « orthogonales » 9 afin d’éviter que les intervenants dans une étape soit en collusion avec la phase en regard. Et surtout, vous l’aurez notés les codeurs étaient vus comme des ouvriers de gros œuvres, digérant des documents et codant à partir de là.
Le problème est que pour spécifier et estimer la charge, il faut … coder à minima un prototype et que parfois -horreur- les défauts de conception en informatique ne se révèle qu’au moment de l’implémentation ou que comme évoqués ci-dessus les standards changent entre la spécification et la livraison.
Alors, les ingénieurs ingénieux ont devisé des « méthodes » pour éviter de faite tout le cycle en V avant de corriger, et de refaire un cycle complet en reroutant les non conformité relevées en remontant les étapes comme un saumon. Genre, si à l’implémentation tu détectes une non conformité tu remontes à la spec détaillée, l’archi … et ainsi de suite jusqu’à la bonne étape avant de faire redescendre les modifications. C’est le fameux modèle en cascade.
Mais c’était toujours chronophage. Surtout dans une industrie informatique qui s’est créée en explosant la muraille de Chine entre MOE/MOA où -l’absence de responsabilité financière et juridique le permettait- les équipes en charges de la définition, l’implémentation et la livraison étaient intégrées dans une même entreprise et souvent les mêmes personnes.
L’organisation matricielle est inspirée de ce qui se fait dans la marine de guerre (où j’ai fait mon service) : quand tu embarques 75 matelots, mais que tu as besoins de 150 équivalents fonction métier alors tu demandes aux matelots d’assurer plusieurs fonctions métiers.
Par exemple, un matelot a d’abord un métier (missilier, bosco, cuistot, fourrier, trans…) mais comme c’est un navire de guerre il est aussi formé à des fonctions généralistes (pompiers, secouristes, quart) il a un poste de combat et peut être appelé à faire des tâches « en dehors de sa fiche de poste ».
Ainsi avec un nombre réduit d’effectifs on peut faire face à plus de charge globale, accroissement de charge qui est déportée sur l’individu.
Ce mode d’organisation qui s’est imposé à l’époque des dot com 10 a cassé des barrières qui existaient précédemment entre métiers comme le développeur, l’analyste métier, l’assurance qualité.
C’était aussi un peu logique car ils étaient les plus à mêmes de faire ces tâches.
Je dis du mal des startups, mais il y avait des moments sympas comme quand Michel Paulin nous expliquait Le business model d’une startup : dégager de l’EBITBA 11 qui pouvait se résumer selon lui comme suit :
Le couple OPEX-CAPEX est important dans la compréhension de la mentalité des dirigeants et donc de leur vision de la notion du métier de l’informaticien.
En résumé, les investissements (apportés par les investisseurs/emprunts) sont nuls, les dépenses à maîtriser sont les coûts récurrents.
Ils permettent aussi de décider quand une ressource qui représente un coût récurrent (par exemple … un salarié) est internalisée ou externalisée.
L’investissement dans le cloud plutôt que des infrastructures en propre est guidée par de savants enfumage comptables sur lesquels même wikipedia tique. Mais bon, c’est le domaine non des ingénieurs mais des écoles de commerces, grandes écoles, DAF.
Il est à noter que dans les CAPEX, on compte les rachats des concurrents: ça veut dire que si vous montez votre petite boîte en informatique en profitant des investissements faibles dans ce domaine (quelques serveurs avec la location d’un rack dans un data center coûtent moins chers qu’une voiture) et que vous avez du succès vous avez plus de chances de terminer retraité après le rachat par un grand groupe concurrent (soit pour tuer votre produit, soit pour l’intégrer) que de devenir le big boss d’une entreprise qui sera transmise puisque de toute façon votre concurrence sera les grands groupes qui rachète vos concurrents.
Dans la compréhension OPEX/CAPEX, le coût d’une chose qui peut sembler fixe, genre un serveur engendre des coût opérationnels pendant sa vie : de l’électricité et du réseau à minima, mais aussi le coût des pannes, des remplacements, de l’obsolescence, le temps moyen entre pannes, des mise à jours, des déplacements physiques …. toutes ces choses que l’on regroupe dans le TCO (Total Cost of Ownership).
Vraiment, je m’aventure dans un domaine qui n’est pas le mien, néanmoins, ces notions comptables qui reviennent au moins comme un folklore font parties du décor, comme une musique, une contine.
Bref, si vous entendez ces mots voler autour de vous, sachez que vous êtes dans une startup financiarisée à l’anglo saxonne et posez vous la question de savoir si vous êtes du coté des OPEX ou des CAPEX.
Si vous êtes une CAPEX vous êtes utiles que le temps de construire le produit.
Si vous êtes une OPEX vous êtes un coût inutiles qu’il faut réduire.
Si vous entendez CAPEX/OPEX soyez sûr d’avoir des actions (stock options) car de toute façon le but du jeu dans 80% des cas est de devenir en se faisant racheter. Si vous n’en avez pas : lol.
Imaginez que vous êtes maraîchers et que vous vouliez développer votre activité sur internet et que vous alliez voir votre banque pour un prêt. Si vous êtes capables d’imaginer ceci, vous êtes capables d’imaginer les logiques derrières les logiques d’internalisation ou d’externalisation des coûts.
Imaginez, toujours que vous êtes férus d’informatique, avez du temps libre en hiver et décidiez de faire VOTRE PROPRE site web de commerce électronique. Même si vous êtes doués vous ne pourrez pas réduire tous les coûts, il va vous falloir des investissements et il va falloir aller à la banque. La banque avant de prêter de l’argent va vous demander :
Si l’informatique est une activité de création, alors vous êtes face à un problème puisqu’une activité de création est selon toute logique aléatoire, la banque va vous demander non d’être créatifs, mais conservatifs. Ce qui veut dire ; ne pas créer, ne pas prendre de risques, faire comme tout le monde.
Oui mais, je peux m’acheter un rasberry pi, le coller sur ma box et … quoi ?
Tu vas réinventer la cryptographie ? Le paiement en ligne ? le « design » ? Je vous rappelle que vous êtes maraîchers, pas startupeurs avec l’ambition de « disrupter » (perturber) l’ordre établi.
Si vous voulez que la banque vous prête, vous allez d’abord commencer par faire une étude de marché pour vérifier que suffisamment de vos (nouveaux?) clients optent pour l’achat et que c’est un pari rentable et pas trop risqué au vu de votre chiffre d’affaire, et ensuite que les coûts récurrents sont absorbés par le changement de méthode. Est-ce moins cher de vendre par correspondance du frais (qui a besoin d’être livré et l’on retiendra qu’en livraison c’est le dernier kilomètre qui coûte cher), ou de laisser les clients venir à son étal du marché ?
Le coût du changement de votre logistique pour parer à la mise en ligne compte aussi. C’est une chose qu’une société comme amazon a bien compris.
Si vous décidez de vous lancer dans la construction d’un centre de données (Data Center) pour vendre 2 bottes de carottes supplémentaires par mois, vous avez forts à parier que la banque vous prêtera pas d’argent.
Par contre, si vous pouvez appuyer par une étude de marché que rendre vos lieux et heures de présence à tel où tel marché frais augmente votre fréquentation, la banque va vous dire banco … à condition que les investissements puissent être amortis.
Là encore, la banque va tout de suite refroidir vos ardeurs de créateurs si vous voulez vous lancer dans la location d’un rack 1U dans un datacenter et la création d’un site original si vous ne pouvez pas justifier de la plus value de l’investissement.
Vous serez probablement conseillés de faire le « one best way » : faire comme tout le monde et louer votre pelle de chercheur d’or sur internet.
Pendant la ruée vers l’or, les personnes qui ont gagné le plus de pognons restent les vendeurs de pelle auxquels les chercheurs d’or autant ceux qui devenaient millionnaires que ceux qui ont tout perdu dans l’aventure ont filé leurs caillasses.
En dehors de notre maraîcher, les métiers de l’informatique, découpés en fonction entreprise ont besoin de fond pour développer leur activité, et comme un maraîcher il va être demander aux fonctions métiers de justifier leurs investissements (les fameux capex) au vu des réductions GLOBALES de coûts opérationnels que ceux de l’informatique engendre.
Quoique vous fassiez en informatique, que ce soit du code qui tournerait sans serveur (ex: embarqué) ou de l’infra vous avez des coûts opérationnels. Un logiciel passe la moitié de sa vie en correction, une infra a besoin de bande passante et d’électricité.
Si PHP qui a été de nombreuses fois enterré depuis 1995 est encore là, par exemple, c’est qu’il est derrière pas mal de succès au moins de visites comme facebook, wikipedia, wordpress (l’un des CMS les plus utilisé au monde en mode SaaS), sugarCRM…
En informatique, il existe une valeur intrinsèque à un logiciel avec une solide base utilisateur : il est dit mûr. Et vouloir construire ce qui a déjà été construit des milliers de fois et qui existe comme un produit fini est voué à l’échec.
Je ne dis pas que je porte wordpress dans mon cœur avec tous ses plugins vérolés qu’un antivax, je dis juste qu’en se restreignant aux plugins de bases et en le mettant à jour il est correque. Si, une association qui a quand même quelques passionnés d’informatique prêts à s’autoformer sur un logiciel je vais leur recommander wordpress, car chose qui défrise l’agile : il y a de la documentation et ça reste vu son déploiement, il est facile de trouver facilement des péquins pour vous aider sur le sujet, voir même le personnaliser avec du code.
Et comme, quand on conseille un outil, on se trouve parfois lié à sa vie, je conseillerais -vu qu’il y a des choses qui m’amusent plus que de maintenir un wordpress à jour au vu de la sécurité- de le prendre en location sur une plateforme qui fait l’hébergement ET les mises à jour. Ce qu’on appelle le SaaS 12 ou Location de logiciel. Pourquoi ?
Imaginons que je valorise ma main d’œuvre au prix marché soit 490€/jour ; c’est 100 fois le prix d’une location annuelle du logiciel en version basique, 10x la version avec les plugins d’e-commerce intégré.
Si un auditeur comptable descend vérifier les livres d’une entreprise -que je facturerais pour mes conseils- il va demander même si je travaille une journée à faire un site statique avec la formation pour sa mise à jour pourquoi on a pas suivi les pratiques du marché ? Serait-ce un abus de bien social qui ne dit pas son nom ?
Vraiment ; pourquoi se faire chier à réinventer la roue carrée quand le marché est déjà inondé de solution de gestion de contenus déjà prête à la location commençant à des tarifs parfois même gratuits ?
Selon le code du commerce, la vente à perte est interdite. Dans ce cas, comment peut-on trouver des doses d’informatiques gratuites ?
L’informatique a ceci de magique qu’elle ne semble pas concerner par les lois du commun, étant -et ce depuis 35 ans- considérée comme le Far West, qu’il est trop tôt pour réguler. Nulles responsabilités pénales ou financières automatiques (comme dans les autres domaines de l’ingénierie) et même mieux des possibilités de faire des choses que tout autres domaines industriels tenteraient de faire qui verraient entraîner une descente d’inspecteur des impôts et de flics. Genre remettre en cause le monopole régalien d’émission de la monnaie.
L’informatique a ce que l’on appelle une valeur d’externalité : ce qui fait sa valeur n’est pas l’outil, mais la taille du réseau de ses utilisateurs. Un exemple classique est le format de compression. Si ZIP s’est imposé, rar (le format utilisé par winrar) a longtemps réussi à survivre car il avait une forte popularité chez les crackeurs et démo-makers pré internet. Mais il y a aussi gz (unix), 7z, lha …
Ce qui fait qu’un format s’impose, c’est que les gens l’utilisent plus et imposent de fait lors des échanges leur utilisation. C’est comme un format de vis, d’écrou, de tuyau PVC dans la construction.
Il est dès lors de l’avantage des éditeurs de rendre captif le maximum d’utilisateur avec leur première dose le plus tôt possible ; c’est ce qui explique les offres éducation/étudiants préférentielles.
Vendre des pelles aux chercheurs d’or du numérique, comme des blogs aux influenceurs, des sites de e-commerce, d’e-réputation dont on fait des profits, c’est une chose, mais en 1849 pendant la ruée vers l’or une chose n’avait pas encore été inventée : la pelle comme un service.
T’imagines, même plus besoin d’aller à la quincaillerie du coin acheter ta pelle, ton mulet et ton tamis, ils te sont garantis par contrat être dispo 24h/24, 7j/7 et tu as même plus besoin d’avoir peur que tes outils cassent, en échange de transformer ton achat en location de service. Tu as échangé un coup fixe de 10$ pour une location de 1$/mois avec une SLA 99.999% hourra. Tu y gagnes, pas vrai ? Puis quand t’auras gagné tes premières pépites tu pourras toujours révoquer ton service de pelle pour avoir ton service de pelles internes.
Mieux, tu peux toi même devenir vendeur de pelles numériques grâce à « Platform As A Service », diminuant tes capex et te laissant avec des opex « prévisibles ».
Alors, prévisibles, ça dépend, la jungle des contrats et de leur coût ainsi qu’un modèle basé sur une consommation de ressources qui est non anticipable donne des coûts non anticipables, non ?
Ce modèle de business est celui qui a fait la fortune d’IBM. IBM louait du temps de calcul et vendait ses ordinateurs qui faisait de la containeurisation avant que ce soit hipster. Le cloud et le PaaS sont un resucé du modèle économique du mainframe avec quelques innovations :
Quoi ? Qu’ouïe-je ?
Ben, même si vous avez un bel appel système comme cgcreate/cgexec pour créer des isolations, ou que vous utilisiez les jeux d’instructions bas niveaux vous partagez toujours un chassis matériel avec un nombre défini de périphériques.
Aux problèmes anciens de diagnostique applicatif s’ajoute des nouveaux problèmes lié au fait que maintenant il y a plusieurs machines virtuelles qui tentent de taper une ressource unique. Et je vous liste deux des points de douleurs non exhaustifs sur lequel je tombe souvent :
Maintenant que vous n’avez une multitude d’applications qui tentent d’accéder à une mémoire centrale, les mécanismes de cache sont plus souvent invalidés, car la régularité émergente d’accès mémoire est remplacé par un accès quasi aléatoire, créant des orages d’exceptions noyaux pouvant ralentir l’accès mémoire d’un facteur 100.
Les applications modernes distribuées (ab)usent beaucoup de l’horloge haute précision pour mettre des tampons temporels sur leurs messages. Or, même en 2025, cette ressource n’est pas infinie, créant des filles d’attentes sur l’interruption bas niveau. Certes les OS font de leur mieux pour masquer le problème, mais il est souvent vital pour éviter « les messages qui viennent du futur ou qui se collisionnent et pètent le système », que l’heure soit donnée à l’heure.
Il y en a d’autre comme les erreurs 500 liés à l’OOM killer dû au ballonage mémoire la solution consistant à avoir des limites de mémoire fixe et des dimensionnement de RAM en accord avec le profil applicatif, ou encore celui de la « horde assoiffée » ….
Les conteneurs hardware et logiciels sont des prisons de verre qui partagent beaucoup de ressources en commun, explicitement comme les interruptions disponibles de timer ou les caches mémoires, ou implicites comme la prédiction de branche hardware qui est à l’origine de nombreux patchs de sécurité.
Un processus, un fil d’execution (thread), un chroot sont eux mêmes déjà des conteneurs, les OS modernes ne font que proposer des conteneurs de diverses tailles et formes qui offrent des gestions diverses des problèmes d’accès concurrents et d’isolation.
Le métier moderne d’informaticien consiste à jouer aux poupées russes en enquillant des conteneurs dans des couches de conteneurs jusqu’à arriver à un processus qui fait tourner le code qu’on livre.
Chaque couche d’abstractions, plus ou moins mûres (kof kof je regarde les couches d’isolation réseaux définies logiciellement particulièrement), apportent leur éventuelles problèmes et bénéfices. Contempler sur windows le nid de pus iptables apporté par un linux tournant en VM/WSL pour apporter les fonctionnalités docker c’est autant contempler l’abîme qu’avoir l’abîme qui vous scrute.
Mais au final, quoique vous fassiez, vous montez du code à une adresse mémoire, et vous pointez le registre PC (program counter) à son origine et vous laissez dérouler au gré des registres de statut …
Le thèorème CAP stipule qu’un système distribué ne peut avoir que deux parmi trois :
Or, pour être ACID comme une base de données relationnelle intègre il faut être à minima cohérent, tolérant au partitionnement, et disponible.
Cela veut dire que quand on a besoin de transactionalité (c’est à dire que l’on manipule par exemple des factures, ou des identités) il est fortement risqué de mettre ses bases de données transactionnelles dans un système distribué (à la k8s), ou de mettre leur fichiers sur un système de fichier distribué.
Entendez moi bien, je ne dis pas que c’est infaisable et que personne le fait, je dis que l’on introduit un risque nouveau qui n’est rarement ni pris en compte, ni évalué en terme de coût de corruption des données. (J’ai vu faire).
Après les gens font ce qu’ils veulent, c’est juste que pour les base de données qui nécessitent de la transactionalité, il est chaudement recommandé de ne pas les coller sur un système de fichier distribué.
Alors, oui, on peut avoir un système CAP éventuellement transactionnel, mais ça coûte comme toujours du budget, et je questionne comme d’habitude le fait que le coût du scénario le pire n’est pas calculé, mais accepté. Le scénario le pire est un cas improbable et rare où le système crashe et que l’on ne peut pas restaurer les données.
Et je pense que c’est la transition parfaite avec la partie suivante : ce qui a de la valeur en informatique.
À peu de choses près on défini la relation entre données et information par :
Ce qui signifie que l’information parfaite c’est quand on présente exactement autant de données pertinentes possibles qu’il y en a de pertinentes de disponibles.
Par exemple, si j’ai une base de données des horaires de toutes les bibliothèques de France, et que vous cherchez l’horaire d’ouverture de LA bibliothèque publique de votre quartier, j’ai le potentiel de vous informer, mais je ne vous informe pas en vous présentant tous les horaires, seulement en vous montrant uniquement l’horaire qui vous intéresse.
Vous noterez que google dans sa mouture actuelle fait encore cela très bien.
Jusqu’ici j’ai vaguement traité des outils que l’on appelle « l’informatique » dans l’œil du grand public, les artefacts qui permettent d’avoir l’interface utilisateur pour accéder aux données, et les traiter, je n’ai pas encore parler d’information, et donc d’informatique.
Le principe général de l’informatique est
Le contexte est ce qui est implicite, comme par exemple, la localisation géographique de l’utilisateur.
Si je connais la géolocalisation d’un utilisateur et qu’il n’y a qu’une bibliothèque publique dans un rayon de 10 km, je n’ai pas besoin de lui demander de quelle bibliothèque il est question, car implicitement : c’est la plus proche.
Le contexte que nous offre les technologies web permet de trier d’autant mieux l’information pertinente à présenter que l’on a plus de contexte : par exemple, si la langue de présentation de la page web demandée est l’allemand, je vais peut être ajouter la bibliothèque la plus proche proposant des ouvrages en allemand.
Les paramètres c’est ce qui est en contrôle de la boîte de tri et qui correspond à la pertinence du trieur (qui peut être opposée à l’utilisateur).
Par exemple, imaginons que je sois pauvre, et décide pour me détendre de lire « Ploutos : Dieu du fric » d’Aristophane, une satire amusante sur la répartition injuste des richesses en ce bas monde.
Mon utilité est maximisée quand je peux lire directement le livre. Or, ça tombe bien, il est dans le domaine public et est disponible sur gutenberg, un projet qui met à disposition des œuvres du domaine publique.
Google -qui est une régie publicitaire-, amazon -qui est un vendeur- n’ont pas « intérêt » à vous montrer en premier cette information quand un de leur client à acheté de la pub/de l’espace pour vendre ce livre.
La notion de pertinence du tri est aussi importante : sachant qu’il n’existe pas de pertinence naturelle, comment les moteurs de recherche ont ils évolué pour être pertinents ?
Et bien avec l’ancêtre de la mécanique utilisée en machine learning : avec des boucles de rétro-action constituées par la présentation de résultats et le clic utilisateur.
Plus l’utilisateur clic dans les premiers choix plus l’information est pertinente. Là encore, le contexte est important : la pertinence pour une recherche va dépendre de qui est l’utilisateur.
On ne montre pas les mêmes produits de beauté selon les genres, les origines, les cultures, l’âge … parce que la beauté est un critère hautement subjectif.
Les données utilisateurs sont au final les « données non saisies » nécessaires à trier des informations pertinentes -selon les paramètres de celui qui contrôle le tri- et permettent de définir un prisme de pseudo-pertinence informationnelle.
Je dis pseudo pertinence, car j’insiste : la pertinence absolue n’existe pas ; il n’y a que des prismes déformant selon les paramètres et quelque part dans l’éther absolu de la perfection l’information pure et parfaite non altérée qui est plus ou moins approchée.
Mais, on peut par contre dégager des consensus de pertinences dès lors que l’on approche la notion de pertinence dans une logique de consensus.
Une manière utilisée pour bâtir le consensus consiste à avoir une armée de petites mains qui se voit présenter aléatoirement des données issues d’une source avec des « étiquettes », de laisser des utilisateurs trier les données par pertinence, et faire apprendre par machine learning à partir de ce classement, et répéter la phase apprentissage jusqu’à obtenir des résultats qui convergent.
Vous allez me dire, avec des 100 aines de milliers de mots dans un dictionnaires, ça va en prendre du temps. Mais bonne nouvelle : on peut automatiser l’apprentissage !
Voici un exemple par méthode fréquentielle d’indexation textuelle :
On peut prendre un texte, le décomposer en vecteur de mots invariabilisés (lemmes). À ces lemmes on peut faire correspondre des lemmes appelées « étiquettes » rattachées au sens que l’on a donné au texte.
Genre, si un texte parle de papa, maman, fifille, on peut le rattacher à « famille », et si en prime ça parle d’aller à la plage on peut rajouter « loisir » et ainsi de suite.
Avec un peu de statistique et de régression on peut déduire d’un texte non étiqueté quels similarités (cosinus) déclenchent le mot clé.
Et ainsi de suite.
Le Traitement automatique des Langues est un sujet aussi vieux que l’informatique.
À l’aspect « à plat » d’un texte vu comme un vecteur de lemmes, vous pouvez rajouter son aspect séquentiel et établir des probabilité de transitions avec les chaînes de Markov et si vous les combinez vous obtenez … un générateur de langages.
L’IA n’est après ça qu’une question d’avoir accès aux lemmisateurs/tokenisateurs qui pour le français sont des secrets jalousement gardés malgré le fait qu’ils sont élaborés avec de l’argent publique par les universitaires, et d’une phénoménale puissance de calcul pour parcourir l’espace des configurations et déterminer des algorithmes « pas trop faux » en utilisant des boucles de rétro-actions (retour d’expérience) où l’on utilise l’utilisateur des algorithmes pour valider les algorithmes.
En effet, imaginons que vous interagissiez avec un modèle génératif et que vous lui demandez la définition d’un truc, si vous demandez des détails supplémentaires c’est peut être que la définition n’était pas parfaite … et hop, vous faîtes rentrer l’interaction présente dans l’amélioration de l’apprentissage. C’est pour ça que les IA se battent pour que vous les utilisiez, parce que vous êtes de la main d’œuvre gratuite qui améliore l’IA par retours d’expériences programmatique.
On peut tenter de mesurer avec les algorithmes de NLP la pertinence d’un tri de données en langage naturel, mais on peut aussi volontairement vouloir modifier ce prisme, ce qui en langage naturel revient à changer le sens des mots.
Genre, je suis roquefort, une nourriture étiquetée E en nutriscore, mais j’aimerais que l’on me voit pas comme un aliment malsain. Comment faire ?
permet de visualiser non plus l’utilisateur, mais l’utilisateur comme
des amas d’utilisateurs connectés. Le chronosociogramme
est plus un outil de visualisation que de modélisation, cependant il
permet de comprendre comment on élabore une pertinence « qui s’impose
».
Il suffit de connaître les nœuds les plus connectés et de leur faire émettre le message voulu pour tenter d’avoir une inversion locale de sens.
C’est pas plus compliqué que ça :
En ceci les réseaux sociaux qui sont basés sur des choix utilisateurs sans « aléas » sont des outils parfaits de modifications de prisme de pertinence informationnelle.
Ne me faîtes pas dire que c’est absolument mal ; l’éducation revient à faire changer le prisme de pertinence, comme par exemple apprendre à mettre un masque FFP3 quand il y a un virus aéroporté qui sévit. Selon que l’on aime ou l’on aime pas cette modification de prisme on appelle ça : éducation, propagande, publicité, politique, culture. Juger si la modification de prisme est morale ou pas n’est pas du domaine de l’informatique. Par contre, connaître sa mécanique algorithmique et l’objectiviser est du ressort de l’informatique, parce que cela peut modifier notre quotidien.
Là, le sociogramme inclus plus haut est issu d’un sous ensemble non représentatif de mails issu des « macron-leaks ».
Une campagne électorale est le parangon de l’opération de « changer le prisme de la pertinence ». On y voit les groupes d’influences qui ont été sollicités (sciences po, la mairie de paris, d’obscures entreprises cathos …) ainsi que les acteurs qui sont tous passés de l’anonymat à l’influence politique après la campagne.
Finalement, la question qui se pose concernant l’influence et sa mécanique est que sa mécanique est connue et accessible uniquement par des moyens pécuniers et politiques qui sont accessibles à seulement une partie de la population créant une inégalité dans le processus d’élaboration de « nouvelles pertinences ». C’est pour ça qu’idéalement, j’appelle de mes vœux une corporation éthique de l’informatique qui tel l’ordre des médecins veillerait à ce que la société reste mettre de l’information telle que définie ici en faisant des informaticiens plus que des employés, mais aussi des garants citoyens et professionnels d’une éthique de l’information (et des données personnelles).
Ce que le monde de l’entreprise fait en morcelant le travail, c’est faire perdre du sens au métier de développeur ; une activité de développeur consistant à réaliser des miettes de développement perd de vue la globalité d’un logiciel.
Parfois, pour se reposer : on part d’un problème, on imagine une solution, on assemble le code nécessaire pour obtenir un résultat, et on livre un logiciel complet, documentation incluse.