Code généré par IA : ce que TypeScript peut vérifier

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.

type Job =
    | { status: 'queued' }
    | { status: 'done'; url: string }
    | { status: 'failed'; message: string }

function assertNever(value: never): never {
    throw new Error(`Unhandled job: ${JSON.stringify(value)}`)
}

function jobLabel(job: Job): string {
    switch (job.status) {
        case 'queued': return 'En attente'
        case 'done': return job.url
        case 'failed': return job.message
        default: return assertNever(job)
    }
}

Si le premier diff oublie la branche failed, l’appel à assertNever(job) ne compile plus : job peut encore contenir cet état. Le diagnostic donne à l’agent le cas à traiter. Une personne doit ensuite vérifier que le message affiché et le comportement de l’interface conviennent au produit. Ce contrôle suppose que les données reçues ont déjà été validées à l’exécution.

Le même problème se pose lorsqu’un agent modifie une fonctionnalité qui appelle un modèle. Les données reçues depuis une API, une base ou un LLM doivent être validées à l’exécution. Les types seuls ne font pas ce contrôle.

Les bibliothèques utilisées pour ces fonctions ont leurs propres contrats. L’AI SDK de Vercel fournit des sorties structurées et des outils validés par schéma ; TanStack AI propose notamment des outils typés et du streaming. Les capacités dépendent des versions, des fournisseurs et des modèles. Le statut bêta de TanStack AI mentionné dans les sources compte aussi dans le choix et la maintenance.

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.