Qu est-ce que le trunk based development : guide 2026
Résumé
Le trunk based development est une stratégie de branches où chaque développeur intègre sur `main` au moins une fois par jour. Il n'existe pas de branches longue durée : le code reste en état production-ready à tout moment. Les fonctionnalités incomplètes sont masquées par des feature flags, pas isolées dans une branche. C'est l'une des 24 capacités que les recherches DORA associent aux équipes à haute performance en livraison logicielle.
Qu est-ce que le trunk based development : guide 2026
Le trunk based development est une stratégie de branches où chaque développeur intègre sur main (parfois appelé trunk) au moins une fois par jour. Il n'existe pas de branches longue durée. Le code reste en état production-ready à tout moment. Si une fonctionnalité n'est pas prête, un feature flag la masque pour les utilisateurs, pas une branche qui l'isole du reste de l'équipe.
C'est la version courte. La version longue, c'est pourquoi votre workflow actuel génère peut-être plus de risques que vous ne le réalisez.
Pourquoi les branches longue durée deviennent un boulet
La plupart des équipes apprennent le contrôle de version avec des feature branches : une branche par ticket, fusionnée après revue. Ça semble organisé.
Dès qu'une branche vit plus de 24 heures, chaque commit que vos collègues poussent sur main est un conflit futur que vous n'avez pas encore vu. Sur une équipe de huit ingénieurs tenant chacun une branche de deux semaines, vous ne gérez pas une intégration. Vous administrez huit mondes parallèles qui divergent un peu plus chaque jour. Le merge day n'est pas une tâche. C'est une négociation.
Les recherches DORA, la plus grande étude longitudinale sur la performance en livraison logicielle menée sur des milliers d'équipes, tracent une ligne claire : les branches qui vivent plus de 24 heures sont un signal prédictif de fréquences de déploiement plus basses et de taux d'échec plus élevés. Les équipes elite intègrent plusieurs fois par jour. Les autres fusionnent quand la fonctionnalité est "terminée", ce qui signifie souvent jamais proprement.
Le coût caché n'est pas le conflit de merge en lui-même. C'est le changement de contexte nécessaire pour le résoudre trois semaines après avoir écrit le code. Personne ne se souvient de l'intention d'origine.
Comment fonctionne le trunk based development en pratique
La mécanique est directe. Vous tirez main. Vous faites un changement petit et cohérent. Vous lancez la suite de tests. Vous poussez sur main. Tout cela avant d'aller déjeuner.
Pour un contributeur solo sur un petit dépôt, c'est déjà le fonctionnement habituel. Pour une équipe de vingt sur un monorepo de 300K LOC, il faut trois pratiques qui fonctionnent ensemble.
Branches courte durée (optionnel mais courant) : certaines équipes tolèrent des branches jusqu'à deux jours avant d'imposer un merge. Cela préserve la culture de revue de code sans créer de divergence sur plusieurs semaines. La branche sert de support de revue, pas de mécanisme d'isolation.
Intégration continue sur chaque push : chaque commit sur main déclenche un build complet et une suite de tests. Si ça casse, ça casse en minutes, pas après qu'une branche de deux semaines atterrit le vendredi à 16h.
Feature flags pour les travaux incomplets : les fonctionnalités inachevées partent en production derrière un flag. Les utilisateurs ne voient rien. L'équipe intègre tout. C'est la partie que la plupart des équipes sautent, et c'est pourquoi leur première expérience TBD échoue.
Aucune de ces pratiques n'est exclusive au trunk based development. La différence est que le TBD les rend toutes les trois obligatoires plutôt qu'optionnelles.
Les feature flags : le mécanisme qui rend le TBD possible
Un feature flag est un conditionnel dans votre code qui s'évalue à l'exécution. Quand un flag est off, le nouveau chemin de code ne s'exécute pas. Quand il est on, pour un utilisateur spécifique, un pourcentage du trafic ou toute la base utilisateur, il s'exécute.
Ça paraît trivial. L'implication ne l'est pas : vous pouvez séparer déploiement et mise en production. Le code part en production en continu. Les fonctionnalités se lancent quand elles sont prêtes, ou pas du tout si le déploiement part en vrille et que vous devez le couper en dix secondes plutôt que de revenir sur trois semaines de commits.
L'installation minimale viable requiert trois choses : un moyen de définir des flags, un moyen de les évaluer à l'exécution, et un moyen de les modifier sans redéployer. Un fichier JSON plat suffit pour une équipe de trois. Un service de gestion de feature flags mérite sa complexité autour de dix ingénieurs, ou quand les flags commencent à nécessiter des règles de ciblage comme "activé pour les utilisateurs de la cohorte bêta en Allemagne".
Un point à surveiller : la dette de flags. Les flags qui ne sont jamais nettoyés après la mise en production de la fonctionnalité deviennent du spaghetti conditionnel. Une équipe qui pratique le TBD correctement retire chaque flag dans le sprint qui suit le déploiement complet. Traitez les flags comme un échafaudage temporaire, pas comme une configuration permanente.
TBD versus Gitflow : comparaison directe en 2026
Gitflow a été conçu en 2010 pour des logiciels livrés en boîte sur un cycle trimestriel. Il modélise les releases comme des branches longue durée. Pour les équipes qui déploient chaque jour ou chaque heure, ce modèle ne correspond plus.
Voilà à quoi ressemble la comparaison pour une équipe qui fait du CI/CD :
Durée de vie des branches : Gitflow court de plusieurs jours à plusieurs semaines. Le TBD court de quelques heures à un maximum de 1 à 2 jours.
Conflits de merge : Gitflow produit des conflits fréquents et sévères. Le TBD en produit de rares et de faibles, parce que les écarts d'intégration se mesurent en heures, pas en semaines.
Fréquence de déploiement : Gitflow lie le déploiement à une branche de release. Le TBD découple entièrement déploiement et mise en production.
Mécanisme de rollback : Gitflow revient en arrière en annulant un merge de branche. Le TBD revient en arrière en éteignant un feature flag.
Complexité d'onboarding : Gitflow requiert de comprendre les conventions develop/main/hotfix. Le TBD n'a qu'une seule branche : main.
Investissement CI requis : Gitflow est faible, les branches absorbent le risque. Le TBD est élevé, main doit rester verte à tout moment.
Gitflow n'est pas faux dans tous les contextes. Si vous livrez une application mobile vers un App Store et ne pouvez pas pousser des correctifs en quelques minutes, un modèle de branche de release est logique. Si vous gérez un SaaS où vous contrôlez les déploiements, la structure de branches supplémentaire est un surcoût de coordination sans bénéfice de sécurité.
Ce que les métriques DORA disent des stratégies de branches
Les recherches DORA State of DevOps suivent la performance en livraison logicielle depuis 2014. Deux résultats sont directement pertinents ici.
Premièrement, le trunk based development est l'une des 24 capacités qui prédisent la performance dans le modèle DORA. Il appartient au cluster "livraison continue", ce qui signifie que DORA le traite comme une pratique d'infrastructure, pas comme une préférence d'équipe.
Deuxièmement, les équipes elite déploient plusieurs fois par jour. Les moins performantes déploient une fois par semaine ou une fois par mois. Les branches longue durée et l'intégration peu fréquente apparaissent à l'extrémité lente de cette distribution sur plusieurs années de données.
Ce que la recherche ne prétend pas : que le TBD cause la performance elite. Les équipes qui adoptent le TBD avec succès ont tendance à disposer déjà de tests automatisés, d'un pipeline CI fonctionnel, et d'une habitude de petits commits. Le trunk based development met ces lacunes en évidence immédiatement si elles sont absentes. Une équipe sans CI et avec 40% de flakiness sur les tests ne bénéficiera pas d'un passage au TBD. Elle cassera main plus souvent, c'est tout.
Quand le trunk based development ne s'applique pas
Trois scénarios où le TBD crée plus de problèmes qu'il n'en résout.
Environnements fortement réglementés avec des gates d'approbation obligatoires avant la mise en production : si chaque release nécessite une validation compliance avant de partir, le déploiement continu en production est bloqué de toute façon. La stratégie de branches devient secondaire. Vous regrouperez les changements quelle que soit la convention.
Suites de tests insuffisantes : le TBD requiert un pipeline CI rapide et fiable. Si les builds prennent 45 minutes et ont 20% de flakiness, les développeurs regrouperont les commits pour éviter d'attendre. Ça contourne le modèle. La contrainte est l'infrastructure de tests, pas la convention de branches.
Équipes très larges avec une propriété du code incohérente : sur des équipes de 50+ où chaque squad possède un service distinct, le TBD fonctionne bien au niveau du service. L'appliquer sur un monorepo partagé où tout le monde touche à tout requiert des conventions de lint strictes et des règles de propriété CI pour garder main propre.
Dans les trois cas, le correctif n'est pas une stratégie de branches différente. C'est le problème d'infrastructure sous-jacent. Le TBD rend juste ce problème visible plus rapidement.
Migrer sans bloquer les livraisons en cours
La migration que la plupart des équipes ratent : elles annoncent le TBD, suppriment la convention de feature branches, et regardent main casser dès la première semaine.
Un chemin plus sûr :
Gardez les branches existantes, ajoutez une règle de durée de vie : aucune branche ne vit plus de 3 jours. Cela force la pression d'une intégration fréquente sans couper le courant.
Instrumentez votre CI d'abord : avant que les merges aillent vite, ils doivent être sûrs. Assurez-vous que la suite de tests est verte, tourne en moins de 15 minutes, et bloque la branche main en cas d'échec.
Choisissez une fonctionnalité à gater avec un flag : construisez le réflexe de gestion des flags avant d'en avoir besoin pour chaque travail incomplet.
Réduisez la durée de vie des branches semaine par semaine : de 3 jours à 2 jours à 1 jour sur six semaines. Suivez la fréquence des conflits de merge comme indicateur avancé. Quand elle chute, le modèle fonctionne.
Ne retirez l'ancienne convention que quand la nouvelle fonctionne : les conventions Gitflow restent en place pour tout ce qui est hors du pilote. Faire tourner les deux modèles pendant 6 à 8 semaines, c'est acceptable.
L'habitude qui prédit si le TBD va durer
Le trunk based development n'échoue pas parce que les équipes ne savent pas fusionner sur main. Il échoue parce que les développeurs n'ont pas l'habitude de dimensionner les tâches assez petites pour livrer en une journée.
Le changement sous-jacent n'est pas technique. C'est la façon dont le travail est défini lors de la planification. Une user story qui dit "implémenter le nouveau flux de paiement" est une branche de deux semaines qui attend de naître. Une user story qui dit "ajouter le handler de route et retourner un 501 derrière le flag payment-v2" est un commit d'une demi-journée.
Cela requiert l'implication du PM et une hygiène du backlog que la plupart des équipes n'ont pas encore construite. Le changement de stratégie de branches prend une journée à annoncer. La discipline de dimensionnement prend six mois à construire.
Si votre équipe livre déjà des logiciels fonctionnels en production chaque jour, le TBD formalise ce que vous faites déjà. Si votre équipe livre toutes les deux semaines avec un merge massif à la fin, le TBD ne sera pas confortable tant que les habitudes de livraison sous-jacentes ne changent pas.
Les équipes qui s'accrochent au TBD sont celles qui ont investi dans trois éléments avant de basculer : un pipeline CI sous les 15 minutes, un service de feature flags opérationnel, et des cérémonies de sprint qui produisent des stories assez petites pour se clore en une journée. Sans ces trois éléments, la convention de branches est le mauvais levier.
Les outils qui aident les équipes à faire tourner des workflows TBD
Pratiquer le trunk based development au niveau de l'équipe implique davantage d'alignement synchrone : des standups rapides pour repérer les dérives d'intégration, des conventions documentées pour les flags et les règles CI, et des sessions de revue en binôme sur les chemins critiques.