Natively : un copilote d'entretien qui tourne sur votre machine, sous licence d'usage personnel

Le problème visé : écouter, transcrire et répondre sans envoyer l'audio à un tiers

Le README positionne l'outil sur un créneau précis : les assistants de réunion et les copilotes d'entretien qui facturent entre 20 et 149 dollars par mois et qui stockent les données sur leurs propres serveurs. Natively revendique l'inverse, à savoir des clés API fournies par l'utilisateur (BYOK), des modèles choisis par l'utilisateur et une exécution locale. La cible annoncée est double : les candidats en entretien technique ou comportemental, et plus largement toute personne qui veut des notes de réunion ou un enregistrement de cours. Le dépôt assume ce positionnement jusqu'au vocabulaire employé dans les sujets GitHub, qui incluent le mot cheating et des références explicites à LeetCode, HackerRank et HireVue. C'est un choix de communication, pas un détail cosmétique : il détermine qui adoptera le projet et qui s'en détournera. Sur le fond technique, le gain revendiqué est la latence de capture audio, annoncée sous 500 ms. Le README écrit « Native Audio Capture (<500ms) », sans préciser la machine, le système ni le modèle utilisé pour la mesure. Cette affirmation doit donc être traitée comme une revendication de l'éditeur, pas comme un résultat reproduit.

Ce que le dépôt permet de déduire de l'architecture

Le README est un document marketing, pas une documentation d'architecture, et il faut le lire comme tel. Trois éléments ressortent néanmoins. D'abord, le projet est écrit en TypeScript et se distribue sous forme d'applications macOS et Windows, avec une icône dans assets et une exigence de macOS 12+ (Apple Silicon et Intel) ou Windows 10/11. Ensuite, l'interface est décrite comme une reproduction de celle de Cluely, avec le même overlay, le même flux de travail et les mêmes raccourcis. Cela signifie que la valeur ajoutée ne se situe pas dans l'ergonomie mais dans le moteur placé derrière. Enfin, la liste des fonctions annoncées couvre la transcription en temps réel, les notes de réunion, l'enregistrement de cours, le RAG local, le BYOK et un mode furtif. Le terme RAG local implique une indexation sur disque et une recherche vectorielle côté client, mais le README ne décrit ni la base utilisée, ni le format des embeddings, ni la façon dont les documents sont découpés. Un lecteur qui a besoin de ces détails devra lire le code. Le mode furtif, lui, est présenté comme un argument de vente sans qu'aucune contrainte technique ne soit expliquée, notamment sur la façon dont la fenêtre échappe ou non aux mécanismes de partage d'écran des systèmes concernés.

Installation : ce que le README donne vraiment

La voie d'installation documentée est le téléchargement d'un binaire depuis la page des releases, via deux boutons distincts pour macOS et Windows. Le dépôt ne fournit pas, dans l'extrait disponible, de commande de compilation ni de fichier de configuration commenté. Le README mentionne l'existence d'un fichier LICENSE à la racine et d'un dossier assets, ce qui donne une idée de l'arborescence mais pas des étapes de build. Autrement dit, un utilisateur qui veut exécuter le projet depuis les sources devra se référer au fichier package.json et aux scripts qu'il contient, éléments que le README ne reproduit pas. Le seul mécanisme d'extension clairement nommé est le BYOK : vous fournissez vos propres clés pour les modèles, ce qui déplace la question du coût et de la confidentialité vers votre fournisseur. Le README ne liste pas les fournisseurs pris en charge, ne montre aucune variable d'environnement et ne donne aucun exemple de fichier de configuration. C'est la principale faiblesse documentaire du dépôt : l'argument central, à savoir le choix du modèle, n'est adossé à aucun exemple concret.

La licence d'usage personnel change la nature du projet

Le badge de licence affiche « Personal Use Source », et le texte précise un usage gratuit pour les particuliers, l'éducation, la recherche et les usages non commerciaux. L'API GitHub renvoie pourtant NOASSERTION, ce qui signifie que l'outil d'analyse n'a pas su classer le texte de licence dans une catégorie reconnue. Ce n'est pas une nuance administrative : cela veut dire qu'un responsable technique ne peut pas se contenter de lire l'étiquette. Il faut ouvrir le fichier LICENSE et vérifier les clauses une par une, en particulier ce qui est autorisé en entreprise, ce qui est autorisé en modification, et ce qui advient des redistributions. Le README parle de source disponible, pas d'open source au sens de l'OSI, et cette distinction est cohérente avec l'absence d'identifiant SPDX reconnu. Pour un usage commercial, la question n'est donc pas tranchée par le README. Je ne peux pas affirmer ce que la licence autorise ou interdit au-delà de ce que le badge et le texte indiquent, et personne ne devrait engager une équipe sur ce point sans lecture du fichier. C'est un point de friction réel pour un projet qui cible aussi les développeurs.

