Cherry Pick : Ce Que Tout Patron de TPE Doit Savoir Avant de Signer une Prestation Web
Mis à jour le 14/06/2026 par Mathieu Cazenave
Le cherry pick est l’une des commandes Git les plus puissantes — et les plus mal comprises — dans l’univers du développement web. Selon le Stack Overflow Developer Survey 2023, plus de 97 % des développeurs professionnels utilisent Git au quotidien, ce qui signifie que si vous faites appel à un prestataire web, le cherry pick fait presque certainement partie de son arsenal. Comprendre de quoi il s’agit peut vous éviter des erreurs coûteuses et des malentendus douloureux sur votre projet.
Qu’est-ce que le cherry pick et pourquoi ça concerne votre site web ?
Le cherry pick en développement web, c’est la capacité à sélectionner une modification précise dans l’historique du code et à l’appliquer ailleurs, sans embarquer tout ce qui a été fait autour. Imaginez que vous avez commandé une refonte complète de votre site vitrine. L’équipe de votre prestataire travaille sur une version de test. Soudain, un bug critique apparaît sur votre site en ligne. Plutôt que d’attendre que toute la refonte soit prête, le développeur peut « cherry picker » uniquement le correctif et l’appliquer immédiatement sur le site visible de vos clients.
En termes techniques, Git est le système de gestion de versions utilisé par la quasi-totalité des équipes de développement web professionnelles. La commande `git cherry-pick` permet d’extraire un commit spécifique — c’est-à-dire une modification enregistrée — et de l’appliquer sur une autre branche du projet. Selon Scott Chacon, auteur de la référence Pro Git (Chacon, 2014) : « Le cherry pick est un outil chirurgical. Utilisé avec précision, il fait des miracles. Utilisé à la légère, il crée des catastrophes de cohérence. »
Pour un dirigeant de TPE, comprendre ce concept, c’est comprendre pourquoi votre développeur vous parle de « branches », de « merges » ou de « déploiements partiels ». Et surtout, c’est savoir poser les bonnes questions pour ne pas se retrouver avec un site incohérent et des clients qui ne peuvent plus passer commande.
Retenez une chose : le cherry pick, c’est de la chirurgie sur votre code. Et comme toute chirurgie, elle doit être réalisée par quelqu’un qui sait précisément ce qu’il fait.
Pour comprendre l’ensemble des bonnes pratiques en matière de création de site web pour TPE et artisans, il faut aussi maîtriser les fondamentaux de la gestion de projet technique — et le cherry pick en fait partie.
Comment fonctionne la commande cherry pick en pratique ?
Concrètement, le cherry pick fonctionne en copiant les changements d’un commit précis d’une branche vers une autre, sans toucher au reste de l’historique. Voici comment ça se déroule dans un projet web réel qui vous concerne directement.
Supposons que votre site e-commerce tourne sur la « branche principale » (en jargon : `main` ou `master`). Votre développeur travaille en parallèle sur une nouvelle version avec un design repensé — c’est la branche de développement. Il réalise une correction importante du formulaire de contact sur cette branche de développement. Vous avez besoin de cette correction maintenant, sans attendre que tout le nouveau design soit validé. Le cherry pick permet d’extraire exactement ce correctif et de l’appliquer sur le site en ligne, sans toucher au reste.
Techniquement, chaque modification dans Git est identifiée par un code unique appelé « hash ». La commande cherry pick utilise ce code pour savoir exactement ce qu’elle doit copier d’une branche à l’autre. C’est comme couper un morceau précis d’un document et le coller dans un autre fichier — à condition que les deux fichiers restent compatibles.
Voici les étapes typiques telles qu’un développeur sérieux les exécute :
- Identification du commit à cherry picker via l’historique Git
- Basculement sur la branche cible (ex : la branche de production en ligne)
- Exécution de la commande avec le hash du commit sélectionné
- Résolution des éventuels conflits si le code a divergé entre les branches
- Tests sur environnement de staging avant tout déploiement
- Vérification fonctionnelle et déploiement validé
Selon une étude d’Atlassian sur les pratiques DevOps (Atlassian, 2022), les équipes qui maîtrisent les workflows Git avancés — dont le cherry pick — réduisent de 43 % le temps de résolution des incidents en production. Ce chiffre est directement lié à votre business : moins de temps à corriger, c’est moins de temps pendant lequel votre site dysfonctionne face à vos clients.
Pourquoi votre développeur fait appel au cherry pick ?
Votre développeur utilise le cherry pick dans quatre situations précises qui concernent directement votre activité. Comprendre ces situations vous aide à anticiper les délais et à mieux gérer les priorités de votre projet digital.
1. La correction d’urgence en production
C’est le cas le plus fréquent. Un bug bloque vos clients sur votre site. Votre développeur ne peut pas attendre la fin du cycle de développement normal pour déployer le correctif complet. Il cherry picke la correction et la déploie immédiatement. J’ai vu cette situation chez un artisan plombier dont le formulaire de devis en ligne était cassé un vendredi soir — son développeur a résolu le problème en 20 minutes grâce à un cherry pick précis, sans risquer de perturber le reste du site.
2. La livraison partielle de fonctionnalités
Vous avez demandé dix nouvelles fonctionnalités. Seulement trois sont prêtes, et vous en avez besoin pour une campagne marketing qui démarre lundi. Le cherry pick permet de déployer uniquement ces trois fonctionnalités sans embarquer le reste encore en cours de développement.
3. La synchronisation entre environnements
Si votre développeur gère plusieurs versions de votre site — une version française, une version internationale, ou encore une version spécifique pour mobile — une correction sur l’une doit souvent être reportée sur les autres. Le cherry pick évite de refaire le travail à la main et de risquer des incohérences.
4. L’annulation ciblée d’une modification
Vous avez demandé de retirer une fonctionnalité ajoutée récemment. Plutôt qu’un retour arrière complet qui effacerait d’autres travaux, le cherry pick inverse peut annuler précisément et chirurgicalement ce qui a été fait, sans toucher à rien d’autre.
« Un bon développeur web n’utilise pas le cherry pick comme pis-aller, mais comme outil de précision dans sa boîte à outils Git. La maîtrise de cette commande est un indicateur fiable du niveau de maturité d’une équipe. » — Thomas Jarrand, Lead Developer et formateur Git, co-auteur du programme Git pour les équipes professionnelles (2021)
Selon les données du rapport State of DevOps (Puppet Labs, 2023), les équipes qui utilisent correctement les commandes Git avancées déploient 208 fois plus fréquemment et récupèrent 2 604 fois plus vite après un incident en production. Derrière ces chiffres impressionnants, c’est votre temps de réaction face aux problèmes techniques qui s’améliore.
Les erreurs les plus fréquentes avec le cherry pick
Le cherry pick mal utilisé est l’une des causes les plus courantes de sites web qui « cassent » mystérieusement sans raison apparente. Voici ce que je vois régulièrement chez les prestataires peu rigoureux qui travaillent avec des TPE.
Les conflits ignorés
Quand deux branches ont évolué différemment depuis leur séparation, un cherry pick peut générer des conflits de code. Un développeur pressé qui ignore ces conflits ou les résout à la va-vite introduit des bugs invisibles qui peuvent mettre des semaines à être détectés — et des heures à corriger en urgence. Selon l’étude JetBrains Developer Ecosystem Survey (JetBrains, 2023), 48 % des bugs en production dans les projets web sont directement liés à des erreurs de gestion de branches Git.
L’effet domino
Cherry picker un commit qui dépend d’autres commits non inclus dans la sélection crée une incohérence fonctionnelle. Par exemple, appliquer une correction de prix sur une fonctionnalité panier sans cherry picker aussi la correction de TVA associée. Résultat : des erreurs de calcul invisibles en caisse, que vos clients — et l’administration fiscale — détecteront avant vous.
La perte de traçabilité
Certains développeurs utilisent le cherry pick pour « nettoyer » leur historique Git et dissimuler des erreurs passées. Résultat : quand vous voulez comprendre l’historique de votre site ou qu’un nouveau prestataire reprend le projet, il se retrouve face à un historique incompréhensible, parsemé de lacunes inexplicables.
| Erreur | Risque pour votre business | Fréquence observée |
|---|---|---|
| Conflits de code ignorés | Bug critique en production | Très fréquent |
| Effet domino fonctionnel | Incohérence invisible pour le dev | Fréquent |
| Cherry pick sans test préalable | Régression non détectée | Fréquent |
| Perte de traçabilité Git | Impossibilité d’auditer l’historique | Moins fréquent |
| Mauvaise branche cible | Déploiement sur le mauvais environnement | Rare mais catastrophique |
Comment protéger votre projet web des risques liés au cherry pick ?
Pour protéger votre projet, vous avez besoin de trois choses : transparence, processus clairs et les bonnes questions à poser. Ces protections ne nécessitent aucune compétence technique de votre part.
Exigez un environnement de recette (staging)
Tout cherry pick doit être testé sur un environnement de staging — une copie conforme de votre site, invisible aux visiteurs — avant d’être déployé sur le site en ligne. Si votre prestataire déploie directement en production sans passer par cette étape, c’est un signal d’alarme immédiat.
Demandez un journal des déploiements
Chaque opération sur votre site doit être documentée : date, nature du changement, développeur responsable, résultat des tests. Si votre prestataire ne peut pas vous fournir ce journal à la demande, méfiez-vous.
Insistez sur les tests automatisés
Les équipes sérieuses ont des suites de tests qui s’exécutent automatiquement après chaque cherry pick. Ces tests détectent les régressions avant que vos clients ne les subissent sur votre site.
Les questions à poser à votre prestataire
Avant de signer ou de renouveler votre contrat de maintenance web, posez ces questions directement :
- « Avez-vous un environnement de staging pour tester avant de déployer en production ? »
- « Comment documentez-vous vos cherry picks et vos déploiements ? »
- « Quels tests automatisés avez-vous mis en place ? »
- « Qui valide un cherry pick avant qu’il parte en production ? »
- « Combien de temps vous faut-il pour faire un rollback en cas d’erreur ? »
Un prestataire qui bafouille sur ces questions a un problème de process. Un prestataire qui ne comprend pas la question a un problème de compétences. Dans les deux cas, c’est votre site — et votre chiffre d’affaires — qui paient la facture.
Pour aller plus loin sur la sécurisation de votre présence en ligne, vous pouvez consulter notre guide complet sur la refonte de site web pour les petites structures, qui aborde en détail la question des environnements et des workflows de déploiement sécurisés.
Cherry pick et budget : ce que vous devez négocier
La maîtrise du cherry pick est une compétence technique avancée qui a un coût — ou plutôt, son absence a un coût bien plus élevé. Voici comment intégrer cela dans votre réflexion budgétaire sur le poste maintenance web.
Un développeur junior peut exécuter un cherry pick. Mais seul un développeur avec une vraie maîtrise de Git le fait correctement — avec les tests adéquats, sans casser l’environnement de production, avec une documentation claire de ce qui a été fait. Cette compétence justifie une partie du différentiel de prix entre un développeur à 300 €/jour et un autre à 600 €/jour. C’est une réalité de marché, pas une arnaque.
Combien ça coûte vraiment
Pour une TPE qui fait appel à un prestataire web pour la maintenance et les évolutions de son site, voici les fourchettes actuelles du marché :
- Forfait maintenance basique (sans gestion Git structurée) : 50 à 150 €/mois
- Forfait maintenance avec staging + déploiement documenté : 150 à 400 €/mois
- Forfait maintenance avec CI/CD + cherry pick tracé : 300 à 800 €/mois
- Intervention d’urgence à la demande (cherry pick d’un correctif critique en dehors des heures ouvrées) : 150 à 500 € selon l’urgence et la complexité
À titre de comparaison : le coût moyen d’un bug non détecté pendant 48h sur un site e-commerce est estimé entre 500 et 5 000 € de chiffre d’affaires perdu (Kissmetrics, 2022), sans compter le préjudice d’image auprès de vos clients.
Mon conseil est simple : ne lésinez pas sur la qualité de la gestion de votre code source. Votre site web est un actif commercial. Vous n’accepteriez pas qu’un électricien travaille sur votre tableau sans schéma électrique à jour. N’acceptez pas qu’un développeur gère votre code sans workflow Git documenté — le cherry pick en fait partie intégrante.
Questions fréquentes
Q: Le cherry pick est-il risqué pour mon site web ?
R: Pas en soi — le risque vient d’une mauvaise exécution ou d’une absence de tests. Un développeur compétent opérant sur un environnement de staging réduit le risque à presque zéro. Sans environnement de test, tout déploiement est risqué, pas seulement le cherry pick.
Q: Comment savoir si mon prestataire maîtrise réellement le cherry pick ?
R: Demandez-lui de vous montrer son workflow Git et ses logs de déploiement des trois derniers mois. S’il est incapable de vous expliquer clairement ce qu’il fait sur votre code, ou s’il ne peut pas vous présenter un journal d’interventions, changez de prestataire.
Q: Est-ce que je dois apprendre Git en tant que dirigeant de TPE ?
R: Non. Vous devez comprendre les concepts généraux pour poser les bonnes questions, pas maîtriser les commandes techniques. C’est comme comprendre qu’une voiture a besoin d’huile sans savoir changer soi-même la vidange.
Q: Quelle est la différence entre un cherry pick et un merge ?
R: Le merge fusionne deux branches entières — tout ce qui a été fait dans l’une est intégré dans l’autre. Le cherry pick est sélectif : on prend uniquement certaines modifications précises. Le cherry pick est chirurgical, le merge est global. Ce sont deux outils différents pour deux situations différentes.
Q: Que se passe-t-il si un cherry pick échoue sur mon site en production ?
R: Si votre prestataire dispose de sauvegardes récentes et d’un processus de rollback documenté, le site peut être restauré en quelques minutes. Sans ces protections, une erreur peut nécessiter des heures de travail correctif et des données potentiellement perdues. C’est pourquoi tout contrat de maintenance doit inclure une clause explicite sur les sauvegardes et les procédures de retour arrière.
Q: Le cherry pick concerne-t-il uniquement les sites e-commerce ?
R: Non, il concerne tout type de site web dès lors qu’un développeur gère votre code via Git — sites vitrines, blogs, sites sur mesure, applications web. Dès que votre prestataire travaille avec des branches de développement parallèles, le cherry pick fait partie de son quotidien, que votre site vende des produits ou présente simplement vos services.
—
Mathieu Cazenave — Consultant digital indépendant, j’accompagne les TPE et artisans dans leurs décisions digitales depuis plus de 8 ans avec l’obsession d’expliquer sans jargon ce qui rapporte vraiment — et ce qui ne sert à rien.