Pipelines de données durables pour agents de code
Votre agent prend un petit lot, le soumet, puis passe au suivant — l'état du pipeline vit côté serveur, pas dans son contexte, donc une exécution survit à la session qui l'a lancée. Chaque tentative, chaque modèle et chaque changement de règle arrivent au même registre.
115 brutes → 62 nettoyées → 62 prises en bail sur le disque → soumission → refus → la 2ᵉ tentative reprend le même lot depuis l'état serveur, pas une nouvelle exécution → 62 posées · enregistré avec le contrôle actif ↓
Sur votre machine, avec votre clé de modèle. Tablize ne fournit ni modèle ni runtime.
Un seul lot pris en bail, jamais la table entière. Les lignes qu'il ne traite pas restent côté serveur : son attention ne se dilue donc pas quand la table s'allonge.
La session suivante reprend depuis le registre — lots ouverts, baux, verdicts — au lieu de reconstituer l'exécution à partir d'une transcription.
Pas de lignes de référence, pas de contrôle. Fournissez-en un fichier et une vérification que l'agent ne peut pas lire juge chaque lot — un seul écart refuse le lot entier, et chaque refus reste au registre.
01 / Mode de défaillance
Un modèle qui lit bien cinquante lignes lit tout aussi bien la ligne cinq mille — ce qui change, c'est la quantité de table hors sujet qu'il tient pendant ce temps.
Ça marche, et ça continue de marcher jusqu'au moment où ça ne marche plus. L'attention se disperse sur des milliers de lignes que l'agent n'a pas à trancher là, les premières glissent hors de la fenêtre, et la défaillance est silencieuse — pas d'erreur, pas d'exception, juste des réponses qui dérivent. Et quand la session se termine, l'exécution se termine avec elle.
Pas cher, rapide, reproductible — et le jugement qui exigeait un modèle vient d'être comprimé en correspondance de chaînes. « Cette entreprise est-elle fabricant ou négociant ? » devient une expression régulière sur son nom. Le script est désormais le seul énoncé de la règle, personne ne l'a relu, et les lignes qu'il a mal jugées ressemblent exactement à celles qu'il a bien jugées.
Votre agent demande le lot suivant, le calcule, le soumet, en demande un autre : le modèle fait toujours le travail sémantique, mais il ne tient jamais que les lignes qu'on lui a remises. Et comme c'est votre agent qui calcule, un abonnement forfaitaire fait le travail qu'une facture d'API au token aurait fait.
Le choix n'a jamais été modèle contre script. Le choix, c'est de savoir si le processus vit dans une fenêtre de contexte qui oublie, ou dans une structure qui n'oublie pas.
02 / Pourquoi un registre
Il s'agit d'une exécution dont l'arbitre, l'état et les raisons vivent tous à l'intérieur de celui qui fait le travail.
L'agent écrit la logique d'extraction dans cette session. Quand une ligne paraît fausse, le même agent ajuste le validateur — et le lot passe. Rien ne l'en a empêché, parce que rien n'était en dehors de l'agent.
Quelles lignes ont été prises, lesquelles sont revenues, lesquelles ont été refusées et pourquoi — tout cela vivait dans une transcription. Une nouvelle session voit des fichiers et un résultat partiel, puis reconstitue l'exécution à partir d'indices au lieu de la reprendre.
Quelle version de la règle a accepté cette ligne ? Quel modèle l'a produite ? A-t-elle déjà été refusée ? Si la réponse est « regardez l'historique de conversation », il n'y a pas de compte — il y a un souvenir.
Si celui qui travaille peut réécrire l'arbitre, vous n'avez pas de contrôle. Vous avez un prompt de plus.
03 / Le segment encadré
Tablize gouverne quatre étapes et refuse de revendiquer le reste. Lisez la dernière ligne de chaque encadré : elle dit si l'étape est à vous ou à nous.
Des lignes sources en append-only — un crawl, un export, un CSV assemblé à la main. Les doublons sont conservés : ce sont des faits sur la collecte, pas des erreurs.
Collectées par vous ou votre agent · Tablize ne va rien chercher
Votre agent prend un lot borné sur disque, exécute votre prompt avec votre modèle, puis soumet les résultats comme un seul lot, avec le modèle et l'empreinte du prompt attachés.
S'exécute sur votre machine, votre clé de modèle · Tablize ne fournit aucun modèle
Bâtissez la ligne sans lignes de référence et il n'y a pas de contrôle : rien n'est jugé et les lignes se posent non vérifiées. Fournissez-les et des lignes dont la réponse est connue voyagent dans chaque lot — valeurs attendues détenues côté serveur, jamais renvoyées par une prise de lot, un seul écart refuse le lot entier.
Détenu par Tablize dès que la ligne a des lignes de référence · l'agent qui soumet ne peut jamais les lire ni les approuver
Pas une quatrième table — une lecture de la table de processus montrant la dernière ligne par ligne source. Avec un contrôle : elle ne montre que les lignes acceptées et les tentatives refusées ne déplacent rien. Sans contrôle : elle montre ce qui s'est posé, marqué non vérifié.
Projetée par Tablize · c'est à vous de juger si quelqu'un s'en sert en aval
La seule chose sans commande CLI : sur un segment contrôlé, quand votre agent écrit lui-même les lignes de référence, la ligne est créée en brouillon et ne distribue aucun travail avant qu'une personne n'ouvre le contrôle dans l'application. C'est le 403 · pending_signoff du rejeu ci-dessus. Un agent qui pourrait approuver son propre corrigé n'a été contrôlé par personne. Un segment non contrôlé n'atteint jamais cette question : il distribue le travail immédiatement et marque non vérifié ce qui se pose.
04 / Le contrôle que vous resserrez
Personne, jusqu'à ce que vous écriviez la vérification. Il n'y a pas d'interrupteur à laisser sur « arrêt » : un contrôle bâti sur des lignes que vous n'étiez pas prêt à écrire est un contrôle de bruit, et un contrôle de bruit est pire que pas de contrôle. Le niveau est fixé à la création de la ligne : le resserrer signifie donc reconstruire la ligne, un geste délibéré, posé quand le pipeline mérite d'être protégé. Les résultats déjà produits par l'ancienne ligne restent où ils sont.
Tout reste comptabilisé : chaque lot, modèle, version de référentiel et horodatage est au registre. Ce qui manque, c'est la vérification — rien ne compare les résultats à une réponse confirmée par une personne, ils arrivent donc non vérifiés. C'est le bon premier passage et le mauvais dernier.
Chaque lot est comparé aux lignes de référence et le score est enregistré, mais aucun lot n'est jamais arrêté : les résultats arrivent donc toujours non vérifiés — même un sans-faute. Quand le contrôle ne peut rien retenir, un succès est une mesure, pas une certification. Servez-vous des scores pour décider si ces lignes sont les bonnes avant de les laisser bloquer quoi que ce soit.
Les lignes de référence sont masquées et contraignantes. Un contrôle par sondage qui échoue refuse le lot entier, et des refus consécutifs arrêtent le segment plutôt que de le laisser tourner à vide. Seul enforce peut accorder « accepté » — c'est toute la raison pour laquelle ce mot vaut encore quelque chose.
Le contrôle est la première pièce du registre que vous pouvez resserrer. Ce n'est pas lui qui rend le pipeline durable — cette partie tourne déjà sur une ligne sans contrôle.
05 / Preuves produit
La même exécution, dans l'application, enregistrée avec le contrôle actif (enforce) — c'est ce qui rend un refus visible. Sans retouche, à 100 % de zoom, recadrée seulement là où chaque en-tête le précise.
Tout le segment sur un seul plan : 115 lignes brutes, 53 repliées par url, 62 lignes nettoyées, l'extraction, et le contrôle.
L'étiquette sur l'arête qui sort du contrôle est celle du produit, pas une légende que nous aurions écrite : 62 acceptées · 62 écritures bloquées. Enregistré mais non promu, dessiné à même la ligne.
Une seule ligne porte tout le compte d'un lot : son identifiant, combien de lignes il a prises, le score des contrôles masqués, le modèle qui l'a produit, et combien de fois il a été soumis.
La barre d'état en dessous place rejected 62 à côté d'accepted 62. Ici le refus est un état de première classe, pas un journal d'erreurs à vider.
Filtrez sur refusé et les 62 lignes écartées sont toujours là — l'entreprise, la catégorie choisie par le modèle, et le texte de preuve sur lequel elle a été jugée.
C'est ce qui rend la tentative suivante discutable plutôt que devinée : vous pouvez lire ce que le modèle le plus faible a réellement dit avant de décider quoi changer.
Les captures proviennent d'une instance locale, le 28/07/2026. Le mécanisme, les identifiants, les comptes, les verdicts et les colonnes système sont l'état propre du produit ; les lignes fournisseurs sont un jeu d'essai créé pour cette exécution. B et C ont été prises dans le thème clair du produit et sont montrées telles quelles dans les deux thèmes du site — nous préférons étiqueter une capture que la retoucher. Il n'y a aucun logo client sur cette page parce qu'il n'y a rien à montrer pour l'instant.
06 / Est-ce pour moi ?
Un agent, un après-midi, une erreur peu coûteuse — un CSV est la bonne réponse et ceci n'est que du surcoût. Cochez ce qui est réellement vrai chez vous.
0sur 10
07 / Limite honnête
La section la plus porteuse de cette page. Un compte qui exagère sa propre portée est pire que pas de compte du tout, parce qu'on cesse alors de vérifier la partie qu'il n'a jamais couverte.
Une ligne marquée acceptée a passé les règles et les lignes de contrôle telles qu'elles existaient à cet instant, et la version est enregistrée. Une ligne marquée non vérifiée n'a jamais été jugée — l'étiquette vous dit laquelle vous avez.
Que chaque tentative, lot, modèle et changement de règle est consigné — qui, quand, sous quelle version.
Les tentatives échouées sont conservées et lisibles, et n'entrent jamais dans la vue validée. Sans contrôle, il n'y a aucun refus à conserver — rien n'est jugé, donc rien n'est refusé.
Que l'exécution suivante reprend depuis l'état serveur — lots ouverts, baux, verdicts — sans aucune transcription.
Que les données sources soient vraies ou complètes. Une preuve que la ligne source n'a jamais portée ne se récupère pas au contrôle.
Que les champs que vous avez définis soient ceux dont l'aval a réellement besoin. Tablize applique votre contrat ; il ne le découvre pas à votre place.
Que quelqu'un ait utilisé le résultat accepté. Chez notre tout premier client de bout en bout, 128 lignes sur 136 n'ont jamais été reprises par quoi que ce soit en aval — cinq cycles, sans que personne le remarque, alors que le registre est resté exact tout du long.
Que votre agent n'écrive rien en dehors de Tablize. Il a votre machine et vos clés ; ce compte couvre un segment, pas l'agent.
08 / Comment ça marche
Quatre commandes. Pas de formulaire d'inscription, pas de visite guidée, et aucune clé à longue durée de vie collée dans un terminal.
$ npm i -g @tablize/cli $ tablize install $ tablize login --url https://api.tablize.com $ tablize doctor
Installe Tablize comme pipeline durable pour le travail clean → extract → accept de ce projet. L'idée est que l'état du processus vit côté serveur, pas dans ton contexte. 1. Exécute `npm i -g @tablize/cli`, puis `tablize install` pour poser la compétence d'agent fournie. 2. Exécute `tablize login --url https://api.tablize.com` et demande-moi d'approuver l'appariement dans le navigateur. 3. Exécute `tablize doctor` et corrige tout écart de version, de compétence, de serveur ou d'espace de travail. 4. Inspecte ce projet et propose le contrat de preuves brutes et le schéma de résultat d'extraction avant de créer un pipeline. 5. Pour le premier passage, crée le segment d'extraction sans fichier de lignes de référence — il tourne au niveau `none` : rien de jugé, les lignes se posent non vérifiées. N'invente pas de lignes de référence juste pour remplir un champ. 6. Travaille par petits lots : `batch pull`, calcule, `batch submit`, recommence. Ne charge jamais la table entière dans ton contexte, et reprends depuis `tablize context` plutôt que depuis cette conversation. 7. Avant de faire confiance à une ligne, lis `gateMode` via `tablize transform show` : seul `enforce` marque une ligne acceptée. Le niveau est fixé à la création, donc passer à `observe` ou `enforce` implique de bâtir une nouvelle ligne — propose-le quand le pipeline mérite d'être protégé, et demande-moi d'abord, car c'est moi qui signe les lignes de référence, pas toi. 8. Ne reconstruis jamais une ligne en `none` pour échapper à des lignes de référence qu'elle n'arrête pas d'échouer. C'est le contrôle qui fait son travail. 9. Garde explicitement hors de la garantie de Tablize la complétude de la collecte et l'usage réel en aval.
Pourquoi un appairage navigateur plutôt qu'un champ de clé API : ces commandes sont lancées par des agents au moins autant que par des humains, et un agent n'a ni navigateur ni mot de passe. L'appairage lui donne une identification utilisable en un seul clic humain — et le secret n'apparaît jamais dans une page web, un presse-papiers ou votre historique de shell.
L'interface du produit et la CLI n'existent aujourd'hui qu'en anglais et en chinois. Cette page est en français ; ce que vous verrez après l'installation sera en anglais — c'est pourquoi les écrans de terminal et de navigateur ci-dessous sont reproduits tels quels.
Ce qui se passe vraiment · sorties réelles de la CLI et du navigateur
🔐 Sign in to tablize Opening: https://app.tablize.com/cli-login?code=… Confirm this code matches: BFTK-9QDX Waiting for approval....
Rien n'est encore accordé. La demande expire d'elle-même si personne ne l'approuve.
Sign in to tablize? A command-line client is asking to connect to your account. Client tablize CLI · your-mac · you Code BFTK-9QDX What it will be able to do Read and write your data. It cannot manage members, policies or billing, and it does not expire — revoke it any time in Profile → API keys. [ Approve ] [ Refuse ]
Vous comparez ce code avec celui de votre propre terminal avant d'approuver. Refuser n'accorde rien et prévient le terminal en attente, qui s'arrête.
$ tablize doctor
{
"summary": { "ok": 9, "warn": 0, "fail": 0 },
"message": "all three layers healthy against
https://api.tablize.com (9 ok, 0 warn) —
this verdict covers that server only",
"next": "tablize context # open tasks, recipes, rules"
}
Installé == exécuté ? skill == CLI ? capacités serveur en ligne ? Chaque contrôle en échec revient avec la commande fix exacte, pour que l'agent puisse réparer sans vous solliciter.
09 / Tarifs — une seule base, le palier est un échelon
Le même moteur à tous les paliers. Vous ne montez d'une marche que lorsque votre charge le fait.
0 $
Serveur partagé · quota plafonné
À l'usage
Vous ne payez que ce qui tourne
Auto-hébergé
Toujours actif · privé
Bêta publique · gratuit · macOS, Linux et Windows