Committe et pousse

12 août 2026 · Dubaï, Émirats arabes unis
25.2048° de latitude nord · 55.2708° de longitude est · fuseau horaire UTC+4
15 208e jour de vie · 1 474e jour à Dubaï

Il y a longtemps, dans une autre vie, un développeur backend au bureau de Yandex essayait de m’expliquer qu’il fallait parfois cherry-picker quelque chose d’une branche vers une autre.

Je l’écoutais attentivement. J’ai toujours essayé d’écouter les programmeurs avec attention : à voir leurs visages, il s’agissait forcément de quelque chose d’extrêmement important. Quelque part, il y avait un arbre, des branches sur cet arbre, des commits sur les branches. Parfois il fallait merger les branches, parfois il ne fallait pas, et il fallait alors cherry-picker quelque chose. Dans les cas particulièrement graves, un conflit survenait.

Pour moi, product designer, tout cela ressemblait à une cabale ancienne. Je comprenais les interfaces, les scénarios, l’architecture de l’information. Je pouvais discuter des heures de la raison pour laquelle l’utilisateur cliquerait ici plutôt que là, pourquoi un bouton devait être huit pixels plus à gauche qu’un autre, et pourquoi l’équipe produit concevait depuis trois mois tout autre chose que ce dont les gens avaient besoin. Je pouvais dessiner un système assez complexe et expliquer son comportement dans cent états. Puis venait une frontière. De l’autre côté vivaient les programmeurs.

Je leur donnais Figma, ils partaient dans leurs terminaux, et une autre physique du monde commençait. Il y avait là des dépôts, conteneurs, environnements, endpoints, migrations, clés et le mystérieux Git. Moi, je restais de mon côté de la rivière. Je croyais l’univers ainsi fait : le designer conçoit, le programmeur construit. L’architecte dessine la carte, et quelqu’un d’autre traverse réellement la forêt.

Bien des années ont passé. J’ai déménagé à Dubaï, changé plusieurs fois de vie, de métier, d’appartement, d’équipe, d’interface et d’idée sur moi-même. Un jour, je me suis retrouvé avec mon ordinateur, quelque part entre une visite de villa à Tilal Al Ghaf, un appel immobilier, des retouches de mon site, les enfants, le chien, le déménagement à Palm Jumeirah et une nouvelle tentative de CRM pour mon activité de courtier, à dire tout naturellement à l’agent : committe les modifications et pousse-les.

J’ai regardé cette phrase et compris soudain qu’il s’était passé bien plus que l’apprentissage d’un nouvel outil.

J’avais traversé la rivière.

Au commencement était le fichier

Les fichiers ont une particularité déplaisante : ils n’existent qu’au présent. Les vieux designers connaissent bien cette archéologie : final.fig, final-final.fig, final-v2.fig, final-v2-new.fig, final-v2-new-real.fig. Chaque nouveau fichier devait conserver d’une manière ou d’une autre la mémoire du précédent. Parfois dans le nom, parfois dans le dossier Archive, parfois dans la tête du designer, parfois elle disparaissait. Pendant des années, nous avons essayé de gérer le temps à la main.

Git a proposé une tout autre façon de penser le passé. Inutile de recopier le monde entier chaque fois qu’il change. On peut conserver le changement lui-même : ici, il y avait ceci, puis j’ai fait cela, en voici la raison, voici l’instant où le système est devenu autre. Cet instant s’appelle un commit.

Il m’a fallu bien des années pour sentir la beauté de ce mot, non pas technique, mais presque métaphysique. Un commit est une promesse au réel. Tu dis : voici l’état du monde dont je prends maintenant la responsabilité. Avant cela, les changements pouvaient traîner autour de toi comme des gravats : quelques fichiers corrigés, un supprimé, un autre apparu, de la logique modifiée ici, et là un agent qui a réécrit la moitié du projet sans qu’on le lui demande. Tout reste incertain, on peut encore renoncer à tout.

Puis tu fais un commit, et le chaos reçoit un nom.

corriger la disposition de la fiche du bien, ajouter la mise en correspondance des propriétaires, rétablir le parcours d'authentification, mettre à jour les instructions des agents, arrêter de casser la production.

Le dernier est particulièrement important.

À cet instant, une chose étonnante se produit : le passé ne disparaît plus. Il devient un chemin.

J’ai longtemps cru que la mémoire était dans la tête

C’est sans doute pour cela que la mémoire des réseaux neuronaux m’occupe tant aujourd’hui. Nous avons l’habitude de considérer la mémoire comme une propriété humaine. Je me souviens du premier bureau, de Moscou, des pièces où nous discutions des produits et de ce développeur qui m’expliquait le cherry-pick, même si je n’avais presque certainement rien compris. Je me souviens du 30 juillet 2022, jour où a commencé mon propre décompte de Dubaï.

