Permettre le développement évolutif des bases de données : le branching de bases de données avec Lakebase, la conclusion

La méthodologie décrite dans Evolutionary Database Design et mise en œuvre dans Refactoring Databases: Evolutionary Database Design est claire depuis vingt ans. Les sept pratiques, le catalogue de plus de 70 refactorisations répertoriées, les mécanismes de transition – tout cela est documenté, évalué par des pairs et enseigné.

Cette méthodologie a atteint le CI/CD en 2010 avec Continuous Delivery (Chapitre 12 : Managing Data). Les migrations sont devenues des artefacts de premier plan dans le pipeline de déploiement. La discipline des modifications de base de données en tant que code s'est étendue au mouvement CI/CD plus large. Ce que le CD n'a pas résolu, c'est l'isolation par pipeline : les pipelines pouvaient exécuter des migrations, mais ils avaient toujours besoin d'une base de données cible, et cette cible était partagée. La pratique n° 4 – Chacun obtient sa propre instance de base de données – est restée un idéal pour la plupart des équipes, car de véritables bases de données calquées sur la production pour chaque développeur coûtent du temps, de l'argent et des cycles de DBA. La couche de compensation qui a émergé pour contourner cette lacune (objets fictifs, environnements de staging partagés, substituts de bases de données en mémoire, files d'attente de tickets DBA) est devenue une méthodologie fondamentale par défaut, et non par conception.

En 2026, le branching de base de données par copie sur écriture (copy-on-write) arrive dans Databricks Lakebase. Créer en une seconde et sans stockage initial une branche d'une base de données de production à l'échelle du téraoctet est désormais une opération en O(1). La contrainte qui empêchait la pratique n° 4 de devenir réalité est levée.

Cette série décrit ce qui change lorsque cette contrainte est levée : non pas la méthodologie – qui reste valable – mais les pratiques qui émergent pour la première fois, la gouvernance à l'échelle de l'équipe qui devient automatique, l'évolution du rôle du DBA et le nouveau substrat que les agents partagent avec leurs homologues humains.

Faites la connaissance de Jen

Jen est le personnage de développeur issu de Evolutionary Database Design. Dans cet essai, elle a mis en œuvre une refactorisation de base de données – en divisant un champ inventory_code en location_code, batch_number et serial_number – comme une simple "user story" de routine, illustrant ainsi que les DBA et les développeurs peuvent collaborer, que les schémas peuvent évoluer par petits incréments et que les migrations permettent d'intégrer les changements en toute sécurité.

La série retrouve Jen vingt ans plus tard. La méthodologie qu'elle suit est la même qu'en 2003. La nouveauté réside dans le substrat sous-jacent à son flux de travail : le branching de base de données par copie sur écriture, qui rend les pratiques qu'elle a découvertes opérationnellement réelles à l'échelle de la production. À travers les trois parties de cette série, nous suivons la même Jen à trois échelles : sa journée (Partie 1), son nouveau guide pratique (Partie 2) et son équipe (Partie 3).

Partie 3 : L'équipe de Jen à l'échelle

Partie 1 a accompagné Jen dans le développement d'une fonctionnalité. Partie 2 a présenté le guide pratique en onze étapes que son travail suit en 2026. La Partie 3 applique ce même guide à une équipe de cinquante développeurs, où des agents créent des branches aux côtés des humains, et pose la question : qu'est-ce qui devient structurel à cette échelle ?

Trois éléments deviennent essentiels.

Premièrement, la topologie des niveaux (tiers), c'est-à-dire les branches à longue durée de vie qui représentent chaque environnement dans le parcours de promotion. Avec un seul développeur, vous aviez une branche de fonctionnalité (feature branch) et la production. À cinquante, vous disposez d'une hiérarchie structurée avec des voies stables et des voies éphémères superposées.

Deuxièmement, le modèle d'autorisation, le cadre qui définit qui peut faire quoi sur quelle branche. Avec un seul développeur, on pouvait se fier aux conventions. À cinquante, avec l'intégration d'agents, ce cadre doit être conçu une fois pour toutes et appliqué automatiquement.

Troisièmement, le rôle du DBA. Avec un seul développeur, le DBA était le partenaire de conception de Jen sur la PR. À cinquante, le DBA est l'ingénieur de plateforme qui a conçu le cadre dans lequel Jen et ses collègues évoluent.

Cet article aborde chacun de ces aspects, puis s'intéresse aux agents. Les agents sur la même capacité correspondent à la Pratique n° 11. Les agents sont comme des développeurs juniors : ils produisent du code qui s'exécute, des tests qui réussissent, des migrations qui s'appliquent et, sans encadrement, des systèmes impossibles à maintenir. Les tests sont le moyen pour l'équipe de s'assurer de leur rigueur. Le guide pratique TDD qui suit montre comment l'équipe fait passer les tests en premier.

Les niveaux (tiers) comme branches à longue durée de vie, et non comme des instances distinctes

Avant l'apparition du branching, un environnement était une instance : un déploiement Postgres dédié pour le staging, un autre pour l'UAT, un autre pour les tests de performance, chacun étant provisionné, corrigé, masqué et synchronisé séparément. La couche de compensation mentionnée dans la Partie 2 se situait également ici. Les écarts (drift) entre les environnements étaient structurels.

À l'échelle de l'équipe, le modèle de niveaux se simplifie en branches à longue durée de vie issues du même parent Lakebase.

Une branche est l'une de ces deux choses : un niveau (tier) (à longue durée de vie, parent dans la hiérarchie de promotion) ou une fonctionnalité (feature) (éphémère, issue d'un niveau et supprimée après usage). Un niveau a un parent. La chaîne de parenté constitue la hiérarchie de promotion.