Là où l'outil n'est pas le bon choix

Trois cas de figure posent problème. Le premier est l'usage en entreprise sur des réunions contenant des données clients ou des informations réglementées : le traitement est local, mais les clés API pointent vers un fournisseur externe, et le README ne décrit aucune politique de rétention, aucun chiffrement au repos ni aucun journal d'audit. Le deuxième est l'utilisateur qui ne veut pas gérer de compte chez un fournisseur de modèles. Le BYOK est présenté comme une force, mais il déplace la charge : il faut créer une clé, la stocker, la révoquer, surveiller la consommation. Un outil par abonnement fait ce travail à votre place. Le troisième cas est celui des environnements verrouillés. Le mode furtif est un argument de vente, mais toute personne qui passe un entretien technique dans un navigateur avec surveillance d'écran, caméra et analyse comportementale prend un risque qui n'a rien de technique. Le README ne dit rien des conditions d'utilisation des plateformes concernées, et il ne pouvait pas le dire. Ce n'est pas une limite du logiciel, c'est une limite du contexte dans lequel il est vendu.

Face à un assistant de réunion classique, la différence tient au stockage

Comparons avec un assistant de réunion hébergé de type Otter ou Fireflies, nommés dans le README. Ces services rejoignent la réunion en tant que participant bot, enregistrent sur leurs serveurs, appliquent leur propre moteur de transcription et facturent un abonnement par utilisateur. Le flux est simple : vous invitez le bot, vous recevez un compte rendu. Natively prend le chemin inverse. Il tourne sur votre poste, capture l'audio localement et délègue uniquement l'inférence à un fournisseur que vous choisissez. La conséquence pratique est double. Vous n'avez pas de bot visible dans la réunion, ce qui est précisément l'objectif du mode furtif. En contrepartie, vous perdez tout ce qui vient avec un service hébergé : la recherche centralisée dans un historique d'équipe, le partage de notes entre collègues, la conservation à long terme gérée par un tiers, et la possibilité de retrouver une réunion depuis un autre appareil. Le RAG local de Natively reste local, donc lié à une seule machine. Pour un usage individuel, l'échange est favorable. Pour une équipe qui veut une mémoire partagée de ses réunions, il ne l'est pas.

Coût de maintenance et rythme des versions

Le dépôt n'est pas archivé et la dernière poussée sur la branche main date du 9 septembre 2026. Les versions publiées montrent un rythme irrégulier : v2.6.0 le 6 mai 2026, v2.7.0 le 5 juin 2026, puis V2.8.8 le 26 août 2026, soit un saut de trois versions mineures en près de trois mois. Ce rythme a une conséquence concrète : un utilisateur qui épingle une version devra relire les notes de version avant de sauter à la suivante, en particulier sur les parties qui touchent à la capture audio et à l'overlay, les deux zones les plus sensibles aux changements de système d'exploitation. Le coût de maintenance ne se limite pas aux mises à jour du logiciel. Il inclut la gestion de vos clés API, la surveillance de votre consommation chez le fournisseur de modèles, et la vérification périodique que la licence n'a pas changé de nature entre deux versions. Sur ce dernier point, l'absence d'identifiant SPDX reconnu rend le suivi plus difficile qu'avec une licence standard : il n'existe pas d'étiquette stable à surveiller, seulement un fichier à relire.

Conclusion éditoriale

Natively convient à un usage personnel, éducatif ou de recherche sur macOS 12+ ou Windows 10/11, avec vos propres clés API, à condition d'accepter une licence d'usage personnel et non un texte open source classique. Il ne convient pas à une équipe qui veut un traitement conforme, une piste d'audit ou un support contractuel, ni à un utilisateur qui refuse de gérer un fournisseur LLM. Avant d'installer quoi que ce soit, ouvrez le fichier LICENSE et les notes de version de la branche main, puis vérifiez dans l'application quels fournisseurs de modèles et de transcription sont réellement configurables, car le README ne les nomme pas.

Sources officielles

1. Issues
2. Natively-AI-assistant/natively-cluely-ai-assistant on GitHub
3. Project website
4. README
5. Releases