Aujourd’hui, c’est le jour 1 474. On pourrait l’écrire autrement : Dubaï / commit 1474.

Pendant ce temps, presque tout a changé : adresses, travail, idées sur le travail, personnes proches, taille des enfants, quantité d’objets dans la maison, de réseaux neuronaux dans l’ordinateur, jusqu’à la définition de qui je suis. Mais la mémoire humaine n’est pas fiable. Elle réécrit sans cesse l’histoire ; chaque souvenir du passé est légèrement retouché pour convenir à celui que nous sommes aujourd’hui.

Git fonctionne autrement. Il est assez impassible : voici ce qui était, ce qui a changé, qui l’a changé, quand et pourquoi, si tu as pris la peine d’écrire un vrai message. En un sens, git log est l’une des autobiographies les plus honnêtes que j’aie vues. Sans réécriture littéraire ultérieure ni envie de paraître plus intelligent après coup.

Mardi, 02:14 — authentification cassée

Mardi, 02:47 — authentification réparée

Mardi, 03:06 — réparé ce que j'ai cassé en réparant l'authentification

La vraie vie ressemble à peu près à cela.

Puis les agents sont arrivés

Et là, tout a définitivement changé. Avant, l’ordinateur était un outil : on pressait des boutons, déplaçait la souris, ouvrait un programme et accomplissait directement l’action. Puis un logiciel a su exécuter des commandes. Maintenant, j’ouvre un projet et des entités peuvent y travailler : il suffit de leur décrire une intention.

L’une lit le code, l’autre étudie l’architecture, la troisième corrige l’interface, la quatrième vérifie le résultat de la première. Une cinquième peut écrire une migration de base de données pendant que je vais visiter une maison de ville. Je cesse peu à peu de faire chaque mouvement à la main pour devenir celui qui en fixe la direction.

Autrefois, je concevais l’interface entre l’humain et le programme. Maintenant, je conçois celle entre l’intention humaine et une multitude d’exécutants artificiels. Et soudain, les vieux mots des programmeurs sont devenus nécessaires à moi précisément.

Avec une seule personne au travail, on peut encore espérer compter sur sa mémoire. Avec des agents, cet espoir s’épuise vite. Il leur faut un territoire, des règles, une histoire et la compréhension de ce qu’on peut toucher ou non. Du contexte sous forme de fichiers, pas sous forme de mon intuition.

C’est ainsi qu’est entré dans ma vie .gitignore, et j’ai découvert, sans m’y attendre, l’une des choses les plus philosophiques de tout le développement.

.gitignore est la liste de ce que le monde doit oublier.

Tout ne mérite pas l’histoire. Il y a les fichiers temporaires, secrets, déchets, artefacts intermédiaires et choses qui n’existent que sur votre machine sans devoir partir plus loin. Pour bien garder la mémoire, il faut d’abord décider de ce qu’il ne faut pas retenir. L’humanité semble être arrivée à cette idée bien après Git.

Et puis il y a AGENTS.md et d’autres fichiers où l’on laisse des instructions à ceux qui viendront après. Ce ne sont désormais pas forcément des humains. On écrit littéralement une lettre aux êtres du futur : voici le projet, sa structure, ses règles. Ne change pas ceci sans raison. Ici, emploie cette approche. Ici, lis d’abord la documentation. Après les changements, vérifie la compilation. Ne touche pas à ce dossier. N’invente pas une nouvelle entité s’il en existe déjà une.

J’aime cette nouvelle forme d’écriture. Mon père écrivait des récits pour conserver son monde et le transmettre. Aujourd’hui, j’écris parfois la nuit des instructions en Markdown pour qu’au matin une instance inconnue d’intelligence artificielle comprenne mon projet. La distance entre ces deux gestes paraît immense ; parfois, elle me semble presque inexistante. Nous faisons toujours la même chose : transmettre le contexte à ceux qui viendront après nous.

Les branches

Le mot qui m’effrayait le plus autrefois était sans doute branch. Une branche. Je comprends enfin pourquoi l’arbre est une métaphore si tenace. La vie, elle aussi, suit rarement une seule ligne. Il y a la branche principale, l’expérience, la version où l’on a voulu tout refaire, celle qui s’est révélée une erreur, celle qu’on n’ose pas encore réunir à la principale. Et forcément une branche oubliée depuis deux mois qu’on regarde un jour sans plus savoir qui l’a créée ni pourquoi.

Parfois, c’est littéralement ta vie.

main — Moscou.

dubai — 2022.

real-estate — 2026.

ai-orchestration — s’est peut-être détachée bien plus tôt, mais a longtemps poussé discrètement.

personal-brand — est toujours en développement actif.

