Chaque révolution technologique apporte son lot d’avancées et promet de nous libérer

Au quel coût ? On l’oublie souvent dans les livres d’histoire.

Aujourd’hui, la promesse s’appelle intelligence artificielle.
Elle écrit, elle code, elle raisonne.
Elle semble tout comprendre, tout accélérer, tout simplifier.

Mais derrière la fascination, une question demeure : que devient l’humain dans un monde où la machine pense pour lui ?

Le logiciel n’est pas un produit industriel.

C’est un organisme vivant, tissé d’intentions humaines, de contraintes, de dialogues, de choix.
Et l’IA, si nous n’y prenons garde, risque d’en faire une matière inerte.

Ce texte n’est pas une dénonciation de la technologie.
C’est une invitation à la réconciliation, une incitation au discernement.

Parce que la question n’est pas de savoir si la machine va nous remplacer.
Elle est de savoir qui est au service de qui.

I. La promesse et le vertige

Depuis quelques mois, une nouvelle promesse traverse la tech : celle d’une machine qui code à notre place.
Les démonstrations sont bluffantes. Quelques phrases en langage naturel, et un agent te génère une application fonctionnelle, des tests, parfois même le déploiement complet. C’est magique. Presque inquiétant.

Je me souviens de ma première expérience.
Une claque.
La sensation de voir s’ouvrir un monde sans friction : plus besoin de chercher, de comprendre, de peiner.
Juste formuler une intention, et la machine exécute.

Et puis, très vite, le doute.
Un malaise diffus, comme si quelque chose d’essentiel m’échappait.
À mesure que la machine avançait seule, je réalisais que je ne comprenais plus vraiment ce qu’elle faisait.
Les tests passaient, mais le sens s’échappait.
Je corrigeais des bugs sans savoir d’où ils venaient. Voire parfois, elle les corrige elle-même sans que je ne comprenne ce qu’elle fait. Mais qu’importe : ça marche. Du moins, ça semble marcher.
J’avais l’impression d’être spectateur de mon propre métier.

C’est là que le vertige s’installe.
Parce qu’on ne parle pas seulement d’efficacité, mais de rapport au travail, de place de l’humain dans la création.
Cette promesse d’automatisation totale — séduisante, rationnelle, économique — soulève une question plus profonde : Que reste-t-il de notre savoir-faire quand la machine prétend le reproduire ?

Quelle est notre rôle ?

On nous vend la liberté : “Fais confiance à l’agent, concentre-toi sur la vision.”
Mais cette délégation sans discernement a un prix : celui de la compréhension.
Et quand on cesse de comprendre, on perd la maîtrise.

C’est ce paradoxe qui me hante.
L’IA nous offre une puissance inédite, mais si nous ne l’abordons pas avec lucidité, elle pourrait nous transformer en simples opérateurs d’un système que nous ne maîtrisons plus.
La promesse de libération pourrait devenir une nouvelle forme d’asservissement.

Et si, finalement, le vrai progrès ne consistait pas à remplacer le développeur, mais à réinventer la relation entre l’humain et la machine ?
À faire de cette alliance une source d’autonomie, pas d’aliénation.

II. Une vieille histoire : de Jacquard à Toyota

Cette tension entre promesse et vertige n’a rien de nouveau.
Chaque révolution industrielle a porté le même rêve : automatiser pour libérer l’humain — et, presque toujours, ce rêve a flirté avec son contraire.

Au début du XIXᵉ siècle, un tisserand lyonnais du nom de Joseph-Marie Jacquard invente une machine extraordinaire.

Un métier à tisser capable de reproduire des motifs complexes grâce à des cartes perforées.
Chaque trou, chaque carte, correspond à une instruction.
Changer de motif, c’est simplement changer le jeu de cartes.

Pour la première fois, un artisan pouvait déléguer l’exécution répétitive à la machine tout en gardant la maîtrise du dessin.
La machine ne créait pas à sa place — elle prolongeait son geste.
Elle exécutait avec fidélité ce que l’esprit humain avait conçu.

C’était une véritable libération.
Comme plus tard la machine à laver, l’électricité, ou le moteur thermique, l’automatisation a, dans bien des cas, tenu ses promesses.
Elle a libéré du temps, du corps, de la fatigue.
Je ne regrette pas l’époque où il fallait laver son linge à la main ou fendre du bois pour se chauffer.
Ces révolutions-là ont allégé la vie.

Mais le logiciel, lui, n’obéit pas aux mêmes lois.
Il ne relève pas de la mécanique, mais du sens.
Son énergie n’est pas physique : elle est cognitive.
Et c’est précisément cette énergie que l’automatisation tente aujourd’hui de remplacer.

Ce que la machine nous “épargne” ici — la compréhension, la conception, la structuration — c’est la matière même du métier.
Là où l’automatisation mécanique remplace l’effort, l’automatisation logicielle risque de remplacer la pensée.
Elle ne lave pas mieux : elle désapprend à comprendre.

Dans le linge, la machine a tenu promesse.
Dans le code, elle fabrique un leurre.
Un mirage de productivité qui repousse sans cesse la compréhension, jusqu’à ce que plus personne ne sache vraiment ce qui se passe.
Un monde où le code se reproduit plus vite qu’on ne peut le lire, où la complexité ne diminue pas — elle s’accumule.

Un siècle après Jacquard, au Japon, Toyota voyait les choses autrement : le Jidoka était né.
L’idée que la machine doit pouvoir s’arrêter d’elle-même quand quelque chose ne va pas.
Non pas pour produire sans pause, mais pour préserver la maîtrise humaine.
L’humain reste le centre du système, non son esclave.

C’est là toute la différence entre automatisation et autonomisation.
Entre un monde où la machine exécute pour nous, et un monde où la machine nous aide à mieux faire.

Et aujourd’hui, avec l’intelligence artificielle, cette bifurcation se rejoue.
Voulons-nous des machines qui tissent pour nous — ou des machines qui nous aident à tisser mieux ?