Sur la Fig. 1, nous voyons une hiérarchie simple, où la branche principale (main) correspond à la production et où des branches de fonctionnalités (Feature) sont créées au besoin. Cette configuration est généralement utile pour le prototypage initial ou les travaux de début de projet avec une très petite équipe. Les équipes matures comptant plus de développeurs et/ou de nombreux environnements ont besoin d'une configuration telle que celle présentée ci-dessous.

Dans certaines entreprises, il est nécessaire de disposer d'une version candidate (RC). Cette version candidate est en cours de développement pendant un certain temps et, après des tests réussis, elle est promue en production. La Fig. 3 présente une configuration qui permet de développer des versions candidates et de les promouvoir ultérieurement en production, la branche de la version candidate étant ensuite supprimée.

Le nom des branches est arbitraire, ce qui importe, ce sont les conventions sur la façon dont les relations de parenté sont définies. Une politique interdisant les transitions qui contredisent la hiérarchie de la chaîne parentale peut être mise en œuvre pour empêcher une fusion directe de fonctionnalités.

Les définitions de politiques offrent de nombreux avantages pour la gestion des pipelines :

• Une seule définition de pipeline, sensible aux branches. Le pr.yml présenté dans la Partie 2 s'exécute pour chaque PR ; le merge.yml s'exécute pour chaque promotion. Le même flux de travail couvre les fonctionnalités, les niveaux et les transitions entre eux.
• La promotion est une fusion, pas un redéploiement. Le passage du staging à la production est un "git merge" dont l'effet en aval est une promotion de branche Lakebase. La migration s'applique une fois à chaque niveau, validée d'abord au niveau précédent, tout comme le code est validé dans les étapes antérieures.
• Aucune dérive (drift) entre « l'environnement de test » et la production. Chaque niveau descend du même parent. La différence de schéma (schema diff) entre deux niveaux est un élément réel et calculable : le schéma est une chaîne unique de pages avec des marqueurs de divergence, et non deux installations distinctes de logiciels de base de données. Cela permet aux équipes de ne pas avoir à gérer un parc de serveurs de bases de données à corriger et à mettre à niveau.

Retour arrière par réorientation. Une mauvaise promotion est corrigée en pointant l'application vers l'instantané du niveau précédant la promotion. L'instantané lui-même est une autre branche, ce qui permet aux équipes de se rétablir après des déploiements défectueux.

Attribution des coûts par project_id, branch_id, endpoint_id. Unity Catalog capture automatiquement les métadonnées. Une requête SQL sur les tables d'audit et de facturation permet de savoir qui a créé quelle branche, quand elle a été créée et combien coûte son maintien en activité.

Le grand nombre d'instances de base de données diminue également de manière drastique. Un monde de six instances d'environnement (prod, staging, UAT, QA, perf, demo) se réduit à un seul parent Lakebase avec une hiérarchie de branches à longue durée de vie liées au parent. L'instance utilisée pour provisionner, surveiller et corriger est désormais une branche logique ayant la même structure de données que la production, régie par les mêmes politiques que la production, et qui se réinitialise à l'état de production en une seconde si nécessaire.

