Le craft est mort, vive le craft

« Le craft, c'est dépassé. »

C'est ce que m'a dit un candidat en entretien après qu'on lui ait dit que sa culture craft était insuffisante. Sa réponse est franche : avec l'IA, ce qui compte, c'est d'aller vite.

On pourrait balayer ça d'un revers. Sauf que dans les équipes que j'accompagne, j'entends la même chose, formulé différemment.

Ce que les données montrent déjà

Faros a mesuré l'impact de l'adoption IA sur 22 000 développeurs et 4 000 équipes, sur deux ans.

Le throughput individuel a augmenté de 34 %. Les epics complétées par développeur de 66 %. L'IA accélère la production de code, personne ne le conteste.

En face : les bugs par développeur ont augmenté de 54 %. Le ratio incidents par PR a été multiplié par 3,4. Le code churn par 9. Le lead time par 5. Et 31 % de PRs supplémentaires sont mergées sans aucune review.

On peut expliquer une partie de ces chiffres par l'augmentation du volume et de l'ambition des projets. On peut aussi argumenter que le churn élevé reflète des refactorings qu'on n'aurait jamais lancés sans l'IA. Mais ça n'explique pas pourquoi les équipes découvrent leur propre implémentation le jour de l'incident en production.

Le constat le plus dur du rapport : les organisations avec de bonnes pratiques engineering pre-IA ne sont pas protégées. Celles qui avaient des fondations solides, des process de review matures, des DORA scores élevés, voient la même dégradation. La génération de code est devenue tellement peu coûteuse qu'elle dépasse la capacité d'absorption des mécanismes de qualité existants.

Certains CTOs que je croise sont convaincus que leurs équipes matures absorberont naturellement l'IA. Les données suggèrent l'inverse.

Ça ne veut pas dire que les anciennes pratiques doivent survivre telles quelles.

Le craft n'a jamais été le code

Pendant des années, on a cru que le craft consistait à écrire du code élégant, appliquer des patterns, maintenir une architecture propre. L'IA est justement très bonne pour produire tout ça. Code idiomatique, bien nommé, stylistiquement cohérent. Si le craft se résumait à ça, le candidat aurait raison : c'est dépassé.

Le code était le support observable d'autre chose. La capacité d'une équipe à construire un modèle mental partagé de son système et de son domaine. Savoir quels compromis ont été faits et pourquoi. Savoir ce qui mérite d'être simplifié et ce qui doit rester complexe.

Dans une équipe que j'accompagnais, j'ai voulu discuté du pairing. La réponse a été immédiate : « on a Claude Code ». Même chose sur la relecture croisée des specs techniques : « une seule relecture suffit ».

Pas de résistance. Un raccourci rationnel. Et pas absurde. Le pairing coûte cher. Le mob programming est lent. Personne ne regrette le temps où un refactoring de 2 heures prenait une journée en binôme. On peut même argumenter que Claude Code est une forme de pairing, avec une machine au lieu d'un collègue.

Sauf que le challenge de la machine ne remplace pas celui d'un autre humain. Il améliore une décision individuelle. Il ne construit pas automatiquement une compréhension collective. Le pairing sert à ce qu'un développeur comprenne et challenge les choix d'un autre, pas à écrire du code à deux. La relecture de spec sert à ce que l'équipe s'aligne sur le problème avant de coder. Le TDD permet de spécifier le comportement attendu avant d'écrire une seule ligne (Kent Beck va jusqu'à l'imposer dans le system prompt de ses agents, parce que sans ça, l'agent supprime le test plutôt que de corriger le code). Le mob programming sert à ancrer les conventions par imitation collective.

Chacune de ces pratiques produit un livrable. Et chacune construit, en parallèle, une compréhension partagée du système. L'IA produit le livrable. Le reste, non.

Le gain est réel. On délivre plus vite, on a plus de tests. Mais j'observe que les équipes n'utilisent pas le temps gagné pour penser. Elles l'utilisent pour produire le ticket suivant. De temps en temps pour améliorer la qualité de l'ensemble, renforcer par exemple les tests ou la doc. Souvent, les pratiques (pair/mob programming, spec reviewing) n'ont même pas la chance de s'installer. L'IA fournit le raccourci avant que la pratique ait prouvé sa valeur.

Ce n'est d'ailleurs pas une critique de l'IA. C'est une critique de ce qu'elle amplifie. Dave Farley résume ça sèchement : les équipes avec de bonnes pratiques bénéficient massivement de l'IA. Les autres produisent du logiciel de mauvaise qualité, plus vite.

Le craft évolue

Certaines équipes délèguent à l'IA. La spec, les tests, le code. L'IA produit, l'équipe valide et passe à la suite. D'autres s'en servent pour penser. Elles spécifient le comportement attendu en TDD, puis laissent l'IA coder. Elles écrivent le premier draft de la spec elles-mêmes, puis utilisent l'IA pour le démolir : qu'est-ce qui peut casser, quel cas a été oublié. Elles relisent les tests générés en se demandant ce qu'ils ne couvrent pas.

Martin Fowler parle de « lâcher l'obsession du code parfait ligne à ligne pour renforcer la compréhension du domaine et de l'architecture globale ». Le craft ne disparaît pas., il évolue. L'exécution compte moins. Le jugement et la modélisation du domaine comptent plus. C'est déjà ce qui séparait les bonnes équipes des autres, mais maintenant l'écart se voit.

La question pour chaque équipe : est-ce qu'on utilise l'IA comme un sparring partner qui force à réfléchir, ou comme un collègue compétent à qui on délègue ?

Le craft n'est pas mort. Pas encore.

Pendant vingt ans, les pratiques engineering ont servi à produire du logiciel et à fabriquer de la compréhension collective. L'IA produit désormais une grande partie du logiciel.

On mesure le throughput, les tickets fermés, les PRs mergées. On ne mesure presque jamais la compréhension distribuée. Qui sait quoi dans l'équipe. Combien de temps il faut pour modifier un système six mois après l'avoir construit. Ce que ça coûte d'expliquer une décision d'architecture à quelqu'un qui vient d'arriver.

Pendant longtemps, la vitesse de production était un signal raisonnable de la santé d'une équipe. Quand écrire du code devient presque gratuit, ce signal cesse progressivement d'être fiable. Si l'IA produit désormais le logiciel, il reste une question que personne ne pose encore assez : comment mesure-t-on la qualité de la compréhension collective qui permet de le faire évoluer ?

Ce candidat pensait que le craft était mort. Le craft d'exécution recule, oui. Mais le craft n'a jamais vraiment été le code. Le craft consiste désormais à produire la compréhension qui permet de le faire évoluer.

L'IA rend le code abondant. La compréhension reste rare.

Sources et articles liés

Données

Faros AI Engineering Report 2026, « The Acceleration Whiplash » — 22 000 développeurs, 4 000 équipes, deux ans de télémétrie

Voix craft + IA

Kent Beck — TDD, AI agents and coding (The Pragmatic Engineer)
Kent Beck — Augmented Coding: Beyond the Vibes
Dave Farley — The AI Shift is Bigger Than Internet and Agile (Aviator podcast)
Martin Fowler & Kent Beck — Tech Truth: Agile Evolution & the Future of SW Engineering (GOTO 2025)

Articles liés (série IA et Qualité)

Le code gratuit qui coûte cher (comprehension debt)
C'est historique (connaissance organisationnelle)
Tokenmaxxing (métriques et ROI de l'IA)
L'IA ne remplace pas les juniors (formation et transmission)