Quand l'IA code à votre place, qui écrit les règles ?

L’IA comme alliée du contract-first

Il y a une bonne nouvelle dans tout ça : l’IA est remarquablement douée pour travailler avec des schémas. Donnez-lui un JSON Schema bien conçu, et elle générera un validateur, un mock, un client TypeScript typé, une doc Markdown, des fixtures de test, en quelques secondes. Le schéma devient un multiplicateur de valeur pour tous vos prompts.

La pratique émergente du Schema-Driven Development augmenté par l’IA fonctionne ainsi :

1. Définir le schéma en humain. C’est le moment de réflexion irremplaçable : quelles entités existent dans mon domaine ? Quelles sont leurs contraintes métier ? Quels champs sont vraiment requis ?

2. Confier l’implémentation à l’IA. “Génère un service Express qui valide les requêtes entrantes contre ce JSON Schema.” “Crée les types TypeScript correspondants.” “Écris des tests qui vérifient les cas limites du schéma.”

3. Versionner le schéma comme du code. Avec un Schema Registry (Confluent, Apicurio, ou simplement un repo Git dédié), chaque évolution est tracée, compatibilité ascendante vérifiée, déprécations annoncées.

OpenAPI : le contrat qui a changé les règles du jeu

Si JSON Schema régit la structure d’un objet, OpenAPI contractualise une API entière : endpoints, méthodes HTTP, paramètres, codes de réponse, schémas des payloads. Une spec OpenAPI bien écrite permet de générer automatiquement des SDK clients dans douze langages, une documentation interactive, des mocks serveur, des suites de tests de contrat (Pact, Schemathesis).

À l’heure du Vibe Coding, la spec OpenAPI devient le cahier des charges technique que vous rédigez avant de demander à l’IA de coder. Elle est lisible par les humains, parsable par les machines, et constitue la source de vérité qui survit à toutes les réécritures. Mieux encore : plutôt que de définir ses schémas localement dans components/schemas, une spec OpenAPI mature peut les référencer depuis un Schema Registry via un $ref distant. Le registry devient alors la source unique depuis laquelle toutes les specs consomment leurs définitions, sans jamais les dupliquer.

Schema Registry : la mémoire partagée de vos contrats

Avoir de beaux schémas ne suffit pas si chaque équipe les stocke dans un coin différent de son repo. C’est là qu’entre en jeu le Schema Registry : un registre centralisé qui référence, versionne et distribue tous les schémas de l’organisation. Confluent Schema Registry pour les architectures Kafka, AWS Glue Schema Registry pour l’écosystème cloud AWS, Apicurio Registry ou simplement un repo Git dédié avec une convention de nommage stricte : la forme importe moins que la discipline qu’elle impose.

Ce que le Schema Registry apporte est fondamental : la compatibilité entre versions devient vérifiable automatiquement. Avant de déployer un producteur qui fait évoluer un schéma, le registry peut garantir que les consommateurs existants ne seront pas cassés (compatibilité backward, forward ou full). C’est une forme de test de non-régression appliqué non pas au code, mais aux interfaces entre systèmes. À l’ère du Vibe Coding, où de nouveaux services émergent quotidiennement, ce garde-fou devient indispensable pour éviter que la vélocité individuelle ne se transforme en dette collective.

Data Contracts : quand le schéma devient engagement organisationnel

Un schéma décrit une structure. Un data contract va plus loin : il formalise les responsabilités autour de cette structure. Qui produit la donnée ? Qui la consomme ? Quel est le SLA de fraîcheur ? Qui est notifié en cas de rupture de compatibilité ? Quelle est la politique de déprécation ? Et surtout : le contrat ne réinvente pas le schéma, il le référence depuis le Schema Registry. C’est ce lien qui lui donne sa force : l’engagement organisationnel est ancré sur une définition technique versionnée et immuable, de sorte que toute évolution du schéma dans le registry peut déclencher une renégociation formelle du contrat.

Des outils comme Soda ou le framework Open Data Contract permettent de matérialiser ces engagements dans un fichier versionnable, au même titre que du code. Un data contract type embarque le schéma JSON ou Avro, les métadonnées métier (propriétaire, domaine, criticité), les règles de qualité (taux de nullité accepté, unicité, fraîcheur maximale) et les modalités de changement (préavis requis, canal de communication). C’est le passage d’une culture du best effort à une culture de la fiabilité explicite : chaque producteur de donnée signe, en quelque sorte, un accord de niveau de service envers ses consommateurs.

Pour les équipes qui pratiquent le Vibe Coding, adopter les data contracts est une façon élégante de réconcilier deux ambitions qui semblent s’opposer : la liberté de générer vite, et la rigueur de livrer des systèmes dignes de confiance.