Différentes conventions vous permettent de créer de nombreux types de branches en tant que parents. Une convention courante consiste à maintenir une branche contenant le schéma de la base de données et toutes les données de référence, afin que chacun puisse créer une branche à partir de celle-ci, la remplir avec des données de test ou exécuter des tests automatisés qui créent de vraies données, évitant ainsi tout conflit avec le staging ou d'autres branches.

Ce qu'il faut faire maintenant : le modèle d'autorisation

Pratique nº 10 Dans le guide de la Partie 2, nous avons abordé la gouvernance conçue une seule fois, héritée par branche. Voyons comment elle est mise en œuvre.

Le travail de conception ne bloque pas l'exécution. Il s'agit d'une conception structurelle que les tâches courantes peuvent ensuite appliquer.

Les décisions à prendre dès maintenant, avant que l'équipe ne s'agrandisse ou que des agents ne soient ajoutés :

• Création de branches à partir de chaque niveau. Créer une branche à partir de la production requiert une autorisation différente de celle requise pour créer une branche à partir du staging ou d'une fonctionnalité. Par défaut, les fonctionnalités doivent être créées à partir du niveau d'entrée (le plus bas), jamais à partir de la production. Les branches de production sont réservées aux flux de correction urgente (hotfix) et de restauration.
• Promotion entre les niveaux. Une promotion « fonctionnalité vers staging » relève de la revue de code. Une promotion « staging vers production » relève de la coordination des versions. Il s'agit de deux étapes distinctes avec des réviseurs différents, ce qui garantit l'indépendance des équipes métiers et de développement.
• Lecture vs écriture. L'accès en lecture à des données structurées comme la production sur une branche ne requiert pas la même autorisation que l'accès en écriture à cette branche. De nombreux rôles d'ingénierie ont besoin de la lecture ; peu ont besoin de l'écriture.
• Politiques Unity Catalog. Unity Catalog Les politiques Unity Catalog telles que le masquage, les filtres de lignes et les autorisations au niveau des colonnes s'appliquent à la production. Ces politiques sont héritées par défaut sur chaque branche descendante ; les exceptions spécifiques à un niveau (par exemple, un niveau QA avec des PII synthétisées pour les tests de charge) sont déclarées une seule fois.
• Captures de la piste d'audit. Chaque création de branche, chaque promotion, chaque application de migration, chaque modèle d'accès, dans un seul endroit interrogeable.

Le principe qui permet de faire fonctionner cela à l'échelle de l'équipe : les rôles déclarent, la politique applique. L'ingénieur de plateforme déclare la hiérarchie des niveaux, le modèle d'autorisation, les chemins de promotion et la posture de la politique Unity Catalog. La politique refuse toute transition qui contredit ce qui a été déclaré. Il n'y a aucun endroit où un humain ou un agent peut contourner une limite déclarée en réessayant l'opération sous une autre forme.

C'est le travail à faire aujourd'hui, avant que l'équipe ne compte cinquante développeurs et que des agents ne créent des branches plus rapidement qu'aucun humain ne pourrait les examiner. Le framework est ce qui unit l'équipe grâce à des conventions partagées et des garde-fous. Tout le reste fonctionne à l'intérieur de celui-ci.

Le nouveau rôle : de DBA à ingénieur de plateforme

Il y a vingt ans, la conclusion de l'essai de 2003 Evolutionary Database Design faisait écho à ce qui suit :

« L'utilisation des techniques que nous décrivons ici peut sembler représenter beaucoup de travail, mais en réalité, elle ne nécessite pas un grand nombre de personnes. Sur de nombreux projets, nous avions une trentaine de développeurs et une équipe (comprenant la QA, les analystes et la direction) de près de cent personnes. Chaque jour, nous avions une centaine de copies de divers schémas sur les postes de travail des collaborateurs. Pourtant, toute cette activité ne nécessitait qu'un seul DBA à plein temps, avec quelques développeurs comprenant le fonctionnement du processus et du flux de travail. »

Cet argument reste valable en 2026, soutenu par cinq arguments supplémentaires.

1. Le ratio reste le même, avec plus de marge de manœuvre par DBA. Un DBA à plein temps pour environ 100 personnes, avec plus d'une centaine de branches simultanées en cours, engendre un coût par branche inférieur, car la création de branche est désormais une opération de métadonnées d'une seconde. Le ratio n'est pas le plus important. Ce qui compte, c'est la façon dont le DBA utilise ses heures.