Et quelque part, au-dessus de tout cela, existe une immense branche family, plus ancienne que la plupart des autres systèmes, avec ses propres règles de déploiement, loin d’être toujours documentées. J’ai trois enfants : je connais donc malgré tout un peu les systèmes distribués.

La beauté d’une branche, c’est de ne pas devoir détruire le monde d’aujourd’hui pour essayer celui de demain. On peut bifurquer, tester, se tromper, changer d’avis, revenir ou, un jour, regarder le résultat et dire : oui, cette version est meilleure. Fusion.

Et ce qui était hier une expérience rejoint l’histoire principale. N’est-ce pas ainsi que nous prenons la plupart des décisions sérieuses ? La nouvelle vie existe d’abord séparément. On l’essaie prudemment : nouveau pays, métier, rôle, façon de travailler. Puis vient un jour où personne n’a officiellement fermé le retour, mais où l’on sait déjà que ce n’est plus une branche expérimentale. C’est main.

Et quelque part, le cherry-pick attend toujours

Bien des années plus tard, j’ai enfin compris ce développeur de Yandex. Il ne m’initiait pas à une magie interdite. Cherry-pick signifie à peu près ceci : inutile de prendre toute l’histoire de quelqu’un d’autre ; un seul changement utile peut suffire.

C’est, je crois, l’un des principes les plus utiles hors de la programmation aussi. Inutile de devenir entièrement quelqu’un d’autre. Parfois, un seul bon commit suffit.

À mon père, la capacité de voir une histoire dans une journée ordinaire. Au design produit, l’habitude de chercher un système. Au courtage, l’attention au prix, au lieu, au temps et à la personne en face. Aux programmeurs, Git. À l’intelligence artificielle, la vitesse. À Dubaï, la foi presque pathologique qu’on peut d’abord imaginer l’avenir, puis le construire physiquement.

Cherry-pick.

Le bon commit, dans sa propre branche.

Et on continue.

Mais un commit ne change encore rien à l’extérieur

Cela aussi a été une découverte importante. On peut committer chez soi autant qu’on veut. Le projet sera magnifique, l’histoire propre, les changements enregistrés, mais tant qu’on n’a pas fait push, tout cela n’existe que sur sa machine, dans sa version locale du monde.

Et là, un mot purement technique devient soudain presque douloureusement humain. Car l’état d’avant le push je le connais très bien. Faire longtemps, préparer, refaire, réfléchir, perfectionner. Construire un site. Écrire un article. Imaginer un positionnement. Créer un produit. Tourner une vidéo. Redessiner une fiche. Améliorer encore un peu. Vérifier encore une fois. Ne le montrer encore à personne.

La plupart des gens ont un immense dépôt local de choses jamais accomplies push.

Chez les designers, je le soupçonne particulièrement grand. Nous savons faire de belles choses dans une Figma fermée. Envoyer le résultat dehors et admettre qu’il ne nous appartient plus à nous seuls est bien plus difficile.

C’est sans doute pour cela que cette courte association m’a tant plu : committe et pousse. D’abord fixer, puis envoyer. N’attends ni la version finale du projet ni celle de toi-même. Elle n’existera pas, et Git ne suppose aucune version finale. C’est peut-être sa plus grande sagesse.

Il n’y a que la version actuelle.

HEAD.

Très bon nom, d’ailleurs. Le point où se trouve ta tête en ce moment. Tout ce qui précède est déjà de l’histoire. Tout ce qui suit n’existe pas encore.

Parfois, il y a un conflit

Évidemment. Il serait même suspect qu’un système ressemblant tant à la vie n’ait pas de conflits. Tu modifies une ligne, quelqu’un d’autre aussi, et les deux versions prétendent maintenant au réel. Git s’arrête et dit : décide toi-même.

J’aime beaucoup cela. Il ne prétend pas connaître la bonne réponse. Voici une vérité, en voici une autre ; impossible de les fusionner automatiquement. C’est précisément là, au point du conflit, qu’il faut un humain.

Cela me semble répondre assez bien à bien des discussions sur l’IA. Plus les machines pourront exécuter de processus, plus on verra clairement les endroits où il faut, non pas produire une variante de plus, mais choisir une version du monde. Pour moi, l’orchestration de l’IA consiste précisément à cela : non pas faire travailler un agent plus vite, mais comprendre ce qui, parmi tout le travail produit, doit entrer dans main.

Git a changé mon rapport aux erreurs

Dans la vie ordinaire, l’erreur ressemble souvent à une destruction : tu as fait le mauvais choix, tout est gâché et il faut restaurer l’état précédent. Dans un système de contrôle de versions, l’erreur devient une partie de l’histoire. Si cette histoire est bien conservée, expérimenter fait moins peur.

