Je me souviens d’une soirée, longtemps avant que Git ne façonne mon travail.

Un répertoire de configuration. Des dizaines de fichiers, chacun avec un suffixe censé révéler quand il avait été touché : sysctl.conf.bak, sysctl.conf.old, sysctl.conf.2021, sysctl.conf.final, sysctl.conf.VRAIMENT_final. Personne ne savait plus quelle version faisait foi. Personne ne savait qui avait modifié quoi, ni quand. Et la question du pourquoi une ligne précise se trouvait là où elle était — elle trouvait réponse, au mieux, dans un commentaire laissé par quelqu’un, un jour. Le plus souvent, personne ne répondait.

Ce n’était pas un cas isolé. C’était la norme.

Et puis est arrivé un outil qui n’était pas prévu pour nous — et qui pourtant a transformé notre monde pour de bon.

Un outil qui n’était pas fait pour nous

Git est apparu en 2005, conçu par Linus Torvalds pour gérer le projet du noyau. Il était destiné aux programmeurs : code source, patchs, collaboration distribuée sur de grandes bases de code. Les administrateurs n’y apparaissaient nulle part.

Au début, les termes sonnaient étranger. Commits, branches, merge, rebase, remote, push, pull, head, detached head. Un langage qui appartenait aux compilateurs, pas à la salle des machines. Quand on était sysadmin, on avait autre chose à faire.

Mais certains d’entre nous ont essayé. Ont placé /etc sous contrôle de versions. Ont suivi leurs dotfiles — ces petits fichiers de configuration dans le répertoire personnel, l’écriture personnelle de chaque administrateur. Et soudain, nous avons remarqué : cet outil correspondait à notre travail mieux qu’on ne l’avait jamais imaginé pour nous.

Ce qui rend Git différent

En son cœur, Git stocke des instantanés, pas des différences. Chaque commit est une image complète de l’état à un instant donné — récupérable, comparable, restaurable. Chaque modification est sécurisée cryptographiquement, par des sommes de hachage. Les altérations deviennent détectables. L’historique devient immuable — tant qu’on ne le réécrit pas exprès.

Cela paraît technique. En vérité, c’est une promesse : Rien ne se perd. Tout est traçable.

Quiconque a déjà édité une configuration jusqu’à la casser sans savoir comment elle était avant comprend ce que vaut cette promesse. git diff montre ce qui a changé. git log -p montre tout l’historique, ligne par ligne. git blame nomme l’auteur de chaque ligne — et le commit qui l’a ajoutée. git revert annule une modification sans effacer l’historique.

Avant Git, une réparation relevait du jeu de hasard. Avec Git, c’est une question.

Transparence et réversibilité

Deux propriétés ont durablement changé l’administration système : la transparence et la réversibilité.

La transparence signifie : toute modification a un auteur, un horodatage et une justification — le message de commit. Qui veut savoir trouve. Pas dans un wiki que personne ne maintient. Pas dans la tête d’un collègue actuellement en vacances. Mais directement dans l’historique que le système tient lui-même.

La réversibilité signifie : tout état ayant existé peut être restauré. Une mise à jour défectueuse, une configuration cassée, un bloc supprimé par erreur — tout est récupérable. Cela ôte l’effroi de l’expérimentation. Savoir qu’on peut revenir permet d’aller plus loin.

Ces deux propriétés ensemble modifient la manière de travailler. On ose davantage, car le risque est moindre. On documente plus précisément, puisque les commits survivent de toute façon. On pense en états, pas en actions.

Une discipline dont on ne se débarrasse pas

C’est ici que ça devient inconfortable. Et c’est ici que réside la vraie valeur.

Git ne récompense pas celui qui va vite. Git récompense celui qui travaille proprement. Il impose des commits atomiques — de petites modifications cohérentes plutôt que des rustins monstrueux. Il impose des messages de commit explicites — parce qu’un message intitulé « stuff » n’aidera personne dans six mois. Il impose des branches quand on tente quelque chose de risqué — au lieu de bricoler en cachette sur le tronc principal.

Oui, c’est fastidieux. Oui, les conflits de fusion énervent. Oui, un detached head peut paniquer un débutant. Oui, un rebase raté donne l’impression d’avoir perdu le contrôle — jusqu’à comprendre que git reflog conserve chaque étape.

Mais ce n’est pas un bug. C’est le programme.

Qui travaille avec Git apprend la précision. Apprend à isoler les changements. Apprend à formuler ses pensées avant de les committer. Apprend que la cohérence n’est pas un état qui naît par hasard, mais une habitude qu’on exerce.

N’est-ce pas ce que nous exigeons ? La cohérence. C’est exactement ce que Git nous offre. Et davantage.

De l’outil de développeur au socle

Regardons la période entre 2010 et aujourd’hui. Ce qui a changé, ce n’est pas seulement l’usage de Git. C’est la place de Git.

Autour de 2010, le contrôle de versions était facultatif pour beaucoup d’administrateurs. Certains utilisaient SVN, d’autres RCS, beaucoup rien du tout. Les configurations vivaient sur les serveurs où elles fonctionnaient. Sauvegarder voulait dire copier.

