Plot est en accès anticipé : entre le moment où quelqu’un se heurte à un mur en écrivant et celui où nous le voyons, il se passe des heures, pas des trimestres. Cette boucle de retours est ce qu’il y a de mieux quand on construit au grand jour. C’est aussi un piège : si vous livrez ce que réclame la demande la plus bruyante, vous finissez avec un tas de fonctionnalités et pas de produit. Voici le regard que nous adoptons à la place.
Nous trions les retours selon ce qu’ils révèlent, pas selon ce qu’ils demandentLien vers cette section
Une demande de fonctionnalité est une réponse. Notre travail consiste à retrouver la question. Quand quelqu’un demande un bouton, ce bouton est sa solution à un problème qu’il ressent – et souvent le problème est réel alors que le bouton proposé n’est pas la meilleure solution. Chaque retour est donc lu deux fois : une fois pour la demande littérale, une fois pour la friction qu’elle signale.
- Qu’essaie vraiment de faire cette personne ? Pas la fonctionnalité, mais l’objectif derrière.
- À quelle fréquence cela revient-il, et chez combien de personnes différentes ? Une demande marquante est un point de données ; cinq demandes discrètes dans le même domaine forment une tendance.
- La solution s’accorde-t-elle avec les fondations, ou les combat-elle ? Les meilleures modifications découlent du contrôle de version, des documents structurés et des skills. Celles qui combattent ces fondations sont des signaux d’alerte.
- Que coûte-t-elle au reste du produit ? Chaque fonctionnalité est aussi de la surface – quelque chose à maintenir, à expliquer et à garder hors du chemin de tous les autres.
Les fondations servent de filtreLien vers cette section
Inkwell repose sur des fondations précises : les documents sont des données structurées, l’historique est une suite de points de sauvegarde immuables, et l’IA fonctionne sous forme de skills dont on relit le travail. Les demandes qui s’accordent naturellement avec ces fondations sont peu coûteuses et durables. Celles qui obligent à les contourner sont chères et fragiles – et signalent en général que la demande ou notre modèle n’a pas la bonne forme.
Concrètement, « laissez-moi comparer côte à côte deux versions de lecture à la table » s’accorde avec elles – ce n’est qu’une comparaison entre deux points de sauvegarde, que les fondations rendent déjà précise. « Laissez-moi modifier librement le PDF mis en page et le resynchroniser » les combat, parce que le PDF est un rendu de données structurées, pas la source de vérité. Même élan du côté de l’auteur ; coût et durabilité très différents. Nous disons oui vite au premier type, et lentement, prudemment, au second.
À quoi ressemble cet ordre aujourd’huiLien vers cette section
L’éditeur structuré et l’analyseur de scénarios sont venus en premier, parce que chaque capacité ultérieure a besoin d’un brouillon qu’elle comprend. Le contrôle de version a suivi : points de sauvegarde, lignes de brouillon, suivi sémantique des modifications et intégration. Les passes sur les dialogues, les vérifications de continuité et les fiches de lecture travaillent ensuite sur ces mêmes brouillons structurés au lieu d’en créer une seconde copie à côté. Canvas étend ces fondations aux documents généralistes, tandis que le travail de production fait passer Plot par la séquence des couleurs de révision de la WGA, les pages verrouillées, les pages A et les exports de livraison. L’avantage pour l’auteur, c’est la continuité : une version de lecture à la table, une passe de la réalisation et une remise à la production restent des moments d’un même historique, que l’on peut parcourir. Consultez la page À propos pour l’état actuel des livraisons.
Un rythme régulier plutôt que de grands lancementsLien vers cette section
Comme l’équipe est petite et la boucle courte, nous préférons des versions fréquentes et ciblées à des versions rares et massives. Une version ciblée est facile à comprendre, facile à annuler et facile à relier aux retours qui l’ont motivée. Elle garde aussi la prochaine version tournée vers le travail de la semaine suivante : si une modification ne peut pas se décrire en une phrase et sortir en une ou deux semaines, elle demande en général à être découpée d’abord en plus petits morceaux.
C’est toute la méthode, et elle est volontairement sans éclat. Lisez les retours pour y trouver la question, pas la réponse. Privilégiez les modifications qui découlent des fondations. Livrez petit, livrez souvent, et gardez la surface sous contrôle. Cela ne produira pas la plus longue liste de fonctionnalités des logiciels d’écriture de scénario. Cela doit produire un outil qui aura encore du sens dans un an.