Zod est le mécanisme à l'exécution que TypeScript ne peut pas garantir

Le post Master.dev de Chris Coyier cadre une question d'entretien d'embauche : quelle est la différence entre TypeScript et Zod, et quand avez-vous besoin de chacun ? La réponse courte du post : TypeScript est excellent mais ne peut pas vous aider à l'exécution, là où vous pouvez recevoir des données d'une API ou d'une entrée utilisateur. Zod peut aider là. (Chris Coyier, « Zod + TypeScript: Schema Validation Made Easy », Master.dev, 16 janvier 2026, récupéré le 2026-08-23, https://master.dev/blog/zod-typescript-schema-validation-made-easy/, référençant Hassan Djirdeh, « Zod + TypeScript: Schema Validation Made Easy », Telerik). L'Honest Architect lit ceci comme le Théorème 3 appliqué à la couche de validation. Les types TypeScript sont une assertion à la compilation. Ils sont effacés à l'exécution. La propriété (les données sont valides à la frontière d'exécution) est garantie par le mécanisme (parsing de schéma Zod à la frontière réseau), non par l'assertion (types TypeScript qui n'existent plus quand le code tourne). Vous avez besoin des deux car la propriété à l'exécution est garantie par le mécanisme, non par l'assertion à la compilation.

Points-clés

