TypeChat : décrire une intention par des types plutôt que par un prompt
TypeChat is a library that makes it easy to build natural language interfaces using types.
En bref
- De quoi s’agit-il ?
- TypeChat est une bibliothèque TypeScript sous licence MIT qui transforme une entrée en langage naturel en objet validé contre un schéma de types. Voici ce que le dépôt permet réellement de vérifier, et où l'approche montre ses limites.
- À qui s’adresse-t-il ?
- TypeChat convient aux équipes TypeScript qui possèdent déjà un modèle de domaine typé et veulent l'exposer à une saisie en langage naturel, sans écrire de prompt à la main. Il ne convient pas à un besoin de conversation libre, ni à un projet qui ne peut pas se permettre un second appel au modèle quand la validation échoue.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 6 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : arrêter d'écrire des arbres de décision
Le README décrit le point de départ sans détour : construire une interface en langage naturel reposait sur des arbres de décision complexes chargés de deviner l'intention et de collecter les entrées nécessaires. Les grands modèles de langage ont déplacé le problème. Ils savent rapprocher une phrase d'une intention, mais ils introduisent trois difficultés que le README énumère : contraindre la réponse pour des raisons de sûreté, structurer cette réponse pour la traiter ensuite, et garantir qu'elle est valide. L'ingénierie de prompt prétend répondre à cela, au prix d'une courbe d'apprentissage raide et d'une fragilité qui augmente avec la taille du prompt. TypeChat propose de remplacer cette pratique par ce que le README appelle la schema engineering. Le public visé est donc précis : des développeurs applicatifs qui savent écrire des types, pas des spécialistes du prompt. Si votre équipe n'a pas de modèle de domaine typé, la bibliothèque n'a rien à quoi s'accrocher.
Ce que fait la bibliothèque entre votre phrase et votre objet
Le README décrit trois étapes. D'abord, TypeChat construit un prompt vers le modèle à partir des types fournis. Ensuite, il valide la réponse du modèle contre le schéma ; si la validation échoue, il répare la sortie non conforme par un échange supplémentaire avec le modèle. Enfin, il résume l'instance obtenue, sans passer par un modèle, pour permettre de confirmer qu'elle correspond à l'intention de l'utilisateur. Ce troisième point mérite qu'on s'y arrête : la confirmation est déterministe, elle ne dépend pas d'une seconde génération. C'est un choix défendable, car il évite d'ajouter une couche d'incertitude au moment précis où l'on demande à l'utilisateur de valider. La forme du schéma compte autant que son contenu. Le README indique que pour ajouter des intentions, on ajoute des types dans une union discriminée, et que pour rendre les schémas hiérarchiques, on utilise un meta-schema qui choisit un ou plusieurs sous-schémas selon l'entrée. Autrement dit, la composition se fait dans le système de types, pas dans le texte du prompt.
Installation et chemins d'accès selon le langage
Pour TypeScript et JavaScript, le README donne une seule commande : npm install typechat. Le reste dépend de votre situation. Travailler depuis les sources est documenté pour Python et TypeScript, avec des renvois vers python/README.md et typescript/README.md, et une implémentation C#/.NET hébergée dans un dépôt distinct, microsoft/TypeChat.net. Les exemples se trouvent dans typescript/examples, exécutables en local ou dans un GitHub Codespace. La documentation de référence est publiée sur microsoft.github.io/TypeChat. Un point pratique : le bloc d'installation du README pour PyPI et NuGet est présent mais commenté, ce qui signale que ces canaux ne sont pas la voie principale annoncée. Si vous êtes en Python ou en .NET, prévoyez de passer par les sources ou par le dépôt séparé plutôt que par un gestionnaire de paquets, et lisez le README de la plateforme concernée avant de vous engager.
La réparation automatique, et ce qu'elle coûte
La réparation est la partie la plus intéressante du mécanisme et la plus coûteuse en pratique. Quand la réponse du modèle ne respecte pas le schéma, TypeChat relance le modèle pour corriger la sortie. Cela signifie qu'un appel utilisateur peut déclencher plusieurs appels au modèle, et que la latence comme le coût ne sont pas fixes. Le README ne donne aucune borne sur le nombre de tentatives ni sur le taux d'échec après réparation, et je ne peux pas l'inventer. Ce que l'on peut affirmer, c'est que la validation est le point de contrôle : sans schéma strict, la réparation n'a rien à corriger. Un schéma permissif, avec des champs optionnels partout ou des types trop larges, laisse passer des objets valides mais inutiles. Le README ne traite pas ce cas. C'est une limite de conception à garder en tête : la bibliothèque garantit la conformité au type, pas la pertinence du contenu.
Quand TypeChat n'est pas le bon outil
Trois situations ressortent de la lecture du README. Premièrement, si vous voulez une conversation ouverte, avec mémoire et relances, le modèle de TypeChat ne correspond pas : il produit une instance conforme à un schéma, puis un résumé de confirmation. Deuxièmement, si votre domaine change plus vite que vos types, vous passerez votre temps à modifier le schéma, et chaque modification touche le prompt construit. Troisièmement, si vous ne pouvez pas appeler le modèle une seconde fois en cas d'échec de validation, la promesse de réparation tombe. Le README présente la schema engineering comme un remplacement de l'ingénierie de prompt, mais la formulation est plus forte que ce que le document démontre : les types contraignent la forme de la réponse, ils ne suppriment pas le besoin de comprendre comment le modèle se comporte sur votre domaine. Un schéma bien écrit reste une hypothèse sur ce que le modèle saura produire.
Face à un appel direct au modèle avec validation JSON
L'alternative la plus proche n'est pas un autre projet mais une pratique : appeler le modèle soi-même, demander du JSON, puis valider avec une bibliothèque de schémas et réessayer à la main. La différence porte sur la répartition du travail. Dans l'approche manuelle, vous écrivez le prompt, vous gérez le format de sortie, vous écrivez la boucle de nouvelle tentative et vous décidez quoi faire de l'erreur. TypeChat prend en charge la construction du prompt à partir des types, la validation contre le schéma, la réparation et le résumé de confirmation. Ce que vous cédez en échange, c'est le contrôle sur la forme exacte du prompt envoyé au modèle. C'est un arbitrage réel : si votre application dépend d'instructions système précises, d'exemples choisis ou d'un format de sortie propriétaire, l'approche manuelle reste plus directe. TypeChat convient quand le schéma est la source de vérité et que le prompt n'est qu'un véhicule.
Licence, maintenance et coût de mise à jour
Le dépôt est publié sous licence MIT, ce qui autorise l'usage, la modification et la redistribution avec conservation de la notice de licence. Cette licence couvre le code de TypeChat, pas le service de modèle que vous appelez : les conditions de votre fournisseur restent applicables, et le README ne traite pas ce point. Le dépôt n'est pas archivé et le dernier push indiqué est le 28 août 2026. Aucune release récente n'a été récupérée dans les métadonnées fournies, donc je ne peux rien dire du rythme de publication ni de la stabilité des versions. Les contributions passent par un CLA et le projet applique le Microsoft Open Source Code of Conduct. Concrètement, le coût de mise à jour se situe moins dans la bibliothèque que dans votre schéma : chaque évolution du domaine demande de vérifier que les types décrivent encore ce que le modèle doit produire, et que la réparation reste efficace sur les cas limites.
Conclusion éditoriale
TypeChat convient aux équipes TypeScript qui possèdent déjà un modèle de domaine typé et veulent l'exposer à une saisie en langage naturel, sans écrire de prompt à la main. Il ne convient pas à un besoin de conversation libre, ni à un projet qui ne peut pas se permettre un second appel au modèle quand la validation échoue. Avant d'adopter, vérifiez trois choses dans votre fork ou votre environnement : le nom exact des exports de typechat pour votre version, le comportement de votre fournisseur de modèle face à la demande de réparation, et la licence MIT du dépôt par rapport aux conditions du service de modèle que vous appelez. Si votre schéma de types ne couvre pas un cas d'usage, aucune reformulation de prompt ne le rattrapera.
Notes de la communauté