Oiseau par oiseau : l'art de décomposer les grands projets créatifs

Il y a un vertige que connaissent tous ceux qui se sont un jour lancés dans un grand projet créatif : celui du sommet qu'on regarde depuis la vallée. Écrire un roman, concevoir un jeu, développer un logiciel — vu d'en bas, tout cela semble une masse compacte, intimidante, presque hostile. L'archevêque anglican Desmond Tutu (https://fr.wikipedia.org/wiki/Desmond_Tutu) répondit avec sagesse et facétie à cette étrange question : « Comment mange-t-on un éléphant ? » Et lui de répondre, imperturbable : « Une bouchée à la fois. » C'est une boutade, bien sûr. Mais comme souvent avec les boutades qui survivent aux siècles, elle cache un vrai savoir-faire. Aujourd'hui, j'aimerais parler de cet art discret qui conditionne presque tout le reste : l'art de décomposer les grands projets en morceaux qu'une personne normale, avec des journées de vingt-quatre heures, peut réellement accomplir.

Descartes avait (presque) tout dit

On présente parfois la décomposition des problèmes comme une trouvaille récente de la gestion de projet. C'est oublier qu'elle figure en toutes lettres dans le Discours de la méthode de Descartes, publié en 1637. Le deuxième de ses quatre préceptes est limpide : diviser chacune des difficultés examinées « en autant de parcelles qu'il se pourrait, et qu'il serait requis pour les mieux résoudre ». Le troisième précepte complète le geste : conduire ses pensées par ordre, en commençant « par les objets les plus simples et les plus aisés à connaître », pour monter « peu à peu, comme par degrés, jusques à la connaissance des plus composés ».

Diviser, puis ordonner du simple vers le complexe : voilà le cœur de la méthode, énoncé il y a près de quatre siècles. Ma formation histoire m'a donné le goût de ces textes fondateurs, et je suis toujours frappé de voir à quel point ils décrivent avec précision nos pratiques d'aujourd'hui. Car ce que Descartes appliquait à la recherche de la vérité, nous l'appliquons, plus modestement, à la fabrication de nos histoires et de nos programmes.

Ce que le code m'a appris

Je suis venu à la programmation par des chemins de traverse, et elle m'a offert un cadeau que je n'attendais pas : elle m'a appris, concrètement, à décomposer un problème énorme en sous-problèmes accessibles. Pas comme un principe abstrait qu'on approuve poliment, mais comme une discipline quotidienne, imposée par la machine elle-même. Un ordinateur n'accepte pas les intentions vagues. Il n'exécute que des instructions précises, petites, ordonnées. Pour lui faire faire quelque chose de grand, on n'a pas le choix : il faut découper.

Les informaticiens ont même donné un nom à cette stratégie : « diviser pour régner ». Nombre d'algorithmes classiques, comme le tri fusion, fonctionnent exactement ainsi : on coupe le problème en deux, on résout chaque moitié (en la coupant elle-même en deux, et ainsi de suite), puis on recombine les solutions. La leçon dépasse largement l'algorithmique. Une fonction bien écrite fait une chose, et une seule ; un module regroupe des fonctions qui vont ensemble ; un logiciel assemble des modules. À chaque étage, la complexité reste à taille humaine. Personne ne « comprend » un grand logiciel d'un seul regard — mais chacune de ses briques, oui.

Or un roman, vu sous cet angle, ressemble beaucoup à un système : des personnages qui sont autant de sous-systèmes avec leurs états et leurs trajectoires, des scènes qui sont autant de fonctions avec leurs entrées et leurs sorties, des fils d'intrigue qui s'appellent les uns les autres. Je ne pousse pas la métaphore jusqu'à l'absurde — un chapitre n'est pas une fonction, et heureusement. Mais le geste mental est cousin : face à l'énormité, chercher les articulations naturelles, et couper là où ça s'articule.

La méthode flocon : grossir plutôt que découper

En matière d'écriture romanesque, la décomposition la plus célèbre est sans doute la « méthode du flocon de neige » (snowflake method). Le concept est le suivant: plutôt que de partir de la masse et de la découper, on part du minuscule et on le fait grossir. On commence par résumer son roman en une seule phrase. Puis on développe cette phrase en un paragraphe. Puis chaque élément du paragraphe en une page. On rédige des fiches de personnages, un synopsis étoffé, une liste de scènes — chaque étape reprenant la précédente pour lui ajouter un niveau de détail.

Le nom vient des flocons fractals de Koch, ces figures géométriques qu'on construit en ajoutant indéfiniment des triangles sur les côtés d'un triangle : la forme se complexifie à chaque itération, mais elle reste à tout moment complète et cohérente. C'est exactement ce que j'aime dans cette approche : à aucun moment on ne se retrouve avec un tas de fragments sans forme. On possède toujours une version entière de son histoire — d'abord ridiculement petite, puis de plus en plus riche. La décomposition ne se fait pas par démembrement, mais par raffinements successifs. C'est, au fond, très proche de ce qu'on appelle en développement logiciel l'approche itérative : livrer tôt quelque chose de complet mais rudimentaire, puis enrichir.

Architectes et jardiniers

Une objection légitime se lève ici : tout le monde n'écrit pas avec des plans. George R. R. Martin a proposé une distinction restée célèbre entre deux familles d'écrivains : les architectes, qui dessinent leurs plans avant de poser la première pierre, et les jardiniers, qui plantent une graine, l'arrosent, et découvrent en même temps que leur récit la forme qu'il va prendre. Martin se range lui-même plutôt du côté des jardiniers — et personne ne songerait à dire que ses intrigues manquent d'ampleur.