III. De l’usine au cloud : la tentation de l’automatisation totale

Ce que le XIXᵉ siècle a vécu dans les usines, nous le vivons aujourd’hui dans le cloud.
Même logique, mêmes promesses, mêmes illusions : produire plus, plus vite, à moindre coût.
Sauf qu’au lieu de rouages et de métiers à tisser, nos machines sont virtuelles, distribuées, connectées en permanence.

L’industrie logicielle a hérité des réflexes de la révolution industrielle : le culte de la productivité, la fascination pour la vitesse, la croyance que tout processus peut être optimisé jusqu’à l’effacement de l’humain.
Et l’intelligence artificielle ne fait que pousser cette logique à son extrême.

Le discours est séduisant :
“Ne perds plus ton temps à coder, laisse faire l’agent.”
“L’humain doit se concentrer sur les tâches à plus forte valeur ajoutée.”

Mais derrière cette rhétorique, un autre mouvement s’opère : une dépossession progressive du savoir.
Ce que les ingénieurs savaient faire par compréhension, ils sont tentés de le déléguer par commodité.

Et c’est vite l’impasse.
On n’a pas attendu l’intelligence artificielle pour en arriver là.
Depuis longtemps déjà, des équipes maintiennent du code qu’elles ne comprennent plus vraiment, des applications fonctionnent “par habitude”, et les bugs sont devenus des phénomènes émergents plus que des erreurs identifiables.
L’IA ne crée pas ce problème — elle l’accélère.

Certains y verront une répétition de la logique décrite par Marx : la machine qui dépossède l’ouvrier de son savoir-faire, le capital qui cherche à réduire sa dépendance à une main-d’œuvre rare et coûteuse.
Cette lecture n’est pas fausse, mais elle n’est pas la mienne.
Là où Marx analysait une aliénation politique, je vois surtout une inefficacité systémique.

Car, dans le logiciel, la promesse de substitution se heurte à une loi plus implacable que le marché : la croissance exponentielle de la complexité.
Plus on délègue à la machine la production du code, plus les interactions se multiplient, plus les dépendances deviennent invisibles, plus la maintenance explose — et avec elle les coûts, les délais, les risques de sécurité.

L’histoire industrielle cherchait à produire toujours plus avec toujours moins d’humains.
Mais dans le logiciel, l’humain n’est pas un rouage à remplacer : il est le seul capable de contenir la complexité.
Je ne crois pas à l’IA qui code à notre place, non par peur du progrès, mais par lucidité : la machine ne peut pas maîtriser ce qu’elle amplifie.

Et même si, un jour, elle y parvenait — même si elle pouvait coder seule, traduire des besoins complexes, écrire des architectures entières —, à quel coût énergétique ?
Chaque ligne générée, chaque modèle entraîné, chaque itération de plus, exigerait une puissance colossale, des fermes de calcul toujours plus vastes, des ressources naturelles toujours plus rares.
L’efficacité locale deviendrait une inefficacité planétaire.
L’énergie qu’il faut pour remplacer la compréhension humaine serait, elle aussi, exponentielle.

Et ce coût ne serait pas que matériel.
À mesure que les systèmes s’opacifient, moins de gens comprennent ce qui se passe réellement.
Le pouvoir se concentre entre les mains de quelques acteurs capables d’interpréter ou d’influencer ces boîtes noires.

C’est là que la question cesse d’être technique.
Elle (re-)devient politique.

Parce qu’un monde où la compréhension disparaît, où la décision est déléguée à des systèmes opaques, où les ressources de la planète sont brûlées pour automatiser des tâches que des humains savaient faire avec discernement — ce n’est pas un progrès.

C’est une régression maquillée en efficacité.

Je ne veux pas de ce monde.
Celui où l’on pille les ressources pour remplacer des humains qu’on aliène de leurs compétences, où l’on appelle “gain de productivité” la perte de savoir-faire.

Si la machine doit nous aider, alors qu’elle le fasse à notre mesure : qu’elle nous augmente, sans nous effacer.
Qu’elle élargisse notre liberté, au lieu de la réduire.

Le reste — cette course à la substitution — n’est qu’une illusion d’efficacité.

IV. Le logiciel : un être vivant, pas un produit industriel

On continue trop souvent à parler du logiciel comme d’un produit : quelque chose qu’on “fabrique”, qu’on “livre”, qu’on “maintient”.
Mais le logiciel ne se comporte pas comme une voiture ou un meuble.
Il ne sort pas d’une chaîne d’assemblage.
Il naît, il grandit, il s’adapte, il se transforme.
Et, s’il n’est pas entretenu, il meurt.

Un code n’existe jamais seul : il vit dans un écosystème – dépendances, données, équipes, outils, infrastructure.
Il réagit à son environnement, il évolue au contact du réel.
Chaque commit, chaque mise à jour, chaque correctif vient réécrire une part de son ADN.
C’est pour cela que deux applications identiques sur le papier ne le sont jamais dans les faits.
Leur contexte, leur histoire, leurs cicatrices les rendent uniques.

Croire qu’on peut “industrialiser” un être vivant, c’est oublier la nature même du vivant. Les phénomènes à l’œuvre ne sont pas linéaires, mais exponentiels, les interactions ne sont pas causales, mais en boucle de rétro-actions et complexes.

L’IA ne change rien à cela – au contraire, elle accélère le cycle.
Elle permet de produire plus vite, donc de complexifier plus vite.
Chaque génération automatique, chaque agent autonome ajoute des couches de code plus ou moins bien pensées et comprises.
Et chaque ligne incomprise augmente l’entropie du système.

C’est là le grand paradoxe : la machine qui devait nous libérer du travail répétitif devient une fabrique d’imprévisible.
Plus on la laisse produire seule, plus le coût de la maintenance explose.
Plus elle écrit vite, plus elle détruit lentement la lisibilité.
Le gain apparent se transforme en dette.

