Tech Teardown 022｜wordcraft : une personne et un groupe d'agents ont « recréé » un Word en cinq jours

Le stockage a eu lieu le 7 octobre, et en cinq jours, plus de 6000 étoiles ont été collectées. C’est le résultat des efforts de storytold/wordcraft sur GitHub. Mais ce n’est pas un cas isolé : la même organisation a réalisé en deux semaines une réimplementation complète de Photoshop, Lightroom, Premiere, Acrobat, Illustrator, Excel, PowerPoint, AutoCAD. Le projet photocraft a atteint 48 000 étoiles, tout écrit en Rust, et tous sont dénommés “clean-room reimplementation”. Wordcraft est le membre de Word, dont la première ligne du README indique : “Une réimplementation open-source de Microsoft Word, réécrite en pure Rust”. Ce qui est vraiment intéressant, c’est sa méthode de production : les principaux contributeurs ont soumis 57 353 lignes de code ajoutées en trois jours, et les heures restantes sur la roadmap du projet sont comptabilisées directement comme “Opus 5.5 agent wall-clock hours”. En une semaine, le nombre de PR a atteint 581. C’est un exemple concret de production en masse de logiciels conformes avec des agents AI. Ce texte détaille cette réimplementation en six parties, selon la tradition.

Première partie : Qu’est-ce que c’est

wordcraft fait partie de la famille ArtCraft de traitement de documents. Son objectif est de fonctionner de manière similaire à Microsoft Word, mais avec un code entièrement réécrit. Il s’agit d’un projet important : le dépôt contient 428 fichiers, 280 sources en Rust, pour un total de 156 273 lignes (y compris les tests). Sa roadmap indique une autre quantité : 433 commandes, 855 tests et 10 blocs de propriétés, pour environ 88 700 lignes de code Rust. Les chiffres rapportés ne correspondent pas aux statistiques réelles, ce qui est typique de ce type de projet. Nous en parlerons plus en détail dans la quatrième partie.

L’architecture se divise en sept niveaux : le niveau inférieur concerne les calculs géométriques et les polices de caractères, le niveau supérieur comprend l’exploitation des formats de fichiers comme DOCX (supportant OOXML/ECMA-376), permettant la lecture de fichiers ODT, RTF, HTML, Markdown, LaTeX, texte brut, et même des fichiers .doc de la version 97-2003 de Word. Ensuite viennent le rendu et la sortie en PDF, puis le niveau des moteurs (conversations, annulations, registre des commandes), et enfin le serveur MCP et l’interface de bureau egui. Il existe trois formes de publication : application de bureau, outil en ligne de commande, et version web WASM.

«La salle pure» est la base de son fonctionnement. Les règles sont écrites dans le fichier AGENTS.md, elles sont assez strictes et contrôlantes : sur l’ordinateur de développement, il faut utiliser le version originale de Word, il est permis d’observer à travers des boîtes noires, de prendre des captures d’écran pour vérification, mais il est interdit de lire le contenu intérieur du paquet de installation de Word, ni de soumettre aucun produit issu de Word. Le format des fichiers doit respecter les normes publiques (ECMA-376, OASIS ODF 1.3, norme RTF) ; les noms des ressources ne doivent pas être copiés de code sous licence GPL comme LibreOffice, AbiWord ou pandoc. La discipline sur les ressources est également stricte : le fichier ATTRIBUTION.md exige que l’auteur, l’origine et la licence de chaque ressource non codée soient déclarées. Une erreur dans le check-up des assets par cargo xtask entraîne l’échec ; toutes les icônes doivent être créées en code, aucune icône Microsoft ne doit apparaître ; les polices utilisées doivent être des polices ouvertes (OFL-1.1). Les licences du code sont MIT ou Apache-2.0, tandis que les marques commerciales restent fermées.

Deuxièmement, pourquoi il est intéressant de lire maintenant

