[{"data":1,"prerenderedAt":765},["ShallowReactive",2],{"/fr-fr/blog/journey-through-gits-20-year-history":3,"navigation-fr-fr":37,"banner-fr-fr":443,"footer-fr-fr":453,"blog-post-authors-fr-fr-Patrick Steinhardt":663,"blog-related-posts-fr-fr-journey-through-gits-20-year-history":677,"assessment-promotions-fr-fr":715,"next-steps-fr-fr":756},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":12,"meta":27,"navigation":12,"path":28,"publishedDate":20,"seo":29,"stem":34,"tagSlugs":35,"__hash__":36},"blogPosts/fr-fr/blog/journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History",[7],"patrick-steinhardt",null,"open-source",{"slug":11,"featured":12,"template":13},"journey-through-gits-20-year-history",true,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22,"updatedDate":25},"Git : 20 ans d'histoire","Revivez les débuts du projet Git, avec le tout premier commit, découvrez les particularités des premières versions et replongez dans la confusion qu'a provoquée le changement du comportement par défaut de git-push(1).",[18],"Patrick Steinhardt","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","2025-04-14","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") vient de fêter ses 20 ans et depuis, bien des choses ont changé : si le design conceptuel de Git est resté globalement le même, la manière dont les utilisateurs s'en servent, elle, a considérablement évolué. Git est au cœur de notre travail chez GitLab et nous sommes fiers d'être liés à son histoire.\n\nRemontez le temps avec nous pour retracer les grandes étapes de son évolution.\n\n## Le premier commit\n\nLe premier commit a été effectué le 7 avril 2005 par Linus Torvalds, le créateur du noyau Linux : `e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`.\n\nComme vous pouvez le constater, ce commit ne contient pas beaucoup de fichiers :\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nOutre l'infrastructure de compilation, le premier commit fournit sept commandes principales :\n\n- `init-db` pour initialiser un nouveau dépôt Git\n- `update-cache` pour ajouter des fichiers à l'index\n- `write-tree` pour créer un nouvel arbre à partir des éléments de l'index\n- `read-tree` pour lire un objet arbre\n- `commit-tree` pour créer un commit à partir d'un arbre\n- `cat-file` pour lire un objet spécifique dans un fichier temporaire\n\nNotez que la commande `git` n'existait pas encore à ce moment-là. Il fallait dès lors les exécuter directement.\n\nPour vous montrer un exemple concret, créons un nouveau dépôt :\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nCela peut surprendre : il n'y a pas de répertoire `.git`, mais un répertoire `.dircache`. Ce dernier représentait une zone de stockage privée.\nGit distinguait alors deux types d'espaces de stockage des objets : un espace « privé » et un espace « partagé ». Ceux-ci regroupaient tous vos objets Git : vos commits et vos blobs, par exemple.\n\nPar défaut, `init-db` créait un espace de stockage des objets privé qui n'était utilisé que pour le répertoire géré dans lequel il avait été créé. L'espace de stockage des objets « partagé », quant à lui, permettait de centraliser les objets communs à plusieurs répertoires, ce qui évitait d'avoir à les stocker deux fois.\n\n### Créer un commit\n\nNous disposons maintenant d'un dépôt, mais comment procéder pour créer un commit ? Autant vous dire que ce n'est pas aussi simple qu'avec la commande actuelle `git add . && git commit`. À l'époque, vous deviez :\n\n1. Mettre à jour l'index en appelant `update-cache` pour chaque fichier que vous souhaitiez ajouter. 2. Écrire un nouvel arbre en appelant `write-tree` pour prendre le contenu que vous aviez\n   ajouté à l'index.\n3. Configurer les variables d'environnement pour indiquer à Git que vous en étiez l'auteur.\n4. Créer un objet de commit en appelant `commit-tree`.\n\nCréons un commit dans le dépôt pour illustrer ce processus :\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nCertes, ce processus n'est pas très pratique, mais il fonctionne ! Découvrons maintenant le commit généré :\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nNotez que `cat-file` n'a pas affiché le contenu directement, mais l'a d'abord écrit\ndans un fichier temporaire. Toutefois, le contenu du fichier ressemblait déjà en tous points à\ncelui des commits actuels.\n\n### Apporter des modifications\n\nMaintenant que nous avons des fichiers, comment pouvons-nous obtenir leur statut ? Vous l'aviez peut-être deviné, en utilisant `show-diff` :\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nÉtonnamment, la commande `show-diff` permettait déjà de générer des diffs entre l'ancien et le nouvel état des fichiers modifiés ! Et pour l'anecdote, Git accomplissait cette tâche en exécutant simplement l'outil Unix diff(1).\n\nEn somme, tout était encore rudimentaire, mais suffisant pour assurer le suivi de l'historique. À ce stade, Git était encore très limité :\n\n- Il était impossible de passer facilement d'un commit à un autre.\n- Il était impossible d'afficher les logs.\n- Il n'y avait pas de branches, de tags ou même de références. Les utilisateurs devaient manuellement conserver une trace des ID d'objet.\n- Il était impossible de synchroniser deux dépôts. Par conséquent,\n  les utilisateurs devaient utiliser rsync(1) pour synchroniser les répertoires `.dircache`.\n- Il était impossible de fusionner des modifications.\n\n## Git 0.99\n\nLa version 0.99 de Git a été la première à entrer en phase de test. Celle-ci a été publiée seulement deux mois après le commit initial, mais contenait déjà 1 076 commits. Près de 50 développeurs différents ont participé à son développement. À ce stade, Linus Torvalds était encore le principal contributeur, talonné de près par Junio Hamano, qui est aujourd'hui le chargé de maintenance.\n\nDe nombreuses améliorations avaient été mises en place depuis le premier commit :\n\n- Git avait commencé à suivre différentes branches de développement à l'aide de références, ce qui, dans la grande majorité des cas, dispensait les utilisateurs de suivre les ID d'objets manuellement.\n- Un nouveau protocole distant permettait désormais à deux dépôts d'échanger\n  des objets entre eux.\n- Le répertoire `.dircache` avait été renommé `.git`.\n- Il était désormais possible de fusionner des fichiers uniques entre eux.\n\nMais le changement le plus marquant a sans doute été l'arrivée de\nla commande principale `git` et de ses nombreuses sous-commandes. C'est aussi à cette occasion\nqu'est née la distinction entre les commandes dites de « plomberie » (plumbing) et de « porcelaine » (porcelain) :\n\n- Les outils de « plomberie » sont les commandes de bas niveau qui accèdent au dépôt Git\n sous-jacent.\n- Les outils de « porcelaine » sont des scripts shell qui encapsulent les commandes de « plomberie » pour fournir une interface utilisateur plus conviviale et performante.\n\nCette distinction existe encore aujourd'hui, comme expliqué dans\n[`git(1)`](https://git-scm.com/docs/git/fr#_commandes_de_haut_niveau_porcelaine), mais avec\nla réécriture en C de nombreuses commandes de « porcelaine » initialement en shell, la frontière entre ces deux catégories a commencé à s'estomper significativement.\n\n## Linus Torvalds passe la main\n\nLinus Torvalds n'a jamais créé Git par passion pour les systèmes de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version\"), mais parce qu'il était nécessaire de remplacer BitKeeper pour le développement du noyau Linux. Dès le départ, il n'avait pas l'intention d'en assurer la maintenance indéfiniment, mais juste le temps de trouver quelqu'un de confiance pour reprendre le flambeau.\nEt cette personne fut Junio Hamano. Junio a rejoint Git une semaine à peine après le premier  commit de Linus Torvalds et comptait déjà plusieurs centaines de commits dans l'historique au moment de la sortie de la version 0.99. Ainsi, le 26 juillet 2005, [Linus Torvalds l'a désigné comme nouveau chargé de maintenance du projet Git](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). Même si Linus Torvalds a continué à contribuer à Git, son implication s'est progressivement réduite, ce qui n'a rien de surprenant, vu ses responsabilités à la tête du projet Linux.\nA ce jour, Junio Hamano dirige toujours le projet Git.\n## Git 1.0\n\nLa première version majeure de Git est sortie le 21 décembre 2005 par Junio Hamano. Fait intéressant : pas moins de 34 nouvelles versions ont été publiées entre la version 0.99 et la version 1.0 : 0.99.1 à 0.99.7, 0.99.7a à 0.99.7d, 0.99.8 à 0.99.8g, et 0.99.9 jusqu'à 0.99.9n.\n\nParmi les évolutions majeures depuis la version 0.99, l'une des plus importantes a sans doute été l'introduction de la commande `git-merge(1)` pour fusionner deux arbres. Un changement radical par rapport à la version précédente, dans laquelle chaque merge devait être effectuée manuellement, fichier par fichier.\n\n### Dépôts distants\n\nUn autre changement majeur a été l'introduction de la notation abrégée pour\nles dépôts distants. Git savait déjà communiquer avec eux, mais jusque-là,\nles utilisateurs devaient entrer l'URL complète à chaque\nrécupération de modifications. Ce processus était plutôt contraignant, car dans la grande majorité des cas, les utilisateurs interagissaient toujours avec le même dépôt distant.\nAujourd'hui, vous connaissez probablement le fonctionnement des dépôts distants,\nmais à l'époque, le mécanisme était encore très différent. Il n'existait pas de commande `git-remote(1)`  pour les gérer. Ils n'étaient même pas stockés  dans votre fichier`.git/config` file. À vrai dire, lorsque les dépôts distants ont fait leur apparition dans\nla version 0.99.2, Git ne *disposait* même pas encore de fichiers de configuration.\nPour les configurer, il fallait créer un fichier dans le\nrépertoire `.git/branches`, un mécanisme qui semble aujourd'hui plutôt contre-intuitif. Mais  il fonctionne encore aujourd'hui :\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nEt ce n'est pas tout ! Le répertoire a été renommé en « dépôts distants » dès la version 0.99.5 de Git. Aujourd'hui, il existe donc trois méthodes distinctes pour configurer des dépôts distants dans un client Git actuel.\nMais soyons honnêtes : la plupart d'entre vous n'ont sans doute jamais eu à utiliser `.git/branches` ni `.git/remotes`,\ndeux mécanismes devenus obsolètes en 2005 et 2011,\nrespectivement. Ces répertoires seront d'ailleurs définitivement supprimés dans la version Git 3.0.\n\n## Image de marque de Git\n\nEn 2007, Git créé son premier logo. Le terme « logo » est peut-être un peu excessif : il ne s'agissait en réalité que de trois signes moins rouges au-dessus de trois signes plus verts, une référence visuelle directement inspirée de la sortie de `git diff` :\n\n![trois signes moins rouges au-dessus de trois signes plus verts, référence visuelle inspirée de la sortie de `git diff`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nLe site web [git-scm.com](https://git-scm.com) voit quant à lui le jour en 2008 :\n\n![page de destination pour git-scm.com en 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nEn 2012, le site web de Git est [remanié](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/) par Scott Chacon et Jason Long et son design ne changera que très peu par la suite :\n\n![site web git remanié en 2012](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nCette refonte du site arbore le nouveau logo rouge-orange conçu par Jason Long, qui est encore utilisé aujourd'hui :\n\n![logo git](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nDès la version 1.0, Git ressemblait déjà fortement à la version d'aujourd'hui,\nc'est pourquoi nous allons faire un grand saut dans le temps et passer directement à une autre étape clé de son histoire : Git 2.0. Publiée environ dix ans après Git 1.0,\ncette version a été la première à\nintroduire délibérément des changements non compatibles avec les versions précédentes dans les workflows principaux.\n\n### Comportement par défaut de `git-push(1)`\n\nLe changement le plus déroutant de cette version a sans doute été\nl'ajustement du comportement par défaut de la commande  `git-push(1)`.\n\nSi vous réalisiez un push dans un dépôt distant sans en indiquer explicitement l'objet,\nGit pouvait réagir de plusieurs façons :\n\n- Refuser d'agir et vous inviter à préciser l'objet de votre push.\n- Effectuer un push de la branche actuellement extraite.\n- Effectuer un push de la branche actuellement extraite, mais uniquement s'il détectait une branche correspondante dans le dépôt distant.\n- Effectuer un push de toutes vos branches disposant d'un équivalent dans le dépôt distant.\n\nAujourd’hui, le comportement par défaut de Git suit la stratégie dite « simple », c'est-à-dire la\ntroisième option mentionnée ci-dessus. Mais avant Git 2.0, le comportement par défaut était la stratégie de « correspondance », soit la dernière option.\n\nLa stratégie de « correspondance » était nettement plus risquée. Avant le push, vous deviez toujours vous assurer que vous vouliez vraiment effectuer un push de toutes vos branches locales disposant d'un équivalent dans le dépôt distant. Dans le cas contraire, vous risquiez d'envoyer des modifications par erreur. C'est pourquoi Git a opté pour la stratégie dite « simple », afin de limiter les risques et de faciliter la prise en main pour les nouveaux utilisateurs.\n\n### `git-add(1)`\n\nLe comportement par défaut de `git-add(1)` vis-à-vis des fichiers supprimés\na lui aussi connu une évolution importante. Avant Git 2.0, la commande `git-add(1)` ne\nprenait pas en compte les fichiers supprimés : il fallait les ajouter manuellement\navec `git-rm(1)` pour qu'ils soient inclus dans un commit. À partir de la version 2.0, la commande `git-add(1)` détecte également les suppressions de fichiers et les ajoute à l’index.\n\n## La communauté Git à l'honneur\n\nNous n'allons pas entrer dans les détails du fonctionnement actuel de Git : vous l'utilisez probablement déjà au quotidien, et dans le cas contraire, de nombreux tutoriels existent pour bien débuter. Prenons plutôt un moment pour célébrer et remercier la communauté Git, qui a permis à ce système de rester aussi performant après deux décennies.\n\nAu fil du temps, Git a :\n\n- Accumulé 56 721 commits depuis [Git 2.49.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-49-0/ \"Git 2.49.0\")\n- Reçu des contributions de plus de 2 000 personnes différentes.\n- Publié 60 nouvelles versions majeures.\n\nLe projet Git continue aussi de se renouveler grâce à l'arrivée régulière de nouveaux contributeurs, notamment par le biais des programmes [Google Summer of Code](https://summerofcode.withgoogle.com/) et [Outreachy](https://www.outreachy.org/). Ce sont eux qui assurent la pérennité du projet Git.\n## L'avenir de Git\n\nGit s'est clairement imposé comme le grand gagnant dans la course aux systèmes de contrôle de version. Il domine largement le marché et il est rare aujourd'hui de voir un projet [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui n'utilise pas Git. C'est bien la preuve que Git a su faire les bons choix.\n\nCela dit, le développement de Git est loin d'être terminé et de nombreux défis restent à relever. Sur le plan technique :\n- la modernisation d'un code base vieillissant  - la mise à l'échelle face à la croissance continue des monorepos  - la gestion plus efficace des fichiers binaires volumineux\n\nSur le plan communautaire :\n- l'amélioration de la convivialité de Git  - la promotion de la communauté Git pour garantir la pérennité du\nprojet\n\nLe travail ne s'arrête pas là et chez GitLab, nous sommes fiers de contribuer activement à faire en sorte que Git reste un système de contrôle de version de référence pour les vingt années à venir.\n\n## En savoir plus sur Git\n\n- [Git fête ses 20 ans : entretien avec son créateur Linus Torvalds](https://about.gitlab.com/fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) - [Format reftable de Git : guide pour les débutants](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/ \"Git fetch vs git pull \")\n- [Commits Git : comment et pourquoi maintenir un historique propre](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Commits Git\") - [Git en ligne de commande sous Windows avec Git Bash](https://about.gitlab.com/fr-fr/blog/git-bash/ \"Git Bash\")  - [Améliorez votre workflow avec Git rebase](https://about.gitlab.com/fr-fr/blog/take-advantage-of-git-rebase/ \"Git rebase\")\n",[23,24],"open source","git","2025-04-25","yml",{},"/fr-fr/blog/journey-through-gits-20-year-history",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":30,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},false,"https://about.gitlab.com/blog/journey-through-gits-20-year-history","https://about.gitlab.com","article","fr-fr/blog/journey-through-gits-20-year-history",[9,24],"i8yMYkmVMQSvxQ5FiVAwM8C-CD7caYtcfU7ytOezw6k",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":369,"minimal":404,"duo":423,"pricingDeployment":433},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/fr-fr/","gitlab logo","header",{"text":45,"config":46},"Commencer un essai gratuit",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Contacter l'équipe commerciale",{"href":52,"dataGaName":53,"dataGaLocation":43},"/fr-fr/sales/","sales",{"text":55,"config":56},"Connexion",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,184,189,290,350],{"text":61,"config":62,"cards":64},"Plateforme",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":68,"config":69},"Découvrir notre plateforme",{"href":70,"dataGaName":63,"dataGaLocation":43},"/fr-fr/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":75,"config":76},"Découvrir GitLab Duo",{"href":77,"dataGaName":78,"dataGaLocation":43},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":83,"config":84},"En savoir plus",{"href":85,"dataGaName":86,"dataGaLocation":43},"/fr-fr/why-gitlab/","why gitlab",{"text":88,"left":12,"config":89,"link":91,"lists":95,"footer":166},"Produit",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"Voir toutes les solutions",{"href":94,"dataGaName":90,"dataGaLocation":43},"/fr-fr/solutions/",[96,121,144],{"title":97,"description":98,"link":99,"items":104},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[105,109,112,117],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/fr-fr/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Gestion du code source",{"href":115,"dataGaLocation":43,"dataGaName":116},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"Livraison de logiciels automatisée",{"href":102,"dataGaLocation":43,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":43,"icon":128},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Tests de sécurité des applications",{"href":126,"dataGaName":133,"dataGaLocation":43},"Application security testing",{"text":135,"config":136},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":137,"dataGaLocation":43,"dataGaName":138},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Conformité logicielle",{"href":142,"dataGaName":143,"dataGaLocation":43},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":145,"link":146,"items":151},"Mesures",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":43},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[152,156,161],{"text":153,"config":154},"Visibilité et mesures",{"href":149,"dataGaLocation":43,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"Gestion de la chaîne de valeur",{"href":159,"dataGaLocation":43,"dataGaName":160},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":162,"config":163},"Données d'analyse et informations clés",{"href":164,"dataGaLocation":43,"dataGaName":165},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab pour",[169,174,179],{"text":170,"config":171},"Entreprises",{"href":172,"dataGaLocation":43,"dataGaName":173},"/fr-fr/enterprise/","enterprise",{"text":175,"config":176},"PME",{"href":177,"dataGaLocation":43,"dataGaName":178},"/fr-fr/small-business/","small business",{"text":180,"config":181},"Secteur public",{"href":182,"dataGaLocation":43,"dataGaName":183},"/fr-fr/solutions/public-sector/","public sector",{"text":185,"config":186},"Tarifs",{"href":187,"dataGaName":188,"dataGaLocation":43,"dataNavLevelOne":188},"/fr-fr/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":277},"Ressources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"Afficher toutes les ressources",{"href":196,"dataGaName":192,"dataGaLocation":43},"/fr-fr/resources/",[198,231,249],{"title":199,"items":200},"Premiers pas",[201,206,211,216,221,226],{"text":202,"config":203},"Installation",{"href":204,"dataGaName":205,"dataGaLocation":43},"/fr-fr/install/","install",{"text":207,"config":208},"Guides de démarrage",{"href":209,"dataGaName":210,"dataGaLocation":43},"/fr-fr/get-started/","quick setup checklists",{"text":212,"config":213},"Apprentissage",{"href":214,"dataGaLocation":43,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Documentation sur le produit",{"href":219,"dataGaName":220,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Vidéos sur les bonnes pratiques",{"href":224,"dataGaName":225,"dataGaLocation":43},"/fr-fr/getting-started-videos/","best practice videos",{"text":227,"config":228},"Intégrations",{"href":229,"dataGaName":230,"dataGaLocation":43},"/fr-fr/integrations/","integrations",{"title":232,"items":233},"Découvrir",[234,239,244],{"text":235,"config":236},"Témoignages clients",{"href":237,"dataGaName":238,"dataGaLocation":43},"/fr-fr/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":43},"/fr-fr/blog/","blog",{"text":245,"config":246},"Travail à distance",{"href":247,"dataGaName":248,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":250,"items":251},"Connecter",[252,257,262,267,272],{"text":253,"config":254},"Services GitLab",{"href":255,"dataGaName":256,"dataGaLocation":43},"/fr-fr/services/","services",{"text":258,"config":259},"Communauté",{"href":260,"dataGaName":261,"dataGaLocation":43},"/community/","community",{"text":263,"config":264},"Forum",{"href":265,"dataGaName":266,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":268,"config":269},"Événements",{"href":270,"dataGaName":271,"dataGaLocation":43},"/events/","events",{"text":273,"config":274},"Partenaires",{"href":275,"dataGaName":276,"dataGaLocation":43},"/fr-fr/partners/","partners",{"backgroundColor":278,"textColor":279,"text":280,"image":281,"link":285},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":282,"config":283},"carte promo The Source",{"src":284},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":286,"config":287},"Lire les articles les plus récents",{"href":288,"dataGaName":289,"dataGaLocation":43},"/fr-fr/the-source/","the source",{"text":291,"config":292,"lists":294},"Société",{"dataNavLevelOne":293},"company",[295],{"items":296},[297,302,308,310,315,320,325,330,335,340,345],{"text":298,"config":299},"À propos",{"href":300,"dataGaName":301,"dataGaLocation":43},"/fr-fr/company/","about",{"text":303,"config":304,"footerGa":307},"Carrières",{"href":305,"dataGaName":306,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":306},{"text":268,"config":309},{"href":270,"dataGaName":271,"dataGaLocation":43},{"text":311,"config":312},"Leadership",{"href":313,"dataGaName":314,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":316,"config":317},"Équipe",{"href":318,"dataGaName":319,"dataGaLocation":43},"/company/team/","team",{"text":321,"config":322},"Manuel",{"href":323,"dataGaName":324,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":326,"config":327},"Relations avec les investisseurs",{"href":328,"dataGaName":329,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":331,"config":332},"Centre de confiance",{"href":333,"dataGaName":334,"dataGaLocation":43},"/fr-fr/security/","trust center",{"text":336,"config":337},"Centre pour la transparence de l'IA",{"href":338,"dataGaName":339,"dataGaLocation":43},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":341,"config":342},"Newsletter",{"href":343,"dataGaName":344,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":346,"config":347},"Presse",{"href":348,"dataGaName":349,"dataGaLocation":43},"/press/","press",{"text":351,"config":352,"lists":353},"Nous contacter",{"dataNavLevelOne":293},[354],{"items":355},[356,359,364],{"text":50,"config":357},{"href":52,"dataGaName":358,"dataGaLocation":43},"talk to sales",{"text":360,"config":361},"Portail d’assistance",{"href":362,"dataGaName":363,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":365,"config":366},"Portail clients GitLab",{"href":367,"dataGaName":368,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":370,"login":371,"suggestions":378},"Fermer",{"text":372,"link":373},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":374,"config":375},"gitlab.com",{"href":57,"dataGaName":376,"dataGaLocation":377},"search login","search",{"text":379,"default":380},"Suggestions",[381,383,388,390,395,400],{"text":72,"config":382},{"href":77,"dataGaName":72,"dataGaLocation":377},{"text":384,"config":385},"Suggestions de code (IA)",{"href":386,"dataGaName":387,"dataGaLocation":377},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":106,"config":389},{"href":108,"dataGaName":106,"dataGaLocation":377},{"text":391,"config":392},"GitLab sur AWS",{"href":393,"dataGaName":394,"dataGaLocation":377},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":396,"config":397},"GitLab sur Google Cloud ",{"href":398,"dataGaName":399,"dataGaLocation":377},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":401,"config":402},"Pourquoi utiliser GitLab ?",{"href":85,"dataGaName":403,"dataGaLocation":377},"Why GitLab?",{"freeTrial":405,"mobileIcon":410,"desktopIcon":415,"secondaryButton":418},{"text":406,"config":407},"Commencer votre essai gratuit",{"href":408,"dataGaName":48,"dataGaLocation":409},"https://gitlab.com/-/trials/new/","nav",{"altText":411,"config":412},"Icône GitLab",{"src":413,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":411,"config":416},{"src":417,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":419,"config":420},"Commencer",{"href":421,"dataGaName":422,"dataGaLocation":409},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/compare/gitlab-vs-github/","get started",{"freeTrial":424,"mobileIcon":429,"desktopIcon":431},{"text":425,"config":426},"En savoir plus sur GitLab Duo",{"href":427,"dataGaName":428,"dataGaLocation":409},"/fr-fr/gitlab-duo/","gitlab duo",{"altText":411,"config":430},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":432},{"src":417,"dataGaName":414,"dataGaLocation":409},{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"Retour aux tarifs",{"href":187,"dataGaName":437,"dataGaLocation":409,"icon":438},"back to pricing","GoBack",{"altText":411,"config":440},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":442},{"src":417,"dataGaName":414,"dataGaLocation":409},{"title":444,"button":445,"config":450},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":446,"config":447},"Regarder GitLab Transcend maintenant",{"href":448,"dataGaName":449,"dataGaLocation":43},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":451,"icon":452},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":654},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":457,"config":458},"Afficher le code source de la page",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Modifier cette page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Veuillez contribuer",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,587,622],{"title":61,"links":479,"subMenu":484},[480],{"text":481,"config":482},"Plateforme DevSecOps",{"href":70,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":185,"links":486},[487,491,496],{"text":488,"config":489},"Voir les forfaits",{"href":187,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Pourquoi choisir GitLab Premium ?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/fr-fr/pricing/premium/","why premium",{"text":497,"config":498},"Pourquoi choisir GitLab Ultimate ?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/fr-fr/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"Transformation digitale",{"href":507,"dataGaName":508,"dataGaLocation":461},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"Sécurité et conformité",{"href":126,"dataGaName":133,"dataGaLocation":461},{"text":118,"config":513},{"href":102,"dataGaName":103,"dataGaLocation":461},{"text":515,"config":516},"Développement agile",{"href":517,"dataGaName":518,"dataGaLocation":461},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Transformation cloud",{"href":522,"dataGaName":523,"dataGaLocation":461},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":115,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":106,"config":529},{"href":108,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":157,"config":532},{"href":159,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/fr-fr/solutions/gitops/","gitops",{"text":170,"config":540},{"href":172,"dataGaName":173,"dataGaLocation":461},{"text":175,"config":542},{"href":177,"dataGaName":178,"dataGaLocation":461},{"text":180,"config":544},{"href":182,"dataGaName":183,"dataGaLocation":461},{"text":546,"config":547},"Formation",{"href":548,"dataGaName":549,"dataGaLocation":461},"/fr-fr/solutions/education/","education",{"text":551,"config":552},"Services financiers",{"href":553,"dataGaName":554,"dataGaLocation":461},"/fr-fr/solutions/finance/","financial services",{"title":190,"links":556},[557,559,562,564,567,569,572,575,577,579,581,583,585],{"text":202,"config":558},{"href":204,"dataGaName":205,"dataGaLocation":461},{"text":560,"config":561},"Guides de démarrage rapide",{"href":209,"dataGaName":210,"dataGaLocation":461},{"text":212,"config":563},{"href":214,"dataGaName":215,"dataGaLocation":461},{"text":217,"config":565},{"href":219,"dataGaName":566,"dataGaLocation":461},"docs",{"text":240,"config":568},{"href":242,"dataGaName":243},{"text":570,"config":571},"Histoires de réussite client",{"href":237,"dataGaLocation":461},{"text":573,"config":574},"Histoires de succès client",{"href":237,"dataGaName":238,"dataGaLocation":461},{"text":245,"config":576},{"href":247,"dataGaName":248,"dataGaLocation":461},{"text":253,"config":578},{"href":255,"dataGaName":256,"dataGaLocation":461},{"text":258,"config":580},{"href":260,"dataGaName":261,"dataGaLocation":461},{"text":263,"config":582},{"href":265,"dataGaName":266,"dataGaLocation":461},{"text":268,"config":584},{"href":270,"dataGaName":271,"dataGaLocation":461},{"text":273,"config":586},{"href":275,"dataGaName":276,"dataGaLocation":461},{"title":291,"links":588},[589,591,594,596,598,600,602,606,611,613,615,617],{"text":298,"config":590},{"href":300,"dataGaName":293,"dataGaLocation":461},{"text":592,"config":593},"Emplois",{"href":305,"dataGaName":306,"dataGaLocation":461},{"text":311,"config":595},{"href":313,"dataGaName":314,"dataGaLocation":461},{"text":316,"config":597},{"href":318,"dataGaName":319,"dataGaLocation":461},{"text":321,"config":599},{"href":323,"dataGaName":324,"dataGaLocation":461},{"text":326,"config":601},{"href":328,"dataGaName":329,"dataGaLocation":461},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":461},"/sustainability/",{"text":607,"config":608},"Diversité, inclusion et appartenance (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":461},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":331,"config":612},{"href":333,"dataGaName":334,"dataGaLocation":461},{"text":341,"config":614},{"href":343,"dataGaName":344,"dataGaLocation":461},{"text":346,"config":616},{"href":348,"dataGaName":349,"dataGaLocation":461},{"text":618,"config":619},"Déclaration de transparence sur l'esclavage moderne",{"href":620,"dataGaName":621,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":351,"links":623},[624,627,632,634,639,644,649],{"text":625,"config":626},"Échanger avec un expert",{"href":52,"dataGaName":53,"dataGaLocation":461},{"text":628,"config":629},"Aide",{"href":630,"dataGaName":631,"dataGaLocation":461},"/support/","get help",{"text":365,"config":633},{"href":367,"dataGaName":368,"dataGaLocation":461},{"text":635,"config":636},"Statut",{"href":637,"dataGaName":638,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":640,"config":641},"Conditions d'utilisation",{"href":642,"dataGaName":643},"/terms/","terms of use",{"text":645,"config":646},"Déclaration de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":461},"/fr-fr/privacy/","privacy statement",{"text":650,"config":651},"Préférences en matière de cookies",{"dataGaName":652,"dataGaLocation":461,"id":653,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,661],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":461},{"text":659,"config":660},"Politique de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":461},{"text":650,"config":662},{"dataGaName":652,"dataGaLocation":461,"id":653,"isOneTrustButton":12},[664],{"id":665,"title":18,"body":8,"config":666,"content":668,"description":8,"extension":26,"meta":672,"navigation":12,"path":673,"seo":674,"stem":675,"__hash__":676},"blogAuthors/en-us/blog/authors/patrick-steinhardt.yml",{"template":667},"BlogAuthor",{"name":18,"config":669},{"headshot":670,"ctfId":671},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661952/Blog/Author%20Headshots/pks-gitlab-headshot.png","pksgitlab",{},"/en-us/blog/authors/patrick-steinhardt",{},"en-us/blog/authors/patrick-steinhardt","SV9Yd_vW69UbvntDP-SEOV9NKT_VwUAj5nfftf2ElSw",[678,690,702],{"content":679,"config":688},{"tags":680,"category":9,"body":681,"date":682,"heroImage":683,"authors":684,"description":686,"title":687},[23,24,261],"Le projet Git a récemment publié [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u). Passons en revue quelques points marquants de cette version, qui comprend des contributions de l'équipe Git chez GitLab.\n\n\n## Prise en charge du rempaquetage géométrique avec les dépôts distants promisor \n\n\nLes objets qui viennent d'être créés dans un dépôt Git sont souvent stockés sous forme de fichiers libres individuels. Pour garantir de bonnes performances et une utilisation optimale de l'espace disque, ces objets libres sont régulièrement compressés dans ce qu'on appelle des fichiers d'empaquetage (« packfiles »). Le nombre de fichiers d'empaquetage dans un dépôt augmente au fil du temps en raison des tâches effectuées, comme la création de nouveaux commits ou la récupération depuis un dépôt distant. À mesure que le nombre de fichiers d'empaquetage augmente dans un dépôt, Git doit effectuer davantage de travail pour rechercher des objets individuels. Par conséquent, pour préserver les performances optimales du dépôt, les fichiers d'empaquetage sont périodiquement rempaquetés via git-repack(1) afin de consolider les objets dans un nombre réduit de fichiers d'empaquetage. Lors du rempaquetage, deux stratégies existent : « tout-en-un » et « géométrique ».\n\n\nLa stratégie tout-en-un est assez simple et constitue la stratégie par défaut actuelle. Comme son nom l'indique, tous les objets du dépôt sont empaquetés dans un seul fichier. Cette approche est idéale pour le dépôt d'un point de vue des performances, car Git n'a besoin de parcourir qu'un seul fichier d'empaquetage lors de la recherche d'objets. Le principal inconvénient ? Le calcul d'un fichier d'empaquetage unique pour un dépôt peut prendre beaucoup de temps en cas de dépôt volumineux.\n\n\nLa stratégie géométrique permet d'atténuer ce problème en maintenant une progression géométrique des fichiers d'empaquetage en fonction de leur taille, au lieu de toujours rempaqueter dans un seul fichier. Lors du rempaquetage, Git maintient un ensemble de fichiers d'empaquetage classés par taille, où chaque fichier de la séquence doit avoir au moins deux fois la taille du fichier d'empaquetage précédent. Si un fichier d'empaquetage de la séquence enfreint cette propriété, les fichiers d'empaquetage sont combinés selon les besoins jusqu'à ce que la progression soit rétablie. Cette stratégie permet de limiter le nombre de fichiers d'empaquetage dans un dépôt tout en minimisant également la quantité de travail à effectuer pour la plupart des opérations de rempaquetage.\n\n\nToutefois, la stratégie de rempaquetage géométrique n'était pas compatible avec les clones partiels. Ces derniers permettent de cloner uniquement certaines parties d'un dépôt (par exemple en ignorant tous les blobs de plus de 1 mégaoctet). Cette approche peut réduire considérablement la taille d'un dépôt, et Git sait comment récupérer les objets manquants auxquels il doit accéder ultérieurement.\n\n\nRésultat : nous obtenons un dépôt dans lequel il manque certains objets. Tout objet qui pourrait ne pas être entièrement connecté est stocké dans un fichier d'empaquetage « promisor ». Lors du rempaquetage, cette propriété promisor doit être conservée pour les fichiers d'empaquetage contenant un objet promisor, afin qu'il soit possible de déterminer si un objet manquant est attendu et peut être récupéré depuis le dépôt distant promisor. Avec une stratégie de rempaquetage tout-en-un, Git sait gérer correctement les objets promisor et les stocke dans un fichier d'empaquetage promisor distinct. Malheureusement, la stratégie de rempaquetage géométrique ne savait pas comment accorder un traitement spécial aux fichiers d'empaquetage promisor et les fusionnait avec des fichiers d'empaquetage normaux sans tenir compte de la présence d'objets promisor. Heureusement, en raison d'un bogue, la commande git-pack-objects(1) sous-jacente échoue lors de l'utilisation du rempaquetage géométrique dans un dépôt de clone partiel. Les dépôts dans cette configuration ne pouvaient donc de toute façon pas être rempaquetés. Ce n'est pas idéal, mais c'est un résultat préférable à une corruption du dépôt.\n\n\nAvec la sortie de Git 2.53, le rempaquetage géométrique fonctionne désormais avec les dépôts de clones partiels. Lors d'un rempaquetage géométrique, les fichiers d'empaquetage promisor sont gérés séparément afin de préserver le marqueur promisor et sont rempaquetés selon une progression géométrique distincte. Avec ce correctif, la stratégie géométrique suit une progression logique en vue de s'imposer comme la stratégie de rempaquetage par défaut. Pour plus d'informations, consultez le [fil de discussion de la liste de diffusion](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/) correspondant.\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n\n## git-fast-import(1) : préservation des signatures valides uniquement \n\n\nDans notre [article de blog consacré à la version Git 2.52](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-52-0/), nous avons abordé les améliorations liées aux signatures apportées à git-fast-import(1) et git-fast-export(1). Consultez cet article pour une explication plus détaillée de ces commandes, de leur utilisation et des modifications apportées concernant les signatures.\n\n\nPour résumer brièvement, git-fast-import(1) fournit un backend qui permet d'importer efficacement des données dans un dépôt et qui est utilisé par des outils tels que [git-filter-repo(1)](https://github.com/newren/git-filter-repo) pour aider à réécrire l'historique d'un dépôt en masse. Dans la version Git 2.52, git-fast-import(1) a appris l'option `--signed-commits=\u003Cmode>`, qui est similaire à la même option dans git-fast-export(1). Avec cette option, il est devenu possible de conserver ou de supprimer de façon inconditionnelle les signatures des commits et des tags.\n\n\nDans les situations où seule une partie de l'historique du dépôt a été réécrite, toute signature pour les commits ou tags réécrits devient invalide. Cela signifie que git-fast-import(1) est limité : la commande peut soit supprimer toutes les signatures, soit les conserver même si elles sont devenues invalides. Mais conserver des signatures invalides n'est pas vraiment utile, c'est pourquoi la réécriture de l'historique avec git-repo-filter(1) entraîne la suppression de toutes les signatures, même si le commit ou tag sous-jacent n'est pas réécrit. Cette approche n'est pas idéale : si le commit ou tag ne change pas, sa signature est toujours valide et il n'y a donc aucune raison réelle de la supprimer. Nous avons en réalité besoin de préserver les signatures pour les objets inchangés, et de supprimer les signatures invalides.\n\n\nAvec la sortie de Git 2.53, l'option `--signed-commits=\u003Cmode>` de git-fast-import(1) a appris un nouveau mode `strip-if-invalid` qui, lorsqu'il est utilisé, supprime seulement les signatures devenues invalides des commits réécrits. Ainsi, avec cette option, il devient possible de préserver certaines signatures de commits lors de l'utilisation de git-fast-import(1). Il s'agit d'une étape critique vers la mise en place des bases qui permettent à des outils comme git-repo-filter(1) de préserver les signatures valides et, plus tard, de signer à nouveau les signatures invalides.\n\n\nCe projet a été mené par [Christian Couder](https://gitlab.com/chriscool).\n\n\n## Plus de données collectées dans git-repo-structure\n\n\nDans la version Git 2.52, la sous-commande « structure » a été introduite dans git-repo(1). L'objectif de cette commande était de collecter des informations sur le dépôt et de remplacer éventuellement nativement des outils tels que [git-sizer(1)](https://github.com/github/git-sizer). Chez GitLab, nous hébergeons des dépôts extrêmement volumineux, et disposer d'informations sur la structure générale d'un dépôt est essentiel pour comprendre ses performances. Dans cette version, la commande collecte désormais également des informations sur la taille totale des objets accessibles dans un dépôt afin d'aider à comprendre la taille globale du dépôt. Dans les données de sortie ci-dessous, vous pouvez voir que la commande collecte désormais à la fois les tailles totales décompressées et sur disque des objets accessibles par type.\n\n```shell\n$ git repo structure\n\n| Repository structure | Value      |\n| -------------------- | ---------- |\n| * References         |            |\n|   * Count            |   1.78 k   |\n|     * Branches       |      5     |\n|     * Tags           |   1.03 k   |\n|     * Remotes        |    749     |\n|     * Others         |      0     |\n|                      |            |\n| * Reachable objects  |            |\n|   * Count            | 421.37 k   |\n|     * Commits        |  88.03 k   |\n|     * Trees          | 169.95 k   |\n|     * Blobs          | 162.40 k   |\n|     * Tags           |    994     |\n|   * Inflated size    |   7.61 GiB |\n|     * Commits        |  60.95 MiB |\n|     * Trees          |   2.44 GiB |\n|     * Blobs          |   5.11 GiB |\n|     * Tags           | 731.73 KiB |\n|   * Disk size        | 301.50 MiB |\n|     * Commits        |  33.57 MiB |\n|     * Trees          |  77.92 MiB |\n|     * Blobs          | 189.44 MiB |\n|     * Tags           | 578.13 KiB |\n```\n\n\nVous aurez peut-être également remarqué que les valeurs de taille dans le tableau des données de sortie sont désormais également affichées de manière plus conviviale avec des unités. Dans les versions suivantes, nous espérons étendre davantage les données de sortie de cette commande pour fournir des éléments supplémentaires, tels que les objets individuels les plus volumineux du dépôt.\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## Pour en savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette dernière version. Vous pouvez en apprendre davantage sur ces contributions dans l'[annonce de version officielle](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) du projet Git. Consultez également nos [articles de blog précédents sur les versions de Git](https://about.gitlab.com/fr-fr/tags/git/) pour découvrir d'autres contributions des membres de l'équipe GitLab.","2026-02-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[685],"Justin Tobler","Découvrez les contributions à cette version, notamment les correctifs apportés au rempaquetage géométrique, une évolution des options de gestion des signatures de commits dans git-fast-import(1), et bien plus encore.","Nouveautés de Git 2.53.0",{"featured":30,"template":13,"slug":689},"whats-new-in-git-2-53-0",{"content":691,"config":700},{"tags":692,"category":9,"date":693,"heroImage":683,"authors":694,"title":697,"description":698,"body":699},[23,24,261],"2025-11-19",[695,696,18],"Christian Couder","Toon Claes","Nouveautés de Git 2.52.0","Découvrez les contributions à cette version, notamment la nouvelle commande git-last-modified(1), les améliorations des outils de réécriture de l'historique et une nouvelle stratégie de maintenance.","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/) a récemment publié [Git 2.52](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/). Après un cycle de publication relativement court de 8 semaines pour la [version 2.51](https://about.gitlab.com/fr-fr/blog/what-s-new-in-git-2-51-0/), en raison de l'été dans l'hémisphère nord, cette version revient au cycle habituel de 12 semaines. Passons en revue certaines modifications notables, notamment les contributions de l'équipe Git de GitLab ainsi que de l'ensemble de la communauté Git.\n\n## Nouvelle commande git-last-modified(1)\n\nDe nombreuses forges Git comme GitLab affichent les fichiers dans une vue arborescente comme celle-ci :\n\n| Nom        | Dernier commit                                             | Dernière mise à jour  |\n| ------------- | --------------------------------------------------------- | -------------- |\n| README.md   | README: *.txt -> *.adoc fixes                           | Il y a 4 mois |\n| RelNotes    | Start 2.51 cycle, the first batch                       | Il y a 4 semaines  |\n| SECURITY.md | SECURITY: describe how to report vulnerabilities        | Il y a 4 ans      |\n| abspath.c   | abspath: move related functions to abspath              | Il y a 2 ans      |\n| abspath.h   | abspath: move related functions to abspath              | Il y a 2 ans      |\n| aclocal.m4  | configure: use AC_LANG_PROGRAM consistently             | Il y a 15 ans |\n| add-patch.c | pager: stop using `the_repository`                      | Il y a 7 mois |\n| advice.c    | advice: allow disabling default branch name advice      | Il y a 4 mois |\n| advice.h    | advice: allow disabling default branch name advice      | Il y a 4 mois |\n| alias.h     | rebase -m: fix serialization of strategy options        | Il y a 2 ans      |\n| alloc.h     | git-compat-util: move alloc macros to git-compat-util.h | Il y a 2 ans  |\n| apply.c     | apply: only write intents to add for new files          | Il y a 8 jours   |\n| archive.c   | Merge branch 'ps/parse-options-integers'                | Il y a 3 mois |\n| archive.h   | archive.h: remove unnecessary include                   | Il y a 1 an       |\n| attr.h      | fuzz: port fuzz-parse-attr-line from OSS-Fuzz           | Il y a 9 mois |\n| banned.h    | banned.h: mark `strtok()` and `strtok_r()` as banned    | Il y a 2 ans      |\n\n \u003Cbr>\u003C/br>\n\nOutre les fichiers eux-mêmes, nous affichons également le dernier commit qui a modifié chaque fichier. Cette information est facile à extraire de Git en exécutant la commande suivante :\n```shell\n\n$ git log --max-count=1 HEAD -- \u003Cfilename>\n\n```\nBien que simple et pratique, cette approche présente une limitation importante : Git ne dispose pas d'un moyen d'extraire cette information pour chacun de ces fichiers en une seule commande. Ainsi, pour obtenir le dernier commit de tous les fichiers de l'arborescence, il faut exécuter cette commande pour chaque fichier séparément, ce qui donne un pipeline similaire à celui-ci :\n```shell\n\n$ git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 HEAD --\n\n```\nNéanmoins, cette approche n'est pas très efficace :\n\n* Il est nécessaire de lancer une nouvelle commande Git pour chaque fichier.\n\n* Git doit parcourir l'historique de chaque fichier séparément.\n\nEn conséquence, cette opération complète est assez coûteuse et génère une charge importante pour GitLab.\n\nPour répondre à ces défis, une nouvelle sous-commande Git, git-last-modified(1), a été introduite. Elle indique le dernier commit pour chaque fichier d'un commit donné :\n```shell\n\n$ git last-modified HEAD\n\n\ne56f6dcd7b4c90192018e848d0810f091d092913        add-patch.c\n373ad8917beb99dc643b6e7f5c117a294384a57e        advice.h\ne9330ae4b820147c98e723399e9438c8bee60a80        advice.c\n5e2feb5ca692c5c4d39b11e1ffa056911dd7dfd3        alloc.h\n954d33a9757fcfab723a824116902f1eb16e05f7        RelNotes\n4ce0caa7cc27d50ee1bedf1dff03f13be4c54c1f        apply.c\n5d215a7b3eb0a9a69c0cb9aa43dcae956a0aa03e        archive.c\nc50fbb2dd225e7e82abba4380423ae105089f4d7        README.md\n72686d4e5e9a7236b9716368d86fae5bf1ae6156        attr.h\nc2c4138c07ca4d5ffc41ace0bfda0f189d3e262e        archive.h\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.c\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.h\n60ff56f50372c1498718938ef504e744fe011ffb        banned.h\n4960e5c7bdd399e791353bc6c551f09298746f61        alias.h\n2e99b1e383d2da56c81d7ab7dd849e9dab5b7bf0        SECURITY.md\n1e58dba142c673c59fbb9d10aeecf62217d4fc9c        aclocal.m4\n```\nL'avantage de cette approche est évident : nous n'avons plus besoin d'exécuter qu'un seul processus Git pour obtenir toutes ces informations. Mais plus important encore, Git ne doit parcourir l'historique qu'une seule fois pour tous les fichiers.\n\nVoici comment faire :\n\n1. Commencez à parcourir l'historique depuis le commit souhaité.\n2. Pour chaque commit :\n   1. S'il ne modifie aucun des chemins d'accès qui nous intéressent, continuez au commit suivant.\n   2. En cas de chemins d'accès modifiés, affichez l'identifiant du commit avec le chemin, puis retirez le chemin de l'ensemble des chemins.\n3. Arrêtez-vous lorsque la liste des chemins est vide.\nGitaly a déjà été adapté pour utiliser la nouvelle commande, mais la logique est encore protégée par un feature flag. Des tests préliminaires ont montré que dans la plupart des situations, `git-last-modified(1)` est au moins deux fois plus rapide que `git log --max-count=1`.\n\n*Ces modifications ont été [écrites à l'origine](https://github.com/ttaylorr/git/tree/tb/blame-tree) par plusieurs développeurs de GitHub et ont été [intégrées en amont](https://lore.kernel.org/git/20250805093358.1791633-1-toon@iotcl.com/) dans Git par [Toon Claes](https://gitlab.com/toon).*\n\n## Améliorations liées aux signatures pour git-fast-export(1) et git-fast-import(1)\n\nLes commandes `git-fast-export(1)` et `git-fast-import(1)` sont conçues pour être principalement utilisées par des outils d'interopérabilité ou de réécriture d'historique. Les outils d'interopérabilité ont pour objectif d'assurer des interactions harmonieuses entre Git et un autre logiciel, le plus souvent un système de contrôle de version qui stocke les données dans un format différent de Git. Par exemple, [hg-fast-export.sh](https://github.com/frej/fast-export) est un « convertisseur Mercurial vers Git utilisant git-fast-import ».\n\nLes outils de réécriture d'historique permettent aux utilisateurs, généralement des administrateurs, d'apporter des modifications à l'historique de leurs dépôts qui ne sont pas possibles ou pas autorisées par le système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/). Par exemple, [reposurgeon](http://www.catb.org/esr/reposurgeon/) indique dans son [introduction](https://gitlab.com/esr/reposurgeon/-/blob/master/repository-editing.adoc?ref_type=heads#introduction) que son objectif est « de permettre des opérations risquées que les systèmes de contrôle de version n'autorisent pas comme (a) modifier des commentaires et métadonnées passés, (b) supprimer des commits, (c) fusionner et diviser des commits, (d) supprimer des fichiers et sous-arbres de l'historique du dépôt, (e) fusionner ou greffer deux dépôts ou davantage et (f) diviser un dépôt en deux en dissociant une relation parent-enfant et en préservant la structure des branches des deux dépôts enfants ».\n\nAu sein de GitLab, nous utilisons [git-filter-repo](https://github.com/newren/git-filter-repo) pour autoriser les administrateurs à effectuer certaines opérations risquées sur leurs dépôts Git. Malheureusement, jusqu'à la [version Git 2.50](https://about.gitlab.com/fr-fr/blog/what-s-new-in-git-2-50-0/) publiée en juin dernier, ni `git-fast-export(1)` ni `git-fast-import(1)` ne prenaient en charge les signatures cryptographiques de commits. Bien que `git-fast-export(1)` ait une option `--signed-tags=\u003Cmode>` qui permette aux utilisateurs de modifier la façon dont les signatures cryptographiques de tags sont gérées, les signatures de commits étaient simplement ignorées.\n\nLes signatures cryptographiques sont très fragiles, car elles sont basées sur les données exactes du commit ou du tag qui ont été signées. Lorsque les données signées ou l'historique qui les précède changent, la signature cryptographique devient invalide. C'est une exigence fragile mais qui rend ces signatures utiles.\n\nDans le contexte de la réécriture d'historique, cette approche devient problématique :\n\n* Nous pourrions vouloir conserver les signatures cryptographiques pour les commits et les tags toujours valides après la réécriture (par exemple, parce que l'historique n'a pas changé).\n\n* Nous pourrions vouloir créer de nouvelles signatures cryptographiques pour les commits et les tags dont la signature précédente est désormais invalide.\n\nCependant, ni `git-fast-import(1)` ni `git-fast-export(1)` ne prennent en charge ces cas d'utilisation, ce que des outils comme [git-filter-repo](https://github.com/newren/git-filter-repo) ou [reposurgeon](http://www.catb.org/esr/reposurgeon/) ne peuvent accomplir.\n\nVoici les progrès significatifs réalisés :\n\n* Dans la version Git 2.50, nous avons ajouté une option `--signed-commits=\u003Cmode>` à `git-fast-export(1)` pour exporter les signatures de commits, et une prise en charge dans `git-fast-import(1)` pour les importer.\n\n* Dans la [version Git 2.51](https://about.gitlab.com/fr-fr/blog/what-s-new-in-git-2-51-0/), nous avons amélioré le format utilisé pour exporter et importer les signatures de commits et modifié `git-fast-import(1)` afin que la commande puisse importer à la fois une signature sur l'ID d'objet SHA-1 du commit et une sur son ID d'objet SHA-256.\n\n* Dans la version Git 2.52, nous avons ajouté les options `--signed-commits=\u003Cmode>` et `--signed-tags=\u003Cmode>` à `git-fast-import(1)`, afin que l'utilisateur puisse contrôler la gestion des données signées au moment de l'importation.\n\n\nLe travail n'est pas encore terminé. Nous devons encore ajouter les fonctionnalités suivantes :\n\n* Conserver uniquement les signatures de commits qui sont toujours valides dans `git-fast-import(1)`.\n\n* Signer à nouveau les données dont la signature est devenue invalide.\n\nNous avons déjà commencé à travailler sur ces prochaines étapes, qui devraient être intégrées à Git 2.53. Une fois ces fonctionnalités disponibles, des outils comme `git-filter-repo(1)` pourront enfin mieux gérer les signatures cryptographiques. Nous vous tiendrons informés dans notre prochain article de blog consacré à la sortie de version Git.\n\n*Ce projet a été mené par [Christian Couder](https://gitlab.com/chriscool).*\n\n## Améliorations des stratégies git-maintenance(1)\n\nLes dépôts Git nécessitent une maintenance régulière pour garantir de bonnes performances. Lors de cette opération, les références sont optimisées, les objets compressés et les données obsolètes éliminées.\n\nJusqu'à la version Git 2.28, ces tâches de maintenance étaient effectuées par `git-gc(1)`. Néanmoins, cette commande n'a pas été conçue dans un esprit de personnalisation : bien que certains paramètres puissent être configurés, il n'est pas possible de contrôler les parties d'un dépôt à optimiser. Elle ne convient donc pas à tous les cas d'utilisation. Plus important encore, il est très difficile d'itérer sur la façon dont Git effectue la maintenance du dépôt.\n\nPour résoudre ce problème et itérer à nouveau, [Derrick Stolee](https://github.com/derrickstolee) a déployé `git-maintenance(1)`. Contrairement à `git-gc(1)`, cette commande a été conçue pour être personnalisable et permet à l'utilisateur de configurer les tâches spécifiques qui doivent s'exécuter dans un certain dépôt. Ce nouvel outil est devenu l'outil par défaut pour la maintenance automatisée de Git dans la version Git 2.29, mais, par défaut, il utilise toujours `git-gc(1)` pour effectuer la maintenance.\n\nBien que cette stratégie de maintenance par défaut fonctionne bien pour les dépôts de petite taille ou même de taille moyenne, elle se révèle problématique dans le contexte de grands monorepos. Le principal facteur limitant est la façon dont `git-gc(1)` rempaquette les objets : dès que le nombre de fichiers d'empaquetage (« packfiles ») dépasse les 50, l'outil les fusionne en un seul fichier. Cette opération gourmande en CPU provoque de nombreuses opérations d'E/S et peut facilement prendre plusieurs minutes, voire des heures pour les grands monorepos.\n\nGit sait déjà comment minimiser ces rempaquetages via le « rempaquetage géométrique ». L'idée est simple : les fichiers d'empaquetage du dépôt doivent suivre une progression géométrique, c'est-à-dire que chaque fichier doit contenir au moins deux fois plus d'objets que le fichier suivant plus petit. Git peut ainsi amortir le nombre de rempaquetages requis et garantir une quantité relativement limitée de fichiers d'empaquetage. Ce mode a été introduit par [Taylor Blau](https://github.com/ttaylorr) dans la version Git 2.32, mais il n'était pas intégré dans la maintenance automatisée.\n\nTous les éléments existants servent à faciliter la mise à l'échelle de la maintenance du dépôt pour les grands monorepos : l'outil flexible `git-maintenance(1)` peut être étendu pour intégrer une nouvelle stratégie de maintenance, et nous disposons d'une meilleure méthode pour rempaqueter les objets. Il ne reste plus qu'à combiner ces deux éléments.\n\nEt c'est exactement ce que nous avons fait dans la version Git 2.52. La nouvelle stratégie de maintenance « géométrique » peut être configurée dans vos dépôts Git et est destinée à remplacer complètement l'ancienne stratégie basée sur `git-gc(1)`. Voici le code de configuration dont vous avez besoin :\n```shell\n\n$ git config set maintenance.strategy geometric\n\n```\nÀ partir de maintenant, Git utilisera le rempaquetage géométrique afin d'optimiser vos objets. Résultat : un taux d'attrition plus faible et une optimisation de l'état de vos objets, en particulier dans les grands monorepos.\n\nDans Git 2.53, nous prévoyons d'en faire la stratégie par défaut.\n\n*Ce projet a été dirigé par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n## Nouvelle sous-commande pour git-repo(1) afin d'afficher les métriques du dépôt\n\nLes performances des opérations Git dans un dépôt dépendent souvent de certaines caractéristiques de sa structure sous-jacente. Chez GitLab, nous hébergeons des dépôts extrêmement volumineux, et il est essentiel d'avoir un aperçu de la structure générale d'un dépôt pour comprendre ses performances. Bien qu'il soit possible de combiner diverses commandes Git et d'autres outils pour obtenir certaines métriques du dépôt, il est impossible d'afficher des informations sur la forme/structure d'un dépôt via une seule commande dans Git. Pour combler cette lacune, des outils externes comme git-sizer(1) ont été développés.\n\nAvec la sortie de Git 2.52, une nouvelle sous-commande « structure » a été ajoutée à git-repo(1) dans le but d'afficher des informations sur la structure d'un dépôt. Actuellement, elle indique le nombre de références et d'objets dans le dépôt sous la forme suivante :\n```shell\n\n$ git repo structure\n\n\n| Repository structure | Value  |\n| -------------------- | ------ |\n| * References         |        |\n|   * Count            |   1772 |\n|     * Branches       |      3 |\n|     * Tags           |   1025 |\n|     * Remotes        |    744 |\n|     * Others         |      0 |\n|                      |        |\n| * Reachable objects  |        |\n|   * Count            | 418958 |\n|     * Commits        |  87468 |\n|     * Trees          | 168866 |\n|     * Blobs          | 161632 |\n|     * Tags           |    992 |\n\n```\nDans les versions ultérieures, nous espérons enrichir cette commande et fournir d'autres points de données intéressants comme les objets les plus volumineux du dépôt.\n\n*Ce projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).*\n\n## Améliorations liées au Google Summer of Code 2025\n\nNous avons mené trois projets avec succès au cours du Google Summer of Code.\n\n### Refactorisation pour réduire l'état global de Git\n\nGit contient plusieurs variables globales utilisées dans tout le code source qui augmentent la complexité du code et réduisent sa maintenabilité. Dans le cadre de ce projet, [Ayush Chandekar](https://ayu-ch.github.io/) a réduit l'utilisation de la variable globale `the_repository` via une série de correctifs.\n\n*Le projet a été encadré par [Christian Couder](https://gitlab.com/chriscool) et [Ghanshyam Thakkar](https://in.linkedin.com/in/ghanshyam-thakkar).*\n\n### Outil de requête d'informations lisibles par machine sur le dépôt\n\nGit manque d'un moyen centralisé pour récupérer des informations sur les dépôts. Les utilisateurs sont donc obligés de les obtenir à partir de diverses commandes. Bien que `git-rev-parse(1)` soit devenu l'outil par défaut pour accéder à une grande partie de ces données, il ne s'agit pas de son objectif principal.\n\nDans le cadre de ce projet, [Lucas Oshiro](https://lucasoshiro.github.io/en/) a créé une nouvelle commande, `git-repo(1)`, qui centralisera toutes les informations au niveau du dépôt. Les utilisateurs peuvent maintenant utiliser `git repo info` pour obtenir des informations sur un dépôt :\n```shell\n\n$ git repo info layout.bare layout.shallow object.format references.format\n\nlayout.bare=false\nlayout.shallow=false\nobject.format=sha1\nreferences.format=reftable\n\n```\n*Le projet a été encadré par [Patrick Steinhardt](https://gitlab.com/pks-gitlab) et [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n### Consolidation des fonctionnalités liées aux références dans git-refs\n\nGit propose plusieurs commandes pour gérer les références, à savoir `git-for-each-ref(1)`, `git show-ref(1)`, `git-update-ref(1)` et `git-pack-refs(1)`. Cette multiplication des commandes freine leur utilisation et crée des fonctionnalités redondantes. Pour résoudre ce problème, nous avons développé la commande `git-refs(1)` afin de consolider ces opérations dans une interface unique. Dans le cadre de ce projet, [Meet Soni](https://inosmeet.github.io/) a étendu la commande avec les sous-commandes suivantes :\n\n* `git refs optimize` pour optimiser le backend qui gère les références\n\n* `git refs list` pour afficher toutes les références\n\n* `git refs exists` pour vérifier l'existence d'une référence\n\n*Le projet a été encadré par [Patrick Steinhardt](https://gitlab.com/pks-gitlab) et [shejialuo](https://luolibrary.com/).*\n\n## Et après ?\n\nPrêt à découvrir ces améliorations ? Passez à la version Git 2.52.0 et commencez à utiliser `git last-modified`.\n\nChez GitLab, nous nous assurerons que toutes ces améliorations soient déployées dans une instance GitLab près de chez vous !\n\nPour en savoir plus, consultez les [notes de version officielles de Git 2.52.0](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) et explorez notre [archive complète du développement Git](https://about.gitlab.com/fr-fr/blog/tags/git/).",{"featured":30,"template":13,"slug":701},"whats-new-in-git-2-52-0",{"content":703,"config":713},{"title":704,"description":705,"authors":706,"date":708,"body":709,"category":9,"tags":710,"heroImage":712},"Qu’est-ce que Docker ? Notre guide complet","Découvrez ce qu’est Docker, comment il fonctionne, ses avantages et ses limites, et son intégration avec GitLab pour une approche DevSecOps complète.",[707],"GitLab France Team","2025-10-10","Docker a révolutionné la façon dont les équipes de développement créent, déploient et exécutent leurs applications grâce à une approche innovante : la conteneurisation. Cette approche est devenue incontournable dans le développement logiciel, car elle simplifie considérablement la gestion des environnements et accélère le cycle de développement logiciel. \n\nDans ce guide complet, découvrez tout ce qu'il faut savoir sur Docker : sa définition, son fonctionnement, ses avantages et son application dans un environnement [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSevOps ?\") avec la plateforme de GitLab. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial\n\"Essai gratuit de GitLab.\") \n\n## Docker : définition\n\nDocker est une plateforme de conteneurisation [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui permet aux équipes de développement d'empaqueter leurs applications et toutes leurs dépendances dans des conteneurs légers et portables. Lancé en 2013, Docker a démocratisé l'utilisation des conteneurs en proposant une solution simple et accessible pour créer des environnements d'exécution isolés.\n\n### Qu’est-ce qu’un conteneur Docker ?\n\nUn conteneur Docker représente un environnement d'exécution léger qui encapsule une application avec l'ensemble de ses composants : code source, bibliothèques, dépendances système, variables d'environnement et fichiers de configuration. Il peut parfois être comparé à une machine virtuelle dans le sens où il permet d’héberger des services sur un même serveur physique tout en les isolant les uns des autres. Néanmoins, le fonctionnement d’un conteneur diffère légèrement d’une simple machine virtuelle. \n\nMoins figés qu'une machine virtuelle, en matière de taille de disque et de ressources allouées, les conteneurs partagent le noyau de la machine hôte et isolent les processus, les utilisateurs, etc. Cela les rend très légers et leur permet de fonctionner comme s'ils étaient des machines distinctes. Par conséquent, les applications peuvent être démarrées et arrêtées rapidement.\n\n## Comment fonctionne Docker ?\n\nDocker révolutionne la virtualisation en exploitant les capacités natives du noyau Linux pour créer des environnements d'exécution légers et isolés. Contrairement à la virtualisation traditionnelle qui nécessite des machines virtuelles complètes avec leur propre système d'exploitation, Docker utilise la conteneurisation pour partager le noyau de l'hôte tout en maintenant une isolation parfaite entre les applications.\n\nLa philosophie de Docker repose sur des technologies Linux avancées telles que les namespaces (qui isolent les processus, le réseau et le système de fichiers) et les cgroups (qui limitent et contrôlent l'utilisation des ressources). Docker encapsule ces fonctionnalités complexes dans une interface simple et portable, permettant aux équipes de développement de créer des environnements cohérents sur n'importe quelle plateforme.\n\nLe processus de conteneurisation avec Docker suit un cheminement précis :\n\n1. **Création d'un Dockerfile :** ce fichier texte contient les instructions pour construire l'environnement\n2. **Construction d’une image docker** : Docker assemble les composants selon les spécifications du Dockerfile\n3. **Instanciation du conteneur** : l'image devient un conteneur exécutable\n4. **Gestion du cycle de vie** : démarrage, arrêt, surveillance et mise à jour des conteneurs\n\nPour comprendre pleinement le fonctionnement de Docker, il est essentiel de maîtriser les quatre composants fondamentaux suivants, qui contribuent à créer un écosystème de conteneurisation complet et efficace.\n\n### Docker Engine : le cœur du système\n\n[Docker Engine](https://docs.docker.com/engine/) est le moteur qui orchestre toutes les opérations de conteneurisation. Cette architecture client-serveur se compose de trois éléments interconnectés qui travaillent en harmonie :\n\n**Docker Daemon ([dockerd](https://docs.docker.com/reference/cli/dockerd/))** constitue le service central qui s'exécute en permanence sur le système hôte et gère l'ensemble du cycle de vie des conteneurs. Il supervise la création, l'exécution, la surveillance et la destruction des conteneurs, tout en gérant les images, les réseaux virtuels et les volumes de stockage. Ce daemon écoute en permanence les requêtes et exécute les opérations demandées.\n\n**L'API REST Docker** est le mode de communication principal avec Docker Daemon. Concrètement, quand vous lancez `docker run` ou [`docker build`](https://docs.gitlab.com/ci/docker/using_docker_build/), votre commande est transformée en requête HTTP qui est envoyée au daemon. Cette API permet également aux équipes de développement de créer leurs propres outils ou d'automatiser Docker dans leurs scripts et applications.\n\n**Le client Docker CLI** représente l'interface en ligne de commande que les utilisateurs emploient quotidiennement. Chaque commande `docker` (run, build, push, pull) transite par ce client qui communique avec le daemon via l'[API REST](https://about.gitlab.com/fr-fr/blog/2024/09/04/what-is-rest-api/ \"Qu'est-ce qu'une API REST ?\").\n\n### Images Docker : les modèles d'exécution\n\nUne **image Docker** constitue un modèle immuable et en lecture seule qui encapsule l'ensemble des éléments nécessaires à l'exécution d'une application. Cette image contient le système de fichiers complet, incluant le code source, les bibliothèques système, les dépendances, les variables d'environnement et les métadonnées de configuration.\n\nL'architecture en couches des images Docker représente l'une des innovations les plus importantes de cette technologie. Chaque instruction dans un Dockerfile crée une nouvelle couche et Docker utilise un système de cache intelligent pour réutiliser les couches communes entre différentes images. Cette approche optimise considérablement l'espace de stockage et accélère les processus de construction et de téléchargement.\n\nLes images sont identifiées par des tags qui combinent un nom et une version (comme `nginx:latest`, `ubuntu:20.04` ou `node:18-alpine`). Ces tags permettent aux équipes de développement de spécifier précisément quelle version d'une image utiliser dans leurs déploiements.\n\n### Dockerfile : automatiser la construction\n\nLe **Dockerfile** représente bien plus qu'un simple script d'instructions : il constitue la recette complète pour reproduire fidèlement un environnement d'exécution. Ce fichier texte utilise une syntaxe déclarative simple pour définir chaque étape de la construction d'une image.\n\nUn Dockerfile typique commence par spécifier une image de base (instruction FROM), puis enchaîne les opérations : installation de dépendances (`RUN`), copie de fichiers (`COPY` ou `ADD`), configuration d'environnement (`ENV`), exposition de ports (`EXPOSE`), et définition de la commande par défaut (`CMD` ou `ENTRYPOINT`).\n\nCette approche Infrastructure as Code garantit la reproductibilité parfaite des environnements et s'inscrit parfaitement dans les pratiques [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") actuelles. En documentant explicitement toutes les étapes de configuration dans un fichier versionable, le Dockerfile facilite la collaboration entre les équipes de développement et les opérateurs.\n\n### Docker Registry : partager et distribuer\n\nLes registres Docker fonctionnent comme des dépôts centralisés qui permettent de stocker, versioner et distribuer des images Docker de manière sécurisée. Ils constituent l'épine dorsale de l'écosystème Docker en facilitant la collaboration et le partage d'images.\n\n**[Docker Hub](https://www.docker.com/products/docker-hub/)** demeure le registre public officiel, hébergeant des millions d'images communautaires et officielles. Les équipes de développement peuvent y trouver des images prêtes à l'emploi : bases de données, serveurs web, etc. \n\nLes entreprises peuvent également déposer leurs images dans des **registres privés** garantissant la sécurité et le contrôle des accès. Ces registres privés peuvent être auto hébergés (on-premise) ou dans le cloud.\n\n## Pourquoi utiliser Docker ?\n\nLe développement d'applications fait face à des défis croissants : multiplication des environnements de déploiement, diversité des technologies utilisées, cycles de livraison accélérés et exigences de fiabilité toujours plus élevées. Les équipes de développement jonglent quotidiennement avec des problématiques complexes qui ralentissent leur productivité et augmentent les risques d'erreur.\n\nEn ce sens, Docker répond directement ou indirectement à ces problématiques récurrentes dans le développement logiciel.\n\n**Uniformisation des environnements** : Docker élimine le fameux « ça marche sur ma machine » en garantissant que l'application s'exécute de manière identique sur tous les environnements, du poste de développement à la production.\n\n**Simplification des déploiements** : l'empaquetage de l'application et de ses dépendances dans un conteneur unique simplifie considérablement les processus de déploiement et réduit les risques d'erreur.\n\n**Isolation des applications** : chaque conteneur dispose de son propre espace d'exécution, évitant les conflits entre différentes versions de bibliothèques ou de dépendances.\n\n**Accélération du développement** : les équipes de développement peuvent rapidement lancer des environnements complexes sans configuration manuelle fastidieuse.\n\n**Optimisation des ressources informatiques** : Docker permet une utilisation plus efficace des ressources serveur comparé aux machines virtuelles traditionnelles. Plusieurs conteneurs peuvent partager le même noyau système tout en maintenant leur isolation, réduisant ainsi l'empreinte mémoire et CPU. \n\nCette efficacité se traduit par :\n\n* Des temps de démarrage considérablement réduits\n* Une densité d'applications plus élevée par serveur\n* Une consommation énergétique optimisée\n* Des coûts d'infrastructure réduits\n\n## Quels sont les avantages de Docker ?\n\nMaintenant que nous avons vu pourquoi Docker est si populaire, intéressons-nous davantage aux avantages qu'il apporte concrètement aux équipes de développement. \n\n### Portabilité et cohérence\n\nDocker garantit que les applications fonctionnent de manière identique quel que soit l'environnement d'exécution. Cette portabilité facilite :\n\n* La migration d'applications entre différents fournisseurs cloud\n* Le déploiement sur des architectures hybrides (on-premise et cloud)\n* La création d'environnements de test fidèles à la production\n* La distribution d'applications complexes\n\n### Scalabilité et performance\n\nLes conteneurs Docker offrent une flexibilité exceptionnelle pour adapter les ressources aux besoins applicatifs :\n\n* **Montée en charge horizontale** : ajout rapide de nouvelles instances de conteneurs selon la demande\n* **Optimisation des ressources** : allocation précise des ressources CPU et mémoire par conteneur\n* **Démarrage instantané** : les conteneurs se lancent en quelques secondes contre plusieurs minutes pour les machines virtuelles\n* **Efficacité réseau** : gestion sophistiquée des réseaux virtuels entre conteneurs\n\n### Facilitation du DevOps\n\nDocker s'intègre naturellement dans les pratiques DevOps en :\n\n* Automatisant les processus de compilation et de déploiement\n* Facilitant l'intégration et le déploiement continus ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"))\n* Permettant des tests reproductibles dans des environnements isolés\n* Accélérant les cycles de développement et de livraison\n\n### Écosystème et communauté\n\nL'écosystème Docker bénéficie d'une communauté active qui développe :\n\n* Des milliers d'images officielles et communautaires sur Docker Hub\n* Des outils d'orchestration de conteneurs comme Docker Swarm (natif à Docker) et Kubernetes\n* Des solutions de monitoring et de logging adaptées aux conteneurs\n* Des intégrations avec les principales plateformes cloud\n\n## Quelles sont les limites de Docker ?\n\nComme nous venons de le voir, Docker présente de nombreux avantages, mais aussi certains inconvénients, dont il convient de prendre connaissance avec de plonger dans l’écosystème Docker.\n\n### Limitation à un seul système d'exploitation\n\nDocker crée plusieurs conteneurs sur un seul système d'exploitation. Si cette approche offre des avantages en termes de vitesse de démarrage et de traitement, elle peut également présenter des inconvénients. Par exemple, si vous souhaitez tester votre application dans un environnement Windows alors que votre machine hôte fonctionne sous Linux, vous devrez préparer une machine ou une machine virtuelle séparée.\n\n### Surcharge lors du développement à grande échelle\n\nDocker est léger en lui-même, mais lorsqu'il est étendu à un système de grande envergure, la charge de gestion de Docker entre en jeu. Docker peut faire fonctionner de nombreux conteneurs sur un seul serveur, mais d'un autre côté, cela nécessite une gestion et une orchestration qui peuvent générer une surcharge. Il peut également devenir difficile de tout gérer en utilisant Docker seul sans recourir à des outils d’orchestration comme Docker Swarm ou encore [Kubernetes](https://about.gitlab.com/fr-fr/blog/2024/07/25/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\").\n\n### Courbe d'apprentissage exigeante\n\nDocker utilise une méthode différente pour créer des environnements virtuels par rapport aux autres machines virtuelles. Cela signifie que les équipes de développement doivent apprendre et appréhender tous ces nouveaux concepts. Utiliser Docker sans bien comprendre son fonctionnement peut entraîner des problèmes par la suite. Il est important d'étudier Docker de manière approfondie avant de commencer à l'utiliser.\n\n### Vulnérabilités de sécurité potentielles\n\nDocker utilise une architecture basée sur les conteneurs. Comme plusieurs conteneurs fonctionnent sur une seule machine, il faut faire attention aux vulnérabilités qui peuvent en découler. Par exemple, s'il y a une vulnérabilité dans un conteneur, elle pourrait affecter tous les autres conteneurs qui partagent les ressources du système d'exploitation hôte et le noyau.\n\n### Difficultés dans la coopération entre conteneurs\n\nLorsque vous envisagez l'intégration entre plusieurs conteneurs, diverses configurations peuvent être difficiles, ce qui peut conduire à des problèmes opérationnels. Par exemple, si vous créez une application et une base de données dans des conteneurs séparés et souhaitez les faire fonctionner ensemble, vous devez configurer les paramètres de communication au sein du même hôte. L'ouverture de ports et de sockets pose des risques de sécurité. Si vous rendez les paramètres trop compliqués pour éviter cela, vous risquez alors de rencontrer des problèmes en production. Lors de l'intégration de conteneurs, il est important de bien réfléchir dès la phase de conception.\n\n### Comment GitLab résout les défis de Docker ?\n\nGitLab transforme Docker d'un simple outil de conteneurisation en une solution DevSecOps complète et sécurisée. Cette plateforme intégrée résout les principaux défis auxquels font face les organisations utilisant Docker à grande échelle.\n\nL'approche \"shift-left\" de GitLab intègre les contrôles de sécurité directement dans le pipeline de développement. Plutôt que de traiter la sécurité comme une étape finale, GitLab analyse automatiquement les images Docker dès leur construction, détectant les vulnérabilités, les configurations dangereuses et les dépendances obsolètes avant le déploiement. Cette détection précoce réduit considérablement les coûts de remédiation et élimine les risques de sécurité en production.\n\nGitLab Runner et ses pipelines CI/CD transforment la gestion des conteneurs Docker en automatisant l'ensemble du cycle de vie DevSecOps. Cette infrastructure d'exécution permet la construction automatisée d'images Docker optimisées, la validation automatique de la sécurité et des performances et l'orchestration sécurisée vers différents environnements.\n\n## Le rôle de Docker dans l’approche DevSecOps de GitLab\n\nDocker joue également un rôle très important dans l'intégration DevSecOps avec GitLab.\n\n### Conteneurisation des jobs CI/CD\n\nGitLab CI/CD vous permet d'utiliser des conteneurs Docker dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), vous apportant :\n\n* **Cohérence** : les jobs CI/CD s'exécutent dans des conteneurs, éliminant les erreurs dues aux différences de dépendances et d'environnements\n* **Scalabilité** : les conteneurs sont légers, rapides à démarrer et efficaces pour exécuter de larges pipelines\n* **Flexibilité d'environnement** : vous pouvez spécifier différentes images Docker pour chaque job, facilitant la mise à disposition de l'environnement requis\n\nL'image Docker GitLab Runner est basée sur Ubuntu ou Alpine Linux et inclut les commandes standard `gitlab-runner` qui la font fonctionner comme si vous aviez installé GitLab Runner directement sur l'hôte.\n\n### Scanning de sécurité automatisé\n\nLa sécurité est un composant clé de l’approche DevSecOps. GitLab la prend en charge dans les applications conteneurisées avec Docker à l’aide des scannings suivants : \n\n* **Scanning de sécurité des images de conteneurs** : fournit la capacité de scanner les images Docker dans vos pipelines CI/CD, vérifiant les vulnérabilités des packages OS afin d'évaluer la sûreté des images avant qu’elles n’atteignent l’environnement de production \n* **[Scanning en continue des vulnérabilités de conteneurs](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)** : recherche les failles de sécurité dans les dépendances existantes des applications en se basant sur leur SBOM et en comparant les noms et les versions des composants aux informations contenues dans les derniers avis de sécurité.\n* **[Scanning opérationnel de conteneurs](https://about.gitlab.com/blog/improve-security-auditing-with-gitlab-operational-container-scanning/)** : exécute les analyses de vulnérabilités sur les conteneurs déployés dans un environnement Kubernetes. Cela comprend l'analyse régulière des images à la recherche de nouvelles vulnérabilités découvertes et le suivi des environnements dans lesquels ces vulnérabilités sont déployées.\n\n### Infrastructure as Code (IaC) et gestion d'environnement\n\n* **Reproductibilité** : l’utilisation de Docker dans les jobs GitLab CI/CD assure la cohérence entre les environnements de développement et de production.\n* **Création instantanée d'environnements de staging et de test** : en s'intégrant avec Docker Compose et Kubernetes, GitLab vous permet de créer des environnements isolés pour des branches spécifiques ou des merge requests, permettant des tests efficaces et un scanning de sécurité.\n\n### Déploiement rationalisé\n\nGitLab supporte les modèles de déploiement suivants avec Docker :\n\n* **Compilation et push d'images Docker** : construisez votre application sous forme d’image de conteneur et effectuez un push vers le registre de conteneurs de GitLab ou d'autres registres Docker.\n* **[Livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ?\")** : utilisez des images Docker et déployez vers des outils d'orchestration de conteneurs pour des releases rapides et sécurisées.\n\n### Prise en charge de l'architecture de microservices\n\nGitLab et Docker ensemble facilitent la construction d'[architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\"), où les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ?\") s'exécutent comme des conteneurs Docker séparés. \n\nAvec les pipelines GitLab CI/CD, vous pouvez gérer :\n\n* La configuration des dépendances entre services\n* Les scans de sécurité individuels\n* Le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") (facilite les retours à une version précédente)\n\n## Conclusion\n\nDocker a transformé le paysage du développement logiciel en démocratisant la conteneurisation et en simplifiant la gestion des environnements d'exécution. Sa capacité à créer des applications portables, légères et facilement déployables en fait aujourd’hui un outil incontournable pour les équipes de développement.\n\nL'intégration native avec GitLab renforce encore davantage sa valeur en proposant une plateforme DevSecOps complète. Cette synergie permet aux entreprises d'accélérer leurs cycles de développement logiciel tout en maintenant des standards élevés de sécurité et de qualité.\n\nPour les équipes souhaitant moderniser leurs pratiques de développement, l'adoption de Docker représente un investissement stratégique qui se traduit par une productivité accrue, des déploiements plus fiables, une meilleure évolutivité et un environnement flexible.\n\n> Vous souhaitez installer GitLab dans un conteneur Docker ? Consultez notre [documentation](https://docs.gitlab.com/install/docker/) pour en savoir plus. \n\n## FAQ sur Docker\n\n### Que peut-on faire avec Docker ?\n\nDocker est une technologie de virtualisation légère et autonome qui empaquette le code d'application, ses dépendances et ses bibliothèques. Docker vous permet de créer plusieurs conteneurs (environnements virtuels) sur une seule machine, vous permettant d'unifier vos environnements de développement et de test. \n\n### À quoi sert Docker ?\n\nDocker est utilisé par les équipes de développement pour découpler les applications et leurs dépendances du reste du système. Les conteneurs regroupent les applications et leurs dépendances ensemble et fournissent un environnement d'exécution léger.\n\n### Docker peut-il remplacer les machines virtuelles ?\n\nDocker ne remplace pas complètement les machines virtuelles, mais offre une alternative plus légère pour de nombreux cas d'usage. Les conteneurs partagent le noyau du système hôte, tandis que les machines virtuelles émulent un système complet. Le choix dépend de vos besoins en isolation, performance et compatibilité système.\n\n*Note : certaines parties de cet article proviennent de l'article japonais [Dockerとは：超入門編](https://about.gitlab.com/ja-jp/blog/what-is-docker/).*",[711,106],"DevSecOps","https://res.cloudinary.com/about-gitlab-com/image/upload/v1760102032/qsxbap3mitapwa5tko76.jpg",{"featured":30,"template":13,"slug":714},"what-is-docker-comprehensive-guide",{"promotions":716},[717,731,744],{"id":718,"categories":719,"header":721,"text":722,"button":723,"image":728},"ai-modernization",[720],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":724,"config":725},"Get your AI maturity score",{"href":726,"dataGaName":727,"dataGaLocation":243},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":729},{"src":730},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":732,"categories":733,"header":736,"text":722,"button":737,"image":741},"devops-modernization",[734,735],"product","devsecops","Are you just managing tools or shipping innovation?",{"text":738,"config":739},"Get your DevOps maturity score",{"href":740,"dataGaName":727,"dataGaLocation":243},"/assessments/devops-modernization-assessment/",{"config":742},{"src":743},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":745,"categories":746,"header":748,"text":722,"button":749,"image":753},"security-modernization",[747],"security","Are you trading speed for security?",{"text":750,"config":751},"Get your security maturity score",{"href":752,"dataGaName":727,"dataGaLocation":243},"/assessments/security-modernization-assessment/",{"config":754},{"src":755},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":757,"blurb":758,"button":759,"secondaryButton":763},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":45,"config":760},{"href":761,"dataGaName":48,"dataGaLocation":762},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":50,"config":764},{"href":52,"dataGaName":53,"dataGaLocation":762},1772652093780]