Dyad : un constructeur d'applications IA qui tourne sur votre machine, avec vos clés API

Ce que Dyad propose et à qui il s'adresse

Le README décrit Dyad comme un constructeur d'applications IA local et open source, à la manière de Lovable, v0 ou Bolt, mais exécuté sur la machine de l'utilisateur. La page d'accueil du projet, dyad.sh, sert de point d'entrée pour le téléchargement. Le dépôt est écrit en TypeScript et publié sous licence non identifiée par GitHub, avec un détail qui compte : le README précise que le code hors de src/pro est sous Apache 2.0, tandis que le code dans src/pro relève de la Functional Source License 1.1 Apache 2.0. Cette séparation est le premier élément à examiner, avant même de regarder les fonctionnalités.

Le public visé est explicite dans la description du dépôt : les utilisateurs avancés. Ce n'est pas un outil pour quelqu'un qui cherche à décrire une idée et à obtenir une application sans rien configurer. Le modèle annoncé est celui du « bring your own keys » : vous fournissez vos propres clés d'API pour les fournisseurs d'IA. Le README liste parmi les thèmes du dépôt anthropic, openai, gemini, deepseek, qwen et ollama. Les trois premiers sont des services hébergés, les trois derniers incluent des options locales ou auto-hébergées. Cette liste de thèmes est la seule indication du matériel fourni sur les fournisseurs pris en charge ; je ne peux pas confirmer depuis ce matériel lesquels sont effectivement câblés dans l'interface, ni lesquels fonctionnent sans configuration supplémentaire.

La promesse tient en trois adjectifs dans le README : rapide, privé, sans verrouillage. Rapide et privé se comprennent si le traitement passe par des modèles locaux via Ollama, ou si l'application n'envoie au fournisseur que les requêtes nécessaires. Sans verrouillage se comprend par le choix du fournisseur et par le fait que le code produit reste sur votre disque. Ces trois qualificatifs sont des affirmations du projet, pas des mesures.

Le mécanisme : une application de bureau, pas un service web

La différence structurelle avec Lovable, v0 ou Bolt ne porte pas sur la génération de code mais sur l'endroit où elle s'exécute. Ces trois services fonctionnent dans le navigateur : vous vous connectez, vous décrivez, le code est généré et hébergé côté fournisseur. Dyad se télécharge et s'installe. Le README indique une prise en charge de Mac et Windows, sans mention de Linux dans la section des fonctionnalités. Le dépôt est archivé : non, donc le développement est actif au moment de la rédaction, avec une dernière poussée datée du 9 septembre 2026.

Le flux de données que l'on peut déduire du matériel est le suivant : l'application locale reçoit votre demande, la transmet au fournisseur d'IA choisi avec la clé que vous avez configurée, récupère la réponse, et écrit le résultat dans un projet sur votre machine. Le README ne détaille pas l'architecture interne, le format des invites, ni la manière dont les fichiers sont modifiés. Je ne peux donc pas décrire la boucle de génération au-delà de ce schéma général. Ce qui est confirmé, c'est que la clé API circule entre votre poste et le fournisseur, sans passer par un serveur Dyad, puisque l'application est locale et que vous apportez vos propres clés.

Cette architecture a une conséquence pratique : la qualité du résultat dépend du modèle que vous branchez. Le README ne donne aucun exemple de sortie, aucune capture de code généré, aucune comparaison entre fournisseurs. Un utilisateur qui veut savoir si Qwen via Ollama produit un code React utilisable devra l'essayer lui-même. Le dépôt ne fournit pas d'évaluation de ce type, et je n'en inventerai pas.

Installation et configuration des clés

Le README ne documente pas de commande d'installation en ligne de commande. La section Download renvoie vers la page dyad.sh, avec la mention « No sign-up required. Just download and go. » Il n'y a donc pas de npm install, pas de script de démarrage, pas de variable d'environnement décrite dans le matériel fourni. Toute description d'une procédure en terminal serait une invention.

Ce que l'on peut affirmer, c'est que la configuration attendue est celle de clés API de fournisseurs. Le README cite la fonctionnalité « Bring your own keys » et la liste de thèmes nomme anthropic, openai, gemini, deepseek, qwen et ollama. Les noms exacts des champs de configuration, l'emplacement du fichier de réglages et la façon dont une clé est validée ne figurent pas dans le README. Pour un projet qui se présente comme destiné aux utilisateurs avancés, l'absence de documentation de configuration dans le README lui-même est un manque : la documentation détaillée est renvoyée vers le site, que je n'ai pas consulté.

Le dépôt contient un fichier CONTRIBUTING.md, mentionné dans la section Contributing. Pour quelqu'un qui veut compiler l'application depuis les sources plutôt que télécharger un binaire, c'est ce document qu'il faut lire, pas le README. Le README ne décrit pas la chaîne de build, ni les prérequis Node, ni la commande de lancement en développement.

La licence scindée : le point à vérifier avant tout

GitHub affiche NOASSERTION pour la licence du dépôt, ce qui signifie que l'outil d'analyse n'a pas pu identifier une licence unique. Le README explique pourquoi : deux régimes coexistent. Tout le code en dehors de src/pro est sous Apache 2.0, avec un fichier LICENSE à la racine. Tout le code dans src/pro est sous Functional Source License 1.1 Apache 2.0, avec un fichier LICENSE dans src/pro. La FSL est une licence « fair-source » : le code source est disponible, mais elle n'accorde pas les mêmes droits qu'une licence open source classique. Elle comporte généralement des restrictions d'usage concurrentiel et une conversion vers une licence open source après un délai défini par la licence elle-même. Je ne reproduis pas les termes exacts, que je n'ai pas sous les yeux : lisez le fichier src/pro/LICENSE.

