Il y a une pensée qui m’accompagne depuis des mois, peut-être depuis que l’intelligence artificielle a cessé d’être une promesse lointaine pour devenir un outil que l’on utilise tous les jours. Une pensée inconfortable, parce qu’elle remet en cause certaines convictions qui m’ont guidé pendant des années, et qui étaient peut-être plus fragiles que je ne voulais l’admettre.
Elle m’est revenue aujourd’hui quand le Prof. Zanero a relayé ce skeet :
Une pensée inconfortable
La pensée est la suivante : la qualité absolue, recherchée comme valeur en soi, pourrait être un luxe que nous ne pouvons plus nous permettre. Pas toujours, pas partout, pas comme principe universel.
Je l’écris et j’entends déjà les objections, les mêmes que je me suis faites longtemps. « Mais la qualité paie toujours », « La dette technique s’accumule », « Qui coupe les angles échoue à long terme ». Toutes choses vraies, en un sens. Et toutes choses qui méritent d’être réexaminées à la lumière d’un monde qui a changé plus vite que nous n’étions prêts à l’admettre.
J’ai passé des années à monter des équipes, à définir des standards, à me battre pour avoir le temps de faire les choses « bien ». J’ai discuté avec des commerciaux qui voulaient tout pour hier, avec des clients qui ne comprenaient pas pourquoi il fallait plus de temps, avec des développeurs qui voulaient livrer quelque chose d’imparfait. Et la plupart du temps, je crois avoir eu raison. Mais la raison d’alors n’est pas nécessairement la raison d’aujourd’hui, et une partie de mon travail consiste à distinguer entre principes intangibles et habitudes déguisées en principes.
Le sujet n’a jamais été vitesse contre qualité, comme s’il fallait choisir entre deux pôles opposés. Le sujet a toujours été : quelle qualité, pour qui, quand, et combien me coûte-t-elle dans la durée. Sauf qu’aujourd’hui cette question a d’autres réponses qu’il y a cinq ans, parce que l’intelligence artificielle a changé les règles du jeu d’une façon que nous cherchons encore à comprendre.
Quand un modèle génératif peut écrire en quelques secondes du code qui marche, du code qui demandait autrefois des heures, la perception de la valeur change. Je ne parle pas de valeur réelle, je parle de perception. Et dans le business, la perception compte, parfois plus que la réalité. Un client qui voit un concurrent pondre des fonctionnalités à un rythme soutenu commence à se demander pourquoi nous sommes si lents. Et il ne suffit pas de lui expliquer que notre code est plus propre, mieux testé, plus maintenable. Ce sont des choses qu’il comprendra seulement quand il aura un problème, et à ce moment-là il pourrait être trop tard pour tout le monde.
Quand l’artisanat fonctionne
Le modèle artisanal pur — « on fait tout à la main, calmement, avec soin » — fonctionne encore. Mais il ne fonctionne que dans des conditions précises qui ne sont pas toujours réunies. Il faut un problème vraiment critique, où une erreur coûte très cher. Il faut peu de concurrents crédibles, parce que s’ils sont nombreux, le client a des alternatives. Et il faut un client prêt à payer cher pour dormir tranquille, ce qui veut dire un client qui comprend le risque et a les moyens de le mitiger.
Quand ces trois conditions sont alignées, l’artisanat gagne. Quand l’une au moins manque, la promesse « nous faisons tout à la main, parfaitement » risque d’être perçue comme de la lenteur et du coût plutôt que comme de la valeur. Et ce n’est pas la faute du client s’il ne comprend pas ; c’est notre responsabilité de trouver le moyen de communiquer cette valeur ou, si nous n’y parvenons pas, de nous adapter au marché qui existe vraiment.
La qualité comme investissement progressif
Le truc, peut-être, c’est de cesser de penser à la qualité comme à un absolu et de commencer à la traiter comme un investissement progressif, lié au stade du produit et aux besoins réels du moment. C’est une perspective qui m’a pris du temps à accepter, parce qu’elle va contre l’instinct de qui a grandi en croyant que les choses se font bien ou ne se font pas du tout.
Au début d’un produit, quand on cherche encore à savoir s’il y a un marché, on a besoin de quelque chose d’assez fiable sur un périmètre très étroit. Pas de perfection. De quelque chose qui marche, qui ne s’effondre pas au premier usage, et qui soit conçu assez proprement pour pouvoir grandir sans imploser. C’est ce que certains appellent « simple, lovable, complete » : peu, mais bien fait sur ce qui compte vraiment. Pas tout poli à la perfection, mais les bonnes choses faites avec soin.
À mesure que le produit trouve son marché, que les clients commencent à payer, que le chiffre d’affaires monte, on relève le niveau de robustesse, de sécurité et de finition précisément sur les morceaux qui génèrent le plus de valeur ou de risque. On ne polit pas partout uniformément, parce qu’on n’a pas des ressources infinies et que tout ne mérite pas le même investissement. On concentre l’artisanat là où il compte, là où un bug se traduit en dommage direct, là où la qualité fait la différence entre un client qui reste et un client qui part.
Et la vitesse ? La vraie vitesse, on ne l’obtient pas en écrivant du code médiocre. Je le sais parce que j’ai vu assez de projets se noyer dans leur propre dette technique pour comprendre que les coupes finissent toujours par mordre. La vitesse, on l’obtient en coupant le scope, en décidant ce qu’on ne fera pas, en automatisant les tests, en rapprochant le plus possible les contrôles qualité du moment où le code est écrit. Surtout quand l’IA est dans la boucle, qui peut produire des montagnes de code en peu de temps mais n’a pas le jugement pour décider quel code mérite d’exister.
Ainsi, on ne choisit pas entre perfection et shipping rapide. On choisit entre diverses combinaisons sur un front de possibilités qu’on déplace selon le contexte. C’est une façon plus honnête de penser le métier, je crois. Moins romantique, peut-être, mais plus utile.
Qualité réelle et qualité perçue
Il y a aussi une chose inconfortable dont on parle peu : l’écart entre qualité réelle et qualité perçue. Pour le client, la qualité, c’est surtout l’expérience, pas l’implémentation interne. Une interface claire, des temps de réponse corrects, un support présent et honnête couvrent un tas de défauts techniques qui ne cassent pas le flux. Et paradoxalement on peut avoir un logiciel techniquement très raffiné mais perçu comme médiocre parce que lent à évoluer, peu aligné au besoin, ou mal communiqué.
Je l’ai vu se produire. Des projets sur lesquels on avait travaillé des mois pour atteindre des standards très élevés, et que le client trouvait frustrants parce qu’ils ne répondaient pas à ses besoins réels. Et des projets moins soignés techniquement, mais que les clients adoraient parce qu’ils résolvaient un problème précis simplement, et étaient mis à jour souvent sans drame.
Cela ne veut pas dire que la qualité technique ne compte pas. Cela veut dire qu’elle compte en relation avec tout le reste, pas comme valeur absolue détachée du contexte. Et cela veut dire que notre travail consiste aussi à comprendre ce que le client perçoit comme qualité, pas seulement ce que nous savons être de la qualité.
Où mettre le temps artisanal
La question que je me pose le plus souvent ces derniers temps : où mets-je mon temps artisanal dans un monde où l’IA peut faire une grosse part du travail standard ? Pas 60 %, peut-être pas même 80 % comme certains prétendent, mais en tout cas une portion significative de ce qui demandait autrefois des heures de travail humain.
À coût équivalent, le client te paie volontiers la part où ton jugement réduit un risque important ou augmente fortement le résultat. Il ne te paie pas la part où tu réécris à la main quelque chose qu’un modèle génératif peut sortir en quelques secondes. Et si tu insistes à facturer le temps comme si l’IA n’existait pas, tôt ou tard quelqu’un offrira le même résultat à moitié prix, parce qu’il a compris comment l’utiliser.
J’ai commencé à raisonner différemment. Je fais à la main, avec des standards très élevés, tout ce qui est proche de l’argent, du risque juridique ou réputationnel, de la sécurité. Les morceaux où un bug se traduit en dommage direct, où il faut du jugement et pas seulement de l’exécution. Et je laisse l’IA faire, sous supervision attentive, tout ce qui est commodité, répétitif, facilement testable, substituable. Pas parce que je lui fais aveuglément confiance, mais parce que je sais où contrôler et quoi vérifier.
Le prix, ensuite, devrait refléter davantage le risque qu’on prend et la valeur qu’on permet que le nombre d’heures passées dessus. C’est un changement qui prend du temps à être accepté, par nous comme par les clients. Mais c’est la direction vers laquelle nous allons, qu’on aime ou non.
Qui risque vraiment l’échec
Et qui risque vraiment de tomber dans ce nouveau monde ? Je me suis posé la question de nombreuses fois, en cherchant à voir où se trouvent les vrais dangers.
Je ne crois pas que ce soient ceux qui aiment la qualité. Je crois que ce sont ceux qui confondent perfectionnisme et professionnalisme, qui ralentissent toujours, qui ne savent pas dire « ceci aujourd’hui ne sert pas ». Ceux qui polissent à l’infini pendant que le marché les double, persuadés que tôt ou tard le monde reconnaîtra leur valeur. Parfois cela arrive. Souvent non.
Et risquent aussi ceux qui sont à l’extrême opposé : ceux qui ne courent qu’après la vitesse, saturent le système de changements non gouvernés, accumulent une dette technique sans même s’en rendre compte. Tôt ou tard les problèmes émergent, les clients perdent confiance, et tout le temps économisé au début se paie avec intérêts.
Qui a la meilleure chance, à mon sens, c’est celle ou celui qui parvient à faire trois choses ensemble. Utiliser l’IA pour aller vite, parce que ne pas le faire revient à rester en arrière. Utiliser sa tête pour décider où s’arrêter pour finir, parce que tout ne mérite pas le même soin. Et user d’honnêteté pour raconter au client le type de qualité qu’il achète et pourquoi.
Cette dernière partie est peut-être la plus difficile. Elle demande d’admettre que tout ce que nous faisons n’est pas parfait, qu’il y a des compromis, que certains choix sont faits pour des raisons de temps ou de budget et non pour des raisons techniques. Elle demande de faire confiance à la capacité du client à comprendre, ou au moins d’essayer. Et elle demande d’accepter que parfois il ne comprendra pas, et qu’il faudra trouver un moyen d’avancer quand même.
Ce sont des réflexions en cours, pas des conclusions définitives. Le métier change sous nos pieds, et qui prétend avoir toutes les réponses n’a probablement pas bien compris les questions. Ce que je sais, c’est que l’équilibre entre qualité et vitesse n’est plus celui d’avant, que l’IA a redessiné les frontières du possible, et que notre tâche est de trouver une nouvelle manière de créer de la valeur dans ce contexte.
Cela ne veut pas dire abandonner les principes. Cela veut dire comprendre quels principes sont vraiment des principes et quels n’étaient que des habitudes qui avaient du sens dans un monde qui n’existe plus. C’est un travail de discernement qui demande de l’humilité, de l’honnêteté intellectuelle, et la disponibilité à remettre en cause ses propres certitudes.
Et peut-être, à la fin, c’est précisément cela qui distingue un bon professionnel de quelqu’un qui ne fait que répéter des formules apprises : la capacité à s’adapter sans se perdre, à changer sans trahir, à évoluer en restant fidèle à ce qui compte vraiment. Qui n’est pas la qualité en soi, mais la valeur que cette qualité crée pour qui en a besoin.
Ce qu'il faut retenir
Le fantôme de l’artisan parfait suscite culpabilité chez ceux qui utilisent l’IA et sentiment de supériorité chez ceux qui la refusent : les deux sont inutiles, parce que la valeur n’est pas dans les heures écrites à la main mais dans le système qui tient.
La vraie vitesse, ce n’est pas du code médiocre : c’est un scope coupé, des tests automatisés, des contrôles qualité au plus près de l’écriture — sinon l’IA produit une dette technique qui explose à six mois.
Le prix devrait refléter le risque qu’on prend et la valeur qu’on permet, pas les heures au chronomètre — qui facture comme si l’IA n’existait pas se fera doubler par qui a compris comment l’utiliser.
Questions & réponses
Pourquoi l'IA remet-elle en cause le rapport entre qualité et vitesse dans le software ?
Parce que pendant vingt ans, la qualité était le compromis de la vitesse : aller vite, c’était faire moins bien, faire bien demandait du temps. L’IA brise cette corrélation sur une certaine tranche de travail : on obtient un output décent à des vitesses qui exigeaient autrefois des sacrifices. Mais la tranche où cela vaut ne coïncide pas avec celle qu’on imagine — et c’est là que naît le fantôme de l’artisan parfait.
Qu'est-ce que le « fantôme de l'artisan parfait » ?
C’est l’image idéalisée de la développeuse ou du développeur qui pèse, conçoit, écrit chaque ligne avec un soin maniaque. Elle existait dans quelques situations privilégiées, et est devenue un mythe universel. L’IA la rend insoutenable, non parce qu’elle est invalide — mais parce qu’elle n’est pas scalable. Le fantôme produit de la culpabilité chez celles et ceux qui utilisent des agents, et un sentiment de supériorité chez celles et ceux qui ne les utilisent pas. Les deux sont inutiles.
Peut-on avoir qualité et vitesse ensemble avec l'IA ?
Oui, mais pas automatiquement. Il faut une infrastructure de contrôle : revue de code sérieuse, tests exhaustifs, observabilité, critères d’acceptation explicites. Avec cette infrastructure, l’IA multiplie la productivité sans compromettre la qualité. Sans, elle accélère en produisant une dette technique qui explose six mois plus tard. La différence ne vient pas de l’outil, elle vient du processus qui l’entoure.
Que devrait faire celui ou celle qui se sent aujourd'hui écrasé entre les deux exigences ?
Cesser de courir après le fantôme. Accepter qu’un bon professionnel utilise les outils disponibles (IA comprise) avec jugement critique — pas avec nostalgie. La valeur n’est pas dans le fait d’avoir écrit chaque ligne à la main, elle est dans le fait d’avoir produit un système qui tient, qui est documenté, qui peut être modifié. Qui mesure son travail au nombre d’heures passées à écrire du code mesure la mauvaise chose.
L'auteur
