Astuce — savoir ceci suffit pour commander
Le code est structure (Cours 8), le systeme est structure (Cours 9). Reste les donnees. Les donnees sont les plus dangereuses. Les erreurs de code sont detectees par les tests, les erreurs systeme par /health. Les erreurs de donnees ne sont vues par personne. On les decouvre 3 mois plus tard dans le rapport trimestriel.
A l’agent : “Pas de JSONB — cree un schema avec des colonnes explicites et des contraintes. amount > 0, status n’accepte que des valeurs definies.”
A l’agent : “Importe cet Excel en BDD. Les contraintes DDL doivent etre respectees. Les lignes en violation dans un fichier separe avec rapport.”
A l’agent : “Modifie le DDL et passe yongol validate. Genere les fichiers de migration, en cas d’echec, rollback.”
Vous qui ne connaissez pas les BDD n’avez qu’a decider “quoi stocker”. “Le telephone doit commencer par 010”, “l’email doit etre unique” — ces decisions en langage naturel, l’agent les traduit en DDL.
Pourquoi commander ainsi
Les donnees pourrissent avant le code
Erreur de code → test. Erreur systeme → monitoring. Erreur de donnees → personne ne voit. Decouvert 3 mois plus tard.
4 conditions de l’Agent Operable Data
1. Le schema est declare. DDL = contrat des donnees. Types, contraintes, relations explicites.
2. Les transformations sont verifiables. Regles de mapping declaratives, invariants avant/apres verifies.
3. L’origine et le moment sont traces. source, created_at, created_by dans chaque enregistrement.
4. Le cliquet s’applique aux changements de donnees. DDL → validate → migration (up + down) → staging → production (approbation).
Le schema est la loi que j’etablis
Le principe du Cours 5 “la contrainte est un contrat” se manifeste directement dans les donnees. La base de donnees a un schema. Le schema definit ce qui est valide. NOT NULL, FOREIGN KEY, CHECK — impossible de contourner.
La loi n’est pas la justice (正義) mais la definition (定義).
Des donnees sans schema sont une societe sans loi.
Meme pattern, domaines differents
| Cours 8 : Code | Cours 9 : Systeme | Cours 10 : Donnees | |
|---|---|---|---|
| Lisible ? | filefunc | /health | DDL |
| Verifiable ? | go test + tsma | CI/CD + healthcheck | Contraintes BDD + Rego |
| Reversible ? | git revert | rollback image | migration down |
Tout est la meme structure : declarer, verifier, verrouiller, persister.
Vision
| Cours | Ce qu’on a appris | Resultat |
|---|---|---|
| 1 | Vibe Coding | “Dites, le code sort” |
| 2 | Pourquoi ca casse | Derive, perte de contexte, flatterie |
| 3 | Comment prevenir | Hurl, Git, CI/CD |
| 4 | Le mur des 200 endpoints | yongol — SSOT declaratif |
| 5 | L’IA bridee | Reins Engineering : 3 piliers |
| 6 | Verrouiller et avancer | Ratchet Pattern |
| 7 | Retourner la flatterie | IFEval |
| 8 | Structurer le code | filefunc + tsma |
| 9 | Structurer le systeme | Agent Operable System |
| 10 | Structurer les donnees | Schema = loi |
Dites et c’est fait. Pas seulement le code, mais le systeme et les donnees aussi. Pour cela, il faut des brides, des rails et des lois. Concevoir ces brides, rails et lois, c’est le Reins Engineering.
Articles connexes
Cours complet Reins Engineering
| Cours | Titre |
|---|---|
| Cours 1 | Comment commander l’IA |
| Cours 2 | Comment ne pas faire confiance a l’IA |
| Cours 3 | L’application incassable |
| Cours 4 | Les decisions hors du code |
| Cours 5 | L’IA bridee |
| Cours 6 | Passe, verrouille |
| Cours 7 | Retourner la flatterie |
| Cours 8 | L’usine des agents |
| Cours 9 | L’automatisation au-dela du code |
| Cours 10 | La loi des donnees |
Sources
- E.F. Codd, “A Relational Model of Data for Large Shared Data Banks” (1970)
- OPA / Rego — Langage de politique declaratif
- yongol DDL → sqlc — Verification croisee sans rupture du schema au code type-safe
- Principe de l’etat de droit (Rule of Law) — Verifiabilite, definition de la violation, applicabilite