Ndoc : l’IA peut-elle remplacer Microsoft Office ?

Le problème n'est pas l'absence d'IA

Les suites bureautiques évoluent déjà. Il existe des assistants pour remplir des cellules, résumer un document ou générer une présentation. Ndoc démarre pourtant d'un autre constat : l'analyse est souvent dispersée entre plusieurs applications. Les données sont dans un tableur ou un entrepôt, les calculs dans un outil dédié, les conclusions dans un document, puis les résultats finissent en slides. L'IA conversationnelle s'ajoute parfois au passage, avec son lot de copier-coller et de transitions brouillées.

Et cette fragmentation a un coût. Entre deux outils, on peut perdre du contexte, introduire une erreur, ou simplement se retrouver incapable de retrouver la formule, la source ou l'hypothèse qui explique un chiffre présenté en réunion. Le souci n'est pas uniquement le temps passé à produire un document. C'est la difficulté à garder un lien net entre données, raisonnement et décision.

Ndoc veut rassembler ces éléments dans un espace partagé. Selon la présentation de Rohit Patel relayée par TechCrunch, l'objectif est aussi de permettre aux collègues de consulter le résultat même s'ils ne sont pas inscrits à Ndoc. L'ambition est donc plus large qu'un simple assistant intégré à un tableur : l'outil veut devenir l'endroit où une analyse est construite, expliquée et partagée.

Une alternative complète implique un changement d'habitudes

La différence entre une fonctionnalité utile et un remplacement de suite bureautique est majeure. Un assistant ajouté à Microsoft 365 ou Google Workspace s'appuie sur des habitudes déjà installées : fichiers existants, droits d'accès, processus internes. Un nouvel espace de travail, lui, doit justifier la migration et cohabiter avec l'existant.

C'est aussi pour ça que Ndoc prévoit des connecteurs pour importer des données issues d'outils déjà utilisés. Cela limite le coût du démarrage, mais ne règle pas tout : il faut encore décider quels documents migrer, qui peut les modifier et comment gérer les versions. La question n'est donc pas seulement « est-ce que l'outil produit une bonne analyse ? » Elle est aussi : « est-ce qu'on peut l'intégrer sans créer un nouveau silo ? ».

Le choix de Patel est ambitieux, mais cohérent avec le problème qu'il cherche à résoudre. Ajouter de l'IA aux outils existants reste souvent l'option la moins risquée à court terme. Repenser le flux complet peut, lui, rendre l'expérience plus unifiée - à condition que l'outil soit suffisamment fiable et compatible pour entrer dans le quotidien des équipes.

Trois vues pour relier résultat, explication et données

Ndoc découpe le travail en trois espaces. Le premier, Stage, accueille les résultats destinés à être consultés ou présentés : tableaux de bord, simulations, présentations ou petites applications. C'est la partie « visible », celle qu'on partage pour faire passer une conclusion exploitable.

Le deuxième, Narrative, rassemble l'analyse qui donne du sens aux résultats. On y trouve des explications, des références numérotées et des figures générées. Cette séparation compte : une présentation peut aller à l'essentiel, tandis que le raisonnement détaillé reste accessible sans transformer chaque diapo en document technique.

Le troisième espace, Model, contient les jeux de données et les scripts Python qui se trouvent derrière. L'objectif est de garder une trace des éléments utilisés pour produire les conclusions. Dans un flux classique, ces éléments se retrouvent dispersés entre un tableur, un notebook, un dossier partagé et des échanges par messagerie. Les réunir au même endroit facilite la vérification... et la maintenance.

Un exemple de flux de travail

Concrètement, une équipe pourrait importer un jeu de données, demander à Ndoc d'en tirer des tendances, puis récupérer une analyse en Narrative et un support de présentation. Ensuite, elle peut enrichir le document avec des précisions propres au contexte : le public visé, le ton attendu, etc. Patel indique aussi que la mémoire de l'outil peut s'appliquer à plusieurs niveaux : personne, document, équipe ou entreprise.

Sur le papier, ça évite de répéter les mêmes consignes pour chaque livrable. Mais il y a une vraie question de gouvernance derrière : qu'est-ce qui est conservé à quel niveau, qui y a accès, et comment corriger ce qui devient obsolète ? La personnalisation ne sert vraiment que si les règles restent compréhensibles et maîtrisées par l'organisation.