Le logiciel, comme tout organisme, demande de l’attention, du soin, de la sobriété.
Il faut l’observer, le comprendre, l’élaguer régulièrement.
Il faut lui permettre de respirer, de se simplifier.
C’est un travail vivant, un art de la continuité, pas une course à la livraison.

Alors, non, le code n’est pas un produit industriel.
C’est une matière organique, tissée d’intentions humaines.
Tirer sur une tomate ne la fait pas pousser plus vite.

V. L’IA : la nouvelle machine à entropie

On croyait que l’IA allait simplifier le développement.

Qu’elle allait écrire le code à notre place, corriger nos erreurs, documenter nos intentions.
Mais à bien y regarder, elle ne simplifie pas : elle accélère.
Et l’accélération, dans un système déjà complexe, ne fait pas disparaître la complexité — elle la démultiplie.

Chaque ligne générée automatiquement, chaque refactor fait par un agent autonome, ajoute une petite dose de désordre.
Pas toujours visible au début, mais bien réel.
Des dépendances mal comprises, des tests contournés, des morceaux de logique réécrits sans cohérence.
Le tout finit par produire ce que les anciens appelaient déjà la dette technique, mais à une échelle et une vitesse inédites.

C’est une loi simple : chaque automatisation qui ne s’accompagne pas de compréhension augmente l’entropie du système.

L’IA est une machine à produire du code, pas du sens.
Elle écrit, mais elle ne voit pas.
Elle optimise localement sans percevoir la cohérence globale.
Si elle écrit plus vite que nous ne lisons, le stock de code “non assimilé” grandit.
Ce stock, c’est la matière noire du logiciel moderne : personne ne la comprend, mais tout en dépend.

À court terme, tout semble fluide : la productivité explose, les prototypes jaillissent.
Mais sous la surface, l’entropie s’accumule.

Et un jour, elle se manifeste :

• les temps de build qui s’allongent,
• les bugs inexplicables,
• les équipes paralysées par la peur de casser l’existant,
• les coûts de maintenance qui dépassent la création.

C’est ce que j’appelle le mur entropique.
Ce point où la vitesse de production cesse d’apporter de la valeur, parce que chaque ajout de code coûte plus cher à stabiliser qu’à écrire.
Un mur invisible, qu’on ne voit qu’après l’avoir percuté.

Et plus on délègue à l’IA, plus on s’en rapproche vite.

Parce que ce qui faisait notre boussole — la compréhension, la structure, l’intention — s’efface derrière des lignes générées sans compréhension.

Alors oui, l’IA est puissante.
Mais laissée seule, elle devient une machine à entropie.
Une machine qui accélère la perte de lisibilité du monde qu’elle fabrique.

Et si l’on veut éviter ce mur, il va falloir changer de logique : non plus courir après la vitesse, mais redonner de la valeur à la compréhension, à la sobriété et à l’autonomie humaine.

VI. L’autre voie : vers un logiciel écologique

Si le logiciel est vivant, alors il mérite d’être traité comme tel.
Pas optimisé, pas pressé, pas forcé à croître sans limite — mais accompagné, soigné, élagué.

Cette idée d’un logiciel écologique n’est pas une métaphore poétique : c’est une nécessité systémique.

Dans un écosystème logiciel, la dette n’est pas une fatalité.
Elle devient un symptôme : celui d’un système qui consomme plus d’énergie qu’il n’en restitue.
À l’inverse, un système écologique produit de la valeur régénérative : chaque action renforce la cohérence, améliore la lisibilité, augmente la résilience.

Concrètement, cela veut dire :

• écrire moins de code, mais mieux ;
• supprimer avant d’ajouter ;
• comprendre avant d’automatiser ;
• concevoir des agents capables de s’arrêter, de signaler leurs doutes, de demander de l’aide ;
• intégrer la sobriété logicielle dans nos critères de qualité au même titre que la performance ou la sécurité.

L’écologie du logiciel, c’est aussi une écologie du travail.
Des équipes plus petites, plus conscientes de leurs flux, où chaque membre comprend la finalité de ce qu’il construit.
Des boucles de feedback courtes, des tests clairs, des décisions explicites.
Tout ce qui rend le système humain lisible et respirable.

L’IA a toute sa place dans cette vision, à condition qu’on l’utilise comme un outil de soin plutôt que de prolifération.
Un assistant qui aide à diagnostiquer la complexité, à détecter les redondances, à révéler les dépendances cachées.
Un compagnon de maintenance, pas une usine à features.

Le logiciel écologique, c’est le retour de l’intention dans la technique.
C’est redire : “Je comprends ce que je fais, et pourquoi je le fais.”
C’est refuser la course à la production pour retrouver la conscience du geste.

Il ne s’agit pas de ralentir pour le plaisir de ralentir, mais de ralentir pour durer.
Car dans un monde où tout s’accélère, la véritable puissance n’est plus dans la vitesse — elle est dans la maîtrise.

VII. Une responsabilité collective

Le logiciel n’est pas qu’une affaire d’ingénieurs.
C’est la colonne vertébrale du monde moderne.
Et la manière dont nous le concevons, l’entretenons, le gouvernons, dit beaucoup de la société que nous construisons.

L’IA, sous couvert d’efficacité, a concentré le pouvoir entre les mains de quelques acteurs : les détenteurs des modèles, des données, des plateformes.
Ce sont eux qui décident de ce que nous comprenons.
Cette centralisation n’est pas neutre.
Elle crée une dépendance cognitive, une nouvelle forme de colonisation : celle du savoir technique.

Reprendre la main sur nos outils, c’est d’abord refuser cette dépendance.
C’est retrouver la maîtrise de notre infrastructure mentale. Cela passe par des choix très concrets :

• préférer les modèles ouverts quand c’est possible ;
• comprendre les outils avant de les intégrer ;
• conserver la capacité à auditer, à corriger, à expliquer.

