[{"data":1,"prerenderedAt":849},["ShallowReactive",2],{"/fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes":3,"navigation-fr-fr":44,"banner-fr-fr":470,"footer-fr-fr":480,"blog-post-authors-fr-fr-Karthik Nayak|Manuel Kraft":718,"blog-related-posts-fr-fr-how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes":745,"blog-promotions-fr-fr":788,"next-steps-fr-fr":840},{"id":4,"title":5,"authorSlugs":6,"authors":9,"body":12,"category":13,"categorySlug":13,"config":14,"content":18,"date":26,"description":19,"extension":28,"externalUrl":29,"featured":17,"heroImage":21,"isFeatured":17,"meta":30,"navigation":17,"path":31,"publishedDate":26,"rawbody":32,"seo":33,"slug":16,"stem":39,"tagSlugs":40,"tags":42,"template":15,"updatedDate":27,"__hash__":43},"blogPosts/fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.md","Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min ",[7,8],"karthik-nayak","manuel-kraft",[10,11],"Karthik Nayak","Manuel Kraft","Les sauvegardes de dépôt sont un élément essentiel de toute stratégie de reprise après un sinistre important. Cependant, à mesure que les dépôts grossissent, garantir des sauvegardes fiables devient de plus en plus difficile. Notre propre [dépôt Rails](https://gitlab.com/gitlab-org/gitlab) mettait 48 heures à être sauvegardé, ce qui nous obligeait à faire un choix impossible entre la fréquence des sauvegardes et les performances du système. Nous avons donc décidé de trouver une solution à ce problème pour nos clients et pour nos propres équipes internes.\n\nAprès investigation, nous avons pu déterminer la cause du problème, qui remontait à une fonction Git vieille de 15 ans dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme et **avons ainsi réduit les temps de sauvegarde de manière exponentielle**.\n\nRésultat : des coûts réduits, des risques diminués, et surtout, des stratégies de sauvegarde désormais adaptées à la croissance de votre code source.\n\nCe problème d'évolutivité de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") affectait tout utilisateur disposant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.\n\n## Sauvegarde à grande échelle : enjeux et solutions\n\nÀ mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :\n\n* **Sauvegardes trop longues** : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.\n* **Utilisation intensive des ressources** : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter d'autres opérations critiques.\n* **Fenêtres de sauvegarde** : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes qui fonctionnent 24 h/24 et 7 j/7.\n* **Risque accru d'échec** : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, et obligent souvent les équipes à recommencer tout le processus depuis le début.\n* **Conditions de concurrence** : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus et peut conduire à une sauvegarde invalide ou à des interruptions liées à des objets devenus indisponibles.\n\nCes défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme l'utilisation d'outils externes ou la réduction de la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises.\n\nDécouvrez maintenant comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.\n\n## Le défi technique\n\nLa fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande [`git bundle create`](https://git-scm.com/docs/git-bundle/fr), qui génère un aperçu complet du dépôt avec tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration pour recréer le dépôt dans son état exact.\n\nCependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références et entraînait un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.\n\n### Analyse des causes profondes\n\nPour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.\n\n![Flame graph montrant la commande pendant son exécution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\nCe graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.\n\nLe flame graph de `git bundle create` exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction `object_array_remove_duplicates()`, introduite dans Git par le biais du [commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).\n\nPour comprendre ce changement, il est important de savoir que la commande `git bundle create` permet de préciser les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag `--all` compacte toutes les références.\n\nCe commit corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que `git bundle create main.bundle main main`, et créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois, ce qui provoquait une erreur.\n\nLe code ajouté pour éviter ces duplications utilise des boucles `for` imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) est un goulot d'étranglement majeur en termes de performance dans les dépôts car il contient un grand nombre de références et prolonge considérablement le temps de traitement des données.\n\n### La solution : d'O(N²) à un mappage efficace\n\nPour résoudre ce problème, nous avons proposé une correction en amont dans Git pour remplacer les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.\n\nCe changement améliore considérablement les performances de la commande `git bundle create` et garantit une bien meilleure évolutivité dans les dépôts avec un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.\n\n```shell\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\nLe correctif a été accepté et [fusionné](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d) dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement sans attendre la prochaine version officielle de Git.\n\n## Résultat : des temps de sauvegarde radicalement réduits\n\nLes gains de performance qui découlent de cette amélioration sont considérables :\n\n* **De 48 heures à 41 minutes** : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.\n* **Performances constantes** : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.\n* **Efficacité des ressources** : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.\n* **Applicabilité étendue** : si le processus de sauvegarde est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets avec un grand nombre de références en profitent également.\n\n## Avantages pour nos clients GitLab\n\nPour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :\n\n* **Transformation des stratégies de sauvegarde**\n\n  * Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.\n  * Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans processus longs ni dédiés.\n* **Continuité des activités améliorée**\n\n  * Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits, tout comme le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.\n* **Réduction de la charge opérationnelle**\n\n  * La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.\n  * Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.\n* **Pérennisation de l'infrastructure**\n\n  * La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.\n  * À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.\n\nLes entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un compromis difficile est devenu une pratique opérationnelle simple.\n\nÀ partir de la version [GitLab 18.0](https://docs.gitlab.com/releases/18/gitlab-18-0-released/), tous les clients GitLab, quelle que soit leur version de licence, profitent désormais pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs [sauvegardes](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/), sans aucune autre modification de la configuration.\n\n## Et après ?\n\nCette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente une étape majeure, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.\n\nNous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git afin de profiter non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.\n\n> Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Consultez le [replay de notre événement virtuel de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/) et découvrez les autres améliorations fondamentales que nous proposons.","engineering",{"template":15,"slug":16,"featured":17},"BlogPost","how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",true,{"title":5,"description":19,"authors":20,"heroImage":21,"tags":22,"category":13,"date":26,"updatedDate":27,"body":12},"L'optimisation d'une fonction Git vieille de 15 ans a permis d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de réduire les risques.",[10,11],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png",[23,24,25],"git","open source","performance","2025-06-05","2025-07-09","md",null,{},"/fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","---\nseo:\n  ogTitle: 'Dépôts GitLab : forte diminution des temps de sauvegarde'\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png\n  ogDescription: L'optimisation d'une fonction Git vieille de 15 ans a permis\n    d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de\n    réduire les risques.\n  ogSiteName: https://about.gitlab.com\n  noIndex: false\n  ogType: article\n  ogUrl: https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes\n  title: 'Dépôts GitLab : forte diminution des temps de sauvegarde'\n  canonicalUrls: https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes\n  description: L'optimisation d'une fonction Git vieille de 15 ans a permis\n    d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de\n    réduire les risques.\ntitle: 'Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min '\ndescription: L'optimisation d'une fonction Git vieille de 15 ans a permis d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de réduire les risques.\nauthors:\n  - Karthik Nayak\n  - Manuel Kraft\nheroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png\ntags:\n  - git\n  - open source\n  - performance\ncategory: engineering\ndate: '2025-06-05'\nupdatedDate: '2025-07-09'\nslug: how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes\nfeatured: true\ntemplate: BlogPost\n---\n\nLes sauvegardes de dépôt sont un élément essentiel de toute stratégie de reprise après un sinistre important. Cependant, à mesure que les dépôts grossissent, garantir des sauvegardes fiables devient de plus en plus difficile. Notre propre [dépôt Rails](https://gitlab.com/gitlab-org/gitlab) mettait 48 heures à être sauvegardé, ce qui nous obligeait à faire un choix impossible entre la fréquence des sauvegardes et les performances du système. Nous avons donc décidé de trouver une solution à ce problème pour nos clients et pour nos propres équipes internes.\n\nAprès investigation, nous avons pu déterminer la cause du problème, qui remontait à une fonction Git vieille de 15 ans dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme et **avons ainsi réduit les temps de sauvegarde de manière exponentielle**.\n\nRésultat : des coûts réduits, des risques diminués, et surtout, des stratégies de sauvegarde désormais adaptées à la croissance de votre code source.\n\nCe problème d'évolutivité de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") affectait tout utilisateur disposant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.\n\n## Sauvegarde à grande échelle : enjeux et solutions\n\nÀ mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :\n\n* **Sauvegardes trop longues** : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.\n* **Utilisation intensive des ressources** : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter d'autres opérations critiques.\n* **Fenêtres de sauvegarde** : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes qui fonctionnent 24 h/24 et 7 j/7.\n* **Risque accru d'échec** : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, et obligent souvent les équipes à recommencer tout le processus depuis le début.\n* **Conditions de concurrence** : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus et peut conduire à une sauvegarde invalide ou à des interruptions liées à des objets devenus indisponibles.\n\nCes défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme l'utilisation d'outils externes ou la réduction de la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises.\n\nDécouvrez maintenant comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.\n\n## Le défi technique\n\nLa fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande [`git bundle create`](https://git-scm.com/docs/git-bundle/fr), qui génère un aperçu complet du dépôt avec tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration pour recréer le dépôt dans son état exact.\n\nCependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références et entraînait un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.\n\n### Analyse des causes profondes\n\nPour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.\n\n![Flame graph montrant la commande pendant son exécution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\nCe graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.\n\nLe flame graph de `git bundle create` exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction `object_array_remove_duplicates()`, introduite dans Git par le biais du [commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).\n\nPour comprendre ce changement, il est important de savoir que la commande `git bundle create` permet de préciser les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag `--all` compacte toutes les références.\n\nCe commit corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que `git bundle create main.bundle main main`, et créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois, ce qui provoquait une erreur.\n\nLe code ajouté pour éviter ces duplications utilise des boucles `for` imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) est un goulot d'étranglement majeur en termes de performance dans les dépôts car il contient un grand nombre de références et prolonge considérablement le temps de traitement des données.\n\n### La solution : d'O(N²) à un mappage efficace\n\nPour résoudre ce problème, nous avons proposé une correction en amont dans Git pour remplacer les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.\n\nCe changement améliore considérablement les performances de la commande `git bundle create` et garantit une bien meilleure évolutivité dans les dépôts avec un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.\n\n```shell\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\nLe correctif a été accepté et [fusionné](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d) dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement sans attendre la prochaine version officielle de Git.\n\n## Résultat : des temps de sauvegarde radicalement réduits\n\nLes gains de performance qui découlent de cette amélioration sont considérables :\n\n* **De 48 heures à 41 minutes** : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.\n* **Performances constantes** : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.\n* **Efficacité des ressources** : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.\n* **Applicabilité étendue** : si le processus de sauvegarde est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets avec un grand nombre de références en profitent également.\n\n## Avantages pour nos clients GitLab\n\nPour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :\n\n* **Transformation des stratégies de sauvegarde**\n\n  * Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.\n  * Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans processus longs ni dédiés.\n* **Continuité des activités améliorée**\n\n  * Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits, tout comme le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.\n* **Réduction de la charge opérationnelle**\n\n  * La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.\n  * Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.\n* **Pérennisation de l'infrastructure**\n\n  * La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.\n  * À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.\n\nLes entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un compromis difficile est devenu une pratique opérationnelle simple.\n\nÀ partir de la version [GitLab 18.0](https://docs.gitlab.com/releases/18/gitlab-18-0-released/), tous les clients GitLab, quelle que soit leur version de licence, profitent désormais pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs [sauvegardes](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/), sans aucune autre modification de la configuration.\n\n## Et après ?\n\nCette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente une étape majeure, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.\n\nNous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git afin de profiter non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.\n\n> Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Consultez le [replay de notre événement virtuel de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/) et découvrez les autres améliorations fondamentales que nous proposons.\n",{"ogTitle":34,"ogImage":21,"ogDescription":19,"ogSiteName":35,"noIndex":36,"ogType":37,"ogUrl":38,"title":34,"canonicalUrls":38,"description":19},"Dépôts GitLab : forte diminution des temps de sauvegarde","https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",[23,41,25],"open-source",[23,24,25],"QyNvmctRTMyI3vvXQ3x4afJMJ-9d7OvwQMkuVZW02nI",{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":386,"minimal":421,"duo":440,"switchNav":449,"pricingDeployment":460},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/fr-fr/","gitlab logo","header",{"text":51,"config":52},"Commencer un essai gratuit",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Contacter l'équipe commerciale",{"href":58,"dataGaName":59,"dataGaLocation":49},"/fr-fr/sales/","sales",{"text":61,"config":62},"Connexion",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,95,197,202,305,366],{"text":67,"config":68,"menu":70},"Plateforme",{"dataNavLevelOne":69},"platform",{"type":71,"columns":72},"cards",[73,79,87],{"title":67,"description":74,"link":75},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":76,"config":77},"Explorer notre plateforme",{"href":78,"dataGaName":69,"dataGaLocation":49},"/fr-fr/platform/",{"title":80,"description":81,"link":82},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":83,"config":84},"Découvrir GitLab Duo",{"href":85,"dataGaName":86,"dataGaLocation":49},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":88,"description":89,"link":90},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":91,"config":92},"En savoir plus",{"href":93,"dataGaName":94,"dataGaLocation":49},"/fr-fr/why-gitlab/","why gitlab",{"text":96,"left":17,"config":97,"menu":99},"Produit",{"dataNavLevelOne":98},"solutions",{"type":100,"link":101,"columns":105,"feature":176},"lists",{"text":102,"config":103},"Voir toutes les solutions",{"href":104,"dataGaName":98,"dataGaLocation":49},"/fr-fr/solutions/",[106,131,154],{"title":107,"description":108,"link":109,"items":114},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":110},{"icon":111,"href":112,"dataGaName":113,"dataGaLocation":49},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[115,119,122,127],{"text":116,"config":117},"CI/CD",{"href":118,"dataGaLocation":49,"dataGaName":116},"/fr-fr/solutions/continuous-integration/",{"text":80,"config":120},{"href":85,"dataGaLocation":49,"dataGaName":121},"gitlab duo agent platform - product menu",{"text":123,"config":124},"Gestion du code source",{"href":125,"dataGaLocation":49,"dataGaName":126},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":128,"config":129},"Livraison de logiciels automatisée",{"href":112,"dataGaLocation":49,"dataGaName":130},"Automated software delivery",{"title":132,"description":133,"link":134,"items":139},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":135},{"href":136,"dataGaName":137,"dataGaLocation":49,"icon":138},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[140,144,149],{"text":141,"config":142},"Tests de sécurité des applications",{"href":136,"dataGaName":143,"dataGaLocation":49},"Application security testing",{"text":145,"config":146},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":147,"dataGaLocation":49,"dataGaName":148},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":150,"config":151},"Conformité logicielle",{"href":152,"dataGaName":153,"dataGaLocation":49},"/fr-fr/solutions/software-compliance/","software compliance",{"title":155,"link":156,"items":161},"Mesures",{"config":157},{"icon":158,"href":159,"dataGaName":160,"dataGaLocation":49},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[162,166,171],{"text":163,"config":164},"Visibilité et mesures",{"href":159,"dataGaLocation":49,"dataGaName":165},"Visibility and Measurement",{"text":167,"config":168},"Gestion de la chaîne de valeur",{"href":169,"dataGaLocation":49,"dataGaName":170},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":172,"config":173},"Données d'analyse et informations clés",{"href":174,"dataGaLocation":49,"dataGaName":175},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":177,"type":100,"items":178},"GitLab",[179,185,191],{"text":180,"config":181},"Pour les entreprises",{"icon":182,"href":183,"dataGaLocation":49,"dataGaName":184},"Building","/fr-fr/enterprise/","enterprise",{"text":186,"config":187},"Pour les PME",{"icon":188,"href":189,"dataGaLocation":49,"dataGaName":190},"Work","/fr-fr/small-business/","small business",{"text":192,"config":193},"Pour le secteur public",{"icon":194,"href":195,"dataGaLocation":49,"dataGaName":196},"Organization","/fr-fr/solutions/public-sector/","public sector",{"text":198,"config":199},"Tarifs",{"href":200,"dataGaName":201,"dataGaLocation":49,"dataNavLevelOne":201},"/fr-fr/pricing/","pricing",{"text":203,"config":204,"menu":206},"Ressources",{"dataNavLevelOne":205},"resources",{"type":100,"link":207,"columns":211,"feature":291},{"text":208,"config":209},"Afficher toutes les ressources",{"href":210,"dataGaName":205,"dataGaLocation":49},"/fr-fr/resources/",[212,245,263],{"title":213,"items":214},"Premiers pas",[215,220,225,230,235,240],{"text":216,"config":217},"Installation",{"href":218,"dataGaName":219,"dataGaLocation":49},"/fr-fr/install/","install",{"text":221,"config":222},"Guides de démarrage",{"href":223,"dataGaName":224,"dataGaLocation":49},"/fr-fr/get-started/","quick setup checklists",{"text":226,"config":227},"Apprentissage",{"href":228,"dataGaLocation":49,"dataGaName":229},"https://university.gitlab.com/","learn",{"text":231,"config":232},"Documentation",{"href":233,"dataGaName":234,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":236,"config":237},"Vidéos sur les bonnes pratiques",{"href":238,"dataGaName":239,"dataGaLocation":49},"/fr-fr/getting-started-videos/","best practice videos",{"text":241,"config":242},"Intégrations",{"href":243,"dataGaName":244,"dataGaLocation":49},"/fr-fr/integrations/","integrations",{"title":246,"items":247},"Découvrir",[248,253,258],{"text":249,"config":250},"Témoignages clients",{"href":251,"dataGaName":252,"dataGaLocation":49},"/fr-fr/customers/","customer success stories",{"text":254,"config":255},"Blog",{"href":256,"dataGaName":257,"dataGaLocation":49},"/fr-fr/blog/","blog",{"text":259,"config":260},"Travail à distance",{"href":261,"dataGaName":262,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":264,"items":265},"Connecter",[266,271,276,281,286],{"text":267,"config":268},"Services GitLab",{"href":269,"dataGaName":270,"dataGaLocation":49},"/fr-fr/services/","services",{"text":272,"config":273},"Communauté",{"href":274,"dataGaName":275,"dataGaLocation":49},"/community/","community",{"text":277,"config":278},"Forum",{"href":279,"dataGaName":280,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":282,"config":283},"Événements",{"href":284,"dataGaName":285,"dataGaLocation":49},"/events/","events",{"text":287,"config":288},"Partenaires",{"href":289,"dataGaName":290,"dataGaLocation":49},"/fr-fr/partners/","partners",{"config":292,"text":295,"image":296,"link":300},{"background":293,"textColor":294},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":297,"config":298},"carte promo The Source",{"src":299},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":301,"config":302},"Lire les articles les plus récents",{"href":303,"dataGaName":304,"dataGaLocation":49},"/fr-fr/the-source/","the source",{"text":306,"config":307,"menu":309},"Société",{"dataNavLevelOne":308},"company",{"type":100,"columns":310},[311],{"items":312},[313,318,324,326,331,336,341,346,351,356,361],{"text":314,"config":315},"À propos",{"href":316,"dataGaName":317,"dataGaLocation":49},"/fr-fr/company/","about",{"text":319,"config":320,"footerGa":323},"Carrières",{"href":321,"dataGaName":322,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":322},{"text":282,"config":325},{"href":284,"dataGaName":285,"dataGaLocation":49},{"text":327,"config":328},"Leadership",{"href":329,"dataGaName":330,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":332,"config":333},"Équipe",{"href":334,"dataGaName":335,"dataGaLocation":49},"/company/team/","team",{"text":337,"config":338},"Manuel",{"href":339,"dataGaName":340,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":342,"config":343},"Relations avec les investisseurs",{"href":344,"dataGaName":345,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":347,"config":348},"Trust Center",{"href":349,"dataGaName":350,"dataGaLocation":49},"/fr-fr/security/","trust center",{"text":352,"config":353},"Centre pour la transparence de l'IA",{"href":354,"dataGaName":355,"dataGaLocation":49},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":357,"config":358},"Newsletter",{"href":359,"dataGaName":360,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":362,"config":363},"Presse",{"href":364,"dataGaName":365,"dataGaLocation":49},"/press/","press",{"text":367,"config":368,"menu":369},"Nous contacter",{"dataNavLevelOne":308},{"type":100,"columns":370},[371],{"items":372},[373,376,381],{"text":56,"config":374},{"href":58,"dataGaName":375,"dataGaLocation":49},"talk to sales",{"text":377,"config":378},"Assistance GitLab",{"href":379,"dataGaName":380,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":382,"config":383},"Portail clients GitLab",{"href":384,"dataGaName":385,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":387,"login":388,"suggestions":395},"Fermer",{"text":389,"link":390},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":391,"config":392},"GitLab.com",{"href":63,"dataGaName":393,"dataGaLocation":394},"search login","search",{"text":396,"default":397},"Suggestions",[398,400,405,407,412,417],{"text":80,"config":399},{"href":85,"dataGaName":80,"dataGaLocation":394},{"text":401,"config":402},"Suggestions de code (IA)",{"href":403,"dataGaName":404,"dataGaLocation":394},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":116,"config":406},{"href":118,"dataGaName":116,"dataGaLocation":394},{"text":408,"config":409},"GitLab sur AWS",{"href":410,"dataGaName":411,"dataGaLocation":394},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":413,"config":414},"GitLab sur Google Cloud",{"href":415,"dataGaName":416,"dataGaLocation":394},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":418,"config":419},"Pourquoi utiliser GitLab ?",{"href":93,"dataGaName":420,"dataGaLocation":394},"Why GitLab?",{"freeTrial":422,"mobileIcon":427,"desktopIcon":432,"secondaryButton":435},{"text":423,"config":424},"Commencer votre essai gratuit",{"href":425,"dataGaName":54,"dataGaLocation":426},"https://gitlab.com/-/trials/new/","nav",{"altText":428,"config":429},"Icône GitLab",{"src":430,"dataGaName":431,"dataGaLocation":426},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":428,"config":433},{"src":434,"dataGaName":431,"dataGaLocation":426},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":436,"config":437},"Commencer",{"href":438,"dataGaName":439,"dataGaLocation":426},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":441,"mobileIcon":445,"desktopIcon":447},{"text":442,"config":443},"En savoir plus sur GitLab Duo",{"href":85,"dataGaName":444,"dataGaLocation":426},"gitlab duo",{"altText":428,"config":446},{"src":430,"dataGaName":431,"dataGaLocation":426},{"altText":428,"config":448},{"src":434,"dataGaName":431,"dataGaLocation":426},{"button":450,"mobileIcon":455,"desktopIcon":457},{"text":451,"config":452},"/switch",{"href":453,"dataGaName":454,"dataGaLocation":426},"#contact","switch",{"altText":428,"config":456},{"src":430,"dataGaName":431,"dataGaLocation":426},{"altText":428,"config":458},{"src":459,"dataGaName":431,"dataGaLocation":426},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":461,"mobileIcon":466,"desktopIcon":468},{"text":462,"config":463},"Retour aux tarifs",{"href":200,"dataGaName":464,"dataGaLocation":426,"icon":465},"back to pricing","GoBack",{"altText":428,"config":467},{"src":430,"dataGaName":431,"dataGaLocation":426},{"altText":428,"config":469},{"src":434,"dataGaName":431,"dataGaLocation":426},{"title":471,"button":472,"config":477},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":473,"config":474},"S'inscrire à GitLab Transcend le 10 juin",{"href":475,"dataGaName":476,"dataGaLocation":49},"/fr-fr/releases/whats-new/#sign-up","transcend event",{"layout":478,"icon":479,"disabled":36},"release","AiStar",{"data":481},{"text":482,"source":483,"edit":489,"contribute":494,"config":499,"items":504,"minimal":709},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":484,"config":485},"Afficher le code source de la page",{"href":486,"dataGaName":487,"dataGaLocation":488},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":490,"config":491},"Modifier cette page",{"href":492,"dataGaName":493,"dataGaLocation":488},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":495,"config":496},"Veuillez contribuer",{"href":497,"dataGaName":498,"dataGaLocation":488},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":500,"facebook":501,"youtube":502,"linkedin":503},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[505,550,603,647,674],{"title":198,"links":506,"subMenu":521},[507,511,516],{"text":508,"config":509},"Voir les forfaits",{"href":200,"dataGaName":510,"dataGaLocation":488},"view plans",{"text":512,"config":513},"GitLab Premium",{"href":514,"dataGaName":515,"dataGaLocation":488},"/fr-fr/pricing/premium/","why premium",{"text":517,"config":518},"GitLab Ultimate",{"href":519,"dataGaName":520,"dataGaLocation":488},"/fr-fr/pricing/ultimate/","why ultimate",[522],{"title":367,"links":523},[524,526,528,530,535,540,545],{"text":56,"config":525},{"href":58,"dataGaName":59,"dataGaLocation":488},{"text":377,"config":527},{"href":379,"dataGaName":380,"dataGaLocation":488},{"text":382,"config":529},{"href":384,"dataGaName":385,"dataGaLocation":488},{"text":531,"config":532},"Statut",{"href":533,"dataGaName":534,"dataGaLocation":488},"https://status.gitlab.com/","status",{"text":536,"config":537},"Conditions d'utilisation",{"href":538,"dataGaName":539,"dataGaLocation":488},"/terms/","terms of use",{"text":541,"config":542},"Politique de confidentialité",{"href":543,"dataGaName":544,"dataGaLocation":488},"/fr-fr/privacy/","privacy statement",{"text":546,"config":547},"Gérer vos cookies",{"dataGaName":548,"dataGaLocation":488,"id":549,"isOneTrustButton":17},"cookie preferences","ot-sdk-btn",{"title":96,"links":551,"subMenu":560},[552,556],{"text":553,"config":554},"Plateforme DevSecOps",{"href":78,"dataGaName":555,"dataGaLocation":488},"devsecops platform",{"text":557,"config":558},"Développement assisté par l'IA",{"href":85,"dataGaName":559,"dataGaLocation":488},"ai-assisted development",[561],{"title":562,"links":563},"Thèmes",[564,568,573,578,583,588,593,598],{"text":116,"config":565},{"href":566,"dataGaName":567,"dataGaLocation":488},"/fr-fr/topics/ci-cd/","cicd",{"text":569,"config":570},"GitOps",{"href":571,"dataGaName":572,"dataGaLocation":488},"/fr-fr/topics/gitops/","gitops",{"text":574,"config":575},"DevOps",{"href":576,"dataGaName":577,"dataGaLocation":488},"/fr-fr/topics/devops/","devops",{"text":579,"config":580},"Contrôle de version",{"href":581,"dataGaName":582,"dataGaLocation":488},"/fr-fr/topics/version-control/","version control",{"text":584,"config":585},"DevSecOps",{"href":586,"dataGaName":587,"dataGaLocation":488},"/fr-fr/topics/devsecops/","devsecops",{"text":589,"config":590},"Cloud-native",{"href":591,"dataGaName":592,"dataGaLocation":488},"/fr-fr/topics/cloud-native/","cloud native",{"text":594,"config":595},"IA pour la programmation",{"href":596,"dataGaName":597,"dataGaLocation":488},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":599,"config":600},"IA agentique",{"href":601,"dataGaName":602,"dataGaLocation":488},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":604,"links":605},"Solutions",[606,609,611,616,619,622,625,628,631,634,637,642],{"text":141,"config":607},{"href":136,"dataGaName":608,"dataGaLocation":488},"Application Security Testing",{"text":128,"config":610},{"href":112,"dataGaName":113,"dataGaLocation":488},{"text":612,"config":613},"Développement Agile",{"href":614,"dataGaName":615,"dataGaLocation":488},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":123,"config":617},{"href":125,"dataGaName":618,"dataGaLocation":488},"source code management",{"text":116,"config":620},{"href":118,"dataGaName":621,"dataGaLocation":488},"continuous integration & delivery",{"text":167,"config":623},{"href":169,"dataGaName":624,"dataGaLocation":488},"value stream management",{"text":569,"config":626},{"href":627,"dataGaName":572,"dataGaLocation":488},"/fr-fr/solutions/gitops/",{"text":629,"config":630},"Entreprises",{"href":183,"dataGaName":184,"dataGaLocation":488},{"text":632,"config":633},"PME",{"href":189,"dataGaName":190,"dataGaLocation":488},{"text":635,"config":636},"Secteur public",{"href":195,"dataGaName":196,"dataGaLocation":488},{"text":638,"config":639},"Éducation",{"href":640,"dataGaName":641,"dataGaLocation":488},"/fr-fr/solutions/education/","education",{"text":643,"config":644},"Services financiers",{"href":645,"dataGaName":646,"dataGaLocation":488},"/fr-fr/solutions/finance/","financial services",{"title":203,"links":648},[649,651,653,655,658,660,662,664,666,668,670,672],{"text":216,"config":650},{"href":218,"dataGaName":219,"dataGaLocation":488},{"text":221,"config":652},{"href":223,"dataGaName":224,"dataGaLocation":488},{"text":226,"config":654},{"href":228,"dataGaName":229,"dataGaLocation":488},{"text":231,"config":656},{"href":233,"dataGaName":657,"dataGaLocation":488},"docs",{"text":254,"config":659},{"href":256,"dataGaName":257,"dataGaLocation":488},{"text":249,"config":661},{"href":251,"dataGaName":252,"dataGaLocation":488},{"text":259,"config":663},{"href":261,"dataGaName":262,"dataGaLocation":488},{"text":267,"config":665},{"href":269,"dataGaName":270,"dataGaLocation":488},{"text":272,"config":667},{"href":274,"dataGaName":275,"dataGaLocation":488},{"text":277,"config":669},{"href":279,"dataGaName":280,"dataGaLocation":488},{"text":282,"config":671},{"href":284,"dataGaName":285,"dataGaLocation":488},{"text":287,"config":673},{"href":289,"dataGaName":290,"dataGaLocation":488},{"title":306,"links":675},[676,678,680,682,684,686,688,693,698,700,702,704],{"text":314,"config":677},{"href":316,"dataGaName":308,"dataGaLocation":488},{"text":319,"config":679},{"href":321,"dataGaName":322,"dataGaLocation":488},{"text":327,"config":681},{"href":329,"dataGaName":330,"dataGaLocation":488},{"text":332,"config":683},{"href":334,"dataGaName":335,"dataGaLocation":488},{"text":337,"config":685},{"href":339,"dataGaName":340,"dataGaLocation":488},{"text":342,"config":687},{"href":344,"dataGaName":345,"dataGaLocation":488},{"text":689,"config":690},"Développement durable",{"href":691,"dataGaName":692,"dataGaLocation":488},"/sustainability/","Sustainability",{"text":694,"config":695},"Diversité, inclusion et appartenance (DIB)",{"href":696,"dataGaName":697,"dataGaLocation":488},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":347,"config":699},{"href":349,"dataGaName":350,"dataGaLocation":488},{"text":357,"config":701},{"href":359,"dataGaName":360,"dataGaLocation":488},{"text":362,"config":703},{"href":364,"dataGaName":365,"dataGaLocation":488},{"text":705,"config":706},"Déclaration de transparence sur l'esclavage moderne",{"href":707,"dataGaName":708,"dataGaLocation":488},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":710},[711,713,716],{"text":536,"config":712},{"href":538,"dataGaName":539,"dataGaLocation":488},{"text":714,"config":715},"Gestion des cookies",{"dataGaName":548,"dataGaLocation":488,"id":549,"isOneTrustButton":17},{"text":541,"config":717},{"href":543,"dataGaName":544,"dataGaLocation":488},[719,733],{"id":720,"title":10,"body":29,"config":721,"content":723,"description":29,"extension":727,"meta":728,"navigation":17,"path":729,"seo":730,"stem":731,"__hash__":732},"blogAuthors/en-us/blog/authors/karthik-nayak.yml",{"template":722},"BlogAuthor",{"name":10,"config":724},{"headshot":725,"ctfId":726},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659809/Blog/Author%20Headshots/Screenshot_2025-06-04_at_8.49.51%C3%A2__AM.png","3Q6ZKvaiCRw7tFZdDGlecg","yml",{},"/en-us/blog/authors/karthik-nayak",{},"en-us/blog/authors/karthik-nayak","pDQbfmQk6aaJ6PA9L68AzPlzIUBcosTh7WBoq680gpk",{"id":734,"title":11,"body":29,"config":735,"content":736,"description":29,"extension":727,"meta":740,"navigation":17,"path":741,"seo":742,"stem":743,"__hash__":744},"blogAuthors/en-us/blog/authors/manuel-kraft.yml",{"template":722},{"name":11,"config":737},{"headshot":738,"ctfId":739},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659815/Blog/Author%20Headshots/manuel_kraft.png","5q1NADtEqxyoV1F1s6JKDz",{},"/en-us/blog/authors/manuel-kraft",{},"en-us/blog/authors/manuel-kraft","TqWe6Rx9TnEopbWMshRuht-6QCOpGPAMjs1vtlA_93Y",[746,759,773],{"content":747,"config":757},{"body":748,"date":749,"category":13,"tags":750,"heroImage":752,"authors":753,"description":755,"title":756},"Transformez GitLab Duo d'un assistant IA générique en un expert en codage personnalisé pour votre équipe grâce aux règles personnalisées. Ne perdez plus de temps à corriger constamment les suggestions de l'IA qui utilisent les mauvaises versions de Java et des binaires Python incorrects ou qui vont à l'encontre de vos guides de style. Ce guide approfondi vous apprendra à créer des règles personnalisées intelligentes qui appliquent automatiquement vos normes de développement.\n\nNous aborderons les points suivants :\n\n* Contrôle des versions : obligez l'IA à utiliser Java 8, gérez les environnements Python3 et générez du code C++ multi-plateforme\n* Application du style : prévenez les anti-patterns C `goto`, appliquez les design patterns VueJS et assurez la conformité aux linters Ansible\n* Automatisation DevSecOps : configurez des projets avec scans de sécurité CI/CD appropriés et normes de documentation\n\nChaque exemple inclut des projets GitLab fonctionnels à dupliquer, des configurations complètes et des démonstrations avant/après. Découvrez comment les systèmes bancaires maintiennent leur conformité à Java 8, comment les collecteurs IoT fonctionnent sur plusieurs plateformes et comment les composants VueJS suivent les normes de production de GitLab.\n\n## Premiers pas avec les règles personnalisées pour GitLab Duo Agentic Chat\n\nSuivez la [documentation](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#create-custom-rules) pour créer des règles personnalisées pour GitLab Duo Agentic Chat dans le répertoire `.gitlab/duo/chat-rules.md` d'un projet GitLab nouveau ou existant dans votre IDE.\n\nVous pouvez commencer avec des instructions en saisie libre et itérer pour obtenir le meilleur résultat. Les règles personnalisées prennent en charge le format [Markdown](https://docs.gitlab.com/user/markdown/) pour une meilleure structuration.\n\n* Utilisez les titres Markdown (`#`, `##`, etc.) pour créer des sections.\n* Utilisez les listes Markdown (`-`) pour fournir des instructions concises aux LLM et aux agents.\n* Réduisez les chemins de fichiers avec des backticks (accents graves) simples et utilisez des blocs de code avec indentation ou trois backticks.\n\nExemple :\n\n```markdown\n\n# Development guide\n\n## Frontend: VueJS\n\n### Styling Pattern\n- Do not use `\u003Cstyle>` tags in Vue components\n- Use Tailwind CSS utility classes or page-specific CSS instead\n\n```\n\nImportant : après avoir modifié les règles personnalisées, vous devrez créer un nouveau chat en appuyant sur l'icône `+` ou en envoyant `/new` dans le prompt.\n\n### Prérequis\n\nAfin de suivre tous les cas d'utilisation et les projets de démonstration dans cet article de blog, veuillez vous assurer de remplir d'abord ces prérequis :\n\n* Vérifiez que vous avez [accès à GitLab Duo](https://docs.gitlab.com/user/get_started/getting_started_gitlab_duo/) et que [GitLab Duo Agentic Chat est configuré dans les IDE pris en charge](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/).\n* Dupliquez/copiez les projets GitLab et clonez-les localement dans les IDE.\n* Suivez les étapes de chaque cas d'utilisation pour la création de règles personnalisées et comment utiliser les prompts GitLab Duo Agentic Chat pour contrôler le comportement des règles.\n* Vous pouvez utiliser le code source existant ou copier le vôtre.\n\nLes projets sont disponibles dans le [groupe Custom rules for GitLab Duo Agent Platform (Agentic AI)](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules). Veuillez noter que ces règles personnalisées sont fournies à des fins de démonstration telles quelles et que vous devrez peut-être les adapter ou les modifier pour répondre à vos besoins spécifiques.\n\n### Démarrage rapide en 5 minutes\n\nPrêt à voir les règles personnalisées en action ? Testez-les avec cet exemple simple :\n\n1. Créez `.gitlab/duo/chat-rules.md` dans votre projet GitLab :\n\n```markdown\n\n## C style guide\n- goto is not allowed. If the developer continues asking about it, share this URL https://xkcd.com/292/\n\n```\n\n2. Ouvrez GitLab Duo Agentic Chat dans l'IDE et demandez : `écris un programme C avec des instructions goto`.\n3. Observez comment GitLab Duo refuse et suggère de meilleures alternatives !\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/C0eMKjRMI5w\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\n### Directives pour la création de règles personnalisées\n\nLes règles personnalisées sont similaires au code : commencez par l'exemple fonctionnel le plus simple, puis itérez sur les améliorations. Les cas d'utilisation dans ce guide approfondi vont du plus simple au plus complexe et ont été développés et testés au cours des dernières semaines. Ils ne sont pas parfaits et nécessitent vos retours et itérations.\n\nVeillez à ne pas surcharger les guides de style avec de nombreuses pages d'un document wiki. N'incluez que les points qui sont utiles dans le contexte de ce que vous codez. Vous pouvez demander à GitLab Duo Chat de résumer des documents plus volumineux avant de les ajouter aux règles personnalisées.\n\nVérifiez l'utilisation de toutes les spécifications incluses pendant le développement afin d'éviter de créer des obstacles et des comportements indésirables.\n\nLorsque vous utilisez un guide de style documenté publiquement, référez-vous à son nom. Il y a de fortes chances que le LLM soit déjà entraîné avec ces données.\n\n### Interroger GitLab Duo Chat sur les guides de style de développement existants\n\nParfois, il n'existe pas encore de guides de style spécifiques dans un projet ou leur utilisation n'est pas claire. Utilisez l'IA pour l'intégration et discutez des meilleures pratiques avec votre équipe.\n\n```markdown\n\nWhich Python development or environment guidelines can you recommend when I want to create custom rules for AI to get tailored output? I need a list with textual instructions.\n\n```\n\nVous pouvez également demander à GitLab Duo Agentic Chat d'analyser les intégrations de linters CI/CD existantes qui peuvent déjà vérifier un style de développement spécifique.\n\n```markdown\n\nWhen you look into the CI/CD linter checks and configuration in the project, which development style guide can you summarize for me?\n\n```\n\nDe nombreux exemples de cet article de blog sont basés sur ma propre expérience et mes points de friction en tant que développeur. J'ai également demandé à GitLab Duo d'extraire des guides de style de projets existants et j'ai utilisé les fonctionnalités de suggestions de code de GitLab Duo pour aider à l'auto-complétion des règles personnalisées existantes. Vous pouvez obtenir le même résultat en configurant [`markdown` comme langage supplémentaire pour les fonctionnalités de suggestions de code de GitLab Duo](https://docs.gitlab.com/user/project/repository/code_suggestions/supported_extensions/#add-support-for-more-languages) dans les IDE.\n\n## Autres cas d'utilisation avec des règles personnalisées\n\nLes sections suivantes fournissent un aperçu de guides de style spécifiques. Vous pouvez mapper des langages de programmation et des environnements similaires à vos cas d'utilisation en production.\n\n* **Prise en charge de versions et de plateformes** : référez-vous à la [section Java](#exigences-de-version-java) ci-dessous pour apprendre à forcer un standard de langage spécifique pour le code généré et créé. Vous pouvez appliquer un processus similaire pour les versions C++23 et antérieures, PHP 8, Ruby 3, etc. La [section C++ ci-dessous](#prise-en-charge-multi-plateforme-C++-windows-Linux-macOS) montre comment indiquer des instructions à l'IA agentique avec la prise en charge multi-plateforme.\n* **Environnements de développement** : référez-vous aux sections ci-dessous sur [Python](#environnement-de-developpement-python-3) et [Ansible](#conformite-au-linter-ansible). Indiquez l'environnement de développement, les binaires, les outils et plus encore. Vous pouvez également indiquer aux agents des informations de routage sur les emplacements des tests/scripts et la façon d'appliquer la conformité avec les linters.\n* **Design patterns** : vous pouvez indiquer des design patterns complets avec [VueJS](#guides-de-style-frontend-pour-vuejs-3) comme exemple, en tirant parti des guides de style de développement de production de GitLab comme base.\n* **Workflows DevSecOps** : configurez des pratiques DevSecOps complètes avec la [configuration CI/CD](#preferences-de-configuration-cicd) pour des attributs CI/CD spécifiques et des valeurs par défaut pour le scan de sécurité, les [tests et linters](#tests-et-linters), et les [outils de build](#outils-de-build). Les cas d'utilisation fréquemment demandés pour la mise en place de projets incluent la [génération de documentation](#generation-de-documentation) avec `README.md` et diagrammes d'architecture, les [modèles de tickets et de merge requests](#modeles-de-tickets-et-merge-requests), [l'intégration, les exigences et les licences](#intégration-exigences-licences), et les [flux Git](#flux-git) avec `.gitignore`. Des techniques avancées avec règles personnalisées sont fournies pour les [exigences de refactorisation et de modification du code](#exigences-de-refactorisation-et-de-modification-du-code).\n\n### Cas d'utilisation : prise en charge de versions et de plateformes\n\nLe développement logiciel nécessite souvent des versions spécifiques de langages de programmation et de frameworks, ainsi qu'une prise en charge mono ou multi-plateforme. Les exemples suivants illustrent ces scénarios.\n\n#### Exigences de version Java\n\nLes environnements d'entreprise n'utilisent pas toujours la dernière version logicielle disponible. Ils s'appuient souvent sur des versions maintenues avec des correctifs de sécurité pendant une période plus longue. Par exemple, Java 7 et Java 8 sont encore utilisés dans certaines entreprises aujourd'hui.\n\nPréciser systématiquement la version requise dans les prompts de chat peut être fastidieux et conduire à des erreurs humaines, même en cas d'un seul oubli.\n\n```markdown\n\nImplement classes for managing banking transactions and different currencies.\n\n```\n\nL'exemple nécessitera des indications supplémentaires pour Java 8 :\n\n```markdown\n\nUse Java 8 for the implementation.\n\n```\n\nPour appliquer Java 8 de manière permanente, vous pouvez créer une règle personnalisée dans `.gitlab/duo/chat-rules.md` et ajouter éventuellement une URL d'epic de référence si un utilisateur vous pose des questions sur la modernisation du code :\n\n```markdown\n\n## Java style guide\n\n\n- Only Java 8 is allowed when suggesting and editing code.\n- When the user asks about code modernization and Java 9 or 21, or newer, point them to this issue to contribute: https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/issues/1\n\n```\n\nUne démonstration complète est disponible dans le [projet Custom Rules – Java versions](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions).\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/iZLvpgHdABY\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nLes modifications résultantes sont disponibles dans [cette merge request](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/merge_requests/2).\n\n#### Prise en charge multi-plateforme C++ (Windows, Linux, macOS)\n\nLe développement d'applications en C++ peut nécessiter une prise en charge multi-plateforme, notamment lors de l'exécution d'agents de service sur des systèmes utilisant Windows, Linux et macOS. Les applications sont profondément intégrées aux produits clients et une migration vers un langage plus moderne comme Go ou Rust n'est pas toujours possible ni pratique.\n\nMaintenir du code qui fonctionne sur plusieurs plateformes peut être difficile en raison des différences dans les API de système d'exploitation, les chaînes d'outils, les versions de bibliothèques et les chemins de système de fichiers. Les équipes de développement sont souvent confrontés à plusieurs macros de préprocesseur `#if defined` et à des conditions imbriquées. Ils doivent alors ajouter du code et des tests personnalisés pour chaque plateforme prise en charge. Résultat : cette situation alourdit la dette technique et entraîne des défis de maintenance.\n\nL'IA peut aider lors de la génération de code correct et spécifique à une plateforme, mais elle doit connaître ces exigences. Soit l'IA agentique comprendra le code source existant via un graphe de connaissances, soit les équipes devront fournir des instructions via des règles personnalisées et des prompts.\n\nEssayons ce cas d'utilisation en pratique. Le [projet Custom Rule – C++ platforms – IoT Sensor Data Collector](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector) implémente un collecteur de données de capteurs IoT et a des tâches ouvertes pour moderniser le code source et ajouter la prise en charge multi-plateforme pour Linux, Windows et macOS. Vous pouvez dupliquer le projet et le cloner localement.\n\nOuvrez le fichier `.gitlab/duo/chat-rules.md` et examinez ou ajoutez les règles personnalisées suivantes :\n\n```markdown\n\n## C++ style guide\n\n- The application runs on Linux, macOS and Windows. Generate code that handles the OS API differences.\n- Use pre-processor macros for Windows and POSIX conventions for Unix (Linux, macOS).\n\n## CI/CD Configuration\n\n- Ensure that GitLab CI/CD jobs cover the different platform support. Use CI/CD job templates with extends where applicable.\n\n```\n\nDémarrez un nouveau chat et demandez de restructurer le code pour la prise en charge multi-plateforme.\n\n```markdown\n\nPlease help me restructure the code and ensure multi-platform support.\n\n```\n\nVous pouvez également indiquer le numéro de ticket ou l'URL ([ticket 3](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector/-/issues/3)). GitLab Duo récupérera automatiquement le contenu du ticket depuis la plateforme GitLab et le mettra dans le contexte de l'IA.\n\n```markdown\n\nPlease help me implement issue 3\n\nPlease help me implement https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector/-/issues/3\n\n```\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/C5NxOjB0R1Q\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\n### Cas d'utilisation : environnements de développement\n\nLes environnements de développement varient souvent entre les systèmes d'exploitation et les équipes, ce qui peut perturber les modèles d'IA qui génèrent du code ou suggèrent des modifications. Les cas d'utilisation suivants illustrent ces problèmes d'environnement et leurs solutions avec des règles personnalisées.\n\n#### Environnement de développement Python 3\n\nUn environnement de développement Python est généralement fourni avec le fichier exécutable `python` et le gestionnaire de paquets `pip`. Cependant, sur des systèmes comme MacOS ou Ubuntu, vous devez utiliser `python3` et `pip3` pour accéder aux versions plus récentes de Python 3. Cette approche peut entraîner une confusion lors de l'exécution de scripts Python, de la création d'environnements virtuels et de l'installation de dépendances de paquets.\n\nPour ce cas d'utilisation de règles personnalisées, j'ai installé Python en utilisant [Homebrew](https://brew.sh/), ce qui entraîne un fichier exécutable binaire appelé `python3` et un gestionnaire de paquets `pip3`.\n\nConfigurez un environnement virtuel Python à titre d'exemple, installez les dépendances avec `pip` et exécutez l'application :\n\n```shell\n\npython -m venv myenv\nsource myenv/bin/activate\n\npip install -r requirements.txt\n\npython script.py\n\n```\n\nCela ne fonctionne pas comme prévu, car nous devons utiliser des binaires spécifiques avec la version `3` :\n\n```shell\n\npython3 -m venv myenv\nsource myenv/bin/activate\n\npip3 install -r requirements.txt\n\npython3 script.py\n\n```\n\nNous pouvons tester ce problème avec l'Agentic Chat pour les blocs de code suggérés et la demande d'approbation pour les commandes à exécuter. Le [projet Custom Rule – Python3 Env Shop app](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app) implémente une application de boutique web en Python et fournit les chemins de fichiers exécutables Python par défaut dans son fichier `README.md` qui est généralement ajouté au contexte d'Agentic Chat.\n\n![GitLab Duo Agentic Chat, qui propose les mauvaises commandes binaires](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769123901/c0jltxbgxi2suobxhwwq.png)\n\nAfin de résoudre le problème, examinez `.gitlab/duo/chat-rules.md`, qui contient les règles personnalisées suivantes pour appliquer les noms de fichiers exécutables Python.\n\n```markdown\n\n## Python style guide\n\n- For Python binaries, always use python3 and pip3 when suggesting or running shell commands.\n- Detect the Python environment automatically when possible.\n\n```\n\nVous pouvez également instruire les agents avec des routes prédéfinies pour rassembler des informations supplémentaires via l'appel d'outils et/ou le MCP, s'ils ne le font pas déjà automatiquement.\n\nOuvrez un nouvel Agentic Chat et demandez `Comment exécuter cette application ?` pour voir les règles personnalisées en action avec `python3` et `pip3` comme souhaité.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/UQ2_OCvUmF0\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nLe code source complet est disponible dans le [projet Custom Rule – Python3 Env Shop app](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app).\n\n#### Conformité au linter Ansible\n\nLe linter Ansible moderne pour les tâches d'Infrastructure-as-Code applique un guide de style strict, qui peut être vérifié avec `ansible-lint` : il détecte lorsque des valeurs booléennes (`true`/`false`) sont requises au lieu de chaînes (`yes`/`no`), les actions de modules intégrés qui requièrent le FQCN (Fully Qualified Collection Name) comme noms de paramètres, et les caractères invisibles de fin à supprimer. Les intégrations CLI et IDE, telles que l'[extension VS Code Ansible par Red Hat](https://developers.redhat.com/learning/learn:ansible:get-started-ansible-visual-studio-code-extension/resource/resources:install-and-configure-ansible-extension-visual-studio-code) aident les équipes à visualiser ces erreurs. Les LLM et les agents de chat ne génèrent pas toujours du code Ansible correct, ce qui force les équipes à le corriger manuellement.\n\nExaminons le problème avec un cas d'utilisation concret. L'exemple suivant implémente un guide Ansible basique dans le [projet Custom Rule – Ansible Environment](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) pour configurer un serveur GitLab sur Ubuntu. Les valeurs booléennes sont incorrectement typées comme chaînes (`yes`/`no`), et les actions de modules intégrés ainsi que la suppression des espaces entraînent des problèmes supplémentaires.\n\n![VS Code avec erreur de linter Ansible : mauvais type booléen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769123900/eofxonbvbs7o2qt48tmc.png)\n\n![VS Code avec erreur de linter Ansible : FQCN d'action de module intégré](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769123900/qnzwk8b1dslmcqercxul.png)\n\n![VS Code avec erreur de linter Ansible : caractères invisibles de fin](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769123900/fsrceusoksp16xj42yix.png)\n\nVoyons comment nous pouvons créer des règles personnalisées pour aider les agents GitLab Duo à corriger les erreurs de linter Ansible et les empêcher de se reproduire à l'avenir.\n\nDupliquez et clonez le [projet Custom Rule – Ansible Environment](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) et ouvrez `.gitlab/duo/chat-rules.md` dans l'IDE pour inspecter les règles personnalisées :\n\n```markdown\n\n## Ansible styleguide\n\n- Boolean values in Ansible should be typed as \"true\" or \"false\" and never as string.\n- Ansible module builtin actions must use the FQCN (Fully Qualified Collection Name).\n- Always trim whitespaces in Ansible YAML.\n\n```\n\nOuvrez un nouveau prompt GitLab Duo Agentic Chat et demandez à l'agent GitLab Duo le même guide de directives et de procédures opérationnelles Ansible :\n\n```markdown\n\nPlease help me fix the Ansible linter errors\n\n```\n\nLes agents analyseront le dépôt, demanderont d'exécuter des commandes `ansible-lint`, et examineront comment corriger les problèmes en suivant les règles personnalisées définies.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/P465U8IfScE\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nVous pouvez inspecter les règles personnalisées et les modifications de code Ansible dans [cette merge request](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment/-/merge_requests/1) dans le [projet Custom Rule – Ansible Environment](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment).\n\nExercice asynchrone : démarrez un nouveau projet où les règles personnalisées sont configurées par défaut et vérifiez que le guide de style correct est appliqué immédiatement.\n\n### Cas d'utilisation : design patterns\n\nCette section explore les design patterns et modèles à éviter, qui sont spécifiques aux langages et frameworks. \n\n#### Éviter les anti-patterns avec C et les instructions goto\n\nVoici une présentation plus approfondie de l'[exemple de démarrage rapide](#démarrage-rapide-en-5-minutes), qui montre comment vous pouvez donner des instructions à l'IA agentique pour éviter l'anti-pattern `goto` en C. L'anti-pattern `goto` en C est déconseillé car il rend le code plus difficile à lire et à déboguer. Pour illustrer le problème, voici un exemple de commande for-loop qui incrémente la variable de boucle à l'intérieur du corps de la boucle :\n\n```C\n\n// Bad C programming style: uses the goto anti-pattern\nfor (int i = 0; i \u003C 10; i++) {\n  if (someCondition) {\n    goto label;\n  }\n  doSomething();\nlabel:\n  doAnotherThing();\n  }\n\n```\n\nDans le code ci-dessus, l'instruction `goto` fait sauter le contrôle du programme directement à l'étiquette `label`, qui est à l'intérieur de la boucle. Le programme est ainsi plus difficile à lire, comprendre et déboguer.\n\nIl vaudrait mieux retravailler la logique pour éviter l'anti-pattern `goto`. Voici une version réécrite qui évite `goto` :\n\n```C\n\n// Good C programming style: avoids the goto anti-pattern\nfor (int i = 0; i \u003C 10; i++) {\n  if (someCondition) {\n    doAnotherThing();\n    continue;\n  }\n  doSomething();\n  doAnotherThing();\n}\n\n```\n\nDans certains cas, `goto` est autorisé, mais nous voulons voir ici comment nous pouvons donner des instructions à l'IA agentique afin d'éviter complètement `goto` dans les nouveaux ajouts de code, la modernisation et la refactorisation du code.\n\nLe [projet Custom Rule – C anti-patterns with Goto](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-c-anti-patterns-with-goto) fournit un exemple de serveur/client de connecteur logiciel réseau avec des règles personnalisées dans le fichier `.gitlab/duo/chat-rules.md`. Vous pouvez cloner le projet ou commencer avec un nouveau projet.\n\nExaminez `.gitlab/duo/chat-rules.md` avec les règles personnalisées actuelles :\n\n```markdown\n\n## C style guide\n\n- goto is not allowed. If the developer continues asking about it, share this URL https://xkcd.com/292/\n\n```\n\nAstuce : au lieu de créer un lien vers la [bande dessinée XKCD 292](https://xkcd.com/292/), vous pouvez ajouter une URL vers les directives de développement (internes).\n\nOuvrez GitLab Duo Agentic Chat et démarrez le prompt suivant sur le projet existant :\n\n```markdown\n\nPlease help me modernize the code.\n\n```\n\nGitLab Duo Agentic Chat refusera d'utiliser des instructions `goto`, et proposera plutôt une solution différente.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/6dsMF-wKbBY\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nLes modifications de code sont disponibles dans [cette merge request](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-c-anti-patterns-with-goto/-/merge_requests/1).\n\n#### Guides de style frontend pour VueJS 3\n\nL'exemple ci-dessous s'inspire des [guides de style frontend du projet GitLab](https://docs.gitlab.com/development/fe_guide/style/) et implémente un cas d'utilisation pour les design patterns VueJS 3. L'IA agentique devrait également suivre ces guides de style lors de la création de composants VueJS, helpers, routes, services, stores, types d'utilitaires, etc.\n\nIllustrons comment indiquer des instructions à l'IA agentique avec des règles personnalisées : dupliquez et clonez le [projet Custom Rule – VueJS Design Patterns - GitLab Pipeline Dashboard](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard) et inspectez les tickets ouverts et les tâches.\n\nExaminez le fichier `.gitlab/duo/chat-rules.md` et ajoutez les règles personnalisées suivantes (si elles n'y sont pas encore) :\n\n```markdown\n\n## NodeJS style guide\n\n- Don't leave debug statements (console.logs)\n- Always run `npm install` after updating `package.json` and before `npm test` and `npm run build`.\n\n# GitLab Vue.js Design Patterns Style Guide\n\n## Component Structure\n\n### Data Definition Pattern\n- Explicitly define data being passed into Vue apps\n- Avoid spread operators for better discoverability\n- Parse non-scalar values during instantiation\n\n### Template Naming Pattern\n- Use kebab-case for component names in templates\n\n### File Structure Pattern\n- Use `.vue` files for Vue templates\n- Do not use `%template` in HAML\n\n### Styling Pattern\n- Do not use `\u003Cstyle>` tags in Vue components\n- Use Tailwind CSS utility classes or page-specific CSS instead\n\n[...]\n\n```\n\nLes règles personnalisées complètes sont disponibles dans le [fichier `.gitlab/duo/chat-rules.md`](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/blob/main/.gitlab/duo/chat-rules.md?ref_type=heads&plain=1).\n\nEnsuite, ouvrez GitLab Duo Agentic Chat et demandez comment [ajouter de nouveaux mini graphiques de pipeline](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/issues/6), ou d'autres tâches que vous rencontrez. Astuce : vous pouvez référencer uniquement le ticket ou coller l'URL complète du ticket, et l'Agentic Chat recherchera les deux et extraira le titre et la description pour le contexte actuel.\n\n```markdown\n\nPlease help me implement issue 6\n\n```\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/KbczS-OVb90\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nLes modifications de code qui en résultent sont disponibles dans [cette merge request](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/merge_requests/3).\n\nRemarque : le guide de style VueJS a été extrait du [projet gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab) grâce à GitLab Duo Agentic Chat avec le prompt suivant :\n\n```markdown\n\nWhat is the development style guide for VueJS?\n\nCan you print the styleguide as Markdown formatted list with headings.\n\nCreate a file in the repo, and only print the style guide rules there, no codeblocks.\n\n```\n\n![IntelliJ IDEA avec le code source `gitlab-org/gitlab`, et GitLab Duo Agentic Chat écrivant le fichier du guide de style](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769123901/prf63nqoqsqzn7lh9pnq.png)\n\n### Cas d'utilisation : workflows DevSecOps\n\nLes workflows DevSecOps comprennent les meilleures pratiques pour la configuration initiale d'un projet avec des modèles de tickets/merge requests, `.gitignore`, la configuration GitLab CI/CD, la documentation `README.md`, les licences et bien plus encore. La section suivante explore une large gamme de cas d'utilisation. Vous pouvez vous en inspirer pour vos propres règles personnalisées.\n\nAutomatisation DevSecOps courante avec règles personnalisées :\n\n* **Configuration initiale de projet** : création automatique de README, .gitignore, configuration CI/CD\n* **Valeurs par défaut de sécurité** : application de test statique de sécurité des applications (SAST), scan des dépendances, détection des secrets\n* **Documentation** : génération de templates de tickets/merge requests, diagrammes d'architecture\n\nUn exemple de cas d'utilisation combiné est disponible dans le [projet Custom Rule – DevSecOps workflows – Git README build tools issue MR templates](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-devsecops-workflows). Vous pouvez explorer les règles personnalisées, et les dupliquer/cloner localement pour interroger l'Agentic Chat avec un nouveau prompt, tel que : `Aide-moi à effectuer la configuration initiale de ce projet`.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/hKpLcBtbC4g\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nLes sections suivantes (aussi disponibles dans la vidéo ci-dessus) fournissent des prompts détaillés.\n\n#### Templates de tickets et merge requests\n\nVous pouvez demander à l'IA agentique de créer des templates de tickets/merge requests s'ils sont manquants, et proposer d'ajouter des informations spécifiques au projet ou des étiquettes. Les agents interrogeront automatiquement l'API de GitLab en arrière-plan et intégreront la structure actuelle du projet dans un template.\n\n```markdown\n\n## Issue and MR templates\n\n- If no issue templates for `Default` and `Feature Proposal` exist in .gitlab/issue_templates, create them using the following raw template sources:\n\n        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Default.md\n        Feature Proposal: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Feature%20Proposal.md\n\n- If no default MR template `Default` exists in `.gitlab/merge_request_templates`, create them using the following raw template sources:\n\n        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/merge_request_templates/Default.md\n\n- Update the project URLs, and available labels in the fetched templates accordingly, or remove anything unknown and let the user know about TODOs.\n- Create a test issue/MR, when bootstrapping a new project.\n\n```\n\n#### Outils de build\n\nIl existe une variété d'outils de build, de gestionnaires de paquets, de compilateurs, de constructeurs de conteneurs disponibles par langage de programmation. Lors de questions sur les mises à jour et dépendances, l'IA agentique peut utiliser ces outils par défaut sans demander l'autorisation.\n\n```markdown\n\n## Build tools\n\n- Always use a virtual env with Python, and set it up before executing any Python commands\n- For C/C++: Prefer CMake, and gcc on Linux, clang on macOS, MSVC on Windows.\n- For Python: Always use pip\n- For Java: Always use Gradle\n- For Node.js, suggest to use npm/yarn.\n- For Rust: Always use cargo\n- For Go: Always use go.mod\n- For Ruby: Always use Bundler\n- For PHP: Always use Composer\n- For .NET: Always use .NET CLI\n- For Scala: Always use SBT\n- For Elixir: Always use Mix\n- For Haskell: Always use Cabal\n- For Swift: Always use Swift Package Manager\n- For Kotlin: Always use Gradle or Maven.\n- For TypeScript: Always use npm or yarn.\n- Always suggest using a package manager or build tool based on the main programming language of the project.\n- When asking for dependencies, assume that the user wants to update all current dependencies to the latest version available.\n\n- Always suggest to create a Dockerfile if there isn't one. Always use a minimal image and use a tag for security scanning.\n- Always add a `Dockerfile` with the base image and the entrypoint if one does not exist.\n- Always include a `.dockerignore` and use it in the Docker build process.\n\n```\n\n#### Préférences de configuration CI/CD\n\nUtilisez des règles pour indiquer des images de conteneur spécifiques, des modèles de variables et de noms de jobs, etc.\n\n```markdown\n\n## CI/CD Configuration\n\n- If no GitLab CI/CD configuration exists in `.gitlab-ci.yml`, ask the user for approval to create.\n- Create a GitLab CI/CD configuration automatically when a new project gets bootstrapped\n\n- Always use alpine as container image to build the application.\n- Add caching for detected programming languages and frameworks.\n\n```\n\n#### Préférences de scan de sécurité\n\nLes scanners de sécurité peuvent également être appliqués dans la configuration GitLab CI/CD. L'exemple suivant indique aux agents de toujours inclure l'analyseur Advanced SAST, le scan des dépendances et la détection des secrets. Il a été testé avec succès dans d'autres cas d'utilisation de ce tutoriel.\n\n```markdown\n\n## Security scanning\n\n- Always use Advanced SAST.\n- Always include SAST, Dependency Scanning, Secrets Detection templates, similar to the following format:\n\n    include:\n        - template: Jobs/SAST.gitlab-ci.yml\n        - template: Jobs/Secret-Detection.gitlab-ci.yml\n        - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\n    variables:\n        GITLAB_ADVANCED_SAST_ENABLED: 'true'\n\n        \n```\n\n![VS Code avec une application Java, GitLab CI/CD, des règles personnalisées, et l'Agentic Chat qui ajoute l'analyseur Advanced SAST (test statique de sécurité des applications)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769123900/avokij2uelhkx711wp1q.png)\n\n#### Tests et linters\n\nVous pouvez également indiquer directement à l'Agentic Chat où trouver les tests et comment les exécuter. La même idée s'applique à l'appel de commandes de linter. Merci à Jessie Young pour cette astuce pratique !\n\n```markdown\n\n## Tests and linting details\n\n- Tests in this project are located in __ directory and are run using the ___ command\n- Linting is done with the ___ command\n\n```\n\n#### Génération de documentation\n\nVoici les meilleures règles personnalisées concernant la documentation.\n\n```markdown\n\n- If a README is missing, ask the user if they want to create one. If the user agrees, create a basic `README.md` for them.\n- When the user asks for an architecture proposal, always respond with generating an architecture diagram in Mermaid, and ask the user if they want you to add it to the README.md or another documentation file.\n- For documentation in Markdown, always use GitLab flavored Markdown.\n- Always add correct code block syntax highlighting support.\n\n```\n\n#### Exigences de refactorisation et de modification du code\n\nLorsqu'un projet doit être progressivement modernisé avec du code qui vient d'être généré et ne doit pas entraîner de grandes refactorisations, les règles suivantes peuvent être utiles.\n\n```markdown\n\n## Keep the changes minimal\n\n- The project uses \u003Cthis standard and version>. For newly generated code, use this standard.\n- Do not attempt to refactor code already created in a project to this standard, but for new code, always ensure this standard is used.\n- If unsure whether a file requires modification or refactoring, document this as a todo task.\n- Never fix detected problems, whitespaces, code formatting, unless the user instructs you specifically in a comment.\n- The code must be retained in its original format and only changes specific to solving the user request are allowed.\n\n## Summaries\n\n- List all items to address at the bottom in a summary section with TODO: followed by a textual description.\n- Identify 3 critical items, and ask the user if you should create GitLab issues from those items.\n\n```\n\n#### Intégration, exigences, licences\n\nIncluez toujours un lien de documentation spécifique, et des directives à suivre dans les réponses de chat.\n\n```markdown\n\n## Link to guidelines\n- Always refer to our developer guidelines when answering questions. You can find those guidelines here: https://docs.gitlab.com/development/\n\n## Context and planning\n- Always start with finding existing issues with the desired topic. Only then propose new implementation work.\n\n## License\n- Always add the MIT license into `LICENSE` and use `GitLab B.V.` as copyright holder.\n\n```\n\n#### Flux Git\n\nSuivez un flux de gestion de branches Git spécifique pour les suggestions et commandes exécutées.\n\n```markdown\n\n## Git flows\n\n- Examine the project and involved development environment and programming languages. Always add a `.gitignore`.\n- Consider more best practices when bootstrapping a new project.\n- For existing projects, offer to add a `.gitignore` when missing, but only when asked about the state of the project, or what is missing.\n\nWhen a user requests to start with a new feature, always create a new branch, called \"feature/\u003Cshortname>\" and describe the behavior. Ask for the user's approval.\n\n```\n\n## Distribution et tests des règles personnalisées\n\nVous pouvez créer des [templates de projets GitLab](https://docs.gitlab.com/administration/custom_project_templates/) avec des prompts de règles personnalisées éprouvés et appliquer les meilleures pratiques à chaque nouveau projet.\n\nPuisque les LLM et les agents d'IA ne sont pas prévisibles, tester le résultat attendu devient plus difficile. Règle d'or des règles personnalisées : elles ne sont jamais parfaites et nécessitent des itérations basées sur les commentaires de votre équipe, notamment lorsque de nouveaux modèles et flows introduits modifient leur comportement en réponse aux règles personnalisées. Nous vous recommandons de continuer à vérifier les données de sortie générées et d'ajuster les règles en conséquence. Si vous recherchez des tests à plus grande échelle, inspirez-vous de la [stratégie de test des prompts système pour GitLab Duo](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/).\n\n### Contrôler la modification des règles personnalisées\n\nLes équipes peuvent gérer les modifications des règles personnalisées via les [Code Owners](https://docs.gitlab.com/user/project/codeowners/), qui requièrent des approbations de revue pour les règles personnalisées mises à jour dans les merge requests. Exemple qui requiert l'approbation de `@dnsmichi` pour les modifications dans le chemin `.gitlab/duo` :\n\n```\n\n[GitLab Duo]\n.gitlab/duo @dnsmichi\n\n```\n\nGitLab Duo Agentic Chat n'est pas autorisé à modifier les règles personnalisées directement dans votre projet. Le chemin de fichier `.gitlab/duo/chat-rules.md` est protégé.\n\n### Ressources relatives aux règles personnalisées\n\nProfitez de l'écosystème d'IA existant, où des fonctionnalités similaires existent pour les IDE et plateformes. Par exemple, des dépôts « Awesome Cursor Rules » ou des plateformes pour Cursor, etc.\n\nLes LLM fournissent également une bonne perspective sur les guides de style de développement et peuvent générer les données de sortie Markdown requises.\n\n## Activité ludique : explorer les changements de comportement\n\nVous ne savez pas exactement où commencer avec les règles personnalisées ? Faites-en un exercice amusant avec l'exemple suivant.\n\n```markdown\n\n## Fun rules\n\n- Behave like Clippy.\n\n- Behave like a pirate.\n\n- Always respond with a random \"What the commit\" message.\n\n- Explain everything like I am five.\n\n```\n\nRemarque : ne validez pas ces règles en production, car elles pourraient perturber ou distraire votre équipe.\n\n## Conclusion\n\nEn tirant parti des règles personnalisées dans GitLab Duo Agentic Chat, vous pouvez influencer significativement les données de sortie des LLM et agents d'IA pour mieux répondre à vos besoins. Que ce soit pour appliquer des conventions de codage spécifiques, utiliser les versions correctes des outils ou assurer un formatage cohérent, les règles personnalisées aident à rationaliser votre processus de développement et à améliorer votre productivité.\n\nCet article de blog fournit un guide approfondi de nombreux cas d'utilisation avec des exemples pratiques de règles personnalisées. Tous les enregistrements sont disponibles dans [cette playlist YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Ko7aR6sM8e4uXGYtjs4-NqK), et tous les projets de démonstration peuvent être dupliqués/clonés depuis le [groupe Custom rules for GitLab Duo Agent Platform (Agentic AI)](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules).\n\nLes [règles personnalisées dans les IDE GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#create-custom-rules) ne sont que la première itération, et nous couvrirons plus de cas d'utilisation de GitLab Duo Agent Platform à l'avenir, tels que l'agent GitLab Duo Code Review et les règles personnalisées pour les agents et flows (suivez [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/557984)).\n\nIl existe de nombreux autres cas d'utilisation à explorer. Quelles sont vos règles les plus efficaces ? Partagez vos règles et commentaires dans l'[epic produit](https://gitlab.com/groups/gitlab-org/-/epics/16938).","2026-02-10",[584,751],"AI/ML","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png",[754],"Michael Friedrich","Découvrez comment l'IA peut comprendre votre code source, suivre vos conventions et générer du code prêt pour la production avec un minimum de cycles de revue.","GitLab Duo Agentic Chat : renforcez votre code avec les règles personnalisées",{"featured":36,"template":15,"slug":758},"custom-rules-duo-agentic-chat-deep-dive",{"content":760,"config":771},{"tags":761,"category":13,"date":764,"heroImage":765,"authors":766,"body":768,"description":769,"title":770},[762,763],"product","inside GitLab","2025-12-16","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1764108112/tyntnsy3xotlmehtnfkb.png",[767],"John Skarbek","Chaque jour, GitLab déploie des modifications de code sur GitLab.com, la plus grande instance GitLab au monde, et ce jusqu'à 12 fois sans aucun temps d'arrêt. Nous utilisons la plateforme [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"CI/CD\") de GitLab elle-même afin de gérer ces déploiements qui impactent des millions d'équipes de développement à travers le monde. Cette fréquence de déploiement constitue notre principal critère de qualité et notre test de charge. Résultat : nos clients profitent des nouvelles fonctionnalités quelques heures seulement après leur développement au lieu d'attendre des semaines ou des mois. Lorsque des organisations s'appuient sur GitLab pour leurs workflows [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\"), elles utilisent une plateforme évolutive et éprouvée.    \n\nDans cet article, vous découvrirez comment nous avons construit un pipeline de déploiement automatisé en utilisant les fonctionnalités principales de GitLab CI/CD afin de gérer cette complexité de déploiement.\n\n## L'impératif métier de la vélocité de déploiement\n\nPour GitLab, la fréquence de déploiement ne représente pas simplement un indicateur technique, il s'agit au contraire d'un impératif métier. Des cycles de déploiement rapides nous permettent de répondre aux retours clients en quelques heures, de déployer immédiatement des correctifs de sécurité et de valider les nouvelles fonctionnalités en production avant de les déployer à grande échelle.\n\nPour nos clients, chaque déploiement vers GitLab.com valide les pratiques de déploiement que nous recommandons à nos utilisateurs. Lorsque vous utilisez les fonctionnalités de déploiement de GitLab, vous utilisez la même approche éprouvée qui gère quotidiennement des millions d'opérations [git](https://about.gitlab.com/fr-fr/blog/2024/10/08/what-is-git/ \"Git\"), de [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\") et d'interactions utilisateurs. Vous bénéficiez ainsi des avantages suivants :\n\n- Disponibilité immédiate des dernières fonctionnalités : les nouvelles fonctionnalités vous parviennent quelques heures après leur finalisation, et non dans des cycles trimestriels.\n- Fiabilité éprouvée à grande échelle : si une fonctionnalité fonctionne sur GitLab.com, il en ira de même pour votre environnement.\n- Valeur complète de GitLab : les déploiements sans interruption garantissent un accès constant à votre [plateforme DevOps](https://about.gitlab.com/fr-fr/solutions/devops-platform/ \"Plateforme DevOps\"), même pendant les mises à jour.\n- Pratiques testées en conditions réelles : notre documentation de déploiement ne relève pas de la théorie et reflète exactement la manière dont nous exploitons la plus grande instance GitLab existante.\n\n\n## Architecture du flux de code\n\n\nNotre pipeline de déploiement suit une progression structurée à travers plusieurs étapes, chacune agissant comme un point de contrôle sur le parcours allant de la proposition de code au déploiement en production.\n```mermaid\n  graph TD\n      A[Code proposé] --> B[Merge request créée]\n      B --> C[Pipeline déclenché]\n      C --> D[Build et test]\n      D --> E{Spécifications/intégration/tests QA réussis ?}\n      E -->|Non| F[Boucle de rétroaction]\n      F --> B\n      E -->|Oui| G[Merge vers la branche par défaut]\n      G -->|Périodiquement| H[Branche déployée automatiquement]\n\n      subgraph \"Pipeline de déploiement\"\n          H --> I[Création de paquet]\n          I --> K[Environnement canari]\n          K --> L[Validation QA]\n          L --> M[Environnement principal]\n\n      end\n```\n\n## Composition du pipeline de déploiement\n\nNotre approche de déploiement utilise les capacités CI/CD natives de GitLab afin d'orchestrer des déploiements complexes sur une infrastructure hybride.\nVoici comment nous procédons.\n\n\n### Build\n\n\nLe build de GitLab constitue en soi un sujet complexe, c'est pourquoi nous en aborderons les détails à un niveau général.\n\nNous construisons à la fois notre paquet Omnibus et nos images Cloud Native GitLab (CNG). Les paquets Omnibus se déploient sur notre flotte Gitaly (notre couche de stockage Git), tandis que les images CNG exécutent tous les autres composants sous forme de charges de travail conteneurisées. D'autres services dynamiques comme Postgres et Redis ont pris une telle ampleur que nous disposons d'équipes dédiées qui les gèrent séparément. Pour GitLab.com, ces systèmes ne sont pas déployés lors de nos procédures de déploiement automatique.\n\n\nNous disposons d'un pipeline planifié qui examine régulièrement `gitlab-org/gitlab` et recherche le commit le plus récent sur la branche par défaut avec un pipeline réussi (« vert »). Les pipelines verts signalent que chaque composant de GitLab a réussi sa suite de tests complète. Nous créons ensuite une **branche déployée automatiquement** à partir de ce commit.\n\n\nUne séquence d'événements est déclenchée : nous devons construire ce paquet et tous les composants qui font partie de notre monolithe. Un autre pipeline planifié sélectionne le dernier paquet construit et initie le pipeline de déploiement, ce qui ressemble à ceci :\n\n```mermaid\n  graph LR\n      A[Créer une branche] --> B[Build]\n      B --> C[Choisir le paquet construit]\n      C --> D[Démarrer le pipeline de déploiement]\n```\n\nLe build prend un certain temps et, étant donné que les déploiements peuvent varier en raison de diverses circonstances, nous choisissons le dernier build à déployer. Techniquement, nous construisons plus de versions de GitLab pour GitLab.com que nous n'en déploierons jamais. Cela nous permet de toujours disposer d'un paquet prêt à être utilisé, ce qui nous rapproche le plus possible d'un produit entièrement livré en continu pour GitLab.com.\n\n\n### Validation basée sur l'environnement et stratégie canari\n\nL'assurance qualité (QA) ne constitue pas ici une simple réflexion après coup : elle est intégrée à chaque couche, du développement au déploiement. Notre processus QA exploite des suites de tests automatisées qui incluent des tests unitaires, des tests d'intégration et des tests de bout en bout qui simulent les interactions réelles des utilisateurs avec les fonctionnalités de GitLab. Mais plus important encore pour notre pipeline de déploiement, notre processus QA fonctionne en synergie avec notre stratégie canari via une validation basée sur l'environnement .\n\n\nDans le cadre de notre approche de validation, nous exploitons les [déploiements canari](https://docs.gitlab.com/user/project/canary_deployments/) natifs de GitLab. Ces derniers permettent une validation contrôlée des modifications avec une exposition limitée au trafic avant le déploiement complet en production. Environ 5 % de l'ensemble du trafic passe par [l'étape canari](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage). Cette approche augmente la complexité des migrations de base de données, mais des étapes canari réussies garantissent le déploiement d'un produit fiable de manière transparente.\n\nLes fonctionnalités de déploiement canari que vous utilisez dans GitLab ont été affinées grâce à la gestion de l'un des scénarios de déploiement les plus complexes en production. Lorsque vous implémentez des déploiements canari pour vos applications, vous utilisez des modèles éprouvés à très grande échelle.\nNotre processus de déploiement suit une stratégie de déploiement progressif :\n1. **Préproduction canari :** environnement de validation initial\n2. **Production canari :** trafic de production limité\n3. **Préproduction environnement principal :** déploiement complet de l'environnement de préproduction\n4. **Production environnement principal :** déploiement complet en production\n```mermaid\n  graph TD\n      C[Déploiement préproduction canari]\n      C --> D[QA – smoke tests étape environnement principal]\n      C --> E[QA – smoke tests étape canari]\n      D --> F\n      E --> F{Tests réussis ?}\n      F -->|Oui| G[Déploiement production canari]\n      G --> S[QA – smoke tests étape environnement principal]\n      G --> T[QA – smoke tests étape canari]\n      F -->|Non| H[Création de ticket]\n      H --> K[Correction et rétroportage]\n      K --> C\n\n      S --> M[Surveillance trafic canari]\n      T --> M[Période de stabilisation surveillance trafic canari]\n      M --> U[Vérifications de sécurité production]\n      U --> N[Préproduction environnement principal]\n      N --> V[Production environnement principal]\n```\nNotre validation QA intervient à plusieurs points de contrôle tout au long de ce processus de déploiement progressif : après chaque déploiement canari, puis de nouveau après les migrations post-déploiement. Cette approche multi-couches garantit que chaque phase de notre stratégie de déploiement dispose de son propre filet de sécurité. Vous pouvez en apprendre davantage sur [l'approche de test complète de GitLab](https://handbook.gitlab.com/handbook/engineering/testing/) dans notre handbook.\n\n## Pipeline de déploiement\n\nVoici les défis que nous relevons avec notre pipeline de déploiement.\n\n### Considérations relatives à l'architecture technique\n\nGitLab.com représente une complexité de déploiement réelle à grande échelle. En tant que plus grande instance GitLab connue, les déploiements utilisent notre chart Helm GitLab officiel et le paquet Linux officiel, soit les mêmes artefacts que nos clients utilisent. Vous pouvez en apprendre davantage sur [l'architecture de GitLab.com](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture) dans notre manuel. Cette approche hybride signifie que notre pipeline de déploiement doit gérer intelligemment à la fois les services conteneurisés et les services Linux traditionnels au sein du même cycle de déploiement.\n\n**Utilisation de nos fonctionnalités à grande échelle (dogfooding) :** nous déployons en utilisant les mêmes procédures que nous documentons pour les [mises à niveau sans temps d’arrêt](https://docs.gitlab.com/update/zero_downtime/). Si certaines fonctionnalités ne fonctionnent pas correctement pour nous, nous ne les recommandons pas à nos clients. Cette contrainte que nous nous imposons stimule l'amélioration continue de nos outils de déploiement.\n\nLes étapes suivantes sont exécutées pour toutes les mises à niveau d'environnement et d'étape :\n```mermaid\n  graph LR\n      a[Préparation] --> c[Migrations régulières – étape canari uniquement]\n      a --> f[Actifs – étape canari uniquement]\n      c --> d[Gitaly]\n      d --> k8s\n\n      subgraph subGraph0[\"Charges de travail MV\"]\n        d[\"Gitaly\"]\n      end\n\n      subgraph subGraph1[\"Charges de travail Kubernetes\"]\n        k8s[\"k8s\"]\n      end\n\n      subgraph fleet[\"Flotte\"]\n        subGraph0\n        subGraph1\n      end\n```\n\n**Détails des étapes :**\n\n\n- **Préparation :** cette étape valide la préparation du déploiement et effectue des vérifications de pré-déploiement.\n\n- **Migrations :** cette étape exécute les migrations régulières de base de données, uniquement pendant l'étape canari. Étant donné que les étapes canari et environnement principal partagent la même base de données, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie, ce qui signifie qu'il n'est plus nécessaire de répéter ces tâches.\n\n- **Actifs :** nous exploitons un bucket GCS pour tous les actifs statiques. Si de nouveaux actifs sont créés, nous les importons vers notre bucket de sorte qu'ils soient immédiatement disponibles pour notre étape canari. Comme nous exploitons WebPack pour les actifs et utilisons correctement les SHA dans le nommage de nos actifs, nous pouvons être sûrs que nous n'écrasons pas un actif plus ancien. Par conséquent, les anciens actifs restent disponibles pour les déploiements plus anciens et les nouveaux actifs sont immédiatement disponibles lorsque l'étape canari commence son déploiement. Cela se produit uniquement pendant le déploiement de l'étape canari. Étant donné que l'étape canari et l'étape environnement principal partagent le même stockage d'actifs, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie.\n\n- **Gitaly :** cette étape met à jour la couche de stockage de la machine virtuelle Gitaly via notre paquet Linux Omnibus sur chaque nœud Gitaly. Ce service est unique car nous [le regroupons avec `git`](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/git-execution-environments.md). Par conséquent, nous devons garantir que ce service soit capable de procéder à des mises à niveau atomiques. Nous exploitons un [encapsuleur autour de Gitaly](https://gitlab.com/gitlab-org/gitaly/-/tree/master/cmd/gitaly-wrapper), qui nous permet d'installer une version plus récente de Gitaly et d'utiliser la bibliothèque [`tableflip`](https://github.com/cloudflare/tableflip) afin de faire pivoter proprement le Gitaly en cours d'exécution, et de garantir la haute disponibilité de ce service sur chacune de nos instances.\n\n- **[Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\") :** déploie les composants GitLab conteneurisés via notre chart Helm. Notez que nous déployons sur de nombreux clusters répartis sur plusieurs zones pour des questions de redondance, ces étapes sont donc généralement divisées en leurs propres étapes afin de minimiser les dommages et de nous permettent d'arrêter un déploiement en cours si des problèmes critiques sont détectés.\n\n\n### Compatibilité multi-versions : le défi caché\n\n\nÀ la lecture de nos processus, vous remarquerez qu'il existe une période pendant laquelle notre schéma de base de données est en avance sur le code que l'étape environnement principal connaît. Cette situation se produit parce que l'étape canari a déjà déployé le nouveau code et exécute des migrations régulières de base de données, mais l'étape environnement principal exécute toujours la version précédente du code qui ne connaît pas encore ces nouvelles modifications de base de données.\n\n**Exemple concret :** imaginons que nous ajoutons un nouveau champ `merge_readiness` aux merge requests. Pendant le déploiement, certains serveurs exécutent du code qui s'attend à ce champ, tandis que d'autres ignorent son existence. Si nous gérons mal cette situation, GitLab.com sera inutilisable pour des millions d'utilisateurs. Si nous la gérons bien, personne ne remarquera quoi que ce soit.\n\nCette situation se produit également avec la plupart des autres services. Par exemple, si un client envoie plusieurs requêtes, il est possible que l'une d'entre elles aboutisse dans notre étape canari ; d'autres requêtes pourraient être dirigées vers l'étape environnement principal. Ce n'est pas très différent d'un déploiement, car il faut un temps considérable pour parcourir les quelques milliers de pods qui exécutent nos services.\n\n\nÀ quelques exceptions près, la grande majorité de nos services exécutera une version légèrement plus récente de ce composant dans l'étape canari pendant une certaine période. Dans un sens, ces scénarios sont tous des états transitoires. Mais ils peuvent souvent persister pendant plusieurs heures ou jours dans un environnement de production actif. Par conséquent, nous devons les traiter avec le même soin que les états permanents. Pendant tout déploiement, plusieurs versions de GitLab s'exécutent simultanément, et elles doivent toutes cohabiter harmonieusement.\n\n## Opérations de base de données\n\nLes migrations de base de données présentent un défi unique dans notre modèle de déploiement canari. Nous avons besoin de modifier le schéma afin de prendre en charge les nouvelles fonctionnalités et de maintenir notre capacité à effectuer un retour à la version précédente si des problèmes surviennent. Notre solution implique une séparation minutieuse des préoccupations :\n\n- **Migrations régulières :** exécutées pendant l'étape canari, conçues pour être rétrocompatibles, constituées uniquement de modifications réversibles.\n\n- **Migrations post-déploiement :** les migrations « point de non-retour » qui se produisent uniquement après plusieurs déploiements réussis.\n\n\nLes modifications de base de données sont gérées avec précision et selon des procédures de validation approfondies :\n\n```mermaid\n  graph LR\n      A[Migrations régulières] --> B[Déploiement étape canari]\n      B --> C[Déploiement étape environnement principal]\n      C --> D[Migrations post-déploiement]\n\n```\n### Migrations post-déploiement\n\n\nLes déploiements GitLab impliquent de nombreux composants. La mise à jour de GitLab n'est pas atomique, c'est pourquoi de nombreux composants doivent être rétrocompatibles.\n\n\nLes migrations post-déploiement contiennent souvent des modifications qui ne peuvent pas être facilement annulées, comme les transformations de données, les suppressions de colonnes ou les modifications structurelles qui entraîneraient une rupture dans les versions de code plus anciennes. En les exécutant _après_ plusieurs déploiements réussis, nous garantissons les aspects suivants :\n\n\n1. **Le nouveau code est stable** et il est peu probable que nous ayons besoin de devoir retourner à la version précédente.\n\n2. **Les caractéristiques de performance** sont bien comprises en production.\n\n3. **Tous les cas marginaux** ont été découverts et traités.\n\n4. **Le rayon d'impact** est minimisé en cas de problème.\n\n\nCette approche offre un équilibre optimal entre un déploiement rapide des fonctionnalités via les releases canari et des capacités de retour à la version précédente jusqu'à ce que nous ayons suffisamment confiance dans la stabilité du déploiement.\n\n\n**Modèle étendre-migrer-réduire :** nos modifications de compatibilité de base de données, frontend et application suivent une approche en trois phases soigneusement orchestrée.\n\n\n1. **Étendre :** ajouter de nouvelles structures (colonnes, index) tout en gardant les anciennes fonctionnelles.\n\n2. **Migrer :** déployer le nouveau code d'application qui utilise les nouvelles structures.\n\n3. **Réduire :** supprimer les anciennes structures dans les migrations post-déploiement une fois que tout est stable.\n\n**Exemple concret :** lors de l'ajout d'une nouvelle colonne `merge_readiness` aux merge requests :\n\n1. **Étendre :** ajouter la nouvelle colonne avec une valeur par défaut ; le code existant l'ignore.\n\n2. **Migrer :** déployer le code qui lit et écrit dans la nouvelle colonne tout en prenant en charge l'ancienne approche.\n\n3. **Réduire :** après plusieurs déploiements réussis, supprimer l'ancienne colonne dans une migration post-déploiement\n\nToutes les opérations de base de données, le code d'application, le code frontend et bien d'autres, sont soumis à un ensemble de directives que les équipes d’ingénieries doivent respecter, que vous pouvez consulter dans notre [documentation sur la compatibilité multi-versions](https://docs.gitlab.com/development/multi_version_compatibility/).\n\n\n## Résultats et impact\n\nNotre infrastructure de déploiement offre des avantages mesurables :\n\n**Pour GitLab**\n\n* Jusqu'à 12 déploiements quotidiens sur GitLab.com\n* Déploiements sans temps d’arrêt au service de millions de développeurs\n* Application de correctifs de sécurité en production en quelques heures au lieu de plusieurs jours\n* Nouvelles fonctionnalités validées en production à grande échelle avant la disponibilité générale\n\n**Pour nos clients**\n\n* Modèles de déploiement éprouvés que vous pouvez adopter pour vos propres applications\n* Fonctionnalités testées en conditions réelles sur la plus grande instance GitLab au monde avant d'atteindre votre environnement\n* Documentation qui reflète les pratiques de production réelles, et non des bonnes pratiques théoriques\n* Fiabilité des procédures de mise à niveau recommandées par GitLab à toute échelle\n\n## Points clés pour les équipes d'ingénierie\n\nLe pipeline de déploiement de GitLab représente un système sophistiqué qui met en jeu la vélocité de déploiement et la fiabilité opérationnelle. Le modèle de déploiement progressif, l'intégration complète des tests et les capacités robustes de retour à la version précédente fournissent une base pour une livraison logicielle fiable à grande échelle.\n\n\nLes équipes d'ingénierie qui implémentent des systèmes similaires doivent avoir les points clés suivants en tête :\n\n\n- **Tests automatisés :** couverture de tests complète tout au long du pipeline de déploiement\n\n- **Déploiement progressif :** déploiements par étapes afin de minimiser les risques et permettre une récupération rapide\n\n- **Intégration de la surveillance :** observabilité complète à travers toutes les étapes de déploiement\n\n- **Réponse aux incidents :** capacités de détection et de résolution rapides pour les problèmes de déploiement\n\n\nL'architecture de GitLab démontre comment des systèmes CI/CD modernes peuvent gérer la complexité de déploiements à grande échelle tout en maintenant la vélocité requise pour un développement logiciel compétitif.\n\n\n## Note importante sur la portée\n\n\nCet article couvre spécifiquement le pipeline de déploiement pour les services qui font partie du **paquet GitLab Omnibus** et du **chart Helm**, soit le monolithe GitLab principal et ses composants étroitement intégrés.\n\n\nCependant, le paysage d'infrastructure de GitLab s'étend au-delà de ce qui est décrit ici. D'autres services, notamment nos **services d'IA** et les services qui pourraient faire partie d'une **étude de faisabilité**, suivent une approche de déploiement différente au moyen de notre plateforme interne Runway.\n\n\nSi vous travaillez avec ces services ou souhaitez en savoir plus, vous pouvez obtenir plus d'informations dans notre [documentation dédiée à Runway](https://docs.runway.gitlab.com).\n\n\nD'autres offres, telles que [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/ \"GitLab Dedicated\"), sont déployées de manière plus alignée avec ce que nous attendons que les clients soient capables de réaliser eux-mêmes au moyen de **GitLab Environment Toolkit**. Si vous souhaitez en savoir plus, consultez le [projet GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit).\n\n\nLes stratégies de déploiement, les considérations architecturales et les complexités de pipeline décrites dans cet article représentent l'approche éprouvée que nous utilisons pour notre plateforme principale, mais comme toute grande organisation d'ingénierie, nous disposons de plusieurs stratégies de déploiement adaptées aux différents types de services et niveaux de maturité.\n\nPour plus de documentation sur le déploiement automatique et nos procédures, vous pouvez consulter les liens ci-dessous :\n- [Déploiements d'ingénierie](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n- [Documentation sur les procédures de release](https://gitlab-org.gitlab.io/release/docs/)","Plongez au cœur du pipeline de déploiement de GitLab.com, des déploiements progressifs, des stratégies canari aux migrations de base de données en passant par la compatibilité multi-versions.","Comment déployer la plus grande instance GitLab 12 fois par jour",{"featured":36,"template":15,"slug":772},"continuously-deploying-the-largest-gitlab-instance",{"content":774,"config":786},{"tags":775,"category":13,"body":778,"date":779,"title":780,"description":781,"heroImage":782,"authors":783},[776,23,116,777],"tutorial","migration","La migration d'Azure DevOps vers GitLab peut sembler complexe, mais avec la bonne approche et les bons outils, le processus sera fluide et efficace. Ce guide détaille toutes les étapes pour migrer avec succès vos projets, dépôts et pipelines d'Azure DevOps vers GitLab.\n\n## Vue d'ensemble\n\nGitLab propose à la fois [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintenu par les [Services professionnels de GitLab](https://about.gitlab.com/fr-fr/professional-services/)) et [une importation intégrée des dépôts Git](https://docs.gitlab.com/user/project/import/repo_by_url/) pour migrer des projets depuis Azure DevOps (ADO). Ces options prennent en charge la migration dépôt par dépôt ou de façon groupée et préservent l'historique des commits [git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), les branches et les tags. Elles prennent également en charge des éléments supplémentaires tels que les [wikis](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"GitLab Wiki\"), les éléments de travail, les [variables CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/), les images de conteneurs, les paquets, les pipelines et bien plus encore ([matrice de fonctionnalités](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)). Utilisez ce guide pour planifier et exécuter votre migration, puis accomplir les tâches de suivi post-migration.\n\nLes entreprises qui migrent d'Azure DevOps vers GitLab suivent généralement une approche en plusieurs étapes :\n\n* Elles migrent les dépôts d'Azure DevOps vers GitLab à l'aide de Congregate ou de la migration de dépôt intégrée à GitLab.\n* Elles migrent les pipelines d'Azure Pipelines vers GitLab CI/CD.\n* Elles migrent les éléments restants tels que les tableaux, les éléments de travail et les artefacts vers les tickets, registres de paquets et de conteneurs GitLab.\n\nPhases de migration principales :\n\n\n```mermaid\ngraph LR\n    subgraph Prérequis\n        direction TB\n        A[\"Configurer le fournisseur d'identité (IdP)\u003Cbr/>et provisionner les utilisateurs\"]\n        A --> B[\"Configurer les runners et\u003Cbr/>les intégrations tierces\"]\n        B --> I[\"Former les utilisateurs et\u003Cbr/>gérer le changement\"]\n    end\n    \n    subgraph MigrationPhase[\"Phase de migration\"]\n        direction TB\n        C[\"Migrer le code source\"]\n        C --> D[\"Préserver les contributions et\u003Cbr/>l'historique du format\"]\n        D --> E[\"Migrer les éléments de travail,\u003Cbr/>mapper vers \u003Ca href=\"https://docs.gitlab.com/topics/plan_and_track/\">GitLab Plan\u003Cbr/>et suivre le travail\"]\n    end\n    \n    subgraph PostMigration[\"Étapes post-migration\"]\n        direction TB\n        F[\"Créer ou traduire les\u003Cbr/>pipelines ADO vers GitLab CI\"]\n        F --> G[\"Migrer les autres actifs,\u003Cbr/>paquets et images de conteneurs\"]\n        G --> H[\"Introduire des améliorations SDLC et de \u003Ca href=\"https://docs.gitlab.com/user/application_security/secure_your_application/\">sécurité\u003C/a>\u003Cbr/>\"]\n    end\n    \n    Prérequis --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n\n## Planifiez votre migration\n\n**Pour planifier votre migration, posez-vous ces questions :**\n\n* Dans quels délais devons-nous achever la migration ?\n* Comprenons-nous ce qui sera migré ?\n* Qui exécutera la migration ?\n* Quelle structure organisationnelle souhaitons-nous mettre en place dans GitLab ?\n* Existe-t-il des contraintes, limitations ou pièges à prendre en compte ?\n\nDéterminez votre calendrier, car il dictera en grande partie votre approche de migration. Identifiez des spécialistes ou des groupes familiarisés avec les plateformes Azure DevOps et GitLab (comme les « Early adopters ») pour faciliter l'adoption et fournir des conseils.\n\n**Faites l'inventaire de ce que vous devez migrer :**\n\n* Le nombre de dépôts, de pull requests et de contributeurs\n* Le nombre et la complexité des éléments de travail et des pipelines\n* Les tailles de dépôts et les relations de dépendance\n* Les intégrations critiques et les exigences relatives aux runners (pools d'agents dotés de capacités spécifiques)\n\nUtilisez l'outil [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops) des Services professionnels de GitLab pour produire un inventaire complet de toute votre organisation Azure DevOps avec les dépôts, le nombre de pull requests, les listes de contributeurs, le nombre de pipelines, les éléments de travail, les variables CI/CD et bien plus encore. Si vous travaillez avec l'équipe des Services professionnels de GitLab, partagez ce rapport avec votre responsable de mission ou votre architecte technique pour faciliter la planification de la migration.\n\nLe calendrier de migration est principalement déterminé par le nombre de pull requests, la taille des dépôts et le volume de contributions (par exemple, les commentaires dans les pull requests, les éléments de travail, etc.). 1 000 petits dépôts avec un nombre limité de pull requests et de contributeurs peuvent migrer beaucoup plus rapidement qu'un ensemble plus restreint de dépôts contenant des dizaines de milliers de pull requests et des milliers de contributeurs. Utilisez vos données d'inventaire pour estimer l'effort et planifier des tests avant de procéder aux migrations de production.\n\nComparez l'inventaire avec le calendrier souhaité et décidez si vous allez migrer tous les dépôts à la fois ou par lots. Si les équipes ne peuvent pas migrer simultanément, organisez les migrations par lots et échelonnez-les pour vous aligner sur les calendriers des équipes. Par exemple, lors des missions des Services professionnels, nous organisons des migrations par vagues de 200 à 300 projets pour limiter la complexité et respecter les limites de débit des API, à la fois dans [GitLab](https://docs.gitlab.com/security/rate_limits/) et [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops).\n\nL'[outil d'importation de dépôt intégré](https://docs.gitlab.com/user/project/import/repo_by_url/) de GitLab migre les dépôts Git (commits, branches et tags) un par un. Congregate est conçu pour préserver les pull requests (appelées merge requests dans GitLab), les commentaires et les métadonnées associées lorsque cela est possible ; l'importation simple de dépôt intégrée se concentre uniquement sur les données Git (historique, branches et tags).\n\n**Éléments nécessitant généralement une migration distincte ou une recréation manuelle :**\n\n* Pipelines Azure : créez des pipelines GitLab CI/CD équivalents (consultez la [documentation YAML CI/CD](https://docs.gitlab.com/ci/yaml/) et/ou les [composants CI/CD](https://docs.gitlab.com/ci/components/)). Vous pouvez également envisager d'utiliser la conversion de pipelines basée sur l'IA disponible dans Congregate.\n* Éléments de travail et tableaux : mappez-les vers les tickets, epics et tableaux de tickets de GitLab.\n* Artefacts, images de conteneurs (ACR) : migrez-les vers le registre de paquets ou le registre de conteneurs de GitLab.\n* Hooks de service et intégrations externes : recréez-les dans GitLab.\n* Les [modèles de permissions](https://docs.gitlab.com/user/permissions/) diffèrent entre ADO et GitLab ; examinez et planifiez le mappage des permissions plutôt que de supposer une préservation exacte.\n\nExaminez ce que chaque outil (Congregate vs importation intégrée) va migrer et choisissez celui qui correspond à vos besoins. Dressez une liste de toutes les données ou intégrations qui doivent être migrées ou recréées manuellement.\n\n**Qui exécutera la migration ?**\n\nLes migrations sont généralement exécutées par un propriétaire de groupe GitLab ou un administrateur d'instance, ou par une personne désignée ayant obtenu les permissions nécessaires relatives au groupe/projet de destination. Congregate et les API d'importation GitLab nécessitent des tokens d'authentification valides pour Azure DevOps et GitLab.\n\n* Décidez si un propriétaire/administrateur de groupe effectuera les migrations ou si vous accorderez un accès délégué à une équipe/personne spécifique.\n* Assurez-vous que la personne dédiée à la migration a correctement configuré les tokens d'accès personnels (Azure DevOps et GitLab) avec les portées requises par votre outil de migration choisi (par exemple, les portées api/read_repository et toute exigence spécifique à l'outil).\n* Testez les tokens et les permissions avec une petite migration pilote.\n\n**Remarque :** Congregate exploite la fonctionnalité d'importation basée sur des fichiers pour les migrations ADO et nécessite des permissions d'administrateur d'instance pour s'exécuter ([consultez notre documentation](https://docs.gitlab.com/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)). Si vous migrez vers GitLab.com, envisagez de faire appel aux Services professionnels. Pour plus d'informations, consultez leur [catalogue complet](https://about.gitlab.com/professional-services/catalog/). Un compte non-administrateur ne peut pas préserver l'attribution des contributions !\n\n**Quelle structure organisationnelle souhaitons-nous dans GitLab ?**\n\nBien qu'il soit possible de mapper directement la structure ADO vers la structure GitLab, il est recommandé de rationaliser et de simplifier la structure pendant la migration. Réfléchissez à la façon dont les équipes travailleront dans GitLab et concevez la structure de façon à faciliter la collaboration et la gestion des accès. Voici un exemple de mappage de la structure ADO vers la structure GitLab :\n\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"Groupe principal\"]\n        B[\"Sous-groupe (facultatif)\"]\n        C[\"Projets\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"Organisations\"]\n        G[\"Projets\"]\n        H[\"Dépôts\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\n\nApproche recommandée :\n\n* Mappez chaque organisation ADO à un groupe GitLab (ou un petit ensemble de groupes), et non à de nombreux petits groupes. Évitez de créer un groupe GitLab pour chaque projet d'équipe ADO et utilisez la migration comme une opportunité de rationaliser votre structure GitLab.\n* Utilisez des sous-groupes et des permissions au niveau du projet pour regrouper les dépôts associés.\n* Gérez l'accès à des ensembles de projets en utilisant les groupes et l'appartenance aux groupes (groupes et sous-groupes) de GitLab plutôt qu'un groupe par projet d'équipe.\n* Examinez les [permissions](https://docs.gitlab.com/user/permissions/) de GitLab et utilisez les [liens de groupe SAML](https://docs.gitlab.com/user/group/saml_sso/group_sync/) pour mettre en œuvre un modèle de contrôle d'accès basé sur les rôles (RBAC) d'entreprise pour votre instance GitLab (ou un espace de nommage GitLab.com).\n\n**Tableaux ADO et éléments de travail : état de la migration**\n\nIl est important de comprendre comment les éléments de travail migrent d'ADO vers GitLab Plan (tickets, epics et tableaux).\n\n* Les tableaux et éléments de travail ADO sont mappés vers les tickets, epics et tableaux de tickets de GitLab. Planifiez comment vos workflows et configurations de tableaux seront migrés.\n* Les epics et fonctionnalités ADO deviennent des epics GitLab.\n* Les autres types d'éléments de travail (user stories, tâches, bogues) deviennent des tickets au niveau du projet.\n* La plupart des champs standard sont préservés ; certains champs personnalisés sélectionnés peuvent être migrés lorsqu'ils sont pris en charge.\n* Les relations parent-enfant sont conservées afin que les epics référencent tous les tickets associés.\n* Les liens vers les pull requests sont convertis en liens de merge requests pour maintenir la traçabilité du développement.\n\nExemple d'une migration d'un élément de travail individuel vers un ticket GitLab, avec conservation des champs et relations :\n\n![Exemple d'une migration d'un élément de travail individuel vers un ticket GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nConseils pour la migration par lots :\n\n* Si vous devez exécuter des migrations par lots, utilisez votre nouvelle structure de groupe/sous-groupe pour définir les lots (par exemple, par organisation ADO ou par domaine produit).\n* Utilisez les rapports d'inventaire pour orienter la sélection des lots et testez chaque lot avec une migration pilote avant d'effectuer la migration complète.\n\n**Migration des pipelines**\n\nCongregate a [récemment introduit](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) une conversion basée sur l'IA pour les pipelines YAML multi-étapes d'Azure DevOps vers GitLab CI/CD. Cette conversion automatisée fonctionne avant tout pour les pipelines simples avec un fichier unique et est conçue pour fournir un point de départ fonctionnel plutôt qu'un fichier `.gitlab-ci.yml` prêt pour la production. L'outil génère un pipeline GitLab équivalent sur le plan fonctionnel que vous pouvez ensuite affiner et optimiser selon vos besoins.\n\n*  Conversion automatique des pipelines YAML Azure au format `.gitlab-ci.yml`\n* Mieux adapté pour les configurations de pipeline simples avec un fichier unique\n* Fichier passe-partout fourni pour accélérer la migration, pas un artefact de production final\n* Revue et ajustement requis pour les scénarios complexes, les tâches personnalisées ou les exigences de l'entreprise\n* Pas de prise en charge de pipelines de version classiques Azure DevOps, [conversion en YAML multi-étapes](https://learn.microsoft.com/fr-fr/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops) nécessaire\n\nLes propriétaires de dépôts doivent consulter la [documentation GitLab CI/CD](https://docs.gitlab.com/ci/) pour optimiser et améliorer davantage leurs pipelines après la conversion initiale.\n\nExemple de pipelines convertis :\n\n\n```yml \n\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n\n```\n\n```yaml\n\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n\n```\n\n\n**Liste de contrôle finale :**\n\n* Décidez du calendrier et de la stratégie par lots.\n* Produisez un inventaire complet des dépôts, pull requests et contributeurs.\n* Choisissez Congregate ou l'importation intégrée en fonction de la portée (pull requests  et métadonnées vs données Git uniquement).\n* Décidez qui exécutera les migrations et assurez-vous que les tokens/permissions sont configurés.\n* Identifiez les éléments qui doivent être migrés séparément (pipelines, éléments de travail, artefacts et hooks) et planifiez ces migrations.\n* Effectuez des migrations pilotes, validez les résultats, puis passez à la migration complète selon votre calendrier.\n\n## Exécutez vos migrations\n\nUne fois la planification terminée, exécutez les migrations par étapes, en commençant par des migrations d'essai, qui permettent de faire remonter les problèmes spécifiques à l'organisation tôt et de mesurer la durée, de valider les résultats et d'affiner votre approche avant la production.\n\nUtilisez les migrations d'essai pour valider les éléments suivants :\n\n* Succès de la migration d'un dépôt donné et des éléments associés (historique, branches, tags ; ainsi que les merge requests/commentaires si vous utilisez Congregate)\n* Utilisation immédiate de la destination (permissions, runners, variables CI/CD, intégrations)\n* Durée de chaque lot (afin de définir les calendriers et les attentes des parties prenantes)\n\nConseils concernant les temps d'arrêt :\n\n* L'importation Git intégrée de GitLab et Congregate ne nécessitent pas intrinsèquement de temps d'arrêt.\n* Pour les vagues de production, gelez les modifications dans ADO (protections de branches ou lecture seule) pour éviter les commits manqués, les mises à jour de pull requests ou les éléments de travail créés en cours de migration.\n* Les essais n'ont pas besoin d'être gelés et peuvent être exécutés à tout moment.\n\nConseils pour la migration par lots :\n\n* Exécutez des lots d'essai consécutifs pour raccourcir le temps écoulé ; laissez les équipes valider les résultats de manière asynchrone.\n* Utilisez votre structure de groupe/sous-groupe planifiée pour définir les lots et respectez les limites de débit des API.\n\nÉtapes recommandées :\n\n1. Créez une destination de test dans GitLab pour les essais :\n\n* GitLab.com : créez un groupe/espace de nommage dédié (par exemple, my-org-sandbox).\n* Instance auto-gérée : créez un groupe de niveau supérieur ou une instance de test distincte si nécessaire.\n\n2. Préparez l'authentification :\n\n* PAT Azure DevOps avec les portées requises.\n* Token d'accès personnel GitLab avec api et read_repository (plus accès administrateur pour les importations basées sur des fichiers utilisées par Congregate).\n\n3. Exécutez des migrations d'essai :\n\n* Dépôts uniquement : utilisez l'importation intégrée de GitLab (dépôt par URL).\n* Dépôts + pull requests/merge requests et actifs supplémentaires : utilisez Congregate.\n\n4. Suivi post-essai :\n\n* Vérifiez l'historique du dépôt, les branches, les tags ; les merge requests (si elles ont été migrées), les tickets/epics (s'ils ont été migrées), les labels et les relations.\n* Vérifiez les permissions/rôles, les branches protégées, les approbations requises, les runners/tags, les variables/secrets, les intégrations/webhooks.\n* Validez les pipelines (`.gitlab-ci.yml`) ou les pipelines convertis le cas échéant.\n\n5. Demandez aux utilisateurs de valider la fonctionnalité et la fidélité des données.\n6. Résolvez les problèmes découverts lors des essais et mettez à jour vos runbooks.\n7. Réseau et sécurité :\n\n* Si votre destination utilise des listes d'IP autorisées, ajoutez les IP de votre hôte de migration et tous les runners/intégrations requis afin de garantir la réussite des importations.\n\n8. Exécutez les migrations de production par vagues :\n\n* Appliquez des gels de modifications dans ADO pendant chaque vague.\n* Surveillez la progression et les logs ; réessayez ou ajustez les tailles de lots si vous atteignez les limites de débit.\n\n9. Facultatif : supprimez le groupe de l'environnement sandbox ou archivez-le après avoir terminé.\n\n\u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n    \u003C/figure>\n\n## Références terminologiques pour GitLab et Azure DevOps\n\n| GitLab                                                           | Azure DevOps                                 | Similitudes et différences clés                                                                                                                                          |\n| ---------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Groupe                                                            | Organisation                                 | Espace de nommage principal, adhésion, politiques. Une organisation ADO contient des projets ; un groupe GitLab contient des sous-groupes et des projets.                                                   |\n| Groupe ou sous-groupe                                                | Projet                                      | Conteneur logique, limite de permissions. Un projet ADO contient de nombreux dépôts ; les groupes/sous-groupes GitLab contiennent de nombreux projets.                                                |\n| Projet (inclut un dépôt Git)                                    | Dépôt (à l'intérieur d'un projet)                | Historique Git, branches, tags. Dans GitLab, un « projet » est le dépôt plus les tickets, CI/CD, wiki, etc. Un dépôt par projet.                                                  |\n| Merge Request (MR)                                               | Pull Request (PR)                            | Revue de code, discussions, approbations. Les règles des MR incluent les approbations, les pipelines requis, les propriétaires de code.                                                                     |\n| Branches protégées, règles d'approbation des MR, vérifications de statut             | Politiques des branches                              | Imposent des revues et des vérifications. GitLab combine les protections + les règles d'approbation + les vérifications de statut requises.                                                                    |\n| GitLab CI/CD                                                     | Pipelines Azure                             | Pipelines YAML, étapes/jobs, logs. ADO a également des pipelines UI classiques ; GitLab se concentre sur .gitlab-ci.yml.                                                               |\n| .gitlab-ci.yml                                                   | azure-pipelines.yml                          | Définit les étapes/jobs/déclencheurs. La syntaxe/les fonctionnalités diffèrent ; map job, variables, artefacts et déclencheurs.                                                                   |\n| Runners (partagés/spécifiques)                                        | Agents / pools d'agents                         | Exécutent les jobs sur des machines/conteneurs. Ciblent via des demandes (ADO) ou tags (GitLab). L'enregistrement/la portée diffère.                                                         |\n| Variables CI/CD (projet/groupe/instance), protégées/masquées       | Variables de pipeline, groupes de variables, bibliothèque | Transmettent la configuration/les secrets aux jobs. GitLab prend en charge l'héritage de groupe et les flags de masquage/protection.                                                                          |\n| Intégrations, variables CI/CD, clés de déploiement                       | Connexions de service                          | Authentification externe vers les services/clouds. Map vers les intégrations ou les variables ; des assistants spécifiques au cloud sont disponibles.                                                                 |\n| Environnements et déploiements (environnements protégés)                      | Environnements (avec approbations)                | Suivent les cibles/l'historique de déploiement. Approbations via environnements protégés et jobs manuels dans GitLab.                                                                                 |\n| Versions (tag + notes)                                           | Versions (classiques ou pipelines)              | Notes/artefacts versionnés. La version GitLab est liée aux tags ; les déploiements sont suivis séparément.                                                                               |\n| Artefacts de job                                                    | Artefacts de pipeline                           | Inscrivent de manière permanente les sorties de job. La rétention/l'expiration sont configurées par job ou par projet.                                                                                                  |\n| Registre de paquets (NuGet/npm/Maven/PyPI/Composer, etc.)           | Artefacts Azure (NuGet/npm/Maven, etc.)      | Hébergement de paquets. L'authentification/l'espace de nommage diffère ; migrez par type de paquets.                                                                                                     |\n| Registre de conteneurs GitLab                                        | Registre de conteneurs Azure (ACR) ou autres     | Images OCI. GitLab fournit des registres par projet/groupe.                                                                                                             |\n| Tableaux de tickets                                                     | Tableaux                                       | Affichent les tâches dans des colonnes. Les tableaux GitLab sont pilotés par des labels ; plusieurs tableaux par projet/groupe.                                                                         |\n| Tickets (types/labels), epics                                     | Éléments de travail (user story/bogue/tâche)             | Suivent les unités de travail. Mappent les types/champs ADO vers les labels/champs personnalisés ; epics au niveau du groupe.                                                                              |\n| Epics, tickets parent/enfant                                       | Epics/fonctionnalités                               | Hiérarchie du travail. Le schéma diffère ; utilisation des epics + relations de tickets.                                                                                                   |\n| Jalons et itérations                                        | Chemins d'itération                              | Temps limité. Itérations GitLab (fonctionnalité de groupe) ou jalons par projet/groupe.                                                                                       |\n| Labels (labels à portée)                                           | Chemins de domaine                                   | Catégorisation/propriété. Remplacement des domaines hiérarchiques par des labels à portée.                                                                                              |\n| Wiki de projet/groupe                                               | Wiki de projet                                 | Wiki Markdown. Sauvegardes avec des dépôts dans les deux ; la mise en page/l'authentification diffère légèrement.                                                                                                  |\n| Rapports de test via CI, gestion des exigences/tests, intégrations  | Plans/cas/exécutions de test                        | QA des preuves/de la traçabilité. Pas de correspondance 1:1 avec les plans de test ADO ; utilisent souvent les rapports CI + tickets/exigences.                                                                     |\n| Rôles (propriétaire/chargé de maintenance/développeur/rapporteur/invité) + rôles personnalisés | Niveaux d'accès + permissions granulaires         | Contrôlent la lecture/l'écriture/l'administration. Les modèles diffèrent ; exploitation de l'héritage de groupe et des ressources protégées.                                                                          |\n| Webhooks                                                         | Hooks de service                                | Intégrations basées sur les événements. Les noms/charges utiles d'événements diffèrent ; reconfiguration des points de terminaison.                                                                                        |\n| Recherche avancée                                                  | Recherche de code                                  | Recherche dans le dépôt en texte intégral. GitLab Self-Managed peut nécessiter Elasticsearch/OpenSearch pour les fonctionnalités avancées.","2025-12-08","Migrer d'Azure DevOps vers GitLab :  le guide complet","Découvrez comment migrer d'Azure DevOps vers GitLab à l'aide des outils de migration des Services professionnels de GitLab, de la planification à l'exécution en passant par les tâches de suivi post-migration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[784,785],"Evgeny Rudinsky","Michael Leopard",{"featured":36,"template":15,"slug":787},"migration-from-azure-devops-to-gitlab",{"promotions":789},[790,804,815,827],{"id":791,"categories":792,"header":794,"text":795,"button":796,"image":801},"ai-modernization",[793],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":797,"config":798},"Get your AI maturity score",{"href":799,"dataGaName":800,"dataGaLocation":257},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":802},{"src":803},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":805,"categories":806,"header":807,"text":795,"button":808,"image":812},"devops-modernization",[762,587],"Are you just managing tools or shipping innovation?",{"text":809,"config":810},"Get your DevOps maturity score",{"href":811,"dataGaName":800,"dataGaLocation":257},"/assessments/devops-modernization-assessment/",{"config":813},{"src":814},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":816,"categories":817,"header":819,"text":795,"button":820,"image":824},"security-modernization",[818],"security","Are you trading speed for security?",{"text":821,"config":822},"Get your security maturity score",{"href":823,"dataGaName":800,"dataGaLocation":257},"/assessments/security-modernization-assessment/",{"config":825},{"src":826},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":828,"paths":829,"header":831,"text":832,"button":833,"image":838},"github-azure-migration",[787,830],"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":834,"config":835},"See how GitLab compares to GitHub",{"href":836,"dataGaName":837,"dataGaLocation":257},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":839},{"src":814},{"header":841,"blurb":842,"button":843,"secondaryButton":847},"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":51,"config":844},{"href":845,"dataGaName":54,"dataGaLocation":846},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":56,"config":848},{"href":58,"dataGaName":59,"dataGaLocation":846},1777934837012]