TypeScript pour vérifier plus tôt le code produit avec l’IA

En août 2025, TypeScript est devenu le langage le plus utilisé sur GitHub selon le nombre de contributeurs mensuels. Cette mesure ne résume pas toute l’industrie, mais elle confirme une évolution déjà visible dans les équipes produit : le JavaScript typé fait désormais partie de l’outillage habituel.

TypeScript s’utilise pour le code navigateur, React et Next.js, les API Node.js, les workers et une grande partie de l’outillage. Une équipe peut ainsi travailler dans le même langage de l’interface au serveur. Ce confort s’arrête aux frontières d’exécution : une interface TypeScript ne vérifie pas à elle seule le JSON reçu depuis une API, une base de données ou un LLM.

Un modèle génère du code plausible. Il peut inventer une propriété, oublier une branche d’une union ou utiliser l’ancienne signature d’une fonction. Le compilateur ne sait pas si la fonctionnalité est pertinente, mais il peut confronter le diff aux contrats présents dans le dépôt.

Les agents connaissent bien les API et les patterns courants de l’écosystème TypeScript. Cela accélère une première proposition, sans garantir qu’elle corresponde à la version installée ou aux conventions locales. Les diagnostics du type checker les ramènent alors au code qui existe réellement dans le projet.

Le type checker répond à une question limitée : ce code est-il compatible avec les contrats déclarés ? Il ne valide pas le besoin produit, mais sa réponse est rapide et reproductible.

Une tâche adaptée à un agent porte sur un objectif précis. Elle indique le comportement attendu, les fichiers concernés et les contraintes à préserver. Le premier diff peut alors être confronté aux commandes habituelles du dépôt plutôt qu’à une description abstraite du projet.

Les erreurs de tsc --noEmit donnent à l’agent une liste concrète de corrections. Une fois les vérifications automatiques passées, la review se concentre sur le reste : le comportement attendu, la lisibilité, les risques d’exploitation et la pertinence des tests.

import { tool } from 'ai'
import { z } from 'zod'

export const searchPlaces = tool({
    description: 'Rechercher des établissements par nom',
    inputSchema: z.object({
        query: z.string().min(2),
        limit: z.number().int().min(1).max(20),
    }),
    execute: async ({ query, limit }) => {
        return searchPlacesInDatabase({ query, limit })
    },
})

Dans cet exemple avec l’AI SDK, le schéma décrit et valide l’entrée de l’outil, puis fournit le type des paramètres de la fonction execute. Il ne vérifie pas que la personne peut effectuer cette recherche, ni que les résultats doivent lui être accessibles. Ces règles restent dans le code serveur.

L’AI SDK de Vercel fournit une API commune aux fournisseurs pris en charge, des sorties structurées, des outils validés par schéma et des primitives UI pour React et Next.js. Les fonctionnalités disponibles et leur comportement dépendent néanmoins du fournisseur et du modèle choisis.

TanStack AI propose un cœur indépendant du framework, des outils typés, du streaming et des adaptateurs pour plusieurs fournisseurs. Le projet est actuellement en bêta, ce qui compte dans une décision d’architecture et dans le niveau de maintenance à prévoir.

1. 01

   Valider les données externes

   Zod, Valibot ou JSON Schema peuvent refuser un appel mal formé. Les contrôles métier, comme vérifier qu’un utilisateur peut accéder à la ressource ou que la plage de dates est cohérente, restent explicites dans le service.

2. 02

   Limiter le contrat de chaque outil

   Un outil avec peu de paramètres, des noms précis et un résultat documenté est plus simple à appeler, tester et faire évoluer qu’une fonction générique exposant tout un service.

3. 03

   Relire le comportement obtenu

   Un diff qui compile peut encore choisir la mauvaise API, masquer une erreur ou ajouter une dépendance inutile. La review porte sur ces décisions, pas seulement sur la forme du code.

Un même schéma peut valider les arguments d’un outil et typer sa fonction execute lorsqu’il s’agit exactement du même contrat. Il ne faut pas pour autant fusionner les modèles d’API, de domaine et de stockage uniquement pour éviter quelques lignes de mapping.

Avec le mode strict activé, le compilateur détecte une propriété absente, une valeur undefined non traitée ou une réponse incompatible. Il ne sait pas si une règle métier est juste, si un utilisateur est autorisé à agir ou si une requête renvoie les bonnes données. Ces points demandent des validations à l’exécution, des tests ciblés et une review attentive.