[{"data":1,"prerenderedAt":1203},["ShallowReactive",2],{"/fr-fr/blog":3,"navigation-fr-fr":21,"banner-fr-fr":439,"footer-fr-fr":452,"footer-source-/fr-fr/blog/":663,"blogCategories-fr-fr":667,"relatedBlogPosts-fr-fr":789,"maineFeaturedPost-fr-fr":1168,"recentFeaturedPosts-fr-fr":1173,"recentPosts-fr-fr":1187},{"_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":435,"_type":16,"title":436,"_source":17,"_file":437,"_stem":438,"_extension":20},"/shared/fr-fr/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":376,"minimal":412,"duo":426},{"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,187,192,297,357],{"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":169},"Produit",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/fr-fr/solutions/",[99,125,147],{"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/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Application Security Testing",{"href":130,"dataGaName":137,"dataGaLocation":28},"Application security testing",{"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},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":28},"/fr-fr/solutions/software-compliance/",{"title":148,"link":149,"items":154},"Mesures",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":28},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Visibilité et mesures",{"href":152,"dataGaLocation":28,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Gestion de la chaîne de valeur",{"href":162,"dataGaLocation":28,"dataGaName":163},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Données d'analyse et informations clés",{"href":167,"dataGaLocation":28,"dataGaName":168},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab pour",[172,177,182],{"text":173,"config":174},"Entreprises",{"href":175,"dataGaLocation":28,"dataGaName":176},"/fr-fr/enterprise/","enterprise",{"text":178,"config":179},"PME",{"href":180,"dataGaLocation":28,"dataGaName":181},"/fr-fr/small-business/","small business",{"text":183,"config":184},"Secteur public",{"href":185,"dataGaLocation":28,"dataGaName":186},"/fr-fr/solutions/public-sector/","public sector",{"text":188,"config":189},"Tarifs",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/fr-fr/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":284},"Ressources",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Afficher toutes les ressources",{"href":199,"dataGaName":195,"dataGaLocation":28},"/fr-fr/resources/",[201,234,256],{"title":202,"items":203},"Premiers pas",[204,209,214,219,224,229],{"text":205,"config":206},"Installation",{"href":207,"dataGaName":208,"dataGaLocation":28},"/fr-fr/install/","install",{"text":210,"config":211},"Guides de démarrage rapide",{"href":212,"dataGaName":213,"dataGaLocation":28},"/fr-fr/get-started/","quick setup checklists",{"text":215,"config":216},"Apprentissage",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Documentation sur le produit",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Vidéos sur les bonnes pratiques",{"href":227,"dataGaName":228,"dataGaLocation":28},"/fr-fr/getting-started-videos/","best practice videos",{"text":230,"config":231},"Intégrations",{"href":232,"dataGaName":233,"dataGaLocation":28},"/fr-fr/integrations/","integrations",{"title":235,"items":236},"Découvrir",[237,242,246,251],{"text":238,"config":239},"Histoires de succès client",{"href":240,"dataGaName":241,"dataGaLocation":28},"/fr-fr/customers/","customer success stories",{"text":9,"config":243},{"href":244,"dataGaName":245,"dataGaLocation":28},"/fr-fr/blog/","blog",{"text":247,"config":248},"Travail à distance",{"href":249,"dataGaName":250,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":252,"config":253},"TeamOps",{"href":254,"dataGaName":255,"dataGaLocation":28},"/fr-fr/teamops/","teamops",{"title":257,"items":258},"Connecter",[259,264,269,274,279],{"text":260,"config":261},"Services GitLab",{"href":262,"dataGaName":263,"dataGaLocation":28},"/fr-fr/services/","services",{"text":265,"config":266},"Communauté",{"href":267,"dataGaName":268,"dataGaLocation":28},"/community/","community",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Événements",{"href":277,"dataGaName":278,"dataGaLocation":28},"/events/","events",{"text":280,"config":281},"Partenaires",{"href":282,"dataGaName":283,"dataGaLocation":28},"/fr-fr/partners/","partners",{"backgroundColor":285,"textColor":286,"text":287,"image":288,"link":292},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":289,"config":290},"carte promo The Source",{"src":291},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":293,"config":294},"Lire les articles les plus récents",{"href":295,"dataGaName":296,"dataGaLocation":28},"/fr-fr/the-source/","the source",{"text":298,"config":299,"lists":301},"Société",{"dataNavLevelOne":300},"company",[302],{"items":303},[304,309,315,317,322,327,332,337,342,347,352],{"text":305,"config":306},"À propos",{"href":307,"dataGaName":308,"dataGaLocation":28},"/fr-fr/company/","about",{"text":310,"config":311,"footerGa":314},"Emplois",{"href":312,"dataGaName":313,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":313},{"text":275,"config":316},{"href":277,"dataGaName":278,"dataGaLocation":28},{"text":318,"config":319},"Leadership",{"href":320,"dataGaName":321,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":323,"config":324},"Équipe",{"href":325,"dataGaName":326,"dataGaLocation":28},"/company/team/","team",{"text":328,"config":329},"Manuel",{"href":330,"dataGaName":331,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":333,"config":334},"Relations avec les investisseurs",{"href":335,"dataGaName":336,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":338,"config":339},"Centre de confiance",{"href":340,"dataGaName":341,"dataGaLocation":28},"/fr-fr/security/","trust center",{"text":343,"config":344},"Centre pour la transparence de l'IA",{"href":345,"dataGaName":346,"dataGaLocation":28},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":348,"config":349},"Newsletter",{"href":350,"dataGaName":351,"dataGaLocation":28},"/company/contact/","newsletter",{"text":353,"config":354},"Presse",{"href":355,"dataGaName":356,"dataGaLocation":28},"/press/","press",{"text":358,"config":359,"lists":360},"Nous contacter",{"dataNavLevelOne":300},[361],{"items":362},[363,366,371],{"text":35,"config":364},{"href":37,"dataGaName":365,"dataGaLocation":28},"talk to sales",{"text":367,"config":368},"Aide",{"href":369,"dataGaName":370,"dataGaLocation":28},"/support/","get help",{"text":372,"config":373},"Portail clients GitLab",{"href":374,"dataGaName":375,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"Fermer",{"text":379,"link":380},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":381,"config":382},"gitlab.com",{"href":42,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"Suggestions",[388,391,396,398,403,408],{"text":57,"config":389},{"href":62,"dataGaName":390,"dataGaLocation":384},"GitLab Duo (AI)",{"text":392,"config":393},"Suggestions de code (IA)",{"href":394,"dataGaName":395,"dataGaLocation":384},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":397},{"href":111,"dataGaName":109,"dataGaLocation":384},{"text":399,"config":400},"GitLab sur AWS",{"href":401,"dataGaName":402,"dataGaLocation":384},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":404,"config":405},"GitLab sur Google Cloud ",{"href":406,"dataGaName":407,"dataGaLocation":384},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":409,"config":410},"Pourquoi utiliser GitLab ?",{"href":70,"dataGaName":411,"dataGaLocation":384},"Why GitLab?",{"freeTrial":413,"mobileIcon":418,"desktopIcon":423},{"text":414,"config":415},"Commencer votre essai gratuit",{"href":416,"dataGaName":33,"dataGaLocation":417},"https://gitlab.com/-/trials/new/","nav",{"altText":419,"config":420},"Icône GitLab",{"src":421,"dataGaName":422,"dataGaLocation":417},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":419,"config":424},{"src":425,"dataGaName":422,"dataGaLocation":417},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"En savoir plus sur GitLab Duo",{"href":62,"dataGaName":430,"dataGaLocation":417},"gitlab duo",{"altText":419,"config":432},{"src":421,"dataGaName":422,"dataGaLocation":417},{"altText":419,"config":434},{"src":425,"dataGaName":422,"dataGaLocation":417},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":440,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":441,"titleMobile":441,"button":442,"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":443,"config":444},"Essayer la version bêta",{"href":445,"dataGaName":446,"dataGaLocation":28},"/fr-fr/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":659,"_type":16,"title":660,"_source":17,"_file":661,"_stem":662,"_extension":20},"/shared/fr-fr/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":650},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":457,"config":458},"Afficher le code source de la page",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Modifier cette page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Veuillez contribuer",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,587,621],{"title":46,"links":479,"subMenu":484},[480],{"text":481,"config":482},"Plateforme DevSecOps",{"href":55,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":188,"links":486},[487,491,496],{"text":488,"config":489},"Voir les forfaits",{"href":190,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Pourquoi choisir GitLab Premium ?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/fr-fr/pricing/premium/","why premium",{"text":497,"config":498},"Pourquoi choisir GitLab Ultimate ?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/fr-fr/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"Transformation digitale",{"href":507,"dataGaName":508,"dataGaLocation":461},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"Sécurité et conformité",{"href":130,"dataGaName":137,"dataGaLocation":461},{"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":160,"config":532},{"href":162,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/fr-fr/solutions/gitops/","gitops",{"text":173,"config":540},{"href":175,"dataGaName":176,"dataGaLocation":461},{"text":178,"config":542},{"href":180,"dataGaName":181,"dataGaLocation":461},{"text":183,"config":544},{"href":185,"dataGaName":186,"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":193,"links":556},[557,559,561,563,566,568,571,573,575,577,579,581,583,585],{"text":205,"config":558},{"href":207,"dataGaName":208,"dataGaLocation":461},{"text":210,"config":560},{"href":212,"dataGaName":213,"dataGaLocation":461},{"text":215,"config":562},{"href":217,"dataGaName":218,"dataGaLocation":461},{"text":220,"config":564},{"href":222,"dataGaName":565,"dataGaLocation":461},"docs",{"text":9,"config":567},{"href":244,"dataGaName":245},{"text":569,"config":570},"Histoires de réussite client",{"href":240,"dataGaLocation":461},{"text":238,"config":572},{"href":240,"dataGaName":241,"dataGaLocation":461},{"text":247,"config":574},{"href":249,"dataGaName":250,"dataGaLocation":461},{"text":260,"config":576},{"href":262,"dataGaName":263,"dataGaLocation":461},{"text":252,"config":578},{"href":254,"dataGaName":255,"dataGaLocation":461},{"text":265,"config":580},{"href":267,"dataGaName":268,"dataGaLocation":461},{"text":270,"config":582},{"href":272,"dataGaName":273,"dataGaLocation":461},{"text":275,"config":584},{"href":277,"dataGaName":278,"dataGaLocation":461},{"text":280,"config":586},{"href":282,"dataGaName":283,"dataGaLocation":461},{"title":298,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":305,"config":590},{"href":307,"dataGaName":300,"dataGaLocation":461},{"text":310,"config":592},{"href":312,"dataGaName":313,"dataGaLocation":461},{"text":318,"config":594},{"href":320,"dataGaName":321,"dataGaLocation":461},{"text":323,"config":596},{"href":325,"dataGaName":326,"dataGaLocation":461},{"text":328,"config":598},{"href":330,"dataGaName":331,"dataGaLocation":461},{"text":333,"config":600},{"href":335,"dataGaName":336,"dataGaLocation":461},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":461},"/sustainability/",{"text":606,"config":607},"Diversité, inclusion et appartenance (DIB)",{"href":608,"dataGaName":609,"dataGaLocation":461},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":338,"config":611},{"href":340,"dataGaName":341,"dataGaLocation":461},{"text":348,"config":613},{"href":350,"dataGaName":351,"dataGaLocation":461},{"text":353,"config":615},{"href":355,"dataGaName":356,"dataGaLocation":461},{"text":617,"config":618},"Déclaration de transparence sur l'esclavage moderne",{"href":619,"dataGaName":620,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":358,"links":622},[623,626,628,630,635,640,645],{"text":624,"config":625},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":461},{"text":367,"config":627},{"href":369,"dataGaName":370,"dataGaLocation":461},{"text":372,"config":629},{"href":374,"dataGaName":375,"dataGaLocation":461},{"text":631,"config":632},"Statut",{"href":633,"dataGaName":634,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":636,"config":637},"Conditions d'utilisation",{"href":638,"dataGaName":639},"/terms/","terms of use",{"text":641,"config":642},"Déclaration de confidentialité",{"href":643,"dataGaName":644,"dataGaLocation":461},"/fr-fr/privacy/","privacy statement",{"text":646,"config":647},"Préférences en matière de cookies",{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,657],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":461},{"text":655,"config":656},"Politique de confidentialité",{"href":643,"dataGaName":644,"dataGaLocation":461},{"text":646,"config":658},{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":665,"config":666,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},{"title":9,"description":10},{"title":12},{"template":14},[668,682,694,706,718,730,742,754,766,777],{"_path":669,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":671,"content":674,"config":675,"_id":678,"_type":16,"title":679,"_source":17,"_file":680,"_stem":681,"_extension":20},"/fr-fr/blog/categories/agile-planning","categories",{"title":672,"description":673},"Planification Agile","Browse articles related to Planification Agile on the GitLab Blog",{"name":672},{"template":676,"slug":677,"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":683,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":684,"content":687,"config":688,"_id":690,"_type":16,"title":691,"_source":17,"_file":692,"_stem":693,"_extension":20},"/fr-fr/blog/categories/ai-ml",{"title":685,"description":686},"IA/ML","Browse articles related to IA/ML on the GitLab Blog",{"name":685},{"template":676,"slug":689,"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":695,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":696,"content":699,"config":700,"_id":702,"_type":16,"title":703,"_source":17,"_file":704,"_stem":705,"_extension":20},"/fr-fr/blog/categories/bulletin-board",{"title":697,"description":698},"Annonces","Browse articles related to Annonces on the GitLab Blog",{"name":697},{"template":676,"slug":701,"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":707,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":708,"content":711,"config":712,"_id":714,"_type":16,"title":715,"_source":17,"_file":716,"_stem":717,"_extension":20},"/fr-fr/blog/categories/customer-stories",{"title":709,"description":710},"Étude de cas","Browse articles related to Étude de cas on the GitLab Blog",{"name":709},{"template":676,"slug":713,"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":719,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":720,"content":723,"config":724,"_id":726,"_type":16,"title":727,"_source":17,"_file":728,"_stem":729,"_extension":20},"/fr-fr/blog/categories/devsecops",{"title":721,"description":722},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":721},{"template":676,"slug":725,"hide":6},"devsecops","content:fr-fr:blog:categories:devsecops.yml","Devsecops","fr-fr/blog/categories/devsecops.yml","fr-fr/blog/categories/devsecops",{"_path":731,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":732,"content":735,"config":736,"_id":738,"_type":16,"title":739,"_source":17,"_file":740,"_stem":741,"_extension":20},"/fr-fr/blog/categories/engineering",{"title":733,"description":734},"Ingénierie","Browse articles related to Ingénierie on the GitLab Blog",{"name":733},{"template":676,"slug":737,"hide":6},"engineering","content:fr-fr:blog:categories:engineering.yml","Engineering","fr-fr/blog/categories/engineering.yml","fr-fr/blog/categories/engineering",{"_path":743,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":744,"content":747,"config":748,"_id":750,"_type":16,"title":751,"_source":17,"_file":752,"_stem":753,"_extension":20},"/fr-fr/blog/categories/news",{"title":745,"description":746},"Actualités","Browse articles related to Actualités on the GitLab Blog",{"name":745},{"template":676,"slug":749,"hide":6},"news","content:fr-fr:blog:categories:news.yml","News","fr-fr/blog/categories/news.yml","fr-fr/blog/categories/news",{"_path":755,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":756,"content":759,"config":760,"_id":762,"_type":16,"title":763,"_source":17,"_file":764,"_stem":765,"_extension":20},"/fr-fr/blog/categories/open-source",{"title":757,"description":758},"Open source","Browse articles related to Open source on the GitLab Blog",{"name":757},{"template":676,"slug":761,"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":767,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":768,"content":770,"config":771,"_id":773,"_type":16,"title":774,"_source":17,"_file":775,"_stem":776,"_extension":20},"/fr-fr/blog/categories/product",{"title":90,"description":769},"Browse articles related to Produit on the GitLab Blog",{"name":90},{"template":676,"slug":772,"hide":6},"product","content:fr-fr:blog:categories:product.yml","Product","fr-fr/blog/categories/product.yml","fr-fr/blog/categories/product",{"_path":778,"_dir":670,"_draft":6,"_partial":6,"_locale":7,"seo":779,"content":782,"config":783,"_id":785,"_type":16,"title":786,"_source":17,"_file":787,"_stem":788,"_extension":20},"/fr-fr/blog/categories/security",{"title":780,"description":781},"Sécurité","Browse articles related to Sécurité on the GitLab Blog",{"name":780},{"template":676,"slug":784,"hide":6},"security","content:fr-fr:blog:categories:security.yml","Security","fr-fr/blog/categories/security.yml","fr-fr/blog/categories/security",[790,837,876,891,937,978,1015,1054,1093,1130],{"category":672,"slug":677,"posts":791},[792,810,825],{"content":793,"config":807},{"body":794,"title":795,"description":796,"authors":797,"heroImage":801,"date":802,"category":677,"tags":803},"Vous arrive-t-il de basculer entre plusieurs onglets dans GitLab simplement pour suivre ce qui se passe dans votre projet ? Peut-être consultez-vous un ticket, puis passez à une merge request, et enfin à un epic pour avoir une vue d'ensemble. Sans vous en rendre compte, votre navigateur déborde d'onglets et vous avez perdu le fil.\n\n\n\nSi cette situation vous semble familière, vous n'êtes certainement pas seul. De nombreuses équipes perdent du temps et de l'énergie à naviguer entre différents éléments dans leur logiciel de gestion de projet, alors qu'elles essaient simplement de suivre leur travail.\n\n\n\nC'est justement pour répondre à ce problème que nous avons créé les [vues intégrées](https://docs.gitlab.com/user/glql/#embedded-views), alimentées par [GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/). [Disponible dans la version 18.3](https://about.gitlab.com/fr-fr/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/), cette fonctionnalité fournit un aperçu des informations pertinentes en temps réel là où vous travaillez déjà dans GitLab. Fini le changement de contexte permanent et les rapports obsolètes : vous disposez des informations dont vous avez besoin, au moment précis où vous en avez besoin.\n\n\n\n## Pourquoi utiliser les vues intégrées ?\n\n\n\nLes vues intégrées représentent bien plus qu'une nouvelle fonctionnalité : elles constituent un changement fondamental dans la façon dont les équipes comprennent et suivent leur travail au sein de GitLab. Avec les vues intégrées, les équipes ne changent pas de contexte et accèdent aux informations dont elles ont besoin en temps réel. Ainsi, elles profitent d'une vision commune sans jamais quitter leur workflow actuel et renforcent leur collaboration. Grâce à un suivi du travail facilité et sans effort, les équipes peuvent se concentrer sur l'essentiel.\n\n\n\n## Des données en temps réel là où vous en avez besoin\n\n\n\nLes vues intégrées permettent d'insérer des requêtes GLQL dynamiques dans des blocs de code Markdown à travers des pages [wiki](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/), des epics, des tickets et des merge requests. \n\n\n\nElles offrent de nombreux avantages :\n\n\n\n### Mises à jour en continu\n\n\n\nLes requêtes GLQL sont dynamiques et extraient des données actualisées à chaque chargement de page. Ainsi, vos vues intégrées reflètent toujours l'état actuel de votre travail, et non le moment où vous avez ajouté cette vue. Lorsque des modifications sont apportées aux tickets, aux merge requests ou aux jalons, la page s'actualise et affiche ces mises à jour dans votre vue intégrée.\n\n\n\n### Contexte\n\n\n\nUtilisez des fonctions comme `currentUser()` et `today()` pour que vos requêtes s'appliquent à un contexte spécifique. Vos vues intégrées s'adaptent automatiquement pour afficher les informations pertinentes en fonction de la personne qui les consulte et offrent ainsi une expérience personnalisée sans configuration manuelle.\n\n\n\n### Filtrage puissant\n\n\n\nVous avez à disposition des filtres comme l'assigné, l'auteur, le label, le jalon, l'indicateur de progression, la date de création et plus encore. Il vous suffit d'utiliser des expressions logiques pour obtenir exactement les données souhaitées. Nous prenons en charge plus de 30 champs de filtres depuis la version 18.3.\n\n\n\n### Affichage personnalisable\n\n\n\nVous pouvez afficher vos données sous forme de tableau, de liste ou de liste numérotée. Choisissez les champs à afficher, définissez une limite du nombre d'éléments et indiquez l'ordre de tri pour profiter d'un affichage ciblé et exploitable.\n\n\n\n### Disponibilité\n\n\n\nVous pouvez utiliser les vues intégrées dans les wikis de groupe et de projet, les descriptions d'epics et de tickets, les merge requests et les commentaires. GLQL est disponible sur la version gratuite de GitLab, GitLab Premium, GitLab Ultimate, GitLab.com, GitLab Self-Managed et GitLab Dedicated. Certaines fonctionnalités, telles que l'affichage des epics, du statut, des champs personnalisés, des itérations et des poids, sont disponibles uniquement pour les utilisateurs de GitLab Premium et GitLab Ultimate. L'affichage de l'indicateur de progression est disponible uniquement dans GitLab Ultimate.\n\n\n\n## Découvrez les vues intégrées en action\n\n\n\nLa syntaxe du code source d'une vue intégrée est un sur-ensemble de YAML qui comprend :\n\n\n\n* Le paramètre `query` : des expressions reliées par un opérateur logique, tel que `and`.\n\n\n\n* Des paramètres liés à la couche de présentation, comme `display`, `limit`, ou `fields`, `title` et `description` représentés en YAML.\n\n\n\nUne vue est définie en Markdown comme un bloc de code, similaire à d'autres blocs de code comme Mermaid.\n\n\n\nPar exemple :\n\n\n- Afficher un tableau des 5 premiers tickets ouverts assignés à l'utilisateur authentifié dans `gitlab-org/gitlab`.\n\n- Afficher les colonnes `title`, `state`, `health`, `epic`, `milestone`, `weight` et `updated`.\n\n\n\n````yaml\n```glql\ndisplay: table\ntitle: GLQL table 🎉\ndescription: This view lists my open issues\nfields: title, state, health, epic, milestone, weight, updated\nlimit: 5\nquery: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n```\n````\n\n\nLe tableau généré devrait ressembler à celui ci-dessous :\n\n\n![Vue intégrée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\n\n\n\nPour créer votre première vue intégrée, accédez au menu déroulant **Plus d'options** dans la barre d'outils de l'éditeur de texte enrichi. Une fois dans cette barre d'outils, sélectionnez **Vue intégrée**. \n\n\n\nLa requête suivante sera insérée dans un bloc de code Markdown :\n\n\n\n````yaml\n```glql\nquery: assignee = currentUser()\nfields: title, createdAt, milestone, assignee\ntitle: Issues assigned to current user\n```\n````\n\n\n\n\nEnregistrez vos modifications dans le commentaire ou la description où le bloc de code apparaît, et c'est terminé : vous avez créé votre première vue intégrée !\n\n\n\n## Comment GitLab utilise les vues intégrées\n\n\n\nQue ce soit pour suivre les merge requests relatives à des versions de sécurité, trier les bogues pour améliorer le backlog ou gérer l'intégration de l'équipe et la planification des jalons, nous nous servons des vues intégrées quotidiennement pour des processus essentiels. Il ne s'agit pas simplement d'une fonctionnalité que nous avons développée, c'est un outil dont nous dépendons pour gérer efficacement notre activité. Adopter les vues intégrées, c'est profiter d'une solution éprouvée qui aide déjà les équipes de GitLab à travailler plus efficacement, à prendre des décisions basées sur les données et à bénéficier d'une visibilité sur des workflows complexes. \n\n\n\nPour résumer, les vues intégrées peuvent transformer la façon dont votre équipe gère et analyse les tâches au cœur de votre travail.\n\n\n\nPour en savoir plus sur la façon dont GitLab utilise les vues intégrées en interne, consultez l’article [« Comment GitLab mesure l'impact de la Red Team : la métrique du taux d'adoption »](https://about.gitlab.com/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric/) et les tickets de planification concernant la version de recherche globale pour les jalons [18.1](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/239), [18.2](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/241) et [18.3](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/245).\n\n\n\n## Prochaines étapes\n\n\n\nLes vues intégrées ne sont que le début de la vision du [groupe Knowledge](https://about.gitlab.com/direction/plan/knowledge/) consacrée au suivi du travail. Découvrez nos futurs projets dans l'[epic post disponibilité générale des vues intégrées](https://gitlab.com/groups/gitlab-org/-/epics/15249). En ce qui concerne l'évolution de cette fonctionnalité, nous nous engageons à renforcer son efficacité et son [accessibilité](https://gitlab.com/gitlab-org/gitlab/-/issues/548722).\n\n\n\n## Partagez votre expérience\n\n\n\nPartagez vos retours dans le [ticket dédié aux vues intégrées en disponibilité générale](https://gitlab.com/gitlab-org/gitlab/-/issues/509792). Que vous ayez découvert des cas d'utilisation innovants, rencontré des défis ou que vous ayez des idées d'amélioration, nous voulons connaître votre avis.\n","Vues intégrées : l'avenir du suivi des tâches dans GitLab","Découvrez comment les vues intégrées aident les équipes de GitLab à travailler plus efficacement, à prendre des décisions basées sur les données et à bénéficier d’une visibilité sur des workflows complexes.",[798,799,800],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","2025-09-09",[804,805,806],"agile","workflow","DevSecOps platform",{"featured":6,"template":808,"slug":809},"BlogPost","embedded-views-the-future-of-work-tracking-in-gitlab",{"content":811,"config":823},{"title":812,"description":813,"authors":814,"heroImage":816,"date":817,"body":818,"category":677,"tags":819,"updatedDate":822},"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.",[815],"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](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",[804,806,820,772,821],"features","tutorial","2025-05-12",{"slug":824,"featured":91,"template":808},"safe-without-silos-in-gitlab",{"content":826,"config":835},{"title":827,"description":828,"authors":829,"heroImage":830,"date":831,"body":832,"category":677,"tags":833,"updatedDate":834},"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.",[815],"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",[804,821,805,806],"2025-03-06",{"slug":836,"featured":91,"template":808},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"category":685,"slug":689,"posts":838},[839,852,864],{"content":840,"config":850},{"tags":841,"category":689,"date":843,"heroImage":844,"title":845,"description":846,"authors":847,"body":849},[842,772,820,821],"AI/ML","2025-10-02","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","Vibe coding avec GitLab Duo Agent Platform : du ticket à la merge request","Découvrez comment mettre à jour rapidement votre application avec le flow « ticket à MR », qui aide les équipes de développement à passer de l'idée au code.",[848],"Cesar Saavedra","[GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) (disponible en version bêta) fournit un framework qui permet aux agents d'IA d'interagir avec les ressources de GitLab telles que les tickets et les merge requests et d'exécuter des tâches complexes en plusieurs étapes, du concept à la réalisation. GitLab Duo Agent Platform offre une expérience conversationnelle avec ([GitLab Duo Agentic Chat)](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) et automatisée avec les ([flows)](https://about.gitlab.com/fr-fr/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/) pour aider à la génération de code, à la modernisation, à la résolution des vulnérabilités de sécurité et à l'analyse de projets avec une sécurité à l’échelle de l'entreprise et des contrôles personnalisables.\n\nLe flow « ticket à merge request » simplifie la transformation d'un ticket détaillé en brouillon de merge request (MR). Le flow analyse la description et les exigences d'un ticket, ouvre une merge request liée au ticket, crée un plan de développement et propose une implémentation, directement depuis l'interface de GitLab.\n\n## Le défi des équipes de développement\n\nLes mises à jour telles que la réorganisation d'une interface utilisateur, l'ajustement de la taille d'un composant ou la modification mineure d'un workflow ne devraient pas nécessiter des heures de configuration. Pourtant, les équipes de développement se retrouvent face à un cycle frustrant : elles doivent rechercher dans le code source pour localiser les bons fichiers, créer des branches, rassembler des modifications dispersées à travers de multiples composants et gérer des processus de revue complexes, avant même de pouvoir vérifier si leur solution fonctionne. Ce processus de développement trop complexe transforme ce qui devrait être des itérations rapides en tâches chronophages qui ralentissent les boucles de rétroaction et transforment des améliorations simples en projets majeurs.\n\n## Comment utiliser le flow « ticket à merge request » pour accélérer une mise à jour d'application ?\n\nVous devez d'abord remplir les conditions ci-dessous avant d'utiliser ce flow :\n\n* Un ticket existant avec des exigences claires et des critères d'acceptation. GitLab Duo Agent Platform arrivera ainsi à mieux comprendre ce que vous essayez d'accomplir et à améliorer la qualité du résultat.\n* Un niveau d'accès Développeur ou plus au projet, car le flow apportera des modifications au code source de votre projet.\n* GitLab Duo Agent Platform activée pour votre groupe ou projet, avec les flows autorisés. Pour activer cette option, allez dans **Paramètres > Général > GitLab Duo > Autoriser l'exécution des flows**. GitLab s'engage à fournir des garde-fous, c'est pourquoi les fonctionnalités d'IA agentique nécessitent l'activation de ces options pour protéger les projets sensibles et garantir que seuls les projets sélectionnés sont accessibles à GitLab Duo Agent Platform.\n\nUne fois que vous avez rempli toutes les conditions ci-dessus, suivez les étapes ci-dessous pour tirer parti de ce flow :\n\n1. Créez un ticket de projet qui décrit ce que vous souhaitez que GitLab Duo Agent Platform accomplisse pour vous. Fournissez autant de détails que possible dans la description. Si le ticket existe déjà, ouvrez-le en allant dans **Programmation > Tickets** et cliquez sur le ticket qui décrit la mise à jour que vous souhaitez. Assurez-vous que le ticket soit précis et détaillé.\n2. Sous l'en-tête du ticket, cliquez sur **Générer une MR avec GitLab Duo** pour lancer le flow.\n3. Si vous souhaitez suivre la progression des agents qui travaillent sur l'implémentation de votre ticket, accédez à **Automatisation > Sessions d'agent** pour voir le journal de session en direct pendant que les agents planifient et proposent des modifications.\n4. Une fois le pipeline terminé, un lien vers la merge request apparaît dans l'activité du ticket. Ouvrez-le pour examiner le résumé et les modifications apportées au niveau des fichiers.\n5. Si vous souhaitez valider localement les mises à jour proposées par GitLab Duo Agent Platform, vous pouvez effectuer un pull de la branche sur votre ordinateur, compiler et exécuter votre application, puis vérifier que la mise à jour fonctionne comme prévu. Si nécessaire, effectuez des modifications dans la merge request et procédez à la revue habituelle.\n6. Si vous êtes satisfait de toutes les mises à jour de l'application proposées, fusionnez la merge request dans la branche principale.\n\n## Pourquoi utiliser le flow « ticket à merge request » pour modifier une application ?\n\nCe flow propose des modifications de code et met à jour directement la merge request. Résultat : vous passez moins de temps à localiser des fichiers et n'avez qu'à évaluer et examiner le résultat. De plus, la merge request est automatiquement liée au ticket d'origine, ce qui maintient un contexte précis pour les relecteurs et les parties prenantes. Enfin, vous pouvez surveiller la session de l'agent afin de suivre toutes les étapes.\n\n## Quels sont les avantages de GitLab Duo Agent Platform ?\n\nGitLab Duo Agent Platform est [une couche d'orchestration agentique](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-public-beta/) qui fournit **un contexte complet au projet**, notamment la planification, le codage, la compilation, la sécurisation, le déploiement et la surveillance, afin que les agents puissent aider tout au long du cycle de développement logiciel (SDLC), et pas seulement pour l'édition de code.\n\n* Modèle de données unifié : les agents GitLab Duo opèrent sur les données unifiées du SDLC de GitLab afin de fournir des décisions de meilleure qualité et une collaboration entre les tâches, y compris celles qui ne concernent pas le codage.\n* Sécurité et conformité intégrées : les agents GitLab Duo fonctionnent avec des garde-fous à l’échelle de l'entreprise et peuvent être utilisés même dans des environnements hautement réglementés ou hors ligne/air-gapped.\n* Interopérabilité et extensibilité : orchestrez des flow entre fournisseurs et outils ; connectez des données externes via les protocoles [MCP](https://about.gitlab.com/topics/ai/model-context-protocol/)/Agent2Agent pour un contexte plus riche.\n* Collaboration à grande échelle : les agents GitLab Duo fonctionnent dans l'interface utilisateur de GitLab et les IDE afin d'offrir une collaboration multiple entre humains et agents.\n* Découvrabilité et partages : trouvez et partagez des agents et des flows dans un catalogue d'IA centralisé.\n\n## Essayez le flow « ticket à merge request » dès maintenant\n\nPour les mises à jour d'application, comme un ajustement mineur de l'interface utilisateur, le flow « ticket à merge request » vous aide à passer rapidement d'un ticket clair à une merge request à réviser : vous pouvez surveiller la progression et valider les modifications dans votre workflow standard. Le flow maintient le contexte, réduit les transferts et permet à votre équipe de se concentrer sur la qualité plutôt que sur des tâches fastidieuses.\n\nDécouvrez le flow en action :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/BrrMHN4gXF4?si=J7beTgWOLxvS4hOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Essayez dès maintenant le flow « ticket à merge request » sur GitLab Duo Agent Platform en profitant d'un [essai gratuit de GitLab Ultimate avec GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/).",{"featured":6,"template":808,"slug":851},"vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"content":853,"config":862},{"title":854,"description":855,"authors":856,"heroImage":858,"date":859,"body":860,"category":689,"tags":861},"GitLab Duo et Claude Sonnet 4.5 : plus de choix en matière d'IA","Le tout dernier modèle d'Anthropic pour le développement et les workflows agentiques est désormais disponible dans GitLab Duo Pro, GitLab Duo Enterprise et GitLab Duo Agent Platform.",[857],"Tim Zallmann","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","2025-10-01","GitLab propose désormais Claude Sonnet 4.5, le modèle le plus avancé d'Anthropic pour le développement et les agents en conditions réelles, directement dans le sélecteur de modèles de GitLab Duo.\n\nLes utilisateurs ont désormais la possibilité de choisir Claude Sonnet 4.5 aux côtés d'autres modèles de premier plan, améliorant ainsi leur expérience avec [GitLab Duo](https://about.gitlab.com/gitlab-duo/) grâce à des avancées en matière d'orchestration d'outils, d'édition contextuelle et de capacités spécifiques à chaque domaine. Avec des performances de pointe sur [SWE-bench Verified (77,2 %](https://www.anthropic.com/news/claude-sonnet-4-5)) et des atouts en matière de cybersécurité, de finance et de workflows nécessitant des recherches approfondies, les utilisateurs de GitLab peuvent exploiter Claude Sonnet 4.5 pour obtenir des informations plus précises et un contexte plus approfondi dans leurs travaux de développement.\n\n« L’intégration de Claude Sonnet 4.5 dans GitLab représente une avancée majeure pour les équipes de développement. Il s'agit d'un modèle de développement particulièrement performant qui, associé à GitLab Duo Agent Platform, vous offre une assistance plus intelligente directement dans vos workflows. C'est le type d'évolution qui facilite le développement », déclare Taylor McCaslin, Principal, Strategy and Operations for AI Partnerships chez GitLab.\n\n## GitLab Duo Agent Platform et Claude Sonnet 4.5\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/agent-platform/) amplifie la valeur de Claude Sonnet 4.5 en orchestrant les agents, en les connectant aux systèmes internes et en les intégrant tout au long du cycle de développement logiciel. Cette combinaison crée une expérience unique, où le raisonnement avancé et la résolution de problèmes rencontrent le contexte et la sécurité à l'échelle de la plateforme. Le résultat : un développement plus rapide, des résultats plus précis et une couverture organisationnelle renforcée, le tout intégré dans le workflow de GitLab que les équipes de développement utilisent déjà au quotidien.\n\n## Où utiliser Claude Sonnet 4.5 ?\n\nClaude Sonnet 4.5 est désormais disponible en tant qu'option de modèle dans GitLab Duo Agent Platform Agentic Chat sur GitLab.com. Vous pouvez sélectionner Claude Sonnet 4.5 dans le menu déroulant de sélection des modèles pour tirer parti de ses capacités de codage avancées dans vos tâches de développement.\n\n![Sélection déroulante de Claude Sonnet 4.5 dans GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759180378/sopuv0msxrmhzt2dyxdi.png)\n\n**Remarque :** La possibilité de sélectionner Claude Sonnet 4.5 dans les IDE pris en charge sera bientôt disponible.\n\n## Premiers pas\n\nLes clients GitLab Duo Pro et GitLab Duo Enterprise peuvent accéder à Claude Sonnet 4.5 dès aujourd'hui. Consultez notre [documentation](https://docs.gitlab.com/user/gitlab_duo/) pour en savoir plus sur les fonctionnalités et les modèles de GitLab Duo.\n\n> Vous souhaitez essayer GitLab Ultimate avec GitLab Duo Enterprise ? [Commencez un essai gratuit dès aujourd'hui.](https://about.gitlab.com/gitlab-duo/)",[842,772],{"featured":91,"template":808,"slug":863},"greater-ai-choice-in-gitlab-duo-claude-sonnet-4-5-arrives",{"content":865,"config":874},{"heroImage":866,"date":867,"title":868,"description":869,"authors":870,"body":872,"category":689,"tags":873},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758541195/kig7sww6jyvxzmkmimbv.png","2025-09-23","GitLab 18.4 : développement et automatisation avec l’IA native","Avec GitLab 18.4, les équipes créent des agents personnalisés, exploitent le contexte du graphe de connaissances et automatisent la correction des pipelines afin d'améliorer la concentration et l'efficacité des équipes de développement.",[871],"Bill Staples","Toutes les équipes savent que le développement moderne ne se limite pas à l'écriture de code, et englobe au contraire la gestion des changements tout au long du cycle de développement logiciel.\n\nDans la version [GitLab 18.3](https://about.gitlab.com/fr-fr/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/), nous avons posé les bases d'une véritable collaboration entre humains et IA. Nous avons introduit des outils d'IA de premier plan tels que Claude Code, Codex CLI, Amazon Q CLI et Gemini CLI en tant qu'intégrations natives à GitLab, fourni notre premier aperçu du serveur GitLab Model Context Protocol ([MCP](https://about.gitlab.com/topics/ai/model-context-protocol/)) en partenariat avec Cursor et lancé deux nouveaux flows : « ticket à MR » et « conversion de fichier CI pour les Flows Jenkins » afin de proposer des solutions à des problèmes quotidiens rencontrés par les équipes.\n\nAvec [GitLab 18.4](https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/), nous renforçons la sécurité et la gouvernance relatives à votre utilisation de l'IA. Par ailleurs, nous étendons aussi votre capacité à créer et à partager des agents personnalisés, à collaborer plus efficacement grâce à Agentic Chat, à naviguer dans le code source avec le graphe de connaissances et à maintenir vos pipelines opérationnels avec le flow « correction de pipelines en échec ».\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1120293274?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=\"18.4 Release video placeholder\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> [Essayez GitLab Ultimate avec GitLab Duo Enterprise gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n## Construisez votre expérience\n\n*Commencez votre journée en consultant GitLab Duo AI Catalog, une bibliothèque d'agents spécialisés qui mettent en avant les priorités, automatisent les tâches routinières et vous aident à rester concentré.*\n\n### GitLab Duo AI Catalog : une bibliothèque d'agents spécialisés\n\nNotre version GitLab 18.4 intègre GitLab Duo AI Catalog (actuellement en phase d'expérimentation), une bibliothèque centralisée où les équipes peuvent créer, partager et collaborer avec des agents personnalisés au sein de leur entreprise. Chaque équipe aime faire les choses à sa façon, c'est pourquoi il suffit de former des agents personnalisés pour que tout soit fait correctement.\n\nPar exemple, un agent Planification de produit personnalisé peut signaler des bogues dans un format spécifique conformément à vos normes de labélisation, un agent Rédacteur technique peut rédiger une documentation concise en suivant vos conventions, ou un agent Securité peut s'assurer que chaque MR respecte vos normes de sécurité et de conformité. Au lieu de fonctionner comme des outils déconnectés, ces agents s'intègrent naturellement dans le workflow de GitLab et vous aident à terminer vos tâches plus rapidement sans perturber les processus établis.\n\n**Note :** cette fonctionnalité n'est actuellement disponible que sur GitLab.com à titre expérimental. Nous prévoyons de la mettre à la disposition de nos clients GitLab Self-Managed le mois prochain dans la version 18.5.\n\n## Réduisez le changement de contexte\n\n*GitLab Duo Agentic Chat garantit une collaboration fluide avec les agents.*\n\n### Agentic Chat : rationaliser la collaboration avec les agents (bêta)\n\nPièce maîtresse de GitLab Duo Agent Platform (bêta), [Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) vous offre un moyen transparent de collaborer avec les agents d'IA. La dernière mise à jour d'Agentic Chat dans la version GitLab 18.4 améliore l'expérience de chat ainsi que l'affichage et la gestion des sessions.\n\n* **Chat avec agent personnalisé**. Commençons par votre agent personnalisé que vous venez de créer. Vous pouvez immédiatement le mettre au travail via Agentic Chat. Par exemple, vous pourriez lui demander « donne-moi une liste de tâches » pour commencer à travailler sur les projets les plus urgents. De plus, vous avez maintenant la possibilité de démarrer de nouvelles conversations avec de nouveaux agents et de reprendre des conversations précédentes avec des agents sans perte de contexte.\n\n* [**Sélection du modèle par l'utilisateur**](https://docs.gitlab.com/user/gitlab_duo/model_selection/#select-a-model-to-use-in-gitlab-duo-agentic-chat). Avec les versions précédentes, vous pouviez sélectionner des modèles au niveau d'un espace de nommage, mais dans GitLab 18.4, vous pouvez maintenant choisir des modèles au niveau de l'utilisateur à chaque session de chat. Cela vous permet d'opter pour le [LLM](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\") qui convient le mieux à la tâche à accomplir ou de tester différents LLM pour voir lequel fournit la meilleure réponse concernant votre tâche.\n\n* **Formatage et design améliorés**. Nous espérons que vous apprécierez le nouveau design de GitLab Duo Agentic Chat, qui comprend également une meilleure gestion des approbations d'appels d'outils pour améliorer votre expérience.\n\n* **Sessions d'agents disponibles via Agentic Chat**. Les sessions font désormais partie intégrante de l'expérience Agentic Chat. Toute utilisation d’agents ou de flow apparaît maintenant dans l'aperçu des sessions dans Agentic Chat. Chaque session fournit des informations détaillées comme les job logs, les informations utilisateur et les métadonnées d'outils afin de garantir une transparence essentielle sur la façon dont les agents travaillent pour vous.\n  \n**Note :** les sessions dans Agentic Chat sont disponibles uniquement sur GitLab.com. Nous prévoyons de les mettre à disposition de nos clients GitLab Self-Managed le mois prochain dans la version 18.5.\n\n## Exploitez pleinement votre code source\n\n*Avec les agents, le contexte est primordial. Le graphe de connaissances vous permet de donner à vos agents plus de contexte pour qu'ils puissent travailler plus rapidement et vous donner de meilleurs résultats.*\n\n### Graphe de connaissances de GitLab (version bêta)\n\nLe [graphe de connaissances](https://gitlab-org.gitlab.io/rust/knowledge-graph/) disponible dans la version 18.4 transforme la façon dont les équipes et les agents comprennent et naviguent dans les codes sources complexes. Il fournit une carte connectée de la totalité de votre projet et relie fichiers, routes et références tout au long du cycle de développement logiciel. Les outils tels que l'accès aux définitions, la recherche dans le code source et le suivi des références disponibles dans les requêtes de chat aident les équipes de développement à poser des questions précises comme « quels sont les autres éléments impactés par cette modification ? ».\n\nCe contexte approfondi aide les équipes à avancer plus rapidement et à se sentir plus en confiance, qu'il s'agisse d'intégrer de nouveaux contributeurs, d'effectuer des recherches approfondies sur un projet ou d'explorer l’impact d’une modification sur le code dépendant. Plus votre écosystème gravite dans GitLab, plus le graphe de connaissances devient puissant et donne aux équipes et aux agents d'IA les bases pour travailler avec précision, vitesse et plein accès aux informations du projet. Dans les futures versions, nous intégrerons toutes vos données GitLab dans le graphe de connaissances, y compris les plans, les merge requests, les vulnérabilités de sécurité et plus encore.\n\nCette version du graphe de connaissances se concentre sur l'indexation locale du code, où l'interface CLI `gkg` transforme votre code source en une base de données graphique dynamique et intégrable pour la génération augmentée par récupération (RAG). Vous pouvez l'installer à l’aide d’un simple script en une ligne, analyser des dépôts locaux et vous connecter via MCP pour interroger votre espace de travail.\n\nNotre vision pour le graphe de connaissances est double : construire une édition communautaire dynamique que les équipes de développement peuvent exécuter localement dès aujourd'hui, qui servira de fondation pour un futur service de graphe de connaissances entièrement intégré au sein de GitLab.com et des instances auto-hébergées.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1121017374?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=\"18.4 Knowledge Graph Demo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> [Essayez GitLab Ultimate avec GitLab Duo Enterprise gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n## Automatisez la maintenance de vos pipelines\n\n*Corrigez les échecs de pipeline plus rapidement et restez concentré avec le flow « correction de pipelines en échec ».*\n\n### Corrigez des pipelines en échec en tenant compte du contexte métier\n\nLe maintien des pipelines est essentiel pour votre vélocité de développement, mais les approches traditionnelles se concentrent uniquement sur le dépannage technique sans considérer l'impact métier. Le **flow « correction de pipelines en échec »** adresse ce problème en combinant l'analyse technique avec le contexte stratégique. Par exemple, il peut automatiquement prioriser la correction d'un pipeline de déploiement en échec pour un service client avant un job de test nocturne, ou signaler différemment les problèmes de compilation dans une branche de release hautement prioritaire par rapport aux branches de fonctionnalités expérimentales.\n\n* **La détection des échecs avec contexte métier** surveille les exécutions de pipeline et comprend l'importance des différents workflows et cibles de déploiement.\n\n* **L'analyse des causes profondes en contexte** analyse les journaux d'échec en parallèle des exigences métier, les modifications récentes et les dépendances entre projets pour identifier les causes sous-jacentes.\n\n* **La priorisation stratégique des correctifs** génère des corrections appropriées tout en considérant l'impact métier, les échéances et les priorités d'allocation des ressources.\n\n* **La résolution intégrée au workflow** crée automatiquement des merge requests avec des correctifs qui maintiennent des processus de revue appropriés et fournissent un contexte métier afin d'aider à prioriser les tâches.\n\nCe flow assure l'exécution des pipelines et l'alignement stratégique. Ses corrections automatisées prennent en compte les objectifs métier et ne servent pas uniquement à résoudre des problèmes techniques de manière isolée.\n\n## Personnalisez votre environnement IA\n\n*L'automatisation ne fonctionne que si vous faites confiance aux modèles qui l'alimentent. C'est pourquoi la version 18.4 offre des fonctionnalités de gouvernance comme la sélection de modèles et les clés gérées par GitLab.*\n\n### Sélection de modèles GitLab Duo pour l'optimisation des performances\n\nLa [sélection de modèles](https://docs.gitlab.com/user/gitlab_duo/model_selection/) est maintenant proposée en disponibilité générale afin de contrôler directement les grands modèles de langage (LLM) qui alimentent GitLab Duo. Vous et votre équipe pouvez sélectionner les modèles de votre choix, les appliquer à l'ensemble de votre entreprise ou les adapter à chaque fonctionnalité. Vous pouvez définir des valeurs par défaut pour garantir la cohérence entre les espaces de nommage et les outils, dans le respect des exigences en matière de gouvernance, de conformité et de sécurité.\n\nPour les clients qui utilisent GitLab Duo Self-Hosted, la nouvelle prise en charge de GPT OSS et GPT‑5 offre une flexibilité supplémentaire pour les workflows de développement alimentés par l'IA.\n\n**Note :** GitLab Duo Self-Hosted n'est pas disponible pour les clients GitLab.com, et les modèles GPT ne sont pas pris en charge sur GitLab.com.\n\n## Protégez vos données sensibles\n\n*La gouvernance s’accompagne d’une protection des données afin de contrôler précisément ce que l'IA peut et ne peut pas voir.*\n\n### GitLab Duo Context Exclusion : une protection granulaire des données\n\nUn contrôle granulaire sur les informations auxquelles les agents d'IA peuvent accéder est nécessaire. Dans la version 18.4, **GitLab Duo Context Exclusion**  fournit des paramètres au niveau du projet qui permettent aux équipes d'interdire à l'IA d'accéder à des fichiers spécifiques ou des chemins d'accès de fichiers :\n\n* **Exclusions spécifiques à certains fichiers** pour aider à protéger les fichiers sensibles tels que les configurations de mots de passe, les secrets et les algorithmes propriétaires.\n\n* **Règles basées sur les chemins d’accès** pour créer des modèles d'exclusion en fonction des structures de répertoires ou des conventions de nommage de fichiers.\n\n* **Configuration flexible** pour appliquer des exclusions au niveau du projet tout en maintenant l'efficacité du workflow de développement.\n\n* **Visibilité d'audit** pour suivre le contenu exclu et garantir la conformité aux politiques de gouvernance des données.\n\nGitLab Duo Context Exclusion vous aide à protéger vos données sensibles pendant que vous accélérez votre développement avec l'IA agentique.\n\n## Renforcez vos fonctionnalités d'IA avec de nouveaux outils MCP\n\n*Les outils MCP étendus font passer ces fonctionnalités à la vitesse supérieure en connectant votre environnement GitLab à un écosystème plus vaste d'agents intelligents.*\n\n### Nouveaux outils pour le serveur GitLab MCP\n\nSur la base du serveur MCP initial introduit dans [la version 18.3](https://about.gitlab.com/fr-fr/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/), GitLab 18.4 ajoute plus d'outils MCP afin de définir la manière dont les clients MCP interagissent avec GitLab. Ces nouveaux outils augmentent les possibilités d'intégration et permettent aux agents d'IA de première partie et tiers de s'attaquer à des tâches plus détaillées telles que l'accès aux données de projet, l'exécution d'opérations de code ou la recherche dans des dépôts, le tout dans le respect des modèles de sécurité et d'autorisations existants. Pour une liste complète des outils MCP, y compris les nouveautés de la version 18.4, consultez notre [documentation dédiée au serveur MCP](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/).\n\n## Découvrez l'avenir du développement logiciel intelligent\n\nAvec [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/), les équipes n'ont plus à travailler sur un ticket à la fois dans un fil de discussion unique : la collaboration se déroule désormais dans plusieurs fils avec des agents asynchrones qui agissent comme des collègues pour accomplir des tâches plus rapidement. Nous donnons vie à cette vision unique en respectant les souhaits d'indépendance et de liberté de choix de nos clients : vous pouvez travailler dans vos environnements cloud préférés en utilisant les LLM et les outils d'IA qui vous conviennent le mieux, dans le respect des règles de sécurité et de conformité que vous avez définies.\n\nEn tant que partie intégrante de cette innovation, GitLab 18.4 est non seulement une mise à jour logicielle, mais aussi une version plus fluide, plus intelligente et plus sûre qui facilite le quotidien des équipes de développement. Des agents réutilisables aux corrections de pipeline adaptées aux enjeux métier, chaque fonctionnalité est conçue pour renforcer la concentration des équipes et assurer vitesse, sécurité et contrôle. Pour un aperçu plus approfondi de la façon dont ces fonctionnalités se combinent en pratique, consultez notre vidéo de démonstration.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1120288083?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=\"A day in the life with GitLab Duo Agent Platform\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cp>\u003C/p>\n\nLes utilisateurs de GitLab Premium et GitLab Ultimate peuvent commencer à utiliser ces fonctionnalités dès aujourd'hui sur GitLab.com et GitLab Self-Managed, tandis que les clients [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/) pourront y accéder le mois prochain.\n\n> **Activez les fonctionnalités bêta et expérimentales dans GitLab Duo Agent Platform dès aujourd'hui** et découvrez comment l'IA, avec un accès complet au contexte, peut transformer la façon dont vos équipes développent des logiciels. Nouveau sur GitLab ? [Commencez votre essai gratuit](https://about.gitlab.com/fr-fr/free-trial/devsecops/) et découvrez pourquoi l'avenir du développement est alimenté par l'IA, sécurisé et orchestré sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") la plus complète au monde.\n\n## Maintenez votre instance GitLab à jour\n\nPour vous assurer d'obtenir les dernières fonctionnalités, mises à jour de sécurité et améliorations de performances, nous vous recommandons de maintenir votre instance GitLab à jour. Les ressources suivantes peuvent vous aider à planifier et terminer votre mise à niveau :\n\n* [Outil de chemin d’accès de mise à niveau](https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/)  indiquez votre version actuelle pour consulter les étapes à suivre afin de mettre à niveau votre instance.\n\n* [Documentation de mise à niveau](https://docs.gitlab.com/fr-fr/update/upgrade_paths/) : guides détaillés pour chaque version prise en charge, y compris les exigences, les instructions étape par étape et les meilleures pratiques.\n\nEn effectuant régulièrement des mises à niveau, vous vous assurez que votre équipe bénéficie des dernières fonctionnalités de GitLab ainsi que d'une sécurité et d’une prise en charge optimales.\n\nPour les entreprises qui privilégient une approche autonome, pourquoi ne pas faire appel à [GitLab Managed Maintenance](https://content.gitlab.com/viewer/d1fe944dddb06394e6187f0028f010ad#1) ? Avec GitLab Managed Maintenance, votre équipe se concentre sur l'innovation tandis que les experts GitLab gèrent les mises à niveau de votre instance GitLab Self-Managed afin d'assurer la fiabilité, la sécurité et l'efficacité de vos processus DevSecOps. Contactez votre gestionnaire de compte pour obtenir plus d'informations.\n\n> [Essayez GitLab Ultimate avec GitLab Duo Enterprise gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n*Cet article de blog contient des énoncés de nature prospective au sens de la Section 27A de la Securities Act de 1933, telle que modifiée, et de la Section 21E de la Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans les énoncés de nature prospective contenus dans cet article de blog sont raisonnables, ils sont soumis à des risques connus et inconnus, des incertitudes, des hypothèses et d'autres facteurs qui peuvent entraîner des résultats ou des conséquences sensiblement différents. De plus amples informations sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos documents déposés auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de publication de cet article, sauf si la loi l'exige.*",[842,820,772,806],{"featured":6,"template":808,"slug":875},"gitlab-18-4-ai-native-development-with-automation-and-insight",{"category":697,"slug":701,"posts":877},[878],{"content":879,"config":889},{"title":880,"description":881,"authors":882,"heroImage":884,"date":885,"body":886,"category":701,"tags":887,"updatedDate":888},"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.",[883],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","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,749,806],"2025-03-28",{"slug":890,"featured":91,"template":808},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":709,"slug":713,"posts":892},[893,909,923],{"content":894,"config":907},{"title":895,"description":896,"authors":897,"heroImage":899,"date":900,"body":901,"category":713,"tags":902,"updatedDate":906},"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.",[898],"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",[903,904,905],"contributors","open source","customers","2025-02-10",{"slug":908,"featured":91,"template":808},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":910,"config":921},{"title":911,"description":912,"authors":913,"heroImage":915,"date":916,"body":917,"category":713,"tags":918,"updatedDate":920},"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.",[914],"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.**",[905,109,919,806],"user stories","2024-12-18",{"slug":922,"featured":91,"template":808},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":924,"config":935},{"title":925,"description":926,"authors":927,"heroImage":929,"date":930,"body":931,"category":713,"tags":932},"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.",[928],"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",[933,934,842,905],"DevOps","DevOps platform",{"slug":936,"featured":6,"template":808},"southwest-looking-to-help-developers-take-flight",{"category":721,"slug":725,"posts":938},[939,952,965],{"content":940,"config":950},{"title":941,"description":942,"authors":943,"heroImage":945,"date":946,"body":947,"category":725,"tags":948},"Atlassian met fin à Data Center tandis que GitLab maintient ses options de déploiement","Atlassian fait migrer ses clients Data Center vers une solution exclusivement cloud. Découvrez les options de déploiement de GitLab adaptées aux besoins des entreprises.",[944],"Emilio Salvador","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","2025-10-09","Le changement n'est jamais facile, surtout lorsqu'il ne relève pas de votre choix. L'annonce par Atlassian de la fin de vie de [tous ses produits Data Center au 28 mars 2029](https://www.atlassian.com/blog/announcements/atlassian-ascend) signifie que des milliers d'entreprises doivent désormais repenser leur déploiement et leur infrastructure [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\"). Mais vous n'avez pas à vous contenter d'options de déploiement qui ne correspondent pas à vos besoins. GitLab vous laisse libre de choisir, que vous ayez besoin d'une solution self-managed pour la conformité, d'une solution cloud pour la commodité ou d'une solution hybride pour la flexibilité. Le tout au sein d'une plateforme DevSecOps unique alimentée par l'IA qui respecte vos exigences.\n\nAlors que d'autres fournisseurs imposent des migrations vers des architectures exclusivement cloud, GitLab reste déterminé à prendre en charge les choix de déploiement qui correspondent à vos besoins métier. Que vous gériez des données gouvernementales sensibles, que vous opériez dans des environnements air-gapped ou que vous préfériez simplement le contrôle des déploiements self-managed, nous comprenons qu'une solution unique ne convient pas à tous.\n\n## Le cloud n'est pas la solution pour tout le monde\n\nPour les nombreuses entreprises qui ont investi des millions de dollars dans des déploiements Data Center, y compris celles qui ont migré vers Data Center [après l'arrêt des produits Server](https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/), cette annonce représente bien plus qu'un simple retrait de produit. Elle marque un changement fondamental dans l'approche des choix d'architecture centrés sur le client, plaçant les entreprises face à un dilemme difficile : accepter un modèle de déploiement inadapté à leurs besoins, ou trouver un fournisseur qui respecte leurs exigences.\n\nBon nombre d'organisations qui ont besoin de déploiements self-managed comptent parmi les plus importantes au monde : des systèmes de santé protégeant les données des patients, des institutions financières gérant des milliers de milliards d'actifs, des agences gouvernementales chargées de la sécurité nationale et des sous-traitants de la défense opérant dans des environnements air-gapped.\n\nCes organisations ne choisissent pas les déploiements self-managed par commodité. Elles les choisissent pour répondre à des exigences de conformité, de sécurité et de souveraineté auxquelles les architectures exclusivement basées sur le cloud ne peuvent tout simplement pas satisfaire. Les organisations opérant dans des environnements fermés avec un accès Internet restreint ou inexistant ne font pas exception. Elles représentent une part importante des clients d'entreprise dans divers secteurs.\n\n![GitLab vs. Atlassian comparison table](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759928476/ynl7wwmkh5xyqhszv46m.jpg)\n\n## Le coût réel d'une migration forcée vers le cloud dépasse le simple aspect financier\n\nAlors que les fournisseurs cloud présentent les migrations obligatoires comme des « mises à niveau », les organisations sont confrontées à des défis considérables qui vont bien au-delà des simples coûts financiers :\n\n* **Perte des capacités d'intégration :** des années d'intégrations personnalisées avec des systèmes hérités, des workflows soigneusement élaborés et des automatisations spécifiques à l'organisation deviennent obsolètes. Les organisations fortement intégrées à des systèmes hérités trouvent souvent la migration vers le cloud techniquement irréalisable.\n\n* **Contraintes réglementaires :** pour les organisations des secteurs réglementés, la migration vers le cloud n'est pas seulement complexe, elle est souvent interdite. Les exigences en matière de résidence des données, les environnements air-gapped et les frameworks réglementaires stricts ne s'adaptent pas aux préférences des fournisseurs. L'absence de solutions monolocataires dans de nombreuses approches exclusivement basées sur le cloud crée des obstacles insurmontables en matière de conformité.\n\n* **Impacts sur la productivité :** les architectures exclusivement cloud nécessitent souvent de jongler entre plusieurs produits : des outils distincts pour la planification, la gestion du code, le [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et la documentation. Chaque outil implique un nouveau changement de contexte, une nouvelle intégration à maintenir, ou encore un nouveau point de défaillance potentiel. Les recherches menées par GitLab montrent que [30 % des équipes de développement consacrent au moins 50 % de leur temps à maintenir et/ou intégrer leur chaîne d'outils DevSecOps](https://about.gitlab.com/fr-fr/developer-survey/). Les architectures fragmentées exacerbent ce problème plutôt que de le résoudre.\n\n## GitLab offre choix, engagement et consolidation\n\nLes entreprises méritent un partenaire technologique fiable. C'est pourquoi nous nous sommes engagés à prendre en charge toute une gamme d'options de déploiement. Que vous ayez besoin d'une solution sur site pour la conformité, d'une solution hybride pour la flexibilité ou d'une solution cloud pour la commodité, le choix vous appartient. Cet engagement se poursuit avec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre solution d'IA qui accompagne les équipes de développement à chaque étape de leur workflow.\n\nMais nous offrons plus qu'une simple flexibilité de déploiement. Alors que d'autres fournisseurs peuvent vous obliger à assembler leurs produits pour former une chaîne d'outils fragmentée, GitLab fournit tout ce dont vous avez besoin dans une **plateforme DevSecOps complète avec l'IA native**. La gestion du code source, le CI/CD, le scanning de sécurité, la [planification Agile](https://about.gitlab.com/fr-fr/blog/how-gitlab-agile-planning-improves-collaborative-project-management/ \"Qu'est-ce que la planification agile ?\") et la documentation sont tous gérés au sein d'une seule application et d'une seule relation fournisseur.\n\nCe n'est pas théorique. Lorsque [Airbus](https://about.gitlab.com/fr-fr/customers/airbus/) et [Iron Mountain](https://about.gitlab.com/fr-fr/customers/iron-mountain/) ont évalué leurs chaînes d'outils fragmentées existantes, ils ont systématiquement identifié les défis suivants : mauvaise expérience utilisateur, fonctionnalités manquantes comme le scanning de sécurité intégré et les versions temporaires d'application, et complexité de gestion liée au dépannage des plugins. **Ce ne sont pas des défis mineurs, mais des obstacles majeurs à la livraison logicielle moderne.**\n\n## Votre parcours de migration : plus simple que vous ne le pensez\n\nNous avons aidé des milliers d'organisations à migrer depuis d'autres fournisseurs, et nous avons développé les outils et l'expertise nécessaires pour faciliter votre transition :\n\n* **Outils de migration automatisés :** notre [outil d'importation Bitbucket Server](https://docs.gitlab.com/user/project/import/bitbucket_server/) transfère les dépôts, les pull requests, les commentaires et même les objets Large File Storage (LFS). Pour Jira, notre [outil d'importation intégré](https://docs.gitlab.com/user/project/import/jira/) gère les tickets, les descriptions et les labels, avec des services professionnels disponibles pour les migrations complexes.\n\n* **Efficacité prouvée à grande échelle :** un dépôt de 500 Gio avec 13 000 pull requests, 10 000 branches et 7 000 tags ne prendra probablement que [8 heures à migrer](https://docs.gitlab.com/user/project/import/bitbucket_server/) de Bitbucket vers GitLab en utilisant le traitement parallèle.\n\n* **Retour sur investissement immédiat :** une [étude Total Economic Impact™ de Forrester Consulting commandée par GitLab](https://about.gitlab.com/fr-fr/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years/) révèle qu'investir dans GitLab Ultimate confirme que ces avantages se traduisent par un impact réel sur les résultats financiers, avec un ROI de 483 % sur trois ans, un gain de temps multiplié par 5 dans les activités liées à la sécurité et 25 % d'économies sur les coûts de la chaîne d'outils logiciels.\n\n## Commencez votre transition vers une plateforme DevSecOps unifiée\n\nLes organisations avant-gardistes n'attendent pas les échéances imposées par les fournisseurs. Elles évaluent les alternatives dès maintenant, pendant qu'elles ont encore le temps de migrer de manière réfléchie vers des plateformes qui protègent leurs investissements et tiennent leurs promesses.\n\nLes organisations investissent dans des déploiements self-managed parce qu'elles ont besoin de contrôle, de conformité et de personnalisation. Lorsque les fournisseurs déprécient ces capacités, ils suppriment non seulement des fonctionnalités, mais aussi la possibilité fondamentale de choisir des environnements adaptés aux exigences métier.\n\nLes plateformes DevSecOps modernes doivent offrir des fonctionnalités complètes qui respectent les besoins de déploiement, consolident les chaînes d'outils et accélèrent la livraison logicielle, sans imposer de compromis en matière de sécurité ou de souveraineté des données.\n\n[Contactez notre équipe commerciale](https://about.gitlab.com/fr-fr/sales/) dès aujourd'hui pour discuter de vos options de migration, ou explorez nos [ressources](https://about.gitlab.com/move-to-gitlab-from-atlassian/) et découvrez comment des milliers d'organisations ont déjà effectué leur transition.\n\n> [Essayez GitLab Ultimate avec GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/devsecops/) gratuitement et découvrez ce qu'une plateforme DevSecOps unifiée peut apporter à votre organisation.",[949,721,772,820],"cloud native",{"featured":91,"template":808,"slug":951},"atlassian-ending-data-center-as-gitlab-maintains-deployment-choice",{"content":953,"config":963},{"title":954,"description":955,"authors":956,"date":958,"body":959,"category":725,"tags":960,"heroImage":962},"[Étude] L'innovation logicielle en France : plus de 12 milliards d'euros en jeu","L'innovation logicielle génère des revenus, mais l'expertise humaine, les lacunes en matière de compétences, la gouvernance de l'IA et l'alignement stratégique restent des facteurs déterminants pour le succès à long terme des entreprises.",[957],"GitLab France Team","2025-09-24","GitLab, la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") la plus complète et intelligente, vient de publier une  nouvelle étude intitulée, « L'innovation logicielle en France, plus de 12 milliards d'euros en jeu ». Menée par The Harris Poll, cette étude a interrogé des cadres dirigeants basés en France sur le rôle de l'innovation logicielle dans la réussite des entreprises. Cette étude définit l'innovation logicielle comme « la création de nouveaux logiciels ou l'amélioration significative de logiciels existants afin d’introduire de nouvelles fonctionnalités, d’améliorer leur efficacité ou de résoudre des problèmes de manière innovante ».\n\nLes cadres dirigeants reconnaissent que l'innovation logicielle améliorée par l'IA entraîne un changement économique significatif, servant de moteur de croissance et d’expansion des entreprises. Cependant, bien que l'adoption de l'IA génère un retour sur investissement mesurable et une productivité accrue, cette étude révèle également des tensions autour des lacunes en matière de compétences, de la collaboration homme-machine et du besoin de gouvernance formelle de l'IA agentique.\n\nDe plus, alors que les cadres dirigeants aspirent à atteindre une productivité optimale grâce à un partenariat 50/50 entre humain et IA, la réalité actuelle révèle que les humains gèrent les trois quarts des tâches, et que l'IA ne contribue uniquement qu'à hauteur d’un quart. Ce décalage s’accompagne de préoccupations persistantes concernant le déplacement d'emplois, la complexité perçue des systèmes d’intelligence artificielle et la cybersécurité.\n\n> Pour accéder à notre étude complète GitLab C-Suite Insights - France 2025 « L'innovation logicielle en France, plus de 12 milliards d'euros en jeu », [cliquez ici](https://learn.gitlab.com/fr-csuite-software-innovation-report/report-fr-fr-fr-devsecops-report-csuite?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_painpoint_fr_ds25_fr).\n\n![Infographie sur l'innovation logicielle en France](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758724632/jznahiwr2wzbme6350lx.png \"Infographie sur l'innovation logicielle en France\")\n\n## Chiffres clés de notre étude\n\n**L'innovation logicielle alimentée par l'IA émerge comme nouveau moteur de croissance économique, générant des milliards de dollars de valeur**\n\n* Les dirigeants interrogés déclarent économiser en moyenne 22 308,38 € par développeur annuellement grâce aux investissements dans l’IA, ce qui représente plus de 12 milliards d’euros de valeur économique potentielle lorsqu'appliqué aux 553 000 développeurs que compte la France. \n  86 % déclarent que l'innovation logicielle est désormais une priorité commerciale essentielle.\n  61 % rapportent que leur entreprise a connu une croissance liée aux efforts d'innovation logicielle au cours des 12 derniers mois.\n  Ils estiment une augmentation de 51 % du chiffre d’affaires et une augmentation de 54 % de la productivité des équipes de développement grâce à l'utilisation de l'IA.\n\n**L'IA agentique est en plein essor, mais les dirigeants estiment que la sécurité et la confiance doivent suivre le mouvement**\n\n* 88 % des cadres dirigeants s'attendent à ce que l'IA agentique devienne la norme pour le développement logiciel d’ici trois ans. \n* En tête de liste des préoccupations concernant l'adoption de l'IA agentique figurent la confidentialité et la sécurité des données (50 %), les menaces liées à la cybersécurité (49 %), et les erreurs introduites par les agents d’IA (42 %).\n* 49 % mettent en œuvre des frameworks de gouvernance alignés sur la réglementation.\n* 52 % développent des politiques internes d'IA, tandis que 51 % mettent en place des programmes pilotes ou des formations.\n\n**Les pénuries de talents à l'ère de l'IA rendent indispensable la mise à niveau des compétences**\n\n* 98 % des cadres dirigeants affirment que les contributions humaines sont précieuses pour le développement logiciel. \n* 92 % estiment que les entreprises devraient prioriser la formation des employés afin qu'ils puissent utiliser l'IA agentique et combler ainsi leurs lacunes en matière de compétences.\n* 75 % pensent que la contribution humaine dans le partenariat entre humain et IA devrait être d'au moins 50/50, avec seulement 25 % estimant que l'IA devrait effectuer la majorité des tâches.\n* La collaboration (42 %) et l’empathie (38 %) se classent comme les contributions humaines les plus précieuses au développement logiciel. \n\n**L'IA est une priorité pour les conseils d'administration, car l'innovation logicielle prouve son impact sur les résultats financiers**\n\n* 9 cadres dirigeants sur 10 déclarent que leur conseil d'administration adhère aux bénéfices de l'innovation logicielle.\n* 86 % déclarent être prêts à investir plus de la moitié du budget informatique annuel de leur entreprise pour prioriser l'innovation logicielle.\n* 87 % ont adopté des frameworks reliant les activités de développement logiciel aux résultats commerciaux clés.\n* Les indicateurs les plus couramment utilisés aujourd'hui pour mesurer le succès de l'innovation logicielle sont une meilleure rentabilité (49 %), une expérience client améliorée (39 %) et une productivité accrue des équipes de développement (38 %).\n\nVous souhaitez en savoir plus ? Téléchargez notre étude complète [GitLab C-Suite Insights - France 2025 « L'innovation logicielle en France, plus de 12 milliards d'euros en jeu »](https://learn.gitlab.com/fr-csuite-software-innovation-report/report-fr-fr-fr-devsecops-report-csuite?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_painpoint_fr_ds25_fr).",[961],"developer survey","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758807223/nzwhf9snd0fu288cqkj4.png",{"featured":6,"template":808,"slug":964},"software-innovation-study-france",{"content":966,"config":976},{"title":967,"description":968,"authors":969,"heroImage":972,"date":973,"body":974,"category":725,"tags":975},"Pourquoi les services financiers choisissent-ils le SaaS monolocataire ?","Découvrez comment GitLab Dedicated aide les services financiers à mettre en place une approche DevSecOps conforme sans compromettre les performances.",[970,971],"George Kichukov","Allie Holland","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682898/Blog/Hero%20Images/cloud-security.png","2025-08-27","Dans les grandes institutions financières, le contraste entre la sécurité déployée à l'entrée des bâtiments et celle appliquée au sein des équipes est saisissant. À l'entrée, gardes armés, scanners biométriques, murs renforcés et multiples points de contrôle assurent la sécurité. Tandis qu’à l'intérieur, les équipes de développement créent les algorithmes qui alimentent la finance mondiale sur une infrastructure partagée avec des millions d'inconnus.\n\nLes logiciels utilisés par les institutions financières actuelles sont tout sauf ordinaires. Ils comprennent des modèles de risque de crédit qui protègent des milliards d'actifs, des algorithmes de traitement des paiements qui gèrent des millions de transactions, des plateformes d'intelligence client qui pilotent la stratégie commerciale, et des systèmes réglementaires qui garantissent la conformité opérationnelle. Le tout alimenté par un code source qui sert à la fois de cœur opérationnel et d'actif stratégique.\n\n## Quand l'infrastructure partagée devient un risque systémique\n\nL'essor des plateformes SaaS (Software-as-a-Service) a créé une réalité inconfortable pour les institutions financières. Chaque locataire partagé devient un risque tiers non maîtrisé qui transforme les incidents à l'échelle de la plateforme en perturbations à l'échelle du secteur. C'est exactement ce type de risque de concentration qui attire de plus en plus l'attention des régulateurs.  \n\nPatrick Opet, Chief Information Security Officer de JPMorgan Chase, a récemment lancé un avertissement sévère au secteur dans une [lettre ouverte](https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers) adressée aux fournisseurs tiers. Il souligne que l'adoption du SaaS « crée une vulnérabilité substantielle qui affaiblit le système économique mondial » en intégrant « un risque de concentration dans les infrastructures critiques du monde entier ». La lettre fait remarquer qu'« une attaque contre un fournisseur majeur de SaaS ou de PaaS peut immédiatement se répercuter sur ses clients » et créer exactement le risque systémique que les plateformes cloud multi-locataires dédiées à la gestion du code source, aux compilations CI, aux déploiements CD et aux scans de sécurité introduisent.\n\nImaginez la complexité réglementaire que cela engendre. Dans des environnements partagés, votre posture de conformité est à la merci d'incidents potentiels qui touchent d'autres locataires ainsi que des risques de concentration des fournisseurs à grande surface d'attaque. Une mauvaise configuration affectant n'importe quelle organisation sur la plateforme peut avoir un impact plus large sur l'ensemble de l'écosystème. \n\nLes défis liés à la souveraineté des données aggravent ce risque. Les plateformes partagées répartissent les charges de travail entre plusieurs régions et juridictions, souvent sans contrôle granulaire sur l'endroit où votre code source s'exécute. Pour les institutions soumises à des exigences réglementaires strictes, cette répartition géographique peut créer des lacunes en matière de conformité qui sont difficiles à combler. \n\nÀ cela s'ajoute l'effet d'amplification. Chaque locataire partagé devient un risque tiers indirect pour vos opérations. Ses vulnérabilités augmentent votre surface d'attaque, ses incidents peuvent impacter votre disponibilité et ses compromissions peuvent affecter votre environnement. \n\n## Une plateforme conçue pour vos données les plus sensibles \n\nGitLab reconnaît que votre code source mérite le même niveau de sécurité que vos données clients les plus sensibles. Plutôt que de vous forcer à choisir entre l'efficacité à l'échelle du cloud et la sécurité de votre entreprise, GitLab offre les deux grâce à [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/), une infrastructure spécialement conçue qui garantit une isolation complète. \n\nVos workflows de développement, [vos dépôts](https://docs.gitlab.com/user/project/repository/) de code source et [vos pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) s'exécutent dans un environnement exclusivement dédié à votre organisation. Les [runners hébergés](https://docs.gitlab.com/administration/dedicated/hosted_runners/) sur GitLab Dedicated illustrent parfaitement cette approche. Ces runners se connectent de manière sécurisée à votre centre de données via des liens privés sortants, vous permettant d'accéder à vos services privés et de garantir que vos données ne soient pas exposées sur l'internet public. L'[architecture de mise à l'échelle automatique](https://docs.gitlab.com/runner/runner_autoscale/) fournit les performances dont vous avez besoin, sans compromettre la sécurité ni le contrôle. \n\n## Repenser le contrôle\n\nPour les institutions financières, minimiser les risques partagés n'est qu'une partie de l'équation. La véritable résilience nécessite un contrôle précis sur la façon dont les systèmes fonctionnent, évoluent et se conforment aux frameworks réglementaires. GitLab Dedicated assure une souveraineté complète des données à travers plusieurs niveaux de contrôle client. Vous conservez une autorité complète sur les [clés de chiffrement](https://docs.gitlab.com/administration/dedicated/encryption/#encrypted-data-at-rest) grâce aux capacités [BYOK (Bring Your Own Key)](https://docs.gitlab.com/administration/dedicated/encryption/#bring-your-own-key-byok), qui garantissent que le code source et les données de configuration sensibles restent accessibles uniquement à votre organisation. Même GitLab ne peut pas accéder à vos données chiffrées sans vos clés. \n\nLa [résidence des données](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) devient un choix plutôt qu'une contrainte. Vous pouvez sélectionner la région AWS de votre choix pour répondre aux exigences réglementaires et aux politiques de gouvernance des données de votre organisation, tout en conservant le contrôle total sur l'endroit où votre code source sensible et votre propriété intellectuelle sont stockés. \n\nCe contrôle s'étend aux [frameworks de conformité](https://docs.gitlab.com/user/compliance/compliance_frameworks/) requis par les institutions financières. La plateforme fournit des [pistes d'audit complètes](https://docs.gitlab.com/user/compliance/audit_events/) et des fonctionnalités de journalisation qui soutiennent les efforts de conformité aux réglementations des services financiers. \n\nSi vous avez des questions de conformité, vous pouvez collaborer directement avec l'équipe d’assistance dédiée de GitLab, composée de professionnels expérimentés qui comprennent les défis réglementaires auxquels sont confrontées les organisations dans les secteurs hautement réglementés. \n\n## Excellence opérationnelle sans charge opérationnelle\n\nGitLab Dedicated assure une [haute disponibilité](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) avec une [reprise après sinistre intégrée](https://docs.gitlab.com/subscriptions/gitlab_dedicated/) qui garantit la résilience de vos opérations de développement même en cas de défaillance de l’infrastructure. Les ressources dédiées s’adaptent aux besoins de votre organisation et évitent les fluctuations de performances inhérentes aux environnements partagés.\n\nL'[approche zéro maintenance](https://docs.gitlab.com/subscriptions/gitlab_dedicated/maintenance/) de l'infrastructure CI/CD élimine une charge opérationnelle importante. Vos équipes se concentrent sur le développement tandis que GitLab gère l'infrastructure sous-jacente, la mise à l'échelle automatique et la maintenance, y compris l'application rapide de correctifs de sécurité pour protéger votre propriété intellectuelle critique face aux menaces émergentes. Cette efficacité opérationnelle ne se fait pas au détriment de la sécurité : l'infrastructure dédiée offre des contrôles à l'échelle de l'entreprise et fournit des performances à l'échelle du cloud.\n\n## La réalité concurrentielle\n\nAlors que certaines institutions débattent des stratégies d'infrastructure, les leaders du secteur prennent des mesures décisives. [NatWest Group](https://about.gitlab.com/press/releases/2022-11-30-gitlab-dedicated-launches-to-meet-complex-compliance-requirements/), l'une des plus grandes institutions financières du Royaume-Uni, a choisi GitLab Dedicated pour transformer ses capacités d'ingénierie : \n\n> *« NatWest Group a adopté GitLab Dedicated pour permettre aux ingénieurs d'utiliser une plateforme d'ingénierie cloud commune, capable de fournir rapidement, fréquemment et en toute sécurité de nouveaux résultats aux clients grâce à des tests automatisés de haute qualité, une infrastructure à la demande et un déploiement direct. Cette nouvelle plateforme améliore considérablement la collaboration entre les équipes, augmente la productivité des développeurs et libère la créativité grâce à une interface unifiée pour le développement logiciel. »* **Adam Leggett**, Platform Lead - Engineering Platforms, NatWest \n\n## Le choix stratégique\n\nLes institutions financières les plus prospères font face à un défi unique : elles courent les plus grands risques en raison de leurs infrastructures partagées, mais elles disposent également des ressources nécessaires pour concevoir de meilleures solutions. \n\n**Pour les leaders du secteur, la question suivante est déterminante face à la concurrence :** Accepterez-vous les risques liés aux infrastructures partagées comme le prix de la transformation numérique, ou investirez-vous dans une infrastructure qui accorde à votre code source l'importance stratégique qu'il mérite ? \n\nVos algorithmes de trading ne sont pas partagés. Vos modèles de risque ne sont pas partagés. Vos données clients ne sont pas partagées. \n\n**Pourquoi votre plateforme de développement est-elle partagée ?** \n\n*Prêt à traiter votre code source comme un actif stratégique ? [Discutons](https://about.gitlab.com/solutions/finance/) ensemble de la manière dont GitLab Dedicated fournit la sécurité, la conformité et les performances dont les institutions financières ont besoin, sans les compromis liés à une infrastructure partagée.*",[554,806],{"featured":6,"template":808,"slug":977},"why-financial-services-choose-single-tenant-saas",{"category":733,"slug":737,"posts":979},[980,989,1003],{"content":981,"config":987},{"title":982,"description":983,"heroImage":984,"date":985,"body":986,"category":737},"Kubernetes : gérer les données du cluster côté frontend","Découvrez dans ce guide tout ce que vous devez savoir sur la solution intégrée de GitLab pour surveiller l'état de vos clusters Kubernetes.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750099045/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2816%29_3L7ZP4GxJrShu6qImuS4Wo_1750099045397.png","2025-10-13","Un accès aux informations relatives au cluster en temps réel est essentiel pour vérifier le succès des déploiements logiciels et lancer les processus de dépannage. Dans cet article, vous découvrirez l'intégration Kubernetes améliorée de GitLab et notamment comment exploiter l'API Watch pour obtenir des informations en temps réel sur l'état des déploiements et les fonctionnalités de dépannage optimisées.\n\n\n## Quelles sont les ressources Kubernetes de GitLab ?\n\n\nGitLab propose un [tableau de bord](https://gitlab.com/groups/gitlab-org/-/epics/2493 \"Afficher l'état des cluster dans GitLab\") dédié à [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") afin de mieux visualiser l'état des clusters connectés grâce à une interface intuitive. Intégré à la page Détails de l'environnement, il permet d'afficher les ressources pertinentes de l'environnement.\n\n\nTrois types de ressources Kubernetes sont actuellement disponibles :\n\n* Les pods filtrés par espace de nommage Kubernetes\n* Les services\n* Les ressources Flux ([HelmRelease](https://fluxcd.io/flux/components/helm/helmreleases/) ou [Kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/))\n\n\nNous fournissons des informations générales telles que le nom, le statut, l'espace de nommage, l'âge, etc., pour ces ressources. Les données sont présentées de manière similaire à ce que la commande [kubectl](https://kubernetes.io/docs/reference/kubectl/) afficherait lorsqu'elle est exécutée depuis le cluster Kubernetes. Il est possible de cliquer sur n'importe quelle ressource pour obtenir plus de détails. Le panneau latéral affiche la liste des labels, des annotations, le statut détaillé et les informations de spécification présentées sous forme de blocs de code YAML en lecture seule, et diffuse en temps réel les événements Kubernetes filtrés pour cette ressource spécifique. En ce qui concerne les pods, les utilisateurs peuvent accéder à une vue dédiée des logs et sélectionner un conteneur afin de diffuser ses logs en temps réel et d'obtenir des informations cruciales pour le débogage.\n\n\nLes informations fournies aident à visualiser l'état du cluster, à repérer d'éventuels problèmes et à déboguer immédiatement les déploiements problématiques. Les utilisateurs peuvent également agir immédiatement (supprimer les pods en échec, déclencher la réconciliation Flux ou suspendre/reprendre la synchronisation), le tout depuis la même interface sans avoir besoin de basculer vers des outils en ligne de commande.\n\n\n## Communication frontend-cluster : la solution GitLab\n\n\nNous avons développé une gamme d'outils et de solutions pour garantir une connexion et une gestion fluides des clusters Kubernetes dans GitLab. L'[agent GitLab pour Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/install/) est l'un des principaux composants de ce système et offre une connexion bidirectionnelle sécurisée entre une instance GitLab et un cluster Kubernetes. Cet outil puissant est composé de deux composants clés : **agentk** et **KAS** (GitLab Agent Server for Kubernetes).\n\n\n![Graphique du flux Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099055229.png)\n\n\nagentk est un composant léger côté cluster qui établit une connexion à une instance KAS et attend les requêtes à traiter. Il sert de proxy pour les requêtes KAS vers l'API Kubernetes. Il peut également envoyer activement des informations sur les événements du cluster à KAS.\n\n\nAlors qu'agentk communique activement avec le cluster, KAS est un composant côté serveur GitLab qui :\n\n\n* Accepte les requêtes d'agentk\n\n* Authentifie les requêtes d'agentk en interrogeant le backend GitLab\n\n* Récupère la configuration de l'agent depuis un dépôt [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") correspondant en utilisant Gitaly\n\n* Interroge les dépôts de manifestes pour la prise en charge de [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Qu'est-ce que Gitops ?\")\n\n\nNous avons implémenté la fonctionnalité relative aux droits d'accès de l'agent pour fournir un accès du frontend GitLab au cluster de manière sécurisée et fiable. Pour activer cette fonctionnalité, l'utilisateur doit mettre à jour le fichier de configuration de l'agent en ajoutant la section [user_access](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html) avec les paramètres `projects`, `groups` et `access_as` afin de préciser les projets qui peuvent accéder aux informations du cluster via l'agent et la manière dont il doit s'authentifier.\n\n\nLe frontend peut ensuite se connecter au cluster en envoyant une requête au contrôleur Rails, qui doit définir un cookie `gitlab_kas`. Ce cookie est ensuite ajouté à la requête envoyée à KAS avec l'ID de l'agent et le token Cross-Site Request Forgery (CSRF). À la réception de la requête, KAS vérifie l'autorisation de l'utilisateur et la transmet à agentk, qui effectue une requête réelle à l'API Kubernetes. Ensuite, la réponse remonte et passe par agentk et KAS avant de finalement arriver au client GitLab.\n\n\n![Aperçu du fonctionnement de Kubernetes overview](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099055229.png)\n\n\nPour intégrer cette logique dans le frontend GitLab et l'utiliser dans l'application Vue, nous avons développé une bibliothèque JavaScript ([@gitlab/cluster-client](https://gitlab.com/gitlab-org/cluster-integration/javascript-client)) générée à partir de la spécification OpenAPI Kubernetes au moyen du générateur typescript-fetch. Elle fournit toutes les API Kubernetes qui peuvent être utilisées dans un navigateur web, ainsi que notre classe `WebSocketWatchManager` qui gère l'API Watch Aggregator et fournit des mises à jour efficaces en temps réel.\n\n\n## Présentation de l'API Watch\n\n\nLes **mises à jour en temps réel** représentent le défi le plus important du tableau de bord Kubernetes. Dans Kubernetes, le concept de commandes watch est une extension des requêtes GET qui permet d'afficher le contenu du corps sous forme de [flux lisible](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams). Une fois connecté au flux, l'API Kubernetes transmet les mises à jour de l'état du cluster de manière similaire à la commande `kubectl get \u003Cresource> --watch`. Le mécanisme de surveillance permet au client de récupérer l'état actuel de la ressource (ou de la liste de ressources) puis de s'abonner aux changements ultérieurs afin de ne rien manquer. Chaque événement contient un type de modification (ajout, modification ou suppression) et l'objet concerné.\n\n\nAu sein de la classe `WatchApi` de la bibliothèque `@gitlab/cluster-client`, nous avons développé une approche systématique pour interagir avec l'API Kubernetes, qui consiste à récupérer un flux continu de données, à le traiter ligne par ligne et à gérer les événements en fonction de leurs types. Explorons les principaux composants et fonctionnalités de cette approche :\n\n\n1. Extension de l'API Kubernetes : au sein de la classe `WatchApi`, nous étendons les fonctionnalités de base de l'API Kubernetes pour récupérer un flux continu de données avec un chemin et des paramètres de requête spécifiés. Cette extension permet une gestion efficace des grands ensembles de données, car le flux est traité ligne par ligne.\n\n2. Décodage et catégorisation des événements : à la réception du flux, chaque ligne, qui représente généralement un objet JSON, est décodée. Ce processus extrait les informations pertinentes et catégorise les événements en fonction de leurs types.\n\n3. Gestion interne des données : la classe `WatchApi` maintient un tableau de données interne pour indiquer l'état actuel des données diffusées. Elle le met à jour en conséquence à mesure que de nouvelles données arrivent ou que des modifications se produisent.\n\n4. Enregistrement d'écouteurs d'événements : la classe `WatchApi` implémente des méthodes pour enregistrer des écouteurs d'événements, tels que `onData`, `onError`, `onTimeout`, et `onTerminate`. Ces méthodes permettent aux équipes de développement de personnaliser la réponse de leur application aux événements tels que les mises à jour de données, les erreurs et les délais d'attente dépassés.\n\n\nLe code gère également des scénarios tels que les types de contenu non valides, les délais d'attente dépassés et les erreurs du serveur, pour lesquels il émet des événements correspondants afin que les clients puissent les traiter de manière appropriée. **Cette approche simple et axée sur les événements de la classe `WatchApi` permet aux équipes de développement de créer en toute efficacité des applications réactives en temps réel.**\n\n\n![Aperçu du flux Kubernetes overview](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099055231.png)\n\n\n## Évolution vers l'agrégation WebSocket\n\n\nNous nous sommes basés sur l'API Watch et avons introduit le `WebSocketWatchManager` pour répondre aux limitations des flux lisibles : le sous-protocole WebSocket `gitlab-agent-watch-api` agrège plusieurs commandes watch de ressources au sein d'une seule connexion persistante. \n\n\nCette approche apporte plusieurs améliorations :\n\n\n* **Plusieurs commandes watch via une connexion unique :** au lieu d'ouvrir des flux HTTP séparés pour chaque ressource Kubernetes, elles partagent toutes une seule connexion WebSocket. Les problèmes de connexion côté client et serveur sont ainsi considérablement réduits, un aspect particulièrement important lors de la surveillance de nombreuses ressources dans différents espaces de nommage.\n\n* **Gestion dynamique des commandes watch :** le protocole prend en charge le démarrage et l'arrêt de commandes watch individuelles à la demande via des messages `watch` et `unwatch`. La fonctionnalité `unwatch` n'est pas encore implémentée dans le client JavaScript, mais une fois ajoutée, elle arrêtera les commandes watch inutiles lorsque les utilisateurs quittent les vues de ressources.\n\n* **Connexions plus fiables :** les connexions WebSocket maintiennent des sessions stables et durables sans les interruptions imprévisibles que nous avons rencontrées avec le streaming basé sur HTTP de l'API Watch. Ces connexions de streaming s'interrompaient parfois de manière inattendue, nécessitaient une logique de reconnexion et risquaient potentiellement de manquer des événements pendant la fenêtre de reconnexion.\n\n\nLors de l'établissement d'une connexion, le client doit d'abord demander un token d'authentification, car les connexions WebSocket ne peuvent pas envoyer d'en-têtes personnalisés (comme les tokens CSRF ou les cookies) après la communication initiale. Ce token, obtenu via une requête HTTP standard avec des en-têtes d'authentification complets, est ensuite intégré dans l'en-tête du sous-protocole WebSocket lors de l'établissement de la connexion. Une fois connecté au point de terminaison `/watch`, le client démarre des commandes watch individuelles en envoyant des messages avec des paramètres de ressource, et le serveur renvoie en continu les événements watch à mesure que les ressources Kubernetes changent.\n\n\nLe système revient à l'implémentation `WatchApi` d'origine lorsque les connexions WebSocket échouent pour une raison quelconque, que ce soit en raison de limitations d'infrastructure réseau, d'échecs de connexion ou de problèmes d'authentification. Cette double approche offre les avantages de performance WebSocket lorsque ceux-ci sont disponibles et maintient une fonctionnalité complète grâce à la méthode de streaming de l'API Watch si nécessaire. Le basculement se fait automatiquement et garantit une fonctionnalité en temps réel et cohérente qui ne requiert aucune connaissance ni intervention de l'utilisateur.\n\n\n## Comment la vue d'ensemble Kubernetes est-elle intégrée au frontend GitLab ?\n\n\nNous avons actuellement deux intégrations Kubernetes dans le produit : la section Vue d'ensemble Kubernetes pour les Environnements et le tableau de bord Kubernetes complet comme vue séparée. Ce dernier représente le fruit de nos efforts en vue d'afficher toutes les ressources Kubernetes disponibles avec des fonctionnalités de filtrage et de tri, et une vue détaillée avec des informations complètes sur les métadonnées, les spécifications et le statut de la ressource. Ce projet est actuellement en pause, car nous sommes en train d'explorer comment afficher les ressources Kubernetes liées à un environnement de la façon la plus utile possible.\n\n\nLa [vue d'ensemble Kubernetes](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html) sur la page Environnements représente une vue détaillée des ressources Kubernetes liées à un environnement spécifique. Pour accéder à la vue de l'état du cluster, l'utilisateur doit sélectionner un agent installé dans le cluster avec les droits d'accès appropriés, fournir un espace de nommage (facultatif) et sélectionner une ressource Flux associée.\n\n\nLa vue affiche une liste de pods et de services Kubernetes filtrés par l'espace de nommage avec leurs statuts et le statut de synchronisation Flux. Cliquer sur chaque ressource ouvre une vue détaillée avec plus d'informations pour faciliter la détection des problèmes et le débogage de haut niveau.\n\n\n![Aperçu de Kubernetes, liste des pods et services Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099055233.png)\n\n\nNous devons paramétrer un objet de configuration correct qui sera utilisé pour toutes les requêtes API. Dans la configuration, nous devons préciser l'URL fournie par le KAS, qui sert de proxy pour les API Kubernetes, l'ID de l'agent GitLab auquel se connecter et le token CSRF. Nous devons inclure les cookies pour que le `kas_cookie` soit récupéré et envoyé dans la requête.\n\n\n```javascript\n\ncreateK8sAccessConfig({ kasTunnelUrl, gitlabAgentId }) {\n  return {\n    basePath: kasTunnelUrl,\n    headers: {\n      'GitLab-Agent-Id': gitlabAgentId,\n      ...csrf.headers,\n    },\n    credentials: 'include',\n  };\n}\n\n```\n\n\nCet objet de configuration sert de base pour toutes les interactions avec l'API Kubernetes via KAS, que ce soit en utilisant des appels API standard, le streaming de l'API Watch ou les connexions WebSocket. Chaque méthode de connexion s'appuie sur cette configuration de base avec ses exigences spécifiques.\n\n\nToutes les requêtes API sont implémentées sous forme de requêtes client GraphQL pour une meilleure efficacité, flexibilité et facilité de développement. La structure de requête permet aux clients de récupérer des données provenant de diverses sources en une seule requête. Grâce à des définitions de schéma claires, GraphQL minimise les erreurs et renforce l'efficacité des équipes de développement. L'implémentation WebSocket complète cette approche avec une gestion des mises à jour en temps réel via une connexion unique persistante, ce qui réduit le besoin de multiples connexions de streaming parallèles et maintient la même structure de requête GraphQL pour les mises à jour de données.\n\n\nLors du premier affichage de la vue d'ensemble Kubernetes, le frontend demande des listes statiques de pods, services et ressources Flux (HelmRelease ou Kustomization). La requête de récupération est nécessaire pour afficher correctement la vue vide. Si le frontend essayait de s'abonner au flux de l'API Watch et qu'une des listes de ressources était vide, il faudrait alors attendre les mises à jour indéfiniment, et le résultat réel, soit 0 ressource, ne serait jamais affiché. Dans le cas des pods et services, après la requête initiale, nous nous abonnons au flux même si une liste vide a été reçue afin de refléter tout changement d'état du cluster. En ce qui concerne la ressource Flux, la probabilité que l'utilisateur s'attende à ce qu'une ressource apparaisse après la requête initiale est faible. Nous utilisons la réponse vide ici en vue de fournir plus d'informations sur la fonctionnalité et sa configuration.\n\n\n![Aperçu de Kubernetes, synchronisation du statut du flux non disponible](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099055235.png)\n\n\nAprès avoir affiché le résultat initial, le frontend établit des connexions en temps réel pour surveiller les changements. L'implémentation tente d'abord la connexion WebSocket et se rabat sur le streaming de l'API Watch lorsqu'elle n'est pas disponible. Avec les connexions WebSocket, une seule connexion gère toutes les commandes watch de ressources, maintient des flux internes pour chaque ressource et les met à jour en fonction des événements entrants (`ADDED`, `MODIFIED`, `DELETED`). En mode de solution alternative API Watch, le frontend effectue des requêtes avec le paramètre de requête `?watch=true` et crée des watchers séparés pour chaque type d'événement :\n\n\n```javascript\n\nwatcher.on(EVENT_DATA, (data) => {\n  result = data.map(mapWorkloadItem);\n  client.writeQuery({\n    query,\n    variables: { configuration, namespace },\n    data: { [queryField]: result },\n  });\n\n  updateConnectionStatus(client, {\n    configuration,\n    namespace,\n    resourceType: queryField,\n    status: connectionStatus.connected,\n  });\n});\n\n```\n\n\nLes deux approches suivent le même modèle de traitement des données :\n\n\n* Transformer les données pour assurer une structure cohérente\n\n* Mettre à jour le cache Apollo pour déclencher les mises à jour de l'interface utilisateur\n\n* Exécuter une mutation pour mettre à jour l'indicateur d'état de connexion\n\n\nÉtant donné que les informations détaillées sont affichées pour chaque ressource, nous devons pouvoir consulter les champs statut, spécifications et métadonnées avec annotations et labels. L'API Kubernetes n'envoie pas toujours ces informations, ce qui pourrait mettre à mal l'interface utilisateur et générer des erreurs du client GraphQL. Il faut d'abord transformer les données reçues pour éviter ces problèmes, et ajouter `__typename` afin de mieux définir les types de données et simplifier les requêtes en réutilisant les fragments partagés.\n\n\nAprès la stabilisation des données, nous mettons à jour le cache Apollo pour que le frontend puisse afficher de nouveau les vues afin de refléter les changements d'état du cluster. Il est intéressant de constater que nous pouvons visualiser exactement ce qui se passe dans le cluster : par exemple, lors de la suppression des pods, Kubernetes en crée de nouveaux avec un état en attente, puis il supprime les anciens pods. Ainsi, il est possible de voir deux fois plus de pods qu'escompté pendant un bref instant. Nous pouvons également vérifier comment les pods passent d'un état à un autre en temps réel. Pour ce faire, il nous suffit de combiner les événements ajoutés, supprimés et modifiés reçus des API Kubernetes et traités soit par le `WebSocketWatchManager`, soit par la classe `WatchApi` de la bibliothèque `@gitlab/cluster-client`.\n\n\n![Aperçu de Kubernetes, états des statuts de connexion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099055236.gif)\n\n\nL'indicateur d'état de connexion est un élément important pour les deux types de connexion, bien que pour des raisons différentes. Même si les connexions WebSocket sont plus stables et durables, les utilisateurs doivent pouvoir savoir si la connexion est interrompue en raison de problèmes réseau ou d'authentifications expirées. Avec le streaming de l'API Watch, les connexions ont des limitations dues aux délais d'attente dépassés et sont davantage sujettes à la déconnexion. Pour obtenir une meilleure visibilité à ce sujet, nous avons introduit une requête `k8sConnection` avec la mutation `reconnectToCluster`. L'interface utilisateur affiche un badge avec une infobulle qui indique trois états de connexion :\n\n\n* Connexion en cours : défini lors de l'initiation de l'une ou l'autre connexion\n\n* Connecté : mis à jour lorsque les premières données arrivent via l'une ou l'autre connexion\n\n* Déconnecté : déclenché en cas d'échec de connexion WebSocket, d'expiration des flux API Watch, ou d'erreur de connexion\n\n\nEn cas de déconnexion, les utilisateurs peuvent cliquer pour se reconnecter sans actualiser le navigateur. En comptant sur l'utilisateur pour se reconnecter au flux, nous pouvons économiser des ressources et ne demander que les données nécessaires tout en garantissant que l'état précis du cluster est disponible pour l'utilisateur à tout moment.\n\n\n## Et maintenant ? \n\n\nLa fonctionnalité intégrée de Kubernetes pour surveiller le flux lisible nous a aidés à développer rapidement cette fonctionnalité et à fournir une solution d'interface utilisateur Kubernetes à nos clients, à obtenir des retours précoces et à ajuster le produit. Bien que l'approche initiale de l'API Watch présente des défis comme les délais d'attente dépassés de connexion et les besoins de reconnexion, elle nous a donné des informations précieuses sur les modèles d'utilisation réels. L'implémentation WebSocket a résolu bon nombre de ces défis initiaux et a offert des connexions plus stables ainsi qu'une meilleure efficacité des ressources grâce aux commandes watch multiplexées. Les deux approches API Watch et WebSocket continueront d'évoluer en fonction des besoins des utilisateurs.\n\n\nIl existe des solutions qui pourraient améliorer davantage l'expérience utilisateur. Le protocole WebSocket prend déjà en charge les messages `unwatch` pour la gestion dynamique des commandes watch, même s'il n'est pas encore implémenté dans le client JavaScript. Une gestion des erreurs plus complète et la prise en charge de types de ressources Kubernetes supplémentaires pourraient également renforcer les fonctionnalités du tableau de bord.\n\n\n> Vous souhaitez contribuer à la fonctionnalité du tableau de bord Kubernetes, explorer les possibilités d'amélioration ou partager vos cas d'utilisation ? Partagez vos retours dans notre [epic Tableau de bord Kubernetes](https://gitlab.com/groups/gitlab-org/-/epics/2493).\n",{"featured":6,"template":808,"slug":988},"kubernetes-overview-operate-cluster-data-on-the-frontend",{"content":990,"config":1001},{"heroImage":991,"date":992,"title":993,"description":994,"authors":995,"category":737,"tags":999,"body":1000},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/blog/hero%20images/workflow_1800x945","2025-09-01","La documentation de GitLab fait peau neuve","Découvrez les fonctionnalités de notre nouvelle documentation produit, qui facilite désormais les retours et prend en charge le mode sombre tant demandé.",[996,997,998],"Suzanne Selhorn","Julia Miocene","Sarah German",[268],"La documentation de GitLab arbore désormais une toute nouvelle apparence. Ce qui a commencé comme une demande de corrections de design ciblées s'est transformé en une refonte complète avec cinq améliorations majeures :\n\n**Un mode sombre** : la fonctionnalité la plus demandée est enfin disponible. Alternez entre thème clair et thème sombre en cliquant dans le coin supérieur droit pour améliorer la lisibilité et réduire la fatigue oculaire.\n\n**Un alignement de la marque** : notre documentation reflète désormais les couleurs et le design de notre site web et de notre interface utilisateur afin de garantir une expérience cohérente à travers toutes les propriétés de GitLab.\n\n**Des retours simplifiés** : les utilisateurs peuvent désormais donner leur avis (positif ou négatif) et laisser des commentaires sur n'importe quelle page de la documentation.\n\n**Une navigation repensée** : nous avons déplacé la navigation principale vers le haut et restructuré notre barre latérale gauche pour rendre nos plus de 2 300 pages moins intimidantes et plus faciles à parcourir.\n\n**Une dette technique résolue** : des dizaines de corrections mineures ont été apportées à la typographie, à l'espacement, aux blocs de code et aux incohérences visuelles qui s'étaient accumulées au fil des ans.\n\n## Pourquoi maintenant ? \n\nAu début de l'année, sous la direction de Sarah German, notre équipe d'ingénierie chargée de la documentation a mené à bien un projet crucial de refonte de la plateforme, migrant de Nanoc vers Hugo. Bien que largement invisible pour les utilisateurs, ce changement a permis d’améliorer considérablement les performances (avec des compilations locales 130 fois plus rapides et des compilations complètes 30 fois plus rapides ) et a fourni la base technique solide nécessaire à ces améliorations.\n\nCette refonte était une étape essentielle qui nous a permis de nous concentrer sur l’amélioration de l'expérience utilisateur. Examinons de plus près ces changements.\n\n### Mode sombre\n\nProbablement la plus grande nouveauté parmi ces améliorations : le mode sombre est maintenant disponible sur l'ensemble de la documentation. Il vous suffit de modifier le paramètre dans le coin supérieur droit, et le site se souviendra de votre préférence. Pour de nombreux utilisateurs, le mode sombre rend le contenu plus lisible et réduit la fatigue oculaire.\n\n![image du mode sombre](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617168/gz45eaygeb0nizf1kwyu.png)\n\n### Alignement de la marque avec le site web\n\nLe nouveau design crée une harmonie visuelle entre notre documentation et l'expérience GitLab au sens large. Nous avons intégré la palette de couleurs et les éléments de design modernes de GitLab tout en conservant l'aspect épuré et fonctionnel que les utilisateurs attendent d’une documentation technique.\n\n![image de la nouvelle page d'accueil](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617230/ialfadj3i3theizk08p5.png)\n\nLa page d'accueil mise à jour se concentre sur nos principaux domaines de documentation, y compris les tutoriels et les guides de démarrage qui aident les nouveaux utilisateurs à se familiariser avec GitLab.\n\n### Mécanisme de retours simplifié\n\nNous avons simplifié le processus des retours. Au lieu d'obliger les utilisateurs à quitter la documentation et à créer des tickets GitLab, ils peuvent désormais laisser des commentaires et rédiger des avis sans quitter le site. Faites défiler n'importe quelle page de la documentation vers le bas pour voir cette nouvelle fonctionnalité en action.\n\n![image de la zone de commentaires](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617289/rjocpkmqumacaw7thjqi.png)\n\n### Refonte de la navigation\n\nL'un de nos plus grands défis consistait à organiser plus de 2 300 pages de manière à ne pas submerger les utilisateurs. Notre ancienne navigation à gauche, bien que complète, était plutôt intimidante :\n\n![image de l'ancienne navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617332/k75fwr3rhjxfjyxmc49d.png)\n\nDans cette refonte, la navigation principale a été déplacée vers le haut. Les sections de table des matières sont plus courtes, plus faciles à gérer et plus simples à parcourir :\n\n![image de la nouvelle navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617366/wziabrijury9jl5j7ica.png)\n\nCette structure reflète mieux les relations entre les fonctionnalités et rend les sections individuelles plus digestes.\n\n### Mises à jour stylistiques et dette technique\n\nAu fil des ans, de petites incohérences de style s'étaient accumulées : remplissage irrégulier dans les listes, espacement supplémentaire autour des alertes et divers problèmes de typographie. Bien qu'elles puissent sembler mineures, ces incohérences créaient une expérience légèrement dérangeante pour les utilisateurs quotidiens.\n\nNous nous sommes tout particulièrement penchés sur nos onglets et blocs de code au cours du processus de refonte afin de mieux les définir.\n\nAuparavant, les onglets contenant du code ressemblaient à ceci :\n\n![image des anciens onglets avec bloc de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617460/jsa2gz3b2slqu0udrg28.png)\n\nMaintenant, avec quelques petits ajustements, ils ressemblent à ceci :\n\n![image des nouveaux onglets avec bloc de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617493/jpxiybvnadsex39lyawu.png)\n\nCes corrections « mineures » peuvent sembler insignifiantes individuellement, mais collectivement, elles créent une expérience beaucoup plus soignée et professionnelle.\n\n## Et maintenant ?\n\nCette refonte représente la façon dont nous itérons chez GitLab : nous apportons des améliorations significatives et construisons un avenir encore meilleur. Nous prévoyons de continuer à affiner la structure et à ajouter des fonctionnalités qui aideront les utilisateurs à trouver plus facilement ce dont ils ont besoin.\n\nLes retours des utilisateurs guideront nos prochaines itérations, et avec notre nouveau mécanisme de retour simplifié, nous sommes mieux placés que jamais pour répondre directement aux attentes des utilisateurs de notre documentation.\n\n## L'équipe\n\nCette transformation a été le fruit d’un véritable travail d’équipe. Félicitations à UX Papercuts et Julia Miocene pour avoir transformé ce qui n'était au départ qu'une simple demande en une vision complète. Merci aux ingénieurs de l’équipe Technical Writing : Sarah German, Pearl Latteier, et Hiru Fernando, qui ont donné vie à ces améliorations.\n\nLe nouveau design trouve le juste équilibre entre densité des informations et clarté visuelle, modernise notre site tout en conservant les normes d'utilisabilité et d'accessibilité et représente une étape importante en matière d'expérience utilisateur et de design visuel.\n",{"featured":6,"template":808,"slug":1002},"docs-site-design-overhaul",{"content":1004,"config":1013},{"title":1005,"description":1006,"date":1007,"body":1008,"heroImage":1009,"authors":1010,"category":737,"tags":1012},"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",[1011],"Stan Hu",[268,772,749],{"featured":6,"template":808,"slug":1014},"inside-gitlabs-healthy-backlog-initiative",{"category":745,"slug":749,"posts":1016},[1017,1029,1041],{"content":1018,"config":1027},{"heroImage":1019,"date":1020,"authors":1021,"body":1023,"category":749,"tags":1024,"title":1025,"description":1026},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1757675943/q9kb7zfiw1cyxx9fcafp.png","2025-09-17",[1022],"Manav Khurana","Pour la deuxième fois consécutive, GitLab se distingue comme Leader dans le rapport Magic Quadrant™ 2025 de Gartner® dédié aux assistants IA pour le code. Cette distinction confirme un pilier essentiel de notre stratégie d'IA globale : l'évolution de l'assistance intelligente dédiée au code vers une IA complète qui transforme la façon dont les équipes planifient, développent, sécurisent et déploient leurs logiciels.\n\n![Rapport Magic Quadrant™ 2025 de Gartner® dédié aux assistants IA pour le code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758121248/jfkmhddve6qvlg79xico.png)\n\n> [Téléchargez le rapport complet.](https://about.gitlab.com/gartner-mq-ai-code-assistants/)\n\n## De l'IA à une collaboration intelligente\n\nL'évaluation de Gartner s'est concentrée sur les capacités d'assistance pour le code par IA générative de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo\"). Initialement conçu comme un module d'IA complémentaire à la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") de GitLab, GitLab Duo a posé les fondations de notre vision actuelle : une IA agentique intégrée nativement à la plateforme DevSecOps de GitLab.\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) permet aux équipes de développement de collaborer avec plusieurs agents d'IA qui automatisent des tâches tout au long du cycle de développement logiciel. Ces agents interagissent entre eux et avec les équipes de développement à l'aide du graphe de connaissances de GitLab afin d'avoir une compréhension complète du contexte du projet. Les équipes gagnent ainsi en rapidité tout en conservant visibilité et contrôle sur leurs processus.\n\n* **Des agents spécialisés** prennent en charge simultanément diverses tâches : génération de code, analyse de sécurité et recherche.\n* **Le graphe de connaissances** connecte les agents à un système de référence unifié qui couvre le code, les tickets, les pipelines et les données de conformité.\n* **La collaboration entre humains et agents** s'effectue par le biais d'un chat en langage naturel et de flows personnalisables, avec validation et supervision intégrées.\n* **L'interopérabilité avec les outils et les systèmes externes** est assurée grâce au Model Context Protocol (MCP) et aux frameworks Agent2Agent (A2A).\n\nÉtant donné que les agents gèrent les tâches routinières sous supervision humaine, les équipes peuvent accélérer leur cadence, se concentrer sur les activités à forte valeur ajoutée et maintenir la sécurité et la conformité de leurs projets.\n\n## Conception sécurisée et pratique flexible\n\nGitLab Duo Agent Platform place la [sécurité et la conformité](https://about.gitlab.com/fr-fr/solutions/application-security-testing/) au premier plan. Les agents s'exécutent dans l'environnement DevSecOps sécurisé de GitLab, et chaque action peut être suivie et vérifiée avant application des modifications. Les intégrations sécurisées garantissent une gestion sûre des identifiants et données sensibles, tandis que l'interopérabilité via des standards ouverts connecte les agents aux outils externes sans exposer l'entreprise à des risques.\n\nLa plateforme donne aux équipes l'assurance que l'IA améliore leur productivité sans nuire à la gouvernance.\n\nVoici comment chaque partie prenante en bénéficie :\n\n* **Les équipes de développement** se concentrent sur les tâches complexes à fort impact et délèguent les tâches routinières aux agents pour des résultats plus rapides et un contexte plus précis directement dans leurs workflows existants.\n* **Les responsables en ingénierie** gagnent en visibilité sur l'évolution des tâches tout au long du cycle de développement logiciel, car les agents opèrent dans un cadre clairement défini. Ils s'assurent que leurs équipes se concentrent sur les priorités et simplifient l'intégration des nouveaux arrivants à l'aide des agents, qui ont accès au contexte et aux workflows.\n* **Les entreprises informatiques** conservent le contrôle sur l'activité des agents grâce aux fonctionnalités de gouvernance qui appliquent les politiques de codage et de sécurité, offrent une flexibilité dans le choix des modèles et assurent une interopérabilité sécurisée avec une supervision humaine de bout en bout.\n\n## À la pointe du développement avec l’IA native\n\nGitLab poursuit le développement de GitLab Duo et ajoutera de nouveaux agents, des workflows avancés et des capacités d'orchestration étendues à GitLab Duo Agent Platform. Cet engagement en faveur de l'innovation renforce la productivité de vos équipes sur la plateforme que vous connaissez et en laquelle vous avez confiance. Suivez les mises à jour de notre roadmap et découvrez comment nous révolutionnons le DevSecOps avec l'IA native.\n\n> [Téléchargez le rapport Magic Quadrant™ 2025 de Gartner® dédié aux assistants IA pour le code](https://about.gitlab.com/gartner-mq-ai-code-assistants/) et [essayez GitLab Duo Agent Platform dès aujourd'hui](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/).\n\n*Source : Gartner, Magic Quadrant for AI Code Assistants, Philip Walsh, Haritha Khandabattu, Matt Brasier, Keith Holloway, Arun Batchu, 15 septembre 2025*\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 marque 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 une 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 Gartner est disponible sur demande auprès de Gartner B.V.*",[772,749,721],"GitLab nommée Leader dans le Magic Quadrant 2025 de Gartner dédié aux assistants IA pour le code","GitLab obtient à nouveau le titre de Leader dans le rapport Magic Quadrant™ 2025 de Gartner® dédié aux assistants IA pour le code pour sa vision et son exécution.",{"featured":6,"template":808,"slug":1028},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"content":1030,"config":1039},{"date":1031,"authors":1032,"heroImage":1034,"title":1035,"description":1036,"tags":1037,"category":749,"body":1038},"2025-09-15",[1033,957],"GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1751568278/bots3gyfarx8qysbkw6c.png","GitLab et Accenture annoncent un accord mondial de distribution","Ce nouvel accord permet à Accenture de proposer la plateforme DevSecOps complète de GitLab à l’ensemble de ses clients.",[749,772,721],"Nous sommes ravis d'annoncer que GitLab et Accenture ont signé un accord de distribution mondial, faisant d'Accenture un distributeur agréé GitLab et un fournisseur de services professionnels. Cet accord permet à Accenture de proposer la plateforme DevSecOps complète de GitLab directement à ses clients via plusieurs canaux de distribution, y compris AWS Marketplace.\n\n## Une étape importante dans notre collaboration\n\nCette collaboration associe la plateforme DevSecOps complète et intelligente de GitLab à l'expertise approfondie d'Accenture en matière de transformation numérique et de services de mise en œuvre, permettant aux organisations de créer et de livrer des logiciels sécurisés à grande échelle. Cet accord mondial fournit un cadre global qui peut être facilement adapté localement.\n\nCette collaboration se concentrera dans un premier temps sur plusieurs domaines clés :\n\n* **La transformation DevSecOps à l'échelle de l'entreprise :** aider les organisations à moderniser leurs pratiques de développement et à rationaliser leur cycle de livraison de logiciels\n* **La modernisation des mainframes :** accompagner les organisations à migrer depuis leurs systèmes hérités\n* **GitLab Duo combiné à Amazon Q :** proposer le développement logiciel piloté par l'IA aux organisations qui cherchent à accélérer leur vitesse de développement tout en maintenant la sécurité et la conformité de bout en bout\n\n## Perspectives d'avenir\n\nNous sommes impatients d'aider nos clients communs à accélérer l'innovation, à rationaliser leurs processus de développement et à renforcer leur posture de sécurité afin d’atteindre plus efficacement leurs objectifs commerciaux. \n\nPour plus d'informations sur la façon dont GitLab et Accenture peuvent aider votre organisation, consultez [notre site partenaire](https://about.gitlab.com/partners/channel-partners/#/2328213) ou contactez votre représentant Accenture ou GitLab.",{"featured":6,"template":808,"slug":1040},"gitlab-and-accenture-announce-global-reseller-agreement",{"content":1042,"config":1052},{"title":1043,"description":1044,"authors":1045,"heroImage":945,"date":1047,"body":1048,"category":749,"tags":1049,"updatedDate":1051},"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.",[1046],"Dave Steer","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/application-security-testing/) 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.*",[806,1050,749,784],"research","2024-11-26",{"slug":1053,"featured":91,"template":808},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"category":757,"slug":761,"posts":1055},[1056,1067,1080],{"content":1057,"config":1065},{"title":1058,"description":1059,"authors":1060,"date":1061,"body":1062,"category":761,"tags":1063,"heroImage":1064},"Qu’est-ce que Docker ? Notre guide complet","Découvrez ce qu’est Docker, comment il fonctionne, ses avantages et ses limites, et son intégration avec GitLab pour une approche DevSecOps complète.",[957],"2025-10-10","Docker a révolutionné la façon dont les équipes de développement créent, déploient et exécutent leurs applications grâce à une approche innovante : la conteneurisation. Cette approche est devenue incontournable dans le développement logiciel, car elle simplifie considérablement la gestion des environnements et accélère le cycle de développement logiciel. \n\nDans ce guide complet, découvrez tout ce qu'il faut savoir sur Docker : sa définition, son fonctionnement, ses avantages et son application dans un environnement [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSevOps ?\") avec la plateforme de GitLab. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial\n\"Essai gratuit de GitLab.\") \n\n## Docker : définition\n\nDocker est une plateforme de conteneurisation [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui permet aux équipes de développement d'empaqueter leurs applications et toutes leurs dépendances dans des conteneurs légers et portables. Lancé en 2013, Docker a démocratisé l'utilisation des conteneurs en proposant une solution simple et accessible pour créer des environnements d'exécution isolés.\n\n### Qu’est-ce qu’un conteneur Docker ?\n\nUn conteneur Docker représente un environnement d'exécution léger qui encapsule une application avec l'ensemble de ses composants : code source, bibliothèques, dépendances système, variables d'environnement et fichiers de configuration. Il peut parfois être comparé à une machine virtuelle dans le sens où il permet d’héberger des services sur un même serveur physique tout en les isolant les uns des autres. Néanmoins, le fonctionnement d’un conteneur diffère légèrement d’une simple machine virtuelle. \n\nMoins figés qu'une machine virtuelle, en matière de taille de disque et de ressources allouées, les conteneurs partagent le noyau de la machine hôte et isolent les processus, les utilisateurs, etc. Cela les rend très légers et leur permet de fonctionner comme s'ils étaient des machines distinctes. Par conséquent, les applications peuvent être démarrées et arrêtées rapidement.\n\n## Comment fonctionne Docker ?\n\nDocker révolutionne la virtualisation en exploitant les capacités natives du noyau Linux pour créer des environnements d'exécution légers et isolés. Contrairement à la virtualisation traditionnelle qui nécessite des machines virtuelles complètes avec leur propre système d'exploitation, Docker utilise la conteneurisation pour partager le noyau de l'hôte tout en maintenant une isolation parfaite entre les applications.\n\nLa philosophie de Docker repose sur des technologies Linux avancées telles que les namespaces (qui isolent les processus, le réseau et le système de fichiers) et les cgroups (qui limitent et contrôlent l'utilisation des ressources). Docker encapsule ces fonctionnalités complexes dans une interface simple et portable, permettant aux équipes de développement de créer des environnements cohérents sur n'importe quelle plateforme.\n\nLe processus de conteneurisation avec Docker suit un cheminement précis :\n\n1. **Création d'un Dockerfile :** ce fichier texte contient les instructions pour construire l'environnement\n2. **Construction d’une image docker** : Docker assemble les composants selon les spécifications du Dockerfile\n3. **Instanciation du conteneur** : l'image devient un conteneur exécutable\n4. **Gestion du cycle de vie** : démarrage, arrêt, surveillance et mise à jour des conteneurs\n\nPour comprendre pleinement le fonctionnement de Docker, il est essentiel de maîtriser les quatre composants fondamentaux suivants, qui contribuent à créer un écosystème de conteneurisation complet et efficace.\n\n### Docker Engine : le cœur du système\n\n[Docker Engine](https://docs.docker.com/engine/) est le moteur qui orchestre toutes les opérations de conteneurisation. Cette architecture client-serveur se compose de trois éléments interconnectés qui travaillent en harmonie :\n\n**Docker Daemon ([dockerd](https://docs.docker.com/reference/cli/dockerd/))** constitue le service central qui s'exécute en permanence sur le système hôte et gère l'ensemble du cycle de vie des conteneurs. Il supervise la création, l'exécution, la surveillance et la destruction des conteneurs, tout en gérant les images, les réseaux virtuels et les volumes de stockage. Ce daemon écoute en permanence les requêtes et exécute les opérations demandées.\n\n**L'API REST Docker** est le mode de communication principal avec Docker Daemon. Concrètement, quand vous lancez `docker run` ou [`docker build`](https://docs.gitlab.com/ci/docker/using_docker_build/), votre commande est transformée en requête HTTP qui est envoyée au daemon. Cette API permet également aux équipes de développement de créer leurs propres outils ou d'automatiser Docker dans leurs scripts et applications.\n\n**Le client Docker CLI** représente l'interface en ligne de commande que les utilisateurs emploient quotidiennement. Chaque commande `docker` (run, build, push, pull) transite par ce client qui communique avec le daemon via l'[API REST](https://about.gitlab.com/fr-fr/blog/2024/09/04/what-is-rest-api/ \"Qu'est-ce qu'une API REST ?\").\n\n### Images Docker : les modèles d'exécution\n\nUne **image Docker** constitue un modèle immuable et en lecture seule qui encapsule l'ensemble des éléments nécessaires à l'exécution d'une application. Cette image contient le système de fichiers complet, incluant le code source, les bibliothèques système, les dépendances, les variables d'environnement et les métadonnées de configuration.\n\nL'architecture en couches des images Docker représente l'une des innovations les plus importantes de cette technologie. Chaque instruction dans un Dockerfile crée une nouvelle couche et Docker utilise un système de cache intelligent pour réutiliser les couches communes entre différentes images. Cette approche optimise considérablement l'espace de stockage et accélère les processus de construction et de téléchargement.\n\nLes images sont identifiées par des tags qui combinent un nom et une version (comme `nginx:latest`, `ubuntu:20.04` ou `node:18-alpine`). Ces tags permettent aux équipes de développement de spécifier précisément quelle version d'une image utiliser dans leurs déploiements.\n\n### Dockerfile : automatiser la construction\n\nLe **Dockerfile** représente bien plus qu'un simple script d'instructions : il constitue la recette complète pour reproduire fidèlement un environnement d'exécution. Ce fichier texte utilise une syntaxe déclarative simple pour définir chaque étape de la construction d'une image.\n\nUn Dockerfile typique commence par spécifier une image de base (instruction FROM), puis enchaîne les opérations : installation de dépendances (`RUN`), copie de fichiers (`COPY` ou `ADD`), configuration d'environnement (`ENV`), exposition de ports (`EXPOSE`), et définition de la commande par défaut (`CMD` ou `ENTRYPOINT`).\n\nCette approche Infrastructure as Code garantit la reproductibilité parfaite des environnements et s'inscrit parfaitement dans les pratiques [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") actuelles. En documentant explicitement toutes les étapes de configuration dans un fichier versionable, le Dockerfile facilite la collaboration entre les équipes de développement et les opérateurs.\n\n### Docker Registry : partager et distribuer\n\nLes registres Docker fonctionnent comme des dépôts centralisés qui permettent de stocker, versioner et distribuer des images Docker de manière sécurisée. Ils constituent l'épine dorsale de l'écosystème Docker en facilitant la collaboration et le partage d'images.\n\n**[Docker Hub](https://www.docker.com/products/docker-hub/)** demeure le registre public officiel, hébergeant des millions d'images communautaires et officielles. Les équipes de développement peuvent y trouver des images prêtes à l'emploi : bases de données, serveurs web, etc. \n\nLes entreprises peuvent également déposer leurs images dans des **registres privés** garantissant la sécurité et le contrôle des accès. Ces registres privés peuvent être auto hébergés (on-premise) ou dans le cloud.\n\n## Pourquoi utiliser Docker ?\n\nLe développement d'applications fait face à des défis croissants : multiplication des environnements de déploiement, diversité des technologies utilisées, cycles de livraison accélérés et exigences de fiabilité toujours plus élevées. Les équipes de développement jonglent quotidiennement avec des problématiques complexes qui ralentissent leur productivité et augmentent les risques d'erreur.\n\nEn ce sens, Docker répond directement ou indirectement à ces problématiques récurrentes dans le développement logiciel.\n\n**Uniformisation des environnements** : Docker élimine le fameux « ça marche sur ma machine » en garantissant que l'application s'exécute de manière identique sur tous les environnements, du poste de développement à la production.\n\n**Simplification des déploiements** : l'empaquetage de l'application et de ses dépendances dans un conteneur unique simplifie considérablement les processus de déploiement et réduit les risques d'erreur.\n\n**Isolation des applications** : chaque conteneur dispose de son propre espace d'exécution, évitant les conflits entre différentes versions de bibliothèques ou de dépendances.\n\n**Accélération du développement** : les équipes de développement peuvent rapidement lancer des environnements complexes sans configuration manuelle fastidieuse.\n\n**Optimisation des ressources informatiques** : Docker permet une utilisation plus efficace des ressources serveur comparé aux machines virtuelles traditionnelles. Plusieurs conteneurs peuvent partager le même noyau système tout en maintenant leur isolation, réduisant ainsi l'empreinte mémoire et CPU. \n\nCette efficacité se traduit par :\n\n* Des temps de démarrage considérablement réduits\n* Une densité d'applications plus élevée par serveur\n* Une consommation énergétique optimisée\n* Des coûts d'infrastructure réduits\n\n## Quels sont les avantages de Docker ?\n\nMaintenant que nous avons vu pourquoi Docker est si populaire, intéressons-nous davantage aux avantages qu'il apporte concrètement aux équipes de développement. \n\n### Portabilité et cohérence\n\nDocker garantit que les applications fonctionnent de manière identique quel que soit l'environnement d'exécution. Cette portabilité facilite :\n\n* La migration d'applications entre différents fournisseurs cloud\n* Le déploiement sur des architectures hybrides (on-premise et cloud)\n* La création d'environnements de test fidèles à la production\n* La distribution d'applications complexes\n\n### Scalabilité et performance\n\nLes conteneurs Docker offrent une flexibilité exceptionnelle pour adapter les ressources aux besoins applicatifs :\n\n* **Montée en charge horizontale** : ajout rapide de nouvelles instances de conteneurs selon la demande\n* **Optimisation des ressources** : allocation précise des ressources CPU et mémoire par conteneur\n* **Démarrage instantané** : les conteneurs se lancent en quelques secondes contre plusieurs minutes pour les machines virtuelles\n* **Efficacité réseau** : gestion sophistiquée des réseaux virtuels entre conteneurs\n\n### Facilitation du DevOps\n\nDocker s'intègre naturellement dans les pratiques DevOps en :\n\n* Automatisant les processus de compilation et de déploiement\n* Facilitant l'intégration et le déploiement continus ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"))\n* Permettant des tests reproductibles dans des environnements isolés\n* Accélérant les cycles de développement et de livraison\n\n### Écosystème et communauté\n\nL'écosystème Docker bénéficie d'une communauté active qui développe :\n\n* Des milliers d'images officielles et communautaires sur Docker Hub\n* Des outils d'orchestration de conteneurs comme Docker Swarm (natif à Docker) et Kubernetes\n* Des solutions de monitoring et de logging adaptées aux conteneurs\n* Des intégrations avec les principales plateformes cloud\n\n## Quelles sont les limites de Docker ?\n\nComme nous venons de le voir, Docker présente de nombreux avantages, mais aussi certains inconvénients, dont il convient de prendre connaissance avec de plonger dans l’écosystème Docker.\n\n### Limitation à un seul système d'exploitation\n\nDocker crée plusieurs conteneurs sur un seul système d'exploitation. Si cette approche offre des avantages en termes de vitesse de démarrage et de traitement, elle peut également présenter des inconvénients. Par exemple, si vous souhaitez tester votre application dans un environnement Windows alors que votre machine hôte fonctionne sous Linux, vous devrez préparer une machine ou une machine virtuelle séparée.\n\n### Surcharge lors du développement à grande échelle\n\nDocker est léger en lui-même, mais lorsqu'il est étendu à un système de grande envergure, la charge de gestion de Docker entre en jeu. Docker peut faire fonctionner de nombreux conteneurs sur un seul serveur, mais d'un autre côté, cela nécessite une gestion et une orchestration qui peuvent générer une surcharge. Il peut également devenir difficile de tout gérer en utilisant Docker seul sans recourir à des outils d’orchestration comme Docker Swarm ou encore [Kubernetes](https://about.gitlab.com/fr-fr/blog/2024/07/25/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\").\n\n### Courbe d'apprentissage exigeante\n\nDocker utilise une méthode différente pour créer des environnements virtuels par rapport aux autres machines virtuelles. Cela signifie que les équipes de développement doivent apprendre et appréhender tous ces nouveaux concepts. Utiliser Docker sans bien comprendre son fonctionnement peut entraîner des problèmes par la suite. Il est important d'étudier Docker de manière approfondie avant de commencer à l'utiliser.\n\n### Vulnérabilités de sécurité potentielles\n\nDocker utilise une architecture basée sur les conteneurs. Comme plusieurs conteneurs fonctionnent sur une seule machine, il faut faire attention aux vulnérabilités qui peuvent en découler. Par exemple, s'il y a une vulnérabilité dans un conteneur, elle pourrait affecter tous les autres conteneurs qui partagent les ressources du système d'exploitation hôte et le noyau.\n\n### Difficultés dans la coopération entre conteneurs\n\nLorsque vous envisagez l'intégration entre plusieurs conteneurs, diverses configurations peuvent être difficiles, ce qui peut conduire à des problèmes opérationnels. Par exemple, si vous créez une application et une base de données dans des conteneurs séparés et souhaitez les faire fonctionner ensemble, vous devez configurer les paramètres de communication au sein du même hôte. L'ouverture de ports et de sockets pose des risques de sécurité. Si vous rendez les paramètres trop compliqués pour éviter cela, vous risquez alors de rencontrer des problèmes en production. Lors de l'intégration de conteneurs, il est important de bien réfléchir dès la phase de conception.\n\n### Comment GitLab résout les défis de Docker ?\n\nGitLab transforme Docker d'un simple outil de conteneurisation en une solution DevSecOps complète et sécurisée. Cette plateforme intégrée résout les principaux défis auxquels font face les organisations utilisant Docker à grande échelle.\n\nL'approche \"shift-left\" de GitLab intègre les contrôles de sécurité directement dans le pipeline de développement. Plutôt que de traiter la sécurité comme une étape finale, GitLab analyse automatiquement les images Docker dès leur construction, détectant les vulnérabilités, les configurations dangereuses et les dépendances obsolètes avant le déploiement. Cette détection précoce réduit considérablement les coûts de remédiation et élimine les risques de sécurité en production.\n\nGitLab Runner et ses pipelines CI/CD transforment la gestion des conteneurs Docker en automatisant l'ensemble du cycle de vie DevSecOps. Cette infrastructure d'exécution permet la construction automatisée d'images Docker optimisées, la validation automatique de la sécurité et des performances et l'orchestration sécurisée vers différents environnements.\n\n## Le rôle de Docker dans l’approche DevSecOps de GitLab\n\nDocker joue également un rôle très important dans l'intégration DevSecOps avec GitLab.\n\n### Conteneurisation des jobs CI/CD\n\nGitLab CI/CD vous permet d'utiliser des conteneurs Docker dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), vous apportant :\n\n* **Cohérence** : les jobs CI/CD s'exécutent dans des conteneurs, éliminant les erreurs dues aux différences de dépendances et d'environnements\n* **Scalabilité** : les conteneurs sont légers, rapides à démarrer et efficaces pour exécuter de larges pipelines\n* **Flexibilité d'environnement** : vous pouvez spécifier différentes images Docker pour chaque job, facilitant la mise à disposition de l'environnement requis\n\nL'image Docker GitLab Runner est basée sur Ubuntu ou Alpine Linux et inclut les commandes standard `gitlab-runner` qui la font fonctionner comme si vous aviez installé GitLab Runner directement sur l'hôte.\n\n### Scanning de sécurité automatisé\n\nLa sécurité est un composant clé de l’approche DevSecOps. GitLab la prend en charge dans les applications conteneurisées avec Docker à l’aide des scannings suivants : \n\n* **Scanning de sécurité des images de conteneurs** : fournit la capacité de scanner les images Docker dans vos pipelines CI/CD, vérifiant les vulnérabilités des packages OS afin d'évaluer la sûreté des images avant qu’elles n’atteignent l’environnement de production \n* **[Scanning en continue des vulnérabilités de conteneurs](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)** : recherche les failles de sécurité dans les dépendances existantes des applications en se basant sur leur SBOM et en comparant les noms et les versions des composants aux informations contenues dans les derniers avis de sécurité.\n* **[Scanning opérationnel de conteneurs](https://about.gitlab.com/blog/improve-security-auditing-with-gitlab-operational-container-scanning/)** : exécute les analyses de vulnérabilités sur les conteneurs déployés dans un environnement Kubernetes. Cela comprend l'analyse régulière des images à la recherche de nouvelles vulnérabilités découvertes et le suivi des environnements dans lesquels ces vulnérabilités sont déployées.\n\n### Infrastructure as Code (IaC) et gestion d'environnement\n\n* **Reproductibilité** : l’utilisation de Docker dans les jobs GitLab CI/CD assure la cohérence entre les environnements de développement et de production.\n* **Création instantanée d'environnements de staging et de test** : en s'intégrant avec Docker Compose et Kubernetes, GitLab vous permet de créer des environnements isolés pour des branches spécifiques ou des merge requests, permettant des tests efficaces et un scanning de sécurité.\n\n### Déploiement rationalisé\n\nGitLab supporte les modèles de déploiement suivants avec Docker :\n\n* **Compilation et push d'images Docker** : construisez votre application sous forme d’image de conteneur et effectuez un push vers le registre de conteneurs de GitLab ou d'autres registres Docker.\n* **[Livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ?\")** : utilisez des images Docker et déployez vers des outils d'orchestration de conteneurs pour des releases rapides et sécurisées.\n\n### Prise en charge de l'architecture de microservices\n\nGitLab et Docker ensemble facilitent la construction d'[architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\"), où les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ?\") s'exécutent comme des conteneurs Docker séparés. \n\nAvec les pipelines GitLab CI/CD, vous pouvez gérer :\n\n* La configuration des dépendances entre services\n* Les scans de sécurité individuels\n* Le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") (facilite les retours à une version précédente)\n\n## Conclusion\n\nDocker a transformé le paysage du développement logiciel en démocratisant la conteneurisation et en simplifiant la gestion des environnements d'exécution. Sa capacité à créer des applications portables, légères et facilement déployables en fait aujourd’hui un outil incontournable pour les équipes de développement.\n\nL'intégration native avec GitLab renforce encore davantage sa valeur en proposant une plateforme DevSecOps complète. Cette synergie permet aux entreprises d'accélérer leurs cycles de développement logiciel tout en maintenant des standards élevés de sécurité et de qualité.\n\nPour les équipes souhaitant moderniser leurs pratiques de développement, l'adoption de Docker représente un investissement stratégique qui se traduit par une productivité accrue, des déploiements plus fiables, une meilleure évolutivité et un environnement flexible.\n\n> Vous souhaitez installer GitLab dans un conteneur Docker ? Consultez notre [documentation](https://docs.gitlab.com/install/docker/) pour en savoir plus. \n\n## FAQ sur Docker\n\n### Que peut-on faire avec Docker ?\n\nDocker est une technologie de virtualisation légère et autonome qui empaquette le code d'application, ses dépendances et ses bibliothèques. Docker vous permet de créer plusieurs conteneurs (environnements virtuels) sur une seule machine, vous permettant d'unifier vos environnements de développement et de test. \n\n### À quoi sert Docker ?\n\nDocker est utilisé par les équipes de développement pour découpler les applications et leurs dépendances du reste du système. Les conteneurs regroupent les applications et leurs dépendances ensemble et fournissent un environnement d'exécution léger.\n\n### Docker peut-il remplacer les machines virtuelles ?\n\nDocker ne remplace pas complètement les machines virtuelles, mais offre une alternative plus légère pour de nombreux cas d'usage. Les conteneurs partagent le noyau du système hôte, tandis que les machines virtuelles émulent un système complet. Le choix dépend de vos besoins en isolation, performance et compatibilité système.\n\n*Note : certaines parties de cet article proviennent de l'article japonais [Dockerとは：超入門編](https://about.gitlab.com/ja-jp/blog/what-is-docker/).*",[721,109],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1760102032/qsxbap3mitapwa5tko76.jpg",{"featured":6,"template":808,"slug":1066},"what-is-docker-comprehensive-guide",{"content":1068,"config":1078},{"title":1069,"description":1070,"authors":1071,"heroImage":1073,"date":1074,"body":1075,"category":761,"tags":1076},"Nouveautés de Git 2.51.0","Découvrez les dernières contributions de l'équipe Git de GitLab et de la communauté Git, notamment les optimisations de performances pour git-push(1) et git-fetch(1).",[1072],"Karthik Nayak","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png","2025-08-25","Le projet Git a récemment publié la version [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u). En raison de l'été dans l'hémisphère nord et d'un développement plus lent, ce cycle de sortie de nouvelles versions a été plus court et a duré 8 semaines (au lieu des 12 semaines habituelles). Passons en revue certaines modifications notables de cette version, notamment les contributions de l'équipe Git de GitLab ainsi que de la communauté Git dans son ensemble.\n\n\n## Optimisations des performances pour `git-push(1)` et `git-fetch(1)`\n\n\n\nLes commandes `git-push(1)` et `git-fetch(1)` permettent aux utilisateurs de synchroniser les dépôts locaux et distants. Une partie de ces commandes consiste à mettre à jour les références dans le dépôt, ce qui peut prendre un temps considérable dans les dépôts comportant de nombreuses références, en particulier pour les utilisateurs qui travaillent avec de grands environnements de développement, des monorepos ou des dépôts avec des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu’est-ce qu’un pipeline CI/CD ?\") étendus.\n\n\n\nLes transactions de références Git peuvent inclure plusieurs mises à jour de références, mais elles suivent une approche « tout ou rien ». Si une seule mise à jour dans la transaction échoue, la transaction entière échoue, et aucune des mises à jour de références n'est appliquée. Cependant, les mises à jour de références dans `git-push(1)` et [`git-fetch(1)`](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/ \"Git Pull et Git Fetch\") sont autorisées à échouer, ce qui permet aux dépôts de synchroniser un sous-ensemble de références même si un sous-ensemble différent a divergé. Pour faciliter ce comportement, Git crée une transaction distincte pour chaque mise à jour de référence afin que certaines transactions réussissent même si d'autres échouent.\n\n\n\nLa création d'une transaction distincte par mise à jour entraîne une surcharge opérationnelle importante, car chaque transaction comprend une phase d'initialisation et de finalisation, et vérifie s'il existe des noms de références contradictoires. Le backend « reftable » effectue également un compactage automatique à la fin de chaque transaction. De multiples transactions peuvent ainsi déclencher plusieurs compactages automatiques, ce qui peut augmenter considérablement la latence de la commande.\n\n\n\nDans Git 2.51.0, ces commandes utilisent désormais des mises à jour par lots au lieu de transactions distinctes afin de mettre à jour plusieurs références dans une seule transaction, tout en autorisant certaines mises à jour à échouer. Cette approche élimine le surcoût lié aux initialisations, vérifications et finalisations répétées et supporte mieux la montée en charge du nombre de références à mettre à jour, puisqu'une seule transaction est utilisée. Les performances du backend « reftable » en sont considérablement améliorées, et ce dernier surpasse désormais le backend « files ». Ces améliorations de performances s'appliquent de manière transparente pour les utilisateurs.\n\n\n\nPour `git-fetch(1)`, nous constatons *des performances 22x meilleures pour le backend « reftable »* et *1,25x meilleures pour le backend « files »* lorsque cette commande est utilisée dans un dépôt avec 10 000 références.\n\n\n\n```\nBenchmark 1: fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      3.403 s ±  0.775 s    [User: 1.875 s, System: 1.417 s]\n  Range (min … max):    2.454 s …  4.529 s    10 runs\n\nBenchmark 2: fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n Time (mean ± σ):     154.3 ms ±  17.6 ms    [User: 102.5 ms, System: 56.1 ms]\n Range (min … max):   145.2 ms … 220.5 ms    18 runs\n\nSummary\n  fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   22.06 ± 5.62 times faster than fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: fetch: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):     605.5 ms ±   9.4 ms    [User: 117.8 ms, System: 483.3 ms]\n  Range (min … max):   595.6 ms … 621.5 ms    10 runs\n\nBenchmark 2: fetch: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     485.8 ms ±   4.3 ms    [User: 91.1 ms, System: 396.7 ms]\n  Range (min … max):   477.6 ms … 494.3 ms    10 runs\n\nSummary\n  fetch: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n   1.25 ± 0.02 times faster than fetch: many refs (refformat = files, refcount = 10000, revision = master)\n```\n\n\n\nPour `git-push(1)`, nous constatons des *performances 18x meilleures pour le backend reftable* et *1,21x meilleures pour le backend « files »* lorsque cette commande est utilisée dans un dépôt avec 10 000 références.\n\n\n\n```\nBenchmark 1: push: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      4.276 s ±  0.078 s    [User: 0.796 s, System: 3.318 s]\n  Range (min … max):    4.185 s …  4.430 s    10 runs\n\nBenchmark 2: push: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     235.4 ms ±   6.9 ms    [User: 75.4 ms, System: 157.3 ms]\n  Range (min … max):   228.5 ms … 254.2 ms    11 runs\n\nSummary\n  push: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   18.16 ± 0.63 times faster than push: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: push: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):      1.121 s ±  0.021 s    [User: 0.128 s, System: 0.975 s]\n  Range (min … max):    1.097 s …  1.156 s    10 runs\n\nBenchmark 2: push: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     927.9 ms ±  22.6 ms    [User: 99.0 ms, System: 815.2 ms]\n  Range (min … max):   903.1 ms … 978.0 ms    10 runs\n\nSummary\n  push: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.21 ± 0.04 times faster than push: many refs (refformat = files, refcount = 10000, revision = master)\n```\n\n\n\nCe [projet](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n\n## En route vers la version Git 3.0\n\n\n\nLa dernière version majeure de Git, la version 2.0, a été publiée il y a onze ans déjà. Bien que nous n'ayons pas de calendrier spécifique pour la prochaine version majeure de Git, la version 2.51.0 inclut déjà des décisions concernant Git 3.0.\n\n\n\nLa planification de la version Git 3.0 nous permet de prévoir et d'implémenter des changements rendant cette version incompatible avec les précédentes et de les communiquer à la communauté Git. En plus de la documentation, Git peut également être compilé avec ces changements incompatibles à des fins de test. Pour en savoir plus, consultez le [document BreakingChanges](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc).\n\n\n\nLa version Git 2.51.0 apporte des changements importants en préparation de Git 3.0.\n\n\n\n### Reftable comme backend de références par défaut\n\n\n\nDans la version [Git 2.45.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/), le format « reftable » a été introduit comme nouveau backend pour stocker les références comme les branches ou les tags dans Git, afin de corriger de nombreux problèmes avec le backend « files » existant. Consultez notre [guide du débutant sur le fonctionnement du format reftable](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/ \"Format reftable\") pour obtenir plus d'informations sur le backend « reftable ».\n\n\n\nLa version Git 2.51.0 marque le passage à l'utilisation du format « reftable » par défaut dans Git 3.0 pour les dépôts nouvellement créés et configure également le changement d'un feature flag. Le format « reftable » offre les améliorations suivantes par rapport au backend « files » traditionnel :\n\n\n\n* Il est impossible de stocker deux références avec pour seule différence la casse sur des systèmes de fichiers qui ne tiennent pas compte de la casse avec le format « files ». Ce problème est courant sur les systèmes Windows et macOS. Étant donné que le backend « reftable » n'utilise pas de chemins de système de fichiers pour encoder les noms de références, ce problème n'a plus lieu d'être.\n\n\n* De même, macOS normalise les noms de chemins qui contiennent des caractères unicode. Vous ne pouvez donc pas stocker deux noms avec des caractères unicode qui sont encodés différemment avec le backend « files », mais ce n'est pas un problème avec le backend « reftable ».\n\n\n* La suppression de références avec le backend « files » nécessite que Git réécrive le fichier complet « packed-refs ». Dans les grands dépôts avec de nombreuses références, ce fichier peut facilement faire des dizaines de mégaoctets, voire des gigaoctets. Le backend « reftable » utilise des marqueurs « tombstone » pour les références supprimées et n'a donc pas à réécrire toutes ses données.\n\n\n* La maintenance du dépôt avec le backend « files » effectue généralement des repacks tout-en-un des références. Cette approche peut être assez coûteuse, et par conséquent, la maintenance est un compromis entre le nombre de références seules par fichier qui s'accumulent et ralentissent les opérations qui lisent les références, et la compression de ces références non compactées en un seul fichier « packed-refs ». Le backend « reftable » utilise le compactage géométrique après chaque écriture, ce qui amortit les coûts et garantit que le backend est toujours bien entretenu.\n\n\n* Les opérations qui écrivent plusieurs références à la fois ne sont pas atomiques avec le backend « files ». Par conséquent, [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") peut voir des états intermédiaires lorsqu'il lit des références pendant qu'une transaction de référence est en cours de validation sur le disque.\n\n\n* L'écriture de nombreuses références à la fois est un processus lent avec le backend « files », car chaque référence est créée en tant que fichier séparé. Le backend « reftable » fournit des résultats considérablement meilleurs par rapport au backend « files ».\n\n\n* Le backend « reftable » utilise un format binaire avec compression de préfixe pour les noms de références. En conséquence, le format utilise moins d'espace par rapport au fichier « packed-refs ».\n\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n\n\n### SHA-256 comme fonction de hachage par défaut\n\n\n\nLe système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") Git stocke les objets dans un système de fichiers adressable par contenu. Cela signifie qu'il utilise le hachage d'un objet pour adresser le contenu tel que les fichiers, les répertoires et les révisions, contrairement aux systèmes de fichiers traditionnels, qui utilisent des nombres séquentiels. L'utilisation d'une fonction de hachage présente les avantages suivants :\n\n\n\n* Vérifications faciles de l'intégrité, car un seul bit inversé modifierait complètement le résultat du hachage.\n\n\n* Recherche d'objets rapide, car ces derniers peuvent être indexés par leur hachage.\n\n\n* Les noms d'objets peuvent être signés, et des tiers peuvent faire confiance au hachage pour adresser l'objet signé et tous les objets qu'il référence.\n\n\n* La communication via le protocole Git et les méthodes de communication hors bande disposent d'une chaîne de caractères courte et fiable qui peut être utilisée pour adresser de manière fiable le contenu stocké.\n\n\n\nDepuis sa création, Git a utilisé l'algorithme de hachage SHA-1. Cependant, des chercheurs en sécurité ont découvert quelques failles dans cet algorithme, en particulier l'[attaque SHAttered](https://shattered.io), qui montre une collision de hachage SHA-1 réalisable en pratique. Nous sommes passés à l'utilisation d'une implémentation SHA-1 renforcée par défaut depuis Git 2.13.0. Cependant, SHA-1 reste un algorithme de hachage faible, et ce n'est qu'une question de temps avant que des attaques supplémentaires ne diminuent encore davantage sa sécurité.\n\n\n\nSHA-256 a été identifié comme le successeur de SHA-1 fin 2018. Git 2.51.0 le marque comme l'algorithme de hachage par défaut à utiliser dans Git 3.0.\n\n\n\nCe projet a été mené par [brian m. carlson](https://github.com/bk2204).\n\n\n\n### Suppression de `git-whatchanged(1)`\n\n\n\nLa commande `git-whatchanged(1)` montre les logs avec les différences que chaque commit introduit. Bien que cette commande soit maintenant remplacée par `git log --raw`, elle a été conservée pour des raisons historiques.\n\n\n\nGit 2.51.0 oblige les utilisateurs de la commande à utiliser explicitement le flag `--i-still-use-this` pour identifier tous les utilisateurs qui utilisent encore cette commande dépréciée, et marque également la commande pour suppression dans Git 3.0.\n\n\n\nCe projet a été mené par [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano).\n\n\n\n## `git switch` et `git restore` ne sont plus en phase expérimentale\n\n\n\nLa commande `git-checkout(1)` peut être utilisée dans plusieurs cas d'utilisation différents. Elle peut être utilisée pour changer la référence courante :\n\n\n\n```\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n\n$ git checkout next\nSwitched to branch 'next'\nYour branch is up to date with 'origin/next'.\n```\n\n\n\nOu pour restaurer des fichiers :\n\n\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n$ git checkout git.c\nUpdated 1 path from the index\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n```\n\n\n\nPour les nouveaux utilisateurs de Git, ces différentes possibilités peuvent être source de confusion. Dans Git 2.33.0, elles ont été divisées en deux nouvelles commandes, `git-switch(1)` et `git-restore(1)`.\n\n\n\nLa commande `git-switch(1)` permet aux utilisateurs de basculer vers une branche spécifique :\n\n\n\n```\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n\n$ git switch next\nSwitched to branch 'next'\nYour branch is up to date with 'origin/next'.\n```\n\n\n\nEt la commande `git-restore(1)` permet aux utilisateurs de restaurer les fichiers de l'arbre de travail :\n\n\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n$ git restore git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n```\n\n\n\nCes deux commandes existent depuis 2019, mais étaient en phase expérimentale. Ce qui signifie que le projet Git ne garantissait pas la compatibilité avec les versions précédentes pour ces commandes, et le comportement pouvait changer à tout moment. L'objectif était initialement de stabiliser ces commandes après quelques nouvelles versions, mais cela n'a pas été le cas jusqu'à présent.\n\n\n\nCela a entraîné plusieurs discussions sur la liste de diffusion Git, où les utilisateurs se demandaient s'ils pouvaient commencer à utiliser ces nouvelles commandes, ou si celles-ci pourraient éventuellement disparaître à nouveau. Mais étant donné qu'aucun changement significatif n'a été proposé, et que certains utilisateurs utilisent déjà ces commandes, nous avons décidé de les retirer de leur phase expérimentale dans la version Git 2.51.\n\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n\n## Prise en charge de la pagination pour `git for-each-ref(1)`\n\n\n\nLa commande `git for-each-ref` est utilisée pour indiquer toutes les références présentes dans un dépôt. Comme elle fait partie de la couche de plomberie de Git, cette commande est fréquemment utilisée par les forges logicielles d'hébergement pour lister sur leur interface utilisateur les références qui existent dans le dépôt. Mais à mesure que les dépôts grandissent, il n'est pas réaliste de lister toutes les références à la fois, car les plus grands dépôts peuvent en contenir des millions ! À la place, les forges ont tendance à paginer les références.\n\n\n\nUne lacune importante émerge ainsi : `git-for-each-ref` ne sait pas ignorer les références des pages précédentes qui ont déjà été affichées. Par conséquent, cette commande peut devoir lister un grand nombre de références sans intérêt avant de commencer à indiquer les références requises pour la page actuelle. Ce processus est peu efficace et conduit à une latence plus élevée que nécessaire ou même à des délais d'attente dépassés.\n\n\n\nGit 2.51.0 prend en charge une nouvelle option `--start-after` pour `git for-each-ref`, qui permet de paginer les données de sortie. Il est aussi possible de la combiner avec l'option `--count` pour itérer sur un lot de références.\n\n\n\n```\n$ git for-each-ref --count=10\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n\n## Perspectives\n\n\n\nPrêt à découvrir ces améliorations ? Mettez à jour votre version Git et commencez à utiliser `git switch` et `git restore` dans vos workflows quotidiens.\n\n\n\nPour les utilisateurs de GitLab, ces améliorations de performances enrichiront automatiquement l'expérience de développement une fois la version de Git mise à jour.\n\n\n\nPour en savoir plus, consultez les [notes de version officielles de Git 2.51.0](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) et explorez notre [archive complète de le développement de Git](https://about.gitlab.com/fr-fr/blog/tags/git/).\n",[1077,904,268],"git",{"featured":6,"template":808,"slug":1079},"what-s-new-in-git-2-51-0",{"content":1081,"config":1091},{"description":1082,"title":1083,"category":761,"tags":1084,"heroImage":1085,"date":1086,"body":1087,"authors":1088},"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",[904,268,772],"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\nque nos contributeurs open source récurrents fusionnaient davantage de\nmodifications de code et collaboraient sur des fonctionnalités avancées, les\ncontributeurs novices, quant à eux, avaient du mal à se lancer. Nous étions\nconscients que beaucoup de nouveaux contributeurs open source finissaient\npar abandonner sans même demander de l'aide. Attachés à la [mission de\nGitLab](https://handbook.gitlab.com/handbook/company/mission/) où chacun\npeut contribuer, nous aspirions à inverser cette tendance.\n\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\n\nTrois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.\n\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\n## Ce que nous avons appris sur les nouveaux contributeurs\n\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\n\nVoici ce qu’ils nous ont dit : \n\n\n* La documentation destinée aux contributeurs était confuse\n\n* La prise en main était difficile \n\n* Trouver de l’aide n'était pas clair\n\n\nSeul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.\n\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\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\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\n## Création d’une intégration personnalisée\n\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\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\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\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\n![Ticket d'intégration GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\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\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\n## Standardisation des réponses avec des templates de commentaires\n\n\nAvec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.\n\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\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\n```yaml\n\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\n![Template de commentaire dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Suppression du temps d'attente de 5 minutes\n\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\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\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\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\n```json\n\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\n\n![Liste de pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Automatisation des suivis\n\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\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\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\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\n## Organisation du suivi des tickets avec GLQL\n\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\n![Vue GLQL du suivi des tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\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\n## Meilleure accessibilité du README\n\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\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\n![Mise en miroir de projet GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![README de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Les résultats parlent d'eux-mêmes\n\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\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\n![Graphique de croissance des forks de la communauté](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\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\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\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\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\n![Chronologie de l’analyse de la chaîne de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\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\n## Meilleure reconnaissance des contributeurs\n\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\n## Partager ce que nous avons appris\n\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\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\n**Contactez-nous**\n\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.\n",[1089,1090],"Lee Tickett","Daniel Murphy",{"featured":6,"template":808,"slug":1092},"how-we-use-gitlab-to-grow-open-source-communities",{"category":90,"slug":772,"posts":1094},[1095,1106,1118],{"content":1096,"config":1104},{"heroImage":1097,"date":1098,"title":1099,"description":1100,"authors":1101,"body":1102,"category":772,"tags":1103},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1758812952/yxhgljkwljld0lyizmaz.png","2025-09-29","GitLab nommée Leader dans le Magic Quadrant 2025 de Gartner dédié aux plateformes DevOps","GitLab se classe en première position dans 4 des 6 cas d'utilisation selon le rapport Critical Capabilities 2025 de Gartner® qui accompagne le Magic Quadrant.",[1022],"Pour la troisième année consécutive, GitLab a été nommée **Leader dans le Magic Quadrant™ 2025 de Gartner® dédié aux plateformes [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\")**, pour sa capacité d'exécution et l'exhaustivité de sa vision. Plus important encore, GitLab se classe en première position dans 4 des 6 cas d'utilisation : la livraison agile de logiciels, la livraison d'applications cloud-native, l’ingénierie de plateforme et la livraison réglementée, d'après le rapport Critical Capabilities 2025 de Gartner® dédié aux plateformes DevOps qui l'accompagne.\n\nCette reconnaissance valide, selon nous, notre stratégie de plateforme complète à un moment crucial pour le développement logiciel. Les organisations s'empressent d'adopter les capacités alimentées par l'IA tout en maintenant la sécurité, la conformité et l'excellence opérationnelle. Le succès exige une approche de plateforme unifiée qui transforme la façon dont les équipes collaborent et créent de la valeur.\n\nQue nos clients livrent des logiciels agiles, développent des applications cloud-native ou conçoivent des plateformes, GitLab leur permet de collaborer étroitement avec des agents d’IA pour livrer des logiciels sécurisés et fiables, plus rapidement. \n\n![Magic Quadrant™ 2025 de Gartner® pour les plateformes DevOps](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812615/sfchvkvtczmzqlaalk7y.png)\n\n\u003Cp>\u003C/p>\n\n> [Téléchargez les rapports](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/) pour en savoir plus.\n\n## Une durée de création de valeur accélérée\n\nNotre mission est de permettre à chacun de contribuer et de co-créer des logiciels qui font fonctionner notre monde. [Le rythme rapide de notre programme d'innovation](https://about.gitlab.com/fr-fr/blog/gitlab-18-4-ai-native-development-with-automation-and-insight/) démontre que nous sommes loin d'avoir terminé. Nous avons livré de nouvelles solutions à nos clients chaque mois pendant plus de 150 mois, et nous prévoyons de poursuivre cette tradition. \n\nEn tant que leader du secteur, nous restons déterminés à aider nos clients à transformer ces nouvelles capacités en valeur commerciale. \n\nNous sommes convaincus qu'à l'heure où l'innovation alimentée par l'IA s'accélère dans l'ensemble de l'écosystème technologique, il n'a jamais été aussi important qu'aujourd'hui d'adopter [une approche de plateforme unifiée](https://about.gitlab.com/fr-fr/blog/why-are-organizations-moving-to-a-unified-devsecops-platform/) pour relever les défis d'ingénierie les plus complexes de nos clients. Cette approche permet aux organisations de réduire les coûts d'intégration, de combler les failles de sécurité et d'adopter l'innovation sans perturber les workflows de livraison de logiciels existants. \n\nVoici quelques exemples : \n\n* **Accélérez les releases avec l'IA agentique :** les chaînes d'outils fragmentées ralentissent les revues de code et les tests. Les agents et les flows de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo ?\") automatisent un certain nombre de tâches comme les revues de code, la génération de tests et le tri des vulnérabilités dans le contexte de la plateforme complète, aidant les équipes à réduire les temps de cycle et à améliorer la qualité des logiciels.  \n* **Construisez de manière sécurisée dès le départ :** de nombreuses organisations traitent la sécurité comme une réflexion après coup, ce qui entraîne des rectifications coûteuses et des lacunes en matière de conformité. GitLab intègre l'analyse, l'application des politiques et les contrôles de conformité dans les workflows quotidiens, détectant les risques le plus tôt possible sans ralentir les équipes de développement. \n* **Déployez avec flexibilité :** les équipes soumises à des contraintes réglementaires ou opérationnelles strictes ont besoin d'options de déploiement allant au-delà du SaaS multilocataire. GitLab prend en charge les environnements SaaS, self-managed et air-gapped, afin de garantir aux clients un contrôle que les concurrents ne peuvent offrir.\n* **Offrez une innovation constante :** la fragmentation des outils rend l'adoption de nouvelles fonctionnalités risquée et perturbatrice. Les releases mensuelles de GitLab offrent de nouvelles fonctionnalités, telles que [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/), une gouvernance IA étendue et des intégrations cloud que les équipes peuvent adopter sans avoir à se rééquiper.\n\n## Les cas d'utilisation clients qui comptent le plus\n\nTout comme le Magic Quadrant, nous pensons que le rapport Critical Capabilities 2025 de Gartner dédié aux plateformes DevOps évalue la capacité des plateformes à répondre aux besoins réels des clients. GitLab s'est classée en première position dans 4 des 6 cas d'utilisation présentés dans ce rapport.\n\nGitLab prend en charge les domaines d'innovation suivants :\n\n* **[Ensemble d'outils intégrés](https://about.gitlab.com/fr-fr/platform/)** pour une livraison cloud-native et à l'échelle de l’entreprise  \n* **[Outils de planification avancés](https://about.gitlab.com/fr-fr/solutions/agile-delivery/)** et **[fonctionnalités de sécurité étendues](https://about.gitlab.com/solutions/application-security-testing/)**\n* **[Gestion des paquets](https://about.gitlab.com/stages-devops-lifecycle/package/)** et feature flags pour une livraison progressive  \n* **[Mesures de la chaîne de valeur](https://about.gitlab.com/fr-fr/solutions/analytics-and-insights/)** pour une visibilité et une amélioration tout au long du cycle de développement logiciel.   \n* **[Workflows avec l’IA native](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/)**, intégrés directement dans les tâches quotidiennes\n\nCette polyvalence se traduit par une réelle valeur ajoutée pour les clients, comme l'explique Bal Kang, Engineering Platform Lead chez NatWest : \n\n*« L'intégration des agents d’IA de GitLab Duo dans notre système d'enregistrement pour le code, les tests, le [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) et l'ensemble du cycle de développement logiciel stimule la productivité, la vélocité et l'efficacité. Les agents comprennent l'intention, décomposent les problèmes et agissent, devenant de véritables collaborateurs pour nos équipes. »*\n\nLe passage à des plateformes unifiées représente un changement fondamental dans la façon dont les organisations abordent le développement logiciel. C'est pourquoi, selon nous, Gartner® nous a également récemment nommé [Leader dans le Magic Quadrant™ 2025 dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants/).\n\nAlors que les entreprises cherchent à maximiser la productivité des équipes de développement de manière sécurisée et à accélérer l'innovation, une approche de plateforme complète devient plus urgente que jamais.\n\n> [Téléchargez les rapports](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/) pour en savoir plus.\n\n*Source : Gartner, Magic Quadrant for DevOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, 22 septembre 2025*\n\n*Source : Gartner, Critical Capabilities for DevOps Platforms, Thomas Murphy, Keith Mann, George Spafford, Bill Holz, 22 septembre 2025*\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 dans le monde, et MAGIC QUADRANT est une marque déposée de Gartner, Inc. et/ou de ses sociétés affiliées et 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, concernant 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 large et doit être évalué dans le contexte de l’ensemble du document. Le document Gartner est disponible sur demande auprès de Gartner B.V.*",[772,749,934],{"featured":6,"template":808,"slug":1105},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms",{"content":1107,"config":1116},{"title":1108,"description":1109,"authors":1110,"heroImage":1112,"date":1113,"body":1114,"category":772,"tags":1115},"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.",[1111],"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. Il s'agit d'une méthode simple et automatisée pour migrer des ressources GitLab entre instances GitLab vers 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 (intuitive et simple d'utilisation), ou [l'API](https://docs.gitlab.com/ee/api/bulk_imports.html) qui 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, il vous suffit de migrer directement tout groupe de niveau supérieur dont vous avez le rôle de propriétaire avec tous ses sous-groupes et projets.\n* La migration par transfert direct 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), pour 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 du nombre de fichiers à mesure que de nouveaux éléments sont importés. Ensuite, vous pouvez [vérifier les résultats de l'importation](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#review-results-of-the-import). Les éléments importés sont indiqués par le badge `Imported` 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/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 également minutieusement testé la sécurité et la stabilité des instances de cette nouvelle fonctionnalité.\n\nVoici deux exemples d'importations réussies qui illustrent la taille des groupes et des projets que nous avons testés, ainsi que leur durée d'importation :\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 cette solution [prendra en charge les instances hors ligne](https://gitlab.com/groups/gitlab-org/-/epics/8985).\n\nAvant toute 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 connaître les prochaines étapes à suivre une fois la migration terminée.\n\n### Examinez les options pour réduire la durée de migration\n\nSelon l'endroit où vous migrez (GitLab.com, une instance Self-Managed ou Dedicated) vous pouvez appliquer [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 avez la possibilité d'afficher les statistiques des éléments importés et d'examiner plus en détails les éléments qui 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 que certaines relations manquent encore dans un ou deux projets, comme des merge requests ou des tickets, nous vous recommandons d'essayer de réimporter ces projets [avec 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 proposer la migration par transfert direct et espérons que cette amélioration vous plaira ! Nous souhaitons connaître votre avis. Quelle est la fonctionnalité qui, selon vous, manque encore ? 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 !",[721,772,820],{"featured":91,"template":808,"slug":1117},"migrating-by-direct-transfer-is-generally-available",{"content":1119,"config":1128},{"title":1120,"description":1121,"authors":1122,"heroImage":899,"date":1125,"body":1126,"category":772,"tags":1127},"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.",[1123,1124],"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":1129,"featured":6,"template":808},"4-ways-to-accelerate-embedded-development-with-gitlab",{"category":780,"slug":784,"posts":1131},[1132,1143,1154],{"content":1133,"config":1141},{"heroImage":1134,"date":859,"title":1135,"description":1136,"authors":1137,"body":1139,"category":784,"tags":1140},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749663259/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images__3_.png","Connexion et commits sécurisés avec GitLab et Yubico","GitLab et Yubico se sont associés pour renforcer la sécurité du développement logiciel grâce à des mesures d'authentification robustes.",[1138],"Fernando Diaz","Nous vivons à une époque où les violations de données et les attaques de\nphishing font quotidiennement la une des médias. Ces violations peuvent\nnuire aux entreprises et entraîner des amendes réglementaires, des temps\nd'arrêt ou, pire encore, des atteintes à la réputation. En matière\nd'authentification, les mots de passe constituent la base de la sécurité en\nligne depuis des décennies, mais ils s'avèrent de plus en plus inadaptés\nface aux cybermenaces sophistiquées.\n\n\nGitLab et [Yubico](https://www.yubico.com/?lang=fr) se sont associés pour renforcer la sécurité du développement logiciel au moyen de mesures d'authentification robustes. Yubico est l'inventeur de la YubiKey, une clé de sécurité qui offre une authentification multifacteur (MFA) résistante au phishing. En implémentant le protocole FIDO Universal 2nd Factor (U2F) et la protection matérielle YubiKey, GitLab offre aux équipes de développement une défense puissante contre les attaques de phishing et autres cybermenaces afin de garantir la sécurité de leur code et de leurs projets. Cette collaboration renforce l'authentification de niveau entreprise dans la plateforme GitLab et aide les équipes de développement à se concentrer sur la création de logiciels et à avoir confiance en l'intégrité de leur compte.\n\n\nDécouvrez dans cet article comment configurer GitLab pour utiliser les YubiKeys afin de protéger vos équipes contre les menaces en ligne. Vous apprendrez également comment prévenir davantage la falsification de code avec les commits vérifiés de GitLab.\n\n\n## Comment fonctionnent les YubiKeys ?\n\n\nLes YubiKeys fonctionnent comme des tokens matériels cryptographiques qui génèrent et stockent des clés privées dans un environnement sécurisé. Ces clés implémentent les protocoles d'authentification FIDO2/WebAuthn, qui peuvent être utilisés comme facteur supplémentaire pour se connecter à GitLab.\n\n\nVoici comment la connexion fonctionne :\n\n\n1. Vous saisissez votre nom d'utilisateur et votre mot de passe.\n\n2. GitLab envoie un défi cryptographique à votre navigateur.\n\n3. Votre navigateur demande à la YubiKey de signer ce défi.\n\n4. Vous touchez physiquement la YubiKey pour approuver la connexion.\n\n5. La YubiKey crée une signature cryptographique unique pour ce service et ce défi spécifiques.\n\n6. GitLab vérifie la signature à l'aide de votre clé publique stockée lors de la configuration.\n\n\nLa plupart des violations de sécurité majeures sont liées à des mots de passe compromis. Une clé YubiKey garantit la sécurité de votre compte contre une violation à distance. En cas de vol de votre mot de passe, votre compte GitLab reste sécurisé.\n\n\nLa clé YubiKey offre d'autres avantages pour l'authentification sur GitLab :\n\n\n* **Protection contre le phishing :** les sites frauduleux n'auront pas les bonnes clés cryptographiques pour vérifier la réponse.\n\n* **Aucun secret à voler :** la clé privée ne quitte jamais la YubiKey.\n\n* **Sécurité physique :** une présence physique est requise pour la connexion (vous devez toucher la YubiKey).\n\n\n## Configuration de l'authentification multifacteur YubiKey dans GitLab\n\n\nVoyons maintenant comment configurer une YubiKey pour l'authentification multifacteur dans GitLab. Assurez-vous d'utiliser un [navigateur et un système d'exploitation pris en charge](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F), car ils offrent une meilleure compatibilité WebAuthn pour les clés de sécurité matérielles.\n\n\n1. Connectez-vous à votre compte GitLab et accédez à vos paramètres utilisateur (cliquez sur votre avatar dans le coin supérieur gauche et sélectionnez **Préférences**).\n\n\n2. Dans la barre latérale gauche, cliquez sur **Compte** et accédez à la section **Authentification à deux facteurs**.\n\n\n3. Si vous n'avez pas encore activé l'authentification à deux facteurs, faites-le maintenant.\n\n   a. Cliquez sur **Activer l'authentification à deux facteurs**.\n\n   b. Scannez le QR code avec votre application d'authentification.\n\n   c. Saisissez le code fourni par votre application d'authentification.\n\n   d. Saisissez votre mot de passe GitLab. Si vous avez besoin d’accéder à votre compte GitLab sans utiliser l'authentification Google, vous devrez peut-être :\n   * Utiliser l'option **Mot de passe oublié** sur la page de connexion GitLab pour configurer un mot de passe GitLab distinct.\n   * Contacter votre administrateur GitLab pour configurer une autre méthode de connexion.\n\n   e. Enregistrez vos codes de récupération dans un endroit sûr.\n\n4. Une fois l'authentification à deux facteurs activée, revenez à l'écran précédent en cliquant sur **Gérer l'authentification à deux facteurs** et faites défiler jusqu'à la section **Enregistrer un token matériel**.\n\n\n5. Cliquez sur le bouton **Configurer un nouvel appareil**.\n   a. Une fenêtre contextuelle de votre navigateur devrait apparaître. **Remarque :** cette image peut varier selon votre navigateur. Si des fenêtres contextuelles de vos gestionnaires de mots de passe s'affichent, ignorez-les.\n\n![Demande d'authentification du navigateur (Brave)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674606/Blog/Content%20Images/browser_auth_request.png)\n\n\n    b. Sélectionnez **Utiliser un téléphone, une tablette ou une clé de sécurité**.\n\n\n6. Une nouvelle fenêtre contextuelle apparaîtra.\n\n\n![Demande de clé de sécurité du navigateur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/browser_security_key_request.png)\n\n\n    a. Insérez votre YubiKey dans le port USB de votre ordinateur.\n\n\n    b. Touchez le contact métallique/bouton sur votre YubiKey lorsque vous y êtes invité. Le champ se remplira automatiquement avec un code à usage unique.\n\n\n7. Saisissez votre mot de passe GitLab et attribuez un nom à votre clé.\n\n\n8. Cliquez sur **Enregistrer** pour ajouter la YubiKey à votre compte.\n\n\nVotre YubiKey est maintenant enregistrée et peut être utilisée comme second facteur d’authentification lors de votre connexion à GitLab. Vous pouvez enregistrer plusieurs YubiKeys sur votre compte à des fins de sauvegarde. **Remarque :** le processus peut légèrement varier selon les navigateurs.\n\n\n![Yubikey enregistrée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/yubikey_registered.png)\n\n\n\u003Ccenter>\u003Ci>Enregistrement de la YubiKey\u003C/i>\u003C/center>\n\n\n## Comment se connecter avec une YubiKey sur GitLab ?\n\n\nMaintenant que votre  YubiKey est configurée, vous pouvez vous connecter comme suit :\n\n\n1. Accédez à GitLab.com.\n\n\n![Connexion à GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/gitlab_login.png)\n\n\n2. Indiquez votre nom d'utilisateur et votre mot de passe, puis cliquez sur le bouton **Se connecter**.\n\n\n3. Vous serez redirigé vers l'écran suivant.\n\n\n![Connexion à l'authentification à deux facteurs GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674606/Blog/Content%20Images/2fa_login.png)\n\n\n    a. Une fenêtre contextuelle, comme celle ci-dessous, devrait apparaître. **Remarque :** cette image peut varier selon votre navigateur. Si des fenêtres contextuelles de vos gestionnaires de mots de passe s'affichent, ignorez-les.\n\n\n![Demande de clé de sécurité du navigateur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/browser_security_key_request.png)\n\n\n    b. Insérez votre YubiKey dans le port USB de votre ordinateur.\n\n\n    c. Touchez le contact métallique/bouton sur votre YubiKey lorsque vous y êtes invité. Le champ se remplira automatiquement avec un code à usage unique.\n\n\nVous devriez être désormais connecté. Vous serez ensuite redirigé vers votre page GitLab.\n\n\n**Remarque :** le processus peut légèrement varier selon les navigateurs.\n\n\n## Que se passe-t-il si je perds ma YubiKey ?\n\n\nYubico recommande d'utiliser et de conserver une YubiKey de secours. Pensez à votre maison, votre voiture ou votre bureau : vous possédez sûrement une clé de secours dans un endroit sûr. Votre identité numérique devrait bénéficier du même niveau d’attention. Une deuxième YubiKey garantit une sauvegarde rapide et sûre si vous perdez votre clé principale et vous permet également de désactiver facilement la clé perdue et d'ajouter une nouvelle clé principale ou secondaire.\n\n\nSi vous n'avez pas ajouté de YubiKey supplémentaire, nous vous recommandons de configurer une autre forme d'authentification à deux facteurs à vos comptes. Dans les deux cas, vous devriez être en mesure d'accéder à votre compte et de retirer la clé perdue. Veuillez noter que sans une clé de sauvegarde ou une autre méthode d'authentification, vous devrez contacter le service/site web afin d'obtenir de l'aide pour récupérer votre compte.\n\n\n## Commits vérifiés de GitLab\n\n\nPour prévenir davantage la falsification de code, vous pouvez également configurer des commits vérifiés. Dans GitLab, ceux-ci utilisent des signatures GPG (GNU Privacy Guard) pour prouver qu’un commit provient réellement de vous. Ce processus ajoute une couche de sécurité en plus de l'authentification et garantit que non seulement votre compte est sécurisé, mais aussi que chaque modification de code peut être vérifiée de façon cryptographique comme provenant de vous.\n\n\nVotre YubiKey peut stocker des clés GPG :\n\n\n* La clé privée est stockée en toute sécurité sur la YubiKey.\n\n* La clé publique est partagée avec GitLab.\n\n* La paire de clés est utilisée pour signer vos commits.\n\n\nUne fois les clés GPG configurées :\n\n* Lorsque vous effectuez un commit, [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/) utilise votre clé privée pour créer une signature.\n\n* La clé GPG est accessible depuis la YubiKey connectée.\n\n* La signature est stockée avec les métadonnées du commit.\n\n* GitLab vérifie la signature à l'aide de votre clé publique.\n\n\n## Configuration des commits vérifiés\n\n\nVoyons comment configurer les commits vérifiés. Dans cet exemple, la clé GPG est stockée dans votre YubiKey et offre une couche de sécurité supplémentaire.\n\n\n1. Installez le logiciel requis.\n\n\n```bash\n\n\n# On macOS\n\n\nbrew install --cask yubico-yubikey-manager\n\n\nbrew install gnupg gpg yubikey-manager\n\n\n\n# On Ubuntu/Debian\n\n\nsudo apt install gnupg gpg yubikey-personalization\n\n\n\n# On Windows\n\n\n# Download and install Gpg4win from https://gpg4win.org\n\n\n```\n\n\n\n2. Vérifiez le statut GPG de la YubiKey.\n\n\n```bash\n\n\ngpg --card-status\n\n\n```\n\n\n3. Générez des clés GPG directement sur la YubiKey (processus plus sécurisé).\n\n\n```bash\n\n\n# Start GPG edit mode\n\n\ngpg --card-edit\n\n\n\n# Enter admin mode\n\n\nadmin\n\n\n\n# Generate key directly on card\n\n\n# PIN = '123456' | Admin PIN = '12345678'\n\n\ngenerate\n\n\n\n# Follow prompts\n\n\n# See documentation for more info\n\n\n#\n\nhttps://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP\n\n\n```\n\n\n4. Exportez votre clé publique.\n\n\n```bash\n\n\n# Get your key ID\n\n\ngpg --list-secret-keys --keyid-format LONG\n\n\n\n# Export the public key\n\n\ngpg --armor --export YOUR_KEY_ID\n\n\n```\n\n\n5. Ajoutez la clé publique à GitLab.\n\n   a. Cliquez sur votre Avatar GitLab et sélectionnez **Préférences**.\n\n   b. Dans l'onglet latéral, sélectionnez **Clés GPG**.\n\n   c. Cliquez sur **Ajouter une nouvelle clé**.\n\n   d. Collez votre clé publique.\n\n   e. Cliquez sur **Ajouter la clé**.\n\n6. Configurez Git.\n\n\n```bash\n\n\n# Set signing key\n\n\ngit config --global user.signingkey YOUR_KEY_ID\n\n\n\n# Enable automatic signing\n\n\ngit config --global commit.gpgsign true\n\n\n\n# Tell GPG which key to use\n\n\necho \"default-key YOUR_KEY_ID\" >> ~/.gnupg/gpg.conf\n\n\n```\n\n\n7. Testons maintenant la configuration en créant un commit test dans un projet :\n\n\n```bash\n\n\n# Make a change in the project\n\n\n# Add changes\n\n\ngit add .\n\n\n\n# Make a test commit\n\n\ngit commit -S -m \"Test signed commit\"\n\n\n\n# Verify signature\n\n\ngit verify-commit HEAD\n\n\n\n# Push the change\n\n\ngit push\n\n\n```\n\n\nLa commande `git verify-commit HEAD` devrait afficher la clé GPG utilisée :\n\n\n```bash\n\n\ngpg: Signature made Wed Feb 26 11:45:00 2025 CST\n\n\ngpg:                using RSA key YOUR_KEY_ID\n\n\ngpg: Good signature from “NAME (DESCRIPTION) \u003CEMAIL>\" [ultimate]\n\n\n```\n\n\nUne fois le commit effectué dans GitLab, vous devriez voir qu'il est vérifiée comme suit :\n\n\n![Le commit est vérifié](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/verified.png)\n\n\n\u003Ccenter>\u003Ci>Commit vérifié avec la clé GPG\u003C/i>\u003C/center>\n\n\nVous pouvez également utiliser l'[API des commits](https://docs.gitlab.com/api/commits/#get-signature-of-a-commit) pour vérifier la signature d’un commit, ce qui vous permet d'opérationnaliser davantage le workflow de vérification.\n\n\n## En savoir plus\n\n\nPour en savoir plus sur GitLab et Yubico, consultez ces ressources :\n\n\n* [Pourquoi choisir GitLab ?](https://about.gitlab.com/fr-fr/why-gitlab/)\n\n* [Pourquoi choisir Yubico ?](https://www.yubico.com/pourquoi-yubico/?lang=fr)\n\n* [Solutions de sécurité et de conformité de\n GitLab](https://about.gitlab.com/fr-fr/solutions/application-security-testing/)\n* [Annonce concernant GitLab dans le catalogue des plateformes compatibles avec YubiKey](https://www.yubico.com/works-with-yubikey/catalog/gitlab/)\n * [Documentation sur les commits verifiés de GitLab](https://docs.gitlab.com/ee/user/project/repository/signed_commits/)\n* [Règles de push dans\n GitLab](https://docs.gitlab.com/user/project/repository/push_rules/)\n* [Documentation relative à la signature de commits avec des clés GPG](https://docs.gitlab.com/user/project/repository/signed_commits/gpg/)\n",[784,821,806,233,772,820],{"featured":6,"template":808,"slug":1142},"secure-and-safe-login-and-commits-with-gitlab-yubico",{"content":1144,"config":1152},{"title":1145,"description":1146,"authors":1147,"date":1148,"body":1149,"category":784,"tags":1150,"heroImage":1151},"Gestion des vulnérabilités : le guide complet pour sécuriser vos logiciels","La gestion des vulnérabilités est un enjeu majeur. Découvrez comment sécuriser efficacement votre entreprise avec GitLab.",[957],"2025-09-26","Dans un contexte où les équipes de développement doivent livrer toujours plus rapidement et où les équipes de sécurité découvrent toujours plus de failles, les entreprises font face à une tension permanente qui génère inévitablement des retards et multiplie les risques.\n\nFace à ce défi, la gestion des vulnérabilités apporte une réponse concrète. En identifiant, priorisant et corrigeant les vulnérabilités de manière structurée, cette approche permet de maintenir la cadence de développement tout en renforçant la sécurité des logiciels. \n\nPour mettre en œuvre cette approche avec succès, ce guide vous présente les différents types de vulnérabilités et leurs risques, détaille chaque étape d'un processus de gestion efficace, et partage les meilleures pratiques en la matière. Vous découvrirez également comment la plateforme DevSecOps de GitLab peut optimiser cette démarche et sécuriser durablement vos développements logiciels.\n\n## Qu’est-ce que la gestion des vulnérabilités ?\n\n**La gestion des vulnérabilités**, appelée aussi *vulnerability management*, représente l'ensemble des processus destinés à identifier et à neutraliser les risques liés aux failles de sécurité dans les systèmes d'information.\n\nCette discipline essentielle de la cybersécurité s'articule autour d'un cycle qui comprend la détection proactive des vulnérabilités, leur classification selon leur niveau de sévérité, la définition des priorités de remédiation, le suivi des actions correctives et l’amélioration constante des pratiques de sécurité pour anticiper au mieux les futures menaces.\n\n> Vous souhaitez renforcer la sécurité de vos logiciels ? Commencez un [essai gratuit de GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/&glm_content=default-saas-trial) dès aujourd'hui !\n\n## Quels sont les différents types de vulnérabilité ?\n\nCes vulnérabilités, variées et en constante évolution, représentent une menace permanente pour les entreprises qui doivent s’adapter continuellement à un paysage de menaces en perpétuelle mutation. Dans une démarche de gestion structurée, il convient de distinguer deux grandes familles de vulnérabilités :\n\n* **Les vulnérabilités techniques :** elles sont liées aux logiciels, au matériel ou aux protocoles utilisés dans le système d'information. Les cyberattaques s'appuient le plus souvent sur des erreurs de programmation ou de configuration du code, des défauts conceptuels ou des versions obsolètes d'un logiciel. Les vulnérabilités des dépendances logicielles, les secrets exposés dans le code et les bogues non corrigés offrent aussi un angle d'attaque aux données du système. \n* **Le facteur humain :** il constitue le second type de vulnérabilité que les outils de gestion des vulnérabilités cherchent à maîtriser. Il peut s’agir d’une erreur humaine comme des pratiques de codage non sécurisées, d’un manque de sensibilisation aux bonnes pratiques en matière de sécurisation logicielle, ou encore d’une mauvaise communication entre les services de l’entreprise.\n\n## Quelles sont les conséquences d'une mauvaise gestion des vulnérabilités ?\n\nUne vulnérabilité non corrigée peut avoir des effets désastreux, tant sur le plan financier qu'humain. C’est une menace potentielle pour les entreprises, avec des répercussions à de nombreux niveaux :   \n\n* **Atteinte aux actifs.** La compromission de la sécurité peut entraîner la perte de ressources critiques, de données stratégiques et d'informations sensibles. Cela nuit aux processus internes, aux opérations commerciales et aux relations économiques de l'entreprise.\n* **Pertes financières.** Une faille de protection peut engendrer des coûts financiers considérables pour l’entreprise. Aux frais liés aux interruptions de service et aux pertes de productivité, il faut aussi ajouter la mise à jour des systèmes et parfois même le paiement de rançon aux cybercriminels.\n* **Conformité et amendes.** Les incidents de sécurité exposent l'entreprise à des poursuites judiciaires et à des amendes importantes en cas de non-conformité des systèmes, de préjudices subis par des tiers, et de manquement à des réglementations telles que le Règlement Général sur la Protection des Données (RGPD).\n* **Perte de réputation.** La vulnérabilité d'une entreprise met aussi en danger sa réputation et son image de marque. Si des informations sensibles de clients ou partenaires sont exposées, la perte de confiance qui en résulte assombrit les perspectives commerciales de l'entreprise. \n* **Impact sur la vélocité de développement.** Les vulnérabilités découvertes tardivement dans le cycle de développement ralentissent considérablement les déploiements et augmentent les coûts de correction.\n\n> D’après notre [rapport Global DevSecOps 2024 sur « La sécurité des applications à l'ère du numérique »](https://about.gitlab.com/fr-fr/developer-survey/2024/security-compliance/), 55 % des membres de l'équipe de sécurité affirment que les vulnérabilités sont principalement découvertes par la sécurité après le merge du code dans un environnement de test.\n\nPour se défendre, les entreprises se doivent d'adopter une approche proactive en matière de gestion des vulnérabilités et réduire ainsi au maximum leur surface d’attaque. \n\n## Comment mettre en place un processus de gestion des vulnérabilités ?\n\nLa complexité et la diversité des menaces exigent une réponse structurée et continue de la part des équipes de développement et de sécurité. Un processus de gestion des vulnérabilités efficace repose sur plusieurs étapes rigoureuses : \n\n1. **Identification des composants logiciels.** Avant d'identifier des vulnérabilités, il est essentiel de connaître l'étendue du code et des dépendances utilisées. Cette étape consiste à identifier les bibliothèques, frameworks et composants présents dans les logiciels, afin d'avoir une vision claire des éléments à surveiller. \n2. **Analyse des vulnérabilités.** Cette étape consiste à rechercher activement toutes les vulnérabilités présentes dans le code source et les dépendances, en les comparant aux bases de connaissance des vulnérabilités connues afin d'identifier les menaces. Pour cela, il est recommandé de mettre en place des tests de sécurité automatisés (SAST, DAST, analyse des dépendances) afin de corriger ces vulnérabilités le plus tôt possible. \n3. **Hiérarchisation des risques.** En gestion des vulnérabilités, toute faiblesse ne présente pas le même niveau de risque. L'étape d'évaluation des risques permet de prioriser les failles en fonction de leur facilité d'exploitation, de leur [niveau de sévérité](https://docs.gitlab.com/user/application_security/vulnerabilities/severities/), et de leur impact potentiel sur l’entreprise et ses clients.\n4. **Correction et vérification.** Une fois les vulnérabilités identifiées et hiérarchisées, les actions correctives interviennent à travers des corrections de code, des modifications architecturales ou des mises à jour de dépendances. Les corrections sont testées avant et après la mise en production pour garantir la résolution complète des vulnérabilités. Pour accélérer ce processus, GitLab permet notamment à ses utilisateurs de suggérer des corrections automatiques et de créer des merge requests à l’aide de l’IA.\n5. **Surveillance continue.** La surveillance en temps réel permet de détecter les nouvelles expositions aux menaces et de rester agile face à l'évolution des risques. Cette surveillance doit s’opérer tout au long du développement de logiciels, avant, pendant et après la mise en production. \n\nEnfin, les processus et outils de gestion des vulnérabilités incluent une réévaluation périodique. Chaque étape est régulièrement réévaluée à mesure que le panorama des menaces change et que les logiciels et les langages de programmation évoluent. Ce cycle itératif garantit un niveau de sécurité optimal et actualisé. Une approche continue et adaptative de la gestion des vulnérabilités différencie une entreprise bien protégée d'une autre à risque.\n\n### Intégrez la sécurité à chaque étape du cycle de développement avec l’approche DevSecOps\n\nL'approche [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") représente un changement fondamental dans la gestion des vulnérabilités. Plutôt que de traiter la sécurité comme une étape finale, elle l'intègre tout au long du cycle de développement logiciel. \n\nCette approche « shift left » permet :\n\n* **D’anticiper les risques :** l'identification précoce des vulnérabilités réduit drastiquement les coûts de correction et évite les retards de livraison.\n  Responsabiliser les équipes : la sécurité devient une responsabilité partagée, transformant chaque membre de l'équipe en gardien de la qualité du code.\n* **Automatiser les processus :** l'automatisation des analyses libère les équipes des tâches répétitives et accélère la résolution des problèmes.\n* **Améliorer la collaboration entre les équipes :** le rapprochement des équipes Dev et Sec favorise une communication fluide et une résolution plus rapide des vulnérabilités.\n\nLes entreprises comme [Airbus](https://about.gitlab.com/fr-fr/customers/airbus/) qui utilisent GitLab bénéficient de cette approche pour protéger leur code, grâce à l’ajout de scans de sécurité et de vulnérabilité aux tests d'intégration. *« Auparavant, toute modification d'une portion du code affectait le fonctionnement d'une autre portion. Nous pouvons désormais identifier les problèmes éventuels dès qu'un développeur effectue un push du code »*, explique Logan Weber, Software Automation Engineer chez Airbus.\n\n## Gestion des vulnérabilités : nos bonnes pratiques\n\nL'évolution rapide des technologies et l'augmentation constante des cybermenaces oblige chaque entreprise à mettre en place les meilleures pratiques de gestion des vulnérabilités (ou vulnerability management). Elles impliquent le changement des habitudes de travail, la modernisation des méthodes de communication, et la sensibilisation des équipes, y compris du management, à ces différents sujets.  \n\nDécouvrez nos bonnes pratiques pour sécuriser vos logiciels : \n\n* **Approche proactive.** La prévention constitue le pilier d'une stratégie de sécurité efficace. Anticiper les vulnérabilités et déployer des mesures préventives s'avère infiniment plus rentable que de réagir après qu’une faille de sécurité ne soit exploitée. Cette démarche d'anticipation, associée à une capacité d'adaptation face aux évolutions technologiques, permet aux entreprises de transformer la gestion des vulnérabilités en avantage concurrentiel plutôt qu'en contrainte opérationnelle.\n* **Collaboration des équipes.** Les processus bureaucratiques constituent un frein majeur à la résolution rapide des vulnérabilités, affectant plus de la moitié des équipes de sécurité selon notre [Rapport Global DevSecOps 2024](https://about.gitlab.com/fr-fr/developer-survey/). Face à ce constat, l'établissement d'une communication directe et efficace entre les équipes DevSecOps devient essentiel. Cette collaboration optimisée facilite le partage d'informations stratégiques, accélère l'intégration des correctifs en production et garantit une prise en compte continue des enjeux de sécurité à chaque étape du développement logiciel.\n* **Formation des employés.** Des équipes bien formées aux pratiques de codage sécurisé peuvent significativement réduire les vulnérabilités introduites dans le code. La sensibilisation aux vulnérabilités courantes, ainsi que l'utilisation d'outils d'analyse automatisée, renforcent la sécurité à chaque étape du SDLC.\n* **Consolidation des outils.** Remplacer une multitude d'outils disparates par une plateforme unifiée réduit les inefficacités causées par le changement de contexte et améliore la visibilité globale sur la sécurité au sein de l’entreprise.\n\n### Des défis toujours à relever\n\nLes bonnes pratiques en matière de gestion des vulnérabilités reposent avant tout sur l'implication et la collaboration de toutes les équipes autour de ces questions. Les défis sont d'autant plus grands que certaines difficultés accompagnent la sécurisation des logiciels dans les environnements de développement modernes : \n\n* La complexité croissante des dépendances logicielles complique l'identification des vulnérabilités et la prise de décision.\n* Une approche continue peut être difficile à maintenir pendant les périodes de forte activité de développement.\n* Les processus manuels d'analyse des vulnérabilités rendent le travail des équipes fastidieux et peu fiable.\n* Le manque de collaboration entre les équipes de développement et de sécurité ralentit le processus de résolution des vulnérabilités.\n* La détection tardive des failles de sécurité dans le cycle de développement engendre des coûts supplémentaires à l’entreprise.\n* Les exigences réglementaires complexifient la gestion des vulnérabilités.\n\nPour relever ces défis, les entreprises doivent s'appuyer sur des outils modernes, une meilleure intégration de la sécurité dans les processus de développement et une collaboration efficace entre les équipes.\n\n## Comment améliorer votre gestion des vulnérabilités avec GitLab ?\n\nGitLab adopte une approche DevSecOps intégrée qui permet aux équipes d'identifier et de corriger les vulnérabilités le plus tôt possible dans le cycle de développement logiciel.\n\nPour cela, la plateforme propose les fonctionnalités suivantes : \n\n* **Scanners de sécurité :** ces scanners incluent les tests statiques de sécurité des applications (SAST) et les tests dynamiques de sécurité des applications (DAST), l’analyse des dépendances, l’analyse des conteneurs, la détection des secrets, l’analyse de l'Infrastructure as Code (IaC), ainsi que les tests à données aléatoires. Ils s'exécutent automatiquement dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), garantissant une couverture de sécurité exhaustive sans ralentir le développement.\n* **[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo ?\") :** GitLab Duo assiste les équipes de développement tout au long de leur processus de développement logiciel. Cette suite de fonctionnalités alimentées par l’intelligence artificielle analyse les vulnérabilités détectées, fournit des explications contextuelles et propose des solutions de corrections adaptées, permettant une résolution plus rapide et plus efficace des problèmes de sécurité.\n* **Tableaux de bord et rapports :** les tableaux de bord de sécurité et rapports de vulnérabilités offrent une vue d'ensemble en temps réel du niveau de sécurité des logiciels. Cette visibilité facilite le suivi des corrections, la priorisation des actions et la communication avec les parties prenantes.\n* **Processus d’approbation :** la gestion des vulnérabilités commence aussi par une bonne gestion des droits de modifications. GitLab permet d’automatiser un processus d’approbation si des vulnérabilités sont détectées, garantissant une revue poussée des modifications introduisant des vulnérabilités potentielles. \n\n> Vous souhaitez renforcer la sécurité de vos logiciels ? Commencez un [essai gratuit de GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/&glm_content=default-saas-trial) dès aujourd'hui !",[806,784],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758890538/ct0ffsxm1eyfeppyrnjt.jpg",{"featured":6,"template":808,"slug":1153},"what-is-vulnerability-management",{"content":1155,"config":1166},{"title":1156,"description":1157,"authors":1158,"heroImage":1160,"date":1161,"body":1162,"category":784,"tags":1163},"Optimisez la gestion des écarts de conformité avec GitLab","L'équipe Security Compliance de GitLab gère les écarts de conformité sur la plateforme DevSecOps, et renforce visibilité, collaboration et responsabilisation.",[1159],"Madeline Lake","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-08-26","Un écart de conformité est mis en évidence lors de la surveillance des contrôles de sécurité et correspond à une déviation entre le fonctionnement attendu d’un contrôle de sécurité et son comportement réel. Il peut résulter d'un défaut de conception (contrôle de sécurité mal défini et qui ne satisfait pas les exigences), d'un manque d'efficacité opérationnelle (contrôle inefficace), ou encore d'un manque de preuves (absence de documentation ou de preuve d'exécution du contrôle).\n\nChez GitLab, nous détectons ces écarts de conformité principalement lors de notre processus de surveillance trimestriel qui évalue systématiquement l'efficacité des contrôles de sécurité soutenant nos certifications (SOC 2, ISO 27001, etc.) ou lors d'audits externes par des évaluateurs indépendants. Au-delà des lacunes en matière de conformité, ils reflètent les risques de sécurité avérés, qui nécessitent l'application rapide de mesures correctives traçables.\n\nLe processus de gestion des écarts de conformité se décompose en plusieurs étapes, depuis leur identification jusqu'à leur résolution complète, en passant par les mesures correctives. Dans cet article, découvrez comment l'équipe Security Compliance de GitLab s'appuie sur la plateforme DevSecOps pour gérer et remédier aux écarts de conformité, ainsi que les gains d'efficacité obtenus grâce à cette approche.\n\n## Le cycle de vie d'un écart de conformité chez GitLab\n\nCe cycle englobe l'ensemble du processus, de l'identification des écarts de conformité par l'équipe en charge de la conformité jusqu'à leur résolution complète par les responsables chargés de la remédiation. Ce cadre structuré permet un suivi transparent en temps réel, simple à comprendre par toutes les parties prenantes.\n\nIl se compose des étapes suivantes :\n\n**1. Identification**\n\n* Les équipes responsables de la conformité identifient les éventuels écarts de conformité lors de la surveillance trimestrielle des contrôles de sécurité.  \n* Une validation initiale est effectuée pour confirmer la non-conformité.  \n* Dès cette étape, un ticket GitLab est créé avec une documentation détaillée.  \n* La cause profonde de l'écart de conformité est déterminée et un plan de remédiation est établi.\n\n**2. Validation**\n\n* Le ticket est attribué au responsable de la remédiation concerné (chef d'équipe ou manager).  \n* Ce dernier l'examine et confirme qu'il en accepte la propriété.  \n* Le plan de remédiation est examiné, priorisé et ajusté de manière collaborative, le cas échéant.\n\n**3. Mise en œuvre**\n\n* Les actions de remédiation commencent par la définition de jalons et d'échéances clairs.  \n* Des retours sont ajoutés directement dans le ticket GitLab et son statut est mis à jour. \n* La collaboration s'effectue de manière transparente : toutes les parties prenantes peuvent suivre la progression du ticket.\n\n**4. Remédiation**\n\n* Le responsable de la remédiation exécute les actions correctives et les marquent comme terminées, tout en fournissant les preuves de leur mise en place. \n* Le ticket passe à l'étape de revue de la conformité à des fins de validation.\n\n**5. Résolution**\n\n* L'équipe de conformité vérifie que tous les critères définis pour pouvoir clôturer le ticket sont respectés.  \n* Le ticket incluant une documentation complète est ensuite fermé.  \n* Les leçons tirées du cycle de l'écart de conformité sont consignées afin de prévenir des cas similaires à l'avenir.\n\nDes **processus alternatifs** sont prévus pour les cas bloquants, les risques acceptés ou les retards, avec des workflows d'escalade adaptés.\n![Exemple de cycle de vie d'un écart de conformité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753301753/pbvheikwpivuvhzd5ith.png)\n\u003Ccenter>\u003Ci>Exemple de cycle de vie d'un écart de conformité\u003C/i>\u003C/center>\n\n## La force de la transparence avec GitLab\n\nAvec une gestion efficace des écarts de conformité, l'accès aux métadonnées de base, à savoir la propriété, le statut ou le niveau de priorité, ne doit demander aucun effort. Pourtant, dans de nombreuses entreprises, c'est exactement le contraire : les équipes de conformité doivent sans cesse relancer pour obtenir la moindre mise à jour, les équipes des opérations ignorent leurs responsabilités, et la direction manque de visibilité sur l'exposition réelle aux risques jusqu'au moment de l'audit.\n\nL'équipe Security Compliance de GitLab a rencontré les mêmes difficultés. Elle a d'abord utilisé un outil GRC dédié comme source unique de vérité pour les écarts de conformité les plus critiques. Mais, faute de visibilité pour les principales parties prenantes, très peu de mesures de remédiation étaient effectivement mises en œuvre, car l'équipe passait la plupart de son temps sur des tâches administratives. \n\nNous avons finalement migré la gestion des écarts de conformité directement dans GitLab, à l'aide de tickets regroupés dans un projet dédié. Ainsi chaque écart de conformité devient un élément de travail visible et exploitable, naturellement intégré au workflow des équipes de développement et des opérations. Chaque contributeur peut identifier les sujets prioritaires, collaborer à l'élaboration des plans de remédiation et suivre les progrès en temps réel, favorisant ainsi une transparence et une responsabilisation que les outils traditionnels sont incapables d'offrir.\n\n### Une organisation intelligente avec les labels et les tableaux de tickets\n\nGitLab permet de classer les tickets d'écarts de conformité en différentes vues et catégories pour une organisation flexible. L'équipe Security Compliance de GitLab organise ses tickets de la manière suivante :\n\n* **Workflow :** `~workflow::identified`, `~workflow::validated`, `~workflow::in progress`, `~workflow::remediated`  \n* **Équipe concernée :** `~dept::engineering`, `~dept::security`, `~dept::product`   \n* **Gravité du risque :** `~risk::critical`, `~risk::high`, `~risk::medium`, `~risk::low`  \n* **Système impacté :** `~system::gitlab`, `~system::gcp`, `~system::hr-systems`   \n* **Programme de conformité :** `~program::soc2`, `~program::iso`, `~program::fedramp` , `~program::pci`\n\nCes labels permettent de créer des tableaux de tickets personnalisés :\n\n* Les **tableaux par workflow** pour une vue claire des étapes du cycle de vie de chaque écart de conformité.  \n* Les **tableaux par équipe** pour visualiser la charge de travail de chaque équipe liée à la remédiation.  \n* Les **tableaux par niveau de risque** pour prioriser les écarts de conformité critiques nécessitant une action immédiate.  \n* Les **tableaux par système** pour regrouper les écart de conformité liés à un environnement ou une plateforme spécifique.  \n* Les **tableaux par programme** pour le suivi des tâches de remédiation en fonction des certifications associées.\n\nLes labels permettent également de définir des filtres et de générer des rapports de façon optimale, tout en facilitant l'automatisation des workflows grâce aux politiques définies par notre bot de classement. Pour en savoir plus, consultez la section dédiée à l’automatisation.\n\n## La puissance de l'automatisation\n\nGérer des dizaines d'écarts de conformité liés à plusieurs certifications nécessite une automatisation intelligente. Notre équipe Security Compliance s'appuie pour cela sur le [bot de classement par priorité](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), un projet open source hébergé sur GitLab. Ce bot, mis à disposition sous forme d'une gemme, permet de classer automatiquement les tickets au sein des projets ou groupes GitLab en fonction de politiques prédéfinies, et ainsi de les organiser de manière structurée. De cette façon, les parties prenantes peuvent concentrer leurs efforts sur la remédiation plutôt que sur la gestion administrative. \n\nNotre projet dédié regroupe nos politiques d'automatisation alignées sur les bonnes pratiques : chaque ticket doit disposer d'un responsable assigné, il doit inclure les labels requis, il doit être mis à jour au moins tous les 30 jours, et les tickets bloqués ou en attente doivent être relancés tous les 90 jours. En outre, un ticket récapitulatif est généré chaque semaine : il répertorie tous les tickets qui ne respectent pas ces politiques. Les membres de l'équipe restent ainsi concentrés sur la remédiation en se libérant des tâches administratives.\n\n## Le potentiel des rapports et indicateurs de performance\n\nLes données brutes issues des tickets GitLab offrent une source précieuse d'informations stratégiques. En analysant des métadonnées telles que les dates de création, de clôture, de dernière mise à jour ou encore les labels appliqués, les équipes dirigeantes peuvent en tirer des enseignements concrets pour optimiser la gestion des écarts de conformité. Voici les indicateurs clés pour évaluer l’efficacité de votre processus :\n\n**Analyse de l'efficacité de la remédiation :** délai moyen entre l'identification et la résolution de l'écart de conformité, ventilé par équipe et niveau de gravité.\n\nComparez les dates de création et de clôture des tickets en fonction des équipes et du niveau de gravité pour identifier les goulots d'étranglement et évaluer la performance par rapport aux accords de niveau de service (SLA). Cette approche met en évidence les équipes les plus réactives, ainsi que celles qui ont besoin de ressources supplémentaires ou d'optimiser leur processus.\n\n**Évaluation du risque en temps réel :** profil de risque actuel basé sur les écarts de conformité critiques exposant à des risques majeurs, et dont les tickets sont encore ouverts.\n\nTirez parti des labels de niveau de risque pour obtenir une vue instantanée du niveau actuel d'exposition aux risques de votre entreprise. De cette manière, vous identifiez immédiatement les écarts de conformité critiques nécessitant une attention immédiate.\n\n**Allocation stratégique des ressources :** cartographie des risques par équipe pour orienter les efforts\n\nIdentifiez les équipes responsables de la remédiation des écarts de conformité les plus critiques afin de concentrer les ressources, de renforcer le suivi et de prioriser les projets. Cette approche fondée sur les données garantit un impact maximal.\n\n**Suivi de la préparation à la conformité :** nombre d'écarts de conformité par certification et taux de résolution.\n\nUtilisez les labels de certification pour évaluer le niveau de préparation aux audits et suivre la progression vers les objectifs de conformité. Cet indicateur permet d'anticiper les risques de non-conformité à une certification spécifique et valide l'efficacité des actions de remédiation.\n\n**Suivi de la responsabilisation :** identification des remédiations en retard. \n\nL'analyse des délais via les métadonnées des tickets permet de détecter les irrégularités par rapport aux SLA. Cet indicateur met en évidence les retards systémiques et favorise les interventions proactives avant qu'ils ne compromettent la sécurité ou la conformité.\n\n**Contrôle de l'engagement :** mise à jour de l'état des écarts de conformité.\n\nSuivez les mises à jour récentes (30 derniers jours) pour vous assurer que les écarts de conformité sont activement pris en charge. Cet indicateur identifie les tickets non traités qui peuvent nécessiter une réattribution ou une relance.\n\n## L'art de la gestion proactive\n\nVoici comment amplifier l'impact de votre gestion des écarts de conformité :\n\n**Intégrer les outils de sécurité** \n\nLa gestion moderne des écarts de conformité ne repose plus sur un suivi manuel ; elle s'intègre à votre infrastructure de sécurité en place. Configurez des scanners de détection des vulnérabilités et des outils de surveillance de la sécurité pour générer automatiquement des tickets pour vos écarts de conformité. Vous éliminez ainsi la saisie manuelle des données et garantissez une couverture complète. \n\n**Appliquer l'analyse prédictive** \n\nLes historiques d'écarts de conformité offrent une base solide de prévision lorsqu'elles sont correctement analysées. Tirez parti des schémas de remédiation antérieurs pour anticiper les délais et besoins en ressources, facilement planifier les projets et allouer les budgets. La reconnaissance de motifs récurrents parmi les types d'écarts de conformité révèle des vulnérabilités systémiques qui justifient la mise en place de contrôles préventifs et passer ainsi d'une gestion réactive à une gestion proactive des risques. Les systèmes avancées, combinant plusieurs sources de données, fournissent une priorisation fine des menaces via des algorithmes sophistiqués de notation des risques.\n\n**Adapter les processus aux parties prenantes** \n\nLes besoins varient selon les rôles. Des tableaux de bord basés sur les rôles offrent des vues personnalisées à chaque profil : les dirigeants tirent parti des synthèses stratégiques des risques critiques, les managers suivent la performance de leurs équipes et les contributeurs gèrent les écarts de conformité qui leur sont attribuées. Automatisez les systèmes de reporting pour qu'ils répondent aux différents besoins techniques et aux préférences de communication des utilisateurs (rapports détaillés ou briefings destinés à la direction, par exemple). Les capacités d'analyse en libre-service permettent aux parties prenantes d'effectuer des analyses ad hoc et de générer des informations personnalisées, et ce sans assistance ni expertise technique.\n\n## De la conformité à l'excellence opérationnelle\n\nL'approche de GitLab en matière de gestion des écarts de conformité dépasse le simple changement d'outil. Elle permet en effet de passer d'une mise en conformité réactive à une atténuation proactive des risques. En brisant les silos entre les équipes de conformité et des opérations, elle offre une visibilité sans précédent tout en améliorant considérablement les résultats de la remédiation.\n\nLes bénéfices sont mesurables : des délais de résolution raccourcis grâce à une responsabilisation claire, une collaboration active plutôt qu'une implication contrainte et une préparation continue aux audits sans charge de travail intense à la dernière minute. Les workflows automatisés libèrent du temps aux professionnels de la conformité, qui peuvent gérer des tâches stratégiques, tandis que l'exploitation de métadonnées riches alimentent des analyses prédictives favorisant une prévention proactive et non plus réactive.\n\nPlus important encore, grâce à cette approche, la conformité n'est plus un fardeau, mais un catalyseur stratégique. Lorsque les écarts de conformité deviennent des éléments de travail visibles et traçables, intégrés aux workflows opérationnels, les entreprises renforcent leur culture de sécurité et instaurent des améliorations durables qui s'étendent au-delà de chaque cycle d'audit. Il en résulte non seulement une conformité réglementaire, mais aussi une résilience organisationnelle accrue et un avantage concurrentiel fondé sur une gestion optimale des risques.\n\n> Pour en savoir plus sur les pratiques de conformité liées aux contrôles de sécurité de GitLab, consultez [la section Security Compliance de notre manuel](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/) enrichie de conseils pratiques pour la mise en œuvre.",[1164,1165],"sécurité","intégré à GitLab",{"featured":6,"template":808,"slug":1167},"how-to-transform-compliance-observation-management-with-gitlab",{"content":1169,"config":1172},{"title":941,"description":942,"authors":1170,"heroImage":945,"date":946,"body":947,"category":725,"tags":1171},[944],[949,721,772,820],{"featured":91,"template":808,"slug":951},[1174,1177,1182],{"content":1175,"config":1176},{"title":982,"description":983,"heroImage":984,"date":985,"body":986,"category":737},{"featured":6,"template":808,"slug":988},{"content":1178,"config":1181},{"title":1058,"description":1059,"authors":1179,"date":1061,"body":1062,"category":761,"tags":1180,"heroImage":1064},[957],[721,109],{"featured":6,"template":808,"slug":1066},{"content":1183,"config":1186},{"tags":1184,"category":689,"date":843,"heroImage":844,"title":845,"description":846,"authors":1185,"body":849},[842,772,820,821],[848],{"featured":6,"template":808,"slug":851},[1188,1193,1198],{"content":1189,"config":1192},{"heroImage":1134,"date":859,"title":1135,"description":1136,"authors":1190,"body":1139,"category":784,"tags":1191},[1138],[784,821,806,233,772,820],{"featured":6,"template":808,"slug":1142},{"content":1194,"config":1197},{"heroImage":1097,"date":1098,"title":1099,"description":1100,"authors":1195,"body":1102,"category":772,"tags":1196},[1022],[772,749,934],{"featured":6,"template":808,"slug":1105},{"content":1199,"config":1202},{"title":1145,"description":1146,"authors":1200,"date":1148,"body":1149,"category":784,"tags":1201,"heroImage":1151},[957],[806,784],{"featured":6,"template":808,"slug":1153},1760469813265]