2. Le travail se déplace plus haut dans la pile. Les heures consacrées en 2003 au provisionnement de l'infrastructure, au provisionnement des schémas, au contrôle des accès et aux interventions manuelles occasionnelles sont désormais consacrées à la conception de politiques de création de branches, aux politiques de masquage, aux flux de promotion et à l'observabilité de la piste d'audit. Les livrables concrets : des bots de comparaison de schémas (schema-diff) qui publient sur chaque PR, des tâches planifiées qui réinitialisent les branches de développement chaque nuit, des tableaux de bord d'observabilité qui suivent le cycle de vie des branches et la conformité TTL, des définitions CI qui bloquent les fusions lors de la validation des schémas. Il s'agit d'un travail de conception de plateforme, d'un niveau bien plus élevé qu'auparavant.

3. Les agents entrent en jeu. Une chose que l'essai de 2003 n'avait pas à gérer était l'écriture de code par des agents. Neon signale environ un demi-million de branches par jour, dont plus de 80 % sont créées par des agents. Un seul DBA ne peut pas filtrer ce volume par tickets. L'évolution du rôle vers celui d'architecte de plateforme est la seule approche viable à l'échelle des agents.

4. Les chiffres deviennent concrets. Une équipe de six développeurs génère généralement plus de 30 tickets opérationnels par sprint dans l'ancien modèle (provisionnement, revues de schémas, rafraîchissements de données, octrois d'accès). Dans le modèle natif de branche : moins de 5 revues de politiques à forte valeur ajoutée par sprint. La charge de travail répétitive du DBA passe de plus de 20 heures par semaine à moins de 5, et le MTTR passe de plus de 4 heures à moins de 30 minutes. Cette réduction des tâches répétitives peut aider le DBA à collaborer avec les développeurs pour trouver des solutions optimales pour les fonctionnalités en cours de développement.

5. La piste d'audit devient un tableau de bord stratégique. Ce qui nécessitait auparavant de croiser trois services et trois langages de requête se résume désormais à une seule requête SQL sur les tables système de la plateforme. Chaque branche, chaque action, chaque coût, chaque événement de gouvernance au même endroit. Le DBA ne crée pas cette vue manuellement ; c'est la plateforme qui s'en charge.

Dans l'avant-propos de Refactoring Databases (2006), Martin Fowler espérait que le livre ne représentait « qu'une première étape » vers des outils qui automatiseraient le refactoring de bases de données de la même manière que les IDE automatisent le refactoring de code. La création de branches est cette étape suivante. Ce que Fowler espérait en 2006, à savoir une modification disciplinée des bases de données à la vitesse du code, est précisément ce que la plateforme offre aujourd'hui. Le DBA conçoit la discipline ; la plateforme l'applique.

Le titre de ce nouveau rôle varie (ingénieur de plateforme, responsable de plateforme de base de données, ou toujours DBA de nom). La substance reste la même : la personne qui conçoit le framework au sein duquel tous les autres travaillent.

Les agents dotés de la même capacité

Pratique nº 11 Dans la Partie 2, nous avons décrit l'agent de codage en tant que praticien doté de la même capacité de création de branches. Discutons-en.

Les agents ont accès aux branches, pas à la production. Les mêmes règles de flux de travail qui s'appliquent à Jen s'appliquent à l'agent. Les tests s'exécutent sur une véritable base de données sur une branche, et non sur des simulations qu'un agent pourrait modifier ou supprimer. Des comparaisons de schémas sont générées pour chaque PR, quel que soit l'auteur de la migration. Les politiques qui protègent Jen protègent également l'agent.

Mais les politiques seules ne suffisent pas. Les agents, s'ils ne sont pas encadrés, sont comme des développeurs juniors.

Un développeur junior, à qui l'on confie un ticket de fonctionnalité sans autre directive, peut produire du code qui compile, des tests qui réussissent et un script de migration qui s'applique sans problème. Le code pourrait également dupliquer une logique déjà présente ailleurs dans la base de code, introduisant ainsi de la redondance. La migration pourrait ajouter une colonne avec le bon nom mais le mauvais type. Le test pourrait réussir simplement parce qu'il ne teste que le cas nominal (happy path). Aucun de ces défauts n'apparaît lors de l'exécution réussie (au vert) de la CI ; ils surgissent six semaines plus tard, lorsque quelqu'un d'autre doit faire évoluer le travail.

Les agents font exactement la même chose, mais beaucoup plus rapidement et à un volume bien plus élevé.

Sans directives explicites, un agent va :

