# Qu'est-ce que le trunk based development ? Guide concret
URL: https://whatshouldibuildnext.com/fr/journal/qu-est-ce-que-le-trunk-based-development
Type: blog
Locale: fr
Published: 2026-10-24
Updated: 2026-10-26
---
> Le trunk based development : fusionner petit et souvent dans une seule branche partagée. Définition, avantages, feature flags et première semaine pour se lancer.
Qu'est-ce que le trunk based development ? C'est un modèle de branches où tout le monde fusionne de petits changements dans une seule branche partagée, appelée main ou trunk, au moins une fois par jour. Les branches, si vous en gardez, vivent quelques heures et jamais plusieurs semaines. Le travail inachevé part en production derrière un feature flag, si bien que le trunk reste livrable à chaque commit. L'idée tient en une phrase, et elle est moins exotique que son nom.
Voici la scène qui rend le sujet concret. Vous rouvrez un side project laissé de côté depuis trois semaines. La branche de fonctionnalité accuse 41 commits de retard sur main, deux fichiers sont en conflit, et ce que vous construisiez ne colle plus au reste du code. Le trunk based development est l'habitude qui empêche cette scène de se produire.
## Ce que le trunk based development veut dire concrètement
Le site de référence [trunkbaseddevelopment.com](https://trunkbaseddevelopment.com/) le décrit comme un modèle de gestion de sources où les développeurs collaborent sur une branche partagée et évitent les autres branches de développement longue durée. Les commits directs sur le trunk conviennent aux très petites équipes. Les pull requests conviennent aussi, à condition que les branches restent courtes et ne portent que le travail d'une personne sur un seul poste.
Trois règles portent l'essentiel du modèle.
-
Fusionner dans le trunk au moins une fois toutes les 24 heures.
-
Garder le trunk vert : un build cassé sur main est la priorité de tout le monde.
-
Cacher le travail inachevé derrière des feature flags, plutôt que de le garder sur une branche à part.
Ce qui manque est aussi intéressant. Il n'y a pas de branche develop, pas de longue branche de release par fonctionnalité, pas de phase d'intégration à la fin où tout le monde découvre que son code ne s'emboîte pas. Avec les anciens modèles, la douleur s'accumule, puis elle se paie d'un seul coup.
## Pourquoi c'est plus efficace que les branches longue durée pour la plupart des petites équipes
Une branche longue durée fonctionne comme un prêt. Chaque jour où elle vit, elle s'éloigne un peu plus de main, et les intérêts arrivent sous forme de conflits de fusion, d'hypothèses périmées et de revues que personne ne termine, parce que le diff touche 60 fichiers.
La page [DORA sur le trunk based development](https://dora.dev/capabilities/trunk-based-development/) relie trois pratiques à une meilleure vitesse de livraison, à une meilleure stabilité et à une meilleure disponibilité, d'après les données State of DevOps. Gardez trois branches actives ou moins dans le dépôt. Fusionnez dans le trunk au moins une fois par jour. Évitez les gels de code et les phases d'intégration. Ce sont des cibles concrètes et mesurables, ce qui reste rare dans ce domaine.
Pour un dev solo ou une équipe de trois, l'argument est encore plus simple. Les petites fusions sont faciles à relire, faciles à annuler et faciles à comprendre six mois plus tard, quand vous lisez `git blame` à 22 h en vous demandant ce que vous aviez en tête.
Trois raisons de le faire, une raison de ne pas le faire. Les raisons : des diffs plus petits, un retour plus rapide de la CI, et une branche main qu'on peut déployer un vendredi sans transpirer. La raison de ne pas le faire : si vos tests sont minces, fusionner chaque jour ne fait que répandre la casse plus vite. On y revient plus bas.
## Branches courtes ou commit direct sur main ?
Les deux méthodes relèvent du trunk based development. La différence tient à la sécurité que vous voulez avant qu'un code n'arrive sur la branche principale.
Committer directement sur main fonctionne quand vous êtes seul ou en binôme, que votre build local tourne en moins d'une minute et que vous faites confiance à vos tests. C'est la boucle la plus rapide qui existe. La plupart des builders solo le font déjà sans lui donner de nom.
Les branches courtes avec pull request prennent tout leur sens dès qu'une deuxième ou une troisième personne rejoint le projet, ou quand vous voulez que la CI tourne sur un checkout propre avant la fusion. La discipline tient dans le mot « courtes ». Une branche qui survit au lendemain dérive déjà vers le modèle que vous cherchez à quitter.
Une routine pratique qui tient la route :
-
Mettre main à jour, puis créer une branche au nom qui dit ce que fait le changement.
-
Faire le plus petit changement qui fait avancer les choses, et lancer le build complet en local.
-
Ouvrir la PR, laisser la CI tourner, fusionner le jour même.
-
Supprimer la branche. Ne pas les laisser s'accumuler.
Si un changement ne tient pas en une journée, la réponse n'est pas une branche plus longue. La réponse est de le découper plus finement.
## Comment livrer du travail inachevé sans casser main ?
C'est la question qui bloque la plupart des gens. Si vous fusionnez chaque jour, vous allez fusionner du code pour des fonctionnalités qui n'existent pas encore. Deux techniques règlent le problème.
La première est le feature flag. Le nouveau chemin de code est fusionné mais désactivé, si bien que les utilisateurs ne le voient jamais. Un flag peut être aussi simple qu'un booléen dans une variable d'environnement :
`const showNewCheckout = process.env.FEATURE_NEW_CHECKOUT === "true";
export function Checkout() {
return showNewCheckout ? : ;
}`Pour un side project, cela suffit. Quand vous avez besoin de ciblage, de déploiements progressifs ou d'un interrupteur d'urgence sans redéploiement, un service managé se justifie.
La seconde technique est le branch by abstraction, pour les changements plus lourds, comme remplacer un client de base de données ou un fournisseur de paiement. Vous placez une interface devant l'ancienne implémentation, vous construisez la nouvelle derrière la même interface, vous migrez les appelants petit à petit, puis vous supprimez l'ancienne. Chaque étape est une petite fusion dans le trunk, et rien ne reste sur une branche longue.
Une mise en garde honnête sur les flags : ce sont une dette. Un flag qui reste dans le code pendant un an, c'est une branche déguisée. Donnez à chaque flag un responsable et une date de suppression, et retirez-le une fois la fonctionnalité entièrement déployée.
## Ce dont votre CI a besoin avant d'essayer
Sans filet de sécurité, le trunk based development n'est qu'une casse rapide. Trois éléments doivent être en place avant de s'engager dans une fusion quotidienne.
-
Un build qui tourne à chaque push et se termine en quelques minutes, pas en une demi-heure.
-
Des tests qui échouent quand quelque chose de réel casse. Le taux de couverture compte moins que la capacité à attraper un mauvais changement.
-
Un moyen rapide de revenir en arrière : annuler le commit ou couper le flag.
L'analyse statique est une couche supplémentaire peu coûteuse. Elle attrape une famille de problèmes, comme les bugs évidents, les failles de sécurité typiques et le code dupliqué, avant qu'un humain ne lise le diff.
Si vous êtes le seul relecteur, un outil qui signale les zones à risque aide encore plus, parce que personne d'autre ne vous dira que le fichier que vous touchez sans cesse est en train de devenir un fouillis.
N'imaginez pas qu'il faille un pipeline lourd dès le premier jour. Un seul fichier de workflow qui installe, lint, teste et déploie main est un très bon départ. Ce n'est pas optimal, mais c'est la première version qui marche, et vous pourrez la resserrer plus tard. Testé, pas optimal, et ça vaut le coup quand même.
## Branches de release, hotfix et points qui demandent encore de la vigilance
Le trunk based development n'interdit pas les branches de release. Certaines équipes créent une branche depuis le trunk juste avant une release, la durcissent, la livrent, puis la suppriment. D'autres livrent directement depuis le trunk et corrigent en avançant quand un bug apparaît. Pour une application web déployée plusieurs fois par semaine, corriger en avançant est presque toujours plus simple.
Les applications mobiles, et tout ce qui passe par une validation lente en boutique, sont une autre histoire. Là, vous gardez peut-être une branche de release courte par version, pour pouvoir corriger ce qui est déjà entre les mains des utilisateurs. Même dans ce cas, la règle tient : les corrections atterrissent d'abord sur le trunk, puis sont reportées par cherry-pick, jamais l'inverse.
Les hotfix suivent la même logique. Corriger sur le trunk, déployer, et c'est fini. Une branche hotfix séparée qui n'est jamais refusionnée, c'est ainsi que les équipes se retrouvent avec deux historiques qui divergent.
## Une première semaine réaliste
Jour un : regardez comment votre dépôt gère ses branches aujourd'hui. Listez les branches ouvertes et notez l'âge de chacune. Tout ce qui date de plus de quelques jours est un candidat à la fusion ou à la suppression. Cela seul montre souvent où se trouve la friction.
Jour deux : ajoutez le mécanisme de flags. Même une variable d'environnement convient. Choisissez une fonctionnalité en cours, placez son point d'entrée derrière un flag, puis fusionnez ce que vous avez.
Jours trois à cinq : changez l'habitude. Découpez chaque tâche en morceaux qui peuvent atterrir dans la journée, et fusionnez chaque morceau dès que la CI passe. Les premiers morceaux vous paraîtront trop petits. Ils ne le sont pas. Un commit qui ajoute une colonne de base de données encore inutilisée, ou une fonction non appelée, est une unité de progrès tout à fait valable, parce qu'elle est sûre, relue et déjà intégrée.
À la fin de la semaine, vous saurez deux choses : si vos tests sont assez fiables, et quelles parties de votre code résistent aux petits changements. Les deux sont utiles, et aucune des deux n'apparaît quand on travaille sur des branches longues.
Vous n'avez pas besoin de tableau de bord pour le voir. Regardez combien de temps vivent vos branches, à quelle fréquence main est rouge, et combien de temps un changement met entre le premier commit et la production. Si l'âge des branches diminue et que les déploiements deviennent ennuyeux, l'habitude paie.
Si vous voulez mesurer les effets côté utilisateur de ce que vous livrez derrière des flags, un outil d'expérimentation peut relier un déploiement à des métriques réelles plutôt qu'à une intuition.
Pour une équipe d'une seule personne, un simple carnet suffit. Notez chaque semaine le délai entre la fusion et le déploiement, pendant un mois. La tendance vous en dira plus que n'importe quel chiffre isolé.
## Faut-il passer au trunk based development, ou attendre ?
Passez-y si vous travaillez seul, en binôme, ou dans une petite équipe avec des tests auxquels vous faites à moitié confiance et une CI que vous pouvez améliorer. Le coût d'un essai, c'est une semaine de petits commits un peu inconfortables. Le coût de rester sur des branches longues se paie en conflits et en revues lentes, et il grandit avec chaque personne qui rejoint le projet.
Attendez si vous n'avez aucun test automatisé et aucun moyen de revenir en arrière. Réglez cela d'abord, parce que des fusions quotidiennes dans un trunk non testé ne feraient que déplacer la douleur.
Ce n'est pas une méthode parfaite. C'est une méthode praticable. Prenez le prochain petit changement de votre projet en cours, fusionnez-le aujourd'hui, et regardez ce que ça fait. Quelle est la plus petite tranche de votre fonctionnalité actuelle que vous pourriez livrer avant ce soir ?
## FAQ
### Qu'est-ce que le trunk based development en une phrase ?
C'est un modèle où toute l'équipe fusionne de petits changements dans une seule branche partagée au moins une fois par jour, en gardant cette branche toujours livrable.
### Le trunk based development interdit-il les branches ?
Non. Des branches courtes sont autorisées, à condition qu'elles ne vivent pas plus d'une journée et qu'elles ne portent qu'un petit changement.
### Faut-il des feature flags pour pratiquer le trunk based development ?
Pas strictement, mais ils sont le moyen le plus simple de fusionner du travail inachevé sans l'exposer aux utilisateurs. Le branch by abstraction est une alternative pour les gros changements.
### Quelle différence avec GitFlow ?
GitFlow repose sur une branche develop et sur de longues branches de release. Le trunk based development n'en utilise pas : une seule branche partagée sert de référence.
### Combien de temps une branche peut-elle vivre ?
Le référentiel trunkbaseddevelopment.com recommande de fusionner au moins une fois toutes les 24 heures. Une branche qui dépasse la journée dérive déjà vers le modèle à éviter.
### Un développeur solo doit-il adopter ce modèle ?
Oui, si ses tests sont fiables et qu'il sait revenir en arrière rapidement. Sans ces deux éléments, des fusions quotidiennes répandent simplement les bugs plus vite.
### Peut-on faire du trunk based development sur une application mobile ?
Oui, avec une branche de release courte par version pour corriger ce qui est déjà chez les utilisateurs. Les corrections doivent toujours être faites sur le trunk d'abord, puis reportées.