Le flux proposé peut se résumer comme suit :

• Importer des données depuis les outils existants.
• Produire une analyse et ses représentations avec l'assistance de l'IA.
• Examiner les explications, les sources et les scripts associés.
• Partager le résultat dans un espace pensé pour les collaborateurs.

Cette organisation peut réduire les allers-retours entre applications. En revanche, elle ne fait pas disparaître le risque d'une conclusion fausse ni celui de données de départ médiocres. L'outil rend le travail plus lisible, mais il ne transforme pas une donnée incomplète en preuve solide.

Le fichier comme format de partage

Patel veut aussi faire bouger le document lui-même. Ndoc prévoit une exportation sous la forme d'un fichier unique au format « .ndoc.html », lisible dans un navigateur. Le fondateur dit vouloir ouvrir ce format pour que d'autres développeurs puissent créer des applications compatibles, sans obliger les utilisateurs à rester entièrement dans Ndoc.

Sur le fond, l'idée est intéressante : traiter le verrouillage par les formats comme un enjeu de produit, pas seulement comme un problème d'export. Un fichier autonome facilite la consultation et le partage. Reste à voir ce que cet export contient vraiment : les données, les interactions, les scripts et les droits d'accès, ou seulement une version « présentable » du document. Le fait d'annoncer un format ouvert ne répond pas, à lui seul, aux questions de sécurité, de mises à jour ou de compatibilité dans le temps.

Montrer les scripts ne suffit pas, mais c'est un bon début

Rohit Patel a travaillé chez Meta sur l'évaluation des systèmes d'IA et l'apprentissage par renforcement. Cette expérience se traduit, côté Ndoc, par une priorité : rendre inspectable une partie du travail généré. Si un tableur ou un support de décision est produit à partir d'un script Python, l'utilisateur peut retrouver ce script et demander à l'assistant d'expliquer une formule ou une étape de calcul.

Ce point répond à une faiblesse fréquente des outils génératifs : le résultat peut paraître convaincant sans que l'origine soit claire. Avoir accès au code donne un repère concret. Un analyste peut examiner une formule, comparer un calcul à une méthode connue, ou demander une explication avant d'utiliser le résultat dans une décision.

Mais la transparence technique ne garantit pas la validité. Un script visible peut contenir une erreur, s'appuyer sur des données biaisées ou appliquer une hypothèse discutable. Et pour un utilisateur qui ne connaît pas Python, une explication générée par la même IA que celle qui a produit l'analyse n'est pas, à elle seule, une vérification indépendante. La traçabilité améliore le contrôle possible ; elle ne remplace pas le contrôle.

Mettre en place une vérification adaptée au risque

Avant de lancer ce type d'outil, une entreprise devrait définir des règles de revue plutôt que de considérer l'accès au code comme une garantie automatique. Le niveau de contrôle devrait dépendre de l'usage. Un graphique exploratoire pour une discussion interne n'appelle pas le même examen qu'un calcul servant à fixer un budget, évaluer un risque ou contribuer à une décision réglementée.

Pour un pilote, une procédure pragmatique pourrait inclure :

1. Identifier le propriétaire de l'analyse et la personne responsable de son approbation.
2. Vérifier les données d'entrée : origine, période couverte, champs manquants et limites éventuelles.
3. Contrôler les calculs décisifs, notamment les formules qui changent la conclusion.
4. Comparer les résultats importants à une méthode ou à un calcul indépendant.
5. Tracer les modifications et préciser quand une sortie de l'IA a été revue.

Ce cadre ajoute du travail, mais il évite le faux choix entre automatisation totale et rejet de l'IA. Le vrai test pour un environnement comme Ndoc sera sa capacité à réduire les tâches répétitives tout en rendant la vérification plus simple. Si l'équipe doit tout reconstruire ailleurs pour avoir confiance, le gain annoncé finit par s'évaporer.

Les modèles utilisés et le coût d'exploitation

Patel indique que Ndoc est construit et ajusté à partir d'un mélange de modèles ouverts. Il affirme aussi que l'architecture développée pour le produit coûte moins cher à faire fonctionner que des solutions basées sur des modèles d'IA plus « avancés ». Ce sont des déclarations du fondateur, pas une comparaison indépendante publiée avec des détails de tarification.