La salle pure vise à réinventer Office. Avant, seule LibreOffice avait emprunté cette voie, au prix d’années de travail et d’une lourde charge historique. Maintenant, c’est l’AI agent qui joue un rôle clé : réécrire Word selon les normes publiques permet de réduire le temps nécessaire à « une carrière d’un équipement » à « quelques semaines pour une personne et un groupe d’agents ». Le plan de travail de wordcraft montre cela clairement : tout le travail est facturé en heures d’agent. Pour atteindre la version beta, il faut 150 à 230 heures d’agent, et pour atteindre 95 % de finition, il faut 650 à 1100 heures ; les exemples cités montrent que « PR #191 nécessite 5 heures pour environ 9 700 lignes » ou « un lecteur de .doc prend environ 10 heures pour 4 500 lignes ». Personne ne peut écrire à cette vitesse, et le projet fonctionne selon un modèle de génération massif par les agents AI. L’auteur ne cache pas cela, et lors des discussions sur HN, on utilise même le terme « vibe-coded » pour décrire ce système.

Un autre aspect est lié aux émotions. La fatigue causée par les abonnements d’Adobe et Microsoft s’est accumulée au fil des ans. Dans les discussions sur HN, une opinion populaire est que « le bouclier de Adobe est trop petit, tôt ou tard quelqu’un reconstruira toute la suite Creative Suite à cause des prix ». Certains commentateurs affirment même avoir vendu Adobe immédiatement après avoir vu le projet (c’est une action personnelle, pas sérieuse). L’auteur lui-même est franc lorsqu’il apparaît sur HN : « Je n’étais pas prêt à publier cela sur HN. Ce n’est pas du tout prêt », c’était la phase alpha très précoce, avec une recrutement public de contributeurs, et des promesses de bourses et de récompenses pour les bugs.

Troisièmement, les mécanismes techniques fondamentaux

Ce qui vaut la peine d’être emporté, c’est le quatuor.

Premier point, tout est une commande. Chaque opération est un CommandSpec doté d’un id, et le même ensemble de commandes (422 selon le README, 433 selon la roadmap, avec des variations selon les itérations) s’exécute simultanément à travers six entrées : le menu de la barre de menu, les raccourcis du clavier, la recherche de commandes, les outils de ligne de commande, le canal de contrôle JSON, et le serveur MCP. Ajouter une fonctionnalité équivaut à enregistrer une commande, et ces six entrées s’appliquent automatiquement. Le README fait du “Built for agents” un point fort officiel, permettant aux agents de piloter l’ensemble de l’application sans dépendance au serveur MCP.

Deuxièmement, la discipline de ne jamais tomber en panne. Les codes non testés doivent éviter les erreurs panic, les instructions unsafe_code doivent être directement interdites ; il existe un test hostile_params_never_panic qui exécute toutes les commandes avec des paramètres invalides pour garantir une stabilité. Session::run transforme les erreurs panic en exceptions et rétablit l’état du document. La clause “ne jamais tomber en panne” est mentionnée dans AGENTS.md et prévaut sur les fonctionnalités. Pour les grandes quantités de code généré par l’IA, une telle protection globale est essentielle, ce n’est pas une question de propreté.

Troisièmement, la méthode d’observation du “salon propre”. Les règles mentionnées précédemment sont complétées ici par les détails d’exécution : seuls les formats conformes aux normes publiques sont acceptés, l’observation se fait uniquement avec des tests noirs (exécution, captures d’écran), et les contrôles de CI empêchent les références inter-étapes. Les zones juridiquement floues ne sont pas touchées, mais la pratique de “corriger l’UI en alignant avec les captures d’écran” est-elle une violation de l’apparence ? Certains ont déjà posé la question sur HN : “Microsoft va-t-il porter plainte ?” C’est une question suspendue au projet.

Quatrièmement, la mesurabilité de la parité. Cargo xtask parity génère une liste de fonctionnalités comparées à celles du Word. Dans la roadmap, le dossier ribbon couvre 481/496 (97,0 %) de ces commandes testées, pas juste imaginées ; le seuil minimum de tests ne peut être augmenté mais pas diminué. Toutes les étapes de qualité sont regroupées dans un cargo xtask ci :fmt, clippy avec -D warnings, tests, enregistrement des assets, contrôles hiérarchiques, construction WASM, tout doit être passé avec succès avant soumission.