C’est aussi garder un sens de l’effort pour continuer à comprendre ce que fait la machine pour en rester maître et non pas devenir son serviteur.

Le but n’est pas de freiner le progrès, mais de redonner au progrès un sens humain.

Reprendre la main, ce n’est pas revenir en arrière.
C’est redonner à la technique sa juste place : un prolongement de notre discernement, pas un substitut à notre jugement.

A nous d’utiliser les outils qui nous augmentent au lieu de ceux qui nous remplacent.

La machine n’est pas notre ennemie.
Elle n’a pas d’intention propre. Du moins pas encore.
Elle amplifie simplement celle de ceux qui la conçoivent.

Le logiciel n’est pas une matière inerte.
Il est le miroir de notre manière d’habiter le monde.
S’il devient chaotique, c’est souvent que nous le sommes aussi.
Le soigner, c’est apprendre à nous soigner nous-mêmes.

L’enjeu, désormais, n’est plus de produire plus vite.
Il est de comprendre plus profondément.
De ralentir pour écouter ce que le système nous dit, de retrouver l’intelligence du geste, la satisfaction de bien faire son travail.

L’IA ne nous condamne pas à la passivité.
Elle nous met au défi d’être à la hauteur de ce que nous inventons.

Alors oui, utilisons la machine.
Mais gardons la main.

Je me souviens d’un projet où, du jour au lendemain, tout semblait s’effondrer. Crash en prod qui te file la boule au ventre. Régressions en cascade dès qu’on corrige un bug. Et puis ces tensions qui montent dans l’équipe : chacun se renvoie la balle, surtout quand la QA est déportée chez d’autres. Tu vois le tableau ? Le désastre complet.

Dans ces moments-là, on entend souvent la même rengaine :
“Il faut plus de tests !”

Mais quand tu commences à te dire ça, c’est déjà le signe que tu as un problème de qualité. Peut-être pas juste un manque de tests : c’est plus profond. Comme si tu voyais de la fumée et que tu te contentais d’aérer la pièce sans t’occuper du feu.

Alors, quels sont ces symptômes ?

• Crashes en production à répétition.
• Régressions en cascade dès qu’une mise à jour pointe le bout de son nez.
• Tensions et incompréhensions entre ceux qui codent et ceux qui testent.
• Et d’autres indices : code qui part dans tous les sens, bugs qui reviennent, énergie qui se dilue…

Ça finit par plomber le moral et la productivité. Et comme le montre bien la manière dont on peut évaluer la performance d’une équipe logicielle, ces indicateurs de qualité ne sont pas anodins : ils reflètent directement la santé globale du projet et de l’équipe.

Dans cet article, on va voir comment retrouver un vrai souffle de qualité… parce que c’est possible.

Qualité VS Qualité

Il y a quelques années, j’ai vu un ébéniste travailler sur une table en chêne massif. Il polissait le bois sans relâche, s’appliquant à chaque geste. Son atelier était pourtant un fouillis monstrueux, avec des outils qui traînaient un peu partout. Il n’avait pas de procédure hyper cadrée. Mais quand tu passais la main sur ce plateau, tu sentais la perfection au bout des doigts. C’est ce que j’appelle la qualité intrinsèque.

À l’inverse, j’ai déjà visité une chaîne de production où tout était millimétré, façon “process qualité” : tout le monde portait les mêmes blouses et les mêmes charlottes, on notait chaque action dans un registre. Pourtant, en bout de course, les pièces étaient mal finies. Les normes étaient respectées, mais il manquait ce grain de soin, ce souci de la dernière imperfection qui fait la différence.

Est-ce que tu imagines la confusion ? On pense souvent que “qualité” veut dire la même chose, qu’il s’agisse de la beauté du travail (qualité intrinsèque) ou de la rigueur des démarches (processus qualité). Mais en réalité, ce sont deux notions distinctes. Les deux ont vocation à se rencontrer, à s’embrasser. Pourtant, l’un n’implique pas obligatoirement l’autre.

Pourquoi c’est important ? Parce que si on veut bâtir une culture de la qualité, il faut soigner à la fois le fond (le souci du détail) et la forme (un cadre clair). Quand on oublie l’un ou l’autre, on rate ce moment magique où le travail bien fait est aussi visiblement bien fait.
C’est exactement l’esprit du Software Craftsmanship, qui cherche à marier excellence technique et exigence humaine.

L’approche lean

Le lean, c’est cette philosophie qui dit : laisse la lumière entrer sur tes problèmes, au lieu de les masquer. Les “5 pourquoi” en sont l’exemple le plus connu : chaque fois qu’un souci survient (un bug, un crash, une régression), tu te demandes pourquoi. Puis encore pourquoi. Et encore. Jusqu’à sentir que tu touches la racine du mal.

Pourquoi est-ce si puissant ? Parce que ça t’évite de t’arrêter à la première cause apparente. Tu vas sous la surface, là où se trouvent les vraies racines. Par exemple :
• 1er pourquoi : “On a un crash en prod, c’est la faute à la base de données.”
• 2e pourquoi : “Pourquoi la base de données est dans cet état ?”
• 3e pourquoi : “On n’a pas de mécanisme de nettoyage.”
• 4e pourquoi : “On n’a jamais pensé à le mettre en place.”
• 5e pourquoi : “On ne prend pas le temps d’analyser les problèmes après les avoir résolus.”

Grâce à cette méthode, chaque problème devient l’occasion de s’améliorer pour de bon, pas juste de poser un pansement. L’approche lean, c’est avant tout regarder la réalité brute pour changer ses habitudes, au lieu de se réfugier dans des théories ou des recettes vite achetées.

Amener le changement

Pour faire bouger la culture qualité dans une équipe, il y a toujours cette question : comment on s’y prend ? Certains managers choisissent d’embarquer tout le monde façon “process participatif”. On discute, on brainstorme, on vote, on itère. D’autres tranchent directement, imposent des routines, des plannings de revues post-mortem, des check-lists qualité, etc.

