Payer un abonnement pour Word, Excel et PowerPoint, ou essayer des alternatives gratuites capables d'ouvrir les mêmes fichiers : l'idée n'est pas nouvelle. La différence, aujourd'hui, c'est la vitesse à laquelle on peut construire une suite bureautique complète avec l'aide d'un modèle d'intelligence artificielle.
Brandon Thomas, à l'origine du projet ArtCraft - des applications inspirées de logiciels Adobe - a publié WordCraft, GridCraft et DeckCraft : des alternatives à Word, Excel et PowerPoint. Ces outils sont gratuits, open source et développés avec l'aide de Claude, le modèle d'Anthropic. Le code est écrit en Rust, avec l'objectif de fonctionner sur plusieurs systèmes d'exploitation et aussi dans un navigateur.
Sur le papier, les chiffres sont encourageants : WordCraft couvrirait 88 % des fonctionnalités du ruban de Word, et GridCraft prendrait en charge 513 des 523 fonctions de feuille de calcul d'Excel. Mais ces pourcentages ne suffisent pas à dire si les outils sont prêts à remplacer ceux de Microsoft en entreprise. Les développeurs eux-mêmes estiment leur niveau de préparation autour de 50 à 60 % pour des usages réels. En clair : couvrir des fonctions et garantir un comportement fiable au quotidien, ce n'est pas la même promesse.
Voici ce que ces clones font déjà, ce qu'ils ne garantissent pas encore, et ce que cette expérience dit du rôle de l'IA dans le développement logiciel.
Trois applications, un objectif commun
WordCraft, GridCraft et DeckCraft cherchent à reproduire des usages courants de la suite Microsoft Office, sans reprendre son code. Le projet est présenté comme une reconstruction « clean room » : les développeurs s'appuient sur des formats de fichiers publics et observent le comportement des applications d'origine, plutôt que de copier leur implémentation.
Cette distinction compte. Copier un logiciel et reproduire une interface ou un format ne revient pas à faire la même chose. Mais une approche de reconstruction ne règle pas tous les sujets juridiques. Noms commerciaux, marques, licences de composants et conditions de redistribution : tout cela mérite un examen séparé, surtout si l'outil vise un usage commercial.
WordCraft : la compatibilité avec les documents Word
WordCraft lit et enregistre des fichiers DOCX, le format utilisé par Microsoft Word. Selon Decrypt, l'outil couvrirait 88 % des fonctions du ruban. La liste inclut notamment le suivi des modifications, les notes de bas de page, les citations et le publipostage (pour personnaliser des documents à partir d'une liste de contacts).
Ces fonctions sont utiles, mais leur présence dans l'interface ne veut pas dire que tout sera parfaitement compatible. En entreprise, un fichier peut combiner styles, tableaux, en-têtes, commentaires, polices, sauts de section et éléments incorporés. Le test à faire est simple à dire, mais exigeant : vérifier l'affichage, la conservation de la mise en page après modification, et le résultat d'un aller-retour entre logiciels.
Le projet est aussi présenté comme encore en alpha. La feuille de route mentionne des tests sur des DOCX réels, la gestion de graphiques et de SmartArt après enregistrement, l'amélioration de la mise en page, la stabilité et l'impression « native ». En pratique : WordCraft peut être pertinent pour essayer ou pour des documents assez simples, mais ce n'est pas encore un remplacement « éprouvé » pour des fichiers sensibles.
GridCraft : presque toutes les fonctions, pas encore tous les classeurs
GridCraft, l'alternative à Excel, annonce la prise en charge de 513 fonctions de feuille de calcul sur 523, ainsi qu'environ 89 % des commandes du ruban. Les fonctions de tableur (comme SOMME ou RECHERCHEV, selon la langue et la configuration) comptent beaucoup pour la compatibilité. Mais le nombre de formules prises en charge ne raconte pas toute l'histoire.
Un classeur « réel » peut contenir des macros, des connexions de données, des tableaux croisés dynamiques, des règles de mise en forme, des noms de plages et des formules imbriquées. Il peut aussi dépendre de détails de calcul ou de présentation difficiles à résumer dans une liste de fonctions. Les développeurs estiment GridCraft à environ 50 % pour un usage réel, et indiquent que la compatibilité avec les fichiers XLSX existants reste un travail en cours.
C'est une limite importante pour une entreprise française qui s'appuie sur des modèles de trésorerie, des tableaux de suivi RH ou des fichiers transmis par des clients. Un classeur peut s'ouvrir sans erreur et donner un résultat différent. Le bon réflexe reste le même : comparer les résultats, les formats et les comportements sur des copies de fichiers représentatifs, pas uniquement se baser sur le chiffre des fonctions annoncées.
DeckCraft : la présentation arrive après les deux autres
DeckCraft vise les usages de PowerPoint. D'après l'article source, le projet annonce environ 79 % des fonctions générales et 93 % des fonctions jugées centrales. L'application ouvre et enregistre des PPTX, gère les transitions et les animations, et peut exporter en PDF.
Mais au moment de la publication, le logiciel n'avait pas encore atteint sa première version alpha. Les pourcentages décrivent donc une couverture fonctionnelle revendiquée, pas forcément une expérience validée sur des présentations complexes. Pour une équipe, les points à contrôler sont concrets : fidélité des polices, masques, animations, graphiques et qualité de l'export PDF.
Les trois applications sont écrites en Rust. Ce langage est pensé pour limiter certaines erreurs liées à la gestion mémoire et pour construire des logiciels natifs. Le projet indique qu'une base de code peut servir sous Windows, macOS, Linux et BSD, ainsi que dans un navigateur. Ça aide à la portabilité, mais ça ne garantit ni l'absence de bogues ni une équivalence parfaite avec Office.
Des chiffres prometteurs, mais pas une garantie de remplacement
Les pourcentages de couverture attirent l'œil : ils donnent l'impression qu'on s'approche vite des produits établis. Pourtant, « prendre en charge une fonctionnalité » et « être fiable pour le travail quotidien » ne coïncident pas.
Une suite bureautique doit respecter les contenus et les habitudes accumulées pendant des années. Une mise en forme de contrat, des formules de budget ou des animations de présentation ne sont pas juste des détails d'interface : ça peut changer un livrable et donc une décision métier.
Le test utile porte sur vos fichiers, pas sur une démonstration
Avant d'évaluer une alternative, il faut choisir les documents qui comptent vraiment. Pour une équipe, un échantillon pertinent pourrait inclure :
- un document Word avec styles, commentaires, tableaux et notes de bas de page ;
- un classeur Excel avec formules imbriquées, formats conditionnels et graphiques ;
- une présentation avec masque, polices spécifiques, animations et export PDF ;
- des fichiers reçus de clients ou de partenaires, pas seulement des documents créés dans l'outil testé.
Faites les tests sur des copies. Ouvrez chaque fichier, modifiez-le, enregistrez-le, puis vérifiez le résultat dans Office ou via un outil de référence. Comparez les calculs, la pagination, les polices et le rendu visuel. Et testez aussi les opérations moins fréquentes : c'est souvent là que les incompatibilités apparaissent.
Ce protocole évite une erreur classique : confondre une application qui « ressemble à Office » et une application réellement interopérable avec les fichiers utilisés par votre organisation. L'apparence réduit le temps d'apprentissage. Elle ne remplace pas une vraie campagne de compatibilité.
Alpha, bêta et usage professionnel ne sont pas synonymes
Le mot « alpha » veut dire, en général, que le produit est encore précoce : fonctions incomplètes, bogues fréquents, comportements parfois instables. Ça ne prédit pas la qualité de chaque fonction, mais ça dit qu'il faut accepter plus d'incertitude. De même, une estimation de « 60 % prêt pour le travail réel » n'est pas une mesure standard : elle dépend de la méthode, des critères et de ce qu'on considère comme un « usage réel ».
Decrypt indique que WordCraft aurait collecté plus de 12 000 étoiles sur GitHub quelques jours après son lancement. C'est un signal d'intérêt côté développeurs, pas une preuve de stabilité en production. Une grosse visibilité peut accélérer les contributions et les retours, mais elle ne remplace pas les tests, la documentation détaillée ou un support pensé pour les contraintes des entreprises.
La prudence doit donc être calibrée sur le risque. Pour un brouillon ou une interface à essayer, le seuil d'exigence est plus bas. Pour un document réglementaire, un modèle financier ou un support client contractuel, il faut vérifier la fiabilité, les exports, la sécurité et les conditions de maintenance avant de basculer.
Le coût de la suite bureautique n'est qu'une partie de l'équation
L'argument économique est simple : les clones sont présentés comme gratuits, et Microsoft 365 Personal est cité à 99,99 dollars par an, avec une formule familiale à 129,99 dollars. Ces montants proviennent de la source ; ils ne doivent pas être appliqués tels quels au marché français. Les tarifs locaux, les offres et les conditions d'abonnement peuvent changer. Le plus raisonnable reste de consulter la page officielle des offres Microsoft 365 pour comparer.
Mais le prix d'une licence ne représente qu'une ligne du coût total. Pour une organisation, il faut compter aussi le temps passé à tester, les incidents de compatibilité, la formation, le support, la gestion des mises à jour, et les procédures de sécurité. Un outil gratuit peut coûter plus cher si une équipe passe beaucoup de temps à réparer des documents abîmés ou à rattraper des résultats erronés.
Quand une alternative open source peut avoir du sens
WordCraft, GridCraft ou DeckCraft peuvent être intéressants quand le risque est limité et que la maîtrise locale compte plus que l'accès à toutes les fonctions avancées :
- usage personnel ou expérimentation sur des documents non critiques ;
- poste secondaire ou environnement de test ;
- besoin de travailler hors ligne, à condition de vérifier le comportement réel de l'application ;
- envie d'auditer le code ou de contribuer à un projet open source ;
- équipe capable de tester les formats qu'elle utilise et de gérer les versions installées.
L'open source donne une porte d'entrée à l'inspection et à la modification du code. Mais ça ne veut pas dire automatiquement que le logiciel est audité, maintenu avec des engagements clairs, ou adapté aux exigences de sécurité d'une entreprise. Les licences MIT et Apache 2.0 mentionnées pour le projet sont permissives ; reste que l'organisation doit vérifier la licence applicable à chaque composant et la façon dont elle distribue ou modifie le logiciel.
Quand le coût de la transition dépasse l'abonnement
Dans une entreprise, Office s'insère souvent dans des processus qui dépassent Word, Excel et PowerPoint : stockage partagé, gestion des identités, droits d'accès, commentaires, historique des versions, modèles documentaires et automatisations. Remplacer l'application sans regarder ces dépendances, c'est parfois « optimiser » une facture tout en ignorant le reste du système.
La vraie question n'est donc pas seulement « peut-on ouvrir un DOCX ? », mais « peut-on garder nos flux de travail sans perte de qualité, ni charge cachée ? ». Il faut penser aux échanges avec les clients, aux exigences de conservation, aux sauvegardes, à l'assistance aux utilisateurs et à la responsabilité en cas de problème.
Pour une PME, un pilote limité est souvent plus rationnel qu'une migration générale : choisissez quelques utilisateurs volontaires, des fichiers non sensibles et un calendrier court. Fixez des critères mesurables : taux d'ouverture sans anomalie, fidélité après enregistrement, temps de traitement, incidents et coût du support. Si le gain n'est pas visible au bout du pilote, le fait que l'outil soit gratuit ne suffit pas.
Ce que l'IA accélère - et ce qu'elle ne supprime pas
Ce qui compte ici, ce n'est pas seulement l'apparition de nouveaux clones bureautiques. Des alternatives à Office existent depuis longtemps, notamment LibreOffice. Ce qui change, c'est la cadence annoncée : Brandon Thomas aurait publié ces trois applications moins de deux semaines après ses clones d'outils Adobe, avec l'aide de Claude. Ça change forcément les attentes sur le prototypage. Mais ça ne veut pas dire que des années de développement et de maintenance ont disparu.
Un modèle de langage peut aider à générer du code, proposer des variantes, explorer des API ou accélérer la mise en place d'une interface. Il ne remplace pas les choix d'architecture, la validation des formats, les tests sur des cas limites ou le suivi des bogues. Ce sont ces éléments qui transforment une démo convaincante en outil fiable.
Générer plus vite déplace le problème
Dans un projet logiciel classique, le temps de développement est une contrainte majeure. Avec une assistance, une partie de la production de code peut accélérer. Le goulot d'étranglement se déplace alors vers la revue, les tests, la cohérence globale et la maintenance.
Et paradoxalement, générer plus vite peut aussi augmenter le coût de validation : plus de code produit rapidement, c'est aussi plus de comportements à comprendre, tester et faire évoluer. Si une équipe ne regarde que le nombre de fonctionnalités livrées, elle risque de sous-estimer le travail nécessaire pour stabiliser le produit.
C'est particulièrement vrai pour les formats bureautiques. DOCX, XLSX et PPTX peuvent contenir beaucoup de structures et d'options. Une application peut sembler solide sur quelques fichiers de démonstration, puis échouer sur un document issu d'une version différente de Microsoft Office (ou d'un autre outil). La compatibilité est moins spectaculaire que l'ajout d'une fonctionnalité, mais c'est elle qui fait confiance sur le long terme.
L'intégration avec des agents ouvre une autre couche
Les trois applications sont aussi présentées comme pilotables par des agents d'IA via MCP, le protocole de contexte de modèle créé par Anthropic. Selon le projet, des commandes de l'interface peuvent être déclenchées par un agent. On peut imaginer demander à un assistant de créer un graphique dans un tableur ou de reformater un rapport sans tout faire manuellement.
Ça mérite des tests séparés de la compatibilité bureautique. Il faut clarifier ce que l'agent peut faire, quelles données il lit, si l'utilisateur doit valider les changements, et comment revenir en arrière. En entreprise, donner à un agent l'accès à un fichier peut exposer des données personnelles ou des informations confidentielles. La conformité RGPD dépend notamment des données traitées, des fournisseurs impliqués, des lieux de traitement et des garanties contractuelles : la présence de MCP ne répond pas toute seule à ces questions.
Dans les faits, une intégration sérieuse d'agent doit être encadrée par des permissions explicites, une journalisation utile et une validation humaine avant toute opération sensible. Automatiser une tâche répétitive, oui. Laisser un agent modifier un fichier financier ou un document juridique sans contrôle, non.
La promesse doit rester vérifiable
Dernier point : l'histoire de ces projets invite à distinguer ce qui est annoncé de ce qui est réellement livré. L'article source indique que Thomas a déjà revu certaines ambitions formulées autour de ses applications précédentes. Ce n'est pas surprenant pour un projet en développement, mais ça rappelle qu'une feuille de route n'est pas une garantie.
Pour un utilisateur, les signaux les plus utiles sont concrets : versions publiées, liste de bogues, fréquence des mises à jour, tests reproductibles, documentation et retours sur des fichiers réels. Les scores de couverture et les étoiles GitHub peuvent aider à repérer un projet prometteur. Ils ne doivent pas remplacer une évaluation adaptée à votre usage.
Conclusion : tester avant de basculer
WordCraft, GridCraft et DeckCraft montrent que l'IA peut accélérer la création de logiciels ambitieux. Leur approche open source, leur compatibilité visée avec les formats Office et l'intégration envisagée avec des agents en font des projets à surveiller. Mais les chiffres de fonctionnalités ne prouvent pas encore qu'ils peuvent remplacer la suite Microsoft dans un contexte professionnel.
La décision dépend de vos fichiers, de vos processus et du coût réel de la transition. Pour un usage personnel ou un pilote à faible risque, l'expérimentation peut être pertinente. Pour des documents critiques, mieux vaut attendre une maturité démontrée ou garder ces outils pour des tâches secondaires.
Commencez par un test limité : prenez des copies de vos fichiers représentatifs, fixez des critères de réussite et vérifiez chaque résultat dans votre environnement habituel. C'est souvent une manière plus fiable d'évaluer la promesse que de se baser uniquement sur un prix ou sur un pourcentage annoncé. Pour approfondir le contexte du lancement, consultez l'article source de Decrypt.