[{"data":1,"prerenderedAt":814},["ShallowReactive",2],{"/fr-fr/blog/what-s-new-in-git-2-50-0":3,"navigation-fr-fr":36,"banner-fr-fr":451,"footer-fr-fr":461,"blog-post-authors-fr-fr-Justin Tobler":699,"blog-related-posts-fr-fr-what-s-new-in-git-2-50-0":713,"blog-promotions-fr-fr":751,"next-steps-fr-fr":805},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":11,"meta":27,"navigation":28,"path":29,"publishedDate":21,"seo":30,"stem":33,"tagSlugs":34,"__hash__":35},"blogPosts/fr-fr/blog/what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0",[7],"justin-tobler",null,"open-source",{"featured":11,"template":12,"slug":13},false,"BlogPost","what-s-new-in-git-2-50-0",{"body":15,"title":16,"description":17,"heroImage":18,"authors":19,"date":21,"category":9,"tags":22},"Le projet Git a récemment publié la [version 2.50.0 de Git](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u).\nDécouvrons les points forts de cette nouvelle version, qui comprend les contributions de l'équipe Git de GitLab et de la communauté Git.\n\n## Nouvelle commande git-diff-pairs(1)\n\nLes diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet [« Modifications »](https://docs.gitlab.com/user/project/merge_requests/changes/) d'une merge request. En arrière-plan, la génération de diff est effectuée par [`git-diff(1)`](https://git-scm.com/docs/git-diff).\n\nPar exemple :\n\n```shell\n$ git diff HEAD~1 HEAD\n```\n\nCette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème de performance, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser le délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à traiter.\n\nPour ce faire, vous pouvez utiliser [`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree/fr) pour récupérer des informations sur tous les fichiers modifiés :\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n```\n\nGit appelle ce résultat le [format « brut »](https://git-scm.com/docs/git-diff-tree/fr). En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de diffs pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer une détection de changement de nom en ajoutant `-M` pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.\n\nAvec ces informations, nous pourrions utiliser `git-diff(1)` pour calculer chacun des diffs de paire de fichiers individuellement.\n\nPar exemple, nous pouvons fournir directement des ID de blob :\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n```\n\nNous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme pouvant recevoir des informations « brutes » sur les paires de fichiers et générant en sortie les diffs correspondants.\n\nAvec la version 2.50.0, Git dispose d’une nouvelle commande intégrée `git-diff-pairs(1)`, qui reçoit sur son entrée standard (« stdin ») les informations de paires de fichiers au format « brut » pour déterminer avec précision les diffs à générer.\n\nL'exemple suivant montre comment cette commande peut être utilisée :\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nDe cette façon, la sortie générée est identique à celle obtenue avec `git-diff(1)`. En utilisant une commande distincte pour générer la sortie de diffs, la sortie « brute » de `git-diff-tree(1)` peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus `git-diff-pairs(1)` distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.\n\nPour plus d'informations sur ce changement, consultez ce [fil de discussion](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n## Mises à jour des références par lots\n\nGit fournit la commande `git-update-ref(1)` pour effectuer des mises à jour de références. Lorsqu'elle est associée à `--stdin`, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur l'entrée standard (« stdin »). La mise à jour des références en un seul lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.\n\nVoici un exemple illustrant ce comportement :\n\n```shell\n# Create repository with three empty commits and branch named \"foo\"\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n# Print out the commit IDs\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n# Update is expected to fail because the specified old object ID doesn’t match.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# The \"bar\" reference was not created.\n\n$ git switch bar\n\nfatal: invalid reference: bar\n```\n\nEn comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Mais nous voulons quand même bénéficier de l'efficacité des mises à jour par lot.\n\nAvec cette version, `git-update-ref(1)` met à disposition la nouvelle option `--batch-updates`, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.\n\nDans ce mode, les échecs individuels sont signalés dans le format suivant :\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n```\n\nIl est ainsi possible de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.\n\nVoici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :\n\n```shell\n# Attempt to create a new reference and update existing reference in transaction.\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n\n$ git switch bar\n\nSwitched to branch 'bar'\n```\n\nCette fois, avec l'option `--batch-updates`, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de diffs est un aperçu des futures améliorations des performances de `git-fetch(1)` et `git-receive-pack(1)` lors de la mise à jour de références par lot.\n\nPour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/).\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Nouvelle option de filtre pour git-cat-file(1)\n\nAvec `git-cat-file(1)`, il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option `--batch–all-objects`.\n\nEn voici un exemple :\n\n```shell\n# Setup simple repository.\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n# Create an unreachable object.\n\n$ git commit --amend --no-edit\n\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nDans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.\n\nPar exemple, si nous voulons voir uniquement les objets qui sont des commits, nous pouvons utiliser `grep(1)` :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nBien que cela fonctionne, un des inconvénients du filtrage de la sortie est que `git-cat-file(1)` doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.\n\nAvec la version 2.50.0, `git-cat-file(1)` dispose désormais de l'option `--filter`, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour `git-rev-list(1)`, mais seul un sous-ensemble des filtres est pris en charge : `blob:none`, `blob:limit=`, ainsi que `object:type=`.\n\nComme dans l'exemple précédent, il est possible de filtrer les objets par type avec [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") directement :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nNon seulement il est pratique de laisser Git s'occuper du traitement, mais pour les dépôts volumineux contenant de nombreux objets, c'est aussi potentiellement plus efficace. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage (« packfile »), ce qui accélère significativement le processus.\n\nLes benchmarks effectués sur le [dépôt Chromium](https://github.com/chromium/chromium.git) montrent des améliorations significatives :\n\n```text\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\n\nRange (min … max): 73.936 s … 89.690 s 10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\n\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\n\nRange (min … max): 1.541 s … 1.566 s 10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\n\nRange (min … max): 11.114 s … 11.245 s 10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\n\nRange (min … max): 62.836 s … 73.618 s 10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\n\nRange (min … max): 12.960 s … 13.199 s 10 runs\n\nSummary\n\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\n3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n```\n\nIl est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n## Amélioration des performances lors de la génération d'archives\n\nAvec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui les accompagnent via la commande [`git-bundle(1)`](https://git-scm.com/docs/git-bundle/fr). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme [`bundle-URI`](https://git-scm.com/docs/bundle-uri).\n\nPour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab ([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans l'archive. L'implémentation utilisait une boucle `for` imbriquée pour itérer et comparer toutes les références répertoriées, ce qui entrainait une complexité temporelle O(N^2). Cette façon de procéder dégradait fortement les performances à mesure que le nombre de références dans un dépôt augmentait.\n\nDans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par un tableau associatif, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'une archive avec un dépôt contenant 100 000 références :\n\n```text\nBenchmark 1: bundle (refcount = 100000, revision = master)\n\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\n\nRange (min … max): 14.237 s … 14.920 s 10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\n\nRange (min … max): 2.364 s … 2.425 s 10 runs\n\nSummary\n\nbundle (refcount = 100000, revision = HEAD) ran\n\n6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nPour en savoir plus, découvrez notre article de blog qui explique [comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) et consultez ce [fil de discussion](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n*Ce projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n## Meilleur dégroupage des URI d'archives\n\nÀ l'aide du mécanisme [bundle-uri](https://git-scm.com/docs/bundle-uri) dans Git, il est possible de fournir aux clients les emplacements pour récupérer des archives dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge une archive, les références sous `refs/heads/*` et les objets qui les accompagnent sont copiés de l'archive dans le dépôt. Une archive peut contenir des références supplémentaires en dehors de `refs/heads/*` telles que `refs/tags/*`, qui sont simplement ignorées lors de l'utilisation de bundle-uri sur le clone.\n\nDans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à `refs/*` contenues dans l'archive téléchargée sont copiées.\n\n[Scott Chacon](https://github.com/schacon), qui a contribué à cette fonctionnalité, montre la différence lors du clonage de [gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss) :\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n```\n\nEn comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction de l'archive, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.\n\nPour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n*Cette série de contributions a été fournie par Scott Chacon.*\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) du projet Git et en consultant ces [ressources](https://about.gitlab.com/blog/tags/git/).\n","Nouveautés de Git 2.50.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png",[20],"Justin Tobler","2025-07-02",[23,24,25],"community","git","open source","yml",{},true,"/fr-fr/blog/what-s-new-in-git-2-50-0",{"noIndex":11,"title":16,"description":31,"ogTitle":16,"ogDescription":32,"ogImage":18},"Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.\n\n\n","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.\n","fr-fr/blog/what-s-new-in-git-2-50-0",[23,24,9],"tilF2v2fPutrrWiYFOF9nadufb2Tlx8fcV42k5OWzw8",{"data":37},{"logo":38,"freeTrial":43,"sales":48,"login":53,"items":58,"search":367,"minimal":402,"duo":421,"switchNav":430,"pricingDeployment":441},{"config":39},{"href":40,"dataGaName":41,"dataGaLocation":42},"/fr-fr/","gitlab logo","header",{"text":44,"config":45},"Commencer un essai gratuit",{"href":46,"dataGaName":47,"dataGaLocation":42},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":49,"config":50},"Contacter l'équipe commerciale",{"href":51,"dataGaName":52,"dataGaLocation":42},"/fr-fr/sales/","sales",{"text":54,"config":55},"Connexion",{"href":56,"dataGaName":57,"dataGaLocation":42},"https://gitlab.com/users/sign_in/","sign in",[59,86,183,188,288,348],{"text":60,"config":61,"cards":63},"Plateforme",{"dataNavLevelOne":62},"platform",[64,70,78],{"title":60,"description":65,"link":66},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":67,"config":68},"Explorer notre plateforme",{"href":69,"dataGaName":62,"dataGaLocation":42},"/fr-fr/platform/",{"title":71,"description":72,"link":73},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":74,"config":75},"Découvrir GitLab Duo",{"href":76,"dataGaName":77,"dataGaLocation":42},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":79,"description":80,"link":81},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":82,"config":83},"En savoir plus",{"href":84,"dataGaName":85,"dataGaLocation":42},"/fr-fr/why-gitlab/","why gitlab",{"text":87,"left":28,"config":88,"link":90,"lists":94,"footer":165},"Produit",{"dataNavLevelOne":89},"solutions",{"text":91,"config":92},"Voir toutes les solutions",{"href":93,"dataGaName":89,"dataGaLocation":42},"/fr-fr/solutions/",[95,120,143],{"title":96,"description":97,"link":98,"items":103},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":99},{"icon":100,"href":101,"dataGaName":102,"dataGaLocation":42},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[104,108,111,116],{"text":105,"config":106},"CI/CD",{"href":107,"dataGaLocation":42,"dataGaName":105},"/fr-fr/solutions/continuous-integration/",{"text":71,"config":109},{"href":76,"dataGaLocation":42,"dataGaName":110},"gitlab duo agent platform - product menu",{"text":112,"config":113},"Gestion du code source",{"href":114,"dataGaLocation":42,"dataGaName":115},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":117,"config":118},"Livraison de logiciels automatisée",{"href":101,"dataGaLocation":42,"dataGaName":119},"Automated software delivery",{"title":121,"description":122,"link":123,"items":128},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":124},{"href":125,"dataGaName":126,"dataGaLocation":42,"icon":127},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[129,133,138],{"text":130,"config":131},"Tests de sécurité des applications",{"href":125,"dataGaName":132,"dataGaLocation":42},"Application security testing",{"text":134,"config":135},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":136,"dataGaLocation":42,"dataGaName":137},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":139,"config":140},"Conformité logicielle",{"href":141,"dataGaName":142,"dataGaLocation":42},"/fr-fr/solutions/software-compliance/","software compliance",{"title":144,"link":145,"items":150},"Mesures",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":42},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[151,155,160],{"text":152,"config":153},"Visibilité et mesures",{"href":148,"dataGaLocation":42,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"Gestion de la chaîne de valeur",{"href":158,"dataGaLocation":42,"dataGaName":159},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":161,"config":162},"Données d'analyse et informations clés",{"href":163,"dataGaLocation":42,"dataGaName":164},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLab",[168,173,178],{"text":169,"config":170},"Pour les entreprises",{"href":171,"dataGaLocation":42,"dataGaName":172},"/fr-fr/enterprise/","enterprise",{"text":174,"config":175},"Pour les PME",{"href":176,"dataGaLocation":42,"dataGaName":177},"/fr-fr/small-business/","small business",{"text":179,"config":180},"Pour le secteur public",{"href":181,"dataGaLocation":42,"dataGaName":182},"/fr-fr/solutions/public-sector/","public sector",{"text":184,"config":185},"Tarifs",{"href":186,"dataGaName":187,"dataGaLocation":42,"dataNavLevelOne":187},"/fr-fr/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":275},"Ressources",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"Afficher toutes les ressources",{"href":195,"dataGaName":191,"dataGaLocation":42},"/fr-fr/resources/",[197,230,248],{"title":198,"items":199},"Premiers pas",[200,205,210,215,220,225],{"text":201,"config":202},"Installation",{"href":203,"dataGaName":204,"dataGaLocation":42},"/fr-fr/install/","install",{"text":206,"config":207},"Guides de démarrage",{"href":208,"dataGaName":209,"dataGaLocation":42},"/fr-fr/get-started/","quick setup checklists",{"text":211,"config":212},"Apprentissage",{"href":213,"dataGaLocation":42,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"Documentation",{"href":218,"dataGaName":219,"dataGaLocation":42},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"Vidéos sur les bonnes pratiques",{"href":223,"dataGaName":224,"dataGaLocation":42},"/fr-fr/getting-started-videos/","best practice videos",{"text":226,"config":227},"Intégrations",{"href":228,"dataGaName":229,"dataGaLocation":42},"/fr-fr/integrations/","integrations",{"title":231,"items":232},"Découvrir",[233,238,243],{"text":234,"config":235},"Témoignages clients",{"href":236,"dataGaName":237,"dataGaLocation":42},"/fr-fr/customers/","customer success stories",{"text":239,"config":240},"Blog",{"href":241,"dataGaName":242,"dataGaLocation":42},"/fr-fr/blog/","blog",{"text":244,"config":245},"Travail à distance",{"href":246,"dataGaName":247,"dataGaLocation":42},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"Connecter",[251,256,260,265,270],{"text":252,"config":253},"Services GitLab",{"href":254,"dataGaName":255,"dataGaLocation":42},"/fr-fr/services/","services",{"text":257,"config":258},"Communauté",{"href":259,"dataGaName":23,"dataGaLocation":42},"/community/",{"text":261,"config":262},"Forum",{"href":263,"dataGaName":264,"dataGaLocation":42},"https://forum.gitlab.com/","forum",{"text":266,"config":267},"Événements",{"href":268,"dataGaName":269,"dataGaLocation":42},"/events/","events",{"text":271,"config":272},"Partenaires",{"href":273,"dataGaName":274,"dataGaLocation":42},"/fr-fr/partners/","partners",{"backgroundColor":276,"textColor":277,"text":278,"image":279,"link":283},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":280,"config":281},"carte promo The Source",{"src":282},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":284,"config":285},"Lire les articles les plus récents",{"href":286,"dataGaName":287,"dataGaLocation":42},"/fr-fr/the-source/","the source",{"text":289,"config":290,"lists":292},"Société",{"dataNavLevelOne":291},"company",[293],{"items":294},[295,300,306,308,313,318,323,328,333,338,343],{"text":296,"config":297},"À propos",{"href":298,"dataGaName":299,"dataGaLocation":42},"/fr-fr/company/","about",{"text":301,"config":302,"footerGa":305},"Carrières",{"href":303,"dataGaName":304,"dataGaLocation":42},"/jobs/","jobs",{"dataGaName":304},{"text":266,"config":307},{"href":268,"dataGaName":269,"dataGaLocation":42},{"text":309,"config":310},"Leadership",{"href":311,"dataGaName":312,"dataGaLocation":42},"/company/team/e-group/","leadership",{"text":314,"config":315},"Équipe",{"href":316,"dataGaName":317,"dataGaLocation":42},"/company/team/","team",{"text":319,"config":320},"Manuel",{"href":321,"dataGaName":322,"dataGaLocation":42},"https://handbook.gitlab.com/","handbook",{"text":324,"config":325},"Relations avec les investisseurs",{"href":326,"dataGaName":327,"dataGaLocation":42},"https://ir.gitlab.com/","investor relations",{"text":329,"config":330},"Trust Center",{"href":331,"dataGaName":332,"dataGaLocation":42},"/fr-fr/security/","trust center",{"text":334,"config":335},"Centre pour la transparence de l'IA",{"href":336,"dataGaName":337,"dataGaLocation":42},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":339,"config":340},"Newsletter",{"href":341,"dataGaName":342,"dataGaLocation":42},"/company/contact/#contact-forms","newsletter",{"text":344,"config":345},"Presse",{"href":346,"dataGaName":347,"dataGaLocation":42},"/press/","press",{"text":349,"config":350,"lists":351},"Nous contacter",{"dataNavLevelOne":291},[352],{"items":353},[354,357,362],{"text":49,"config":355},{"href":51,"dataGaName":356,"dataGaLocation":42},"talk to sales",{"text":358,"config":359},"Assistance GitLab",{"href":360,"dataGaName":361,"dataGaLocation":42},"https://support.gitlab.com","support portal",{"text":363,"config":364},"Portail clients GitLab",{"href":365,"dataGaName":366,"dataGaLocation":42},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":368,"login":369,"suggestions":376},"Fermer",{"text":370,"link":371},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":372,"config":373},"GitLab.com",{"href":56,"dataGaName":374,"dataGaLocation":375},"search login","search",{"text":377,"default":378},"Suggestions",[379,381,386,388,393,398],{"text":71,"config":380},{"href":76,"dataGaName":71,"dataGaLocation":375},{"text":382,"config":383},"Suggestions de code (IA)",{"href":384,"dataGaName":385,"dataGaLocation":375},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":105,"config":387},{"href":107,"dataGaName":105,"dataGaLocation":375},{"text":389,"config":390},"GitLab sur AWS",{"href":391,"dataGaName":392,"dataGaLocation":375},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":394,"config":395},"GitLab sur Google Cloud",{"href":396,"dataGaName":397,"dataGaLocation":375},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":399,"config":400},"Pourquoi utiliser GitLab ?",{"href":84,"dataGaName":401,"dataGaLocation":375},"Why GitLab?",{"freeTrial":403,"mobileIcon":408,"desktopIcon":413,"secondaryButton":416},{"text":404,"config":405},"Commencer votre essai gratuit",{"href":406,"dataGaName":47,"dataGaLocation":407},"https://gitlab.com/-/trials/new/","nav",{"altText":409,"config":410},"Icône GitLab",{"src":411,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":409,"config":414},{"src":415,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":417,"config":418},"Commencer",{"href":419,"dataGaName":420,"dataGaLocation":407},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"En savoir plus sur GitLab Duo",{"href":76,"dataGaName":425,"dataGaLocation":407},"gitlab duo",{"altText":409,"config":427},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":429},{"src":415,"dataGaName":412,"dataGaLocation":407},{"button":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"/switch",{"href":434,"dataGaName":435,"dataGaLocation":407},"#contact","switch",{"altText":409,"config":437},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":439},{"src":440,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":442,"mobileIcon":447,"desktopIcon":449},{"text":443,"config":444},"Retour aux tarifs",{"href":186,"dataGaName":445,"dataGaLocation":407,"icon":446},"back to pricing","GoBack",{"altText":409,"config":448},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":450},{"src":415,"dataGaName":412,"dataGaLocation":407},{"title":452,"button":453,"config":458},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":454,"config":455},"Regarder GitLab Transcend maintenant",{"href":456,"dataGaName":457,"dataGaLocation":42},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":459,"icon":460,"disabled":28},"release","AiStar",{"data":462},{"text":463,"source":464,"edit":470,"contribute":475,"config":480,"items":485,"minimal":690},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":465,"config":466},"Afficher le code source de la page",{"href":467,"dataGaName":468,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":471,"config":472},"Modifier cette page",{"href":473,"dataGaName":474,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":476,"config":477},"Veuillez contribuer",{"href":478,"dataGaName":479,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":481,"facebook":482,"youtube":483,"linkedin":484},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[486,531,584,628,655],{"title":184,"links":487,"subMenu":502},[488,492,497],{"text":489,"config":490},"Voir les forfaits",{"href":186,"dataGaName":491,"dataGaLocation":469},"view plans",{"text":493,"config":494},"GitLab Premium",{"href":495,"dataGaName":496,"dataGaLocation":469},"/fr-fr/pricing/premium/","why premium",{"text":498,"config":499},"GitLab Ultimate",{"href":500,"dataGaName":501,"dataGaLocation":469},"/fr-fr/pricing/ultimate/","why ultimate",[503],{"title":349,"links":504},[505,507,509,511,516,521,526],{"text":49,"config":506},{"href":51,"dataGaName":52,"dataGaLocation":469},{"text":358,"config":508},{"href":360,"dataGaName":361,"dataGaLocation":469},{"text":363,"config":510},{"href":365,"dataGaName":366,"dataGaLocation":469},{"text":512,"config":513},"Statut",{"href":514,"dataGaName":515,"dataGaLocation":469},"https://status.gitlab.com/","status",{"text":517,"config":518},"Conditions d'utilisation",{"href":519,"dataGaName":520,"dataGaLocation":469},"/terms/","terms of use",{"text":522,"config":523},"Politique de confidentialité",{"href":524,"dataGaName":525,"dataGaLocation":469},"/fr-fr/privacy/","privacy statement",{"text":527,"config":528},"Gérer vos cookies",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"title":87,"links":532,"subMenu":541},[533,537],{"text":534,"config":535},"Plateforme DevSecOps",{"href":69,"dataGaName":536,"dataGaLocation":469},"devsecops platform",{"text":538,"config":539},"Développement assisté par l'IA",{"href":76,"dataGaName":540,"dataGaLocation":469},"ai-assisted development",[542],{"title":543,"links":544},"Thèmes",[545,549,554,559,564,569,574,579],{"text":105,"config":546},{"href":547,"dataGaName":548,"dataGaLocation":469},"/fr-fr/topics/ci-cd/","cicd",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":469},"/fr-fr/topics/gitops/","gitops",{"text":555,"config":556},"DevOps",{"href":557,"dataGaName":558,"dataGaLocation":469},"/fr-fr/topics/devops/","devops",{"text":560,"config":561},"Contrôle de version",{"href":562,"dataGaName":563,"dataGaLocation":469},"/fr-fr/topics/version-control/","version control",{"text":565,"config":566},"DevSecOps",{"href":567,"dataGaName":568,"dataGaLocation":469},"/fr-fr/topics/devsecops/","devsecops",{"text":570,"config":571},"Cloud-native",{"href":572,"dataGaName":573,"dataGaLocation":469},"/fr-fr/topics/cloud-native/","cloud native",{"text":575,"config":576},"IA pour la programmation",{"href":577,"dataGaName":578,"dataGaLocation":469},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":580,"config":581},"IA agentique",{"href":582,"dataGaName":583,"dataGaLocation":469},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":585,"links":586},"Solutions",[587,590,592,597,600,603,606,609,612,615,618,623],{"text":130,"config":588},{"href":125,"dataGaName":589,"dataGaLocation":469},"Application Security Testing",{"text":117,"config":591},{"href":101,"dataGaName":102,"dataGaLocation":469},{"text":593,"config":594},"Développement Agile",{"href":595,"dataGaName":596,"dataGaLocation":469},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":112,"config":598},{"href":114,"dataGaName":599,"dataGaLocation":469},"source code management",{"text":105,"config":601},{"href":107,"dataGaName":602,"dataGaLocation":469},"continuous integration & delivery",{"text":156,"config":604},{"href":158,"dataGaName":605,"dataGaLocation":469},"value stream management",{"text":550,"config":607},{"href":608,"dataGaName":553,"dataGaLocation":469},"/fr-fr/solutions/gitops/",{"text":610,"config":611},"Entreprises",{"href":171,"dataGaName":172,"dataGaLocation":469},{"text":613,"config":614},"PME",{"href":176,"dataGaName":177,"dataGaLocation":469},{"text":616,"config":617},"Secteur public",{"href":181,"dataGaName":182,"dataGaLocation":469},{"text":619,"config":620},"Éducation",{"href":621,"dataGaName":622,"dataGaLocation":469},"/fr-fr/solutions/education/","education",{"text":624,"config":625},"Services financiers",{"href":626,"dataGaName":627,"dataGaLocation":469},"/fr-fr/solutions/finance/","financial services",{"title":189,"links":629},[630,632,634,636,639,641,643,645,647,649,651,653],{"text":201,"config":631},{"href":203,"dataGaName":204,"dataGaLocation":469},{"text":206,"config":633},{"href":208,"dataGaName":209,"dataGaLocation":469},{"text":211,"config":635},{"href":213,"dataGaName":214,"dataGaLocation":469},{"text":216,"config":637},{"href":218,"dataGaName":638,"dataGaLocation":469},"docs",{"text":239,"config":640},{"href":241,"dataGaName":242,"dataGaLocation":469},{"text":234,"config":642},{"href":236,"dataGaName":237,"dataGaLocation":469},{"text":244,"config":644},{"href":246,"dataGaName":247,"dataGaLocation":469},{"text":252,"config":646},{"href":254,"dataGaName":255,"dataGaLocation":469},{"text":257,"config":648},{"href":259,"dataGaName":23,"dataGaLocation":469},{"text":261,"config":650},{"href":263,"dataGaName":264,"dataGaLocation":469},{"text":266,"config":652},{"href":268,"dataGaName":269,"dataGaLocation":469},{"text":271,"config":654},{"href":273,"dataGaName":274,"dataGaLocation":469},{"title":289,"links":656},[657,659,661,663,665,667,669,674,679,681,683,685],{"text":296,"config":658},{"href":298,"dataGaName":291,"dataGaLocation":469},{"text":301,"config":660},{"href":303,"dataGaName":304,"dataGaLocation":469},{"text":309,"config":662},{"href":311,"dataGaName":312,"dataGaLocation":469},{"text":314,"config":664},{"href":316,"dataGaName":317,"dataGaLocation":469},{"text":319,"config":666},{"href":321,"dataGaName":322,"dataGaLocation":469},{"text":324,"config":668},{"href":326,"dataGaName":327,"dataGaLocation":469},{"text":670,"config":671},"Développement durable",{"href":672,"dataGaName":673,"dataGaLocation":469},"/sustainability/","Sustainability",{"text":675,"config":676},"Diversité, inclusion et appartenance (DIB)",{"href":677,"dataGaName":678,"dataGaLocation":469},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":329,"config":680},{"href":331,"dataGaName":332,"dataGaLocation":469},{"text":339,"config":682},{"href":341,"dataGaName":342,"dataGaLocation":469},{"text":344,"config":684},{"href":346,"dataGaName":347,"dataGaLocation":469},{"text":686,"config":687},"Déclaration de transparence sur l'esclavage moderne",{"href":688,"dataGaName":689,"dataGaLocation":469},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,694,697],{"text":517,"config":693},{"href":519,"dataGaName":520,"dataGaLocation":469},{"text":695,"config":696},"Gestion des cookies",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":28},{"text":522,"config":698},{"href":524,"dataGaName":525,"dataGaLocation":469},[700],{"id":701,"title":20,"body":8,"config":702,"content":704,"description":8,"extension":26,"meta":708,"navigation":28,"path":709,"seo":710,"stem":711,"__hash__":712},"blogAuthors/en-us/blog/authors/justin-tobler.yml",{"template":703},"BlogAuthor",{"name":20,"config":705},{"headshot":706,"ctfId":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664737/Blog/Author%20Headshots/james_tobler_headshot.png","5pnOIbNI1Sc5IFnReNHNtv",{},"/en-us/blog/authors/justin-tobler",{},"en-us/blog/authors/justin-tobler","fZs0fJVrV3MQT0RHzrMvziLDriL7K4hf9Db4QlPsRvA",[714,727,738],{"content":715,"config":725},{"title":716,"description":717,"authors":718,"heroImage":720,"date":721,"body":722,"category":9,"tags":723},"GitLab AI Hackathon 2026 : découvrez les gagnants","Près de 7 000 développeurs ont créé plus de 600 agents et flows d'IA sur GitLab Duo Agent Platform. Découvrez les gagnants et leurs projets.",[719],"Nick Veenhof","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","2026-04-22","Il est désormais acquis que l'IA écrit du code. Mais qu'en est-il de la planification, de la sécurité, de la conformité et des déploiements ? Dans ces domaines, des lacunes persistent. Nous organisons des programmes de contribution depuis des années et n'avons jamais vu une communauté réagir à une technologie de cette manière.\n\nC'est pourquoi nous avons lancé [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) et invité des équipes de développement du monde entier à créer des agents d'IA qui aident les équipes à livrer des logiciels sécurisés plus rapidement. Pas des chatbots qui répondent à des questions, mais des agents qui s'intègrent dans les workflows, réagissent aux événements et agissent en votre nom. Le GitLab AI Hackathon 2026 s'est déroulé du 9 février au 25 mars 2026 sur Devpost, la plateforme dédiée aux hackathons. Google Cloud et Anthropic y ont participé en tant que co-sponsors.\n\nLorsque nous avons préparé ce hackathon avec Google Cloud et Anthropic, nous avons demandé aux juges d'évaluer quatre critères : la qualité technique, le design, l'impact potentiel et l'originalité de l'idée. Nous espérions une forte participation, mais les résultats nous ont tous surpris. Dix-neuf juges ont consacré 18 jours à examiner tous les projets. Google Cloud et Anthropic ont fourni les juges, les prix et un accès cloud. La communauté a créé des centaines d'agents et de flows afin de s'atteler aux lacunes mentionnées plus haut.\n\nPrès de 7 000 développeurs ont répondu à l'appel et créé plus de 600 agents et flows en quelques semaines. Les prix, toutes catégories confondues, totalisaient 65 000 dollars offerts par GitLab, Google Cloud et Anthropic.\n\n\nSi vous avez déjà vu un ingénieur senior quitter une équipe en emportant avec lui la moitié des connaissances de son équipe, vous comprendrez pourquoi le projet gagnant a autant marqué les esprits.\n\nPoursuivez votre lecture pour découvrir ce que les participants ont créé.\n\n## Premier prix : LORE\n\n[LORE](https://devpost.com/software/lore-living-organizational-record-engine), le Living Organizational Record Engine, utilise huit agents avec un routeur qui dirige chaque question vers l'agent approprié, une logique de prévention des boucles circulaires dans le graphe de connaissances, un tableau de bord visuel et un suivi de l'empreinte carbone. L'outil en ligne de commande est livré avec 43 tests (un chiffre inédit dans un projet de hackathon).\n\nLORE résout un problème concret : les connaissances des ingénieurs qui disparaissent lorsque ces derniers quittent l'entreprise. D'après notre expérience, un projet de hackathon avec 43 tests est rare. Un tel nombre en dit long sur l'équipe qui l'a conçu.\n\nApril Guo (Anthropic), membre du jury, a écrit : « On dirait un produit, pas un projet de hackathon. »\n\n\n### Gagnants Google Cloud\n\n[Gitdefender](https://devpost.com/software/gitdefender) a remporté le premier prix Google Cloud. L'outil s'intègre dans les workflows de revue de code afin de détecter et de corriger les vulnérabilités de sécurité. Il identifie les bogues, rédige des correctifs et ouvre la revue de code. Aucune intervention humaine n'est nécessaire.\n\n[Aegis](https://devpost.com/software/aegis-2m1oq0) a remporté le deuxième prix Google Cloud. L'outil fournit des explications assistées par l'IA pour chaque décision prise, qui est déployée sur Google Cloud et prête pour la production.\n\n### Gagnants Anthropic\n\n[GraphDev](https://devpost.com/software/graphdev) a remporté le premier prix Anthropic. L'outil cartographie les liens entre les éléments du code et montre comment les systèmes évoluent au fil du temps. Aboobacker MK (GitLab), membre du jury, a noté que le projet était « en phase avec notre travail sur le graphe de connaissances GitLab ». Ayush Billore (GitLab) a écrit : « J'ai adoré la démo et l'expérience utilisateur, un outil très utile pour comprendre comment le système a évolué et ce qui est impacté par les changements. » Vous pouvez visualiser l'impact complet d'une modification avant de l'autoriser.\n\n[DocSync](https://devpost.com/software/pipeheal) a remporté le deuxième prix Anthropic. L'outil utilise trois agents : Detector, Writer et Reviewer. Si DocSync a confiance dans le correctif, il ouvre une revue de code. Dans le cas contraire, il crée un ticket pour qu'un humain le vérifie.\n\n## Gagnants par catégorie\n\n### Projet le plus impressionnant sur le plan technique\n\nLes migrations de bases de données sont source de problèmes. [Time-Traveler](https://devpost.com/software/time-traveler-w3cxp0) crée une copie sécurisée de votre environnement de production, exécute la migration sur cette copie et génère un rapport. L'outil exécute cinq agents connectés par un pont, avec un déploiement réel sur Google Cloud, de véritables migrations PostgreSQL et des données réelles.\n\n### Projet avec le plus grand impact\n\n[RedAgent](https://devpost.com/software/redagent) vérifie les rapports de sécurité générés par l'IA et comble le fossé de confiance entre les résultats de l'IA et l'action des équipes de développement. Si votre équipe utilise l'IA pour les scans de sécurité, vous connaissez ce problème. Certaines équipes ignorent les résultats de l'IA parce qu'elles ne peuvent pas les vérifier. RedAgent offre aux équipes un moyen de valider les résultats de l'IA avant qu'ils ne parviennent aux équipes de développement.\n\n### Projet le plus facile à utiliser\n\n[Launch Control](https://devpost.com/software/launch-control-bgp8az) offre une expérience utilisateur soignée et une infrastructure solide, avec également de bons résultats en matière de durabilité.\n\n## Le signal de durabilité\n\nCinq projets ont remporté des prix ou des bonus pour leur impact environnemental. La livraison logicielle a un coût carbone lié aux pipelines CI/CD, et désormais les grands modèles de langage (LLM) consomment également des ressources de calcul à grande échelle. Nous avons créé la catégorie Green Agent pour inciter les équipes de développement à mesurer et réduire cette empreinte. Stacy Cline et Kim Buncle, de l'équipe durabilité de GitLab, ont participé au jury de la catégorie Green Agent.\n\n### Prix Green Agent\n\n[GreenPipe](https://devpost.com/software/greenpipe) analyse les pipelines CI/CD pour évaluer leur impact environnemental et produit des rapports d'empreinte carbone. Kim Buncle et Rajesh Agadi (Google), membres du jury, ont tous deux soutenu le projet.\n\n### Prix bonus consacrés au design durable\n\nLes prix bonus consacrés au design durable ont été attribués aux projets ayant adopté des pratiques de durabilité exceptionnelles dans leur conception, des techniques d'optimisation des modèles aux choix d'architecture écoénergétique.\n\n* [BugFlow](https://devpost.com/software/bugflow-ai-regression-detective-ci-optimizer) a transformé un rapport de bogue en 10 correctifs en 20 minutes.\n* [DELTA Cyber Reasoning](https://devpost.com/software/delta-cyber-reasoning-system) propose des tests à données aléatoires automatisés pour la sécurité.\n* [CarbonLint](https://devpost.com/software/carbonlint) applique l'analyse de code à la consommation énergétique.\n* [TFGuardian](https://devpost.com/software/tfguardian) intègre un analyseur d'empreinte carbone, entre autres agents.\n\nFélicitations à tous les lauréats des prix bonus consacrés au design durable !\n\nJens-Joris Decorte (TechWolf), membre du jury, a mentionné que les coûts étaient passés de 556 $ à 18 $ par mois, soit une réduction de 96 % de l'empreinte carbone (une économie mensuelle de 538 $ assortie d'un label de durabilité).\n\n## Mentions honorables et projets remarquables\n\nSix projets ont reçu des mentions honorables :\n\n\n- [SecurityMonkey](https://devpost.com/software/securitymonkey) injecte des vulnérabilités connues dans une branche de test et évalue la capacité de vos scanners de sécurité à les détecter.\n- [stregent](https://devpost.com/software/stregent) surveille les pipelines CI/CD et permet aux équipes de développement d'analyser et de fusionner des correctifs depuis WhatsApp, sans ouvrir un ordinateur portable.\n- [Compliance Sentinel](https://devpost.com/software/compliance-sentinel-autonomous-devsecops-governance) attribue un score de risque de conformité à chaque merge request et bloque le merge si des violations critiques sont détectées.\n- [Carbon Tracker](https://devpost.com/software/carbon-tracker-ij25kf) calcule l'empreinte carbone de chaque job de pipeline CI/CD et publie des conseils d'optimisation sur la merge request.\n- [RepoWarden](https://devpost.com/software/docuguard) est le premier Living Specification Engine, un système d'IA qui capture les raisons pour lesquelles le code a été écrit, et pas seulement ce qu'il fait.\n- [MR Compliance Auditor](https://devpost.com/software/mr-compliance-auditor) collecte des preuves à travers les merge requests, les associe aux contrôles SOC 2 et diffuse les scores de conformité sur un tableau de bord en temps réel.\n\nMa citation préférée du jury vient de Luca Chun Lun Lit (Anthropic), à propos de l'approche axée sur mobile de stregent : « Pouvoir coder depuis son téléphone représente un nouveau cap dans l'expérience d'ingénierie. »\n\n> Explorez les plus de 600 projets dans la [galerie de projets](https://gitlab.devpost.com/project-gallery).\n\n## Et ensuite ?\n\nChaque agent de ce hackathon fonctionnait au sein d'un seul projet. Les résultats obtenus étaient néanmoins impressionnants. Certains participants ont exécuté un graphe de connaissances local en parallèle de leurs agents pour faire émerger les relations et les dépendances au sein du dépôt. LORE capture l'historique du projet. Gitdefender détecte les vulnérabilités. Associer des agents à un contexte local plus riche aide déjà les contributeurs à créer des outils plus performants. Le prochain hackathon s'appuiera sur ce que les contributeurs font déjà avec un contexte enrichi. Inscrivez-vous sur [contributors.gitlab.com](https://contributors.gitlab.com/) pour être informé dès que les détails seront disponibles.\n\n\n## Lancez-vous\n\nUn grand merci à Lee Tickett (GitLab) et Mattias Michaux (GitLab) pour avoir guidé les innovateurs de ce hackathon !\n\nMerci à chaque développeur qui a soumis un projet. Près de 7 000 d'entre vous ont démontré ce que GitLab Duo Agent Platform peut accomplir lorsqu'une communauté décide de créer. Nous sommes fiers de ce que vous avez produit ici et avons hâte de voir ce que vous créerez ensuite.\n\nCréez votre propre agent sur [GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/). Parcourez les agents créés par la communauté dans le [catalogue d'IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/). Vous orchestrez les agents. L'IA accélère le développement.\n",[724,23],"AI/ML",{"featured":11,"template":12,"slug":726},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":728,"config":736},{"tags":729,"category":9,"body":730,"date":731,"heroImage":732,"authors":733,"description":734,"title":735},[25,24,23],"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/blog/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",[20],"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":11,"template":12,"slug":737},"whats-new-in-git-2-53-0",{"content":739,"config":749},{"tags":740,"category":9,"date":741,"heroImage":732,"authors":742,"title":746,"description":747,"body":748},[25,24,23],"2025-11-19",[743,744,745],"Christian Couder","Toon Claes","Patrick Steinhardt","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":11,"template":12,"slug":750},"whats-new-in-git-2-52-0",{"promotions":752},[753,767,779,791],{"id":754,"categories":755,"header":757,"text":758,"button":759,"image":764},"ai-modernization",[756],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":760,"config":761},"Get your AI maturity score",{"href":762,"dataGaName":763,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":765},{"src":766},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":768,"categories":769,"header":771,"text":758,"button":772,"image":776},"devops-modernization",[770,568],"product","Are you just managing tools or shipping innovation?",{"text":773,"config":774},"Get your DevOps maturity score",{"href":775,"dataGaName":763,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":777},{"src":778},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":780,"categories":781,"header":783,"text":758,"button":784,"image":788},"security-modernization",[782],"security","Are you trading speed for security?",{"text":785,"config":786},"Get your security maturity score",{"href":787,"dataGaName":763,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":789},{"src":790},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":792,"paths":793,"header":796,"text":797,"button":798,"image":803},"github-azure-migration",[794,795],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":799,"config":800},"See how GitLab compares to GitHub",{"href":801,"dataGaName":802,"dataGaLocation":242},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":804},{"src":778},{"header":806,"blurb":807,"button":808,"secondaryButton":812},"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":44,"config":809},{"href":810,"dataGaName":47,"dataGaLocation":811},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":49,"config":813},{"href":51,"dataGaName":52,"dataGaLocation":811},1777394011352]