Les pièces complémentaires méritent également attention. Au-dessus du noyau principal, les dossiers crates contiennent également des intégrations avec Zotero pour l’écriture académique, un contrôle orthographique hors ligne (sans connexion, sans diffusion du contenu), et un modèle de lecture en vozio au niveau de la phrase. Ces ajouts montrent que l’auteur a une conscience des exigences d’un “écosystème complet pour le traitement de documents”, et non seulement le noyau de mise en page. Il y a aussi une discipline dans la roadmap qui mérite d’être respectée : les dates de dernière révision et de dernière mise à jour sont indiquées en tête du document (Last reviewed 10-10, Last updated 10-11), avec indication si le chiffre est measured ou estimated à côté de chaque date. Cette clarté des données est rare dans un contexte où les documents générés par l’IA sont courants.

Quatrièmement, les chiffres et les limites

La combinaison des trois chiffres indiqués par les participants représente la frontière : le pourcentage de couverture du catalogue est de 97 % (selon mesures effectuées par des outils), la largeur des fonctionnalités est d’environ 80 % (estimation), et le niveau de “Prêt pour le travail réel” est d’environ 60 % (intervalle d’estimation de 55-63 %). Cependant, les chiffres du côté des utilisateurs sont plus faibles : la feuille de route indique 120 problèmes signalés par des utilisateurs externes, 4 critiques positives, 0 utilisateurs qui ont migré depuis Word, et environ 21 bugs non corrigés sur les routes principales. La distance entre 97 % de couverture du catalogue et 0 utilisateurs de migration correspond à la distance entre l’état alpha du produit et son réel état de développement.

Toutes les affirmations concernant les performances sont basées sur des estimations : “En tapant dans un document de 188 pages, le réarrangement du texte prend environ 1,4 millisecondes”, sans validation de tierces parties. Les deux chiffres indiqués pour le nombre de lignes (estimation de 88 700 vs mesures effectuées de 156 273, y compris les tests) montrent que l’ajout de contenu ne suit pas la vitesse de génération de code, ce qui est normal dans les projets où des agents génèrent un grand volume de code. La structure des contributeurs mérite également attention : le fichier contributors.json indique 45 contributions, avec une personne principale ajoutant 57 353 lignes par jour, tandis que les autres contributions sont de petits PR ; le répertoire présente une forme de “magasin de produits finis”, avec l’histoire compressée et le processus indiscernable. La maintenance à long terme avec une seule personne principale et des agents générant du code est une question importante.

Les commentaires sur HN sont variés. Les sceptiques disent qu’ils sont sceptiques, certains sont mécontents du besoin de s’inscrire et de se connecter pour essayer la version desktop, d’autres se plaignent que l’expérience avec le curseur de navigation “ne permet pas d’attendre un meilleur UX”, et certains remarquent que le répertoire principal utilise une licence fair source (différente des licences MIT/Apache utilisées par Wordcraft), posant la question de l’autorisation du fait que “le code AI est né dans le domaine public”. Les juristes se demandent si “le modèle de conception parental” peut présenter des risques, et certains demandent même si Microsoft intentera une action en justice contre Wordcraft pour répliquer la GUI. Seuls 3 commentaires ont reçu du soutien, mais la question reste sans réponse. Les enthousiastes louent la conception de la page, certains disent “il y a trois ans, on aurait été stupéfaits par quelque chose comme ça, maintenant nous sommes devenus insensibles à l’AI”, et d’autres pensent que la taille du projet “teste justement toutes les affirmations de vibe coding”. En regardant les deux côtés ensemble, la structure des divergences dans la section des commentaires et le fossé de consensus de Karpathy démontré cette semaine sont identiques : ceux qui ont eu affaire à cela et ceux qui n’y ont pas eu affaire tirent leurs conclusions en se basant sur leurs propres données.

V. Comment fonctionne-t-il ? Qui peut s’y entraîner ?

