Le trunk-based development revient dans les discussions dès qu’on parle de code produit avec l’aide de l’IA. Puisque les modifications arrivent plus vite, pourquoi attendre une pull request, une revue et une fusion pour les intégrer ? Mais supprimer une étape ne supprime pas le travail qu’elle accomplissait. Il faut décider où placer ce travail, et comment vérifier qu’il est bien fait.
Je préfère une petite modification intégrée rapidement à une grosse pull request qui attend plusieurs jours. Pour autant, je ne donnerais pas les clés de la branche principale à toute l’équipe au seul motif qu’un assistant IA aide à écrire le code. La vitesse est utile si elle réduit aussi le délai entre une erreur et sa détection.
Trunk-based development : ce qu’on change vraiment
Le principe du trunk-based development consiste à intégrer fréquemment de petites modifications dans une branche principale commune. On évite ainsi que chacun travaille trop longtemps dans son coin, avec une branche qui diverge progressivement du reste du projet. Ce n’est pas forcément « plus de branches du tout » : des branches très courtes peuvent garder leur place.
La différence importante se situe dans la taille et la durée de vie du travail isolé. Une branche ouverte pour quelques heures et une pull request relue rapidement restent compatibles avec cette logique. À l’inverse, une fonctionnalité complète développée pendant des semaines avant fusion rend l’intégration plus risquée, même si elle passe par une revue formelle.
Le débat « pull requests ou trunk » devient trompeur quand il oppose deux boutons dans une interface Git. Une pull request est un moyen de discuter et de contrôler une modification. Le trunk-based development est une manière d’organiser le flux de travail.
Ce que l’IA accélère, et ce qu’elle ne vérifie pas
Un assistant peut proposer du code, des tests ou une première explication d’un changement. C’est pratique pour avancer. Mais une proposition rapide n’est pas automatiquement une modification pertinente. Il reste à vérifier qu’elle répond au besoin, s’intègre au projet et ne dégrade pas un comportement moins visible.
C’est là que je serais prudent avec l’idée de rendre les pull requests obsolètes. Si l’IA augmente le volume de code produit, elle peut aussi augmenter le volume de code à comprendre. Déplacer ce volume directement sur la branche principale, sans ajuster les contrôles, ne me semble pas être un progrès.
Avant d’intégrer une modification, je garderais au minimum quelques questions en tête :
- Le changement est-il assez petit pour être compris et annulé facilement ?
- Les tests vérifient-ils le comportement qui compte, et pas seulement le chemin le plus évident ?
- Une personne connaît-elle la raison du changement, même si l’IA a participé à son écriture ?
- Que se passe-t-il si cette modification casse quelque chose après l’intégration ?
Ces questions ne réclament pas nécessairement une longue revue asynchrone. Elles réclament en revanche une réponse. Selon les équipes, elle peut prendre la forme d’une revue courte, d’un échange en binôme, de contrôles automatisés ou d’une combinaison des trois.
Des petits changements, pas des contrôles en moins
À mes yeux, le principal intérêt du trunk-based development n’est pas de gagner quelques clics dans Git. C’est de rendre chaque changement assez limité pour qu’on puisse le comprendre, le tester et, si besoin, revenir en arrière. La taille des modifications devient alors un outil de maîtrise du risque.
Prenons une fonctionnalité qui touche à la base de données, au traitement métier et à l’interface. Tout livrer d’un coup complique la revue comme le diagnostic en cas de problème. La découper en étapes cohérentes permet de vérifier chaque partie plus tôt. Mais il faut préparer ces étapes : un changement intermédiaire ne doit pas casser le fonctionnement existant.
Les feature flags peuvent aider à séparer l’intégration du code de l’activation d’une fonctionnalité. Le code rejoint la branche principale, tandis que la nouveauté reste désactivée pour les utilisateurs concernés jusqu’à ce qu’elle soit prête. Ce n’est pas une solution magique : les états activé et désactivé doivent être testés, et les flags devenus inutiles doivent être retirés.
Je retiens surtout une règle pratique : si une modification paraît impossible à intégrer sans tout terminer auparavant, il faut regarder si on peut la découper autrement. Ce n’est pas toujours facile, notamment lorsqu’une migration touche plusieurs composants. Mais cette difficulté mérite d’être traitée comme un problème de conception, pas cachée dans une branche de longue durée.
Ce qu’il faut préparer avant de changer de méthode
Intégrer plusieurs fois par jour suppose une branche principale sur laquelle l’équipe peut travailler sans appréhension. Pour y parvenir, il faut plus qu’une consigne du type « faites des petits commits ». Les tests doivent être utiles, leur résultat doit arriver assez vite, et un échec doit être pris en charge rapidement.
Je commencerais par observer le fonctionnement actuel plutôt que par interdire les pull requests. Combien de temps une modification attend-elle une revue ? Quelle taille font les changements difficiles à relire ? Quels tests échouent régulièrement sans signaler un vrai problème ? Ces questions montrent où le travail ralentit et où la confiance manque.
Ensuite, je ferais évoluer les habitudes progressivement :
- Découper une tâche en changements plus petits, chacun avec un objectif compréhensible.
- Automatiser les vérifications que l’équipe répète déjà à chaque revue.
- Conserver une intervention humaine ciblée sur les choix de conception, les cas sensibles et les risques métier.
- Prévoir comment désactiver une fonctionnalité ou revenir sur un changement problématique.
- Vérifier régulièrement si le délai d’intégration baisse sans multiplier les incidents.
Ce dernier point est important. Une équipe peut fusionner beaucoup plus vite tout en passant davantage de temps à réparer. Elle n’a alors fait que déplacer l’attente : elle n’est plus devant la pull request, elle se retrouve après la mise en production.
Faut-il vraiment supprimer les pull requests ?
Je ne le ferais pas par principe. Dans une petite équipe qui échange souvent, une revue rapide avant fusion peut rester légère et utile. Dans un projet ouvert aux contributions extérieures, la pull request offre aussi un espace clair pour expliquer le changement et en discuter. Et certains changements sensibles justifient un contrôle explicite avant d’atteindre la branche principale.
En revanche, une pull request qui reste ouverte longtemps parce que personne n’a le temps de la lire ne protège pas grand-chose. Elle accumule les conflits, retarde les retours et finit parfois par être validée dans l’urgence. Dans ce cas, la bonne réponse n’est pas nécessairement de supprimer les revues : c’est de réduire leur taille et de leur réserver une vraie place dans le travail de l’équipe.
L’IA rend cette discipline encore plus importante. Si produire une modification prend moins de temps, comprendre pourquoi elle existe et vérifier ses effets ne doit pas devenir une formalité. La responsabilité du code reste humaine, qu’il ait été écrit à la main ou suggéré par un outil.
Au fond, je ne choisirais pas entre « tout passe par une pull request » et « tout part directement sur le trunk ». Je chercherais le circuit le plus court qui permette encore de comprendre, tester et corriger chaque changement. C’est moins spectaculaire qu’une révolution des méthodes de développement, mais probablement plus utile au quotidien.