On peut regarder le diff, voir ce qui a précisément changé, restaurer le passé, commencer une nouvelle branche ou annuler une décision ratée. Cela donne une liberté étonnante. Pas l’infaillibilité, Git ne la promet pas. Il offre bien plus utile : la réversibilité.

Le design produit m’a appris pendant des années à prototyper des interfaces. Git m’a appris, sans prévenir, à prototyper le réel.

Parfois, le soir, j’ouvre le terminal sur mon MacBook, et Dubaï s’étend derrière la fenêtre. La ville ressemble elle-même à un projet développé trop longtemps dans une branche expérimentale, qu’un jour quelqu’un a eu la folie de fusionner dans main.

J’habite maintenant à Palm Jumeirah, un lieu qui illustre particulièrement bien cette idée. Il y eut d’abord une idée, puis une ligne sur un plan, un modèle d’ingénierie, après quoi des gens ont littéralement commencé à verser du sable dans la mer. Difficile d’imaginer une illustration plus concrète d’un git push de l’intention humaine vers la réalité physique.

Ce qui était information est devenu géographie.

Dans la journée, je peux discuter d’une villa : surface, prix, emplacement, rendement, coordonnées, date de transfert. Une heure après, ouvrir le CRM et demander à un agent de modifier la mécanique d’une fiche de bien. Puis vérifier le diff, rejeter la moitié des changements, demander des corrections, committer et pousser. Écrire un texte le soir. Et tout cela ne ressemble plus, allez savoir pourquoi, à plusieurs métiers complètement différents.

Courtier, designer, auteur, orchestrateur d’IA. Avant, je cherchais un seul mot pour expliquer tout cela. Maintenant, cela ne me semble plus nécessaire. Git non plus n’essaie pas d’expliquer un projet par un seul fichier. Il conserve l’historique des changements.

Peut-être l’humain fonctionne-t-il à peu près ainsi.

Nous ne sommes pas un nom. Nous sommes log.

git status

Il y a une autre commande que j’aime particulièrement : git status. Elle ne construit, ne corrige ni ne crée rien. Elle indique simplement où l’on en est, ce qui a changé, ce qui est prêt à être committé, ce qui reste dehors et ce qui se passe dans le projet.

Parfois, je me dis qu’un humain aurait aussi besoin d’une commande git status. Sans livres de motivation, séminaires stratégiques ni tentative de concevoir immédiatement les dix prochaines années. S’arrêter et regarder : où suis-je, qu’est-ce qui a changé en moi, qu’est-ce qui est prêt à être fixé, encore inachevé, à supprimer depuis longtemps, ou à ajouter dans .gitignore, et ce qu’il faut enfin envoyer dehors.

12 août 2026. 15 208e jour de vie. 1 474e jour à Dubaï.

Autrefois, chez Yandex, j’entendais « cherry-picker » comme le nom d’un rite inconnu. Maintenant, plusieurs agents artificiels peuvent travailler à côté de moi, et je râle si l’un modifie des fichiers sans rapport avec sa tâche. Le monde change le vocabulaire d’un homme à une vitesse étonnante.

Mais il y a plus intéressant : parfois, un mot issu d’un domaine professionnel très étroit nomme soudain un phénomène qui a toujours existé.

Nous avons toujours fait des commits, sans les appeler ainsi.

Le premier jour dans un nouveau pays : commit. La naissance d’un enfant : commit. Quitter une entreprise : commit. Nouveau métier : commit. Déménagement : commit. Décider de ne plus être seulement designer : commit. Comprendre que l’IA n’est plus une application qu’on utilise, mais un nouvel environnement où construire : encore un commit.

Mais dans la vie, committer ne suffit pas.

On peut vivre une immense histoire intérieure sans jamais la montrer. Se préparer sans fin à devenir quelqu’un, créer le produit parfait en local, écrire un beau texte en brouillon, tourner une vidéo et la laisser dans Photos, créer un site que personne n’ouvrira ou imaginer une nouvelle vie qui restera toujours une branche expérimentale.

La deuxième partie de l’incantation m’importe donc aujourd’hui encore plus que la première.

Pousse

Envoie les changements là où existe le reste du monde. Qu’il y ait un remote. Que commence la review des autres. Que quelqu’un soit en désaccord. Qu’un conflit surgisse. Qu’il faille corriger quelque chose et faire le commit suivant.

C’est cela, avancer.

C’est sans doute pour cela que, lorsqu’un agent termine un travail et demande la suite, j’aime répondre en deux mots. Ils ont quelque chose de presque paternel, comme un aîné envoyant un plus jeune sur la route sans vouloir expliquer longtemps le monde, puisque la route l’expliquera mieux de toute façon.

Committe et pousse

Garde la mémoire de ce que tu as changé, et ne le garde pas pour toi seul.