Dans l’idéal, je préfère miser sur la participation : c’est plus durable, ça fédère, ça motive. Sauf qu’il y a un piège : analyser un crash, faire l’autopsie d’un bug, c’est pas la partie la plus fun du job. On a envie d’aller de l’avant, de coder, de sortir le prochain feature. Alors quand il faut s’atteler à comprendre pourquoi tout s’est écroulé, il y a une résistance naturelle : que ce soit par flemme ou malaise d’aborder les sujets qui mettent en lumière nos défaillances. Sauf que le monstre legacy se nourrit justement de ces faiblesses. Ignorer les problèmes de qualité finit toujours par coûter cher. Plus on attend, plus il devient difficile de reprendre la main.

Parfois, imposer est la seule vraie option pour que la discipline s’installe. Dire clairement : “OK, chaque régression, on la dissèque.” C’est long, c’est chiant, souvent pénible pour tout le monde. Mais c’est le prix à payer pour qu’un vrai changement de mentalité s’opère. Sans un minimum de structure imposée, le changement risque de rester une idée floue, vite balayée par le quotidien. Le secret, c’est ensuite de laisser la pratique – un peu obligatoire au début – devenir un rituel collectif auquel on tient. Parce qu’on sent les résultats, on voit moins de bugs, on dort mieux la nuit.

C’est ce relais-là qui fait toute la différence : passer de “c’est pénible, mais obligé” à “on y tient tous, c’est devenu notre culture.”

Bref

Arriver à une culture de la qualité, c’est comme cultiver un jardin qu’on veut voir fleurir saison après saison. Au début, il y a des outils à manier, de la terre à retourner, et parfois le résultat tarde à venir. Mais si tu persévères, tu finiras par récolter un produit solide et durable, codé avec la même attention qu’une œuvre d’artisan. Alors, ma question : es-tu prêt à te salir un peu les mains pour ça ?

Si oui, je peux t’accompagner dans le processus. C’est un chemin qui demande du temps, de la méthode et beaucoup de patience. Mais la récompense est immense : moins de stress, plus de fiabilité, plus d’épanouissement pour toute l’équipe. Contacte-moi, on épluchera ensemble tes priorités et je t’aiderai à bâtir cette culture de la qualité, pierre après pierre.

10 000 erreurs critiques en production. Aucun test automatisé. « Surtout ne touche pas à ce code. »

Christophe a vécu l’enfer du développeur dans un legacy de 30 ans en C. Puis il a découvert le TDD… et sa vie a basculé.

Ce que tu vas découvrir dans cet épisode :

✅ Comment Christophe a divisé par 3 ses délais de développement (6 mois → 2 mois)
✅ Pourquoi ses utilisateurs lui disent maintenant : « On n’a jamais vu une vélocité pareille »
✅ Les vraies raisons pour lesquelles les équipes résistent au changement
✅ Sa stratégie pour convaincre (ou pas) ses collègues récalcitrants

Le plus fou ? À 50 ans, Christophe kiffe toujours autant développer grâce à cette découverte tardive.

Le plus frustrant ? Voir ses collègues préférer passer 3 minutes à tester manuellement plutôt que 10 secondes avec ses 200 tests automatisés.

Une masterclass de tous les freins que vous pouvez rencontrer :

« On n’a pas le temps d’écrire des tests »
« Ça ne s’applique pas dans notre contexte »
« C’est de la connerie, j’ai déjà essayé »

Tu te reconnais ? Cet épisode va créer une fissure dans ta conception de la normalité.

Un témoignage authentique et sans filtre sur la réalité du terrain, les succès éclatants et les résistances tenaces.

« Tu te rends compte au bout d’un an que tu refais, avec une stack toute neuve, les même erreurs que tu jugeais durement dans le legacy que tu es en train de refactorer. »

Et oui, la grande refonte n’est pas si simple, même souvent un leurre.
Alors quand il faut vraiment refondre un système, comment faire ?

Quand les baby steps ne suffisent plus pour refactorer du code, tu fais comment ?

Et puis tu fais comment pour garder la motivation pendant la traversée du désert ?

On parle de tout ça dans l’épisode du jour avec Thomas qui nous partage son retour d’expérience sur un gros chantier de refactoring chez Agicap.

L’AI, tout le monde en parle, mais il y a quoi derrière ?
Entre ceux qui codent une application en 5 mins, ceux qui montent un business full AI, ceux qui font 10.000€ avec un app codée en un weekend, j’ai l’impression d’être un peu débile de continuer à me manger le cerveau dans mes biz.

Alors, j’ai eu envie de tester : et si je testais de monter un biz full AI, jusqu’où ça peut aller ?

Continuer la lecture de « 90 mins en tête à tête avec Claude Code »

Ca fait 25 ans que je fais du logiciel, que ce soit en tant que développeur, chef de projet, formateur, coach, manager.

Si les compétences techniques sont clefs pour réussir, les compétences relationnelles sont tout aussi importantes : il y a bien longtemps que fabriquer du logiciel est devenu une activité collective pour la plupart des entreprises.

Récemment, je me suis posé la question de formaliser comment je trouvais pertinent d’évaluer la performance des équipes, et voici les métriques qui me semblent importantes.

Je m’étais inspiré de DORA, mais j’ai réalisé depuis que plusieurs autres framework avaient fait mûrir la discipline.

Continuer la lecture de « Comment évaluer la performance d’une équipe logicielle »

Salut,
Il va falloir apprendre à faire avec un truc qui me chagrine encore parfois : la plupart des non techs n’en ont rien à faire de la tech.
Et c’est pas grave en fait. C’est juste comme ça, il faut faire avec.

En même temps, tu n’es pas obligé d’être passionné par les moteurs pour aimer conduire une belle voiture…

