Se reposer entre les notes

lundi 12 octobre 2026

Il y a quelque temps, j’ai regardé une vidéo qui m’est restée en tête particulièrement longtemps. C’était une conférence donnée à Prodacity 2026 par Kent Beck, qui a créé l’Extreme Programming et popularisé le TDD dans le monde entier. Elle s’intitulait « Software Engineering in the Age of AI ». Il s’agissait de se demander ce que veut dire bien construire un logiciel, maintenant que l’IA écrit une bonne partie du code. Dans cette intervention d’un peu plus de 52 minutes, ce qui m’a le plus marqué, ce sont deux mots, et la courte anecdote d’un violoncelliste.

Beck décrivait le développement logiciel selon deux axes : les features et les futures. D’un côté, les fonctionnalités que nous développons ; de l’autre, les options dont nous disposons pour modifier ce logiciel à l’avenir, autrement dit sa marge d’évolution (optionality). D’après lui, un projet part d’un état où il n’a encore aucune fonctionnalité, mais des possibilités infinies, et chaque fonctionnalité développée réduit les futures. À force de ne faire qu’empiler des fonctionnalités, disait-il, on se retrouve avec un logiciel mort, où il devient difficile de toucher à quoi que ce soit : un logiciel dont les futures valent zéro.

Graphique des features et des futures dessiné par Kent Beck, à 25 min 45 s de la conférence. En rouge, quand on ne fait qu’empiler des fonctionnalités ; en vert, quand on alterne fonctionnalités et remise en ordre (source : chaîne YouTube de Rise8)

C’est un peu ce que j’avais déjà ressenti sur le terrain, en tant qu’ingénieur : l’importance du refactoring. Même en plein développement d’une fonctionnalité, je refactorais au passage ce qui pouvait être amélioré, et quand il me restait un petit moment avant d’attaquer la fonctionnalité suivante, j’en faisais aussi un temps de refactoring. Mais à un moment donné, je me suis mis à demander à l’IA d’écrire tout le code de A à Z, et je me suis dit que, depuis, je laissais filer le « temps du refactoring ». Quand je développe une fonctionnalité, je prévois bien plusieurs harness (des dispositifs qui corrigent le travail de l’IA, comme les tests, le lint, les hooks, les prompts qui fixent des contraintes et les agents de vérification), mais je me suis rendu compte que je ne faisais pas de « travail de pur refactoring ».

Je me suis aussi beaucoup retrouvé dans ce que Beck a dit ensuite, en substance : autrefois, il fallait cent personnes et dix ans pour arriver à des futures à zéro ; aujourd’hui, grâce à l’IA, une seule personne peut créer un bazar complet en une semaine. Je ne peux pas entrer ici dans les détails, mais pendant toute la conférence, les erreurs et les tâtonnements par lesquels j’étais passé en cours de route venaient un à un se superposer au dessin de Beck. Avec le recul, il me semble que j’avais complètement oublié à quel point le cool-down entre deux fonctionnalités compte.

En expliquant comment faire autrement, Beck a évoqué une anecdote sur le violoncelliste Pablo Casals. Il l’avait entendue dans sa jeunesse, disait-il, quand il étudiait la guitare classique en faculté de musique. Le violoncelle est un instrument très physique, et dans l’un des morceaux que jouait Casals, il y avait, paraît-il, un passage où les doubles croches s’enchaînaient sans fin. Quand quelqu’un lui a demandé s’il ne se fatiguait pas à jouer toutes ces doubles croches, Casals a répondu : « Non, je me repose entre les notes. » En réalité, Casals n’aurait jamais dit cela : l’histoire serait inventée. Mais c’était une trop bonne histoire pour ne pas la raconter, a ajouté Beck.

Elle a beau être inventée, cette histoire de repos entre les notes m’a rappelé une chose : même dans le travail avec l’IA, qui avance à un tempo rapide, il faudrait « ce temps où l’on replace ses mains et reprend son souffle pour jouer la note suivante avec précision », c’est-à-dire un « temps de remise en ordre ». Le « temps du refactoring » dont je parlais plus haut, c’était exactement cet espace entre les notes. Il faut remettre de l’ordre régulièrement entre les fonctionnalités pour obtenir un logiciel à la fois souple et extensible : c’est la base, tous les développeurs le savent. Mais j’ai l’impression que c’est justement maintenant, alors que les fonctionnalités pleuvent, qu’il faut revenir à cette base. Tout comme Casals se reposait même entre des doubles croches sans fin, ne faudrait-il pas glisser, entre des features développées à toute vitesse, du refactoring et une remise en ordre des cas de test ? La comparaison de Beck, « on ne peut pas essuyer le couteau en coupant, mais le couteau, il faut l’essuyer », m’a elle aussi parlé d’emblée.

Les traces de cette course sans remise en ordre ne se limitaient pas au code : elles étaient là aussi, telles quelles, sur mon MacBook. Une fois passée une période où le travail s’enchaînait sans relâche, j’ai eu un petit temps mort, et j’ai vu des choses qu’on ne remarque qu’en s’arrêtant. Faute d’avoir pris le temps de remettre de l’ordre, des worktrees git et des conteneurs de base de données s’entassaient un peu partout, et l’espace de stockage restant était presque épuisé. Si je m’étais lancé directement dans la tâche suivante, l’espace libre serait peut-être tombé à zéro à un moment ou à un autre, et tout se serait arrêté. Ce n’est qu’après avoir supprimé un à un tout ce qui s’était accumulé que mon MacBook a retrouvé assez de marge pour accueillir le travail suivant. Lui aussi a ainsi récupéré, en quelque sorte, un peu de ses futures.

Il y a peu, je suis allé sur l’île de Jeju avec ma famille. De ce voyage, ce qui me reste le plus, c’est le lever de soleil à Seogwipo. J’ai beaucoup aimé ce moment où, levé de bonne heure, je regardais le soleil monter. Les nuages pommelés qui tapissaient tout le ciel se teintaient d’orange en partant du bas, et le soleil pointait peu à peu derrière la silhouette des palmiers.

Lever de soleil à Seogwipo

Curieusement, depuis notre retour, l’ambiance du matin a changé du jour au lendemain chez nous. Se lever tôt pour commencer la journée est devenu, sans que nous nous en rendions compte, le rythme de la maison, et je sens que, grâce à ça, notre santé s’améliore elle aussi peu à peu. Pour notre famille, ce voyage aura été, en somme, une remise en ordre entre les notes. Quand j’y pense, il me semble que nos vies ne sont pas si différentes d’un logiciel. Au travail comme dans la vie de parent, les journées filent à toute allure vers la feature suivante ; sans remise en ordre entre deux, est-ce que les futures de nos vies ne se consumeraient pas, là aussi, peu à peu ?