Aujourd’hui, en 2026, Git est l’air que respire l’infrastructure. /etc sous Git est depuis longtemps pratique courante — des outils comme etckeeper l’automatisent. Les dotfiles vivent dans des dépôts, synchronisés entre plusieurs machines. Et tout le mouvement de l’infrastructure as code — Ansible, Terraform, OpenTofu, Puppet, les manifestes Kubernetes — repose sur Git. Sans Git, cela n’existerait pas sous cette forme.

De là est né quelque chose de nouveau : GitOps. L’idée que Git est l’unique source de vérité. Flux, ArgoCD et autres outils surveillent un dépôt et reconcilient la réalité automatiquement — chaque merge est un déploiement, chaque commit une entrée d’audit. La gestion du changement se fait chemin faisant, comme partie intégrante du flux de travail ordinaire. Au lieu de processus d’approbation lourds, les pull requests servent d’instrument léger de contrôle.

Ce n’est pas une tendance. C’est une nouvelle hypothèse de départ.

Seul aussi

Vous pensez peut-être : cela ne vaut que pour les équipes. Non.

Celui qui travaille entièrement seul — un administrateur solo, un indépendant, quelqu’un qui entretient son homelab — en bénéficie tout autant. Peut-être même davantage.

Six mois après avoir positionné une ligne sysctl, vous vous demandez pourquoi. Sans Git, vous devinez. Avec Git, vous tapez git log -p sysctl.conf et vous lisez votre propre raisonnement — dans le message de commit que vous aviez écrit alors. Votre moi passé explique la décision à votre moi présent.

Des dotfiles dans un dépôt Git signifient : une nouvelle machine est prête en quelques minutes. Une panne de disque n’est pas un drame, mais un clone. Votre atelier personnel est partout où vous êtes.

Et la discipline agit même sans collègues pour relire. Savoir que vos commits subsistent — même si personne ne regarde — vous pousse à travailler plus proprement. Non par peur, mais par habitude. Git fait de la cohérence une routine, qu’une équipe se tienne à côté de vous ou non.

Le côté inconfortable, honnêtement dit

Git n’est pas aimable. Sa syntaxe est inconsistante. Certaines opérations sont dangereuses sans que ce soit visible au premier regard. La documentation est abondante mais pas toujours accueillante. Celui qui a lancé un force-push sur la mauvaise branche ne l’oublie pas.

Mais l’amabilité n’a jamais été l’objectif. L’exactitude l’était. Et l’exactitude ne tolère pas la mollesse.

La dureté de Git n’est pas un défaut. C’est la condition de ce qu’il accomplit. Un outil qui pardonne toutes les erreurs n’enseigne pas le soin. Un outil qui rend les erreurs visibles et dont l’annulation est parfois douloureuse enseigne l’attention. La douleur est la leçon.

La cohérence, voilà ce que Git nous donne

À la fin, ce n’est pas la vitesse. Ni l’éventail de fonctions. Ni la popularité.

C’est la cohérence.

Git ne laisse pas la cohérence en option. Il en fait la condition pour que quoi que ce soit fonctionne. Il nous retire la possibilité de travailler à demi — et nous rend quelque chose de plus important : la confiance dans notre propre état. Celui qui sait ce qui est configuré sur ses systèmes, parce que c’est dans l’historique, dort plus tranquille. Celui qui sait qu’il peut revenir ose davantage. Celui qui sait que chaque modification doit être justifiée pense plus clairement.

Voilà ce que signifie l’administration système aujourd’hui. Non bricoler, mais construire. Non espérer, mais savoir. Non la chance, mais la cohérence.

Ce qu’apporte libcom.de

Chez libcom.de, nous travaillons avec Git depuis nos débuts — non comme une expérience, mais comme fondation. Nos playbooks, nos configurations, notre documentation : tout versionné, tout traçable, tout soumis à revue.

En deux décennies de pratique, plus que de l’expérience a grandi. Une culture s’est formée — une attitude où la transparence va de soi et où la réversibilité n’accepte aucun compromis. Nous savons rendre des systèmes existants et non versionnés saisissables sans interrompre l’exploitation. Nous savons introduire GitOps sans bousculer l’équipe. Nous savons quand une revue de pull request apporte une qualité réelle et quand elle n’est que formalisme vide.

Si votre infrastructure fonctionne encore sans contrôle de versions, vous n’avez pas besoin de partir de zéro. Nous aidons à saisir les états existants, à les migrer dans Git et à bâtir progressivement une pratique qui fait de la cohérence une habitude. Si vous versionnez déjà, nous aidons à rendre les flux plus robustes, les revues plus efficaces et à éliminer la dérive.

Et si vous voulez simplement savoir où vous en êtes : nous faisons l’inventaire. Honnêtement, de manière traçable, sans pression commerciale.

La première étape est une discussion. Écrivez-nous à contact@libcom.de — décrivez votre situation, et nous découvrirons ensemble si et comment nous pouvons aider. Sans obligation, sans argumentaire. Simplement un échange honnête sur ce dont votre infrastructure a besoin.

Peut-être est-ce là le véritable progrès. Non pas que nous ayons gagné un nouvel outil. Mais que nous ayons cessé de dépendre de la mémoire et de la chance.

Une infrastructure qui fonctionne parce qu’elle a été construite — non parce que quelqu’un a fait attention. C’est le standard que nous visons. Et c’est le standard que Git nous permet d’atteindre.