Par contre, ce n’est pas à eux de nous dire comment bosser…
Est-ce que tu expliques à ton chirurgien comment t’opérer ?

A contrario, c’est à nous de prendre nos responsabilités pour livrer du bon boulot.
Tu dirais quoi si ton chirurgien t’opérait sans s’être lavé les mains ?
Et s’il oubliait un bistouri dans ton ventre ?

Alors, ne te laisse pas voler la fierté de faire du bon travail :
Ni par ton boss, ni par toi-même.

Pour ce qui est de ton boss, arrête de donner le bâton : ce n’est pas à lui de faire des choix techniques.
C’est bien à lui de poser le cadre de contraintes et te guider dans tes choix techniques, mais rogner sur la qualité est souvent une mauvaise décision.
Donc, ne le laisse te faire faire ce mauvais choix.
Un exemple typique de question suicidaire que j’entends encore trop souvent :
L’application, vous la voulez avec ou sans les tests ? Parce qu’avec, c’est plus cher…
Devine quelle réponse tu vas avoir dans 99 % des cas.

Est-ce que tu imagines acheter un billet d’avion en ligne avec la case à cocher : ‘Avion fiable’.

Pour ce qui est de toi-même, méfie-t’en : je vois trop de développeurs qui sabotent leur progression.
Il y a toujours une bonne raison de ne rien changer.
Peut-être que toi aussi tu tombes dans cet écueil et que tu te dis des choses comme :
“Il y a trop de legacy pour changer, c’est pas le bon projet”
“On n’a pas le temps : il y a trop de bugs à corriger”

Je suis passé par là moi aussi donc je connais bien ça : c’est jamais le bon moment ni le bon projet.

C’est légitime d’avoir peur de sortir de la zone connue.
Cela demande du courage, et parfois de prendre des risques.
Et puis cela demande un travail sur soi déstabilisant : il faut accepter de remettre en cause ses croyances, et redevenir débutant (je déteste ce moment).
Parfois, ça t’amène à continuer à faire quelque chose que tu sais inefficace…

Alors, retrousse-toi les manches, et bouge-toi.

Progresser demande de l’énergie.
Quelle qu’en soit la forme : du temps, des ressources, du sucre pour ton cerveau…
Et cela coûte de l’argent.
Même si j’estime le prix raisonnable du cursus Artisan Développeur, je suis conscient que c’est un investissement.

Mais combien vaut une formation qui peut changer ta carrière ?
Combien ça vaut d’aller chaque jour au travail avec plaisir, et d’en revenir satisfait de ta journée ?

Si tu regardes bien, la formation coûte l’équivalent d’un à deux jours de travail.
Avec la promo qui s’arrête dans 3 jours, c’est même 60% de moins que ça.

Est-ce que 1 jour de travail vaut une carrière épanouissante ?
Il me semble que oui.

Bon, après, je suis un peu malin : dans ce calcul, je ne compte pas le temps que tu vas devoir investir pour étudier.
Mais, même en l’intégrant, je suis convaincu que le pari reste gagnant.

Quoi qu’il en soit, que ce soit avec moi ou ailleurs, forme-toi en continu, et gagne la fierté noble de la satisfaction du devoir accompli.

Pour en savoir plus sur le cursus Artisan Développeur, c’est par ici !

Benoit Gantaume
Artisan Développeur

Salut,
Pour être un bon développeur, il faudrait être passionné.

Mais on fait comment si c’est pas le cas ?

Peut-être que tu lis ce blog et que cela conforte ta passion dans ce métier de développeur.
Peut-être au contraire que cela t’agace et que tu trouves ça surfait.

Ça fait maintenant plus de 5 ans que j’ai lancé le projet Artisan Développeur, avec l’envie de partager la passion du code.
Développer par passion, cela me semblait tellement normal, que je ne pouvais pas imaginer qu’il en soit autrement…

Mais…
C’est en mettant un pied dans les grosses boîtes je me suis rendu compte que le code n’était pas une passion pour tout le monde.

Et c’est là aussi que j’ai découvert quelque chose qui m’a assommé : le gaspillage incroyable que j’y voyais.
Bon d’accord, il y a un biais : en général, on appelle un consultant quand il y a un souci.
Mais j’étais parfois choqué de voir des personnes qui avaient sincèrement envie d’avancer et de donner le meilleur d’elles-mêmes galérer autant…

Entre les jeux de pouvoir, une dette technique asphyxiante, et les émotions des uns et des autres, je voyais un gâchis d’énergie incroyable.

Et je me suis dit que je pouvais aider ces gens à moins souffrir.
Car la passion peut être un remède.

Le truc, c’est que les gens croient que la passion c’est inné.
Pour certains c’est vrai. C’est mon cas, et peut-être le tien.

Mais quelque chose que beaucoup ignorent, c’est que la passion peut se construire : plus tu deviens bon à quelque chose, et plus tu peux l’aimer.
C’est la boucle vertueuse de l’excellence : meilleur tu es, meilleur tu deviens, et plus tu prends ton pied !

Quand j’ai commencé ma carrière professionnelle en 2000, j’étais loin de tout ça.
J’avais un don pour coder, alors je codais.
Je ne me posais pas tellement de questions, je codais à l’instinct, et ça marchait plutôt bien.

Mais il y a une grande différence entre un projet d’étudiant ou de startup week-end et le monde réel : sur un vrai projet, tu vas assumer ton code, ou celui des autres, pendant longtemps !
Et ça change tout dans la manière de coder !

Cette leçon a encore un goût amer dans ma bouche, tant elle m’a coûté cher !
Je me souviens encore de ces premières années où, passée l’euphorie des débuts, je pataugeais dans mon propre code au bout de quelques mois.
J’avais beau avoir des facilités, ça ne suffisait pas…
Je me souviens m’être fait des nœuds à l’estomac à chaque fois que l’on me demandait une estimation.
Par moments, j’en arrivais à venir au travail la boule au ventre. Un comble pour quelqu’un de passionné !
Comme quoi, la passion ne suffit pas…