v0.4.0 (publié le 10 octobre) a déjà fourni des paquets d’installation pour toutes les plateformes : fichier DMG signé macOS, MSI pour Windows, AppImage et deb pour Linux, ainsi que Flatpak, paquet pour FreeBSD, et version WASM en ligne. Dans une semaine, nous mettrons à disposition les versions pour les sept plateformes, ce qui constitue également une démonstration de la capacité de production de l’agent : un projet traditionnel nécessiterait généralement plusieurs semaines de travail d’un ingénieur de publication. Ceux qui souhaitent lire le code ou contribuer peuvent cloner le projet et utiliser la commande cargo xtask ci pour vérifier toutes les qualités du code ; le fichier AGENTS.md est suffisamment détaillé, allant des règles de la salle blanche aux interdictions de panique et à l’enregistrement des ressources, et peut être utilisé comme modèle de spécifications pour le développement d’agents. Ceux qui souhaitent que les agents AI écrivent des documents peuvent simplement démarrer un serveur MCP. Les utilisateurs ordinaires sont invités à rester simplement spectateurs : il est admis que la roadmap propose encore environ 21 bugs de base, et il est trop tôt pour traiter sérieusement les documents avec ces bugs.

VI. Évaluation des valeurs et qui s’y prête

Répondons d’abord à la question liée au titre : il ne peut pas remplacer Word, et le fait qu’il n’ait aucun utilisateur de migration est la réponse. Mais en tant que modèle de projet pour « la production en grande quantité de logiciels conformes avec des agents AI », il a une grande valeur. Les quatre éléments suivants peuvent être directement copiés : discipline de la salle blanche (observation en boîte noire, respect des normes publiques, enregistrement de la trace des ressources), système de récupération globale contre les crashs, mesurabilité par parity (outil de comparaison de listes, limite inférieure des tests ne s’élève jamais), et une vérification complète des qualités du code avec une seule commande. Ces quatre éléments sont indépendants du projet spécifique, et toute équipe utilisant des agents pour écrire le code peut les utiliser.

Cela convient à trois types de personnes : les ingénieurs qui écrivent le code avec des agents AI et qui imitent leurs règles de développement ; ceux qui se concentrent sur l’augmentation de la productivité en IA, car c’est un cas où « cinq mille lignes en trois jours » est possible ; ainsi que ceux qui veulent vérifier les affirmations de vibe coding, car leur roadmap divise clairement « couverture des catégories », « largeur des fonctionnalités » et « utilisation dans le travail réel » en trois critères distincts, indiquant également ce qui est testé avec des outils et ce qui est estimé. Cette honnêteté en elle-même fait partie de l’exemple.

Concernant les risques : il reste des questions non résolues sur le domaine juridique (la réplique de l’interface utilisateur pourrait-elle être poursuivie en justice, personne ne donne de réponse), la durabilité de la maintenance du code par un seul développeur avec des agents est discutable, et il y aura toujours une différence entre les déclarations officielles et les résultats réels. C’est plutôt comme un registre expérimental public : quel devrait être le logiciel de développement dans l’ère des agents AI ? Ce repository a déjà écrit une partie de la réponse. Une autre partie de la réponse ne sera disponible qu’après que le projet aura survécu à l’étape alpha, et la plupart des projets similaires ne survivront pas à cette étape. C’est aussi pour cette raison que cet exemple mérite d’être suivi.

Source d’information

• Références de dépôts et de documents : README, ROADMAP, AGENTS.md, NOTICE, ATTRIBUTION.md, contributors.json sur github.com/storytold/wordcraft (clonage local pour visualisation, nombre de lignes de code mesuré par wc -l).
• Nombre de stars et classements familiaux : API de recherche GitHub, snapshot du 12-10-2026.
• Discussions sur HN : news.ycombinator.com/item?id=49958850 et quatre autres articles, extraits de l’API Algolia, les commentaires sont uniquement des résumés.
• Nombres de performance, couverture et niveau de completion : Informations fournies par le projet, le texte est marqué localement à chaque endroit.