Le code propre n'est pas le craft

Le code propre n'est que la surface

Pendant longtemps, j'ai cru que le craft c'était ça : du code propre. Des fonctions bien nommées, des classes aux responsabilités claires, des tests qui documentent l'intention. Tu fais ça bien, t'es un artisan.

Et puis l'IA est arrivée. Et elle commence à savoir faire tout ça. Pas toujours parfait du premier coup, mais le gap se réduit tous les jours. Si le craft c'est écrire du code propre, alors oui, c'est une question de temps, avec un simple abonnement.

Le code propre, c'est pas le craft. C'est une conséquence du soin qu'on met dans le travail, pas le soin lui-même.

Le craft, c'est ce qu'il y a en amont. Un menuisier, quand il sculpte et façonne, il le fait avec une vision. Une vision qui vient d'un besoin qu'il a cerné avant de toucher le bois. C'est pareil pour nous. Le craft c'est pas la qualité du code qu'on produit, c'est la compréhension qui le précède. "Ce code, il sert bien ceux qui l'utilisent et ceux qui le maintiendront ?" Ça, aucune IA ne se le demande.

Ce qui fait l'artisan

Si le code propre n'est qu'une conséquence, alors qu'est-ce qui fait vraiment l'artisan ? En y réfléchissant, j'ai identifié trois trucs, c'est sûrement pas exhaustif, et les frontières sont floues entre eux. Mais c'est ce qui me revient le plus souvent : du soin, du feedback, de la discipline.

Le soin

On s'arrête. On reprend le lendemain, la semaine d'après, dans trois mois. Et là, il faut retrouver où on en était, comprendre ce qu'on a fait, et décider si c'est toujours la bonne direction.

C'est ça, le soin. Pas de l'esthétique. De la survie. On est humains : on est pas toujours limpides, on fait fausse route sans s'en rendre compte. Le soin, c'est se donner les moyens de reprendre efficacement et d'évaluer avec un oeil frais.

Un bon nommage, une structure claire, des responsabilités bien découpées, c'est pas pour faire joli. C'est pour que toi dans trois mois, ou le prochain qui passe, puisse reprendre le travail sans tout redécouvrir. Le code propre, c'est le résultat de ce soin. Pas une checklist à suivre, un choix qu'on dose selon le projet.

Le feedback

L'artisan a besoin de savoir si ce qu'il a construit tient la route. Pas dans six mois quand ça pète en prod. Maintenant. Le feedback, c'est un signal rapide qui te dit si t'es encore sur le bon chemin.

Les tests, c'est l'outil le plus évident. Tu modifies un truc, tu lances les tests, tu sais en quelques secondes si t'as cassé quelque chose. Sans ça, chaque modification devient un pari. Mais le feedback c'est pas que les tests. C'est mettre en prod et observer ce qui se passe vraiment. C'est aussi montrer le résultat à celui qui l'a demandé, parce qu'on devine la majorité de ce qu'on nous demande, et deviner c'est pas comprendre. Chaque boucle de feedback raccourcit la distance entre ce qu'on croit avoir fait et ce qu'on a vraiment fait.

La discipline

La discipline c'est deux faces.

Résister aux mauvais réflexes. On empile des couches "au cas où", pour se protéger contre un risque qui n'arrivera peut-être jamais. Face à du code qu'on ne comprend pas, le réflexe c'est de "corriger" : renommer, refactorer, réécrire. Corriger sans comprendre, c'est le meilleur moyen de casser quelque chose.

Et se forcer aux bons gestes. Lire avant de toucher. Chercher le pourquoi avant de changer le comment. Écrire le test qu'on a envie de skipper. Accepter que si quelque chose semble bizarre, c'est peut-être qu'on n'a pas encore compris le contexte.

Et derrière tout ça, chercher la simplicité. Pas la simplicité comme point de départ, comme direction. On commence toujours par un truc flou, trop complexe. Et on travaille pour le rendre plus simple. Construire pour aujourd'hui, avec la conscience que demain va changer. Pas blindé contre le futur. Ouvert au futur. Accepter que "assez simple" c'est suffisant, et que le reste c'est de la peur déguisée en rigueur.

C'est contre-intuitif. On a l'impression de faire moins. En réalité, on fait mieux.

À force de soin, de feedback et de discipline, on finit par développer un coup d'oeil. On sent quand ça cloche avant même de vérifier. Mais ce flair-là, c'est pas un pilier, c'est ce qui émerge quand on pratique le reste.

Et l'IA dans tout ça ?

Soyons honnêtes : l'IA progresse sur chacun de ces points. Elle sait nommer, structurer, tester, reconnaître des patterns et améliorer la consistance. La frontière bouge tous les jours.

Mais elle risque rien. Elle n'a pas de projet à maintenir, pas de système dont elle devra assumer les choix dans six mois. L'artisan reste indispensable, pas parce qu'il écrit du meilleur code, mais parce qu'il porte le poids de ce qu'il construit.

---

Questions ouvertes

Une question me reste, que je laisse volontairement sans réponse définitive.

Comment développer le craft sans la pratique ?

Le soin, la discipline, le flair, tout ça vient de la pratique. Des années à lire du code, à se tromper, à corriger sans comprendre et à en payer le prix. C'est ça qui forge l'artisan.

Mais si l'IA fait de plus en plus de la production, si le premier réflexe d'un junior c'est de demander à Copilot au lieu de chercher par soi-même, comment développe-t-il ces muscles ? Le coup d'oeil vient pas d'un tuto. Il vient des erreurs qu'on a faites et du temps qu'on a passé à les comprendre.

On peut pas raccourcir l'expérience. Ou peut-être que si, mais autrement. C'est une question que je me pose encore.