Demandez à dix équipes leur stratégie Git, vous aurez dix réponses - et souvent dix exceptions à chaque réponse. Avec l'arrivée des agents, le problème empire : un agent peut ouvrir une branche, committer dix fois, en abandonner une autre, le tout en quelques minutes. Sans cadre, votre graphe Git devient illisible et vous perdez la seule chose qui compte : savoir où en est chaque fonctionnalité.
La conviction de Survol est simple : le découpage en branches est une vue technique, pas une vue produit. Vous ne devriez pas avoir à y penser. L'outil applique une stratégie claire à votre place et vous la montre sous forme de couloirs lisibles.
Vous pilotez des fonctionnalités et des versions. Les branches, c'est l'affaire de l'outil.
Le modèle : un couloir par fonctionnalité
Chaque fonctionnalité a son couloir. À l'intérieur, chaque version (v1.0, v1.1, v2.0…) vit sur sa branche et donne lieu à une demande de fusion. La règle tient en une ligne :
- Une branche par fonctionnalité pour isoler le travail ;
- Une demande de fusion par version pour rendre chaque incrément relisible et déployable ;
- Une préview par demande de fusion pour valider avant de promouvoir.
# Le couloir de la fonctionnalité « Codes promo » feature/codes-promo ├─ v1.0 → PR #41 → préview → ✅ production ├─ v1.1 → PR #58 → préview → ✅ production └─ v2.0 → PR #72 → préview → ⏳ en test
Humains et agents, côte à côte
Le point clé, c'est que cette stratégie ne fait aucune différence entre une version développée par un agent et une version écrite à la main. Dans le domaine de Survol, l'origine d'une version est neutre : agent, manuelle ou mixte. Une branche manuelle suit exactement le même cycle de vie qu'une branche d'agent - même couloir, même demande de fusion, même préview.
Réconciliation, pas surveillance. Un développeur ouvre une branche en dehors de Survol ? Les webhooks la détectent et l'outil propose de la rattacher à la bonne fonctionnalité. Jamais de ton délateur : on réconcilie le travail, on ne fliquera personne.
Et le multi-dépôts ?
Une fonctionnalité peut s'étaler sur plusieurs dépôts (front, back, lib partagée). Le découpage technique reste invisible au niveau produit : une version multi-dépôts, c'est une branche par dépôt mais un seul bouton « Valider ». Vous raisonnez en fonctionnalité ; Survol coordonne les couloirs sous le capot.
Ce que vous y gagnez
- Un graphe Git lisible, même quand un agent committe à toute vitesse.
- Une réponse permanente à « cette fonctionnalité, elle est dans quelle version, sur quelle branche ? ».
- La cohabitation devs/agents sans friction ni double comptabilité.
On parle beaucoup de la vitesse des agents. On parle trop peu de la lisibilité qu'ils détruisent si on les laisse faire sans cadre. Une branche par fonctionnalité, une demande de fusion par version : c'est ennuyeux, c'est discipliné, et c'est exactement ce qui vous permet de garder la carte de votre produit quand le code, lui, est écrit à la vitesse de la machine.