Le coût d'exécution reste quand même important pour un outil utilisé régulièrement. Une solution facturée à l'usage peut sembler abordable lors d'un essai, puis devenir moins prévisible quand plusieurs équipes l'adoptent. Pour comparer Ndoc à une suite existante, il faudra regarder le coût global : licences, consommation de jetons, intégration, formation, administration et temps consacré à la revue des résultats.

Remplacer un outil installé est plus dur que le construire

Ndoc est porté par une équipe de trois personnes, sans financement annoncé au moment du lancement décrit par TechCrunch. La jeune pousse lance un pilote en entreprise et ouvre une version alpha à un nombre limité de clients via une liste d'attente. L'inscription est gratuite, mais l'usage et les jetons doivent être payants. Patel espère une version bêta dans les semaines suivantes et un lancement plus large l'année prochaine.

Ce calendrier raconte une ambition, pas une disponibilité générale, ni une preuve de demande à grande échelle. Un petit groupe peut avancer vite et garder une cohérence interne. Mais il dispose aussi de moins de marge pour assurer l'assistance, la sécurité, les intégrations, la documentation et la continuité du service, comparé à un éditeur déjà installé.

Le vrai défi arrive après la démo : transformer un prototype en un outil fiable au quotidien. Les utilisateurs ne jugent pas seulement une génération réussie. Ils veulent savoir ce qui se passe quand un connecteur échoue, quand un collègue quitte l'entreprise, quand un document doit être corrigé, ou quand le service est indisponible. Ce sont des scénarios moins spectaculaires que la démonstration, mais ce sont souvent eux qui décident de l'adoption.

La sécurité et la conformité restent à clarifier

À ce stade, la description publique de Ndoc ne permet pas, à elle seule, de conclure sur ses garanties de sécurité ou sur sa conformité au RGPD. Une entreprise européenne devra obtenir des réponses précises avant d'y déposer des données internes ou personnelles : où elles sont hébergées, combien de temps elles sont conservées, quels sous-traitants interviennent, si elles servent à entraîner des modèles et comment leur suppression est gérée.

Il faut aussi regarder la gestion des accès. Une mémoire partagée entre utilisateur, équipe et entreprise peut être pratique, mais elle ne doit pas mélanger des informations qui devraient rester séparées. Les droits de lecture et de modification doivent suivre les responsabilités réelles, y compris quand un document est exporté ou partagé avec quelqu'un qui n'a pas de compte Ndoc.

Pour un premier test, le plus simple est de choisir un cas d'usage limité, avec des données non sensibles et un responsable clairement identifié. Cette prudence ne veut pas dire « attendre une solution parfaite ». Elle permet de mesurer la valeur sans exposer inutilement l'organisation à des risques difficiles à réparer.

Ndoc doit prouver qu'il va au-delà de la simple interface

L'approche défendue par Patel se démarque des outils qui ajoutent une couche d'IA au-dessus d'applications déjà en place. Il considère que remplir quelques cellules avec un assistant ne suffit pas à changer le travail. Son analogie parle d'électricité ajoutée à un outil ancien, plutôt que d'une machine pensée dès le départ pour faire la tâche autrement.

L'analogie exprime une conviction, mais les outils existants ont un avantage concret : ils sont déjà intégrés aux habitudes, aux processus et aux politiques informatiques des entreprises. Une interface plus unifiée ne peut fonctionner que si elle rend les tâches réellement plus simples sans sacrifier le contrôle, la collaboration et la compatibilité. Les connecteurs annoncés deviennent donc essentiels - mais ils devront tenir dans les cas réels, avec les formats et les règles d'accès des clients.

Pour une entreprise française ou européenne, la question ne devrait pas être « est-ce que Ndoc va remplacer Office à court terme ? ». Elle est plus limitée et plus utile : « avons-nous un flux d'analyse assez fragmenté, coûteux ou difficile à vérifier pour justifier un pilote ? ». Si oui, tester un processus précis a du sens. Si le besoin se limite à produire ponctuellement un texte ou une formule, un outil déjà intégré à la suite existante peut rester plus simple.