Encore faut-il acquérir de la technique !
Et c’est ce que je trouve dingue dans l’époque actuelle : cela n’a jamais été aussi facile.
Il y a 25 ans débarquaient l’agilité et l’extreme programming en France. Et les seuls moyens de progresser à l’époque étaient de faire partie d’un groupe de praticiens à Paris, ou les livres.
Pas de YouTube, pas de meetups, pas de blogs… Juste des livres pour le pauvre provincial que j’étais et qui bavait sur les coding dojo parisiens…
Aujourd’hui, les choses sont tout autre : l’offre est pléthorique.
Le développeur qui veut affûter ses compétences ne sait plus où donner de la tête !
Que ce soit :

• Sur YouTube qui te permet d’accéder à des milliers d’heures de confs, de retours d’expérience ou de formations, sans jamais avoir à te déplacer.
• Sur les podcasts qui fleurissent comme des champignons.
• Avec Amazon qui amène les livres du monde entier dans tes mains en 24 h, ou même quelques secondes avec un Kindle.
• Sans compter sur toutes les plateformes d’e-learning qui ont vu le jour.

Sauf qu’acquérir tout ce savoir-faire prend du temps…
Beaucoup de temps.

Une conf dure entre 45 min et 1 h 30.
La plupart des podcasts durent 1 h par épisode.
Un livre prend des jours à étudier.
La plupart des cours en e-learning ne s’occupent que de t’apprendre à utiliser un langage ou un framework, pas de t’apprendre à coder pour durer.

C’est pourquoi, pendant 3 ans, j’ai construis le cursus Artisan Développeur : pour t’apporter une synthèse directement utilisable et condensée de tout ce dont tu auras besoin pour écrire du code durable et vivre une vie de développeur épanouissante.

Plus de 200 développeurs ont déjà suivi ce parcours, et il commence à être rodé !

Alors si tu veux en savoir plus, viens voir par ici !

Comme toujours, je suis disponible par email si tu as des questions.

Benoit Gantaume
Artisan Développeur

Salut,
Dans mes deux précédents articles, je t’ai raconté comment j’ai commencé ma carrière sur des chapeaux de roue avant de me rendre malade, asservi par le monstre spaghetti.
Puis je profitais d’un reset de projet pour changer radicalement ma manière de travailler.
Il m’a fallu passer par une phase douloureuse de remise en question.

Mais quelle récompense !

Non seulement cette nouvelle app a été distribuée à des dizaines de millions d’exemplaires mais surtout nous avions un niveau de qualité exemplaire !
L’app recevait très peu de bugs et le support était géré par deux personnes à temps partiel !

Mais le meilleur dans tout ça était l’incroyable plaisir que je retrouvais, démultiplié, à programmer.

J’allais vite.

Je me sentais léger.

J’avais confiance dans mes développement.

La clef pour déverrouiller mon code, je l’avais sous les yeux depuis plusieurs mois. Elle était dans le petit livre vert intitulé ‘eXtreme Programming’ qui trainait sur mon bureau.
Oh bien sûr, je l’avais lu quand il était arrivé. Mais je n’avais retenu que ce qui m’intéressait : c’était notre caution morale pour travailler à l’arrache.
Par contre j’avais mis de côté tout ce qui était contraignant.
Alors quand je décidais de m’y mettre sérieusement, j’ai tout lu et relu.
Des dizaines de fois pour certains passages.
Et j’ai appliqué le contenu du livre à la lettre, de manière très scolaire et disciplinée.

Etudier ce livre à fond m’a demandé de déconstruire des années de pratique et de faire une confiance aveugle à ses auteurs.
C’est ce livre qui m’a fait découvrir le développement piloté par les tests.
A force d’essayer, de lire et relire les pages du livre, d’expérimenter encore et encore, j’ai fini par avoir le déclic TDD.
J’y ai découvert aussi le binômage, l’intégration continue et toute les autres pratiques qui font la puissance de l’eXtreme Programming.
Mais le TDD a une place centrale : c’est le réacteur du processus.
Enlève ça et tout le reste tombe comme un château de cartes.

Je me souviens de mes premiers tests sur des get/set sur des objets de base…
J’avais l’impression que les cheveux me poussaient dans la tête (et oui, à cette époque j’en avais encore pas mal !).

Je luttais chaque jour pour comprendre et faire des progrès si petits qu’ils pouvaient sembler ridicules.
Je me sentais seul, mais je me suis accroché.
J’avais trop souffert pour abandonner.
Je n’avais plus le choix : je devais changer ma manière de travailler, et, même si le chemin était difficile, je n’avais pas vraiment d’alternative.
Alors, j’ai continué.

Cette blague de tests sur des get/set a bien duré 2 semaines…
Alors oui, aujourd’hui, beaucoup te diront que c’est ridicule de tester des get/set.
On pourrait en parler longtemps.
Mais c’est comme rigoler des premiers pas d’un enfant parce qu’il ne sait pas encore courir : c’est pas le sujet.

Le sujet, c’était de mettre les choses en route.

De commencer par un premier pas pour enclencher une démarche nouvelle.

Chaque jour remettre le travail sur l’ouvrage et recommencer pour s’approprier une nouvelle manière de réfléchir.
Quand tu commences à écrire tes premiers tests en TDD, tu as l’impression que tu inverses le flux d’information dans ton cerveau : tu réfléchis à contre-sens et c’est troublant !

Et puis, j’ai commencé à comprendre des choses.
Mes tests sont devenus plus évolués et plus expressifs.
Au fur et à mesure que je déployais les différentes pratiques de l’eXtreme Programming, j’allais de plus en plus vite.

