[{"data":1,"prerenderedAt":1208},["ShallowReactive",2],{"/fr-fr/blog/":3,"navigation-fr-fr":21,"banner-fr-fr":440,"footer-fr-fr":452,"blogCategories-fr-fr":664,"relatedBlogPosts-fr-fr":786,"maineFeaturedPost-fr-fr":1171,"recentFeaturedPosts-fr-fr":1176,"recentPosts-fr-fr":1192},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/fr-fr/blog","fr-fr",false,"",{"title":9,"description":10},"Blog","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:fr-fr:blog:index.yml","yaml","content","fr-fr/blog/index.yml","fr-fr/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":436,"_type":16,"title":437,"_source":17,"_file":438,"_stem":439,"_extension":20},"/shared/fr-fr/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":413,"duo":427},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/fr-fr/","gitlab logo","header",{"text":30,"config":31},"Commencer un essai gratuit",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Contacter l'équipe commerciale",{"href":37,"dataGaName":38,"dataGaLocation":28},"/fr-fr/sales/","sales",{"text":40,"config":41},"Connexion",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Plateforme",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":53,"config":54},"Découvrir notre plateforme",{"href":55,"dataGaName":48,"dataGaLocation":28},"/fr-fr/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":60,"config":61},"Découvrez GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":68,"config":69},"En savoir plus",{"href":70,"dataGaName":71,"dataGaLocation":28},"/fr-fr/why-gitlab/","why gitlab",{"title":73,"items":74},"Démarrer avec",[75,80,85],{"text":76,"config":77},"Ingénierie de plateforme",{"href":78,"dataGaName":79,"dataGaLocation":28},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Expérience développeur",{"href":83,"dataGaName":84,"dataGaLocation":28},"/fr-fr/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produit",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/fr-fr/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":113,"config":114},"Développement assisté par l'IA",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Gestion du code source",{"href":119,"dataGaLocation":28,"dataGaName":120},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Sécurité et conformité",{"href":130,"dataGaLocation":28,"dataGaName":137},"Security & Compliance",{"text":139,"config":140},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":141,"dataGaLocation":28,"dataGaName":142},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Conformité et gouvernance",{"href":146,"dataGaLocation":28,"dataGaName":147},"/fr-fr/solutions/continuous-software-compliance/","Compliance and governance",{"title":149,"link":150,"items":155},"Mesures",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Visibilité et mesures",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Gestion de la chaîne de valeur",{"href":163,"dataGaLocation":28,"dataGaName":164},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Données d'analyse et informations clés",{"href":168,"dataGaLocation":28,"dataGaName":169},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab pour",[173,178,183],{"text":174,"config":175},"Entreprises",{"href":176,"dataGaLocation":28,"dataGaName":177},"/fr-fr/enterprise/","enterprise",{"text":179,"config":180},"PME",{"href":181,"dataGaLocation":28,"dataGaName":182},"/fr-fr/small-business/","small business",{"text":184,"config":185},"Secteur public",{"href":186,"dataGaLocation":28,"dataGaName":187},"/fr-fr/solutions/public-sector/","public sector",{"text":189,"config":190},"Tarifs",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/fr-fr/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":285},"Ressources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Afficher toutes les ressources",{"href":200,"dataGaName":196,"dataGaLocation":28},"/fr-fr/resources/",[202,235,257],{"title":203,"items":204},"Premiers pas",[205,210,215,220,225,230],{"text":206,"config":207},"Installation",{"href":208,"dataGaName":209,"dataGaLocation":28},"/fr-fr/install/","install",{"text":211,"config":212},"Guides de démarrage rapide",{"href":213,"dataGaName":214,"dataGaLocation":28},"/fr-fr/get-started/","quick setup checklists",{"text":216,"config":217},"Apprentissage",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Documentation sur le produit",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Vidéos sur les bonnes pratiques",{"href":228,"dataGaName":229,"dataGaLocation":28},"/fr-fr/getting-started-videos/","best practice videos",{"text":231,"config":232},"Intégrations",{"href":233,"dataGaName":234,"dataGaLocation":28},"/fr-fr/integrations/","integrations",{"title":236,"items":237},"Découvrir",[238,243,247,252],{"text":239,"config":240},"Histoires de succès client",{"href":241,"dataGaName":242,"dataGaLocation":28},"/fr-fr/customers/","customer success stories",{"text":9,"config":244},{"href":245,"dataGaName":246,"dataGaLocation":28},"/fr-fr/blog/","blog",{"text":248,"config":249},"Travail à distance",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/fr-fr/teamops/","teamops",{"title":258,"items":259},"Connecter",[260,265,270,275,280],{"text":261,"config":262},"Services GitLab",{"href":263,"dataGaName":264,"dataGaLocation":28},"/fr-fr/services/","services",{"text":266,"config":267},"Communauté",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Événements",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partenaires",{"href":283,"dataGaName":284,"dataGaLocation":28},"/fr-fr/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":290,"config":291},"carte promo The Source",{"src":292},"/images/navigation/the-source-promo-card.svg",{"text":294,"config":295},"Lire les articles les plus récents",{"href":296,"dataGaName":297,"dataGaLocation":28},"/fr-fr/the-source/","the source",{"text":299,"config":300,"lists":302},"Société",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"À propos",{"href":308,"dataGaName":309,"dataGaLocation":28},"/fr-fr/company/","about",{"text":311,"config":312,"footerGa":315},"Emplois",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Leadership",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Équipe",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Manuel",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Relations avec les investisseurs",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Centre de confiance",{"href":341,"dataGaName":342,"dataGaLocation":28},"/fr-fr/security/","trust center",{"text":344,"config":345},"Centre pour la transparence de l'IA",{"href":346,"dataGaName":347,"dataGaLocation":28},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Presse",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Nous contacter",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Aide",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Portail clients GitLab",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Fermer",{"text":380,"link":381},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Suggestions",[389,392,397,399,404,409],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"Suggestions de code (IA)",{"href":395,"dataGaName":396,"dataGaLocation":385},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab sur AWS",{"href":402,"dataGaName":403,"dataGaLocation":385},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":405,"config":406},"GitLab sur Google Cloud ",{"href":407,"dataGaName":408,"dataGaLocation":385},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":410,"config":411},"Pourquoi utiliser GitLab ?",{"href":70,"dataGaName":412,"dataGaLocation":385},"Why GitLab?",{"freeTrial":414,"mobileIcon":419,"desktopIcon":424},{"text":415,"config":416},"Commencer votre essai gratuit",{"href":417,"dataGaName":33,"dataGaLocation":418},"https://gitlab.com/-/trials/new/","nav",{"altText":420,"config":421},"Icône GitLab",{"src":422,"dataGaName":423,"dataGaLocation":418},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":420,"config":425},{"src":426,"dataGaName":423,"dataGaLocation":418},"/images/brand/gitlab-logo-type.svg",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"En savoir plus sur GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":418},"gitlab duo",{"altText":420,"config":433},{"src":422,"dataGaName":423,"dataGaLocation":418},{"altText":420,"config":435},{"src":426,"dataGaName":423,"dataGaLocation":418},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":441,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":442,"button":443,"config":447,"_id":449,"_type":16,"_source":17,"_file":450,"_stem":451,"_extension":20},"/shared/fr-fr/banner","GitLab Duo Agent Platform est maintenant disponible en version bêta publique !",{"text":68,"config":444},{"href":445,"dataGaName":446,"dataGaLocation":28},"/gitlab-duo/agent-platform/","duo banner",{"layout":448},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":453,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":660,"_type":16,"title":661,"_source":17,"_file":662,"_stem":663,"_extension":20},"/shared/fr-fr/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":651},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":457,"config":458},"Afficher le code source de la page",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Modifier cette page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Veuillez contribuer",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,588,622],{"title":46,"links":479,"subMenu":484},[480],{"text":481,"config":482},"Plateforme DevSecOps",{"href":55,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":189,"links":486},[487,491,496],{"text":488,"config":489},"Voir les forfaits",{"href":191,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Pourquoi choisir GitLab Premium ?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/fr-fr/pricing/premium/","why premium",{"text":497,"config":498},"Pourquoi choisir GitLab Ultimate ?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/fr-fr/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"Transformation digitale",{"href":507,"dataGaName":508,"dataGaLocation":461},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":135,"config":510},{"href":130,"dataGaName":511,"dataGaLocation":461},"security & compliance",{"text":122,"config":513},{"href":105,"dataGaName":106,"dataGaLocation":461},{"text":515,"config":516},"Développement agile",{"href":517,"dataGaName":518,"dataGaLocation":461},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Transformation cloud",{"href":522,"dataGaName":523,"dataGaLocation":461},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":119,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":109,"config":529},{"href":111,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":161,"config":532},{"href":163,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/fr-fr/solutions/gitops/","gitops",{"text":174,"config":540},{"href":176,"dataGaName":177,"dataGaLocation":461},{"text":179,"config":542},{"href":181,"dataGaName":182,"dataGaLocation":461},{"text":184,"config":544},{"href":186,"dataGaName":187,"dataGaLocation":461},{"text":546,"config":547},"Formation",{"href":548,"dataGaName":549,"dataGaLocation":461},"/fr-fr/solutions/education/","education",{"text":551,"config":552},"Services financiers",{"href":553,"dataGaName":554,"dataGaLocation":461},"/fr-fr/solutions/finance/","financial services",{"title":194,"links":556},[557,559,561,563,566,568,572,574,576,578,580,582,584,586],{"text":206,"config":558},{"href":208,"dataGaName":209,"dataGaLocation":461},{"text":211,"config":560},{"href":213,"dataGaName":214,"dataGaLocation":461},{"text":216,"config":562},{"href":218,"dataGaName":219,"dataGaLocation":461},{"text":221,"config":564},{"href":223,"dataGaName":565,"dataGaLocation":461},"docs",{"text":9,"config":567},{"href":245,"dataGaName":246},{"text":569,"config":570},"Histoires de réussite client",{"href":571,"dataGaLocation":461},"/customers/",{"text":239,"config":573},{"href":241,"dataGaName":242,"dataGaLocation":461},{"text":248,"config":575},{"href":250,"dataGaName":251,"dataGaLocation":461},{"text":261,"config":577},{"href":263,"dataGaName":264,"dataGaLocation":461},{"text":253,"config":579},{"href":255,"dataGaName":256,"dataGaLocation":461},{"text":266,"config":581},{"href":268,"dataGaName":269,"dataGaLocation":461},{"text":271,"config":583},{"href":273,"dataGaName":274,"dataGaLocation":461},{"text":276,"config":585},{"href":278,"dataGaName":279,"dataGaLocation":461},{"text":281,"config":587},{"href":283,"dataGaName":284,"dataGaLocation":461},{"title":299,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":306,"config":591},{"href":308,"dataGaName":301,"dataGaLocation":461},{"text":311,"config":593},{"href":313,"dataGaName":314,"dataGaLocation":461},{"text":319,"config":595},{"href":321,"dataGaName":322,"dataGaLocation":461},{"text":324,"config":597},{"href":326,"dataGaName":327,"dataGaLocation":461},{"text":329,"config":599},{"href":331,"dataGaName":332,"dataGaLocation":461},{"text":334,"config":601},{"href":336,"dataGaName":337,"dataGaLocation":461},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":461},"/sustainability/",{"text":607,"config":608},"Diversité, inclusion et appartenance (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":461},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":612},{"href":341,"dataGaName":342,"dataGaLocation":461},{"text":349,"config":614},{"href":351,"dataGaName":352,"dataGaLocation":461},{"text":354,"config":616},{"href":356,"dataGaName":357,"dataGaLocation":461},{"text":618,"config":619},"Déclaration de transparence sur l'esclavage moderne",{"href":620,"dataGaName":621,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":359,"links":623},[624,627,629,631,636,641,646],{"text":625,"config":626},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":461},{"text":368,"config":628},{"href":370,"dataGaName":371,"dataGaLocation":461},{"text":373,"config":630},{"href":375,"dataGaName":376,"dataGaLocation":461},{"text":632,"config":633},"Statut",{"href":634,"dataGaName":635,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":637,"config":638},"Conditions d'utilisation",{"href":639,"dataGaName":640},"/terms/","terms of use",{"text":642,"config":643},"Déclaration de confidentialité",{"href":644,"dataGaName":645,"dataGaLocation":461},"/fr-fr/privacy/","privacy statement",{"text":647,"config":648},"Préférences en matière de cookies",{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,658],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":461},{"text":656,"config":657},"Politique de confidentialité",{"href":644,"dataGaName":645,"dataGaLocation":461},{"text":647,"config":659},{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",[665,679,691,703,715,727,739,751,763,774],{"_path":666,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":671,"config":672,"_id":675,"_type":16,"title":676,"_source":17,"_file":677,"_stem":678,"_extension":20},"/fr-fr/blog/categories/agile-planning","categories",{"title":669,"description":670},"Planification Agile","Browse articles related to Planification Agile on the GitLab Blog",{"name":669},{"template":673,"slug":674,"hide":6},"BlogCategory","agile-planning","content:fr-fr:blog:categories:agile-planning.yml","Agile Planning","fr-fr/blog/categories/agile-planning.yml","fr-fr/blog/categories/agile-planning",{"_path":680,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":681,"content":684,"config":685,"_id":687,"_type":16,"title":688,"_source":17,"_file":689,"_stem":690,"_extension":20},"/fr-fr/blog/categories/ai-ml",{"title":682,"description":683},"IA/ML","Browse articles related to IA/ML on the GitLab Blog",{"name":682},{"template":673,"slug":686,"hide":6},"ai-ml","content:fr-fr:blog:categories:ai-ml.yml","Ai Ml","fr-fr/blog/categories/ai-ml.yml","fr-fr/blog/categories/ai-ml",{"_path":692,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":693,"content":696,"config":697,"_id":699,"_type":16,"title":700,"_source":17,"_file":701,"_stem":702,"_extension":20},"/fr-fr/blog/categories/bulletin-board",{"title":694,"description":695},"Annonces","Browse articles related to Annonces on the GitLab Blog",{"name":694},{"template":673,"slug":698,"hide":6},"bulletin-board","content:fr-fr:blog:categories:bulletin-board.yml","Bulletin Board","fr-fr/blog/categories/bulletin-board.yml","fr-fr/blog/categories/bulletin-board",{"_path":704,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":705,"content":708,"config":709,"_id":711,"_type":16,"title":712,"_source":17,"_file":713,"_stem":714,"_extension":20},"/fr-fr/blog/categories/customer-stories",{"title":706,"description":707},"Étude de cas","Browse articles related to Étude de cas on the GitLab Blog",{"name":706},{"template":673,"slug":710,"hide":6},"customer-stories","content:fr-fr:blog:categories:customer-stories.yml","Customer Stories","fr-fr/blog/categories/customer-stories.yml","fr-fr/blog/categories/customer-stories",{"_path":716,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":720,"config":721,"_id":723,"_type":16,"title":724,"_source":17,"_file":725,"_stem":726,"_extension":20},"/fr-fr/blog/categories/devsecops",{"title":718,"description":719},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":718},{"template":673,"slug":722,"hide":6},"devsecops","content:fr-fr:blog:categories:devsecops.yml","Devsecops","fr-fr/blog/categories/devsecops.yml","fr-fr/blog/categories/devsecops",{"_path":728,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":729,"content":732,"config":733,"_id":735,"_type":16,"title":736,"_source":17,"_file":737,"_stem":738,"_extension":20},"/fr-fr/blog/categories/engineering",{"title":730,"description":731},"Ingénierie","Browse articles related to Ingénierie on the GitLab Blog",{"name":730},{"template":673,"slug":734,"hide":6},"engineering","content:fr-fr:blog:categories:engineering.yml","Engineering","fr-fr/blog/categories/engineering.yml","fr-fr/blog/categories/engineering",{"_path":740,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":741,"content":744,"config":745,"_id":747,"_type":16,"title":748,"_source":17,"_file":749,"_stem":750,"_extension":20},"/fr-fr/blog/categories/news",{"title":742,"description":743},"Actualités","Browse articles related to Actualités on the GitLab Blog",{"name":742},{"template":673,"slug":746,"hide":6},"news","content:fr-fr:blog:categories:news.yml","News","fr-fr/blog/categories/news.yml","fr-fr/blog/categories/news",{"_path":752,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":753,"content":756,"config":757,"_id":759,"_type":16,"title":760,"_source":17,"_file":761,"_stem":762,"_extension":20},"/fr-fr/blog/categories/open-source",{"title":754,"description":755},"Open source","Browse articles related to Open source on the GitLab Blog",{"name":754},{"template":673,"slug":758,"hide":6},"open-source","content:fr-fr:blog:categories:open-source.yml","Open Source","fr-fr/blog/categories/open-source.yml","fr-fr/blog/categories/open-source",{"_path":764,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":765,"content":767,"config":768,"_id":770,"_type":16,"title":771,"_source":17,"_file":772,"_stem":773,"_extension":20},"/fr-fr/blog/categories/product",{"title":90,"description":766},"Browse articles related to Produit on the GitLab Blog",{"name":90},{"template":673,"slug":769,"hide":6},"product","content:fr-fr:blog:categories:product.yml","Product","fr-fr/blog/categories/product.yml","fr-fr/blog/categories/product",{"_path":775,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":776,"content":779,"config":780,"_id":782,"_type":16,"title":783,"_source":17,"_file":784,"_stem":785,"_extension":20},"/fr-fr/blog/categories/security",{"title":777,"description":778},"Sécurité","Browse articles related to Sécurité on the GitLab Blog",{"name":777},{"template":673,"slug":781,"hide":6},"security","content:fr-fr:blog:categories:security.yml","Security","fr-fr/blog/categories/security.yml","fr-fr/blog/categories/security",[787,832,871,885,931,969,1012,1054,1092,1130],{"category":669,"slug":674,"posts":788},[789,807,820],{"content":790,"config":804},{"title":791,"description":792,"authors":793,"heroImage":795,"date":796,"body":797,"category":674,"tags":798,"updatedDate":803},"Scaled Agile Framework : adoptez le framework SAFe avec GitLab ","Découvrez comment intégrer le Scaled Agile Framework (SAFe) aux fonctionnalités natives de la plateforme DevSecOps de GitLab.",[794],"Amanda Rueda","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","Lorsqu'une entreprise décide d'adopter le Scaled Agile Framework (SAFe) pour s'adapter à ses nouveaux besoins, coordonner les équipes qui travaillent sur des produits complexes devient rapidement un enjeu de taille. Elle doit couramment faire face à un défi majeur : la planification s'effectue dans un outil, tandis que le travail de développement proprement dit est géré dans un autre.\n\nCette séparation crée des silos entre les équipes et entraîne une multitude de problèmes au quotidien : les équipes de développement passent constamment d'un système à l'autre, les chefs de produit peinent à obtenir une image précise de l'avancement des projets, et au final, ce sont tous les contributeurs aux projets qui perdent un temps précieux à transférer manuellement des informations entre les différents systèmes. Or, SAFe a précisément été conçu pour résoudre ce type d'expérience fragmentée.\n\nSi vos équipes de développement utilisent déjà GitLab pour la [gestion du code source](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\"), les processus [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et la sécurité des logiciels, vous vous demandez peut-être s'il est possible d'y intégrer également la planification SAFe. La réponse est oui. Grâce à ses solides capacités de gestion de projets Agile, GitLab prend en charge le framework SAFe à chaque étape du développement logiciel. \n\nDans cet article, découvrez comment GitLab vous aide à mettre en place les concepts et les cérémonies SAFe, le tout au sein d'une seule et même plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\").\n\n## Qu'est-ce que le Scaled Agile Framework (SAFe) ?\n\nLe Scaled Agile Framework (SAFe) est une approche de gestion conçue pour appliquer les principes Agile à l'échelle des grandes entreprises. Il optimise la livraison de valeur, assure un alignement constant entre les équipes et se concentre sur les besoins des clients. \n\nSAFe transpose le modèle collaboratif et itératif des petites équipes aux environnements complexes des grandes entreprises impliquant de nombreuses équipes, parties prenantes et roadmaps. \n\nCette approche permet d'harmoniser tous les efforts de planification et d'exécution vers un objectif commun. Pour les chefs de produit, le Scaled Agile Framework (SAFe) fait le lien entre la stratégie et l'exécution : il ne s'agit pas uniquement de livrer rapidement, mais de livrer les bons produits, en s'appuyant sur des priorités claires et une coordination transversales entre les différentes équipes.\n\nSAFe réduit les silos, encourage la collaboration et aide les équipes à se mobiliser autour des résultats attendus par les clients, et non plus uniquement autour des tâches à accomplir. Une fois intégré à GitLab, la magie opère : visibilité, traçabilité et livraison sont réunies au sein d'une seule et même plateforme.\n\n## Correspondance de la terminologie SAFe dans GitLab\n\nVoici un aperçu des concepts SAFe et leur correspondance dans GitLab :\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Epic principal |\n| Capability | Sous-epic (niveau 1) |\n| Feature | Sous-epic (niveau 2) |\n| User story | Ticket |\n| Task | Tâche |\n| Team | Champ personnalisé / Label à portée limitée |\n| Sprint | Itération |\n| Program Increment (PI) | Jalon |\n| Value Stream | Groupe principal |\n| Agile Release Train (ART) | Groupe principal |\n\n\u003Cbr>\u003C/br>\n\nEn vous basant sur cette correspondance, vous pouvez configurer GitLab pour refléter fidèlement votre implémentation SAFe. La structure des groupes vous permet d'organiser vos équipes autour de vos chaînes de valeur (Value Stream) et de vos Agile Release Trains (ART), tandis que la hiérarchie des éléments de travail (avec jusqu'à sept niveaux d'epics imbriqués) vous offre toute la profondeur nécessaire pour gérer des portefeuilles produits complexes. Que vous travailliez au niveau du portefeuille (groupes principaux), du programme (sous-groupes) ou de l'équipe (projets), la structure organisationnelle de GitLab s'aligne parfaitement avec la hiérarchie SAFe.\n\n## Les cérémonies SAFe dans GitLab\n\nDécouvrez maintenant comment organiser vos cérémonies SAFe dans GitLab. Voici comment procéder, étape par étape.\n\n### Planification PI (Program Increment)\n\nPour faciliter l'alignement entre les équipes et la gestion des dépendances qui font le succès de la planification PI, GitLab offre plusieurs fonctionnalités :\n\n* La vue [Roadmap](https://docs.gitlab.com/user/group/roadmap/) :  visualisez les fonctionnalités par équipe et sur plusieurs périodes.\n* Les [jalons](https://docs.gitlab.com/user/project/milestones/) : associez chaque fonctionnalité au jalon correspondant à votre PI. \n* Les [dépendances](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues) : documentez et visualisez les dépendances entre équipes dès qu'elles sont identifiées.\n\nGitLab vous offre une grande flexibilité pour la planification PI grâce à deux vues principales : les tableaux des epics (qui peuvent être configurés pour afficher les affectations par équipe) et la vue Roadmap (qui affiche les fonctionnalités au fil du temps, façon diagramme de Gantt). Vous pouvez facilement passer d'une vue à l'autre pendant votre session de planification, selon que vous souhaitez vous concentrer sur la chronologie ou l'organisation des équipes.\n\n![Vue Roadmap et tableau des epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Vue Roadmap avec diagramme de Gantt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Affinement\n\nEn tant que chef de produit, animer des sessions d'affinement efficaces repose sur une visibilité complète de votre backlog de fonctionnalités. Vous pouvez exécuter votre session d'affinement directement dans GitLab. Il n'est plus nécessaire de mettre à jour un outil pendant la réunion, puis un autre après coup. \n\nGitLab facilite les sessions d'affinement grâce aux éléments suivants :\n\n* Les [tableaux des epics](https://docs.gitlab.com/user/group/epics/epic_boards/) : regroupez les fonctionnalités en fonction de leur statut.  \n* Les story points : visualisez-les directement dans l'[aperçu](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic).  \n* Les [vues dans un volet latéral](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer) : interagissez avec vos éléments de travail sans jamais perdre de vue le contexte.   \n* Les [tickets enfants](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) : créez et associez des tickets directement à partir des epics.\n\n![SAFe - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Planification de sprint\n\nGitLab vous offre tous les outils nécessaires pour planifier vos sprints sans frictions :\n\n* Les [tableaux des tickets](https://docs.gitlab.com/user/project/issue_board/) : visualisez clairement l'ensemble de votre backlog.  \n* Le [poids total](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) des user stories : visualisez-le directement dans les tableaux.  \n* L'ordonnancement des tickets : déplacez les tickets entre les différentes itérations, par simple glisser-déposer. \n* Une vue repliable : simplifiez le réordonnancement des stories d'un sprint à l'autre.\n\nPlus besoin de jongler entre plusieurs outils, toute la planification se fait dans GitLab. Vous pouvez ainsi consacrer vos réunions de planification à prendre les bonnes décisions.\n\n![Planification de sprint avec GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 Consultez [ce tutoriel dédié à la mise en œuvre de la méthode Scrum avec GitLab](https://docs.gitlab.com/tutorials/scrum_events/) et découvrez en détail la puissance de GitLab dans la planification Agile et le suivi des sprints.*\n\n### Points quotidiens\n\nVotre équipe peut se réunir autour du tableau de bord lors de vos points quotidiens, plus besoin de naviguer entre plusieurs outils ou de deviner l'avancement des projets : tout est visible en un clin d'œil dans GitLab. Votre équipe voit instantanément qui travaille sur quoi, ce qui bloque, et ce qui est prêt pour la revue. GitLab vous permet d'effectuer les actions suivantes lors de vos points quotidiens :\n\n* Les tableaux [filtrés par itération](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) : affichez le travail du sprint en cours.\n* Les story points : affichez le poids des stories directement sur les cartes. \n* La [vue du volet latéral](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer) : accédez aux détails sans quitter le contexte. \n* Les [indicateurs de progression](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status) : mettez en évidence les tâches à risque.\n\n![Tableau de réunions debout quotidiennes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Revue de sprint\n\nPour avoir une vision claire des performances de votre équipe au fil des sprints, GitLab met à votre disposition des indicateurs puissants avec les éléments suivants :\n\n* Des [graphiques d'avancement burndown et burnup](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) : visualisez facilement l'avancement des itérations. \n* Le suivi de la vélocité : mesurez l'efficacité de votre équipe.  \n* Les [délais d'exécution et la durée de cycle](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics) : obtenez des indicateurs précis pour évaluer vos workflows.  \n* Des tableaux de bord personnalisables : créez des vues adaptées à chaque équipe.\n\nCes indicateurs vous aident à comprendre si votre équipe gagne en rapidité, à détecter les goulots d'étranglement et les points de friction à aborder lors de votre prochaine rétrospective.\n\n![Graphiques d'avancement burndown et burnup](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 bonnes raisons d'adopter une plateforme unifiée\n\nIl existe de nombreux outils de planification capables de gérer les cérémonies SAFe. Mais GitLab se distingue véritablement de ses concurrents pour les raisons suivantes :\n\n1. **Plus de changement de contexte** : la planification, le développement, les tests et la sécurité s'effectuent tous sur une seule plateforme.\n2. **Une traçabilité totale** : de l'épic stratégique et prioritaire jusqu'au déploiement, en passant par l'écriture du code, chaque élément est relié et facile à suivre.\n3. **Une collaboration efficace** : toutes les équipes (développement, produit, sécurité) collaborent dans le même outil.\n4. **Une visibilité instantanée** : toutes les parties prenantes accèdent aux informations clés mises à jour, sur une seule plateforme.\n5. **Une vue d'ensemble** : les indicateurs de planification et de développement sont regroupés pour comprendre exactement où en est le projet.\n\nSi vos équipes de développement apprécient déjà GitLab, pourquoi leur imposer un nouvel outil de planification ou créer des intégrations complexes et disparates ? En intégrant votre planification SAFe à GitLab, vous offrez à tous les contributeurs une expérience unifiée, cohérente et bien plus efficace.\n\n## Principes de mise en œuvre\n\nAprès avoir accompagné plusieurs équipes dans leur transition depuis des outils SAFe traditionnels vers GitLab, voici ce qu'il faut retenir : concentrez-vous sur **les objectifs propres à chaque cérémonie SAFe** plutôt que d'essayer de reproduire les processus de vos anciens outils.\n\nLes équipes qui tirent pleinement parti des fonctionnalités natives de GitLab sont plus performantes que celles qui essaient de les contourner. Cela demande un peu de travail au départ pour comprendre comment associer vos concepts SAFe et configurer vos workflows. Mais une fois cette étape franchie, vous constaterez rapidement que vos processus sont en réalité bien plus simples.\n\nLa clé du succès réside dans la définition de conventions partagées entre tous les contributeurs : quels labels utiliser ? Comment suivre les équipes ? Quelle différence entre un epic et un ticket ? En investissant un minimum d'effort dans cette phase de clarification, vous créez un système intuitif qui éliminera toute la charge de travail liée à la coordination entre les différents outils.\n\n## Mise en place du framework SAFe dans GitLab\n\nEnvie de vous lancer ? Voici les étapes pour mettre en œuvre un Scaled Agile Framework (SAFe) dans GitLab :\n\n1. **Structurez votre environnement** : créez des groupes et des sous-groupes qui [s'alignent sur l'organisation de vos équipes](https://about.gitlab.com/fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).\n2. **Définissez la répartition de votre travail** : décidez comment vous allez utiliser les [epics](https://about.gitlab.com/fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), les [tickets](https://docs.gitlab.com/user/project/issues/managing_issues/) et les [tâches](https://docs.gitlab.com/user/tasks/). \n3. **Créez vos itérations** : configurez votre [calendrier de sprints](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence).  \n4. **Ajoutez vos jalons** : les [jalons](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) représentent vos Program Increments (PI) SAFe dans GitLab. \n5. **Personnalisez vos tableaux** : créez des vues dédiées à chaque cérémonie SAFe. \n6. **Accordez-vous sur des conventions** : documentez la façon dont vous utiliserez les labels et les champs personnalisés.\n\nPrendre le temps de bien poser ces bases dès le départ vous évitera bien des tracas par la suite. Votre configuration n'a pas besoin d'être parfaite dès le premier jour : vous pourrez faire des ajustements au fur et à mesure.\n\n## Rassemblez toutes les pièces du puzzle\n\nGitLab vous offre une base solide pour exécuter le Scaled Agile Framework (SAFe), en particulier si vos équipes de développement sont déjà adeptes de GitLab. En centralisant la planification et le développement dans un seul et même outil, vous éliminez les silos et les transferts fastidieux, facilitez la collaboration et accélérez la livraison de vos produits.\n\nLa flexibilité des outils de planification de GitLab vous permet d'adapter l'approche SAFe à vos besoins spécifiques. Vos équipes ne sont pas soumises à des workflows rigides : vous pouvez faire évoluer votre approche à mesure que vos équipes gagnent en maturité et que vos besoins changent.\n\n> Découvrez à quel point la planification sans effet de silo peut être plus simple et plus efficace. [Essayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) et simplifiez l'implémentation de votre approche SAFe.\n\n*💡 Pour en savoir plus à ce sujet, n'hésitez pas à consulter également cet article : [Comment utiliser GitLab pour le développement logiciel agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/)*\n",[799,800,801,769,802],"agile","DevSecOps platform","features","tutorial","2025-05-12",{"slug":805,"featured":91,"template":806},"safe-without-silos-in-gitlab","BlogPost",{"content":808,"config":818},{"title":809,"description":810,"authors":811,"heroImage":812,"date":813,"body":814,"category":674,"tags":815,"updatedDate":817},"Comment harmoniser les sprints Agile avec les roadmaps produit","Découvrez comment tirer parti de la méthodologie Agile et des fonctionnalités de GitLab à chaque étape du cycle de développement logiciel.",[794],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","2025-02-04","Prenons l'exemple d'équipes produit et de développement travaillant en vase clos. La situation est la suivante : l'équipe produit établit une roadmap sur 12 mois et la communique aux parties prenantes internes, sans toutefois l'examiner au préalable avec l'équipe de développement. De son côté, l'équipe de développement commence à créer les fonctionnalités prévues pour le prochain sprint sans tenir compte de la roadmap produit globale. Résultat : des occasions manquées d'optimiser le calendrier, de mener des projets en parallèle, d'ajuster la charge de travail de l'équipe ou de concevoir des API réutilisables pouvant servir à plusieurs initiatives. Ce manque de coordination entraîne des inefficacités et des retards dans la livraison de valeur.\n\nTrouver le juste équilibre entre gains à court terme et vision à long terme n'est pas toujours facile. Pour y parvenir, une communication claire, des priorités alignées et les bons outils sont indispensables. Découvrez dans ce guide des stratégies concrètes pour harmoniser vos sprints Agile avec des roadmaps stratégiques, relever les défis du développement logiciel et mettre en place des solutions efficaces adaptées à vos équipes.\n\n## L'importance d'une source unique de vérité\n\nUne source unique et cohérente de vérité pour les roadmaps avec des objectifs à plus long terme vous garantit, à vous et à vos équipes, de disposer d'informations actualisées sur la vision globale du projet. Concrètement, cela implique d'adopter une plateforme unique et mise à jour régulièrement pour centraliser tous les détails de votre roadmap. Vous évitez ainsi la multiplication des versions de votre roadmap produit dans différents formats, source de divergences en termes d'informations et de mauvaise compréhension des objectifs à atteindre.\n\n### Comment créer une roadmap produit centralisée\n\nEn créant une roadmap centralisée pour votre équipe, vous pouvez :\n\n* communiquer une stratégie à long terme  \n* réduire au maximum les erreurs de communication  \n* faciliter l'alignement entre les différentes équipes \n* vous adapter rapidement aux changements sans perdre le contexte   \n* offrir un accès aux informations en libre-service, et ainsi réduire la dépendance à un point de contact unique détenant l'information\n\n***Conseil GitLab** : avec les [epics](https://docs.gitlab.com/ee/user/group/epics/) et la [vue Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/), vous pouvez facilement suivre la planification de vos produits et leurs livraisons. En effet, la vue Roadmap vous permet de suivre la progression du projet, d'identifier les goulots d'étranglement et d'assurer l'alignement entre les objectifs stratégiques et l'exécution des sprints.* \n\n![Vue Roadmap pour le groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## Pratiques collaboratives de révision d'une roadmap\n\nÉtablissez un processus régulier de révision et de validation des mises à jour de la roadmap produit en incluant un [trio produit](https://www.producttalk.org/product-trio/) gagnant, à savoir les équipes produit, les équipes UX et les équipes d'ingénierie. Les sessions de révision collaboratives de la roadmap vous aident à maintenir l'alignement entre les parties prenantes et à réduire au maximum les risques. Par exemple, chez GitLab, les réunions avec l'Engineering Manager et l'UX Designer assignés à un projet donné ont lieu chaque mois pour passer en revue les modifications et les valider avec eux. Nous maintenons un suivi des validations sur la page wiki de la roadmap elle-même, ce qui nous engage à respecter le calendrier et garantit la transparence vis-à-vis du reste de l'entreprise.\n\n### Comment optimiser l'efficacité des sessions de révision\n\nPour tirer le meilleur parti des sessions de révision, adoptez les bonnes pratiques suivantes :\n\n* Planifiez des révisions systématiques, mensuelles ou trimestrielles, en fonction de la fréquence à laquelle la roadmap a tendance à évoluer au sein de votre entreprise.\n* Validez l'alignement entre les objectifs produit, le délai de mise en œuvre de l'expérience utilisateur et la faisabilité technique en discutant dès le départ des risques potentiels et des dépendances.   \n  * Assurez-vous que la roadmap reflète les objectifs actuels de l'entreprise.  \n  * Veillez à ce que les délais de conception soient réalistes et tiennent compte des besoins en matière de recherche ou de validation.\n  * Vérifiez que la roadmap inclut le temps alloué à la préparation technique, y compris pour des explorations techniques ou des investigations. Vous pouvez ainsi vous assurer que le travail technique en amont s'aligne avec les priorités globales de l’équipe d'ingénierie.  \n* Optimisez l'efficacité de l'équipe en tenant compte des contraintes de capacité et en vous assurant que la séquence de travail correspond au profil de compétences de l'équipe. Il s'agit notamment d'éviter les périodes de sous-utilisation des ressources ou d'inadéquation des compétences tout en planifiant efficacement les situations telles que les baisses d'effectifs pendant les vacances.\n* Adaptez la portée du projet et définissez des objectifs réalistes en fonction de ce qui peut être accompli. Bien que nous souhaitions en faire toujours plus, la perfection est l'ennemie du progrès. Il convient donc de prioriser ce qui compte vraiment pour apporter de la valeur ajoutée de manière efficace. Recherchez les opportunités d'optimisation en identifiant les moyens d'itérer ou d'augmenter la productivité, en ajustant par exemple l'ordre des tâches afin de réduire les dépendances ou en exploitant les composants réutilisables pour rationaliser le développement.\n* Favorisez un dialogue ouvert sur les compromis et les priorités afin de garantir la prise en compte de tous les points de vue. Cette approche collaborative permet d'identifier des solutions créatives pour relever des défis et de parvenir à un consensus sur la meilleure voie à suivre.\n\n***Conseil GitLab** : utilisez une page [wiki](https://docs.gitlab.com/ee/user/project/wiki/) pour compléter votre [Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/). Le wiki vous permet d'inclure des informations contextuelles sur votre roadmap produit, telles que la justification commerciale, des liens vers des études utilisateurs, les scores RICE, ainsi que des détails sur les dépendances ou les risques. Créez des liens directs vers la roadmap pour en faciliter l'accès, et tirez parti de la fonctionnalité de fils de discussion pour encourager la collaboration asynchrone et les retours de votre équipe.*\n\n![Roadmap produit PlanFlow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## Validation continue de la stratégie et mesure de la progression\n\nL'objectif d'une roadmap produit n'est pas seulement de vous permettre de rester sur la bonne voie, mais aussi d'apporter une réelle valeur ajoutée à vos clients. Pour favoriser le partage des retours utilisateurs et des données comportementales en continu, envisagez d'intégrer des points de contact réguliers issus du trio produit en dehors des cycles de sprint. Ces sessions peuvent servir à examiner les informations clés, à analyser les tendances et à s'assurer que la roadmap produit reflète toujours l'évolution des besoins de vos utilisateurs. En fondant les mises à jour de la roadmap sur les informations réelles des utilisateurs, vous optimisez non seulement vos résultats, mais vous vous adaptez également aux réels besoins de vos clients.\n\nLa valeur que vous livrez peut prendre la forme d'une meilleure ergonomie, d'une dette technique réduite ou de nouvelles fonctionnalités. Lorsque le trio produit est aligné sur la vision de la roadmap, il l'est également sur les résultats que vous vous efforcez d'atteindre.\n\nAfin de déterminer si vous serez en mesure d'atteindre ces résultats, vous devez évaluer précisément les résultats escomptés. Les dérives des objectifs, comme l'ajout tardif de user stories, peut retarder votre capacité à fournir de la valeur. Il est également important d'identifier les tâches réalisées qui ne correspondent pas à la roadmap et d'en comprendre les raisons.\n\n### Planification du sprint\n\nPour maintenir l'alignement des parties prenantes impliquées avec votre roadmap produit, vous devez impérativement commencer par une planification réfléchie de votre sprint. \n\nVoici quelques bonnes pratiques à mettre en œuvre afin de permettre à votre équipe de garder le cap et de se concentrer sur la création de valeur :\n\n* Définissez clairement les objectifs souhaités en délimitant précisément leur portée pour assurer une réalisation efficace.  \n* Identifiez les ajouts tardifs ou ajustements potentiels qui pourraient retarder la livraison et prévoyez des marges de sécurité pour maintenir la concentration des équipes.  \n* Mettez-vous d'accord avec votre équipe sur l'ordre des tâches à effectuer afin d'optimiser l'utilisation des ressources, de prendre en compte les compétences disponibles et de réduire les dépendances.\n* Évitez de planifier à 100 % la capacité de l'équipe pour maintenir la concentration et améliorer la confiance dans le respect des délais. Prévoyez une marge (10 à 20 %) pour gérer les imprévus ou les nouvelles opportunités qui pourraient survenir pendant le sprint.\n\n### Exécution du sprint\n\nRespecter votre roadmap pendant le sprint exige de la concentration, une communication adéquate et une évaluation constante. Si l'objectif est de créer de la valeur, il est tout aussi important de s'assurer que le travail en cours correspond aux résultats que vous avez définis et planifiés.\n\n* Validez en permanence le travail en cours par rapport aux résultats de la roadmap pour vous assurer que chaque sprint contribue à la vision globale.\n* Encouragez l'équipe à vérifier régulièrement qu'elle travaille toujours en vue des objectifs et des résultats escomptés.\n* Maintenez une communication ouverte tout au long du sprint. Organisez des réunions quotidiennes ou des mises à jour asynchrones pour identifier rapidement les risques, les imprévus ou les dépendances et procédez aux ajustements nécessaires.\n* Faites preuve d'une rigueur sans faille pour protéger le sprint. Bien qu'il soit naturel de vouloir résoudre les problèmes émergents, le travail non planifié doit être soigneusement évalué afin d'éviter de faire dérailler les priorités convenues.\n* Gérez de manière proactive toute dérive des objectifs. Si de nouvelles tâches apparaissent en cours de sprint, évaluez leur adéquation avec l'objectif défini de manière précise dans la roadmap. Bien que des idées ou des fonctionnalités supplémentaires puissent s'aligner conceptuellement sur le résultat plus large, elles peuvent ne pas s'intégrer dans le plan immédiat de création de valeur. Documentez ces suggestions et évaluez si elles doivent être considérées comme faisant partie d'itérations futures ou comme un plus pour l'avenir, plutôt que de les introduire dans le sprint en cours et de retarder les priorités convenues.\n\n### Rétrospectives de sprint\n\nLors de vos rétrospectives de sprint, prenez le temps de réfléchir avec votre équipe sur la manière dont vous progressez collectivement vers les résultats souhaités. Les questions à se poser sont les suivantes :\n\n* Des tâches imprévues ont-elles été ajoutées pendant le sprint, retardant ainsi votre capacité à créer de la valeur ? Identifiez pourquoi cela s'est produit et quels ajustements peuvent être apportés.\n* Avez-vous livré des tâches qui s'écartaient de la roadmap ? Discutez des raisons de cet écart et des enseignements que vous pouvez en tirer pour la planification future.\n\nDe la planification du sprint aux rétrospectives, il est de la responsabilité de l'équipe de rester concentrée sur l'obtention de résultats tangibles pour les utilisateurs et les parties prenantes. En s'alignant à chaque étape du processus, vous vous assurez que votre roadmap reste un guide clair pour offrir de la valeur de manière efficace et cohérente.\n\n***Conseil GitLab** : utilisez les [graphiques d'avancement burndown](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) de GitLab pour visualiser les progrès et détecter rapidement les écarts, afin d'aider votre équipe à rester concentrée sur l'obtention de résultats.*\n\n![Graphique d'avancement burndow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## Livrer les résultats de la roadmap en toute confiance\n\nHarmoniser les sprints agiles avec les roadmaps stratégiques nécessite une approche intentionnelle, l'adhésion de l'équipe et les outils appropriés. Créer une source unique de vérité, encourager les révisions collaboratives et mesurer la progression vers les résultats vous permet d'aligner l'exécution sur la vision du produit. Grâce aux fonctionnalités de planification de GitLab, vos équipes peuvent transformer tous ces défis en opportunités d'innovation et de croissance.\n\nVous souhaitez aligner vos sprints sur votre roadmap stratégique ? [Commencez un essai gratuit de GitLab](https://about.gitlab.com/fr-fr/free-trial/) dès aujourd'hui et découvrez les fonctionnalités qui vous permettront de garantir que chaque cycle de développement contribue efficacement aux objectifs à long terme de votre entreprise.\n\n## En savoir plus\n\n- [Le nouveau rôle de planificateur de GitLab pour aider les équipes de planification Agile](https://about.gitlab.com/fr-fr/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)\n- [Wiki GitLab : l'outil pour une gestion efficace des connaissances](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)\n- [Comment utiliser GitLab pour le développement logiciel agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/ \"Comment utiliser GitLab pour le développement logiciel agile\")\n- [Comment la planification Agile de GitLab améliore la gestion de projet collaborative ](https://about.gitlab.com/fr-fr/blog/how-gitlab-agile-planning-improves-collaborative-project-management/ \"Comment la planification Agile de GitLab améliore la gestion de projet collaborative \")\n",[799,802,816,800],"workflow","2025-03-06",{"slug":819,"featured":91,"template":806},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"content":821,"config":830},{"heroImage":822,"body":823,"authors":824,"updatedDate":825,"date":826,"title":827,"tags":828,"description":829,"category":674},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","GitLab a créé un nouveau rôle au sein de sa plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") : le planificateur. Cette nouveauté s'aligne avec la stratégie de GitLab, qui consiste à fournir des contrôles d'accès flexibles et basés sur les rôles, comme en témoignent les [rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html). Le rôle de planificateur permet aux équipes de développement logiciel et aux utilisateurs spécialisés dans la planification d'accéder aux outils dont ils ont besoin pour gérer leurs workflows Agile, tout en limitant les autorisations trop étendues susceptibles d'introduire des risques inutiles. En adaptant l'accès aux besoins spécifiques des utilisateurs, le rôle de planificateur garantit la productivité des équipes, tout en maintenant la sécurité et la conformité, conformément au [principe de moindre privilège](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\n## Pourquoi avons-nous créé le rôle de planificateur ?\n\nL'idée nous est venue des retours de nos clients et de nos équipes internes. Il est souvent mentionné que, malgré ses outils complets pour la planification et la gestion des [cycles de développement Agile](https://about.gitlab.com/fr-fr/solutions/agile-delivery/ \"Livraison agile\"), GitLab pouvait manquer de contrôles d'accès plus spécifiques basés sur les rôles. Les chefs de produit, les responsables de projet et les autres utilisateurs impliqués dans la planification ont souvent besoin d'accéder aux fonctionnalités de planification, sans nécessiter des autorisations de développement complètes. Au contraire, il n'est pas souhaitable d'étendre cet accès, car il entraîne une augmentation des risques de sécurité et d'erreurs, telles que des modifications involontaires du code ou des configurations contenant des données sensibles. \n\nNous avons donc mené des entretiens avec des utilisateurs, des analyses concurrentielles et des recherches approfondies, et validé l'intérêt d'un rôle qui accorde un accès complet aux outils de planification, tout en limitant l'accès aux fonctionnalités de développement pour garantir la sécurité.\n\n## Que propose le rôle de planificateur ?\n\nLe rôle de planificateur est un rôle hybride à mi-chemin entre [l'invité et le rapporteur](https://docs.gitlab.com/ee/user/permissions.html#roles). Il est toutefois conçu spécifiquement pour les membres d'équipe qui ont besoin d'accéder aux workflows de planification. \n\nVoici ses particularités :\n\n* L'accès aux principaux outils de planification tels que les epics, les roadmaps, les tableaux des tickets et les [OKR](https://docs.gitlab.com/ee/user/okrs.html) (*certaines fonctionnalités peuvent nécessiter une licence GitLab Premium ou Ultimate*)\n* Une sécurité renforcée qui limite l'accès non requis aux fonctionnalités de développement sensibles\n* Une compatibilité avec le module d'extension GitLab Enterprise Agile Planning, permettant aux équipes de bénéficier d'un accès personnalisé aux outils de planification sans compromettre la sécurité et le contrôle. (*Ce rôle est néanmoins disponible avec toutes les licences*)\n\nLe rôle de planificateur est disponible avec toutes les solutions GitLab, y compris l'édition SaaS de GitLab, GitLab Dedicated et GitLab Auto-géré. Tous les clients bénéficient ainsi de cet accès personnalisé.\n\nCe rôle donne aux équipes la possibilité d'aligner les autorisations sur les fonctions du poste afin d'équilibrer accessibilité et sécurité.\n\n## Comment le rôle de planificateur facilite-t-il les pratiques Agile ?\n\nDans le [développement logiciel Agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/), il est essentiel de s'assurer que chaque membre de l'équipe dispose des outils et des autorisations adéquates pour optimiser l'efficacité du workflow. Le rôle de planificateur facilite cette approche : il permet la pleine participation aux étapes de planification du cycle de développement logiciel des membres de l'équipe qui en sont responsables, sans affecter des domaines tels que le développement ou le déploiement.\n\nDe la création et de la gestion des epics à la définition des roadmaps, il fournit aux équipes agiles les outils nécessaires pour maintenir leur alignement et leur productivité.\n\n## Une approche centrée sur les clients\n\nCe rôle n'a pas été créé en vase clos. Nous avons impliqué notre communauté à chaque étape du processus. Grâce à des enquêtes, des entretiens et des tests, nous avons ajusté les autorisations pour qu'elles répondent aux besoins réels des chefs de produit et des responsables de projet.\n\nLe rôle de planificateur s'inscrit également dans la mission de longue date de GitLab, qui vise à être une plateforme de référence pour les équipes agiles, en offrant aux entreprises la flexibilité et le contrôle nécessaires pour mettre en œuvre des [méthodologies agiles](https://about.gitlab.com/fr-fr/topics/agile-delivery/agile-methodology/ \"Qu'est-ce que la méthodologie Agile ?\") à grande échelle.\n\n## Les retours et l'engagement de la communauté\n\nNous apprécions votre contribution et vous encourageons à nous donner votre avis sur le nouveau rôle de planificateur. Vos retours sont essentiels pour nous aider à affiner et à améliorer votre expérience sur la plateforme DevSecOps de GitLab. N'hésitez pas à consulter notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/503817) pour nous faire part de vos réflexions et suggestions.\n\n## Commencez à planifier avec GitLab dès aujourd'hui !\n\nLe rôle de planificateur n'est qu'une des nombreuses façons dont GitLab permet aux équipes de développement logiciel de planifier, de collaborer et de livrer des logiciels efficacement. Que vous cherchiez à optimiser vos workflows de gestion de produits, à renforcer la collaboration au sein de votre équipe ou à uniformiser vos pratiques Agile, GitLab vous fournit les outils nécessaires pour votre réussite.\n\n> Vous souhaitez découvrir toute la puissance de GitLab ? [Essayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/) et planifiez vos futurs projets avec notre nouveau rôle de planificateur.",[794],"2024-12-03","2024-11-25","GitLab inclut désormais un rôle de planificateur pour aider les équipes de planification Agile",[799,800,801,769],"Découvrez comment le nouveau rôle de planificateur dans GitLab aide les équipes Agile à gérer les workflows de planification.",{"slug":831,"featured":91,"template":806},"introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"category":682,"slug":686,"posts":833},[834,847,860],{"content":835,"config":845},{"tags":836,"category":686,"date":838,"heroImage":839,"authors":840,"description":842,"title":843,"body":844},[837,769,801,746],"AI/ML","2025-07-17","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg",[841],"Bill Staples","Découvrez la plateforme d'orchestration DevSecOps conçue pour permettre une collaboration asynchrone entre les équipes de développement et les agents d’IA.","GitLab Duo Agent Platform (bêta) : votre orchestration IA nouvelle génération","**Nous construisons l'avenir du développement logiciel.**\n\nChez GitLab, nous [réinventons l'avenir de l'ingénierie logicielle](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/) comme une collaboration entre humains et intelligence artificielle. Les équipes de développement se concentrent sur la résolution de problèmes techniques complexes et l'innovation, tandis que les agents d'IA gèrent les tâches routinières et répétitives qui ralentissent l’avancée des projets. Les développeurs sont libres d'explorer de nouvelles idées à moindre coût, les bogues de backlogs appartiennent au passé, et les utilisateurs des logiciels que vous créez profitent d'une expérience plus fluide, fiable et sécurisée. Ceci n'est pas un rêve lointain, et nous construisons cette réalité aujourd'hui avec GitLab Duo Agent Platform.\n\n## Qu'est-ce que GitLab Duo Agent Platform ?\n\nGitLab Duo Agent Platform est notre plateforme d'orchestration DevSecOps nouvelle génération conçue pour permettre une collaboration asynchrone entre les équipes de développement et les agents d'IA. Cette plateforme transformera votre workflow de développement, passant de processus linéaires isolés à une collaboration dynamique où des agents d'IA spécialisés travaillent à vos côtés et avec votre équipe à chaque étape du cycle de vie du développement logiciel. \n\nImaginez déléguer une tâche de refactorisation complexe à un Software Developer Agent tout en ayant simultanément un Security Analyst Agent qui recherche des vulnérabilités et un Deep Research Agent qui analyse les progrès à travers l'historique de votre dépôt. Tout cela se déroule en parallèle, orchestré de manière transparente dans GitLab.\n\nAujourd'hui, nous annonçons le lancement de la [première version bêta publique de GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) pour les clients GitLab.com et GitLab Self-Managed (GitLab Premium et Ultimate). Il s'agit seulement de la première d'une série de mises à jour qui amélioreront la façon dont les logiciels sont planifiés, compilés, vérifiés et déployés, tandis que nous amplifions l'ingéniosité humaine grâce à l'automatisation intelligente.\n\nCette première version bêta se concentre sur l’amélioration de l'expérience IDE via l'extension GitLab VS Code et le plug-in JetBrains IDEs. Le mois prochain, nous prévoyons d'apporter l'expérience Duo Agent Platform à l'application GitLab et d'étendre la prise en charge de l'IDE. Permettez-moi de partager un peu plus notre vision de la roadmap d'ici à la disponibilité générale, prévue pour la fin de l’année. Vous trouverez les détails sur la première version bêta ci-dessous.\n\nRegardez cette vidéo ou lisez la suite de cet article pour découvrir ce qui est désormais disponible et ce qui est à venir. Ensuite, si vous êtes prêt à démarrer avec Duo Agent Platform, découvrez comment faire vos premiers pas sur la version bêta publique.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## La position de GitLab en tant que plateforme d'orchestration\n\nGitLab se trouve au cœur du cycle de vie du développement en tant que système d'enregistrement pour les équipes d'ingénierie, orchestrant l'ensemble du parcours, du concept à la production, pour plus de 50 millions d'utilisateurs enregistrés, dont la moitié des entreprises du classement Fortune 500. Cela comprend plus de 10 000 clients payants dans tous les segments et secteurs d’activité, y compris les institutions publiques.\n\nCe qui donne à GitLab un avantage qu'aucun concurrent ne peut égaler : une compréhension complète de tout ce qu'il faut pour livrer des logiciels. Nous rassemblons vos projets, votre code, vos tests, vos scans de sécurité, vos contrôles de conformité et vos configurations CI/CD au sein d'un seul et même endroit. De cette manière, vous améliorez la productivité de votre équipe et orchestrez la collaboration avec les agents d'IA que vous contrôlez.\n\nEn tant que plateforme DevSecOps intelligente et unifiée, GitLab stocke tout le contexte de votre pratique d'ingénierie logicielle en un seul endroit. Nous exposerons ces données unifiées aux agents d'IA via notre graphe de connaissances. Chaque agent que nous construisons a automatiquement accès à cet ensemble de données connecté au SDLC, fournissant un contexte riche pour que les agents puissent faire des recommandations éclairées et prendre des actions qui respectent vos normes organisationnelles.\n\n**Voici un exemple de cet avantage en action.** Avez-vous déjà essayé de comprendre exactement comment un projet progresse à travers des dizaines, voire des centaines de commentaires et de tickets traités par tous les développeurs impliqués ? Notre Deep Research Agent exploite le graphe de connaissances de GitLab et les capacités de recherche sémantique pour parcourir votre epic et tous les tickets connexes, explorer le code source associé et le contexte environnant. Il corrèle rapidement les informations à travers vos dépôts, merge requests et historique de déploiement. Cela fournit des informations essentielles que les outils autonomes ne peuvent égaler et que les développeurs humains mettraient des heures à découvrir. \n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Notre évolution stratégique des fonctionnalités d'IA vers l'orchestration d'agents\n\nGitLab Duo a été lancé comme un module d’extension, apportant l'IA générative aux équipes de développement via GitLab Duo Pro et GitLab Duo Enterprise. Avec GitLab 18.0, GitLab Duo est désormais intégré à la plateforme. Nous avons débloqué [GitLab Duo Agentic Chat](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) et les suggestions de code pour tous les utilisateurs de GitLab Premium et Ultimate, et nous fournissons un accès immédiat à GitLab Duo Agent Platform. \n\nNous avons augmenté l'investissement en ingénierie et accélérons la livraison, avec de nouvelles fonctionnalités d’IA déployées chaque mois. Mais nous ne construisons pas juste un autre assistant de codage. GitLab Duo devient une plateforme d'orchestration d'agents, où vous pouvez créer, personnaliser et déployer des agents d’IA qui travaillent à vos côtés et interagissent facilement avec d'autres systèmes, augmentant ainsi votre productivité.\n\n> **« GitLab Duo Agent Platform améliore notre workflow de développement avec une IA qui comprend vraiment notre code source et notre organisation. Avoir des agents d’IA intégrés dans notre système d'enregistrement pour le code, les tests, le CI/CD et l'ensemble du cycle de vie du développement logiciel booste la productivité, la vélocité et l'efficacité. Les agents sont devenus de vrais collaborateurs pour nos équipes, et leur capacité à comprendre l'intention, à décomposer les problèmes et à agir permet à nos équipes de se concentrer sur des tâches innovantes et stimulantes. »** - Bal Kang, Engineering Platform Lead chez NatWest\n\n### Des agents qui fonctionnent immédiatement\n\nNous introduisons des agents qui reflètent des rôles d'équipe familiers. Ces agents peuvent rechercher, lire, créer et modifier des artefacts existants dans GitLab. Considérez-les comme des agents avec lesquels vous pouvez interagir individuellement, et qui agissent également comme des blocs de construction que vous pouvez personnaliser pour créer vos propres agents. Comme les membres de votre équipe, les agents ont des spécialisations définies, telles que le développement logiciel, les tests ou la rédaction technique. En tant que spécialistes, ils exploitent les bons contextes et outils pour accomplir de manière cohérente les mêmes types de tâches, où qu'ils soient déployés.\n\nVoici quelques-uns des agents que nous construisons aujourd'hui :\n\n* **Chat Agent (maintenant en version bêta) :** il prend des requêtes en langage naturel pour fournir des informations et du contexte à l'utilisateur. Il peut effectuer des tâches de développement générales, comme la lecture de tickets ou de différences de code. Par exemple, vous pouvez demander à Chat de déboguer un job qui a échoué en fournissant son URL. \n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953504?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-in-web-ui-demo_Update V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Software Developer Agent (maintenant en version bêta) :** il travaille sur des éléments assignés en créant des modifications de code dans des environnements de développement virtuels et en ouvrant des merge requests pour révision.\n\n* **Product Planning Agent :** il priorise les backlogs produit, assigne des éléments de travail aux membres humains et agentiques et l'équipe, et fournit des mises à jour de projet en fonction du calendrier.\n\n* **Software Test Engineer Agent :** il teste les nouvelles contributions de code pour les bogues et valide si les problèmes signalés ont été résolus.\n\n* **Code Reviewer Agent :** il effectue des revues de code suivant les normes de l'équipe, identifie les problèmes de qualité et de sécurité, et peut fusionner le code quand il est prêt.\n\n* **Platform Engineer Agent :** il surveille les déploiements GitLab, y compris les GitLab Runners, suit la santé du pipeline CI/CD, et rapporte les problèmes de performance aux équipes d'ingénierie de plateforme humaines.\n\n* **Security Analyst Agent :** il trouve des vulnérabilités dans le code source et les applications déployées, et implémente des modifications de code et de configuration pour aider à résoudre les faiblesses de sécurité.\n\n* **Deployment Engineer Agent :** il déploie des mises à jour en production, surveille les comportements inhabituels, et annule les modifications qui impactent les performances ou la sécurité de l'application.\n\n* **Deep Research Agent :** il mène une analyse complète et multi-sources à travers tout votre écosystème de développement.\n\nCe qui rend ces agents puissants, c'est leur accès natif à la boîte à outils complète de GitLab. Aujourd'hui, nous avons plus de 25 outils, des tickets et epics aux merge requests et à la documentation, et bien plus à venir. Contrairement aux outils d’IA externes qui fonctionnent avec un contexte limité, nos agents travaillent comme de véritables membres de l'équipe avec des privilèges complets de plateforme sous votre supervision.\n\nDans les mois à venir, vous pourrez également modifier ces agents pour répondre aux besoins de votre organisation. Par exemple, vous pourrez spécifier qu'un Software Test Engineer Agent suit les meilleures pratiques pour un framework ou une méthodologie particulière, approfondissant sa spécialisation et le transformant en un membre d'équipe encore plus précieux.\n\n## Les Flows orchestrent des tâches d'agents complexes\n\nAu-dessus des agents individuels, nous introduisons les Flows d'agents. Considérez-les comme des workflows plus complexes qui peuvent inclure plusieurs agents avec des instructions, étapes et actions pré-construites pour une tâche donnée qui peut s'exécuter de manière autonome.\n\nBien que vous puissiez créer des Flows pour des tâches de base communes aux individus, ils excellent vraiment lorsqu'ils sont appliqués à des tâches complexes et spécialisées qui prendraient normalement des heures de coordination et d'effort pour être complétées. Les Flows vous aideront à terminer des tâches complexes plus rapidement et, dans de nombreux cas, de manière asynchrone sans intervention humaine.\n\nLes Flows ont des déclencheurs spécifiques pour l'exécution. Chaque Flow contient une série d'étapes, et chaque étape a des instructions détaillées qui indiquent à un agent spécialisé quoi faire. Cette approche granulaire vous permet de donner des instructions précises aux agents dans le Flow. En définissant des instructions avec plus de détails et en établissant des points de décision structurés, les Flows peuvent aider à résoudre la variabilité inhérente aux réponses d'IA tout en éliminant le besoin de spécifier les mêmes exigences, débloquant des résultats plus cohérents et prévisibles sans configuration de la part de l'utilisateur.\n\nVoici quelques exemples de Flows prêts à l'emploi :\n\n**Flow de développement logiciel (maintenant en version bêta) :** il orchestre plusieurs agents pour planifier, implémenter et tester des modifications de code de bout en bout, aidant à transformer la façon dont les équipes livrent des fonctionnalités, du concept à la production.\n\n**Flow Issue-to-MR :** il convertit automatiquement les tickets en merge requests exploitables en coordonnant les agents pour analyser les exigences, préparer des plans de mise en œuvre complets et générer du code.\n\n**Flow de conversion de fichier CI :** il rationalise les workflows de migration en demandant aux agents d'analyser les configurations CI/CD existantes et de les convertir intelligemment au format GitLab CI avec une compatibilité complète du pipeline.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n**Flow de recherche et remplacement :** il découvre et transforme des modèles de code à travers le code source en analysant systématiquement les structures de projet, identifiant les opportunités d'optimisation et exécutant des remplacements précis.\n\n**Flow de réponse aux incidents et analyse des causes profondes :** il orchestre la réponse aux incidents en corrélant les données système, coordonnant des agents spécialisés pour l'analyse des causes profondes et exécutant les étapes de remédiation approuvées tout en gardant les parties prenantes humaines informées tout au long du processus de résolution.\n\nC'est là que GitLab Duo Agent Platform adopte une approche vraiment unique par rapport aux autres solutions d’IA. Nous ne vous donnerons pas seulement des agents pré-construits. Nous vous donnerons également le pouvoir de créer, personnaliser et partager des Flows d'agents qui correspondent parfaitement aux besoins de vos équipes et de votre organisation. Avec les Flows, vous pourrez ensuite donner aux agents un plan d'exécution spécifique pour des tâches communes et complexes.\n\nNous croyons que cette approche est plus puissante que de construire des agents spécialisés comme le font nos concurrents, car chaque organisation a des workflows différents, des normes de codage, des exigences de sécurité et une logique métier. Les outils d’IA génériques ne peuvent pas comprendre votre contexte spécifique, mais GitLab Duo Agent Platform s’adaptera au fonctionnement de votre équipe.\n\n## Pourquoi construire des agents et des Flows d'agents dans GitLab Duo Agent Platform ?\n\n**Construire rapidement.** Vous pouvez construire des agents et des Flows d'agents complexes dans Duo Agent Platform rapidement et facilement en utilisant un modèle d'extensibilité déclaratif rapide et une assistance UI.\n\n**Calcul intégré.** Avec Duo Agent Platform, vous n'avez plus à vous soucier des tracas de mise en œuvre de votre propre infrastructure pour les agents : le calcul, le réseau et le stockage sont intégrés.\n\n**Événements SDLC.** Vos agents peuvent être invoqués automatiquement sur des événements communs : pipeline en échec, déploiement interrompu, problème créé, etc.\n\n**Accès instantané.** Vous pouvez interagir avec vos agents dans GitLab ou au sein de notre plug-in IDE : assignez-leur des tickets, @mentionnez-les dans les commentaires et discutez avec eux partout où GitLab Duo Chat est disponible.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**Modèles intégrés et personnalisés pris en charge.** Vos agents auront un accès automatique à tous les modèles que nous prenons en charge, et les utilisateurs pourront choisir des modèles spécifiques pour des tâches spécifiques. Si vous souhaitez connecter Duo Agent Platform à votre propre modèle auto-hébergé, vous pourrez également le faire. \n\n**Points de terminaison MCP.** Chaque agent et Flow peut être accessible ou déclenché via des points de terminaison MCP natifs, vous permettant de vous connecter et de collaborer avec vos agents et vos Flows de n'importe où, y compris des outils populaires comme Claude Code, Cursor, Copilot et Windsurf.\n\n**Observabilité et sécurité.** Enfin, nous fournissons une observabilité intégrée et des tableaux de bord d'utilisation, afin que vous puissiez voir exactement qui, où, quoi et quand les agents ont effectué des actions en votre nom.\n\n## Un avenir piloté par la communauté\n\nLes contributions de la communauté ont longtemps alimenté l'innovation et le développement logiciel de GitLab. Nous sommes ravis de nous associer à notre communauté avec l'introduction du Catalogue IA. Le Catalogue IA vous permettra de créer et de partager des agents et des Flows au sein de votre organisation et à travers l'écosystème GitLab dans notre prochaine version bêta.\n\nNous croyons que les applications d’IA les plus précieuses sont susceptibles d'émerger de notre communauté, grâce à votre usage quotidien de GitLab Duo Agent Platform pour résoudre de nombreux cas d'utilisation du monde réel. En permettant le partage transparent d'agents et de Flows, nous créons un effet de réseau où chaque contribution améliore l'intelligence et la valeur collectives de la plateforme.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## Disponible aujourd'hui dans GitLab Duo Agent Platform en bêta publique\n\nLa version bêta publique de GitLab Duo Agent Platform est disponible dès maintenant pour les clients Premium et Ultimate avec les fonctionnalités suivantes :\n\n**Flow de Développement Logiciel :** notre premier Flow orchestre des agents pour rassembler un contexte complet, clarifier les ambiguïtés avec les équipes de développement humaines et exécuter des plans stratégiques pour apporter des modifications précises à votre code source et votre dépôt. Il exploite l'ensemble de votre projet, y compris sa structure, son code source et son historique, ainsi que des contextes supplémentaires comme les tickets GitLab ou les merge requests pour amplifier la productivité des équipes de développement.\n\n**Nouveaux outils d'agent disponibles :** les agents ont maintenant accès à plusieurs outils pour faire leur travail, notamment :\n\n* Système de fichiers (lire, créer, éditer, trouver des fichiers, lister, Grep)\n* Exécuter la ligne de commande*\n* Tickets (lister, obtenir, obtenir les commentaires, éditer*, créer*, ajouter/mettre à jour les commentaires*)\n* Epics (obtenir, obtenir les commentaires)\n* Merge requests (obtenir, obtenir les commentaires, obtenir le diff, créer, mettre à jour)\n* Pipeline (job logs, erreurs de pipeline)\n* Projet (obtenir, obtenir le fichier)\n* Commits (obtenir, lister, obtenir les commentaires, obtenir le diff)\n* Recherche (recherche de problèmes)\n* Sécurisé (lister les vulnérabilités)\n* Recherche de documentation\n  *=Nécessite l'approbation de l'utilisateur\n\n**GitLab Duo Agentic Chat dans l'IDE :** Duo Agentic Chat transforme l'expérience de chat d'un outil de questions-réponses passif en un partenaire de développement actif directement dans votre IDE.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953477?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-ai-launch-video_Updated V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Retour itératif et historique de chat :** Duo Agentic Chat prend désormais en charge l'historique de chat et le retour itératif, transformant l'agent en un partenaire conversationnel. Cela favorise la confiance, permettant aux équipes de développement de déléguer des tâches plus complexes et d'offrir des conseils correctifs.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Délégation rationalisée avec des commandes slash :** des commandes slash étendues et plus puissantes, telles que /explain, /tests et /include, créent un « langage de délégation » pour une intention rapide et précise. La commande /include permet l'injection explicite de contexte à partir de fichiers spécifiques, de tickets ouverts, de merge requests ou de dépendances directement dans la mémoire de travail de l'agent, rendant l'agent plus puissant et enseignant aux utilisateurs comment fournir un contexte optimal pour des réponses de qualité.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Personnalisation via des règles personnalisées :** les nouvelles règles personnalisées permettent aux équipes de développement d'adapter le comportement de l'agent en fonction de leurs préférences en utilisant le langage naturel, par exemple, des guides de style de développement. Ce mécanisme façonne la personnalité de l'agent en un assistant personnalisé, évoluant vers des agents spécialisés basés sur les préférences définies par l'utilisateur et les politiques organisationnelles.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Support pour GitLab Duo Agentic Chat dans JetBrains IDE :** Pour aider à rencontrer les développeurs là où ils travaillent, nous avons étendu la prise en charge de Duo Agentic Chat à la famille d'IDE JetBrains, y compris IntelliJ, PyCharm, GoLand et Webstorm. Cela s'ajoute à notre support existant pour VS Code. Les utilisateurs existants obtiennent automatiquement les fonctionnalités agentiques, tandis que les nouveaux utilisateurs peuvent installer le plugin depuis le JetBrains Marketplace.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Support client MCP :** Duo Agentic Chat peut maintenant agir comme client MCP, se connectant aux serveurs MCP distants et locaux.\n\nCette fonctionnalité débloque la capacité de l'agent à se connecter à des systèmes au-delà de GitLab comme Jira, ServiceNow et ZenDesk pour rassembler du contexte ou prendre des mesures. Tout service qui s'expose via MCP peut maintenant faire partie de l'ensemble de compétences de l'agent. Le serveur MCP officiel GitLab arrive bientôt !\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **GitLab Duo Agentic Chat dans l'interface Web de GitLab.** Duo Agentic Chat est maintenant disponible directement dans l'interface Web de GitLab. Cette étape fait évoluer l'agent d'un assistant de codage à un véritable agent DevSecOps, car il accède à un contexte riche non lié au code, comme les tickets et les discussions intégrées aux merge requests, lui permettant de comprendre le « pourquoi » derrière une tâche. Au-delà de la compréhension du contexte, l'agent peut apporter des modifications directement depuis l'interface Web, comme mettre à jour automatiquement les statuts des tickets ou éditer les descriptions des merge requests.\n\n## Bientôt disponible dans GitLab Duo Agent Platform\n\nAu cours des prochaines semaines, nous publierons de nouvelles capacités pour Duo Agent Platform, y compris plus d'agents et de Flows prêts à l'emploi. Celles-ci permettront une personnalisation et une extensibilité encore plus grandes, amplifiant la productivité de nos clients : \n\n![GitLab Duo Agent Platform public beta roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform public beta roadmap\")\n\n* **Expérience GitLab intégrée :** s'appuyant sur les extensions IDE disponibles dans 18.2, nous étendons les agents et les Flows au sein de la plateforme GitLab. Cette intégration élargira la manière dont vous pouvez collaborer de manière synchrone et asynchrone avec les agents. Vous pourrez assigner des tickets directement aux agents, les @mentionner dans GitLab Duo Chat, et les invoquer de manière transparente depuis n'importe où dans l'application tout en maintenant la connectivité MCP depuis votre outil de développement préféré. Cette intégration native transforme les agents en véritables membres de l'équipe de développement, accessibles dans GitLab.\n\n* **Observabilité des agents :** alors que les agents deviennent plus autonomes, nous construisons une visibilité complète de leur activité pendant qu'ils progressent dans les Flows, vous permettant de surveiller leurs processus de prise de décision, de suivre les étapes d'exécution et de comprendre comment ils interprètent et agissent sur vos défis liés au développement. Cette transparence dans le comportement des agents renforce la confiance tout en vous permettant d'optimiser les workflows, d'identifier les goulots d'étranglement et aide à garantir que les agents fonctionnent comme prévu.\n\n* **Catalogue IA :** reconnaissant que les grandes solutions viennent de l'innovation communautaire, nous introduirons bientôt la bêta publique de notre Catalogue IA — une marketplace qui vous permettra d'étendre Duo Agent Platform avec des agents et des Flows spécialisés provenant de GitLab, et au fil du temps, de la communauté. Vous pourrez déployer rapidement ces solutions dans GitLab, en exploitant le contexte à travers vos projets et votre code source.\n\n* **Graphe de connaissances :** exploitant l'avantage unique de GitLab en tant que système d'enregistrement pour le code source et son contexte environnant, nous construisons un graphe de connaissances complet qui non seulement cartographie les fichiers et les dépendances à travers le code source, mais rend également cette carte navigable pour les utilisateurs tout en accélérant les temps de requête IA et en aidant à augmenter la précision. Cela permet aux agents GitLab Duo de comprendre rapidement les relations à travers tout votre environnement de développement, des dépendances de code aux modèles de déploiement, débloquant des réponses plus rapides et plus précises aux questions complexes.\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n* **Créer et éditer des agents et des Flows :** comprenant que chaque organisation a des workflows et des exigences uniques, nous développons de puissantes capacités de création et d'édition d'agents et de Flows qui seront introduites à mesure que le Catalogue IA mûrit. Vous pourrez créer et modifier des agents et des Flows pour qu'ils fonctionnent précisément comme votre organisation, offrant une personnalisation à travers Duo Agent Platform qui permet des résultats de meilleure qualité et une productivité accrue.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n* **Serveur MCP officiel GitLab :** reconnaissant que les développeurs travaillent à travers plusieurs outils et environnements, nous construisons un serveur MCP officiel GitLab qui vous permettra d'accéder à tous vos agents et Flows via MCP. Vous pourrez vous connecter et collaborer avec vos agents et vos Flows quel que soit l'endroit oú le MCP est pris en charge, y compris depuis des outils populaires comme Claude Code, Cursor, Copilot et Windsurf, débloquant une collaboration IA transparente quel que soit votre environnement de développement préféré.\n\n* **GitLab Duo Agent Platform CLI :** notre interface de ligne de commande à venir vous permettra d'invoquer des agents et de déclencher des Flows en ligne de commande, en exploitant le contexte riche de GitLab à travers l'ensemble du cycle de vie du développement logiciel : des dépôts de code et des merge requests aux pipelines CI/CD et au suivi des tickets.\n\n## Testez notre bêta publique dès aujourd'hui !\n\n* **Les clients GitLab Premium et Ultimate** dans les environnements GitLab.com et GitLab Self-Managed utilisant GitLab 18.2 peuvent utiliser Duo Agent Platform immédiatement (les fonctionnalités bêta et expérimentales pour GitLab Duo [doivent être activées](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)).\n\n* Les utilisateurs doivent télécharger l'[extension VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) ou le [plugin JetBrains IDEs](https://plugins.jetbrains.com/plugin/22857-gitlab) et suivre notre [guide pour utiliser GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat), y compris les [commandes slash](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands) Duo Chat.\n\n**Nouveau sur GitLab ?** Tout le monde peut rejoindre notre prochaine [démo Technique pour découvrir GitLab Duo Agent Platform](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html) en action. Pour avoir une expérience pratique avec GitLab Duo Agent Platform, inscrivez-vous pour un [essai gratuit](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F) aujourd'hui.\n\n\u003Csmall>*Cet article de blog contient des « déclarations prospectives » au sens de la Section 27A du Securities Act de 1933, tel que modifié, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans les déclarations prospectives contenues dans cet article de blog sont raisonnables, elles sont soumises à des risques connus et inconnus, des incertitudes, des hypothèses et d'autres facteurs qui peuvent faire que les résultats ou les issues réels soient matériellement différents de tout résultat ou issue futur exprimé ou impliqué par les déclarations prospectives.*\n\n*Des informations supplémentaires sur les risques, incertitudes et autres facteurs qui pourraient faire que les résultats et les issues réels diffèrent matériellement de ceux inclus ou envisagés par les déclarations prospectives contenues dans cet article de blog sont incluses sous la rubrique « Facteurs de risque » et ailleurs dans les dépôts et rapports que nous faisons auprès de la Securities and Exchange Commission. Nous ne nous engageons pas à mettre à jour ou à réviser toute déclaration prospective ou à signaler tout événement ou circonstance après la date de cet article de blog ou à refléter la survenance d'événements imprévus, sauf si la loi l'exige.*\u003C/small>",{"featured":91,"template":806,"slug":846},"gitlab-duo-agent-platform-public-beta",{"content":848,"config":858},{"title":849,"description":850,"authors":851,"heroImage":853,"date":854,"body":855,"category":686,"tags":856},"Améliorer la qualité des applications avec la génération de tests alimentée par l'IA","Découvrez comment GitLab Duo combiné à Amazon Q améliore le processus d'assurance qualité en générant automatiquement des tests unitaires complets.",[852],"Cesar Saavedra","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749659604/Blog/Hero%20Images/Screenshot_2024-11-27_at_4.55.28_PM.png","2025-07-15","Vous savez à quel point la qualité des applications est essentielle pour vos clients et votre réputation. Cependant, garantir cette qualité avec des tests complets peut s’avérer complexe. Vous êtes confronté à des processus manuels chronophages, une couverture de test incohérente au sein de votre équipe, ou des problèmes qui parviennent à passer à travers les mailles du filet. Il est ainsi frustrant de voir votre notation chuter à cause d’une assurance qualité qui devient un goulot d'étranglement plutôt qu'une protection.\n\nC'est là que [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) peut transformer votre processus d’assurance qualité. Cette fonctionnalité alimentée par l'IA peut générer automatiquement des tests unitaires complets pour votre code, accélérant considérablement votre workflow d'assurance qualité. Au lieu de passer des heures à écrire des tests manuellement, vous pouvez laisser l'IA analyser votre code et créer des tests qui garantissent une couverture optimale et une qualité constante au sein de votre application.\n\n## Comment fonctionne GitLab Duo combiné à Amazon Q ?\n\nLorsque vous travaillez sur une nouvelle fonctionnalité, vous commencez par sélectionner la classe Java que vous avez ajoutée à votre projet via une merge request. Il vous suffit de naviguer vers votre merge request et de cliquer sur l'onglet « Modifier » pour voir le nouveau code que vous avez ajouté.\n\nEnsuite, vous invoquez Amazon Q en saisissant une commande d'action rapide. Tout ce que vous devez faire est de renseigner `/q test` dans la zone de commentaire du ticket. C'est aussi simple que cela : juste une barre oblique, la lettre « q », et le mot « test ».\n\nUne fois que vous avez appuyé sur la touche Entrée, Amazon Q entre en action. Il analyse votre code sélectionné, comprend sa structure, sa logique et son objectif. L'IA examine les méthodes de votre classe, les dépendances, et les cas limites potentiels pour déterminer quels tests sont nécessaires.\n\nEn quelques instants, Amazon Q génère une couverture de tests unitaires complète pour votre nouvelle classe. Il crée des tests qui couvrent non seulement le chemin heureux (« happy path »), mais aussi les cas limites et les conditions d'erreur que vous auriez pu négliger. Les tests générés suivent les modèles et conventions existants de votre projet, garantissant qu'ils s'intègrent parfaitement à votre code source.\n\n## Pourquoi utiliser GitLab Duo combiné à Amazon Q ?\n\nVous avez commencé avec le défi suivant : maintenir des applications de haute qualité tout en gérant les contraintes de temps et les pratiques de test incohérentes. GitLab Duo combiné à Amazon Q répond à ce défi en automatisant le processus de génération de tests, garantissant une couverture de code optimale et des normes de test cohérentes. Résultat ? Les problèmes sont détectés avant le déploiement, vos applications maintiennent leur qualité, et vous pouvez développer des logiciels plus rapidement sans sacrifier la fiabilité.\n\nAvantages clés de cette fonctionnalité :\n\n* Une réduction du temps consacré à l'écriture de tests unitaires\n* Une couverture de tests complète sur l'ensemble de votre code source\n* Une qualité de tests constante pour tous les membres de votre équipe\n* Une détection des problèmes avant qu'ils n'atteignent l’environnement de production\n* Une accélération de votre vitesse de développement\n\nVous souhaitez en savoir plus sur cette fonctionnalité ? Découvrez comment GitLab Duo combiné à Amazon Q transforme votre processus d'assurance qualité et consultez notre [page partenaire GitLab et AWS](https://about.gitlab.com/partners/technology-partners/aws/ \"Page partenaire GitLab et AWS\") pour obtenir des informations détaillées.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/pxlYJVcHY28?si=MhIz6lnHxc6kFhlL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### En savoir plus sur GitLab Duo combiné à Amazon Q\n\n* [GitLab Duo combiné à Amazon Q : quand le DevSecOps rencontre l’IA agentique](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai/)\n* [GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS disponible à tous les utilisateurs](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n* [GitLab Duo combiné à Amazon Q : créez de nouvelles fonctionnalités en quelques minutes](https://about.gitlab.com/fr-fr/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/) \n* [GitLab Duo combiné à Amazon Q : optimisez vos revues de code](https://about.gitlab.com/fr-fr/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q/)",[837,857,718],"AWS",{"featured":6,"template":806,"slug":859},"enhance-application-quality-with-ai-powered-test-generation",{"content":861,"config":869},{"heroImage":862,"date":863,"title":864,"description":865,"authors":866,"body":867,"category":686,"tags":868},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750687578/esmflevxk5bf3eezjhwk.png","2025-07-03","GitLab Duo Agent Platform : le DevSecOps intelligent","La plateforme DevSecOps GitLab Duo Agent Platform orchestre la collaboration entre développeurs et agents d'IA tout au long du SDLC avec l'IA agentique.",[841],"Découvrez GitLab Duo Agent Platform, la prochaine évolution de GitLab Duo Workflow : cette plateforme innovante étend les fonctionnalités d'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\") à l'ensemble du cycle de développement logiciel et permet aux équipes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") de travailler en parallèle avec plusieurs agents d'IA spécialisés.\n\nVoici à quoi pourrait ressembler une de vos journées de travail :\n\n* Vous demandez à un agent d'IA d'étudier en détail un epic en cours, de résumer les contributions de la semaine précédente et de suggérer une publication pour annoncer les dernières fonctionnalités.\n* En parallèle, vous déléguez à plusieurs autres agents d'IA l'analyse de bogues d'accessibilité en leur demandant d'appliquer directement les corrections nécessaires dans le code.\n* Pendant ce temps, un autre agent d'IA relit vos modifications complexes et vous fournit des commentaires et suggestions avant une revue de code en bonne et due forme par un membre de votre équipe.\n* Enfin, lorsque l'équipe de sécurité vous signale une nouvelle vulnérabilité qui doit faire l'objet d'une investigation dans l'ensemble de votre projet, vous confiez cette tâche à votre agent d'IA dédié à la sécurité.\n\nToutes ces opérations sont exécutées simultanément pour vous aider à vous concentrer sur des tâches à forte valeur ajoutée : décisions d'architecture, résolution créative de problèmes et travail technique stratégique. Avec GitLab Duo Agent Platform, vous pouvez déléguer des tâches à cinq, dix, voire cent agents spécialisés, qui disposent tous du contexte complet de votre projet : votre code, les job logs CI, les tâches de planification, et bien plus encore. Vous automatisez ainsi vos tâches fastidieuses afin de pouvoir vous concentrer sur le travail qui vous passionne vraiment.\n\n**Il ne s'agit pas là de remplacer les équipes de développement, mais d'amplifier leur créativité et leur expertise en éliminant les points de friction liés aux tâches routinières.** C'est l'avenir que nous façonnons avec GitLab Duo Agent Platform.\n\n## Qu'est-ce que GitLab Duo Agent Platform ?\n\nGitLab Duo Agent Platform facilite la collaboration entre plusieurs équipes de développement et agents d'IA tout au long du cycle du développement logiciel, afin de les aider à améliorer considérablement leur productivité et à réduire la durée de leurs cycles de livraison.\n\nReposant sur la base sécurisée de GitLab, GitLab Duo Agent Platform est personnalisable et extensible. La plateforme permet aux équipes de développement de créer des agents capables de résoudre toutes sortes de problématiques d'ingénierie logicielle, en tirant parti du contexte global du projet à chaque étape du développement logiciel.\n\nGitLab Duo Agent Platform ne se limite pas à la création de code. La plateforme propose des agents spécialisés et des workflows personnalisés qui peuvent vous aider à réaliser une liste presque illimitée de tâches, notamment :\n\n* L'implémentation de tickets\n* Les migrations à grande échelle/mises à niveau des dépendances\n* La rédaction automatique de documentations et de publications pour annoncer la sortie de nouvelles fonctionnalités\n* La réparation de [pipelines en échec](https://about.gitlab.com/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/ \"Echec de pipeline\")\n* La recherche assistée lors d'incidents\n* La recherche approfondie de statuts et d'informations sur différents sujets\n* La gestion du backlog\n* La résolution de vulnérabilités\n* Les revues de certains types de code spécifiques (p. ex., base de données)\n* La création rapide d'outils internes à partir des composants déjà disponibles\n* Et plus encore !\n\nVous pourrez utiliser nos agents prêts à l'emploi, mais aussi les personnaliser et enrichir leurs capacités. Nous testons actuellement la version bêta de GitLab Duo Agent Platform avec l'aide de dizaines de clients et nous ouvrirons bientôt l'accès à d'autres équipes.\n\nDécouvrez une démonstration de GitLab Duo Agent Platform :\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1095679084?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Platform Demo Clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Outils, modèles et agents : à vous de choisir\n\nConformément à notre engagement de proposer une plateforme ouverte, les agents GitLab interagissent de manière fluide avec les outils d'écriture de code de votre choix via les protocoles Model Context Protocol (MCP) et Agent2Agent (A2A), que vous utilisiez Cursor, Claude Code, Windsurf, OpenAI Codex ou d'autres.\n\nLa plateforme accepte les contributions de code de n'importe quel outil de développement de votre pile, que ce code ait été écrit par un développeur ou généré par un agent d'IA. Vos workflows existants et vos outils préférés continueront à fonctionner de manière homogène lorsque vous intégrerez les fonctionnalités agentiques.\n\nGitLab Duo Agent Platform fonctionne avec les modèles de langage approuvés qui [répondent à nos critères de sélection](https://about.gitlab.com/fr-fr/ai-transparency-center/#ai-continuity-plan). Pour les entreprises qui ont des exigences strictes en matière de sécurité, la plateforme prend en charge les modèles de GitLab Duo Self-Hosted approuvés qui s'exécutent dans des environnements air-gapped. Vos exigences en matière d'infrastructure et vos règles de sécurité ne limiteront pas votre capacité à tirer parti du développement agentique.\n\n## Le contexte fait la différence, vos agents GitLab Duo aussi\n\nLa différence entre un outil d'IA utile et un agent véritablement intelligent se résume au contexte. Avec GitLab Duo Agent Platform, les agents ne travaillent pas de manière isolée : ils sont profondément intégrés à la plateforme de développement.\n\nChaque agent comprend automatiquement la vue d'ensemble de vos projets, y compris vos tickets ouverts et leur historique, les merge requests qui les ont résolus, la structure et la logique de votre code, la configuration de vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), les risques de sécurité détectés, les exigences de conformité ainsi que les relations complexes entre tous ces éléments.\n\nTout comme les membres de votre équipe, les agents disposent de tout le contexte nécessaire pour vous aider à livrer des logiciels sécurisés plus rapidement. Ils ne se contentent pas de répondre à des questions sur le code, ils sont également en mesure de fournir des analyses sur l'impact potentiel d'un changement sur votre pipeline de déploiement ou de suggérer des améliorations de sécurité en fonction de vos règles de conformité. Plus votre équipe travaillera au sein de la plateforme DevSecOps de GitLab, plus vos agents deviendront intelligents.\n\n## Des équipes plus productives avec les agents d'IA\n\nIl est presque aussi simple d'établir un climat de confiance avec les agents d'IA qu'avec les nouveaux membres d'une équipe. Vous devez tout d'abord vérifier leur travail, puis comprendre leur approche et enfin augmenter progressivement leurs responsabilités à mesure qu'ils prouvent leurs compétences.\n\nC'est ainsi que nous avons pensé notre workflow d'approbation des agents. Avant qu'un agent apporte des modifications à votre code ou à votre environnement, il vous présentera un plan clair : sa compréhension du problème, l'approche qu'il prévoit d'adopter et les actions spécifiques qu'il souhaite effectuer. Vous aurez ensuite la possibilité d'examiner l'approche qu'il aura choisie, de l'approuver ou de donner de nouvelles instructions si nécessaire. Au fil du temps, les agents fourniront un travail de plus en plus qualitatif, vous pourrez leur accorder une plus grande autonomie pour la réalisation des tâches répétitives, tout en continuant à superviser les tâches complexes ou critiques.\n\n## Une plateforme conçue pour la communauté et adaptée à vos besoins\n\nGitLab a toujours évolué grâce aux contributions de sa communauté. Cette année, nous avons franchi une étape importante, car les contributions de nos clients ont atteint un niveau record. Nous étendons désormais cette même énergie collaborative aux agents d'IA grâce à notre approche de framework ouvert.\n\nGitLab Duo Agent Platform ne se limite pas aux agents que nous créons, mais vous donne, à vous ainsi qu'à la communauté au sens large, les moyens de créer des agents spécialisés capables de résoudre vos défis d'ingénierie uniques. Que vous ayez besoin d'un agent qui comprend vos normes de codage spécifiques, qui s'intègre à votre chaîne d'outils personnalisée ou qui gère des tâches propres à votre domaine, la plateforme vous fournira les éléments de base nécessaires pour y parvenir.\n\nCe modèle crée un cercle vertueux qui tire parti de la force de la communauté GitLab grâce au partage mondial, à l'instar de notre [catalogue CI/CD](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/). La diversité des expériences de nos clients est source d'innovation. Les retours que nous recevons des entreprises renforcent la fiabilité et la sécurité. Et les solutions partagées profitent à tous. C'est cette même approche collaborative qui a fait le succès de GitLab et qui s'applique désormais au développement agentique.\n\n## Premiers pas avec GitLab Duo Agent Platform\n\nSi vous avez testé [GitLab Duo Agentic Chat](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/), désormais inclus dans chaque licence utilisateur GitLab.com GitLab 18 Premium et Ultimate, vous avez déjà eu un aperçu des possibilités offertes par l'utilisation d'agents d'IA dans votre workflow de développement.\n\nPour découvrir les capacités de GitLab Duo Agent Platform et les projets sur lesquels nous travaillons actuellement, visionnez les [démonstrations incluses dans notre événement de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/).\n\nVous souhaitez être parmi les premiers à l'essayer ? Inscrivez-vous sur la [liste d'attente de la version bêta de GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/agent-platform/). Cet été, nous ouvrirons l'accès à d'autres équipes. De nouvelles fonctionnalités d'agent sortiront tout au long de l'année dans les prochaines versions de GitLab 18. Nous prévoyons de proposer GitLab Duo Agent Platform en disponibilité générale cet hiver.\n\n*Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter que celles-ci ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article sont susceptibles de changer ou d'être retardés. Le développement, la sortie et le calendrier de tout produit ou de toute fonctionnalité restent à la seule discrétion de GitLab Inc.*\n\n## En savoir plus\n\n- [Du vibe coding à l'IA agentique : une roadmap pour les responsables techniques](https://about.gitlab.com/the-source/ai/from-vibe-coding-to-agentic-ai-a-roadmap-for-technical-leaders/)\n\n- [Automatisation DevOps et agents d'IA](https://about.gitlab.com/topics/agentic-ai/devops-automation-ai-agents/)\n\n- [Développement logiciel augmenté par l'IA : l'IA agentique dédiée au DevOps](https://about.gitlab.com/topics/agentic-ai/ai-augmented-software-development/)\n\n- [Analyse de code pilotée par l'IA pour une sécurité renforcée](https://about.gitlab.com/topics/agentic-ai/ai-code-analysis/)\n",[837,718,746,769],{"featured":6,"template":806,"slug":870},"gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"category":694,"slug":698,"posts":872},[873],{"content":874,"config":883},{"title":875,"description":876,"authors":877,"heroImage":822,"date":879,"body":880,"category":698,"tags":881,"updatedDate":882},"Nouvelles limites de Docker Hub : vos pipelines GitLab CI/CD sont impactés","Les nouvelles limites de Docker Hub relatives aux pulls d'images vont affecter les pipelines GitLab. Voici ce qu'il faut savoir.",[878],"Tim Rizzi","2025-03-24","Le 1er avril 2025, Docker va mettre en place de nouvelles [limites de débit relatives aux pulls d'images](https://docs.docker.com/docker-hub/usage/) sur Docker Hub, susceptibles d'impacter de manière significative les pipelines CI/CD de développement logiciel, y compris ceux qui s'exécutent sur GitLab. Le changement le plus notable : un plafond fixé à 10 pulls d'images par heure pour les utilisateurs non authentifiés.\n\n## Quels sont les changements attendus ?\n\nÀ compter du 1er avril, Docker va appliquer les limites strictes suivantes aux pulls d'images (téléchargements d'images) :\n\n| Type d'utilisateur | Limite de pulls d'images par heure | Nombre de dépôts publics | Nombre de dépôts privés |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business, Team, Pro (authentifié) | Illimité (utilisation raisonnable) | Illimité | Illimité |\n| Personal (authentifié) | 100 | Illimité | Jusqu'à 1 |\n| Utilisateurs non authentifiés | 10 par adresse IPv4 ou sous-réseau IPv6/64 | Non applicable | Non applicable |\n\nCes nouveaux quotas sont particulièrement importants pour les raisons suivantes :\n- Le proxy de dépendances de GitLab effectue actuellement des pulls à partir de Docker Hub en tant qu'utilisateur non authentifié.\n- La plupart des pipelines CI/CD qui n'utilisent pas le proxy de dépendances effectuent des pulls directement à partir de Docker Hub en tant qu'utilisateurs non authentifiés.\n- Pour les runners hébergés sur GitLab.com, le partage d'une même adresse IP ou sous-réseau par plusieurs utilisateurs les soumet collectivement à cette limite.\n\n## Quel impact sur les utilisateurs de GitLab ?\n\n**Impact sur les pulls directs depuis Docker Hub**\n\nSi vos pipelines CI/CD effectuent des pulls directement depuis Docker Hub sans authentification, ils seront limités à 10 pulls d'images par heure et par adresse IP. Dans le cas de pipelines exécutés fréquemment ou sur plusieurs projets partageant la même infrastructure de runner, cette limite sera rapidement atteinte, ce qui entraînera des échecs de pipeline.\n\n**Impact sur le proxy de dépendances de GitLab**\n\nLa fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache des images Docker dans GitLab pour accélérer les pipelines et réduire la dépendance aux registres externes. Cependant, dans sa version actuelle, ce proxy effectue des pulls d'images depuis Docker Hub en tant qu'utilisateur non authentifié, ce qui signifie qu'il est lui aussi soumis à la limite des 10 pulls d'images par heure.\n\n**Impact sur les runners hébergés**\n\nSur GitLab.com, les runners hébergés s'appuient sur le [cache pull-through de Google Cloud](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=fr), qui met en miroir les images fréquemment téléchargées. Cela permet d'éviter les limites de débit, comme pour les images de job définies comme `image:` ou `services:` dans votre fichier `.gitlab-ci.yml`.\n\nTout se complique légèrement lorsque les images sont téléchargées dans l'environnement du runner. Le cas le plus courant de pull d'images pendant l'exécution du runner concerne la création d'une image à l'aide de Docker-in-Docker ou de Kaniko. Dans ce scénario, l'image Docker Hub définie dans votre `Dockerfile` fait l'objet d'un pull directement depuis Docker Hub. Elle est donc susceptible d'être affectée par les limites de débit. \n\n## Comment GitLab répond à ces nouveaux quotas ?\n\nNous travaillons activement à la recherche de solutions pour atténuer les impacts liés à ces nouvelles limites :\n\n* **Authentification du proxy de dépendances :** nous avons ajouté la prise en charge de l'authentification Docker Hub dans la [fonctionnalité de proxy de dépendances de GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/331741). Cela permettra à ce dernier de télécharger des images depuis Docker Hub en tant qu'utilisateur authentifié, et ainsi d'augmenter considérablement les limites de débit.  \n* **Mise à jour de la documentation :** nous avons actualisé notre [documentation](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials) afin de fournir des instructions claires sur la configuration de l'authentification des pipelines pour Docker Hub.\n* **Préparation de l'infrastructure interne :** nous préparons notre infrastructure GitLab.com afin de réduire au maximum l'impact de ces limites sur les runners hébergés.\n\n## Comment s'y préparer ? \n\n**Option 1 : configurez l'authentification Docker Hub dans vos pipelines**\n\nSi vos pipelines effectuent des pulls directement depuis Docker Hub, vous pouvez configurer l'authentification afin d'augmenter votre limite de taux à 100 pulls d'images par heure (ou illimitée avec un abonnement payant à Docker Hub).\n\nPour cela, ajoutez vos identifiants de connexion Docker Hub aux variables CI/CD de votre projet ou groupe (ne les insérez pas directement dans le fichier `.gitlab-ci.yml`). Consultez les instructions détaillées de notre [documentation sur l'utilisation d'images Docker](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials) pour configurer correctement la variable CI/CD `DOCKER_AUTH_CONFIG`.\n\n**Option 2 : utilisez le registre de conteneurs GitLab**\n\nEffectuez un push des images Docker que vous utilisez le plus souvent dans votre [registre de conteneurs GitLab](https://docs.gitlab.com/user/packages/container_registry/) afin d'éviter de devoir effectuer un pull d'images depuis Docker Hub pendant l'exécution des pipelines CI/CD. Procédez comme suit :\n\n1. Effectuez un pull de l'image depuis Docker Hub.\n2. Attribuez-lui un tag adapté à votre registre de conteneurs GitLab.\n3. Effectuez un push de l'image dans votre registre de conteneurs GitLab.\n4. Mettez à jour vos pipelines pour qu'ils effectuent un pull de l'image depuis le registre de conteneurs GitLab.\n\n```\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nPuis ajoutez cette ligne de commande dans votre fichier `.gitlab-ci.yml` :\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**Option 3 : utilisez le proxy de dépendances de GitLab**\n\nLa fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache les images Docker, tout en servant de proxy entre vos pipelines CI/CD et les registres Docker Hub, réduisant ainsi la dépendance aux registres externes et les risques liés aux limites de débit.  \n\nOptions d'authentification actuelles :\n* GitLab 17.10 : configurez l'authentification Docker Hub pour le proxy de dépendances à l'aide de l'[API GraphQL](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api).\n* GitLab 17.11 : utilisez la nouvelle interface de configuration dans les paramètres de votre groupe (déjà disponible sur GitLab.com).\n\nUne fois l'authentification correctement configurée, vous pouvez procéder comme suit :\n\n1. Configurez les identifiants de connexion Docker Hub dans les paramètres du proxy de dépendances de votre groupe :\n  - Pour GitLab 17.11+ (ou la version actuelle de GitLab.com) : accédez aux paramètres de votre groupe > Paquets et registres > Proxy de dépendances.\n  - Pour GitLab 17.10 : utilisez l'API GraphQL afin de configurer l'authentification.\n2. Mettez à jour vos pipelines de façon à ce qu'ils utilisent les URL du proxy de dépendances pour la configuration de votre pipeline CI/CD :\n`image:${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**Option 4 : envisagez d'acheter un abonnement payant à Docker Hub**\n\nPour les équipes qui utilisent Docker Hub de manière intensive, la mise à niveau vers un abonnement Docker payant (Team ou Business) permet d'accéder à un nombre illimité de pulls, ce qui peut s'avérer la solution la plus simple.\n\n## Comment limiter l'impact des nouveaux quotas de Docker Hub ?\n\nQuelle que soit l'option que vous choisissez, tenez compte de ces bonnes pratiques pour réduire au maximum l'impact des nouvelles limites de débit imposées par Docker Hub :\n\n* Utilisez des tags d'image spécifiques au lieu de `latest` pour éviter les pulls inutiles.\n* Consolidez vos fichiers Docker de façon à ce qu'ils réutilisent les mêmes images de base dans tous vos projets.\n* Planifiez l'exécution des pipelines les moins critiques en dehors des heures de pointe.\n* Tirez parti intelligemment de la mise en cache pour éviter d'effectuer maintes fois un pull des mêmes images.\n\n**Remarque :** selon la [documentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition) de Docker Hub, le nombre de pulls augmente dès que vous effectuez le pull d'un manifeste d'image, et non en fonction de la taille de l'image ou du nombre de couches.\n\n## Calendrier et prochaines étapes\n\n**Dès maintenant**\n  * Mettez en œuvre l'authentification pour les pulls directs depuis Docker Hub.\n  * Les utilisateurs de GitLab.com peuvent déjà configurer l'authentification Docker Hub pour le proxy de dépendances en utilisant :\n    * l'API GraphQL, ou\n    * l'interface utilisateur dans les paramètres de groupe.\n  * Les utilisateurs de GitLab Self-Managed 17.10 peuvent configurer l'authentification du proxy de dépendances à l'aide de l'API GraphQL.\n\n**1er avril 2025**\n  * Les limites de débit de Docker Hub entrent en vigueur.\n\n**17 avril 2025**\n  * Sortie de GitLab 17.11 qui prendra en charge l'authentification du proxy de dépendances via l'interface utilisateur pour les instances GitLab Self-Managed. \n\nNous vous recommandons d'appliquer ces mesures bien dès maintenant pour éviter des échecs de pipelines inattendus. Pour la plupart des utilisateurs, configurer le proxy de dépendances avec l'authentification Docker Hub est la solution la plus efficace à long terme.\n\n> Vous avez des questions ou besoin d'aide pour la mise en œuvre ? Consultez [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/526605) dans lequel notre équipe fournit une assistance dédiée à ces changements.",[109,746,800],"2025-03-28",{"slug":884,"featured":91,"template":806},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":706,"slug":710,"posts":886},[887,903,917],{"content":888,"config":901},{"title":889,"description":890,"authors":891,"heroImage":893,"date":894,"body":895,"category":710,"tags":896,"updatedDate":900},"Programme Co-Create : comment nous construisons GitLab avec nos clients","Découvrez comment Thales, Scania et Kitware collaborent avec les ingénieurs de GitLab pour contribuer au développement de fonctionnalités significatives.",[892],"Fatima Sarah Khalid","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","2025-01-30","L'année dernière, plus de 800 membres de la communauté ont apporté plus de 3 000 contributions à GitLab. Parmi ces contributeurs figurent des membres issus d'équipes travaillant pour des entreprises internationales comme Thales, Scania et Kitware qui contribuent à façonner l'avenir de GitLab grâce au [Programme Co-Create](https://about.gitlab.com/community/co-create/). Dans le cadre de ce programme de développement collaboratif mis en place par GitLab, les clients travaillent directement avec les ingénieurs de GitLab pour ajouter des fonctionnalités importantes à la plateforme.\n\nÀ travers des ateliers, des sessions de programmation en binôme et une assistance en continu, les participants au programme acquièrent une connaissance pratique de l'architecture et du code base de GitLab tout en résolvant des problèmes ou en améliorant des fonctionnalités existantes.\n\n*« Notre expérience avec le Programme Co-Create a été incroyable »*, déclare Sébastien Lejeune, Open Source Advocate chez Thales. *« Il n'a fallu que deux mois entre le moment où nous avons discuté de notre contribution avec un ingénieur de l'équipe Contributor Success de GitLab et le moment où nous l'avons intégrée à la version de GitLab. »*\n\nDans cet article, découvrez comment nos clients tirent parti du Programme Co-Create pour transformer leurs idées en code, tout en se formant et en apportant leur contribution.\n\n## Qu'est-ce que le Programme Co-Create ? \n\nAvec le [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit), les contributeurs peuvent facilement faire leurs premiers pas sur la plateforme de développement de GitLab. *« Ce que les nouveaux contributeurs doivent comprendre, c'est que rien n'est définitif avec le GDK »*, indique Hook. *« Si un contributeur effectue une modification qui ne fonctionne pas, il peut l'annuler ou tout recommencer. Le GDK permet d'expérimenter, de tester et d'apprendre sans se soucier de l'environnement. »*\n\nChaque entreprise participant au Programme Co-Create de GitLab reçoit une assistance tout au long de son parcours de contribution :\n\n- __Atelier d'intégration technique__ : session dédiée à la mise en place du GitLab Development Kit (GDK) et à la présentation de l'architecture de la plateforme GitLab.\n- __Support technique individuel__ : accès aux ingénieurs GitLab pour programmer en binôme et recevoir des conseils techniques.\n- __Explications détaillées sur l'architecture__ : sessions sur des composants spécifiques de la plateforme GitLab en lien direct avec le problème auquel l'entreprise contribue.\n- __Aide à la revue de code__ : retours et conseils détaillés tout au long du processus de merge request.\n- __Points réguliers__ : collaboration continue pour assurer l'avancement de la contribution et répondre aux problématiques rencontrées.\n\nCette structure garantit que les équipes peuvent contribuer efficacement, quelle que soit leur expérience antérieure avec le code base de GitLab ou les langages de programmation Ruby/Go. Comme le note John Parent de Kitware, *« si vous êtes un nouvel utilisateur de GitLab, vous avez l'impression d'être face à une architecture sophistiquée et à une immense quantité de code réparti sur différents projets. Le Programme Co-Create regroupe l'équivalent de plusieurs semaines de formation interne en une formation accélérée et ciblée. »*\n\nEn plus d'aboutir au développement de nouvelles fonctionnalités, ce programme permet d'établir des relations durables entre GitLab et sa communauté d'utilisateurs. *« Le fait que nos clients contribuent avec enthousiasme au développement de nouvelles fonctionnalités est inspirant pour nos ingénieurs »*, révèle Shekhar Patnaik, Principal Engineer chez GitLab. *« Les clients découvrent la \"méthode GitLab\" et les ingénieurs sont témoins de leur engagement à façonner l'avenir de GitLab. »*\n\n## Contribution de Thales : amélioration de l'expérience utilisateur des projets\n\nLa société Thales a identifié des opportunités pour améliorer l'interface utilisateur de la plateforme GitLab lorsque les utilisateurs créent des projets vides. Et elle ne s'est pas contentée de soumettre une demande de fonctionnalité : elle a développé la solution elle-même. Elle a axé ses contributions sur l’amélioration de l'expérience de configuration de nouveaux projets en simplifiant la configuration SSH/HTTPS avec une interface composée de plusieurs onglets et en ajoutant une fonctionnalité de copier/coller pour les extraits de code. Ces changements ont eu un impact significatif sur les workflows des équipes de développement. \n\nL'équipe de Thales n'a pas seulement travaillé à l'amélioration de l'UX. Quentin Michaud, doctorant travaillant dans le domaine des applications cloud en périphérie chez Thales, a contribué à l'amélioration du GitLab Development Kit (GDK). Chargé de maintenance de paquets pour Arch Linux, Quentin Michaud, fort de son expertise, a contribué à enrichir la documentation du GDK et à soutenir sa conteneurisation, facilitant ainsi le travail des futurs contributeurs.\n\n*« Grâce à mon expérience en open source, j'ai pu améliorer la prise en charge des distributions Linux par le GDK »*, explique Quentin Michaud. *« Pendant que j'améliorais la documentation sur la gestion de versions des paquets, j'ai constaté que l'équipe Contributor Success de GitLab travaillait également à l'intégration du GDK dans un conteneur. Voir nos efforts converger a été un grand moment pour moi. Cela a montré que la collaboration open source peut contribuer à la création de meilleures solutions. »*\n\nL'expérience s'étant avérée positive pour l'équipe de Thales, Sébastien Lejeune utilise désormais le Programme Co-Create comme exemple *« pour montrer à nos managers le retour sur investissement généré grâce aux contributions open source. »*\n\n## Contribution de Scania : amélioration de la prise en charge des paquets\nLorsque l'entreprise Scania a eu besoin d'une prise en charge avancée des paquets dans GitLab, elle a vu une opportunité d'apporter sa contribution et de développer cette fonctionnalité elle-même. \n\n*« Cela fait longtemps que nous utilisons la plateforme GitLab et que nous promouvons activement l'open source au sein de notre entreprise. Le Programme Co-Create est pour nous une façon concrète d'y contribuer directement »*, révèle Puttaraju Venugopal Hassan, Solution Architect chez Scania.\n\nL'équipe a commencé par des changements mineurs pour se familiariser avec le code base et le processus de revue avant de passer à des fonctionnalités plus importantes. *« L'un des aspects les plus gratifiants du Programme Co-Create a été de revenir sur l'ensemble du processus et de voir le chemin parcouru »*, indique Océane Legrand, Software Developer chez Scania. *« Nous avons commencé par évaluer les besoins et apporter de petits changements, avant de passer à des tâches plus importantes au fil du temps. C'est formidable de voir cette progression. »*\n\nLes contributions de l'équipe de Scania incluent la correction des bogues pour le registre de paquets, ainsi que l'amélioration des fonctionnalités du registre de paquets Conan. Ce dernier pourra bientôt être proposé en disponibilité générale (GA), avec l'implémentation de la prise en charge de la version 2 de Conan. Le travail et la collaboration de Scania avec GitLab sont la preuve que le Programme Co-Create peut apporter des améliorations significatives aux fonctionnalités de registre de paquets de GitLab.\n\n*« Dès le début, notre expérience avec le Programme Co-Create a été très organisée. Nous avons participé à des sessions de formation pendant lesquelles nous avons pu découvrir tous les éléments nécessaires à notre contribution. Des sessions individuelles avec un ingénieur GitLab nous ont également offert une vue détaillée de l'architecture des paquets de GitLab, ce qui a rendu le processus de contribution beaucoup plus fluide »*, déclare Juan Pablo Gonzalez, Software Developer chez Scania. \n\nL'impact du programme va au-delà du code. En effet, les participants acquièrent également des compétences précieuses grâce à leurs contributions. À l'occasion de la sortie de [la version 17.8 de GitLab](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), Océane Legrand et Juan Pablo Gonzalez ont tous deux été désignés comme Most Valuable Person (MVP) de GitLab. Océane Legrand a parlé de l'impact de son travail en open source sur GitLab et Scania, y compris l'obtention de nouvelles compétences pour elle et son équipe : *« Ma contribution au travers du Programme Co-Create m'a permis d'acquérir de nouvelles compétences et une expérience de Ruby et des migrations en arrière-plan. Lorsque mon équipe chez Scania a rencontré un problème lors d'une mise à niveau, j'ai pu participer à sa résolution, car je l'avais déjà rencontré dans le cadre du Programme Co-Create. »*\n\n## Contribution de Kitware : optimisation de l'authentification pour le calcul haute performance\nKitware a mis à profit son expertise spécialisée issue de son travail avec des laboratoires nationaux pour améliorer le framework d'authentification de GitLab. Ses contributions comprenaient l'ajout de la prise en charge du flux d'autorisation d'appareil OAuth2 dans GitLab, ainsi que la mise en œuvre de nouveaux composants, tels que des tables de base de données, des contrôleurs, des vues et de la documentation. Ces améliorations élargissent les options d'authentification de GitLab, rendant la plateforme plus polyvalente pour les appareils sans navigateur ou disposant de capacités de saisie limitées.\n\n*« Le Programme Co-Create est le moyen le plus efficace de contribuer à GitLab en tant que contributeur externe »*, estime John Parent, R&D Engineer chez Kitware. *« Grâce aux sessions de [pair programming](https://about.gitlab.com/fr-fr/blog/agile-pairing-sessions/ \"Pair programming\") entre développeurs et développeuses, nous avons identifié de meilleures implémentations que nous aurions peut-être manquées si nous avions travaillé seuls. »*\n\nEn tant que contributeur open source de longue date, Kitware a particulièrement apprécié l'approche de développement de GitLab. *« Je me doutais que GitLab ne se contenterait pas de solutions prêtes à l'emploi à son échelle, mais voir les équipes de développement intégrer une dépendance Ruby au lieu de créer une solution interne personnalisée était génial »*, explique John Parent. *« Venant du monde C++, où les gestionnaires de paquets sont rares, j'ai apprécié de voir cette approche et sa simplicité. »*\n\n## Quels sont les avantages du Programme Co-Create ?\n\nLe Programme Co-Create crée de la valeur à la fois pour GitLab et le partenaire impliqué. *« Le programme comble le fossé qui peut exister entre les ingénieurs qui développent GitLab et nos clients »*, affirme Imre Farkas, Staff Backend Engineer chez GitLab. *« Collaborer avec les clients nous permet de comprendre leurs défis quotidiens, les parties de l'écosystème GitLab sur lesquelles ils s'appuient et les domaines dans lesquels des améliorations peuvent être apportées. C'est formidable de voir à quel point ils sont enthousiastes à l'idée de s'impliquer dans le développement de GitLab à nos côtés. »*\n\nCette approche collaborative accélère également le développement de GitLab. Comme l'observe Shekhar Patnaik, Principal Engineer chez GitLab : *« Grâce au Programme Co-Create, nos clients nous aident à faire progresser notre roadmap. Leurs contributions nous permettent de fournir des fonctionnalités critiques plus rapidement, ce qui profite à l'ensemble de notre base d'utilisateurs. Le programme étant en constante évolution, nous avons de fortes chances d'accélérer le développement de nos fonctionnalités les plus importantes en travaillant aux côtés des personnes qui comptent sur elles. »*\n\n## Premiers pas avec le Programme Co-Create\nVous souhaitez transformer vos demandes de fonctionnalités en réalité ? Que vous cherchiez à perfectionner l'interface utilisateur de GitLab comme Thales, à améliorer la prise en charge des paquets comme Scania ou à optimiser l'authentification comme Kitware, le Programme Co-Create accueille les entreprises qui souhaitent façonner activement l'avenir de GitLab tout en développant une expérience open source précieuse.\n\nContactez votre représentant GitLab pour en savoir plus sur la participation au Programme Co-Create ou visitez notre [page dédiée](https://about.gitlab.com/community/co-create/) pour plus d'informations.\n",[897,898,899],"contributors","open source","customers","2025-02-10",{"slug":902,"featured":91,"template":806},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":904,"config":915},{"title":905,"description":906,"authors":907,"heroImage":909,"date":910,"body":911,"category":710,"tags":912,"updatedDate":914},"Comment Indeed a transformé sa plateforme CI avec GitLab","Indeed a migré des milliers de projets vers le système d'intégration continue (CI) de GitLab, ce qui lui a permis de booster sa productivité et de réduire ses coûts.",[908],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","2024-08-27","***Cet article a été traduit. Retrouvez la version originale sur [notre blog anglais](https://about.gitlab.com/blog/how-indeed-transformed-its-ci-platform-with-gitlab/ \"Blog anglais de GitLab\").***\n\n***Note de la rédaction : nous invitons parfois les membres de notre communauté de clients à contribuer au blog de GitLab. Nous remercions aujourd'hui Carl Myers, responsable des plateformes CI chez Indeed, de nous avoir fait part de son expérience avec GitLab.***\n\nChez Indeed, notre mission est d'aider chacun à trouver un emploi. Indeed est le [plus grand site d'offres d'emploi](https://www.indeed.com/about?isid=press_us&ikw=press_us_press%2Freleases%2Faward-winning-actress-viola-davis-to-keynote-indeed-futureworks-2023_textlink_https%3A%2F%2Fwww.indeed.com%2Fabout) au monde, accueillant plus de 350 millions de visiteurs uniques chaque mois.\n\nDu côté des équipes de plateforme d'ingénierie d'Indeed, la devise est légèrement différente : « Nous aidons ceux qui aident chacun à trouver un emploi ». Depuis près de vingt ans, les chercheurs d'emploi sont au cœur de notre culture d'ingénierie fondée sur les données. Dans ce contexte, notre responsabilité est de créer des outils qui non seulement facilitent cet objectif, mais qui permettent également aux ingénieurs d'offrir chaque jour des opportunités aux candidats.\n\nL'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\") de GitLab a permis à l'équipe de plateforme CI d'Indeed, composée de seulement 11 personnes, d'accompagner efficacement des milliers d'utilisateurs dans toute l'entreprise. Indeed a également constaté d'autres avantages, avec notamment :\n- une augmentation des pipelines quotidiens de 79 %\n- une réduction de 10 à 20 % des coûts de matériel de CI\n- une diminution des demandes d'assistance\n\n## L'évolution de notre plateforme CI : de Jenkins vers une solution évolutive\n\nComme de nombreuses grandes entreprises dans le domaine technologique, nous avons construit notre plateforme CI de manière organique, au fil de l'évolution de l'entreprise, en faisant appel aux solutions open source et standard qui étaient disponibles à l’époque. En 2007, lorsque Indeed comptait moins de 20 ingénieurs, nous utilisions Hudson, le prédécesseur direct de Jenkins.\n\nUne vingtaine d'années plus tard, nous employons aujourd'hui des milliers d'ingénieurs. Nous avons progressivement amélioré nos outils au fil de l'arrivée de nouvelles technologies, notamment en passant à Jenkins vers 2011. Une autre avancée nous a permis de déplacer la plupart de nos charges de travail vers des nœuds de travail cloud dynamiques grâce à [AWS EC2](https://aws.amazon.com/ec2/). Il est toutefois devenu évident que l'architecture de notre système avait atteint ses limites lorsque nous sommes entrés dans l'ère de [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\").\n\nL'architecture de Jenkins n'est en effet pas conçue pour le cloud. Le fonctionnement de Jenkins repose sur un nœud « contrôleur », un point de défaillance unique qui exécute les parties critiques d'un pipeline et décharge certaines étapes vers les nœuds de travail (qui peuvent évoluer horizontalement dans une certaine mesure). Les contrôleurs constituent également un axe de mise à l'échelle manuelle.\n\nSi vos tâches sont trop nombreuses pour un contrôleur donné, elles doivent être partitionnées manuellement entre plusieurs contrôleurs. CloudBees propose des solutions pour contourner ce problème, notamment avec le CloudBees Jenkins Operations Center qui vous permet de gérer votre constellation de contrôleurs depuis un seul endroit centralisé. Cependant, les contrôleurs restent difficiles à exécuter dans un environnement Kubernetes, car chaque contrôleur est un point de défaillance unique et fragile. Des activités telles que les déploiements de nœuds ou des défaillances matérielles peuvent ainsi entraîner des temps d'arrêt.\n\nAu-delà des limitations techniques inhérentes à Jenkins, notre plateforme CI a également rencontré des problèmes dont nous étions malheureusement à l'origine. Par exemple, nous avons utilisé le DSL Groovy de Jenkins pour générer des jobs à partir du code contenu dans chaque dépôt. Chaque projet s'est ainsi retrouvé avec un pipeline individuel de jobs copiés, ce qui a engendré des centaines de versions difficiles à maintenir et à mettre à jour. Bien que la culture d'ingénierie d'Indeed encourage la flexibilité et permette aux équipes de travailler dans des dépôts distincts, cette flexibilité était devenue un fardeau, car les équipes consacraient trop de temps à répondre aux demandes de maintenance régulières.\n\nAyant pris conscience de cette dette technique, nous nous sommes tournés vers le [modèle « Golden Path »](https://tag-app-delivery.cncf.io/whitepapers/platforms/), qui permet une certaine flexibilité tout en offrant une méthode par défaut pour simplifier les mises à jour et encourager des pratiques cohérentes dans tous les projets.\n\nL'équipe de plateforme CI d'Indeed est relativement petite. Nous comptons environ 11 ingénieurs qui gèrent des milliers d'utilisateurs, répondent aux demandes d'assistance, effectuent des mises à niveau et des opérations de maintenance, et offrent une assistance constante à notre entreprise mondiale.\n\nComme notre équipe prend en charge non seulement notre instance GitLab, mais également l'ensemble de la plateforme CI, y compris le serveur d'artefacts, notre code de compilation partagé et de multiples autres composants personnalisés de notre plateforme, nous avions énormément de travail. Nous avions besoin d'une solution qui nous aiderait à résoudre nos problèmes tout en exploitant au maximum nos ressources existantes.\n\n## Notre migration vers GitLab CI\n\nAprès un examen minutieux de sa conception avec les principales parties prenantes, nous avons décidé de migrer l'ensemble de l'entreprise de Jenkins vers le système d'intégration continue de GitLab. \n\nNos principales raisons étaient les suivantes :\n- Nous utilisions déjà GitLab pour la gestion du code source.\n- GitLab est une offre complète qui fournit tout ce dont nous avons besoin pour l'intégration continue.\n- GitLab CI est conçu pour l'évolutivité et le cloud.\n- GitLab CI nous permet de générer des modèles qui élargissent d'autres modèles, ce qui est compatible avec notre stratégie « Golden Path ».\n- GitLab est un logiciel open source et l'équipe de GitLab nous a toujours aidés à soumettre des correctifs, ce qui nous offre davantage de flexibilité et renforce notre confiance.\n\nAu moment de notre annonce officielle de la disponibilité de la plateforme CI de GitLab pour tous les utilisateurs, 23 % de l'ensemble des compilations étaient déjà effectuées dans le système d'intégration continue de GitLab.\n\nNotre plus grand défi lors de cette migration était que « le diable se niche dans les détails ». Du fait du nombre de compilations personnalisées présentes dans Jenkins, nous savions qu'un outil de migration automatisé ne fonctionnerait pas pour la majorité des équipes. Or, la plupart des avantages du nouveau système ne seraient concrétisés qu'une fois l'ancien système complètement abandonné. Ce n'est qu'alors que nous pourrions cesser d'utiliser le matériel et économiser les frais de licence CloudBees.\n\n## La parité des fonctionnalités et les avantages de repartir à zéro \n\nIndeed utilise de nombreuses technologies différentes, mais les trois langages les plus courants sont Java, Python et JavaScript. Ces piles technologiques de langages sont utilisées pour créer des bibliothèques, des déployables (services Web ou applications) et des tâches cron (un processus qui s'exécute à intervalles réguliers, par exemple pour créer un ensemble de données dans notre lac de données). Chacune de ces piles correspondait à un type de projet spécifique (par ex. Java Library, Python Cronjob, JavaScript Webapp, etc.) avec une configuration de base dans Jenkins. Par conséquent, nous avons dû générer un modèle « Golden Path » dans le système d'intégration continue de GitLab pour chacun de ces types de projets.\n\nLa plupart des utilisateurs pouvaient utiliser ces modèles recommandés tels quels. Pour ceux qui avaient besoin de les personnaliser, le « Golden Path » constituait un point de départ utile leur permettant de modifier uniquement les aspects nécessaires, tout en bénéficiant de mises à jour de modèles centralisées à l'avenir.\n\nNous avons rapidement constaté que la plupart des utilisateurs, même ceux qui avaient besoin de personnaliser certains aspects de leur projet, étaient tout à fait disposés à adopter ce modèle et à l'essayer. S'ils s'apercevaient que certaines de leurs personnalisations n'étaient pas incluses dans le modèle, ils savaient qu'ils pouvaient toujours les ajouter ultérieurement. C'était un résultat surprenant ! Nous pensions en effet que les équipes qui avaient investi dans des personnalisations importantes seraient réticentes à l'idée de les abandonner. Or, dans la majorité des cas, les équipes ne s'en souciaient tout simplement plus. Cela nous a permis de migrer de nombreux projets très rapidement : il suffisait en effet de déposer notre « Golden Path » (un petit fichier d'environ 6 lignes avec des inclusions) dans leur projet pour que chaque équipe puisse s'occuper du reste.\n\n## L'innersource à la rescousse\n\nL'équipe de plateforme CI a également adopté une politique de « priorité aux contributions externes » pour encourager la participation de tous les membres de l'entreprise. C'est ce qu'on appelle parfois l'[innersource](https://about.gitlab.com/fr-fr/topics/version-control/what-is-innersource/ \"Qu'est-ce que l'innersource ?\"). Nous avons créé des tests et une documentation pour encourager les contributions externes (c'est-à-dire externes à notre équipe immédiate). Les équipes qui souhaitaient créer des personnalisations pouvaient ainsi les ajouter au « Golden Path » tout en les activant ou désactivant à l'aide d'un feature flag. Cette approche a encouragé une meilleure collaboration et un plus grand respect des personnalisations (parce que celles-ci faisaient désormais partie du code base commun). \n\nAutre avantage : les équipes qui attendaient désespérément une fonctionnalité dont elles avaient besoin pouvaient désormais la créer elles-mêmes. Nous pouvons désormais leur donner le choix : « Oui, nous prévoyons de mettre en œuvre cette fonctionnalité dans quelques semaines, mais si vous en avez besoin plus tôt, nous serions ravis d'accepter une contribution ». Au final, de nombreuses fonctionnalités de base nécessaires à la parité ont été développées de cette manière, plus rapidement et mieux que nos ressources ne le permettaient. La migration n'aurait pas été un succès sans ce modèle.\n\n## En avance sur le calendrier et en dessous du budget\n\nNotre licence CloudBees arrivait à expiration le 1er avril 2024. Nous avons donc fixé cette date comme date d'achèvement de la migration. Cette échéance était particulièrement ambitieuse, car, à l'époque, 80 % de l'ensemble des compilations (soit 60 % de tous les projets) utilisaient encore Jenkins pour le processus d'intégration continue. Plus de 2 000 [fichiers Jenkins (Jenkinsfiles)](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) devaient donc encore être recréés ou remplacés par nos modèles « Golden Path ».\n\nPour atteindre cet objectif, nous avons mis à disposition des équipes une documentation et des exemples, ajouté des fonctionnalités dans la mesure du possible et aidé nos utilisateurs à offrir des contributions quand ils le pouvaient.\n\nNous avons mis en place des permanences régulières, durant lesquelles tous les utilisateurs pouvaient nous poser des questions ou demander notre aide pour migrer. Nous avons également donné la priorité aux questions d'assistance relatives à la migration. Certains membres de notre équipe sont devenus des experts du système d'intégration continue de GitLab et ont partagé leur expertise avec le reste de l'équipe et toute l'entreprise.\n\nLa migration automatique n'était pas adaptée à la plupart des projets, mais nous avons découvert qu'elle pouvait fonctionner pour un petit sous-ensemble de projets où les personnalisations étaient rares. Nous avons créé une campagne de changement par lots Sourcegraph afin de soumettre des merge requests pour migrer des centaines de projets et, avons convaincu les utilisateurs à accepter ces merge requests.\n\nNous avons également partagé des exemples de réussite notables avec toutes les équipes. Comme les utilisateurs ajoutaient de nouvelles fonctionnalités à nos modèles « Golden Path », nous avons annoncé que ces fonctionnalités seraient ajoutées « gratuitement » lors de la migration vers [GitLab CI](https://about.gitlab.com/fr-fr/blog/ci-deployment-and-environments/ \"Comment déployer du code dans des environnements multiples avec GitLab CI\"). Ces fonctionnalités comportaient entre autres un scan de sécurité et de conformité intégré, des notifications Slack pour les compilations CI et des intégrations avec d'autres systèmes internes.\n\nNous avons également mené une campagne de tests agressifs. Dans ce cadre, nous avons automatiquement désactivé les jobs Jenkins qui n'avaient pas été exécutés ou qui n'avaient pas abouti depuis un certain temps, en disant aux utilisateurs que s'ils en avaient besoin, ils pouvaient les réactiver. C'est un moyen simple d'identifier les jobs qui sont réellement nécessaires. Nous avons ainsi identifié des milliers de jobs qui n'avaient pas été exécutés une seule fois depuis notre dernière migration CI (de Jenkins vers Jenkins). Nous en avons déduit que nous pouvions ignorer la vaste majorité de ces jobs sans aucun risque.\n\nEn janvier 2024, nous avons annoncé que tous les contrôleurs Jenkins passeraient en lecture seule (sans compilation) à moins qu'une exception ne soit explicitement demandée par les utilisateurs. La propriété des contrôleurs était mieux connue et ils s'alignaient généralement sur la structure de notre entreprise. Il était donc logique de se concentrer sur les contrôleurs plutôt que sur les jobs. De plus, la liste des contrôleurs était beaucoup plus gérable que celle des jobs.\n\nPour obtenir une exception, les utilisateurs devaient identifier leurs contrôleurs dans une feuille de calcul, puis saisir leurs coordonnées à côté de chacun d'eux. Nous avons ainsi pu obtenir une liste à jour et fiable des parties prenantes avec lesquelles nous pouvions effectuer un suivi à mesure que la migration progressait, mais cela a également permis aux utilisateurs d'indiquer clairement les jobs dont ils avaient absolument besoin. Nous sommes passés d'environ 400 contrôleurs à 220 au mois de janvier, mais seuls 54 contrôleurs ont nécessité des exceptions (et parmi ces contrôleurs, plusieurs appartenaient à notre équipe pour exécuter nos tests et déploiements canari)).\n\n![Indeed - Graphique de recensement des contrôleurs Jenkins](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\nNous avions donc une liste gérable d'environ 50 équipes et chaque membre de notre équipe a été chargé d'en contacter un certain nombre pour évaluer leurs progrès dans le cadre de la migration. Nous avons consacré les mois de janvier et février à cette tâche et découvert que certaines équipes prévoyaient de terminer leur migration sans notre aide avant le 28 février. D'autres prévoyaient de mettre fin à leurs projets existants avant cette date, et seule une petite minorité pensait rencontrer des difficultés.\n\nNous avons pu travailler avec ce petit groupe d'équipes pour leur offrir un niveau d'accompagnement très personnalisé. Nous leur avons expliqué que nous ne disposions pas de l'expertise nécessaire pour effectuer la migration à leur place, mais que nous pouvions collaborer avec un expert métier de leur équipe. Dans certains cas, nous avons écrit le code et l'équipe s'est chargée de la revue de code, ou vice-versa. Au final, tout notre travail a porté ses fruits et nous avons pu désactiver Jenkins à la date que nous avions annoncée 8 mois plus tôt.\n\n## Résultats : une intégration continue plus efficace et des utilisateurs plus satisfaits\n\nÀ son apogée, notre plateforme CI Jenkins permettait d'exécuter plus de 14 000 pipelines par jour et de réaliser des milliers de projets. Aujourd'hui, notre plateforme CI GitLab exécute régulièrement plus de 25 000 pipelines par jour, mais peut en traiter plus de 40 000 en une seule journée. Le coût différentiel de chaque job dans chaque pipeline est similaire à celui de Jenkins, mais sans les coûts indirects du matériel nécessaire au fonctionnement des contrôleurs. De plus, ces contrôleurs agissaient comme des points de défaillance uniques et des limiteurs de mise à l'échelle, ce qui nous obligeait à diviser artificiellement notre plateforme en segments. Bien qu'une comparaison directe soit difficile, nous constatons que l'élimination de ces frais généraux permet de réduire nos coûts de matériel d'intégration continue de 10 à 20 %. En outre, la charge d'assistance de GitLab CI est bien moindre, car l'application évolue automatiquement dans le cloud et offre une résilience interzone, et le langage utilisé pour la génération de modèles s'accompagne d'une excellente documentation publique.\n\nUn avantage tout aussi important, sinon plus, est que nous sommes maintenant à plus de 70 % d'adoption de nos modèles « Golden Path ». Cela signifie que lorsque nous déployons une amélioration, plus de 5 000 projets en bénéficient immédiatement sans qu'aucune action ne soit requise de la part des équipes d'Indeed. Nous avons ainsi pu déplacer certains jobs vers des instances ARM64 plus rentables, mettre à jour plus facilement les images de compilation des utilisateurs et mieux gérer d'autres opportunités de réduction des coûts. Et le résultat dont nous sommes le plus fiers ? Nos utilisateurs sont plus satisfaits grâce à la nouvelle plateforme.\n\n__À propos de l'auteur :__\n*Carl Myers vit à Sacramento, en Californie, et est le responsable de l'équipe de plateforme CI d'Indeed. Depuis près de vingt ans, Carl crée des outils internes et des plateformes de développement pour le bonheur d'ingénieurs d'entreprises de toutes tailles.*\n\n**Remerciements :**\n*Cette migration n'aurait pas été possible sans le travail inlassable de Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen et de toute l'équipe de plateforme CI. L'équipe souhaite également remercier Deepak Bitragunta et Irina Tyree, dont le leadership a permis de garantir les ressources, l'adhésion et la cohérence à l'échelle de l'entreprise qui étaient nécessaires tout au long de ce long projet. Enfin, nous remercions tous les membres d'Indeed qui ont contribué au code, aux retours d'expérience, aux rapports de bogues et à la migration des projets.*\n\n**Ce texte est une version modifiée de l'article « [How Indeed Replaced Its CI Platform with Gitlab CI](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/) », publié à l'origine sur le blog dédié à l'ingénierie d'Indeed.**",[899,109,913,800],"user stories","2024-12-18",{"slug":916,"featured":91,"template":806},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":918,"config":929},{"title":919,"description":920,"authors":921,"heroImage":923,"date":924,"body":925,"category":710,"tags":926},"Southwest Airlines transforme son développement avec GitLab","Découvrez comment les équipes DevOps de la compagnie aérienne augmentent leur capacité à détecter et à résoudre les problèmes avec GitLab.",[922],"Sharon Gaudin","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","2024-01-30","Southwest Airlines Co. met tout en œuvre pour faciliter le travail de ses équipes de développement.  \n\nLes responsables informatiques de la plus grande compagnie aérienne low-cost au monde s'emploient à éliminer les tâches chronophages et répétitives des workflows de leurs équipes. L'objectif vise à leur faire gagner un temps précieux pour qu'elles se consacrent à des projets à forte valeur ajoutée.\n\n*« Notre approche consiste à éliminer les obstacles qui ralentissent le travail de nos équipes »*, déclare Jim Dayton, Vice President et CISO de Southwest Airlines. *« Je suis fermement convaincu que la plupart des développeurs et développeuses choisissent ce métier pour sa part de créativité. Résoudre les problèmes est leur cheval de bataille. Nous souhaitons donc leur faciliter la tâche et supprimer les obstacles qui entravent leur productivité. »*\n\nPour faire de cette idée une réalité, Jim Dayton s'appuie notamment sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab.\n\nÀ l'occasion de son interview lors du [DevSecOps World Tour de GitLab](https://about.gitlab.com/events/devsecops-world-tour/) à Dallas, Jim Dayton a évoqué les efforts de Southwest Airlines pour soutenir ses équipes de développement et promouvoir leur travail. Lors de son échange avec Reshmi Krishna, Director of Enterprise Solutions Architecture chez GitLab, il a partagé ses réflexions sur les avantages des fonctionnalités d'intelligence artificielle pour enrichir le travail de ses équipes.\n\nSouthwest Airlines a adopté une [approche DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que DevOps ? \") pour le développement d'applications offrant à ses équipes de développement davantage de fonctionnalités en libre-service et de processus de gestion des connaissances. *« Nous voulons permettre aux développeurs et développeuses d'identifier un problème dès qu'il survient, de trouver rapidement une solution et de limiter les interruptions causées par les changements de contexte »*, expose Jim Dayton. *« Il est essentiel de comprendre ce qui freine leur productivité. »*\n\nDepuis 2019, année où Southwest Airlines a entamé sa collaboration avec GitLab, l'entreprise s'est attachée à assurer la cohérence de ses processus de développement logiciel. Pour cela, elle a choisi de centraliser son code dans un dépôt GitLab partagé. En sachant précisément où l'ensemble du code est stocké, les équipes de développement peuvent évaluer plus facilement les indicateurs de performance et gagner en efficacité grâce à la réutilisation du code. \n\n*« Nous finalisons actuellement nos pipelines d'entreprise et la migration des équipes est imminente »*, annonce Jim Dayton. *« Nous collaborons étroitement avec nos nombreuses équipes de développement d'applications pour bien comprendre leurs attentes en matière de pipelines. La finalisation de ce projet est prévue pour la fin de l'année. »*\n\n### La promesse de l'IA\n\nL'utilisation de l'intelligence artificielle est un levier pour les équipes de développement. Elle leur permet notamment de se concentrer sur des tâches plus importantes et plus innovantes, comme le souligne Jim Dayton.\n\nL'IA générative, que ce soit sous la forme d'explications des vulnérabilités, de suggestions de code ou de complétion de code, a un impact considérable sur les workflows tout au long du cycle de vie du développement logiciel. L'intégration de l'IA dans une plateforme DevSecOps renforce la sécurité et réduit le temps consacré aux revues de code et au développement d'applications.\n\nJim Dayton se réjouit de pouvoir utiliser les fonctionnalités d'IA de GitLab pour accélérer et optimiser les processus de développement et de déploiement.\n\n*« Nous voulons éliminer autant que possible les tâches routinières et administratives »*, insiste Jim Dayton, qui considère que l'IA est extrêmement prometteuse, malgré ce que peut laisser penser le battage médiatique autour de cette technologie. *« L'IA nous aidera peut-être à atteindre cet objectif. Un jour, elle pourra sûrement fournir une solution immédiate à une vulnérabilité qui vient d'être identifiée ou expliquer à quoi sert une portion de code. Elle pourra aussi vous dire à quoi elle s'intègre, à quelles données elle accède et pourquoi. Elle pourra nous indiquer clairement, par exemple, qu'un bloc de code spécifique est responsable de 20 % des incidents survenus dans telle application l'année précédente. C'est en ce sens, je pense, que l'IA peut nous aider. »*, précise-t-il. \n\nJim Dayton estime que même si l'IA ne remplacera pas les équipes de développement, elle facilitera grandement leur travail et la communication entre les équipes, notamment dans un contexte où le télétravail s'est généralisé depuis la pandémie de COVID-19.\n\n*« La suggestion de relecteurs est une des fonctionnalités prévues dans la roadmap de [GitLab] »* mentionne Jim Dayton. *« Auparavant, pour obtenir de l'aide dans le cadre de revues de code, il suffisait de demander aux collègues qui partageaient votre bureau. Ce qui n'est plus aussi simple aujourd'hui. En revanche, l'IA peut désormais suggérer un relecteur ayant déjà contribué au code du projet ou résolu des incidents, et qui possède les compétences nécessaires. Ce qui apporte une réelle valeur ajoutée au processus de revue de code. Je pense que l'automatisation est la clé pour réduire le nombre d'étapes manuelles ou les délais d'attente. »*\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/UnUfp7pKnEQ?si=qcX2Qm3zpgQOV4xy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*Southwest Airlines est une société au chiffre d'affaires de près de 24 milliards de dollars basée à Dallas, au Texas. Avec 72 000 employés, elle dessert 120 destinations et effectue 4 000 vols par jour.  Southwest Airlines transporte plus de passagers via des vols nationaux que toute autre compagnie aérienne.*\n\nVous souhaitez en savoir plus sur GitLab ? Consultez nos [témoignages clients](https://about.gitlab.com/fr-fr/customers/).\n",[927,928,837,899],"DevOps","DevOps platform",{"slug":930,"featured":6,"template":806},"southwest-looking-to-help-developers-take-flight",{"category":718,"slug":722,"posts":932},[933,945,957],{"content":934,"config":943},{"title":935,"description":936,"authors":937,"heroImage":939,"date":940,"body":941,"category":722,"tags":942},"Approche CI/CD : notre guide complet","Découvrez comment transformer vos processus CI/CD en automatisant le développement et la livraison de logiciels tout en renforçant la sécurité des pipelines.",[938],"Sandra Gittlen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","2025-06-25","L'adoption des pratiques [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") a révolutionné la création de valeur dans le développement logiciel. L'époque des déploiements manuels et des défis d'intégration complexes est désormais révolue : aujourd'hui, le développement logiciel moderne met l'accent sur l'automatisation, la fiabilité et la rapidité.\n\nL'approche CI/CD repose sur la mise en place d'un pipeline fluide et automatisé qui permet de transférer le code de l'environnement de développement vers l'environnement de production, tout en intégrant les retours et suggestions de modification en temps réel. L'intégration continue (CI) aide les équipes à détecter rapidement les problèmes avant qu'ils ne deviennent coûteux. Les modifications de code sont fréquemment fusionnées dans un dépôt partagé, puis testées automatiquement et validées. La livraison continue (CD) vient compléter cette démarche. Elle vise à automatiser le processus de déploiement, rendant les sorties de nouvelles versions prévisibles et harmonieuses.\n\nGrâce à un pipeline CI/CD robuste, les équipes peuvent compiler, tester et déployer leurs logiciels sans dépendre de processus manuels ou de chaînes d’outils complexes. L'intégration de l'IA aide à optimiser encore davantage ce processus, en générant automatiquement des pipelines CI/CD qui garantissent la cohérence des contrôles de qualité, de conformité et de sécurité.\n\nDécouvrez dans ce guide tout ce que vous devez sur les pipelines CI/CD modernes, des principes de base aux bonnes pratiques, en passant par les stratégies avancées. Apprenez également comment les grandes entreprises leaders dans leur domaine tirent parti de l'approche CI/CD pour atteindre des résultats impressionnants. À l’issue de cette lecture, vous saurez comment faire évoluer votre environnement [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") afin de développer et de livrer des logiciels de manière [agile](https://about.gitlab.com/fr-fr/topics/ci-cd/continuous-integration-agile/ \"Intégration continue et développement agile\"), automatisée et efficace.\n\n## Qu'est-ce que l'intégration continue ?\n\nL'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l’intégration continue ?\") (CI) est une pratique qui consiste à intégrer régulièrement les modifications de code dans la branche principale d'un dépôt de code source partagé. Cette intégration s'effectue dès que possible, et fréquemment. Après chaque validation ou merge, les modifications sont automatiquement testées, puis une compilation est déclenchée sans intervention manuelle. Grâce à l'intégration continue, les équipes peuvent identifier et corriger les erreurs, ainsi que les failles de sécurité, plus facilement et beaucoup plus tôt dans le processus de développement.\n\n## Qu'est-ce que la livraison continue ?\n\n[La livraison continue](https://about.gitlab.com/fr-fr/topics/ci-cd/#what-is-continuous-delivery-cd \"Qu'est-ce que la livraison continue ?\") (CD), également appelée *déploiement continu*, automatise le processus de mise en production des applications. Les équipes de développement ont ainsi plus de temps à consacrer au suivi des déploiements en cours pour en garantir la réussite. Avec la livraison continue, les équipes DevSecOps définissent à l'avance les critères de mise à disposition du code. Une fois ces critères remplis et validés, le code est automatiquement déployé dans l'environnement de production. Cette automatisation permet aux entreprises de gagner en flexibilité et de mettre plus rapidement de nouvelles fonctionnalités à disposition des utilisateurs.\n\n## Quel est le lien entre la gestion du code source et l'approche CI/CD ?\n\nLa [gestion du code source (SCM)](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\") et l'approche CI/CD constituent la base des pratiques modernes de développement logiciel. Les systèmes SCM, comme [Git](https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/ \"Qu'est-ce que Git?\"), offrent une solution centralisée pour suivre les modifications, gérer les versions de code et faciliter la collaboration entre les membres de l'équipe. Lorsqu’un développeur travaille sur une nouvelle fonctionnalité ou une correction de bogues, il crée une branche à partir du code source et apporte ses modifications avant de les [fusionner à l'aide des merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/). Cette stratégie de gestion de branches permet à plusieurs développeurs de travailler simultanément sans interférer avec le code de leurs collègues, tout en maintenant une branche principale stable qui contient un code prêt à être déployé dans l'environnement de production.\n\nL'approche CI/CD automatise les étapes de compilation, de test et de validation du code géré par le système SCM à chaque push de modifications. Lorsqu'un développeur soumet ses modifications de code, le système CI/CD récupère automatiquement le code le plus récent, le combine avec le code source existant, puis exécute une série de vérifications automatisées. Celles-ci comprennent généralement la compilation du code, l'exécution de tests unitaires, l'analyse statique du code et la vérification de la couverture de code. En cas d’échec d’une de ces étapes, l'équipe en est immédiatement informée, ce qui lui permet de résoudre les problèmes avant qu'ils n'affectent d'autres développeurs ou qu'ils n’apparaissent dans l'environnement de production. Cette intégration étroite entre le contrôle de version et l'intégration continue crée une boucle de rétroaction constante qui garantit la qualité du code et prévient l'accumulation de problèmes d'intégration.\n\n## Quels sont les avantages de l'approche CI/CD ?\n\n[L'approche CI/CD apporte de nombreux avantages qui transforment le développement logiciel moderne](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/) et réduisent considérablement les délais ainsi que les risques associés à la livraison de nouvelles fonctionnalités et corrections de bogues. Grâce à une boucle de rétroaction continue, les équipes DevSecOps peuvent garantir que leurs modifications sont automatiquement validées sur l'ensemble du code source. \n\nRésultat : des logiciels de meilleure qualité, des cycles de livraison plus courts et des sorties de nouvelles versions plus fréquentes pour répondre rapidement aux besoins des utilisateurs et aux demandes du marché.\n\nAu-delà des aspects techniques, l'approche CI/CD favorise une culture de collaboration et de transparence au sein des équipes de développement logiciel. Grâce à une visibilité en temps réel du statut des compilations, des tests et des déploiements, il est plus facile d'identifier et de résoudre les goulots d'étranglement dans le processus de livraison. L'automatisation offerte par l'approche CI/CD réduit également la charge cognitive des équipes de développement qui peuvent ainsi se concentrer sur l'écriture de code plutôt que sur la gestion de processus de déploiement manuels. La satisfaction et la productivité des équipes s’améliorent, tandis que les risques généralement associés aux étapes critiques du processus de publication de logiciel diminuent. Les équipes peuvent expérimenter de nouvelles idées sans craindre de compromettre le projet, sachant que des mécanismes de contrôle robustes, comme les revues de code rapides, sont intégrés au processus. Elles peuvent rapidement annuler les modifications si nécessaire. L'approche CI/CD encourage donc une culture d'innovation et d'amélioration continue.\n\n### Quelles sont les principales différences entre l'approche CI/CD et le développement traditionnel ?\n\nL'approche CI/CD diffère du développement logiciel traditionnel à bien des égards, notamment en ce qui concerne les points suivants :\n\n**Validations fréquentes du code**\n\nDans le développement traditionnel, les équipes de développement travaillent souvent de manière isolée et intègrent rarement leurs modifications dans le code source. Cette situation entraîne des conflits de merge et d'autres problèmes chronophages. Avec l'approche CI/CD, les équipes effectuent régulièrement des push de validation, parfois plusieurs fois par jour. De cette manière, les conflits de merge sont détectés rapidement et le code source est maintenu à jour.\n\n**Réduction des risques**\n\nLes méthodes de développement logiciel traditionnelles reposent sur des cycles de test à rallonge et une planification rigoureuse avant la sortie de chaque nouvelle version. Bien que ce type de développement ait pour objectif de réduire au maximum les risques, il entrave souvent la capacité à identifier et à résoudre les problèmes. À l’inverse, l'approche CI/CD permet de gérer les risques en appliquant de petites modifications incrémentielles. Ces changements, surveillés de près, peuvent être facilement annulés en cas de problème.\n\n**Tests automatisés et continus**\n\nDans le cadre du développement logiciel traditionnel, les tests sont généralement exécutés à la fin du processus de développement, ce qui peut entraîner des retards de livraison et des corrections de bogues coûteuses. L'approche CI/CD, en revanche, intègre des tests automatisés qui sont exécutés en continu tout au long du processus de développement logiciel et déclenchés à chaque validation de code. Cette approche permet aux équipes de développement de recevoir des retours immédiats et d’implémenter rapidement les correctifs nécessaires.\n\n**Déploiements automatisés, reproductibles et fréquents**\n\nL’automatisation des déploiements dans l’approche CI/CD réduit le stress et les efforts habituellement associés aux déploiements massifs de logiciels. Ce processus automatisé est reproductible dans tous les environnements et garantit ainsi un gain de temps, une réduction des risques d’erreurs ainsi qu'une cohérence accrue dans chaque déploiement.\n\n## Quels sont les principes fondamentaux de l'approche CI/CD ?\n\nL'approche CI/CD constitue un framework essentiel pour la mise en place de processus de livraison de logiciels évolutifs et régulièrement mis à jour. Pour les équipes DevSecOps, une maîtrise parfaite de ses concepts fondamentaux est indispensable. Une solide compréhension des principes CI/CD permet aux équipes d'adapter leurs stratégies et leurs pratiques aux évolutions technologiques, en s’affranchissant des limitations des méthodes traditionnelles. \n\n### Qu'est-ce qu'un pipeline CI/CD ?\n\nUn [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) est une série d'étapes (compilation, test et déploiement) qui automatise et rationalise le processus de livraison de logiciels. [Chaque étape agit comme un mur qualité](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) et permet de s'assurer que seul le code validé passe à l'étape suivante. Les premières étapes gèrent les vérifications de base, telles que la compilation et les tests unitaires. Les étapes ultérieures, quant à elles, peuvent inclure des tests d'intégration, de performance et de conformité, ainsi que des déploiements échelonnés dans divers environnements.\n\nLe pipeline peut être configuré de manière à nécessiter des approbations manuelles aux points critiques, par exemple avant le déploiement en production, tout en automatisant les tâches routinières. Les équipes de développement obtiennent ainsi un retour rapide sur l'état de leurs modifications. Cette approche structurée assure la cohérence, réduit les erreurs humaines et fournit une piste d'audit claire du transfert des modifications de code de l'environnement de développement vers l'environnement de production. Les pipelines modernes sont souvent implémentés sous forme de code et peuvent ainsi être contrôlés, testés et tenus à jour, de la même manière que le code applicatif.\n\nVoici d'autres termes associés à l'approche CI/CD qu'il est important de connaître :\n\n* **Validation :** une modification apportée au code\n* **Job :** une série d'instructions qu'un runner doit exécuter\n* **Runner :** un agent ou serveur qui exécute chaque job individuellement et qui peut se mettre à l'échelle selon les besoins\n* **Étapes :** un mot-clé qui définit certaines phases spécifiques d'un job, comme la phase de « compilation » et de « déploiement ». Les jobs d'une même étape s’exécutent en parallèle. Les pipelines sont configurés à l'aide d'un fichier YAML nommé `.gitlab-ci.yml`, soumis au contrôle de version et situé à la racine du projet.\n\n![Diagramme représentant un pipeline CI/CD](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## Bonnes pratiques pour réussir votre approche CI/CD\n\nVotre maîtrise de l'approche CI/CD dépend grandement des [bonnes pratiques](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/) que vous mettez en œuvre. \n\n#### Les bonnes pratiques en matière d'intégration continue\n\n* Validez tôt et souvent.\n* Optimisez les étapes du pipeline.\n* Simplifiez et accélérez les compilations.\n* Utilisez les échecs pour améliorer les processus.\n* Assurez-vous que l'environnement de test reflète l'environnement de production.\n\n#### Les bonnes pratiques en matière de livraison continue\n\n* Lancez-vous avec les outils et infrastructures disponibles, puis itérez pour améliorer vos processus.\n* Utilisez le moins d'outils possibles pour optimiser la livraison continue.\n* Surveillez l’avancée des projets en continu afin d’éviter l’accumulation de tickets ou de merge requests.\n* Simplifiez les tests d'acceptation par l'utilisateur et le déploiement vers l'environnement de préproduction grâce à l'automatisation.\n* Automatisez la gestion du pipeline de sortie des nouvelles versions.\n* Mettez en œuvre la surveillance du pipeline pour gagner en visibilité et en productivité. \n\n> ### Pour en savoir plus sur l'approche CI/CD, consultez notre [webinaire « Intro to CI/CD »](https://www.youtube.com/watch?v=sQ7Nw3o0izc).\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y\" title=\"Intro to CI/CD webinar\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Premiers pas avec l'approche CI/CD\n\nPour commencer à utiliser l'approche CI/CD, identifiez un projet simple mais représentatif qui servira de projet pilote. Sélectionnez une application simple avec des exigences de test basiques. Vous pourrez ainsi vous concentrer sur l'apprentissage du fonctionnement des pipelines plutôt que sur des scénarios de déploiement complexes. Assurez-vous que votre code est soumis au [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") et qu'il comporte des [tests automatisés basiques](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/). Même quelques tests unitaires suffisent pour débuter. L'objectif est de [créer un pipeline basique](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/) que vous pourrez améliorer progressivement à mesure que vos compétences progressent.\n\nDans le cas de GitLab, le processus commence par la création d'un fichier `.gitlab-ci.yml` dans le répertoire racine de votre projet. Ce fichier YAML définit les étapes de base (comme la compilation, les tests et le déploiement) et les jobs de votre pipeline. Voici un exemple de pipeline simple : l'étape de « Compilation » compile votre code et crée des artefacts, l'étape de « Test » exécute les tests unitaires et l'étape de « Déploiement » effectue le push de votre application vers un environnement de préproduction. GitLab détecte automatiquement ce fichier et commence à exécuter votre pipeline chaque fois que des modifications sont transmises via un push vers votre dépôt. La plateforme fournit des [runners intégrés](https://docs.gitlab.com/runner/) pour exécuter les jobs de votre pipeline, mais vous pouvez également configurer vos propres runners si vous souhaitez davantage de contrôle.\n\nÀ mesure que vous maîtrisez les éléments de base, enrichissez votre pipeline progressivement avec des fonctionnalités plus avancées. Par exemple, ajoutez des contrôles de qualité du code, [le scanning de sécurité](https://docs.gitlab.com/ee/user/application_security/#security-scanning) ou le déploiement automatisé du nouveau code en production. La plateforme DevSecOps de GitLab inclut des fonctionnalités telles que la [gestion de la conformité](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), les [variables de déploiement](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/) et les portes d'approbation manuelle que vous pouvez intégrer à mesure que votre pipeline évolue. Soyez attentif à la durée d'exécution du pipeline et exécutez dans la mesure du possible des jobs en parallèle. Pensez à ajouter des notifications et un traitement approprié des erreurs afin que les membres de l'équipe soient rapidement informés en cas d’échec de pipeline. Commencez à documenter les problèmes que vous rencontrez le plus souvent et les solutions adoptées. Ces données seront très utiles quand votre équipe s'agrandira.\n\n> ### Vous souhaitez en savoir plus sur l'approche CI/CD ? Inscrivez-vous à notre [cours GitLab University gratuit sur l'approche CI/CD](https://university.gitlab.com/courses/continuous-integration-and-delivery-ci-cd-with-gitlab).\n\n## Sécurité, conformité et approche CI/CD\n\nL'un des plus grands avantages de l'approche CI/CD est la possibilité d'intégrer des contrôles de sécurité et de conformité réguliers, et ce dès les premières étapes du cycle de développement logiciel. Dans GitLab, les équipes peuvent utiliser la configuration `.gitlab-ci.yml` pour déclencher automatiquement des scans de sécurité à plusieurs étapes, de la validation initiale du code à son déploiement en production. Les fonctionnalités d'analyse des conteneurs, d'analyse des dépendances et de scanning de sécurité ([Test dynamique de sécurité des applications](https://docs.gitlab.com/ee/user/application_security/dast/) et [Analyseur Advanced SAST de GitLab](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/)) de la plateforme peuvent être configurées pour s'exécuter automatiquement à chaque modification de code afin de rechercher les vulnérabilités, les violations des exigences de conformité et les erreurs de configuration de sécurité. L'API de la plateforme permet l'intégration avec des [outils de sécurité externes](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/), tandis que les fonctionnalités de couverture des tests garantissent que les tests de sécurité répondent aux seuils requis.\n\nLes rapports de test de sécurité de GitLab fournissent des informations détaillées sur les découvertes de vulnérabilités afin de remédier rapidement aux problèmes de sécurité avant qu'ils n'atteignent l'environnement de production. Le tableau de bord relatif à la sécurité fournit une vue centralisée des vulnérabilités détectées dans les différents projets, tandis que des [stratégies de sécurité peuvent être appliquées](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/) via les approbations de merge request et les portes dans les pipelines. GitLab offre plusieurs niveaux de gestion des secrets pour protéger les données sensibles tout au long du processus CI/CD, y compris des journaux d'audit permettant de suivre l'accès à ces secrets. De plus, un contrôle d'accès basé sur les rôles (RBAC) garantit que seuls les utilisateurs autorisés peuvent consulter ou modifier les données de configuration sensibles.\n\nGitLab prend également en charge la génération de [nomenclatures logicielles (SBOM)](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/), qui fournissent un inventaire complet de l'ensemble des composants logiciels, dépendances et licences dans une application. Elles permettent aux équipes d'identifier et de corriger rapidement les vulnérabilités, ainsi que de se conformer aux exigences réglementaires.\n\n## Approche CI/CD et cloud\n\nLa plateforme CI/CD de GitLab offre une intégration robuste avec les principaux fournisseurs de services cloud, notamment [Amazon Web Services](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/), [Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/) et [Microsoft Azure](https://docs.gitlab.com/ee/install/azure/). Les équipes de développement logiciel peuvent ainsi automatiser leurs déploiements cloud directement à partir de leurs pipelines. Grâce aux intégrations cloud de GitLab, elles peuvent également gérer les ressources cloud, déployer des applications et surveiller les services cloud directement depuis l'interface de GitLab. Les templates de déploiement cloud intégrés et les fonctionnalités [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) de la plateforme réduisent considérablement la complexité des déploiements cloud. Les membres de l'équipe peuvent ainsi se concentrer sur le développement d'applications plutôt que sur la gestion de l'infrastructure. Pour les entreprises qui souhaitent automatiser leur infrastructure informatique à l'aide de [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Qu'est-ce que GitOps ?\"), GitLab propose l'[intégration Flux CD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/).\n\nLes fonctionnalités cloud de GitLab vont au-delà de la simple automatisation des déploiements. L'[intégration Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") à la plateforme GitLab permet aux équipes de gérer l'orchestration des conteneurs entre plusieurs fournisseurs de services cloud. De plus, les [options d'installation cloud-native de GitLab](https://about.gitlab.com/fr-fr/topics/ci-cd/cloud-native-continuous-integration/) permettent à la plateforme elle-même de fonctionner dans des environnements cloud. Grâce à ces fonctionnalités cloud-native, les équipes peuvent mettre en œuvre des runners à mise à l'échelle automatique qui provisionnent dynamiquement les ressources cloud pour l'exécution de pipelines afin d'optimiser les coûts et les performances. Enfin, l'intégration de la plateforme avec les services de sécurité des fournisseurs de services cloud garantit le respect des exigences de sécurité et de conformité tout au long du processus de déploiement.\n\nPour les environnements multicloud, GitLab fournit des workflows et des outils cohérents, quel que soit le fournisseur de services cloud sous-jacent. Les équipes de développement peuvent utiliser les fonctionnalités de gestion de l'environnement de GitLab pour gérer différentes configurations cloud dans les environnements de développement, de préproduction et de production. La prise en charge de l'[Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/infrastructure/iac/) de la plateforme GitLab, en particulier son intégration native avec Terraform, permet aux équipes de développement de contrôler les versions et d'automatiser le provisionnement de leur infrastructure cloud. Les fonctionnalités de surveillance et d'[observabilité](https://about.gitlab.com/fr-fr/blog/observability-vs-monitoring-in-devops/ \"Qu'est-ce que l'observabilité ?\") de GitLab s'intègrent aux indicateurs des fournisseurs de services cloud, offrant une visibilité complète de l'intégrité des applications et de l'infrastructure dans les différents environnements cloud.\n\n## Pipeline CI/CD avancé\n\nL'approche CI/CD a connu une évolution significative qui va bien au-delà de la simple construction et du déploiement de pipelines. Dans les mises en œuvre avancées, elle implique une orchestration sophistiquée des tests automatisés, du scanning de sécurité, du provisionnement de l'infrastructure, de l'IA et de bien d'autres aspects. Voici quelques stratégies CI/CD avancées pour aider les équipes d'ingénierie à améliorer leurs pipelines et à résoudre les problèmes qui surviennent, même lorsque la complexité de l'architecture augmente.\n\n### Réutilisation et automatisation des pipelines CI/CD\n\nGitLab révolutionne les pratiques des équipes de développement logiciel et de gestion des pipelines CI/CD en introduisant deux innovations majeures : le [catalogue CI/CD](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) et [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/). Ce dernier est un nouveau langage de programmation expérimental dédié à l'automatisation DevSecOps. Le catalogue CI/CD est une plateforme centralisée où les équipes peuvent découvrir, réutiliser et optimiser les différents composants CI/CD. Ces derniers fonctionnent comme des blocs de construction réutilisables et à usage unique qui simplifient la configuration des pipelines au sein des workflows CI/CD. Parallèlement, CI/CD Steps offre la possibilité de gérer des workflows complexes en permettant aux équipes de configurer les entrées et sorties pour chaque job CI/CD. Avec le catalogue CI/CD et CI/CD Steps, les équipes DevSecOps peuvent facilement standardiser l'approche CI/CD et ses composants, et ainsi simplifier le processus de développement et de maintenance des pipelines CI/CD.\n\n> Pour en savoir plus, consultez notre [FAQ sur le catalogue CI/CD](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) et notre [documentation sur CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/).\n\n### Dépannage des pipelines avec l'IA\n\nBien qu'une défaillance des pipelines CI/CD soit possible, le dépannage rapide du problème peut considérablement réduire son impact. L'analyse des causes profondes de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo ?\"), l'une des fonctionnalités alimentées par l'IA, élimine les hypothèses en [déterminant la cause profonde de l'échec d'un pipeline CI/CD](https://about.gitlab.com/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/ \"Échecs de pipelines CI/CD\"). Lorsqu'un pipeline échoue, GitLab fournit des job logs détaillés, des messages d'erreur et des traces d'exécution qui indiquent exactement où et pourquoi l'échec s'est produit. L'analyse des causes profondes utilise ensuite l'IA pour suggérer une solution.\n\nDécouvrez la fonctionnalité d'analyse des causes profondes de GitLab Duo en action :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Comment migrer son code vers un pipeline GitLab CI/CD ?\n\nLa migration vers la plateforme DevSecOps de GitLab et son pipeline CI/CD intégré implique l'analyse systématique de vos configurations de pipeline, dépendances et processus de déploiement existants pour les mapper aux fonctionnalités et à la syntaxe équivalentes de GitLab. \n\nConsultez nos ressources pour faciliter votre migration vers GitLab CI/CD : \n\n* [Migration de Bamboo vers GitLab CI/CD](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)\n* [De Jenkins à GitLab : le guide complet pour moderniser votre environnement CI/CD](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n* [Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet](https://about.gitlab.com/fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate/)\n\n## Témoignages d'entreprises leaders dans leur domaine\n\nCes entreprises de premier plan ont migré vers GitLab et profitent des innombrables avantages de l'approche CI/CD. Découvrez leurs témoignages.\n\n* [Lockheed Martin](https://about.gitlab.com/fr-fr/customers/lockheed-martin/)\n* [Indeed](https://about.gitlab.com/fr-fr/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n* [CARFAX](https://about.gitlab.com/fr-fr/customers/carfax/)\n* [HackerOne](https://about.gitlab.com/fr-fr/customers/hackerone/)\n* [Betstudios](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/)\n* [Thales et Carrefour](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/)\n\n## Tutoriels CI/CD\n\nDevenez un expert des pipelines CI/CD à l'aide de ces tutoriels : \n\n* [Intégration continue : créez votre premier pipeline CI avec GitLab](https://about.gitlab.com/fr-fr/blog/basics-of-gitlab-ci-updated/)\n* [Configuration de votre premier composant GitLab CI/CD](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [GitLab CI/CD : comment créer facilement un pipeline pour un monorepo](https://about.gitlab.com/fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [Déployer en continu dans de multiples environnements avec les pipelines enfants](https://about.gitlab.com/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)\n* [Refactorisation d'un template CI/CD en composant CI/CD](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)\n\n> ### Commencez un [essai de GitLab Ultimate](https://gitlab.com/-/trials/new) et essayez gratuitement GitLab CI/CD pendant 60 jours.",[109,718,800,802,781,769],{"slug":944,"featured":91,"template":806},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"content":946,"config":955},{"title":947,"description":948,"authors":949,"heroImage":951,"date":952,"body":953,"category":722,"tags":954},"Pourquoi choisir une plateforme DevSecOps unifiée ?","Découvrez comment GitLab combine des outils et fonctionnalités avancés, une sécurité renforcée, tout en tirant parti de l'IA pour accélérer et optimiser le développement logiciel.",[950],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","2025-06-19","Face aux défis croissants du développement logiciel moderne, de nombreuses entreprises migrent vers le cloud et adoptent des processus DevSecOps. Elles sont cependant confrontées à un défi de taille : les nombreux outils et systèmes hérités ne sont pas adaptés à cette évolution et les obligent souvent à créer des intégrations complexes entre une multitude d'outils pour la gestion des tâches, les pipelines CI/CD, la sécurité, la surveillance, entre autres. Cette mosaïque d’outils entraîne une complexité opérationnelle, des coûts de maintenance élevés et freine la collaboration entre les équipes de développement et celles des opérations. Les développeurs, quant à eux, éprouvent de la frustration, car ils passent constamment d'un outil à l'autre pour un même workflow de développement, de la planification à la production.\n\n![Complexité et coûts opérationnels inhérents à l'intégration de plusieurs outils dans un processus DevSecOps](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>Degré de complexité de l'intégration de plusieurs outils dans un processus DevSecOps\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nBonne nouvelle, une solution existe : une plateforme DevSecOps complète offrant une approche unifiée du développement logiciel.\n\nCette plateforme est conçue pour les entreprises opérant dans des environnements cloud et [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps?\") : tous les aspects du développement logiciel (gestion du code, processus CI/CD, gestion des tâches, sécurité, automatisation pilotée par l'IA) s'effectuent depuis une seule interface. Ainsi, tous les workflows sont centralisés, offrant aux équipes de développement et des opérations une collaboration optimisée, une communication rationalisée et une réduction significative des complexités et des perturbations opérationnelles.\n\nEn outre, l'expérience développeur s'améliore considérablement : les équipes d’ingénierie sont beaucoup plus heureuses de travailler avec un produit conçu spécifiquement pour les besoins du développement moderne.\n\nDécouvrez comment GitLab simplifie la gestion de projet, renforce la [sécurité et la conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et conformité\"), et intègre l’IA pour transformer le développement logiciel et aider les équipes à surmonter les défis courants.\n\n## Gestion de projet Agile intégrée\n\nGitLab fournit une solution holistique qui rassemble toutes les fonctionnalités nécessaires pour la gestion des projets et des tâches. Cette intégration couvre toutes les étapes du développement logiciel, y compris les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Les équipes peuvent ainsi suivre en temps réel la progression du projet. Les tickets et les epics sont directement liés aux processus d'automatisation. De la planification au déploiement en production, toutes les étapes s'effectuent sans accroc. La transparence entre les équipes est ainsi renforcée, les retards sont réduits et toutes les parties prenantes ont une vision claire de l'état du développement en temps réel.\n\n![Les tickets et les epics sont directement liés aux processus d'automatisation. De la planification au déploiement en production, toutes les étapes s'effectuent sans accroc.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## Sécurité intégrée\n\nLa sécurité est au cœur de GitLab avec l'intégration de fonctionnalités de sécurité complètes. La plateforme intègre un large éventail de [scanners de sécurité](https://about.gitlab.com/fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab/ \"Qu'est-ce qu'un scanner de securité ?\") automatisés, notamment :\n\n* [L'analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n* [Les tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n* [Les tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n* [La détection des secrets](https://docs.gitlab.com/user/application_security/secret_detection/)\n* [L'analyse des conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![Fonctionnalités de scanning de sécurité intégrées dans le processus CI/CD à différentes étapes du développement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>Fonctionnalités de scanning de sécurité intégrées dans le processus CI/CD à différentes étapes du développement\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nCes contrôles de sécurité sont intégrés à chaque étape du cycle de développement logiciel, y compris dans les pipelines CI/CD, et offrent aux équipes de développement des retours immédiats sur les failles de sécurité potentielles, et ce dès le début du cycle de développement.\n\n## Conformité et exigences réglementaires\n\nAu-delà de la productivité et de l'expérience utilisateur, de nombreuses entreprises, en particulier celles opérant dans les secteurs réglementés tels que les institutions financières ou les grands groupes, doivent s'assurer que leurs processus respectent des normes de sécurité et de conformité strictes. Elles doivent pouvoir appliquer des stratégies pour différents projets, par exemple en rendant obligatoire l'utilisation d'un scanner de sécurité chaque fois qu'un pipeline CI/CD s'exécute sur des branches de code spécifiques (par exemple, les branches principales ou protégées) ou en exigeant des approbations spécifiques avant de fusionner le code dans la branche principale.\n\nTout devient plus facile avec les [frameworks de conformité](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) de GitLab : cette fonctionnalité permet aux entreprises de définir et d'appliquer des stratégies structurées aux projets sélectionnés. Cette approche garantit la conformité en appliquant sans intervention manuelle des exigences réglementaires et de sécurité, tout en maintenant un workflow de développement fluide et efficace.\n\n## Développement alimenté par l'IA\n\n[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) offre une assistance pilotée par l'IA à chaque étape du développement logiciel. Par conséquent, aucun outil externe n'est nécessaire. Chaque requête alimentée par l'IA est traitée dans le contexte complet du projet et du code base, ce qui permet de travailler de façon plus intelligente et plus efficace.\n\nL'IA peut effectuer de nombreuses tâches, notamment :\n\n* Générer automatiquement des descriptions de tâches\n* Synthétiser les discussions des tickets pour gagner un temps précieux\n* Enrichir la revue de code\n* Suggérer des améliorations pour optimiser le code\n* Automatiser la génération de tests\n* Détecter et corriger les failles de sécurité\n* Réaliser une analyse des causes profondes en cas d'échec des pipelines CI\n* Garantir le respect de la confidentialité et la sécurité des données\n\nGrâce à sa compréhension des besoins des entreprises opérant dans les secteurs fortement réglementés, en particulier dans le [secteur public](https://about.gitlab.com/fr-fr/solutions/public-sector/) et le [secteur financier](https://about.gitlab.com/fr-fr/solutions/finance/), GitLab offre une plateforme unique qui permet d'exécuter des modèles d'IA dans un environnement sécurisé.\n\n[GitLab Duo Self-Hosted](https://about.gitlab.com/fr-fr/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy/ \"GitLab Duo Self-Hosted\") permet de garder un contrôle total sur la confidentialité des données, la sécurité et le déploiement de [grands modèles de langage (LLM)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/ \"Qu'est-ce qu'un grand modèle de language ?\") dans leur propre infrastructure et garantit ainsi :\n\n* La protection de la confidentialité des données\n* La conformité aux exigences réglementaires\n* Une sécurité maximale\n* Tous les avantages de l’IA, sans dépendre d’un réseau externe ni exposer vos systèmes à des risques\n\n## GitLab, une plateforme moderne et complète\n\nLes entreprises ont besoin d'une plateforme DevSecOps complète pour rationaliser leurs processus, renforcer la sécurité et accélérer l'innovation. C'est précisément ce qu'offre GitLab : une application unique, qui regroupe tous les outils essentiels aux équipes de développement, de sécurité et des opérations, avec une sécurité intégrée et une automatisation alimentée par l'IA.\n\nPour en savoir plus sur GitLab, découvrez nos démonstrations interactives :\n\n* [GitLab Premium et Ultimate avec GitLab Duo](https://gitlab.navattic.com/gitlab-premium-with-duo) : l'assistance au développement alimentée par l'IA\n* [La sécurité dans les pipelines CI/CD](https://gitlab.navattic.com/gitlab-scans) : l'analyse de sécurité intégrée qui protège vos logiciels\n* [Frameworks de conformité](https://gitlab.navattic.com/compliance) : des stratégies appliquées à l'ensemble des projets pour une meilleure gouvernance\n\n> Participez à notre événement virtuel à l'occasion du lancement de GitLab 18 et découvrez ce que vous réserve notre plateforme DevSecOps, notamment le rôle de l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique?\"). [Inscrivez-vous dès aujourd'hui !](https://about.gitlab.com/fr-fr/eighteen/)",[718,800,769],{"slug":956,"featured":6,"template":806},"why-are-organizations-moving-to-a-unified-devsecops-platform",{"content":958,"config":967},{"title":959,"description":960,"authors":961,"heroImage":963,"date":964,"body":965,"category":722,"tags":966},"Guide d'introduction aux serveurs Linux : définition, avantages, usage et installation","Le serveur Linux est couramment utilisé dans les entreprises. Découvrez ses fonctionnalités, ses utilisations et ses avantages.",[962],"GitLab France Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663065/Blog/Hero%20Images/serveur-linux.jpg","2024-12-04","Lancé en 1991 comme alternative à Minix, il adopte la licence GNU GPL en février 1992. Linux est aujourd’hui le système d'exploitation le plus utilisé pour la gestion des serveurs d'entreprise. Les serveurs Linux répondent aux besoins d'entreprises de toutes tailles, leur fournissant une plateforme performante et économique pour piloter de nombreuses applications informatiques. Qu'est-ce qu'un serveur Linux ? Quels en sont les avantages et les usages ? Comment installer un serveur Linux ? Voici l'essentiel à savoir pour lancer votre projet sous Linux.\n\n## Qu'est-ce qu'un serveur Linux ?\n\nUn serveur Linux est un serveur informatique opéré avec le système d'exploitation Linux. Linux fut créé en 1991 par le Finlandais Linus Torvalds, sous forme de noyau de système d'exploitation de type Unix. Trois décennies plus tard, il se conçoit aujourd'hui comme une suite cohérente de logiciels formant un __système d'exploitation entièrement opérationnel__, appelée une distribution Linux.  \n\nLes distributions GNU/Linux s'utilisent principalement pour gérer des fonctions informatiques côté serveur (backend). Nous pouvons citer l'hébergement Web, la gestion de réseau et le stockage de données. Linux est open source, ainsi les équipes opérationnelles peuvent télécharger gratuitement une distribution Linux et l'adapter à leurs besoins. Le système d'exploitation Linux est disponible sous différentes distributions GNU/Linux, telles que Debian, Ubuntu ou openSUSE offrant aux équipes de développement un surcroît de flexibilité et de personnalisation. \n\n## Quels sont les avantages d’un serveur Linux ?\n\nLe succès des serveurs Linux s'explique en grande partie par leur accessibilité et leur flexibilité. Mais le système d'exploitation Linux est aussi reconnu pour sa stabilité et sa sécurité, des critères cruciaux pour les infrastructures de serveurs d'entreprise. Certifié par la Free Software Fondation, Linux est un logiciel libre dont le code source est ouvert, ce qui facilite la correction des bogues et des failles de sécurité. \n\nSon __écosystème open source__ cimente aussi la popularité de Linux auprès des développeurs et des ingénieurs informatiques. Une communauté très active promeut GNU/Linux et favorise sa sécurisation et son développement. En résumé, gérer un serveur sous Linux comporte de nombreux avantages : \n\n- __Réduction des coûts.__ Vous pouvez télécharger, utiliser et modifier Linux sans frais de licence, ce qui permet de réaliser d'importantes économies sur les dépenses informatiques. De nombreuses applications compatibles avec Linux sont aussi disponibles gratuitement.\n- __Sécurité.__ Linux offre un niveau de protection avancé, avec un logiciel libre, des mises à jour régulières, des correctifs de sécurité rapidement publiés, et un soutien de la communauté des développeurs et développeuses.\n- __Scalabilité.__ Les serveurs Linux peuvent facilement évoluer en fonction des charges de travail et du nombre d'utilisateurs. Cette souplesse est appréciée par les entreprises en croissance, et idéale pour les [projets DevOps des PME](https://about.gitlab.com/fr-fr/small-business/ \"Projets DevOps des PME\").\n- __Flexibilité.__ Linux offre un degré de personnalisation poussé, les équipes de développement pouvant adapter le logiciel aux spécificités de leur architecture et de leurs applications. Ils disposent aussi d'un large choix parmi les nombreuses distributions GNU/Linux disponibles.\n\n## Comment utiliser un serveur Linux ?\n\nPar leur versatilité, les serveurs Linux se révèlent précieux pour un grand nombre d'usages informatiques. Ils excellent dans les applications d'entreprise les plus sensibles et les plus complexes. Voici quelques exemples d'utilisations fréquentes d'un serveur sous Linux : \n\n- __Hébergement Web__, qui nécessite de gérer de fortes charges de trafic. Des outils très performants dans ce domaine comme Apache et Nginx fonctionnent de façon optimale sous Linux.\n- __Administration système et réseau.__ Avec des commandes en ligne puissantes, des fonctionnalités avancées de routage et de contrôle du trafic intégrées dans le noyau, une maintenance simple et un fonctionnement stable et sobre en ressources, Linux est le système d'exploitation de choix des administrateurs réseau. \n- __Gestion de bases de données.__ Linux procure une robustesse et une scalabilité incomparables pour utiliser les solutions de gestion des données les plus performantes, comme PostgreSQL, MongoDB ou MariaDB. \n- __Cloud et virtualisation.__ Les serveurs Linux permettent de maximiser les performances des logiciels et des serveurs virtuels. Ils sont naturellement plébiscités pour les [applications cloud-native des entreprises](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Applications cloud-natives des entreprises\").  \n\nLe champ d'utilisation des serveurs sous Linux ne se limite pas à ces exemples. Analyse de données, jeux en ligne, transferts de fichier, business intelligence, messagerie… Les équipes choisissent souvent GNU/Linux pour des projets informatiques qui nécessitent un haut degré de contrôle et de sécurisation, et font appel à des applications avancées et exigeantes en ressources.\n\n### Conseils pour administrer un serveur Linux\n\nSi vous souhaitez tirer pleinement parti des capacités offertes par Linux, nous vous conseillons de suivre certaines bonnes pratiques dans l'administration d'un serveur Linux en entreprise. Pour assurer un démarrage réussi, il est essentiel de __former votre équipe IT__ aux commandes en ligne, aux configurations de sécurité et aux techniques de dépannage. Utilisez des __outils de surveillance__ compatibles avec Linux, tels que Prometheus, Nagios ou Zabbix, pour maintenir la fiabilité de votre infrastructure à long terme.\n\nLa __planification des sauvegardes__ est un autre point crucial pour assurer la viabilité de votre projet. Vous pouvez utiliser la règle du 3-2-1. Sauvegardez trois copies des données, stockez deux copies sur des supports différents, dont une sera placée hors site. Enfin, une bonne gestion de serveur Linux requiert une attention particulière aux __mesures de sécurité__. Nous recommandons la mise en place de clés SSH pour les mots de passe, de logiciels pare-feu et de détection des intrusions comme Fail2ban, et d'une authentification à deux facteurs.\n\n## Comment installer un serveur Linux ?\n\nProlongeons ce guide d'introduction sur une note plus pratique. Voici un tutoriel sur le serveur Linux qui vous accompagnera dans l'installation de ce logiciel en entreprise. Suivez les principales étapes pour installer un serveur Linux :\n\n1. Choisissez une __distribution Linux__ adaptée. Optez par exemple pour Ubuntu Server, connu pour sa facilité d'utilisation, ou Debian, réputé pour sa robustesse.\n2. Créez une __ISO bootable__ de la distribution Linux. Téléchargez-la sur le site officiel et placez-la sur une clé USB pour lancer l'installation sur le serveur.\n3. __Installez Linux__ à partir de la clé USB. Procédez à la configuration de base, à la partition du disque, à la configuration de l'utilisateur, au redémarrage et la première connexion.\n4. __Effectuez la configuration initiale__ du serveur Linux : sécurisez l’accès par SSH, créez un utilisateur non-root, configurez le pare-feu et mettez à jour le système.\n5. __Configurez le réseau.__ Choisissez une IP statique ou dynamique, configurez les DNS et la redirection des ports.\n\nEnfin, pour terminer l'installation du serveur Linux, veillez à parfaire la sécurisation du serveur avec installation d'un pare-feu, d'un certificat SSL et d'outils de surveillance du réseau. Une fois ces étapes terminées, votre serveur Linux est prêt à fonctionner. \n\n## Lancez un projet avec GitLab et Linux\n\nSi Linux a toujours dominé le secteur des serveurs d'entreprise, il connaît aussi un regain de popularité du côté du grand public. Au succès relatif des distributions adaptées aux utilisateurs sur PC, telles que Linux Mint et Ubuntu, s'ajoute l'essor des systèmes d'exploitation Android et Chrome OS pour mobiles et tablettes, qui sont basés sur le noyau Linux. Investir dans des applications fonctionnant sous Linux apparaît comme une stratégie gagnante à long terme, tant le succès de ce logiciel ne se dément pas.\n\nGitLab et Linux offrent un environnement idéal pour développer vos activités de façon agile et profiter de tous nos outils de collaboration. La plateforme GitLab prend en charge de nombreux paquets Linux officiels, tels que Debian, Ubuntu, AlmaLinux et CentOS 7. Rendez-vous sur notre page d'information pour [installer GitLab avec un serveur Linux](https://about.gitlab.com/fr-fr/install/#official-linux-package \"Installer GitLab avec un serveur Linux\") et mener à bien votre projet.\n\n## Installer une distribution Linux avec GitLab\n\n- [Paquet Ubuntu](https://about.gitlab.com/fr-fr/install/#ubuntu \"Paquet Ubuntu\")\n- [Paquet Debian](https://about.gitlab.com/fr-fr/install/#debian \"Paquet Debian\")\n- [Paque AlmaLinux](https://about.gitlab.com/fr-fr/install/#almalinux \"Paque AlmaLinux\")\n- [Paquet CentOS 7](https://about.gitlab.com/fr-fr/install/#centos-7 \"Paquet CentOS 7\")\n- [Paquet OpenSUSE Leap](https://about.gitlab.com/fr-fr/install/#opensuse-leap \"Paquet OpenSUSE Leap\")\n- [Paquet Amazon Linux 2](https://about.gitlab.com/fr-fr/install/#amazonlinux-2 \"Paquet Amazon Linux 2\")\n- [Paquet Raspberry Pi](https://about.gitlab.com/fr-fr/install/#raspberry-pi-os \"Paquet Raspberry Pi\")\n",[927,898],{"slug":968,"featured":6,"template":806},"introduction-guide-to-linux-servers",{"category":730,"slug":734,"posts":970},[971,983,999],{"content":972,"config":981},{"title":973,"description":974,"date":975,"body":976,"heroImage":977,"authors":978,"category":734,"tags":980},"Amélioration de la gestion des tickets créés par la communauté GitLab","Découvrez comment nous améliorons la gestion des tickets pour prioriser le travail stratégique, optimiser la livraison de logiciels et créer des boucles de rétroaction plus efficaces avec nos utilisateurs.","2025-07-30","Chez GitLab, nous sommes fiers de la relation solide et collaborative que nous entretenons avec notre communauté. Nous encourageons chacun à contribuer à GitLab. Au fil des années, ces contributions communautaires ont permis de renforcer notre plateforme. Mais au fur et à mesure de notre croissance, la participation de la communauté via les tickets GitLab a également augmenté, créant un backlog de tickets difficile à gérer.\n\nLes équipes chargées du produit et de l'ingénierie de GitLab ont récemment lancé [une initiative pour traiter ce backlog et affiner notre approche de la gestion des tickets](https://gitlab.com/groups/gitlab-org/-/epics/18639). \n\nLes tickets avec un engagement communautaire continu, une activité récente ou un alignement stratégique clair resteront ouverts. Nous fermerons les tickets qui ne sont plus pertinents, qui manquent d'intérêt ou qui ne correspondent plus à notre direction produit.\n\nCette approche ciblée conduira à une innovation accrue, à une meilleure définition des attentes et à des cycles de développement et de livraison plus rapides pour les fonctionnalités proposées par la communauté.\n\n## Présentation de l'initiative\n\nAu fil du temps, la communauté GitLab a soumis des dizaines de milliers de tickets, incluant des bogues, des demandes de fonctionnalités et des retours. Actuellement, [notre système principal de suivi des tickets](https://gitlab.com/gitlab-org/gitlab/-/issues) contient plus de 65 000 tickets. Certains ne sont plus applicables à la plateforme, tandis que d'autres restent toujours pertinents. \n\nAvec cette initiative, nos équipes chargées du produit et de l'ingénierie pourront réduire le backlog et établir un workflow afin de mettre en œuvre une approche plus ciblée de la gestion du backlog. Elles effectueront des évaluations hebdomadaires du backlog pour s'assurer que nous priorisons les tickets qui s'alignent avec notre stratégie produit et notre roadmap.\n\nRemarque : Si vous pensez qu’un ticket fermé s'aligne avec la stratégie produit et la roadmap de GitLab, ou si vous contribuez activement à cette demande, nous vous encourageons à commenter le ticket. Nous nous engageons à examiner ces tickets mis à jour dans le cadre de nos efforts d'évaluation réguliers.\n\n## Quels sont les avantages ?\n\nCette approche rationalisée apporte des améliorations directes et concrètes pour chaque utilisateur de GitLab :\n\n* **Un focus plus précis et une livraison plus rapide :** en recentrant notre backlog sur des fonctionnalités stratégiquement alignées, nous pouvons allouer nos ressources de développement plus efficacement. Cela signifie que vous pouvez vous attendre à des cycles de développement plus courts et à des améliorations plus significatives de votre expérience GitLab.\n* **Des attentes plus claires :** nous nous engageons à communiquer de manière transparente sur ce qui figure ou non dans notre roadmap, afin que vous puissiez prendre des décisions éclairées concernant vos workflows et vos contributions.\n* **Des boucles de rétroaction accélérées :** avec un backlog épuré, les nouveaux retours et demandes de fonctionnalités seront examinés et priorisés plus efficacement, réduisant le temps global de triage et garantissant que les tickets urgents reçoivent l'attention nécessaire. Cela crée une boucle de rétroaction plus réactive pour tous.\n\nCette initiative ne diminue pas l'importance des retours et des contributions de la communauté. Nous prenons cette mesure pour clarifier ce que les membres de l'équipe GitLab peuvent réellement s'engager à livrer, et pour garantir que tous les retours reçoivent la considération appropriée.\n\n## Perspectives d'avenir\n\nCette initiative reflète notre engagement à être des gestionnaires transparents et efficaces de la plateforme GitLab. En communiquant clairement nos priorités et en concentrant nos efforts sur ce que nous pouvons réellement livrer au cours de l'année à venir, nous sommes mieux positionnés pour répondre et dépasser vos attentes.\n\nVotre participation et vos retours continus contribuent à renforcer GitLab. Chaque commentaire, merge request, rapport de bogue et suggestion de fonctionnalité contribue à notre vision commune. Et nous continuons à vous récompenser pour cela, avec des initiatives comme notre programme mensuel Notable Contributor, des récompenses, et plus encore, via notre [portail dédié aux contributeurs](https://contributors.gitlab.com/).\n\nPour en savoir plus sur comment contribuer à GitLab, consultez notre [page Communauté](https://about.gitlab.com/community/). Pour partager vos retours sur cette initiative, veuillez ajouter vos commentaires sur [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/556865).","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png",[979],"Stan Hu",[269,769,746],{"featured":6,"template":806,"slug":982},"inside-gitlabs-healthy-backlog-initiative",{"content":984,"config":997},{"heroImage":985,"body":986,"authors":987,"updatedDate":990,"date":991,"title":992,"tags":993,"description":996,"category":734},"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","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\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://about.gitlab.com/releases/2025/05/15/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.",[988,989],"Karthik Nayak","Manuel Kraft","2025-07-09","2025-06-05","Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min ",[994,898,995],"git","performance","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.",{"slug":998,"featured":91,"template":806},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"content":1000,"config":1010},{"title":1001,"description":1002,"authors":1003,"heroImage":1004,"date":1005,"body":1006,"category":734,"tags":1007,"updatedDate":1009},"Comment automatiser la migration des images de conteneurs d'Amazon ECR vers GitLab","Suivez ce guide étape par étape pour automatiser le processus de migration de vos images de conteneurs d’Amazon ECR vers GitLab.",[878],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","2025-02-13","« Nous devons migrer des centaines d'images de conteneurs d'Amazon Elastic Container Registry (ECR) vers GitLab. Pouvez-vous nous aider ? » Cette question revenait sans cesse lors de nos échanges avec des ingénieurs de plateforme. En pleine modernisation de leur chaîne d'outils DevSecOps avec GitLab, ils se retrouvaient bloqués au moment de déplacer leurs images de conteneurs. D’un point de vue technique, chaque transfert est simple. Mais, l'opération était longue et fastidieuse en raison du volume considérable d'images.\n\nUn ingénieur de plateforme a parfaitement résumé la situation : « Je connais parfaitement le processus : effectuer un pull, retagger, effectuer un push. Le problème, c'est que je gère 200 microservices, chacun contenant plusieurs tags. Je ne peux pas passer plusieurs semaines sur cette migration alors que j'ai des tâches critiques à effectuer au niveau de l'infrastructure. »\n\n## Le défi\n\nCette conversation nous a fait réfléchir et a donné naissance à une idée. Et si nous pouvions automatiser l'ensemble du processus ? Lorsqu'une équipe de plateforme DevOps transfère ses [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") vers GitLab, la migration des images de conteneurs ne devrait pas poser de difficulté particulière. Le processus manuel est rudimentaire, mais répétitif : il s'agit d'effectuer un pull de chaque image, de la retagger et d'effectuer un push pour la migrer vers le registre de conteneurs de GitLab. Réaliser cette même opération pour des dizaines de dépôts et plusieurs tags par image requiert des jours ou des semaines de travail chronophage.\n\n## La solution\n\nNous avons donc entrepris de créer un pipeline GitLab qui effectuerait automatiquement cette lourde tâche. L'objectif était clair : fournir aux ingénieurs de plateforme un outil qu'ils pourraient configurer en quelques minutes et qui, en une seule nuit, parviendrait à migrer toutes leurs images.\n\n### Configuration des accès\n\nCommençons par l'essentiel : les aspects liés à la sécurité. Nous voulions nous assurer que les équipes puissent exécuter cette migration avec un minimum d'autorisations sur AWS. Voici la politique de gestion des identités et des accès (IAM) en lecture seule dont vous avez besoin :\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n```\n\n### Configuration de GitLab\n\nUne fois la sécurité en place, l'étape suivante consiste à configurer GitLab. Nous avons volontairement réduit cela au strict minimum : il vous suffit de configurer les variables suivantes dans les paramètres CI/CD de votre projet :\n\n```\nAWS_ACCOUNT_ID: Your AWS account number\nAWS_DEFAULT_REGION: Your ECR region\nAWS_ACCESS_KEY_ID: [Masked]\nAWS_SECRET_ACCESS_KEY: [Masked]\nBULK_MIGRATE: true\n```\n\n### Le pipeline de migration \n\nPassons maintenant à la partie la plus intéressante. Nous avons créé le pipeline en utilisant Docker-in-Docker pour gérer toutes les opérations liées aux images de manière fiable :\n\n```yaml\nimage: docker:20.10\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\nLe pipeline fonctionne en trois phases, chacune s'appuyant sur la précédente :\n\n1. Identification\n\nDans un premier temps, il détecte l'ensemble de vos dépôts :\n\n```bash\nREPOS=$(aws ecr describe-repositories --query 'repositories[*].repositoryName' --output text)\n```\n\n2. Énumération des tags\n\nEnsuite, pour chaque dépôt, il récupère l'ensemble des tags :\n\n```bash\nTAGS=$(aws ecr describe-images --repository-name $repo --query 'imageDetails[*].imageTags[]' --output text)\n```\n\n3. Transfert\n\nEnfin, il gère la migration proprement dite :\n\n```bash\ndocker pull ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\ndocker tag ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag} ${CI_REGISTRY_IMAGE}/${repo}:${tag}\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n```\n\n## Résultats\n\nVoici ce que cette solution offre comme avantages aux ingénieurs de plateforme qui ne veulent pas passer plusieurs semaines sur la migration :\n\n- Identification et migration automatisées de l'ensemble des dépôts et tags\n- Dénomination cohérente des images entre ECR et GitLab\n- Gestion des échecs de transferts\n- Journalisation claire pour suivre la progression\n\nAu lieu d'écrire des scripts et de surveiller la migration, l'ingénieur de plateforme peut se concentrer sur des tâches à plus grande valeur ajoutée.\n\n## Utilisation\n\nLa première étape est très simple :\n\n1. Copiez le fichier `.gitlab-ci.yml` dans votre dépôt.\n2. Configurez les variables AWS et GitLab.\n3. Définissez `BULK_MIGRATE` sur « true » pour déclencher la migration.\n\n## Bonnes pratiques\n\nEn accompagnant plusieurs équipes dans leur migration, nous avons tiré quelques enseignements pratiques :\n\n- Exécutez la migration en dehors des heures de pointe pour réduire au maximum l'impact sur votre équipe.\n- Consultez les logs de pipeline qui vous indiqueront si un élément nécessite votre attention.\n- Ne désactivez pas votre registre ECR avant d'avoir vérifié que toutes les images ont bien été transférées.\n- Pour les migrations à grande échelle, envisagez d'ajouter une limite de débit pour éviter de saturer votre réseau.\n\nNous mettons ce pipeline à disposition en open source dans notre dépôt GitLab public, car nous sommes convaincus que les ingénieurs de plateforme devraient passer leur temps à créer de la valeur, plutôt qu'à copier des images de conteneurs. N'hésitez pas à l'adapter à vos besoins ou à poser vos questions sur sa mise en œuvre. Consultez notre documentation pour en savoir plus sur les [catalogues CI/CD](https://gitlab.com/explore/catalog/components/package \"Catalogues CI/CD\"). ",[109,857,802,800,769,1008],"solutions architecture","2025-04-07",{"slug":1011,"featured":91,"template":806},"automating-container-image-migration-from-amazon-ecr-to-gitlab",{"category":742,"slug":746,"posts":1013},[1014,1028,1041],{"content":1015,"config":1026},{"title":1016,"description":1017,"authors":1018,"heroImage":1020,"date":1021,"body":1022,"category":746,"tags":1023,"updatedDate":1025},"Impact économique total de GitLab Ultimate : 483 % de ROI sur 3 ans","Découvrez les principales conclusions de l'étude Forrester Consulting consacrée à l'édition GitLab Ultimate, disponible sur la plateforme DevSecOps de GitLab.",[1019],"Dave Steer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2024-11-13","Une plateforme DevSecOps puissante rationalise les opérations, empêche les failles de sécurité de perturber (et de coûter cher à) votre entreprise, augmente la productivité et favorise une culture basée sur l'innovation et la collaboration. C'est exactement ce pour quoi nous avons créé GitLab, et l'édition GitLab Ultimate représente toute la puissance de notre plateforme. Pour connaître son influence concrète, nous avons demandé à Forrester Consulting de réaliser une étude « Total Economic Impact™ » sur GitLab Ultimate. Découvrez dans cet article les principales conclusions de cette étude. \n\nSelon les retours des clients interrogés, l'utilisation de GitLab génère à l'entreprise de référence :  \n\n* **Un retour sur investissement de 483 % sur trois ans**  \n* **Une amélioration de 400 % de la productivité des équipes de développement**  \n* **Une première mise en production 15 fois plus rapide\u003Csup>1\u003C/sup>**  \n* **Un gain de temps multiplié par 5 pour les tâches liées à la sécurité**\n\n**En somme, GitLab permet d'accomplir 50 % de travail à valeur ajoutée en plus.** \n\nLes chiffres parlent d'eux-mêmes : la plateforme GitLab transforme  la manière dont les équipes collaborent entre elles. Que vous soyez un responsable de la sécurité des applications chargé d'améliorer la posture de sécurité de votre entreprise, un membre de l'équipe de développement qui cherche à fournir un code de haute qualité plus rapidement ou encore un CTO à la recherche d'une plateforme DevSecOps évolutive, sécurisée et flexible, cette étude (dont la méthodologie complète est disponible ci-dessous) montre que GitLab Ultimate tient ses promesses. Examinons les résultats de l'étude.  \n\n> Téléchargez l'étude complète de [Forrester Consulting intitulée « The Total Economic Impact™ Of GitLab Ultimate » (2024)](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n## 1. Un ROI de 483 % sur trois ans\n\n*« La clé du succès pour nous a été le gain d'efficacité, à la fois au niveau de l'administration et des opérations globales. Aujourd'hui, le travail en équipe est accessible à tous et nous pouvons facilement automatiser notre pipeline. Je peux également changer la composition des équipes pour effectuer différentes tâches plus efficacement. Au lieu de former nos équipes sur différents outils en fonction des programmes, il leur suffit désormais de maîtriser GitLab pour pouvoir immédiatement se mettre au travail. »* - CTO et Senior Vice President (secteur de la Défense)\n\nL'étude révèle que les entreprises interrogées ont constaté un retour sur investissement dans les six mois suivant l'adoption de GitLab Ultimate, principalement grâce à une efficacité accrue. Avec un **retour sur investissement de 483 % sur trois ans**, elles ont pu réduire le coût de leur chaîne d'outils logiciels de 25 % et le temps consacré par leurs équipes informatiques à l'administration de ces chaînes d'outils complexes de 75 %. Au-delà des économies financières réalisées, le passage à une plateforme unifiée améliore fondamentalement la façon dont les équipes développent et livrent les logiciels.\n\n## 2. Une amélioration de la productivité de 400 %\n\n*« Lorsque j'échange avec les membres de notre équipe de développement à propos de GitLab, ils s'accordent tous sur le fait que son utilisation a augmenté la productivité de notre entreprise, à tous les niveaux et à tous les postes. Nous disposons aujourd'hui d'une plateforme dotée de fonctions et fonctionnalités accessibles à tous nos collaborateurs. »* - Software Architect, (secteur de l'énergie et de la recherche)\n\nLes équipes de développement travaillent mieux dans des environnements où ils peuvent facilement passer d'une tâche à l'autre sans interruptions. Selon cette étude, les développeurs et développeuses peuvent gagner jusqu'à 305 heures par an en [automatisant les tests](https://about.gitlab.com/fr-fr/topics/devops/devops-test-automation/) dans GitLab. Ils peuvent ainsi tester plus souvent, mais aussi suivre et corriger les bugs plus rapidement, le tout au sein d'une seule interface et donc sans changement de contexte. Ce workflow rationalisé leur permet de se concentrer sur le code plutôt que de jongler avec plusieurs outils et processus.\n\nLes gains de productivité s'étendent également à l'intégration : les nouvelles recrues de l'équipe de développement logiciel de l'entreprise de référence atteignent une productivité optimale 75 % plus rapidement (c'est-à-dire en 1,5 semaine au lieu de 1,5 mois). L'impact est clair : non seulement tous les membres de l'équipe peuvent contribuer à des tâches importantes, mais ils peuvent le faire plus tôt. \n\n## 3. Une première mise en production 15 fois plus rapide\n\n*« Le logiciel est notre botte secrète. Les éléments clés sont notre vélocité et notre capacité à offrir de nouvelles fonctionnalités à nos clients. Pour pouvoir nous concentrer sur ces objectifs premiers, il était logique d'un point de vue économique de \\[consolider\\] nos processus sur une plateforme unique. »* - CTO et Senior Vice President (secteur de la Défense)\n\nL'agrégation des données issues des entretiens avec nos clients révèlent que GitLab permet aux entreprises de déployer une première mise en production 15 fois plus rapidement. Cette accélération est facilitée par le démarrage plus rapide des projets, le déploiement plus fréquent de nouvelles versions, sans oublier une approche proactive de la sécurité qui intègre de manière native le scanning de sécurité dès le début du processus de développement. Il est ainsi possible de maintenir une qualité et une sécurité de haut niveau pour les logiciels, même dans le cadre d'une vélocité accrue, car les équipes de développement sont capables de remédier aux problèmes rapidement, dès leur apparition. \n\nL'[intégration de la sécurité directement dans le processus de développement](https://about.gitlab.com/solutions/security-compliance/) permet aux équipes d'identifier, de prioriser et de corriger les failles de sécurité sans interrompre leur workflow. Cette approche unifiée de la gestion de l'ensemble du cycle de développement logiciel permet aux équipes de progresser plus rapidement sans sacrifier la sécurité.\n\n## 4. Un gain de temps multiplié par 5 pour les tâches liées à la sécurité\n\n*« L'intégration des scanners de sécurité et de qualité dans le pipeline a changé la donne. Grâce à une automatisation accrue et à la réduction des processus manuels, nos pipelines rencontrent moins d'échecs, moins de problèmes et les projets avancent plus rapidement. »* - Program Manager (secteur financier) \n\nFace à l'accélération du développement et à l'évolution des menaces, la sécurité reste une priorité absolue pour toutes les entreprises. GitLab permet aux membres des équipes chargées de la sécurité de l'entreprise de référence d'économiser **78 heures par membre et par an** en automatisant les tâches récurrentes telles que la préparation à la reprise après sinistre, les audits et les contrôles de conformité. GitLab améliore également la visibilité des processus de développement logiciel, en aidant les équipes dédiées à la sécurité et au développement à mieux collaborer.  \n\nPour les équipes de cybersécurité et de développement logiciel de l'entreprise de référence, **la gestion et la réduction des risques de sécurité tout au long du cycle de développement logiciel nécessitent désormais 81 % d'efforts en moins.** En effet, GitLab leur permet d'intégrer des protocoles et des scans de sécurité à chaque étape du cycle de développement logiciel, ce qui simplifie le maintien de normes de sécurité strictes. Grâce à l'intégration des tests de sécurité et des mesures correctives dans les pipelines, les équipes réduisent les temps de réponse moyens et empêchent les problèmes d'atteindre l'environnement de production. \n\n## Découvrez l'approche DevSecOps en action\n\nAvec un retour sur investissement de 483 %, un amortissement rapide et d'innombrables exemples de réussites, GitLab est un outil inestimable pour les entreprises qui cherchent à transformer leurs processus de développement logiciel.\n\n> Pour découvrir les avantages de GitLab pour votre entreprise, téléchargez dès maintenant l'étude complète de [Forrester Consulting intitulée « The Total Economic Impact™ Of GitLab Ultimate »](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n**Méthodologie**  \n\n*Dans le cadre de cette étude, Forrester a interrogé quatre clients ayant adopté GitLab Ultimate et exerçant dans divers secteurs (notamment celui de la Finance, de la Défense et de la Recherche), puis a consolidé les résultats sous la forme d'une entreprise de référence. L'objectif pour cette entreprise de référence est d'adopter GitLab Ultimate pour l'ensemble de ses équipes sur une période de trois ans.*\n\n*L'entreprise de référence est une société au capital de 5 milliards de dollars, qui compte 5 000 employés (dont 40 % sont impliqués dans la livraison de logiciels) et 50 % de son chiffre d'affaires annuel dépend du développement logiciel. Ses objectifs sont de consolider plusieurs outils sous la forme d'une plateforme intégrée unique, d'améliorer la productivité de son équipe de développement, de garantir le respect des réglementations du secteur et de ses politiques internes, et de renforcer la sécurité tout au long du cycle de développement.*\n\n*1. Sur la base de données agrégées issues des entretiens avec nos clients ; non applicable aux résultats de l'entreprise de référence.*",[800,1024,746,781],"research","2024-11-26",{"slug":1027,"featured":91,"template":806},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"content":1029,"config":1039},{"title":1030,"description":1031,"authors":1032,"heroImage":1034,"date":1035,"body":1036,"category":746,"tags":1037,"updatedDate":1038},"The Source : une mine d'informations sur l'avenir du développement logiciel","Découvrez des stratégies de développement logiciel transformatrices et des conseils d'experts sur les technologies émergentes.",[1033],"Chandler Gibbons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","2024-10-29","Le développement logiciel moderne transforme la façon dont les entreprises créent, proposent et développent de la valeur commerciale. Les équipes doivent être en mesure d’élaborer des solutions rapidement et efficacement, tout en gérant les menaces de sécurité croissantes, les technologies émergentes et les exigences de conformité de plus en plus complexes.\n\nAujourd'hui, GitLab lance [The Source](https://about.gitlab.com/fr-fr/the-source/), une nouvelle publication qui couvre l'évolution du développement logiciel en tant que moteur de la réussite commerciale. Nous partageons régulièrement des informations clés sur l'avenir du développement logiciel, étayées par les recherches et les analyses originales de nos experts métier et de nos leaders d'opinion.\n\nThe Source vous permet par exemple de trouver des réponses aux questions suivantes : \n* Comment les dirigeants peuvent-ils mesurer le retour sur investissement de l'IA tout au long du cycle de développement logiciel ?  \n* Quelle est la meilleure façon de garantir la sécurité et la conformité tout au long de la chaîne d'approvisionnement logicielle ?\n* Quels gains de productivité les équipes peuvent-elles réaliser grâce à la consolidation de leur plateforme et de leur chaîne d'outils ?\n\nVoici un aperçu du contenu que vous pouvez d'ores et déjà retrouver sur The Source : \n\n**Mesurer l'impact de l'IA : 4 étapes indispensables**\n\n« L'évaluation de la productivité dans un contexte de développement amélioré par l'IA nécessite une approche plus nuancée que celle reposant sur les indicateurs traditionnels tels que les lignes de code, les validations de code ou l'achèvement des tâches. Elle nécessite une réorientation vers des résultats commerciaux concrets qui permettent d'équilibrer la rapidité de développement, la qualité des logiciels et la sécurité. »\n- [Taylor McCaslin, expert en IA, présente les 4 étapes indispensables pour mesurer l'impact de l'IA.](https://about.gitlab.com/fr-fr/the-source/ai/4-steps-for-measuring-the-impact-of-ai/)\n\n**Identifier et remédier aux points de friction liés à la sécurité**\n\n« Bien que l'approche DevSecOps promette une meilleure intégration entre l'ingénierie et la sécurité, la présence de frustrations et de déséquilibres montre que des défis subsistent. Ce constat reflète un problème plus large lié à la manière dont les entreprises perçoivent la sécurité, organisent la collaboration entre les équipes, et allouent du temps à cette priorité. »\n- [Trouvez le bon équilibre, grâce à l'expertise de Josh Lemos, CISO de GitLab.](https://about.gitlab.com/fr-fr/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/)\n\n**L'ingénierie de plateforme au service de la réussite des entreprises**\n\n« En normalisant et en optimisant les workflows des équipes de développement, l'ingénierie de plateforme crée des \"golden paths\" optimisés pour les tâches courantes tout en offrant la flexibilité nécessaire pour les tâches plus uniques et spécialisées. »  \n- [Découvrez les bonnes pratiques de Brian Wald (GitLab Field CTO) en matière d'ingénierie de plateforme.](https://about.gitlab.com/fr-fr/the-source/platform/driving-business-results-with-platform-engineering/)\n\n## The Source, votre partenaire pour la prise de décision\n\nConsultez [The Source](https://about.gitlab.com/fr-fr/the-source/) dès aujourd'hui pour découvrir les dernières informations du secteur, obtenir des réponses en matière de leadership et découvrir les dernières nouveautés du marché à partager avec vos équipes. Vous pouvez également vous abonner à notre newsletter pour recevoir des mises à jour régulières par e-mail. Rejoignez notre communauté de leaders technologiques avant-gardistes et contribuez à façonner l'avenir du développement logiciel.",[837,781,746,718],"2024-11-11",{"slug":1040,"featured":91,"template":806},"introducing-the-source-insights-for-the-future-of-software-development",{"content":1042,"config":1052},{"title":1043,"description":1044,"authors":1045,"heroImage":1047,"date":1048,"body":1049,"category":746,"tags":1050,"updatedDate":1051},"GitLab nommée Leader dans le Magic Quadrant 2024 de Gartner dédié aux plateformes DevOps","Notre approche DevOps innovante et le succès de nos clients ont permis à GitLab de figurer en tête du classement pour sa capacité d'exécution et l'exhaustivité de sa vision.",[1046],"Ashley Kramer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","2024-09-05","À l'origine, l'approche DevOps n'était qu'un concept, une méthodologie qui permettait de livrer des logiciels plus rapidement en réunissant des équipes traditionnellement disparates. Il s'agissait de répondre aux problèmes causés par la séparation entre les équipes de développement et celles de déploiement.\n\nChez GitLab, nous avons repris ce concept et l'avons développé : au lieu d'assembler des outils pour créer une chaîne d'outils DevOps complexe, nous avons créé une [plateforme DevOps unique](https://about.gitlab.com/fr-fr/platform/) pour encourager une collaboration plus étroite, une automatisation plus poussée et des processus plus évolutifs et standardisés.\n\nNous sommes convaincus de la valeur de cette stratégie, qui est axée sur la réussite de nos clients. À l'occasion de la deuxième édition du [Magic Quadrant de Gartner dédié aux plateformes DevOps](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/), nous avons à nouveau été reconnus comme un des Leaders, cette fois-ci, dans les deux domaines suivants : Capacité d'exécution et Exhaustivité de la vision.\n\n![Image Gartner MQ pour les plateformes DevOps 2024](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> Téléchargez le [rapport Magic Quadrant™ 2024 de Gartner® dédié aux plateformes DevOps](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/).\n\nLes fournisseurs de logiciels doivent aujourd'hui faire face à des menaces de sécurité croissantes et à des exigences de conformité complexes, tout en adoptant avec discernement les nouvelles technologies comme l'IA générative. Et bien sûr, ils doivent fournir à leurs clients des services évolutifs et toujours plus innovants.\n\nL'objectif de GitLab est d'aider ses clients à surmonter ces défis et à devenir des leaders dans leurs secteurs. Grâce à notre plateforme DevSecOps alimentée par l'IA, ils peuvent anticiper les problèmes de sécurité et améliorer la visibilité tout au long du cycle de développement, tout en rassemblant les acteurs nécessaires pour créer des logiciels indispensables.\n\n## Aller plus loin dans l'approche DevOps\n\nMais l'aventure ne fait que commencer ! Notre objectif ? Continuer à développer la vision DevOps et faire progresser notre plateforme DevSecOps de deux manières.\n\nPour commencer, nous voulons inviter encore plus d'équipes à collaborer sur la même plateforme, avec des fonctionnalités dédiées à celles impliquées dans [la planification Agile](https://about.gitlab.com/fr-fr/blog/categories/agile-planning/), la [science des données](https://about.gitlab.com/fr-fr/topics/devops/the-role-of-ai-in-devops/) et [l'observabilité](https://about.gitlab.com/fr-fr/blog/observability-vs-monitoring-in-devops/) et la surveillance des applications.\n\nDeuxièmement, nous voulons rendre l’adoption de notre plateforme et les options de déploiement encore plus flexibles pour répondre aux divers besoins de nos clients. Pour ce faire, nous enrichissons [GitLab Dedicated](https://about.gitlab.com/dedicated/), notre option hébergée à locataire unique, afin que les entreprises évoluant dans des secteurs hautement réglementés puissent bénéficier de la simplicité du SaaS et des nouvelles fonctionnalités et capacités, tout en respectant les besoins de conformité des infrastructures isolées.\n\n## Aider les entreprises à créer des logiciels sûrs\n\nAu-delà de la création d'une meilleure plateforme de collaboration pour le développement de logiciels, l'un de nos objectifs clés est d'aider les entreprises à produire des logiciels plus sûrs et plus conformes. C'est cet objectif qui nous démarque de nos concurrents, car GitLab intègre le [scanning de sécurité](https://about.gitlab.com/fr-fr/solutions/security-compliance/) au stade de la validation du code, et non lorsque les applications sont prêtes à être publiées. Les équipes peuvent ainsi détecter plus rapidement les vulnérabilités, ce qui accélère les cycles de sortie. GitLab facilite également le respect de la conformité grâce à la présence de garde-fous au niveau des stratégies et à la génération automatique [d'une nomenclature logicielle](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une nomenclature logicielle (SBOM) ?\").\n\nNous savons que la sécurité est un enjeu de plus en plus important pour nos clients, à mesure que la surface d'attaque de leur logiciel s'étend. C'est pourquoi, au cours des 12 prochains mois, nous prévoyons de continuer à améliorer nos scanners SAST, d'ajouter des contrôles supplémentaires au niveau des stratégies de sécurité et de compiler [un nouveau gestionnaire de secrets natif](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/).\n\n## Accompagner tout le cycle du développement logiciel grâce à l'IA\n\nNotre vision est également d'être leader dans le domaine de l'IA, à la fois en aidant nos clients à créer des logiciels innovants avec l'IA, mais aussi en exploitant les technologies d'IA respectueuses de la confidentialité. L'IA représente en effet une véritable avancée et offre d'innombrables opportunités lorsqu'elle est intégrée tout au long du cycle de développement logiciel. Mais pour nous, l'innovation doit avant tout se faire de manière responsable. Les préoccupations de nos clients sont claires : ils veulent une [IA avec des garde-fous](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/), une [IA transparente](https://about.gitlab.com/fr-fr/ai-transparency-center/) et une IA qui respecte leur code et leur propriété intellectuelle.\n\nNous nous engageons à enrichir [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), une suite de fonctionnalités alimentées par l'IA pour notre plateforme DevSecOps qui sont à la fois complètes, respectueuses de la confidentialité et conçues pour prendre en charge l'ensemble du cycle de développement logiciel.\n\nC'est cet engagement et nos fonctionnalités GitLab Duo qui ont encouragé [Gartner® à nous nommer Leader dans son premier Magic Quadrant™ dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/).\n\nNous sommes fiers de cette reconnaissance qui nous encourage à rester à l'écoute de nos clients afin de continuer à développer notre vision, notre roadmap produit et notre engagement à créer la meilleure plateforme DevSecOps.\n\n> Téléchargez le [rapport Magic Quadrant™ 2024 de Gartner® dédié aux plateformes DevOps](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/).\n\n***Source : Gartner, Magic Quadrant dédié aux plateformes DevOps, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, août 2024***\n\n***GARTNER est une marque déposée et une marque de service de Gartner, Inc. et/ou de ses sociétés affiliées aux États-Unis et à l'étranger et MAGIC QUADRANT est une\nmarque déposée de Gartner, Inc. et/ou de ses sociétés affiliées. Elles sont utilisées ici avec autorisation. Tous droits réservés.***\n\n***Gartner ne cautionne aucun fournisseur, produit ou service décrit dans ses publications de recherche, et ne conseille pas aux utilisateurs de la technologie de sélectionner uniquement les fournisseurs ayant les notes les plus élevées ou toute autre désignation. Les publications de recherche de Gartner reflètent les opinions de l'organisation de recherche de Gartner et ne doivent pas être interprétées comme des déclarations de fait. Gartner décline toute garantie, expresse ou implicite, à l'égard de cette recherche, y compris toute garantie de qualité marchande ou d'adéquation à un usage particulier.***\n\n***Ce graphique a été publié par Gartner Inc. dans le cadre d'un rapport plus vaste et doit être évalué dans le contexte de l'ensemble du document. Le document produit par Gartner est disponible sur demande auprès de Gartner.***",[746,1024,800,927,718],"2024-10-07",{"slug":1053,"featured":91,"template":806},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"category":754,"slug":758,"posts":1055},[1056,1069,1081],{"content":1057,"config":1067},{"description":1058,"title":1059,"category":758,"tags":1060,"heroImage":1061,"date":1062,"body":1063,"authors":1064},"Découvrez comment utiliser la plateforme DevSecOps de GitLab pour résoudre les problèmes d'intégration des nouveaux contributeurs.","Comment nous utilisons GitLab pour développer les communautés open source",[898,269,769],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_820,h_500,c_lfill/v1750099558/Blog/Hero%20Images/gitlabflatlogomap.png","2025-07-22","L'équipe Contributor Success de GitLab faisait face au défi suivant : alors que nos contributeurs open source récurrents fusionnaient davantage de modifications de code et collaboraient sur des fonctionnalités avancées, les contributeurs novices, quant à eux, avaient du mal à se lancer. Nous étions conscients que beaucoup de nouveaux contributeurs open source finissaient par abandonner sans même demander de l'aide. Attachés à la [mission de GitLab](https://handbook.gitlab.com/handbook/company/mission/) où chacun peut contribuer, nous aspirions à inverser cette tendance.\n\nNous avons commencé à effectuer des recherches sur les contributeurs open source de GitLab. Puis nous avons amélioré les obstacles majeurs. En janvier, nous avons atteint un record de 184 contributeurs communautaires uniques à GitLab en un seul mois, dépassant pour la première fois notre objectif de 170 fixé par l'équipe.\n\nTrois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.\n\nVoici comment nous avons utilisé les propres outils de GitLab pour résoudre le dilemme des nouveaux contributeurs et développer notre communauté [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\").\n\n## Ce que nous avons appris sur les nouveaux contributeurs\n\nEn 2023, nous avons mené la toute première étude sur les contributeurs open source de GitLab. Nous avons observé six participants qui n'avaient jamais contribué à GitLab.\n\nVoici ce qu’ils nous ont dit : \n\n* La documentation destinée aux contributeurs était confuse\n* La prise en main était difficile \n* Trouver de l’aide n'était pas clair\n\nSeul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.\n\nIl est devenu évident que nous devions nous concentrer sur l'expérience d'intégration si nous voulions que les nouveaux contributeurs réussissent à faire leurs premiers pas sur GitLab. Nous avons donc [itéré](https://handbook.gitlab.com/handbook/values/#iteration) !\n\nNotre équipe a passé l'année suivante à résoudre leurs défis. Nous avons utilisé les outils de GitLab, tels que les templates de tickets, les pipelines programmés, les webhooks et le GitLab Query Language (GLQL), pour construire une solution d'intégration innovante et semi-automatisée.\n\nEn 2025, nous avons effectué une étude de suivi des utilisateurs avec de nouveaux participants qui n'avaient jamais contribué à GitLab. Les 10 participants ont tous créé et fusionné avec succès des contributions dans GitLab, avec un taux de réussite de 100 %. Les retours ont montré une grande appréciation pour le nouveau processus d'intégration, la rapidité avec laquelle les chargés de maintenance vérifiaient le travail des contributeurs, et la reconnaissance que nous offrions aux contributeurs.\n\n## Création d’une intégration personnalisée\n\nNotre solution a commencé par l'engagement. Pour aider les nouveaux contributeurs à se lancer, nous avons mis en place un processus d'intégration personnalisé connectant chaque contributeur avec un chargé de maintenance communautaire.\n\nNous avons créé un [template de ticket ](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md)avec une liste claire de tâches.\n\nLe ticket d'intégration gère également l'approbation d'accès aux [forks de la communauté de GitLab](https://about.gitlab.com/blog/gitlab-community-forks/), une collection de projets partagés qui facilitent le push de modifications, la collaboration entre contributeurs, et l'accès aux fonctionnalités GitLab Ultimate et GitLab Duo.\n\nEn utilisant des [labels à portée limitée](https://docs.gitlab.com/user/project/labels/#scoped-labels), nous indiquons le statut de la demande d'accès pour faciliter le suivi par les chargés de maintenance.\n\n![Ticket d'intégration GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\nNous avons commencé avec un script Ruby exécuté via un pipeline programmé, vérifiant les nouvelles demandes d'accès et utilisant le template de ticket pour créer des tickets d'intégration personnalisés.\n\nÀ partir de là, nos chargés de maintenance collaborent avec les nouveaux contributeurs pour vérifier l'accès, répondre aux questions et trouver des tickets. \n\n## Standardisation des réponses avec des templates de commentaires\n\nAvec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.\n\nNous avons créé des [templates de commentaires](https://docs.gitlab.com/user/profile/comment_templates/), que nous synchronisons avec le dépôt en utilisant l'API GraphQL et un [script Ruby](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb).\n\nLe script est déclenché dans le fichier `.gitlab-ci.yml` lorsque des modifications de templates de commentaires sont apportées avec un push vers la branche par défaut (un test est déclenché dans les merge requests).\n\n```yaml\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n![Template de commentaire dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n## Suppression du temps d'attente de 5 minutes\n\nNotre première itération était un peu lente. Après avoir commencé le processus d'intégration, les contributeurs se demandaient ce qu’il fallait faire ensuite, tandis que le pipeline programmé prenait jusqu'à 5 minutes pour créer leur ticket d'intégration.\n\n[Niklas](https://gitlab.com/Taucher2003), un membre de notre [équipe Core](https://about.gitlab.com/community/core-team/), a trouvé une solution. Il a ajouté des [événements webhook pour les demandes d'accès](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094) et des [templates de charge utile personnalisés pour les webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738).\n\nCes fonctionnalités combinées nous ont permis de déclencher un pipeline immédiatement. Cela réduit le temps à environ 40 secondes (le temps qu'il faut au pipeline CI pour s'exécuter) et génère le ticket d'intégration immédiatement. Cette action économise également des milliers de pipelines et de minutes de calcul lorsqu’aucune demande d'accès n’a besoin d'être traitée. \n\nNous avons configuré un [token de déclenchement de pipeline](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) et l'avons utilisé comme cible pour le webhook, en passant les variables d'environnement souhaitées :\n\n```json\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n```\n\n![Liste de pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n## Automatisation des suivis\n\nAvec un volume croissant de clients et de contributeurs à la communauté GitLab, les chargés de maintenance avaient du mal à suivre les tickets qui nécessitaient une attention particulière et certaines questions de suivi se perdaient.\n\nNous avons mis en œuvre une automatisation utilisant les webhooks et Ruby pour labeliser les tickets mis à jour par les membres de la communauté. Cela crée un signal clair du statut du ticket pour les chargés de maintenance. \n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) relance automatiquement les tickets d'intégration inactifs afin de maintenir cette dynamique.\n\n![Relance automatisée des tickets d'intégration inactif dans GitLab ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n## Organisation du suivi des tickets avec GLQL\n\nNous avons construit une [vue GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/) pour garder une trace de l'ensemble des tickets. Ce tableau GLQL recense les tickets d'intégration qui nécessitent une attention particulière, permettant aux chargés de maintenance de les examiner et de les suivre avec les membres de la communauté.\n\n![Vue GLQL du suivi des tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\nCes vues GLQL ont amélioré notre efficacité globale de classement. Le succès a été tel que nous avons fini par utiliser cette stratégie dans les programmes [GitLab pour l’open source](https://about.gitlab.com/fr-fr/solutions/open-source/) et [GitLab pour l'éducation](https://about.gitlab.com/fr-fr/solutions/education/). Avec les tableaux GLQL pour les tickets d’assistance, ces programmes communautaires ont réduit leurs temps de réponse de 75 %.\n\n## Meilleure accessibilité du README\n\nLe [groupe @gitlab-community](https://gitlab.com/gitlab-community/) est l’espace dédié aux contributeurs sur Gitlab.com. Nous avions déjà un fichier `README.md` expliquant les forks de la communauté et le processus d'intégration, mais ce fichier vivait dans un projet meta. Avec notre étude de suivi des utilisateurs, nous avons découvert que cette séparation désorientait les nouveaux contributeurs quand leurs tickets d'intégration se trouvaient dans un projet différent.\n\nNous avons alors utilisé la [mise en miroir de projet de GitLab](https://docs.gitlab.com/user/project/repository/mirror/) pour résoudre cela et mis en miroir le projet meta vers `gitlab-profile`. Cela a fait remonter le fichier README existant au niveau du groupe, le rendant plus facile d'accès.\n\n![Mise en miroir de projet GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n![README de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n## Les résultats parlent d'eux-mêmes\n\nEn utilisant GitLab nous-mêmes, nous avons amélioré les points de friction identifiés dans nos études et transformé le parcours des contributeurs de GitLab. Nous avons augmenté le nombre de clients et de membres de la communauté contribuant à GitLab, ajoutant des fonctionnalités au produit, résolvant des bogues, et enrichissant notre catalogue [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD?\").\n\nNotre processus d'intégration a augmenté le taux d'adhésion des nouveaux contributeurs au sein de notre communauté, et le nombre total de contributeurs sur les forks de la communauté a doublé au cours des 9 derniers mois.\n\n![Graphique de croissance des forks de la communauté](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\nNous avons réduit le temps nécessaire aux nouveaux contributeurs pour apporter leur première contribution en les connectant plus rapidement avec les chargés de maintenance et en les aidant à démarrer. \n\nNous utilisons l’[analyse de la chaîne de valeur](https://docs.gitlab.com/user/group/value_stream_analytics/) de GitLab pour suivre nos taux de réponse.\n\n* Le délai avant première réponse des chargés de maintenance de la communauté est descendu à 46 minutes au cours des 3 derniers mois\n* Le temps d'approbation moyen pour l'accès aux forks de la communauté est descendu à 1 heure au cours des 3 derniers mois\n\n![Chronologie de l’analyse de la chaîne de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\nLe taux de réussite de 100 % de notre étude de suivi des utilisateurs de 2025 a confirmé ces améliorations pour nos contributeurs novices.\n\n## Meilleure reconnaissance des contributeurs\n\nCorriger les défis rencontrés par nos nouveaux contributeurs nous a permis de nous concentrer sur une meilleure reconnaissance de notre communauté, incitant les novices à revenir. Le résultat : [contributors.gitlab.com](http://contributors.gitlab.com). Nous avons construit un hub central pour nos contributeurs qui comprend des tableaux de classement, des réalisations et des récompenses. Les contributeurs peuvent voir leur impact, suivre leurs progrès et grandir au sein de la communauté.\n\n## Partager ce que nous avons appris\nCes améliorations fonctionnent et sont reproductibles pour d'autres projets open source. Nous partageons notre approche pour que d'autres projets puissent envisager d'utiliser ces outils pour se développer. \n\nAu fur et à mesure que les organisations prennent connaissance des obstacles à la participation, il est possible de créer un environnement open source plus convivial. Avec les outils de GitLab, nous pouvons offrir une expérience plus fluide aux contributeurs et aux chargés de maintenance. \n\n**Contactez-nous**\n\nVous voulez en savoir plus sur le développement de votre communauté de contributeurs ? Envoyez un e-mail à contributors@gitlab.com ou [créez un ticket](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues) pour démarrer une discussion. Nous sommes là pour aider à construire des communautés.",[1065,1066],"Lee Tickett","Daniel Murphy",{"featured":6,"template":806,"slug":1068},"how-we-use-gitlab-to-grow-open-source-communities",{"content":1070,"config":1079},{"body":1071,"title":1072,"description":1073,"heroImage":1074,"authors":1075,"date":1077,"category":758,"tags":1078},"Le projet Git a récemment publié la [version 2.50.0 de Git](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u). Découvrons les points forts de cette nouvelle version, qui comprend les contributions de l'équipe Git de GitLab et de la communauté Git.\n\n## Nouvelle commande git-diff-pairs(1)\n\nLes diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet [« Modifications »](https://docs.gitlab.com/user/project/merge_requests/changes/) d'une merge request. En arrière-plan, la génération de diff est optimisée par [`git-diff(1)`](https://git-scm.com/docs/git-diff).\n\nPar exemple :\n\n```shell\n$ git diff HEAD~1 HEAD\n```\n\nCette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème d'évolutivité, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser une délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à assimiler.\n\nPour ce faire, vous pouvez utiliser [`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree/fr) pour récupérer des informations sur tous les fichiers modifiés :\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n```\n\nGit appelle ce résultat le [format « brut »](https://git-scm.com/docs/git-diff-tree/fr). En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de la sortie de « correctif » pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer détection de changement de nom en ajoutant `-M` pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.\n\nAvec ces informations, nous pourrions utiliser `git-diff(1)` pour calculer chacun des diffs de paire de fichiers individuellement.\n\\\nPar exemple, nous pouvons fournir directement des ID de blob :\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n```\n\nNous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme permettant d'alimenter des informations « brutes » sur les paires de fichiers et de générer la sortie de correctifs correspondants.\n\nAvec la version 2.50.0, Git dispose d’une nouvelle commande intégrée `git-diff-pairs(1)`, qui prend en charge les informations de paires de fichiers au format « brut » en tant qu'entrée sur stdin pour déterminer avec précision les correctifs à générer.\n\nL'exemple suivant montre comment cette commande peut être utilisée :\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nDe cette façon, la sortie générée est identique à celle obtenue avec `git-diff(1)`. En utilisant une commande distincte pour générer la sortie de correctif, la sortie « brute » de `git-diff-tree(1)` peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus `git-diff-pairs(1)` distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.\n\nPour plus d'informations sur ce changement, consultez ce [fil de discussion](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\\\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n## Mises à jour des références par lots\n\nGit fournit la commande `git-update-ref(1)` pour effectuer des mises à jour de références. Lorsqu'elle est associée à `--stdin`, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur stdin. La mise à jour des références par lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.\n\nVoici un exemple illustrant ce comportement :\n\n```shell\n# Create repository with three empty commits and branch named \"foo\"\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n# Print out the commit IDs\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n# Attempt to create a new reference and update existing reference in transaction.\n# Update is expected to fail because the specified old object ID doesn’t match.\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n# The \"bar\" reference was not created.\n$ git switch bar\nfatal: invalid reference: bar\n```\n\nEn comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Cela ne remet pas en cause les gains de productivité obtenus grâce aux mises à jour par lot.\n\nAvec cette version, `git-update-ref(1)` met à disposition la nouvelle option `--batch-updates`, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.\n\nDans ce mode, les échecs individuels sont signalés dans le format suivant :\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n```\n\nCela permet de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.\n\nVoici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :\n\n```shell\n# Attempt to create a new reference and update existing reference in transaction.\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n$ git switch bar\nSwitched to branch 'bar'\n```\n\nCette fois, avec l'option `--batch-updates`, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de correctifs est un aperçu des futures améliorations des performances de `git-fetch(1)` et `git-receive-pack(1)` lors de la mise à jour de références par lot.\n\nPour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/).\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Nouvelle option de filtre pour git-cat-file(1)\n\nAvec `git-cat-file(1)`, il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option `--batch–all-objects`.\n\nEn voici un exemple :\n\n```shell\n# Setup simple repository.\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n# Create an unreachable object.\n$ git commit --amend --no-edit\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nDans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.\n\nPar exemple, si nous voulons voir uniquement les objets qui correspondent à des commits, nous pouvons utiliser `grep(1)` :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nBien que cela fonctionne, un des inconvénients du filtrage de la sortie est que `git-cat-file(1)` doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.\n\nAvec la version 2.50.0, `git-cat-file(1)` dispose désormais de l'option `--filter`, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour `git-rev-list(1)`, mais seul un sous-ensemble des filtres est pris en charge : `blob:none`, `blob:limit=`, ainsi que `object:type=`.\n\nComme dans l'exemple précédent, il est possible de filtrer les objets par type avec [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") directement :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nCette approche facilite le traitement par Git, mais également la recherche dans les grands dépôts contenant de nombreux objets. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage («packfile»), ce qui accélère de manière considérable le processus.\n\nLes benchmarks effectués sur le [dépôt Chromium](https://github.com/chromium/chromium.git) montrent des améliorations significatives :\n\n```text\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\nRange (min … max): 73.936 s … 89.690 s 10 runs\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\nRange (min … max): 1.541 s … 1.566 s 10 runs\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\nRange (min … max): 11.114 s … 11.245 s 10 runs\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\nRange (min … max): 62.836 s … 73.618 s 10 runs\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\nRange (min … max): 12.960 s … 13.199 s 10 runs\nSummary\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n```\n\nIl est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n## Amélioration des performances lors de la génération de paquets\n\nAvec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui l'accompagnent via la commande [`git-bundle(1)`](https://git-scm.com/docs/git-bundle/fr). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme [`bundle-URI`](https://git-scm.com/docs/bundle-uri).\n\nPour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab ([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans le paquet. L'implémentation a utilisé une boucle `for` imbriquée pour itérer et comparer toutes les références répertoriées, ce qui a entraîné une complexité temporelle O(N^2). Cette façon de procéder n'est pas adaptée en cas d'augmentation du nombre de références dans un dépôt.\n\nDans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par une structure de données de mappage, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'un paquet avec un dépôt contenant 100 000 références :\n\n```text\nBenchmark 1: bundle (refcount = 100000, revision = master)\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\nRange (min … max): 14.237 s … 14.920 s 10 runs\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\nRange (min … max): 2.364 s … 2.425 s 10 runs\nSummary\nbundle (refcount = 100000, revision = HEAD) ran\n6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nPour en savoir plus, découvrez notre article de blog qui explique [comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) et consultez ce [fil de discussion](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n*Ce projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n## Meilleur dégroupage des URI de paquets\n\nÀ l'aide du mécanisme [bundle-uri](https://git-scm.com/docs/bundle-uri) dans Git, il est possible de fournir aux clients les emplacements pour récupérer les paquets dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge un paquet, les références sous `refs/heads/*` et les objets qui les accompagnent sont copiés du paquet dans le dépôt. Un paquet peut contenir des références supplémentaires en dehors de `refs/heads/*` telles que `refs/tags/*`, qui sont simplement ignorées lors de l'utilisation de l'URI du paquet sur le clone.\n\nDans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à `refs/*` contenues dans le paquet téléchargé sont copiées.\n\n[Scott Chacon](https://github.com/schacon), qui a contribué à cette fonctionnalité, montre la différence lors du clonage de [gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss) :\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nEn comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction du paquet, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.\n\nPour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n*Cette série de correctifs a été fournie par Scott Chacon.*\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) du projet Git et en consultant ces [ressources](https://about.gitlab.com/blog/tags/git/).","Nouveautés de Git 2.50.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png",[1076],"Justin Tobler","2025-07-02",[269,994,898],{"featured":6,"template":806,"slug":1080},"what-s-new-in-git-2-50-0",{"content":1082,"config":1090},{"title":1083,"description":1084,"authors":1085,"heroImage":1086,"date":1087,"body":1088,"category":758,"tags":1089},"Open source : définition, avantages et défis","Qu'est-ce que l'open source ? Apprenez comment ce modèle collaboratif transforme le développement logiciel grâce au libre accès et au partage du code.",[962],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662973/Blog/Hero%20Images/open-source-definition.jpg","2025-04-16","Basé sur des principes fondamentaux tels que l'ouverture, le partage des connaissances et l'amélioration continue, l'open source révolutionne le monde du développement logiciel. En réunissant des développeurs du monde entier, l'open source crée un environnement propice à l'innovation, où les idées et les solutions émergent grâce à la diversité des contributions. \n\nDécouvrez dans cet article les principes fondamentaux du développement [open source](https://about.gitlab.com/fr-fr/solutions/open-source/ \"Solutions GitLab pour les projets open source\"). \n\n## Qu’est-ce que l’open source ? \n\nL'open source est un modèle de développement fondé sur la transparence et la collaboration. Contrairement aux logiciels propriétaires, où seul le détenteur des droits peut modifier le code source ou redistribuer le produit, l'open source rend ce code accessible à tous. Les développeurs du monde entier peuvent ainsi l'examiner, l'améliorer et le partager librement, favorisant l'innovation et le progrès collectif.\n\n> [\nEssayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/devsecops/ \"Essai gratuit de GitLab Ultimate\") et commencez à développer des logiciels open source dès aujourd'hui.\n\n## Quels sont les avantages de l'open source ?\n\nBien plus qu'une alternative technologique, l'open source est un modèle offrant de nombreux avantages. Réduction des coûts, accélération de l'innovation, meilleure sécurité des logiciels, ou encore personnalisation, sont autant d'atouts qui peuvent transformer les projets et stimuler la croissance des entreprises.\n\n### Des coûts réduits \n\nÀ l'opposé des solutions propriétaires parfois onéreuses, les logiciels open source se distinguent souvent par leur faible coût, vous dispensant des dépenses traditionnellement associées aux licences et au support technique. Chez GitLab par exemple, les utilisateurs ont la possibilité d’utiliser gratuitement [GitLab Community Edition (CE)](https://about.gitlab.com/fr-fr/install/ce-or-ee/ \"GitLab Community Edition (CE)\") qui est open source. \n\n### Une meilleure transparence\n\nL'accès au code source permet à qui le souhaite d'examiner, de modifier et d'améliorer les logiciels. Pour les développeurs, cette transparence facilite leur compréhension des logiciels, de la manière dont ils sont construits et des failles de sécurité potentielles qu'ils peuvent contenir. Par exemple, le code source de GitLab est disponible publiquement sur GitLab.com et offre aux utilisateurs l'opportunité d’inspecter le code, de comprendre son fonctionnement et même de contribuer activement à son développement.  \n\n### Des logiciels personnalisables \n\nL'open source offre aux entreprises la possibilité d'adapter leurs logiciels à leurs besoins spécifiques, là où les solutions propriétaires limitent souvent cette liberté. Grâce à leur nature modulable, les logiciels open source permettent d'optimiser l'efficacité opérationnelle en s'adaptant précisément aux besoins des entreprises. GitLab illustre cette flexibilité en offrant à tous la possibilité de contribuer de façon traditionnelle, et en offrant également aux entreprises la possibilité de développer des intégrations et des fonctionnalités sur mesure grâce à son [programme Co-Create](https://about.gitlab.com/community/co-create/ \"Programme Co-Create\").\n\n### Une communauté engagée \n\nLes projets open source reposent sur l'engagement d'une communauté qui partage ses connaissances pour résoudre des problèmes ou proposer des améliorations sur les logiciels. GitLab [tire pleinement parti de cet écosystème](https://about.gitlab.com/community/ \"Communauté de GitLab\") en s'appuyant sur une base d'utilisateurs et de développeurs qui enrichissent activement son développement et [partagent leur expertise](https://forum.gitlab.com/ \"Forum de GitLab\"). GitLab collabore également avec d'autres entreprises sur des projets open source comme Git, renforçant son engagement pour l'innovation collective et la création de solutions évolutives.\n\n### Un accélérateur d’innovations\n\nEn réunissant des talents du monde entier autour de projets communs, l'open source devient un puissant moteur d'innovation. Cette synergie stimule l'amélioration continue et l'enrichissement des logiciels grâce à la diversité des compétences partagées. Ce modèle accélère ainsi le développement technologique en rendant les outils open source accessibles à un large public. GitLab, avec son cycle de release mensuel, [intègre régulièrement de nouvelles fonctionnalités et améliorations](https://about.gitlab.com/releases/ \"Releases GitLab\") fondées sur les retours et contributions de sa communauté d'utilisateurs.\n\n### Des logiciels évolutifs\n\nLes logiciels open source reposent souvent sur des normes ouvertes qui [simplifient leur intégration avec d'autres systèmes](https://about.gitlab.com/fr-fr/integrations/ \"Intégrations GitLab\"). Conçus pour s'adapter à divers environnements, ils offrent aux entreprises la possibilité de créer des solutions sur mesure, performantes et évolutives.\n\n### Une sécurité logicielle renforcée\n\nLa sécurité et la fiabilité sont des piliers essentiels des logiciels open source. Grâce à l'examen continu du code par une large communauté de développeurs, les failles de sécurité sont rapidement identifiées et corrigées. Bien que cette approche ne garantisse pas une sécurité absolue, elle favorise grandement la réactivité des équipes de développement face aux vulnérabilités de toutes sortes. GitLab applique ce principe en [s'appuyant sur sa communauté pour renforcer la sécurité de sa plateforme](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/).\n\n### Un savoir-faire enrichi\n\nLes logiciels open source représentent une mine d'opportunités d'apprentissage pour les développeurs. En s'impliquant dans ces projets, ils peuvent perfectionner leurs compétences et gagner en expérience auprès d'autres professionnels du domaine, enrichissant leur savoir-faire et accélérant leur développement professionnel.\n\nPar exemple, les développeurs peuvent étudier la base de code de GitLab pour apprendre les meilleures pratiques en matière de développement de plateformes DevSecOps. Les membres de l'équipe GitLab participent par ailleurs à des programmes de mentorat comme [Google Summer of Code](https://about.gitlab.com/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare/ \"Google Summer of Code\") et [Outreachy](https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020/ \"Outreachy\") qui permettent d'apprendre aux nouveaux participants comment contribuer à GitLab ou autres logiciels open source comme Git.\n\n### Des logiciels plus qualitatifs\n\nDe nombreux projets open source bénéficient de la contribution de développeurs talentueux. Grâce à leur expertise, le code des logiciels open source est constamment examiné, amélioré et renforcé, ce qui permet de développer des solutions robustes et performantes.\n\n## Quels sont les défis liés à l’open source\n\nExplorer l'univers des logiciels open source peut être aussi stimulant qu'exigeant. De la création de relations solides avec une communauté au renforcement de la sécurité des projets, chaque étape comporte ses propres défis. Pour réussir, il est essentiel de comprendre ces obstacles et de mettre en place des stratégies adaptées.\n\n### Construire une relation solide avec sa communauté \n\nLe succès du développement open source repose sur la capacité à établir et à maintenir une relation solide avec une communauté de développeurs et d'utilisateurs. Cela nécessite des échanges continus afin de comprendre et de répondre à ses attentes. Puisque la majorité des contributeurs sont bénévoles, il est essentiel de coordonner leurs efforts de manière agile et structurée.\n\nPour maintenir leur motivation sur le long terme, notamment pour les contributeurs œuvrant sans contrepartie financière, il est crucial de reconnaître et de valoriser leur travail. Cela peut passer par des mentions officielles (crédits), des opportunités de formation ou d'autres formes de reconnaissances professionnelles. Sans cette valorisation, les contributeurs risquent de se détourner des projets, voire de créer des initiatives parallèles. Bâtir une communauté engagée et durable est donc au cœur du succès de tout projet open source.\n\n### Trouver un équilibre entre les intérêts de la communauté et celle des entreprises\n\nTrouver un équilibre entre les intérêts des entreprises et ceux de la communauté est un défi central dans le développement open source. Les entreprises impliquées dans ces projets ont généralement des objectifs prioritaires. Ces priorités, souvent commerciales, peuvent entrer en conflit avec les attentes plus larges de la communauté, dont les intérêts sont plutôt axés sur l'innovation libre ou la personnalisation des logiciels.\n\nLorsque les décisions semblent trop axées sur les intérêts de l'entreprise, la communauté risque de se sentir exclue, ce qui peut réduire son engagement et limiter ses contributions. Pour éviter ce désengagement, les entreprises doivent partager clairement leurs objectifs et échanger régulièrement avec leur communauté pour garantir la pérennité et le succès à long terme des projets open source.\n\n### Maintenir la sécurité des logiciels\n\nLes logiciels open source sont exposés à certains défis en matière de sécurité. La transparence du code, bien qu'étant l'un de leurs plus grands atouts, peut aussi les exposer à des attaques ciblées, ce qui peut devenir un risque majeur si l'entreprise à l’origine du projet open source ne corrige pas rapidement les failles identifiées. \n\nLes utilisateurs comptent ainsi sur la réactivité de l'entreprise pour garantir la sécurité de leurs systèmes et de leurs données. \n\n## GitLab : un partenaire incontournable pour les projets open source\n\nLes projets open source sont un moteur d'innovation technologique, et choisir la bonne plateforme pour les héberger est essentiel. Grâce à son système de gestion de versions basé sur [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"), GitLab permet aux équipes de développement de collaborer efficacement, de suivre les modifications de code et de conserver un historique complet de leurs projets. \n\n### Une suite complète de fonctionnalités collaboratives\n\nGitLab met à disposition de ses utilisateurs une suite complète de fonctionnalités adaptées au développement et à la gestion de projets open source. Parmi ces fonctionnalités figurent le [suivi des tickets](https://docs.gitlab.com/ee/user/project/issues/ \"Tickets GitLab\"), les [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/ \"merge requests\"), la [revue de code](https://about.gitlab.com/fr-fr/topics/version-control/what-is-code-review/ \"Qu'est-ce qu'une revue de code ? \"), les [wikis](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"GitLab Wiki\") et les [GitLab Pages](https://about.gitlab.com/fr-fr/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages/ \"GitLab Pages\"). Ces fonctionnalités permettent aux équipes de suivre l'évolution des projets, de collaborer, de proposer des améliorations, de corriger des bogues et de documenter leurs progrès en temps réel. \n\n### Des pratiques CI/CD au service des projets open source\n\nLes fonctionnalités [CI/CD](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/ \"Meilleures pratiques CI/CD\") de GitLab sont un atout majeur pour les projets open source. Elles automatisent des étapes clés du développement logiciel, comme les [tests](https://docs.gitlab.com/ee/ci/testing/), la validation du code et le déploiement de nouvelles versions, assurant ainsi une meilleure fiabilité des logiciels open source et un développement accéléré. Chaque contribution est automatiquement testée dans un environnement dédié, ce qui permet de détecter rapidement les erreurs et de corriger les bogues. Cela réduit les risques de défaillances tout en assurant la stabilité des projets. \n\n### Un cycle de développement logiciel sécurisé\n\nGitLab propose une suite complète de fonctionnalités conçues pour aider les développeurs de projets open source à sécuriser leurs logiciels. Parmi ces fonctionnalités, nous retrouvons :\n\n- __Le test statique de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))__ qui examine le code source à la recherche de failles de sécurité en amont de la mise en service des logiciels. \n- __Le test dynamique de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))__* qui teste les applications en cours d'exécution au sein d’un environnement déployé pour détecter d'éventuelles vulnérabilités encore non repérées. \n- __L'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/ \"Analyse des dépendances\")__* qui envoie des alertes sur les bibliothèques obsolètes ou vulnérables. Des rapports détaillés sont générés à chaque étape du développement, offrant une visibilité claire sur l'état de la sécurité du projet. Grâce à cela, les développeurs peuvent rapidement éviter ou corriger les composants à risque.\n\n** Fonctionnalité disponible uniquement pour les utilisateurs de GitLab Ultimate.*\n\nEn intégrant ces fonctionnalités directement dans le [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\"), GitLab réduit le risque d'erreurs humaines et accélère l’identification et la correction des vulnérabilités. Cette approche permet ainsi aux développeurs de projets open source de maintenir un niveau élevé de sécurité tout au long du cycle du développement logiciel. \n\n### Une gestion de projet Agile\n\nGitLab met à disposition des équipes de développement un certain nombre de fonctionnalités pour faciliter la gestion des projets open source comme les [tableaux de tickets](https://docs.gitlab.com/ee/user/project/issue_board.html \"Tableaux de tickets\"), les [listes des jalons](https://docs.gitlab.com/ee/user/project/milestones/ \"Listes des jalons\") ou encore le [suivi du temps](https://docs.gitlab.com/ee/user/project/time_tracking.html \"Suivi du temps\"). Ces dernières permettent de voir facilement les tâches à réaliser, de suivre l'avancement des projets en fixant des échéances claires, mais aussi d’évaluer la charge de travail en vue d'optimiser l'utilisation des ressources. En combinant ces fonctionnalités, GitLab permet aux équipes de mieux coordonner leurs efforts, de maintenir un processus de travail fluide et de progresser efficacement dans la réalisation de leurs projets open source.\n\n### Des contributions simplifiées\n\nLes équipes de développement peuvent facilement contribuer au développement de projets open source en les dupliquant ([fork](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html \"fork\")) et en créant des merge requests. Elles peuvent créer leurs propres copies du code, travailler sur des améliorations ou des correctifs dans des branches distinctes, puis soumettre leurs changements via des merge requests. Ce processus permet aux équipes de réviser et de valider chaque modification avant son intégration dans la branche principale, favorisant ainsi une amélioration continue des logiciels, tout en renforçant la qualité et la stabilité du code.\n\n### Une intégration facilité avec d’autres outils\n\nGitLab facilite considérablement son intégration avec d’autres outils et workflows , permettant aux équipes de développement de créer un environnement personnalisé en fonction des exigences spécifiques de leur projet. Pour en savoir plus, [consultez notre documentation](https://docs.gitlab.com/ee/api/). \n\n## Développez des logiciels open source avec GitLab \n\nL’open source continue de s'imposer dans le monde du développement logiciel. Avec des plateformes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") comme GitLab, les équipes de développement disposent de tous les outils et ressources nécessaires au bon développement de leurs logiciels open source.\n\nEn plus d’aider les entreprises à développer des logiciels performants et sécurisés, GitLab fait évoluer continuellement sa plateforme grâce aux contributions et aux retours de ses utilisateurs. En écoutant sa communauté en permanence, GitLab s'adapte aux transformations du développement logiciel, renforçant ainsi sa présence au sein de l'écosystème open source.\n\n> [\nEssayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/devsecops/ \"Essai gratuit de GitLab Ultimate\") et commencez à développer des logiciels open source dès aujourd'hui.",[898,927,718],{"slug":1091,"featured":6,"template":806},"what-is-open-source",{"category":90,"slug":769,"posts":1093},[1094,1106,1118],{"content":1095,"config":1104},{"title":1096,"description":1097,"authors":1098,"heroImage":1100,"date":1101,"body":1102,"category":769,"tags":1103},"La migration par transfert direct est désormais disponible","Découvrez comment migrer efficacement vos groupes et projets GitLab entre instances GitLab grâce à la migration par transfert direct, performante et sécurisée.",[1099],"Magdalena Frankiewicz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1753898687/nlxenzmbdk62dlylt3ey.png","2025-08-04","La migration des groupes et projets GitLab par transfert direct est désormais disponible dans la version GitLab 18.3. Cette fonctionnalité apporte une méthode simple et automatisée pour migrer des ressources GitLab entre instances GitLab à un public encore plus large.\n\nLe [transfert direct](https://docs.gitlab.com/user/group/import/) vous permet de créer facilement une copie des ressources GitLab de votre choix sur la même instance ou sur une autre instance GitLab. Vous pouvez utiliser l'interface utilisateur ou l'API. L'interface utilisateur est intuitive et simple d'utilisation, tandis que [l'API](https://docs.gitlab.com/ee/api/bulk_imports.html) vous offre une flexibilité supplémentaire pour choisir les ressources à copier.\n\nLa migration par transfert direct représente une amélioration majeure par rapport à la [migration de groupes et de projets via l'exportation de fichiers](https://docs.gitlab.com/ee/user/project/settings/import_export.html#migrate-projects-by-uploading-an-export-file) pour les raisons suivantes :\n\n* Vous n'avez plus besoin d'exporter manuellement chaque groupe et projet individuel vers un fichier, puis d'importer tous ces fichiers vers un nouvel emplacement. Désormais, vous pouvez directement migrer tout groupe de niveau supérieur dont vous avez le rôle de propriétaire avec tous ses sous-groupes et projets.\n* Elle permet le [mappage des contributions utilisateur après l'importation](https://about.gitlab.com/blog/streamline-migrations-with-user-contribution-and-membership-mapping/) (comme la paternité des tickets ou des commentaires), ce qui vous offre plus de flexibilité et de contrôle.\n* Elle fonctionne de manière fiable avec des projets volumineux. Grâce au traitement par lots des ressources et à l'exécution simultanée des processus d'importation et d'exportation, les risques d'interruption ou de délai d'attente dépassé sont considérablement réduits.\n* Elle offre une meilleure visibilité sur la migration pendant son exécution ainsi qu'après sa finalisation. Dans l'interface utilisateur, vous pouvez observer l'augmentation des nombres à mesure que de nouveaux éléments sont importés. Ensuite, vous pouvez [examiner les résultats de l'importation](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#review-results-of-the-import). Vous pouvez voir qu'un élément a été importé grâce au badge `Imported` sur les éléments dans l'interface utilisateur GitLab.\n\nNous avons parcouru un long chemin depuis GitLab 14.3, lorsque nous avons commencé à prendre en charge la migration directe des ressources de groupe. Dans GitLab 15.8, nous avons [étendu cette fonctionnalité aux projets en version bêta](https://about.gitlab.com/blog/2023/01/18/try-out-new-way-to-migrate-projects/). Depuis, nous avons travaillé à améliorer l'efficacité et la fiabilité de l'importation, en particulier pour les projets volumineux. Nous avons minutieusement examiné la fonctionnalité du point de vue de la sécurité et de la stabilité des instances.\n\nPour vous donner un exemple de la taille des groupes et des projets que nous avons testés, ainsi que de leur durée d'importation, nous avons constaté des importations réussies de :\n\n* 100 projets (19 900 tickets, 83 000 merge requests, plus de 100 000 pipelines) migrés en 8 heures\n* 1 926 projets (22 000 tickets, 160 000 merge requests, 1,1 million de pipelines) migrés en 34 heures\n\nSur GitLab.com, la migration par transfert direct est activée par défaut, tandis que sur GitLab Self-Managed et sur GitLab Dedicated, un administrateur doit [activer la fonctionnalité dans les paramètres de l'application](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#enable-migration-of-groups-and-projects-by-direct-transfer).\n\n## Quand utiliser la migration par transfert direct et comment obtenir les meilleurs résultats ?\n\nLa migration par transfert direct nécessite une connexion réseau entre les instances ou GitLab.com. Par conséquent, les clients qui utilisent des réseaux air-gapped sans connectivité entre leurs instances GitLab doivent toujours utiliser l'exportation de fichiers pour copier leurs données GitLab. Ils pourront utiliser la migration de groupes et de projets par transfert direct lorsque nous étendrons cette solution pour [prendre en charge les instances hors ligne](https://gitlab.com/groups/gitlab-org/-/epics/8985).\n\nAvant de tenter une migration, consultez notre [documentation](https://docs.gitlab.com/user/group/import/), y compris les [prérequis](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#prerequisites), les [éléments de groupe](https://docs.gitlab.com/ee/user/group/import/#migrated-group-items) et les [éléments de projet](https://docs.gitlab.com/ee/user/group/import/#migrated-project-items) qui sont migrés. Certains éléments sont exclus de la migration ou ne sont pas encore pris en charge.\n\n### Migrez entre les versions les plus récentes possibles\n\nNous recommandons de migrer entre des versions aussi récentes que possible. Mettez à jour les instances source et destination pour profiter de toutes les améliorations et corrections de bogues que nous avons ajoutées au fil du temps.\n\n### Préparez-vous au mappage des contributions utilisateur après la migration\n\nFamiliarisez-vous avec le [processus de mappage des contributions et des appartenances utilisateur](https://docs.gitlab.com/user/project/import/#user-contribution-and-membership-mapping) afin de savoir à quoi vous attendre une fois la migration terminée et quelles sont les prochaines étapes à suivre.\n\n### Examinez les options pour réduire la durée de migration\n\nSelon l'endroit où vous migrez (GitLab.com, une instance auto-gérée ou Dedicated) vous pouvez utiliser [diverses stratégies pour réduire la durée de migration](https://docs.gitlab.com/ee/user/group/import/#reducing-migration-duration).\n\n## Comment puis-je examiner les résultats ?\n\nVous pouvez consulter tous les groupes et projets que vous avez migrés par transfert direct sur la [page d'historique d'importation de groupe](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#group-import-history). Pour chaque groupe et projet, vous pouvez consulter les statistiques des éléments importés et examiner plus en détails si certains éléments n'ont pas été importés. Vous pouvez également utiliser les [points de terminaison API](https://docs.gitlab.com/ee/api/bulk_imports.html#list-all-group-or-project-migrations-entities) pour faire de même.\n\nDans les cas où la plupart de vos projets se sont terminés avec succès mais qu'un ou deux finissent par manquer certaines relations, comme des merge requests ou des tickets, nous vous recommandons d'essayer de réimporter ces projets [en utilisant l'API](https://docs.gitlab.com/ee/api/bulk_imports.html#start-a-new-group-or-project-migration).\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753961409/ja8agmwarwxxlo9vmqbo.gif)\n\n## Quelle est la prochaine étape pour la migration par transfert direct ?\n\nNous sommes ravis de rendre la migration par transfert direct disponible et nous espérons que vous l'êtes aussi ! Nous souhaitons connaître votre avis. Quel est l'élément qui vous manque le plus ? Que pouvons-nous améliorer ? Faites-le nous savoir dans [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/284495) et nous continuerons à itérer !",[718,769,801],{"featured":91,"template":806,"slug":1105},"migrating-by-direct-transfer-is-generally-available",{"content":1107,"config":1116},{"title":1108,"description":1109,"authors":1110,"heroImage":893,"date":1113,"body":1114,"category":769,"tags":1115},"Accélérez le développement de systèmes embarqués avec GitLab","Découvrez comment les tests matériels automatisés, les compilations standardisées, les workflows collaboratifs, et la conformité intégrée éliminent les goulots d’étranglement dans le développement de micrologiciels.",[1111,1112],"Matt DeLaney","Darwin Sanoy","2025-07-29","Les logiciels présents dans les systèmes embarqués, autrefois perçus comme de simples composants techniques, constituent désormais un facteur de différenciation essentiel. Les micrologiciels qui optimisent le fonctionnement de nos véhicules, avions et équipements industriels atteignent aujourd’hui un niveau de complexité remarquable. D'ici fin 2025, chaque véhicule contiendra en moyenne [650 millions](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) de lignes de code, contre 200 millions il y a seulement cinq ans. Dans l’aérospatial, la complexité des logiciels embarqués a presque [doublé tous les quatre ans](https://www.mckinsey.com/industries/aerospace-and-defense/our-insights/debugging-the-software-talent-gap-in-aerospace-and-defense) au cours des dernières décennies. \n\nLes approches traditionnelles de développement de systèmes embarqués ralentissent le travail des ingénieurs, qui peinent à gérer efficacement la complexité croissante des composants logiciels des machines modernes, notamment : \n\n* [Les goulots d'étranglement lors des tests matériels](#challenge-1-hardware-testing-bottlenecks) \n* [Les environnements de compilation incohérents](#challenge-2-inconsistent-build-environments)\n* [Les pratiques de développement cloisonnées](#challenge-3-siloed-development-practices)\n* [Les processus manuels de conformité à la sécurité fonctionnelle](#challenge-4-manual-functional-safety-compliance-processes)\n\nLes équipes chargées de développer des systèmes embarqués doivent adopter une nouvelle approche pour faire face à l'augmentation rapide de la taille des dépôts de code. \n\nDécouvrez dans cet article quatre façons de tirer parti des capacités d'IA native de la plateforme DevSecOps de GitLab, afin de raccourcir les boucles de rétroaction, favoriser un travail collaboratif et itératif, et rationaliser la gestion de la conformité.\n\n## Défi 1 : les goulots d'étranglement lors des tests matériels\n\nContrairement aux logiciels d'entreprise qui peuvent s'exécuter sur pratiquement n'importe quel serveur cloud, les logiciels embarqués du secteur automobile doivent être testés sur du matériel spécialisé reproduisant fidèlement les environnements de production. Les processus de test HIL (Hardware-In-the-Loop) traditionnels suivent souvent ce workflow :\n\n1. Un développeur écrit le code d'un système embarqué (par exemple, une unité de commande électronique).  \n2. Il sollicite l'accès à des bancs d'essai matériels limités et onéreux (le prix peut varier entre 500 000 $ et 10 millions de dollars chacun).  \n3. Il patiente plusieurs jours, voire des semaines, avant d'obtenir cet accès.  \n4. Puis il déploie et teste manuellement le code directement sur son poste de travail.\n5. Enfin, il documente les résultats des tests, transmet le matériel à un autre membre de l'équipe de développement pour la suite du projet, et attend de pouvoir effectuer à nouveau d'autres tests matériels.\n\nCe processus s'avère particulièrement inefficace. Une fois leur code écrit, les développeurs de systèmes embarqués peuvent attendre plusieurs semaines avant de pouvoir le tester sur une cible matérielle. Entre temps, ils sont déjà passés à d'autres tâches, ce qui entraîne un changement de contexte préjudiciable à leur productivité. Pire encore, ils peuvent découvrir au bout de plusieurs semaines qu'une simple erreur de calcul s'est glissée dans leur code. \n\n### Solution : allocation automatisée du matériel et intégration continue\n\nVous pouvez rationaliser les tests matériels grâce à l'automatisation en utilisant le composant CI/CD [On-Premises Device Cloud](https://gitlab.com/guided-explorations/embedded/ci-components/device-cloud) de GitLab. Ce composant permet d'automatiser l'orchestration de ressources matérielles limitées en transformant un processus manuel et fastidieux en un workflow rationalisé et continu.\n\nLe composant On-Premises Device Cloud procède comme suit :\n\n1. Il crée des pools de ressources matérielles partagées.  \n2. Il alloue automatiquement (et exclusivement) du matériel aux tâches de test matériel du pipeline d'un développeur en fonction de la disponibilité.  \n3. Il déploie et exécute les tests sans intervention manuelle.  \n4. Il collecte les résultats des tests et les partage via des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") intégrés.  \n5. Il libère automatiquement le matériel dans le pool de ressources « disponibles ».\n\nUne fois que vous avez soumis le code, vous recevez les résultats en quelques heures, au lieu de plusieurs jours auparavant, souvent sans jamais toucher physiquement le matériel de test.\n\nDécouvrez dans cette vidéo comment le composant CI/CD On-Premises Device Cloud de GitLab permet d'orchestrer à distance l'allocation de matériel partagé pour les tests HIL :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/ltr2CIM9Zag?si=NOij3t1YYz4zKajC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nVous pouvez également adopter des stratégies de test multi-niveaux, qui offrent un compromis optimal entre rapidité d'exécution et qualité des résultats. Pour cela, intégrez les modèles et environnements de test de systèmes embarqués suivants dans vos pipelines automatisés GitLab CI :\n\n* **Software-in-the-Loop (SIL) :** tests effectués sur des simulateurs de matériel virtuels pour obtenir plus rapidement les tout premiers retours sur le code.  \n* **Processor-in-the-Loop (PIL) :** tests réalisés sur un processeur proche du contexte final pour obtenir des retours sur le code plus rapidement et à moindre coût.  \n* **Hardware-in-the-Loop (HIL) :** tests sur du matériel complet équivalent à celui de l'environnement de production, utilisés comme bancs d'essai pour vérification à un stade avancé.\n\nEn automatisant l'orchestration de ces différents tests dans vos pipelines CI, vous serez en mesure d'identifier les problèmes plus tôt, d'itérer plus rapidement et d'accélérer les délais de mise sur le marché.\n\n## Défi 2 : les environnements de compilation incohérents\n\nL'hétérogénéité des environnements de compilation constitue un problème majeur dans le développement de systèmes embarqués. Les équipes chargées de développer des systèmes embarqués exécutent souvent manuellement des compilations sur leurs machines locales avec des configurations, versions de compilateur et dépendances parfois très différentes. Elles intègrent ensuite les binaires issus de leurs compilations locales dans le code source partagé.\n\nCette approche entraîne plusieurs problèmes :\n\n* **Résultats incohérents :** basées sur le même code source, les compilations produisent des résultats différents selon les machines utilisées.  \n* **Syndrome du « Ça fonctionne sur ma machine » :** le code compilé localement échoue dans les environnements partagés.  \n* **Mauvaise traçabilité :** piste d'audit limitée pour connaître l'auteur, la date et le motif de la compilation.  \n* **Compartimentation des connaissances :** seuls quelques experts maîtrisent le processus de compilation.\n\nCette approche accroît le risque d'erreurs, crée des goulots d'étranglement et peut générer des retards coûteux. \n\n### Solution : automatisation standardisée des compilations\n\nVous pouvez relever ces défis en mettant en œuvre une automatisation standardisée de la compilation au sein de vos pipelines CI/CD dans GitLab. Cette approche garantit des environnements de compilation cohérents, reproductibles et basés sur des conteneurs, éliminant ainsi les variations spécifiques de configuration entre les différentes machines. En combinant cette standardisation avec des scripts de provisionnement Embedded Gateway Runner spécifiques, les conteneurs peuvent s'interfacer avec le matériel pour y déployer du code et surveiller les ports dans le cadre de tests automatisés.\n\nVoici les points clés de cette solution :\n\n* **Environnements gérés par le cycle de vie :** définissez vos environnements de simulation de systèmes embarqués complexes sous forme de code, déployez-les automatiquement pour les tests, puis détruisez-les une fois les tests terminés.  \n* **Conteneurisation :** utilisez des conteneurs Docker pour garantir des environnements de compilation homogènes et reproductibles.  \n* **Gestion automatisée des dépendances :** assurez un contrôle et un versionnage rigoureux de toutes les dépendances.  \n* **Compilations centralisée :** exécutez les compilations sur une infrastructure partagée, plutôt que sur des machines locales.\n\n> Suivez ce tutoriel et découvrez [comment automatiser les compilations de logiciels embarqués dans un pipeline GitLab CI](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci/-/blob/main/TUTORIAL2.md%20).\n\nEn standardisant et en automatisant le processus de compilation, vous vous assurez que chaque compilation suit les mêmes étapes avec des dépendances identiques, produisant ainsi des résultats cohérents, quelle que soit la personne qui l'a initiée. Cette approche améliore non seulement la qualité, mais rend aussi le processus accessible à toute l'équipe, même aux membres ne possédant pas une expertise approfondie dans ce domaine.\n\n## Défi 3 : les pratiques de développement cloisonnées\n\nAlors que les équipes de développement ont largement adopté des pratiques collaboratives telles que [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que l'approche DevOps ?\"), en s'appuyant sur la gestion partagée du code source (SCM) et les systèmes d'intégration et de livraison continues ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce que le CI/CD ?\")), les développeurs de systèmes embarqués travaillent encore souvent seuls à leur bureau. Cette situation s'explique par plusieurs contraintes techniques légitimes. \n\nPar exemple, la virtualisation matérielle est un pilier de l'automatisation DevOps. Toutefois, le secteur a été plus lent à virtualiser la vaste gamme de processeurs et de cartes spécialisés utilisés dans les systèmes embarqués, en grande partie en raison des difficultés liées à la virtualisation des systèmes de production en temps réel et d'un manque d'incitations économiques. Nous pouvons comparer cela à la virtualisation cloud, qui s'est largement démocratisée et a profité au développement SaaS depuis plus d'une décennie.\n\nAujourd'hui, de nombreux fournisseurs adoptent désormais la virtualisation afin d'accélérer le développement des systèmes embarqués. Cependant, si les équipes ne parviennent pas à adopter des options de test virtuel, l'effet de silo persistera, avec des impacts négatifs sur l'entreprise, notamment les suivants : \n\n* **Une fragmentation des connaissances** : les informations critiques restent dispersées entre différents membres de l'équipe et entre différentes équipes.  \n* **Un développement redondant** : plusieurs équipes résolvent les mêmes problèmes, ce qui crée des incohérences.  \n* **Une découverte tardive lors des intégrations massives (big-bang)** : les problèmes ne sont détectés qu'aux dernières étapes du processus, lorsque plusieurs développeurs intègrent leur code en même temps, rendant la correction des erreurs plus coûteuses.  \n* **Un ralentissement de l'innovation** : les solutions développées dans un domaine ont peu d'impact sur les autres, ce qui entrave le développement de nouvelles idées de produits.\n\n### Solution : ingénierie collaborative via une plateforme unifiée\n\nUne étape importante pour briser ces silos consiste à standardiser le développement de systèmes embarqués sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") unifiée de GitLab. GitLab joue un rôle central dans l’évolution des systèmes embarqués vers des plateformes consolidées et partagées, adaptées aux contraintes des appareils embarqués. \n\nLa plateforme GitLab offre notamment les avantages suivants :\n\n* **Une visibilité partagée :** l'ensemble du code, des tickets et de la documentation sont accessibles à toutes les équipes.  \n* **Des workflows collaboratifs :** favorisez la revue par les pairs et le partage des connaissances par le biais de merge requests.  \n* **Des connaissances centralisées :** maintenez une source unique de vérité pour tous les artefacts de développement.  \n* **Une collaboration asynchrone :** les équipes sont en mesure de collaborer efficacement, quel que soit leur localisation ou leur fuseau horaire.\n\nLa collaboration entre les humains et les agents d'IA est un ingrédient fondamental pour stimuler les innovations orientées client, tant pour les générations nées à l'ère du numérique que pour les marques établies proposant des systèmes embarqués. GitLab facilite cette synergie en favorisant la transparence tout au long du cycle de développement, transformant ainsi le développement de systèmes embarqués en une pratique collaborative plutôt qu'une activité isolée. Les équipes de développement peuvent suivre le travail de leurs collègues, apprendre des expériences collectives et s'appuyer sur des solutions partagées.\n\nRegardez cette présentation d'Embedded World Germany 2025 et découvrez le potentiel des équipes chargées de développer des systèmes embarqués qui collaborent et partagent leur travail en cours en temps réel. La partie démonstration (de 24:42 à 36:51) illustre comment intégrer les tests HIL dans un pipeline GitLab CI afin de favoriser un développement collaboratif efficace.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/F_rlOyq0hzc?si=eF4alDY6HK98uZPj\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nPlus important encore, en renforçant leur collaboration grâce à l'approche DevSecOps, les équipes parviennent à concevoir des systèmes embarqués totalement novateurs. En effet, la collaboration alimente l'innovation. Par exemple, [une étude](https://www.sciencedirect.com/science/article/abs/pii/S0749597800928887) a démontré que le brainstorming de groupe, lorsqu'il est correctement structuré, génère des idées plus innovantes et créatives que le travail individuel. Dans la course au développement de produits définis par logiciel, le développement collaboratif est donc un facteur clé de succès. \n\n## Défi 4 : les processus manuels de conformité à la sécurité fonctionnelle\n\nDans les secteurs de l'automobile et de l'aérospatiale, les systèmes embarqués doivent respecter des normes strictes de sécurité fonctionnelle, telles que les ISO 26262, MISRA C/C++, DO-178C et DO-254. Les approches traditionnelles de conformité impliquent des revues manuelles, une documentation volumineuse et plusieurs étapes de vérification tardives dans le cycle de développement. Elles créent souvent des goulots d'étranglement lors de la recherche de failles de sécurité. Par exemple, lorsque des scanners spécialisés dans la sécurité et la qualité du code des systèmes embarqués détectent des vulnérabilités, le ticket associé vient s'ajouter à la pile de tickets non résolus. Les développeurs ne peuvent pas intégrer leur code et les équipes de sécurité doivent traiter un important backlog de violations des exigences de conformité. Cette situation ralentit considérablement les délais de mise en conformité et freine l'avancement global du projet. \n\nVoici les principaux défis à relever : \n\n* **Détection tardive des problèmes de conformité** : les anomalies sont découvertes une fois le développement terminé.  \n* **Charge de travail liée à la documentation** : effort manuel important pour créer et maintenir des preuves de conformité.  \n* **Goulots d'étranglement relatifs aux processus** : étapes de conformité réalisées de manière séquentielle, qui bloquent la progression du développement.\n* **Dépendance à l'expertise** : un nombre limité de spécialistes sont sollicités pour les activités de contrôle de la conformité.\n\nEn conséquence, les équipes doivent souvent choisir entre vélocité et conformité, un compromis risqué lorsqu'il s'agit de systèmes critiques pour la sécurité.\n\n### Solution : un workflow automatisé de contrôle de la conformité en matière de sécurité fonctionnelle\n\nPlutôt que de traiter la sécurité et la conformité comme des étapes de vérification post-développement, vous pouvez codifier les exigences de conformité et les appliquer automatiquement via [des frameworks personnalisables dans GitLab](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/). Pour ce faire, en particulier pour les normes de sécurité fonctionnelle, vous pouvez intégrer GitLab à des outils spécialisés, capables d’analyser en profondeur les micrologiciels conformément aux normes en vigueur dans ce domaine. Parallèlement, GitLab propose des contrôles de conformité automatisés, des pistes d'audit complètes et un contrôle rigoureux des merge requests : autant de fonctionnalités essentielles pour prendre en charge un programme de conformité logicielle continue robuste. \n\nVoici les composants de cette approche intégrée :\n\n* **Compliance-as-Code :** définissez les exigences de conformité sous forme de contrôles automatisés.  \n* **Intégration d'outils spécialisés :** connectez des outils tels que CodeSonar à la plateforme DevSecOps pour valider les exigences de conformité propres au secteur automobile.  \n* **Vérification continue de la conformité :** évaluez la conformité tout au long du cycle de développement.  \n* **Collecte automatisée des preuves :** rassemblez les artefacts de conformité comme un sous-produit du développement.\n\nDécouvrez dans cette vidéo comment tirer parti des frameworks de conformité personnalisés dans GitLab afin de créer vos propres politiques de conformité adaptées aux normes en vigueur (par exemple, ISO 26262) et comment les appliquer automatiquement à vos projets dans GitLab.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/S-FQjzSyVJw?si=0UdtGNuugLPG0SLL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nEn contrôlant la conformité en amont et en l'intégrant naturellement dans vos workflows de développement existants, vous pouvez maintenir les normes de sécurité sans compromettre la vélocité. Les contrôles automatisés détectent les problèmes à un stade précoce, lorsqu'ils sont plus faciles et moins coûteux à résoudre, tandis que la collecte continue de preuves réduit la charge de travail liée à la gestion de la documentation.\n\n## Accélérez la livraison de vos logiciels avec les systèmes embarqués \n\nLe développement de systèmes embarqués connaît une transformation rapide. Les équipes qui s'en tiennent à des processus manuels et des workflows isolés seront de plus en plus à la traîne, tandis que celles qui adoptent des pratiques automatisées et collaboratives dessineront l'avenir des systèmes intelligents définis par logiciel.\n\nPour vous lancer, explorez notre [atelier DevOps dédié aux systèmes embarqués](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci) et commencez à automatiser vos workflows de développement de systèmes embarqués avec GitLab. Vous pouvez également [regarder cette présentation par le Field Chief Cloud Architect de GitLab](https://content.gitlab.com/viewer/0a35252831bd130f879b0725738f70ed) pour découvrir comment les entreprises leader intègrent les tests matériels dans leurs workflows d'intégration continue afin d'accélérer la livraison de leurs systèmes embarqués.",[],{"slug":1117,"featured":6,"template":806},"4-ways-to-accelerate-embedded-development-with-gitlab",{"content":1119,"config":1128},{"title":1120,"description":1121,"authors":1122,"heroImage":1124,"date":1125,"body":1126,"category":769,"tags":1127},"Recherche exacte de code : trouvez rapidement du code dans vos dépôts","Découvrez comment trouver des correspondances exactes, utiliser des motifs regex et afficher des résultats contextuels dans des codes sources de plusieurs téraoctets. ",[1123],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-23","Imaginez pouvoir cibler n'importe quelle ligne de code parmi 48 To de dépôts en quelques millisecondes. Ceci est désormais possible avec la fonctionnalité de [recherche exacte de code](https://docs.gitlab.com/ee/user/search/exact_code_search.html) de GitLab qui fournit une précision extrême, une prise en charge avancée des expressions régulières (regex) et des résultats contextuels sur plusieurs lignes. En présence de dépôts de code volumineux, cette fonctionnalité facilite considérablement le travail des équipes.\n\n## Pourquoi la recherche de code traditionnelle est-elle problématique ?\n\nToute personne travaillant avec du code connaît la frustration de devoir chercher du code dans plusieurs dépôts. Qu'il s'agisse de déboguer un problème, d'examiner des fichiers de configuration, de rechercher des vulnérabilités, de mettre à jour une documentation ou de vérifier la mise en œuvre d'un projet, vous savez exactement ce que vous cherchez, mais les outils de recherche traditionnels vous font régulièrement défaut.\n\nCes outils renvoient trop souvent des dizaines de faux positifs, manquent cruellement de contexte pour comprendre les résultats obtenus et sont de plus en plus lents à mesure que le code source s’étoffe. Par conséquent, vous perdez un temps précieux à chercher une aiguille dans une botte de foin au lieu de compiler, de sécuriser ou d'améliorer votre logiciel.\n\nLa fonctionnalité de recherche de code de GitLab était jusqu'ici prise en charge par Elasticsearch ou OpenSearch. Bien qu'excellents pour rechercher des tickets, des merge requests, des commentaires et d'autres données contenant du langage naturel, ces outils n'ont tout simplement pas été spécifiquement conçus pour le code. Après [avoir évalué de nombreuses options](https://gitlab.com/groups/gitlab-org/-/epics/7404), nous avons développé une meilleure solution.\n\n## Qu'est-ce que la recherche exacte de code ?\n\nLa **[recherche exacte de code](https://docs.gitlab.com/ee/user/search/exact_code_search.html)** de GitLab est actuellement en phase de test bêta et optimisée par [Zoekt](https://github.com/sourcegraph/zoekt) (prononcé « zookt », qui signifie « recherche » en néerlandais). Zoekt est un moteur de recherche de code open source initialement développé par Google et aujourd'hui maintenu par Sourcegraph. Conçu spécifiquement pour une recherche de code à la fois rapide et précise à grande échelle, nous l'avons enrichi avec des intégrations propres à GitLab, des améliorations avancées et une intégration facilitée du système d'autorisations.\n\nCette fonctionnalité révolutionne la manière dont vous recherchez et comprenez le code grâce aux trois éléments clés :\n\n**1. Un mode de recherche par correspondance exacte**\n\nLorsque vous basculez en **mode de recherche par correspondance exacte**, le moteur de recherche ne renvoie que les résultats qui correspondent exactement à votre requête, éliminant ainsi les faux positifs. Cette précision est inestimable dans les cas de figure suivants :\n\n* Vous recherchez des messages d'erreur spécifiques.\n* Vous recherchez des signatures de fonctions précises.\n* Vous recherchez des instances de noms de variables spécifiques.\n\n**2. Un mode de recherche par expression régulière**\n\nPour les recherches complexes, ce mode vous permet de créer des motifs de recherche sophistiqués :\n\n* Trouvez des fonctions selon des motifs de nommage spécifiques.\n* Déterminez l’emplacement des variables qui correspondent à certains critères précis.\n* Identifiez les failles de sécurité potentielles à l'aide de la correspondance de motifs.\n\n**3. Des correspondances sur plusieurs lignes**\n\n![Recherche exacte de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\nEn plus de la ligne contenant le code recherché, vous avez accès au contexte environnant qui est indispensable pour bien comprendre le code. Vous n'avez donc plus besoin d'accéder aux fichiers dans le seul but d'obtenir un contexte plus clair, ce qui accélère considérablement votre workflow.\n\n## Des fonctionnalités aux workflows : cas d'utilisation et impact associé \n\nExaminons maintenant comment ces nouvelles capacités se traduisent dans le quotidien des équipes de développement  :\n\n### Débogage en quelques secondes\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez copier un message d'erreur, lancer une recherche, parcourir une longue liste de correspondances partielles dans les commentaires, la documentation et les fragments de code, cliquer sur plusieurs fichiers... avant de trouver enfin la ligne de code que vous recherchiez.\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n1. Vous copiez le message d'erreur exact. \n2. Vous le collez dans la fonctionnalité de recherche exacte de code en activant le mode de recherche par correspondance exacte.\n3. Vous trouvez instantanément l'emplacement précis où l'erreur est présente, avec le contexte environnant nécessaire à sa compréhension.\n\n**Impact :** vous réduisez ainsi le temps de débogage de plusieurs minutes à quelques secondes, sans frustration ni faux positifs.\n\n### Exploration rapide de codes sources inconnus\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez parcourir les répertoires, deviner l'emplacement probable des fichiers, ouvrir des dizaines de fichiers et élaborer peu à peu une compréhension globale du code source.\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n* Vous recherchez directement les méthodes ou classes principales avec le mode de recherche par correspondance exacte.\n* Vous examinez plusieurs correspondances de lignes pour comprendre les détails de leur mise en œuvre.\n* Vous utilisez le mode de recherche par expression régulière pour identifier des motifs similaires dans l'ensemble du code source.\n\n**Impact :** vous bénéficiez d'une vision claire de l'architecture du code en quelques minutes plutôt qu'en quelques heures, ce qui accélère considérablement l'intégration de nouveaux membres au sein de l'équipe ainsi que la collaboration transversale.\n\n### Refactorisation sécurisée\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez localiser toutes les occurrences d'une méthode, mais certaines passaient inaperçues, et vous introduisiez des bogues en raison d'une refactorisation incomplète.\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n* Vous utilisez le mode de recherche par correspondance exacte pour identifier toutes les occurrences de méthodes ou de variables.\n* Vous examinez le contexte pour comprendre les motifs d'utilisation.\n* Vous planifiez votre refactorisation avec des informations complètes sur son impact.\n\n  **Impact :** vous éliminez les bogues liés aux « occurrences manquées » qui entravent souvent les efforts de refactorisation, vous améliorez la qualité du code et vous réduisez les ajustements nécessaires.\n\n### Audit de sécurité optimisé\n\nLes équipes de sécurité peuvent :\n\n* Créer des motifs regex ciblant les portions de code présentant des vulnérabilités connues\n* Effectuer une recherche dans tous les dépôts d'un espace de nommage\n* Identifier rapidement les failles de sécurité potentielles avec un contexte facilitant l'évaluation des risques\n\n**Impact :** vous transformez vos audits de sécurité, souvent manuels et sujets aux erreurs, en revues systématiques et exhaustives.\n\n### Informations recoupées entre plusieurs dépôts\n\nVos équipes peuvent effectuer une recherche dans l'ensemble de votre espace de nommage ou de votre instance pour :\n\n* Identifier des implémentations similaires dans différents projets\n* Identifier des opportunités de création de bibliothèques partagées ou de standardisation du code\n\n**Impact :** vous éliminez les silos entre les projets et identifiez les opportunités de réutilisation et de standardisation du code.\n\n## Zoekt : rapidité et précision au service du code\n\nAvant de détailler nos réalisations à grande échelle, explorons ce qui distingue Zoekt des moteurs de recherche traditionnels, et pourquoi il peut trouver des correspondances exactes aussi rapidement.\n\n### Trigrammes positionnels : le secret d'une correspondance exacte ultra-rapide\n\nLa rapidité de Zoekt provient de son utilisation de **trigrammes positionnels**, une technique qui indexe chaque séquence de trois caractères en conservant leur position exacte dans les fichiers. Cette approche résout l'un des plus grands défis que les équipes de développement rencontrent avec la recherche de code basée sur Elasticsearch : les faux positifs.\n\nVoici le principe :\n\nLes **moteurs de recherche plein texte traditionnels** comme Elasticsearch segmentent le code en mots isolés et perdent ainsi les informations de position. Par exemple, lorsque vous recherchez `getUserId()`, ils peuvent renvoyer des résultats contenant les fragments **user**, **get** et **Id** dispersés dans un même fichier, ce qui génère des faux positifs, source de frustration pour les utilisateurs de GitLab.\n\nLes **trigrammes positionnels de Zoekt**, quant à eux, conservent les séquences de caractères exactes ainsi que leurs positions dans le code. Ainsi, lorsque vous recherchez `getUserId()`, Zoekt cible précisément les trigrammes exacts, comme **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(\", \"d()**, dans cette séquence précise et à ces positions exactes. Cette approche garantit que seules les correspondances exactes sont renvoyées.\n\nAinsi, des recherches qui renvoyaient auparavant des centaines de faux positifs ne renvoient désormais plus que les correspondances exactes souhaitées. Cette fonctionnalité était [l'une des plus demandées](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) pour une bonne raison : les équipes de développement perdaient beaucoup trop de temps à passer au crible les faux positifs.\n\n### Performances des expressions régulières à grande échelle\n\nZoekt excelle dans la recherche de correspondances exactes, mais est également optimisé pour les recherches d'expressions régulières. Grâce à des algorithmes sophistiqués, il convertit les motifs regex en requêtes trigrammes efficaces lorsque cela est possible, garantissant ainsi une rapidité constante, même pour les recherches de motifs complexes portant sur plusieurs téraoctets de code.\n\n## Une fonctionnalité adaptée aux entreprises\n\nLa recherche exacte de code est puissante et conçue pour gérer de très grands volumes de code tout en offrant des temps de réponse remarquables. Il ne s'agit pas du simple ajout d'une nouvelle fonctionnalité à l'interface utilisateur, mais d'une architecture backend entièrement repensée.\n\n### Gestion de plusieurs téraoctets de code en toute simplicité\n\nRien que sur GitLab.com, notre infrastructure de recherche exacte de code indexe et interroge plus de **48 To** de données de code, tout en offrant des temps de réponse ultra-rapides. Cette volumétrie couvre des millions de dépôts répartis dans des milliers d'espaces de nommage, tous consultables en seulement quelques millisecondes, soit plus de code que l'ensemble des projets du noyau Linux, d'Android et de Chromium combinés. Et pourtant, la recherche exacte de code peut trouver une ligne spécifique dans l'ensemble du code source en quelques millisecondes seulement.\n\n### Architecture de nœuds à enregistrement automatique\n\nParmi nos améliorations techniques, voici quelques innovations clés : \n\n* **Enregistrement automatique des nœuds :** les nœuds Zoekt s'enregistrent automatiquement auprès de GitLab.\n* **Attribution dynamique des partitions :** le système attribue automatiquement les espaces de nommage entre les nœuds.\n* **Surveillance de l'état :** les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne.\n\nCette architecture à configuration automatique simplifie considérablement la montée en charge. Lorsque la capacité doit être augmentée, les administrateurs peuvent tout simplement ajouter de nouveaux nœuds, sans aucune reconfiguration complexe.\n\n### Système distribué avec répartition de charge intelligente\n\nEn arrière-plan, la recherche exacte de code repose sur un système distribué comprenant les composants clés suivants :\n\n* **Nœuds de recherche spécialisés :** serveurs dédiés pour gérer l'indexation et la recherche\n* **Partitionnement intelligent :** le code est réparti entre les nœuds en fonction des espaces de nommage\n* **Équilibrage automatique de la charge :** le système répartit intelligemment le travail en fonction des capacités disponibles\n* **Haute disponibilité :** plusieurs réplicas assurent la continuité du service même en cas de défaillance d'un nœud\n\n*Remarque : la haute disponibilité fait partie intégrante de l'architecture, mais n'est pas encore entièrement déployée. Consultez le [ticket 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) pour vous tenir au courant des futures mises à jour.*\n\n### Intégration sans accroc de la sécurité\n\nLa recherche exacte de code s'intègre automatiquement au système d'autorisation de GitLab :\n\n* Les résultats de recherche sont filtrés en fonction des droits d'accès de chaque utilisateur.\n* Seul le code des projets auxquels l'utilisateur a accès est affiché.\n* La sécurité est intégrée à l'architecture de base, et non ajoutée ultérieurement.\n\n### Performances optimisées\n\n* **Indexation performante :** les dépôts volumineux sont indexés en quelques dizaines de secondes.\n* **Exécution rapide des requêtes :** la plupart des recherches renvoient des résultats en moins d'une seconde.\n* **Résultats en streaming :** la nouvelle recherche fédérée basée sur gRPC diffuse les résultats au fur et à mesure de leur découverte.\n* **Arrêt anticipé :** dès qu'un nombre suffisant de résultats a été collecté, le système interrompt la recherche.\n\n## De la bibliothèque au système distribué : notre réponse aux défis d'ingénierie\n\nBien que Zoekt soit très performant pour indexer et rechercher du code localement, son architecture de base était conçue à l'origine comme une bibliothèque minimale, destinée à la gestion des fichiers d'index `.zoekt`, et non comme une base de données distribuée ou un service capable de fonctionner à l'échelle d'une entreprise. \n\nVoici les principaux défis techniques que nous avons dû surmonter pour l'adapter pleinement à l'écosystème GitLab.\n\n### Défi 1 : création d'une couche d'orchestration\n\n**Le problème :** Zoekt a été conçu pour fonctionner avec des fichiers d'index locaux, et non pour être distribué sur plusieurs nœuds desservant de nombreux utilisateurs simultanés.\n\n**Notre solution :** nous avons développé une couche d'orchestration complète qui :\n\n* crée et gère des modèles de base de données pour suivre les nœuds, les index, les dépôts et les tâches.\n* met en œuvre une architecture de nœuds à enregistrement automatique (inspirée du fonctionnement de GitLab Runner).\n* gère l'attribution automatique des partitions et l'équilibrage de la charge entre les nœuds.\n* fournit une communication bidirectionnelle de l'API entre les nœuds GitLab Rails et Zoekt.\n\n### Défi 2 : mise à l'échelle du stockage et de l'indexation\n\n**Le problème :** comment gérer efficacement des téraoctets de données d'indexation répartis sur plusieurs nœuds tout en garantissant des mises à jour rapides ?\n\n**Notre solution :** nous avons déployé les fonctionnalités suivantes  :\n\n* Partitionnement intelligent : les espaces de nommage sont répartis entre les nœuds en tenant compte de leur capacité et de leur charge.\n* Réplication indépendante : chaque nœud est indexé indépendamment à partir de [Gitaly](https://gitlab.com/gitlab-org/gitaly) (notre service de stockage Git), évitant ainsi toute synchronisation complexe.\n* Gestion avancée des filigranes : un système sophistiqué d'allocation de stockage empêche les nœuds de manquer d'espace.\n* Architecture binaire unifiée : un seul binaire `gitlab-zoekt` peut fonctionner à la fois en mode indexeur et en mode serveur web.\n\n### Défi 3 : intégration des autorisations\n\n**Le problème :** Zoekt n'avait aucune notion du système d'autorisation complexe de GitLab. Les utilisateurs ne doivent voir que les résultats des projets auxquels ils ont accès.\n\n**Notre solution :** nous avons intégré un filtrage des autorisations natif directement dans le flux de recherche :\n\n* Les requêtes de recherche incluent le contexte des autorisations de l'utilisateur.\n* Les résultats sont filtrés pour n’inclure que les éléments auxquels l'utilisateur peut accéder, même dans le cas où les autorisations évoluent avant la fin de l'indexation.\n\n### Défi 4 : simplification opérationnelle\n\n**Le problème :** gérer un système de recherche distribué ne devrait pas nécessiter une équipe dédiée.\n\n**Notre solution :**\n\n* Mise à l'échelle automatique : l'ajout de capacité est aussi simple que le déploiement de nœuds supplémentaires. Ces derniers s'enregistrent automatiquement et gèrent immédiatement la charge de travail.\n* Auto-réparation : les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne, avec redistribution automatique de leurs tâches.\n* Partitionnement sans configuration : le système détermine automatiquement les affectations de partitions optimales.\n\n## Déploiement progressif : réduire les risques à grande échelle\n\nLe déploiement d'un tout nouveau backend de recherche auprès de millions d'utilisateurs a nécessité une planification minutieuse. Voici comment nous avons limité l'impact sur les clients tout en garantissant la fiabilité :\n\n### Phase 1 : tests contrôlés (groupe gitlab-org)\n\nNous avons commencé par activer la recherche exacte de code uniquement pour le groupe `gitlab-org`, constitué de nos propres dépôts internes. \n\nCette étape nous a permis de :\n\n* Tester le système avec des charges de travail réelles en production\n* Identifier et corriger les goulots d'étranglement liés aux performances\n* Rationaliser le processus de déploiement\n* Tirer des enseignements concrets sur les workflows grâce aux retours d'utilisateurs\n\n### Phase 2 : validation et optimisation des performances\n\nAvant d'étendre la fonctionnalité, nous nous sommes assurés que le système pouvait gérer la charge à l'échelle de GitLab.com. Pour cela, nous avons dû :\n\n* Mettre en œuvre une surveillance et une gestion des alertes complètes\n* Valider la gestion du stockage basée sur la croissance réelle des données en production\n\n### Phase 3 : expansion progressive auprès des clients\n\nNous avons progressivement ouvert l'accès à la recherche exacte de code aux clients désireux de l'essayer, afin de :\n\n* Collecter leurs retours sur les performances et l'expérience utilisateur\n* Affiner l'interface utilisateur de recherche en fonction des workflows réels des utilisateurs\n* Optimiser les performances d'indexation (par exemple, les grands dépôts comme `gitlab-org/gitlab` sont désormais indexés en environ 10 secondes)\n* Ajuster l'architecture en fonction des leçons tirées des premiers essais\n* Augmenter massivement le débit d'indexation et améliorer le cycle de vie des transitions d'état\n\n### Phase 4 : déploiement à grande échelle\n\nAujourd'hui, plus de 99 % des groupes disposant des licences Premium et Ultimate sur GitLab.com ont accès à la recherche exacte de code. \n\nLes utilisateurs peuvent :\n\n* Basculer facilement entre les modes de recherche par expression régulière et par correspondance exacte\n* Tirer parti des avantages sans modifier la configuration\n* Revenir à l'ancienne méthode de recherche si nécessaire (bien que peu d'entre eux optent pour cette possibilité)\n\nCe déploiement progressif a permis d'éviter toute interruption de service, baisse de performances ou perte de fonctionnalités pendant la transition. Les premiers retours sont très positifs, car les utilisateurs constatent que leurs résultats de recherche sont plus pertinents et qu'ils les obtiennent beaucoup plus rapidement.\n\n> Vous souhaitez en savoir plus sur l'architecture et la mise en œuvre de la recherche exacte de code ? Consultez notre [document de conception](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) complet, qui offre une description technique détaillée de ce système de recherche distribué.\n\n## Premiers pas : comment lancer une recherche exacte de code ? \n\nLa prise en main de la recherche exacte de code est simple, car cette fonctionnalité est déjà activée par défaut pour les groupes Premium et Ultimate sur GitLab.com (accessibles aujourd'hui à plus de 99 % des groupes éligibles).\n\n### Guide de démarrage rapide\n\n1. Accédez à la recherche avancée depuis votre projet ou groupe GitLab.\n2. Saisissez votre terme de recherche dans l'onglet Code.\n3. Basculez entre les modes de recherche par correspondance exacte et par expression régulière.\n4. Utilisez des filtres pour affiner votre recherche.\n\n### Syntaxe de recherche de base\n\nQue vous utilisiez le mode de recherche par correspondance exacte ou par expression régulière, vous pouvez affiner votre recherche avec divers modificateurs :\n\n| Exemple de requête | Fonction                                                               |\n| ------------------ | ---------------------------------------------------------------------- |\n| `file:js`          | Recherche uniquement dans les fichiers dont le nom contient « js »     |\n| `foo -bar`         | Recherche « foo », mais exclut les résultats contenant « bar »         |\n| `lang:ruby`        | Recherche uniquement dans les fichiers Ruby                            |\n| `sym:process`      | Recherche « process » dans les symboles (méthodes, classes, variables) |\n\n> **Conseil :** pour optimiser votre recherche, commencez par une requête précise, puis élargissez-la si besoin. L'utilisation des filtres `file:` et `lang:` augmente considérablement la pertinence des résultats.\n\n### Techniques de recherche avancées\n\nCombinez plusieurs filtres pour gagner en précision :\n\n```\nis_expected file:rb -file:spec\n```\n\nCette requête recherche « is_expected » dans les fichiers Ruby dont le nom ne contient pas « spec ».\n\nTirez parti des expressions régulières pour obtenir des motifs puissants :\n\n```\ntoken.*=.*[\\\"']\n```\n\n[Consultez cette recherche effectuée dans le dépôt GitLab Zoekt.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\nElle permet de trouver des mots de passe codés en dur qui, s'ils ne sont pas détectés, peuvent constituer un risque de sécurité.\n\nPour approfondir la syntaxe, consultez la [documentation dédiée à la recherche exacte de code](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n## Disponibilité et déploiement\n\n### Disponibilité actuelle\n\nLa recherche exacte de code est actuellement disponible en version bêta pour les utilisateurs de GitLab.com disposant de licences Premium et Ultimate :\n\n* Elle est accessible à plus de 99 % des groupes éligibles sous licence.\n* La recherche dans l'interface utilisateur utilise automatiquement Zoekt lorsqu'il est disponible ; la recherche exacte de code via l'API de recherche est activée par le biais d'un feature flag.\n\n### Options de déploiement pour les instances Self-Managed\n\nPour les instances Self-Managed, nous proposons plusieurs méthodes de déploiement :\n\n* Kubernetes/Helm : notre méthode la mieux prise en charge, basée sur notre [Helm Chart `gitlab-zoekt`](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt).\n* Autres méthodes : nous travaillons actuellement sur la simplification du déploiement via Omnibus et d'autres options d'installation.\n\nLes exigences en configuration système varient selon la taille de votre code source, mais l'architecture est conçue pour s'adapter horizontalement et/ou verticalement à mesure que vos besoins évoluent.\n\n## Prochaines étapes\n\nBien que la recherche exacte de code soit déjà performante, nous l'améliorons continuellement avec :\n\n* **Des optimisations à grande échelle** pour gérer des instances comptant des centaines de milliers de dépôts\n* **Des options de déploiement renforcées pour les instances Self-Managed**, y compris la prise en charge simplifiée d'Omnibus\n* **Une prise en charge complète de la haute disponibilité** avec basculement automatique et équilibrage de la charge\n\nRestez à l'écoute pour suivre les prochaines mises à jour lorsque nous passerons de la version bêta à la disponibilité générale.\n\n## Transformez votre façon de rechercher des lignes de code\n\nAvec la recherche exacte de code, GitLab repense en profondeur la manière dont le code est exploré, en fournissant des correspondances exactes, une prise en charge avancée des expressions régulières et des résultats contextuels. \n\nCette nouvelle fonctionnalité résout les aspects les plus frustrants de la recherche de code :\n\n* Ne perdez plus votre temps avec des résultats non pertinents.\n* Ne ratez plus aucune correspondance importante.\n* N'ouvrez plus plusieurs fichiers juste pour comprendre le contexte de base.\n* Ne subissez plus de problèmes de performances à mesure que la taille de vos dépôts de code augmente.\n\nL'impact s'étend même bien au-delà, à la productivité globale des équipes :\n\n* **Vos équipes collaborent plus efficacement** avec un référencement clair du code.\n* **Le partage des connaissances s'accélère** avec la détection facile des motifs.\n* **L'intégration des nouveaux membres d'équipe s'accélère** avec une compréhension rapide du code source.\n* **La sécurité est renforcée** avec un audit efficace des motifs.\n* **Une réduction de la dette technique** devient réellement envisageable.\n\nLa recherche exacte de code est plus qu'une simple fonctionnalité : elle vous permet de mieux comprendre et de gérer le code. Alors, arrêtez de chercher et commencez à trouver ! \n\n**Nous serions ravis de connaître votre avis.** Partagez vos expériences, vos questions ou vos commentaires sur la recherche exacte de code dans notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Vos retours nous aident à hiérarchiser nos priorités d'améliorations et à enrichir nos futures fonctionnalités.\n\n#### Vous souhaitez tirer parti d'une recherche de code plus intelligente ? Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) et essayez dès aujourd'hui notre nouvelle fonctionnalité en effectuant une recherche dans vos espaces de nommage ou vos projets disposant d'une licence Premium ou Ultimate. Vous n'utilisez pas encore GitLab ? Inscrivez-vous pour un [essai gratuit de 60 jours de GitLab Ultimate enrichi des capacités de GitLab Duo](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) !",[898],{"featured":6,"template":806,"slug":1129},"exact-code-search-find-code-faster-across-repositories",{"category":777,"slug":781,"posts":1131},[1132,1145,1159],{"content":1133,"config":1143},{"heroImage":1134,"body":1135,"authors":1136,"updatedDate":1139,"date":1139,"title":1140,"tags":1141,"description":1142,"category":781},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750099268/Blog/Hero%20Images/Blog/Hero%20Images/GitLab_Blog_Header_v4_YBzFAgt2EAkqQfqxNFEgj_1750099267940.svg","Maintenir plusieurs frameworks de conformité dans des pipelines DevSecOps en constante évolution n’a jamais été aussi difficile. À mesure que les normes évoluent et deviennent plus complexes, les entreprises croulent sous des exigences qui se chevauchent et des processus manuels, impactant ainsi le temps des développeurs et ralentissant les audits.\n\nPour résoudre ce problème, GitLab lance les frameworks de conformité personnalisés et 50 contrôles préconfigurés pour une large gamme de normes de conformité, notamment [ISO 27001](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/ \"ISO 27001\"), le [benchmark CIS](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/) et [SOC 2](https://about.gitlab.com/fr-fr/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam/ \"SOC 2\").\n\nLes frameworks de conformité personnalisés permettent aux entreprises de mapper plusieurs contrôles qui se chevauchent, issus de différentes normes et réglementations, en un framework unique et unifié. Cette flexibilité apporte une efficacité indispensable, permettant aux entreprises d'adapter leurs programmes de conformité en fonction de leurs besoins. Comme ces politiques sont intégrées directement dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") de GitLab, la conformité est appliquée automatiquement, sans perturber le développement.\n\nDe plus, avec les contrôles préconfigurés, les équipes peuvent accélérer l'adoption de la conformité, éliminant le besoin d'outils externes ou de configurations personnalisées complexes. En intégrant la conformité directement dans le cycle de développement logiciel, GitLab offre une visibilité en temps réel, une application automatisée et une préparation aux audits simplifiée pour que les équipes puissent livrer des logiciels sécurisés et conformes, plus rapidement.\n\nLes frameworks de conformité personnalisés et les contrôles préconfigurés sont disponibles dès maintenant dans [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\").\n\n## Une pression croissante en matière de conformité\n\nLes entreprises doivent naviguer entre différents frameworks de conformité pour garantir le respect de nombreuses réglementations et fournir une assurance à leurs clients. Bien que ces frameworks partagent souvent des contrôles communs, ces derniers sont rarement alignés. Le résultat est une réalité que les équipes de conformité ne connaissent que trop bien : un suivi manuel via des feuilles de calcul qui génère le chaos, en particulier lors des examens d'audit.\n\nLes équipes de développement sont entraînées dans le tourbillon de la conformité car le développement de logiciels modernes est au cœur de la satisfaction de bon nombre de ces contrôles. Au lieu de créer et de livrer des logiciels sécurisés, ils se retrouvent à soutenir la collecte de preuves et les revues de conformité. Une étude « Total Economic Impact™ » sur GitLab Ultimate et menée par Forrester a révélé qu'avant GitLab, [les équipes de développement consacraient jusqu'à 80 heures par an de leur temps sur des tâches d'audit et de conformité](https://tei.forrester.com/go/GitLab/GitLabUltimate/?lang=en-us#Appendixes), du temps détourné de l'écriture de code et de la création de valeur commerciale.\n\nEn plus d'être inefficace, cette approche fragmentée est également coûteuse. Les [coûts liés à la conformité ont augmenté de 60 % au cours des cinq dernières années](https://www.cato.org/sites/cato.org/files/2024-01/research-brief367.pdf), selon le CATO Institute. Sans un système qui connecte l'application de la conformité à l'endroit où les logiciels sont créés, la conformité restera une réflexion après coup contraignante qui creuse un fossé entre les équipes de développement et de sécurité. \n\n## Pourquoi les frameworks de conformité personnalisés sont-ils importants ?\n\nNos clients nous ont demandé une plus grande flexibilité en matière de suivi et d’application de la conformité dans les workflows DevSecOps. Avec cette version, nous sommes heureux de donner à nos clients les moyens suivants :\n\n### Une conformité qui s'adapte à l'entreprise, et non l'inverse\n\nLes exigences réglementaires se chevauchent entre plusieurs frameworks, ce qui entraîne une complexité dans le suivi et l'application. Les frameworks de conformité personnalisés permettent aux entreprises de créer un framework unifié qui associe les exigences et les contrôles de plusieurs normes, réduisant l'effort manuel et la dépendance à des consultants souvent coûteux.\n\n### Une conformité plus rapide, de la configuration jusqu'aux audits\n\nCommencez à surveiller la conformité instantanément avec des contrôles préconfigurés alignés sur les normes de conformité clés, telles que SOC 2, ISO 27001 et les benchmarks CIS. La surveillance automatisée de la conformité et la collecte de preuves réduisent la préparation des audits de plusieurs semaines à quelques jours, permettant aux équipes de développement de rester concentrées sur la livraison de logiciels sécurisés.\n\n### Une conformité intégrée à la vitesse du développement\n\nContrairement aux outils GRC traditionnels qui fonctionnent de manière isolée, GitLab applique la conformité directement dans les pipelines CI/CD. Cette intégration signifie que la validation de la conformité se produit automatiquement lorsque le code progresse dans le pipeline, éliminant la friction traditionnelle entre la rapidité de développement et les exigences de sécurité.\n\nVoici un exemple de création d’un framework de conformité personnalisé dans GitLab :\n\n![custom compliance frameworks - edit requirement screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099291312.png)\n\n![custom compliance frameworks - screen showing requirements](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099291312.png)\n\n## Ce qu'il faut savoir sur le déploiement des frameworks de conformité personnalisés\n\nCette version comporte deux aspects critiques : \n\n* À partir de GitLab 18.0, les frameworks de conformité personnalisés seront activés par défaut. \n* Depuis GitLab 18.0, nous avons activé les frameworks de conformité personnalisés par défaut. Nous avons également supprimé les « Normes » du Centre de conformité pour simplifier l'expérience. Mais ne vous inquiétez pas, vos contrôles de conformité existants s'appliquent toujours. Nous avons converti les normes GitLab Standard et SOC 2 en labels de framework de conformité et transformé leurs vérifications de conformité en contrôles (notre nouveau terme à l'avenir). \n* Seuls les clients GitLab Ultimate peuvent définir des exigences, mapper des contrôles et appliquer des frameworks de conformité. Les utilisateurs de GitLab Premium peuvent toujours utiliser des labels de conformité, mais ils n'auront pas accès à l'ensemble des fonctionnalités. \n\nPour en savoir plus sur les frameworks de conformité personnalisés, découvrez cette vidéo d'introduction :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/yfJ0oHCIn-8?si=z_Rt_ikry4RhjEAC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n    \u003C/figure>\n\n\u003C!-- blank line -->\n\n## Déplacez la conformité en amont avec GitLab\n\nSimilaire à la sécurité, déplacer la conformité en amont signifie aborder les exigences de conformité plus tôt dans le cycle de vie du développement logiciel. Étant donné que les logiciels sont essentiels à la conformité d'une entreprise, l'intégration de contrôles là où les logiciels sont créés est cruciale. Avec GitLab, les équipes de sécurité et de conformité peuvent définir des frameworks, mapper des contrôles et automatiser l'application directement dans les pipelines CI/CD. Les équipes de développement restent concentrées sur la livraison de fonctionnalités, tandis que les équipes de conformité bénéficient d'une visibilité en temps réel et d'une collecte automatisée de preuves pour être prêtes pour l'audit. Cette approche unifiée comble le fossé entre le développement et la conformité, aidant les entreprises à atteindre une conformité continue dans le cadre de leur pratique DevSecOps.\n\nEn conséquence, les entreprises utilisant GitLab peuvent réduire de 90 % le temps passé par les équipes de développement sur les tâches d'audit et de conformité, et accélérer les audits externes de plusieurs semaines à moins d'une semaine, selon Forrester.\n\nSi vous êtes déjà un client GitLab Ultimate et que vous souhaitez en savoir plus sur la façon dont les frameworks de conformité personnalisés peuvent contribuer à améliorer votre programme de conformité et de sécurité, consultez notre documentation du [Centre de conformité](https://docs.gitlab.com/user/compliance/compliance_center/) où nous couvrons les exigences de mise en œuvre, les cas d'utilisation et plus encore.\n\nNote : « Total Economic Impact™ » sur GitLab Ultimate est une étude réalisée par Forrester Consulting en 2024 pour le compte de GitLab. Les résultats sont basés sur une organisation composite représentative des clients interrogés.",[1137,1138],"Ian Khor","Salman Ladha","2025-07-31","Présentation des frameworks de conformité personnalisés dans GitLab",[781,769,801],"Réduisez le suivi manuel, accélérez la préparation aux audits et appliquez les contrôles plus rapidement, directement depuis les workflows DevSecOps de GitLab.",{"featured":6,"template":806,"slug":1144},"introducing-custom-compliance-frameworks-in-gitlab",{"content":1146,"config":1157},{"title":1147,"description":1148,"authors":1149,"heroImage":1150,"date":975,"body":1151,"category":781,"tags":1152},"Comment sécuriser et optimiser votre dépôt Maven dans GitLab","Optimisez votre workflow DevSecOps en adoptant des bonnes pratiques, en maîtrisant des techniques avancées et en découvrant nos prochaines fonctionnalités.",[878],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","En tant que Product Manager chez GitLab, j'ai le plaisir de vous présenter nos solutions pour sécuriser et optimiser votre dépôt Maven. GitLab s'engage à offrir une plateforme DevSecOps complète, où la gestion des packages et la sécurisation des dépôts Maven jouent un rôle clé. Découvrez dans ce tutoriel les bonnes pratiques, les techniques avancées et les fonctionnalités à venir qui vont transformer votre workflow Maven.\n\n## Sécurisation de votre dépôt Maven : une approche globale\n\nLa sécurisation de votre chaîne d'approvisionnement logicielle est une priorité absolue. Voici les stratégies essentielles pour renforcer la sécurité de vos paquets Maven dans GitLab.\n\n### Mettre en œuvre un système d'authentification forte\n\n**Jetons d'accès personnels (PAT) :** privilégiez les PAT pour un contrôle d'accès affiné.\n\nPar exemple :\n\n```bash\nmvn deploy -s settings.xml\n```\n\nAvec la configuration suivante dans `settings.xml` :\n\n```xml\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_PERSONAL_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\n**Tokens de déploiement :** adaptés pour les pipelines CI/CD. Générez-les dans les paramètres de votre projet GitLab et intégrez-les dans votre fichier `.gitlab-ci.yml`.\n\n```yaml\ndeploy:\n  script:\n    - 'mvn deploy -s ci_settings.xml'\n  variables:\n    MAVEN_CLI_OPTS: \"-s ci_settings.xml --batch-mode\"\n    MAVEN_OPTS: \"-Dmaven.repo.local=.m2/repository\"\n  only:\n    - main\n```\n\nVoici le fichier `ci_settings.xml` correspondant :\n\n```xml\n\u003Csettings xmlns=\"http://maven.apache.org/SETTINGS/1.1.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd\">\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Deploy-Token\u003C/name>\n            \u003Cvalue>${env.CI_DEPLOY_PASSWORD}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nRemarques :\n\n* La variable `CI_DEPLOY_PASSWORD` doit être configurée comme une variable CI/CD dans les paramètres de votre projet GitLab et contenir le token de déploiement.\n* L'élément `\u003Cid>` doit correspondre à l'ID du dépôt tel qu'il est défini dans le fichier `pom.xml` de votre projet.\n\n**Rotation des tokens :** automatisez la stratégie de rotation des tokens à l'aide de l'API GitLab. Par exemple, vous pouvez planifier un pipeline mensuel qui regénère et met à jour vos tokens :\n\n```yaml\nrotate_tokens:\n  script:\n    - curl --request POST \"https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/deploy_tokens\" --header \"PRIVATE-TOKEN: ${ADMIN_TOKEN}\" --form \"name=maven-deploy-${CI_PIPELINE_ID}\" --form \"scopes[]=read_registry\" --form \"scopes[]=write_registry\"\n  only:\n    - schedules\n```\n\n### Tirer parti des fonctionnalités de sécurité intégrées de GitLab\n\n**Analyse des dépendances :** activez-la dans votre fichier `.gitlab-ci.yml`.\n\n```yaml\ninclude:\n  - template: Security/Dependency-Scanning.gitlab-ci.yml\n\nvariables:\n  DS_JAVA_VERSION: 11\n```\n\n**Analyse des conteneurs :** si vous conteneurisez vos applications Maven.\n\n```yaml\ninclude:\n  - template: Security/Container-Scanning.gitlab-ci.yml\n\nvariables:\n  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\n```\n\n**Conformité des licences :** assurez-vous que toutes les dépendances respectent les licences autorisées dans votre projet.\n\n```yaml\ninclude:\n  - template: Security/License-Scanning.gitlab-ci.yml\n```\n\n### Sécuriser votre pipeline CI/CD\n\n* **Variables CI/CD :** stockez toutes les informations contenant des données sensibles en toute sécurité.\n\n  ```yaml\n  variables:\n    MAVEN_REPO_USER: ${CI_DEPLOY_USER}\n    MAVEN_REPO_PASS: ${CI_DEPLOY_PASSWORD}\n  ```\n* **Variables masquées :** empêchez leur affichage dans les job logs et définissez-les dans vos paramètres GitLab CI/CD.\n* **Branches et tags protégés :** configurez-les dans les paramètres de votre projet GitLab pour restreindre les droits de publication des packages Maven aux utilisateurs autorisés.\n\n### Mettre en œuvre la signature de vos paquets\n\n* Utilisez le plug-in Maven GPG pour signer vos artefacts.\n\n  ```xml\n  \u003Cplugin>\n    \u003CgroupId>org.apache.maven.plugins\u003C/groupId>\n    \u003CartifactId>maven-gpg-plugin\u003C/artifactId>\n    \u003Cversion>1.6\u003C/version>\n    \u003Cexecutions>\n      \u003Cexecution>\n        \u003Cid>sign-artifacts\u003C/id>\n        \u003Cphase>verify\u003C/phase>\n        \u003Cgoals>\n          \u003Cgoal>sign\u003C/goal>\n        \u003C/goals>\n      \u003C/execution>\n    \u003C/executions>\n  \u003C/plugin>\n  ```\n\n* Stockez votre clé GPG dans des variables GitLab CI/CD sécurisées.\n\n### Contrôler les accès au registre de paquets\n\n* Configurez les paramètres du registre de paquets au niveau du projet et du groupe dans GitLab afin de restreindre les accès aux seuls utilisateurs autorisés.\n* Activez les listes d'autorisation d'IP au niveau du réseau dans les paramètres de votre instance GitLab pour restreindre l'accès réseau aux adresses approuvées.\n\n## Optimisation des performances : fluidifiez votre workflow Maven\n\nLa gestion de projets complexes ou de nombreuses dépendances exige une productivité maximale. Découvrez ci-dessous des techniques avancées pour tirer le meilleur parti de vos paquets Maven dans GitLab et accélérer vos compilations.\n\n### Maîtriser la gestion des dépendances\n\n* Centralisez vos versions dans la section `\u003CdependencyManagement>` de votre fichier POM parent.\n\n  ```xml\n  \u003CdependencyManagement>\n    \u003Cdependencies>\n      \u003Cdependency>\n        \u003CgroupId>org.springframework.boot\u003C/groupId>\n        \u003CartifactId>spring-boot-dependencies\u003C/artifactId>\n        \u003Cversion>${spring-boot.version}\u003C/version>\n        \u003Ctype>pom\u003C/type>\n        \u003Cscope>import\u003C/scope>\n      \u003C/dependency>\n    \u003C/dependencies>\n  \u003C/dependencyManagement>\n  ```\n### Tirer parti des projets multi-modules\n\n  * Structurez votre projet avec un POM parent et plusieurs modules enfants :\n\n    ```\n    my-project/\n    ├── pom.xml\n    ├── module1/\n    │   └── pom.xml\n    ├── module2/\n    │   └── pom.xml\n    └── module3/\n        └── pom.xml\n    ```\n  * Utilisez le réacteur Maven pour compiler les modules dans un ordre optimal :\n\n    ```bash\n    mvn clean install\n    ```\n\n### Mettre en œuvre les compilations parallèles\n\n* Utilisez la fonctionnalité de compilation parallèle de Maven :\n\n  ```bash\n  mvn -T 4C clean install\n  ```\n\n### Optimiser votre pipeline CI/CD\n\n* Configurez la mise en cache dans `.gitlab-ci.yml` pour accélérer les compilations :\n\n  ```yaml\n  cache:\n    paths:\n      - .m2/repository\n\n  build:\n    script:\n      - mvn clean package -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository\n  ```\n* Implémentez des compilations incrémentielles :\n\n  ```yaml\n  build:\n    script:\n      - mvn clean install -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -am -amd -fae\n  ```\n\n### Utiliser la mise en cache des compilations\n\n* Intégrez l'extension Gradle Enterprise de Maven pour une gestion avancée de la mise en cache des compilations :\n\n  ```xml\n  \u003Cbuild>\n    \u003Cplugins>\n      \u003Cplugin>\n        \u003CgroupId>com.gradle\u003C/groupId>\n        \u003CartifactId>gradle-enterprise-maven-plugin\u003C/artifactId>\n        \u003Cversion>1.9\u003C/version>\n        \u003Cconfiguration>\n          \u003CgradleEnterprise>\n            \u003Cserver>https://ge.example.com\u003C/server>\n            \u003CallowUntrusted>false\u003C/allowUntrusted>\n          \u003C/gradleEnterprise>\n        \u003C/configuration>\n      \u003C/plugin>\n    \u003C/plugins>\n  \u003C/build>\n  ```\n\n## Présentation du programme bêta du registre virtuel Maven\n\nNous avons le plaisir d'annoncer le lancement du programme bêta de notre nouvelle fonctionnalité : le registre virtuel Maven. Cet ajout à l'écosystème GitLab transformera la gestion des dépôts Maven au sein de vos projets.\n\n### Fonctionnalités phares du registre virtuel Maven\n\n1. **Agrégation de dépôts :** combinez plusieurs dépôts Maven (internes et externes) en un seul dépôt virtuel.\n2. **Proxy intelligent et mise en cache :** accélérez les compilations grâce à la mise en cache des artefacts et au routage intelligent des requêtes.\n3. **Contrôle d'accès centralisé :** améliorez la sécurité en gérant l'accès à tous vos dépôts Maven depuis un seul et même endroit.\n\n### Utilisation du registre virtuel Maven\n\n1. **Configuration :** configurez l'authentification Maven dans votre fichier `settings.xml` :\n\n```\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nOptions d'authentification :\n\n- Jeton d'accès personnel : utilisez `Private-Token` comme nom et `${env.GITLAB_TOKEN}` comme valeur.\n\n- Token de déploiement de groupe : utilisez `Deploy-Token` comme nom et `${env.GITLAB_DEPLOY_TOKEN}` comme valeur.\n\n- Token d'accès de groupe : utilisez `Private-Token` comme nom et `${env.GITLAB_ACCESS_TOKEN}` comme valeur.\n\n- Token de job CI : utilisez `Job-Token` comme nom et `${CI_JOB_TOKEN}` comme valeur.\n\n- Configurez le registre virtuel dans votre fichier `pom.xml`.\n\nOption 1 : en tant que registre supplémentaire :\n\n```\n\u003Crepositories>\n  \u003Crepository>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n  \u003C/repository>\n\u003C/repositories>\n```\n\nOption 2 : en remplacement de Maven Central (dans votre fichier `settings.xml`) :\n\n```\n\u003Cmirrors>\n  \u003Cmirror>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Cname>GitLab virtual registry for Maven Central\u003C/name>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n    \u003CmirrorOf>central\u003C/mirrorOf>\n  \u003C/mirror>\n\u003C/mirrors>\n```\n\n2. **Utilisation :** désormais, toutes vos opérations Maven utiliseront ce dépôt virtuel.\n\n```\n# For personal access tokens\nexport GITLAB_TOKEN=your_personal_access_token\n\n# For group deploy tokens\nexport GITLAB_DEPLOY_TOKEN=your_deploy_token\n\n# For group access tokens\nexport GITLAB_ACCESS_TOKEN=your_access_token\n\n# Then run Maven commands normally\nmvn package\n\n```\n\n3. Avantages\n\n- Gestion simplifiée des dépendances\n- Temps de compilation réduits\n- Sécurité et conformité renforcées\n- Contrôle amélioré des dépendances tierces\n\n### Rejoignez le programme bêta\n\nNous recherchons activement des participants souhaitant tester notre version bêta :\n\n* Accédez en avant-première à la fonctionnalité de registre virtuel Maven.\n* Transmettez directement vos retours à notre équipe de développement.\n* Contribuez activement à façonner l'avenir de la gestion des paquets Maven dans GitLab.\n* Participez à des webinaires et sessions de questions-réponses exclusifs animés par notre équipe produit.\n\n> Pour rejoindre le programme bêta ou en savoir plus sur le registre virtuel Maven, consultez notre page dédiée au [programme bêta du registre virtuel Maven de GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/498139) (**Remarque :** lien provisoire).\n\n## Résumé\n\nChez GitLab, nous avons à cœur de proposer des outils à la fois sécurisés, performants et évolutifs pour accompagner votre développement logiciel. Le registre virtuel Maven illustre notre volonté constante d'innover pour répondre aux besoins croissants des développeurs et ingénieurs de plateforme.\n\nEn appliquant les mesures de sécurité et les techniques d'optimisation abordées dans cet article, et en tirant parti des futures fonctionnalités telles que le registre virtuel Maven, vous renforcerez l'efficacité de votre workflow Maven dans GitLab.\n\nNous sommes impatients de voir comment ces nouvelles fonctionnalités de gestion des paquets dans GitLab contribueront à perfectionner vos processus de développement. Restez à l'écoute et bon codage !",[1153,1154,1155,1156,816],"sécurité","plateforme DevSecOps","fonctionnalités","produit",{"slug":1158,"featured":91,"template":806},"tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"content":1160,"config":1169},{"title":1161,"description":1162,"authors":1163,"heroImage":1165,"date":1166,"body":1167,"category":781,"tags":1168},"Intégrez la conformité à vos workflows DevSecOps avec GitLab","Découvrez comment les frameworks de conformité personnalisés de GitLab transforment vos exigences réglementaires en composants intégrés et automatisés dans vos workflows.",[1164],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","2025-04-30","La conformité n'est plus une formalité, mais un vecteur stratégique : elle aide à maîtriser les risques opérationnels, renforce la confiance des clients et améliore la performance globale. Pourtant, trouver l'équilibre entre exigences de conformité et vélocité peut s'avérer particulièrement complexe pour les équipes de développement logiciel. Les [frameworks de conformité personnalisés](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) de GitLab apportent une réponse concrète à cette problématique en intégrant la vérification de la conformité directement dans vos workflows de développement. \n\nDécouvrez dans cet article tout ce que vous devez savoir sur les frameworks de conformité personnalisés de GitLab et comment les utiliser de façon optimale.\n\n## Qu’est-ce qu’un framework de conformité personnalisé ?\n\nLes frameworks de conformité personnalisés de GitLab vous permettent de définir, d'appliquer et de faire respecter vos propres normes de conformité directement dans votre instance GitLab. GitLab propose déjà des fonctionnalités de conformité « prêtes à l’emploi », mais chaque entreprise a ses propres obligations. Avec les frameworks personnalisés, vous pouvez donc définir vos propres stratégies de conformité en fonction de réglementations spécifiques, de vos politiques internes ou des normes de votre secteur.\n\nCes frameworks offrent les principaux avantages suivants : \n\n* Réduction significative du suivi manuel  \n* Accélération de la préparation aux audits  \n* Intégration native des contrôles de conformité\n\n![Capture d'écran du centre de conformité avec les frameworks répertoriés](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nGitLab propose à ce jour plus de 50 contrôles préconfigurés, modifiables, que vous pouvez activer selon vos besoins. Ils couvrent un large éventail de réglementations, comme la loi HIPAA dans le domaine de la santé, le RGPD pour la protection des données, la [norme SOC 2](https://about.gitlab.com/fr-fr/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam/ \"Norme SOC 2\") relative aux prestataires de services et bien d'autres réglementations propres à des secteurs d'activité spécifiques. En voici quelques exemples :\n\n* Séparation des tâches : au moins deux approbateurs requis, y compris l'auteur de la merge request  \n* Scanners de sécurité : scans [SAST](https://docs.gitlab.com/user/application_security/sast/) et [analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) exécutés automatiquement  \n* Authentification/autorisation : visibilité du projet définie sur privé et authentification unique (SSO) activée  \n* Configuration de l'application : vérification obligatoire des statuts de conformité et utilisation de fichiers de configuration Terraform exigée\n\nEn outre, vous pouvez étendre les capacités de conformité de GitLab en configurant vos propres contrôles sur des environnements externes à l'aide de l'API GitLab.\n\n## Comment créer un framework de conformité personnalisé dans GitLab ?\n\nMaintenant que nous avons clarifié l’importance des frameworks de conformité personnalisés, voyons comment les mettre en œuvre dans votre environnement GitLab, en utilisant l'application de démonstration reprise dans la vidéo ci-dessous. \n\n**Remarque :** un abonnement [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"Qu'est-ce que GitLab Ultimate ?\") est requis.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Étape 1 : définissez vos exigences de conformité**\n\nAvant de créer votre framework de conformité personnalisé, vous devez définir clairement vos exigences en la matière :\n\n1. **Identifiez les réglementations applicables :** déterminez les obligations légales et normes qui s'appliquent à votre entreprise (par exemple, le RGPD, la norme PCI DSS ou la loi HIPAA). \n2. **Associez les exigences à des contrôles :** décomposez chaque exigence réglementaire identifiée en contrôles spécifiques et exploitables.  \n3. **Hiérarchisez les exigences :** concentrez vos efforts sur les domaines à haut risque et les exigences à fort impact.\n\n**Étape 2 : créez votre framework de conformité personnalisé dans GitLab**\n\nVoici comment procéder :\n\n1. Accédez à la section **Sécurisation > Centre de conformité** de votre groupe GitLab.  \n2. Cliquez sur le bouton **Nouveau framework**.  \n3. Sélectionnez **Créer un framework vide**.\n\n![Écran de création d'un framework de conformité personnalisé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Renseignez son nom, sa description et choisissez sa couleur.\n\n![Écran Nouveau framework de conformité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Ajoutez des exigences :\\\n   a. Accédez à l'onglet **Exigences**.\n\n   b. Cliquez sur le bouton **Nouvelle exigence**.\n\n   c. Fournissez un nom et une description.\\\n   d. Dans la section **Contrôles**, sélectionnez **Choisir un contrôle GitLab**.\\\n   e. Sélectionnez un contrôle dans la liste (par exemple, au moins deux approbations, l'exécution de scans SAST).\\\n   f. Cliquez ensuite sur le bouton **Créer une exigence**.\n\n![Bouton Créer une exigence](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Cliquez sur le bouton **Créer un framework**.\n\nUne fois créé, ce framework pourra être appliqué à vos projets selon les paramètres définis. Par ailleurs, GitLab permet également d'importer des frameworks de conformité au format JSON, selon le schéma prévu.\n\n**Étape 3 : appliquez le framework à vos projets**\n\nUne fois votre framework de conformité créé, suivez les étapes ci-dessous pour l’appliquer à un ou plusieurs projets :\n\n1. Accédez au **Centre de conformité** de GitLab, puis sélectionnez l'onglet **Projets**.  \n2. Utilisez la barre de recherche pour **Rechercher** ou **Filtrer** les projets concernés.  \n3. Sélectionnez le ou les projets dans la liste.  \n4. Cliquez sur le bouton **Choisir une action groupée**.  \n5. Sélectionnez **Appliquer les frameworks aux projets sélectionnés**.  \n6. Cliquez sur le bouton **Sélectionner des frameworks**.  \n7. Sélectionnez le ou les frameworks de votre choix dans la liste.  \n8. Cliquez sur le bouton **Appliquer**.\n\n![Écran du Centre de conformité avec la liste déroulante affichant le framework SOC 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nUne fois cette opération effectuée, le framework sélectionné est associé aux projets choisis. Les exigences définies sont alors visibles et peuvent être vérifiées directement dans l'interface GitLab.\n\n**Étape 4 : surveillez et générez des rapports de conformité**\n\nUne fois votre framework de conformité en place, GitLab vous offre un suivi continu et centralisé dans le **Centre de conformité** :\n\n1. Suivez le statut de conformité de vos projets, y compris les détails sur les contrôles appliqués, ainsi que des correctifs suggérés pour les contrôles ayant échoué.\n2. Générez des **rapports de conformité** pour les audits et l'examen par les parties prenantes.  \n3. Configurez des **alertes de conformité** pour informer les parties prenantes des problèmes de conformité potentiels. \n4. Consultez les **événements d'audit** pour une vue d'ensemble des mesures prises concernant les paramètres de conformité.\n\n![Écran du Centre de conformité affichant le framework de test SOC 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Exemple : mise en œuvre d'un framework de conformité SOC 2\n\nLe SOC 2 (System and Organization Controls 2), développée par l'American Institute of Certified Public Accountants, est une norme d'audit rigoureuse qui évalue les contrôles mis en œuvre par les prestataires de services en matière de sécurité, de disponibilité, d'intégrité du traitement des données, de confidentialité et de protection des données personnelles. Pour en savoir plus, consultez le [guide sur le respect des exigences de sécurité SOC 2 avec GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/).\n\nVoici un exemple concret d'implémentation d'un framework de conformité personnalisé GitLab dont l'objectif est de vérifier la conformité à la norme de sécurité SOC 2 à l’aide des contrôles GitLab préconfigurés suivants :\n\n* Contrôles contre les accès non autorisés  \n* Procédures d'identification et d'atténuation des risques  \n* Systèmes de détection et de gestion des incidents de sécurité\n\n**Avertissement :** il ne s'agit là que d'un exemple qui illustre certains des contrôles possibles pour vérifier l'adhésion à la norme SOC 2. Avant toute mise en production, validez votre configuration avec votre équipe sécurité ou conformité.\n\nCe framework se présentera comme suit :\n\n* **Nom :** Exigences de sécurité SOC 2  \n* **Description :** Ajout des exigences de sécurité pour la conformité au framework SOC 2  \n* **Exigences :**  \n\n  * **Contrôles contre les accès non autorisés**  \n\n    * Authentification SSO activée  \n    * Portée des tokens pour les jobs CI/CD activée \n    * Authentification multifacteur requise au niveau de l'entreprise\n* **Procédures d'identification et d'atténuation des risques**   \n\n  * Au moins deux approbations requises avant tout merge \n  * Merge request approuvée par l'auteur      \n  * Merge request approuvée par les validateurs \n  * Branche par défaut protégée    \n* **Systèmes de détection et de gestion des incidents de sécurité**  \n\n  * Analyse des dépendances activée  \n  * SAST activé \n  * DAST activé\n\nLorsqu'il est appliqué à vos projets, ce framework vous permet de surveiller toute erreur de conformité et d'identifier les corrections envisageables. Notez que vous pouvez associer plusieurs frameworks de conformité à vos projets, par exemple, pour couvrir les exigences d'intégrité des processus SOC 2.\n\n## Comment définir des stratégies de sécurité en accord avec les exigences de conformité ?\n\nBien que cet aspect ne soit pas obligatoire, il est fortement recommandé d'appliquer des stratégies de sécurité aux projets associés à un framework de conformité personnalisé. Cette approche garantit que les exigences de conformité critiques sont correctement appliquées de manière automatisée et cohérente dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Par exemple, si votre framework de conformité personnalisé impose que des scans de sécurité soient exécutés sur chaque pipeline, une stratégie de sécurité peut en forcer l’exécution.\n\nGitLab fournit différentes stratégies de sécurité pour répondre aux différents objectifs de sécurité et de conformité :\n\n* [Stratégie d'exécution des scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) : impose l'exécution de scans de sécurité dans les pipelines ou selon un calendrier précis.  \n* [Politique d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) : définit des paramètres et règles d'approbation au niveau du projet en fonction des résultats des scans.  \n* [Stratégie d'exécution de pipeline](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) : force l'exécution de jobs CI/CD spécifiques dans les pipelines. \n* [Stratégie de gestion des vulnérabilités](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/) : corrige automatiquement les vulnérabilités afin qu’elles soient supprimées de la branche par défaut.\n\nSi votre framework de conformité personnalisé exige l'exécution de scans SAST, voici comment créer une stratégie de sécurité pour en garantir l’exécution automatique :\n\n1. Accédez à un projet qui dispose d'un framework de conformité personnalisé incluant les **scans SAST**. \n2. Dans la barre latérale du projet, sélectionnez **Sécurisation > Politiques**.\n3. Cliquez sur le bouton **Nouvelle stratégie**.  \n4. Dans la section **Stratégie d'exécution des scans**, cliquez sur le bouton **Sélectionner une stratégie**. \n5. Renseignez le **Nom** et la **Description**. \n6. Dans la section **Actions**, sélectionnez **SAST** comme type de scan à exécuter.\n\n![Écran des actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Dans la section **Conditions**, sélectionnez tous les pipelines, quelle que soit la branche.\n\n![Écran des conditions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Cliquez sur le bouton **Configurer avec une merge request**.  \n9. Une merge request est alors créée dans un projet distinct dédié aux stratégies de sécurité appliquées à ce projet.\n10. Cliquez sur le bouton **Fusionner**.\n\nDésormais, les scans SAST s'exécuteront automatiquement sur toutes les branches du projet afin de garantir le respect continu des exigences de conformité. Nous vous conseillons de parcourir les autres types de stratégies de sécurité pour identifier celles qui répondent le mieux à vos besoins.\n\n## 5 bonnes pratiques pour des frameworks de conformité efficaces\n\nPour tirer pleinement parti des frameworks de conformité personnalisés de GitLab, nous vous conseillons de suivre les principes suivants :\n\n1. **Avancez pas à pas :** commencez par une seule réglementation ou norme critique avant d'aller plus loin.  \n2. **Impliquez les principales parties prenantes :** incluez les équipes de conformité, de sécurité et de développement dans la création du framework.  \n3. **Automatisez dans la mesure du possible :** utilisez GitLab CI/CD pour automatiser les contrôles de conformité.  \n4. **Documentez minutieusement votre approche :** conservez une documentation claire du lien entre chaque exigence réglementaire et les contrôles GitLab mis en place.  \n5. **Révisez régulièrement vos frameworks :** mettez à jour vos frameworks à mesure que les réglementations évoluent ou que de nouvelles exigences sont nécessaires.\n\n## Lancez-vous dès aujourd'hui\n\nLes frameworks de conformité personnalisés de GitLab marquent une avancée majeure pour intégrer la conformité directement dans le workflow de développement DevSecOps. En les adoptant, vous réduisez les frais liés à la conformité, améliorez votre gestion des risques et accélérez vos cycles de développement logiciel, tout en garantissant la meilleure conformité possible aux exigences réglementaires.\n\nGrâce à cette approche, vos équipes bénéficient à la fois de la flexibilité dont elles ont besoin pour répondre aux exigences réglementaires et de la structure indispensable pour garantir des pratiques de conformité cohérentes dans l'ensemble de l'entreprise.\n\nDans un contexte réglementaire de plus en plus exigeant, des outils comme les frameworks de conformité personnalisés de GitLab sont essentiels pour traiter la conformité comme un processus continu, sans compromettre la vélocité de développement.\n\n> Lancez-vous dès aujourd'hui avec un [essai gratuit de 60 jours de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n\nPour en savoir plus, consultez nos ressources connexes :\n\n* [Documentation sur les frameworks de conformité personnalisés](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\n* [Epic sur les frameworks de conformité personnalisés](https://gitlab.com/groups/gitlab-org/-/epics/13295)\n* [Documentation sur les stratégies de sécurité](https://docs.gitlab.com/user/application_security/policies/)\n* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)",[781,802,800,801,769],{"slug":1170,"featured":91,"template":806},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"content":1172,"config":1175},{"title":1096,"description":1097,"authors":1173,"heroImage":1100,"date":1101,"body":1102,"category":769,"tags":1174},[1099],[718,769,801],{"featured":91,"template":806,"slug":1105},[1177,1182,1187],{"content":1178,"config":1181},{"heroImage":1134,"body":1135,"authors":1179,"updatedDate":1139,"date":1139,"title":1140,"tags":1180,"description":1142,"category":781},[1137,1138],[781,769,801],{"featured":6,"template":806,"slug":1144},{"content":1183,"config":1186},{"title":973,"description":974,"date":975,"body":976,"heroImage":977,"authors":1184,"category":734,"tags":1185},[979],[269,769,746],{"featured":6,"template":806,"slug":982},{"content":1188,"config":1191},{"title":1147,"description":1148,"authors":1189,"heroImage":1150,"date":975,"body":1151,"category":781,"tags":1190},[878],[1153,1154,1155,1156,816],{"slug":1158,"featured":91,"template":806},[1193,1198,1203],{"content":1194,"config":1197},{"title":1120,"description":1121,"authors":1195,"heroImage":1124,"date":1125,"body":1126,"category":769,"tags":1196},[1123],[898],{"featured":6,"template":806,"slug":1129},{"content":1199,"config":1202},{"description":1058,"title":1059,"category":758,"tags":1200,"heroImage":1061,"date":1062,"body":1063,"authors":1201},[898,269,769],[1065,1066],{"featured":6,"template":806,"slug":1068},{"content":1204,"config":1207},{"tags":1205,"category":686,"date":838,"heroImage":839,"authors":1206,"description":842,"title":843,"body":844},[837,769,801,746],[841],{"featured":91,"template":806,"slug":846},1754424534136]