5 reframes du software craftsmanship qui transforment le pilotage d’une équipe tech

Le mois dernier, lors de la conférence Bretzel Craft à Strasbourg, je pensais assister à une journée entre passionnés de code. Je suis reparti avec une conviction : les équipes qui maîtrisent le craft creusent un écart décisif en termes de performance et de durabilité.

Le terme software craftsmanship évoque souvent des pratiques d’ingénierie : TDD, refactoring, pairing, code review exigeante. Pourtant, ce qui m’a frappé lors des talks, ce n’est pas tant la technicité des pratiques que les changements de perspective qu’elles impliquent.

Chaque pratique de craftsmanship porte une manière différente de penser la performance : comment on mesure la qualité, comment on réduit les risques, comment on accélère sans sacrifier l'avenir du produit. Le craftsmanship n’est pas seulement une affaire de développeurs, mais également une manière pour les leaders techniques de construire des équipes capables d’allier vitesse, fiabilité et durabilité.

Voici les cinq reframes les plus structurants de cette journée: cinq changements de perspective susceptibles de transformer la manière dont vous accompagnez votre équipe vers l'excellence.

‍

‍

1. Le craftsmanship n’est pas seulement mieux argumenter, mais aussi créer l’espace pour d’autres perspectives

La keynote d’ouverture, portée par Houleymatou Baldé, cofondatrice de Yeeso, une association engagée pour plus d’équité dans l’IT, racontait un parcours improbable : d’une enfance sans scolarisation à ingénieure en France, puis personnalité reconnue du numérique.

Elle y décrivait les difficultés à trouver sa place dans un milieu où, souvent, ceux qui parlent le plus fort finissent par orienter les décisions.

Dans les environnements techniques, ceux qui argumentent vite et maîtrisent le vocabulaire, influencent naturellement les choix d’architecture et les arbitrages structurants.

Or, une équipe où seules quelques voix dominent produit des angles morts. Sans la confrontation des expériences, des doutes et des perspectives divergentes, certaines hypothèses restent implicites jusqu’à ce qu’elles deviennent des incidents. L’accessibilité en est un exemple : rarement priorisée en comité d’architecture, elle peut pourtant devenir décisive pour la viabilité d’un produit.

‍

Garantir des espaces de discussion où chacun peut contribuer est un impératif de robustesse pour tout leader technique. Structurer ces échanges en s’appuyant sur un ADR préparé en amont, qui sert de base factuelle et explicite, permet d’éviter que les décisions ne reposent uniquement sur des opinions ou des biais implicites.

Le rôle du manager consiste alors à créer les conditions pour que chacun, experts comme contributeurs moins expérimentés, puisse formuler un point de vue argumenté. On passe ainsi d’une discussion dominée par quelques voix à une décision collective assumée.

‍

2. L’IA est extrêmement performante, mais elle ne suffit pas.

J’ai participé à un atelier dans lequel nous devions comprendre le comportement d’un programme à partir d’un simple tableau de bytes.

Pas de code source. Pas de documentation. Juste un binaire C.

L’animateur était persuadé que l’IA ne pourrait rien en tirer.

Pourtant, en quelques itérations, plusieurs agents (y compris des versions standards de Claude ou Codex) ont convergé vers la construction d’un désassembleur capable d’expliquer le programme.Coût total de l’analyse la plus aboutie : environ 50 € (Claude Opus 4.6)

L’exercice était impressionnant, mais il nous a montré que désassembler du binaire n’est pas comprendre un système.

Comprendre un système, c’est :

• identifier la valeur business qu’il porte,
• repérer ses limites structurelles,
• anticiper ce qui est modifiable ou non,
• traduire ces contraintes auprès de parties prenantes non techniques.

Si l’IA peut générer du code, produire des tests, et accélérer l’exploration de code existant, la valeur des développeurs se déplace vers le jugement : formuler les bonnes hypothèses, identifier les risques implicites, arbitrer entre vitesse et maintenabilité.

‍

Cela suppose un principe simple : aucune affirmation générée par une IA ne doit être acceptée sans validation déterministe. Cette validation commence par une revue rigoureuse du code produit, en particulier des tests générés par l’IA : si ceux-ci sont faux ou incomplets, c’est l’ensemble du produit qui se retrouve fragilisé.

Une équipe qui se contente d’utiliser l’IA pour aller plus vite produira du volume; mais sans discernement humain, personne ne pourra répondre lorsqu’il faudra expliquer le lien entre un système complexe et la valeur business qu’il est censé servir.

‍

3. Utiliser l’IA n’est pas coder, c’est déléguer.

J’ai longtemps peiné à intégrer l’IA dans mon propre workflow. Non pas parce qu’elle était inefficace, mais parce qu’elle ne codait pas “comme moi”. Les choix de nommage, l’organisation des fonctions, certains arbitrages de structure ne correspondaient pas à mes habitudes. J’avais l’impression de perdre la maîtrise.

Un échange lors du déjeuner a changé ma perspective : utiliser l’IA, ce n’est pas être remplacé. C’est déléguer.

