Pourquoi générer des types
Les modèles typés détectent les erreurs tôt. Quand la réponse d'une API est décrite par une interface ou une classe, votre éditeur complète les noms de champs, le compilateur repère une clé mal orthographiée, et un champ renommé apparaît comme une erreur au lieu d'un undefined ou d'un null silencieux à l'exécution. Écrire ces types à la main pour une réponse de cinquante champs sur trois niveaux d'imbrication prend du temps, et les erreurs arrivent vite.
Un générateur fait la partie répétitive en une seconde. Le résultat est un bon premier jet que vous relisez, renommez si besoin, puis validez dans votre dépôt.
Essayez ici : JSON en code
Ouvrir la page complète de l'outilCe qu'un générateur déduit de votre exemple
Tout vient des valeurs de votre JSON. C'est pourquoi la qualité de l'exemple compte plus que tout le reste.
| Dans le JSON | Déduit comme | Exemple |
|---|---|---|
| Texte | string | "name": "Camille" |
| Nombre entier | int, ou long au-delà de 2 147 483 647 | "id": 42 |
| Nombre avec un point décimal | double ou float | "price": 19.0 |
| true ou false | boolean | "active": true |
| Texte au format de date ISO | type date, si l'option est activée | "created": "2026-10-27T09:30:00Z" |
| null dans certains éléments | type nullable | "phone": null |
| Clé absente de certains éléments | champ optionnel | "discount" dans un seul élément |
| Objet | un nouveau type nommé | "address": { ... } |
| Liste d'objets | liste d'un seul type fusionné | "items": [ { ... }, { ... } ] |
Donnez-lui un exemple varié
Un générateur ne peut décrire que ce qu'il voit. Si votre exemple contient une seule commande avec un seul article, chaque champ semble obligatoire et aucun ne semble nullable. S'il contient une liste de commandes dont certaines ont une remise et d'autres non, le champ de remise est correctement marqué comme optionnel.
Avant de générer, récupérez donc une réponse avec plusieurs éléments, idéalement avec des cas limites : un client sans numéro de téléphone, une commande sans article, un produit avec un prix décimal. Placez-les dans un même tableau au niveau principal et le générateur les fusionnera tous en un type par forme d'objet.
- Les champs qui valent null dans tous les éléments reçoivent un type général comme unknown, object ou Any, car le vrai type n'est pas visible.
- Les listes vides deviennent des listes d'éléments inconnus pour la même raison.
- Un champ qui est un nombre dans un élément et du texte dans un autre devient une union en TypeScript et un type général dans les autres langages.
- Les grands identifiants au-delà de 2^53, comme certaines clés de base de données, sont plus sûrs en texte. JavaScript ne peut pas les représenter exactement sous forme de nombres.
Noms, attributs et conventions
Les clés JSON suivent souvent le style du backend, par exemple le snake_case de Python ou de Ruby, alors que votre code client en utilise un autre. Un bon générateur renomme les champs selon la convention du langage cible et garde la clé d'origine dans un attribut, pour que la sérialisation corresponde toujours aux données.
| Langage | Noms des champs | Comment la clé JSON est conservée |
|---|---|---|
| TypeScript | Inchangés | Inutile ; les clés inhabituelles sont mises entre guillemets |
| C# | PascalCase | [JsonPropertyName] ou [JsonProperty] |
| Python | snake_case | Field(alias=...) dans Pydantic |
| Go | Exportés, avec ID et URL | Tags de struct json:"key" |
| Java | camelCase | @JsonProperty (Jackson) |
| Kotlin | camelCase | @SerialName (kotlinx.serialization) |
Des types ne sont pas une validation
Une interface TypeScript disparaît à la compilation. Si l'API envoie autre chose que ce que l'interface promet, rien ne l'arrête à l'exécution. C'est la même chose pour les classes simples dans la plupart des langages : le désérialiseur remplit ce qu'il peut et laisse le reste vide.
Si les données viennent d'une source que vous ne maîtrisez pas, validez-les à leur arrivée. En Python, les modèles Pydantic le font d'office, ce qui est une bonne raison de choisir ce style dans le générateur. En TypeScript, des bibliothèques qui vérifient les données à l'exécution peuvent être écrites à partir des interfaces générées. En C#, Java et Kotlin, marquez comme obligatoires les champs qui doivent être présents et laissez le sérialiseur échouer tôt.
Une liste de contrôle avant de valider
- Renommez le type principal Root en quelque chose de parlant, comme Order.
- Relisez chaque champ typé unknown, object, Any ou JsonElement et remplacez-le par le vrai type.
- Vérifiez les nombres : un prix est-il vraiment un double, ou faut-il un type décimal adapté à l'argent ?
- Vérifiez les dates : les voulez-vous en texte, ou dans un type date avec un fuseau horaire connu ?
- Décidez quels champs optionnels le sont vraiment et lesquels manquaient seulement par hasard dans l'exemple.
- Fusionnez les types que le générateur a séparés uniquement parce que leurs exemples différaient légèrement.