• Réinventer un pattern déjà présent dans la base de code.
• Créer une modification de schéma qui semble correcte mais ignore les mécanismes de transition de refactoring définis (par exemple, supprimer une colonne sans déplacer préalablement les données, ou ajouter une colonne NOT NULL sans mettre à jour les lignes existantes).
• Écrire des tests qui réussissent sur la structure de données qu'il a imaginée, et non sur celle qui existe réellement en production.
• Créer des migrations qui s'appliquent mais génèrent un état incohérent en cas de rollback.
• Superposer des couches d'abstraction pour répondre à un changement mineur.

Le substrat garantit l'authenticité de la barre verte (pas de mocks ; une véritable base de données sur une branche). En revanche, il ne rend pas le code maintenable.

L'équipe assure la maintenabilité du code grâce à quatre piliers de renforcement :

• Garde-fous : le modèle de permissions. Les agents ne peuvent pas créer de branches à partir de la production, ne peuvent pas effectuer de promotion entre les différents niveaux (tiers), et ne peuvent pas appliquer de migrations à un niveau dont ils ne sont pas propriétaires. Le substrat s'y oppose.
• Patterns : les refactorings nommés. Le catalogue de 2006 sur databaserefactoring.com répertorie plus de 70 refactorings avec des mécanismes de transition explicites. Un agent guidé pour « appliquer le refactoring Split Column » produira une migration différente d'un agent simplement invité à « diviser cette colonne ».
• Workflow : la machine à états de gestion du contrôle de source (SCM). Les agents suivent une séquence d'états séparés par des barrières (gates) bloquantes. Le substrat refuse les transitions qui ne respectent pas le contrat déclaré.
• Revue : des humains dans la boucle de PR. Le diff de schéma est visible sur chaque PR, avec le DBA intégré au processus de revue. La pratique n°1 reformulée dans la Partie 2 a rendu ce processus asynchrone ; à l'échelle d'une équipe, avec l'intégration d'agents, cette revue asynchrone est précisément ce qui permet de détecter les dérives que les tests n'ont pas relevées.

Le workflow SCM est le pilier central. Dans le Lakebase App Dev Kit, la gestion du contrôle de source va au-delà de la simple branche de code : elle englobe le branching jumelé (la branche de code et la branche Lakebase gérées comme une seule entité, comme présenté dans la Partie 1). Ce branching jumelé, proposé comme fonctionnalité dans le substrat commun du Lakebase App Dev Kit, impose des garde-fous communs tels que le refus des fusions contredisant la hiérarchie, la migration qui accompagne la branche, les barrières de CI, et la fusion qui applique la migration au niveau parent. Le kit de développement fournit ce workflow SCM sous la forme d'une machine à états exécutable.

La Fig. 4 ci-dessus décrit les cents états durant le développement : scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Chaque transition entre les différents états est pilotée par une commande CLI (lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge). Chaque commande CLI valide les préconditions avant d'exécuter une tâche, effectue la transition et enregistre le nouvel état dans .lakebase/workflow-state.json (une surface de contrôle validée par schéma). L'échec d'une barrière laisse la machine dans un état récupérable à l'étape précédente. Ces barrières sont bloquantes et non simplement indicatives.

Les agents appellent ces CLI, ils ne peuvent pas inventer de chemin parallèle. Le substrat refuse de faire avancer la machine à états en cas d'échec d'une précondition : une branche de fonctionnalité rattachée au mauvais niveau parent est rejetée ; une tentative de fusion avant que la CI ne soit au vert est refusée ; un fichier d'état incohérent bloque la barrière suivante. Les contrats de transfert (handoff) relèvent du rôle de scrum-master ; le substrat les fait respecter. Les décisions structurelles (la hiérarchie des niveaux, le niveau source d'une fonctionnalité, le chemin de promotion) appartiennent à l'architecte ou au scrum-master, sont enregistrées, puis respectées par le substrat. Le substrat n'invente jamais de niveau ou de parent ; il respecte ce qui a été déclaré et refuse les transitions qui y contredisent.

C'est ce cadre qui bouscule la façon dont les équipes utilisaient les agents jusqu'à présent. L'intégration naïve traite l'agent comme un ingénieur senior dans une fenêtre de chat : on lui fournit du contexte, on lui demande un résultat, puis on procède par itération. Cela fonctionne à l'échelle d'un seul développeur, mais échoue à l'échelle d'une équipe, car le « contexte » de l'agent ne peut être ni revu, ni gouverné, ni rejoué. Traisez plutôt l'agent comme un développeur junior : confiez-lui une tâche précise et documentée au sein d'une machine à états exécutable, validez son résultat par rapport à un schéma, passez la barrière suivante, puis recommencez. Le substrat applique les règles ; le fichier d'état du workflow sert d'API.