Déléguer implique d’accepter que le résultat ne soit pas identique à ce que l’on aurait produit soi-même, tout en garantissant un bon niveau de qualité.

‍

Comment est-ce qu’un responsable technique peut s’assurer que ses équipes sont dans les bonnes conditions pour déléguer ? Tout d’abord s’assurer que chacune ait des standards explicites, documentés sous forme d’instructions pour agents.

Ces instructions, plutôt que d’énumérer des prescriptions détaillées, doivent clarifier des principes structurants : conventions de nommage, contraintes d’architecture, exigences de testabilité. L’objectif n’est pas de décrire chaque ligne de code attendue, sinon, à vouloir tout contrôler, on finit par saturer le contexte des modèles et réduire leur efficacité.

‍

4. Optimiser son environnement est un geste de préservation.

Deux étudiants d’Epitech présentaient leur environnement de travail. Claviers divisés, configuration avancée, raccourcis maîtrisés à la perfection grâce à la mémoire musculaire. À un moment, l’un d’eux corrige un bug les yeux fermés, uniquement au clavier. C’était épatant.

On pourrait y voir dans cette démonstration une quête de performance. En réalité, il ne s’agissait pas de vitesse, ni d'une envie d’impressionner, mais d'une recherche de confort.

Dans un quotidien saturé d’interruptions (Slack, pull requests, incidents, IA), chaque friction inutile consomme de l’attention. Changer de fenêtre, chercher une commande, répéter une action mécanique, tout ça a un coût. Prises isolément, ces frictions sont invisibles, mais accumulées, elles épuisent.

Or, une équipe cognitivement saturée ne prend pas les bonnes décisions à temps. Aider une équipe, c’est donc aussi s’assurer que chaque membre ait un environnement de travail adapté. Le temps dédié à améliorer cet environnement est aussi précieux que le temps dédié à la qualité de code. La vitesse est un effet secondaire.

Vous ne savez pas par où commencer ? Bonne nouvelle ! Ces deux évangélistes de l’ergonomie ont créé un site qui recense des outils et des configs pour améliorer l’espace de travail d’un développeur, que ce soit sur Linux, Mac ou Windows.

‍

5. Le TDD n’est pas lent, mais il donne l’impression de l’être.

L’atelier s’intitule “TDD au-delà de l’intro”, animé par Romeu Moura.

Deux heures consacrées à FizzBuzz. Oui, deux heures sur FizzBuzz.

Chaque ligne était commentée, chaque geste disséqué, chaque décision analysée. Je vous partage mes deux apprentissages préférés:

Le premier explique pourquoi tant d’équipes abandonnent le TDD.

Pour citer Romeu:

Les humains aiment la sensation de vitesse, pas la vitesse réelle.Un kart donne l’impression d’aller vite.L’avion est objectivement plus rapide.Le TDD est l’avion.

Le deuxième, c’est la raison pour laquelle le TDD est si rapide:

L’hésitation coûte cher

En TDD, les phases RED et GREEN sont volontairement simplifiées: on écrit un test, puis le code minimal pour le faire passer. On ne cherche pas la perfection, l’objectif est d’autopiloter ces étapes autant que possible.

La réflexion profonde est réservée au refactoring.

Pourquoi ?

Parce que chaque microdécision (nommer un test, optimiser un algorithme, anticiper tous les cas) consomme de l’énergie cognitive. Multipliées sur une journée entière, ces hésitations fragmentent l’attention et ralentissent.

Un détail illustre parfaitement cette logique : pendant la phase RED, Romeu nomme ses tests  TODO_RENAME().

Provocateur ? Un peu. Mais cohérent.

L’objectif n’est pas de trouver le nom parfait dès le début — d’autant que le test sera peut être supprimé ou fusionné plus tard.L’objectif est de poser rapidement les bases d’une réflexion approfondie, sans saturer l’esprit.

La rigueur n’est pas abandonnée. Elle est juste déplacée au bon moment.

‍

Pour un manager, l’enseignement est qu’une équipe performante est celle qui structure ses moments de réflexion plutôt que de réfléchir en permanence à tout. Le TDD est plus un cadre pour protéger l’attention et réduire le coût cognitif des micro-arbitrages que doivent faire les développeurs au quotidien.

‍

Ce que le craftsmanship change quand on pilote une équipe

Ce que j’ai retenu de Bretzel Craft, ce sont des changements de perspective plus que des pratiques d’ingénierie.

Les équipes qui maîtrisent le craft ne sont pas plus performantes parce qu’elles écrivent “du code plus propre”, mais parce qu’elles travaillent différemment.

Elles créent de l’espace pour les discussions plutôt que de chercher les décisions rapides.

Elles traitent l’IA comme un levier qui déplace la responsabilité humaine sans l’effacer.

Elles protègent l’attention comme une ressource rare et structurent la réflexion plutôt que de l’imposer en continu.

Dans un monde dans lequel l’IA accélère la production de code, la différence se fera sur la qualité des systèmes construits, la clarté des décisions techniques, et la maturité des équipes qui les portent. C’est là que le rôle du manager et celui de l’artisan se rejoignent.

‍