J’ai vu ça échouer chez au moins une dizaine de PME clientes : un dirigeant embauche un développeur freelance sur une mission courte, le site ou l’appli tourne, et six mois plus tard une mise à jour casse tout en production. Le freelance est injoignable ou a changé de tarif pour « réparer une erreur qu’il a lui-même commise ». Dans un cas que j’ai suivi de près, une PME de vente en ligne près de Rennes — je l’appellerai Traiteur K., un traiteur événementiel qui vendait aussi en ligne — a payé 3 200 € de facture corrective et perdu quatre jours de ventes sur son site e-commerce parce que son développeur avait appliqué un correctif de bug directement en production sans jamais l’intégrer proprement dans son historique de code. La cause profonde ? Une mauvaise utilisation — en réalité une absence totale d’usage — du « cherry-pick » Git. Si vous dirigez une TPE et que vous avez externalisé votre développement, ce mot doit entrer dans votre vocabulaire, même si vous ne toucherez jamais une ligne de code vous-même.
Qu’est-ce qu’un cherry-pick, et pourquoi vous, dirigeant, devez le comprendre
Git est l’outil que la quasi-totalité des développeurs utilisent pour suivre l’historique des modifications d’un site ou d’un logiciel. Je garde le mot « Git » et le mot « commit » tels quels, en anglais, parce qu’il n’existe pas d’équivalent français utilisé dans la pratique — un développeur français dira « commit », jamais « validation », et si vous employez le mot français face à un prestataire, il ne comprendra pas immédiatement de quoi vous parlez. Un « commit » est une photo à un instant T d’une modification du code. Une « branche » (ça, on peut le garder en français, tout le monde l’utilise) est une version parallèle du code, souvent utilisée pour développer une fonctionnalité sans toucher à la version qui tourne en production.
Le « cherry-pick » consiste à prendre un commit précis d’une branche et à l’appliquer sur une autre branche, sans copier tout le reste. Concrètement : votre développeur corrige un bug urgent sur une branche de test, et au lieu de refaire tout un processus de fusion complet, il « pioche » (c’est le sens littéral, cueillir la cerise) juste ce commit-là pour le poser directement sur la branche qui alimente votre site en ligne. Utilisé correctement, c’est un outil rapide et précis. Utilisé n’importe comment — ou pas utilisé du tout, remplacé par des copier-coller de fichiers en FTP à même le serveur de production, ce que j’ai vu chez Traiteur K. — c’est la porte ouverte aux catastrophes silencieuses.
Pourquoi est-ce que ça vous concerne alors que vous n’écrivez pas de code ? Parce que la façon dont un développeur gère ses branches et ses cherry-picks est le meilleur indicateur de son sérieux professionnel. Un développeur qui n’a pas de discipline Git claire ne sait généralement pas non plus revenir en arrière proprement quand quelque chose casse. Et c’est vous qui payez la facture de la remise en état.
Le cas Traiteur K. : 3 200 € et quatre jours de ventes perdues
Voici ce qui s’est passé, en détail, parce que les chiffres parlent mieux que les mises en garde théoriques. Le freelance de Traiteur K. travaillait seul, sans processus formalisé, sur un site WooCommerce personnalisé. Il avait une branche de développement et une branche de production, en théorie. En pratique, il testait ses modifications directement sur un clone du site, puis recopiait à la main les fichiers modifiés par FTP quand « ça avait l’air de marcher ». Aucun cherry-pick, aucune fusion tracée, aucun historique fiable de ce qui avait réellement été déployé.
Un jour, il corrige un bug d’affichage des prix TTC pendant les soldes. Le correctif fonctionne sur son environnement de test. Il recopie les fichiers en production — sauf qu’il recopie une version de fichier plus ancienne que celle en ligne, écrasant au passage une correction antérieure liée au calcul de la TVA sur les commandes groupées. Résultat : pendant quatre jours, une partie des commandes groupées facturait la mauvaise TVA. Personne ne s’en rend compte immédiatement parce que le site « marche », au sens où il n’y a pas d’erreur visible, juste des chiffres faux.
Le coût réel : 3 200 € facturés par un second développeur pour reconstituer l’historique des modifications à la main (en comparant des sauvegardes de fichiers, faute de véritable trace Git), corriger le calcul de TVA, et remettre en place une vraie gestion de branches. À cela s’ajoutent les quatre jours pendant lesquels Traiteur K. a dû suspendre les commandes groupées en ligne le temps de comprendre l’origine du problème — un manque à gagner que la dirigeante a estimé, avec ses chiffres de vente moyens sur cette période de l’année, à environ 2 400 € de commandes non passées. Total : plus de 5 500 € pour un bug qu’un cherry-pick bien exécuté et documenté aurait évité, ou du moins rendu traçable et réversible en quelques minutes.
Est-ce que cette histoire est isolée ? Non. C’est le scénario le plus fréquent que je rencontre chez les TPE qui travaillent avec un développeur unique et sans second regard sur son travail.
Attention à ces trois signaux qui doivent vous alerter
Attention à un développeur qui ne peut pas répondre clairement à la question « comment reviens-tu en arrière si ta mise à jour casse le site ? ». Si la réponse est vague, floue, ou s’appuie sur « je garde une copie de sauvegarde sur mon ordinateur », c’est un signal d’alarme direct. Une vraie gestion Git permet de revenir à n’importe quel état précédent en quelques commandes, pas en cherchant un fichier zip sur un disque dur.
Deuxième signal : un développeur qui travaille uniquement en local et déploie par copie manuelle de fichiers (FTP, SFTP) sans jamais mentionner de dépôt Git hébergé (GitHub, GitLab, Bitbucket — ces noms propres restent en anglais, ce sont des marques). Sans dépôt centralisé, il n’y a tout simplement pas d’historique fiable, cherry-pick ou pas.
Troisième signal, plus subtil : un développeur qui fait des cherry-picks « à l’oreille », c’est-à-dire qui reprend des bouts de code d’une branche à l’autre sans jamais documenter pourquoi, ni tester l’ensemble après coup. Le cherry-pick isolé, sans vérification de ce qu’il modifie autour, est justement ce qui a produit l’écrasement silencieux chez Traiteur K.
Est-ce que cela veut dire qu’il faut exiger un processus Git digne d’une entreprise de 200 développeurs pour un site vitrine à 2 000 € ? Non, évidemment, ce serait disproportionné. Mais il existe un minimum non négociable, même pour une mission courte.
Ce qu’il faut exiger, concrètement, dès demain
Le minimum que je recommande à toute PME qui externalise du développement, quelle que soit la taille du projet : un dépôt Git hébergé (même gratuit) auquel vous avez, vous, un accès en lecture, même si vous ne l’utilisez jamais. Ce n’est pas de la méfiance déplacée, c’est l’équivalent numérique de demander à voir le bail avant de signer un contrat de sous-location. Deuxièmement, exigez que chaque mise à jour en production corresponde à un commit identifiable, avec une description en une phrase de ce qui a changé. Ce n’est pas contraignant pour un développeur sérieux — ça prend trente secondes par commit — et ça vous donne une trace exploitable en cas de problème.
Mon conseil : avant de valider la prochaine facture de votre développeur freelance, demandez-lui simplement de vous montrer l’historique des dix derniers commits sur le projet, avec leurs descriptions. Si l’historique est cohérent, daté, avec des messages qui décrivent clairement chaque changement, c’est bon signe. Si le développeur peine à vous montrer un historique clair, ou si les descriptions sont du type « fix » ou « update » répété quinze fois sans plus de détail, c’est le moment de poser des questions, pas après le prochain bug.
Je sais que ce n’est pas ce que les agences web vous vendent dans leur discours commercial — elles préfèrent parler de « solutions sur-mesure » et de « performance » plutôt que de rigueur d’historique de code. Mais c’est cette rigueur, invisible et peu vendeuse, qui évite les factures de 5 500 € pour un bug de TVA. Posez la question sur les commits dès demain, même si vous ne comprenez pas une ligne de code : la clarté de la réponse en dit plus long sur le sérieux du prestataire que n’importe quelle plaquette commerciale.