Fiches pratiques pour le travail à l'échelle de l'équipe

La Partie 2 a présenté les pratiques n°10 et n°11 parmi les Pratiques émergentes pour 2026

Pratique n°10 : Une gouvernance conçue une fois pour toutes, héritée par branche

Règle. Le modèle de permissions, les politiques Unity Catalog pour gérer le contrôle d'accès et la capture des pistes d'audit sont conçus une seule fois sur la branche principale (trunk) et hérités automatiquement par chaque branche descendante.

Pourquoi est-ce une habitude durable aujourd'hui ? À l'échelle d'une équipe, la gouvernance doit relever de la responsabilité du DBA ou de l'ingénieur plateforme, et non être une discipline qu'un développeur doit s'efforcer de mémoriser. Les branches sont créées et détruites en quelques secondes ; configurer manuellement la gouvernance pour chaque branche annulerait le gain de temps offert par le branching.

Mécanismes :

• Déclarer la hiérarchie des niveaux : quelles branches à longue durée de vie existent, quels sont leurs liens de parenté et quelle posture de gouvernance chaque niveau adopte.
• Déclarer les limites de permissions : qui peut créer des branches à partir de chaque niveau, qui peut effectuer des promotions entre les niveaux, et qui dispose des droits de lecture ou d'écriture.
• Déclarer l'héritage des politiques Unity Catalog : le masquage, les filtres de lignes et les permissions au niveau des colonnes héritées par défaut du parent ; les exceptions spécifiques à un niveau sont déclarées une seule fois. La propagation automatique sur tous les types de politiques Unity Catalog est en cours de finalisation ; concevez le framework en ciblant l'état final souhaité.
• Déclarer la capture des pistes d'audit : chaque création de branche, chaque promotion, chaque application de migration et chaque modèle d'accès est automatiquement enregistré dans des tables système interrogeables.
• Le DBA ou l'ingénieur plateforme fait appliquer ces règles par le biais de politiques. Toute transition qui contredit le modèle déclaré est refusée.

Anti-pattern. Configurer la gouvernance par branche au moment de l'exécution (runtime). L'intérêt de la déclarer une seule fois est que le framework reste efficace même lorsque les branches sont créées plus rapidement qu'un humain ne peut les examiner. Une configuration manuelle par branche recréerait le goulot d'étranglement que le branching vient précisément de supprimer.

Là où l'équipe de Jen va plus loin. L'ingénieur de plateforme ou le DBA de Jen a déclaré la hiérarchie des niveaux lors de la création du projet. Chaque branche créée par Jen, ses coéquipiers ou les agents de l'équipe hérite de la configuration de masquage, de permissions et d'audit déclarée. Lorsque l'équipe ajoute un nouveau niveau, le framework enregistre le nouveau lien parent ; les fonctionnalités en cours de développement conservent leur parent d'origine (pas de changement de parent rétroactif) ; les nouvelles fonctionnalités sont créées à partir du nouveau niveau d'entrée.

Pratique nº 11 : L'agent en tant que praticien avec la même capacité de création de branches

Règle. Les agents opèrent au sein de la machine à états exécutable du workflow SCM : cinq états, des barrières bloquantes entre eux, et des fichiers d'état validés par schéma. Les mêmes règles de workflow régissent Jen et l'agent ; un substrat commun les applique, peu importe qui agit.

Pourquoi est-ce une habitude durable désormais ? La création de branches est une opération de métadonnées, ce qui rend possible un volume d'activité généré par les agents. Le substrat développé pour les agents peut refuser les transitions qui contredisent la hiérarchie des niveaux déclarée ou l'état enregistré de la barrière. Il n'y a pas de contexte de fenêtre de chat sur lequel se rabattre ; seul l'artefact sur le disque (workflow-state.json) franchit la limite entre les transitions de barrière.

Fonctionnement :

• La machine à états SCM comporte cinq états : scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Chaque transition est pilotée par une CLI ; chaque CLI valide les préconditions avant d'exécuter le travail.
• L'interface de la barrière est .lakebase/workflow-state.json, validée par rapport à scm-workflow-state.schema.json. Chaque transition écrit le nouvel état et les invariants requis par la barrière suivante.
• Les décisions structurelles (hiérarchie des niveaux, niveau source par fonctionnalité, chemin de promotion, contrats de transfert) appartiennent aux rôles (architecte ou scrum-master), sont enregistrées, puis appliquées par le substrat.
• Les agents appellent les CLI. Le substrat applique les règles ; les agents ne peuvent pas les contourner. L'échec d'une barrière permet de restaurer la machine à états à son état précédent ; l'agent ne tente pas de « réessayer sous une autre forme ».
• Les barrières CI qui s'exécutent de pr-ready à ci-green testent un vrai Postgres sur une branche, avec le diff de schéma publié sur la PR. C'est par rapport à l'état réel de la base de données que le travail de l'agent est évalué.