À ce moment de l’histoire, je n’étais encore qu’au début de mon nouveau chemin, mais je pouvais déjà sentir les bénéfices au bout de 3 mois : le code que j’écrivais était beaucoup plus robuste.
Non pas que je faisais moins de régressions, au contraire, c’est juste qu’elles étaient levées en quelques secondes.
Du coup, je pouvais me permettre de coder plus vite, je savais que mes filets de sécurité s’occupaient du reste.

J’ai aussi appris 3 grandes leçons que je partagerai avec toi ces prochains jours.

Alors oui, je faisais un peu marrer mon boss avec mes petites cartes bristol format A6.
De toute façon il n’avait plus rien à perdre…
Et puis au bout de quelques temps il fallait se rendre à l’évidence : les résultats étaient incroyables.

Grâce au TDD et aux designs patterns que je découvrais quelques temps après, je pouvais coder une app de manière fluide.
J’étais en maîtrise de mon code.
Je pouvais faire évoluer les spécifications en restant super confiant sur ce qui avait été produit.
C’était pour moi une libération et une révélation : je découvrais une manière de travailler qui rendait mon travail épanouissant au quotidien.

Le souci avec le TDD, c’est que c’est une compétence qui peut être difficile à acquérir.

Il faut se remettre en question, faire évoluer ses pratiques.

Peut-être que toi aussi tu as essayé de t’y mettre.
Tu a lu ou regardé des gens de parler de la boucle en trois temps du TDD.
Et tu t’es dit que ça avait l’air cool.
Mais quand tu as essayé d’aller au delà du tuto de base, tu t’es retrouvé bien seul face à ton code…
Et là tu en as conclu que ce n’était pas pour toi.

Rassure toi, c’est normal.

Cela fait, maintenant, 10 ans que je le transmets à d’autres développeurs, et j’ai souvent ce type de retour.

J’ai compris que la marche était très haute et qu’il fallait diviser la progression.
J’ai aussi compris qu’il fallait intégrer le code legacy non pas comme un obstacle, mais comme un point de départ : peu de développeurs ont la chance de démarrer un projet de 0.
La plupart travaillent sur des projets existants.
Peut-être es-tu dans cette situation?

En intégrant ces deux éléments dans une pédagogie moderne et actualisée qui mélange cours en ligne, exercices, QCM, groupes de travail et soutien à distance, j’ai mis au point une nouvelle manière encore plus efficace de transmettre les compétences nécessaires pour écrire du code durable : c’est le Cursus Artisan Développeur.

Si tu as envie d’ en savoir plus sur ce cursus, c’est ici !

Et si tu as des questions, je suis à ton écoute.

Benoit Gantaume
Artisan Développeur

Salut,
Dans mon email précédent je te racontais comment j’en étais arrivé au point d’avoir la boule au ventre en venant travailler alors que j’adorais mon travail. 
Je m’étais fait la promesse de ne plus retomber dans le même piège, asservi par le monstre spaghetti.

Je profitais de cette occasion de recommencer à zéro pour revoir complètement ma manière de coder. 
C’était un défi incroyable car il fallait que je dés-apprenne les réflexes que j’avais acquis pendant des années.

Au bout de quelques semaines, nous avions un prototype montrable (aujourd’hui on dirait un MVP) que nous avons pu emmener au CES de Las Vegas, la grande messe annuelle technologique.
Nous avions pris les derniers euros du compte en banque pour payer les billets d’avions et nous squattions la chambre d’un ami pour économiser l’hôtel.

Et tu veux savoir le plus dingue de cette histoire?

Mes démos marchaient.

Toutes.

Fini murphy.

J’étais devenu serein et j’avais confiance dans ce que j’avais produit.
Même si l’app faisait vraiment peu de choses, elle le faisait bien. 
Alors j’enchainais les démos… Jusqu’à LA démo.

En voyant arriver ce petit monsieur au ventre rebondis, j’ignorais, et tant mieux, qu’on jouait le contrat de notre vie.
J’avais commencé à me méfier en voyant mon boss et notre prospect devenir tout blancs.
Je me doutais que ce petit monsieur était important, mais je m’efforçais de sortir ça de ma tête pour faire la meilleur démo possible.
Et tu sais quoi ? C’est passé comme une lettre à la poste.

Ce petit monsieur était juste l’inventeur de la mémoire flash et fondateur d’une belle boîte du Nasdaq. 
Après cet échange, on a eu le feu vert pour distribuer l’app qu’on était en train de fabriquer. Au bout de quelques années, nous avions distribué des dizaines de millions d’exemplaires de l’app pré-installé sur les clefs USB et les disques durs portables de grandes marques renommées dans plus de 150 pays. En fait, tu as même probablement été utilisateur de notre solution dans les année 2002 à 2008 si tu as acheté certaines clefs USB ou disques portables.

Pour commercialiser la solution, j’ai voyagé dans le monde entier sur les plus grands salons et c’était trop cool !

Le plus intéressant dans cette histoire un peu folle c’est que la solution, je l’avais sous les yeux depuis longtemps. Cela faisait un moment que j’avais acheté le livre qui allait me donner les clefs pour écrire du code durable, me permettre de coder à la vitesse de l’éclair tout en restant complètement serein pour le passage en prod et rendre mon quotidien *beaucoup* plus épanouissant.

Mais en première lecture je n’avais retenu que ce qui m’intéressait. Jusqu’à ce jour où je me suis fait la promesse de changer les choses. 
Alors j’ai repris mon livre et je l’ai étudié à fond. Je l’ai tellement usé à force d’en retourner les pages, qu’elles finissaient par se détacher et j’ai du en acheter un autre.

Tu veux savoir quel est ce livre?
Tu veux, toi aussi, comprendre ce qui a changé ma vie de développeur ?
Je te raconte tout ça dans mon prochain email…

D’ici là, je t’invite à venir  découvrir le cursus Artisan Développeur  : c’est une synthèse de 20 ans de vie professionnelle à coder et transmettre.

Si tu as la moindre question, je suis à ton écoute.
A demain.

Benoit Gantaume
Artisan Développeur