[{"data":1,"prerenderedAt":1217},["ShallowReactive",2],{"/fr-fr/blog/":3,"navigation-fr-fr":21,"banner-fr-fr":440,"footer-fr-fr":453,"blogCategories-fr-fr":664,"relatedBlogPosts-fr-fr":786,"maineFeaturedPost-fr-fr":1171,"recentFeaturedPosts-fr-fr":1185,"recentPosts-fr-fr":1201},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/fr-fr/blog","fr-fr",false,"",{"title":9,"description":10},"Blog","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:fr-fr:blog:index.yml","yaml","content","fr-fr/blog/index.yml","fr-fr/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":436,"_type":16,"title":437,"_source":17,"_file":438,"_stem":439,"_extension":20},"/shared/fr-fr/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":413,"duo":427},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/fr-fr/","gitlab logo","header",{"text":30,"config":31},"Commencer un essai gratuit",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Contacter l'équipe commerciale",{"href":37,"dataGaName":38,"dataGaLocation":28},"/fr-fr/sales/","sales",{"text":40,"config":41},"Connexion",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Plateforme",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":53,"config":54},"Découvrir notre plateforme",{"href":55,"dataGaName":48,"dataGaLocation":28},"/fr-fr/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":60,"config":61},"Découvrez GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":68,"config":69},"En savoir plus",{"href":70,"dataGaName":71,"dataGaLocation":28},"/fr-fr/why-gitlab/","why gitlab",{"title":73,"items":74},"Démarrer avec",[75,80,85],{"text":76,"config":77},"Ingénierie de plateforme",{"href":78,"dataGaName":79,"dataGaLocation":28},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Expérience développeur",{"href":83,"dataGaName":84,"dataGaLocation":28},"/fr-fr/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produit",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/fr-fr/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":113,"config":114},"Développement assisté par l'IA",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Gestion du code source",{"href":119,"dataGaLocation":28,"dataGaName":120},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":142,"dataGaLocation":28,"dataGaName":143},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Mesures",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Visibilité et mesures",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Gestion de la chaîne de valeur",{"href":163,"dataGaLocation":28,"dataGaName":164},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Données d'analyse et informations clés",{"href":168,"dataGaLocation":28,"dataGaName":169},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab pour",[173,178,183],{"text":174,"config":175},"Entreprises",{"href":176,"dataGaLocation":28,"dataGaName":177},"/fr-fr/enterprise/","enterprise",{"text":179,"config":180},"PME",{"href":181,"dataGaLocation":28,"dataGaName":182},"/fr-fr/small-business/","small business",{"text":184,"config":185},"Secteur public",{"href":186,"dataGaLocation":28,"dataGaName":187},"/fr-fr/solutions/public-sector/","public sector",{"text":189,"config":190},"Tarifs",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/fr-fr/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":285},"Ressources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Afficher toutes les ressources",{"href":200,"dataGaName":196,"dataGaLocation":28},"/fr-fr/resources/",[202,235,257],{"title":203,"items":204},"Premiers pas",[205,210,215,220,225,230],{"text":206,"config":207},"Installation",{"href":208,"dataGaName":209,"dataGaLocation":28},"/fr-fr/install/","install",{"text":211,"config":212},"Guides de démarrage rapide",{"href":213,"dataGaName":214,"dataGaLocation":28},"/fr-fr/get-started/","quick setup checklists",{"text":216,"config":217},"Apprentissage",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Documentation sur le produit",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Vidéos sur les bonnes pratiques",{"href":228,"dataGaName":229,"dataGaLocation":28},"/fr-fr/getting-started-videos/","best practice videos",{"text":231,"config":232},"Intégrations",{"href":233,"dataGaName":234,"dataGaLocation":28},"/fr-fr/integrations/","integrations",{"title":236,"items":237},"Découvrir",[238,243,247,252],{"text":239,"config":240},"Histoires de succès client",{"href":241,"dataGaName":242,"dataGaLocation":28},"/fr-fr/customers/","customer success stories",{"text":9,"config":244},{"href":245,"dataGaName":246,"dataGaLocation":28},"/fr-fr/blog/","blog",{"text":248,"config":249},"Travail à distance",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/fr-fr/teamops/","teamops",{"title":258,"items":259},"Connecter",[260,265,270,275,280],{"text":261,"config":262},"Services GitLab",{"href":263,"dataGaName":264,"dataGaLocation":28},"/fr-fr/services/","services",{"text":266,"config":267},"Communauté",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Événements",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partenaires",{"href":283,"dataGaName":284,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":290,"config":291},"carte promo The Source",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"Lire les articles les plus récents",{"href":296,"dataGaName":297,"dataGaLocation":28},"/fr-fr/the-source/","the source",{"text":299,"config":300,"lists":302},"Société",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"À propos",{"href":308,"dataGaName":309,"dataGaLocation":28},"/fr-fr/company/","about",{"text":311,"config":312,"footerGa":315},"Emplois",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Leadership",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Équipe",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Manuel",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Relations avec les investisseurs",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Centre de confiance",{"href":341,"dataGaName":342,"dataGaLocation":28},"/fr-fr/security/","trust center",{"text":344,"config":345},"Centre pour la transparence de l'IA",{"href":346,"dataGaName":347,"dataGaLocation":28},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Presse",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Nous contacter",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Aide",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Portail clients GitLab",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Fermer",{"text":380,"link":381},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Suggestions",[389,392,397,399,404,409],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"Suggestions de code (IA)",{"href":395,"dataGaName":396,"dataGaLocation":385},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab sur AWS",{"href":402,"dataGaName":403,"dataGaLocation":385},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":405,"config":406},"GitLab sur Google Cloud ",{"href":407,"dataGaName":408,"dataGaLocation":385},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":410,"config":411},"Pourquoi utiliser GitLab ?",{"href":70,"dataGaName":412,"dataGaLocation":385},"Why GitLab?",{"freeTrial":414,"mobileIcon":419,"desktopIcon":424},{"text":415,"config":416},"Commencer votre essai gratuit",{"href":417,"dataGaName":33,"dataGaLocation":418},"https://gitlab.com/-/trials/new/","nav",{"altText":420,"config":421},"Icône GitLab",{"src":422,"dataGaName":423,"dataGaLocation":418},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":420,"config":425},{"src":426,"dataGaName":423,"dataGaLocation":418},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"En savoir plus sur GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":418},"gitlab duo",{"altText":420,"config":433},{"src":422,"dataGaName":423,"dataGaLocation":418},{"altText":420,"config":435},{"src":426,"dataGaName":423,"dataGaLocation":418},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":441,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":442,"titleMobile":442,"button":443,"config":448,"_id":450,"_type":16,"_source":17,"_file":451,"_stem":452,"_extension":20},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":444,"config":445},"Essayer la version bêta",{"href":446,"dataGaName":447,"dataGaLocation":28},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":449},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":454,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":660,"_type":16,"title":661,"_source":17,"_file":662,"_stem":663,"_extension":20},"/shared/fr-fr/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":651},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":458,"config":459},"Afficher le code source de la page",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Modifier cette page",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Veuillez contribuer",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,556,588,622],{"title":46,"links":480,"subMenu":485},[481],{"text":482,"config":483},"Plateforme DevSecOps",{"href":55,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":189,"links":487},[488,492,497],{"text":489,"config":490},"Voir les forfaits",{"href":191,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Pourquoi choisir GitLab Premium ?",{"href":495,"dataGaName":496,"dataGaLocation":462},"/fr-fr/pricing/premium/","why premium",{"text":498,"config":499},"Pourquoi choisir GitLab Ultimate ?",{"href":500,"dataGaName":501,"dataGaLocation":462},"/fr-fr/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Solutions",[505,510,513,515,520,525,529,532,535,540,542,544,546,551],{"text":506,"config":507},"Transformation digitale",{"href":508,"dataGaName":509,"dataGaLocation":462},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":511,"config":512},"Sécurité et conformité",{"href":137,"dataGaName":138,"dataGaLocation":462},{"text":122,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Développement agile",{"href":518,"dataGaName":519,"dataGaLocation":462},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Transformation cloud",{"href":523,"dataGaName":524,"dataGaLocation":462},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":119,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":109,"config":530},{"href":111,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":161,"config":533},{"href":163,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/fr-fr/solutions/gitops/","gitops",{"text":174,"config":541},{"href":176,"dataGaName":177,"dataGaLocation":462},{"text":179,"config":543},{"href":181,"dataGaName":182,"dataGaLocation":462},{"text":184,"config":545},{"href":186,"dataGaName":187,"dataGaLocation":462},{"text":547,"config":548},"Formation",{"href":549,"dataGaName":550,"dataGaLocation":462},"/fr-fr/solutions/education/","education",{"text":552,"config":553},"Services financiers",{"href":554,"dataGaName":555,"dataGaLocation":462},"/fr-fr/solutions/finance/","financial services",{"title":194,"links":557},[558,560,562,564,567,569,572,574,576,578,580,582,584,586],{"text":206,"config":559},{"href":208,"dataGaName":209,"dataGaLocation":462},{"text":211,"config":561},{"href":213,"dataGaName":214,"dataGaLocation":462},{"text":216,"config":563},{"href":218,"dataGaName":219,"dataGaLocation":462},{"text":221,"config":565},{"href":223,"dataGaName":566,"dataGaLocation":462},"docs",{"text":9,"config":568},{"href":245,"dataGaName":246},{"text":570,"config":571},"Histoires de réussite client",{"href":241,"dataGaLocation":462},{"text":239,"config":573},{"href":241,"dataGaName":242,"dataGaLocation":462},{"text":248,"config":575},{"href":250,"dataGaName":251,"dataGaLocation":462},{"text":261,"config":577},{"href":263,"dataGaName":264,"dataGaLocation":462},{"text":253,"config":579},{"href":255,"dataGaName":256,"dataGaLocation":462},{"text":266,"config":581},{"href":268,"dataGaName":269,"dataGaLocation":462},{"text":271,"config":583},{"href":273,"dataGaName":274,"dataGaLocation":462},{"text":276,"config":585},{"href":278,"dataGaName":279,"dataGaLocation":462},{"text":281,"config":587},{"href":283,"dataGaName":284,"dataGaLocation":462},{"title":299,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":306,"config":591},{"href":308,"dataGaName":301,"dataGaLocation":462},{"text":311,"config":593},{"href":313,"dataGaName":314,"dataGaLocation":462},{"text":319,"config":595},{"href":321,"dataGaName":322,"dataGaLocation":462},{"text":324,"config":597},{"href":326,"dataGaName":327,"dataGaLocation":462},{"text":329,"config":599},{"href":331,"dataGaName":332,"dataGaLocation":462},{"text":334,"config":601},{"href":336,"dataGaName":337,"dataGaLocation":462},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":462},"/sustainability/",{"text":607,"config":608},"Diversité, inclusion et appartenance (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":462},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":612},{"href":341,"dataGaName":342,"dataGaLocation":462},{"text":349,"config":614},{"href":351,"dataGaName":352,"dataGaLocation":462},{"text":354,"config":616},{"href":356,"dataGaName":357,"dataGaLocation":462},{"text":618,"config":619},"Déclaration de transparence sur l'esclavage moderne",{"href":620,"dataGaName":621,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":359,"links":623},[624,627,629,631,636,641,646],{"text":625,"config":626},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":462},{"text":368,"config":628},{"href":370,"dataGaName":371,"dataGaLocation":462},{"text":373,"config":630},{"href":375,"dataGaName":376,"dataGaLocation":462},{"text":632,"config":633},"Statut",{"href":634,"dataGaName":635,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":637,"config":638},"Conditions d'utilisation",{"href":639,"dataGaName":640},"/terms/","terms of use",{"text":642,"config":643},"Déclaration de confidentialité",{"href":644,"dataGaName":645,"dataGaLocation":462},"/fr-fr/privacy/","privacy statement",{"text":647,"config":648},"Préférences en matière de cookies",{"dataGaName":649,"dataGaLocation":462,"id":650,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,658],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":462},{"text":656,"config":657},"Politique de confidentialité",{"href":644,"dataGaName":645,"dataGaLocation":462},{"text":647,"config":659},{"dataGaName":649,"dataGaLocation":462,"id":650,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",[665,679,691,703,715,727,739,751,763,774],{"_path":666,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":671,"config":672,"_id":675,"_type":16,"title":676,"_source":17,"_file":677,"_stem":678,"_extension":20},"/fr-fr/blog/categories/agile-planning","categories",{"title":669,"description":670},"Planification Agile","Browse articles related to Planification Agile on the GitLab Blog",{"name":669},{"template":673,"slug":674,"hide":6},"BlogCategory","agile-planning","content:fr-fr:blog:categories:agile-planning.yml","Agile Planning","fr-fr/blog/categories/agile-planning.yml","fr-fr/blog/categories/agile-planning",{"_path":680,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":681,"content":684,"config":685,"_id":687,"_type":16,"title":688,"_source":17,"_file":689,"_stem":690,"_extension":20},"/fr-fr/blog/categories/ai-ml",{"title":682,"description":683},"IA/ML","Browse articles related to IA/ML on the GitLab Blog",{"name":682},{"template":673,"slug":686,"hide":6},"ai-ml","content:fr-fr:blog:categories:ai-ml.yml","Ai Ml","fr-fr/blog/categories/ai-ml.yml","fr-fr/blog/categories/ai-ml",{"_path":692,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":693,"content":696,"config":697,"_id":699,"_type":16,"title":700,"_source":17,"_file":701,"_stem":702,"_extension":20},"/fr-fr/blog/categories/bulletin-board",{"title":694,"description":695},"Annonces","Browse articles related to Annonces on the GitLab Blog",{"name":694},{"template":673,"slug":698,"hide":6},"bulletin-board","content:fr-fr:blog:categories:bulletin-board.yml","Bulletin Board","fr-fr/blog/categories/bulletin-board.yml","fr-fr/blog/categories/bulletin-board",{"_path":704,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":705,"content":708,"config":709,"_id":711,"_type":16,"title":712,"_source":17,"_file":713,"_stem":714,"_extension":20},"/fr-fr/blog/categories/customer-stories",{"title":706,"description":707},"Étude de cas","Browse articles related to Étude de cas on the GitLab Blog",{"name":706},{"template":673,"slug":710,"hide":6},"customer-stories","content:fr-fr:blog:categories:customer-stories.yml","Customer Stories","fr-fr/blog/categories/customer-stories.yml","fr-fr/blog/categories/customer-stories",{"_path":716,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":720,"config":721,"_id":723,"_type":16,"title":724,"_source":17,"_file":725,"_stem":726,"_extension":20},"/fr-fr/blog/categories/devsecops",{"title":718,"description":719},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":718},{"template":673,"slug":722,"hide":6},"devsecops","content:fr-fr:blog:categories:devsecops.yml","Devsecops","fr-fr/blog/categories/devsecops.yml","fr-fr/blog/categories/devsecops",{"_path":728,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":729,"content":732,"config":733,"_id":735,"_type":16,"title":736,"_source":17,"_file":737,"_stem":738,"_extension":20},"/fr-fr/blog/categories/engineering",{"title":730,"description":731},"Ingénierie","Browse articles related to Ingénierie on the GitLab Blog",{"name":730},{"template":673,"slug":734,"hide":6},"engineering","content:fr-fr:blog:categories:engineering.yml","Engineering","fr-fr/blog/categories/engineering.yml","fr-fr/blog/categories/engineering",{"_path":740,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":741,"content":744,"config":745,"_id":747,"_type":16,"title":748,"_source":17,"_file":749,"_stem":750,"_extension":20},"/fr-fr/blog/categories/news",{"title":742,"description":743},"Actualités","Browse articles related to Actualités on the GitLab Blog",{"name":742},{"template":673,"slug":746,"hide":6},"news","content:fr-fr:blog:categories:news.yml","News","fr-fr/blog/categories/news.yml","fr-fr/blog/categories/news",{"_path":752,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":753,"content":756,"config":757,"_id":759,"_type":16,"title":760,"_source":17,"_file":761,"_stem":762,"_extension":20},"/fr-fr/blog/categories/open-source",{"title":754,"description":755},"Open source","Browse articles related to Open source on the GitLab Blog",{"name":754},{"template":673,"slug":758,"hide":6},"open-source","content:fr-fr:blog:categories:open-source.yml","Open Source","fr-fr/blog/categories/open-source.yml","fr-fr/blog/categories/open-source",{"_path":764,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":765,"content":767,"config":768,"_id":770,"_type":16,"title":771,"_source":17,"_file":772,"_stem":773,"_extension":20},"/fr-fr/blog/categories/product",{"title":90,"description":766},"Browse articles related to Produit on the GitLab Blog",{"name":90},{"template":673,"slug":769,"hide":6},"product","content:fr-fr:blog:categories:product.yml","Product","fr-fr/blog/categories/product.yml","fr-fr/blog/categories/product",{"_path":775,"_dir":667,"_draft":6,"_partial":6,"_locale":7,"seo":776,"content":779,"config":780,"_id":782,"_type":16,"title":783,"_source":17,"_file":784,"_stem":785,"_extension":20},"/fr-fr/blog/categories/security",{"title":777,"description":778},"Sécurité","Browse articles related to Sécurité on the GitLab Blog",{"name":777},{"template":673,"slug":781,"hide":6},"security","content:fr-fr:blog:categories:security.yml","Security","fr-fr/blog/categories/security.yml","fr-fr/blog/categories/security",[787,834,874,889,935,975,1019,1058,1096,1132],{"category":669,"slug":674,"posts":788},[789,807,822],{"content":790,"config":804},{"body":791,"title":792,"description":793,"authors":794,"heroImage":798,"date":799,"category":674,"tags":800},"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.",[795,796,797],"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",[801,802,803],"agile","workflow","DevSecOps platform",{"featured":6,"template":805,"slug":806},"BlogPost","embedded-views-the-future-of-work-tracking-in-gitlab",{"content":808,"config":820},{"title":809,"description":810,"authors":811,"heroImage":813,"date":814,"body":815,"category":674,"tags":816,"updatedDate":819},"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.",[812],"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",[801,803,817,769,818],"features","tutorial","2025-05-12",{"slug":821,"featured":91,"template":805},"safe-without-silos-in-gitlab",{"content":823,"config":832},{"title":824,"description":825,"authors":826,"heroImage":827,"date":828,"body":829,"category":674,"tags":830,"updatedDate":831},"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.",[812],"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",[801,818,802,803],"2025-03-06",{"slug":833,"featured":91,"template":805},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"category":682,"slug":686,"posts":835},[836,849,861],{"content":837,"config":847},{"heroImage":838,"date":839,"title":840,"description":841,"authors":842,"body":844,"category":686,"tags":845},"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.",[843],"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.*",[846,817,769,803],"AI/ML",{"featured":6,"template":805,"slug":848},"gitlab-18-4-ai-native-development-with-automation-and-insight",{"content":850,"config":859},{"title":851,"description":852,"authors":853,"heroImage":855,"date":856,"body":857,"category":686,"tags":858},"Mesurez le ROI de l'IA à grande échelle avec GitLab Duo Analytics","Découvrez comment transformer des données d'utilisation brutes en informations exploitables et en calculs de ROI à l’aide de ce tutoriel.",[854],"Paul Meresanu","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","2025-09-15","L'investissement dans l'IA commence par la mesure. Pour construire une plateforme de développement alimentée par l'IA, il faut tout d'abord comprendre l'utilisation réelle, les modèles d'adoption et la valeur métier quantifiable, notamment le retour sur investissement (ROI) de [GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/gitlab-duo/).\n\nPour aider nos clients à maximiser leurs investissements dans l'IA, nous avons développé la solution GitLab Duo Analytics dans le cadre de notre programme d'accélération GitLab Duo. GitLab Duo Analytics est une solution complète et orientée client qui transforme les données d'utilisation brutes en données métiers exploitables et mesure le ROI. Il s’agit d’un outil d'accompagnement spécialisé que nous avons créé pour répondre aux besoins d'analyse immédiats des entreprises, qui calculent de plus en plus la productivité de l'IA dans son ensemble.\n\nCes données de base aident à transformer l'IA en profondeur. Par exemple, les entreprises peuvent les utiliser pour optimiser l’attribution des licences, identifier les cas d’utilisation à forte valeur ajoutée et élaborer des business cases convaincants pour renforcer l'adoption de l'IA au sein des équipes de développement.\n\nUne grande entreprise du secteur financier a collaboré avec l’un de nos Customer Success Architect dans le cadre du programme d'accélération GitLab Duo afin d’obtenir une visibilité sur son investissement [GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/blog/gitlab-duo-enterprise-is-now-available/). Ensemble, ils ont mis en œuvre une solution d'analyse hybride qui combine la collecte mensuelle de données avec une intégration API en temps réel, afin de créer une base évolutive pour mesurer les gains de productivité de l'IA et optimiser l'utilisation des licences à l'échelle de l'entreprise.\n\n## Mesurer le ROI de l'IA dans le développement d'entreprise\n\nAvant de mettre en œuvre une solution d'analyse, il est essentiel de comprendre comment vous évaluez votre utilisation de l'IA.\n\nPosez-vous les questions suivantes :\n\n* **Quelles fonctionnalités de GitLab Duo doivent être évaluées ?** (Suggestions de code, assistance par chat, scanning de sécurité) ?\n* **Qui utilise l'IA au sein de votre entreprise ?** (Développeurs, équipes de sécurité, ingénieurs DevOps) ?\n* **Quels indicateurs métiers sont importants pour votre entreprise ?** (Gain de temps, gains de productivité, optimisation des coûts) ?\n* **Comment fonctionne votre collecte de données actuelle** (Exports manuels, intégration API, outils existants) ?\n\nUtilisez cette étape pour définir les éléments suivants :\n\n* Votre framework de calcul du ROI\n* Vos indicateurs clés de performance (KPI)\n* Votre stratégie de collecte de données\n* Vos exigences de reporting des parties prenantes\n\n### Exemple de framework de calcul du ROI\n\n![Exemple de framework de calcul du ROI](https://gitlab.com/-/project/54775568/uploads/06da2f5c3a75197cd272aedb3d67a347/image.png)\n\n## Guide de mise en œuvre étape par étape\n\nVeuillez noter que la solution ci-dessous décrit une approche [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/) que vous pouvez déployer gratuitement dans votre propre environnement. Téléchargez, personnalisez et exécutez cette solution dès maintenant ! \n\n### Prérequis\n\n**Avant de commencer, assurez-vous de disposer des éléments suivants :**\n\n* Instance GitLab avec GitLab Duo activé\n* Token API GitLab avec autorisations de lecture\n* Accès pour configurer les variables CI/CD de GitLab \n* Connaissances de base des pipelines CI/CD de GitLab\n\n### 1. Configurer et paramétrer l'environnement initial\n\nConfigurez l'environnement du projet en clonant d'abord le dépôt.\n\n```bash\ngit clone https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/gitlab-graphql-api.git\ncd gitlab-graphql-api\n```\n\nEffectuez un push vers votre propre instance GitLab ou votre espace de nommage, puis accédez à votre projet dans GitLab pour configurer les [variables CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/).\n\n### 2. Configurer les variables de contrôle du pipeline\n\nContrôlez quels pipelines d’analyse s'exécutent en définissant les variables CI/CD du projet. Allez dans **Paramètres du projet → CI/CD → Variables** et ajoutez :\n\n| Variable | Défaut | Description | \n|----------|---------|-------------| \n| `ENABLE_DUO_METRICS` | \"true\" | Activer/désactiver le pipeline de métriques GitLab Duo AI | \n| `ENABLE_PROJECT_METRICS` | \"false\" | Activer/désactiver le pipeline de métriques de projet traditionnel | \n\n#### Exemples de configurations : \n- **Configurer GitLab Duo uniquement** : `ENABLE_DUO_METRICS=\"true\"`, `ENABLE_PROJECT_METRICS=\"false\"` \n- **Configurer les deux tableaux de bord** : `ENABLE_DUO_METRICS=\"true\"`, `ENABLE_PROJECT_METRICS=\"true\"` \n- **Tout désactiver** : `ENABLE_DUO_METRICS=\"false\"`, `ENABLE_PROJECT_METRICS=\"false\"`\n\n### 3. Configurer l’ingestion des données\n\nConfigurez l'ingestion des données dans votre fichier `.gitlab-ci.yml`. Cette action crée des métadonnées de projet brutes partagées entre les métriques. \n\n#### Variables de configuration de base :\n\n\n```yaml\nvariables:\n  GROUP_PATH: \"gitlab-org/professional-services-automation\"  # Your group path\n  INCLUDE_SIMPLE_FIELDS: \"fullPath,name,description\"  # Fields to fetch\n  ARGUMENT_FIELDS: \"mergeRequests\"  # Argument fields requiring additional config\n  LIMIT: \"100\"  # Projects per API call\n  MAX_ITERATIONS: \"2\"  # Maximum API calls (for testing)\n  GITLAB_GRAPHQL_API_VERSION: \"0.1.0\"  # API version from Package Registry\n```\n#### Configurer les champs d'argument pour des métriques spécifiques : \n\nPour chaque métrique que vous souhaitez collecter, définissez des variables de champ d'argument :\n\n```yaml\n# Example: Merged Merge Requests\nARGUMENT_FIELD_1_NAME: \"mergeRequests\"\nARGUMENT_FIELD_1_FILTER_NAME: \"state\"\nARGUMENT_FIELD_1_FILTER_VALUE: \"merged\"\nARGUMENT_FIELD_1_RETURN_VALUES: \"count totalTimeToMerge\"\n\n# Example: Packages Count\nARGUMENT_FIELD_2_NAME: \"packages\"\nARGUMENT_FIELD_2_RETURN_VALUES: \"count\"\n```\n\n### 4. Configurer l'agrégation des métriques\n\nAprès l'ingestion des données, configurez les règles d'agrégation dans `.gitlab/Schedule.gitlab-ci.yml` pour chaque métrique que vous souhaitez générer. \n\n#### Exemple de configuration de job de métrique :\n\n```yaml\nprocess_average_time_to_merge:\n  \u003C\u003C: *process_data_template\n  stage: process_data\n  variables:\n    METRIC_NAME: \"9_Average_Time_To_Merge\"\n    BUSINESS_LEVEL_START: 2\n    BUSINESS_LEVEL_END: 4\n    AGGREGATE_COLUMNS: \"mergeRequests_state_merged_totalTimeToMerge:sum mergeRequests_state_merged_count:sum\"\n    NEW_COLUMN_NAME: \"average_time_to_merge_days\"\n    NEW_COLUMN_FORMULA: \"mergeRequests_state_merged_totalTimeToMerge / mergeRequests_state_merged_count / (24 * 60 * 60)\"\n    SORT_BY: \"average_time_to_merge_days\"\n    FILTER_CONDITION: \"mergeRequests_state_merged_count >= 5\"\n```\n\n#### Variables requises pour chaque métrique :\n\n| Variable | Description | Exemple |\n|----------|-------------|---------|\n| `METRIC_NAME` | Nom de la métrique (utilisé dans le nommage des fichiers) | \"9_Average_Time_To_Merge\" |\n| `BUSINESS_LEVEL_START` | Niveau de départ pour la hiérarchie métier | 1 |\n| `BUSINESS_LEVEL_END` | Niveau final pour la hiérarchie métier | 3 |\n| `AGGREGATE_COLUMNS` | Colonnes à agréger avec fonction | \"mergeRequests_state_merged_count:sum\" |\n| `SORT_BY` | Colonne pour trier les résultats | \"average_time_to_merge_days\" |\n\n### 5. Exécuter le pipeline planifié pour configurer l’analyse\n\nUne fois configuré, exécutez un pipeline planifié pour générer votre analyse :\n\n1. Allez dans **CI/CD → Planifications** \n2. Créez une nouvelle planification ou exécutez-en une existante \n3. Le pipeline va automatiquement : \n  - Ingérer les données selon votre configuration \n  - Agréger les métriques selon vos règles \n  - Déployer les tableaux de bord sur GitLab Pages \n\n### 6. Accéder à vos tableaux de bord d’analyse \n\nAprès l'exécution réussie du pipeline planifié, GitLab Pages déploie automatiquement vos tableaux de bord : \n\n- **Tableau de bord des métriques de projet**: `https://your-username.gitlab.io/project-name/existing-metrics/`\n- **Tableau de bord des métriques GitLab Duo**: `https://your-username.gitlab.io/project-name/duo-metrics/`\n- **Page d'accueil principale**: `https://your-username.gitlab.io/project-name/`\n\nLa page d'accueil principale détecte automatiquement quels tableaux de bord sont disponibles et affiche les liens appropriés.\n\nVous verrez les éléments suivants :\n\n- Utilisation des licences : nombre total d’utilisateurs sous licence par rapport au nombre d’utilisateurs actifs (avec analyse des suggestions de code)\n\n![Tableau de bord de GitLab Duo Analytics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/nhbukcflhmghs5jatrip.png)\n\n- Analyse de GitLab Duo Chat : utilisateurs uniques de GitLab Duo Chat, moyenne des événements du chat sur 90 jours et taux d'adoption du chat\n\n- Analyse d'engagement de GitLab Duo : catégorisation de l'utilisation de GitLab Duo pour un groupe d'utilisateurs comme Fort (10+ suggestions), Moyen (5-9) ou Faible (1-4) selon les modèles d'utilisation\n\n![Analyse de GitLab Duo Chat sur les 90 derniers jours](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/xgq05hh2ybzb8ugsxqza.png)\n\n- Analyse de l'utilisation : suggestions de code par langage de programmation (répartition par langage), analyse des performances des langages de suggestions de code (taux d'acceptation et de rejet)\n\n![Vue d'adoption de l'analyse de l'utilisation de GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/mu3dx5g2l2lki2ehlr2g.png)\n\n ![Analyse des performances par langage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478267/xf0thn8sm4dlhoyyqg9i.png)\n\n- Tendances hebdomadaires de GitLab Duo Chat : modèles d'utilisation de GitLab Duo Chat\n\n![Tendances d'utilisation quotidienne de GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/plhycnmewye3vp6vitqj.png) \n\n#### Les fonctionnalités du tableau de bord incluent :\n \n- **L’analyse de l'utilisation des licences** - Suivi des utilisateurs sous licence par rapport aux utilisateurs actifs \n- **Analyse des suggestions de code** - Suivi des taux d'acceptation et de la répartition des langages \n- **Analyse de GitLab Duo Chat** - Affichage des interactions par chat et des taux d'adoption \n- **Analyse de l’engagement des utilisateurs** - Catégorisation des utilisateurs par niveau d'activité \n- **Analyse des performance par langage** - Analyse des taux d'acceptation par langage de programmation \n\n### 7. Comprendre les API utilisées \n\nLa solution exploite plusieurs API GitLab pour collecter des données d'utilisation complètes : \n\n#### API pour collecter les données d'utilisation de l'IA (aiUsageData)\n\n```graphql\n# Fetches individual code suggestion events\nquery: |\n  {\n    group(fullPath: \"your-group\") {\n      aiUsageData {\n        codeSuggestionEvents {\n          event         # ACCEPTED or SHOWN\n          timestamp     # When it happened\n          language      # Programming language\n          suggestionSize # SINGLE_LINE or MULTI_LINE\n          user { username }\n        }\n      }\n    }\n  }\n# Purpose: Tracks every code suggestion shown or accepted by developers\n```\n\n#### API pour collecter les utilisateurs du module d'extension GitLab Self-Managed\n\n```graphql\n# Gets licensed user information\nquery: |\n  {\n    selfManagedAddOnEligibleUsers(\n      addOnType: DUO_ENTERPRISE\n      filterByAssignedSeat: \"Yes\"\n    ) {\n      user {\n        username\n        lastDuoActivityOn\n      }\n    }\n  }\n# Purpose: Identifies who has licenses and when they last used Duo\n```\n\n#### API pour collecter les métriques d'IA\n\n```graphql\nquery: |\n  {\n    aiMetrics(from: \"2024-01-01\", to: \"2024-06-30\") {\n      codeSuggestions {\n        shownCount\n        acceptedCount\n      }\n      duoChatContributorsCount\n      duoAssignedUsersCount\n    }\n  }\n# Purpose: Gets pre-calculated metrics for trend analysis\n```\n\n#### API pour collecter le Ping de Service (REST)\n\n```bash \nurl: \"{GITLAB_URL}/api/v4/usage_data/service_ping\" \n# Purpose: Collects instance-wide usage statistics \n```\n\n## Mise en pratique complète\n\nPour démontrer la puissance de cette solution d'analyse intégrée, parcourons ensemble toutes les étapes d'une implémentation complète, du déploiement initial au calcul automatisé du ROI.\n\nCommencez par déployer la solution conteneurisée dans votre environnement avec la configuration Docker fournie. En quelques minutes, l'API d'analyse et le tableau de bord React seront opérationnels localement. \n\nL'architecture de données hybride commence immédiatement à collecter des métriques à partir de vos exports CSV mensuels existants et établit des connexions GraphQL en temps réel vers votre instance GitLab.\n\n**Automatisation via les scripts Python**\n\nCette approche déploie toute sa puissance lorsque vous exploitez les scripts Python pour automatiser l'ensemble du workflow de collecte et de traitement des données. La solution comprend des scripts Python complets qui peuvent être facilement personnalisés et planifiés.\n\n**Intégration GitLab CI/CD**\n\nPour une automatisation à l'échelle de l'entreprise, intégrez ces scripts Python dans des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) planifiés. Cette approche exploite votre infrastructure GitLab existante et garantit une collecte de données cohérente et fiable :\n\n```yaml\n\n# .gitlab-ci.yml example\n\nduo_analytics_collection:\n  stage: analytics\n  script:\n    - python scripts/enhanced_duo_data_collection.py\n    - python scripts/metric_aggregations.py\n    - ./deploy_dashboard_updates.sh\n  schedule:\n    - cron: \"0 2 1 * *\"  # Monthly on 1st at 2 AM\n  only:\n    - schedules\n```\n\nCette stratégie d'automatisation transforme la collecte manuelle de données en un moteur d'analyse autonome. Vos scripts Python s'exécutent mensuellement via les pipelines [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) de GitLab, collectent automatiquement les données d'utilisation, calculent les métriques de ROI et mettent à jour les tableaux de bord, le tout sans intervention manuelle.\n\nUne fois automatisée, la solution fonctionne de manière fluide : les pipelines planifiés exécutent les scripts de collecte de données Python, traitent les réponses GraphQL en indicateurs commerciaux et mettent à jour les données du tableau de bord. Vous découvrirez ainsi de véritables modèles d'utilisation dans le tableau de bord comme les volumes de suggestions de code par langage de programmation, les tendances d'adoption des utilisateurs entre les équipes et le taux d'utilisation des licences. \n\nDans le tableau de bord, la vue d'ensemble du ROI est ici le véritable atout. Vous y trouverez des métriques d'engagement concrètes qui peuvent être converties en impact commercial pour votre entreprise : vous découvrirez peut-être que vos utilisateurs actifs de GitLab Duo génèrent un ROI mensuel de 127 % grâce à des gains de temps et de productivité, tandis que 23 % de vos licences restent sous-utilisées. \n\nCes informations se traduisent immédiatement en recommandations concrètes : vous pouvez ainsi fournir des licences aux équipes les plus performantes, mettre en place une formation ciblée pour les utilisateurs avec des licences sous-utilisées et élaborer des arguments commerciaux basés sur les données pour une adoption plus large de l'IA.\n\n## Pourquoi choisir GitLab ?\n\nLa plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/) complète de GitLab fournit la base idéale pour l'analyse et l'évaluation de l'IA en entreprise. Avec des API GraphQL natives, un accès flexible aux données et des capacités d’IA intégrées via GitLab Duo, les entreprises peuvent centraliser l'évaluation de l'IA tout au long du cycle de développement logiciel sans perturber les workflows existants.\n\nL'architecture ouverte de la solution permet des solutions d'analyse personnalisées comme celle développée dans le cadre de notre programme d'accélération GitLab Duo. L'engagement de GitLab en faveur d’une conception API-first signifie que vous pouvez extraire des données d'utilisation détaillées, intégrer avec les systèmes d'entreprise existants et élaborer des calculs de ROI sophistiqués qui s'alignent sur des métriques spécifiques et les exigences de création de rapports de votre organisation.\n\nAu-delà des capacités techniques, notre approche garantit que vous ne faites pas que mettre en œuvre des outils, vous élaborez également des stratégies d'adoption de l'IA durables. Cette solution conçue spécialement dans le cadre du programme d'accélération GitLab Duo illustre parfaitement cette approche avec des conseils pratiques, des frameworks éprouvés et des solutions personnalisées qui répondent à de véritables défis comme le calcul du ROI et l'optimisation des licences.\n\nÀ mesure que GitLab continue d'améliorer ses capacités d'analyse avec l'IA native, cette approche n'en est que plus précieuse. Les frameworks de calcul, les indicateurs clés de performance et les processus de collecte de données établis via des solutions d'analyse personnalisées s'intègrent de manière transparente aux fonctionnalités natives améliorées et garantissent que votre investissement dans l'évaluation de l'IA évolue au même rythme que GitLab. \n\n## Essayez GitLab Duo dès aujourd'hui\n\nLe calcul du ROI de l'IA n'est qu’un début. Avec les fonctionnalités de GitLab Duo, vous pouvez obtenir une analyse complète qui suit non seulement l'utilisation de l'IA, mais sert aussi de base pour une optimisation basée sur les données. Cette base peut ensuite évoluer avec la croissance de votre entreprise et avec les capacités d'IA en pleine expansion de GitLab.\n\nLa solution d'analyse développée dans le cadre du programme d'accélération de GitLab Duo démontre comment les partenariats axés sur la réussite client peuvent apporter une valeur immédiate et des avantages stratégiques à long terme. Du déploiement initial au calcul du ROI à l'échelle de l'entreprise, cette solution offre la visibilité et les données nécessaires pour maximiser les investissements dans l’IA et favoriser son adoption durable.\n\nLa combinaison de l'automatisation Python, de l'intégration GitLab CI/CD et de l'analyse sur mesure crée un avantage concurrentiel qui s'étend bien au-delà de la productivité individuelle des équipes de développement. Elle permet une prise de décision stratégique, optimise l'allocation des ressources et fournit des arguments commerciaux convaincants pour un investissement et une expansion continus de l'IA.\n\nL'avenir du développement alimenté par l'IA est basé sur les données, et commence par une évaluation approfondie. Que vous commenciez votre parcours dans l’IA ou que vous optimisiez des investissements existants, GitLab fournit à la fois la plateforme et la base du partenariat nécessaires pour réussir.\n\n> Lancez-vous dès aujourd'hui avec GitLab Duo et profitez d'un [essai gratuit de GitLab Ultimate avec GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/gitlab-duo/).\n\n",[846,769,818],{"featured":6,"template":805,"slug":860},"measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics",{"content":862,"config":872},{"tags":863,"heroImage":864,"authors":865,"title":868,"description":869,"date":870,"body":871,"category":686},[846,817,803,781],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749664299/Blog/Hero%20Images/AdobeStock_887599633.jpg",[866,867],"Kyle Smith","Ayoub Fandi","Sécurité et IA : tout savoir sur le framework de GitLab","Découvrez comment les contrôles de sécurité, les intégrations tierces et les politiques de rétention de GitLab Duo aident les équipes à implémenter l'IA en toute sécurité dans leur workflow de développement.","2025-09-11","Alors que les entreprises adoptent rapidement les technologies d'IA, les responsables de la sécurité des systèmes d'information (RSSI) font face à de nouveaux défis en matière de sécurité. De nombreux RSSI sont en effet confrontés à des questions inédites : comment évaluer les fournisseurs d'IA par rapport aux fournisseurs de logiciels traditionnels ? Quels sont les contrôles de sécurité les plus importants ? Où s'arrête la responsabilité du fournisseur et où commence celle du client ? Comment évaluer les risques de sécurité liés à l'IA dans le contexte du service fourni ? \n\nPour répondre à ces questions, nous avons créé le [framework de sécurité relatif à l'IA de GitLab](https://trust.gitlab.com/?itemUid=ad3d92c1-889e-49fc-b19c-2434f70071ee&source=click) afin de montrer aux responsables de la sécurité comment GitLab et ses clients peuvent garantir un développement sécurisé alimenté par l'IA avec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \" Qu'est-ce que GitLab Duo ?\").\n\n## La genèse des défis de sécurité liés à l'IA\n\nLes responsables sécurité de divers secteurs mentionnent tous le même schéma : leurs organisations adoptent rapidement les technologies d'IA pour améliorer la livraison logicielle, alors que leurs équipes sécurité peinent à établir des contrôles adéquats.\n\nCette problématique n'est pas simplement une question de ressources ou d'expertise, elle représente un changement fondamental dans la façon dont les organisations doivent aborder la sécurité à l'ère de l'IA. Les responsables sécurité assistent à une adoption rapide et sans précédent de l'IA dans leurs organisations, des équipes de développement aux départements marketing.\n\nLes organisations intègrent l'IA dans leurs propres logiciels, et nombre de leurs applications SaaS actuelles ont également des fonctionnalités d'IA. Bien que cette adoption favorise l'innovation et l'efficacité, elle crée également un ensemble complexe de problématiques de sécurité que les frameworks traditionnels n'étaient pas conçus pour traiter. \n\nVoici quelques-uns des défis spécifiques que nous avons identifiés.\n\n## Les défis de sécurité à l'ère de l'IA\n\n**1. Incertitudes concernant la responsabilité et le contrôle**\n\nEn raison du rythme rapide d'adoption de l'IA, de nombreuses organisations se retrouvent sans stratégie cohérente de gouvernance de sécurité. Les équipes de sécurité doivent alors essayer d'adapter les frameworks de sécurité existants pour répondre aux préoccupations spécifiques à l'IA. Quant aux responsables sécurité, ils tentent de comprendre où commencent et s’arrêtent leurs responsabilités en matière de sécurité liée à l'IA. La traditionnelle relation fournisseur-client se complexifie avec les systèmes d'IA, car les flux de données, l'entraînement des modèles et les processus d'inférence créent de nouveaux types d'interactions et de dépendances.\n\n**2. Évolution de l'évaluation des risques**\n\nLes modèles de risques de sécurité traditionnels peinent à capturer les caractéristiques uniques des systèmes d'IA. Les responsables sécurité constatent que les frameworks standards d'évaluation des risques ne traitent pas correctement les risques de sécurité spécifiques à l'IA, qui diffèrent selon l'implémentation et le contexte d'utilisation. Plus difficile encore, les organisations doivent évaluer les fournisseurs d'IA alors que leurs équipes de sécurité ne disposent pas forcément d'une expertise technique approfondie sur ce sujet.\n\n**3. Complexification de la protection des données**\n\nLes systèmes d'IA présentent des défis uniques en matière de protection des données. La façon dont ces systèmes traitent, apprennent et génèrent des données crée de nouveaux problèmes de confidentialité et de sécurité que les organisations doivent évaluer soigneusement. Les RSSI sont tenus de s'assurer que leurs frameworks de gouvernance des données évoluent afin de pouvoir s'adapter à la façon dont les systèmes d'IA utilisent et protègent les informations sensibles. Implémenter l'IA sans mesures de protection adéquates pourrait révéler par inadvertance des informations confidentielles dans les résultats générés par l'IA.\n\n**4. Conformité et normes**\n\nLe paysage réglementaire relatif à la sécurité de l'IA évolue rapidement : de nouvelles normes, notamment la [norme ISO 42001](https://about.gitlab.com/fr-fr/blog/gitlab-achieves-iso-iec-42001-certification-for-ai-governance/), sont mises en place en parallèle des frameworks existants. Les responsables sécurité doivent apprendre à gérer cet environnement complexe et s'assurer que leurs implémentations d'IA restent conformes aux réglementations actuelles et futures. Ils doivent trouver un équilibre entre adoption de l'IA et contrôles de sécurité robustes qui répondent aux exigences réglementaires.\n\n## Comment relever ces défis ?\n\nPour répondre aux préoccupations des RSSI, nous avons développé un framework complet pour aider les organisations à gérer la sécurité de l'IA dans le contexte de notre plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") alimentée par l'IA. Notre framework de sécurité relatif à l'IA détaille notre implémentation axée sur la confidentialité de l'IA dans GitLab Duo et les procédures de validation de sécurité de nos fournisseurs d'IA. Il comprend également une matrice de responsabilités pour aider les responsables sécurité à gérer leurs tâches liées à la sécurité de l'IA et à innover dans un environnement sécurisé. Nous avons également compilé une sélection de risques de sécurité spécifiques à l'IA à garder à l'esprit et mis en évidence la façon dont les fonctionnalités de GitLab comme les [garde-fous relatifs aux prompts](https://about.gitlab.com/blog/how-gitlab-uses-prompt-guardrails-to-help-protect-customers/) peuvent aider à les atténuer.\n\n> Vous souhaitez en savoir plus sur nos contrôles de sécurité ? Consultez notre [framework de sécurité relatif à l'IA](https://trust.gitlab.com/?itemUid=ad3d92c1-889e-49fc-b19c-2434f70071ee&source=click).\n\n## En savoir plus\n\n* [Centre pour la transparence de l'IA de GitLab](https://about.gitlab.com/fr-fr/ai-transparency-center/)\n* [Améliorer la sécurité de l'IA dans GitLab avec des identités composites](https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/)\n* [Sécurité, conformité et IA : découvrez 3 nouvelles fonctionnalités GitLab](https://about.gitlab.com/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features/)\n* [Informations clés sur l'IA et sécurité de notre communauté de développeurs](https://about.gitlab.com/blog/icymi-key-ai-and-security-insights-from-our-developer-community/)",{"featured":6,"template":805,"slug":873},"the-gitlab-ai-security-framework-for-security-leaders",{"category":694,"slug":698,"posts":875},[876],{"content":877,"config":887},{"title":878,"description":879,"authors":880,"heroImage":882,"date":883,"body":884,"category":698,"tags":885,"updatedDate":886},"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.",[881],"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,746,803],"2025-03-28",{"slug":888,"featured":91,"template":805},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":706,"slug":710,"posts":890},[891,907,921],{"content":892,"config":905},{"title":893,"description":894,"authors":895,"heroImage":897,"date":898,"body":899,"category":710,"tags":900,"updatedDate":904},"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.",[896],"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",[901,902,903],"contributors","open source","customers","2025-02-10",{"slug":906,"featured":91,"template":805},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":908,"config":919},{"title":909,"description":910,"authors":911,"heroImage":913,"date":914,"body":915,"category":710,"tags":916,"updatedDate":918},"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.",[912],"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.**",[903,109,917,803],"user stories","2024-12-18",{"slug":920,"featured":91,"template":805},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":922,"config":933},{"title":923,"description":924,"authors":925,"heroImage":927,"date":928,"body":929,"category":710,"tags":930},"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.",[926],"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",[931,932,846,903],"DevOps","DevOps platform",{"slug":934,"featured":6,"template":805},"southwest-looking-to-help-developers-take-flight",{"category":718,"slug":722,"posts":936},[937,950,963],{"content":938,"config":948},{"title":939,"description":940,"authors":941,"date":943,"body":944,"category":722,"tags":945,"heroImage":947},"[É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.",[942],"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).",[946],"developer survey","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758807223/nzwhf9snd0fu288cqkj4.png",{"featured":6,"template":805,"slug":949},"software-innovation-study-france",{"content":951,"config":961},{"title":952,"description":953,"authors":954,"heroImage":957,"date":958,"body":959,"category":722,"tags":960},"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.",[955,956],"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.*",[555,803],{"featured":6,"template":805,"slug":962},"why-financial-services-choose-single-tenant-saas",{"content":964,"config":973},{"heroImage":965,"body":966,"authors":967,"updatedDate":969,"date":969,"title":970,"tags":971,"description":972,"category":722},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","Longtemps perçue comme réservée aux applications SaaS, l'approche [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") s'impose désormais dans le développement de systèmes embarqués. Cette approche est portée par l'évolution du rôle des logiciels, qui sont devenus un facteur de différenciation majeur. Face aux nouvelles attentes du marché, les pratiques de développement modernes sont désormais incontournables. En réponse, les entreprises adoptent l'approche DevSecOps dans le développement de systèmes embarqués.\n\nCette approche consiste à appliquer des pratiques d'ingénierie collaborative, des chaînes d'outils intégrées et une automatisation des processus de compilation, de test et de sécurisation des logiciels au développement de systèmes embarqués. Elle introduit également les ajustements nécessaires pour tenir compte des spécificités matérielles.\n\n## Convergence des forces du marché\n\nLes équipes en charge des systèmes embarqués doivent désormais faire face à une convergence de trois grandes forces du marché qui rendent la modernisation de leurs pratiques inévitable.\n\n### 1. L'essor des produits définis par logiciel\n\nLes produits autrefois définis principalement par leur composant matériel se différencient désormais par leurs capacités logicielles. Cette évolution est particulièrement visible sur le marché des véhicules définis par logiciel (SDV), dont la valeur devrait passer de 213,5 milliards de dollars en 2024 à [1,24 billions de dollars](https://www.marketsandmarkets.com/Market-Reports/software-defined-vehicles-market-187205966.html) d'ici 2030, soit un taux de croissance annuel moyen de 34 %.\nLa part du contenu logiciel embarqué de ces véhicules explose. D'ici fin 2025, chaque véhicule contiendra en moyenne [650 millions de lignes de code](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/). Les approches traditionnelles du développement de systèmes embarqués ne parviennent pas à gérer ce niveau de complexité logicielle. \n\n### 2. La virtualisation matérielle comme catalyseur technique\n\nLa virtualisation matérielle joue un rôle technique central dans l'approche DevSecOps pour le développement de systèmes embarqués. Les unités de commande électronique virtuelles (vECU), les processeurs ARM hébergés sur le cloud et les environnements de simulation sophistiqués sont de plus en plus répandus. Le matériel virtuel permet d'effectuer des tests qui nécessitaient autrefois du matériel physique.\n\nCes technologies de virtualisation posent les bases de l'[intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que l'intégration continue ?\"). Toutefois, ce n'est que lorsqu'elles sont intégrées dans des workflows automatisés que leur utilisation fait sens. Combinés à des pratiques de développement collaboratif et à des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") automatisés, les tests virtuels aident les équipes à détecter les problèmes beaucoup plus tôt, lorsque l'application de correctifs est bien moins onéreuse. Sans approche DevSecOps pour le développement de systèmes embarqués et sans outils pour orchestrer ces ressources virtuelles, les entreprises ne peuvent pas tirer profit de la virtualisation.\n\n### 3. La pression concurrentielle et économique\n\nTrois dynamiques corrélées modifient le paysage concurrentiel du développement de systèmes embarqués :\n\n* Les nouvelles générations d'ingénieurs ont des attentes bien précises. Comme l'explique un responsable du développement de systèmes embarqués chez un client de GitLab : « Les jeunes diplômés développant des systèmes embarqués ne connaissent pas les outils hérités comme Perforce. Ils ont été formés sur [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"). S'ils doivent utiliser des outils dépassés, ils démissionnent au bout de six mois. » Les entreprises qui persistent à utiliser des outils obsolètes risquent de perdre leur capacité à attirer les meilleurs ingénieurs.\n* À l'inverse, les entreprises à la pointe de la technologie qui attirent les ingénieurs les plus talentueux avec des pratiques modernes ont un avantage majeur sur leurs concurrents et obtiennent des résultats remarquables. Par exemple, en 2024, [SpaceX](https://spacenews.com/spacex-launch-surge-helps-set-new-global-launch-record-in-2024/) a réalisé le plus grand nombre de lancements orbitaux dans le monde. Les entreprises qui utilisent les dernières technologies excellent dans le développement logiciel et adoptent une culture de développement moderne. Elles obtiennent notamment des résultats que les entreprises qui continuent de faire appel à des outils traditionnels ont du mal à égaler. \n* Les longs cycles de rétroaction alourdissent considérablement les coûts du développement embarqué et rendent l'adoption d'une approche DevSecOps plus urgente que jamais. Lorsque les équipes de développement doivent patienter plusieurs semaines pour tester leur code sur des bancs d'essai matériels, la productivité chute intrinsèquement : les ingénieurs perdent le fil et doivent changer de contexte lorsque les résultats des tests leur parviennent. Ce phénomène s'aggrave encore lorsque des bogues sont découverts tardivement, et les correctifs deviennent plus coûteux à implémenter. Dans les systèmes embarqués, ces délais sont structurels.\n\nSeule une approche DevSecOps permet de répondre efficacement à ces problématiques.\n\n## Axes de transformation prioritaires\n\nPortées par ces dynamiques de marché, les entreprises avant-gardistes dans le domaine des systèmes embarqués adoptent une approche DevSecOps pour transformer en profondeur leurs pratiques. \n\n### Mise en place de tests continus\n\nLes goulots d'étranglement matériels représentent l'une des contraintes les plus importantes du développement traditionnel de systèmes embarqués. Ces retards créent des conditions économiques défavorables dues à l'accès tardif au matériel et à l'augmentation des coûts qui en résultent.\nPour résoudre ce problème, il est nécessaire d'adopter une approche multidimensionnelle : \n\n* Automatiser l'orchestration des bancs de test matériel partagés, souvent coûteux, entre les développeurs  \n* Intégrer les tests SIL (Software-in-the-Loop) et HIL (Hardware-in-the-Loop) dans des pipelines CI automatisés  \n* Standardiser les environnements de compilation avec un [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") rigoureux\n\nAvec le composant [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que l'approche CI/CD ?\") [On-Premises Device Cloud](https://gitlab.com/gitlab-accelerates-embedded/comp/device-cloud) de GitLab, les équipes de développement de systèmes embarqués peuvent automatiser l'orchestration des tests de micrologiciels sur du matériel virtuel et réel. Elles réduisent ainsi plus facilement les cycles de rétroaction de plusieurs semaines à quelques heures et détectent les bogues dès le début du cycle du développement logiciel.\n\n### Automatisation de la conformité et de la sécurité\n\nLes systèmes embarqués évoluent dans un environnement fortement réglementé, où les processus de conformité manuels ne sont plus viables.\nLes entreprises à la pointe automatisent la gouvernance de leurs processus de sécurité et de conformité en adoptant plusieurs pratiques clés : \n\n* Elles remplacent les workflows manuels par des [frameworks de conformité](https://about.gitlab.com/fr-fr/blog/introducing-custom-compliance-frameworks-in-gitlab/ \"Qu'est-ce qu'un framework de conformité ?\") automatisés.  \n* Elles intègrent des outils spécialisés de sécurité fonctionnelle, de cybersécurité et de qualité du code dans des pipelines CI automatisés.  \n* Elles automatisent les workflows d'approbation, en appliquant systématiquement des revues de code et en maintenant des pistes d'audit complètes.  \n* Elles configurent des frameworks de conformité alignés sur des normes sectorielles, telles que ISO 26262 ou DO-178C.\n\nCette approche permet une plus grande maturité en matière de conformité sans effectifs supplémentaires. Ce qui constituait autrefois un fardeau devient un avantage concurrentiel. Un grand constructeur de véhicules électriques exécute ainsi 120 000 jobs CI/CD par jour avec GitLab, dont une part importante inclut des contrôles de conformité. Grâce à cette automatisation, l'entreprise peut corriger les bogues et déployer des corrections sur ses véhicules dans l'heure qui suit leur découverte. Un tel niveau d'évolutivité et de réactivité serait extrêmement difficile à atteindre sans l'automatisation des workflows de conformité.\n\n### Innovation collaborative\n\nHistoriquement, pour des raisons commerciales et techniques légitimes, les équipes chargées du développement de systèmes embarqués travaillaient souvent seules à leur bureau. Les possibilités de collaboration étaient ainsi limitées. Pour remédier à cette situation, les entreprises innovantes fournissent une visibilité partagée du code grâce à un contrôle de version intégré et à des workflows CI/CD. Ces pratiques modernes attirent et fidélisent les ingénieurs tout en favorisant l'innovation.\nComme le souligne le directeur [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que l'approche DevOps ?\") d'un grand constructeur automobile à la pointe de la technologie (client de GitLab) : « Il est vraiment essentiel pour nous de travailler sur une seule plateforme où il est facile de vérifier le statut de nos workflows. Lorsque les développeurs soumettent une merge request, ils ont immédiatement une visibilité sur le statut du workflow concerné afin de pouvoir agir le plus rapidement possible. » Cette transparence accélère l'innovation. Elle permet aux constructeurs automobiles d'itérer rapidement sur les fonctionnalités logicielles qui différencient leurs véhicules sur un marché de plus en plus concurrentiel.\n\n## Une fenêtre d'opportunité\n\nLes leaders du développement de systèmes embarqués disposent aujourd'hui d'une fenêtre d'opportunité unique pour prendre une longueur d'avance en adoptant l'approche DevSecOps. Mais ils doivent agir rapidement, car à mesure que les logiciels deviennent le principal levier de différenciation des produits embarqués, l'écart entre les pionniers et les retardataires ne cessera de se creuser.\nLes entreprises qui réussiront cette transition réduiront leurs coûts, accéléreront leurs délais de mise sur le marché et développeront des logiciels plus innovants qui leur permettront de se différencier. Les leaders du secteur de demain seront ceux qui, dès aujourd'hui, font le choix de l'approche DevSecOps.\n\n> Bien que cet article mette en lumière les raisons pour lesquelles il est désormais essentiel pour les équipes de développement de systèmes embarqués d'adopter l'approche DevSecOps, vous vous demandez peut-être par où commencer. Pour passer à l'action, découvrez comment mettre ces concepts en pratique dans notre guide : [Accélérez le développement de systèmes embarqués avec GitLab](https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab/).",[968],"Matt DeLaney","2025-08-06","DevSecOps et systèmes embarqués : pourquoi adopter cette approche ?",[109],"Surmontez la lenteur des boucles de rétroaction, la lourdeur des processus de conformité et l'isolement des équipes en adoptant une plateforme DevSecOps.",{"featured":6,"template":805,"slug":974},"why-now-is-the-time-for-embedded-devsecops",{"category":730,"slug":734,"posts":976},[977,991,1003],{"content":978,"config":989},{"heroImage":979,"date":980,"title":981,"description":982,"authors":983,"category":734,"tags":987,"body":988},"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é.",[984,985,986],"Suzanne Selhorn","Julia Miocene","Sarah German",[269],"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":805,"slug":990},"docs-site-design-overhaul",{"content":992,"config":1001},{"title":993,"description":994,"date":995,"body":996,"heroImage":997,"authors":998,"category":734,"tags":1000},"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",[999],"Stan Hu",[269,769,746],{"featured":6,"template":805,"slug":1002},"inside-gitlabs-healthy-backlog-initiative",{"content":1004,"config":1017},{"heroImage":1005,"body":1006,"authors":1007,"updatedDate":1010,"date":1011,"title":1012,"tags":1013,"description":1016,"category":734},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","Les sauvegardes de dépôt sont un élément essentiel de toute stratégie de\nreprise après un sinistre important. Cependant, à mesure que les dépôts\ngrossissent, garantir des sauvegardes fiables devient de plus en plus\ndifficile. Notre propre [dépôt Rails](https://gitlab.com/gitlab-org/gitlab)\nmettait 48 heures à être sauvegardé, ce qui nous obligeait à faire un choix\nimpossible entre la fréquence des sauvegardes et les performances du\nsystème. Nous avons donc décidé de trouver une solution à ce problème pour\nnos clients et pour nos propres équipes internes.\n\n\nAprès investigation, nous avons pu déterminer la cause du problème, qui remontait à une fonction Git vieille de 15 ans dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme et **avons ainsi réduit les temps de sauvegarde de manière exponentielle**. \n\n\nRésultat : des coûts réduits, des risques diminués, et surtout, des stratégies de sauvegarde désormais adaptées à la croissance de votre code source.\n\n\nCe problème d'évolutivité de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") affectait tout utilisateur disposant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.\n\n\n## Sauvegarde à grande échelle : enjeux et solutions\n\n\nÀ mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :\n\n\n* **Sauvegardes trop longues** : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.\n\n* **Utilisation intensive des ressources** : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter d'autres opérations critiques.\n\n* **Fenêtres de sauvegarde** : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes qui fonctionnent 24 h/24 et 7 j/7.\n\n* **Risque accru d'échec** : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, et obligent souvent les équipes à recommencer tout le processus depuis le début.\n\n* **Conditions de concurrence** : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus et peut conduire à une sauvegarde invalide ou à des interruptions liées à des objets devenus indisponibles.\n\n\nCes défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme l'utilisation d'outils externes ou la réduction de la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises.\n\n\nDécouvrez maintenant comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.\n\n\n## Le défi technique\n\n\nLa fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande [`git bundle create`](https://git-scm.com/docs/git-bundle/fr), qui génère un aperçu complet du dépôt avec tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration pour recréer le dépôt dans son état exact.\n\n\nCependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références et entraînait un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.\n\n\n### Analyse des causes profondes\n\n\nPour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.\n\n\n![Flame graph montrant la commande pendant son exécution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\n\nCe graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.\n\n\nLe flame graph de `git bundle create` exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction `object_array_remove_duplicates()`, introduite dans Git par le biais du [commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).\n\n\nPour comprendre ce changement, il est important de savoir que la commande `git bundle create` permet de préciser les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag `--all` compacte toutes les références.\n\n\nCe commit corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que `git bundle create main.bundle main main`, et créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois, ce qui provoquait une erreur. \n\n\nLe code ajouté pour éviter ces duplications utilise des boucles `for` imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) est un goulot d'étranglement majeur en termes de performance dans les dépôts car il contient un grand nombre de références et prolonge considérablement le temps de traitement des données.\n\n\n### La solution : d'O(N²) à un mappage efficace\n\n\nPour résoudre ce problème, nous avons proposé une correction en amont dans Git pour remplacer les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.\n\n\nCe changement améliore considérablement les performances de la commande `git bundle create` et garantit une bien meilleure évolutivité dans les dépôts avec un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.\n\n\n```shell\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\n\nLe correctif a été accepté et [fusionné](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d) dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement sans attendre la prochaine version officielle de Git.\n\n\n## Résultat : des temps de sauvegarde radicalement réduits\n\n\nLes gains de performance qui découlent de cette amélioration sont considérables :\n\n\n* **De 48 heures à 41 minutes** : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.\n\n* **Performances constantes** : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.\n\n* **Efficacité des ressources** : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.\n\n* **Applicabilité étendue** : si le processus de sauvegarde est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets avec un grand nombre de références en profitent également.\n\n\n## Avantages pour nos clients GitLab\n\n\nPour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :\n\n\n* **Transformation des stratégies de sauvegarde**   \n\n  * Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.   \n  * Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans processus longs ni dédiés.  \n* **Continuité des activités améliorée**  \n\n  * Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits, tout comme le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.\n* **Réduction de la charge opérationnelle**   \n\n  * La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.  \n  * Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.\n* **Pérennisation de l'infrastructure**   \n\n  * La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.   \n  * À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.\n\nLes entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un compromis difficile est devenu une pratique opérationnelle simple.\n\n\nÀ partir de la version [GitLab 18.0](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/), tous les clients GitLab, quelle que soit leur version de licence, profitent désormais pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs [sauvegardes](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/), sans aucune autre modification de la configuration.\n\n\n## Et après ?\n\n\nCette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente une étape majeure, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.\n\n\nNous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git afin de profiter non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.\n\n\n> Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Consultez le [replay de notre événement virtuel de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/) et découvrez les autres améliorations fondamentales que nous proposons.\n",[1008,1009],"Karthik Nayak","Manuel Kraft","2025-07-09","2025-06-05","Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min ",[1014,902,1015],"git","performance","L'optimisation d'une fonction Git vieille de 15 ans a permis d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de réduire les risques.",{"slug":1018,"featured":91,"template":805},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"category":742,"slug":746,"posts":1020},[1021,1033,1044],{"content":1022,"config":1031},{"heroImage":1023,"date":1024,"authors":1025,"body":1027,"category":746,"tags":1028,"title":1029,"description":1030},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1757675943/q9kb7zfiw1cyxx9fcafp.png","2025-09-17",[1026],"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/security-compliance/) 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.*",[769,746,718],"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":805,"slug":1032},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"content":1034,"config":1042},{"date":856,"authors":1035,"heroImage":1037,"title":1038,"description":1039,"tags":1040,"category":746,"body":1041},[1036,942],"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.",[746,769,718],"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":805,"slug":1043},"gitlab-and-accenture-announce-global-reseller-agreement",{"content":1045,"config":1056},{"title":1046,"description":1047,"authors":1048,"heroImage":1050,"date":1051,"body":1052,"category":746,"tags":1053,"updatedDate":1055},"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.",[1049],"Dave Steer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2024-11-13","Une plateforme DevSecOps puissante rationalise les opérations, empêche les failles de sécurité de perturber (et de coûter cher à) votre entreprise, augmente la productivité et favorise une culture basée sur l'innovation et la collaboration. C'est exactement ce pour quoi nous avons créé GitLab, et l'édition GitLab Ultimate représente toute la puissance de notre plateforme. Pour connaître son influence concrète, nous avons demandé à Forrester Consulting de réaliser une étude « Total Economic Impact™ » sur GitLab Ultimate. Découvrez dans cet article les principales conclusions de cette étude. \n\nSelon les retours des clients interrogés, l'utilisation de GitLab génère à l'entreprise de référence :  \n\n* **Un retour sur investissement de 483 % sur trois ans**  \n* **Une amélioration de 400 % de la productivité des équipes de développement**  \n* **Une première mise en production 15 fois plus rapide\u003Csup>1\u003C/sup>**  \n* **Un gain de temps multiplié par 5 pour les tâches liées à la sécurité**\n\n**En somme, GitLab permet d'accomplir 50 % de travail à valeur ajoutée en plus.** \n\nLes chiffres parlent d'eux-mêmes : la plateforme GitLab transforme  la manière dont les équipes collaborent entre elles. Que vous soyez un responsable de la sécurité des applications chargé d'améliorer la posture de sécurité de votre entreprise, un membre de l'équipe de développement qui cherche à fournir un code de haute qualité plus rapidement ou encore un CTO à la recherche d'une plateforme DevSecOps évolutive, sécurisée et flexible, cette étude (dont la méthodologie complète est disponible ci-dessous) montre que GitLab Ultimate tient ses promesses. Examinons les résultats de l'étude.  \n\n> Téléchargez l'étude complète de [Forrester Consulting intitulée « The Total Economic Impact™ Of GitLab Ultimate » (2024)](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n## 1. Un ROI de 483 % sur trois ans\n\n*« La clé du succès pour nous a été le gain d'efficacité, à la fois au niveau de l'administration et des opérations globales. Aujourd'hui, le travail en équipe est accessible à tous et nous pouvons facilement automatiser notre pipeline. Je peux également changer la composition des équipes pour effectuer différentes tâches plus efficacement. Au lieu de former nos équipes sur différents outils en fonction des programmes, il leur suffit désormais de maîtriser GitLab pour pouvoir immédiatement se mettre au travail. »* - CTO et Senior Vice President (secteur de la Défense)\n\nL'étude révèle que les entreprises interrogées ont constaté un retour sur investissement dans les six mois suivant l'adoption de GitLab Ultimate, principalement grâce à une efficacité accrue. Avec un **retour sur investissement de 483 % sur trois ans**, elles ont pu réduire le coût de leur chaîne d'outils logiciels de 25 % et le temps consacré par leurs équipes informatiques à l'administration de ces chaînes d'outils complexes de 75 %. Au-delà des économies financières réalisées, le passage à une plateforme unifiée améliore fondamentalement la façon dont les équipes développent et livrent les logiciels.\n\n## 2. Une amélioration de la productivité de 400 %\n\n*« Lorsque j'échange avec les membres de notre équipe de développement à propos de GitLab, ils s'accordent tous sur le fait que son utilisation a augmenté la productivité de notre entreprise, à tous les niveaux et à tous les postes. Nous disposons aujourd'hui d'une plateforme dotée de fonctions et fonctionnalités accessibles à tous nos collaborateurs. »* - Software Architect, (secteur de l'énergie et de la recherche)\n\nLes équipes de développement travaillent mieux dans des environnements où ils peuvent facilement passer d'une tâche à l'autre sans interruptions. Selon cette étude, les développeurs et développeuses peuvent gagner jusqu'à 305 heures par an en [automatisant les tests](https://about.gitlab.com/fr-fr/topics/devops/devops-test-automation/) dans GitLab. Ils peuvent ainsi tester plus souvent, mais aussi suivre et corriger les bugs plus rapidement, le tout au sein d'une seule interface et donc sans changement de contexte. Ce workflow rationalisé leur permet de se concentrer sur le code plutôt que de jongler avec plusieurs outils et processus.\n\nLes gains de productivité s'étendent également à l'intégration : les nouvelles recrues de l'équipe de développement logiciel de l'entreprise de référence atteignent une productivité optimale 75 % plus rapidement (c'est-à-dire en 1,5 semaine au lieu de 1,5 mois). L'impact est clair : non seulement tous les membres de l'équipe peuvent contribuer à des tâches importantes, mais ils peuvent le faire plus tôt. \n\n## 3. Une première mise en production 15 fois plus rapide\n\n*« Le logiciel est notre botte secrète. Les éléments clés sont notre vélocité et notre capacité à offrir de nouvelles fonctionnalités à nos clients. Pour pouvoir nous concentrer sur ces objectifs premiers, il était logique d'un point de vue économique de \\[consolider\\] nos processus sur une plateforme unique. »* - CTO et Senior Vice President (secteur de la Défense)\n\nL'agrégation des données issues des entretiens avec nos clients révèlent que GitLab permet aux entreprises de déployer une première mise en production 15 fois plus rapidement. Cette accélération est facilitée par le démarrage plus rapide des projets, le déploiement plus fréquent de nouvelles versions, sans oublier une approche proactive de la sécurité qui intègre de manière native le scanning de sécurité dès le début du processus de développement. Il est ainsi possible de maintenir une qualité et une sécurité de haut niveau pour les logiciels, même dans le cadre d'une vélocité accrue, car les équipes de développement sont capables de remédier aux problèmes rapidement, dès leur apparition. \n\nL'[intégration de la sécurité directement dans le processus de développement](https://about.gitlab.com/solutions/security-compliance/) permet aux équipes d'identifier, de prioriser et de corriger les failles de sécurité sans interrompre leur workflow. Cette approche unifiée de la gestion de l'ensemble du cycle de développement logiciel permet aux équipes de progresser plus rapidement sans sacrifier la sécurité.\n\n## 4. Un gain de temps multiplié par 5 pour les tâches liées à la sécurité\n\n*« L'intégration des scanners de sécurité et de qualité dans le pipeline a changé la donne. Grâce à une automatisation accrue et à la réduction des processus manuels, nos pipelines rencontrent moins d'échecs, moins de problèmes et les projets avancent plus rapidement. »* - Program Manager (secteur financier) \n\nFace à l'accélération du développement et à l'évolution des menaces, la sécurité reste une priorité absolue pour toutes les entreprises. GitLab permet aux membres des équipes chargées de la sécurité de l'entreprise de référence d'économiser **78 heures par membre et par an** en automatisant les tâches récurrentes telles que la préparation à la reprise après sinistre, les audits et les contrôles de conformité. GitLab améliore également la visibilité des processus de développement logiciel, en aidant les équipes dédiées à la sécurité et au développement à mieux collaborer.  \n\nPour les équipes de cybersécurité et de développement logiciel de l'entreprise de référence, **la gestion et la réduction des risques de sécurité tout au long du cycle de développement logiciel nécessitent désormais 81 % d'efforts en moins.** En effet, GitLab leur permet d'intégrer des protocoles et des scans de sécurité à chaque étape du cycle de développement logiciel, ce qui simplifie le maintien de normes de sécurité strictes. Grâce à l'intégration des tests de sécurité et des mesures correctives dans les pipelines, les équipes réduisent les temps de réponse moyens et empêchent les problèmes d'atteindre l'environnement de production. \n\n## Découvrez l'approche DevSecOps en action\n\nAvec un retour sur investissement de 483 %, un amortissement rapide et d'innombrables exemples de réussites, GitLab est un outil inestimable pour les entreprises qui cherchent à transformer leurs processus de développement logiciel.\n\n> Pour découvrir les avantages de GitLab pour votre entreprise, téléchargez dès maintenant l'étude complète de [Forrester Consulting intitulée « The Total Economic Impact™ Of GitLab Ultimate »](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n**Méthodologie**  \n\n*Dans le cadre de cette étude, Forrester a interrogé quatre clients ayant adopté GitLab Ultimate et exerçant dans divers secteurs (notamment celui de la Finance, de la Défense et de la Recherche), puis a consolidé les résultats sous la forme d'une entreprise de référence. L'objectif pour cette entreprise de référence est d'adopter GitLab Ultimate pour l'ensemble de ses équipes sur une période de trois ans.*\n\n*L'entreprise de référence est une société au capital de 5 milliards de dollars, qui compte 5 000 employés (dont 40 % sont impliqués dans la livraison de logiciels) et 50 % de son chiffre d'affaires annuel dépend du développement logiciel. Ses objectifs sont de consolider plusieurs outils sous la forme d'une plateforme intégrée unique, d'améliorer la productivité de son équipe de développement, de garantir le respect des réglementations du secteur et de ses politiques internes, et de renforcer la sécurité tout au long du cycle de développement.*\n\n*1. Sur la base de données agrégées issues des entretiens avec nos clients ; non applicable aux résultats de l'entreprise de référence.*",[803,1054,746,781],"research","2024-11-26",{"slug":1057,"featured":91,"template":805},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"category":754,"slug":758,"posts":1059},[1060,1071,1084],{"content":1061,"config":1069},{"title":1062,"description":1063,"authors":1064,"heroImage":1065,"date":1066,"body":1067,"category":758,"tags":1068},"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).",[1008],"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",[1014,902,269],{"featured":6,"template":805,"slug":1070},"what-s-new-in-git-2-51-0",{"content":1072,"config":1082},{"description":1073,"title":1074,"category":758,"tags":1075,"heroImage":1076,"date":1077,"body":1078,"authors":1079},"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",[902,269,769],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_820,h_500,c_lfill/v1750099558/Blog/Hero%20Images/gitlabflatlogomap.png","2025-07-22","L'équipe Contributor Success de GitLab faisait face au défi suivant : alors\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",[1080,1081],"Lee Tickett","Daniel Murphy",{"featured":6,"template":805,"slug":1083},"how-we-use-gitlab-to-grow-open-source-communities",{"content":1085,"config":1094},{"body":1086,"title":1087,"description":1088,"heroImage":1089,"authors":1090,"date":1092,"category":758,"tags":1093},"Le projet Git a récemment publié la [version 2.50.0 de Git](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u).\n\nDécouvrons les points forts de cette nouvelle version, qui comprend les contributions de l'équipe Git de GitLab et de la communauté Git.\n\n\n## Nouvelle commande git-diff-pairs(1)\n\n\nLes diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet [« Modifications »](https://docs.gitlab.com/user/project/merge_requests/changes/) d'une merge request. En arrière-plan, la génération de diff est effectuée par [`git-diff(1)`](https://git-scm.com/docs/git-diff).\n\n\nPar exemple :\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nCette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème de performance, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser le délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à traiter.\n\n\nPour ce faire, vous pouvez utiliser [`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree/fr) pour récupérer des informations sur tous les fichiers modifiés :\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n\n:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n\n\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n\n```\n\n\nGit appelle ce résultat le [format « brut »](https://git-scm.com/docs/git-diff-tree/fr). En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de diffs pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer une détection de changement de nom en ajoutant `-M` pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.\n\n\nAvec ces informations, nous pourrions utiliser `git-diff(1)` pour calculer chacun des diffs de paire de fichiers individuellement.\n\n\nPar exemple, nous pouvons fournir directement des ID de blob :\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nNous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme pouvant recevoir des informations « brutes » sur les paires de fichiers et générant en sortie les diffs correspondants.\n\n\nAvec la version 2.50.0, Git dispose d’une nouvelle commande intégrée `git-diff-pairs(1)`, qui reçoit sur son entrée standard (« stdin ») les informations de paires de fichiers au format « brut » pour déterminer avec précision les diffs à générer.\n\n\nL'exemple suivant montre comment cette commande peut être utilisée :\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nDe cette façon, la sortie générée est identique à celle obtenue avec `git-diff(1)`. En utilisant une commande distincte pour générer la sortie de diffs, la sortie « brute » de `git-diff-tree(1)` peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus `git-diff-pairs(1)` distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.\n\n\nPour plus d'informations sur ce changement, consultez ce [fil de discussion](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## Mises à jour des références par lots\n\n\nGit fournit la commande `git-update-ref(1)` pour effectuer des mises à jour de références. Lorsqu'elle est associée à `--stdin`, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur l'entrée standard (« stdin »). La mise à jour des références en un seul lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.\n\n\nVoici un exemple illustrant ce comportement :\n\n\n```shell\n\n# Create repository with three empty commits and branch named \"foo\"\n\n\n$ git init\n\n\n$ git commit --allow-empty -m 1\n\n\n$ git commit --allow-empty -m 2\n\n\n$ git commit --allow-empty -m 3\n\n\n$ git branch foo\n\n\n# Print out the commit IDs\n\n\n$ git rev-list HEAD\n\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n\n# Update is expected to fail because the specified old object ID doesn’t match.\n\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n> EOF\n\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# The \"bar\" reference was not created.\n\n\n$ git switch bar\n\n\nfatal: invalid reference: bar\n\n```\n\n\nEn comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Mais nous voulons quand même bénéficier de l'efficacité des mises à jour par lot.\n\n\nAvec cette version, `git-update-ref(1)` met à disposition la nouvelle option `--batch-updates`, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.\n\n\nDans ce mode, les échecs individuels sont signalés dans le format suivant :\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nIl est ainsi possible de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.\n\n\nVoici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :\n\n\n```shell\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n> EOF\n\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n\n\n$ git switch bar\n\n\nSwitched to branch 'bar'\n\n```\n\n\nCette fois, avec l'option `--batch-updates`, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de diffs est un aperçu des futures améliorations des performances de `git-fetch(1)` et `git-receive-pack(1)` lors de la mise à jour de références par lot.\n\n\nPour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/).\n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n## Nouvelle option de filtre pour git-cat-file(1)\n\n\nAvec `git-cat-file(1)`, il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option `--batch–all-objects`.\n\n\nEn voici un exemple :\n\n\n```shell\n\n# Setup simple repository.\n\n\n$ git init\n\n\n$ echo foo >foo\n\n\n$ git add foo\n\n\n$ git commit -m init\n\n\n# Create an unreachable object.\n\n\n$ git commit --amend --no-edit\n\n\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nDans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.\n\n\nPar exemple, si nous voulons voir uniquement les objets qui sont des commits, nous pouvons utiliser `grep(1)` :\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nBien que cela fonctionne, un des inconvénients du filtrage de la sortie est que `git-cat-file(1)` doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.\n\n\nAvec la version 2.50.0, `git-cat-file(1)` dispose désormais de l'option `--filter`, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour `git-rev-list(1)`, mais seul un sous-ensemble des filtres est pris en charge : `blob:none`, `blob:limit=`, ainsi que `object:type=`.\n\n\nComme dans l'exemple précédent, il est possible de filtrer les objets par type avec [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") directement :\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nNon seulement il est pratique de laisser Git s'occuper du traitement, mais pour les dépôts volumineux contenant de nombreux objets, c'est aussi potentiellement plus efficace. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage (« packfile »), ce qui accélère significativement le processus.\n\n\nLes benchmarks effectués sur le [dépôt Chromium](https://github.com/chromium/chromium.git) montrent des améliorations significatives :\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\n\n\nRange (min … max): 73.936 s … 89.690 s 10 runs\n\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\n\n\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\n\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\n\n\nRange (min … max): 1.541 s … 1.566 s 10 runs\n\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\n\n\nRange (min … max): 11.114 s … 11.245 s 10 runs\n\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\n\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\n\n\nRange (min … max): 62.836 s … 73.618 s 10 runs\n\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\n\n\nRange (min … max): 12.960 s … 13.199 s 10 runs\n\n\nSummary\n\n\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\n\n3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n```\n\n\nIl est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n## Amélioration des performances lors de la génération d'archives\n\n\nAvec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui les accompagnent via la commande [`git-bundle(1)`](https://git-scm.com/docs/git-bundle/fr). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme [`bundle-URI`](https://git-scm.com/docs/bundle-uri).\n\n\nPour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab ([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans l'archive. L'implémentation utilisait une boucle `for` imbriquée pour itérer et comparer toutes les références répertoriées, ce qui entrainait une complexité temporelle O(N^2). Cette façon de procéder dégradait fortement les performances à mesure que le nombre de références dans un dépôt augmentait.\n\n\nDans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par un tableau associatif, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'une archive avec un dépôt contenant 100 000 références :\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n\n\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\n\n\nRange (min … max): 14.237 s … 14.920 s 10 runs\n\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n\n\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\n\n\nRange (min … max): 2.364 s … 2.425 s 10 runs\n\n\nSummary\n\n\nbundle (refcount = 100000, revision = HEAD) ran\n\n\n6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\n\nPour en savoir plus, découvrez notre article de blog qui explique [comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) et consultez ce [fil de discussion](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n*Ce projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n## Meilleur dégroupage des URI d'archives\n\n\nÀ l'aide du mécanisme [bundle-uri](https://git-scm.com/docs/bundle-uri) dans Git, il est possible de fournir aux clients les emplacements pour récupérer des archives dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge une archive, les références sous `refs/heads/*` et les objets qui les accompagnent sont copiés de l'archive dans le dépôt. Une archive peut contenir des références supplémentaires en dehors de `refs/heads/*` telles que `refs/tags/*`, qui sont simplement ignorées lors de l'utilisation de bundle-uri sur le clone.\n\n\nDans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à `refs/*` contenues dans l'archive téléchargée sont copiées.\n\n\n[Scott Chacon](https://github.com/schacon), qui a contribué à cette fonctionnalité, montre la différence lors du clonage de [gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss) :\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\n\nCloning into 'gl2.49'...\n\n\nremote: Enumerating objects: 1092703, done.\n\n\nremote: Counting objects: 100% (973405/973405), done.\n\n\nremote: Compressing objects: 100% (385827/385827), done.\n\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\n\nChecking objects: 100% (4194304/4194304), done.\n\n\nChecking connectivity: 959668, done.\n\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\n\nCloning into 'gl-2.50'...\n\n\nremote: Enumerating objects: 65538, done.\n\n\nremote: Counting objects: 100% (56054/56054), done.\n\n\nremote: Compressing objects: 100% (28950/28950), done.\n\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nEn comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction de l'archive, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.\n\n\nPour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n*Cette série de contributions a été fournie par Scott Chacon.*\n\n\n## En savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) du projet Git et en consultant ces [ressources](https://about.gitlab.com/blog/tags/git/).\n","Nouveautés de Git 2.50.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png",[1091],"Justin Tobler","2025-07-02",[269,1014,902],{"featured":6,"template":805,"slug":1095},"what-s-new-in-git-2-50-0",{"category":90,"slug":769,"posts":1097},[1098,1109,1121],{"content":1099,"config":1107},{"heroImage":1100,"date":1101,"title":1102,"description":1103,"authors":1104,"body":1105,"category":769,"tags":1106},"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.",[1026],"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.*",[769,746,932],{"featured":6,"template":805,"slug":1108},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms",{"content":1110,"config":1119},{"title":1111,"description":1112,"authors":1113,"heroImage":1115,"date":1116,"body":1117,"category":769,"tags":1118},"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.",[1114],"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/2023/01/18/try-out-new-way-to-migrate-projects/). Depuis, nous avons travaillé à améliorer l'efficacité et la fiabilité de l'importation, en particulier pour les projets volumineux. Nous avons é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 !",[718,769,817],{"featured":91,"template":805,"slug":1120},"migrating-by-direct-transfer-is-generally-available",{"content":1122,"config":1130},{"title":1123,"description":1124,"authors":1125,"heroImage":897,"date":1127,"body":1128,"category":769,"tags":1129},"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.",[968,1126],"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":1131,"featured":6,"template":805},"4-ways-to-accelerate-embedded-development-with-gitlab",{"category":777,"slug":781,"posts":1133},[1134,1146,1157],{"content":1135,"config":1144},{"heroImage":1136,"date":1137,"title":1138,"description":1139,"authors":1140,"body":1142,"category":781,"tags":1143},"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","2025-10-01","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.",[1141],"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/security-compliance/)  \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",[781,818,803,234,769,817],{"featured":6,"template":805,"slug":1145},"secure-and-safe-login-and-commits-with-gitlab-yubico",{"content":1147,"config":1155},{"title":1148,"description":1149,"authors":1150,"date":1151,"body":1152,"category":781,"tags":1153,"heroImage":1154},"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.",[942],"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 !",[803,781],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758890538/ct0ffsxm1eyfeppyrnjt.jpg",{"featured":6,"template":805,"slug":1156},"what-is-vulnerability-management",{"content":1158,"config":1169},{"title":1159,"description":1160,"authors":1161,"heroImage":1163,"date":1164,"body":1165,"category":781,"tags":1166},"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.",[1162],"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.",[1167,1168],"sécurité","intégré à GitLab",{"featured":6,"template":805,"slug":1170},"how-to-transform-compliance-observation-management-with-gitlab",{"content":1172,"config":1183},{"title":1173,"description":1174,"authors":1175,"heroImage":1177,"date":1178,"body":1179,"category":686,"tags":1180},"GitLab Duo : optimiser les suggestions de code de l'IA","Découvrez comment utiliser les suggestions de code et les combiner avec nos autres fonctionnalités IA pour optimiser l'expérience de développement (avec exercices).",[1176],"Michael Friedrich","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669095/Blog/Hero%20Images/gitlabduo.png","2025-09-10","[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités alimentées par l'IA, offre une occasion unique d'optimiser vos workflows DevSecOps. Pour en tirer pleinement parti, rien ne vaut la pratique et l'apprentissage collaboratif en situation réelle. Ce tutoriel se concentre sur les suggestions de code de GitLab Duo. Il fournit des conseils et des bonnes pratiques ainsi que quelques bonus (notamment comment combiner les suggestions de code avec nos autres fonctionnalités d'IA pour gagner encore en efficacité). Vous découvrirez également comment l'IA améliore considérablement l'expérience développeur.\n\nLes bonnes pratiques, conseils et exemples présentés dans cet article ont été conçus sur mesure par l'équipe Developer Relations de GitLab. Ils sont intégrés à la [documentation dédiée à GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/index.html) ainsi qu'au [projet GitLab Duo Prompts](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts) associé. N'hésitez pas à ajouter cette page à vos favoris et revenez-y dès que vous en ressentirez le besoin.\n\n## Pourquoi utiliser les suggestions de code de GitLab Duo ?\n\nPrenons comme exemple deux scénarios :\n\n1. En tant que développeur senior, vous maîtrisez différents langages de programmation pour pouvoir écrire du nouveau code source, réviser celui de vos pairs, concevoir des architectures résilientes et lancer de nouveaux projets. Cependant, se former sur les nouvelles fonctionnalités des langages de programmation nécessite du temps, des recherches et un réel effort d'adaptation. Alors, comment apprendre rapidement celles qui pourraient rendre votre code encore plus performant ou utiliser les ressources de manière plus durable ?\n\n    - Personnellement, j'ai appris la norme C++03, puis adopté C++11 sans jamais vraiment m'approprier les versions C++14/17/20/23. Entre-temps, de nouveaux langages tels que [Rust](https://about.gitlab.com/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/) sont apparus, et ils offrent une expérience développeur bien plus moderne. Que faire dans ce contexte ?\n\n2. En tant qu'ingénieur junior, il peut être difficile d'appréhender de nouveaux projets, d'apprendre un nouveau langage de programmation, de comprendre certains algorithmes spécifiques et de trouver la documentation sur les structures, les interfaces et d'autres composants techniques. Le tout, souvent sous pression, ce qui augmente le risque d'erreurs et entraîne des blocages. Le temps manque pour se pencher sur les bonnes pratiques.\n\n    - Moi-même, je n'ai jamais réellement appris le développement frontend. J'ai quelques notions en HTML, CSS et JavaScript acquises en autodidacte. Et après dix ans, j'ai du mal à m'adapter à des frameworks frontend tels que VueJS. Et le temps pour apprendre se fait rare.\n\nCes scénarios illustrent à quel point il est difficile de suivre l'évolution constante des langages de programmation, bonnes pratiques et autres informations importantes. Mais les [suggestions de code de GitLab Duo](https://about.gitlab.com/fr-fr/solutions/code-suggestions/) peuvent vous aider : elles prédisent et complètent vos blocs de code, définissent la logique de vos fonctions, génèrent des tests automatisés et proposent du code courant, comme des motifs regex, le tout directement dans votre environnement de développement. Alimentée par l'IA, cette fonctionnalité vous aide à approfondir vos connaissances sans quitter votre workflow.\n\n## Commencer avec des prompts simples, puis les affiner\n\nJ'ai commencé mon parcours d'adoption de GitLab Duo par des prompts simples tenant sur une ligne, souvent avec des résultats peu convaincants. \n\n```\n# Generate a webserver\n\n// Create a database backend\n\n/* Use multi-threaded data access here */\n```\n\nAprès avoir testé différents contextes et styles de rédaction de prompts, j'ai rapidement constaté que la génération de code était beaucoup plus pertinente à partir de requêtes affinées. \n\n```\n# Generate a webserver, using the Flask framework. Implement the / URL endpoint with example output.\n\n// Create a database backend. Abstract data handlers and SQL queries into function calls.\n\n/* Use multi-threaded data access here. Create a shared locked resource, and focus on supporting Linux pthreads. */\n```\n\nCependant, les prompts et commentaires seuls ne suffisent pas. Explorons d'autres bonnes pratiques.\n\n## Pratiquer continuellement  \n\nDans vos workflows quotidiens, identifiez des cas d'utilisation et des défis spécifiques, et utilisez exclusivement GitLab Duo pour les traiter. Bien qu'il soit tentant d'ouvrir des onglets de recherche dans votre navigateur, vous pouvez souvent résoudre le problème directement dans votre IDE avec GitLab Duo. Voici quelques exemples :\n\n1. Corrigez des dépendances manquantes, souvent responsables d'échecs lors de la compilation ou de l'exécution.\n1. Laissez les suggestions de code compléter automatiquement les appels de fonction lorsque le contexte de journalisation est manquant, y compris les instructions `print`.\n1. Générez des méthodes et des attributs courants pour les design patterns orientés objet (par exemple, les accesseurs/mutateurs getter/setter, les méthodes `toString()`, les opérateurs de comparaison d'objets, l'héritage d'objets, et bien plus encore).\n1. Identifiez la fonction à l'origine de plantages aléatoires et implémentez-en une nouvelle avec un algorithme différent à l'aide des suggestions de code.\n1. En cas d'erreur cryptique empêchant la compilation ou l'exécution, demandez à GitLab Duo Chat de vous aider.\n1. Analysez le code (hérité) existant et les stratégies pour documenter et refactoriser le code vers des bibliothèques modernes. Lancez une version v2 de l'application avec un nouveau framework ou langage afin de réduire la dette technique.\n1. Prévenez les problèmes d'opérations et de sécurité dans l'historique Git en les détectant en amont (performances, plantages, failles de sécurité).\n\nEnfin, pensez à la tâche de codage la plus ennuyeuse (voire celle que vous détestez le plus) et ajoutez-la à cette liste. Personnellement, je redoute les tâches impliquant les accesseurs/mutateurs getter/setter d'attributs dans les classes C++ (comme le montre la vidéo ci-dessous), juste avant les expressions régulières d'analyse du format des adresses e-mail.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Z9EJh0J9358?si=QGvQ6mXxPPz4WpM0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\nIl peut également être utile d'utiliser les suggestions de code dans différents langages de programmation, par exemple en alternant entre langages backend et frontend. Si vous maîtrisez plusieurs d'entre eux, réutilisez ceux que vous n'avez pas pratiqués depuis un certain temps, ou envisagez d'en apprendre un nouveau, tel que [Python](https://about.gitlab.com/blog/learning-python-with-a-little-help-from-ai-code-suggestions/) ou [Rust](https://about.gitlab.com/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/). \n\nUne fois intégrées dans un workflow d'auto-complétion rapide, les suggestions de code ne souffrent d'aucune interruption. Le code suggéré s'affiche en grisé et reste facultatif, selon l'interface utilisateur, par exemple VS Code, ce qui ne vous empêchera pas de continuer à écrire du code source sans distraction. Prenez le temps de vous familiariser avec la façon dont les suggestions de code s'affichent et la manière de les accepter entièrement ou partiellement. Vous verrez qu'elles deviendront très vite une aide discrète mais précieuse pour écrire du code de meilleure qualité.  \n\n![Image avec suggestions de code grisées](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_java_springboot_class_methods_tostring.png)\n\n### Corriger les dépendances manquantes\n\nIl n'est pas rare que la compilation ou l'exécution du code source échoue à cause de dépendances non déclarées, qui peuvent être journalisées et empêcher toute exécution et tout test ultérieurs. Prenons l'exemple suivant en Go : une erreur générée par `go build` signale que le code source n'a pas encore importé les dépendances nécessaires. L'approche manuelle consisterait à collecter toutes les dépendances répertoriées, à les trier de manière unique et à les ajouter dans le fichier de code source, comme illustré ci-dessous.\n\n![Échec de la compilation Go – dépendances manquantes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_build_failed_missing_deps.png)\n\nMais si GitLab Duo connaît déjà le contexte du fichier et peut identifier les dépendances manquantes, pourquoi ne pas en profiter ? Dans la section située tout en haut du fichier, il suffit d'ajouter un commentaire indiquant `// add missing imports`, puis de patienter un instant : les suggestions de code proposeront automatiquement les lignes à importer.\n\n![Suggestions de code de GitLab Duo – correction suggérée pour les dépendances manquantes ayant entraîné l'échec de la commande go build](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_build_failed_missing_deps_suggested_fix.png)\n\nEnsuite, relancez `go build`, et si tout se passe bien, le code source pourra être testé et s'exécutera correctement.\n\n![Échec de la commande go build – correction des dépendances manquantes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_build_failed_missing_deps_fixed.png)\n\n### Générer du code standardisé avec une journalisation optimisée\n\n*Défi : mettre en place un système de journalisation, et d'autres mécanismes d'observabilité incluant des indicateurs et traces, peut s'avérer fastidieux et complexe. Quel est le moyen le plus efficace de les mettre en œuvre sans affecter les performances de l'application ni introduire de bogues ?*\n\n*Solution : utilisez les suggestions de code pour générer les appels de fonction de journalisation et refactorisez le code en vous appuyant sur des abstractions robustes via des bibliothèques d'instrumentation dédiées à l'observabilité. Cette approche peut par exemple vous aider à préparer le code pour une intégration ultérieure avec [OpenTelemetry](https://docs.gitlab.com/ee/development/stage_group_observability/gitlab_instrumentation_for_opentelemetry.html).*\n\nExemple d'une classe de journalisation en Ruby :\n\n```ruby\n# Create Logging utility class\n# Define default log level as attribute\n# Add method for logging, inputs: level, app, message\n# Print the data with formatted date and time in syslog format\n\n# Potential AI-generated code below\nclass Logging\n  attr_accessor :log_level\n\n  def log(level, app, message)\n    time = Time.now.strftime(\"%b %d %H:%M:%S\")\n    puts \"#{time} #{app}[#{Process.pid}]: #{level} - #{message}\"\n  end\nend\n\n# Instantiate class and test the log method\n\n# Potential AI-generated code below\nlogger = Logging.new\nlogger.log_level = :debug\n\nlogger.log(:info, 'MyApp', 'Application started - info')\nlogger.log(:debug, 'MyApp', 'Application started - debug')\nlogger.log(:error, 'MyApp', 'Application started - error')\nlogger.log(:fatal, 'MyApp', 'Application started - fatal')\nlogger.log(:warn, 'MyApp', 'Application started - warn')\n```\n\n### Créer des tests pour les fonctions d'assistance utilitaires\n\n*Défi : le langage de programmation utilisé ne fournit pas certaines fonctions de base dans sa bibliothèque standard. L'envie est grande d'ouvrir un onglet de recherche dans mon navigateur pour trouver et ajouter des fonctions de manipulation de chaînes et d'analyse via des expressions régulières.*\n\n*Solution : Créez un fichier nommé `utility.{language-suffix}` et ajoutez un commentaire en tête de fichier. Demandez ensuite aux suggestions de code de générer la fonction de manipulation de chaîne ().*\n\nExemple de méthode de manipulation de chaîne en Python :\n\n```python\n# Create a function to search for a string in a string, return the index\n# Optionally remove search string, and return modified string\n# Test the function on the string \"Cool programming languages: C++, Rust, Python\" - Remove the string \"C++\"\n\n# Potential AI-generated code below\ndef search_and_remove(text, search):\n    index = text.find(search)\n    if index != -1:\n        return index, text[:index] + text[index+len(search):]\n    else:\n        return None, text\n\ntext = \"Cool programming languages: C++, Rust, Python\"\nindex, new_text = search_and_remove(text, \"C++\")\nprint(index, new_text)\n```\n\n**Exercice asynchrone :** demandez à GitLab Duo Chat comment ajouter des tests en Python, sélectionnez le code source concerné et utilisez la commande slash `/tests`. \n\nExemple similaire en Go : créez des fonctions utilitaires pour obtenir les valeurs entières uniques dans un tableau, ou pour calculer la somme de toutes les valeurs paires. Commencez par définir la structure du projet via `go mod init gitlab.com/group/project`, puis créez un fichier `array.go`. Définissez le `package` et ajoutez un premier commentaire pour générer des fonctions.\n\n```go\npackage array \n\n// Create a function that returns unique values from an integer array\n\n// Possible AI-generated code\nfunc unique(ints []int) []int {\n    occurred := map[int]bool{}\n    result := []int{}\n    for _, i := range ints {\n        if !occurred[i] {\n            occurred[i] = true\n            result = append(result, i)\n        }\n    }\n    return result\n}\n\n// Create a function that returns the sum of all even numbers in an integer array\n\n// Possible AI-generated code\nfunc sumEvens(ints []int) int {\n    var sum int\n    for _, i := range ints {\n        if i%2 == 0 {\n            sum += i\n        }\n    }\n    return sum\n}\n```\n\n**Exercice asynchrone** : créez plus de fonctions utilitaires dans des bibliothèques dédiées et utilisez GitLab Duo Chat pour sélectionner et générer les tests via la commande `/tests`. Pour l'exemple en Go, vous pouvez consulter les solutions potentielles disponibles dans le fichier `go/utility/array_test.go` du [projet Prompts de GitLab Duo](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts). Compilez et testez ensuite le code à l'aide de `go build && go test`.\n\n### Générer des expressions régulières sur mesure\n\nLes expressions régulières sont des lignes de code, souvent sur une seule ligne (ou « one liners » en anglais), que les développeurs aiment écrire à la va-vite, qui fonctionnent et donc, qu'ils ne mettent jamais à jour. Il est possible d'utiliser `git blame` pour savoir qui l'a écrite et quand, mais le contexte de ces lignes reste souvent obscur. GitLab Duo peut vous aider à les créer, les expliquer et les refactoriser, comme dans l'exemple suivant :\n\n*Défi : certaines expressions régulières pour analyser des adresses IPv6 et IPv4 ne fonctionnent pas. Quelle est la meilleure approche pour résoudre ce problème ?*\n\n*Solution : ajoutez les commentaires suggérés par les suggestions de code pour générer des exemples adaptés à ces types de regex. Utilisez également GitLab Duo Chat pour poser vos questions et demandez des variantes dans d'autres langages. Vous pouvez également sélectionner un extrait de code source et soumettre un prompt affiné avec `/refactor using regular expressions` via Chat.*\n\n**Exercice asynchrone** : choisissez votre langage préféré, créez une fonction factice (stub) qui vérifie que format des chaînes d'adresses IPv6 et IPv4 est valide. Laissez les suggestions de code générer le code d'expression régulière de vérification à votre place. Vous pouvez également utiliser Chat pour affiner ou refactoriser cette regex pour bénéficier de meilleures performances.\n\nExemple pour ce tutoriel : j'ai choisi TypeScript, un langage qui figure sur ma liste d'apprentissage personnelle pour 2024. Voici mon prompt : '// Generate a TypeScript function which parses IPv6 and IPv4 address formats. Use regular expressions`.\n\n![Suggestions de code - utilitaire TypeScript pour les regex de vérification d'adresses IP](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_typescript_utility_parse_ip_address_regex.png)\n\n![Suggestions de code TypeScript - tests de l'utilitaire pour les regex de vérification d'adresses IP](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_typescript_utility_parse_ip_address_regex_tests.png)\n\n## Maîtriser les suggestions de code\n\nVous pouvez activer les suggestions de code en appuyant sur la touche `Entrée` ou `Espace`, selon le contexte. Dans VS Code comme dans le Web IDE de GitLab, l'icône GitLab Duo s'affiche sur la même ligne que la suggestion, ainsi qu'en bas de la fenêtre.\n\nSi vous avez accepté une suggestion, mais que vous souhaitez en fait en essayer une autre, sélectionnez la ligne de code concernée, supprimez-la et reprenez à zéro.\n\n> **Astuce :** cette vidéo présente des combinaisons de touches et des stratégies complémentaires pour mieux utiliser les suggestions de code :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ORpRqp-A9hQ?si=CmA7PBJ9ckWsvjO3\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n### Utiliser les raccourcis clavier pour relancer les suggestions de code\n\nEn particulier dans la phase d'adoption initiale des suggestions de code, vous devrez vous entraîner pour obtenir des résultats optimaux à partir des commentaires, du style de code existant, etc., mis en contexte.\n\nVoici quelques combinaisons de touches couramment utilisées pour déclencher des suggestions :\n\n1. Appuyez sur `Entrée` et attendez que la suggestion s'affiche.\n1. Appuyez sur `Espace`, puis sur `Retour arrière` pour supprimer immédiatement l'espace.\n1. Appuyez sur `Entrée` à nouveau pour déclencher une nouvelle suggestion, puis sur `Retour arrière` pour effacer les nouvelles lignes vides restantes.\n\nLorsqu'une suggestion semble pertinente, ou que vous souhaitez tester jusqu'où elle peut vous mener : \n\n1. Continuez à appuyer sur la touche `Tab` pour l'accepter.\n1. Ajoutez un espace ou appuyez sur `Entrée` pour ouvrir une nouvelle portée afin de déclencher une nouvelle suggestion.\n1. Continuez à accepter les suggestions avec `Tab`. \n\nNotez que l'IA générative finit parfois par suggérer en boucle des chemins de code similaires, encore et encore. Vous pouvez déclencher ce comportement en insérant des données de test dans un tableau (par exemple, des chaînes et des nombres de manière ordonnée) ou en générant plusieurs points de terminaison d'API, car elle essaie alors d'anticiper les autres points de terminaison qui pourraient être utiles. Dans ce cas, interrompez le flux d'acceptation et continuez à écrire du code normalement.\n\n### Gérer les suggestions de code incomplètes\n\nParfois, les suggestions de code s'arrêtent au milieu d'une définition de variable, de fonction, ou d'une structure incomplète. Si vous avez un doute quant à la syntaxe ou souhaitez relancer les suggestions de code, voici quelques options possibles :\n\n1. Supprimez le ou les derniers caractères, voire la ligne dans son intégralité, avec la touche `Retour arrière`.\n1. Vous pouvez également utiliser `Maj curseur gauche` (sélectionner les caractères) `cmd Maj curseur gauche` (sélectionner la ligne entière), puis appuyer sur `Retour arrière`.\n1. Une autre option consiste à placer le curseur sur la ligne du dessus, puis appuyez sur `Entrée` pour forcer à nouveau le déclenchement des suggestions de code.\n\n### Gérer les suggestions de code qui s'interrompent\n\nSi les suggestions de code cessent de fonctionner, plusieurs raisons peuvent en être à l'origine :\n\n1. La portée du fichier actuel se termine, par exemple, une fonction `main()` a été entièrement générée et fermée.\n1. Il peut s'agit d'un problème de connexion à l'instance GitLab (édition Self-Managed) ou à GitLab.com (SaaS, [Dedicated](https://about.gitlab.com/fr-fr/dedicated/)). Dans ce cas, référez-vous à la [documentation de dépannage](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/troubleshooting.html).\n\n## Différencier suggestions et génération de code\n\nLes suggestions de code s'affichent à mesure que vous écrivez du code pour vous aider à compléter une ou plusieurs lignes. La génération de code, quant à elle, nécessite davantage de contexte pour créer des blocs entiers, comme des fonctions, des algorithmes, des classes, et bien plus encore. \n\nLes sections suivantes expliquent en détail les deux approches et comment commencer, avec un exemple pratique. \n\n### Intégrer les commentaires au flux de suggestions de code\n\nUtilisez votre flux de programmation naturel et insérez des commentaires de code lorsque cela fournit du contexte afin d'obtenir de meilleures suggestions. Pour accepter les suggestions de code, appuyez sur la touche `Tab`, ou acceptez-les mot par mot à l'aide du raccourci `cmd + flèche droite`.\n\nLe défi suivant consiste à implémenter un outil de statistiques Linux simple, en C, qui reproduit les fonctionnalités des commandes CLI `iostat`, `vmstat` et `du`. Parfois, ces indicateurs détaillés sont utiles pour présenter les statistiques de l'application, ou faciliter le débogage, notamment lors de la collecte de données d'assistance auprès des utilisateurs.\n\nCréez un répertoire d'application nommé `linux_stat` ainsi qu'un fichier `main.c`, puis laissez les suggestions de code compléter le reste à partir d'un simple bloc de commentaires initial :\n\n```c\n// Create a Linux statistic tool\n// Collect IO, performance, disk usage, TCP latency\n// Print summaries\n```\n\nAppuyez ensuite sur `Entrée` pour déclencher la création de la méthode `main()`. Si elle n'est pas créée automatiquement, ajoutez un nouveau commentaire explicite pour forcer sa création.\n\n```c\n// Create main function to collect data\n```\n\nLors de mes tentatives, l'IA générative n'a pas immédiatement implémenté toutes les fonctionnalités. Au lieu de cela, elle a ajouté un commentaire `TODO` dans le bloc de code suivant.\n\n```c\nint main() {\n    struct stat statbuf;\n\n    if (stat(\"/etc\", &statbuf) != 0) {\n        perror(\"stat\");\n        return 1;\n    }\n\n    printf(\"IO Block Size: %ld\n\", statbuf.st_blksize);\n\n    // TODO: add CPU usage, disk usage, network latency measurements\n\n    return 0;\n}\n```\n\nPlacez le curseur après le commentaire `TODO`, puis ajoutez un nouveau commentaire pour collecter les données sur l'utilisation du CPU :\n\n```c\n    // Collect CPU usage\n\n    // Example for AI-generated code below\n    double cpu_usage;\n\n    FILE* stat_file = fopen(\"/proc/stat\", \"r\");\n    if (stat_file == NULL) {\n        perror(\"fopen\");\n        return 1;\n    }\n\n    // Parse /proc/stat to get CPU usage\n    fscanf(stat_file, \"cpu %lf\", &cpu_usage);\n\n    printf(\"CPU Usage: %.2f%%\n\", cpu_usage * 100);\n\n    fclose(stat_file);\n```\n\nLe code généré peut ne pas être précis à 100 %, car la mesure de l'utilisation du CPU sur Linux nécessite de prendre des échantillons sur une plage de temps définie. Il faudra donc calculer l'utilisation réelle du processeur à partir de toutes les valeurs dans `/proc/stat`, y compris [`system, nice, user, idle, iowait`, etc.](https://www.kernel.org/doc/Documentation/filesystems/proc.txt).\n\n**Exercice asynchrone :** optimisez le processus de collecte en ajoutant un calcul de moyenne.\n\nRépétez les étapes pour mesurer l'utilisation du disque et la latence du réseau. Vous rédigez le commentaire, et GitLab Duo génère le code C.\n\n```c\n    // Collect disk usage\n\n    // Collect network latency\n\n    // Example for AI-generated code below\n    int sockfd = socket(AF_INET, SOCK_STREAM, 0);\n\n    struct sockaddr_in servaddr;\n    servaddr.sin_family = AF_INET;\n    servaddr.sin_port = htons(80);\n    inet_pton(AF_INET, \"8.8.8.8\", &servaddr.sin_addr);\n```\n\nLe code généré peut utiliser une adresse IP publique pour tester la latence du réseau. Remplacez-la par l'adresse actuelle de GitLab.com. \n\n```c\n    inet_pton(AF_INET, \"172.65.251.78\", &servaddr.sin_addr);\n```\n\nLe code source généré a ajouté plus de dépendances d'en-tête. Accédez à la section supérieure du fichier et ajoutez un commentaire pour inclure tous les en-têtes nécessaires :\n\n```c\n// Import required headers\n```\n\nCompilez et exécutez l'application sur Linux, par exemple sur Ubuntu 22 LTS :\n\n```shell\n# Install compiler\napt install gcc\n\n# Build\ngcc main.c -o linux_stat\n\n# Build: If the math.h header is included, linking against the library is needed, too\ngcc linux_stat.c -o linux_stat -lm\n\n# Run the tool\n./linux_stat\n```\n\n**Bonus :** modifiez le code pour utiliser IPv6 et récupérez l'adresse IPv6 de GitLab.com (`dig gitlab.com AAAA +short`).\n\n```c\n    // Collect network latency\n\n    // Use IPv6 \n\n    // Example for AI-generated code below\n    struct sockaddr_in6 servaddr;\n    servaddr.sin6_family = AF_INET6;\n    servaddr.sin6_port = htons(80);\n    //inet_pton(AF_INET6, \"2001:db8::1\", &servaddr.sin6_addr);\n    inet_pton(AF_INET6, \"2606:4700:90:0:f22e:fbec:5bed:a9b9\", &servaddr.sin6_addr);\n\n    int sockfd = socket(AF_INET6, SOCK_STREAM, 0);\n```\n\n![Tests Linux stat en C](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_c_linux_stat_tests.png)\n\nLe code source complet et fonctionnel est disponible dans le [projet GitLab Duo Prompts](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts), dans le répertoire dédié au code C.\n\n**Exercice asynchrone :** refactorisez le code C en code Rust, en utilisant uniquement GitLab Duo. Commencez par sélectionner le code source, puis saisissez le prompt `/refactor into Rust` dans GitLab Duo Chat. \n\n> **Astuce :** des commentaires de code bien rédigés améliorent la lisibilité du code source. Ils facilitent l'intégration de nouveaux membres dans l'équipe, aident les ingénieurs de la fiabilité des sites à déboguer les incidents en production et guident les contributeurs open source dans leurs [premières merge requests](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#first-time-contributors).\n\n### Orienter la génération de code avec des commentaires explicites\n\nLe code source peut être structuré en plusieurs fichiers. Que vous conceviez une nouvelle architecture applicative ou refactorisiez un code existant, GitLab Duo vous aide à générer du code automatiquement.\n\nCommencez par ajouter une section de commentaires en haut du fichier détaillant chaque étape. N'hésitez pas à diviser les commentaires les plus longs en plusieurs lignes, en reprenant les exemples de cet article. Ce modèle vous aide à réfléchir aux exigences du projet et à affiner vos prompts. \n\n```diff\n# Generate a webserver, using the Flask framework. \n# Implement the / URL endpoint with example output.\n+# Add an endpoint for Promtheus metrics\n\n// Create a database backend. \n// Abstract data handlers and SQL queries into function calls.\n+// Use PostgreSQL as default backend, and SQLite for developers as fallback.\n\n/* \nUse multi-threaded data access here.\nCreate a shared locked resource, and focus on supporting Linux pthreads. \n+Abstract the thread creation/wait procedures into object-oriented classes and methods.\n*/\n```\n\nDécouvrez d'autres prompts de génération de code pour les [langages de programmation pris en charge](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html) dans la [documentation présentant les cas d'utilisation de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#code-generation-prompts).\n\n### Définir l'intention de la requête\n\nEn fonction du Language Server de GitLab que vous utilisez dans votre IDE, les suggestions de code analysent l'intention de votre saisie et proposent des suggestions de complétion de code en ligne ou des blocs de code.\n\nLa technologie en arrière-plan s'appuie sur TreeSitter pour analyser le code dans un [arbre de syntaxe abstraite (AST)](https://fr.wikipedia.org/wiki/Arbre_de_la_syntaxe_abstraite) et déterminer si la portée se trouve dans une section de commentaires de code (génération) ou dans du code source (complétion). Cette détection doit être exécutée rapidement sur l'IDE client et s'avère être un excellent cas d'utilisation pour [WebAssembly](https://webassembly.org/). Pour en savoir plus, consultez [cet epic](https://gitlab.com/groups/gitlab-org/-/epics/11568) et la vidéo suivante, qui présente le Language Server de GitLab qui alimente les suggestions de code :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VQlWz6GZhrs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Structurer la requête comme une histoire\n\nLa génération de code est un art. Formulez votre demande sous forme d'une histoire et GitLab Duo, alimenté par l'IA, pourra vous aider. \n\nL'exemple suivant vise à implémenter un magasin clé-valeur en mémoire en Go, à la manière de Redis. Commencez par rédiger un commentaire descriptif, puis passez à la ligne suivante et appuyez sur `Entrée` pour déclencher les suggestions de code.\n\n```golang\n// Create an in-memory key value store, similar to Redis \n// Provide methods to\n// set/unset keys\n// update values\n// list/print with filters\n```\n\nSoyez explicite et précisez : quelles sont les méthodes nécessaires pour manipuler les données ? Demandez aux suggestions de code de générer des méthodes pour définir des clés, mettre à jour des valeurs et répertorier toutes les données stockées.\n\n```golang\n// Create an in-memory key value store, similar to Redis \n// Provide methods to\n// set/unset keys\n// update values\n// list/print with filters\n```\n\nAcceptez les suggestions à l'aide de la touche `Tab`. Ensuite, demandez aux suggestions de code de créer une fonction `main` accompagnée de code de test.\n\n```golang\n// Create a main function and show how the code works\n```\n\nSi les données de test ne suffisent pas, affinez le code généré en vous concentrant sur les scénarios de test extrêmes.\n\n> **Astuce :** vous pouvez utiliser la même méthode pour affiner les [prompts et générer des tests avec GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide) via `/tests focus on extreme test cases`.\n\n```golang\n// Add more random test data, focus on extreme test cases\n```\n\n![Suggestions de code - plus de données de test clé-valeur Go](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_kv_more_test_data.png)\n\nL'exemple complet, y compris les dépendances corrigées, se trouve dans le [projet gitlab-duo-prompts](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts) dans le répertoire `code-suggestions/go/key-value-store`. Mettez à jour le fichier `main.go`, puis compilez et exécutez le code à l'aide de la commande suivante : \n\n```shell\ngo build\n./key-value-store\n```\n\nCette première itération consiste à créer un binaire autonome et à tester différentes stratégies de mise en œuvre pour les magasins clé-valeur. Validez le code fonctionnel et passez à l'étape suivante de votre parcours d'adoption de GitLab Duo.\n\n> **Astuce :** les nouveaux projets tirent parti de la génération de code, mais requièrent de la pratique et des techniques avancées pour exploiter efficacement les commentaires de code en tant que prompts. Cette approche peut aussi optimiser les workflows des développeurs expérimentés. Les études de faisabilité, l'intégration de nouvelles bibliothèques ou les itérations ne sont pas toujours compatibles avec le framework ou le projet existant. Les développeurs expérimentés optent alors pour créer des projets temporaires en isolant ou simplifiant la portée de certaines fonctionnalités, par exemple, pour tester une nouvelle couche backend de base de données en comparant ses performances à celles de l'environnement de production. Ou pour remplacer une bibliothèque présentant des failles de sécurité ou des problèmes de licence par une alternative plus sûre ou une fonctionnalité intégrée au code.\n\n### Accélérer les itérations avec la génération de code\n\nComme le dirait un développeur expérimenté : « Il existe forcément déjà une bibliothèque clé-valeur en Go, alors inutile de réinventer la roue. » Heureusement, Go est un langage de programmation mature doté d'un écosystème riche. Des projets comme la collection awesome-go — par exemple [avelino/awesome-go](https://github.com/avelino/awesome-go) — recensent de nombreuses bibliothèques d'exemples, ce qui facilite grandement la recherche de solutions existantes. Remarque : cette option n'est pas forcément applicable à tous les langages de programmation et doit être évaluée au cas par cas.\n\nVous pouvez également poser la question à GitLab Duo Chat : `Quelles bibliothèques Go utiliser pour un stockage clé-valeur ?`:\n\n![GitLab Duo Chat - demande bibliothèques clé-valeur Golang](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_chat_ask_golang_libs_kv.png)\n\nEnsuite, affinez le prompt des suggestions de code pour utiliser spécifiquement les bibliothèques suggérées, par exemple BoltDB.\n\n```diff\n// Create an in-memory key value store, similar to Redis \n// Provide methods to\n// set/unset keys\n// update values\n// list/print with filters\n+// Use BoltDB as external library\n```\n\nRépétez le schéma ci-dessus : générez les fonctions du code, demandez à GitLab Duo de créer une fonction « main » avec des données de test, puis compilez le code. La principale différence réside dans les bibliothèques externes, qui doivent d'abord faire l'objet d'un pull à l'aide de la commande `go get`. \n\n```shell\ngo get\ngo build\n```\n\nEn cas d'échec de la compilation due à des dépendances manquantes, comme `fmt`, profitez-en pour vous entraîner à nouveau avec GitLab Duo : placez le curseur sur l'instruction `import` et attendez la suggestion ajoute les dépendances nécessaires. Vous pouvez ajouter un commentaire tel que `Import all libraries`.\n\n![Suggestions de code - correction dépendances bibliothèque externe BoltDB clé-valeur Go](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_kv_external_lib_boltdb_fix_deps.png)\n\nVous pouvez également enrichir les tests avec de nouvelles données afin de vérifier le comportement des fonctions : `// Add more random test data, focus on extreme test cases`. Dans l'exemple suivant, une clé vide provoque un arrêt brutal du programme.\n\n![Suggestions de code - scénario de test d'arrêt brutal du programme bibliothèque externe BoltDB clé-valeur Golang](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_kv_external_lib_boltdb_test_extreme_cases_panic.png)\n\nCet exemple est une excellente préparation pour les scénarios de test ultérieurs.\n\n### Appliquer la génération de code à des cas concrets : observabilité cloud-native\n\nImaginez une application cliente en Go, chargée de répertorier l'état des conteneurs, pods et services dans un cluster Kubernetes, comme la ligne de commande `kubectl get pods`. Le projet Kubernetes fournit des [bibliothèques Go](https://pkg.go.dev/k8s.io/client-go/kubernetes) permettant d'interagir par programmation avec les API, les interfaces et les structures d'objets Kubernetes.\n\nOuvrez votre IDE et créez un nouveau projet Go.\n\n> **Astuce :** vous pouvez demander à GitLab Duo Chat de vous expliquer la procédure à suivre avec ce prompt : `How to start a Go project? Please show CLI command examples`. \n\nCommencez par rédiger un commentaire simple en haut du fichier `main.go` qui décrit l'objectif de l'application : observabilité dans Kubernetes.\n\n```golang\n// Create a client for Kubernetes observability\n```\n\nRéfléchissez aux principales exigences : accéder à Kubernetes, définir un contexte et un espace de nommage, et inspecter l'état des ressources. En outre, demandez aux suggestions de code d'importer les paquets nécessaires et de créer un paquet « main » dans le fichier `main.go`.\n\nPremière itération :\n\n```golang\n// Create a client for Kubernetes observability\n// Inspect container, pod, service status and print an overview\n```\n\nVous pourriez obtenir des résultats inattendus, comme le codage en dur des identifiants d'accès, des contextes manquants ou l'échec de la compilation.\n\nDeuxième itération :\n\n```golang\n// Create a client for Kubernetes observability\n// Create a function that\n// Read the kubernetes configuration file from the KUBECONFIG env var\n// Inspect container, pod, service status and print an overview\n```\n\nL'absence de contextes ou d'espaces de nommage Kubernetes connus peut entraîner l'échec de la compilation ou des comportements inattendus.\n\nTroisième itération :\n\n```golang\n// Create a client for Kubernetes observability\n// Create a function that\n// Read the kubernetes configuration file from the KUBECONFIG env var\n// Create kubernetes context, namespace default\n// Inspect container, pod, service status and print an overview\n```\n\nCet exemple code en dur le contexte Kubernetes et l'espace de nommage par défaut pour générer une base initiale. Les itérations ultérieures peuvent lire la valeur de l'espace de nommage à partir d'un paramètre de ligne de commande ou d'un fichier de configuration.\n\nLe dernier exemple peut ressembler à ce qui suit. En plus de la fonctionnalité de l'application, il demande également aux suggestions de code d'importer toutes les dépendances et de générer le paquet `main` dans `main.go`.\n\n```golang\n// Create a client for Kubernetes observability\n// Create a function that\n// Read the kubernetes configuration file from the KUBECONFIG env var\n// Create kubernetes context, namespace default\n// Inspect container, pod, service status and print an overview\n// Import necessary packages\n// Create main package\n```\n\n\u003Cdetails> Solution \n\u003Csummary>\n\n```golang\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"os\"\n\n\t\"k8s.io/client-go/kubernetes\"\n\t\"k8s.io/client-go/tools/clientcmd\"\n\tmetav1 \"k8s.io/apimachinery/pkg/apis/meta/v1\"\n)\n\nfunc main() {\n\tkubeconfig := os.Getenv(\"KUBECONFIG\")\n\tconfig, err := clientcmd.BuildConfigFromFlags(\"\", kubeconfig)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tclientset, err := kubernetes.NewForConfig(config)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tpods, err := clientset.CoreV1().Pods(\"\").List(context.TODO(), metav1.ListOptions{})\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tfmt.Printf(\"There are %d pods in the cluster\n\", len(pods.Items))\n\n\t// Additional code to inspect services, containers, etc\n}\n```\n\n\u003C/summary>\n\u003C/details>\n\nExemple de données de sortie :\n\n![Suggestions de code GitLab Duo - données de sortie observabilité scénario k8s Go](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_k8s_o11y_output.png)\n\n**Exercice asynchrone :** complétez le projet avec du code pour vérifier les services, les conteneurs, etc., puis exportez les résultats vers [OpenTelemetry](https://opentelemetry.io/).\n\n> **Astuce :** entraînez-vous avec les [cas d'utilisation de GitLab Duo : utilisez les prompts de génération de code](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#code-generation-prompts) dans la documentation ou envoyez des merge requests contenant vos propres prompts fonctionnels.\n\nAlors que nous enregistrions une courte démonstration vidéo illustrant la génération de code, une variante plus aboutie du code a été générée. N'hésitez pas à comparer les différences dans [cette validation](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/commit/a1a46de9789d4791f04b4df9f1a35d05b8e67568) et tirer parti des deux versions.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ORpRqp-A9hQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Tirer parti de toutes les fonctionnalités de GitLab Duo \n\n### Combiner GitLab Duo Chat avec les suggestions de code\n\nUtilisées avec [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html), les suggestions de code deviennent encore plus efficaces. Le workflow suivant illustre l'efficacité de cette synergie entre IA et développement logiciel :\n\nÉcrivez et générez du code à l'aide des suggestions de code. Le code source sera ensuite vérifié par le biais de l'automatisation CI/CD, de tests de qualité du code et d'un scanning de sécurité. Mais qu'en est-il des connaissances du développeur ?\n\n1. Dans votre IDE, sélectionnez les portions de code générées et utilisez la [commande slash `/explain`](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide) dans le prompt de GitLab Duo Chat. Vous pouvez même affiner le prompt en ajoutant `/explain with focus on algorithms` ou d'autres domaines utiles pour une explication centrée spécifiquement sur les problèmes de sécurité potentiels ou de performance, etc.\n\n    - Continuez à écrire et à maintenir votre code, mais gardez à l'esprit qu'à un certain stade, la qualité peut se dégrader et rendre la refactorisation plus complexe. Demandez de l'aide à GitLab Duo Chat.\n\n2. Dans votre IDE, sélectionnez le code source concerné et utilisez la [commande slash `/refactor`](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide) dans le prompt de GitLab Duo Chat. Là encore, vous pouvez affiner le prompt pour cibler des design patterns spécifiques (fonctions, classes orientées objet, etc.), comme `/refactor into testable functions`._\n\n    - Après avoir rendu le code plus lisible, vous devez rédiger des tests. Quels sont les scénarios extrêmes ou les exemples de données aléatoires à utiliser pour les tests unitaires ? Ce type de recherche et la mise en œuvre dans différents frameworks peuvent prendre du temps.\n\n3. Dans votre IDE, sélectionnez le code source et utilisez la [commande slash `/tests`](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide) dans le prompt de GitLab Duo Chat. Vous pouvez affiner le prompt pour vous concentrer sur des frameworks de test, des scénarios, des méthodes fondées sur les données d'entrée spécifiques, etc. \n\n    - Une fois la qualité du code et la couverture des tests assurées, vous pouvez à nouveau vous concentrer sur l'optimisation de vos workflows DevSecOps avec les suggestions de code.\n\nDécouvrez d'autres scénarios dans la [documentation présentant les cas d'utilisation de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html).\n\n### Générer des configurations de compilation avec GitLab Duo Chat\n\nLes recherches nécessaires au démarrage d'un nouveau projet sont souvent fastidieuses. Entre les multiples approches possibles et les frameworks alternatifs, il est facile de se retrouver avec une charge de travail bien plus importante que prévue. Certains langages modernes comme Rust imposent une approche unifiée avec un seul outil (Cargo), tandis que d'autres comme Java ou C++ proposent plusieurs méthodes avec des langages de configuration supplémentaires comme Kotlin DSL ou CMake DSL, etc.\n\nAvec GitLab Duo, demandez comment démarrer un projet, générez des configurations adaptées à vos outils de compilation (p. ex. `Please show a gradle.build example for Spring Boot`), et accélérez les premières étapes de développement, de compilation et de test du code source. Voici quelques exemples de prompts utiles :\n\n1. Java, Gradle, Spring Boot : `Please show a gradle.build example for Spring Boot`\n1. C++, CMake, clang : `Please show a basic CMake configuration file for C++17, using clang as compiler.`\n1. Python : `Please show how to initialize and configure a Python project on the CLI`\n1. Rust : `Please show how to initialize and configure a Rust project.`, suivi d'une question pour affiner le prompt telle que : `Explain the structure of Cargo.toml`.\n1. Golang : `Please show how to initialize and configure a Go project`. \n\n### Demander des explications sur les vulnérabilités à GitLab Duo Chat\n\nSupposons qu'un code PHP a été généré pour créer un formulaire web. Il peut présenter des failles de sécurité potentielles.\n\n```php\n\u003C?php \n// Create a feedback form for user name, email, and comments\n// Render a HTML form\n\n$name = $_POST['name'];\n$email = $_POST['email'];\n$comments = $_POST['comments'];\n\necho '\u003Cform method=\"post\">';\necho '\u003Clabel for=\"name\">Name:\u003C/label>';\necho '\u003Cinput type=\"text\" id=\"name\" name=\"name\">';\n\necho '\u003Clabel for=\"email\">Email:\u003C/label>';\necho '\u003Cinput type=\"email\" id=\"email\" name=\"email\">';\n\necho '\u003Clabel for=\"comments\">Comments:\u003C/label>';\necho '\u003Ctextarea id=\"comments\" name=\"comments\">\u003C/textarea>';\n\necho '\u003Cinput type=\"submit\" value=\"Submit\">'; \necho '\u003C/form>';\n\n?>\n```\n\nSélectionnez-le dans votre IDE, puis [demandez à GitLab Duo Chat d'expliquer le problème](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide), en utilisant un prompt affiné tel que `/explain why this code is vulnerable to bad security actors`\n\n![Suggestions de code : GitLab Duo Chat explique la vulnérabilité potentielle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_chat_explain_potential_vulnerability.png)\n\n> **Astuce** : les vérifications et l'apprentissage s'effectuent dans l'environnement de développement local, ce qui permet d'identifier et de corriger les vulnérabilités en amont, avant même que le code ne fasse l'objet d'un push et qu'une merge request ne déclenche un scanning de sécurité capable d'identifier et de tracer les failles. Mieux comprendre les failles de sécurité contribue à améliorer l'expérience développeur.\n\n### Combiner la résolution des vulnérabilités avec les suggestions de code\n\nPrenons un nouvel exemple avec une [vulnérabilité simulée](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/vulnerability-resolution/challenge-resolve-vulnerabilities), et voyons si les suggestions de code peuvent nous aider à la corriger efficacement. Le projet associé a été préconfiguré avec un test statique de sécurité des applications (SAST). Vous pouvez suivre ces étapes pour configurer le SAST GitLab à l'aide du [composant SAST CI/CD](https://gitlab.com/explore/catalog/components/sast) du fichier de configuration CI/CD `.gitlab-ci.yml`.\n\n```yaml\ninclude:\n  # Security: SAST (for vulnerability resolution)\n  - component: gitlab.com/components/sast/sast@1.1.0\n```\n\nAprès avoir examiné le tableau de bord et les détails de la vulnérabilité, vous pouvez utiliser la fonctionnalité d'[explication des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) pour mieux comprendre le contexte et les risques potentiels. La fonctionnalité de [résolution des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#vulnerability-resolution), quant à elle, génère une merge request contenant une proposition de correction du code source pour la faille de sécurité détectée. \n\nParfois, il peut être nécessaire d'affiner le code suggéré. Accédez alors à la [MR générée](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/vulnerability-resolution/challenge-resolve-vulnerabilities/-/merge_requests/1), puis copiez le chemin d'accès de la branche Git pour exécuter la commande git fetch en local, ou ouvrez directement le Web IDE à partir du bouton `Edit` pour continuer dans le navigateur. Accédez aux sections du code source contenant les correctifs et modifiez-les si besoin en ajoutant un commentaire :\n\n```\n// refactor using safe buffers, null byte termination\n```\n\n![Suggestions de code de GitLab Duo - avec proposition de résolution des vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_with_vulnerability_resolution_proposal.png)\n\nVous pouvez également ouvrir GitLab Duo Chat, sélectionner le code source et utiliser la commande slash `/refactor`.\n\n![Suggestions de code de GitLab Duo - avec résolution des vulnérabilités en ajoutant la commande refactor de GitLab Chat Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_with_vulnerability_resolution_add_duo_chat_refactor.png)\n\nDécouvrez un exemple complet dans la [documentation présentant les cas d'utilisation de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#explain-and-resolve-vulnerabilities). \n\nVoici un enregistrement de cet exemple :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Ypwx4lFnHP0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Conseils supplémentaires \n\n### Vérifier la qualité et la sécurité du code\n\nLa génération accrue de code implique davantage d'efforts en matière de qualité, de tests et de sécurité. Profitez de toutes les fonctionnalités qu'offre une plateforme DevSecOps complète :\n\n1. [Composants CI/CD](https://docs.gitlab.com/ee/ci/components/) et [efficacité des pipelines](https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html)\n1. [Qualité du code](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n1. [Couverture des tests](https://docs.gitlab.com/ee/ci/testing/code_coverage.html)\n1. [Sécurité applicative](https://docs.gitlab.com/ee/user/application_security/)\n1. [Observabilité](https://docs.gitlab.com/ee/operations/tracing.html)\n\n### Apprendre en équipe et comprendre l'impact de l'IA\n\nOrganisez des sessions collaboratives ciblées pour tester et itérer et enregistrez-les afin que d'autres équipes puissent s'en inspirer par la suite. Vous pouvez également suivre la [playlist GitLab Duo Coffee Chat sur YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp5uj_JgQiSvHw1jQu0mSVZ).\n\nDécouvrez les indicateurs d'impact de l'IA dans nos articles, notamment celui intitulé [Utiliser l'IA générative dans votre environnement DevSecOps](https://about.gitlab.com/the-source/ai/how-to-put-generative-ai-to-work-in-your-devsecops-environment/) et [GitLab Duo : mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/). Consultez notre page dédiée au [Centre pour la transparence de l'IA](https://about.gitlab.com/fr-fr/ai-transparency-center/) pour en savoir plus sur l'utilisation des données, la transparence et l'éthique de l'IA chez GitLab.\n\n### Adopter une vision à long terme du développement\n\nLes suggestions de code peuvent parfois prendre plus de temps à charger que les fonctionnalités d'auto-complétion locales. Mettez à profit ce temps pour réfléchir à l'algorithme ou au problème que vous essayez de résoudre. Prendre un moment de recul permet de faire émerger des idées plus claires. Ou bien profitez-en pour savourer une gorgée de votre boisson préférée, puis reprenez le travail avec un regard neuf.\n\nCertains algorithmes sont particulièrement complexes ou nécessitent des dépendances de code qui ne peuvent pas être résolues par auto-complétion. Le code propriétaire ou confidentiel offre souvent moins de contexte exploitable aux grands modèles de langage. Il peut donc être utile d'enrichir les commentaires pour améliorer la qualité des suggestions de code. Avancez à votre propre rythme et selon votre propre stratégie, et utilisez les suggestions de code là où elles apportent le plus de valeur, notamment pour générer des modèles standards ou des fonctions d'assistance.\n\n> **Astuce :** découvrez [Repository X-Ray](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/repository_xray.html) pour obtenir davantage de contexte sur les suggestions de code et tester des fonctionnalités expérimentales, par exemple, [la prise en charge élargie à d'autres langages dans VS Code](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#add-support-for-more-languages-for-code-suggestions-in-vs-code). Vous trouverez plus d'informations dans l'epic pour dédiée à l'[amélioration du taux d'acceptation des suggestions de code](https://gitlab.com/groups/gitlab-org/-/epics/13085).\n\n### Comment contribuer à GitLab Duo\n\nUtilisez GitLab Duo pour contribuer à des projets open source en tirant parti des suggestions de code, de la refactorisation du code, de la génération de tests et de la documentation automatisée avec des explications claires sur le fonctionnement du code.\n\nLes clients de GitLab peuvent également [co-créer la plateforme GitLab à l'aide de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#use-gitlab-duo-to-contribute-to-gitlab). Suivez les directives récentes concernant les [contributions générées par l'IA](https://about.gitlab.com/community/contribute/dco-cla/#ai-generated-contributions) et regardez cet exemple issu des sessions GitLab Duo Coffee Chat : Contribuer à GitLab à l'aide des suggestions de code et de GitLab Duo Chat :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/TauP7soXj-E\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Comment partager vos retours\n\nGitLab Duo optimise les workflows de développement grâce à ses suggestions de code, mais une adoption efficace passe par des exercices concrets : tutoriels, ateliers en équipe et sessions de formation guidée. L'automatisation des workflows, l'amélioration de la qualité du code, l'ajout de scanning de sécurité et la mesure de l'observabilité permettent de relever les défis posés par l'introduction fréquente de nouveau code. Tirer pleinement parti de toutes les fonctionnalités de GitLab Duo, y compris GitLab Duo Chat, renforce considérablement l'expérience développeur sur la plateforme DevSecOps la plus complète alimentée par l'IA.\n\nPour bien commencer, suivez les bonnes pratiques de ce tutoriel, consultez la [documentation de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/index.html) et [sollicitez nos équipes pour organiser des ateliers GitLab Duo dédiés à l'IA](https://about.gitlab.com/fr-fr/solutions/gitlab-duo-pro/sales/) (j'ai déjà assisté à des ateliers clients, et je vous les recommande vivement !). N'hésitez pas à partager vos retours sur les suggestions de code dans [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/435783), en incluant des captures d'écran et des vidéos (si possible).\n\n> [Inscrivez-vous à un essai gratuit de GitLab Duo dès aujourd'hui !](https://about.gitlab.com/fr-fr/gitlab-duo/)",[682,1181,1182],"fonctionnalités","tutoriel",{"slug":1184,"featured":91,"template":805},"top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo",[1186,1191,1196],{"content":1187,"config":1190},{"heroImage":1136,"date":1137,"title":1138,"description":1139,"authors":1188,"body":1142,"category":781,"tags":1189},[1141],[781,818,803,234,769,817],{"featured":6,"template":805,"slug":1145},{"content":1192,"config":1195},{"heroImage":1100,"date":1101,"title":1102,"description":1103,"authors":1193,"body":1105,"category":769,"tags":1194},[1026],[769,746,932],{"featured":6,"template":805,"slug":1108},{"content":1197,"config":1200},{"title":1148,"description":1149,"authors":1198,"date":1151,"body":1152,"category":781,"tags":1199,"heroImage":1154},[942],[803,781],{"featured":6,"template":805,"slug":1156},[1202,1207,1212],{"content":1203,"config":1206},{"heroImage":838,"date":839,"title":840,"description":841,"authors":1204,"body":844,"category":686,"tags":1205},[843],[846,817,769,803],{"featured":6,"template":805,"slug":848},{"content":1208,"config":1211},{"heroImage":1023,"date":1024,"authors":1209,"body":1027,"category":746,"tags":1210,"title":1029,"description":1030},[1026],[769,746,718],{"featured":6,"template":805,"slug":1032},{"content":1213,"config":1216},{"date":856,"authors":1214,"heroImage":1037,"title":1038,"description":1039,"tags":1215,"category":746,"body":1041},[1036,942],[746,769,718],{"featured":6,"template":805,"slug":1043},1759347861786]