Anti-pattern. Traiter un agent comme un ingénieur senior dans une fenêtre de chat en utilisant l'approche « vider le contexte et demander un résultat » fonctionne à l'échelle d'un seul développeur, mais échoue à l'échelle d'une équipe car le « contexte » ne peut pas être examiné, gouverné ou rejoué. Utilisez plutôt le modèle de l'artefact en tant qu'API : les agents LISENT workflow-state.json et les entrées documentées pour leur phase ; ils ÉCRIVENT les sorties documentées ; les validateurs vérifient ; la barrière suivante ne se déclenche que si le contrat est respecté.

Là où l'équipe de Jen va plus loin. Chaque agent de l'équipe de Jen opère au sein de la même machine à cinq états que Jen et ses coéquipiers. Le rôle de scrum-master est propriétaire des contrats de transfert ; le substrat refuse les transitions qui ne les respectent pas. Un agent ne peut pas livrer une fonctionnalité créée à partir du mauvais niveau ; un agent ne peut pas fusionner avant que la CI ne soit verte ; un agent ne peut pas contourner l'artefact de diff de schéma. Le framework tient bon, peu importe qui ou quoi a initié l'action.

Le TDD comme couche optionnelle intégrée par-dessus

La pratique nº 11 établit le workflow SCM comme référence : chaque utilisateur du kit le suit, qu'il s'agisse d'agents ou d'humains. Le TDD est une considération distincte qui se superpose à cette référence pour les équipes qui souhaitent adopter une discipline de développement piloté par les tests. Il est optionnel ; les barrières SCM sont obligatoires quel que soit le chemin emprunté.

Pourquoi les tests sont importants, même avant le TDD : lorsque les agents rédigent du code, les tests sont le seul moyen de contrôle qui passe à l'échelle. Kent Beck, dans son interview de 2026 Pragmatic Engineer, a publiquement désigné ce mode de défaillance : il a du mal à empêcher les agents IA de supprimer des tests pour les faire réussir. La barre verte est facile à obtenir lorsque rien dans la boucle ne force l'agent à se confronter à la structure réelle du système. Les mocks rendent cela trivial. Les substituts en mémoire également.

La création de branches rend la barre verte honnête au niveau de la couche de données. C'est par rapport à une vraie base de données sur une vraie branche que l'agent effectue ses tests ; les contraintes de schéma rejettent les insertions de lignes non conformes, les clés étrangères rejettent les orphelins, la structure réelle des données expose des hypothèses que le mock aurait acceptées silencieusement, et l'agent ne peut pas supprimer de tables. Le coût d'une fausse conformité augmente avec ces garde-fous.

Mais le substrat est nécessaire, pas suffisant. Les tests doivent bien venir de quelque part. Si l'agent les écrit, il peut aussi les supprimer. C'est cette lacune que le TDD comble.

