[{"data":1,"prerenderedAt":1205},["ShallowReactive",2],{"/fr-fr/blog":3,"navigation-fr-fr":20,"banner-fr-fr":426,"footer-fr-fr":436,"blogCategories-fr-fr":646,"relatedBlogPosts-fr-fr":777,"mainFeaturedPost-fr-fr":1168,"recentFeaturedPosts-fr-fr":1173,"recentPosts-fr-fr":1189},{"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":416},{"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/compare/gitlab-vs-github/","get started",{"freeTrial":407,"mobileIcon":412,"desktopIcon":414},{"text":408,"config":409},"En savoir plus sur GitLab Duo",{"href":410,"dataGaName":411,"dataGaLocation":392},"/fr-fr/gitlab-duo/","gitlab duo",{"altText":394,"config":413},{"src":396,"dataGaName":397,"dataGaLocation":392},{"altText":394,"config":415},{"src":400,"dataGaName":397,"dataGaLocation":392},{"freeTrial":417,"mobileIcon":422,"desktopIcon":424},{"text":418,"config":419},"Retour aux tarifs",{"href":170,"dataGaName":420,"dataGaLocation":392,"icon":421},"back to pricing","GoBack",{"altText":394,"config":423},{"src":396,"dataGaName":397,"dataGaLocation":392},{"altText":394,"config":425},{"src":400,"dataGaName":397,"dataGaLocation":392},{"title":427,"button":428,"config":433},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":429,"config":430},"Regarder GitLab Transcend maintenant",{"href":431,"dataGaName":432,"dataGaLocation":26},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":434,"icon":435},"release","AiStar",{"data":437},{"text":438,"source":439,"edit":445,"contribute":450,"config":455,"items":460,"minimal":637},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":440,"config":441},"Afficher le code source de la page",{"href":442,"dataGaName":443,"dataGaLocation":444},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":446,"config":447},"Modifier cette page",{"href":448,"dataGaName":449,"dataGaLocation":444},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":451,"config":452},"Veuillez contribuer",{"href":453,"dataGaName":454,"dataGaLocation":444},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":456,"facebook":457,"youtube":458,"linkedin":459},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[461,484,538,570,605],{"title":44,"links":462,"subMenu":467},[463],{"text":464,"config":465},"Plateforme DevSecOps",{"href":53,"dataGaName":466,"dataGaLocation":444},"devsecops platform",[468],{"title":168,"links":469},[470,474,479],{"text":471,"config":472},"Voir les forfaits",{"href":170,"dataGaName":473,"dataGaLocation":444},"view plans",{"text":475,"config":476},"Pourquoi choisir GitLab Premium ?",{"href":477,"dataGaName":478,"dataGaLocation":444},"/fr-fr/pricing/premium/","why premium",{"text":480,"config":481},"Pourquoi choisir GitLab Ultimate ?",{"href":482,"dataGaName":483,"dataGaLocation":444},"/fr-fr/pricing/ultimate/","why ultimate",{"title":485,"links":486},"Solutions",[487,492,495,497,502,507,511,514,517,522,524,526,528,533],{"text":488,"config":489},"Transformation digitale",{"href":490,"dataGaName":491,"dataGaLocation":444},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":493,"config":494},"Sécurité et conformité",{"href":109,"dataGaName":116,"dataGaLocation":444},{"text":101,"config":496},{"href":85,"dataGaName":86,"dataGaLocation":444},{"text":498,"config":499},"Développement agile",{"href":500,"dataGaName":501,"dataGaLocation":444},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":503,"config":504},"Transformation cloud",{"href":505,"dataGaName":506,"dataGaLocation":444},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":508,"config":509},"SCM",{"href":98,"dataGaName":510,"dataGaLocation":444},"source code management",{"text":89,"config":512},{"href":91,"dataGaName":513,"dataGaLocation":444},"continuous integration & delivery",{"text":140,"config":515},{"href":142,"dataGaName":516,"dataGaLocation":444},"value stream management",{"text":518,"config":519},"GitOps",{"href":520,"dataGaName":521,"dataGaLocation":444},"/fr-fr/solutions/gitops/","gitops",{"text":153,"config":523},{"href":155,"dataGaName":156,"dataGaLocation":444},{"text":158,"config":525},{"href":160,"dataGaName":161,"dataGaLocation":444},{"text":163,"config":527},{"href":165,"dataGaName":166,"dataGaLocation":444},{"text":529,"config":530},"Formation",{"href":531,"dataGaName":532,"dataGaLocation":444},"/fr-fr/solutions/education/","education",{"text":534,"config":535},"Services financiers",{"href":536,"dataGaName":537,"dataGaLocation":444},"/fr-fr/solutions/finance/","financial services",{"title":173,"links":539},[540,542,545,547,550,552,555,558,560,562,564,566,568],{"text":185,"config":541},{"href":187,"dataGaName":188,"dataGaLocation":444},{"text":543,"config":544},"Guides de démarrage rapide",{"href":192,"dataGaName":193,"dataGaLocation":444},{"text":195,"config":546},{"href":197,"dataGaName":198,"dataGaLocation":444},{"text":200,"config":548},{"href":202,"dataGaName":549,"dataGaLocation":444},"docs",{"text":223,"config":551},{"href":225,"dataGaName":226},{"text":553,"config":554},"Histoires de réussite client",{"href":220,"dataGaLocation":444},{"text":556,"config":557},"Histoires de succès client",{"href":220,"dataGaName":221,"dataGaLocation":444},{"text":228,"config":559},{"href":230,"dataGaName":231,"dataGaLocation":444},{"text":236,"config":561},{"href":238,"dataGaName":239,"dataGaLocation":444},{"text":241,"config":563},{"href":243,"dataGaName":244,"dataGaLocation":444},{"text":246,"config":565},{"href":248,"dataGaName":249,"dataGaLocation":444},{"text":251,"config":567},{"href":253,"dataGaName":254,"dataGaLocation":444},{"text":256,"config":569},{"href":258,"dataGaName":259,"dataGaLocation":444},{"title":274,"links":571},[572,574,577,579,581,583,585,589,594,596,598,600],{"text":281,"config":573},{"href":283,"dataGaName":276,"dataGaLocation":444},{"text":575,"config":576},"Emplois",{"href":288,"dataGaName":289,"dataGaLocation":444},{"text":294,"config":578},{"href":296,"dataGaName":297,"dataGaLocation":444},{"text":299,"config":580},{"href":301,"dataGaName":302,"dataGaLocation":444},{"text":304,"config":582},{"href":306,"dataGaName":307,"dataGaLocation":444},{"text":309,"config":584},{"href":311,"dataGaName":312,"dataGaLocation":444},{"text":586,"config":587},"Sustainability",{"href":588,"dataGaName":586,"dataGaLocation":444},"/sustainability/",{"text":590,"config":591},"Diversité, inclusion et appartenance (DIB)",{"href":592,"dataGaName":593,"dataGaLocation":444},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":314,"config":595},{"href":316,"dataGaName":317,"dataGaLocation":444},{"text":324,"config":597},{"href":326,"dataGaName":327,"dataGaLocation":444},{"text":329,"config":599},{"href":331,"dataGaName":332,"dataGaLocation":444},{"text":601,"config":602},"Déclaration de transparence sur l'esclavage moderne",{"href":603,"dataGaName":604,"dataGaLocation":444},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":334,"links":606},[607,610,615,617,622,627,632],{"text":608,"config":609},"Échanger avec un expert",{"href":35,"dataGaName":36,"dataGaLocation":444},{"text":611,"config":612},"Aide",{"href":613,"dataGaName":614,"dataGaLocation":444},"/support/","get help",{"text":348,"config":616},{"href":350,"dataGaName":351,"dataGaLocation":444},{"text":618,"config":619},"Statut",{"href":620,"dataGaName":621,"dataGaLocation":444},"https://status.gitlab.com/","status",{"text":623,"config":624},"Conditions d'utilisation",{"href":625,"dataGaName":626},"/terms/","terms of use",{"text":628,"config":629},"Déclaration de confidentialité",{"href":630,"dataGaName":631,"dataGaLocation":444},"/fr-fr/privacy/","privacy statement",{"text":633,"config":634},"Préférences en matière de cookies",{"dataGaName":635,"dataGaLocation":444,"id":636,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"items":638},[639,641,644],{"text":623,"config":640},{"href":625,"dataGaName":626,"dataGaLocation":444},{"text":642,"config":643},"Politique de confidentialité",{"href":630,"dataGaName":631,"dataGaLocation":444},{"text":633,"config":645},{"dataGaName":635,"dataGaLocation":444,"id":636,"isOneTrustButton":13},[647,662,675,688,701,714,727,740,753,765],{"id":648,"title":649,"body":6,"category":6,"config":650,"content":654,"description":6,"extension":11,"meta":656,"navigation":13,"path":657,"seo":658,"slug":6,"stem":660,"testContent":6,"type":6,"__hash__":661},"blogCategories/fr-fr/blog/categories/agile-planning.yml","Agile Planning",{"template":651,"slug":652,"hide":653},"BlogCategory","agile-planning",false,{"name":655},"Planification Agile",{},"/fr-fr/blog/categories/agile-planning",{"title":655,"description":659},"Browse articles related to Planification Agile on the GitLab Blog","fr-fr/blog/categories/agile-planning","eCqDMy3Tm86R-iWAOOuE2c44f2rrTYcCvzRSwiYWJ-M",{"id":663,"title":664,"body":6,"category":6,"config":665,"content":667,"description":6,"extension":11,"meta":669,"navigation":13,"path":670,"seo":671,"slug":6,"stem":673,"testContent":6,"type":6,"__hash__":674},"blogCategories/fr-fr/blog/categories/ai-ml.yml","Ai Ml",{"template":651,"slug":666,"hide":653},"ai-ml",{"name":668},"IA/ML",{},"/fr-fr/blog/categories/ai-ml",{"title":668,"description":672},"Browse articles related to IA/ML on the GitLab Blog","fr-fr/blog/categories/ai-ml","QEkTagmpAgYCe2FweiJ5Mdu-ASs4S6n27fkyyQbeQYw",{"id":676,"title":677,"body":6,"category":6,"config":678,"content":680,"description":6,"extension":11,"meta":682,"navigation":13,"path":683,"seo":684,"slug":6,"stem":686,"testContent":6,"type":6,"__hash__":687},"blogCategories/fr-fr/blog/categories/bulletin-board.yml","Bulletin Board",{"template":651,"slug":679,"hide":653},"bulletin-board",{"name":681},"Annonces",{},"/fr-fr/blog/categories/bulletin-board",{"title":681,"description":685},"Browse articles related to Annonces on the GitLab Blog","fr-fr/blog/categories/bulletin-board","CgolUFMrAPm4AqXQgRGM3NrXyeBTkTdY4L4PMTLX5ao",{"id":689,"title":690,"body":6,"category":6,"config":691,"content":693,"description":6,"extension":11,"meta":695,"navigation":13,"path":696,"seo":697,"slug":6,"stem":699,"testContent":6,"type":6,"__hash__":700},"blogCategories/fr-fr/blog/categories/customer-stories.yml","Customer Stories",{"template":651,"slug":692,"hide":653},"customer-stories",{"name":694},"Étude de cas",{},"/fr-fr/blog/categories/customer-stories",{"title":694,"description":698},"Browse articles related to Étude de cas on the GitLab Blog","fr-fr/blog/categories/customer-stories","oD7Yig6z8tF5C1WEm53kLdc1lXLLzK7gGqNML46MHqY",{"id":702,"title":703,"body":6,"category":6,"config":704,"content":706,"description":6,"extension":11,"meta":708,"navigation":13,"path":709,"seo":710,"slug":6,"stem":712,"testContent":6,"type":6,"__hash__":713},"blogCategories/fr-fr/blog/categories/devsecops.yml","Devsecops",{"template":651,"slug":705,"hide":653},"devsecops",{"name":707},"DevSecOps",{},"/fr-fr/blog/categories/devsecops",{"title":707,"description":711},"Browse articles related to DevSecOps on the GitLab Blog","fr-fr/blog/categories/devsecops","5CrNSdWz8mAe8HviC-_hzouJyiY3I5xVJekmz-uuxvM",{"id":715,"title":716,"body":6,"category":6,"config":717,"content":719,"description":6,"extension":11,"meta":721,"navigation":13,"path":722,"seo":723,"slug":6,"stem":725,"testContent":6,"type":6,"__hash__":726},"blogCategories/fr-fr/blog/categories/engineering.yml","Engineering",{"template":651,"slug":718,"hide":653},"engineering",{"name":720},"Ingénierie",{},"/fr-fr/blog/categories/engineering",{"title":720,"description":724},"Browse articles related to Ingénierie on the GitLab Blog","fr-fr/blog/categories/engineering","QgLZNRi6l7UgbB5sPrIeGPDanWZXCR-1E7llL3f2HA4",{"id":728,"title":729,"body":6,"category":6,"config":730,"content":732,"description":6,"extension":11,"meta":734,"navigation":13,"path":735,"seo":736,"slug":6,"stem":738,"testContent":6,"type":6,"__hash__":739},"blogCategories/fr-fr/blog/categories/news.yml","News",{"template":651,"slug":731,"hide":653},"news",{"name":733},"Actualités",{},"/fr-fr/blog/categories/news",{"title":733,"description":737},"Browse articles related to Actualités on the GitLab Blog","fr-fr/blog/categories/news","QZmlZtD0CUGmknioTqq1c_83S87r3pvABIaaQlQzRzM",{"id":741,"title":742,"body":6,"category":6,"config":743,"content":745,"description":6,"extension":11,"meta":747,"navigation":13,"path":748,"seo":749,"slug":6,"stem":751,"testContent":6,"type":6,"__hash__":752},"blogCategories/fr-fr/blog/categories/open-source.yml","Open Source",{"template":651,"slug":744,"hide":653},"open-source",{"name":746},"Open source",{},"/fr-fr/blog/categories/open-source",{"title":746,"description":750},"Browse articles related to Open source on the GitLab Blog","fr-fr/blog/categories/open-source","rj3ZmgYeIL4rq70hMj1N46cv3zwho00yhlPs_8_a4zo",{"id":754,"title":755,"body":6,"category":6,"config":756,"content":758,"description":6,"extension":11,"meta":759,"navigation":13,"path":760,"seo":761,"slug":6,"stem":763,"testContent":6,"type":6,"__hash__":764},"blogCategories/fr-fr/blog/categories/product.yml","Product",{"template":651,"slug":757,"hide":653},"product",{"name":71},{},"/fr-fr/blog/categories/product",{"title":71,"description":762},"Browse articles related to Produit on the GitLab Blog","fr-fr/blog/categories/product","xnMpk_LeB1cHpmZfK2kjmim_7OxrgcGuNf716Rbj6eE",{"id":766,"title":767,"body":6,"category":6,"config":768,"content":770,"description":6,"extension":11,"meta":771,"navigation":13,"path":772,"seo":773,"slug":6,"stem":775,"testContent":6,"type":6,"__hash__":776},"blogCategories/fr-fr/blog/categories/security.yml","Security",{"template":651,"slug":769,"hide":653},"security",{"name":105},{},"/fr-fr/blog/categories/security",{"title":105,"description":774},"Browse articles related to Sécurité on the GitLab Blog","fr-fr/blog/categories/security","w53e73P2QHMFJINqvUAC204SXUgtVy7XBivdu5WQyqo",[778,826,866,892,938,974,1016,1054,1092,1129],{"category":655,"slug":652,"posts":779},[780,797,813],{"content":781,"config":794},{"title":782,"description":783,"heroImage":784,"date":785,"body":786,"category":652,"tags":787,"authors":791},"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.",[788,789,790,757],"AI/ML","agile","features",[792,793],"Aathira Nair","Amanda Rueda",{"featured":13,"template":795,"slug":796},"BlogPost","ace-your-planning-without-the-context-switching",{"content":798,"config":811},{"body":799,"title":800,"description":801,"authors":802,"heroImage":806,"date":807,"category":652,"tags":808},"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\nLes vues intégrées ne sont que le début de la vision du [groupe Knowledge](https://about.gitlab.com/direction/plan/knowledge/) consacrée au suivi du travail. Découvrez nos futurs projets dans l'[epic post disponibilité générale des vues intégrées](https://gitlab.com/groups/gitlab-org/-/epics/15249). En ce qui concerne l'évolution de cette fonctionnalité, nous nous engageons à renforcer son efficacité et son [accessibilité](https://gitlab.com/gitlab-org/gitlab/-/issues/548722).\n\n\n## 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,804,805],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","2025-09-09",[789,809,810],"workflow","DevSecOps platform",{"featured":653,"template":795,"slug":812},"embedded-views-the-future-of-work-tracking-in-gitlab",{"content":814,"config":824},{"title":815,"description":816,"authors":817,"heroImage":818,"date":819,"body":820,"category":652,"tags":821,"updatedDate":823},"Scaled Agile Framework : adoptez le framework SAFe avec GitLab ","Découvrez comment intégrer le Scaled Agile Framework (SAFe) aux fonctionnalités natives de la plateforme DevSecOps de GitLab.",[793],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","Lorsqu'une entreprise décide d'adopter le Scaled Agile Framework (SAFe) pour s'adapter à ses nouveaux besoins, coordonner les équipes qui travaillent sur des produits complexes devient rapidement un enjeu de taille. Elle doit couramment faire face à un défi majeur : la planification s'effectue dans un outil, tandis que le travail de développement proprement dit est géré dans un autre.\n\nCette séparation crée des silos entre les équipes et entraîne une multitude de problèmes au quotidien : les équipes de développement passent constamment d'un système à l'autre, les chefs de produit peinent à obtenir une image précise de l'avancement des projets, et au final, ce sont tous les contributeurs aux projets qui perdent un temps précieux à transférer manuellement des informations entre les différents systèmes. Or, SAFe a précisément été conçu pour résoudre ce type d'expérience fragmentée.\n\nSi vos équipes de développement utilisent déjà GitLab pour la [gestion du code source](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\"), les processus [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et la sécurité des logiciels, vous vous demandez peut-être s'il est possible d'y intégrer également la planification SAFe. La réponse est oui. Grâce à ses solides capacités de gestion de projets Agile, GitLab prend en charge le framework SAFe à chaque étape du développement logiciel.\nDans cet article, découvrez comment GitLab vous aide à mettre en place les concepts et les cérémonies SAFe, le tout au sein d'une seule et même plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\").\n\n## Qu'est-ce que le Scaled Agile Framework (SAFe) ?\n\nLe Scaled Agile Framework (SAFe) est une approche de gestion conçue pour appliquer les principes Agile à l'échelle des grandes entreprises. Il optimise la livraison de valeur, assure un alignement constant entre les équipes et se concentre sur les besoins des clients.\nSAFe transpose le modèle collaboratif et itératif des petites équipes aux environnements complexes des grandes entreprises impliquant de nombreuses équipes, parties prenantes et roadmaps.\nCette approche permet d'harmoniser tous les efforts de planification et d'exécution vers un objectif commun. Pour les chefs de produit, le Scaled Agile Framework (SAFe) fait le lien entre la stratégie et l'exécution : il ne s'agit pas uniquement de livrer rapidement, mais de livrer les bons produits, en s'appuyant sur des priorités claires et une coordination transversales entre les différentes équipes.\n\nSAFe réduit les silos, encourage la collaboration et aide les équipes à se mobiliser autour des résultats attendus par les clients, et non plus uniquement autour des tâches à accomplir. Une fois intégré à GitLab, la magie opère : visibilité, traçabilité et livraison sont réunies au sein d'une seule et même plateforme.\n\n## Correspondance de la terminologie SAFe dans GitLab\n\nVoici un aperçu des concepts SAFe et leur correspondance dans GitLab :\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Epic principal |\n| Capability | Sous-epic (niveau 1) |\n| Feature | Sous-epic (niveau 2) |\n| User story | Ticket |\n| Task | Tâche |\n| Team | Champ personnalisé / Label à portée limitée |\n| Sprint | Itération |\n| Program Increment (PI) | Jalon |\n| Value Stream | Groupe principal |\n| Agile Release Train (ART) | Groupe principal |\n\n\u003Cbr>\u003C/br>\n\nEn vous basant sur cette correspondance, vous pouvez configurer GitLab pour refléter fidèlement votre implémentation SAFe. La structure des groupes vous permet d'organiser vos équipes autour de vos chaînes de valeur (Value Stream) et de vos Agile Release Trains (ART), tandis que la hiérarchie des éléments de travail (avec jusqu'à sept niveaux d'epics imbriqués) vous offre toute la profondeur nécessaire pour gérer des portefeuilles produits complexes. Que vous travailliez au niveau du portefeuille (groupes principaux), du programme (sous-groupes) ou de l'équipe (projets), la structure organisationnelle de GitLab s'aligne parfaitement avec la hiérarchie SAFe.\n\n## Les cérémonies SAFe dans GitLab\n\nDécouvrez maintenant comment organiser vos cérémonies SAFe dans GitLab. Voici comment procéder, étape par étape.\n\n### Planification PI (Program Increment)\n\nPour faciliter l'alignement entre les équipes et la gestion des dépendances qui font le succès de la planification PI, GitLab offre plusieurs fonctionnalités :\n\n* La vue [Roadmap](https://docs.gitlab.com/user/group/roadmap/) :  visualisez les fonctionnalités par équipe et sur plusieurs périodes.\n* Les [jalons](https://docs.gitlab.com/user/project/milestones/) : associez chaque fonctionnalité au jalon correspondant à votre PI. * Les [dépendances](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues) : documentez et visualisez les dépendances entre équipes dès qu'elles sont identifiées.\n\nGitLab vous offre une grande flexibilité pour la planification PI grâce à deux vues principales : les tableaux des epics (qui peuvent être configurés pour afficher les affectations par équipe) et la vue Roadmap (qui affiche les fonctionnalités au fil du temps, façon diagramme de Gantt). Vous pouvez facilement passer d'une vue à l'autre pendant votre session de planification, selon que vous souhaitez vous concentrer sur la chronologie ou l'organisation des équipes.\n\n![Vue Roadmap et tableau des epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Vue Roadmap avec diagramme de Gantt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Affinement\n\nEn tant que chef de produit, animer des sessions d'affinement efficaces repose sur une visibilité complète de votre backlog de fonctionnalités. Vous pouvez exécuter votre session d'affinement directement dans GitLab. Il n'est plus nécessaire de mettre à jour un outil pendant la réunion, puis un autre après coup.\nGitLab facilite les sessions d'affinement grâce aux éléments suivants :\n\n* Les [tableaux des epics](https://docs.gitlab.com/user/group/epics/epic_boards/) : regroupez les fonctionnalités en fonction de leur statut.  * Les story points : visualisez-les directement dans l'[aperçu](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic).  * Les [vues dans un volet latéral](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer) : interagissez avec vos éléments de travail sans jamais perdre de vue le contexte.   * Les [tickets enfants](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) : créez et associez des tickets directement à partir des epics.\n\n![SAFe - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Planification de sprint\n\nGitLab vous offre tous les outils nécessaires pour planifier vos sprints sans frictions :\n\n* Les [tableaux des tickets](https://docs.gitlab.com/user/project/issue_board/) : visualisez clairement l'ensemble de votre backlog.  * Le [poids total](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) des user stories : visualisez-le directement dans les tableaux.  * L'ordonnancement des tickets : déplacez les tickets entre les différentes itérations, par simple glisser-déposer. * Une vue repliable : simplifiez le réordonnancement des stories d'un sprint à l'autre.\n\nPlus besoin de jongler entre plusieurs outils, toute la planification se fait dans GitLab. Vous pouvez ainsi consacrer vos réunions de planification à prendre les bonnes décisions.\n\n![Planification de sprint avec GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 Consultez [ce tutoriel dédié à la mise en œuvre de la méthode Scrum avec GitLab](https://docs.gitlab.com/tutorials/scrum_events/) et découvrez en détail la puissance de GitLab dans la planification Agile et le suivi des sprints.*\n\n### Points quotidiens\n\nVotre équipe peut se réunir autour du tableau de bord lors de vos points quotidiens, plus besoin de naviguer entre plusieurs outils ou de deviner l'avancement des projets : tout est visible en un clin d'œil dans GitLab. Votre équipe voit instantanément qui travaille sur quoi, ce qui bloque, et ce qui est prêt pour la revue. GitLab vous permet d'effectuer les actions suivantes lors de vos points quotidiens :\n\n* Les tableaux [filtrés par itération](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) : affichez le travail du sprint en cours.\n* Les story points : affichez le poids des stories directement sur les cartes. * La [vue du volet latéral](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer) : accédez aux détails sans quitter le contexte. * Les [indicateurs de progression](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status) : mettez en évidence les tâches à risque.\n\n![Tableau de réunions debout quotidiennes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Revue de sprint\n\nPour avoir une vision claire des performances de votre équipe au fil des sprints, GitLab met à votre disposition des indicateurs puissants avec les éléments suivants :\n\n* Des [graphiques d'avancement burndown et burnup](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) : visualisez facilement l'avancement des itérations. * Le suivi de la vélocité : mesurez l'efficacité de votre équipe.  * Les [délais d'exécution et la durée de cycle](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics) : obtenez des indicateurs précis pour évaluer vos workflows.  * Des tableaux de bord personnalisables : créez des vues adaptées à chaque équipe.\n\nCes indicateurs vous aident à comprendre si votre équipe gagne en rapidité, à détecter les goulots d'étranglement et les points de friction à aborder lors de votre prochaine rétrospective.\n\n![Graphiques d'avancement burndown et burnup](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 bonnes raisons d'adopter une plateforme unifiée\n\nIl existe de nombreux outils de planification capables de gérer les cérémonies SAFe. Mais GitLab se distingue véritablement de ses concurrents pour les raisons suivantes :\n\n1. **Plus de changement de contexte** : la planification, le développement, les tests et la sécurité s'effectuent tous sur une seule plateforme.\n2. **Une traçabilité totale** : de l'épic stratégique et prioritaire jusqu'au déploiement, en passant par l'écriture du code, chaque élément est relié et facile à suivre.\n3. **Une collaboration efficace** : toutes les équipes (développement, produit, sécurité) collaborent dans le même outil.\n4. **Une visibilité instantanée** : toutes les parties prenantes accèdent aux informations clés mises à jour, sur une seule plateforme.\n5. **Une vue d'ensemble** : les indicateurs de planification et de développement sont regroupés pour comprendre exactement où en est le projet.\n\nSi vos équipes de développement apprécient déjà GitLab, pourquoi leur imposer un nouvel outil de planification ou créer des intégrations complexes et disparates ? En intégrant votre planification SAFe à GitLab, vous offrez à tous les contributeurs une expérience unifiée, cohérente et bien plus efficace.\n\n## Principes de mise en œuvre\n\nAprès avoir accompagné plusieurs équipes dans leur transition depuis des outils SAFe traditionnels vers GitLab, voici ce qu'il faut retenir : concentrez-vous sur **les objectifs propres à chaque cérémonie SAFe** plutôt que d'essayer de reproduire les processus de vos anciens outils.\n\nLes équipes qui tirent pleinement parti des fonctionnalités natives de GitLab sont plus performantes que celles qui essaient de les contourner. Cela demande un peu de travail au départ pour comprendre comment associer vos concepts SAFe et configurer vos workflows. Mais une fois cette étape franchie, vous constaterez rapidement que vos processus sont en réalité bien plus simples.\n\nLa clé du succès réside dans la définition de conventions partagées entre tous les contributeurs : quels labels utiliser ? Comment suivre les équipes ? Quelle différence entre un epic et un ticket ? En investissant un minimum d'effort dans cette phase de clarification, vous créez un système intuitif qui éliminera toute la charge de travail liée à la coordination entre les différents outils.\n\n## Mise en place du framework SAFe dans GitLab\n\nEnvie de vous lancer ? Voici les étapes pour mettre en œuvre un Scaled Agile Framework (SAFe) dans GitLab :\n\n1. **Structurez votre environnement** : créez des groupes et des sous-groupes qui [s'alignent sur l'organisation de vos équipes](https://about.gitlab.com/fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).\n2. **Définissez la répartition de votre travail** : décidez comment vous allez utiliser les [epics](https://about.gitlab.com/fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), les [tickets](https://docs.gitlab.com/user/project/issues/managing_issues/) et les [tâches](https://docs.gitlab.com/user/tasks/). 3. **Créez vos itérations** : configurez votre [calendrier de sprints](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence).  4. **Ajoutez vos jalons** : les [jalons](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) représentent vos Program Increments (PI) SAFe dans GitLab. 5. **Personnalisez vos tableaux** : créez des vues dédiées à chaque cérémonie SAFe. 6. **Accordez-vous sur des conventions** : documentez la façon dont vous utiliserez les labels et les champs personnalisés.\n\nPrendre le temps de bien poser ces bases dès le départ vous évitera bien des tracas par la suite. Votre configuration n'a pas besoin d'être parfaite dès le premier jour : vous pourrez faire des ajustements au fur et à mesure.\n\n## Rassemblez toutes les pièces du puzzle\n\nGitLab vous offre une base solide pour exécuter le Scaled Agile Framework (SAFe), en particulier si vos équipes de développement sont déjà adeptes de GitLab. En centralisant la planification et le développement dans un seul et même outil, vous éliminez les silos et les transferts fastidieux, facilitez la collaboration et accélérez la livraison de vos produits.\n\nLa flexibilité des outils de planification de GitLab vous permet d'adapter l'approche SAFe à vos besoins spécifiques. Vos équipes ne sont pas soumises à des workflows rigides : vous pouvez faire évoluer votre approche à mesure que vos équipes gagnent en maturité et que vos besoins changent.\n\n> Découvrez à quel point la planification sans effet de silo peut être plus simple et plus efficace. [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) et simplifiez l'implémentation de votre approche SAFe.\n\n*💡 Pour en savoir plus à ce sujet, n'hésitez pas à consulter également cet article : [Comment utiliser GitLab pour le développement logiciel agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/)*\n",[789,810,790,757,822],"tutorial","2025-05-12",{"slug":825,"featured":13,"template":795},"safe-without-silos-in-gitlab",{"category":668,"slug":666,"posts":827},[828,840,852],{"content":829,"config":838},{"title":830,"description":831,"authors":832,"date":834,"body":835,"category":666,"tags":836,"heroImage":837},"GitLab Duo Agent Platform : comment réinventer le développement logiciel avec l’IA agentique","Découvrez comment GitLab Duo Agent Platform transforme la collaboration entre équipes de développement et les agents d’IA.\n",[833],"GitLab France Team","2026-02-24","> *Cet article de blog est un résumé de notre webinaire sur la Collaboration entre agents d’IA et développeurs animé par Lucas Rangeard (Solutions Architect) et Chloé Cartron (Senior Solutions Architect). Pour visionner le replay, [cliquez ici](https://learn.gitlab.com/fr-oct-agentic-ai/duo-ai-fr).* \n\nStructurer un besoin client en ticket, diviser un ticket en sous-tâches assignables, et implémenter la fonctionnalité : trois opérations qui, dans un cycle de développement traditionnel, s'enchaînent de manière séquentielle entraînant un goulot d'étranglement bien connu des [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"équipes DevOps\").\n\nGrâce à GitLab Duo Agent Platform, ces trois tâches sont exécutées en parallèle, avec une merge request prête à être revue en quelques minutes. \n\nDécouvrez dans cet article les capacités de GitLab Duo Agent Platform conçue pour transformer la collaboration entre équipes de développement et agents intelligents et apprenez comment mettre en place des flows, de la création d’un ticket au développement d’une application à travers trois cas d’usage.\n\n## GitLab Duo Agent Platform : une orchestration agentique native\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/ \"GitLab Duo Agent Platform\") représente une évolution majeure dans notre approche du DevSecOps. En disponibilité générale depuis janvier 2026 pour les clients GitLab Premium et GitLab Ultimate (GitLab.com et GitLab Self-Managed), GitLab Duo Agent Platform permet aux équipes de développement de collaborer avec des agents d’IA sur l'ensemble 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> 🎯 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’orchestration agentique au coeur du SDLC\n\nNotre approche repose sur trois piliers interconnectés :\n\n* **Nous conservons ce qui fait notre force** : une plateforme unifiée avec un système de données centralisé et des APIs.\n* **Nous ajoutons une couche d'intelligence agentique** : des agents spécialisés travaillant ensemble et de manière autonome. \n* **Nous créons un graphe de connaissances reliant l'ensemble des données entre elles** : votre code, vos tickets, vos déploiements, vos scans de sécurité. Cette interconnexion permet aux agents de comprendre votre contexte complet et de prendre des décisions éclairées rapidement. \n\n### Des agents spécialisés tout au long du SDLC\n\nGitLab Duo Agent Platform ne vise pas à remplacer les équipes de développement, mais à leur fournir des partenaires capables d'exécuter des tâches en parallèle. \n\nLes utilisateurs ont accès à trois types d’agents différents : les [agents par défaut](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/) comme [Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/), [Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) et [Data Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/data_analyst/) pour les tâches courantes de développement, les [agents personnalisables](https://docs.gitlab.com/user/duo_agent_platform/agents/custom/) pour les workflows spécifiques à votre équipe, ainsi que les [agents externes](https://docs.gitlab.com/user/duo_agent_platform/agents/external/) comme Claude Code ou OpenAI Codex. Pour en savoir plus sur les agents, consultez notre article de blog [GitLab Duo Agent Platform : comprendre les agents](https://about.gitlab.com/fr-fr/blog/understanding-agents-foundational-custom-external/).\n\nCes agents partagent un contexte unifié. Ils peuvent accéder aux tickets, au code source, aux [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), aux merge requests et à l'historique de déploiement, selon les permissions données. \n\n> Chez NatWest, l'intégration des agents d’IA dans le cycle de développement logiciel a permis d'améliorer « la productivité, la vélocité et l'efficacité » des équipes, selon Bal Kang, Engineering Platform Lead. \n\n## Comment l'IA agentique réduit les temps d'attente entre chaque étape ?\n\nDans un cycle de développement traditionnel, les étapes s'enchaînent les unes après les autres. Rédaction des spécifications, découpage en tâches, implémentation, tests, revue de code : chaque phase attend la précédente. Ce modèle séquentiel génère des temps morts et limite la capacité des équipes à traiter plusieurs demandes simultanément.\n\nL'approche agentique change cette dynamique. En déléguant des tâches à des agents autonomes, les équipes de développement peuvent avancer sur plusieurs fronts en parallèle. Pendant qu'un agent implémente une fonctionnalité, un autre structure une nouvelle demande, et un troisième prépare une analyse de sécurité. Le cycle de développement global est raccourci.\n\nL'objectif : permettre aux équipes de développement de déléguer certaines tâches à des agents pendant qu'ils se concentrent sur d'autres tâches à plus forte valeur ajoutée, tout en gardant le contrôle sur les résultats.\n\n## 3 exemples de flows à tester\n\nDécouvrez comment GitLab Duo Agent Platform transforme le quotidien des équipes grâce à ces trois cas d'usage qui peuvent être exécutés simultanément. \n\n### Transformer une idée en ticket structuré\n\nAvec GitLab Duo Agentic Chat, les utilisateurs peuvent générer un ticket complet et personnalisable à partir d'une idée en formulant leur demande en langage naturel à l’aide du modèle IA de leur choix. \n\nCe ticket comprend le titre correspondant au besoin, la user story, les critères d'acceptance, les contraintes techniques, la « definition of done », ainsi que tout autre élément de gestion de projet propre aux équipes : personnes assignées, labels, date de début et date de fin de la tâche, confidentialité du ticket, etc.\n\nL'action proposée est soumise à validation. Une fois approuvé, le ticket apparaît dans le backlog en quelques secondes.\n\n### Diviser un ticket en sous-tâches\n\nUn ticket couvrant plusieurs fonctionnalités peut être divisé automatiquement en sous-tickets distincts. L'agent crée les sous tickets, maintient les références avec le ticket parent, et préserve la cohérence des critères d'acceptance. Ce mécanisme transforme un besoin business global en un ensemble de tâches assignables aux équipes. \n\n### Générer une merge request depuis un ticket\n\nÀ partir d’un ticket décrivant une fonctionnalité à implémenter, l'agent analyse le contexte du projet, comprend l'architecture existante, et génère le code correspondant. Il modifie les fichiers nécessaires, crée une merge request et le pipeline CI/CD se lance automatiquement.\n\nIl est également possible d'assigner GitLab Duo comme relecteur sur une merge request. L'agent analyse les changements, identifie les points d'attention et laisse des commentaires dans la merge request, offrant un premier niveau de revue avant la sollicitation des pairs.\n\n## Une collaboration entre humains et IA\n\nUn aspect distingue GitLab Duo Agent Platform des approches purement automatisées : chaque action proposée par un agent nécessite une validation explicite. L'utilisateur visualise ce que l'agent souhaite exécuter et approuve ou ajuste le travail effectué par l’agent avant d’effectuer une action.\nCette approche répond aux exigences des équipes en matière de gouvernance. L'agent accélère l'exécution, mais les décisions restent sous contrôle humain. Une approche indispensable dans un contexte où la qualité du code et la sécurité ne peuvent être compromises.\n\n## Le catalogue d’IA : un écosystème agentique\n\nAu-delà des agents natifs, GitLab développe un écosystème ouvert : le catalogue d’IA. Ce dernier permet de découvrir, utiliser et partager des agents et des flows développés par GitLab, ainsi que par toute la communauté.\n\nLes options de partage sont flexibles : ouverture à la communauté ou restriction à des usages internes selon les besoins de gouvernance.\n\nCette approche permet d'imaginer un agent expert en migration de bases de données, ou encore un flow d’optimisation de performance tous intégrés nativement dans GitLab. \n\nCes agents et flows s'intègrent à votre interface GitLab et identifient rapidement votre contexte et vos projets.\n\n## Prérequis\n\nPour utiliser GitLab Duo Agent Platform, plusieurs conditions sont requises :\n\n* Disposer de la version 18.8 ou ultérieure de GitLab ou d’un compte GitLab.com.\n* Être abonné à [GitLab Premium](https://about.gitlab.com/fr-fr/pricing/premium/) ou [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/)\n\nGitLab Duo Agent Platform utilise par défaut les modèles d'IA fournis par GitLab. Une configuration alternative utilisant les modèles des clients est disponible [pour les installations auto hébergées](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#gitlab-duo-agent-platform). Pour en savoir plus, consultez notre article [IA agentique avec contrôle d'entreprise : 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/).\n\n## Perspectives : l'IA agentique au coeur du DevSecOps\n\nGitLab Duo Agent Platform marque une évolution dans l'intégration de l'IA dans le cycle de développement DevSecOps. Il ne s'agit plus uniquement de suggestions de code, mais d'une véritable orchestration agentique où des agents spécialisés prennent en charge des workflows complets.\n\nVous souhaitez en savoir plus sur les flows ? Consultez notre article [Comprendre les flows : workflows multi-agents](https://about.gitlab.com/fr-fr/blog/understanding-flows-multi-agent-workflows/) et découvrez comment utiliser les [flows par défaut](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/) et les [flows personnalisables](https://docs.gitlab.com/user/duo_agent_platform/flows/custom/).\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 !",[788],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1765809212/noh0mdfn9o94ry9ykura.png",{"featured":653,"template":795,"slug":839},"gitlab-duo-agent-platform-software-development-agentic-ai",{"content":841,"config":850},{"title":842,"description":843,"authors":844,"heroImage":846,"date":847,"body":848,"category":666,"tags":849},"IA agentique avec contrôle d'entreprise : GitLab Duo Agent Platform Self-Hosted et BYOM","Découvrez comment GitLab 18.9 offre aux entreprises des secteurs réglementés une IA agentique gouvernée grâce à GitLab Duo Agent Platform Self-Hosted et à la prise en charge Bring Your Own Model.",[845],"Rebecca Carter","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","2026-02-19","Pour les organisations qui opèrent dans des secteurs réglementés, la transition vers l'automatisation alimentée par l'IA s'accompagne de contraintes strictes. La résidence des données, le contrôle des fournisseurs et la gouvernance ne sont pas négociables. De nombreuses organisations ont déjà investi massivement dans leurs propres modèles, avec des processus d'approbation rigoureux qui régissent leur fonctionnement et leur déploiement.\n\nAvec [GitLab 18.9](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/), nous proposons deux fonctionnalités qui comblent une lacune stratégique critique pour ces organisations et transformons [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) en un plan de contrôle d'IA prêt à être déployé et gouvernable pour les environnements réglementaires les plus stricts.\n\n## GitLab Duo Agent Platform Self-Hosted pour les licences cloud en ligne\nAvec GitLab Duo Agent Platform, les équipes d'ingénierie créent des flows alimentés par l'IA qui automatisent des séquences de tâches, allant de la refactorisation des services au renforcement des pipelines CI/CD en passant par la hiérarchisation des vulnérabilités. Jusqu'à présent, l'utilisation de GitLab Duo Agent Platform en production avec des modèles auto-hébergés était principalement alignée sur des chemins de licence hors ligne ou complémentaires et n'était pas conçue pour les clients disposant de licences cloud en ligne qui opèrent dans des environnements avec des réglementations strictes.\n\nDésormais en disponibilité générale, [GitLab Duo Agent Platform Self-Hosted pour les licences cloud en ligne](https://docs.gitlab.com/subscriptions/subscription-add-ons/#gitlab-duo-agent-platform-self-hosted) introduit un modèle de facturation basé sur l'usage alimenté par les [GitLab Credits](https://about.gitlab.com/fr-fr/blog/introducing-gitlab-credits/). Cette approche offre la mesure transparente et prévisible dont les entreprises ont besoin pour instaurer la confiance et la refacturation interne.\n* **Résidence et contrôle des données** : vous pouvez désormais exécuter GitLab Duo Agent Platform en production sur des licences cloud en ligne tout en utilisant des modèles hébergés sur votre propre infrastructure ou dans des environnements cloud approuvés. Vous contrôlez ainsi le lieu d'exécution des modèles et la façon dont le trafic d'inférence est acheminé dans vos environnements approuvés.\n* **Transparence des coûts et refacturation** : bénéficiez d'une transparence granulaire des coûts grâce aux GitLab Credits et au décompte par requête, deux éléments essentiels pour une refacturation interne précise et le respect des normes réglementaires en matière de reporting.\n* **Accélération de l'adoption** : supprime un obstacle majeur au déploiement de l'IA agentique dans des secteurs comme les services financiers, les administrations publiques et les infrastructures critiques, où l'acheminement des données via des fournisseurs d'IA externes n'est tout simplement pas envisageable. Avec GitLab 18.9, GitLab Duo Agent Platform devient un environnement de déploiement de premier ordre pour les licences cloud en ligne.\n\n## Bring Your Own Model\nL'auto-hébergement de la couche d'orchestration n'est qu'une partie de la solution. De nombreux clients de secteurs réglementés ont déjà investi massivement dans leurs propres modèles : des LLM adaptés à leur domaine, des déploiements dans une région dédiée ou air-gapped pour la souveraineté des données, et des modèles fermés et internes conçus en fonction d'un profil de risque spécifique.\n\n**Bring Your Own Model (BYOM)** renforce la flexibilité de GitLab Duo Agent Platform. Les administrateurs peuvent connecter des modèles tiers ou auto-hébergés via la [passerelle d'IA (AI-Gateway) de GitLab](https://docs.gitlab.com/administration/gitlab_duo/gateway/), et les clients choisissent et contrôlent le modèle.\n* **Intégration et gouvernance** : les modèles BYOM apparaissent aux côtés des modèles gérés par GitLab dans le plan de contrôle d'IA de GitLab. GitLab Duo Agent Platform peut ainsi les traiter comme des options prêtes à l'emploi pour l'entreprise.\n* **Mappage granulaire** : une fois enregistrés via la passerelle d'IA, les modèles peuvent être mappés à des flows ou des fonctionnalités spécifiques de GitLab Duo Agent Platform. Vous pouvez ainsi exercer un contrôle étroit sur les agents et les flows, ainsi que sur les modèles utilisés. Les administrateurs restent toujours responsables de la validation des modèles, des performances et de l'évaluation des risques. Vous êtes responsable de la compatibilité, des performances et de l'évaluation des risques pour les modèles que vous apportez.\n\nEnsemble, ces fonctionnalités donnent aux responsables d'ingénierie un contrôle complet sur l'IA agentique. Ce plan de contrôle unique et gouverné pour l'IA agentique remplace l'ensemble fragmenté de solutions ponctuelles et d'outils d'IA non gérés sur lesquels de nombreuses organisations s'appuient aujourd'hui. Il s'agit d'une combinaison que les organisations réglementées réclamaient depuis longtemps : la liberté de choisir son modèle accompagnée d'une gouvernance forte, au sein de la même plateforme DevSecOps en laquelle elles ont déjà confiance.\n\n> Vous souhaitez essayer GitLab Duo Agent Platform ? [Contactez-nous ou commencez un essai gratuit dès aujourd'hui](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).\n\n-----------\n\n_Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou des issues réels sensiblement différents. Des informations supplémentaires sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige._",[788,757,790],{"featured":13,"template":795,"slug":851},"agentic-ai-enterprise-control-self-hosted-duo-agent-platform-and-byom",{"content":853,"config":864},{"description":854,"body":855,"title":856,"heroImage":857,"date":858,"authors":859,"category":666,"tags":861},"Ce guide explique comment déployer un agent d'IA basé sur l'Agent Development Kit vers Google Kubernetes Engine à l'aide de la plateforme DevSecOps de GitLab en toute simplicité et sécurité.","Créer des [agents d'IA](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) est passionnant, mais leur déploiement sécurisé en production est parfois compliqué. Dans ce tutoriel, vous découvrirez comment [l'intégration native de GitLab avec Google Cloud](https://cloud.google.com/blog/topics/partners/understand-the-google-cloud-gitlab-integration) facilite le déploiement d'agents d'IA vers Google Kubernetes Engine (GKE), avec scans de sécurité intégrés et sans clés de compte de service.\n\n\n\n## Pourquoi choisir GKE pour déployer vos agents d'IA ?\n\n\n\nGKE offre une orchestration d'entreprise qui s'intègre parfaitement aux pipelines [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) de GitLab grâce à l'authentification OpenID Connect (OIDC). Votre équipe de développement peut déployer des agents d'IA tout en conservant une visibilité, une conformité et un contrôle complets sur votre infrastructure cloud. Ce guide utilise l'Agent Development Kit ([ADK](https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/)) de Google afin de créer l'application, ce qui garantit une intégration fluide lors du déploiement avec GitLab.\n\n\n\nVoici trois avantages clés de cette approche :\n\n\n\n**Contrôle total de l'infrastructure :** vos données, vos règles, votre environnement. Vous conservez un contrôle complet sur l'emplacement d'exécution de vos agents d'IA et de leur configuration.\n\n\n\n **Intégration native avec GitLab :** pas de solution de contournement complexe. Vos pipelines existants fonctionnent immédiatement grâce à l'intégration native de GitLab avec Google Cloud.\n\n\n\n **Mise à l'échelle de niveau production :** GKE gère automatiquement la mise à l'échelle et l'orchestration interne à mesure que vos charges de travail d'IA augmentent.\n\n\n\nAvec GKE, GitLab offre la fiabilité d'entreprise dont vos déploiements d'IA ont besoin sans sacrifier l'expérience développeur que vos équipes attendent.\n\n\n\n## Prérequis\n\n\n\nAvant de commencer, assurez-vous d'avoir activé ces API :\n\n\n\n- API GKE\n\n\n- API Artifact Registry\n\n\n- API Vertex AI\n\n\n\nAssurez-vous également de disposer des éléments suivant :\n\n\n- Un projet GitLab créé\n\n\n- Un cluster GKE provisionné\n\n\n- Un dépôt Artifact Registry créé\n\n\n\n## Le processus de déploiement\n\n\n\n### 1. Configurer IAM et les autorisations sur GitLab\n\n\n\nAccédez à vos intégrations GitLab afin de configurer l'authentification Google Cloud (IAM).\n\n\n\nAccédez à **Paramètres > Intégrations** et configurez l'intégration Google Cloud. Si vous utilisez une intégration au niveau du groupe, notez que les paramètres par défaut sont déjà hérités par les projets. Il vous suffit donc de configurer vos paramètres une fois au niveau du groupe pour que tous les projets en bénéficient et les héritent.\n\n\n\nPour configurer les paramètres, vous devez fournir les éléments suivants :\n\n\n- ID du projet\n\n\n- Numéro du projet \n\n\n- ID du pool d'identités de charge de travail\n\n- ID du fournisseur\n\n\n\nUne fois ces informations renseignées, GitLab fournit un script à exécuter dans Google Cloud Console via Cloud Shell. Le résultat de l'exécution de ce script est un pool de fédération d'identité de charge de travail avec l'identité de service de compte principal nécessaire pour permettre l'accès approprié.\n\n\n### 2. Configurer l'intégration à Artifact Registry\n\n\n\nToujours dans les paramètres d'intégration de GitLab, configurez la gestion des artefacts :\n\n\n\n1. Cliquez sur **Gestion des artefacts**.\n\n\n2. Sélectionnez **Google Artifact Registry**.\n\n\n3. Indiquez les éléments suivants :\n      - ID du projet\n      - Nom du dépôt (créé au préalable)\n      - Emplacement du dépôt\n\nGitLab fournit un autre script à exécuter dans Google Cloud Console.\n\n\n\n**Important :** avant de continuer, ajoutez ces rôles supplémentaires au pool de fédération d'identité de charge de travail :\n\n\n- Utilisateur de compte de service\n\n\n- Développeur Kubernetes\n\n\n- Observateur de cluster Kubernetes\n\n\n\nCes autorisations permettent à GitLab de déployer vers GKE dans les étapes suivantes.\n\n\n\n### 3. Créer le pipeline CI/CD\n\n\n\nVoici maintenant la partie essentielle : la création du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\") pour le déploiement.\n\n\n\nAccédez à **Compilation > Éditeur de pipeline** et définissez votre pipeline en quatre étapes :\n\n\n\n* **Build :** Docker crée l'image de conteneur.\n\n\n\n* **Test :** GitLab Auto DevOps fournit des scans de sécurité intégrés afin de garantir l'absence de vulnérabilités.\n\n\n\n* **Importation :** utilise le composant CI/CD intégré de GitLab pour effectuer un push vers Google Artifact Registry.\n\n\n\n* **Déploiement :** utilise la configuration [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\") pour déployer vers GKE.\n\n\n\nVoici le fichier `.gitlab-ci.yml` complet :\n\n\n    ```yaml\n\n\n\n    default:\n      tags: [ saas-linux-2xlarge-amd64 ]\n\n    stages:\n      - build\n      - test\n      - upload\n      - deploy\n\n    variables:\n      GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA\n      AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA\n      GCP_PROJECT_ID: \"your-project-id\"\n      GKE_CLUSTER: \"your-cluster\"\n      GKE_REGION: \"us-central1\"\n      KSA_NAME: \"ai-agent-ksa\"\n\n    build:\n      image: docker:24.0.5\n      stage: build\n      services:\n        - docker:24.0.5-dind\n      before_script:\n        - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n      script:\n        - docker build -t $GITLAB_IMAGE .\n        - docker push $GITLAB_IMAGE\n\n    include:\n      - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n      - template: Jobs/Container-Scanning.gitlab-ci.yml\n      - template: Jobs/Secret-Detection.gitlab-ci.yml\n      - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main\n        inputs:\n          stage: upload\n          source: $GITLAB_IMAGE\n          target: $AR_IMAGE\n\n    deploy:\n      stage: deploy\n      image: google/cloud-sdk:slim\n      identity: google_cloud\n      before_script:\n        - apt-get update && apt-get install -y kubectl google-cloud-sdk-gke-gcloud-auth-plugin\n        - gcloud container clusters get-credentials $GKE_CLUSTER --region $GKE_REGION --project $GCP_PROJECT_ID\n      script:\n        - |\n          kubectl apply -f - \u003C\u003CEOF\n          apiVersion: apps/v1\n          kind: Deployment\n          metadata:\n            name: ai-agent\n            namespace: default\n          spec:\n            replicas: 2\n            selector:\n              matchLabels:\n                app: ai-agent\n            template:\n              metadata:\n                labels:\n                  app: ai-agent\n              spec:\n                serviceAccountName: $KSA_NAME\n                containers:\n                - name: ai-agent\n                  image: $AR_IMAGE\n                  ports:\n                  - containerPort: 8080\n                  resources:\n                    requests: {cpu: 500m, memory: 1Gi}\n                    limits: {cpu: 2000m, memory: 4Gi}\n                  livenessProbe:\n                    httpGet: {path: /health, port: 8080}\n                    initialDelaySeconds: 60\n                  readinessProbe:\n                    httpGet: {path: /health, port: 8080}\n                    initialDelaySeconds: 30\n          ---\n          apiVersion: v1\n          kind: Service\n          metadata:\n            name: ai-agent-service\n            namespace: default\n          spec:\n            type: LoadBalancer\n            ports:\n            - port: 80\n              targetPort: 8080\n            selector:\n              app: ai-agent\n          ---\n          apiVersion: autoscaling/v2\n          kind: HorizontalPodAutoscaler\n          metadata:\n            name: ai-agent-hpa\n            namespace: default\n          spec:\n            scaleTargetRef:\n              apiVersion: apps/v1\n              kind: Deployment\n              name: ai-agent\n            minReplicas: 2\n            maxReplicas: 10\n            metrics:\n            - type: Resource\n              resource:\n                name: cpu\n                target: {type: Utilization, averageUtilization: 70}\n          EOF\n          \n          kubectl rollout status deployment/ai-agent -n default --timeout=5m\n          EXTERNAL_IP=$(kubectl get service ai-agent-service -n default -o jsonpath='{.status.loadBalancer.ingress[0].ip}')\n          echo \"Deployed at: http://$EXTERNAL_IP\"\n      only:\n        - main\n```\n\n\n#### Configuration essentielle pour GKE\n\n\n\nPour que tout fonctionne, et c'est la raison pour laquelle nous avons besoin de cette configuration supplémentaire pour GKE, nous devons disposer d'un compte de service Kubernetes dans le cluster qui peut fonctionner avec Vertex AI. Ce compte de service doit être autorisé à accéder aux capacités d'IA de Google Cloud.\n\n\n\nSans cela, nous pouvons déployer l'application, mais l'agent d'IA ne fonctionnera pas. Nous devons créer un compte de service Kubernetes capable d'accéder à Vertex AI.\n\n\n\nExécutez cette configuration ponctuelle :\n\n\n\n    ```bash\n\n\n\n    #!/bin/bash\n\n\n\n    PROJECT_ID=\"your-project-id\"\n\n\n\n    GSA_NAME=\"ai-agent-vertex\"\n\n\n\n    GSA_EMAIL=\"${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com\"\n\n\n\n    KSA_NAME=\"ai-agent-ksa\"\n\n\n\n    CLUSTER_NAME=\"your-cluster\"\n\n\n\n    REGION=\"us-central1\"\n\n\n\n\n    # Create GCP Service Account\n\n\n\n    gcloud iam service-accounts create $GSA_NAME \\\n        --display-name=\"AI Agent Vertex AI\" \\\n        --project=$PROJECT_ID\n\n    # Grant Vertex AI permissions\n\n\n\n    gcloud projects add-iam-policy-binding $PROJECT_ID \\\n        --member=\"serviceAccount:${GSA_EMAIL}\" \\\n        --role=\"roles/aiplatform.user\"\n\n    # Get cluster credentials\n\n\n\n    gcloud container clusters get-credentials $CLUSTER_NAME \\\n        --region $REGION --project $PROJECT_ID\n\n    # Create Kubernetes Service Account\n\n\n\n    kubectl create serviceaccount $KSA_NAME -n default\n\n\n\n\n    # Link accounts\n\n\n\n    kubectl annotate serviceaccount $KSA_NAME -n default \\\n        iam.gke.io/gcp-service-account=${GSA_EMAIL}\n\n    gcloud iam service-accounts add-iam-policy-binding ${GSA_EMAIL} \\\n        --role=roles/iam.workloadIdentityUser \\\n        --member=\"serviceAccount:${PROJECT_ID}.svc.id.goog[default/${KSA_NAME}]\" \\\n        --project=$PROJECT_ID\n```\n\n\n### 4. Déployer vers GKE\n\n\n\nUne fois que vous avez terminé, effectuez un push vers le pipeline et le tour est joué.\n\n\n\nLe pipeline vient d'être déployé. Accédez à **CI/CD > Pipelines** pour voir les quatre étapes :\n\n\n- Build\n\n\n- Test (avec tous les scans de sécurité définis)\n\n\n- Importation vers Artifact Registry (réussie)\n\n\n- Déploiement vers Kubernetes dans GKE (réussi)\n\n\n\n## Résumé\n\n\n\nAvec GitLab et Google Cloud, vous êtes en mesure de déployer votre agent d'IA vers GKE en toute simplicité et sécurité en quelques étapes seulement grâce à l'intégration native de GitLab avec Google Cloud.\n\n\nRegardez cette démo :\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mc2pCL5Qjus?si=QoH02lvz5KH5Ku9O\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n> Utilisez [l'exemple de code complet de ce tutoriel](https://gitlab.com/gitlab-partners-public/google-cloud/demos/gke-ai-agent) pour commencer dès maintenant. Vous n’utilisez pas encore GitLab ? Découvrez la plateforme DevSecOps et profitez d'[un essai gratuit](https://about.gitlab.com/fr-fr/free-trial/). Les startups hébergées sur Google Cloud disposent d'[une offre spéciale pour essayer et utiliser GitLab](https://about.gitlab.com/fr-fr/solutions/startups/google-cloud/).","Déploiement sécurisé d'agents d'IA sur GKE","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749670563/Blog/Hero%20Images/cloudcomputing.jpg","2026-02-06",[860],"Regnard Raquedan",[788,862,863,822],"google","cloud native",{"featured":653,"template":795,"slug":865},"secure-ai-agent-deployment-to-gke",{"category":681,"slug":679,"posts":867},[868,879],{"content":869,"config":877},{"title":870,"description":871,"heroImage":872,"authors":873,"date":834,"body":875,"category":679,"tags":876},"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",[874],"Denis Afonso","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).",[757],{"featured":653,"template":795,"slug":878},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"content":880,"config":890},{"title":881,"description":882,"authors":883,"heroImage":885,"date":886,"body":887,"category":679,"tags":888,"updatedDate":889},"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.",[884],"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/) 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,731,810],"2025-03-28",{"slug":891,"featured":13,"template":795},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":694,"slug":692,"posts":893},[894,910,924],{"content":895,"config":908},{"title":896,"description":897,"authors":898,"heroImage":900,"date":901,"body":902,"category":692,"tags":903,"updatedDate":907},"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.",[899],"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",[904,905,906],"contributors","open source","customers","2025-02-10",{"slug":909,"featured":13,"template":795},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":911,"config":922},{"title":912,"description":913,"authors":914,"heroImage":916,"date":917,"body":918,"category":692,"tags":919,"updatedDate":921},"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.",[915],"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.**",[906,89,920,810],"user stories","2024-12-18",{"slug":923,"featured":13,"template":795},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":925,"config":936},{"title":926,"description":927,"authors":928,"heroImage":930,"date":931,"body":932,"category":692,"tags":933},"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.",[929],"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",[934,935,788,906],"DevOps","DevOps platform",{"slug":937,"featured":653,"template":795},"southwest-looking-to-help-developers-take-flight",{"category":707,"slug":705,"posts":939},[940,951,963],{"content":941,"config":949},{"title":942,"description":943,"authors":944,"date":945,"body":946,"category":705,"tags":947,"heroImage":948},"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.  ",[833],"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 !",[934,707],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1763646158/crdpd8lt5fndfzbcl9ln.jpg",{"featured":653,"template":795,"slug":950},"containers-vs-virtual-machines",{"content":952,"config":961},{"title":953,"description":954,"authors":955,"heroImage":957,"date":958,"body":959,"category":705,"tags":960},"[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é.",[956],"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.**",[788,935,769],{"featured":13,"template":795,"slug":962},"devsecops-report-france",{"content":964,"config":972},{"body":965,"date":966,"title":967,"description":968,"authors":969,"category":705,"tags":970,"heroImage":971},"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.",[833],[934,935,707],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1767978731/pvpg5siho29b1nrgnmea.jpg",{"featured":653,"template":795,"slug":973},"devops-benefits",{"category":720,"slug":718,"posts":975},[976,989,1004],{"content":977,"config":987},{"tags":978,"category":718,"date":980,"heroImage":981,"authors":982,"body":984,"description":985,"title":986},[757,979],"inside GitLab","2025-12-16","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1764108112/tyntnsy3xotlmehtnfkb.png",[983],"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":653,"template":795,"slug":988},"continuously-deploying-the-largest-gitlab-instance",{"content":990,"config":1002},{"tags":991,"category":718,"body":994,"date":995,"title":996,"description":997,"heroImage":998,"authors":999},[822,992,89,993],"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",[1000,1001],"Evgeny Rudinsky","Michael Leopard",{"featured":653,"template":795,"slug":1003},"migration-from-azure-devops-to-gitlab",{"content":1005,"config":1014},{"title":1006,"description":1007,"authors":1008,"tags":1010,"heroImage":1011,"category":718,"date":1012,"body":1013},"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.",[1009],"Fernando Diaz",[244,905,822],"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 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/) 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/).\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":1015,"featured":13,"template":795},"secure-rust-development-with-gitlab",{"category":733,"slug":731,"posts":1017},[1018,1030,1042],{"content":1019,"config":1028},{"title":1020,"description":1021,"authors":1022,"heroImage":1024,"date":1025,"body":1026,"category":731,"tags":1027},"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.",[1023],"Karishma Kumar","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",[707,731,259],{"featured":653,"template":795,"slug":1029},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"content":1031,"config":1040},{"heroImage":1032,"date":1033,"title":1034,"description":1035,"authors":1036,"body":1038,"category":731,"tags":1039},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1759320418/xjmqcozxzt4frx0hori3.png","2025-12-11","Nouvelle vague d'escroqueries au recrutement usurpant l'identité de recruteurs","Découvrez ces escroqueries ciblant les chercheurs d'emploi, les mesures prises par GitLab et comment vous protéger.",[1037],"Hasan Chawich","Les chercheurs d'emploi sont ciblés par des escrocs qui usurpent l'identité de recruteurs d'entreprises technologiques, notamment GitLab, via e-mails, LinkedIn et des plateformes de visioconférence. Ces escroqueries utilisent frauduleusement le nom, le logo et l'identité des membres de l'équipe GitLab pour créer l'illusion d'une activité de recrutement légitime.\n\nLes victimes ont signalé avoir reçu de fausses invitations à des entretiens, des offres d'emploi et des documents d'intégration, souvent suivis de demandes de paiement ou d'informations personnelles. Ces campagnes ne sont en aucun cas affiliées à GitLab.\n\n## Les nouveautés de cette vague\n\nLes incidents récents se distinguent des escroqueries précédentes par l'introduction de nouveaux domaines et tactiques, notamment :\n\n* L'utilisation de domaines non autorisés tels que `gitlab[.]careers` et `careers-gitlab[.]com`\n\n* Des références à de fausses certifications comme « CPD USA Certification »\n\n* De faux profils de recruteurs sur LinkedIn et Teams usurpant l'identité du personnel RH de GitLab\n\n* Des demandes d'informations sensibles ou de paiements anticipés pour « l'équipement » après de faux entretiens\n\nCes usurpateurs deviennent de plus en plus sophistiqués, utilisant des e-mails professionnels, des lettres d'offre d'apparence authentique et des invitations réalistes à des entretiens vidéo.\n\n## Signaux d'alerte courants\n\nLes candidats doivent faire preuve de prudence s'ils rencontrent l'un des éléments suivants :\n\n* Le domaine de messagerie n'est pas `@gitlab.com` (par exemple, Gmail, Outlook ou un domaine ressemblant).\n\n* Le recruteur vous demande de payer pour de l'équipement, une certification ou des vérifications d'antécédents.\n\n* La communication se fait uniquement par chat, sans invitations calendrier vérifiées de GitLab.\n\n* L'offre d'emploi n'apparaît pas sur la page carrière officielle de GitLab.\n\n* Le recruteur refuse de prouver son identité via une adresse GitLab.com ou vous dirige vers des URL externes non liées à GitLab.\n\n## Le processus de recrutement officiel de GitLab\n\nLe processus de recrutement de GitLab est entièrement à distance mais transparent et vérifiable.\n\n* Toutes les communications proviennent d'adresses de messagerie officielles `@gitlab.com`.\n\n* Les entretiens sont menés via Zoom, et non Microsoft Teams ou WhatsApp.\n\n* GitLab ne demande jamais de paiement, d'achats ou de frais de certification pendant le recrutement.\n\n* Les offres légitimes et les étapes d'intégration sont gérées de manière sécurisée via les systèmes GitLab.\n\nPour plus de détails sur notre processus de recrutement, veuillez consulter notre [manuel du candidat](https://handbook.gitlab.com/handbook/hiring/candidate-faq/).\n\n## Les mesures prises par GitLab\n\nLes équipes Sécurité et Ressources humaines de GitLab enquêtent activement et signalent les faux domaines et profils de recrutement aux fournisseurs d'hébergement et réseaux sociaux. Nous continuons à collaborer avec nos partenaires juridiques, de communication et de plateforme pour supprimer le contenu frauduleux et informer les personnes concernées.\n\nSi vous remarquez quelque chose de suspect, informez-nous à l'adresse [`security@gitlab.com`](mailto:security@gitlab.com). Toute personne peut signaler une activité de recrutement suspecte pour examen par notre équipe de réponse aux incidents de sécurité.\n\n## Comment vous protéger\n\nSi vous recevez une communication suspecte prétendant provenir de GitLab :\n\n1. Vérifiez le domaine de messagerie de l'expéditeur : il doit toujours se terminer par `@gitlab.com`.\n\n2. Consultez les offres d'emploi directement sur about.gitlab.com/jobs.\n\n3. Évitez d'envoyer des informations personnelles ou financières à des recruteurs non vérifiés.\n\n4. Signalez tout domaine ou message suspect à `security@gitlab.com`.\n\nPour des informations supplémentaires sur la façon d'éviter les escroqueries à l'emploi, consultez ces ressources fiables :\n\n* [Manuel du candidat](https://handbook.gitlab.com/handbook/hiring/candidate-faq/)  \n\n* [Ressources sur les escroqueries à l'emploi en ligne – FTC](https://consumer.ftc.gov/articles/job-scams)\n\nSi vous pensez avoir été ciblé par un faux recruteur GitLab, veuillez le signaler immédiatement à `security@gitlab.com` afin que notre équipe puisse enquêter.\n",[769],{"featured":653,"template":795,"slug":1041},"new-wave-of-fake-job-scams-impersonating-recruiters",{"content":1043,"config":1052},{"title":1044,"authors":1045,"description":1047,"heroImage":1048,"date":1049,"body":1050,"category":731,"tags":1051},"GitLab Partner Awards 2025 : les lauréats de la région EMEA",[1046],"Alex Picker","Découvrez les récompenses attribuées à nos partenaires de la région EMEA pour leur collaboration et leurs contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677669/Blog/Hero%20Images/blog-image-template-1800x945__5_.png","2025-11-25","Le [programme de partenariat](https://about.gitlab.com/fr-fr/partners/) de GitLab regroupe un écosystème de professionnels [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") dont l'objectif est de stimuler l'innovation dans le développement logiciel et d'obtenir des résultats significatifs. Cette année, plusieurs partenaires en Europe, au Moyen-Orient et en Afrique (EMEA) ont excellé dans leur expertise DevSecOps et leurs services à valeur ajoutée.\n\nPlus tôt ce mois-ci, les partenaires de la région EMEA se sont réunis lors d'un événement pour célébrer leurs réalisations, renforcer leurs capacités et définir les initiatives futures. À cette occasion, nous avons récompensé plusieurs partenaires pour leurs contributions exceptionnelles à GitLab et à nos clients communs.\n\nNous sommes ravis d'annoncer les lauréats des GitLab Partner Awards 2025 de la région EMEA dans cinq catégories :\n\n**Prix du partenaire régional de l'année** : cette distinction récompense le partenaire de chaque région qui a réalisé des performances globales exceptionnelles et favorisé une collaboration stratégique.\n\n* **Europe Centrale : [cc cloud GmbH](http://www.codecentric.cloud/)**  \n  cc cloud est une filiale de codecentric AG qui accompagne les organisations au moyen de prestations de conseil et de services gérés dans leur parcours de numérisation et de transformation. \n\n    \n* **Europe du Nord : [Adaptavist](https://www.adaptavist.com/)**\n\n  Adaptavist, membre du groupe The Adaptavist Group, offre à ses clients des services et solutions complets dans les domaines Agile, [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\"), gestion du travail, ITSM et cloud. L'organisation accompagne les workflows, la transformation métier et les stratégies de croissance soutenue. \n\n    \n* **Europe du Sud : [knowmad mood](https://www.knowmadmood.com/es)**\n\n  Knowmad mood est une société de conseil, de services informatiques et de développement logiciel qui propose des solutions innovantes pour accompagner ses clients dans leur parcours de transformation numérique.\n\n    \n* **Meta (Moyen-Orient, Turquie et Afrique) : [Digital Future](https://digital-future.me/)**\n\n  Digital Future agit comme un guichet unique pour l'agilité d'entreprise. L'entreprise aide ses clients à accélérer leur mise sur le marché dans trois domaines de transformation critiques : les talents, la technologie et les compétences.\n\n    \n* **Marchés émergents (Europe de l'Est et Israël) : [Cloudfresh](https://cloudfresh.com/en/services/gitlab/)** \n\n  Cloudfresh est un partenaire certifié GitLab qui collabore avec les organisations pour accélérer la livraison de logiciels et renforcer la sécurité tout au long de leur parcours DevSecOps. De l'étude de faisabilité à la formation en passant par l'assistance continue et les conseils alimentés par l'IA, chaque étape est adaptée au contexte informatique unique de l'organisation.\n\n**Meilleure solution/meilleur projet technique** : ce prix récompense le partenaire avec la solution technique la plus innovante, complexe ou impactante pour un client.\n\n* [**D|OPS Digital**](https://dopsdigital.com/)\n\n  D|OPS Digital, membre du groupe The Adaptavist Group, aide les organisations à maximiser leurs investissements technologiques et les développeurs à atteindre leur plein potentiel.\n\n**Partenaire avec le personnel le plus certifié et formé** : ce prix récompense le partenaire avec le plus grand nombre de professionnels certifiés GitLab dans son équipe.\n\n* [**Devoteam**](https://www.devoteam.com/fr/)\n\n  Devoteam est un cabinet de conseil de premier plan axé sur la stratégie numérique, les plateformes technologiques, la cybersécurité et la transformation métier.\n\n**Recrue de l'année** : ce prix distingue le partenaire qui vient de rejoindre le programme et a obtenu rapidement des résultats et un impact significatif.\n\n* [**Conoa**](https://www.conoa.se/)\n\n  Conoa fournit des solutions de bout en bout et une expertise de pointe, notamment des services de conseil, des formations, des ateliers, des produits, des outils et une plateforme de conteneurs gérée.\n\n**Pro des premières commandes** : ce prix célèbre le partenaire qui excelle dans l'acquisition de nouveaux clients et obtient régulièrement de nouvelles commandes.\n\n\n* [**Gantek**](https://gantek.com/)\n\n  Gantek est une société de technologies de l'information qui fournit des services à valeur ajoutée afin de répondre aux besoins d'infrastructure et d'applications/de logiciels des technologies et systèmes numériques de bout en bout.",[259,731],{"featured":653,"template":795,"slug":1053},"meet-the-2025-emea-gitlab-partner-award-winners",{"category":746,"slug":744,"posts":1055},[1056,1068,1081],{"content":1057,"config":1066},{"tags":1058,"category":744,"body":1059,"date":1060,"heroImage":1061,"authors":1062,"description":1064,"title":1065},[905,992,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",[1063],"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":653,"template":795,"slug":1067},"whats-new-in-git-2-53-0",{"content":1069,"config":1079},{"tags":1070,"category":744,"date":1071,"heroImage":1061,"authors":1072,"title":1076,"description":1077,"body":1078},[905,992,244],"2025-11-19",[1073,1074,1075],"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":653,"template":795,"slug":1080},"whats-new-in-git-2-52-0",{"content":1082,"config":1090},{"title":1083,"description":1084,"authors":1085,"date":1086,"body":1087,"category":744,"tags":1088,"heroImage":1089},"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.",[833],"2025-10-10","Docker a révolutionné la façon dont les équipes de développement créent, déploient et exécutent leurs applications grâce à une approche innovante : la conteneurisation. Cette approche est devenue incontournable dans le développement logiciel, car elle simplifie considérablement la gestion des environnements et accélère le cycle de développement logiciel. \n\nDans ce guide complet, découvrez tout ce qu'il faut savoir sur Docker : sa définition, son fonctionnement, ses avantages et son application dans un environnement [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSevOps ?\") avec la plateforme de GitLab. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial\n\"Essai gratuit de GitLab.\") \n\n## Docker : définition\n\nDocker est une plateforme de conteneurisation [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui permet aux équipes de développement d'empaqueter leurs applications et toutes leurs dépendances dans des conteneurs légers et portables. Lancé en 2013, Docker a démocratisé l'utilisation des conteneurs en proposant une solution simple et accessible pour créer des environnements d'exécution isolés.\n\n### Qu’est-ce qu’un conteneur Docker ?\n\nUn conteneur Docker représente un environnement d'exécution léger qui encapsule une application avec l'ensemble de ses composants : code source, bibliothèques, dépendances système, variables d'environnement et fichiers de configuration. Il peut parfois être comparé à une machine virtuelle dans le sens où il permet d’héberger des services sur un même serveur physique tout en les isolant les uns des autres. Néanmoins, le fonctionnement d’un conteneur diffère légèrement d’une simple machine virtuelle. \n\nMoins figés qu'une machine virtuelle, en matière de taille de disque et de ressources allouées, les conteneurs partagent le noyau de la machine hôte et isolent les processus, les utilisateurs, etc. Cela les rend très légers et leur permet de fonctionner comme s'ils étaient des machines distinctes. Par conséquent, les applications peuvent être démarrées et arrêtées rapidement.\n\n## Comment fonctionne Docker ?\n\nDocker révolutionne la virtualisation en exploitant les capacités natives du noyau Linux pour créer des environnements d'exécution légers et isolés. Contrairement à la virtualisation traditionnelle qui nécessite des machines virtuelles complètes avec leur propre système d'exploitation, Docker utilise la conteneurisation pour partager le noyau de l'hôte tout en maintenant une isolation parfaite entre les applications.\n\nLa philosophie de Docker repose sur des technologies Linux avancées telles que les namespaces (qui isolent les processus, le réseau et le système de fichiers) et les cgroups (qui limitent et contrôlent l'utilisation des ressources). Docker encapsule ces fonctionnalités complexes dans une interface simple et portable, permettant aux équipes de développement de créer des environnements cohérents sur n'importe quelle plateforme.\n\nLe processus de conteneurisation avec Docker suit un cheminement précis :\n\n1. **Création d'un Dockerfile :** ce fichier texte contient les instructions pour construire l'environnement\n2. **Construction d’une image docker** : Docker assemble les composants selon les spécifications du Dockerfile\n3. **Instanciation du conteneur** : l'image devient un conteneur exécutable\n4. **Gestion du cycle de vie** : démarrage, arrêt, surveillance et mise à jour des conteneurs\n\nPour comprendre pleinement le fonctionnement de Docker, il est essentiel de maîtriser les quatre composants fondamentaux suivants, qui contribuent à créer un écosystème de conteneurisation complet et efficace.\n\n### Docker Engine : le cœur du système\n\n[Docker Engine](https://docs.docker.com/engine/) est le moteur qui orchestre toutes les opérations de conteneurisation. Cette architecture client-serveur se compose de trois éléments interconnectés qui travaillent en harmonie :\n\n**Docker Daemon ([dockerd](https://docs.docker.com/reference/cli/dockerd/))** constitue le service central qui s'exécute en permanence sur le système hôte et gère l'ensemble du cycle de vie des conteneurs. Il supervise la création, l'exécution, la surveillance et la destruction des conteneurs, tout en gérant les images, les réseaux virtuels et les volumes de stockage. Ce daemon écoute en permanence les requêtes et exécute les opérations demandées.\n\n**L'API REST Docker** est le mode de communication principal avec Docker Daemon. Concrètement, quand vous lancez `docker run` ou [`docker build`](https://docs.gitlab.com/ci/docker/using_docker_build/), votre commande est transformée en requête HTTP qui est envoyée au daemon. Cette API permet également aux équipes de développement de créer leurs propres outils ou d'automatiser Docker dans leurs scripts et applications.\n\n**Le client Docker CLI** représente l'interface en ligne de commande que les utilisateurs emploient quotidiennement. Chaque commande `docker` (run, build, push, pull) transite par ce client qui communique avec le daemon via l'[API REST](https://about.gitlab.com/fr-fr/blog/2024/09/04/what-is-rest-api/ \"Qu'est-ce qu'une API REST ?\").\n\n### Images Docker : les modèles d'exécution\n\nUne **image Docker** constitue un modèle immuable et en lecture seule qui encapsule l'ensemble des éléments nécessaires à l'exécution d'une application. Cette image contient le système de fichiers complet, incluant le code source, les bibliothèques système, les dépendances, les variables d'environnement et les métadonnées de configuration.\n\nL'architecture en couches des images Docker représente l'une des innovations les plus importantes de cette technologie. Chaque instruction dans un Dockerfile crée une nouvelle couche et Docker utilise un système de cache intelligent pour réutiliser les couches communes entre différentes images. Cette approche optimise considérablement l'espace de stockage et accélère les processus de construction et de téléchargement.\n\nLes images sont identifiées par des tags qui combinent un nom et une version (comme `nginx:latest`, `ubuntu:20.04` ou `node:18-alpine`). Ces tags permettent aux équipes de développement de spécifier précisément quelle version d'une image utiliser dans leurs déploiements.\n\n### Dockerfile : automatiser la construction\n\nLe **Dockerfile** représente bien plus qu'un simple script d'instructions : il constitue la recette complète pour reproduire fidèlement un environnement d'exécution. Ce fichier texte utilise une syntaxe déclarative simple pour définir chaque étape de la construction d'une image.\n\nUn Dockerfile typique commence par spécifier une image de base (instruction FROM), puis enchaîne les opérations : installation de dépendances (`RUN`), copie de fichiers (`COPY` ou `ADD`), configuration d'environnement (`ENV`), exposition de ports (`EXPOSE`), et définition de la commande par défaut (`CMD` ou `ENTRYPOINT`).\n\nCette approche Infrastructure as Code garantit la reproductibilité parfaite des environnements et s'inscrit parfaitement dans les pratiques [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") actuelles. En documentant explicitement toutes les étapes de configuration dans un fichier versionable, le Dockerfile facilite la collaboration entre les équipes de développement et les opérateurs.\n\n### Docker Registry : partager et distribuer\n\nLes registres Docker fonctionnent comme des dépôts centralisés qui permettent de stocker, versioner et distribuer des images Docker de manière sécurisée. Ils constituent l'épine dorsale de l'écosystème Docker en facilitant la collaboration et le partage d'images.\n\n**[Docker Hub](https://www.docker.com/products/docker-hub/)** demeure le registre public officiel, hébergeant des millions d'images communautaires et officielles. Les équipes de développement peuvent y trouver des images prêtes à l'emploi : bases de données, serveurs web, etc. \n\nLes entreprises peuvent également déposer leurs images dans des **registres privés** garantissant la sécurité et le contrôle des accès. Ces registres privés peuvent être auto hébergés (on-premise) ou dans le cloud.\n\n## Pourquoi utiliser Docker ?\n\nLe développement d'applications fait face à des défis croissants : multiplication des environnements de déploiement, diversité des technologies utilisées, cycles de livraison accélérés et exigences de fiabilité toujours plus élevées. Les équipes de développement jonglent quotidiennement avec des problématiques complexes qui ralentissent leur productivité et augmentent les risques d'erreur.\n\nEn ce sens, Docker répond directement ou indirectement à ces problématiques récurrentes dans le développement logiciel.\n\n**Uniformisation des environnements** : Docker élimine le fameux « ça marche sur ma machine » en garantissant que l'application s'exécute de manière identique sur tous les environnements, du poste de développement à la production.\n\n**Simplification des déploiements** : l'empaquetage de l'application et de ses dépendances dans un conteneur unique simplifie considérablement les processus de déploiement et réduit les risques d'erreur.\n\n**Isolation des applications** : chaque conteneur dispose de son propre espace d'exécution, évitant les conflits entre différentes versions de bibliothèques ou de dépendances.\n\n**Accélération du développement** : les équipes de développement peuvent rapidement lancer des environnements complexes sans configuration manuelle fastidieuse.\n\n**Optimisation des ressources informatiques** : Docker permet une utilisation plus efficace des ressources serveur comparé aux machines virtuelles traditionnelles. Plusieurs conteneurs peuvent partager le même noyau système tout en maintenant leur isolation, réduisant ainsi l'empreinte mémoire et CPU. \n\nCette efficacité se traduit par :\n\n* Des temps de démarrage considérablement réduits\n* Une densité d'applications plus élevée par serveur\n* Une consommation énergétique optimisée\n* Des coûts d'infrastructure réduits\n\n## Quels sont les avantages de Docker ?\n\nMaintenant que nous avons vu pourquoi Docker est si populaire, intéressons-nous davantage aux avantages qu'il apporte concrètement aux équipes de développement. \n\n### Portabilité et cohérence\n\nDocker garantit que les applications fonctionnent de manière identique quel que soit l'environnement d'exécution. Cette portabilité facilite :\n\n* La migration d'applications entre différents fournisseurs cloud\n* Le déploiement sur des architectures hybrides (on-premise et cloud)\n* La création d'environnements de test fidèles à la production\n* La distribution d'applications complexes\n\n### Scalabilité et performance\n\nLes conteneurs Docker offrent une flexibilité exceptionnelle pour adapter les ressources aux besoins applicatifs :\n\n* **Montée en charge horizontale** : ajout rapide de nouvelles instances de conteneurs selon la demande\n* **Optimisation des ressources** : allocation précise des ressources CPU et mémoire par conteneur\n* **Démarrage instantané** : les conteneurs se lancent en quelques secondes contre plusieurs minutes pour les machines virtuelles\n* **Efficacité réseau** : gestion sophistiquée des réseaux virtuels entre conteneurs\n\n### Facilitation du DevOps\n\nDocker s'intègre naturellement dans les pratiques DevOps en :\n\n* Automatisant les processus de compilation et de déploiement\n* Facilitant l'intégration et le déploiement continus ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"))\n* Permettant des tests reproductibles dans des environnements isolés\n* Accélérant les cycles de développement et de livraison\n\n### Écosystème et communauté\n\nL'écosystème Docker bénéficie d'une communauté active qui développe :\n\n* Des milliers d'images officielles et communautaires sur Docker Hub\n* Des outils d'orchestration de conteneurs comme Docker Swarm (natif à Docker) et Kubernetes\n* Des solutions de monitoring et de logging adaptées aux conteneurs\n* Des intégrations avec les principales plateformes cloud\n\n## Quelles sont les limites de Docker ?\n\nComme nous venons de le voir, Docker présente de nombreux avantages, mais aussi certains inconvénients, dont il convient de prendre connaissance avec de plonger dans l’écosystème Docker.\n\n### Limitation à un seul système d'exploitation\n\nDocker crée plusieurs conteneurs sur un seul système d'exploitation. Si cette approche offre des avantages en termes de vitesse de démarrage et de traitement, elle peut également présenter des inconvénients. Par exemple, si vous souhaitez tester votre application dans un environnement Windows alors que votre machine hôte fonctionne sous Linux, vous devrez préparer une machine ou une machine virtuelle séparée.\n\n### Surcharge lors du développement à grande échelle\n\nDocker est léger en lui-même, mais lorsqu'il est étendu à un système de grande envergure, la charge de gestion de Docker entre en jeu. Docker peut faire fonctionner de nombreux conteneurs sur un seul serveur, mais d'un autre côté, cela nécessite une gestion et une orchestration qui peuvent générer une surcharge. Il peut également devenir difficile de tout gérer en utilisant Docker seul sans recourir à des outils d’orchestration comme Docker Swarm ou encore [Kubernetes](https://about.gitlab.com/fr-fr/blog/2024/07/25/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\").\n\n### Courbe d'apprentissage exigeante\n\nDocker utilise une méthode différente pour créer des environnements virtuels par rapport aux autres machines virtuelles. Cela signifie que les équipes de développement doivent apprendre et appréhender tous ces nouveaux concepts. Utiliser Docker sans bien comprendre son fonctionnement peut entraîner des problèmes par la suite. Il est important d'étudier Docker de manière approfondie avant de commencer à l'utiliser.\n\n### Vulnérabilités de sécurité potentielles\n\nDocker utilise une architecture basée sur les conteneurs. Comme plusieurs conteneurs fonctionnent sur une seule machine, il faut faire attention aux vulnérabilités qui peuvent en découler. Par exemple, s'il y a une vulnérabilité dans un conteneur, elle pourrait affecter tous les autres conteneurs qui partagent les ressources du système d'exploitation hôte et le noyau.\n\n### Difficultés dans la coopération entre conteneurs\n\nLorsque vous envisagez l'intégration entre plusieurs conteneurs, diverses configurations peuvent être difficiles, ce qui peut conduire à des problèmes opérationnels. Par exemple, si vous créez une application et une base de données dans des conteneurs séparés et souhaitez les faire fonctionner ensemble, vous devez configurer les paramètres de communication au sein du même hôte. L'ouverture de ports et de sockets pose des risques de sécurité. Si vous rendez les paramètres trop compliqués pour éviter cela, vous risquez alors de rencontrer des problèmes en production. Lors de l'intégration de conteneurs, il est important de bien réfléchir dès la phase de conception.\n\n### Comment GitLab résout les défis de Docker ?\n\nGitLab transforme Docker d'un simple outil de conteneurisation en une solution DevSecOps complète et sécurisée. Cette plateforme intégrée résout les principaux défis auxquels font face les organisations utilisant Docker à grande échelle.\n\nL'approche \"shift-left\" de GitLab intègre les contrôles de sécurité directement dans le pipeline de développement. Plutôt que de traiter la sécurité comme une étape finale, GitLab analyse automatiquement les images Docker dès leur construction, détectant les vulnérabilités, les configurations dangereuses et les dépendances obsolètes avant le déploiement. Cette détection précoce réduit considérablement les coûts de remédiation et élimine les risques de sécurité en production.\n\nGitLab Runner et ses pipelines CI/CD transforment la gestion des conteneurs Docker en automatisant l'ensemble du cycle de vie DevSecOps. Cette infrastructure d'exécution permet la construction automatisée d'images Docker optimisées, la validation automatique de la sécurité et des performances et l'orchestration sécurisée vers différents environnements.\n\n## Le rôle de Docker dans l’approche DevSecOps de GitLab\n\nDocker joue également un rôle très important dans l'intégration DevSecOps avec GitLab.\n\n### Conteneurisation des jobs CI/CD\n\nGitLab CI/CD vous permet d'utiliser des conteneurs Docker dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), vous apportant :\n\n* **Cohérence** : les jobs CI/CD s'exécutent dans des conteneurs, éliminant les erreurs dues aux différences de dépendances et d'environnements\n* **Scalabilité** : les conteneurs sont légers, rapides à démarrer et efficaces pour exécuter de larges pipelines\n* **Flexibilité d'environnement** : vous pouvez spécifier différentes images Docker pour chaque job, facilitant la mise à disposition de l'environnement requis\n\nL'image Docker GitLab Runner est basée sur Ubuntu ou Alpine Linux et inclut les commandes standard `gitlab-runner` qui la font fonctionner comme si vous aviez installé GitLab Runner directement sur l'hôte.\n\n### Scanning de sécurité automatisé\n\nLa sécurité est un composant clé de l’approche DevSecOps. GitLab la prend en charge dans les applications conteneurisées avec Docker à l’aide des scannings suivants : \n\n* **Scanning de sécurité des images de conteneurs** : fournit la capacité de scanner les images Docker dans vos pipelines CI/CD, vérifiant les vulnérabilités des packages OS afin d'évaluer la sûreté des images avant qu’elles n’atteignent l’environnement de production \n* **[Scanning en continue des vulnérabilités de conteneurs](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)** : recherche les failles de sécurité dans les dépendances existantes des applications en se basant sur leur SBOM et en comparant les noms et les versions des composants aux informations contenues dans les derniers avis de sécurité.\n* **[Scanning opérationnel de conteneurs](https://about.gitlab.com/blog/improve-security-auditing-with-gitlab-operational-container-scanning/)** : exécute les analyses de vulnérabilités sur les conteneurs déployés dans un environnement Kubernetes. Cela comprend l'analyse régulière des images à la recherche de nouvelles vulnérabilités découvertes et le suivi des environnements dans lesquels ces vulnérabilités sont déployées.\n\n### Infrastructure as Code (IaC) et gestion d'environnement\n\n* **Reproductibilité** : l’utilisation de Docker dans les jobs GitLab CI/CD assure la cohérence entre les environnements de développement et de production.\n* **Création instantanée d'environnements de staging et de test** : en s'intégrant avec Docker Compose et Kubernetes, GitLab vous permet de créer des environnements isolés pour des branches spécifiques ou des merge requests, permettant des tests efficaces et un scanning de sécurité.\n\n### Déploiement rationalisé\n\nGitLab supporte les modèles de déploiement suivants avec Docker :\n\n* **Compilation et push d'images Docker** : construisez votre application sous forme d’image de conteneur et effectuez un push vers le registre de conteneurs de GitLab ou d'autres registres Docker.\n* **[Livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ?\")** : utilisez des images Docker et déployez vers des outils d'orchestration de conteneurs pour des releases rapides et sécurisées.\n\n### Prise en charge de l'architecture de microservices\n\nGitLab et Docker ensemble facilitent la construction d'[architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\"), où les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ?\") s'exécutent comme des conteneurs Docker séparés. \n\nAvec les pipelines GitLab CI/CD, vous pouvez gérer :\n\n* La configuration des dépendances entre services\n* Les scans de sécurité individuels\n* Le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") (facilite les retours à une version précédente)\n\n## Conclusion\n\nDocker a transformé le paysage du développement logiciel en démocratisant la conteneurisation et en simplifiant la gestion des environnements d'exécution. Sa capacité à créer des applications portables, légères et facilement déployables en fait aujourd’hui un outil incontournable pour les équipes de développement.\n\nL'intégration native avec GitLab renforce encore davantage sa valeur en proposant une plateforme DevSecOps complète. Cette synergie permet aux entreprises d'accélérer leurs cycles de développement logiciel tout en maintenant des standards élevés de sécurité et de qualité.\n\nPour les équipes souhaitant moderniser leurs pratiques de développement, l'adoption de Docker représente un investissement stratégique qui se traduit par une productivité accrue, des déploiements plus fiables, une meilleure évolutivité et un environnement flexible.\n\n> Vous souhaitez installer GitLab dans un conteneur Docker ? Consultez notre [documentation](https://docs.gitlab.com/install/docker/) pour en savoir plus. \n\n## FAQ sur Docker\n\n### Que peut-on faire avec Docker ?\n\nDocker est une technologie de virtualisation légère et autonome qui empaquette le code d'application, ses dépendances et ses bibliothèques. Docker vous permet de créer plusieurs conteneurs (environnements virtuels) sur une seule machine, vous permettant d'unifier vos environnements de développement et de test. \n\n### À quoi sert Docker ?\n\nDocker est utilisé par les équipes de développement pour découpler les applications et leurs dépendances du reste du système. Les conteneurs regroupent les applications et leurs dépendances ensemble et fournissent un environnement d'exécution léger.\n\n### Docker peut-il remplacer les machines virtuelles ?\n\nDocker ne remplace pas complètement les machines virtuelles, mais offre une alternative plus légère pour de nombreux cas d'usage. Les conteneurs partagent le noyau du système hôte, tandis que les machines virtuelles émulent un système complet. Le choix dépend de vos besoins en isolation, performance et compatibilité système.\n\n*Note : certaines parties de cet article proviennent de l'article japonais [Dockerとは：超入門編](https://about.gitlab.com/ja-jp/blog/what-is-docker/).*",[707,89],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1760102032/qsxbap3mitapwa5tko76.jpg",{"featured":653,"template":795,"slug":1091},"what-is-docker-comprehensive-guide",{"category":71,"slug":757,"posts":1093},[1094,1105,1118],{"content":1095,"config":1103},{"title":1096,"description":1097,"authors":1098,"heroImage":846,"body":1100,"date":1101,"category":757,"tags":1102},"Réduction des goulots d'étranglement CI/CD avec GitLab","Découvrez comment les indicateurs de performance des jobs CI/CD et le registre virtuel de conteneurs, actuellement disponible en version bêta, aident les équipes plateforme à identifier rapidement les jobs lents et à simplifier les extractions de conteneurs multi-registres.",[1099],"Talia Armato-Helle","Les ingénieurs plateforme et [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") passent trop de temps à rassembler les informations dispersées entre différents outils fragmentés et à gérer une infrastructure qui devrait simplement fonctionner. \n\nDeux nouvelles fonctionnalités GitLab, disponibles actuellement en version bêta, abordent ce problème sous différents angles mais partagent le même objectif : donner aux praticiens un contrôle direct sur l'infrastructure [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") dont ils dépendent, sans ajouter un nouvel outil tiers. L'une affiche les données de performance au niveau des jobs directement à l'endroit où vous surveillez les pipelines. L'autre simplifie la façon dont vous extrayez les images de conteneurs à partir de plusieurs registres avec une mise en cache intégrée.\n\nCes deux fonctionnalités sont désormais ouvertes aux retours. Vos commentaires nous aideront à façonner les prochaines versions.\n\n## Indicateurs de performance des jobs CI/CD\n\n* **Niveaux disponibles :** GitLab Premium, GitLab Ultimate\n* **Statut :** Version bêta à disponibilité limitée sur GitLab.com ; disponible sur GitLab Self-Managed et GitLab Dedicated lorsque ClickHouse est configuré\n\nÀ l'heure actuelle, il n'existe aucun moyen simple de savoir quand la durée d'un job commence à augmenter ou quels jobs ralentissent l'exécution de votre pipeline. La plupart des équipes construisent des tableaux de bord personnalisés ou examinent manuellement les logs pour répondre à des questions basiques telles que :\n\n* Quels jobs sont les plus lents ?\n* Où les taux d'échec augmentent-ils ?\n* Quelle étape constitue le véritable goulot d'étranglement ?\n\nLes indicateurs de performance des jobs CI/CD changent cela en ajoutant un nouveau panneau axé sur les jobs à la page d'analyse CI/CD au niveau du projet.\n\nPour chaque job, vous pouvez voir :\n\n* La durée typique (P50, médiane) et la durée dans le pire des cas (P95) du job, pour que vous puissiez rapidement comparer les exécutions normales et les exécutions les plus lentes\n* Le taux d'échec, pour que vous puissiez identifier les jobs fragiles ou instables\n* Le nom et l’étape du job, couvrant par défaut les 30 derniers jours\n\nLe tableau est triable, consultable par nom de job et paginé, ce qui permet aux équipes de plateforme d'obtenir une vue unique pour répondre aux questions qui nécessitaient auparavant des outils distincts ou des rapports personnalisés.\n\n**Essayez cette fonctionnalité**\n\n* Accédez à votre projet et sélectionnez **Analyse \\> Données d'analyse CI/CD**.\n* Recherchez le panneau des indicateurs de performance des jobs CI/CD et triez-les par durée ou par taux d'échec pour trouver vos jobs les plus lents ou les moins fiables.\n\n**Documentation**\n\n* [Analyses CI/CD – Indicateurs de performance des jobs CI/CD](https://docs.gitlab.com/user/analytics/ci_cd_analytics/#cicd-job-performance-metrics)\n\n**À venir**\n\nNous travaillons actuellement sur le regroupement par étape pour que vous puissiez consulter les indicateurs agrégés dans vos étapes de build, de test et de déploiement, et comprendre rapidement où concentrer vos efforts d'optimisation.\n\n**Partagez vos retours :**\n\n* [Epic des indicateurs de performance des jobs CI/CD](https://gitlab.com/groups/gitlab-org/-/work_items/18548)\n\n## Registre virtuel de conteneurs\n\n**Niveau :** GitLab Premium, GitLab Ultimate\n**Statut :** Version bêta, compatible API dans la version 18.9\n\nLa plupart des organisations qui intègrent des images de conteneurs dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") s'appuient sur plusieurs registres : Docker Hub, Harbor, Quay et les registres internes, pour n'en citer que quelques-uns. Gérer l'authentification, la disponibilité et la mise en cache sur l'ensemble de ces registres représente une charge opérationnelle qui ralentit les pipelines et introduit une certaine fragilité.\n\nLe registre virtuel de conteneurs vous permet de créer un point de terminaison GitLab unique qui extrait des données de plusieurs sources de conteneurs en amont avec une mise en cache intégrée.\n\nAu lieu de configurer les identifiants et la disponibilité pour chaque registre dans votre configuration de pipeline, vous pouvez :\n\n* Diriger vos pipelines vers un point de terminaison de registre virtuel GitLab\n* Configurer plusieurs registres en amont (Docker Hub, Harbor, Quay et autres utilisant l'authentification par jeton à longue durée de vie)\n* Laisser GitLab résoudre automatiquement les extractions d'images, avec une mise en cache pull-through pour réduire les coûts de bande passante et améliorer la fiabilité\n\nPour les équipes qui évaluent GitLab comme remplacement de registre de conteneurs, cela comble une lacune critique en matière de capacités. Pour les équipes qui gèrent déjà des worflows de conteneurs multi-registres, cela centralise la gestion des images dans GitLab et réduit les extractions répétées.\n\n**Ce que la version bêta prend en charge aujourd'hui**\n\n* Registres en amont qui utilisent l'authentification par jeton à longue durée de vie : Docker Hub, Harbor, Quay et autres registres compatibles\n* Mise en cache pull-through pour que les images couramment utilisées soient fournies par GitLab après le premier pull\n* Configuration API-first, avec gestion de l'interface utilisateur en cours++\n\nLes registres de fournisseurs cloud qui nécessitent une authentification IAM (tels que Amazon Elastic Container Registry, Google Artifact Registry et Azure Container Registry) sont à l'étude pour de futures itérations.\n\n**Essayez cette fonctionnalité**\n\n* Le registre virtuel de conteneurs est compatible API dans la version 18.9.\n* SaaS (GitLab.com) : demandez l'accès via votre CSM ou en commentant le ticket ci-dessous pour que le feature flag soit activé pour votre groupe.\n* GitLab Self-managed : activez le feature flag et configurez le registre virtuel à l'aide de l'API.\n\n**Documentation**\n\n* [API du registre virtuel de conteneurs](https://docs.gitlab.com/api/container_virtual_registries/)\n* [Extraire des images de conteneurs à partir du registre virtuel](https://docs.gitlab.com/user/packages/virtual_registry/container/#pull-container-images-from-the-virtual-registry)\n\n\n Regardez cette démonstration du registre virtuel de conteneurs disponible en version bêta :\n   \n\n  \u003Ciframe src=\"https://player.vimeo.com/video/1167512082?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"20260223_Container Virtual Registry Beta_V1\">\u003C/iframe>\u003C\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n  \u003Cbr>\u003C/br>\n\n\n\n**Partagez vos retours :**\n\n* [Ticket lié aux retours sur le registre virtuel de conteneurs](https://gitlab.com/gitlab-org/gitlab/-/issues/589630)\n\n## Aidez-nous à construire GitLab\n\nTous les membres de la communauté GitLab sont des contributeurs. Nous avons développé ces versions bêta en fonction des demandes de la communauté.\n\n* **Les indicateurs de performance des jobs CI/CD** ont été proposés par des équipes qui n'avaient aucun moyen facile de voir quand les temps de build commençaient à évoluer dans la mauvaise direction, ou quels jobs nuisaient à la fiabilité du pipeline.\n* **Le registre virtuel de conteneurs** a été proposé par des entreprises clientes qui géraient plusieurs registres et cherchaient à réduire la prolifération d'outils et les coûts de bande passante tout en évaluant GitLab comme registre central.\n\nVos retours façonnent ce que nous créons. Essayez ces versions bêta et partagez votre expérience dans les tickets mentionnés dans cet article.\n\nCet article le premier d'une série de versions bêta Core DevOps que nous prévoyons de mettre en avant. D'autres suivront tout au long de l'année, et nous espérons que vous nous aiderez à les rendre aussi utiles que possible.\n","2026-03-02",[89,757,790],{"featured":13,"template":795,"slug":1104},"new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks",{"content":1106,"config":1116},{"title":1107,"description":1108,"authors":1109,"date":1111,"body":1112,"heroImage":1113,"category":757,"tags":1114},"GitLab garantit une disponibilité de 99,9 % avec des crédits de service pour les clients Ultimate","Les clients GitLab Ultimate bénéficient désormais de crédits de service lorsque la disponibilité de la plateforme passe sous le seuil de 99,9 %, garantissant la fiabilité des workflows DevSecOps critiques.",[792,1110],"Lyle Kozloff","2026-02-18","GitLab garantit désormais son engagement en matière de disponibilité de 99,9 % avec des crédits de service destinés aux clients GitLab Ultimate sur GitLab.com et [GitLab Dedicated](https://about.gitlab.com/dedicated/). Lorsque la disponibilité mensuelle est inférieure à ce seuil, les clients éligibles reçoivent des crédits à appliquer sur leurs prochaines factures. Cet engagement assure à vos workflows DevSecOps la fiabilité dont ils ont besoin.\n\n## Votre confiance, notre priorité\n\nLa livraison logicielle moderne évolue à un rythme soutenu : les équipes effectuent des push de code, ouvrent des merge requests et suivent les tickets en continu tout au long de la journée. Les opérations [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") (push, pull, clone) se produisent des milliers de fois par heure au sein d’équipes distribuées. Lorsque l'une de ces actions essentielles devient indisponible, l'ensemble de votre workflow de livraison de logiciels est impacté.\n\nL'accord de niveau de service (SLA) garantissant une disponibilité de 99,9 % vous assure que votre rythme de développement accéléré ne se heurte pas à des obstacles liés à l’infrastructure. Les crédits de service témoignent de notre responsabilité. Ils lient notre réussite à la fiabilité de la plateforme et alignent nos intérêts sur les vôtres. Nous nous tenons responsables de vos résultats commerciaux, et pas seulement des objectifs de disponibilité.\n\nL'engagement SLA de GitLab couvre les services de base de la plateforme essentiels à vos workflows DevSecOps.\n\nAu lancement, les expériences couvertes sont les suivantes :\n\n* Tickets et merge requests\n* Opérations Git (push, pull, clone via HTTPS et SSH)\n* Opérations du registre de conteneurs\n* Opérations du registre de paquets\n* Requêtes API (limitées aux éléments ci-dessus)\n\nLa liste actualisée des expériences couvertes et exclues est disponible dans le [manuel de GitLab](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#covered-experiences).\n\nLa disponibilité du service est mesurée à l'aide d'une surveillance automatisée couvrant plusieurs zones géographiques, offrant une représentation précise de la disponibilité réelle du service telle qu’elle est expérimentée par les clients. Lorsque la disponibilité passe sous le seuil de 99,9 %, les clients sont éligibles à des crédits proportionnels à la durée et à la sévérité de l’indisponibilité.\n\n## Comprendre les minutes d'indisponibilité\n\nLorsque le service de GitLab enregistre une disponibilité dégradée affectant 5 % ou plus des requêtes clients valides pour les expériences couvertes au cours d'une minute donnée, entraînant des erreurs serveur, cette période est appelée une [minute d'indisponibilité](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#downtime-minute-definition). Les erreurs serveur sont définies comme des codes de statut HTTP 5xx ou des délais d'expiration de connexion dépassant 30 secondes, tels que déterminés par les systèmes de surveillance internes et externes de GitLab.\n\nLe SLA mesure les défaillances côté serveur, mais certains problèmes peuvent ne pas générer d'erreurs 5xx, comme les bogues applicatifs qui rendent des fonctionnalités inutilisables, les interruptions du traitement des jobs Sidekiq ou les problèmes d'infrastructure qui dégradent les performances sans provoquer des échecs de requêtes.\n\nVoici comment réclamer des crédits de service lorsque les conditions requises sont remplies :\n\n1. Soumettez une demande d'assistance sur support.gitlab.com dans les trente (30) jours suivant la fin du mois affecté.\n\n2. L'équipe de GitLab examine la demande, valide l'indisponibilité et traite le crédit le cas échéant.\n\n3. Les crédits de service seront appliqués sur votre prochaine facture émise.\n\n[Consultez notre manuel](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#calculating-monthly-uptime-percentage) pour en savoir plus sur le calcul de la disponibilité mensuelle, les crédits de service offerts le cas échéant et les procédures de réclamation de crédits.\n\nBien que notre système de surveillance soit conçu pour détecter la grande majorité des interruptions de service, si votre expérience ne correspond pas à la disponibilité rapportée, nous vous encourageons à soumettre une demande de crédit de service. GitLab examinera la demande dans sa globalité, y compris les problèmes susceptibles de ne pas être reflétés dans la surveillance automatisée.\n\n## Une fiabilité sur laquelle vous pouvez compter\n\nLe SLA à 99,9 % assorti de crédits de service traduit notre engagement à être une base fiable pour vos workflows de livraison logicielle. Vos équipes comptent sur GitLab pour continuer à livrer des logiciels, et nous sommes là pour vous soutenir.\n\nDes questions sur le SLA ? Contactez votre chargé de compte GitLab ou soumettez une demande via le [support de GitLab](http://support.GitLab.com).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812952/yxhgljkwljld0lyizmaz.png",[1115,757,707],"performance",{"featured":13,"template":795,"slug":1117},"gitlab-backs-99-9-availability-with-service-credits-for-ultimate-customers",{"content":1119,"config":1127},{"title":1120,"description":1121,"authors":1122,"heroImage":1123,"date":1124,"body":1125,"category":757,"tags":1126},"GitLab Credits : la tarification à l'usage pour GitLab Duo Agent Platform","Découvrez comment GitLab Credits permet de réduire les coûts et offre une flexibilité relative à l'utilisation de l'IA agentique dans le cycle de développement logiciel en entreprise.",[956],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1768314648/gvy4pfqjaeahkoagsjmr.png","2026-01-15","Nous avons créé GitLab Credits car la tarification par siège n’avait pas de sens pour l'IA agentique.\n\nLa tarification par siège crée une fracture entre les équipes d'ingénierie qui ont accès à l'IA et celles qui n'y ont pas accès, ce qui est en totale contradiction avec la manière dont l'IA agentique moderne devrait être utilisée tout au long du cycle de développement logiciel. \n\nAujourd'hui, vous devez acheter un siège pour chaque personne avant qu'elle ne puisse commencer à utiliser l'IA. Bien que cette tarification fonctionne pour les quelques utilisateurs intensifs, elle peut s'avérer trop coûteuse et injuste pour la majorité de l'équipe dont l'utilisation est ponctuelle. C'est pourquoi dans de nombreuses organisations, seule une partie de l'équipe dispose d'un « siège IA ».\n\nPar ailleurs, [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-is-generally-available/) diffère de GitLab Duo Pro, de GitLab Duo Enterprise et des autres outils de développement d'IA sur le marché. Les agents et les flows agentiques peuvent être utilisés par votre équipe lorsque celle-ci a besoin d'une assistance IA et déclenchés par des événements [SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/) qui s'exécutent en arrière-plan. Avec GitLab Duo Agent Platform, l'IA agentique n'est plus uniquement liée aux sièges utilisateurs.\n\nGitLab Credits, notre nouvelle monnaie virtuelle pour la tarification à l'usage, permet de pallier ces différences d'utilisation, à commencer par GitLab Duo Agent Platform. Chaque membre de votre organisation avec un compte GitLab (Premium ou Ultimate) peut désormais utiliser les fonctionnalités d'IA agentique sans que vous ayez à payer pour un siège IA, que celles-ci soient utilisées directement ou configurées comme agents en arrière-plan. \n\n## Fonctionnement de GitLab Credits\n\nLes crédits sont mutualisés dans l'ensemble de votre organisation. GitLab Duo Agent Platform, y compris l'usage synchrone et asynchrone des agents et des flows agentiques, requiert des GitLab Credits.\n\nLes fonctionnalités suivantes consomment des GitLab Credits :\n\n* Les [agents de base](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/) tels que l'agent GitLab Duo Security Analyst,  l'agent GitLab Duo Planner et l'agent GitLab Duo Data Analyst  \n\n* Les [flows de base](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/) tels que le flow « revue de code », le flow flow « développeur » et le flow « correction de pipelines CI/CD »  \n\n* Les [agents externes](https://docs.gitlab.com/user/duo_agent_platform/agents/external/) tels qu'Anthropic Claude Code et OpenAI Codex  \n\n* Les agents et les flows personnalisés que vous créez et publiez dans votre [Catalogue d'IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/)  \n\n* [Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) dans l'interface de GitLab et dans l'[IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/).\n\n**Remarque :** les agents externes sont disponibles gratuitement dans la version 18.8 et ne consomment pas de GitLab Credits. Nous présenterons la tarification le mois prochain, lors de la sortie de la version GitLab 18.9. Les flow personnalisés sont actuellement en version bêta et ne consomment pas de GitLab Credits. \n\nLe nombre de crédits utilisés est basé sur le nombre de requêtes agentiques effectuées par les grands modèles de langage ([LLM](https://about.gitlab.com/fr-fr/blog/what-is-a-large-language-model-llm/)) (plus de détails [ici](https://docs.gitlab.com/subscriptions/gitlab_credits/#models)). À mesure que le nombre de LLM disponibles augmentera, nous les certifierons pour une utilisation avec GitLab Duo Agent Platform et les ajouterons à cette liste afin d'offrir aux utilisateurs une vision transparente de leur consommation.\n\nLe nombre total de crédits est calculé à la fin du mois en fonction de l'utilisation réelle. Ce modèle compense également automatiquement l'usage des utilisateurs intensifs par rapport à celui des utilisateurs occasionnels, afin de réduire ainsi efficacement le coût total de l'IA par personne (par rapport au paiement par siège pour chaque personne). \n\nPar souci de simplicité, chaque crédit a un prix catalogue **à la demande** de 1 $. Vous pouvez utiliser GitLab Duo Agent Platform sans aucun engagement, et l'utilisation est facturée mensuellement (à la fin de chaque mois). Pour les clients Enterprise qui souscrivent à des **engagements annuels**, nous proposons des remises sur volume pour les crédits mensuels. \n\nDans le cadre d'une promotion à durée limitée[*](#notes), tous les clients GitLab avec un abonnement GitLab Premium et GitLab Ultimate actif recevront automatiquement **12 $ et 24 $ de crédits inclus par utilisateur**, respectivement. Ces crédits seront renouvelés chaque mois jusqu'à la fin de la période promotionnelle et permettront à votre équipe d'accéder à toutes les fonctionnalités de GitLab Duo Agent Platform sans frais supplémentaires. Lorsque vous acceptez nos conditions de facturation, toute utilisation supérieure à ces crédits inclus sera facturée via des crédits mensuels engagés ou des crédits à la demande.\n\n## Gouvernance des coûts avec GitLab Credits\n\n**Dimensionnement de GitLab Credits :** votre équipe commerciale dispose d'un calculateur de dimensionnement dans le cadre de la disponibilité générale de GitLab Duo Agent Platform, pour estimer le nombre de crédits dont vous aurez besoin chaque mois. Ce calculateur a été conçu avec des modèles d'utilisation que nous avons observés pendant la période bêta. De plus, en tant que client existant ou nouveau client, vous pouvez demander un essai gratuit pour confirmer votre utilisation réelle estimée. \n\n**Visibilité de l'utilisation :** avec la version 18.8, vous disposez d'informations détaillées sur l'utilisation via deux tableaux de bord complémentaires : un disponible dans le portail clients de GitLab pour les responsables de facturation à des fins de supervision financière, et l'autre intégré au produit pour les administrateurs à des fins de surveillance opérationnelle. Les deux fournissent une attribution de l'utilisation, des répartitions de coûts et des tendances historiques afin que vous sachiez toujours exactement comment vos crédits sont consommés. Si vous suivez une pratique de refacturation interne, vous pourrez utiliser les cumuls au niveau des projets et des groupes pour les allocations de coûts.  \n\n**Contrôles d'utilisation :** vous pouvez activer ou désactiver l'accès à GitLab Duo Agent Platform pour des équipes ou des projets spécifiques afin de garantir que seule l'utilisation approuvée peut être comptabilisée dans vos crédits. Nous prévoyons également d'ajouter des contrôles au niveau utilisateur peu après la disponibilité générale pour vous aider à gérer l'usage des fonctionnalités de GitLab Duo Agent Platform et des crédits.\n\n**Notifications automatiques d'utilisation :** nous vous tiendrons informé de manière proactive de votre utilisation des crédits via des alertes par e-mail lorsque vous atteindrez 50 %, 80 % et 100 % de vos crédits mensuels engagés, afin que vous ayez le temps d'ajuster votre utilisation, d'acheter des engagements supplémentaires ou de planifier la facturation à la demande.\n\n## Mise à niveau de la tarification par siège GitLab Duo Pro/GitLab Enterprise vers GitLab Credits pour GitLab Duo Agent Platform\n\nSi vous avez acheté et utilisez GitLab Duo Pro et GitLab Duo Enterprise, vous pouvez continuer à utiliser ces fonctionnalités comme options prises en charge. Vous pouvez passer à tout moment à GitLab Duo Agent Platform, afin d'utiliser la version « classique » de GitLab Duo, et accéder à de nouvelles fonctionnalités telles que l'Agentic Chat, des agents de base supplémentaires, des agents et des flows personnalisés, des agents externes et plus encore. \n\nAu moment de la mise à niveau, nous transférerons votre investissement dans les sièges de GitLab Duo Pro et GitLab Duo Enterprise vers GitLab Credits pour GitLab Duo Agent Platform. Le montant restant des engagements de sièges sera échangé contre des GitLab Credits mensuels avec des remises basées sur le volume. Les crédits mensuels pourront ensuite être partagés entre tous les membres de votre organisation que vous autorisez, et non plus seulement les utilisateurs qui disposaient de sièges GitLab Duo assignés auparavant. \n\n## Comparaison concurrentielle : GitLab Credits vs tarification par siège \n\n| Avantage | GitLab Credits | Tarification par siège |\n| ----- | ----- | ----- |\n| **L'IA pour tous** | Chaque membre d'équipe approuvé dispose d'un accès IA dès le premier jour | Crée des « nantis » et des « non-nantis » de l'IA, impose un rationnement des sièges |\n| **Aucun investissement initial**  | Commencez modestement avec les crédits inclus, augmentez l'engagement au fur et à mesure que le ROI devient clair | Vous devez acheter des sièges à l'avance avant de prouver leur valeur |\n| **Payez ce que vous utilisez** | Seul le travail d'IA réellement effectué au-delà du niveau inclus est facturé | Vous payez par siège quelle que soit l'utilisation réelle |\n| **Dépenses optimisées** | Le pool de crédits partagé vous permet d'équilibrer les utilisateurs intensifs avec les utilisateurs occasionnels | Vous devez payer pour les utilisateurs occasionnels et les dépassements pour les requêtes premium des utilisateurs intensifs |\n| **Visibilité détaillée** | Tableaux de bord d'utilisation avec attribution détaillée et tendances historiques | Aperçu limité des utilisateurs qui génèrent de la valeur |\n| **Contrôles de coûts granulaires** | Déterminez les utilisateurs, des alertes proactives et des contrôles budgétaires à venir pour limiter l'usage | Limitez qui obtient un siège pour contrôler les coûts |\n| **Flexibilité de dimensionnement**  | Calculateur pour estimer les crédits mensuels, avec plus de remises unitaires en volume | Comptez qui obtient un siège multiplié par le prix par siège |\n| **Contrats et facturation simplifiés** | Un seul SKU et une facture couvre toutes les fonctionnalités agentiques dans le cycle de vie DevSecOps | Plusieurs licences IA requises pour différents outils tiers |\n\n## Configuration\n\n1. **Pour les clients GitLab Premium et GitLab Ultimate existants** : avec la disponibilité générale, GitLab Duo Agent Platform sera disponible pour les clients disposant de licences GitLab Premium et GitLab Ultimate actives[**](#notes). Les clients GitLab.com SaaS y auront accès automatiquement. Les clients GitLab Self-Managed y auront accès lorsqu'ils passeront à la version GitLab 18.8 (avec la disponibilité générale prévue de GitLab Duo Agent Platform). Les clients [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/) seront mis à niveau vers GitLab 18.8 pendant leur fenêtre de maintenance programmée en février et pourront alors utiliser GitLab Duo Agent Platform.\n      \n2. **Activez GitLab Duo** : assurez-vous que GitLab Duo Agent Platform est activé dans les paramètres de votre espace de nommage.  \n\n3. **Commencez à explorer** : utilisez vos GitLab Credits mensuels inclus pour essayer les fonctionnalités de GitLab Duo Agent Platform.   \n\n4. **Au-delà des crédits inclus :** vous pourrez accepter GitLab Credits pour une utilisation étendue au-delà des crédits inclus au prix catalogue à la demande. Pour des remises sur volume avec engagement, veuillez [nous contacter](https://about.gitlab.com/fr-fr/sales/) pour obtenir un devis pour votre niveau d'utilisation spécifique. \n\nConsultez notre [documentation](https://docs.gitlab.com/user/duo_agent_platform/) pour en savoir plus sur la prise en main de GitLab Duo Agent Platform.\n\n## Remarques\n\n\\* Ces crédits promotionnels inclus sont disponibles pour une durée limitée lors de la disponibilité générale, et peuvent être modifiés à la discrétion de GitLab.\n\n** Exclut GitLab Duo avec Amazon Q et GitLab Dedicated pour les clients \ngouvernementaux.\n\n> Pour en savoir plus sur GitLab Duo Agent Platform et toutes les façons dont l'IA agentique peut transformer le travail de votre équipe, [consultez notre page GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/). Si vous êtes un client GitLab existant, contactez votre gestionnaire de compte GitLab ou votre partenaire pour planifier une démonstration de nos fonctionnalités de plateforme.\n\n## FAQ sur GitLab Credits\n\n**1\\. Qu'est-ce que GitLab Credits et pourquoi GitLab les a-t-il introduits ?**\n\nGitLab Credits est une nouvelle monnaie virtuelle pour les fonctionnalités GitLab basées sur l'utilisation, à commencer par GitLab Duo Agent Platform. GitLab a introduit ce modèle car la tarification par siège forçait les organisations à rationner l'accès à l'IA au sein des équipes d'ingénierie, et l'utilisation de GitLab Duo Agent Platform n'est pas uniquement liée aux sièges. Les crédits sont mutualisés dans l'ensemble de votre organisation, vous permettant de donner à chaque membre de l'équipe un accès aux fonctionnalités d'IA, ou de configurer des workflows agentiques en arrière-plan, sans nécessiter l'achat de sièges individuels à l'avance.\n\n**2\\. Comment fonctionne la consommation de crédits ?**\n\nLes crédits sont déduits en fonction du nombre de requêtes agentiques effectuées, avec des taux différents selon le LLM utilisé. Par exemple, vous obtenez deux requêtes de modèle par crédit pour Claude-sonnet-4.5 (le modèle par défaut pour la plupart des fonctionnalités), et 20 requêtes par crédit pour des modèles comme gpt-5-mini ou claude-3-haiku. \n\n**3\\. Qu'est-ce qui est inclus pour les clients GitLab Premium et GitLab Ultimate existants ?**\n\nDans le cadre d'une promotion à durée limitée, les clients disposant d'abonnements GitLab Premium et GitLab Ultimate actifs reçoivent automatiquement des crédits inclus gratuitement parallèlement à la version de disponibilité générale de GitLab Duo Agent Platform dans GitLab 18.8 : \n\n* 12 $ de crédits par utilisateur par mois pour GitLab Premium  \n\n* 24 $ de crédits par utilisateur par mois pour GitLab Ultimate\n\nLes crédits inclus sont au niveau utilisateur, se renouvellent mensuellement et permettent l'accès à toutes les fonctionnalités de GitLab Duo Agent Platform sans frais supplémentaires. Toute utilisation supplémentaire sera facturée séparément. Ces crédits promotionnels inclus sont disponibles pour une durée limitée après la disponibilité générale, et peuvent être modifiés  à la discrétion de GitLab.\n\n**4\\. Comment puis-je contrôler et surveiller l'utilisation des crédits ?**\n\nGitLab fournit plusieurs outils de gouvernance : tableaux de bord d'utilisation détaillés dans le portail clients et au sein du produit, possibilité d'activer et de désactiver l'accès pour des équipes ou des projets spécifiques, contrôles au niveau utilisateur à venir, et alertes e-mail automatisées à 50 %, 80 % et 100 % des crédits mensuels engagés. Nous prévoyons également de proposer un calculateur de dimensionnement pour estimer vos besoins mensuels en crédits.\n\n**5\\. Comment puis-je commencer à utiliser GitLab Duo Agent Platform ?**\n\nUne fois en disponibilité générale, pour les clients GitLab Premium et GitLab Ultimate existants, l'accès est automatique sur GitLab.com SaaS. Les clients Self-Managed obtiennent l'accès lors de la mise à niveau vers GitLab 18.8 avec la disponibilité générale prévue de GitLab Duo Agent Platform. Activez simplement GitLab Duo Agent Platform dans les paramètres de votre espace de nommage et commencez à explorer GitLab Duo Agent Platform en utilisant vos crédits mensuels inclus. Pour une utilisation au-delà des crédits inclus, vous pouvez accepter la facturation à la demande ou contacter GitLab pour des remises sur volume avec engagements annuels.\n\n*Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou des issues réels sensiblement différents. Des informations supplémentaires sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige.*",[788,757,731],{"featured":653,"template":795,"slug":1128},"introducing-gitlab-credits",{"category":105,"slug":769,"posts":1130},[1131,1143,1155],{"content":1132,"config":1141},{"title":1133,"description":1134,"authors":1135,"heroImage":846,"date":1138,"body":1139,"category":769,"tags":1140},"Mise à jour du tableau de bord de sécurité de GitLab : suivez la correction des vulnérabilités","Priorisez rapidement la correction de vos projets à risque et mesurez vos progrès à l'aide des informations relatives aux vulnérabilités.",[1136,1137],"Alisa Ho","Mike Clausen","2026-02-23","Les équipes de sécurité et de développement font face à la même frustration : des milliers de vulnérabilités demandent leur attention, mais elles manquent d'informations pour les aider à hiérarchiser les mesures correctives. Où se concentrent les risques et à quelle vitesse sont-ils corrigés ? Où les mesures correctives auront-elles le plus d'impact ? La mise à jour apportée au tableau de bord de sécurité de GitLab aide à répondre à ces questions avec le suivi des tendances, la répartition des vulnérabilités en fonction de leur ancienneté et la notation des risques par projet.\n\n## Mesurer la correction, pas seulement la détection\nLes équipes chargées de la sécurité des applications ne peinent pas à trouver des vulnérabilités. En revanche, elles peinent à les comprendre. La plupart des tableaux de bord affichent des décomptes bruts sans contexte, ce qui les force à passer des heures à mettre en œuvre des mesures correctives sans comprendre quelles vulnérabilités les exposent aux risques les plus importants.\n\n[Le tableau de bord de sécurité de GitLab](https://docs.gitlab.com/user/application_security/security_dashboard/#new-security-dashboards) regroupe toutes les données relatives aux vulnérabilités en une vue unique qui couvre l'ensemble des projets, groupes et unités commerciales.\n\nDans la version 18.6, nous avons introduit la première mise à jour du tableau de bord de sécurité, où les équipes pouvaient visualiser les vulnérabilités au fil du temps et les filtrer en fonction du type de projet ou de rapport. Dans le cadre de la [version 18.9](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/), les clients pourront profiter de nouveaux filtres et graphiques qui facilitent le découpage des données par gravité, statut, scanner ou projet et visualiser les tendances (vulnérabilités ouvertes, vitesse de correction, répartition des vulnérabilités en fonction de leur ancienneté et score de risque au fil du temps).\n\nLes scores de risque aident les équipes à prioriser la correction de leurs vulnérabilités les plus critiques. Le score de risque est calculé au moyen de facteurs tels que l'âge de la vulnérabilité, le système EPSS (Exploit Prediction Scoring System) et les scores KEV (Known Exploited Vulnerabilities) pour les dépôts associés et leurs postures de sécurité. Avec ces données, les équipes de sécurité des applications peuvent identifier les domaines à prioriser.\n\nLe tableau de bord de sécurité de GitLab aide les équipes chargées de la sécurité et du développement des applications à :\n* **Suivre l'efficacité des programmes** : surveiller la vitesse de correction, l'adoption des scanners et la posture de risque pour montrer une amélioration mesurable.\n* **Se concentrer sur les corrections ciblées** : corriger les vulnérabilités qui représentent le plus grand risque pour les systèmes de production.\n* **Identifier les domaines nécessitant une formation à la correction** : identifier les équipes qui ont des difficultés à corriger les vulnérabilités conformément à la politique de l'entreprise afin d'investir dans des formations supplémentaires.\n* **Réduire les rapports manuels** : éliminer le recours à des tableaux de bord et de feuilles de calcul externes en suivant tout depuis GitLab.\n\nCette mise à jour reflète l'engagement continu de GitLab en faveur de la sécurité mesurable, contextuelle et intégrée dans les workflows de développement quotidiens. Le tableau de bord de sécurité de GitLab transforme les résultats bruts en informations exploitables afin que les équipes de sécurité et de développement puissent fixer des priorités, réduire les risques plus rapidement et étayer leurs progrès.\n\n## Découvrez le tableau de bord de sécurité de GitLab en action\nImaginez un responsable en charge de la sécurité des applications qui se prépare pour une réunion avec sa direction. Il peut maintenant montrer si les investissements réalisés réduisent les risques à l'aide des points de tendance clairs : vulnérabilités ouvertes en baisse, ancienneté des vulnérabilités en baisse, types de failles CWE autrefois fréquentes en baisse, score de risque satisfaisant. Au lieu de présenter des informations bruts, il peut afficher la diminution du backlog et l'amélioration de la posture de risque d'un trimestre à l'autre.\n\nParallèlement, les équipes de développement peuvent accéder au même tableau de bord, où les vulnérabilités critiques sont mises en évidence dans leurs projets actifs, afin de concentrer leurs efforts de correction sans avoir à exporter de données ni à jongler entre plusieurs outils.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1166108924?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=\"Security-Dashboard-Demo-Final\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> Pour plus d’informations sur l'utilisation du tableau de bord de sécurité de GitLab, consultez notre [documentation](https://docs.gitlab.com/user/application_security/security_dashboard/).",[769,757,790],{"featured":653,"template":795,"slug":1142},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":1144,"config":1153},{"tags":1145,"category":769,"authors":1146,"heroImage":1148,"date":1149,"body":1150,"description":1151,"title":1152},[707,810,769,166],[1147],"Abubakar Siddiq Ango","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","2026-02-09","Des principes directeurs sous forme de normes ont toujours permis de garantir la livraison sécurisée et fiable de produits et services aux clients. Ces normes, généralement appliquées par des organismes légalement mandatés, réglementent les secteurs d'activité et empêchent la diffusion de produits de qualité inférieure.\n\nDans le secteur des technologies de l'information, le respect des normes va au-delà de la livraison du produit final ; il englobe l'ensemble du cycle de vie de la solution. Étant donné que tous les secteurs d'activité exploitent de plus en plus diverses formes de technologies afin d'accélérer les processus et d'améliorer l'efficacité, de vastes quantités de données souvent sensibles sont générées, stockées et transmises au moyen d'outils et de services informatiques. Le traitement inapproprié de ces données peut entraîner de graves conséquences et conduire à des pertes financières [de l'ordre de centaines de millions de dollars](https://tech.co/news/data-breaches-updated-list).\n\nCe guide complet présente des normes de conformité du monde entier et explique comment respecter les normes réglementaires avec la gestion des politiques de conformité et de sécurité de GitLab.\n## Normes de conformité informatiques courantes\n\nLes normes de conformité réglementaire prennent diverses formes et dépendent du secteur d'activité ou de la région dans laquelle une organisation opère. Nous examinerons d'abord les normes de conformité courantes, suivies des normes spécifiques à certaines régions et à certains secteurs.\n\n### RGPD\n\nLe [Règlement général sur la protection des données (RGPD)](https://gdpr-info.eu/) est une loi importante de l'Union européenne qui régit la protection des données personnelles. Mis en œuvre en 2018, le RGPD établit des directives strictes pour les organisations qui traitent les informations personnelles des résidents de l'UE. Il accorde aux individus un contrôle accru sur leurs données, notamment le droit d'accéder, de rectifier et d'effacer les informations personnelles détenues par les entreprises. Le RGPD exige que les organisations obtiennent un consentement explicite avant de collecter ou de traiter des données personnelles et qu'elles expliquent clairement l'objectif de la collecte de données. Le non-respect peut entraîner des sanctions financières importantes.\n\nBien qu'il s'agisse d'une réglementation de l'UE, le RGPD a des implications dans le monde entier et concerne toute organisation qui traite les données des résidents de l'UE. Cette législation a entraîné des changements généralisés dans les pratiques de traitement des données et a sensibilisé le monde entier aux questions de confidentialité.\n\n### NIST SSDF\n\nLe framework relatif au développement de logiciels sécurisés NIST, SSDF [(NIST Secure Software Development Framework, SSDF)](https://csrc.nist.gov/Projects/ssdf)  est un guide qui aide les organisations à créer des logiciels plus sûrs. Créé par le National Institute of Standards and Technology, ce framework propose [des pratiques de base pour le développement sécurisé de logiciels](https://about.gitlab.com/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/).\n\nLe SSDF se concentre sur quatre domaines principaux : préparer l'organisation, protéger le logiciel, créer des logiciels sécurisés et gérer les vulnérabilités. Il aide les entreprises à intégrer la sécurité, y compris les protocoles de sécurité, pendant le développement et tout au long de la chaîne d'approvisionnement logicielle.\n\nEn suivant ces directives, les organisations peuvent créer des logiciels avec moins de points faibles et gérer les problèmes plus efficacement. Le SSDF est flexible et peut fonctionner avec différentes méthodes de développement logiciel, il est donc utile pour de nombreuses organisations.\n\n### PCI DSS\n\nLa norme de sécurité de l’industrie des cartes de paiement [(Payment Card Industry Data Security Standard, PCI DSS)](https://www.pcisecuritystandards.org/lang/fr-fr/) représente un ensemble de règles de sécurité pour les organisations qui traitent des informations de cartes de crédit. Créée par les principales sociétés de cartes de crédit, elle vise à protéger les données des titulaires de cartes et à prévenir la fraude. La norme PCI DSS exige que les entreprises mettent en place et maintiennent un réseau sécurisé, protègent les données des titulaires de cartes, utilisent des mesures strictes de contrôle d'accès, surveillent et testent régulièrement les réseaux et maintiennent une politique de sécurité de l'information. Ces règles s'appliquent à toute entreprise qui accepte, traite, stocke ou transmet des données de cartes de crédit.\n\nLa conformité à la norme PCI DSS est obligatoire pour ces entreprises, quelle que soit leur taille ou leur volume de transactions. En suivant cette norme, les entreprises peuvent mieux protéger les informations financières sensibles, réduire le risque de violations de données et maintenir la confiance des clients. Des audits réguliers garantissent le respect continu de ces mesures de sécurité importantes.\n\n### ISO 27000\n\nLa norme [ISO/IEC 27000](https://www.iso.org/fr/standard/iso-iec-27000-family) fournit le cadre fondamental de la famille de normes ISO/IEC 27000 et offre un aperçu complet des systèmes de gestion de la sécurité de l'information. Elle établit un vocabulaire normalisé grâce à des termes et concepts clés qui garantissent une compréhension cohérente entre les organisations dans le domaine de la sécurité de l'information.\n\nLa norme décrit les composants et processus essentiels qui établissent et maintiennent des systèmes de gestion de la sécurité de l'information efficaces. Ces directives permettent aux organisations de gérer systématiquement les risques liés à la sécurité de l'information et protègent les données confidentielles ainsi que la propriété intellectuelle.\n\nL'adhésion à la norme ISO/IEC 27000 permet aux organisations de construire des systèmes de gestion de la sécurité de l'information robustes, de renforcer leur résilience face aux menaces liées à la cybersécurité, de protéger des informations précieuses et de favoriser la confiance des parties prenantes.\n\n> [Découvrez comment GitLab peut vous aider dans votre parcours de conformité à la norme ISO 27001.](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/)\n\n### HIPAA\n\nLa loi sur la portabilité et la responsabilité des assurances-maladie [(Health Insurance Portability and Accountability Act, HIPAA)](https://www.hhs.gov/hipaa/index.html) est une législation importante qui a un impact sur le secteur de la santé aux États-Unis. L'objectif principal de la loi HIPAA, adoptée en 1996, est de protéger les informations sensibles de santé des patients contre toute divulgation sans qu'ils n'y aient consenti ou n'en aient connaissance.\n\nIl est essentiel de préserver la confidentialité des patients, de garantir la sécurité des données et de normaliser les transactions électroniques des soins de santé. La loi HIPAA a contraint les prestataires de soins de santé, les assureurs et les entités connexes à mettre en œuvre des mesures strictes de protection des données afin de réduire considérablement l'accès non autorisé aux dossiers médicaux et de renforcer la confiance des patients.\n\n## Normes de conformité mondiales et régionales\n\n### Réglementations nationales/régionales\n\nBien que des normes de conformité comme la loi HIPAA et le RGPD soient connues dans le monde entier, il s'agit respectivement de normes américaines et européennes. Elles influencent d'autres normes régionales dans le monde, mais ne sont requises que pour les entreprises qui traitent des données provenant, par exemple, de l'UE. Plusieurs pays ont des normes de conformité qui doivent être respectées si une entreprise opère dans ces pays. Voici quelques autres normes spécifiques à certains pays :\n\n- [SOX](https://fr.wikipedia.org/wiki/Loi_Sarbanes-Oxley) (États-Unis, sociétés cotées) : Sarbanes-Oxley Act. Cette loi impose une tenue et une déclaration appropriées des documents comptables pour les sociétés cotées.\n\n- [LPRPDE](https://www.priv.gc.ca/fr/sujets-lies-a-la-protection-de-la-vie-privee/lois-sur-la-protection-des-renseignements-personnels-au-canada/la-loi-sur-la-protection-des-renseignements-personnels-et-les-documents-electroniques-lprpde/) (Canada, entreprises commerciales) : Loi sur la protection des renseignements personnels et les documents électroniques. Elle régit la manière dont les organisations du secteur privé collectent, utilisent et divulguent les informations personnelles.\n\n- [PDPA](https://www.pdpc.gov.sg/overview-of-pdpa/the-legislation/personal-data-protection-act) (Singapour, toutes les organisations) : Personal Data Protection Act. Cette loi sur la protection des données personnelles régit la collecte, l'utilisation et la divulgation de données personnelles par les organisations.\n\n- [APPI](https://www.ppc.go.jp/files/pdf/Act_on_the_Protection_of_Personal_Information.pdf) (Japon, tous les secteurs) : Act on the Protection of Personal Information. Cette loi sur la protection des informations personnelles réglemente l'utilisation d'informations personnelles au Japon.\n\n- [LGPD](https://lgpd-brazil.info/) (Brésil, tous les secteurs) : Lei Geral de Proteção de Dados. La loi brésilienne sur la protection des données est similaire au RGPD.\n\n- [FISMA](https://www.cisa.gov/topics/cyber-threats-and-advisories/federal-information-security-modernization-act) (États-Unis, agences fédérales) : Federal Information Security Management Act. Cette loi sur la gestion de la sécurité des informations fédérales définit un cadre pour la gestion de la sécurité de l'information des systèmes d'information fédéraux.\n\n- [POPI Act](https://popia.co.za/) (Afrique du Sud, tous les secteurs) : Protection of Personal Information Act. Cette loi sur la protection des données personnelles promeut la protection des informations personnelles traitées par des organismes publics et privés.\n\n- [PDPA](https://www.pwc.com/th/en/tax/personal-data-protection-act.html) (Thaïlande, tous les secteurs) : Personal Data Protection Act. Comme le RGPD, cette loi sur la protection des données personnelles réglemente la collecte, l'utilisation et la divulgation de données personnelles en Thaïlande.\n\n- [PIPL](https://en.wikipedia.org/wiki/Personal_Information_Protection_Law_of_the_People%27s_Republic_of_China) (Chine, tous les secteurs) : Personal Information Protection Law. La première loi complète sur la protection des données de la Chine est similaire au RGPD.\n\n- [NDPR](https://nitda.gov.ng/wp-content/uploads/2021/01/NDPR-Implementation-Framework.pdf) (Nigeria, tous les secteurs) : Nigeria Data Protection Regulation. Ce règlement sur la protection des données au Nigéria protège les droits des personnes physiques à la confidentialité des données.\n\n- [DIFC Data Protection Law](https://www.difc.ae/business/laws-and-regulations/legal-database/difc-laws/data-protection-law-difc-law-no-5-2020) (Dubaï, entreprises du Dubai International Financial Centre) : cette loi sur la protection des données du DIFC réglemente le traitement des données personnelles dans la zone franche du DIFC.\n\n- [PDPA](https://www.pdp.gov.my/jpdpv2/laws-of-malaysia-pdpa/personal-data-protection-act-2010/?lang=en) (Malaisie, transactions commerciales) : Personal Data Protection Act. Cette loi sur la protection des données personnelles réglemente le traitement des données personnelles dans les transactions commerciales.\n\n- [Privacy Act](https://www.ag.gov.au/rights-and-protections/privacy) (Australie, agences gouvernementales et certaines organisations du secteur privé). Cette loi relative à la confidentialité réglemente la manière dont les informations personnelles sont traitées par les agences gouvernementales australiennes et certaines organisations du secteur privé.\n\n- [KVKK](https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law) (Turquie, tous les secteurs) : Turkish Personal Data Protection Law. La loi sur la protection des données personnelles turque réglemente le traitement des données personnelles et protège les droits individuels.\n\nCes normes reflètent la préoccupation croissante concernant la confidentialité et la sécurité des données. De nombreux pays développent leurs propres frameworks inspirés de réglementations établies comme le RGPD. Chaque norme est adaptée au contexte juridique, culturel et économique spécifique de son pays.\n\n### Normes spécifiques aux secteurs\n\n- [PCI DSS](https://www.pcisecuritystandards.org/lang/fr-fr/) (services financiers) : cette norme s'applique à toutes les organisations qui traitent des informations de cartes de crédit dans le monde entier.\n\n- [ISO 27001](https://www.iso.org/fr/standard/iso-iec-27000-family) (tous les secteurs) : cette norme de système de gestion de la sécurité de l'information fournit un framework pour les pratiques de gestion de la sécurité de l'information.\n\n- [GAMP 5](https://qbdgroup.com/en/blog/gamp-categories/) (secteur pharmaceutique) : Good Automated Manufacturing Practice. Directives pour les systèmes informatiques dans la fabrication pharmaceutique.\n\n- [ISO 13485](https://www.iso.org/fr/standard/59752.html) (dispositifs médicaux) : cette norme précise les exigences d'un système de gestion de la qualité pour les fabricants de dispositifs médicaux.\n\n- [COBIT](https://www.isaca.org/resources/cobit) (gestion informatique) : Control Objectives for Information and Related Technologies. Framework pour la gestion informatique et la gouvernance informatique.\n\n- [ITIL](https://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library) (services informatiques) : Information Technology Infrastructure Library. Ensemble de pratiques détaillées pour la gestion des services informatiques.\n\n- [NIST CSF](https://www.nist.gov/cyberframework) (cybersécurité) : National Institute of Standards and Technology Cybersecurity Framework. Conseils pour gérer et réduire les risques liés à la cybersécurité.\n\n- [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/fr) (accessibilité Web) : Web Content Accessibility Guidelines. Ces directives dédiées à l’accessibilité des contenus Web visent à rendre le Web plus accessible aux personnes handicapées.\n\n- [Basel III](https://www.bis.org/bcbs/basel3_fr.htm) (secteur bancaire). Dispositif réglementaire international pour les banques, qui comprend des exigences de gestion des risques informatiques.\n\n- [TISAX](https://portal.enx.com/en-US/TISAX/) (secteur automobile) : Trusted Information Security Assessment Exchange. Mécanisme d'évaluation et d'échange de sécurité de l'information pour l'industrie automobile.\n\nCes normes s'appliquent dans le monde entier à des secteurs spécifiques, et garantissent des pratiques cohérentes et des mesures de sécurité dans leurs domaines respectifs.\n\n## Importance de la conformité continue\n\nLes organisations doivent mettre en œuvre des systèmes qui assurent la conformité aux exigences réglementaires pertinentes. Elles peuvent y parvenir grâce à [la conformité continue des logiciels](https://about.gitlab.com/fr-fr/solutions/compliance/), un principe essentiel à tous les secteurs qui garantit la surveillance, l'évaluation et l'ajustement continus des systèmes, processus et pratiques d'une organisation afin de garantir que ces derniers respectent à tout moment les normes et réglementations pertinentes.\n\nLa conformité continue n'est pas seulement une case à cocher en matière de réglementation, mais une nécessité stratégique pour le développement logiciel aujourd'hui. Elle permet aux organisations de naviguer de manière proactive face aux menaces émergentes, aux changements technologiques et aux évolutions réglementaires, tout en favorisant la confiance des parties prenantes, l'efficacité opérationnelle et l'avantage concurrentiel dans un environnement commercial de plus en plus complexe.\n\n## Conformité réglementaire ou normes auto-imposées ?\n\nLa conformité réglementaire et les normes auto-imposées sont deux approches distinctes de la gouvernance organisationnelle. La conformité réglementaire implique le respect de lois et de réglementations obligatoires établies par des autorités externes, qui ont une portée large et des conséquences juridiques potentielles en cas de non-respect. Elle se concentre sur le respect des exigences légales minimales et est généralement moins flexible. Le RGPD et la loi HIPAA en sont des exemples.\n\nEn revanche, les normes auto-imposées sont des directives volontaires adoptées par les organisations pour améliorer la qualité, la sécurité ou les performances. Elles peuvent être adaptées à des besoins spécifiques et visent généralement à dépasser les exigences minimales. Bien que le non-respect des normes auto-imposées puisse avoir un impact sur la réputation d'une organisation, il n'entraîne généralement pas de conséquences juridiques. Les principales différences résident dans leur origine, leur motivation, leur adaptabilité et leur portée. De nombreuses organisations mettent en œuvre les deux approches pour créer une stratégie complète de gestion de la qualité, de la sécurité et des performances.\n\n## Gestion de la conformité\n\nPour respecter des normes, les organisations doivent évaluer les [indicateurs de conformité](https://advisory.kpmg.us/articles/2018/compliance-metrics.html) appropriés et les intégrer dans leurs procédures opérationnelles standard. L'objectif est de fournir des informations permettant la détection et la prévention précoces des risques de conformité actuels et futurs. La gestion de la conformité doit être efficace et représente bien plus qu'une simple liste de contrôle avec des tâches à effectuer périodiquement ; il s'agit d'un processus continu complet à l'échelle de l'organisation.\n\n## Gestion de la conformité avec GitLab\n\nAvec GitLab, les organisations peuvent créer des [frameworks de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html), des [politiques de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/) et une [gestion des audits](https://docs.gitlab.com/ee/administration/audit_reports.html). GitLab permet également aux équipes de conformité ou de direction de surveiller les indicateurs de conformité avec les [rapports de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html).\n\n### Frameworks et pipelines de conformité\n\nLes organisations peuvent créer un [framework de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) qui identifie les projets dans GitLab avec des exigences de conformité définies, qui peuvent être appliquées au moyen de [pipelines de conformité](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html). Par exemple, une entreprise FinTech peut créer un [framework de conformité par défaut](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#default-compliance-frameworks) pour tous les projets afin de garantir que chaque étape de son cycle de développement logiciel respecte les exigences PCI DSS pour le traitement des données des titulaires de cartes.\n\nCes exigences sont ensuite appliquées en veillant à ce que chaque modification introduite dans le code source soit suffisamment testée automatiquement avec les [fonctionnalités de sécurité des applications](https://docs.gitlab.com/ee/user/application_security/) de GitLab, qui couvrent le code source, les dépendances, les licences, les vulnérabilités dans l'application en cours d'exécution et les configurations d'infrastructure. Vous pouvez en savoir plus sur la façon dont GitLab vous aide à atteindre la conformité PCI et d'autres [normes de conformité réglementaires](https://about.gitlab.com/fr-fr/solutions/continuous-software-compliance/) avec les frameworks de conformité.\n\nLes vidéos suivantes vous aident à configurer et à utiliser des frameworks et pipelines de conformité.\n\n**Tutoriel vidéo : créer des frameworks de conformité**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/IDswzRI-8VQ\" title=\"Comment configurer les frameworks et pipelines de conformité dans GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Tutoriel vidéo : appliquer des pipelines de conformité**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jKA_e_jimoI\" title=\"GitLab Compliance Pipelines & Overriding Settings\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Gestion des politiques de sécurité\n\nLes équipes de sécurité et de conformité peuvent utiliser GitLab pour appliquer les exigences de conformité en veillant à ce que des scanners de sécurité s'exécutent dans certains pipelines ou exigent une approbation sur les merge requests lorsque les [politiques de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/) sont enfreintes. GitLab prend en charge les politiques d'[exécution des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) et de [résultats des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html). Ces politiques sont définies dans un [projet de politique de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/#security-policy-project) dédié qui sépare les responsabilités entre les équipes de sécurité et de développement. Les politiques de sécurité peuvent être appliquées de manière granulaire au niveau du groupe, du sous-groupe et du projet. Les politiques peuvent être modifiées en mode règle, qui utilise l'[éditeur de politique](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor), ou en mode yaml.\n\n#### Politiques d'exécution des scans\n\nLes politiques d'exécution des scans peuvent être configurées pour s'exécuter sur un [GitLab Runner](https://docs.gitlab.com/runner/) spécifié :\n\n- [Test statique de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n- [Infrastructure as Code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n- [Test dynamique de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n- [Détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/)\n- [Analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n- [Analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nLes jobs de scans peuvent être exécutés selon un calendrier ou chaque fois qu'un pipeline s'exécute. Les équipes de conformité et de sécurité peuvent utiliser les politiques d'exécution des analyses pour vérifier périodiquement et prévenir de manière proactive l'escalade des vulnérabilités dans le cadre d'une stratégie de gestion des vulnérabilités. Elles peuvent également renforcer les contrôles lorsque de nouvelles tendances sont observées à partir des résultats des scans.\n\n**Tutoriel vidéo : configurer des politiques d'analyse de sécurité dans GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZBcqGmEwORA\" title=\"Comment configurer des politiques des scans de sécurité dans GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Politiques de résultats des scans\n\nLes politiques de résultats des scans ajoutent une révision et une approbation requises pour les merge requests lorsque les résultats des analyses de sécurité spécifiées enfreignent les règles des politiques. Par exemple, une politique peut exiger qu'un membre de l'équipe de sécurité prenne des mesures lorsqu'une nouvelle vulnérabilité SAST critique est détectée. De cette façon, les membres des équipes de sécurité et de conformité peuvent venir en aide aux développeurs tout en veillant à ce que les modifications introduites dans la base de code soient sécurisées et respectent les exigences de conformité.\n\n**Tutoriel vidéo : aperçu des politiques de résultats des scans de GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/w5I9gcUgr9U\" title=\"Aperçu des politiques de résultats des scans de GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Politiques d'approbation des licences\n\nLors de la sélection des types de scans pour les règles de politique de résultats des scans, vous pouvez choisir entre le scan de sécurité, le comportement par défaut pour les politiques de résultats d'analyse, et l'analyse de licence, qui aide à garantir la conformité des licences. L'analyse des licences dépend des résultats du job [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) d'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) qui vérifie si les licences identifiées correspondent aux critères spécifiés, puis ajoute des exigences d'approbation avant qu'une merge request ouverte puisse être fusionnée. Cette étape est cruciale pour garantir que seules les dépendances avec des licences approuvées sont utilisées dans votre organisation.\n\n**Démonstration vidéo : politiques d'approbation des licences**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/34qBQ9t8qO8\" title=\"Démonstration des politiques d'approbation des licences\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Gestion des audits\n\n#### Préparation aux audits\n\nLes audits sont essentiels pour la gestion de la conformité, car ils permettent de comprendre la posture de sécurité et de conformité de votre organisation. Les audits externes requis par les régulateurs sont souvent détaillés et exhaustifs. Pour s'y préparer, les organisations doivent :\n\n- Déterminer les réglementations ou normes qui seront évaluées et les domaines de l'organisation qui seront examinés.\n- Analyser les résultats d'audit passés et s'assurer que tous les problèmes précédemment identifiés ont été résolus.\n- Collecter toutes les politiques, procédures et dossiers pertinents qui démontrent la conformité.\n- Effectuer un audit interne avant l'audit officiel pour identifier et combler toute lacune de conformité potentielle.\n- Informer les employés du processus d'audit et de leurs rôles. Effectuer une formation si nécessaire.\n- S'assurer que toute la documentation requise est facilement accessible et bien organisée.\n- Veiller à ce que toutes les politiques et procédures liées à la conformité soient à jour et alignées sur les réglementations actuelles.\n- Vérifier que toutes les mesures de protection techniques et tous les contrôles sont en place et fonctionnent correctement.\n- Identifier le personnel clé qui pourrait être interrogé et le briefer sur les questions potentielles.\n- Traiter les problèmes connus : s'il existe des problèmes de conformité connus, élaborer et documenter des plans d'action pour y remédier.\n\nPour faciliter votre préparation, les [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) et le [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) de GitLab offrent une vue détaillée de la conformité de l'organisation.\n\n#### Utilisation efficace des journaux d'audit GitLab\n\nLes [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) vous permettent de connaître chaque action effectuée sur l'instance GitLab. Les rapports d'audit indiquent chaque événement significatif avec son auteur et le moment où il a été effectué. Vous pouvez également générer des rapports détaillés à partir des événements d'audit en utilisant les [rapports d'audit](https://docs.gitlab.com/ee/administration/audit_reports.html), ce qui vous permet de prouver votre conformité aux auditeurs ou aux régulateurs.\n\n![Événements d'audit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098755493.png)\n\n[Le Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html#compliance-violations-report) est un composant important de la gestion des audits dans GitLab qui offre une visibilité sur la posture de conformité de votre organisation. Les rapports de conformité détaillent chaque violation découverte avec le [rapport sur les violations de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) et les frameworks utilisés par les projets au sein de votre organisation avec le [rapport sur les frameworks de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html).\n\n![Respect des exigences réglementaires – image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098756/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098755493.png)\n\n\u003Ccenter>\u003Ci>Exemple d'un rapport sur les violations de conformité d'un groupe GitLab parent\u003C/i>\u003C/center>\n\n![Respect des exigences réglementaires – image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098755495.png)\n\n\u003Ccenter>\u003Ci>Exemple d'un rapport de framework de conformité pour tous les projets dans un groupe\u003C/i>\u003C/center>\n\n#### Streaming des événements d'audit\n\nLa plupart des organisations disposent de systèmes pour surveiller les activités dans leurs systèmes en temps réel. Avec le [streaming des événements d'audit](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) de GitLab, vous pouvez intégrer des solutions tierces comme Splunk pour la surveillance d'infrastructure ou DataDog pour la surveillance des flux afin d'obtenir des analyses des événements d'audit en temps réel. Toutes les données d'événements d'audit sont envoyées à la destination de streaming (il est essentiel de diffuser vers un service de confiance). Le streaming des événements d'audit peut être [configuré au niveau des groupes principaux](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html#top-level-group-streaming-destinations) et au [niveau de l'instance](https://docs.gitlab.com/ee/administration/audit_event_streaming/#instance-streaming-destinations) pour les instances GitLab autogérées.\n\n## Bonnes pratiques pour la gestion de la conformité\n\nVoici quelques bonnes pratiques pour une gestion efficace de la conformité :\n\n- Établissez une solide culture de conformité qui favorise la sensibilisation à la conformité au sein de l'organisation et garantit l'engagement et le soutien de la direction.\n- Développez un programme de conformité complet avec des politiques et procédures claires et révisez-le régulièrement pour refléter les changements réglementaires.\n- Mettez en œuvre l'évaluation et la gestion des risques pour identifier et évaluer régulièrement les risques de conformité, en hiérarchisant les risques en fonction de l'impact potentiel et de la probabilité.\n- Organisez régulièrement des formations sur la conformité adaptée aux rôles et responsabilités spécifiques pour tous les employés.\n- Mettez en œuvre une gestion de la conformité pour automatiser la surveillance de la conformité et les rapports de conformité dans la mesure du possible.\n- Effectuez des audits internes pour identifier les lacunes et les domaines d'amélioration. Il est également essentiel de considérer les audits externes de manière impartiale et d'utiliser les résultats d'audit pour affiner et améliorer les processus de conformité.\n- Tenez-vous informé des changements réglementaires en assignant à une personne ou équipe la surveillance des mises à jour réglementaires et en rejoignant des associations ou en participant à des forums du secteur.\n- Intégrez la conformité dans les processus métier, intégrez des contrôles de conformité dans les workflows opérationnels et prenez en compte la conformité dans la prise de décision stratégique. Alignez les objectifs de conformité avec les objectifs commerciaux.\n- Développez des plans de réponse pour les violations potentielles de conformité et effectuez des scénarios fictifs pour tester la préparation aux incidents et violations.\n\n## En savoir plus\n\nLa conformité est un processus continu de gestion efficace des risques, qui implique la mise en œuvre de garde-fous et la surveillance des indicateurs de conformité. GitLab permet aux organisations de respecter les normes réglementaires avec des fonctionnalités de [gestion de la conformité](https://about.gitlab.com/fr-fr/solutions/compliance/). Avec GitLab, vous pouvez améliorer l'expérience de la chaîne d'approvisionnement logicielle, créer des logiciels plus sécurisés plus rapidement et maintenir la confiance de vos utilisateurs, de vos clients et de votre communauté.\n\n> Pour en savoir plus sur la conformité et la gestion des politiques de sécurité, consultez le [tutoriel GitLab DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/), qui couvre le cycle de vie complet de la sécurité des applications dans GitLab.\n\n## Pour aller plus loin\n\n- [GitLab Dedicated pour le secteur public](https://about.gitlab.com/blog/introducing-gitlab-dedicated-for-government/)\n- [Comment garantir la séparation des tâches et appliquer la conformité avec GitLab](https://about.gitlab.com/fr-fr/blog/ensuring-compliance/)\n- [Accès avec le principe de moindre privilège avec GitLab : notre guide](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)","La conformité est un processus continu de gestion des risques qui requiert la mise en œuvre de garde-fous et le suivi d'indicateurs spécifiques. Découvrez la marche à suivre dans ce guide complet.","Sécurité et conformité : respectez les normes réglementaires avec GitLab",{"featured":653,"template":795,"slug":1154},"meet-regulatory-standards-with-gitlab",{"content":1156,"config":1166},{"title":1157,"description":1158,"heroImage":1159,"date":1160,"body":1161,"category":769,"tags":1162,"authors":1164},"Mises à jour des politiques du programme de bug bounty de GitLab","Découvrez les améliorations apportées qui renforcent la précision et la portée du programme.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664844/Blog/Hero%20Images/AdobeStock_941867776.jpg","2026-01-20","GitLab a lancé [son programme de bug bounty HackerOne](https://about.gitlab.com/blog/gitlab-hackerone-bug-bounty-program-is-public-today/) pour la première fois en 2018. Nous avons depuis travaillé avec la communauté des chercheurs pour sécuriser notre plateforme DevSecOps complète alimentée par l'IA. Nous sommes ravis d'annoncer les mises à jour des politiques du programme, qui reflètent notre engagement envers la transparence, les retours des chercheurs et nos efforts continus en vue de fournir des attentes claires et des processus rationalisés.\n\n## Les changements apportés\n\n### Conseils améliorés pour les tests\n\nNous mettons davantage l'accent sur les environnements de test locaux pour protéger à la fois les chercheurs et notre infrastructure de production. Nous **recommandons fortement les tests locaux avec le [GitLab Development Kit (GDK)](https://gitlab-org.gitlab.io/gitlab-development-kit/)** pour la plupart des recherches en sécurité. Le GDK vous donne accès à des fonctionnalités de pointe avant leur publication et vous permet d'expérimenter sans devoir vous préoccuper de l'infrastructure de production.\n\nSi vous devez démontrer l'impact d'une attaque par déni de service (DoS), nous vous recommandons de le tester sur une instance GitLab auto-gérée avec des spécifications et des ressources égales ou supérieures aux [exigences d'installation des instances GitLab auto-gérées](https://docs.gitlab.com/install/requirements/).\n\nPour les vulnérabilités qui requièrent l'architecture de production de GitLab.com, vous devez utiliser des comptes de test créés avec votre alias de courrier électronique HackerOne : `yourhandle@wearehackerone.com`.\n\n### Portée affinée pour une meilleure concentration\n\nNous avons clarifié plusieurs domaines de portée en fonction des retours de la communauté :\n\n**Les attaques par DoS sortent du champ d'application :** des exceptions peuvent être envisagées pour les vulnérabilités DoS au niveau de l'application qui entraînent une interruption totale persistante du service et peuvent être exécutées via des points de terminaison non authentifiés (exemples : ReDoS, bombes logiques, etc.).\n\n**Injection de prompt :** l'injection de prompt autonome sort du champ d'application, mais peut être admise si elle sert de vecteur initial pour causer un préjudice au-delà de sa limite de sécurité.\n\n**Métadonnées et énumération** : la collecte générale d'informations sort du champ d'application, tandis que les violations de confidentialité exposant des données confidentielles tombent dans le champ d'application. Nous avons fourni de nouveaux exemples détaillés qui distinguent ces deux types de problèmes sur la [page des politiques du programme](https://hackerone.com/gitlab).\n\n## Période de transition pour les chercheurs\n\nNous sommes conscients que les changements de politique peuvent créer de l'incertitude pour les chercheurs qui mènent des enquêtes actives. Pour préserver la confiance pendant cette transition et éviter d'interférer avec les importantes recherches déjà en cours :\n\n* GitLab offre un délai de grâce de 7 jours pour les rapports DoS soumis avant **le 22 janvier 2026 à 21 h 00, heure du Pacifique (23 janvier 2026 à 6 h 00, heure française).** Les rapports soumis avant cette date seront évalués selon notre politique précédente.\n\nVotre investissement dans la sécurité de GitLab nous tient à cœur, et nous nous engageons à honorer la politique dans le cadre de laquelle vous avez commencé votre recherche.\n\n## Notre engagement envers la communauté\n\nCes changements reflètent notre engagement profond envers la communauté des chercheurs à travers trois principes clés.\n\n1\\. Nous mettons l'accent sur la transparence en établissant des limites plus claires et des critères objectifs qui réduisent l'ambiguïté et préviennent les différends.\n\n2\\. Nous renforçons la sécurité grâce à des conseils améliorés sur la plateforme de test qui protègent à la fois les systèmes de production et les chercheurs contre les interruptions accidentelles de service.\n\n3\\. Nous assurons l'équité grâce à des normes d'évaluation cohérentes et à des dispositions qui garantissent un traitement équitable pour tous les chercheurs, y compris ceux qui participent déjà au programme.\n\nLes ajustements apportés à la portée contribuent également à la durabilité du programme, car ils concentrent les ressources sur les problèmes de sécurité à fort impact et maintiennent une couverture large.\n\n## Lancez-vous\n\nEnvie de contribuer à la sécurité de GitLab ?\n\n* **Nouveaux chercheurs :** visitez notre [page consacrée au programme HackerOne](https://hackerone.com/gitlab).\n* **Configurer des tests locaux :** téléchargez le [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit).\n* **Examiner les politiques :** [consultez notre documentation complète pour obtenir des directives détaillées](https://hackerone.com/gitlab).\n* **Comprendre l'évaluation de la gravité :** explorez notre [calculateur CVSS](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/).\n\nNous remercions la communauté des chercheurs dont l'engagement continu aide à maintenir la sécurité de GitLab. Votre expertise et votre dévouement font une réelle différence pour des millions d'utilisateurs dans le monde.\n\n---\n\n*Des questions sur ces changements ? Contactez notre équipe en [créant un ticket](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/hackerone-questions/-/issues/new) dans notre projet de questions HackerOne sur GitLab.*",[769,1163],"bug bounty",[1165],"Kayla Hagopian",{"featured":653,"template":795,"slug":1167},"gitlab-bug-bounty-program-policy-updates",{"content":1169,"config":1172},{"title":1096,"description":1097,"authors":1170,"heroImage":846,"body":1100,"date":1101,"category":757,"tags":1171},[1099],[89,757,790],{"featured":13,"template":795,"slug":1104},[1174,1179,1184],{"content":1175,"config":1178},{"title":942,"description":943,"authors":1176,"date":945,"body":946,"category":705,"tags":1177,"heroImage":948},[833],[934,707],{"featured":653,"template":795,"slug":950},{"content":1180,"config":1183},{"title":1020,"description":1021,"authors":1181,"heroImage":1024,"date":1025,"body":1026,"category":731,"tags":1182},[1023],[707,731,259],{"featured":653,"template":795,"slug":1029},{"content":1185,"config":1188},{"title":870,"description":871,"heroImage":872,"authors":1186,"date":834,"body":875,"category":679,"tags":1187},[874],[757],{"featured":653,"template":795,"slug":878},[1190,1195,1200],{"content":1191,"config":1194},{"title":1133,"description":1134,"authors":1192,"heroImage":846,"date":1138,"body":1139,"category":769,"tags":1193},[1136,1137],[769,757,790],{"featured":653,"template":795,"slug":1142},{"content":1196,"config":1199},{"title":842,"description":843,"authors":1197,"heroImage":846,"date":847,"body":848,"category":666,"tags":1198},[845],[788,757,790],{"featured":13,"template":795,"slug":851},{"content":1201,"config":1204},{"title":1107,"description":1108,"authors":1202,"date":1111,"body":1112,"heroImage":1113,"category":757,"tags":1203},[792,1110],[1115,757,707],{"featured":13,"template":795,"slug":1117},1772652095744]