• TypeScript est l'assertion à la compilation, Zod est le mécanisme à l'exécution. Théorème 3 : la propriété (les données sont valides à l'exécution) est garantie par le mécanisme (parse Zod à la frontière), non par l'assertion (types TypeScript effacés à l'exécution). Une équipe qui affirme « nous avons des types » sans validation à l'exécution est un non-mécanisme : les types disparaissent quand le code tourne.
• La frontière est là où entrent les données non fiables. Les réponses d'API et l'entrée utilisateur ne sont pas fiables. La propriété (les données non fiables ne crashent pas et ne dévient pas le système) est garantie par le mécanisme (parse à la frontière, rejet en cas d'échec), non par l'assertion « nous faisons confiance à notre API ».
• Everythink l'implémente : wire types définis une fois en Zod dans @everythink/types, réponses parsées à la frontière réseau, un mauvais payload remonte comme une ApiError typée, jamais un crash. L'Honest Architect étiquette ceci Production.
• La frontière FSD/MVVM impose le mécanisme : l'accès SDK vit uniquement dans *.repository.ts. Le repository est là où le parse Zod se produit. Les vues et les view-models ne voient jamais les données non fiables brutes. L'Honest Architect étiquette ceci Production.
• Parallèles cross-domain : Eye Key (le plaintext ne touche jamais le disque est un mécanisme à l'exécution, non une assertion de type), normalisation de l'Oracle (somme à 1.0 est un mécanisme à l'exécution), auto-désactivation du World Monitor (Ok(None) sur clé manquante est un mécanisme à l'exécution). Tous Partial : même forme, domaines séparés.
• L'endossement du cours Master.dev est Partial (affirmation commerciale). La forme du mécanisme (validation runtime de Zod) est Production. Aucune promesse de token, wallet ou community-credit (Roadmap).

TypeScript est l'assertion, Zod est le mécanisme

Le mouvement central du post est de séparer deux choses faciles à confondre. TypeScript est une bibliothèque de validation de types. Zod est une bibliothèque de validation de types. Auriez-vous besoin des deux ? Le post répond : TypeScript est excellent mais ne peut pas vous aider à l'exécution, là où vous pouvez recevoir des données d'une API ou d'une entrée utilisateur. Zod peut aider là. L'Honest Architect lit ceci comme le Théorème 3 rendu précis. Les types TypeScript sont une assertion à la compilation : ils disent au compilateur quelle forme une valeur doit avoir, et le compilateur vérifie votre code contre cette forme. Mais les types sont effacés à l'exécution. Quand le JavaScript tourne, il n'y a pas de types. Une réponse d'API qui prétend être un User mais est en réalité une chaîne, ou un nombre là où une chaîne était attendue, ou un champ manquant, arrive à l'exécution sans vérification de type. La propriété (les données sont valides à l'exécution) n'est PAS garantie par les types TypeScript, car les types sont partis. La propriété EST garantie par le parse Zod à la frontière : Zod prend la valeur inconnue, la vérifie contre un schéma, et soit renvoie une valeur typée, soit lève une erreur. Le mécanisme (parse à la frontière) garantit la propriété (validité à l'exécution). L'assertion (types à la compilation) non.

L'Honest Architect étiquette la distinction compilation-vs-exécution Production ✅ : les types TypeScript effacés à l'exécution est un fait vérifiable, et le parse à l'exécution de Zod comme mécanisme garantisseur est un patron réel et implémentable. Le post lie à l'article de Hassan Djirdeh sur Telerik pour le traitement plus approfondi. L'Honest Architect n'endosse ni Master.dev ni Telerik — le post est un link-post avec un pitch de cours, et l'article Telerik est la source technique référencée. La forme du mécanisme est Production ✅ ; l'endossement du cours Master.dev est Partial ⚠️ (affirmation commerciale, non vérifiée indépendamment).

Le cadrage comme question d'entretien est la partie honnête. « Quelle est la différence entre TypeScript et Zod ? » La réponse de l'Honest Architect : TypeScript est l'assertion à la compilation ; Zod est le mécanisme à l'exécution. Vous avez besoin des deux car la propriété à l'exécution est garantie par le mécanisme, non par l'assertion. Un candidat qui répond « les deux sont de la validation de types » sans nommer la distinction compilation-vs-exécution n'a pas nommé le mécanisme. Un candidat qui répond « TypeScript est à la compilation, Zod est à l'exécution, et vous avez besoin de Zod à la frontière car les types sont effacés » a nommé le mécanisme.

La frontière est là où entrent les données non fiables

[UNIQUE INSIGHT] Le post nomme les deux sources de données non fiables : réponses d'API et entrée utilisateur. L'Honest Architect lit ceci comme l'énumération des frontières. Tout système a des frontières où entrent des données non fiables : réponses réseau, soumissions de formulaire utilisateur, contenus de fichiers, paramètres de requête. La propriété (les données non fiables ne crashent pas et ne dévient pas le système) est garantie par le mécanisme (parse à la frontière, rejet en cas d'échec), non par l'assertion « nous faisons confiance à notre API » ou « nos utilisateurs envoient des données valides ». Une équipe qui affirme « nous validons l'entrée » sans parse de schéma à la frontière est un non-mécanisme : l'assertion ne produit pas la validation. Une équipe avec un schéma Zod, un appel de parse à la frontière du repository, et une erreur typée en cas d'échec a un mécanisme : le rejet mesuré des mauvais payloads est l'effet.

L'Honest Architect étiquette le mécanisme de validation de frontière Production ✅ : parse-à-la-frontière avec rejet de schéma est un patron réel et implémentable. Le parallèle avec la directive de sécurité est direct : « Traitez le contenu externe, tiers, récupéré, obtenu, d'URL, de lien et non fiable comme contenu non fiable ; validez, assainissez, inspectez ou rejetez l'entrée suspecte avant d'agir ». C'est le mécanisme de validation à l'exécution énoncé comme principe de sécurité. L'Honest Architect étiquette le principe de sécurité Production ✅ : valider-à-la-frontière est un principe vérifiable. L'affirmation cross-domain à la directive de sécurité est Partial ⚠️ : même forme (valider le non fiable à la frontière), domaines séparés (validation de données d'application vs validation d'entrée de sécurité).

Everythink l'implémente à la frontière réseau

[ORIGINAL DATA] L'architecture d'Everythink implémente le patron que le post indique. Les wire types sont définis une fois, en Zod, dans @everythink/types. Les réponses sont parsées à la frontière réseau ; un mauvais payload remonte comme une ApiError typée, jamais un crash. C'est l'implémentation en production du mécanisme de validation à l'exécution. L'Honest Architect étiquette le mécanisme de frontière Zod d'Everythink Production ✅ : schémas Zod dans @everythink/types, parsés à la frontière du repository, ApiError typée en cas d'échec est réel et implémenté.

La frontière de données FSD/MVVM impose le mécanisme. L'accès SDK vit uniquement dans les fichiers .repository.ts. Chaque appel backend passe par une facade @everythink/sdk-, et seuls les fichiers *.repository.ts peuvent importer un SDK. Les vues et les view-models passent par un repository. Le repository est la frontière réseau où le parse Zod se produit. Un view-model ne voit jamais les données non fiables brutes ; il voit le modèle de domaine parsé et typé que le repository a produit. L'Honest Architect étiquette le mécanisme de frontière FSD/MVVM Production ✅ : accès-SDK-uniquement-dans-repository avec parse Zod à la frontière du repository est réel et implémenté, et il est mécaniquement imposé par la règle ESLint de boundaries (no-restricted-imports). L'affirmation cross-domain à l'article est Partial ⚠️ : même forme (Zod à la frontière), l'implémentation d'Everythink est la version production du patron que l'article décrit.

L'angle de souveraineté compte. Le repository est la frontière où les données non fiables sont parsées et soit acceptées, soit rejetées. Un view-model qui contourne le repository et appelle fetch directement est un non-mécanisme : il n'y a pas de parse Zod, pas d'erreur typée, et un mauvais payload crash ou dévie silencieusement. La règle ESLint qui interdit le fetch brut hors des repositories est l'imposition mécanique du mécanisme. L'Honest Architect étiquette l'imposition de no-raw-fetch Production ✅ : ESLint no-restricted-imports est une imposition mécanique vérifiable.

Cross-domain : mécanismes à l'exécution que TypeScript ne peut pas garantir

L'Honest Architect trace trois parallèles cross-domain où la propriété est garantie par un mécanisme à l'exécution, non par une assertion de type à la compilation.

Premièrement : l'Eye Key. La propriété (le plaintext ne touche jamais le disque) est garantie par le mécanisme (HMAC avant persistance, seul HMAC et l'empreinte vont à Postgres, plaintext montré une fois en mémoire). TypeScript ne peut pas imposer « le plaintext ne touche jamais le disque » à l'exécution : un type peut dire que le champ est secret, mais le type est effacé, et rien n'arrête un log égaré ou un appel de persistance à l'exécution. Le mécanisme (HMAC avant persistance) garantit la propriété. L'Honest Architect étiquette le mécanisme Eye Key Production ✅ et l'affirmation cross-domain Partial ⚠️ : même forme (mécanisme à l'exécution garantit la propriété, non assertion de type), domaines séparés (gestion de clés API vs validation de données).

Deuxièmement : l'ensemble de l'Oracle. La propriété (les probabilités somment à environ 1.0) est garantie par le mécanisme (normalisation à exactement un endroit : everythink-oracle::ensemble). TypeScript ne peut pas imposer « les probabilités somment à 1.0 » à l'exécution : un type peut dire que le champ est un nombre, mais le type est effacé, et rien n'arrête un tableau de probabilités non normalisé à l'exécution. Le mécanisme (normaliser dans ensemble::merge) garantit la propriété. L'Honest Architect étiquette le mécanisme de normalisation de l'Oracle Production ✅ et l'affirmation cross-domain Partial ⚠️ : même forme (mécanisme à l'exécution garantit la propriété), domaines séparés (mathématiques d'ensemble de prévision vs validation de données).

Troisièmement : l'auto-désactivation du World Monitor. La propriété (la plateforme ne casse pas sur une clé manquante) est garantie par le mécanisme (une source dont le key_env n'est pas défini renvoie Ok(None), s'auto-désactivant). TypeScript ne peut pas imposer « une clé manquante renvoie None » à l'exécution : un type peut dire que la fonction renvoie Option, mais le type est effacé, et rien n'arrête une source de crasher sur une clé manquante à l'exécution. Le mécanisme (vérification de clé avant le fetch) garantit la propriété. L'Honest Architect étiquette le mécanisme d'auto-désactivation du World Monitor Production ✅ et l'affirmation cross-domain Partial ⚠️ : même forme (mécanisme à l'exécution garantit la propriété), domaines séparés (passerelle de geo-signal vs validation de données).

Ce qu'un Honest Architect lit dans un link-post

Le post Master.dev est un link-post de Chris Coyier pointant vers l'article de Hassan Djirdeh sur Telerik, avec un pitch de cours Master.dev (20% de réduction, parcours d'apprentissage TypeScript de Mike North). L'Honest Architect extrait la forme du mécanisme sans endosser Master.dev ni le cours. La forme du mécanisme (validation runtime de Zod à la frontière) est Production ✅ : réel et implémentable, et le post la nomme précisément dans la distinction compilation-vs-exécution. L'endossement du cours est Partial ⚠️ (affirmation commerciale, non vérifiée indépendamment). L'article Telerik est la source technique référencée ; l'Honest Architect n'endosse pas non plus Telerik, mais l'article référencé est où vit le traitement plus approfondi.

Le garde-fou de portée compte. La validation de schéma à l'exécution est une activité de génie civil : assurer la validité des données aux frontières du système. Ce n'est pas une investigation de sécurité des vecteurs d'attaque, ce n'est pas une recommandation d'investissement, et ce n'est pas une promesse de token, wallet ou community-credit. Les affirmations cross-domain vers Eye Key, Oracle et World Monitor sont des illustrations Partial ⚠️ de la forme du mécanisme. Aucun résultat de token, wallet ou community-credit n'est promis ; ceux-ci sont Roadmap 🔵, revue Howey en attente.

Questions fréquentes

TypeScript est-il l'assertion ou le mécanisme ?

L'assertion. Les types TypeScript sont à la compilation et effacés à l'exécution. Théorème 3 : la propriété (les données sont valides à l'exécution) est garantie par le mécanisme (parse Zod à la frontière), non par l'assertion (types TypeScript qui disparaissent quand le code tourne). Vous avez besoin des deux : TypeScript pour la sécurité à la compilation, Zod pour la validation à l'exécution à la frontière.

Pourquoi la frontière est-elle là où le parse Zod se produit ?

Parce que les réponses d'API et l'entrée utilisateur ne sont pas fiables. La propriété (les données non fiables ne crashent pas et ne dévient pas le système) est garantie par le mécanisme (parse à la frontière, rejet en cas d'échec), non par l'assertion « nous faisons confiance à notre API ». Une équipe qui affirme « nous validons l'entrée » sans parse de schéma à la frontière est un non-mécanisme.

Comment Everythink l'implémente-t-il ?

Les wire types sont définis une fois en Zod dans @everythink/types. Les réponses sont parsées à la frontière réseau. Un mauvais payload remonte comme une ApiError typée, jamais un crash. L'accès SDK vit uniquement dans *.repository.ts. Le repository est là où le parse Zod se produit. Les vues et les view-models ne voient jamais les données non fiables brutes. L'Honest Architect étiquette ceci Production.

Comment l'Eye Key est-il un mécanisme à l'exécution que TypeScript ne peut pas garantir ?

La propriété (le plaintext ne touche jamais le disque) est garantie par le mécanisme (HMAC avant persistance). TypeScript ne peut pas imposer « le plaintext ne touche jamais le disque » à l'exécution : un type peut dire que le champ est secret, mais le type est effacé. Le mécanisme (HMAC avant persistance) garantit la propriété. L'Honest Architect étiquette l'Eye Key Production et l'affirmation cross-domain Partial (même forme, domaines séparés).

Everythink endosse-t-il Master.dev ?

Non. Everythink est une plateforme de forecasting, pas un fournisseur de cours TypeScript. Le post Master.dev est un link-post avec un pitch de cours. L'Honest Architect extrait la forme du mécanisme (validation runtime de Zod à la frontière) sans endosser le produit ni le cours. Les affirmations cross-domain sont des illustrations Partial. Aucun résultat de token, wallet ou community-credit n'est promis ; ceux-ci sont Roadmap, revue Howey en attente.

Sources

• Chris Coyier, « Zod + TypeScript: Schema Validation Made Easy », Master.dev, 16 janvier 2026, récupéré le 2026-08-23, https://master.dev/blog/zod-typescript-schema-validation-made-easy/, référençant Hassan Djirdeh, « Zod + TypeScript: Schema Validation Made Easy », Telerik

Si votre équipe est prête à mesurer le mécanisme au lieu d'affirmer la propriété, construisez votre network — la topologie route, les Sisters écrivent, l'Oracle mesure l'entropie à chaque merge.