Pour un utilisateur individuel qui installe Dyad pour construire ses propres applications, cette scission n'a probablement pas d'incidence sur le code qu'il produit. Pour une entreprise qui envisage de réutiliser du code de src/pro, ou de proposer un service dérivé, la distinction devient déterminante. C'est exactement le genre de détail qu'un lecteur doit vérifier lui-même, parce qu'il dépend de l'usage prévu et non du projet.

Un point à garder en tête : la présence de deux fichiers LICENSE signifie que le simple fait de cloner le dépôt ne suffit pas à connaître les droits applicables. Il faut savoir quel répertoire contient le code que l'on veut réutiliser.

Limites et cas où Dyad n'est pas le bon outil

La première limite est matérielle : le README annonce Mac et Windows. Si vous travaillez sous Linux, le matériel fourni ne mentionne pas de prise en charge. Ce n'est pas une preuve d'absence de support, seulement une absence de mention dans la section des fonctionnalités.

La deuxième limite concerne la documentation. Le README est court. Il liste des fonctionnalités, donne un lien de téléchargement, mentionne une communauté Reddit et renvoie au site pour le reste. Il ne contient ni exemple d'invite, ni description du format de projet généré, ni explication de la façon dont les fichiers existants sont modifiés. Pour un outil dont la valeur repose sur la qualité du code produit, cette absence rend l'évaluation difficile avant installation.

La troisième limite est le modèle de distribution. Dyad est une application de bureau, pas un service. Cela signifie que la collaboration en temps réel, le partage d'un espace de travail et le déploiement intégré, qui sont des arguments courants des constructeurs hébergés, ne sont pas décrits dans le matériel. Si votre besoin principal est de faire travailler plusieurs personnes sur le même projet généré, ou de publier en un clic, rien dans le README n'indique que Dyad couvre ce cas. Il faut le considérer comme un outil de production locale, pas comme une plateforme d'équipe.

Enfin, l'absence de clé API configurée rend l'outil inutilisable. Le README ne décrit pas de mode de secours, de quota gratuit ou de compte fourni par le projet. « Bring your own keys » est une contrainte, pas seulement un argument.

Face à Bolt et aux constructeurs hébergés

La comparaison la plus directe est avec Bolt, que le README cite lui-même comme point de référence. Bolt, dans sa version hébergée, exécute la génération et l'aperçu dans le navigateur, avec un compte et une facturation gérés par le service. Dyad déplace ces deux éléments sur votre poste : l'exécution est locale, la facturation passe directement par le fournisseur d'IA dont vous utilisez la clé. La différence de coût n'est pas documentée dans le matériel, mais la structure est claire : vous payez le fournisseur, pas Dyad.

Cette différence change aussi le périmètre de confiance. Avec un service hébergé, votre code et vos invites transitent par l'infrastructure du fournisseur du service. Avec Dyad, ils vont de votre machine au fournisseur d'IA que vous avez choisi. Si vous utilisez Ollama, ils ne quittent pas votre machine. C'est l'argument de confidentialité du README, et il tient à condition que le fournisseur sélectionné soit effectivement local.

L'autre différence est le contrôle du résultat. Un constructeur hébergé gère l'environnement d'exécution, les dépendances et le déploiement. Dyad vous laisse le projet sur votre disque, ce qui veut dire que la gestion des dépendances, la configuration du build et le déploiement restent à votre charge. Pour un utilisateur avancé, c'est un avantage. Pour quelqu'un qui veut éviter toute manipulation de fichiers, c'est un coût.

Maintenance, versions et coût de suivi

Le rythme de publication est soutenu. Le matériel fourni montre v1.14.0 le 9 septembre 2026, précédée de v1.14.0-beta.2 le 7 septembre et de v1.14.0-beta.1 le 4 septembre. Une version stable toutes les quelques semaines, avec des bêtas intermédiaires, implique un suivi régulier si vous voulez les correctifs. Ce rythme a un revers : les bêtas sont publiées avant la stable, donc un utilisateur qui suit les préversions s'expose à des régressions que la stable n'a pas encore intégrées.

Le coût de maintenance ne se limite pas aux mises à jour de Dyad. Comme l'outil produit du code dans votre projet, chaque changement de modèle ou de fournisseur peut modifier la nature du code généré. Le dépôt ne documente pas de politique de compatibilité entre versions pour les projets déjà générés. Si vous construisez quelque chose d'important avec Dyad, prévoyez de versionner votre propre code indépendamment des mises à jour de l'outil.

Sur la licence, la scission entre Apache 2.0 et FSL 1.1 Apache 2.0 implique que le suivi des versions doit s'accompagner d'une vérification du périmètre, si vous réutilisez du code du dépôt. Pour un simple utilisateur de l'application, la question ne se pose pas de la même façon. Elle se pose pour quiconque veut forker ou redistribuer.

Conclusion éditoriale

Dyad convient aux développeurs qui veulent générer des applications React ou Next.js depuis leur poste, avec leurs propres clés OpenAI, Anthropic, Gemini, DeepSeek, Qwen ou Ollama, et qui acceptent d'installer une application de bureau plutôt que d'utiliser un service hébergé. Il ne convient pas à une équipe qui a besoin d'une licence unique et permissive sur l'intégralité du code, puisque src/pro relève de la Functional Source License 1.1 Apache 2.0. Avant d'adopter, ouvrez les deux fichiers LICENSE, celui de la racine et celui de src/pro, et vérifiez que le périmètre de chacun correspond à votre usage.

Sources officielles

1. dyad-sh/dyad on GitHub
2. Issues
3. Project website
4. README
5. Releases