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

Un schéma, c’est un contrat, pas une documentation

La première erreur est de penser qu’un schéma de données est une forme de documentation, utile mais optionnelle. C’est tout le contraire. Un schéma est un contrat légal entre systèmes. Il dit : “voilà exactement ce que j’envoie, voilà ce que j’accepte, et si tu ne respectes pas ces termes, la transaction est refusée.”

Prenons l’exemple d’un JSON Schema pour un événement produit e-commerce :

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://shop.example.com/events/order-created.schema.json",
  "title": "OrderCreated",
  "type": "object",
  "required": ["orderId", "customerId", "amount", "currency"],
  "properties": {
    "orderId":    { "type": "string", "format": "uuid" },
    "customerId": { "type": "string" },
    "amount":     { "type": "number", "minimum": 0 },
    "currency":   { "type": "string", "enum": ["EUR", "USD", "GBP"] },
    "items": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["sku", "quantity"],
        "properties": {
          "sku":      { "type": "string" },
          "quantity": { "type": "integer", "minimum": 1 }
        }
      }
    }
  },
  "additionalProperties": false
}

Ce schéma ne documente pas : il interdit. additionalProperties: false signifie qu’aucun champ inattendu ne passera. minimum: 0 sur le montant évite qu’un remboursement mal formaté ne corrompe la comptabilité. format: "uuid" garantit l’interopérabilité entre services. Chaque contrainte est une décision d’architecture, pas un détail d’implémentation.

Pourquoi l’IA générative rend ça encore plus critique

Voici le problème concret du Vibe Coding sans schémas : vous demandez à Claude de générer un service de commandes. Il produit quelque chose de parfaitement fonctionnel, dans le vide. Son champ total est un entier, là où votre système de paiement attend un flottant. Son timestamp est en Unix epoch, votre data warehouse attend du ISO 8601. Son enum status a cinq valeurs, votre frontend en connaît trois.

Ces bugs n’apparaissent pas en développement. Ils émergent en production, le vendredi de préférence à 17h, lors d’un pic de charge. Et la pire partie : si vous avez plusieurs services générés par différentes sessions IA, sans schéma commun comme point de vérité, vous avez construit une tour de Babel ultra-rapide.

Principe Contract-First Définir le schéma avant de demander à l’IA de générer le code. Le schéma devient le brief technique que vous collez dans votre prompt. L’IA implémente alors un contrat défini par un humain, et non une structure inventée à la volée. Résultat : cohérence garantie entre tous les services générés.

RSS et le spectre des flux non-contractualisés

On oublie souvent que RSS, né en 1999 et toujours massivement utilisé, est l’un des plus vieux exemples de flux de données contractualisé du web. Sa spec définit précisément ce que contient un <item>, ce qui est requis, ce qui est optionnel. Des milliers d’agrégateurs, de lecteurs, de scrapers s’en nourrissent parce qu’ils savent exactement à quoi s’attendre.

Mais regardez ce qui se passe quand des équipes décident de “customiser” leur RSS sans schéma : des namespaces inventés, des dates en formats biscornus, des descriptions tronquées différemment selon les articles.

Résultat : chaque agrégateur doit écrire du code défensif spécifique. L’interopérabilité, raison d’être du flux, est sabotée.