Faut-il en conclure que la décomposition est réservée aux architectes ? Je ne crois pas. Les jardiniers décomposent aussi, mais autrement : non pas la structure de l'œuvre, mais le processus de travail. Écrire une scène aujourd'hui. S'asseoir chaque matin devant la page. Laisser le plan émerger de la pratique plutôt que la précéder. La bouchée d'éléphant n'est plus « le chapitre 12 tel que prévu dans le plan », mais « ma séance d'écriture de ce matin ». Dans les deux cas, on a remplacé une tâche impossible — « écrire un roman » — par une tâche faisable aujourd'hui. C'est cela, la vraie ligne de partage : non pas plan ou absence de plan, mais tâche accessible ou tâche écrasante.

Bird by bird

Sur cette question de la tâche accessible, il existe un livre que je trouve précieux : Bird by Bird d'Anne Lamott, publié en 1994 (traduit en français sous divers titres, dont Mot après mot). Le titre vient d'une anecdote familiale que raconte l'autrice : son frère, âgé de dix ans, devait rendre un exposé sur les oiseaux qu'il avait eu trois mois pour préparer — et qu'il n'avait pas commencé. La veille de la remise, paralysé devant l'ampleur de la tâche, il était au bord des larmes. Leur père s'est alors assis près de lui et lui a donné ce conseil devenu proverbial : « Oiseau par oiseau, mon grand. Prends-les simplement oiseau par oiseau. »

Toute la méthode d'écriture de Lamott découle de là. Elle recommande les « short assignments », les petites missions : ne jamais s'asseoir pour « écrire son livre », mais pour écrire un tout petit morceau qu'on peut se représenter entièrement. Elle garde, dit-elle, un cadre photo de quelques centimétres sur son bureau, pour se rappeler qu'elle n'a besoin de voir, à chaque instant, que ce qui tient dans ce petit cadre : une scène, un souvenir, un échange. Ce n'est pas une technique de gestion de projet, c'est presque une hygiène mentale — une façon de tenir l'angoisse à distance en réduisant le champ de vision jusqu'à ce que la tâche redevienne attaquable.

La tranche verticale, ou l'art de finir un petit morceau en entier

Le monde du jeu vidéo a développé son propre vocabulaire de la décomposition, et l'une de ses notions me semble utile bien au-delà du jeu : la « tranche verticale » (vertical slice). Quand un studio veut prouver — à un éditeur, ou à lui-même — que son jeu tient debout, il ne construit pas tous les systèmes à moitié. Il fabrique un petit fragment du jeu, parfois quelques minutes seulement, mais fini de haut en bas : les mécaniques jouables, les graphismes aboutis, le son, l'interface. Une tranche du gâteau qui traverse toutes les couches, plutôt qu'une fine couche étalée sur tout le gâteau.

L'intérêt est double. D'abord, on apprend le coût réel des choses : tant qu'on n'a pas mené un morceau jusqu'au bout, toutes les estimations sont des fictions optimistes (et ma vie de dev me le rappelle de façon récurrente). Ensuite, on obtient très tôt un objet qui existe, qu'on peut montrer, éprouver, corriger. Transposé à l'écriture, cela donne un conseil que je trouve fécond : plutôt que d'avoir cinquante chapitres esquissés, en finir vraiment un — réécrit, poli, mené à la qualité qu'on vise. Ce chapitre-là vous apprendra plus sur votre livre que tous les synopsis du monde.

Les limites de la découpe

Un mot de prudence, tout de même, car tout outil a son revers. On peut mourir de trop découper. Une liste de quatre cents micro-tâches est aussi paralysante qu'un projet monolithique — elle a seulement changé de forme d'écrasement. Et surtout, la carte n'est pas le territoire : un plan, aussi fin soit-il, n'est qu'une hypothèse sur l'œuvre à venir. Les meilleurs morceaux d'une histoire sont souvent ceux qu'aucun plan n'avait prévus, ceux qui surgissent en cours de route parce que l'écriture elle-même est une découverte. La décomposition doit rester une servante, pas une maîtresse : elle sert à rendre le travail possible, jamais à le rendre prévisible. Quand un découpage ne correspond plus à ce que le projet est devenu, c'est le découpage qu'on jette, pas le projet. Par expérience, j'ai appris à découper les choses que je souhaite faire pour pouvoir les aborder, mais par expérience aussi je sais que tout mes plans ne résistent pas toujours à la confrontation avec le réel. Parfois, je peste parce que j'introduis un nouvel élément qui donne une inflexion à la suite de l'histoire. Parfois, pire, la nouvelle idée implique des corrections en amont. Le plan n'est pas figé, il doit pouvoir s'adapter à l'envie ou à l'inspiration du moment.

Une bouchée, puis l'autre

S'il fallait résumer tout cela d'une formule, je dirais : on ne crée jamais une grande chose, on crée une longue suite de petites choses honnêtes, et un jour, en se retournant, on découvre qu'elles forment une grande chose. C'est une conception artisanale de la création — l'établi plutôt que l'éclair de génie — et c'est celle dans laquelle je me reconnais.

J'ajouterais que certaines formes rendent cette vérité littéralement visible. Un livre dont vous êtes le héros, par exemple, est une histoire qui assume sa nature de structure : des sections numérotées, des choix, des chemins qui se séparent et se rejoignent — un graphe qu'il faut bien, pour l'écrire, décomposer nœud par nœud. C'est un des plaisirs particuliers que j'ai trouvés dans ce format, où l'architecte et le jardinier sont condamnés à collaborer.