Imaginez un monde parallèle : votre expérience tourne encore, la date limite de la première version de votre article est arrivée, et vous décidez d'écrire d'abord le chapitre des résultats.
Premier scénario : les chiffres ne sont pas encore disponibles, vous comblez avec des « valeurs estimées » en pensant les remplacer une fois l'expérience terminée. Puis la durée de l'expérience s'allonge, vous changez deux jeux de paramètres, et vous oubliez de modifier les anciens chiffres dans le chapitre des résultats — ils se retrouvent dans la version soumise.
Deuxième scénario : vous demandez à l'IA de « vous aider à générer une analyse de résultats qui semble plausible ». Le texte est très fluide, mais il n'est étayé par aucune donnée, il est fait d'affirmations fortes et creuses d'un bout à l'autre ; dès qu'on lance un rapport anti-IA, ce chapitre vire au rouge sur toute la ligne.
Troisième scénario : vous êtes le plus diligent et vous rédigez toutes les analyses imaginables. Le jour où les données expérimentales arrivent vraiment, vous constatez que les résultats réels ne correspondent pas à la structure anticipée — deux chapitres sont à reprendre de zéro.
Trois mondes parallèles, une même source d'erreur :le chapitre des résultats a été placé à un moment qui n'est pas le sien.
La bonne chronologie : data_needed monte la garde pour vous
Dans le plan de rédaction de muchsci Paper Sailor, il y a une étape : lors de la génération du plan, indiquer, chapitre par chapitre, ceux quine dépendent pas de données— revue de littérature, cadre théorique, peuvent être rédigés d'abord ; ceux quidoivent contenir de vrais résultats— à marquer data_needed, en attendant l'expérience.
Après l'annotation, votre ordre de rédaction devient automatiquement logique : remplir d'abord tout ce qui peut l'être, conserver la structure des chapitres en attente de données et laisser des espaces réservés —et ces espaces réservés ne remplissent jamais automatiquement de chiffres, cette règle est gravée dans le produit muchsci. Une fois les données disponibles, il suffit de les réinjecter, sans reprise.
Liste d'actions des lacunes : la base de la planification des expériences
Les marqueurs data_needed rassemblés forment une liste d'actions : le chapitre 4 nécessite les résultats d'une expérience contrôlée avec deux groupes A/B, statut « en attente d'expérience » ; le chapitre 3 dispose d'un appui documentaire suffisant, terminé ; le chapitre 5 nécessite le retour des questionnaires, planifié.
La valeur de cette liste dépasse la rédaction — elle donne une base à la planification des expériences : quelles données sont sur le chemin critique, lesquelles peuvent être collectées en parallèle, tout est clair d'un coup d'œil. Mieux vaut exposer les lacunes tôt que la veille de la remise.
Dans le monde réel, il n'existe pas d'univers parallèle pour procéder par essais et erreurs, mais vous pouvez laisser le mécanisme de muchsci écarter tous les mauvais scénarios à votre place. En rendant claires les dépendances aux données de chaque chapitre, rédaction et expérimentation peuvent avancer en parallèle sans se contredire — c'est l'organisation la plus rentable en rédaction d'article scientifique.