Le workflow TDD se superpose au workflow SCM. Il se déclenche entre les états SCM feature-claimed et pr-ready ; il appelle SCM pour les opérations de branche (les branches d'expérimentation de cycle utilisent la primitive SCM sous-jacente) ; il n'effectue pas d'appels ascendants vers SCM. La dépendance est unidirectionnelle. Les équipes qui ne souhaitent pas utiliser la couche TDD peuvent livrer des fonctionnalités en modifiant directement le code sur la branche de fonctionnalité, tout en respectant chaque barrière SCM.

Le Lakebase App Dev Kit fournit le workflow TDD sous la forme d'une deuxième machine à états, avec ses propres agents par rôle et ses propres validateurs de barrières :

• Spec-author transforme le récit d'un demandeur en un artefact de fonctionnalité structuré, validé par schéma.
• Architect-reviewer associe les exigences non fonctionnelles et les principes d'architecture de la fonctionnalité à des décisions architecturales, générées sous forme de architecture.json et de texte explicatif.
• Test-strategist produit la liste de tests et les scénarios par critère d'acceptation, générés sous forme de test-list.json et de markdown rendu. Chaque NFR a au moins un critère d'acceptation (AC) ; chaque AC a un scénario.
• Scrum-master orchestre les cycles de build. Chaque cycle crée une branche d'expérimentation (en utilisant le substrat SCM sous-jacent), exécute un agent pilote (driver) pour implémenter l'AC suivante, et exécute un agent navigateur (navigator) pour examiner et valider le résultat.
• Driver et navigator sont le rédacteur de tests et le rédacteur de code de la boucle interne, fonctionnant en binôme, selon l'approche RED-GREEN-REFACTOR.

Chaque rôle dispose d'entrées et de sorties documentées, validées par rapport à un schéma. Chaque agent reçoit uniquement ses entrées documentées ; les sorties sont validées avant l'exécution du rôle suivant. L'artefact constitue l'API entre les rôles ; le schéma fait office de vérification de type. Un artefact manquant est traité comme une barrière échouée. Un artefact malformé est traité comme un artefact manquant. La couche TDD emprunte le même modèle d'artefact en tant qu'API que celui établi par la pratique nº 11 pour le SCM.

La couche TDD se trouve dans le guide d'accompagnement Companion: Lakebase App Dev Kit (open-source, avec un e-book d'accompagnement pour les praticiens humains). Les machines à états SCM et TDD, les contrats d'agent par rôle, les vérifications de conformité des artefacts et les validateurs de barrières sont tous fournis sous forme de CLI que n'importe quel orchestrateur (le kit, l'extension IDE, un job CI, une session de terminal humaine) peut appeler.

En résumé : le SCM est la référence (pratique nº 11). Le TDD est une couche supérieure. La création de branches rend les tests honnêtes ; le TDD permet de faire passer les tests en premier ; le kit rend ces deux workflows exécutables.

Ce que montre l'équipe de Jen

La partie 1 a guidé Jen à travers une fonctionnalité : elle a associé une branche de code à une branche Lakebase, a exécuté une véritable migration sur des données structurées comme en production en quelques secondes, a testé sans mocks, a ouvert une PR avec le diff de schéma publié en ligne pour révision, et a fusionné une fois la migration appliquée et les branches éphémères nettoyées. Les modifications de base de données font désormais partie intégrante du développement normal.

La partie 2 a défini le guide pratique : les sept pratiques de 2003, les limites qui ont maintenu cinq d'entre elles à l'état d'aspirations jusqu'en 2026, ces sept mêmes pratiques reformulées une fois la création de branches disponible, plus deux nouvelles pratiques que la technologie permet pour le développeur individuel. Neuf pratiques au quotidien, deux autres émergeant à l'échelle de l'équipe.

La partie 3 a étendu le guide pratique à l'équipe. Elle a défini la topologie des niveaux, décrivant comment les branches à longue durée de vie résident au sein d'un parent Lakebase unique, comment le modèle de permissions devient l'artefact de conception de l'ingénieur plateforme, déclaré une fois et appliqué par le substrat (Pratique #10). Comment le rôle du DBA achève son évolution vers celui d'architecte plateforme, avec de nouveaux renforcements de l'argument de dotation en personnel de 2003. Les agents entrent dans le workflow avec la même capacité, au sein de la machine d'état exécutable du workflow SCM, le substrat appliquant les portes de validation indépendamment de qui ou de quoi agit (Pratique #11). Le TDD est une couche optionnelle intégrée par-dessus : une discipline axée sur les tests d'abord avec des rôles dédiés, des portes de validation et des contrats d'artefacts, pour les équipes qui le souhaitent.

Le Companion : Plugin Walkthrough présente l'extension Lakebase SCM Extension pour VS Code et Cursor de bout en bout.

Le Companion : Lakebase App Dev Kit, accompagné d'un e-book pour les praticiens humains, couvre le workflow TDD ci-dessus : les machines d'état SCM et TDD, les agents par rôle, les validateurs de portes de validation et les contrats d'artefacts qui permettent d'intégrer les agents à l'équipe en toute sécurité.

La méthodologie était claire depuis vingt ans. La capacité technique est arrivée en 2026. Le guide pratique pour les praticiens humains et les agents est désormais opérationnel. L'équipe de Jen compte cinquante développeurs et une flotte d'agents ; le workflow est le même.

Conclusion : La capacité de créer des branches de base de données offre désormais une immense flexibilité à l'équipe de développement pour provisionner des bases de données, concevoir des tests par rapport à des schémas réels, exécuter la CI pour chaque création de PR sur sa propre base de données et permettre aux agents de travailler de cette manière, le tout avec le cadre de gouvernance de Unity Catalog qui applique les politiques.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original