[{"data":1,"prerenderedAt":1216},["ShallowReactive",2],{"/fr-fr/blog/":3,"navigation-fr-fr":21,"banner-fr-fr":440,"footer-fr-fr":453,"blogCategories-fr-fr":666,"relatedBlogPosts-fr-fr":788,"maineFeaturedPost-fr-fr":1179,"recentFeaturedPosts-fr-fr":1184,"recentPosts-fr-fr":1200},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/fr-fr/blog","fr-fr",false,"",{"title":9,"description":10},"Blog","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:fr-fr:blog:index.yml","yaml","content","fr-fr/blog/index.yml","fr-fr/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":436,"_type":16,"title":437,"_source":17,"_file":438,"_stem":439,"_extension":20},"/shared/fr-fr/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":413,"duo":427},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/fr-fr/","gitlab logo","header",{"text":30,"config":31},"Commencer un essai gratuit",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Contacter l'équipe commerciale",{"href":37,"dataGaName":38,"dataGaLocation":28},"/fr-fr/sales/","sales",{"text":40,"config":41},"Connexion",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Plateforme",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":53,"config":54},"Découvrir notre plateforme",{"href":55,"dataGaName":48,"dataGaLocation":28},"/fr-fr/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":60,"config":61},"Découvrez GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":68,"config":69},"En savoir plus",{"href":70,"dataGaName":71,"dataGaLocation":28},"/fr-fr/why-gitlab/","why gitlab",{"title":73,"items":74},"Démarrer avec",[75,80,85],{"text":76,"config":77},"Ingénierie de plateforme",{"href":78,"dataGaName":79,"dataGaLocation":28},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Expérience développeur",{"href":83,"dataGaName":84,"dataGaLocation":28},"/fr-fr/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produit",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/fr-fr/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":113,"config":114},"Développement assisté par l'IA",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Gestion du code source",{"href":119,"dataGaLocation":28,"dataGaName":120},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Sécurité et conformité",{"href":130,"dataGaLocation":28,"dataGaName":137},"Security & Compliance",{"text":139,"config":140},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":141,"dataGaLocation":28,"dataGaName":142},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Conformité et gouvernance",{"href":146,"dataGaLocation":28,"dataGaName":147},"/fr-fr/solutions/continuous-software-compliance/","Compliance and governance",{"title":149,"link":150,"items":155},"Mesures",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Visibilité et mesures",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Gestion de la chaîne de valeur",{"href":163,"dataGaLocation":28,"dataGaName":164},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Données d'analyse et informations clés",{"href":168,"dataGaLocation":28,"dataGaName":169},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab pour",[173,178,183],{"text":174,"config":175},"Entreprises",{"href":176,"dataGaLocation":28,"dataGaName":177},"/fr-fr/enterprise/","enterprise",{"text":179,"config":180},"PME",{"href":181,"dataGaLocation":28,"dataGaName":182},"/fr-fr/small-business/","small business",{"text":184,"config":185},"Secteur public",{"href":186,"dataGaLocation":28,"dataGaName":187},"/fr-fr/solutions/public-sector/","public sector",{"text":189,"config":190},"Tarifs",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/fr-fr/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":285},"Ressources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Afficher toutes les ressources",{"href":200,"dataGaName":196,"dataGaLocation":28},"/fr-fr/resources/",[202,235,257],{"title":203,"items":204},"Premiers pas",[205,210,215,220,225,230],{"text":206,"config":207},"Installation",{"href":208,"dataGaName":209,"dataGaLocation":28},"/fr-fr/install/","install",{"text":211,"config":212},"Guides de démarrage rapide",{"href":213,"dataGaName":214,"dataGaLocation":28},"/fr-fr/get-started/","quick setup checklists",{"text":216,"config":217},"Apprentissage",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Documentation sur le produit",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Vidéos sur les bonnes pratiques",{"href":228,"dataGaName":229,"dataGaLocation":28},"/fr-fr/getting-started-videos/","best practice videos",{"text":231,"config":232},"Intégrations",{"href":233,"dataGaName":234,"dataGaLocation":28},"/fr-fr/integrations/","integrations",{"title":236,"items":237},"Découvrir",[238,243,247,252],{"text":239,"config":240},"Histoires de succès client",{"href":241,"dataGaName":242,"dataGaLocation":28},"/fr-fr/customers/","customer success stories",{"text":9,"config":244},{"href":245,"dataGaName":246,"dataGaLocation":28},"/fr-fr/blog/","blog",{"text":248,"config":249},"Travail à distance",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/fr-fr/teamops/","teamops",{"title":258,"items":259},"Connecter",[260,265,270,275,280],{"text":261,"config":262},"Services GitLab",{"href":263,"dataGaName":264,"dataGaLocation":28},"/fr-fr/services/","services",{"text":266,"config":267},"Communauté",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Événements",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partenaires",{"href":283,"dataGaName":284,"dataGaLocation":28},"/fr-fr/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":290,"config":291},"carte promo The Source",{"src":292},"/images/navigation/the-source-promo-card.svg",{"text":294,"config":295},"Lire les articles les plus récents",{"href":296,"dataGaName":297,"dataGaLocation":28},"/fr-fr/the-source/","the source",{"text":299,"config":300,"lists":302},"Société",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"À propos",{"href":308,"dataGaName":309,"dataGaLocation":28},"/fr-fr/company/","about",{"text":311,"config":312,"footerGa":315},"Emplois",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Leadership",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Équipe",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Manuel",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Relations avec les investisseurs",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Centre de confiance",{"href":341,"dataGaName":342,"dataGaLocation":28},"/fr-fr/security/","trust center",{"text":344,"config":345},"Centre pour la transparence de l'IA",{"href":346,"dataGaName":347,"dataGaLocation":28},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Presse",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Nous contacter",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Aide",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Portail clients GitLab",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Fermer",{"text":380,"link":381},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Suggestions",[389,392,397,399,404,409],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"Suggestions de code (IA)",{"href":395,"dataGaName":396,"dataGaLocation":385},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab sur AWS",{"href":402,"dataGaName":403,"dataGaLocation":385},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":405,"config":406},"GitLab sur Google Cloud ",{"href":407,"dataGaName":408,"dataGaLocation":385},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":410,"config":411},"Pourquoi utiliser GitLab ?",{"href":70,"dataGaName":412,"dataGaLocation":385},"Why GitLab?",{"freeTrial":414,"mobileIcon":419,"desktopIcon":424},{"text":415,"config":416},"Commencer votre essai gratuit",{"href":417,"dataGaName":33,"dataGaLocation":418},"https://gitlab.com/-/trials/new/","nav",{"altText":420,"config":421},"Icône GitLab",{"src":422,"dataGaName":423,"dataGaLocation":418},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":420,"config":425},{"src":426,"dataGaName":423,"dataGaLocation":418},"/images/brand/gitlab-logo-type.svg",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"En savoir plus sur GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":418},"gitlab duo",{"altText":420,"config":433},{"src":422,"dataGaName":423,"dataGaLocation":418},{"altText":420,"config":435},{"src":426,"dataGaName":423,"dataGaLocation":418},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":441,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":442,"titleMobile":442,"button":443,"config":448,"_id":450,"_type":16,"_source":17,"_file":451,"_stem":452,"_extension":20},"/shared/fr-fr/banner","GitLab 18 et la prochaine étape du DevSecOps intelligent. Rejoignez-nous le 24 juin.",{"text":444,"config":445},"S'inscrire",{"href":446,"dataGaName":447,"dataGaLocation":28},"/fr-fr/eighteen/","gitlab 18 banner",{"layout":449},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":454,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":662,"_type":16,"title":663,"_source":17,"_file":664,"_stem":665,"_extension":20},"/shared/fr-fr/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":653},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":458,"config":459},"Afficher le code source de la page",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Modifier cette page",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Veuillez contribuer",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,556,589,624],{"title":46,"links":480,"subMenu":485},[481],{"text":482,"config":483},"Plateforme DevSecOps",{"href":55,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":189,"links":487},[488,492,497],{"text":489,"config":490},"Voir les forfaits",{"href":191,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Pourquoi choisir GitLab Premium ?",{"href":495,"dataGaName":496,"dataGaLocation":462},"/fr-fr/pricing/premium/","why premium",{"text":498,"config":499},"Pourquoi choisir GitLab Ultimate ?",{"href":500,"dataGaName":501,"dataGaLocation":462},"/fr-fr/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Solutions",[505,510,513,515,520,525,529,532,535,540,542,544,546,551],{"text":506,"config":507},"Transformation digitale",{"href":508,"dataGaName":509,"dataGaLocation":462},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":135,"config":511},{"href":130,"dataGaName":512,"dataGaLocation":462},"security & compliance",{"text":122,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Développement agile",{"href":518,"dataGaName":519,"dataGaLocation":462},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Transformation cloud",{"href":523,"dataGaName":524,"dataGaLocation":462},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":119,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":109,"config":530},{"href":111,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":161,"config":533},{"href":163,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/fr-fr/solutions/gitops/","gitops",{"text":174,"config":541},{"href":176,"dataGaName":177,"dataGaLocation":462},{"text":179,"config":543},{"href":181,"dataGaName":182,"dataGaLocation":462},{"text":184,"config":545},{"href":186,"dataGaName":187,"dataGaLocation":462},{"text":547,"config":548},"Formation",{"href":549,"dataGaName":550,"dataGaLocation":462},"/fr-fr/solutions/education/","education",{"text":552,"config":553},"Services financiers",{"href":554,"dataGaName":555,"dataGaLocation":462},"/fr-fr/solutions/finance/","financial services",{"title":194,"links":557},[558,560,562,564,567,569,573,575,577,579,581,583,585,587],{"text":206,"config":559},{"href":208,"dataGaName":209,"dataGaLocation":462},{"text":211,"config":561},{"href":213,"dataGaName":214,"dataGaLocation":462},{"text":216,"config":563},{"href":218,"dataGaName":219,"dataGaLocation":462},{"text":221,"config":565},{"href":223,"dataGaName":566,"dataGaLocation":462},"docs",{"text":9,"config":568},{"href":245,"dataGaName":246},{"text":570,"config":571},"Histoires de réussite client",{"href":572,"dataGaLocation":462},"/customers/",{"text":239,"config":574},{"href":241,"dataGaName":242,"dataGaLocation":462},{"text":248,"config":576},{"href":250,"dataGaName":251,"dataGaLocation":462},{"text":261,"config":578},{"href":263,"dataGaName":264,"dataGaLocation":462},{"text":253,"config":580},{"href":255,"dataGaName":256,"dataGaLocation":462},{"text":266,"config":582},{"href":268,"dataGaName":269,"dataGaLocation":462},{"text":271,"config":584},{"href":273,"dataGaName":274,"dataGaLocation":462},{"text":276,"config":586},{"href":278,"dataGaName":279,"dataGaLocation":462},{"text":281,"config":588},{"href":283,"dataGaName":284,"dataGaLocation":462},{"title":299,"links":590},[591,593,595,597,599,601,603,608,613,615,617,619],{"text":306,"config":592},{"href":308,"dataGaName":301,"dataGaLocation":462},{"text":311,"config":594},{"href":313,"dataGaName":314,"dataGaLocation":462},{"text":319,"config":596},{"href":321,"dataGaName":322,"dataGaLocation":462},{"text":324,"config":598},{"href":326,"dataGaName":327,"dataGaLocation":462},{"text":329,"config":600},{"href":331,"dataGaName":332,"dataGaLocation":462},{"text":334,"config":602},{"href":336,"dataGaName":337,"dataGaLocation":462},{"text":604,"config":605},"Stratégie environnementale, sociale et de gouvernance (ESG)",{"href":606,"dataGaName":607,"dataGaLocation":462},"/fr-fr/environmental-social-governance/","environmental, social and governance",{"text":609,"config":610},"Diversité, inclusion et appartenance (DIB)",{"href":611,"dataGaName":612,"dataGaLocation":462},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":614},{"href":341,"dataGaName":342,"dataGaLocation":462},{"text":349,"config":616},{"href":351,"dataGaName":352,"dataGaLocation":462},{"text":354,"config":618},{"href":356,"dataGaName":357,"dataGaLocation":462},{"text":620,"config":621},"Déclaration de transparence sur l'esclavage moderne",{"href":622,"dataGaName":623,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":359,"links":625},[626,629,631,633,638,643,648],{"text":627,"config":628},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":462},{"text":368,"config":630},{"href":370,"dataGaName":371,"dataGaLocation":462},{"text":373,"config":632},{"href":375,"dataGaName":376,"dataGaLocation":462},{"text":634,"config":635},"Statut",{"href":636,"dataGaName":637,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":639,"config":640},"Conditions d'utilisation",{"href":641,"dataGaName":642},"/terms/","terms of use",{"text":644,"config":645},"Déclaration de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":462},"/fr-fr/privacy/","privacy statement",{"text":649,"config":650},"Préférences en matière de cookies",{"dataGaName":651,"dataGaLocation":462,"id":652,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,660],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":462},{"text":658,"config":659},"Politique de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":462},{"text":649,"config":661},{"dataGaName":651,"dataGaLocation":462,"id":652,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",[667,681,693,705,717,729,741,753,765,776],{"_path":668,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":673,"config":674,"_id":677,"_type":16,"title":678,"_source":17,"_file":679,"_stem":680,"_extension":20},"/fr-fr/blog/categories/agile-planning","categories",{"title":671,"description":672},"Planification Agile","Browse articles related to Planification Agile on the GitLab Blog",{"name":671},{"template":675,"slug":676,"hide":6},"BlogCategory","agile-planning","content:fr-fr:blog:categories:agile-planning.yml","Agile Planning","fr-fr/blog/categories/agile-planning.yml","fr-fr/blog/categories/agile-planning",{"_path":682,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":683,"content":686,"config":687,"_id":689,"_type":16,"title":690,"_source":17,"_file":691,"_stem":692,"_extension":20},"/fr-fr/blog/categories/ai-ml",{"title":684,"description":685},"IA/ML","Browse articles related to IA/ML on the GitLab Blog",{"name":684},{"template":675,"slug":688,"hide":6},"ai-ml","content:fr-fr:blog:categories:ai-ml.yml","Ai Ml","fr-fr/blog/categories/ai-ml.yml","fr-fr/blog/categories/ai-ml",{"_path":694,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":695,"content":698,"config":699,"_id":701,"_type":16,"title":702,"_source":17,"_file":703,"_stem":704,"_extension":20},"/fr-fr/blog/categories/bulletin-board",{"title":696,"description":697},"Annonces","Browse articles related to Annonces on the GitLab Blog",{"name":696},{"template":675,"slug":700,"hide":6},"bulletin-board","content:fr-fr:blog:categories:bulletin-board.yml","Bulletin Board","fr-fr/blog/categories/bulletin-board.yml","fr-fr/blog/categories/bulletin-board",{"_path":706,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":707,"content":710,"config":711,"_id":713,"_type":16,"title":714,"_source":17,"_file":715,"_stem":716,"_extension":20},"/fr-fr/blog/categories/customer-stories",{"title":708,"description":709},"Étude de cas","Browse articles related to Étude de cas on the GitLab Blog",{"name":708},{"template":675,"slug":712,"hide":6},"customer-stories","content:fr-fr:blog:categories:customer-stories.yml","Customer Stories","fr-fr/blog/categories/customer-stories.yml","fr-fr/blog/categories/customer-stories",{"_path":718,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":719,"content":722,"config":723,"_id":725,"_type":16,"title":726,"_source":17,"_file":727,"_stem":728,"_extension":20},"/fr-fr/blog/categories/devsecops",{"title":720,"description":721},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":720},{"template":675,"slug":724,"hide":6},"devsecops","content:fr-fr:blog:categories:devsecops.yml","Devsecops","fr-fr/blog/categories/devsecops.yml","fr-fr/blog/categories/devsecops",{"_path":730,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":731,"content":734,"config":735,"_id":737,"_type":16,"title":738,"_source":17,"_file":739,"_stem":740,"_extension":20},"/fr-fr/blog/categories/engineering",{"title":732,"description":733},"Ingénierie","Browse articles related to Ingénierie on the GitLab Blog",{"name":732},{"template":675,"slug":736,"hide":6},"engineering","content:fr-fr:blog:categories:engineering.yml","Engineering","fr-fr/blog/categories/engineering.yml","fr-fr/blog/categories/engineering",{"_path":742,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":743,"content":746,"config":747,"_id":749,"_type":16,"title":750,"_source":17,"_file":751,"_stem":752,"_extension":20},"/fr-fr/blog/categories/news",{"title":744,"description":745},"Actualités","Browse articles related to Actualités on the GitLab Blog",{"name":744},{"template":675,"slug":748,"hide":6},"news","content:fr-fr:blog:categories:news.yml","News","fr-fr/blog/categories/news.yml","fr-fr/blog/categories/news",{"_path":754,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":755,"content":758,"config":759,"_id":761,"_type":16,"title":762,"_source":17,"_file":763,"_stem":764,"_extension":20},"/fr-fr/blog/categories/open-source",{"title":756,"description":757},"Open source","Browse articles related to Open source on the GitLab Blog",{"name":756},{"template":675,"slug":760,"hide":6},"open-source","content:fr-fr:blog:categories:open-source.yml","Open Source","fr-fr/blog/categories/open-source.yml","fr-fr/blog/categories/open-source",{"_path":766,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":767,"content":769,"config":770,"_id":772,"_type":16,"title":773,"_source":17,"_file":774,"_stem":775,"_extension":20},"/fr-fr/blog/categories/product",{"title":90,"description":768},"Browse articles related to Produit on the GitLab Blog",{"name":90},{"template":675,"slug":771,"hide":6},"product","content:fr-fr:blog:categories:product.yml","Product","fr-fr/blog/categories/product.yml","fr-fr/blog/categories/product",{"_path":777,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":778,"content":781,"config":782,"_id":784,"_type":16,"title":785,"_source":17,"_file":786,"_stem":787,"_extension":20},"/fr-fr/blog/categories/security",{"title":779,"description":780},"Sécurité","Browse articles related to Sécurité on the GitLab Blog",{"name":779},{"template":675,"slug":783,"hide":6},"security","content:fr-fr:blog:categories:security.yml","Security","fr-fr/blog/categories/security.yml","fr-fr/blog/categories/security",[789,834,874,888,934,972,1018,1060,1098,1139],{"category":671,"slug":676,"posts":790},[791,809,822],{"content":792,"config":806},{"title":793,"description":794,"authors":795,"heroImage":797,"date":798,"body":799,"category":676,"tags":800,"updatedDate":805},"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.",[796],"Amanda Rueda","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","Lorsqu'une entreprise décide d'adopter le Scaled Agile Framework (SAFe) pour s'adapter à ses nouveaux besoins, coordonner les équipes qui travaillent sur des produits complexes devient rapidement un enjeu de taille. Elle doit couramment faire face à un défi majeur : la planification s'effectue dans un outil, tandis que le travail de développement proprement dit est géré dans un autre.\n\nCette séparation crée des silos entre les équipes et entraîne une multitude de problèmes au quotidien : les équipes de développement passent constamment d'un système à l'autre, les chefs de produit peinent à obtenir une image précise de l'avancement des projets, et au final, ce sont tous les contributeurs aux projets qui perdent un temps précieux à transférer manuellement des informations entre les différents systèmes. Or, SAFe a précisément été conçu pour résoudre ce type d'expérience fragmentée.\n\nSi vos équipes de développement utilisent déjà GitLab pour la [gestion du code source](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\"), les processus [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et la sécurité des logiciels, vous vous demandez peut-être s'il est possible d'y intégrer également la planification SAFe. La réponse est oui. Grâce à ses solides capacités de gestion de projets Agile, GitLab prend en charge le framework SAFe à chaque étape du développement logiciel. \n\nDans cet article, découvrez comment GitLab vous aide à mettre en place les concepts et les cérémonies SAFe, le tout au sein d'une seule et même plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\").\n\n## Qu'est-ce que le Scaled Agile Framework (SAFe) ?\n\nLe Scaled Agile Framework (SAFe) est une approche de gestion conçue pour appliquer les principes Agile à l'échelle des grandes entreprises. Il optimise la livraison de valeur, assure un alignement constant entre les équipes et se concentre sur les besoins des clients. \n\nSAFe transpose le modèle collaboratif et itératif des petites équipes aux environnements complexes des grandes entreprises impliquant de nombreuses équipes, parties prenantes et roadmaps. \n\nCette approche permet d'harmoniser tous les efforts de planification et d'exécution vers un objectif commun. Pour les chefs de produit, le Scaled Agile Framework (SAFe) fait le lien entre la stratégie et l'exécution : il ne s'agit pas uniquement de livrer rapidement, mais de livrer les bons produits, en s'appuyant sur des priorités claires et une coordination transversales entre les différentes équipes.\n\nSAFe réduit les silos, encourage la collaboration et aide les équipes à se mobiliser autour des résultats attendus par les clients, et non plus uniquement autour des tâches à accomplir. Une fois intégré à GitLab, la magie opère : visibilité, traçabilité et livraison sont réunies au sein d'une seule et même plateforme.\n\n## Correspondance de la terminologie SAFe dans GitLab\n\nVoici un aperçu des concepts SAFe et leur correspondance dans GitLab :\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Epic principal |\n| Capability | Sous-epic (niveau 1) |\n| Feature | Sous-epic (niveau 2) |\n| User story | Ticket |\n| Task | Tâche |\n| Team | Champ personnalisé / Label à portée limitée |\n| Sprint | Itération |\n| Program Increment (PI) | Jalon |\n| Value Stream | Groupe principal |\n| Agile Release Train (ART) | Groupe principal |\n\n\u003Cbr>\u003C/br>\n\nEn vous basant sur cette correspondance, vous pouvez configurer GitLab pour refléter fidèlement votre implémentation SAFe. La structure des groupes vous permet d'organiser vos équipes autour de vos chaînes de valeur (Value Stream) et de vos Agile Release Trains (ART), tandis que la hiérarchie des éléments de travail (avec jusqu'à sept niveaux d'epics imbriqués) vous offre toute la profondeur nécessaire pour gérer des portefeuilles produits complexes. Que vous travailliez au niveau du portefeuille (groupes principaux), du programme (sous-groupes) ou de l'équipe (projets), la structure organisationnelle de GitLab s'aligne parfaitement avec la hiérarchie SAFe.\n\n## Les cérémonies SAFe dans GitLab\n\nDécouvrez maintenant comment organiser vos cérémonies SAFe dans GitLab. Voici comment procéder, étape par étape.\n\n### Planification PI (Program Increment)\n\nPour faciliter l'alignement entre les équipes et la gestion des dépendances qui font le succès de la planification PI, GitLab offre plusieurs fonctionnalités :\n\n* La vue [Roadmap](https://docs.gitlab.com/user/group/roadmap/) :  visualisez les fonctionnalités par équipe et sur plusieurs périodes.\n* Les [jalons](https://docs.gitlab.com/user/project/milestones/) : associez chaque fonctionnalité au jalon correspondant à votre PI. \n* Les [dépendances](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues) : documentez et visualisez les dépendances entre équipes dès qu'elles sont identifiées.\n\nGitLab vous offre une grande flexibilité pour la planification PI grâce à deux vues principales : les tableaux des epics (qui peuvent être configurés pour afficher les affectations par équipe) et la vue Roadmap (qui affiche les fonctionnalités au fil du temps, façon diagramme de Gantt). Vous pouvez facilement passer d'une vue à l'autre pendant votre session de planification, selon que vous souhaitez vous concentrer sur la chronologie ou l'organisation des équipes.\n\n![Vue Roadmap et tableau des epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Vue Roadmap avec diagramme de Gantt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Affinement\n\nEn tant que chef de produit, animer des sessions d'affinement efficaces repose sur une visibilité complète de votre backlog de fonctionnalités. Vous pouvez exécuter votre session d'affinement directement dans GitLab. Il n'est plus nécessaire de mettre à jour un outil pendant la réunion, puis un autre après coup. \n\nGitLab facilite les sessions d'affinement grâce aux éléments suivants :\n\n* Les [tableaux des epics](https://docs.gitlab.com/user/group/epics/epic_boards/) : regroupez les fonctionnalités en fonction de leur statut.  \n* Les story points : visualisez-les directement dans l'[aperçu](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic).  \n* Les [vues dans un volet latéral](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer) : interagissez avec vos éléments de travail sans jamais perdre de vue le contexte.   \n* Les [tickets enfants](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) : créez et associez des tickets directement à partir des epics.\n\n![SAFe - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Planification de sprint\n\nGitLab vous offre tous les outils nécessaires pour planifier vos sprints sans frictions :\n\n* Les [tableaux des tickets](https://docs.gitlab.com/user/project/issue_board/) : visualisez clairement l'ensemble de votre backlog.  \n* Le [poids total](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) des user stories : visualisez-le directement dans les tableaux.  \n* L'ordonnancement des tickets : déplacez les tickets entre les différentes itérations, par simple glisser-déposer. \n* Une vue repliable : simplifiez le réordonnancement des stories d'un sprint à l'autre.\n\nPlus besoin de jongler entre plusieurs outils, toute la planification se fait dans GitLab. Vous pouvez ainsi consacrer vos réunions de planification à prendre les bonnes décisions.\n\n![Planification de sprint avec GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 Consultez [ce tutoriel dédié à la mise en œuvre de la méthode Scrum avec GitLab](https://docs.gitlab.com/tutorials/scrum_events/) et découvrez en détail la puissance de GitLab dans la planification Agile et le suivi des sprints.*\n\n### Points quotidiens\n\nVotre équipe peut se réunir autour du tableau de bord lors de vos points quotidiens, plus besoin de naviguer entre plusieurs outils ou de deviner l'avancement des projets : tout est visible en un clin d'œil dans GitLab. Votre équipe voit instantanément qui travaille sur quoi, ce qui bloque, et ce qui est prêt pour la revue. GitLab vous permet d'effectuer les actions suivantes lors de vos points quotidiens :\n\n* Les tableaux [filtrés par itération](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) : affichez le travail du sprint en cours.\n* Les story points : affichez le poids des stories directement sur les cartes. \n* La [vue du volet latéral](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer) : accédez aux détails sans quitter le contexte. \n* Les [indicateurs de progression](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status) : mettez en évidence les tâches à risque.\n\n![Tableau de réunions debout quotidiennes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Revue de sprint\n\nPour avoir une vision claire des performances de votre équipe au fil des sprints, GitLab met à votre disposition des indicateurs puissants avec les éléments suivants :\n\n* Des [graphiques d'avancement burndown et burnup](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) : visualisez facilement l'avancement des itérations. \n* Le suivi de la vélocité : mesurez l'efficacité de votre équipe.  \n* Les [délais d'exécution et la durée de cycle](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics) : obtenez des indicateurs précis pour évaluer vos workflows.  \n* Des tableaux de bord personnalisables : créez des vues adaptées à chaque équipe.\n\nCes indicateurs vous aident à comprendre si votre équipe gagne en rapidité, à détecter les goulots d'étranglement et les points de friction à aborder lors de votre prochaine rétrospective.\n\n![Graphiques d'avancement burndown et burnup](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 bonnes raisons d'adopter une plateforme unifiée\n\nIl existe de nombreux outils de planification capables de gérer les cérémonies SAFe. Mais GitLab se distingue véritablement de ses concurrents pour les raisons suivantes :\n\n1. **Plus de changement de contexte** : la planification, le développement, les tests et la sécurité s'effectuent tous sur une seule plateforme.\n2. **Une traçabilité totale** : de l'épic stratégique et prioritaire jusqu'au déploiement, en passant par l'écriture du code, chaque élément est relié et facile à suivre.\n3. **Une collaboration efficace** : toutes les équipes (développement, produit, sécurité) collaborent dans le même outil.\n4. **Une visibilité instantanée** : toutes les parties prenantes accèdent aux informations clés mises à jour, sur une seule plateforme.\n5. **Une vue d'ensemble** : les indicateurs de planification et de développement sont regroupés pour comprendre exactement où en est le projet.\n\nSi vos équipes de développement apprécient déjà GitLab, pourquoi leur imposer un nouvel outil de planification ou créer des intégrations complexes et disparates ? En intégrant votre planification SAFe à GitLab, vous offrez à tous les contributeurs une expérience unifiée, cohérente et bien plus efficace.\n\n## Principes de mise en œuvre\n\nAprès avoir accompagné plusieurs équipes dans leur transition depuis des outils SAFe traditionnels vers GitLab, voici ce qu'il faut retenir : concentrez-vous sur **les objectifs propres à chaque cérémonie SAFe** plutôt que d'essayer de reproduire les processus de vos anciens outils.\n\nLes équipes qui tirent pleinement parti des fonctionnalités natives de GitLab sont plus performantes que celles qui essaient de les contourner. Cela demande un peu de travail au départ pour comprendre comment associer vos concepts SAFe et configurer vos workflows. Mais une fois cette étape franchie, vous constaterez rapidement que vos processus sont en réalité bien plus simples.\n\nLa clé du succès réside dans la définition de conventions partagées entre tous les contributeurs : quels labels utiliser ? Comment suivre les équipes ? Quelle différence entre un epic et un ticket ? En investissant un minimum d'effort dans cette phase de clarification, vous créez un système intuitif qui éliminera toute la charge de travail liée à la coordination entre les différents outils.\n\n## Mise en place du framework SAFe dans GitLab\n\nEnvie de vous lancer ? Voici les étapes pour mettre en œuvre un Scaled Agile Framework (SAFe) dans GitLab :\n\n1. **Structurez votre environnement** : créez des groupes et des sous-groupes qui [s'alignent sur l'organisation de vos équipes](https://about.gitlab.com/fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).\n2. **Définissez la répartition de votre travail** : décidez comment vous allez utiliser les [epics](https://about.gitlab.com/fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), les [tickets](https://docs.gitlab.com/user/project/issues/managing_issues/) et les [tâches](https://docs.gitlab.com/user/tasks/). \n3. **Créez vos itérations** : configurez votre [calendrier de sprints](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence).  \n4. **Ajoutez vos jalons** : les [jalons](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) représentent vos Program Increments (PI) SAFe dans GitLab. \n5. **Personnalisez vos tableaux** : créez des vues dédiées à chaque cérémonie SAFe. \n6. **Accordez-vous sur des conventions** : documentez la façon dont vous utiliserez les labels et les champs personnalisés.\n\nPrendre le temps de bien poser ces bases dès le départ vous évitera bien des tracas par la suite. Votre configuration n'a pas besoin d'être parfaite dès le premier jour : vous pourrez faire des ajustements au fur et à mesure.\n\n## Rassemblez toutes les pièces du puzzle\n\nGitLab vous offre une base solide pour exécuter le Scaled Agile Framework (SAFe), en particulier si vos équipes de développement sont déjà adeptes de GitLab. En centralisant la planification et le développement dans un seul et même outil, vous éliminez les silos et les transferts fastidieux, facilitez la collaboration et accélérez la livraison de vos produits.\n\nLa flexibilité des outils de planification de GitLab vous permet d'adapter l'approche SAFe à vos besoins spécifiques. Vos équipes ne sont pas soumises à des workflows rigides : vous pouvez faire évoluer votre approche à mesure que vos équipes gagnent en maturité et que vos besoins changent.\n\n> Découvrez à quel point la planification sans effet de silo peut être plus simple et plus efficace. [Essayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) et simplifiez l'implémentation de votre approche SAFe.\n\n*💡 Pour en savoir plus à ce sujet, n'hésitez pas à consulter également cet article : [Comment utiliser GitLab pour le développement logiciel agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/)*\n",[801,802,803,771,804],"agile","DevSecOps platform","features","tutorial","2025-05-12",{"slug":807,"featured":91,"template":808},"safe-without-silos-in-gitlab","BlogPost",{"content":810,"config":820},{"title":811,"description":812,"authors":813,"heroImage":814,"date":815,"body":816,"category":676,"tags":817,"updatedDate":819},"Comment harmoniser les sprints Agile avec les roadmaps produit","Découvrez comment tirer parti de la méthodologie Agile et des fonctionnalités de GitLab à chaque étape du cycle de développement logiciel.",[796],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","2025-02-04","Prenons l'exemple d'équipes produit et de développement travaillant en vase clos. La situation est la suivante : l'équipe produit établit une roadmap sur 12 mois et la communique aux parties prenantes internes, sans toutefois l'examiner au préalable avec l'équipe de développement. De son côté, l'équipe de développement commence à créer les fonctionnalités prévues pour le prochain sprint sans tenir compte de la roadmap produit globale. Résultat : des occasions manquées d'optimiser le calendrier, de mener des projets en parallèle, d'ajuster la charge de travail de l'équipe ou de concevoir des API réutilisables pouvant servir à plusieurs initiatives. Ce manque de coordination entraîne des inefficacités et des retards dans la livraison de valeur.\n\nTrouver le juste équilibre entre gains à court terme et vision à long terme n'est pas toujours facile. Pour y parvenir, une communication claire, des priorités alignées et les bons outils sont indispensables. Découvrez dans ce guide des stratégies concrètes pour harmoniser vos sprints Agile avec des roadmaps stratégiques, relever les défis du développement logiciel et mettre en place des solutions efficaces adaptées à vos équipes.\n\n## L'importance d'une source unique de vérité\n\nUne source unique et cohérente de vérité pour les roadmaps avec des objectifs à plus long terme vous garantit, à vous et à vos équipes, de disposer d'informations actualisées sur la vision globale du projet. Concrètement, cela implique d'adopter une plateforme unique et mise à jour régulièrement pour centraliser tous les détails de votre roadmap. Vous évitez ainsi la multiplication des versions de votre roadmap produit dans différents formats, source de divergences en termes d'informations et de mauvaise compréhension des objectifs à atteindre.\n\n### Comment créer une roadmap produit centralisée\n\nEn créant une roadmap centralisée pour votre équipe, vous pouvez :\n\n* communiquer une stratégie à long terme  \n* réduire au maximum les erreurs de communication  \n* faciliter l'alignement entre les différentes équipes \n* vous adapter rapidement aux changements sans perdre le contexte   \n* offrir un accès aux informations en libre-service, et ainsi réduire la dépendance à un point de contact unique détenant l'information\n\n***Conseil GitLab** : avec les [epics](https://docs.gitlab.com/ee/user/group/epics/) et la [vue Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/), vous pouvez facilement suivre la planification de vos produits et leurs livraisons. En effet, la vue Roadmap vous permet de suivre la progression du projet, d'identifier les goulots d'étranglement et d'assurer l'alignement entre les objectifs stratégiques et l'exécution des sprints.* \n\n![Vue Roadmap pour le groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## Pratiques collaboratives de révision d'une roadmap\n\nÉtablissez un processus régulier de révision et de validation des mises à jour de la roadmap produit en incluant un [trio produit](https://www.producttalk.org/product-trio/) gagnant, à savoir les équipes produit, les équipes UX et les équipes d'ingénierie. Les sessions de révision collaboratives de la roadmap vous aident à maintenir l'alignement entre les parties prenantes et à réduire au maximum les risques. Par exemple, chez GitLab, les réunions avec l'Engineering Manager et l'UX Designer assignés à un projet donné ont lieu chaque mois pour passer en revue les modifications et les valider avec eux. Nous maintenons un suivi des validations sur la page wiki de la roadmap elle-même, ce qui nous engage à respecter le calendrier et garantit la transparence vis-à-vis du reste de l'entreprise.\n\n### Comment optimiser l'efficacité des sessions de révision\n\nPour tirer le meilleur parti des sessions de révision, adoptez les bonnes pratiques suivantes :\n\n* Planifiez des révisions systématiques, mensuelles ou trimestrielles, en fonction de la fréquence à laquelle la roadmap a tendance à évoluer au sein de votre entreprise.\n* Validez l'alignement entre les objectifs produit, le délai de mise en œuvre de l'expérience utilisateur et la faisabilité technique en discutant dès le départ des risques potentiels et des dépendances.   \n  * Assurez-vous que la roadmap reflète les objectifs actuels de l'entreprise.  \n  * Veillez à ce que les délais de conception soient réalistes et tiennent compte des besoins en matière de recherche ou de validation.\n  * Vérifiez que la roadmap inclut le temps alloué à la préparation technique, y compris pour des explorations techniques ou des investigations. Vous pouvez ainsi vous assurer que le travail technique en amont s'aligne avec les priorités globales de l’équipe d'ingénierie.  \n* Optimisez l'efficacité de l'équipe en tenant compte des contraintes de capacité et en vous assurant que la séquence de travail correspond au profil de compétences de l'équipe. Il s'agit notamment d'éviter les périodes de sous-utilisation des ressources ou d'inadéquation des compétences tout en planifiant efficacement les situations telles que les baisses d'effectifs pendant les vacances.\n* Adaptez la portée du projet et définissez des objectifs réalistes en fonction de ce qui peut être accompli. Bien que nous souhaitions en faire toujours plus, la perfection est l'ennemie du progrès. Il convient donc de prioriser ce qui compte vraiment pour apporter de la valeur ajoutée de manière efficace. Recherchez les opportunités d'optimisation en identifiant les moyens d'itérer ou d'augmenter la productivité, en ajustant par exemple l'ordre des tâches afin de réduire les dépendances ou en exploitant les composants réutilisables pour rationaliser le développement.\n* Favorisez un dialogue ouvert sur les compromis et les priorités afin de garantir la prise en compte de tous les points de vue. Cette approche collaborative permet d'identifier des solutions créatives pour relever des défis et de parvenir à un consensus sur la meilleure voie à suivre.\n\n***Conseil GitLab** : utilisez une page [wiki](https://docs.gitlab.com/ee/user/project/wiki/) pour compléter votre [Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/). Le wiki vous permet d'inclure des informations contextuelles sur votre roadmap produit, telles que la justification commerciale, des liens vers des études utilisateurs, les scores RICE, ainsi que des détails sur les dépendances ou les risques. Créez des liens directs vers la roadmap pour en faciliter l'accès, et tirez parti de la fonctionnalité de fils de discussion pour encourager la collaboration asynchrone et les retours de votre équipe.*\n\n![Roadmap produit PlanFlow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## Validation continue de la stratégie et mesure de la progression\n\nL'objectif d'une roadmap produit n'est pas seulement de vous permettre de rester sur la bonne voie, mais aussi d'apporter une réelle valeur ajoutée à vos clients. Pour favoriser le partage des retours utilisateurs et des données comportementales en continu, envisagez d'intégrer des points de contact réguliers issus du trio produit en dehors des cycles de sprint. Ces sessions peuvent servir à examiner les informations clés, à analyser les tendances et à s'assurer que la roadmap produit reflète toujours l'évolution des besoins de vos utilisateurs. En fondant les mises à jour de la roadmap sur les informations réelles des utilisateurs, vous optimisez non seulement vos résultats, mais vous vous adaptez également aux réels besoins de vos clients.\n\nLa valeur que vous livrez peut prendre la forme d'une meilleure ergonomie, d'une dette technique réduite ou de nouvelles fonctionnalités. Lorsque le trio produit est aligné sur la vision de la roadmap, il l'est également sur les résultats que vous vous efforcez d'atteindre.\n\nAfin de déterminer si vous serez en mesure d'atteindre ces résultats, vous devez évaluer précisément les résultats escomptés. Les dérives des objectifs, comme l'ajout tardif de user stories, peut retarder votre capacité à fournir de la valeur. Il est également important d'identifier les tâches réalisées qui ne correspondent pas à la roadmap et d'en comprendre les raisons.\n\n### Planification du sprint\n\nPour maintenir l'alignement des parties prenantes impliquées avec votre roadmap produit, vous devez impérativement commencer par une planification réfléchie de votre sprint. \n\nVoici quelques bonnes pratiques à mettre en œuvre afin de permettre à votre équipe de garder le cap et de se concentrer sur la création de valeur :\n\n* Définissez clairement les objectifs souhaités en délimitant précisément leur portée pour assurer une réalisation efficace.  \n* Identifiez les ajouts tardifs ou ajustements potentiels qui pourraient retarder la livraison et prévoyez des marges de sécurité pour maintenir la concentration des équipes.  \n* Mettez-vous d'accord avec votre équipe sur l'ordre des tâches à effectuer afin d'optimiser l'utilisation des ressources, de prendre en compte les compétences disponibles et de réduire les dépendances.\n* Évitez de planifier à 100 % la capacité de l'équipe pour maintenir la concentration et améliorer la confiance dans le respect des délais. Prévoyez une marge (10 à 20 %) pour gérer les imprévus ou les nouvelles opportunités qui pourraient survenir pendant le sprint.\n\n### Exécution du sprint\n\nRespecter votre roadmap pendant le sprint exige de la concentration, une communication adéquate et une évaluation constante. Si l'objectif est de créer de la valeur, il est tout aussi important de s'assurer que le travail en cours correspond aux résultats que vous avez définis et planifiés.\n\n* Validez en permanence le travail en cours par rapport aux résultats de la roadmap pour vous assurer que chaque sprint contribue à la vision globale.\n* Encouragez l'équipe à vérifier régulièrement qu'elle travaille toujours en vue des objectifs et des résultats escomptés.\n* Maintenez une communication ouverte tout au long du sprint. Organisez des réunions quotidiennes ou des mises à jour asynchrones pour identifier rapidement les risques, les imprévus ou les dépendances et procédez aux ajustements nécessaires.\n* Faites preuve d'une rigueur sans faille pour protéger le sprint. Bien qu'il soit naturel de vouloir résoudre les problèmes émergents, le travail non planifié doit être soigneusement évalué afin d'éviter de faire dérailler les priorités convenues.\n* Gérez de manière proactive toute dérive des objectifs. Si de nouvelles tâches apparaissent en cours de sprint, évaluez leur adéquation avec l'objectif défini de manière précise dans la roadmap. Bien que des idées ou des fonctionnalités supplémentaires puissent s'aligner conceptuellement sur le résultat plus large, elles peuvent ne pas s'intégrer dans le plan immédiat de création de valeur. Documentez ces suggestions et évaluez si elles doivent être considérées comme faisant partie d'itérations futures ou comme un plus pour l'avenir, plutôt que de les introduire dans le sprint en cours et de retarder les priorités convenues.\n\n### Rétrospectives de sprint\n\nLors de vos rétrospectives de sprint, prenez le temps de réfléchir avec votre équipe sur la manière dont vous progressez collectivement vers les résultats souhaités. Les questions à se poser sont les suivantes :\n\n* Des tâches imprévues ont-elles été ajoutées pendant le sprint, retardant ainsi votre capacité à créer de la valeur ? Identifiez pourquoi cela s'est produit et quels ajustements peuvent être apportés.\n* Avez-vous livré des tâches qui s'écartaient de la roadmap ? Discutez des raisons de cet écart et des enseignements que vous pouvez en tirer pour la planification future.\n\nDe la planification du sprint aux rétrospectives, il est de la responsabilité de l'équipe de rester concentrée sur l'obtention de résultats tangibles pour les utilisateurs et les parties prenantes. En s'alignant à chaque étape du processus, vous vous assurez que votre roadmap reste un guide clair pour offrir de la valeur de manière efficace et cohérente.\n\n***Conseil GitLab** : utilisez les [graphiques d'avancement burndown](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) de GitLab pour visualiser les progrès et détecter rapidement les écarts, afin d'aider votre équipe à rester concentrée sur l'obtention de résultats.*\n\n![Graphique d'avancement burndow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## Livrer les résultats de la roadmap en toute confiance\n\nHarmoniser les sprints agiles avec les roadmaps stratégiques nécessite une approche intentionnelle, l'adhésion de l'équipe et les outils appropriés. Créer une source unique de vérité, encourager les révisions collaboratives et mesurer la progression vers les résultats vous permet d'aligner l'exécution sur la vision du produit. Grâce aux fonctionnalités de planification de GitLab, vos équipes peuvent transformer tous ces défis en opportunités d'innovation et de croissance.\n\nVous souhaitez aligner vos sprints sur votre roadmap stratégique ? [Commencez un essai gratuit de GitLab](https://about.gitlab.com/fr-fr/free-trial/) dès aujourd'hui et découvrez les fonctionnalités qui vous permettront de garantir que chaque cycle de développement contribue efficacement aux objectifs à long terme de votre entreprise.\n\n## En savoir plus\n\n- [Le nouveau rôle de planificateur de GitLab pour aider les équipes de planification Agile](https://about.gitlab.com/fr-fr/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)\n- [Wiki GitLab : l'outil pour une gestion efficace des connaissances](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)\n- [Comment utiliser GitLab pour le développement logiciel agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/ \"Comment utiliser GitLab pour le développement logiciel agile\")\n- [Comment la planification Agile de GitLab améliore la gestion de projet collaborative ](https://about.gitlab.com/fr-fr/blog/how-gitlab-agile-planning-improves-collaborative-project-management/ \"Comment la planification Agile de GitLab améliore la gestion de projet collaborative \")\n",[801,804,818,802],"workflow","2025-03-06",{"slug":821,"featured":91,"template":808},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"content":823,"config":832},{"title":824,"description":825,"authors":826,"heroImage":827,"date":828,"body":829,"category":676,"tags":830,"updatedDate":831},"GitLab inclut désormais un rôle de planificateur pour aider les équipes de planification Agile","Découvrez comment le nouveau rôle de planificateur dans GitLab aide les équipes Agile à gérer les workflows de planification.",[796],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2024-11-25","GitLab a créé un nouveau rôle au sein de sa plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") : le planificateur. Cette nouveauté s'aligne avec la stratégie de GitLab, qui consiste à fournir des contrôles d'accès flexibles et basés sur les rôles, comme en témoignent les [rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html). Le rôle de planificateur permet aux équipes de développement logiciel et aux utilisateurs spécialisés dans la planification d'accéder aux outils dont ils ont besoin pour gérer leurs workflows Agile, tout en limitant les autorisations trop étendues susceptibles d'introduire des risques inutiles. En adaptant l'accès aux besoins spécifiques des utilisateurs, le rôle de planificateur garantit la productivité des équipes, tout en maintenant la sécurité et la conformité, conformément au [principe de moindre privilège](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\n## Pourquoi avons-nous créé le rôle de planificateur ?\n\nL'idée nous est venue des retours de nos clients et de nos équipes internes. Il est souvent mentionné que, malgré ses outils complets pour la planification et la gestion des [cycles de développement Agile](https://about.gitlab.com/fr-fr/solutions/agile-delivery/ \"Livraison agile\"), GitLab pouvait manquer de contrôles d'accès plus spécifiques basés sur les rôles. Les chefs de produit, les responsables de projet et les autres utilisateurs impliqués dans la planification ont souvent besoin d'accéder aux fonctionnalités de planification, sans nécessiter des autorisations de développement complètes. Au contraire, il n'est pas souhaitable d'étendre cet accès, car il entraîne une augmentation des risques de sécurité et d'erreurs, telles que des modifications involontaires du code ou des configurations contenant des données sensibles. \n\nNous avons donc mené des entretiens avec des utilisateurs, des analyses concurrentielles et des recherches approfondies, et validé l'intérêt d'un rôle qui accorde un accès complet aux outils de planification, tout en limitant l'accès aux fonctionnalités de développement pour garantir la sécurité.\n\n## Que propose le rôle de planificateur ?\n\nLe rôle de planificateur est un rôle hybride à mi-chemin entre [l'invité et le rapporteur](https://docs.gitlab.com/ee/user/permissions.html#roles). Il est toutefois conçu spécifiquement pour les membres d'équipe qui ont besoin d'accéder aux workflows de planification. \n\nVoici ses particularités :\n\n* L'accès aux principaux outils de planification tels que les epics, les roadmaps, les tableaux des tickets et les [OKR](https://docs.gitlab.com/ee/user/okrs.html) (*certaines fonctionnalités peuvent nécessiter une licence GitLab Premium ou Ultimate*)\n* Une sécurité renforcée qui limite l'accès non requis aux fonctionnalités de développement sensibles\n* Une compatibilité avec le module d'extension GitLab Enterprise Agile Planning, permettant aux équipes de bénéficier d'un accès personnalisé aux outils de planification sans compromettre la sécurité et le contrôle. (*Ce rôle est néanmoins disponible avec toutes les licences*)\n\nLe rôle de planificateur est disponible avec toutes les solutions GitLab, y compris l'édition SaaS de GitLab, GitLab Dedicated et GitLab Auto-géré. Tous les clients bénéficient ainsi de cet accès personnalisé.\n\nCe rôle donne aux équipes la possibilité d'aligner les autorisations sur les fonctions du poste afin d'équilibrer accessibilité et sécurité.\n\n## Comment le rôle de planificateur facilite-t-il les pratiques Agile ?\n\nDans le [développement logiciel Agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/), il est essentiel de s'assurer que chaque membre de l'équipe dispose des outils et des autorisations adéquates pour optimiser l'efficacité du workflow. Le rôle de planificateur facilite cette approche : il permet la pleine participation aux étapes de planification du cycle de développement logiciel des membres de l'équipe qui en sont responsables, sans affecter des domaines tels que le développement ou le déploiement.\n\nDe la création et de la gestion des epics à la définition des roadmaps, il fournit aux équipes agiles les outils nécessaires pour maintenir leur alignement et leur productivité.\n\n## Une approche centrée sur les clients\n\nCe rôle n'a pas été créé en vase clos. Nous avons impliqué notre communauté à chaque étape du processus. Grâce à des enquêtes, des entretiens et des tests, nous avons ajusté les autorisations pour qu'elles répondent aux besoins réels des chefs de produit et des responsables de projet.\n\nLe rôle de planificateur s'inscrit également dans la mission de longue date de GitLab, qui vise à être une plateforme de référence pour les équipes agiles, en offrant aux entreprises la flexibilité et le contrôle nécessaires pour mettre en œuvre des [méthodologies agiles](https://about.gitlab.com/fr-fr/topics/agile-delivery/agile-methodology/ \"Qu'est-ce que la méthodologie Agile ?\") à grande échelle.\n\n## Les retours et l'engagement de la communauté\n\nNous apprécions votre contribution et vous encourageons à nous donner votre avis sur le nouveau rôle de planificateur. Vos retours sont essentiels pour nous aider à affiner et à améliorer votre expérience sur la plateforme DevSecOps de GitLab. N'hésitez pas à consulter notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/503817) pour nous faire part de vos réflexions et suggestions.\n\n## Commencez à planifier avec GitLab dès aujourd'hui !\n\nLe rôle de planificateur n'est qu'une des nombreuses façons dont GitLab permet aux équipes de développement logiciel de planifier, de collaborer et de livrer des logiciels efficacement. Que vous cherchiez à optimiser vos workflows de gestion de produits, à renforcer la collaboration au sein de votre équipe ou à uniformiser vos pratiques Agile, GitLab vous fournit les outils nécessaires pour votre réussite.\n\n> Vous souhaitez découvrir toute la puissance de GitLab ? [Essayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/) et planifiez vos futurs projets avec notre nouveau rôle de planificateur. ",[801,802,803,771],"2024-12-03",{"slug":833,"featured":91,"template":808},"introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"category":684,"slug":688,"posts":835},[836,850,862],{"content":837,"config":848},{"title":838,"description":839,"authors":840,"heroImage":842,"date":843,"body":844,"category":688,"tags":845},"Améliorer la qualité des applications avec la génération de tests alimentée par l'IA","Découvrez comment GitLab Duo combiné à Amazon Q améliore le processus d'assurance qualité en générant automatiquement des tests unitaires complets.",[841],"Cesar Saavedra","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749659604/Blog/Hero%20Images/Screenshot_2024-11-27_at_4.55.28_PM.png","2025-07-15","Vous savez à quel point la qualité des applications est essentielle pour vos clients et votre réputation. Cependant, garantir cette qualité avec des tests complets peut s’avérer complexe. Vous êtes confronté à des processus manuels chronophages, une couverture de test incohérente au sein de votre équipe, ou des problèmes qui parviennent à passer à travers les mailles du filet. Il est ainsi frustrant de voir votre notation chuter à cause d’une assurance qualité qui devient un goulot d'étranglement plutôt qu'une protection.\n\nC'est là que [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) peut transformer votre processus d’assurance qualité. Cette fonctionnalité alimentée par l'IA peut générer automatiquement des tests unitaires complets pour votre code, accélérant considérablement votre workflow d'assurance qualité. Au lieu de passer des heures à écrire des tests manuellement, vous pouvez laisser l'IA analyser votre code et créer des tests qui garantissent une couverture optimale et une qualité constante au sein de votre application.\n\n## Comment fonctionne GitLab Duo combiné à Amazon Q ?\n\nLorsque vous travaillez sur une nouvelle fonctionnalité, vous commencez par sélectionner la classe Java que vous avez ajoutée à votre projet via une merge request. Il vous suffit de naviguer vers votre merge request et de cliquer sur l'onglet « Modifier » pour voir le nouveau code que vous avez ajouté.\n\nEnsuite, vous invoquez Amazon Q en saisissant une commande d'action rapide. Tout ce que vous devez faire est de renseigner `/q test` dans la zone de commentaire du ticket. C'est aussi simple que cela : juste une barre oblique, la lettre « q », et le mot « test ».\n\nUne fois que vous avez appuyé sur la touche Entrée, Amazon Q entre en action. Il analyse votre code sélectionné, comprend sa structure, sa logique et son objectif. L'IA examine les méthodes de votre classe, les dépendances, et les cas limites potentiels pour déterminer quels tests sont nécessaires.\n\nEn quelques instants, Amazon Q génère une couverture de tests unitaires complète pour votre nouvelle classe. Il crée des tests qui couvrent non seulement le chemin heureux (« happy path »), mais aussi les cas limites et les conditions d'erreur que vous auriez pu négliger. Les tests générés suivent les modèles et conventions existants de votre projet, garantissant qu'ils s'intègrent parfaitement à votre code source.\n\n## Pourquoi utiliser GitLab Duo combiné à Amazon Q ?\n\nVous avez commencé avec le défi suivant : maintenir des applications de haute qualité tout en gérant les contraintes de temps et les pratiques de test incohérentes. GitLab Duo combiné à Amazon Q répond à ce défi en automatisant le processus de génération de tests, garantissant une couverture de code optimale et des normes de test cohérentes. Résultat ? Les problèmes sont détectés avant le déploiement, vos applications maintiennent leur qualité, et vous pouvez développer des logiciels plus rapidement sans sacrifier la fiabilité.\n\nAvantages clés de cette fonctionnalité :\n\n* Une réduction du temps consacré à l'écriture de tests unitaires\n* Une couverture de tests complète sur l'ensemble de votre code source\n* Une qualité de tests constante pour tous les membres de votre équipe\n* Une détection des problèmes avant qu'ils n'atteignent l’environnement de production\n* Une accélération de votre vitesse de développement\n\nVous souhaitez en savoir plus sur cette fonctionnalité ? Découvrez comment GitLab Duo combiné à Amazon Q transforme votre processus d'assurance qualité et consultez notre [page partenaire GitLab et AWS](https://about.gitlab.com/partners/technology-partners/aws/ \"Page partenaire GitLab et AWS\") pour obtenir des informations détaillées.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/pxlYJVcHY28?si=MhIz6lnHxc6kFhlL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### En savoir plus sur GitLab Duo combiné à Amazon Q\n\n* [GitLab Duo combiné à Amazon Q : quand le DevSecOps rencontre l’IA agentique](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai/)\n* [GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS disponible à tous les utilisateurs](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n* [GitLab Duo combiné à Amazon Q : créez de nouvelles fonctionnalités en quelques minutes](https://about.gitlab.com/fr-fr/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/) \n* [GitLab Duo combiné à Amazon Q : optimisez vos revues de code](https://about.gitlab.com/fr-fr/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q/)",[846,847,720],"AI/ML","AWS",{"featured":6,"template":808,"slug":849},"enhance-application-quality-with-ai-powered-test-generation",{"content":851,"config":860},{"heroImage":852,"date":853,"title":854,"description":855,"authors":856,"body":858,"category":688,"tags":859},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750687578/esmflevxk5bf3eezjhwk.png","2025-07-03","GitLab Duo Agent Platform : le DevSecOps intelligent","La plateforme DevSecOps GitLab Duo Agent Platform orchestre la collaboration entre développeurs et agents d'IA tout au long du SDLC avec l'IA agentique.",[857],"Bill Staples","Découvrez GitLab Duo Agent Platform, la prochaine évolution de GitLab Duo Workflow : cette plateforme innovante étend les fonctionnalités d'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\") à l'ensemble du cycle de développement logiciel et permet aux équipes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") de travailler en parallèle avec plusieurs agents d'IA spécialisés.\n\nVoici à quoi pourrait ressembler une de vos journées de travail :\n\n* Vous demandez à un agent d'IA d'étudier en détail un epic en cours, de résumer les contributions de la semaine précédente et de suggérer une publication pour annoncer les dernières fonctionnalités.\n* En parallèle, vous déléguez à plusieurs autres agents d'IA l'analyse de bogues d'accessibilité en leur demandant d'appliquer directement les corrections nécessaires dans le code.\n* Pendant ce temps, un autre agent d'IA relit vos modifications complexes et vous fournit des commentaires et suggestions avant une revue de code en bonne et due forme par un membre de votre équipe.\n* Enfin, lorsque l'équipe de sécurité vous signale une nouvelle vulnérabilité qui doit faire l'objet d'une investigation dans l'ensemble de votre projet, vous confiez cette tâche à votre agent d'IA dédié à la sécurité.\n\nToutes ces opérations sont exécutées simultanément pour vous aider à vous concentrer sur des tâches à forte valeur ajoutée : décisions d'architecture, résolution créative de problèmes et travail technique stratégique. Avec GitLab Duo Agent Platform, vous pouvez déléguer des tâches à cinq, dix, voire cent agents spécialisés, qui disposent tous du contexte complet de votre projet : votre code, les job logs CI, les tâches de planification, et bien plus encore. Vous automatisez ainsi vos tâches fastidieuses afin de pouvoir vous concentrer sur le travail qui vous passionne vraiment.\n\n**Il ne s'agit pas là de remplacer les équipes de développement, mais d'amplifier leur créativité et leur expertise en éliminant les points de friction liés aux tâches routinières.** C'est l'avenir que nous façonnons avec GitLab Duo Agent Platform.\n\n## Qu'est-ce que GitLab Duo Agent Platform ?\n\nGitLab Duo Agent Platform facilite la collaboration entre plusieurs équipes de développement et agents d'IA tout au long du cycle du développement logiciel, afin de les aider à améliorer considérablement leur productivité et à réduire la durée de leurs cycles de livraison.\n\nReposant sur la base sécurisée de GitLab, GitLab Duo Agent Platform est personnalisable et extensible. La plateforme permet aux équipes de développement de créer des agents capables de résoudre toutes sortes de problématiques d'ingénierie logicielle, en tirant parti du contexte global du projet à chaque étape du développement logiciel.\n\nGitLab Duo Agent Platform ne se limite pas à la création de code. La plateforme propose des agents spécialisés et des workflows personnalisés qui peuvent vous aider à réaliser une liste presque illimitée de tâches, notamment :\n\n* L'implémentation de tickets\n* Les migrations à grande échelle/mises à niveau des dépendances\n* La rédaction automatique de documentations et de publications pour annoncer la sortie de nouvelles fonctionnalités\n* La réparation de [pipelines en échec](https://about.gitlab.com/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/ \"Echec de pipeline\")\n* La recherche assistée lors d'incidents\n* La recherche approfondie de statuts et d'informations sur différents sujets\n* La gestion du backlog\n* La résolution de vulnérabilités\n* Les revues de certains types de code spécifiques (p. ex., base de données)\n* La création rapide d'outils internes à partir des composants déjà disponibles\n* Et plus encore !\n\nVous pourrez utiliser nos agents prêts à l'emploi, mais aussi les personnaliser et enrichir leurs capacités. Nous testons actuellement la version bêta de GitLab Duo Agent Platform avec l'aide de dizaines de clients et nous ouvrirons bientôt l'accès à d'autres équipes.\n\nDécouvrez une démonstration de GitLab Duo Agent Platform :\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1095679084?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Platform Demo Clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Outils, modèles et agents : à vous de choisir\n\nConformément à notre engagement de proposer une plateforme ouverte, les agents GitLab interagissent de manière fluide avec les outils d'écriture de code de votre choix via les protocoles Model Context Protocol (MCP) et Agent2Agent (A2A), que vous utilisiez Cursor, Claude Code, Windsurf, OpenAI Codex ou d'autres.\n\nLa plateforme accepte les contributions de code de n'importe quel outil de développement de votre pile, que ce code ait été écrit par un développeur ou généré par un agent d'IA. Vos workflows existants et vos outils préférés continueront à fonctionner de manière homogène lorsque vous intégrerez les fonctionnalités agentiques.\n\nGitLab Duo Agent Platform fonctionne avec les modèles de langage approuvés qui [répondent à nos critères de sélection](https://about.gitlab.com/fr-fr/ai-transparency-center/#ai-continuity-plan). Pour les entreprises qui ont des exigences strictes en matière de sécurité, la plateforme prend en charge les modèles de GitLab Duo Self-Hosted approuvés qui s'exécutent dans des environnements air-gapped. Vos exigences en matière d'infrastructure et vos règles de sécurité ne limiteront pas votre capacité à tirer parti du développement agentique.\n\n## Le contexte fait la différence, vos agents GitLab Duo aussi\n\nLa différence entre un outil d'IA utile et un agent véritablement intelligent se résume au contexte. Avec GitLab Duo Agent Platform, les agents ne travaillent pas de manière isolée : ils sont profondément intégrés à la plateforme de développement.\n\nChaque agent comprend automatiquement la vue d'ensemble de vos projets, y compris vos tickets ouverts et leur historique, les merge requests qui les ont résolus, la structure et la logique de votre code, la configuration de vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), les risques de sécurité détectés, les exigences de conformité ainsi que les relations complexes entre tous ces éléments.\n\nTout comme les membres de votre équipe, les agents disposent de tout le contexte nécessaire pour vous aider à livrer des logiciels sécurisés plus rapidement. Ils ne se contentent pas de répondre à des questions sur le code, ils sont également en mesure de fournir des analyses sur l'impact potentiel d'un changement sur votre pipeline de déploiement ou de suggérer des améliorations de sécurité en fonction de vos règles de conformité. Plus votre équipe travaillera au sein de la plateforme DevSecOps de GitLab, plus vos agents deviendront intelligents.\n\n## Des équipes plus productives avec les agents d'IA\n\nIl est presque aussi simple d'établir un climat de confiance avec les agents d'IA qu'avec les nouveaux membres d'une équipe. Vous devez tout d'abord vérifier leur travail, puis comprendre leur approche et enfin augmenter progressivement leurs responsabilités à mesure qu'ils prouvent leurs compétences.\n\nC'est ainsi que nous avons pensé notre workflow d'approbation des agents. Avant qu'un agent apporte des modifications à votre code ou à votre environnement, il vous présentera un plan clair : sa compréhension du problème, l'approche qu'il prévoit d'adopter et les actions spécifiques qu'il souhaite effectuer. Vous aurez ensuite la possibilité d'examiner l'approche qu'il aura choisie, de l'approuver ou de donner de nouvelles instructions si nécessaire. Au fil du temps, les agents fourniront un travail de plus en plus qualitatif, vous pourrez leur accorder une plus grande autonomie pour la réalisation des tâches répétitives, tout en continuant à superviser les tâches complexes ou critiques.\n\n## Une plateforme conçue pour la communauté et adaptée à vos besoins\n\nGitLab a toujours évolué grâce aux contributions de sa communauté. Cette année, nous avons franchi une étape importante, car les contributions de nos clients ont atteint un niveau record. Nous étendons désormais cette même énergie collaborative aux agents d'IA grâce à notre approche de framework ouvert.\n\nGitLab Duo Agent Platform ne se limite pas aux agents que nous créons, mais vous donne, à vous ainsi qu'à la communauté au sens large, les moyens de créer des agents spécialisés capables de résoudre vos défis d'ingénierie uniques. Que vous ayez besoin d'un agent qui comprend vos normes de codage spécifiques, qui s'intègre à votre chaîne d'outils personnalisée ou qui gère des tâches propres à votre domaine, la plateforme vous fournira les éléments de base nécessaires pour y parvenir.\n\nCe modèle crée un cercle vertueux qui tire parti de la force de la communauté GitLab grâce au partage mondial, à l'instar de notre [catalogue CI/CD](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/). La diversité des expériences de nos clients est source d'innovation. Les retours que nous recevons des entreprises renforcent la fiabilité et la sécurité. Et les solutions partagées profitent à tous. C'est cette même approche collaborative qui a fait le succès de GitLab et qui s'applique désormais au développement agentique.\n\n## Premiers pas avec GitLab Duo Agent Platform\n\nSi vous avez testé [GitLab Duo Agentic Chat](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/), désormais inclus dans chaque licence utilisateur GitLab.com GitLab 18 Premium et Ultimate, vous avez déjà eu un aperçu des possibilités offertes par l'utilisation d'agents d'IA dans votre workflow de développement.\n\nPour découvrir les capacités de GitLab Duo Agent Platform et les projets sur lesquels nous travaillons actuellement, visionnez les [démonstrations incluses dans notre événement de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/).\n\nVous souhaitez être parmi les premiers à l'essayer ? Inscrivez-vous sur la [liste d'attente de la version bêta de GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/agent-platform/). Cet été, nous ouvrirons l'accès à d'autres équipes. De nouvelles fonctionnalités d'agent sortiront tout au long de l'année dans les prochaines versions de GitLab 18. Nous prévoyons de proposer GitLab Duo Agent Platform en disponibilité générale cet hiver.\n\n*Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter que celles-ci ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article sont susceptibles de changer ou d'être retardés. Le développement, la sortie et le calendrier de tout produit ou de toute fonctionnalité restent à la seule discrétion de GitLab Inc.*\n\n## En savoir plus\n\n- [Du vibe coding à l'IA agentique : une roadmap pour les responsables techniques](https://about.gitlab.com/the-source/ai/from-vibe-coding-to-agentic-ai-a-roadmap-for-technical-leaders/)\n\n- [Automatisation DevOps et agents d'IA](https://about.gitlab.com/topics/agentic-ai/devops-automation-ai-agents/)\n\n- [Développement logiciel augmenté par l'IA : l'IA agentique dédiée au DevOps](https://about.gitlab.com/topics/agentic-ai/ai-augmented-software-development/)\n\n- [Analyse de code pilotée par l'IA pour une sécurité renforcée](https://about.gitlab.com/topics/agentic-ai/ai-code-analysis/)\n",[846,720,748,771],{"featured":6,"template":808,"slug":861},"gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"content":863,"config":872},{"title":864,"description":865,"authors":866,"heroImage":867,"date":868,"body":869,"category":688,"tags":870},"GitLab Duo combiné à Amazon Q : optimisez vos revues de code","Découvrez comment optimiser vos revues de code avec des agents d’IA capables d'analyser automatiquement vos merge requests et de vous fournir des commentaires complets sur les bogues, la lisibilité et les normes de codage.",[841],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","2025-06-27","Les revues de code sont essentielles pour détecter les bogues, améliorer la lisibilité du code et garantir le respect des normes de codage. Elles peuvent toutefois constituer un goulot d'étranglement majeur qui ralentit votre workflow. Lorsque vous devez livrer rapidement des fonctionnalités, attendre que plusieurs membres de l'équipe examinent votre code peut vite devenir une source de frustration. Entre les discussions interminables, les conflits de calendrier et le temps nécessaire pour que tout le monde soit sur la même longueur d'onde, une revue de code simple peut facilement s'étendre sur plusieurs jours, voire plusieurs semaines.\n\nAvec [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), ce scénario appartient maintenant au passé. Notre nouvel outil d'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\") dédié aux clients AWS intervient à chaque étape du cycle de développement logiciel pour effectuer une revue complète de votre code en une fraction du temps qu'il vous faudrait, à vous et vos collègues. En tirant parti des capacités avancées de l'IA agentique, GitLab Duo combiné à Amazon Q rationalise l'ensemble de votre workflow de revue de code et maintient la qualité et la rigueur dont votre équipe a besoin. Vous disposez ainsi d'un relecteur expérimenté et disponible à tout moment, capable d'analyser instantanément votre code, de détecter les problèmes et de fournir des recommandations pertinentes et exploitables.\n\n## Lancement d'une revue de code\n\nComment fonctionne GitLab Duo combiné à Amazon Q ? Imaginons que vous venez de finaliser la mise à jour d'une fonctionnalité via une merge request répertoriant toutes les modifications que vous avez apportées au code. Au lieu de contacter vos collègues et d'attendre qu'ils soient disponibles pour relire votre travail, il vous suffit de saisir une commande rapide directement dans les commentaires : « /q review ». Cette commande suffit pour que l’IA entre en action. \n\n![Déclenchement d'une revue de code à l'aide de GitLab Duo combiné à Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\nL'agent Amazon Q s'active immédiatement et analyse vos modifications. Un message de confirmation vous indique que la revue de code est en cours et, en quelques instants, l'IA examine votre travail ligne par ligne, à la recherche d'erreurs, de bogues et d'anomalies potentiels.\n\nUne fois la revue de code terminée, vous recevez des commentaires détaillés qui couvrent tous les points critiques, conformément aux standards de votre équipe en matière de codage : détection de bogues, amélioration de la lisibilité, erreurs de syntaxe. Chaque retour de l'agent d'IA est contextualisé, avec des suggestions précises pour résoudre ces problèmes. Il vous aide à comprendre facilement ce qui nécessite votre attention et pourquoi.\n\nL'intérêt de cette approche basée sur l'IA agentique est qu'elle gère tous les aspects fastidieux de la revue de code afin que vous puissiez vous concentrer sur ce qui compte le plus : créer des logiciels performants. Vous bénéficiez des avantages d'une revue de code approfondie (détection des bogues améliorée, cohérence du code et code de meilleure qualité) sans perdre de temps. Vos délais de déploiement s'en trouvent considérablement réduits, car vous n'avez plus à patienter pour votre revue de code. Toute votre équipe gagne ainsi en productivité.\n\n## Pourquoi utiliser GitLab Duo combiné à Amazon Q ?\n\nGitLab Duo combiné à Amazon Q transforme votre workflow de développement en profondeur :\n\n* Des revues de code ultra-rapides, sans compromis sur la qualité\n* Une application cohérente des normes sur l'ensemble de votre code source\n* Des commentaires instantanés pour résoudre les problèmes avant qu'ils n'atteignent l'environnement de production\n* Des délais de déploiement réduits pour livrer de nouvelles fonctionnalités, plus rapidement\n* Plus de temps pour se concentrer sur la résolution créative des problèmes plutôt que sur des revues de code répétitives\n\nRegardez cette vidéo et découvrez comment GitLab Duo combiné à Amazon Q peut optimiser votre processus de revue de code :\n\n\u003C!-- blank line --> \u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure> \u003C!-- blank line -->\n\nPour en savoir plus sur GitLab Duo combiné à Amazon Q, [contactez votre représentant GitLab](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/).",[846,802,871,771,803,284,847,804],"code review",{"featured":6,"template":808,"slug":873},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"category":696,"slug":700,"posts":875},[876],{"content":877,"config":886},{"title":878,"description":879,"authors":880,"heroImage":827,"date":882,"body":883,"category":700,"tags":884,"updatedDate":885},"Nouvelles limites de Docker Hub : vos pipelines GitLab CI/CD sont impactés","Les nouvelles limites de Docker Hub relatives aux pulls d'images vont affecter les pipelines GitLab. Voici ce qu'il faut savoir.",[881],"Tim Rizzi","2025-03-24","Le 1er avril 2025, Docker va mettre en place de nouvelles [limites de débit relatives aux pulls d'images](https://docs.docker.com/docker-hub/usage/) sur Docker Hub, susceptibles d'impacter de manière significative les pipelines CI/CD de développement logiciel, y compris ceux qui s'exécutent sur GitLab. Le changement le plus notable : un plafond fixé à 10 pulls d'images par heure pour les utilisateurs non authentifiés.\n\n## Quels sont les changements attendus ?\n\nÀ compter du 1er avril, Docker va appliquer les limites strictes suivantes aux pulls d'images (téléchargements d'images) :\n\n| Type d'utilisateur | Limite de pulls d'images par heure | Nombre de dépôts publics | Nombre de dépôts privés |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business, Team, Pro (authentifié) | Illimité (utilisation raisonnable) | Illimité | Illimité |\n| Personal (authentifié) | 100 | Illimité | Jusqu'à 1 |\n| Utilisateurs non authentifiés | 10 par adresse IPv4 ou sous-réseau IPv6/64 | Non applicable | Non applicable |\n\nCes nouveaux quotas sont particulièrement importants pour les raisons suivantes :\n- Le proxy de dépendances de GitLab effectue actuellement des pulls à partir de Docker Hub en tant qu'utilisateur non authentifié.\n- La plupart des pipelines CI/CD qui n'utilisent pas le proxy de dépendances effectuent des pulls directement à partir de Docker Hub en tant qu'utilisateurs non authentifiés.\n- Pour les runners hébergés sur GitLab.com, le partage d'une même adresse IP ou sous-réseau par plusieurs utilisateurs les soumet collectivement à cette limite.\n\n## Quel impact sur les utilisateurs de GitLab ?\n\n**Impact sur les pulls directs depuis Docker Hub**\n\nSi vos pipelines CI/CD effectuent des pulls directement depuis Docker Hub sans authentification, ils seront limités à 10 pulls d'images par heure et par adresse IP. Dans le cas de pipelines exécutés fréquemment ou sur plusieurs projets partageant la même infrastructure de runner, cette limite sera rapidement atteinte, ce qui entraînera des échecs de pipeline.\n\n**Impact sur le proxy de dépendances de GitLab**\n\nLa fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache des images Docker dans GitLab pour accélérer les pipelines et réduire la dépendance aux registres externes. Cependant, dans sa version actuelle, ce proxy effectue des pulls d'images depuis Docker Hub en tant qu'utilisateur non authentifié, ce qui signifie qu'il est lui aussi soumis à la limite des 10 pulls d'images par heure.\n\n**Impact sur les runners hébergés**\n\nSur GitLab.com, les runners hébergés s'appuient sur le [cache pull-through de Google Cloud](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=fr), qui met en miroir les images fréquemment téléchargées. Cela permet d'éviter les limites de débit, comme pour les images de job définies comme `image:` ou `services:` dans votre fichier `.gitlab-ci.yml`.\n\nTout se complique légèrement lorsque les images sont téléchargées dans l'environnement du runner. Le cas le plus courant de pull d'images pendant l'exécution du runner concerne la création d'une image à l'aide de Docker-in-Docker ou de Kaniko. Dans ce scénario, l'image Docker Hub définie dans votre `Dockerfile` fait l'objet d'un pull directement depuis Docker Hub. Elle est donc susceptible d'être affectée par les limites de débit. \n\n## Comment GitLab répond à ces nouveaux quotas ?\n\nNous travaillons activement à la recherche de solutions pour atténuer les impacts liés à ces nouvelles limites :\n\n* **Authentification du proxy de dépendances :** nous avons ajouté la prise en charge de l'authentification Docker Hub dans la [fonctionnalité de proxy de dépendances de GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/331741). Cela permettra à ce dernier de télécharger des images depuis Docker Hub en tant qu'utilisateur authentifié, et ainsi d'augmenter considérablement les limites de débit.  \n* **Mise à jour de la documentation :** nous avons actualisé notre [documentation](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials) afin de fournir des instructions claires sur la configuration de l'authentification des pipelines pour Docker Hub.\n* **Préparation de l'infrastructure interne :** nous préparons notre infrastructure GitLab.com afin de réduire au maximum l'impact de ces limites sur les runners hébergés.\n\n## Comment s'y préparer ? \n\n**Option 1 : configurez l'authentification Docker Hub dans vos pipelines**\n\nSi vos pipelines effectuent des pulls directement depuis Docker Hub, vous pouvez configurer l'authentification afin d'augmenter votre limite de taux à 100 pulls d'images par heure (ou illimitée avec un abonnement payant à Docker Hub).\n\nPour cela, ajoutez vos identifiants de connexion Docker Hub aux variables CI/CD de votre projet ou groupe (ne les insérez pas directement dans le fichier `.gitlab-ci.yml`). Consultez les instructions détaillées de notre [documentation sur l'utilisation d'images Docker](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials) pour configurer correctement la variable CI/CD `DOCKER_AUTH_CONFIG`.\n\n**Option 2 : utilisez le registre de conteneurs GitLab**\n\nEffectuez un push des images Docker que vous utilisez le plus souvent dans votre [registre de conteneurs GitLab](https://docs.gitlab.com/user/packages/container_registry/) afin d'éviter de devoir effectuer un pull d'images depuis Docker Hub pendant l'exécution des pipelines CI/CD. Procédez comme suit :\n\n1. Effectuez un pull de l'image depuis Docker Hub.\n2. Attribuez-lui un tag adapté à votre registre de conteneurs GitLab.\n3. Effectuez un push de l'image dans votre registre de conteneurs GitLab.\n4. Mettez à jour vos pipelines pour qu'ils effectuent un pull de l'image depuis le registre de conteneurs GitLab.\n\n```\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nPuis ajoutez cette ligne de commande dans votre fichier `.gitlab-ci.yml` :\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**Option 3 : utilisez le proxy de dépendances de GitLab**\n\nLa fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache les images Docker, tout en servant de proxy entre vos pipelines CI/CD et les registres Docker Hub, réduisant ainsi la dépendance aux registres externes et les risques liés aux limites de débit.  \n\nOptions d'authentification actuelles :\n* GitLab 17.10 : configurez l'authentification Docker Hub pour le proxy de dépendances à l'aide de l'[API GraphQL](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api).\n* GitLab 17.11 : utilisez la nouvelle interface de configuration dans les paramètres de votre groupe (déjà disponible sur GitLab.com).\n\nUne fois l'authentification correctement configurée, vous pouvez procéder comme suit :\n\n1. Configurez les identifiants de connexion Docker Hub dans les paramètres du proxy de dépendances de votre groupe :\n  - Pour GitLab 17.11+ (ou la version actuelle de GitLab.com) : accédez aux paramètres de votre groupe > Paquets et registres > Proxy de dépendances.\n  - Pour GitLab 17.10 : utilisez l'API GraphQL afin de configurer l'authentification.\n2. Mettez à jour vos pipelines de façon à ce qu'ils utilisent les URL du proxy de dépendances pour la configuration de votre pipeline CI/CD :\n`image:${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**Option 4 : envisagez d'acheter un abonnement payant à Docker Hub**\n\nPour les équipes qui utilisent Docker Hub de manière intensive, la mise à niveau vers un abonnement Docker payant (Team ou Business) permet d'accéder à un nombre illimité de pulls, ce qui peut s'avérer la solution la plus simple.\n\n## Comment limiter l'impact des nouveaux quotas de Docker Hub ?\n\nQuelle que soit l'option que vous choisissez, tenez compte de ces bonnes pratiques pour réduire au maximum l'impact des nouvelles limites de débit imposées par Docker Hub :\n\n* Utilisez des tags d'image spécifiques au lieu de `latest` pour éviter les pulls inutiles.\n* Consolidez vos fichiers Docker de façon à ce qu'ils réutilisent les mêmes images de base dans tous vos projets.\n* Planifiez l'exécution des pipelines les moins critiques en dehors des heures de pointe.\n* Tirez parti intelligemment de la mise en cache pour éviter d'effectuer maintes fois un pull des mêmes images.\n\n**Remarque :** selon la [documentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition) de Docker Hub, le nombre de pulls augmente dès que vous effectuez le pull d'un manifeste d'image, et non en fonction de la taille de l'image ou du nombre de couches.\n\n## Calendrier et prochaines étapes\n\n**Dès maintenant**\n  * Mettez en œuvre l'authentification pour les pulls directs depuis Docker Hub.\n  * Les utilisateurs de GitLab.com peuvent déjà configurer l'authentification Docker Hub pour le proxy de dépendances en utilisant :\n    * l'API GraphQL, ou\n    * l'interface utilisateur dans les paramètres de groupe.\n  * Les utilisateurs de GitLab Self-Managed 17.10 peuvent configurer l'authentification du proxy de dépendances à l'aide de l'API GraphQL.\n\n**1er avril 2025**\n  * Les limites de débit de Docker Hub entrent en vigueur.\n\n**17 avril 2025**\n  * Sortie de GitLab 17.11 qui prendra en charge l'authentification du proxy de dépendances via l'interface utilisateur pour les instances GitLab Self-Managed. \n\nNous vous recommandons d'appliquer ces mesures bien dès maintenant pour éviter des échecs de pipelines inattendus. Pour la plupart des utilisateurs, configurer le proxy de dépendances avec l'authentification Docker Hub est la solution la plus efficace à long terme.\n\n> Vous avez des questions ou besoin d'aide pour la mise en œuvre ? Consultez [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/526605) dans lequel notre équipe fournit une assistance dédiée à ces changements.",[109,748,802],"2025-03-28",{"slug":887,"featured":91,"template":808},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":708,"slug":712,"posts":889},[890,906,920],{"content":891,"config":904},{"title":892,"description":893,"authors":894,"heroImage":896,"date":897,"body":898,"category":712,"tags":899,"updatedDate":903},"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.",[895],"Fatima Sarah Khalid","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","2025-01-30","L'année dernière, plus de 800 membres de la communauté ont apporté plus de 3 000 contributions à GitLab. Parmi ces contributeurs figurent des membres issus d'équipes travaillant pour des entreprises internationales comme Thales, Scania et Kitware qui contribuent à façonner l'avenir de GitLab grâce au [Programme Co-Create](https://about.gitlab.com/community/co-create/). Dans le cadre de ce programme de développement collaboratif mis en place par GitLab, les clients travaillent directement avec les ingénieurs de GitLab pour ajouter des fonctionnalités importantes à la plateforme.\n\nÀ travers des ateliers, des sessions de programmation en binôme et une assistance en continu, les participants au programme acquièrent une connaissance pratique de l'architecture et du code base de GitLab tout en résolvant des problèmes ou en améliorant des fonctionnalités existantes.\n\n*« Notre expérience avec le Programme Co-Create a été incroyable »*, déclare Sébastien Lejeune, Open Source Advocate chez Thales. *« Il n'a fallu que deux mois entre le moment où nous avons discuté de notre contribution avec un ingénieur de l'équipe Contributor Success de GitLab et le moment où nous l'avons intégrée à la version de GitLab. »*\n\nDans cet article, découvrez comment nos clients tirent parti du Programme Co-Create pour transformer leurs idées en code, tout en se formant et en apportant leur contribution.\n\n## Qu'est-ce que le Programme Co-Create ? \n\nAvec le [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit), les contributeurs peuvent facilement faire leurs premiers pas sur la plateforme de développement de GitLab. *« Ce que les nouveaux contributeurs doivent comprendre, c'est que rien n'est définitif avec le GDK »*, indique Hook. *« Si un contributeur effectue une modification qui ne fonctionne pas, il peut l'annuler ou tout recommencer. Le GDK permet d'expérimenter, de tester et d'apprendre sans se soucier de l'environnement. »*\n\nChaque entreprise participant au Programme Co-Create de GitLab reçoit une assistance tout au long de son parcours de contribution :\n\n- __Atelier d'intégration technique__ : session dédiée à la mise en place du GitLab Development Kit (GDK) et à la présentation de l'architecture de la plateforme GitLab.\n- __Support technique individuel__ : accès aux ingénieurs GitLab pour programmer en binôme et recevoir des conseils techniques.\n- __Explications détaillées sur l'architecture__ : sessions sur des composants spécifiques de la plateforme GitLab en lien direct avec le problème auquel l'entreprise contribue.\n- __Aide à la revue de code__ : retours et conseils détaillés tout au long du processus de merge request.\n- __Points réguliers__ : collaboration continue pour assurer l'avancement de la contribution et répondre aux problématiques rencontrées.\n\nCette structure garantit que les équipes peuvent contribuer efficacement, quelle que soit leur expérience antérieure avec le code base de GitLab ou les langages de programmation Ruby/Go. Comme le note John Parent de Kitware, *« si vous êtes un nouvel utilisateur de GitLab, vous avez l'impression d'être face à une architecture sophistiquée et à une immense quantité de code réparti sur différents projets. Le Programme Co-Create regroupe l'équivalent de plusieurs semaines de formation interne en une formation accélérée et ciblée. »*\n\nEn plus d'aboutir au développement de nouvelles fonctionnalités, ce programme permet d'établir des relations durables entre GitLab et sa communauté d'utilisateurs. *« Le fait que nos clients contribuent avec enthousiasme au développement de nouvelles fonctionnalités est inspirant pour nos ingénieurs »*, révèle Shekhar Patnaik, Principal Engineer chez GitLab. *« Les clients découvrent la \"méthode GitLab\" et les ingénieurs sont témoins de leur engagement à façonner l'avenir de GitLab. »*\n\n## Contribution de Thales : amélioration de l'expérience utilisateur des projets\n\nLa société Thales a identifié des opportunités pour améliorer l'interface utilisateur de la plateforme GitLab lorsque les utilisateurs créent des projets vides. Et elle ne s'est pas contentée de soumettre une demande de fonctionnalité : elle a développé la solution elle-même. Elle a axé ses contributions sur l’amélioration de l'expérience de configuration de nouveaux projets en simplifiant la configuration SSH/HTTPS avec une interface composée de plusieurs onglets et en ajoutant une fonctionnalité de copier/coller pour les extraits de code. Ces changements ont eu un impact significatif sur les workflows des équipes de développement. \n\nL'équipe de Thales n'a pas seulement travaillé à l'amélioration de l'UX. Quentin Michaud, doctorant travaillant dans le domaine des applications cloud en périphérie chez Thales, a contribué à l'amélioration du GitLab Development Kit (GDK). Chargé de maintenance de paquets pour Arch Linux, Quentin Michaud, fort de son expertise, a contribué à enrichir la documentation du GDK et à soutenir sa conteneurisation, facilitant ainsi le travail des futurs contributeurs.\n\n*« Grâce à mon expérience en open source, j'ai pu améliorer la prise en charge des distributions Linux par le GDK »*, explique Quentin Michaud. *« Pendant que j'améliorais la documentation sur la gestion de versions des paquets, j'ai constaté que l'équipe Contributor Success de GitLab travaillait également à l'intégration du GDK dans un conteneur. Voir nos efforts converger a été un grand moment pour moi. Cela a montré que la collaboration open source peut contribuer à la création de meilleures solutions. »*\n\nL'expérience s'étant avérée positive pour l'équipe de Thales, Sébastien Lejeune utilise désormais le Programme Co-Create comme exemple *« pour montrer à nos managers le retour sur investissement généré grâce aux contributions open source. »*\n\n## Contribution de Scania : amélioration de la prise en charge des paquets\nLorsque l'entreprise Scania a eu besoin d'une prise en charge avancée des paquets dans GitLab, elle a vu une opportunité d'apporter sa contribution et de développer cette fonctionnalité elle-même. \n\n*« Cela fait longtemps que nous utilisons la plateforme GitLab et que nous promouvons activement l'open source au sein de notre entreprise. Le Programme Co-Create est pour nous une façon concrète d'y contribuer directement »*, révèle Puttaraju Venugopal Hassan, Solution Architect chez Scania.\n\nL'équipe a commencé par des changements mineurs pour se familiariser avec le code base et le processus de revue avant de passer à des fonctionnalités plus importantes. *« L'un des aspects les plus gratifiants du Programme Co-Create a été de revenir sur l'ensemble du processus et de voir le chemin parcouru »*, indique Océane Legrand, Software Developer chez Scania. *« Nous avons commencé par évaluer les besoins et apporter de petits changements, avant de passer à des tâches plus importantes au fil du temps. C'est formidable de voir cette progression. »*\n\nLes contributions de l'équipe de Scania incluent la correction des bogues pour le registre de paquets, ainsi que l'amélioration des fonctionnalités du registre de paquets Conan. Ce dernier pourra bientôt être proposé en disponibilité générale (GA), avec l'implémentation de la prise en charge de la version 2 de Conan. Le travail et la collaboration de Scania avec GitLab sont la preuve que le Programme Co-Create peut apporter des améliorations significatives aux fonctionnalités de registre de paquets de GitLab.\n\n*« Dès le début, notre expérience avec le Programme Co-Create a été très organisée. Nous avons participé à des sessions de formation pendant lesquelles nous avons pu découvrir tous les éléments nécessaires à notre contribution. Des sessions individuelles avec un ingénieur GitLab nous ont également offert une vue détaillée de l'architecture des paquets de GitLab, ce qui a rendu le processus de contribution beaucoup plus fluide »*, déclare Juan Pablo Gonzalez, Software Developer chez Scania. \n\nL'impact du programme va au-delà du code. En effet, les participants acquièrent également des compétences précieuses grâce à leurs contributions. À l'occasion de la sortie de [la version 17.8 de GitLab](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), Océane Legrand et Juan Pablo Gonzalez ont tous deux été désignés comme Most Valuable Person (MVP) de GitLab. Océane Legrand a parlé de l'impact de son travail en open source sur GitLab et Scania, y compris l'obtention de nouvelles compétences pour elle et son équipe : *« Ma contribution au travers du Programme Co-Create m'a permis d'acquérir de nouvelles compétences et une expérience de Ruby et des migrations en arrière-plan. Lorsque mon équipe chez Scania a rencontré un problème lors d'une mise à niveau, j'ai pu participer à sa résolution, car je l'avais déjà rencontré dans le cadre du Programme Co-Create. »*\n\n## Contribution de Kitware : optimisation de l'authentification pour le calcul haute performance\nKitware a mis à profit son expertise spécialisée issue de son travail avec des laboratoires nationaux pour améliorer le framework d'authentification de GitLab. Ses contributions comprenaient l'ajout de la prise en charge du flux d'autorisation d'appareil OAuth2 dans GitLab, ainsi que la mise en œuvre de nouveaux composants, tels que des tables de base de données, des contrôleurs, des vues et de la documentation. Ces améliorations élargissent les options d'authentification de GitLab, rendant la plateforme plus polyvalente pour les appareils sans navigateur ou disposant de capacités de saisie limitées.\n\n*« Le Programme Co-Create est le moyen le plus efficace de contribuer à GitLab en tant que contributeur externe »*, estime John Parent, R&D Engineer chez Kitware. *« Grâce aux sessions de [pair programming](https://about.gitlab.com/fr-fr/blog/agile-pairing-sessions/ \"Pair programming\") entre développeurs et développeuses, nous avons identifié de meilleures implémentations que nous aurions peut-être manquées si nous avions travaillé seuls. »*\n\nEn tant que contributeur open source de longue date, Kitware a particulièrement apprécié l'approche de développement de GitLab. *« Je me doutais que GitLab ne se contenterait pas de solutions prêtes à l'emploi à son échelle, mais voir les équipes de développement intégrer une dépendance Ruby au lieu de créer une solution interne personnalisée était génial »*, explique John Parent. *« Venant du monde C++, où les gestionnaires de paquets sont rares, j'ai apprécié de voir cette approche et sa simplicité. »*\n\n## Quels sont les avantages du Programme Co-Create ?\n\nLe Programme Co-Create crée de la valeur à la fois pour GitLab et le partenaire impliqué. *« Le programme comble le fossé qui peut exister entre les ingénieurs qui développent GitLab et nos clients »*, affirme Imre Farkas, Staff Backend Engineer chez GitLab. *« Collaborer avec les clients nous permet de comprendre leurs défis quotidiens, les parties de l'écosystème GitLab sur lesquelles ils s'appuient et les domaines dans lesquels des améliorations peuvent être apportées. C'est formidable de voir à quel point ils sont enthousiastes à l'idée de s'impliquer dans le développement de GitLab à nos côtés. »*\n\nCette approche collaborative accélère également le développement de GitLab. Comme l'observe Shekhar Patnaik, Principal Engineer chez GitLab : *« Grâce au Programme Co-Create, nos clients nous aident à faire progresser notre roadmap. Leurs contributions nous permettent de fournir des fonctionnalités critiques plus rapidement, ce qui profite à l'ensemble de notre base d'utilisateurs. Le programme étant en constante évolution, nous avons de fortes chances d'accélérer le développement de nos fonctionnalités les plus importantes en travaillant aux côtés des personnes qui comptent sur elles. »*\n\n## Premiers pas avec le Programme Co-Create\nVous souhaitez transformer vos demandes de fonctionnalités en réalité ? Que vous cherchiez à perfectionner l'interface utilisateur de GitLab comme Thales, à améliorer la prise en charge des paquets comme Scania ou à optimiser l'authentification comme Kitware, le Programme Co-Create accueille les entreprises qui souhaitent façonner activement l'avenir de GitLab tout en développant une expérience open source précieuse.\n\nContactez votre représentant GitLab pour en savoir plus sur la participation au Programme Co-Create ou visitez notre [page dédiée](https://about.gitlab.com/community/co-create/) pour plus d'informations.\n",[900,901,902],"contributors","open source","customers","2025-02-10",{"slug":905,"featured":91,"template":808},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":907,"config":918},{"title":908,"description":909,"authors":910,"heroImage":912,"date":913,"body":914,"category":712,"tags":915,"updatedDate":917},"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.",[911],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","2024-08-27","***Cet article a été traduit. Retrouvez la version originale sur [notre blog anglais](https://about.gitlab.com/blog/how-indeed-transformed-its-ci-platform-with-gitlab/ \"Blog anglais de GitLab\").***\n\n***Note de la rédaction : nous invitons parfois les membres de notre communauté de clients à contribuer au blog de GitLab. Nous remercions aujourd'hui Carl Myers, responsable des plateformes CI chez Indeed, de nous avoir fait part de son expérience avec GitLab.***\n\nChez Indeed, notre mission est d'aider chacun à trouver un emploi. Indeed est le [plus grand site d'offres d'emploi](https://www.indeed.com/about?isid=press_us&ikw=press_us_press%2Freleases%2Faward-winning-actress-viola-davis-to-keynote-indeed-futureworks-2023_textlink_https%3A%2F%2Fwww.indeed.com%2Fabout) au monde, accueillant plus de 350 millions de visiteurs uniques chaque mois.\n\nDu côté des équipes de plateforme d'ingénierie d'Indeed, la devise est légèrement différente : « Nous aidons ceux qui aident chacun à trouver un emploi ». Depuis près de vingt ans, les chercheurs d'emploi sont au cœur de notre culture d'ingénierie fondée sur les données. Dans ce contexte, notre responsabilité est de créer des outils qui non seulement facilitent cet objectif, mais qui permettent également aux ingénieurs d'offrir chaque jour des opportunités aux candidats.\n\nL'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\") de GitLab a permis à l'équipe de plateforme CI d'Indeed, composée de seulement 11 personnes, d'accompagner efficacement des milliers d'utilisateurs dans toute l'entreprise. Indeed a également constaté d'autres avantages, avec notamment :\n- une augmentation des pipelines quotidiens de 79 %\n- une réduction de 10 à 20 % des coûts de matériel de CI\n- une diminution des demandes d'assistance\n\n## L'évolution de notre plateforme CI : de Jenkins vers une solution évolutive\n\nComme de nombreuses grandes entreprises dans le domaine technologique, nous avons construit notre plateforme CI de manière organique, au fil de l'évolution de l'entreprise, en faisant appel aux solutions open source et standard qui étaient disponibles à l’époque. En 2007, lorsque Indeed comptait moins de 20 ingénieurs, nous utilisions Hudson, le prédécesseur direct de Jenkins.\n\nUne vingtaine d'années plus tard, nous employons aujourd'hui des milliers d'ingénieurs. Nous avons progressivement amélioré nos outils au fil de l'arrivée de nouvelles technologies, notamment en passant à Jenkins vers 2011. Une autre avancée nous a permis de déplacer la plupart de nos charges de travail vers des nœuds de travail cloud dynamiques grâce à [AWS EC2](https://aws.amazon.com/ec2/). Il est toutefois devenu évident que l'architecture de notre système avait atteint ses limites lorsque nous sommes entrés dans l'ère de [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\").\n\nL'architecture de Jenkins n'est en effet pas conçue pour le cloud. Le fonctionnement de Jenkins repose sur un nœud « contrôleur », un point de défaillance unique qui exécute les parties critiques d'un pipeline et décharge certaines étapes vers les nœuds de travail (qui peuvent évoluer horizontalement dans une certaine mesure). Les contrôleurs constituent également un axe de mise à l'échelle manuelle.\n\nSi vos tâches sont trop nombreuses pour un contrôleur donné, elles doivent être partitionnées manuellement entre plusieurs contrôleurs. CloudBees propose des solutions pour contourner ce problème, notamment avec le CloudBees Jenkins Operations Center qui vous permet de gérer votre constellation de contrôleurs depuis un seul endroit centralisé. Cependant, les contrôleurs restent difficiles à exécuter dans un environnement Kubernetes, car chaque contrôleur est un point de défaillance unique et fragile. Des activités telles que les déploiements de nœuds ou des défaillances matérielles peuvent ainsi entraîner des temps d'arrêt.\n\nAu-delà des limitations techniques inhérentes à Jenkins, notre plateforme CI a également rencontré des problèmes dont nous étions malheureusement à l'origine. Par exemple, nous avons utilisé le DSL Groovy de Jenkins pour générer des jobs à partir du code contenu dans chaque dépôt. Chaque projet s'est ainsi retrouvé avec un pipeline individuel de jobs copiés, ce qui a engendré des centaines de versions difficiles à maintenir et à mettre à jour. Bien que la culture d'ingénierie d'Indeed encourage la flexibilité et permette aux équipes de travailler dans des dépôts distincts, cette flexibilité était devenue un fardeau, car les équipes consacraient trop de temps à répondre aux demandes de maintenance régulières.\n\nAyant pris conscience de cette dette technique, nous nous sommes tournés vers le [modèle « Golden Path »](https://tag-app-delivery.cncf.io/whitepapers/platforms/), qui permet une certaine flexibilité tout en offrant une méthode par défaut pour simplifier les mises à jour et encourager des pratiques cohérentes dans tous les projets.\n\nL'équipe de plateforme CI d'Indeed est relativement petite. Nous comptons environ 11 ingénieurs qui gèrent des milliers d'utilisateurs, répondent aux demandes d'assistance, effectuent des mises à niveau et des opérations de maintenance, et offrent une assistance constante à notre entreprise mondiale.\n\nComme notre équipe prend en charge non seulement notre instance GitLab, mais également l'ensemble de la plateforme CI, y compris le serveur d'artefacts, notre code de compilation partagé et de multiples autres composants personnalisés de notre plateforme, nous avions énormément de travail. Nous avions besoin d'une solution qui nous aiderait à résoudre nos problèmes tout en exploitant au maximum nos ressources existantes.\n\n## Notre migration vers GitLab CI\n\nAprès un examen minutieux de sa conception avec les principales parties prenantes, nous avons décidé de migrer l'ensemble de l'entreprise de Jenkins vers le système d'intégration continue de GitLab. \n\nNos principales raisons étaient les suivantes :\n- Nous utilisions déjà GitLab pour la gestion du code source.\n- GitLab est une offre complète qui fournit tout ce dont nous avons besoin pour l'intégration continue.\n- GitLab CI est conçu pour l'évolutivité et le cloud.\n- GitLab CI nous permet de générer des modèles qui élargissent d'autres modèles, ce qui est compatible avec notre stratégie « Golden Path ».\n- GitLab est un logiciel open source et l'équipe de GitLab nous a toujours aidés à soumettre des correctifs, ce qui nous offre davantage de flexibilité et renforce notre confiance.\n\nAu moment de notre annonce officielle de la disponibilité de la plateforme CI de GitLab pour tous les utilisateurs, 23 % de l'ensemble des compilations étaient déjà effectuées dans le système d'intégration continue de GitLab.\n\nNotre plus grand défi lors de cette migration était que « le diable se niche dans les détails ». Du fait du nombre de compilations personnalisées présentes dans Jenkins, nous savions qu'un outil de migration automatisé ne fonctionnerait pas pour la majorité des équipes. Or, la plupart des avantages du nouveau système ne seraient concrétisés qu'une fois l'ancien système complètement abandonné. Ce n'est qu'alors que nous pourrions cesser d'utiliser le matériel et économiser les frais de licence CloudBees.\n\n## La parité des fonctionnalités et les avantages de repartir à zéro \n\nIndeed utilise de nombreuses technologies différentes, mais les trois langages les plus courants sont Java, Python et JavaScript. Ces piles technologiques de langages sont utilisées pour créer des bibliothèques, des déployables (services Web ou applications) et des tâches cron (un processus qui s'exécute à intervalles réguliers, par exemple pour créer un ensemble de données dans notre lac de données). Chacune de ces piles correspondait à un type de projet spécifique (par ex. Java Library, Python Cronjob, JavaScript Webapp, etc.) avec une configuration de base dans Jenkins. Par conséquent, nous avons dû générer un modèle « Golden Path » dans le système d'intégration continue de GitLab pour chacun de ces types de projets.\n\nLa plupart des utilisateurs pouvaient utiliser ces modèles recommandés tels quels. Pour ceux qui avaient besoin de les personnaliser, le « Golden Path » constituait un point de départ utile leur permettant de modifier uniquement les aspects nécessaires, tout en bénéficiant de mises à jour de modèles centralisées à l'avenir.\n\nNous avons rapidement constaté que la plupart des utilisateurs, même ceux qui avaient besoin de personnaliser certains aspects de leur projet, étaient tout à fait disposés à adopter ce modèle et à l'essayer. S'ils s'apercevaient que certaines de leurs personnalisations n'étaient pas incluses dans le modèle, ils savaient qu'ils pouvaient toujours les ajouter ultérieurement. C'était un résultat surprenant ! Nous pensions en effet que les équipes qui avaient investi dans des personnalisations importantes seraient réticentes à l'idée de les abandonner. Or, dans la majorité des cas, les équipes ne s'en souciaient tout simplement plus. Cela nous a permis de migrer de nombreux projets très rapidement : il suffisait en effet de déposer notre « Golden Path » (un petit fichier d'environ 6 lignes avec des inclusions) dans leur projet pour que chaque équipe puisse s'occuper du reste.\n\n## L'innersource à la rescousse\n\nL'équipe de plateforme CI a également adopté une politique de « priorité aux contributions externes » pour encourager la participation de tous les membres de l'entreprise. C'est ce qu'on appelle parfois l'[innersource](https://about.gitlab.com/fr-fr/topics/version-control/what-is-innersource/ \"Qu'est-ce que l'innersource ?\"). Nous avons créé des tests et une documentation pour encourager les contributions externes (c'est-à-dire externes à notre équipe immédiate). Les équipes qui souhaitaient créer des personnalisations pouvaient ainsi les ajouter au « Golden Path » tout en les activant ou désactivant à l'aide d'un feature flag. Cette approche a encouragé une meilleure collaboration et un plus grand respect des personnalisations (parce que celles-ci faisaient désormais partie du code base commun). \n\nAutre avantage : les équipes qui attendaient désespérément une fonctionnalité dont elles avaient besoin pouvaient désormais la créer elles-mêmes. Nous pouvons désormais leur donner le choix : « Oui, nous prévoyons de mettre en œuvre cette fonctionnalité dans quelques semaines, mais si vous en avez besoin plus tôt, nous serions ravis d'accepter une contribution ». Au final, de nombreuses fonctionnalités de base nécessaires à la parité ont été développées de cette manière, plus rapidement et mieux que nos ressources ne le permettaient. La migration n'aurait pas été un succès sans ce modèle.\n\n## En avance sur le calendrier et en dessous du budget\n\nNotre licence CloudBees arrivait à expiration le 1er avril 2024. Nous avons donc fixé cette date comme date d'achèvement de la migration. Cette échéance était particulièrement ambitieuse, car, à l'époque, 80 % de l'ensemble des compilations (soit 60 % de tous les projets) utilisaient encore Jenkins pour le processus d'intégration continue. Plus de 2 000 [fichiers Jenkins (Jenkinsfiles)](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) devaient donc encore être recréés ou remplacés par nos modèles « Golden Path ».\n\nPour atteindre cet objectif, nous avons mis à disposition des équipes une documentation et des exemples, ajouté des fonctionnalités dans la mesure du possible et aidé nos utilisateurs à offrir des contributions quand ils le pouvaient.\n\nNous avons mis en place des permanences régulières, durant lesquelles tous les utilisateurs pouvaient nous poser des questions ou demander notre aide pour migrer. Nous avons également donné la priorité aux questions d'assistance relatives à la migration. Certains membres de notre équipe sont devenus des experts du système d'intégration continue de GitLab et ont partagé leur expertise avec le reste de l'équipe et toute l'entreprise.\n\nLa migration automatique n'était pas adaptée à la plupart des projets, mais nous avons découvert qu'elle pouvait fonctionner pour un petit sous-ensemble de projets où les personnalisations étaient rares. Nous avons créé une campagne de changement par lots Sourcegraph afin de soumettre des merge requests pour migrer des centaines de projets et, avons convaincu les utilisateurs à accepter ces merge requests.\n\nNous avons également partagé des exemples de réussite notables avec toutes les équipes. Comme les utilisateurs ajoutaient de nouvelles fonctionnalités à nos modèles « Golden Path », nous avons annoncé que ces fonctionnalités seraient ajoutées « gratuitement » lors de la migration vers [GitLab CI](https://about.gitlab.com/fr-fr/blog/ci-deployment-and-environments/ \"Comment déployer du code dans des environnements multiples avec GitLab CI\"). Ces fonctionnalités comportaient entre autres un scan de sécurité et de conformité intégré, des notifications Slack pour les compilations CI et des intégrations avec d'autres systèmes internes.\n\nNous avons également mené une campagne de tests agressifs. Dans ce cadre, nous avons automatiquement désactivé les jobs Jenkins qui n'avaient pas été exécutés ou qui n'avaient pas abouti depuis un certain temps, en disant aux utilisateurs que s'ils en avaient besoin, ils pouvaient les réactiver. C'est un moyen simple d'identifier les jobs qui sont réellement nécessaires. Nous avons ainsi identifié des milliers de jobs qui n'avaient pas été exécutés une seule fois depuis notre dernière migration CI (de Jenkins vers Jenkins). Nous en avons déduit que nous pouvions ignorer la vaste majorité de ces jobs sans aucun risque.\n\nEn janvier 2024, nous avons annoncé que tous les contrôleurs Jenkins passeraient en lecture seule (sans compilation) à moins qu'une exception ne soit explicitement demandée par les utilisateurs. La propriété des contrôleurs était mieux connue et ils s'alignaient généralement sur la structure de notre entreprise. Il était donc logique de se concentrer sur les contrôleurs plutôt que sur les jobs. De plus, la liste des contrôleurs était beaucoup plus gérable que celle des jobs.\n\nPour obtenir une exception, les utilisateurs devaient identifier leurs contrôleurs dans une feuille de calcul, puis saisir leurs coordonnées à côté de chacun d'eux. Nous avons ainsi pu obtenir une liste à jour et fiable des parties prenantes avec lesquelles nous pouvions effectuer un suivi à mesure que la migration progressait, mais cela a également permis aux utilisateurs d'indiquer clairement les jobs dont ils avaient absolument besoin. Nous sommes passés d'environ 400 contrôleurs à 220 au mois de janvier, mais seuls 54 contrôleurs ont nécessité des exceptions (et parmi ces contrôleurs, plusieurs appartenaient à notre équipe pour exécuter nos tests et déploiements canari)).\n\n![Indeed - Graphique de recensement des contrôleurs Jenkins](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\nNous avions donc une liste gérable d'environ 50 équipes et chaque membre de notre équipe a été chargé d'en contacter un certain nombre pour évaluer leurs progrès dans le cadre de la migration. Nous avons consacré les mois de janvier et février à cette tâche et découvert que certaines équipes prévoyaient de terminer leur migration sans notre aide avant le 28 février. D'autres prévoyaient de mettre fin à leurs projets existants avant cette date, et seule une petite minorité pensait rencontrer des difficultés.\n\nNous avons pu travailler avec ce petit groupe d'équipes pour leur offrir un niveau d'accompagnement très personnalisé. Nous leur avons expliqué que nous ne disposions pas de l'expertise nécessaire pour effectuer la migration à leur place, mais que nous pouvions collaborer avec un expert métier de leur équipe. Dans certains cas, nous avons écrit le code et l'équipe s'est chargée de la revue de code, ou vice-versa. Au final, tout notre travail a porté ses fruits et nous avons pu désactiver Jenkins à la date que nous avions annoncée 8 mois plus tôt.\n\n## Résultats : une intégration continue plus efficace et des utilisateurs plus satisfaits\n\nÀ son apogée, notre plateforme CI Jenkins permettait d'exécuter plus de 14 000 pipelines par jour et de réaliser des milliers de projets. Aujourd'hui, notre plateforme CI GitLab exécute régulièrement plus de 25 000 pipelines par jour, mais peut en traiter plus de 40 000 en une seule journée. Le coût différentiel de chaque job dans chaque pipeline est similaire à celui de Jenkins, mais sans les coûts indirects du matériel nécessaire au fonctionnement des contrôleurs. De plus, ces contrôleurs agissaient comme des points de défaillance uniques et des limiteurs de mise à l'échelle, ce qui nous obligeait à diviser artificiellement notre plateforme en segments. Bien qu'une comparaison directe soit difficile, nous constatons que l'élimination de ces frais généraux permet de réduire nos coûts de matériel d'intégration continue de 10 à 20 %. En outre, la charge d'assistance de GitLab CI est bien moindre, car l'application évolue automatiquement dans le cloud et offre une résilience interzone, et le langage utilisé pour la génération de modèles s'accompagne d'une excellente documentation publique.\n\nUn avantage tout aussi important, sinon plus, est que nous sommes maintenant à plus de 70 % d'adoption de nos modèles « Golden Path ». Cela signifie que lorsque nous déployons une amélioration, plus de 5 000 projets en bénéficient immédiatement sans qu'aucune action ne soit requise de la part des équipes d'Indeed. Nous avons ainsi pu déplacer certains jobs vers des instances ARM64 plus rentables, mettre à jour plus facilement les images de compilation des utilisateurs et mieux gérer d'autres opportunités de réduction des coûts. Et le résultat dont nous sommes le plus fiers ? Nos utilisateurs sont plus satisfaits grâce à la nouvelle plateforme.\n\n__À propos de l'auteur :__\n*Carl Myers vit à Sacramento, en Californie, et est le responsable de l'équipe de plateforme CI d'Indeed. Depuis près de vingt ans, Carl crée des outils internes et des plateformes de développement pour le bonheur d'ingénieurs d'entreprises de toutes tailles.*\n\n**Remerciements :**\n*Cette migration n'aurait pas été possible sans le travail inlassable de Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen et de toute l'équipe de plateforme CI. L'équipe souhaite également remercier Deepak Bitragunta et Irina Tyree, dont le leadership a permis de garantir les ressources, l'adhésion et la cohérence à l'échelle de l'entreprise qui étaient nécessaires tout au long de ce long projet. Enfin, nous remercions tous les membres d'Indeed qui ont contribué au code, aux retours d'expérience, aux rapports de bogues et à la migration des projets.*\n\n**Ce texte est une version modifiée de l'article « [How Indeed Replaced Its CI Platform with Gitlab CI](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/) », publié à l'origine sur le blog dédié à l'ingénierie d'Indeed.**",[902,109,916,802],"user stories","2024-12-18",{"slug":919,"featured":91,"template":808},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":921,"config":932},{"title":922,"description":923,"authors":924,"heroImage":926,"date":927,"body":928,"category":712,"tags":929},"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.",[925],"Sharon Gaudin","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","2024-01-30","Southwest Airlines Co. met tout en œuvre pour faciliter le travail de ses équipes de développement.  \n\nLes responsables informatiques de la plus grande compagnie aérienne low-cost au monde s'emploient à éliminer les tâches chronophages et répétitives des workflows de leurs équipes. L'objectif vise à leur faire gagner un temps précieux pour qu'elles se consacrent à des projets à forte valeur ajoutée.\n\n*« Notre approche consiste à éliminer les obstacles qui ralentissent le travail de nos équipes »*, déclare Jim Dayton, Vice President et CISO de Southwest Airlines. *« Je suis fermement convaincu que la plupart des développeurs et développeuses choisissent ce métier pour sa part de créativité. Résoudre les problèmes est leur cheval de bataille. Nous souhaitons donc leur faciliter la tâche et supprimer les obstacles qui entravent leur productivité. »*\n\nPour faire de cette idée une réalité, Jim Dayton s'appuie notamment sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab.\n\nÀ l'occasion de son interview lors du [DevSecOps World Tour de GitLab](https://about.gitlab.com/events/devsecops-world-tour/) à Dallas, Jim Dayton a évoqué les efforts de Southwest Airlines pour soutenir ses équipes de développement et promouvoir leur travail. Lors de son échange avec Reshmi Krishna, Director of Enterprise Solutions Architecture chez GitLab, il a partagé ses réflexions sur les avantages des fonctionnalités d'intelligence artificielle pour enrichir le travail de ses équipes.\n\nSouthwest Airlines a adopté une [approche DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que DevOps ? \") pour le développement d'applications offrant à ses équipes de développement davantage de fonctionnalités en libre-service et de processus de gestion des connaissances. *« Nous voulons permettre aux développeurs et développeuses d'identifier un problème dès qu'il survient, de trouver rapidement une solution et de limiter les interruptions causées par les changements de contexte »*, expose Jim Dayton. *« Il est essentiel de comprendre ce qui freine leur productivité. »*\n\nDepuis 2019, année où Southwest Airlines a entamé sa collaboration avec GitLab, l'entreprise s'est attachée à assurer la cohérence de ses processus de développement logiciel. Pour cela, elle a choisi de centraliser son code dans un dépôt GitLab partagé. En sachant précisément où l'ensemble du code est stocké, les équipes de développement peuvent évaluer plus facilement les indicateurs de performance et gagner en efficacité grâce à la réutilisation du code. \n\n*« Nous finalisons actuellement nos pipelines d'entreprise et la migration des équipes est imminente »*, annonce Jim Dayton. *« Nous collaborons étroitement avec nos nombreuses équipes de développement d'applications pour bien comprendre leurs attentes en matière de pipelines. La finalisation de ce projet est prévue pour la fin de l'année. »*\n\n### La promesse de l'IA\n\nL'utilisation de l'intelligence artificielle est un levier pour les équipes de développement. Elle leur permet notamment de se concentrer sur des tâches plus importantes et plus innovantes, comme le souligne Jim Dayton.\n\nL'IA générative, que ce soit sous la forme d'explications des vulnérabilités, de suggestions de code ou de complétion de code, a un impact considérable sur les workflows tout au long du cycle de vie du développement logiciel. L'intégration de l'IA dans une plateforme DevSecOps renforce la sécurité et réduit le temps consacré aux revues de code et au développement d'applications.\n\nJim Dayton se réjouit de pouvoir utiliser les fonctionnalités d'IA de GitLab pour accélérer et optimiser les processus de développement et de déploiement.\n\n*« Nous voulons éliminer autant que possible les tâches routinières et administratives »*, insiste Jim Dayton, qui considère que l'IA est extrêmement prometteuse, malgré ce que peut laisser penser le battage médiatique autour de cette technologie. *« L'IA nous aidera peut-être à atteindre cet objectif. Un jour, elle pourra sûrement fournir une solution immédiate à une vulnérabilité qui vient d'être identifiée ou expliquer à quoi sert une portion de code. Elle pourra aussi vous dire à quoi elle s'intègre, à quelles données elle accède et pourquoi. Elle pourra nous indiquer clairement, par exemple, qu'un bloc de code spécifique est responsable de 20 % des incidents survenus dans telle application l'année précédente. C'est en ce sens, je pense, que l'IA peut nous aider. »*, précise-t-il. \n\nJim Dayton estime que même si l'IA ne remplacera pas les équipes de développement, elle facilitera grandement leur travail et la communication entre les équipes, notamment dans un contexte où le télétravail s'est généralisé depuis la pandémie de COVID-19.\n\n*« La suggestion de relecteurs est une des fonctionnalités prévues dans la roadmap de [GitLab] »* mentionne Jim Dayton. *« Auparavant, pour obtenir de l'aide dans le cadre de revues de code, il suffisait de demander aux collègues qui partageaient votre bureau. Ce qui n'est plus aussi simple aujourd'hui. En revanche, l'IA peut désormais suggérer un relecteur ayant déjà contribué au code du projet ou résolu des incidents, et qui possède les compétences nécessaires. Ce qui apporte une réelle valeur ajoutée au processus de revue de code. Je pense que l'automatisation est la clé pour réduire le nombre d'étapes manuelles ou les délais d'attente. »*\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/UnUfp7pKnEQ?si=qcX2Qm3zpgQOV4xy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*Southwest Airlines est une société au chiffre d'affaires de près de 24 milliards de dollars basée à Dallas, au Texas. Avec 72 000 employés, elle dessert 120 destinations et effectue 4 000 vols par jour.  Southwest Airlines transporte plus de passagers via des vols nationaux que toute autre compagnie aérienne.*\n\nVous souhaitez en savoir plus sur GitLab ? Consultez nos [témoignages clients](https://about.gitlab.com/fr-fr/customers/).\n",[930,931,846,902],"DevOps","DevOps platform",{"slug":933,"featured":6,"template":808},"southwest-looking-to-help-developers-take-flight",{"category":720,"slug":724,"posts":935},[936,948,960],{"content":937,"config":946},{"title":938,"description":939,"authors":940,"heroImage":942,"date":943,"body":944,"category":724,"tags":945},"Approche CI/CD : notre guide complet","Découvrez comment transformer vos processus CI/CD en automatisant le développement et la livraison de logiciels tout en renforçant la sécurité des pipelines.",[941],"Sandra Gittlen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","2025-06-25","L'adoption des pratiques [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") a révolutionné la création de valeur dans le développement logiciel. L'époque des déploiements manuels et des défis d'intégration complexes est désormais révolue : aujourd'hui, le développement logiciel moderne met l'accent sur l'automatisation, la fiabilité et la rapidité.\n\nL'approche CI/CD repose sur la mise en place d'un pipeline fluide et automatisé qui permet de transférer le code de l'environnement de développement vers l'environnement de production, tout en intégrant les retours et suggestions de modification en temps réel. L'intégration continue (CI) aide les équipes à détecter rapidement les problèmes avant qu'ils ne deviennent coûteux. Les modifications de code sont fréquemment fusionnées dans un dépôt partagé, puis testées automatiquement et validées. La livraison continue (CD) vient compléter cette démarche. Elle vise à automatiser le processus de déploiement, rendant les sorties de nouvelles versions prévisibles et harmonieuses.\n\nGrâce à un pipeline CI/CD robuste, les équipes peuvent compiler, tester et déployer leurs logiciels sans dépendre de processus manuels ou de chaînes d’outils complexes. L'intégration de l'IA aide à optimiser encore davantage ce processus, en générant automatiquement des pipelines CI/CD qui garantissent la cohérence des contrôles de qualité, de conformité et de sécurité.\n\nDécouvrez dans ce guide tout ce que vous devez sur les pipelines CI/CD modernes, des principes de base aux bonnes pratiques, en passant par les stratégies avancées. Apprenez également comment les grandes entreprises leaders dans leur domaine tirent parti de l'approche CI/CD pour atteindre des résultats impressionnants. À l’issue de cette lecture, vous saurez comment faire évoluer votre environnement [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") afin de développer et de livrer des logiciels de manière [agile](https://about.gitlab.com/fr-fr/topics/ci-cd/continuous-integration-agile/ \"Intégration continue et développement agile\"), automatisée et efficace.\n\n## Qu'est-ce que l'intégration continue ?\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) est une pratique qui consiste à intégrer régulièrement les modifications de code dans la branche principale d'un dépôt de code source partagé. Cette intégration s'effectue dès que possible, et fréquemment. Après chaque validation ou merge, les modifications sont automatiquement testées, puis une compilation est déclenchée sans intervention manuelle. Grâce à l'intégration continue, les équipes peuvent identifier et corriger les erreurs, ainsi que les failles de sécurité, plus facilement et beaucoup plus tôt dans le processus de développement.\n\n## Qu'est-ce que la livraison continue ?\n\n[La livraison continue](https://about.gitlab.com/fr-fr/topics/ci-cd/#what-is-continuous-delivery-cd \"Qu'est-ce que la livraison continue ?\") (CD), également appelée *déploiement continu*, automatise le processus de mise en production des applications. Les équipes de développement ont ainsi plus de temps à consacrer au suivi des déploiements en cours pour en garantir la réussite. Avec la livraison continue, les équipes DevSecOps définissent à l'avance les critères de mise à disposition du code. Une fois ces critères remplis et validés, le code est automatiquement déployé dans l'environnement de production. Cette automatisation permet aux entreprises de gagner en flexibilité et de mettre plus rapidement de nouvelles fonctionnalités à disposition des utilisateurs.\n\n## Quel est le lien entre la gestion du code source et l'approche CI/CD ?\n\nLa [gestion du code source (SCM)](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\") et l'approche CI/CD constituent la base des pratiques modernes de développement logiciel. Les systèmes SCM, comme [Git](https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/ \"Qu'est-ce que Git?\"), offrent une solution centralisée pour suivre les modifications, gérer les versions de code et faciliter la collaboration entre les membres de l'équipe. Lorsqu’un développeur travaille sur une nouvelle fonctionnalité ou une correction de bogues, il crée une branche à partir du code source et apporte ses modifications avant de les [fusionner à l'aide des merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/). Cette stratégie de gestion de branches permet à plusieurs développeurs de travailler simultanément sans interférer avec le code de leurs collègues, tout en maintenant une branche principale stable qui contient un code prêt à être déployé dans l'environnement de production.\n\nL'approche CI/CD automatise les étapes de compilation, de test et de validation du code géré par le système SCM à chaque push de modifications. Lorsqu'un développeur soumet ses modifications de code, le système CI/CD récupère automatiquement le code le plus récent, le combine avec le code source existant, puis exécute une série de vérifications automatisées. Celles-ci comprennent généralement la compilation du code, l'exécution de tests unitaires, l'analyse statique du code et la vérification de la couverture de code. En cas d’échec d’une de ces étapes, l'équipe en est immédiatement informée, ce qui lui permet de résoudre les problèmes avant qu'ils n'affectent d'autres développeurs ou qu'ils n’apparaissent dans l'environnement de production. Cette intégration étroite entre le contrôle de version et l'intégration continue crée une boucle de rétroaction constante qui garantit la qualité du code et prévient l'accumulation de problèmes d'intégration.\n\n## Quels sont les avantages de l'approche CI/CD ?\n\n[L'approche CI/CD apporte de nombreux avantages qui transforment le développement logiciel moderne](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/) et réduisent considérablement les délais ainsi que les risques associés à la livraison de nouvelles fonctionnalités et corrections de bogues. Grâce à une boucle de rétroaction continue, les équipes DevSecOps peuvent garantir que leurs modifications sont automatiquement validées sur l'ensemble du code source. \n\nRésultat : des logiciels de meilleure qualité, des cycles de livraison plus courts et des sorties de nouvelles versions plus fréquentes pour répondre rapidement aux besoins des utilisateurs et aux demandes du marché.\n\nAu-delà des aspects techniques, l'approche CI/CD favorise une culture de collaboration et de transparence au sein des équipes de développement logiciel. Grâce à une visibilité en temps réel du statut des compilations, des tests et des déploiements, il est plus facile d'identifier et de résoudre les goulots d'étranglement dans le processus de livraison. L'automatisation offerte par l'approche CI/CD réduit également la charge cognitive des équipes de développement qui peuvent ainsi se concentrer sur l'écriture de code plutôt que sur la gestion de processus de déploiement manuels. La satisfaction et la productivité des équipes s’améliorent, tandis que les risques généralement associés aux étapes critiques du processus de publication de logiciel diminuent. Les équipes peuvent expérimenter de nouvelles idées sans craindre de compromettre le projet, sachant que des mécanismes de contrôle robustes, comme les revues de code rapides, sont intégrés au processus. Elles peuvent rapidement annuler les modifications si nécessaire. L'approche CI/CD encourage donc une culture d'innovation et d'amélioration continue.\n\n### Quelles sont les principales différences entre l'approche CI/CD et le développement traditionnel ?\n\nL'approche CI/CD diffère du développement logiciel traditionnel à bien des égards, notamment en ce qui concerne les points suivants :\n\n**Validations fréquentes du code**\n\nDans le développement traditionnel, les équipes de développement travaillent souvent de manière isolée et intègrent rarement leurs modifications dans le code source. Cette situation entraîne des conflits de merge et d'autres problèmes chronophages. Avec l'approche CI/CD, les équipes effectuent régulièrement des push de validation, parfois plusieurs fois par jour. De cette manière, les conflits de merge sont détectés rapidement et le code source est maintenu à jour.\n\n**Réduction des risques**\n\nLes méthodes de développement logiciel traditionnelles reposent sur des cycles de test à rallonge et une planification rigoureuse avant la sortie de chaque nouvelle version. Bien que ce type de développement ait pour objectif de réduire au maximum les risques, il entrave souvent la capacité à identifier et à résoudre les problèmes. À l’inverse, l'approche CI/CD permet de gérer les risques en appliquant de petites modifications incrémentielles. Ces changements, surveillés de près, peuvent être facilement annulés en cas de problème.\n\n**Tests automatisés et continus**\n\nDans le cadre du développement logiciel traditionnel, les tests sont généralement exécutés à la fin du processus de développement, ce qui peut entraîner des retards de livraison et des corrections de bogues coûteuses. L'approche CI/CD, en revanche, intègre des tests automatisés qui sont exécutés en continu tout au long du processus de développement logiciel et déclenchés à chaque validation de code. Cette approche permet aux équipes de développement de recevoir des retours immédiats et d’implémenter rapidement les correctifs nécessaires.\n\n**Déploiements automatisés, reproductibles et fréquents**\n\nL’automatisation des déploiements dans l’approche CI/CD réduit le stress et les efforts habituellement associés aux déploiements massifs de logiciels. Ce processus automatisé est reproductible dans tous les environnements et garantit ainsi un gain de temps, une réduction des risques d’erreurs ainsi qu'une cohérence accrue dans chaque déploiement.\n\n## Quels sont les principes fondamentaux de l'approche CI/CD ?\n\nL'approche CI/CD constitue un framework essentiel pour la mise en place de processus de livraison de logiciels évolutifs et régulièrement mis à jour. Pour les équipes DevSecOps, une maîtrise parfaite de ses concepts fondamentaux est indispensable. Une solide compréhension des principes CI/CD permet aux équipes d'adapter leurs stratégies et leurs pratiques aux évolutions technologiques, en s’affranchissant des limitations des méthodes traditionnelles. \n\n### Qu'est-ce qu'un pipeline CI/CD ?\n\nUn [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) est une série d'étapes (compilation, test et déploiement) qui automatise et rationalise le processus de livraison de logiciels. [Chaque étape agit comme un mur qualité](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) et permet de s'assurer que seul le code validé passe à l'étape suivante. Les premières étapes gèrent les vérifications de base, telles que la compilation et les tests unitaires. Les étapes ultérieures, quant à elles, peuvent inclure des tests d'intégration, de performance et de conformité, ainsi que des déploiements échelonnés dans divers environnements.\n\nLe pipeline peut être configuré de manière à nécessiter des approbations manuelles aux points critiques, par exemple avant le déploiement en production, tout en automatisant les tâches routinières. Les équipes de développement obtiennent ainsi un retour rapide sur l'état de leurs modifications. Cette approche structurée assure la cohérence, réduit les erreurs humaines et fournit une piste d'audit claire du transfert des modifications de code de l'environnement de développement vers l'environnement de production. Les pipelines modernes sont souvent implémentés sous forme de code et peuvent ainsi être contrôlés, testés et tenus à jour, de la même manière que le code applicatif.\n\nVoici d'autres termes associés à l'approche CI/CD qu'il est important de connaître :\n\n* **Validation :** une modification apportée au code\n* **Job :** une série d'instructions qu'un runner doit exécuter\n* **Runner :** un agent ou serveur qui exécute chaque job individuellement et qui peut se mettre à l'échelle selon les besoins\n* **Étapes :** un mot-clé qui définit certaines phases spécifiques d'un job, comme la phase de « compilation » et de « déploiement ». Les jobs d'une même étape s’exécutent en parallèle. Les pipelines sont configurés à l'aide d'un fichier YAML nommé `.gitlab-ci.yml`, soumis au contrôle de version et situé à la racine du projet.\n\n![Diagramme représentant un pipeline CI/CD](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## Bonnes pratiques pour réussir votre approche CI/CD\n\nVotre maîtrise de l'approche CI/CD dépend grandement des [bonnes pratiques](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/) que vous mettez en œuvre. \n\n#### Les bonnes pratiques en matière d'intégration continue\n\n* Validez tôt et souvent.\n* Optimisez les étapes du pipeline.\n* Simplifiez et accélérez les compilations.\n* Utilisez les échecs pour améliorer les processus.\n* Assurez-vous que l'environnement de test reflète l'environnement de production.\n\n#### Les bonnes pratiques en matière de livraison continue\n\n* Lancez-vous avec les outils et infrastructures disponibles, puis itérez pour améliorer vos processus.\n* Utilisez le moins d'outils possibles pour optimiser la livraison continue.\n* Surveillez l’avancée des projets en continu afin d’éviter l’accumulation de tickets ou de merge requests.\n* Simplifiez les tests d'acceptation par l'utilisateur et le déploiement vers l'environnement de préproduction grâce à l'automatisation.\n* Automatisez la gestion du pipeline de sortie des nouvelles versions.\n* Mettez en œuvre la surveillance du pipeline pour gagner en visibilité et en productivité. \n\n> ### Pour en savoir plus sur l'approche CI/CD, consultez notre [webinaire « Intro to CI/CD »](https://www.youtube.com/watch?v=sQ7Nw3o0izc).\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y\" title=\"Intro to CI/CD webinar\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Premiers pas avec l'approche CI/CD\n\nPour commencer à utiliser l'approche CI/CD, identifiez un projet simple mais représentatif qui servira de projet pilote. Sélectionnez une application simple avec des exigences de test basiques. Vous pourrez ainsi vous concentrer sur l'apprentissage du fonctionnement des pipelines plutôt que sur des scénarios de déploiement complexes. Assurez-vous que votre code est soumis au [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") et qu'il comporte des [tests automatisés basiques](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/). Même quelques tests unitaires suffisent pour débuter. L'objectif est de [créer un pipeline basique](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/) que vous pourrez améliorer progressivement à mesure que vos compétences progressent.\n\nDans le cas de GitLab, le processus commence par la création d'un fichier `.gitlab-ci.yml` dans le répertoire racine de votre projet. Ce fichier YAML définit les étapes de base (comme la compilation, les tests et le déploiement) et les jobs de votre pipeline. Voici un exemple de pipeline simple : l'étape de « Compilation » compile votre code et crée des artefacts, l'étape de « Test » exécute les tests unitaires et l'étape de « Déploiement » effectue le push de votre application vers un environnement de préproduction. GitLab détecte automatiquement ce fichier et commence à exécuter votre pipeline chaque fois que des modifications sont transmises via un push vers votre dépôt. La plateforme fournit des [runners intégrés](https://docs.gitlab.com/runner/) pour exécuter les jobs de votre pipeline, mais vous pouvez également configurer vos propres runners si vous souhaitez davantage de contrôle.\n\nÀ mesure que vous maîtrisez les éléments de base, enrichissez votre pipeline progressivement avec des fonctionnalités plus avancées. Par exemple, ajoutez des contrôles de qualité du code, [le scanning de sécurité](https://docs.gitlab.com/ee/user/application_security/#security-scanning) ou le déploiement automatisé du nouveau code en production. La plateforme DevSecOps de GitLab inclut des fonctionnalités telles que la [gestion de la conformité](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), les [variables de déploiement](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/) et les portes d'approbation manuelle que vous pouvez intégrer à mesure que votre pipeline évolue. Soyez attentif à la durée d'exécution du pipeline et exécutez dans la mesure du possible des jobs en parallèle. Pensez à ajouter des notifications et un traitement approprié des erreurs afin que les membres de l'équipe soient rapidement informés en cas d’échec de pipeline. Commencez à documenter les problèmes que vous rencontrez le plus souvent et les solutions adoptées. Ces données seront très utiles quand votre équipe s'agrandira.\n\n> ### Vous souhaitez en savoir plus sur l'approche CI/CD ? Inscrivez-vous à notre [cours GitLab University gratuit sur l'approche CI/CD](https://university.gitlab.com/courses/continuous-integration-and-delivery-ci-cd-with-gitlab).\n\n## Sécurité, conformité et approche CI/CD\n\nL'un des plus grands avantages de l'approche CI/CD est la possibilité d'intégrer des contrôles de sécurité et de conformité réguliers, et ce dès les premières étapes du cycle de développement logiciel. Dans GitLab, les équipes peuvent utiliser la configuration `.gitlab-ci.yml` pour déclencher automatiquement des scans de sécurité à plusieurs étapes, de la validation initiale du code à son déploiement en production. Les fonctionnalités d'analyse des conteneurs, d'analyse des dépendances et de scanning de sécurité ([Test dynamique de sécurité des applications](https://docs.gitlab.com/ee/user/application_security/dast/) et [Analyseur Advanced SAST de GitLab](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/)) de la plateforme peuvent être configurées pour s'exécuter automatiquement à chaque modification de code afin de rechercher les vulnérabilités, les violations des exigences de conformité et les erreurs de configuration de sécurité. L'API de la plateforme permet l'intégration avec des [outils de sécurité externes](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/), tandis que les fonctionnalités de couverture des tests garantissent que les tests de sécurité répondent aux seuils requis.\n\nLes rapports de test de sécurité de GitLab fournissent des informations détaillées sur les découvertes de vulnérabilités afin de remédier rapidement aux problèmes de sécurité avant qu'ils n'atteignent l'environnement de production. Le tableau de bord relatif à la sécurité fournit une vue centralisée des vulnérabilités détectées dans les différents projets, tandis que des [stratégies de sécurité peuvent être appliquées](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/) via les approbations de merge request et les portes dans les pipelines. GitLab offre plusieurs niveaux de gestion des secrets pour protéger les données sensibles tout au long du processus CI/CD, y compris des journaux d'audit permettant de suivre l'accès à ces secrets. De plus, un contrôle d'accès basé sur les rôles (RBAC) garantit que seuls les utilisateurs autorisés peuvent consulter ou modifier les données de configuration sensibles.\n\nGitLab prend également en charge la génération de [nomenclatures logicielles (SBOM)](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/), qui fournissent un inventaire complet de l'ensemble des composants logiciels, dépendances et licences dans une application. Elles permettent aux équipes d'identifier et de corriger rapidement les vulnérabilités, ainsi que de se conformer aux exigences réglementaires.\n\n## Approche CI/CD et cloud\n\nLa plateforme CI/CD de GitLab offre une intégration robuste avec les principaux fournisseurs de services cloud, notamment [Amazon Web Services](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/), [Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/) et [Microsoft Azure](https://docs.gitlab.com/ee/install/azure/). Les équipes de développement logiciel peuvent ainsi automatiser leurs déploiements cloud directement à partir de leurs pipelines. Grâce aux intégrations cloud de GitLab, elles peuvent également gérer les ressources cloud, déployer des applications et surveiller les services cloud directement depuis l'interface de GitLab. Les templates de déploiement cloud intégrés et les fonctionnalités [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) de la plateforme réduisent considérablement la complexité des déploiements cloud. Les membres de l'équipe peuvent ainsi se concentrer sur le développement d'applications plutôt que sur la gestion de l'infrastructure. Pour les entreprises qui souhaitent automatiser leur infrastructure informatique à l'aide de [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Qu'est-ce que GitOps ?\"), GitLab propose l'[intégration Flux CD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/).\n\nLes fonctionnalités cloud de GitLab vont au-delà de la simple automatisation des déploiements. L'[intégration Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") à la plateforme GitLab permet aux équipes de gérer l'orchestration des conteneurs entre plusieurs fournisseurs de services cloud. De plus, les [options d'installation cloud-native de GitLab](https://about.gitlab.com/fr-fr/topics/ci-cd/cloud-native-continuous-integration/) permettent à la plateforme elle-même de fonctionner dans des environnements cloud. Grâce à ces fonctionnalités cloud-native, les équipes peuvent mettre en œuvre des runners à mise à l'échelle automatique qui provisionnent dynamiquement les ressources cloud pour l'exécution de pipelines afin d'optimiser les coûts et les performances. Enfin, l'intégration de la plateforme avec les services de sécurité des fournisseurs de services cloud garantit le respect des exigences de sécurité et de conformité tout au long du processus de déploiement.\n\nPour les environnements multicloud, GitLab fournit des workflows et des outils cohérents, quel que soit le fournisseur de services cloud sous-jacent. Les équipes de développement peuvent utiliser les fonctionnalités de gestion de l'environnement de GitLab pour gérer différentes configurations cloud dans les environnements de développement, de préproduction et de production. La prise en charge de l'[Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/infrastructure/iac/) de la plateforme GitLab, en particulier son intégration native avec Terraform, permet aux équipes de développement de contrôler les versions et d'automatiser le provisionnement de leur infrastructure cloud. Les fonctionnalités de surveillance et d'[observabilité](https://about.gitlab.com/fr-fr/blog/observability-vs-monitoring-in-devops/ \"Qu'est-ce que l'observabilité ?\") de GitLab s'intègrent aux indicateurs des fournisseurs de services cloud, offrant une visibilité complète de l'intégrité des applications et de l'infrastructure dans les différents environnements cloud.\n\n## Pipeline CI/CD avancé\n\nL'approche CI/CD a connu une évolution significative qui va bien au-delà de la simple construction et du déploiement de pipelines. Dans les mises en œuvre avancées, elle implique une orchestration sophistiquée des tests automatisés, du scanning de sécurité, du provisionnement de l'infrastructure, de l'IA et de bien d'autres aspects. Voici quelques stratégies CI/CD avancées pour aider les équipes d'ingénierie à améliorer leurs pipelines et à résoudre les problèmes qui surviennent, même lorsque la complexité de l'architecture augmente.\n\n### Réutilisation et automatisation des pipelines CI/CD\n\nGitLab révolutionne les pratiques des équipes de développement logiciel et de gestion des pipelines CI/CD en introduisant deux innovations majeures : le [catalogue CI/CD](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) et [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/). Ce dernier est un nouveau langage de programmation expérimental dédié à l'automatisation DevSecOps. Le catalogue CI/CD est une plateforme centralisée où les équipes peuvent découvrir, réutiliser et optimiser les différents composants CI/CD. Ces derniers fonctionnent comme des blocs de construction réutilisables et à usage unique qui simplifient la configuration des pipelines au sein des workflows CI/CD. Parallèlement, CI/CD Steps offre la possibilité de gérer des workflows complexes en permettant aux équipes de configurer les entrées et sorties pour chaque job CI/CD. Avec le catalogue CI/CD et CI/CD Steps, les équipes DevSecOps peuvent facilement standardiser l'approche CI/CD et ses composants, et ainsi simplifier le processus de développement et de maintenance des pipelines CI/CD.\n\n> Pour en savoir plus, consultez notre [FAQ sur le catalogue CI/CD](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) et notre [documentation sur CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/).\n\n### Dépannage des pipelines avec l'IA\n\nBien qu'une défaillance des pipelines CI/CD soit possible, le dépannage rapide du problème peut considérablement réduire son impact. L'analyse des causes profondes de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo ?\"), l'une des fonctionnalités alimentées par l'IA, élimine les hypothèses en [déterminant la cause profonde de l'échec d'un pipeline CI/CD](https://about.gitlab.com/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/ \"Échecs de pipelines CI/CD\"). Lorsqu'un pipeline échoue, GitLab fournit des job logs détaillés, des messages d'erreur et des traces d'exécution qui indiquent exactement où et pourquoi l'échec s'est produit. L'analyse des causes profondes utilise ensuite l'IA pour suggérer une solution.\n\nDécouvrez la fonctionnalité d'analyse des causes profondes de GitLab Duo en action :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Comment migrer son code vers un pipeline GitLab CI/CD ?\n\nLa migration vers la plateforme DevSecOps de GitLab et son pipeline CI/CD intégré implique l'analyse systématique de vos configurations de pipeline, dépendances et processus de déploiement existants pour les mapper aux fonctionnalités et à la syntaxe équivalentes de GitLab. \n\nConsultez nos ressources pour faciliter votre migration vers GitLab CI/CD : \n\n* [Migration de Bamboo vers GitLab CI/CD](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)\n* [De Jenkins à GitLab : le guide complet pour moderniser votre environnement CI/CD](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n* [Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet](https://about.gitlab.com/fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate/)\n\n## Témoignages d'entreprises leaders dans leur domaine\n\nCes entreprises de premier plan ont migré vers GitLab et profitent des innombrables avantages de l'approche CI/CD. Découvrez leurs témoignages.\n\n* [Lockheed Martin](https://about.gitlab.com/fr-fr/customers/lockheed-martin/)\n* [Indeed](https://about.gitlab.com/fr-fr/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n* [CARFAX](https://about.gitlab.com/fr-fr/customers/carfax/)\n* [HackerOne](https://about.gitlab.com/fr-fr/customers/hackerone/)\n* [Betstudios](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/)\n* [Thales et Carrefour](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/)\n\n## Tutoriels CI/CD\n\nDevenez un expert des pipelines CI/CD à l'aide de ces tutoriels : \n\n* [Intégration continue : créez votre premier pipeline CI avec GitLab](https://about.gitlab.com/fr-fr/blog/basics-of-gitlab-ci-updated/)\n* [Configuration de votre premier composant GitLab CI/CD](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [GitLab CI/CD : comment créer facilement un pipeline pour un monorepo](https://about.gitlab.com/fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [Déployer en continu dans de multiples environnements avec les pipelines enfants](https://about.gitlab.com/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)\n* [Refactorisation d'un template CI/CD en composant CI/CD](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)\n\n> ### Commencez un [essai de GitLab Ultimate](https://gitlab.com/-/trials/new) et essayez gratuitement GitLab CI/CD pendant 60 jours.",[109,720,802,804,783,771],{"slug":947,"featured":91,"template":808},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"content":949,"config":958},{"title":950,"description":951,"authors":952,"heroImage":954,"date":955,"body":956,"category":724,"tags":957},"Pourquoi choisir une plateforme DevSecOps unifiée ?","Découvrez comment GitLab combine des outils et fonctionnalités avancés, une sécurité renforcée, tout en tirant parti de l'IA pour accélérer et optimiser le développement logiciel.",[953],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","2025-06-19","Face aux défis croissants du développement logiciel moderne, de nombreuses entreprises migrent vers le cloud et adoptent des processus DevSecOps. Elles sont cependant confrontées à un défi de taille : les nombreux outils et systèmes hérités ne sont pas adaptés à cette évolution et les obligent souvent à créer des intégrations complexes entre une multitude d'outils pour la gestion des tâches, les pipelines CI/CD, la sécurité, la surveillance, entre autres. Cette mosaïque d’outils entraîne une complexité opérationnelle, des coûts de maintenance élevés et freine la collaboration entre les équipes de développement et celles des opérations. Les développeurs, quant à eux, éprouvent de la frustration, car ils passent constamment d'un outil à l'autre pour un même workflow de développement, de la planification à la production.\n\n![Complexité et coûts opérationnels inhérents à l'intégration de plusieurs outils dans un processus DevSecOps](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>Degré de complexité de l'intégration de plusieurs outils dans un processus DevSecOps\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\nBonne nouvelle, une solution existe : une plateforme DevSecOps complète offrant une approche unifiée du développement logiciel.\n\nCette plateforme est conçue pour les entreprises opérant dans des environnements cloud et [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps?\") : tous les aspects du développement logiciel (gestion du code, processus CI/CD, gestion des tâches, sécurité, automatisation pilotée par l'IA) s'effectuent depuis une seule interface. Ainsi, tous les workflows sont centralisés, offrant aux équipes de développement et des opérations une collaboration optimisée, une communication rationalisée et une réduction significative des complexités et des perturbations opérationnelles. \n\nEn outre, l'expérience développeur s'améliore considérablement : les équipes d’ingénierie sont beaucoup plus heureuses de travailler avec un produit conçu spécifiquement pour les besoins du développement moderne.\n\nDécouvrez comment GitLab simplifie la gestion de projet, renforce la [sécurité et la conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et conformité\"), et intègre l’IA pour transformer le développement logiciel et aider les équipes à surmonter les défis courants.\n\n## Gestion de projet Agile intégrée\n\nGitLab fournit une solution holistique qui rassemble toutes les fonctionnalités nécessaires pour la gestion des projets et des tâches. Cette intégration couvre toutes les étapes du développement logiciel, y compris les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Les équipes peuvent ainsi suivre en temps réel la progression du projet. Les tickets et les epics sont directement liés aux processus d'automatisation. De la planification au déploiement en production, toutes les étapes s'effectuent sans accroc. La transparence entre les équipes est ainsi renforcée, les retards sont réduits et toutes les parties prenantes ont une vision claire de l'état du développement en temps réel.\n\n![Les tickets et les epics sont directement liés aux processus d'automatisation. De la planification au déploiement en production, toutes les étapes s'effectuent sans accroc.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## Sécurité intégrée\n\nLa sécurité est au cœur de GitLab avec l'intégration de fonctionnalités de sécurité complètes. La plateforme intègre un large éventail de [scanners de sécurité](https://about.gitlab.com/fr-fr/blog/2024/02/27/how-to-integrate-custom-security-scanners-into-gitlab/ \"Qu'est-ce qu'un scanner de securité ?\") automatisés, notamment :\n\n* [L'analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) \n* [Les tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/user/application_security/sast/) \n* [Les tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/user/application_security/dast/) \n* [La détection des secrets](https://docs.gitlab.com/user/application_security/secret_detection/)\n* [L'analyse des conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![Fonctionnalités de scanning de sécurité intégrées dans le processus CI/CD à différentes étapes du développement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>Fonctionnalités de scanning de sécurité intégrées dans le processus CI/CD à différentes étapes du développement\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nCes contrôles de sécurité sont intégrés à chaque étape du cycle de développement logiciel, y compris dans les pipelines CI/CD, et offrent aux équipes de développement des retours immédiats sur les failles de sécurité potentielles, et ce dès le début du cycle de développement.\n\n## Conformité et exigences réglementaires\n\nAu-delà de la productivité et de l'expérience utilisateur, de nombreuses entreprises, en particulier celles opérant dans les secteurs réglementés tels que les institutions financières ou les grands groupes, doivent s'assurer que leurs processus respectent des normes de sécurité et de conformité strictes. Elles doivent pouvoir appliquer des stratégies pour différents projets, par exemple en rendant obligatoire l'utilisation d'un scanner de sécurité chaque fois qu'un pipeline CI/CD s'exécute sur des branches de code spécifiques (par exemple, les branches principales ou protégées) ou en exigeant des approbations spécifiques avant de fusionner le code dans la branche principale.\n\nTout devient plus facile avec les [frameworks de conformité](https://about.gitlab.com/blog/2025/04/17/introducing-custom-compliance-frameworks-in-gitlab/) de GitLab : cette fonctionnalité permet aux entreprises de définir et d'appliquer des stratégies structurées aux projets sélectionnés. Cette approche garantit la conformité en appliquant sans intervention manuelle des exigences réglementaires et de sécurité, tout en maintenant un workflow de développement fluide et efficace.\n\n## Développement alimenté par l'IA\n\n[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) offre une assistance pilotée par l'IA à chaque étape du développement logiciel. Par conséquent, aucun outil externe n'est nécessaire. Chaque requête alimentée par l'IA est traitée dans le contexte complet du projet et du code base, ce qui permet de travailler de façon plus intelligente et plus efficace.\n\nL'IA peut effectuer de nombreuses tâches, notamment :\n\n* Générer automatiquement des descriptions de tâches\n* Synthétiser les discussions des tickets pour gagner un temps précieux\n* Enrichir la revue de code\n* Suggérer des améliorations pour optimiser le code\n* Automatiser la génération de tests\n* Détecter et corriger les failles de sécurité\n* Réaliser une analyse des causes profondes en cas d'échec des pipelines CI\n* Garantir le respect de la confidentialité et la sécurité des données\n\nGrâce à sa compréhension des besoins des entreprises opérant dans les secteurs fortement réglementés, en particulier dans le [secteur public](https://about.gitlab.com/fr-fr/solutions/public-sector/) et le [secteur financier](https://about.gitlab.com/fr-fr/solutions/finance/), GitLab offre une plateforme unique qui permet d'exécuter des modèles d'IA dans un environnement sécurisé. \n\n[GitLab Duo Self-Hosted](https://about.gitlab.com/fr-fr/blog/2025/02/27/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy/ \"GitLab Duo Self-Hosted\") permet de garder un contrôle total sur la confidentialité des données, la sécurité et le déploiement de [grands modèles de langage (LLM)](https://about.gitlab.com/blog/2025/05/29/what-is-a-large-language-model-llm/ \"Qu'est-ce qu'un grand modèle de language ?\") dans leur propre infrastructure et garantit ainsi :\n\n* La protection de la confidentialité des données\n* La conformité aux exigences réglementaires\n* Une sécurité maximale\n* Tous les avantages de l’IA, sans dépendre d’un réseau externe ni exposer vos systèmes à des risques\n\n## GitLab, une plateforme moderne et complète\n\nLes entreprises ont besoin d'une plateforme DevSecOps complète pour rationaliser leurs processus, renforcer la sécurité et accélérer l'innovation. C'est précisément ce qu'offre GitLab : une application unique, qui regroupe tous les outils essentiels aux équipes de développement, de sécurité et des opérations, avec une sécurité intégrée et une automatisation alimentée par l'IA.\n\nPour en savoir plus sur GitLab, découvrez nos démonstrations interactives :\n\n* [GitLab Premium et Ultimate avec GitLab Duo](https://gitlab.navattic.com/gitlab-premium-with-duo) : l'assistance au développement alimentée par l'IA\n* [La sécurité dans les pipelines CI/CD](https://gitlab.navattic.com/gitlab-scans) : l'analyse de sécurité intégrée qui protège vos logiciels\n* [Frameworks de conformité](https://gitlab.navattic.com/compliance) : des stratégies appliquées à l'ensemble des projets pour une meilleure gouvernance\n\n> Participez à notre événement virtuel à l'occasion du lancement de GitLab 18 et découvrez ce que vous réserve notre plateforme DevSecOps, notamment le rôle de l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique?\"). [Inscrivez-vous dès aujourd'hui !](https://about.gitlab.com/fr-fr/eighteen/)",[720,802,771],{"slug":959,"featured":6,"template":808},"why-are-organizations-moving-to-a-unified-devsecops-platform",{"content":961,"config":970},{"title":962,"description":963,"authors":964,"heroImage":966,"date":967,"body":968,"category":724,"tags":969},"Guide d'introduction aux serveurs Linux : définition, avantages, usage et installation","Le serveur Linux est couramment utilisé dans les entreprises. Découvrez ses fonctionnalités, ses utilisations et ses avantages.",[965],"GitLab France Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663065/Blog/Hero%20Images/serveur-linux.jpg","2024-12-04","Lancé en 1991 comme alternative à Minix, il adopte la licence GNU GPL en février 1992. Linux est aujourd’hui le système d'exploitation le plus utilisé pour la gestion des serveurs d'entreprise. Les serveurs Linux répondent aux besoins d'entreprises de toutes tailles, leur fournissant une plateforme performante et économique pour piloter de nombreuses applications informatiques. Qu'est-ce qu'un serveur Linux ? Quels en sont les avantages et les usages ? Comment installer un serveur Linux ? Voici l'essentiel à savoir pour lancer votre projet sous Linux.\n\n## Qu'est-ce qu'un serveur Linux ?\n\nUn serveur Linux est un serveur informatique opéré avec le système d'exploitation Linux. Linux fut créé en 1991 par le Finlandais Linus Torvalds, sous forme de noyau de système d'exploitation de type Unix. Trois décennies plus tard, il se conçoit aujourd'hui comme une suite cohérente de logiciels formant un __système d'exploitation entièrement opérationnel__, appelée une distribution Linux.  \n\nLes distributions GNU/Linux s'utilisent principalement pour gérer des fonctions informatiques côté serveur (backend). Nous pouvons citer l'hébergement Web, la gestion de réseau et le stockage de données. Linux est open source, ainsi les équipes opérationnelles peuvent télécharger gratuitement une distribution Linux et l'adapter à leurs besoins. Le système d'exploitation Linux est disponible sous différentes distributions GNU/Linux, telles que Debian, Ubuntu ou openSUSE offrant aux équipes de développement un surcroît de flexibilité et de personnalisation. \n\n## Quels sont les avantages d’un serveur Linux ?\n\nLe succès des serveurs Linux s'explique en grande partie par leur accessibilité et leur flexibilité. Mais le système d'exploitation Linux est aussi reconnu pour sa stabilité et sa sécurité, des critères cruciaux pour les infrastructures de serveurs d'entreprise. Certifié par la Free Software Fondation, Linux est un logiciel libre dont le code source est ouvert, ce qui facilite la correction des bogues et des failles de sécurité. \n\nSon __écosystème open source__ cimente aussi la popularité de Linux auprès des développeurs et des ingénieurs informatiques. Une communauté très active promeut GNU/Linux et favorise sa sécurisation et son développement. En résumé, gérer un serveur sous Linux comporte de nombreux avantages : \n\n- __Réduction des coûts.__ Vous pouvez télécharger, utiliser et modifier Linux sans frais de licence, ce qui permet de réaliser d'importantes économies sur les dépenses informatiques. De nombreuses applications compatibles avec Linux sont aussi disponibles gratuitement.\n- __Sécurité.__ Linux offre un niveau de protection avancé, avec un logiciel libre, des mises à jour régulières, des correctifs de sécurité rapidement publiés, et un soutien de la communauté des développeurs et développeuses.\n- __Scalabilité.__ Les serveurs Linux peuvent facilement évoluer en fonction des charges de travail et du nombre d'utilisateurs. Cette souplesse est appréciée par les entreprises en croissance, et idéale pour les [projets DevOps des PME](https://about.gitlab.com/fr-fr/small-business/ \"Projets DevOps des PME\").\n- __Flexibilité.__ Linux offre un degré de personnalisation poussé, les équipes de développement pouvant adapter le logiciel aux spécificités de leur architecture et de leurs applications. Ils disposent aussi d'un large choix parmi les nombreuses distributions GNU/Linux disponibles.\n\n## Comment utiliser un serveur Linux ?\n\nPar leur versatilité, les serveurs Linux se révèlent précieux pour un grand nombre d'usages informatiques. Ils excellent dans les applications d'entreprise les plus sensibles et les plus complexes. Voici quelques exemples d'utilisations fréquentes d'un serveur sous Linux : \n\n- __Hébergement Web__, qui nécessite de gérer de fortes charges de trafic. Des outils très performants dans ce domaine comme Apache et Nginx fonctionnent de façon optimale sous Linux.\n- __Administration système et réseau.__ Avec des commandes en ligne puissantes, des fonctionnalités avancées de routage et de contrôle du trafic intégrées dans le noyau, une maintenance simple et un fonctionnement stable et sobre en ressources, Linux est le système d'exploitation de choix des administrateurs réseau. \n- __Gestion de bases de données.__ Linux procure une robustesse et une scalabilité incomparables pour utiliser les solutions de gestion des données les plus performantes, comme PostgreSQL, MongoDB ou MariaDB. \n- __Cloud et virtualisation.__ Les serveurs Linux permettent de maximiser les performances des logiciels et des serveurs virtuels. Ils sont naturellement plébiscités pour les [applications cloud-native des entreprises](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Applications cloud-natives des entreprises\").  \n\nLe champ d'utilisation des serveurs sous Linux ne se limite pas à ces exemples. Analyse de données, jeux en ligne, transferts de fichier, business intelligence, messagerie… Les équipes choisissent souvent GNU/Linux pour des projets informatiques qui nécessitent un haut degré de contrôle et de sécurisation, et font appel à des applications avancées et exigeantes en ressources.\n\n### Conseils pour administrer un serveur Linux\n\nSi vous souhaitez tirer pleinement parti des capacités offertes par Linux, nous vous conseillons de suivre certaines bonnes pratiques dans l'administration d'un serveur Linux en entreprise. Pour assurer un démarrage réussi, il est essentiel de __former votre équipe IT__ aux commandes en ligne, aux configurations de sécurité et aux techniques de dépannage. Utilisez des __outils de surveillance__ compatibles avec Linux, tels que Prometheus, Nagios ou Zabbix, pour maintenir la fiabilité de votre infrastructure à long terme.\n\nLa __planification des sauvegardes__ est un autre point crucial pour assurer la viabilité de votre projet. Vous pouvez utiliser la règle du 3-2-1. Sauvegardez trois copies des données, stockez deux copies sur des supports différents, dont une sera placée hors site. Enfin, une bonne gestion de serveur Linux requiert une attention particulière aux __mesures de sécurité__. Nous recommandons la mise en place de clés SSH pour les mots de passe, de logiciels pare-feu et de détection des intrusions comme Fail2ban, et d'une authentification à deux facteurs.\n\n## Comment installer un serveur Linux ?\n\nProlongeons ce guide d'introduction sur une note plus pratique. Voici un tutoriel sur le serveur Linux qui vous accompagnera dans l'installation de ce logiciel en entreprise. Suivez les principales étapes pour installer un serveur Linux :\n\n1. Choisissez une __distribution Linux__ adaptée. Optez par exemple pour Ubuntu Server, connu pour sa facilité d'utilisation, ou Debian, réputé pour sa robustesse.\n2. Créez une __ISO bootable__ de la distribution Linux. Téléchargez-la sur le site officiel et placez-la sur une clé USB pour lancer l'installation sur le serveur.\n3. __Installez Linux__ à partir de la clé USB. Procédez à la configuration de base, à la partition du disque, à la configuration de l'utilisateur, au redémarrage et la première connexion.\n4. __Effectuez la configuration initiale__ du serveur Linux : sécurisez l’accès par SSH, créez un utilisateur non-root, configurez le pare-feu et mettez à jour le système.\n5. __Configurez le réseau.__ Choisissez une IP statique ou dynamique, configurez les DNS et la redirection des ports.\n\nEnfin, pour terminer l'installation du serveur Linux, veillez à parfaire la sécurisation du serveur avec installation d'un pare-feu, d'un certificat SSL et d'outils de surveillance du réseau. Une fois ces étapes terminées, votre serveur Linux est prêt à fonctionner. \n\n## Lancez un projet avec GitLab et Linux\n\nSi Linux a toujours dominé le secteur des serveurs d'entreprise, il connaît aussi un regain de popularité du côté du grand public. Au succès relatif des distributions adaptées aux utilisateurs sur PC, telles que Linux Mint et Ubuntu, s'ajoute l'essor des systèmes d'exploitation Android et Chrome OS pour mobiles et tablettes, qui sont basés sur le noyau Linux. Investir dans des applications fonctionnant sous Linux apparaît comme une stratégie gagnante à long terme, tant le succès de ce logiciel ne se dément pas.\n\nGitLab et Linux offrent un environnement idéal pour développer vos activités de façon agile et profiter de tous nos outils de collaboration. La plateforme GitLab prend en charge de nombreux paquets Linux officiels, tels que Debian, Ubuntu, AlmaLinux et CentOS 7. Rendez-vous sur notre page d'information pour [installer GitLab avec un serveur Linux](https://about.gitlab.com/fr-fr/install/#official-linux-package \"Installer GitLab avec un serveur Linux\") et mener à bien votre projet.\n\n## Installer une distribution Linux avec GitLab\n\n- [Paquet Ubuntu](https://about.gitlab.com/fr-fr/install/#ubuntu \"Paquet Ubuntu\")\n- [Paquet Debian](https://about.gitlab.com/fr-fr/install/#debian \"Paquet Debian\")\n- [Paque AlmaLinux](https://about.gitlab.com/fr-fr/install/#almalinux \"Paque AlmaLinux\")\n- [Paquet CentOS 7](https://about.gitlab.com/fr-fr/install/#centos-7 \"Paquet CentOS 7\")\n- [Paquet OpenSUSE Leap](https://about.gitlab.com/fr-fr/install/#opensuse-leap \"Paquet OpenSUSE Leap\")\n- [Paquet Amazon Linux 2](https://about.gitlab.com/fr-fr/install/#amazonlinux-2 \"Paquet Amazon Linux 2\")\n- [Paquet Raspberry Pi](https://about.gitlab.com/fr-fr/install/#raspberry-pi-os \"Paquet Raspberry Pi\")\n",[930,901],{"slug":971,"featured":6,"template":808},"introduction-guide-to-linux-servers",{"category":732,"slug":736,"posts":973},[974,990,1003],{"content":975,"config":988},{"heroImage":976,"body":977,"authors":978,"updatedDate":981,"date":982,"title":983,"tags":984,"description":987,"category":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","Les sauvegardes de dépôt sont un élément essentiel de toute stratégie de reprise après un sinistre important. Cependant, à mesure que les dépôts grossissent, garantir des sauvegardes fiables devient de plus en plus difficile. Notre propre [dépôt Rails](https://gitlab.com/gitlab-org/gitlab) mettait 48 heures à être sauvegardé, ce qui nous obligeait à faire un choix impossible entre la fréquence des sauvegardes et les performances du système. Nous avons donc décidé de trouver une solution à ce problème pour nos clients et pour nos propres équipes internes.\n\nAprès investigation, nous avons pu déterminer la cause du problème, qui remontait à une fonction Git vieille de 15 ans dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme et **avons ainsi réduit les temps de sauvegarde de manière exponentielle**. \n\nRésultat : des coûts réduits, des risques diminués, et surtout, des stratégies de sauvegarde désormais adaptées à la croissance de votre code source.\n\nCe problème d'évolutivité de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") affectait tout utilisateur disposant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.\n\n## Sauvegarde à grande échelle : enjeux et solutions\n\nÀ mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :\n\n* **Sauvegardes trop longues** : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.\n* **Utilisation intensive des ressources** : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter d'autres opérations critiques.\n* **Fenêtres de sauvegarde** : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes qui fonctionnent 24 h/24 et 7 j/7.\n* **Risque accru d'échec** : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, et obligent souvent les équipes à recommencer tout le processus depuis le début.\n* **Conditions de concurrence** : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus et peut conduire à une sauvegarde invalide ou à des interruptions liées à des objets devenus indisponibles.\n\nCes défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme l'utilisation d'outils externes ou la réduction de la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises.\n\nDécouvrez maintenant comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.\n\n## Le défi technique\n\nLa fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande [`git bundle create`](https://git-scm.com/docs/git-bundle/fr), qui génère un aperçu complet du dépôt avec tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration pour recréer le dépôt dans son état exact.\n\nCependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références et entraînait un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.\n\n### Analyse des causes profondes\n\nPour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.\n\n![Flame graph montrant la commande pendant son exécution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\nCe graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.\n\nLe flame graph de `git bundle create` exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction `object_array_remove_duplicates()`, introduite dans Git par le biais du [commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).\n\nPour comprendre ce changement, il est important de savoir que la commande `git bundle create` permet de préciser les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag `--all` compacte toutes les références.\n\nCe commit corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que `git bundle create main.bundle main main`, et créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois, ce qui provoquait une erreur. \n\nLe code ajouté pour éviter ces duplications utilise des boucles `for` imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) est un goulot d'étranglement majeur en termes de performance dans les dépôts car il contient un grand nombre de références et prolonge considérablement le temps de traitement des données.\n\n### La solution : d'O(N²) à un mappage efficace\n\nPour résoudre ce problème, nous avons proposé une correction en amont dans Git pour remplacer les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.\n\nCe changement améliore considérablement les performances de la commande `git bundle create` et garantit une bien meilleure évolutivité dans les dépôts avec un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.\n\n```shell\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nLe correctif a été accepté et [fusionné](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d) dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement sans attendre la prochaine version officielle de Git.\n\n## Résultat : des temps de sauvegarde radicalement réduits\n\nLes gains de performance qui découlent de cette amélioration sont considérables :\n\n* **De 48 heures à 41 minutes** : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.\n* **Performances constantes** : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.\n* **Efficacité des ressources** : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.\n* **Applicabilité étendue** : si le processus de sauvegarde est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets avec un grand nombre de références en profitent également.\n\n## Avantages pour nos clients GitLab\n\nPour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :\n\n* **Transformation des stratégies de sauvegarde**   \n\n  * Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.   \n  * Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans processus longs ni dédiés.  \n* **Continuité des activités améliorée**  \n\n  * Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits, tout comme le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.\n* **Réduction de la charge opérationnelle**   \n\n  * La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.  \n  * Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.\n* **Pérennisation de l'infrastructure**   \n\n  * La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.   \n  * À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.\n\nLes entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un compromis difficile est devenu une pratique opérationnelle simple.\n\nÀ partir de la version [GitLab 18.0](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/), tous les clients GitLab, quelle que soit leur version de licence, profitent désormais pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs [sauvegardes](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/), sans aucune autre modification de la configuration.\n\n## Et après ?\n\nCette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente une étape majeure, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.\n\nNous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git afin de profiter non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.\n\n> Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Consultez le [replay de notre événement virtuel de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/) et découvrez les autres améliorations fondamentales que nous proposons.",[979,980],"Karthik Nayak","Manuel Kraft","2025-07-09","2025-06-05","Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min ",[985,901,986],"git","performance","L'optimisation d'une fonction Git vieille de 15 ans a permis d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de réduire les risques.",{"slug":989,"featured":91,"template":808},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"content":991,"config":1001},{"title":992,"description":993,"authors":994,"heroImage":995,"date":996,"body":997,"category":736,"tags":998,"updatedDate":1000},"Comment automatiser la migration des images de conteneurs d'Amazon ECR vers GitLab","Suivez ce guide étape par étape pour automatiser le processus de migration de vos images de conteneurs d’Amazon ECR vers GitLab.",[881],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","2025-02-13","« Nous devons migrer des centaines d'images de conteneurs d'Amazon Elastic Container Registry (ECR) vers GitLab. Pouvez-vous nous aider ? » Cette question revenait sans cesse lors de nos échanges avec des ingénieurs de plateforme. En pleine modernisation de leur chaîne d'outils DevSecOps avec GitLab, ils se retrouvaient bloqués au moment de déplacer leurs images de conteneurs. D’un point de vue technique, chaque transfert est simple. Mais, l'opération était longue et fastidieuse en raison du volume considérable d'images.\n\nUn ingénieur de plateforme a parfaitement résumé la situation : « Je connais parfaitement le processus : effectuer un pull, retagger, effectuer un push. Le problème, c'est que je gère 200 microservices, chacun contenant plusieurs tags. Je ne peux pas passer plusieurs semaines sur cette migration alors que j'ai des tâches critiques à effectuer au niveau de l'infrastructure. »\n\n## Le défi\n\nCette conversation nous a fait réfléchir et a donné naissance à une idée. Et si nous pouvions automatiser l'ensemble du processus ? Lorsqu'une équipe de plateforme DevOps transfère ses [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") vers GitLab, la migration des images de conteneurs ne devrait pas poser de difficulté particulière. Le processus manuel est rudimentaire, mais répétitif : il s'agit d'effectuer un pull de chaque image, de la retagger et d'effectuer un push pour la migrer vers le registre de conteneurs de GitLab. Réaliser cette même opération pour des dizaines de dépôts et plusieurs tags par image requiert des jours ou des semaines de travail chronophage.\n\n## La solution\n\nNous avons donc entrepris de créer un pipeline GitLab qui effectuerait automatiquement cette lourde tâche. L'objectif était clair : fournir aux ingénieurs de plateforme un outil qu'ils pourraient configurer en quelques minutes et qui, en une seule nuit, parviendrait à migrer toutes leurs images.\n\n### Configuration des accès\n\nCommençons par l'essentiel : les aspects liés à la sécurité. Nous voulions nous assurer que les équipes puissent exécuter cette migration avec un minimum d'autorisations sur AWS. Voici la politique de gestion des identités et des accès (IAM) en lecture seule dont vous avez besoin :\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n```\n\n### Configuration de GitLab\n\nUne fois la sécurité en place, l'étape suivante consiste à configurer GitLab. Nous avons volontairement réduit cela au strict minimum : il vous suffit de configurer les variables suivantes dans les paramètres CI/CD de votre projet :\n\n```\nAWS_ACCOUNT_ID: Your AWS account number\nAWS_DEFAULT_REGION: Your ECR region\nAWS_ACCESS_KEY_ID: [Masked]\nAWS_SECRET_ACCESS_KEY: [Masked]\nBULK_MIGRATE: true\n```\n\n### Le pipeline de migration \n\nPassons maintenant à la partie la plus intéressante. Nous avons créé le pipeline en utilisant Docker-in-Docker pour gérer toutes les opérations liées aux images de manière fiable :\n\n```yaml\nimage: docker:20.10\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\nLe pipeline fonctionne en trois phases, chacune s'appuyant sur la précédente :\n\n1. Identification\n\nDans un premier temps, il détecte l'ensemble de vos dépôts :\n\n```bash\nREPOS=$(aws ecr describe-repositories --query 'repositories[*].repositoryName' --output text)\n```\n\n2. Énumération des tags\n\nEnsuite, pour chaque dépôt, il récupère l'ensemble des tags :\n\n```bash\nTAGS=$(aws ecr describe-images --repository-name $repo --query 'imageDetails[*].imageTags[]' --output text)\n```\n\n3. Transfert\n\nEnfin, il gère la migration proprement dite :\n\n```bash\ndocker pull ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\ndocker tag ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag} ${CI_REGISTRY_IMAGE}/${repo}:${tag}\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n```\n\n## Résultats\n\nVoici ce que cette solution offre comme avantages aux ingénieurs de plateforme qui ne veulent pas passer plusieurs semaines sur la migration :\n\n- Identification et migration automatisées de l'ensemble des dépôts et tags\n- Dénomination cohérente des images entre ECR et GitLab\n- Gestion des échecs de transferts\n- Journalisation claire pour suivre la progression\n\nAu lieu d'écrire des scripts et de surveiller la migration, l'ingénieur de plateforme peut se concentrer sur des tâches à plus grande valeur ajoutée.\n\n## Utilisation\n\nLa première étape est très simple :\n\n1. Copiez le fichier `.gitlab-ci.yml` dans votre dépôt.\n2. Configurez les variables AWS et GitLab.\n3. Définissez `BULK_MIGRATE` sur « true » pour déclencher la migration.\n\n## Bonnes pratiques\n\nEn accompagnant plusieurs équipes dans leur migration, nous avons tiré quelques enseignements pratiques :\n\n- Exécutez la migration en dehors des heures de pointe pour réduire au maximum l'impact sur votre équipe.\n- Consultez les logs de pipeline qui vous indiqueront si un élément nécessite votre attention.\n- Ne désactivez pas votre registre ECR avant d'avoir vérifié que toutes les images ont bien été transférées.\n- Pour les migrations à grande échelle, envisagez d'ajouter une limite de débit pour éviter de saturer votre réseau.\n\nNous mettons ce pipeline à disposition en open source dans notre dépôt GitLab public, car nous sommes convaincus que les ingénieurs de plateforme devraient passer leur temps à créer de la valeur, plutôt qu'à copier des images de conteneurs. N'hésitez pas à l'adapter à vos besoins ou à poser vos questions sur sa mise en œuvre. Consultez notre documentation pour en savoir plus sur les [catalogues CI/CD](https://gitlab.com/explore/catalog/components/package \"Catalogues CI/CD\"). ",[109,847,804,802,771,999],"solutions architecture","2025-04-07",{"slug":1002,"featured":91,"template":808},"automating-container-image-migration-from-amazon-ecr-to-gitlab",{"content":1004,"config":1016},{"title":1005,"description":1006,"authors":1007,"heroImage":1009,"date":1010,"body":1011,"category":736,"tags":1012,"updatedDate":1015},"Déployer en continu dans de multiples environnements avec les pipelines enfants","Découvrez comment créer un workflow rationalisé dans GitLab pour gérer le déploiement continu dans de multiples environnements.",[1008],"Olivier Dupré","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","2024-09-26","Les équipes DevSecOps doivent parfois coordonner le déploiement continu dans des environnements différents, tout en préservant leurs workflows. La [plateforme DevSecOps de GitLab](https://about.gitlab.com/fr-fr) répond à ce besoin, de manière simple et efficace, y compris avec des environnements sandbox temporaires créés à la demande. Découvrez dans cet article un exemple de mise en œuvre de ce processus en déployant une architecture avec Terraform sur plusieurs environnements cibles.\n\nCette stratégie s'adapte facilement qu'il s'agisse d'un projet d'Infrastructure as Code (IaC) utilisant une autre technologie comme [Pulumi](https://www.pulumi.com/) ou [Ansible](https://www.ansible.com/), d'un projet de code source ou d'un projet de dépôt monolithique combinant plusieurs langages.\n\nÀ la fin de ce tutoriel, le pipeline que vous aurez créé permettra de déployer :\n\n* Un environnement temporaire de **développement** pour chaque branche de fonctionnalité.\n* Un environnement d'**intégration**, qu'il est facile de supprimer et redéployer à partir de la branche principale.\n* Un environnement d'**assurance qualité (QA)**, également déployé à partir de la branche principale, pour exécuter les étapes de QA.\n* Un environnement de **préproduction** pour chaque tag, dernière étape avant la phase de production.\n* Un environnement de **production** qui dans cet exemple sera déployé manuellement, mais qui peut également être déployé en continu.\n\n>Légende des schémas figurant dans cet article :\n> * Les encarts aux angles arrondis représentent les branches de GitLab.\n> * Les encarts rectangulaires représentent les environnements.\n> * Le texte sur les flèches représente les actions requises pour passer d'un encart à l'autre.\n> * Les encarts carrés représentent une prise de décision.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\nNous allons vous expliquer les [raisons](#why) des [actions](#what) présentées dans le flowchart ci-dessus, ainsi que [les étapes à suivre](#how) pour chacune d'elles. Ce tutoriel sera ainsi plus facile à suivre et vous pourrez le reproduire sans difficulté.\n\n## Raisons\n\n* [L'intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/) constitue quasiment une norme établie. La plupart des entreprises implémentent des pipelines CI ou cherchent à standardiser leurs pratiques.\n\n* La [livraison continue (CD)](https://about.gitlab.com/fr-fr/topics/ci-cd/), qui consiste à effectuer la publication des artefacts vers un dépôt ou un registre à la fin du pipeline CI, est également courante.\n\n* L'étape suivante, le [déploiement continu](https://about.gitlab.com/fr-fr/topics/ci-cd/#what-is-continuous-deployment \"Qu'est-ce que le déploiement continu ? \"), qui automatise le déploiement de ces artefacts, est en revanche moins répandu. Il est essentiellement implémenté dans le domaine des applications. Le déploiement continu d'une infrastructure est plus compliqué et implique la gestion de plusieurs environnements. Tester, sécuriser et vérifier le code de l'infrastructure constitue un défi supplémentaire et c'est un domaine où le processus [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps ?\") n'a pas encore atteint sa pleine maturité. L'intégration de la sécurité en amont, qui nécessite l'implication des équipes de sécurité, représente également une difficulté. Et il est très important de prendre en compte les problèmes de sécurité dès les premières étapes du développement, afin de passer d'une approche DevOps à un processus **[DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\")**.\n\nCe tutoriel vous invite à tester une méthode simple et efficace pour adopter une approche DevSecOps pour votre infrastructure. Nous prendrons l'exemple du déploiement de ressources dans cinq environnements, du développement à la production.\n\n__Remarque :__ même si je préconise l'adoption d'une [approche FinOps](https://about.gitlab.com/fr-fr/the-source/platform/finops-balancing-financial-responsibility-and-innovation/ \"Qu'est-ce que l'approche FinOps ? \") et la réduction du nombre d'environnements, il existe parfois d'excellentes raisons de ne pas se limiter aux simples étapes de développement, préproduction et production. N'hésitez pas à adapter les exemples en fonction de vos besoins.\n\n## Actions\n\nL’avènement du cloud a boosté l'utilisation de l'IaC. Ansible et Terraform ont ouvert la voie, suivis par OpenTofu, Pulumi, AWS CDK, Google Deploy Manager et bien d'autres.\n\nUne Infrastructure as Code est la solution parfaite pour déployer une infrastructure de manière sécurisée. Vous pouvez la tester, la déployer et la réappliquer autant de fois que nécessaire pour atteindre votre objectif.\n\nMalheureusement, les entreprises maintiennent souvent plusieurs branches, voire de multiples dépôts, pour chacun de leurs environnements cibles, ce qui crée des problèmes. Elles ne respectent plus un processus rigoureux. Elles ne s'assurent plus que chaque modification du code en production a été soigneusement testée dans les environnements précédents. Par conséquent, des décalages apparaissent peu à peu d'un environnement à l'autre.\n\nJ'ai réalisé que ce tutoriel était nécessaire lors d'une conférence à laquelle j'ai assisté : tous les participants ont déclaré que leur workflow n'imposait des tests rigoureux de l'infrastructure qu'avant le déploiement en production. Et ils ont tous convenu qu'ils appliquaient parfois des correctifs directement en production. Bien sûr, cette démarche permet d'aller vite, mais est-elle sûre ? Comment reporter les correctifs sur les environnements précédents ? Comment vérifier qu'il n'y a pas d'effets de bord ? Comment limiter les risques auxquels votre entreprise est exposée lorsque vous déployez votre code trop rapidement en production ?\n\nLa question essentielle est de savoir *pourquoi* les [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Créer une structure d'équipe DevOps idéale\") déploient directement en production. Le pipeline devrait-il être plus efficace ou plus rapide ? N'est-il pas possible d'automatiser le processus ? Ou, pire encore, n'y a-t-il *aucun moyen de tester le code en dehors de l'environnement de production* ?\n\nDans la section suivante, vous apprendrez à automatiser votre infrastructure et à garantir que votre équipe DevOps mène des tests efficaces avant d'effectuer un push vers un environnement qui affectera le reste du processus. Vous verrez comment sécuriser votre code et contrôler son déploiement de bout en bout.\n\n## Les étapes à suivre\n\nComme mentionné précédemment, de nombreux langages permettent actuellement de gérer l'IaC et nous ne pouvons pas *tous* les aborder ici. Je vais m'appuyer sur un code Terraform version 1.4. Ne prêtez pas attention au langage utilisé pour gérer l'IaC, mais plutôt au processus transposable à votre écosystème.\n\n### Le code Terraform\n\nCommençons par un code Terraform de base.\n\nNous allons déployer sur AWS, un cloud privé virtuel (VPC), qui est un réseau virtuel. Dans ce VPC, nous déploierons un sous-réseau public et un sous-réseau privé. Comme leur nom l'indique, il s'agit de sous-réseaux du VPC principal. Enfin, nous ajouterons une instance Elastic Cloud Compute (EC2) (une machine virtuelle) dans le sous-réseau public.\n\nNous allons ainsi déployer quatre ressources de manière relativement simple. L'idée est de se concentrer sur le pipeline, et non sur le code.\n\nVoici la cible que nous voulons atteindre pour votre dépôt.\n\n![cible du dépôt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097033415.png)\n\nDécomposons le processus.\n\nTout d'abord, nous déclarons toutes les ressources dans un fichier `terraform/main.tf` :\n\n```terraform\nprovider \"aws\" {\n  region = var.aws_default_region\n}\n\nresource \"aws_vpc\" \"main\" {\n  cidr_block = var.aws_vpc_cidr\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\nresource \"aws_subnet\" \"public_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_public_subnet_cidr\n\n  tags = {\n    Name = \"Public Subnet\"\n  }\n}\nresource \"aws_subnet\" \"private_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_private_subnet_cidr\n\n  tags = {\n    Name = \"Private Subnet\"\n  }\n}\n\nresource \"aws_instance\" \"sandbox\" {\n  ami           = var.aws_ami_id\n  instance_type = var.aws_instance_type\n\n  subnet_id = aws_subnet.public_subnet.id\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n```\n\nComme vous pouvez le constater, ce code nécessite plusieurs variables. Nous les déclarons dans un fichier `terraform/variables.tf` :\n\n```terraform\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\n}\n\nvariable \"aws_instance_type\" {\n  description = \"The instance type of the VM being deployed.\"\n  type        = string\n  default     = \"t2.micro\"\n}\n\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\n}\n\nvariable \"aws_public_subnet_cidr\" {\n  description = \"The CIDR of the public subnet.\"\n  type        = string\n  default     = \"10.0.1.0/24\"\n}\n\nvariable \"aws_private_subnet_cidr\" {\n  description = \"The CIDR of the private subnet.\"\n  type        = string\n  default     = \"10.0.2.0/24\"\n}\n\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n```\n\nÀ ce stade, nous avons presque terminé la partie IaC. Il nous manque simplement une méthode pour partager les états Terraform. Si vous l'ignorez, Terraform fonctionne schématiquement comme suit :\n\n* La commande `plan` vérifie les différences entre l'infrastructure actuelle et celle définie dans le code. Elle génère ensuite un rapport des différences.\n* La commande `apply` exécute les modifications en fonction du rapport `plan` et met à jour l'état.\n\nLors du premier passage, l'état est vide. Il comporte ensuite les détails (ID, etc.) des ressources appliquées par Terraform.\n\nLe problème est le suivant : où cet état est-il stocké ? Comment le partager pour permettre à plusieurs développeurs et développeuses de collaborer sur le code ?\n\nLa solution est assez simple : stockez et partagez l'état dans GitLab via un [backend HTTP Terraform](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html).\n\nLorsque vous utilisez ce backend, la première étape consiste à créer le fichier `terraform/backend.tf` le plus simple qui soit. La deuxième étape est prise en charge dans le pipeline.\n\n```terraform\nterraform {\n  backend \"http\" {\n  }\n}\n```\n\nEt voilà ! Nous disposons maintenant d'un code Terraform minimaliste pour déployer ces quatre ressources. Nous renseignerons les valeurs des variables lors de l'exécution à une étape ultérieure.\n\n### Le workflow\n\nMettons en œuvre le workflow suivant :\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n1. Créez une branche de **fonctionnalité**. Elle exécute tous les scanners en continu sur le code pour s'assurer qu'il est toujours conforme et sécurisé. Ce code est déployé en continu dans un environnement temporaire `review/feature_branch` portant le nom de la branche actuelle. Il s'agit d'un environnement sûr où les équipes de développement et d'opérations peuvent tester leur code sans impact sur le reste du Système d’Information (SI). Le processus, comme les revues de code et l'exécution de scanners, est imposé à cette étape pour assurer que la qualité et la sécurité du code sont suffisantes et ne mettent pas votre SI en danger. L'infrastructure déployée par cette branche est automatiquement détruite lorsque la branche est fermée. Vous pouvez ainsi contrôler votre budget.\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\u003C/pre>\n\n2. Une fois approuvée, la branche de fonctionnalité est **fusionnée** dans la branche principale. Il s'agit d'une [branche protégée](https://docs.gitlab.com/ee/user/project/protected_branches.html) où aucun push ne peut être effectué directement. Elle est nécessaire pour veiller à ce que chaque demande de modification de l'environnement de production soit minutieusement testée. Cette branche est également déployée en continu. La cible ici est l'environnement `integration`. La suppression de cet environnement n'est pas automatisée pour des questions de stabilité, mais elle peut être déclenchée manuellement.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|auto deploy| E[integration]\n\u003C/pre>\n\n3. Une approbation manuelle est ensuite nécessaire pour déclencher le déploiement suivant. La branche principale sera déployée dans l'environnement `qa`. J'ai défini une règle ici pour empêcher la suppression depuis le pipeline. Cet environnement devrait être assez stable (après tout, c'est déjà le troisième) et je souhaite éviter une suppression accidentelle. N'hésitez pas à adapter les règles à vos processus.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main)-->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\u003C/pre>\n\n4. Pour continuer, nous devons **ajouter un tag** au code. Nous utilisons les [tags protégés](https://docs.gitlab.com/ee/user/project/protected_tags.html) pour que seul un ensemble spécifique d'utilisateurs ait l'autorisation de déployer dans ces deux derniers environnements. Ce tag va immédiatement déclencher un déploiement dans l'environnement `staging`.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|tag| G(X.Y.Z)\n    F[qa] -->|validate| G\n\n    G -->|auto deploy| H[staging]\n\u003C/pre>\n\n5. Nous arrivons enfin à l'environnement `production`. Il est souvent difficile de déployer l'infrastructure progressivement (10 %, 25 %, etc.). Nous la déployons donc dans son intégralité. Nous contrôlons toutefois ce déploiement à l'aide d'un déclencheur manuel intégré dans cette dernière étape. Afin de garder un contrôle maximal sur cet environnement hautement critique, nous le contrôlons en tant qu'[environnement protégé](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    H[staging] -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n### Le pipeline\n\nPour mettre en œuvre le [workflow](#the-workflow) ci-dessus, nous allons maintenant implémenter un pipeline comportant deux [pipelines enfants](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n\n#### Le pipeline principal\n\nCommençons par le pipeline principal. Il est déclenché automatiquement par un **push effectué vers une branche de fonctionnalité**, une **fusion vers la branche par défaut** ou un **tag**. *Il* effectue un vrai **déploiement continu** dans les environnements suivants : `dev`, `integration` et `staging`. Il est déclaré dans le fichier `.gitlab-ci.yml` à la racine de votre projet.\n\n![la cible du dépôt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097033417.png)\n\n```yml\nstages:\n  - test\n  - environments\n\n.environment:\n  stage: environments\n  variables:\n    TF_ROOT: terraform\n    TF_CLI_ARGS_plan: \"-var-file=../vars/$variables_file.tfvars\"\n  trigger:\n    include: .gitlab-ci/.first-layer.gitlab-ci.yml\n    strategy: depend            # Wait for the triggered pipeline to successfully complete\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nreview:\n  extends: .environment\n  variables:\n    environment: review/$CI_COMMIT_REF_SLUG\n    TF_STATE_NAME: $CI_COMMIT_REF_SLUG\n    variables_file: review\n    TF_VAR_aws_resources_name: $CI_COMMIT_REF_SLUG  # Used in the tag Name of the resources deployed, to easily differenciate them\n  rules:\n    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n\nintegration:\n  extends: .environment\n  variables:\n    environment: integration\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nstaging:\n  extends: .environment\n  variables:\n    environment: staging\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_TAG\n\n#### TWEAK\n# This tweak is needed to display vulnerability results in the merge widgets.\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700 is resolved, the `include` instruction below can be removed.\n# Until then, the SAST IaC scanners will run in the downstream pipelines, but their results will not be available directly in the merge request widget, making it harder to track them.\n# Note: This workaround is perfectly safe and will not slow down your pipeline.\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\n```\n\nCe pipeline n'exécute que deux étapes : `test` et  `environments`. La première est nécessaire pour que le *TWEAK* exécute les scanners. La seconde déclenche un pipeline enfant contenant un ensemble de variables différent pour chaque cas défini ci-dessus (push vers la branche, fusion dans la branche par défaut ou tag).\n\nNous ajoutons ici une dépendance avec le mot-clé [strategy:depend](https://docs.gitlab.com/ee/ci/yaml/index.html#triggerstrategy) sur notre pipeline enfant afin que la vue du pipeline dans GitLab ne soit mise à jour qu'une fois le déploiement terminé.\n\nComme vous le voyez, nous définissons un job de base [masqué](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs), puis nous ajoutons des variables et des règles spécifiques afin de déclencher un seul déploiement pour chaque environnement cible.\n\nOutre les [variables prédéfinies](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html), nous utilisons deux nouveaux éléments que nous devons définir :\n1. [Les variables spécifiques](#the-variable-definitions) à chaque environnement : `../vars/$variables_file.tfvars`\n2. [Le pipeline enfant](#the-child-pipeline), défini dans `.gitlab-ci/.first-layer.gitlab-ci.yml`\n\nCommençons par le plus rapide, les définitions des variables.\n\n### Les définitions des variables\n\nNous allons ici mélanger deux solutions pour fournir des variables à Terraform :\n\n* La première utilise des [fichiers .tfvars](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files) pour tous les intrants ne contenant pas de données sensibles, qui doivent être stockées dans GitLab.\n\n![solution 1 pour fournir des variables à Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097033419.png)\n\n* La seconde utilise des [variables d'environnement](https://developer.hashicorp.com/terraform/language/values/variables#environment-variables) avec le préfixe `TF_VAR`. Combinée à la capacité de GitLab à [masquer les variables](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable), à [les protéger](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) et à les rendre [accessibles uniquement pour certains environnements](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable), cette deuxième façon d'injecter des variables est une solution puissante pour **empêcher les fuites d'informations contenant des données sensibles**. Par exemple, si vous considérez que le routage CIDR privé de votre environnement de production est une donnée sensible, vous pouvez le protéger de cette manière. Veillez à ce qu'il ne soit disponible que pour l'environnement `production`, pour les pipelines fonctionnant avec des branches et des tags protégés, et que sa valeur soit masquée dans les journaux du job.\n\n![solution 2 pour fournir des variables à Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097033422.png)\n\nDe plus, chaque fichier de variables doit être contrôlé via un [fichier `CODEOWNERS`](https://docs.gitlab.com/ee/user/project/codeowners/) où sont définies les personnes ayant l'autorisation d'apporter des modifications.\n\n```\n[Production owners] \nvars/production.tfvars @operations-group\n\n[Staging owners]\nvars/staging.tfvars @odupre @operations-group\n\n[CodeOwners owners]\nCODEOWNERS @odupre\n```\n\nCet article n'a pas pour but d'expliquer Terraform, nous allons donc simplement montrer le fichier `vars/review.tfvars`. Les fichiers d'environnement suivants sont, bien sûr, très similaires. Il suffit de définir les variables ne contenant pas de données sensibles et leurs valeurs ici.\n\n```shell\naws_vpc_cidr = \"10.1.0.0/16\"\naws_public_subnet_cidr = \"10.1.1.0/24\"\naws_private_subnet_cidr = \"10.1.2.0/24\"\n```\n\n#### Le pipeline enfant\n\nC'est dans ce pipeline que le travail concret est effectué. Il est donc un peu plus complexe que le premier. Mais rien qu'on ne puisse surmonter ensemble !\n\nComme nous l'avons vu dans la définition du pipeline principal, ce pipeline enfant est déclaré dans le fichier `.gitlab-ci/.first-layer.gitlab-ci.yml`.\n\n![Pipeline downstream déclaré dans le fichier](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097033424.png)\n\nDécomposons-le en petites étapes avant de revenir à une vue d'ensemble.\n\n##### Exécution des commandes Terraform et sécurisation du code\n\nNous allons d'abord mettre en place un pipeline pour Terraform. GitLab est une plateforme open source tout comme notre template de pipeline pour Terraform. Il vous suffit de l'inclure, en utilisant l'extrait de code suivant :\n\n```yml\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\n\nCe template exécute les vérifications Terraform sur le formatage et valide votre code, avant de le planifier et de l'appliquer. Il vous permet également de détruire ce que vous avez déployé.\n\nEn tant que plateforme DevSecOps unifiée, GitLab intègre deux scanners de sécurité directement dans ce template afin de détecter les menaces potentielles dans votre code et de vous avertir avant tout déploiement dans les environnements suivants.\n\nMaintenant que nous avons vérifié, sécurisé, compilé et déployé notre code, explorons quelques astuces supplémentaires.\n\n##### Partage du cache entre les jobs\n\nPour réutiliser les résultats des jobs dans les étapes suivantes du pipeline, nous allons activer la mise en cache. Il suffit d'ajouter le code suivant :\n\n```yml\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n```\n\nNous définissons ici un cache différent pour chaque commit, en revenant au nom de la branche principale si nécessaire.\n\nEn regardant de près les templates utilisés, on observe qu’ils contiennent des règles contrôlant l’exécution des jobs. Nous voulons exécuter tous les contrôles (assurance qualité et sécurité) sur toutes les branches. Nous allons donc personnaliser ces paramètres.\n\n##### Exécution des contrôles sur toutes les branches\n\nLes templates GitLab offrent une fonctionnalité puissante permettant de modifier uniquement certaines parties d’un template. Nous souhaitons seulement remplacer les règles de certains jobs afin de toujours exécuter des contrôles d'assurance qualité et de sécurité. Les autres paramètres de ces jobs resteront conformes au template.\n\n```yml\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - when: always\n\niac-sast:\n  rules:\n    - when: always\n```\n\nMaintenant que nous avons appliqué les contrôles d'assurance qualité et de sécurité, nous voulons différencier le comportement des environnements principaux (intégration et préproduction) dans le [workflow](#the-workflow) par rapport aux environnements de revue. Commençons par définir le comportement des environnements principaux. Nous modifierons ensuite cette configuration pour les environnements de revue.\n\n##### Pipeline CD pour l'intégration et la préproduction\n\nComme indiqué, nous voulons déployer la branche principale et les tags dans ces deux environnements. Nous ajoutons des règles pour contrôler ce déploiement sur les jobs `build` et `deploy`. Ensuite, nous activons la fonction `destroy` uniquement pour `integration`, car l'environnement `staging` est trop critique pour être supprimé en un seul clic. Les erreurs sont possibles et nous souhaitons les éviter.\n\nEnfin, nous relions le job `deploy` au job `destroy`, afin de pouvoir déclencher un `stop` sur l'environnement directement à partir de l'interface utilisateur graphique de GitLab.\n\n`GIT_STRATEGY` positionné à `none` empêche la récupération du code de la branche source dans le runner lors de la destruction. L'opération échouerait si la branche avait été supprimée manuellement. Nous comptons donc sur le cache pour obtenir tout ce dont nous avons besoin pour exécuter les instructions Terraform.\n\n```yml\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n```\n\nComme indiqué, cela nous permet de déployer sur les environnements `integration` et `staging`. Mais il manque toujours un environnement temporaire où les développeurs et développeuses peuvent expérimenter et valider leur code sans affecter le travail des autres. C'est tout l'intérêt du déploiement dans l'environnement `review`.\n\n##### Pipeline CD pour les environnements de revue\n\nLe déploiement dans l'environnement de revue n'est pas très différent du déploiement dans les environnements `integration` et `staging`. Nous allons une fois de plus tirer parti de la capacité de GitLab à remplacer uniquement des éléments de définition de job.\n\nTout d'abord, nous définissons des règles pour exécuter ces jobs uniquement sur les branches de fonctionnalités.\n\nEnsuite, nous relions le job `deploy_review` à `destroy_review`. Nous pouvons ainsi arrêter l'environnement **manuellement** à partir de l'interface utilisateur de GitLab. Plus important encore, ce job **déclenche automatiquement la destruction de l'environnement** lorsque la branche de fonctionnalité est fermée. Cette bonne pratique FinOps vous aide à contrôler vos dépenses opérationnelles.\n\nPuisque Terraform a besoin d'un fichier de plan pour la destruction d'une infrastructure, comme pour la compilation, nous ajoutons une dépendance de `destroy_review` à `build_review` afin de récupérer ses artefacts.\n\nEnfin, nous voyons ici que le nom de l'environnement est `$environment`. Il a été défini sur `review/$CI_COMMIT_REF_SLUG` dans le [pipeline principal](#the-main-pipeline) et transmis à ce pipeline enfant avec l'instruction `trigger:forward:yaml_variables:true`.\n\n```yml\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n```\n\nPour récapituler, nous avons maintenant un pipeline qui peut :\n\n* Déployer des environnements de revue temporaires, qui sont automatiquement détruits lorsque la branche de fonctionnalité est fermée\n* Déployer en continu la **branche par défaut** sur `integration`\n* Déployer en continu les **tags** sur l'environnement `staging`\n\nAjoutons maintenant un niveau supplémentaire, où nous allons déployer sur les environnements `qa` et `production` avec un déclencheur manuel.\n\n##### Pipeline CD pour l'assurance qualité et la production\n\nComme tout le monde n'est pas prêt à effectuer des déploiements continus en production, nous ajoutons une validation manuelle pour les deux prochains déploiements. À strictement parler, nous ne devrions pas ajouter ce déclencheur dans un processus **CD**, mais profitons de cette occasion pour vous apprendre à exécuter des jobs à partir d'autres déclencheurs.\n\nJusqu'à présent, nous avons lancé un [pipeline enfant](#the-child-pipeline) à partir du [pipeline principal](#the-main-pipeline) pour exécuter tous les déploiements.\n\nComme nous voulons exécuter d'autres déploiements à partir de la branche par défaut et des tags, nous ajoutons un nouveau niveau pour ces étapes supplémentaires. Rien de bien nouveau. Nous allons répéter le processus utilisé pour le [pipeline principal](#the-main-pipeline). En procédant de cette façon, vous pouvez manipuler autant de niveaux que vous le souhaitez. J'ai déjà vu jusqu'à neuf environnements.\n\nSans revenir sur les avantages d'un nombre limité d'environnements, le processus que nous utilisons ici permet d'implémenter très facilement le même pipeline, de la phase initiale jusqu’à la livraison finale, tout en gardant la définition de votre pipeline simple et divisée en petits segments que vous pouvez maintenir facilement.\n\nPour éviter les conflits de variables, nous utilisons simplement de nouveaux noms pour identifier l'état Terraform et le fichier d'intrant.\n\n```yml\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\n**Un point important ici est la stratégie utilisée pour le nouveau pipeline enfant.** Nous maintenons la valeur par défaut du déclencheur `trigger:strategy`. Dans le cas contraire, le [pipeline principal](#the-main-pipeline) attend la fin de votre [pipeline de niveau « petit-enfant »](#the-grand-child-pipeline). Si vous utilisez un déclencheur manuel, cette opération peut prendre beaucoup de temps et rendre votre tableau de bord de pipeline plus difficile à lire et à comprendre.\n\nVous vous demandez probablement ce que contient le fichier `.gitlab-ci/.second-layer.gitlab-ci.yml` qui est inclus ici. Nous aborderons cette question dans la section suivante.\n\n##### Le premier niveau complet de définition de pipeline\n\nSi vous recherchez une vue complète de ce premier niveau (stocké dans `.gitlab-ci/.first-layer.gitlab-ci.yml`), consultez la section suivante.\n\n```yml\nvariables:\n  TF_VAR_aws_ami_id: $AWS_AMI_ID\n  TF_VAR_aws_instance_type: $AWS_INSTANCE_TYPE\n  TF_VAR_aws_default_region: $AWS_DEFAULT_REGION\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n  - cleanup\n  - 2nd_layer       # Use to deploy a 2nd environment on both the main branch and on the tags\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\niac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\n###########################################################################################################\n## Integration env. and Staging. env\n##  * Auto-deploy to Integration on merge to main.\n##  * Auto-deploy to Staging on tag.\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n##  * Destroy of next env. is not automated to prevent errors.\n###########################################################################################################\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n###########################################################################################################\n\n###########################################################################################################\n## Dev env.\n##  * Temporary environment. Lives and dies with the Merge Request.\n##  * Auto-deploy on push to feature branch.\n##  * Auto-destroy on when Merge Request is closed.\n###########################################################################################################\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n###########################################################################################################\n\n###########################################################################################################\n## Second layer\n##  * Deploys from main branch to qa env.\n##  * Deploys from tag to production.\n###########################################################################################################\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n###########################################################################################################\n```\n\nÀ cette étape, nous avons déjà effectué des déploiements vers trois environnements en toute sécurité. Je trouve personnellement que cette démarche est idéale. Cependant, si vous avez besoin d'autres environnements, ajoutez-les à votre pipeline CD.\n\nVous avez sûrement remarqué que nous incluons un pipeline enfant avec le mot-clé `trigger:include`. Il inclut le fichier `.gitlab-ci/.second-layer.gitlab-ci.yml`. Nous souhaitons exécuter un pipeline très similaire, son contenu ressemble donc évidemment beaucoup à celui présenté ci-dessus. Le principal avantage de ce [pipeline de niveau « petit-enfant »](#the-grand-child-pipeline) est qu'il existe par lui-même, ce qui facilite la définition des variables et des règles.\n\n### Le pipeline de niveau « petit-enfant »\n\nCe pipeline de deuxième couche est tout nouveau. Par conséquent, il doit imiter la définition de la première couche, à savoir :\n\n* [Il doit inclure le template Terraform](#run-terraform-commands-and-secure-the-code).\n* [Il doit exécuter des contrôles de sécurité](#run-controls-on-all-branches). La validation Terraform dupliquerait le premier niveau, mais les scanners de sécurité peuvent identifier des menaces qui n'existaient pas encore lors des précédents scans (par exemple, si vous déployez en production quelques jours après votre déploiement en préproduction).\n* [Il doit remplacer les jobs de compilation et de déploiement pour définir des règles spécifiques](#cd-to-review-environments). Notez que l'étape `destroy` n'est plus automatisée pour éviter des suppressions accidentelles.\n\nComme expliqué ci-dessus, les variables `TF_STATE_NAME` et `TF_CLI_ARGS_plan` sont copiées du pipeline principal au pipeline enfant. Nous avions besoin d'un nom de variable différent pour transférer ces valeurs du pipeline enfant au pipeline « petit-enfant ». C'est pourquoi, dans le pipeline enfant, les noms de ces variables incluent le suffixe `_2`. La valeur est ensuite copiée dans la variable correspondante appropriée lors de l'exécution de la section `before_script`.\n\nComme nous avons déjà décomposé chaque étape, nous pouvons passer directement à la vue d'ensemble du deuxième niveau (codé dans `.gitlab-ci/.second-layer.gitlab-ci.yml`).\n\n```yml\n# Use to deploy a second environment on both the default branch and the tags.\n\ninclude:\n  template: Terraform.gitlab-ci.yml\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n\nfmt:\n  rules:\n    - when: never\n\nvalidate:\n  rules:\n    - when: never\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: always\n\n###########################################################################################################\n## QA env. and Prod. env\n##  * Manually trigger build and auto-deploy in QA\n##  * Manually trigger both build and deploy in Production\n##  * Destroy of these env. is not automated to prevent errors.\n###########################################################################################################\nbuild:  # terraform plan\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment:\n    name: $TF_STATE_NAME_2\n    action: prepare\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - when: manual\n\ndeploy: # terraform apply\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment: \n    name: $TF_STATE_NAME_2\n    action: start\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG && $TF_AUTO_DEPLOY == \"true\"\n    - if: $CI_COMMIT_TAG\n      when: manual\n###########################################################################################################\n```\n\nVoilà qui est fait. **Tout est prêt.** N'hésitez pas à changer la façon dont vous contrôlez l'exécution de vos jobs, en tirant parti, par exemple, de la capacité de GitLab à [retarder un job](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay) avant de le déployer en production.\n\n## Essayez par vous-même\n\nCe tutoriel est maintenant terminé. Nous savons désormais comment contrôler les **déploiements vers cinq environnements différents** en utilisant uniquement les **branches de fonctionnalités**, la **branche principale** et les **tags**.\n* Nous réutilisons intensivement les templates open source GitLab pour assurer la productivité et la sécurité de nos pipelines.\n* Nous tirons parti des capacités du template GitLab pour remplacer uniquement les blocs nécessitant un contrôle personnalisé.\n* Nous avons divisé le pipeline en petits segments et contrôlons les pipelines enfants afin qu'ils correspondent exactement à nos besoins.\n\nÀ vous de jouer maintenant. Vous pouvez, par exemple, facilement mettre à jour le pipeline principal afin de déclencher des pipelines enfants, pour votre code source logiciel, avec le mot-clé [trigger:rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges). Vous pouvez utiliser un autre [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/) en fonction des changements qui se sont produits. Mais c'est une autre histoire.",[109,1013,1014,802,804],"CI","CD","2025-01-09",{"slug":1017,"featured":6,"template":808},"using-child-pipelines-to-continuously-deploy-to-five-environments",{"category":744,"slug":748,"posts":1019},[1020,1034,1047],{"content":1021,"config":1032},{"title":1022,"description":1023,"authors":1024,"heroImage":1026,"date":1027,"body":1028,"category":748,"tags":1029,"updatedDate":1031},"Impact économique total de GitLab Ultimate : 483 % de ROI sur 3 ans","Découvrez les principales conclusions de l'étude Forrester Consulting consacrée à l'édition GitLab Ultimate, disponible sur la plateforme DevSecOps de GitLab.",[1025],"Dave Steer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2024-11-13","Une plateforme DevSecOps puissante rationalise les opérations, empêche les failles de sécurité de perturber (et de coûter cher à) votre entreprise, augmente la productivité et favorise une culture basée sur l'innovation et la collaboration. C'est exactement ce pour quoi nous avons créé GitLab, et l'édition GitLab Ultimate représente toute la puissance de notre plateforme. Pour connaître son influence concrète, nous avons demandé à Forrester Consulting de réaliser une étude « Total Economic Impact™ » sur GitLab Ultimate. Découvrez dans cet article les principales conclusions de cette étude. \n\nSelon les retours des clients interrogés, l'utilisation de GitLab génère à l'entreprise de référence :  \n\n* **Un retour sur investissement de 483 % sur trois ans**  \n* **Une amélioration de 400 % de la productivité des équipes de développement**  \n* **Une première mise en production 15 fois plus rapide\u003Csup>1\u003C/sup>**  \n* **Un gain de temps multiplié par 5 pour les tâches liées à la sécurité**\n\n**En somme, GitLab permet d'accomplir 50 % de travail à valeur ajoutée en plus.** \n\nLes chiffres parlent d'eux-mêmes : la plateforme GitLab transforme  la manière dont les équipes collaborent entre elles. Que vous soyez un responsable de la sécurité des applications chargé d'améliorer la posture de sécurité de votre entreprise, un membre de l'équipe de développement qui cherche à fournir un code de haute qualité plus rapidement ou encore un CTO à la recherche d'une plateforme DevSecOps évolutive, sécurisée et flexible, cette étude (dont la méthodologie complète est disponible ci-dessous) montre que GitLab Ultimate tient ses promesses. Examinons les résultats de l'étude.  \n\n> Téléchargez l'étude complète de [Forrester Consulting intitulée « The Total Economic Impact™ Of GitLab Ultimate » (2024)](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n## 1. Un ROI de 483 % sur trois ans\n\n*« La clé du succès pour nous a été le gain d'efficacité, à la fois au niveau de l'administration et des opérations globales. Aujourd'hui, le travail en équipe est accessible à tous et nous pouvons facilement automatiser notre pipeline. Je peux également changer la composition des équipes pour effectuer différentes tâches plus efficacement. Au lieu de former nos équipes sur différents outils en fonction des programmes, il leur suffit désormais de maîtriser GitLab pour pouvoir immédiatement se mettre au travail. »* - CTO et Senior Vice President (secteur de la Défense)\n\nL'étude révèle que les entreprises interrogées ont constaté un retour sur investissement dans les six mois suivant l'adoption de GitLab Ultimate, principalement grâce à une efficacité accrue. Avec un **retour sur investissement de 483 % sur trois ans**, elles ont pu réduire le coût de leur chaîne d'outils logiciels de 25 % et le temps consacré par leurs équipes informatiques à l'administration de ces chaînes d'outils complexes de 75 %. Au-delà des économies financières réalisées, le passage à une plateforme unifiée améliore fondamentalement la façon dont les équipes développent et livrent les logiciels.\n\n## 2. Une amélioration de la productivité de 400 %\n\n*« Lorsque j'échange avec les membres de notre équipe de développement à propos de GitLab, ils s'accordent tous sur le fait que son utilisation a augmenté la productivité de notre entreprise, à tous les niveaux et à tous les postes. Nous disposons aujourd'hui d'une plateforme dotée de fonctions et fonctionnalités accessibles à tous nos collaborateurs. »* - Software Architect, (secteur de l'énergie et de la recherche)\n\nLes équipes de développement travaillent mieux dans des environnements où ils peuvent facilement passer d'une tâche à l'autre sans interruptions. Selon cette étude, les développeurs et développeuses peuvent gagner jusqu'à 305 heures par an en [automatisant les tests](https://about.gitlab.com/fr-fr/topics/devops/devops-test-automation/) dans GitLab. Ils peuvent ainsi tester plus souvent, mais aussi suivre et corriger les bugs plus rapidement, le tout au sein d'une seule interface et donc sans changement de contexte. Ce workflow rationalisé leur permet de se concentrer sur le code plutôt que de jongler avec plusieurs outils et processus.\n\nLes gains de productivité s'étendent également à l'intégration : les nouvelles recrues de l'équipe de développement logiciel de l'entreprise de référence atteignent une productivité optimale 75 % plus rapidement (c'est-à-dire en 1,5 semaine au lieu de 1,5 mois). L'impact est clair : non seulement tous les membres de l'équipe peuvent contribuer à des tâches importantes, mais ils peuvent le faire plus tôt. \n\n## 3. Une première mise en production 15 fois plus rapide\n\n*« Le logiciel est notre botte secrète. Les éléments clés sont notre vélocité et notre capacité à offrir de nouvelles fonctionnalités à nos clients. Pour pouvoir nous concentrer sur ces objectifs premiers, il était logique d'un point de vue économique de \\[consolider\\] nos processus sur une plateforme unique. »* - CTO et Senior Vice President (secteur de la Défense)\n\nL'agrégation des données issues des entretiens avec nos clients révèlent que GitLab permet aux entreprises de déployer une première mise en production 15 fois plus rapidement. Cette accélération est facilitée par le démarrage plus rapide des projets, le déploiement plus fréquent de nouvelles versions, sans oublier une approche proactive de la sécurité qui intègre de manière native le scanning de sécurité dès le début du processus de développement. Il est ainsi possible de maintenir une qualité et une sécurité de haut niveau pour les logiciels, même dans le cadre d'une vélocité accrue, car les équipes de développement sont capables de remédier aux problèmes rapidement, dès leur apparition. \n\nL'[intégration de la sécurité directement dans le processus de développement](https://about.gitlab.com/solutions/security-compliance/) permet aux équipes d'identifier, de prioriser et de corriger les failles de sécurité sans interrompre leur workflow. Cette approche unifiée de la gestion de l'ensemble du cycle de développement logiciel permet aux équipes de progresser plus rapidement sans sacrifier la sécurité.\n\n## 4. Un gain de temps multiplié par 5 pour les tâches liées à la sécurité\n\n*« L'intégration des scanners de sécurité et de qualité dans le pipeline a changé la donne. Grâce à une automatisation accrue et à la réduction des processus manuels, nos pipelines rencontrent moins d'échecs, moins de problèmes et les projets avancent plus rapidement. »* - Program Manager (secteur financier) \n\nFace à l'accélération du développement et à l'évolution des menaces, la sécurité reste une priorité absolue pour toutes les entreprises. GitLab permet aux membres des équipes chargées de la sécurité de l'entreprise de référence d'économiser **78 heures par membre et par an** en automatisant les tâches récurrentes telles que la préparation à la reprise après sinistre, les audits et les contrôles de conformité. GitLab améliore également la visibilité des processus de développement logiciel, en aidant les équipes dédiées à la sécurité et au développement à mieux collaborer.  \n\nPour les équipes de cybersécurité et de développement logiciel de l'entreprise de référence, **la gestion et la réduction des risques de sécurité tout au long du cycle de développement logiciel nécessitent désormais 81 % d'efforts en moins.** En effet, GitLab leur permet d'intégrer des protocoles et des scans de sécurité à chaque étape du cycle de développement logiciel, ce qui simplifie le maintien de normes de sécurité strictes. Grâce à l'intégration des tests de sécurité et des mesures correctives dans les pipelines, les équipes réduisent les temps de réponse moyens et empêchent les problèmes d'atteindre l'environnement de production. \n\n## Découvrez l'approche DevSecOps en action\n\nAvec un retour sur investissement de 483 %, un amortissement rapide et d'innombrables exemples de réussites, GitLab est un outil inestimable pour les entreprises qui cherchent à transformer leurs processus de développement logiciel.\n\n> Pour découvrir les avantages de GitLab pour votre entreprise, téléchargez dès maintenant l'étude complète de [Forrester Consulting intitulée « The Total Economic Impact™ Of GitLab Ultimate »](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n**Méthodologie**  \n\n*Dans le cadre de cette étude, Forrester a interrogé quatre clients ayant adopté GitLab Ultimate et exerçant dans divers secteurs (notamment celui de la Finance, de la Défense et de la Recherche), puis a consolidé les résultats sous la forme d'une entreprise de référence. L'objectif pour cette entreprise de référence est d'adopter GitLab Ultimate pour l'ensemble de ses équipes sur une période de trois ans.*\n\n*L'entreprise de référence est une société au capital de 5 milliards de dollars, qui compte 5 000 employés (dont 40 % sont impliqués dans la livraison de logiciels) et 50 % de son chiffre d'affaires annuel dépend du développement logiciel. Ses objectifs sont de consolider plusieurs outils sous la forme d'une plateforme intégrée unique, d'améliorer la productivité de son équipe de développement, de garantir le respect des réglementations du secteur et de ses politiques internes, et de renforcer la sécurité tout au long du cycle de développement.*\n\n*1. Sur la base de données agrégées issues des entretiens avec nos clients ; non applicable aux résultats de l'entreprise de référence.*",[802,1030,748,783],"research","2024-11-26",{"slug":1033,"featured":91,"template":808},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"content":1035,"config":1045},{"title":1036,"description":1037,"authors":1038,"heroImage":1040,"date":1041,"body":1042,"category":748,"tags":1043,"updatedDate":1044},"The Source : une mine d'informations sur l'avenir du développement logiciel","Découvrez des stratégies de développement logiciel transformatrices et des conseils d'experts sur les technologies émergentes.",[1039],"Chandler Gibbons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","2024-10-29","Le développement logiciel moderne transforme la façon dont les entreprises créent, proposent et développent de la valeur commerciale. Les équipes doivent être en mesure d’élaborer des solutions rapidement et efficacement, tout en gérant les menaces de sécurité croissantes, les technologies émergentes et les exigences de conformité de plus en plus complexes.\n\nAujourd'hui, GitLab lance [The Source](https://about.gitlab.com/fr-fr/the-source/), une nouvelle publication qui couvre l'évolution du développement logiciel en tant que moteur de la réussite commerciale. Nous partageons régulièrement des informations clés sur l'avenir du développement logiciel, étayées par les recherches et les analyses originales de nos experts métier et de nos leaders d'opinion.\n\nThe Source vous permet par exemple de trouver des réponses aux questions suivantes : \n* Comment les dirigeants peuvent-ils mesurer le retour sur investissement de l'IA tout au long du cycle de développement logiciel ?  \n* Quelle est la meilleure façon de garantir la sécurité et la conformité tout au long de la chaîne d'approvisionnement logicielle ?\n* Quels gains de productivité les équipes peuvent-elles réaliser grâce à la consolidation de leur plateforme et de leur chaîne d'outils ?\n\nVoici un aperçu du contenu que vous pouvez d'ores et déjà retrouver sur The Source : \n\n**Mesurer l'impact de l'IA : 4 étapes indispensables**\n\n« L'évaluation de la productivité dans un contexte de développement amélioré par l'IA nécessite une approche plus nuancée que celle reposant sur les indicateurs traditionnels tels que les lignes de code, les validations de code ou l'achèvement des tâches. Elle nécessite une réorientation vers des résultats commerciaux concrets qui permettent d'équilibrer la rapidité de développement, la qualité des logiciels et la sécurité. »\n- [Taylor McCaslin, expert en IA, présente les 4 étapes indispensables pour mesurer l'impact de l'IA.](https://about.gitlab.com/fr-fr/the-source/ai/4-steps-for-measuring-the-impact-of-ai/)\n\n**Identifier et remédier aux points de friction liés à la sécurité**\n\n« Bien que l'approche DevSecOps promette une meilleure intégration entre l'ingénierie et la sécurité, la présence de frustrations et de déséquilibres montre que des défis subsistent. Ce constat reflète un problème plus large lié à la manière dont les entreprises perçoivent la sécurité, organisent la collaboration entre les équipes, et allouent du temps à cette priorité. »\n- [Trouvez le bon équilibre, grâce à l'expertise de Josh Lemos, CISO de GitLab.](https://about.gitlab.com/fr-fr/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/)\n\n**L'ingénierie de plateforme au service de la réussite des entreprises**\n\n« En normalisant et en optimisant les workflows des équipes de développement, l'ingénierie de plateforme crée des \"golden paths\" optimisés pour les tâches courantes tout en offrant la flexibilité nécessaire pour les tâches plus uniques et spécialisées. »  \n- [Découvrez les bonnes pratiques de Brian Wald (GitLab Field CTO) en matière d'ingénierie de plateforme.](https://about.gitlab.com/fr-fr/the-source/platform-and-infrastructure/driving-business-results-with-platform-engineering/)\n\n## The Source, votre partenaire pour la prise de décision\n\nConsultez [The Source](https://about.gitlab.com/fr-fr/the-source/) dès aujourd'hui pour découvrir les dernières informations du secteur, obtenir des réponses en matière de leadership et découvrir les dernières nouveautés du marché à partager avec vos équipes. Vous pouvez également vous abonner à notre newsletter pour recevoir des mises à jour régulières par e-mail. Rejoignez notre communauté de leaders technologiques avant-gardistes et contribuez à façonner l'avenir du développement logiciel.",[846,783,748,720],"2024-11-11",{"slug":1046,"featured":91,"template":808},"introducing-the-source-insights-for-the-future-of-software-development",{"content":1048,"config":1058},{"title":1049,"description":1050,"authors":1051,"heroImage":1053,"date":1054,"body":1055,"category":748,"tags":1056,"updatedDate":1057},"GitLab nommée Leader dans le Magic Quadrant 2024 de Gartner dédié aux plateformes DevOps","Notre approche DevOps innovante et le succès de nos clients ont permis à GitLab de figurer en tête du classement pour sa capacité d'exécution et l'exhaustivité de sa vision.",[1052],"Ashley Kramer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","2024-09-05","À l'origine, l'approche DevOps n'était qu'un concept, une méthodologie qui permettait de livrer des logiciels plus rapidement en réunissant des équipes traditionnellement disparates. Il s'agissait de répondre aux problèmes causés par la séparation entre les équipes de développement et celles de déploiement.\n\nChez GitLab, nous avons repris ce concept et l'avons développé : au lieu d'assembler des outils pour créer une chaîne d'outils DevOps complexe, nous avons créé une [plateforme DevOps unique](https://about.gitlab.com/fr-fr/platform/) pour encourager une collaboration plus étroite, une automatisation plus poussée et des processus plus évolutifs et standardisés.\n\nNous sommes convaincus de la valeur de cette stratégie, qui est axée sur la réussite de nos clients. À l'occasion de la deuxième édition du [Magic Quadrant de Gartner dédié aux plateformes DevOps](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/), nous avons à nouveau été reconnus comme un des Leaders, cette fois-ci, dans les deux domaines suivants : Capacité d'exécution et Exhaustivité de la vision.\n\n![Image Gartner MQ pour les plateformes DevOps 2024](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> Téléchargez le [rapport Magic Quadrant™ 2024 de Gartner® dédié aux plateformes DevOps](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/).\n\nLes fournisseurs de logiciels doivent aujourd'hui faire face à des menaces de sécurité croissantes et à des exigences de conformité complexes, tout en adoptant avec discernement les nouvelles technologies comme l'IA générative. Et bien sûr, ils doivent fournir à leurs clients des services évolutifs et toujours plus innovants.\n\nL'objectif de GitLab est d'aider ses clients à surmonter ces défis et à devenir des leaders dans leurs secteurs. Grâce à notre plateforme DevSecOps alimentée par l'IA, ils peuvent anticiper les problèmes de sécurité et améliorer la visibilité tout au long du cycle de développement, tout en rassemblant les acteurs nécessaires pour créer des logiciels indispensables.\n\n## Aller plus loin dans l'approche DevOps\n\nMais l'aventure ne fait que commencer ! Notre objectif ? Continuer à développer la vision DevOps et faire progresser notre plateforme DevSecOps de deux manières.\n\nPour commencer, nous voulons inviter encore plus d'équipes à collaborer sur la même plateforme, avec des fonctionnalités dédiées à celles impliquées dans [la planification Agile](https://about.gitlab.com/fr-fr/blog/categories/agile-planning/), la [science des données](https://about.gitlab.com/fr-fr/topics/devops/the-role-of-ai-in-devops/) et [l'observabilité](https://about.gitlab.com/fr-fr/blog/observability-vs-monitoring-in-devops/) et la surveillance des applications.\n\nDeuxièmement, nous voulons rendre l’adoption de notre plateforme et les options de déploiement encore plus flexibles pour répondre aux divers besoins de nos clients. Pour ce faire, nous enrichissons [GitLab Dedicated](https://about.gitlab.com/dedicated/), notre option hébergée à locataire unique, afin que les entreprises évoluant dans des secteurs hautement réglementés puissent bénéficier de la simplicité du SaaS et des nouvelles fonctionnalités et capacités, tout en respectant les besoins de conformité des infrastructures isolées.\n\n## Aider les entreprises à créer des logiciels sûrs\n\nAu-delà de la création d'une meilleure plateforme de collaboration pour le développement de logiciels, l'un de nos objectifs clés est d'aider les entreprises à produire des logiciels plus sûrs et plus conformes. C'est cet objectif qui nous démarque de nos concurrents, car GitLab intègre le [scanning de sécurité](https://about.gitlab.com/fr-fr/solutions/security-compliance/) au stade de la validation du code, et non lorsque les applications sont prêtes à être publiées. Les équipes peuvent ainsi détecter plus rapidement les vulnérabilités, ce qui accélère les cycles de sortie. GitLab facilite également le respect de la conformité grâce à la présence de garde-fous au niveau des stratégies et à la génération automatique [d'une nomenclature logicielle](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une nomenclature logicielle (SBOM) ?\").\n\nNous savons que la sécurité est un enjeu de plus en plus important pour nos clients, à mesure que la surface d'attaque de leur logiciel s'étend. C'est pourquoi, au cours des 12 prochains mois, nous prévoyons de continuer à améliorer nos scanners SAST, d'ajouter des contrôles supplémentaires au niveau des stratégies de sécurité et de compiler [un nouveau gestionnaire de secrets natif](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/).\n\n## Accompagner tout le cycle du développement logiciel grâce à l'IA\n\nNotre vision est également d'être leader dans le domaine de l'IA, à la fois en aidant nos clients à créer des logiciels innovants avec l'IA, mais aussi en exploitant les technologies d'IA respectueuses de la confidentialité. L'IA représente en effet une véritable avancée et offre d'innombrables opportunités lorsqu'elle est intégrée tout au long du cycle de développement logiciel. Mais pour nous, l'innovation doit avant tout se faire de manière responsable. Les préoccupations de nos clients sont claires : ils veulent une [IA avec des garde-fous](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/), une [IA transparente](https://about.gitlab.com/fr-fr/ai-transparency-center/) et une IA qui respecte leur code et leur propriété intellectuelle.\n\nNous nous engageons à enrichir [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), une suite de fonctionnalités alimentées par l'IA pour notre plateforme DevSecOps qui sont à la fois complètes, respectueuses de la confidentialité et conçues pour prendre en charge l'ensemble du cycle de développement logiciel.\n\nC'est cet engagement et nos fonctionnalités GitLab Duo qui ont encouragé [Gartner® à nous nommer Leader dans son premier Magic Quadrant™ dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/).\n\nNous sommes fiers de cette reconnaissance qui nous encourage à rester à l'écoute de nos clients afin de continuer à développer notre vision, notre roadmap produit et notre engagement à créer la meilleure plateforme DevSecOps.\n\n> Téléchargez le [rapport Magic Quadrant™ 2024 de Gartner® dédié aux plateformes DevOps](https://about.gitlab.com/fr-fr/gartner-magic-quadrant/).\n\n***Source : Gartner, Magic Quadrant dédié aux plateformes DevOps, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, août 2024***\n\n***GARTNER est une marque déposée et une marque de service de Gartner, Inc. et/ou de ses sociétés affiliées aux États-Unis et à l'étranger et MAGIC QUADRANT est une\nmarque déposée de Gartner, Inc. et/ou de ses sociétés affiliées. Elles sont utilisées ici avec autorisation. Tous droits réservés.***\n\n***Gartner ne cautionne aucun fournisseur, produit ou service décrit dans ses publications de recherche, et ne conseille pas aux utilisateurs de la technologie de sélectionner uniquement les fournisseurs ayant les notes les plus élevées ou toute autre désignation. Les publications de recherche de Gartner reflètent les opinions de l'organisation de recherche de Gartner et ne doivent pas être interprétées comme des déclarations de fait. Gartner décline toute garantie, expresse ou implicite, à l'égard de cette recherche, y compris toute garantie de qualité marchande ou d'adéquation à un usage particulier.***\n\n***Ce graphique a été publié par Gartner Inc. dans le cadre d'un rapport plus vaste et doit être évalué dans le contexte de l'ensemble du document. Le document produit par Gartner est disponible sur demande auprès de Gartner.***",[748,1030,802,930,720],"2024-10-07",{"slug":1059,"featured":91,"template":808},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"category":756,"slug":760,"posts":1061},[1062,1074,1085],{"content":1063,"config":1072},{"body":1064,"title":1065,"description":1066,"heroImage":1067,"authors":1068,"date":1070,"category":760,"tags":1071},"Le projet Git a récemment publié la [version 2.50.0 de Git](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u). Découvrons les points forts de cette nouvelle version, qui comprend les contributions de l'équipe Git de GitLab et de la communauté Git.\n\n## Nouvelle commande git-diff-pairs(1)\n\nLes diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet [« Modifications »](https://docs.gitlab.com/user/project/merge_requests/changes/) d'une merge request. En arrière-plan, la génération de diff est optimisée par [`git-diff(1)`](https://git-scm.com/docs/git-diff).\n\nPar exemple :\n\n```shell\n$ git diff HEAD~1 HEAD\n```\n\nCette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème d'évolutivité, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser une délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à assimiler.\n\nPour ce faire, vous pouvez utiliser [`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree/fr) pour récupérer des informations sur tous les fichiers modifiés :\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n```\n\nGit appelle ce résultat le [format « brut »](https://git-scm.com/docs/git-diff-tree/fr). En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de la sortie de « correctif » pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer détection de changement de nom en ajoutant `-M` pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.\n\nAvec ces informations, nous pourrions utiliser `git-diff(1)` pour calculer chacun des diffs de paire de fichiers individuellement.\n\\\nPar exemple, nous pouvons fournir directement des ID de blob :\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n```\n\nNous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme permettant d'alimenter des informations « brutes » sur les paires de fichiers et de générer la sortie de correctifs correspondants.\n\nAvec la version 2.50.0, Git dispose d’une nouvelle commande intégrée `git-diff-pairs(1)`, qui prend en charge les informations de paires de fichiers au format « brut » en tant qu'entrée sur stdin pour déterminer avec précision les correctifs à générer.\n\nL'exemple suivant montre comment cette commande peut être utilisée :\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nDe cette façon, la sortie générée est identique à celle obtenue avec `git-diff(1)`. En utilisant une commande distincte pour générer la sortie de correctif, la sortie « brute » de `git-diff-tree(1)` peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus `git-diff-pairs(1)` distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.\n\nPour plus d'informations sur ce changement, consultez ce [fil de discussion](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\\\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n## Mises à jour des références par lots\n\nGit fournit la commande `git-update-ref(1)` pour effectuer des mises à jour de références. Lorsqu'elle est associée à `--stdin`, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur stdin. La mise à jour des références par lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.\n\nVoici un exemple illustrant ce comportement :\n\n```shell\n# Create repository with three empty commits and branch named \"foo\"\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n# Print out the commit IDs\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n# Attempt to create a new reference and update existing reference in transaction.\n# Update is expected to fail because the specified old object ID doesn’t match.\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n# The \"bar\" reference was not created.\n$ git switch bar\nfatal: invalid reference: bar\n```\n\nEn comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Cela ne remet pas en cause les gains de productivité obtenus grâce aux mises à jour par lot.\n\nAvec cette version, `git-update-ref(1)` met à disposition la nouvelle option `--batch-updates`, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.\n\nDans ce mode, les échecs individuels sont signalés dans le format suivant :\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n```\n\nCela permet de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.\n\nVoici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :\n\n```shell\n# Attempt to create a new reference and update existing reference in transaction.\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n$ git switch bar\nSwitched to branch 'bar'\n```\n\nCette fois, avec l'option `--batch-updates`, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de correctifs est un aperçu des futures améliorations des performances de `git-fetch(1)` et `git-receive-pack(1)` lors de la mise à jour de références par lot.\n\nPour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/).\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Nouvelle option de filtre pour git-cat-file(1)\n\nAvec `git-cat-file(1)`, il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option `--batch–all-objects`.\n\nEn voici un exemple :\n\n```shell\n# Setup simple repository.\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n# Create an unreachable object.\n$ git commit --amend --no-edit\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nDans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.\n\nPar exemple, si nous voulons voir uniquement les objets qui correspondent à des commits, nous pouvons utiliser `grep(1)` :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nBien que cela fonctionne, un des inconvénients du filtrage de la sortie est que `git-cat-file(1)` doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.\n\nAvec la version 2.50.0, `git-cat-file(1)` dispose désormais de l'option `--filter`, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour `git-rev-list(1)`, mais seul un sous-ensemble des filtres est pris en charge : `blob:none`, `blob:limit=`, ainsi que `object:type=`.\n\nComme dans l'exemple précédent, il est possible de filtrer les objets par type avec [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") directement :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nCette approche facilite le traitement par Git, mais également la recherche dans les grands dépôts contenant de nombreux objets. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage («packfile»), ce qui accélère de manière considérable le processus.\n\nLes benchmarks effectués sur le [dépôt Chromium](https://github.com/chromium/chromium.git) montrent des améliorations significatives :\n\n```text\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\nRange (min … max): 73.936 s … 89.690 s 10 runs\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\nRange (min … max): 1.541 s … 1.566 s 10 runs\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\nRange (min … max): 11.114 s … 11.245 s 10 runs\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\nRange (min … max): 62.836 s … 73.618 s 10 runs\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\nRange (min … max): 12.960 s … 13.199 s 10 runs\nSummary\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n```\n\nIl est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n## Amélioration des performances lors de la génération de paquets\n\nAvec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui l'accompagnent via la commande [`git-bundle(1)`](https://git-scm.com/docs/git-bundle/fr). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme [`bundle-URI`](https://git-scm.com/docs/bundle-uri).\n\nPour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab ([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans le paquet. L'implémentation a utilisé une boucle `for` imbriquée pour itérer et comparer toutes les références répertoriées, ce qui a entraîné une complexité temporelle O(N^2). Cette façon de procéder n'est pas adaptée en cas d'augmentation du nombre de références dans un dépôt.\n\nDans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par une structure de données de mappage, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'un paquet avec un dépôt contenant 100 000 références :\n\n```text\nBenchmark 1: bundle (refcount = 100000, revision = master)\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\nRange (min … max): 14.237 s … 14.920 s 10 runs\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\nRange (min … max): 2.364 s … 2.425 s 10 runs\nSummary\nbundle (refcount = 100000, revision = HEAD) ran\n6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nPour en savoir plus, découvrez notre article de blog qui explique [comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) et consultez ce [fil de discussion](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n*Ce projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n## Meilleur dégroupage des URI de paquets\n\nÀ l'aide du mécanisme [bundle-uri](https://git-scm.com/docs/bundle-uri) dans Git, il est possible de fournir aux clients les emplacements pour récupérer les paquets dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge un paquet, les références sous `refs/heads/*` et les objets qui les accompagnent sont copiés du paquet dans le dépôt. Un paquet peut contenir des références supplémentaires en dehors de `refs/heads/*` telles que `refs/tags/*`, qui sont simplement ignorées lors de l'utilisation de l'URI du paquet sur le clone.\n\nDans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à `refs/*` contenues dans le paquet téléchargé sont copiées.\n\n[Scott Chacon](https://github.com/schacon), qui a contribué à cette fonctionnalité, montre la différence lors du clonage de [gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss) :\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nEn comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction du paquet, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.\n\nPour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n*Cette série de correctifs a été fournie par Scott Chacon.*\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) du projet Git et en consultant ces [ressources](https://about.gitlab.com/blog/tags/git/).","Nouveautés de Git 2.50.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png",[1069],"Justin Tobler","2025-07-02",[269,985,901],{"featured":6,"template":808,"slug":1073},"what-s-new-in-git-2-50-0",{"content":1075,"config":1083},{"title":1076,"description":1077,"authors":1078,"heroImage":1079,"date":1080,"body":1081,"category":760,"tags":1082},"Open source : définition, avantages et défis","Qu'est-ce que l'open source ? Apprenez comment ce modèle collaboratif transforme le développement logiciel grâce au libre accès et au partage du code.",[965],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662973/Blog/Hero%20Images/open-source-definition.jpg","2025-04-16","Basé sur des principes fondamentaux tels que l'ouverture, le partage des connaissances et l'amélioration continue, l'open source révolutionne le monde du développement logiciel. En réunissant des développeurs du monde entier, l'open source crée un environnement propice à l'innovation, où les idées et les solutions émergent grâce à la diversité des contributions. \n\nDécouvrez dans cet article les principes fondamentaux du développement [open source](https://about.gitlab.com/fr-fr/solutions/open-source/ \"Solutions GitLab pour les projets open source\"). \n\n## Qu’est-ce que l’open source ? \n\nL'open source est un modèle de développement fondé sur la transparence et la collaboration. Contrairement aux logiciels propriétaires, où seul le détenteur des droits peut modifier le code source ou redistribuer le produit, l'open source rend ce code accessible à tous. Les développeurs du monde entier peuvent ainsi l'examiner, l'améliorer et le partager librement, favorisant l'innovation et le progrès collectif.\n\n> [\nEssayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/devsecops/ \"Essai gratuit de GitLab Ultimate\") et commencez à développer des logiciels open source dès aujourd'hui.\n\n## Quels sont les avantages de l'open source ?\n\nBien plus qu'une alternative technologique, l'open source est un modèle offrant de nombreux avantages. Réduction des coûts, accélération de l'innovation, meilleure sécurité des logiciels, ou encore personnalisation, sont autant d'atouts qui peuvent transformer les projets et stimuler la croissance des entreprises.\n\n### Des coûts réduits \n\nÀ l'opposé des solutions propriétaires parfois onéreuses, les logiciels open source se distinguent souvent par leur faible coût, vous dispensant des dépenses traditionnellement associées aux licences et au support technique. Chez GitLab par exemple, les utilisateurs ont la possibilité d’utiliser gratuitement [GitLab Community Edition (CE)](https://about.gitlab.com/fr-fr/install/ce-or-ee/ \"GitLab Community Edition (CE)\") qui est open source. \n\n### Une meilleure transparence\n\nL'accès au code source permet à qui le souhaite d'examiner, de modifier et d'améliorer les logiciels. Pour les développeurs, cette transparence facilite leur compréhension des logiciels, de la manière dont ils sont construits et des failles de sécurité potentielles qu'ils peuvent contenir. Par exemple, le code source de GitLab est disponible publiquement sur GitLab.com et offre aux utilisateurs l'opportunité d’inspecter le code, de comprendre son fonctionnement et même de contribuer activement à son développement.  \n\n### Des logiciels personnalisables \n\nL'open source offre aux entreprises la possibilité d'adapter leurs logiciels à leurs besoins spécifiques, là où les solutions propriétaires limitent souvent cette liberté. Grâce à leur nature modulable, les logiciels open source permettent d'optimiser l'efficacité opérationnelle en s'adaptant précisément aux besoins des entreprises. GitLab illustre cette flexibilité en offrant à tous la possibilité de contribuer de façon traditionnelle, et en offrant également aux entreprises la possibilité de développer des intégrations et des fonctionnalités sur mesure grâce à son [programme Co-Create](https://about.gitlab.com/community/co-create/ \"Programme Co-Create\").\n\n### Une communauté engagée \n\nLes projets open source reposent sur l'engagement d'une communauté qui partage ses connaissances pour résoudre des problèmes ou proposer des améliorations sur les logiciels. GitLab [tire pleinement parti de cet écosystème](https://about.gitlab.com/community/ \"Communauté de GitLab\") en s'appuyant sur une base d'utilisateurs et de développeurs qui enrichissent activement son développement et [partagent leur expertise](https://forum.gitlab.com/ \"Forum de GitLab\"). GitLab collabore également avec d'autres entreprises sur des projets open source comme Git, renforçant son engagement pour l'innovation collective et la création de solutions évolutives.\n\n### Un accélérateur d’innovations\n\nEn réunissant des talents du monde entier autour de projets communs, l'open source devient un puissant moteur d'innovation. Cette synergie stimule l'amélioration continue et l'enrichissement des logiciels grâce à la diversité des compétences partagées. Ce modèle accélère ainsi le développement technologique en rendant les outils open source accessibles à un large public. GitLab, avec son cycle de release mensuel, [intègre régulièrement de nouvelles fonctionnalités et améliorations](https://about.gitlab.com/releases/ \"Releases GitLab\") fondées sur les retours et contributions de sa communauté d'utilisateurs.\n\n### Des logiciels évolutifs\n\nLes logiciels open source reposent souvent sur des normes ouvertes qui [simplifient leur intégration avec d'autres systèmes](https://about.gitlab.com/fr-fr/integrations/ \"Intégrations GitLab\"). Conçus pour s'adapter à divers environnements, ils offrent aux entreprises la possibilité de créer des solutions sur mesure, performantes et évolutives.\n\n### Une sécurité logicielle renforcée\n\nLa sécurité et la fiabilité sont des piliers essentiels des logiciels open source. Grâce à l'examen continu du code par une large communauté de développeurs, les failles de sécurité sont rapidement identifiées et corrigées. Bien que cette approche ne garantisse pas une sécurité absolue, elle favorise grandement la réactivité des équipes de développement face aux vulnérabilités de toutes sortes. GitLab applique ce principe en [s'appuyant sur sa communauté pour renforcer la sécurité de sa plateforme](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/).\n\n### Un savoir-faire enrichi\n\nLes logiciels open source représentent une mine d'opportunités d'apprentissage pour les développeurs. En s'impliquant dans ces projets, ils peuvent perfectionner leurs compétences et gagner en expérience auprès d'autres professionnels du domaine, enrichissant leur savoir-faire et accélérant leur développement professionnel.\n\nPar exemple, les développeurs peuvent étudier la base de code de GitLab pour apprendre les meilleures pratiques en matière de développement de plateformes DevSecOps. Les membres de l'équipe GitLab participent par ailleurs à des programmes de mentorat comme [Google Summer of Code](https://about.gitlab.com/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare/ \"Google Summer of Code\") et [Outreachy](https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020/ \"Outreachy\") qui permettent d'apprendre aux nouveaux participants comment contribuer à GitLab ou autres logiciels open source comme Git.\n\n### Des logiciels plus qualitatifs\n\nDe nombreux projets open source bénéficient de la contribution de développeurs talentueux. Grâce à leur expertise, le code des logiciels open source est constamment examiné, amélioré et renforcé, ce qui permet de développer des solutions robustes et performantes.\n\n## Quels sont les défis liés à l’open source\n\nExplorer l'univers des logiciels open source peut être aussi stimulant qu'exigeant. De la création de relations solides avec une communauté au renforcement de la sécurité des projets, chaque étape comporte ses propres défis. Pour réussir, il est essentiel de comprendre ces obstacles et de mettre en place des stratégies adaptées.\n\n### Construire une relation solide avec sa communauté \n\nLe succès du développement open source repose sur la capacité à établir et à maintenir une relation solide avec une communauté de développeurs et d'utilisateurs. Cela nécessite des échanges continus afin de comprendre et de répondre à ses attentes. Puisque la majorité des contributeurs sont bénévoles, il est essentiel de coordonner leurs efforts de manière agile et structurée.\n\nPour maintenir leur motivation sur le long terme, notamment pour les contributeurs œuvrant sans contrepartie financière, il est crucial de reconnaître et de valoriser leur travail. Cela peut passer par des mentions officielles (crédits), des opportunités de formation ou d'autres formes de reconnaissances professionnelles. Sans cette valorisation, les contributeurs risquent de se détourner des projets, voire de créer des initiatives parallèles. Bâtir une communauté engagée et durable est donc au cœur du succès de tout projet open source.\n\n### Trouver un équilibre entre les intérêts de la communauté et celle des entreprises\n\nTrouver un équilibre entre les intérêts des entreprises et ceux de la communauté est un défi central dans le développement open source. Les entreprises impliquées dans ces projets ont généralement des objectifs prioritaires. Ces priorités, souvent commerciales, peuvent entrer en conflit avec les attentes plus larges de la communauté, dont les intérêts sont plutôt axés sur l'innovation libre ou la personnalisation des logiciels.\n\nLorsque les décisions semblent trop axées sur les intérêts de l'entreprise, la communauté risque de se sentir exclue, ce qui peut réduire son engagement et limiter ses contributions. Pour éviter ce désengagement, les entreprises doivent partager clairement leurs objectifs et échanger régulièrement avec leur communauté pour garantir la pérennité et le succès à long terme des projets open source.\n\n### Maintenir la sécurité des logiciels\n\nLes logiciels open source sont exposés à certains défis en matière de sécurité. La transparence du code, bien qu'étant l'un de leurs plus grands atouts, peut aussi les exposer à des attaques ciblées, ce qui peut devenir un risque majeur si l'entreprise à l’origine du projet open source ne corrige pas rapidement les failles identifiées. \n\nLes utilisateurs comptent ainsi sur la réactivité de l'entreprise pour garantir la sécurité de leurs systèmes et de leurs données. \n\n## GitLab : un partenaire incontournable pour les projets open source\n\nLes projets open source sont un moteur d'innovation technologique, et choisir la bonne plateforme pour les héberger est essentiel. Grâce à son système de gestion de versions basé sur [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"), GitLab permet aux équipes de développement de collaborer efficacement, de suivre les modifications de code et de conserver un historique complet de leurs projets. \n\n### Une suite complète de fonctionnalités collaboratives\n\nGitLab met à disposition de ses utilisateurs une suite complète de fonctionnalités adaptées au développement et à la gestion de projets open source. Parmi ces fonctionnalités figurent le [suivi des tickets](https://docs.gitlab.com/ee/user/project/issues/ \"Tickets GitLab\"), les [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/ \"merge requests\"), la [revue de code](https://about.gitlab.com/fr-fr/topics/version-control/what-is-code-review/ \"Qu'est-ce qu'une revue de code ? \"), les [wikis](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"GitLab Wiki\") et les [GitLab Pages](https://about.gitlab.com/fr-fr/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages/ \"GitLab Pages\"). Ces fonctionnalités permettent aux équipes de suivre l'évolution des projets, de collaborer, de proposer des améliorations, de corriger des bogues et de documenter leurs progrès en temps réel. \n\n### Des pratiques CI/CD au service des projets open source\n\nLes fonctionnalités [CI/CD](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/ \"Meilleures pratiques CI/CD\") de GitLab sont un atout majeur pour les projets open source. Elles automatisent des étapes clés du développement logiciel, comme les [tests](https://docs.gitlab.com/ee/ci/testing/), la validation du code et le déploiement de nouvelles versions, assurant ainsi une meilleure fiabilité des logiciels open source et un développement accéléré. Chaque contribution est automatiquement testée dans un environnement dédié, ce qui permet de détecter rapidement les erreurs et de corriger les bogues. Cela réduit les risques de défaillances tout en assurant la stabilité des projets. \n\n### Un cycle de développement logiciel sécurisé\n\nGitLab propose une suite complète de fonctionnalités conçues pour aider les développeurs de projets open source à sécuriser leurs logiciels. Parmi ces fonctionnalités, nous retrouvons :\n\n- __Le test statique de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))__ qui examine le code source à la recherche de failles de sécurité en amont de la mise en service des logiciels. \n- __Le test dynamique de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))__* qui teste les applications en cours d'exécution au sein d’un environnement déployé pour détecter d'éventuelles vulnérabilités encore non repérées. \n- __L'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/ \"Analyse des dépendances\")__* qui envoie des alertes sur les bibliothèques obsolètes ou vulnérables. Des rapports détaillés sont générés à chaque étape du développement, offrant une visibilité claire sur l'état de la sécurité du projet. Grâce à cela, les développeurs peuvent rapidement éviter ou corriger les composants à risque.\n\n** Fonctionnalité disponible uniquement pour les utilisateurs de GitLab Ultimate.*\n\nEn intégrant ces fonctionnalités directement dans le [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\"), GitLab réduit le risque d'erreurs humaines et accélère l’identification et la correction des vulnérabilités. Cette approche permet ainsi aux développeurs de projets open source de maintenir un niveau élevé de sécurité tout au long du cycle du développement logiciel. \n\n### Une gestion de projet Agile\n\nGitLab met à disposition des équipes de développement un certain nombre de fonctionnalités pour faciliter la gestion des projets open source comme les [tableaux de tickets](https://docs.gitlab.com/ee/user/project/issue_board.html \"Tableaux de tickets\"), les [listes des jalons](https://docs.gitlab.com/ee/user/project/milestones/ \"Listes des jalons\") ou encore le [suivi du temps](https://docs.gitlab.com/ee/user/project/time_tracking.html \"Suivi du temps\"). Ces dernières permettent de voir facilement les tâches à réaliser, de suivre l'avancement des projets en fixant des échéances claires, mais aussi d’évaluer la charge de travail en vue d'optimiser l'utilisation des ressources. En combinant ces fonctionnalités, GitLab permet aux équipes de mieux coordonner leurs efforts, de maintenir un processus de travail fluide et de progresser efficacement dans la réalisation de leurs projets open source.\n\n### Des contributions simplifiées\n\nLes équipes de développement peuvent facilement contribuer au développement de projets open source en les dupliquant ([fork](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html \"fork\")) et en créant des merge requests. Elles peuvent créer leurs propres copies du code, travailler sur des améliorations ou des correctifs dans des branches distinctes, puis soumettre leurs changements via des merge requests. Ce processus permet aux équipes de réviser et de valider chaque modification avant son intégration dans la branche principale, favorisant ainsi une amélioration continue des logiciels, tout en renforçant la qualité et la stabilité du code.\n\n### Une intégration facilité avec d’autres outils\n\nGitLab facilite considérablement son intégration avec d’autres outils et workflows , permettant aux équipes de développement de créer un environnement personnalisé en fonction des exigences spécifiques de leur projet. Pour en savoir plus, [consultez notre documentation](https://docs.gitlab.com/ee/api/). \n\n## Développez des logiciels open source avec GitLab \n\nL’open source continue de s'imposer dans le monde du développement logiciel. Avec des plateformes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") comme GitLab, les équipes de développement disposent de tous les outils et ressources nécessaires au bon développement de leurs logiciels open source.\n\nEn plus d’aider les entreprises à développer des logiciels performants et sécurisés, GitLab fait évoluer continuellement sa plateforme grâce aux contributions et aux retours de ses utilisateurs. En écoutant sa communauté en permanence, GitLab s'adapte aux transformations du développement logiciel, renforçant ainsi sa présence au sein de l'écosystème open source.\n\n> [\nEssayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/fr-fr/free-trial/devsecops/ \"Essai gratuit de GitLab Ultimate\") et commencez à développer des logiciels open source dès aujourd'hui.",[901,930,720],{"slug":1084,"featured":6,"template":808},"what-is-open-source",{"content":1086,"config":1096},{"title":1087,"description":1088,"authors":1089,"heroImage":1091,"date":1092,"body":1093,"category":760,"tags":1094,"updatedDate":1095},"Git : 20 ans d'histoire","Revivez les débuts du projet Git, avec le tout premier commit, découvrez les particularités des premières versions et replongez dans la confusion qu'a provoquée le changement du comportement par défaut de git-push(1).",[1090],"Patrick Steinhardt","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","2025-04-14","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") vient de fêter ses 20 ans et depuis, bien des choses ont changé : si le design conceptuel de Git est resté globalement le même, la manière dont les utilisateurs s'en servent, elle, a considérablement évolué. Git est au cœur de notre travail chez GitLab et nous sommes fiers d'être liés à son histoire.\n\nRemontez le temps avec nous pour retracer les grandes étapes de son évolution.\n\n## Le premier commit\n\nLe premier commit a été effectué le 7 avril 2005 par Linus Torvalds, le créateur du noyau Linux : `e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`.\n\nComme vous pouvez le constater, ce commit ne contient pas beaucoup de fichiers :\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nOutre l'infrastructure de compilation, le premier commit fournit sept commandes principales :\n\n- `init-db` pour initialiser un nouveau dépôt Git\n- `update-cache` pour ajouter des fichiers à l'index\n- `write-tree` pour créer un nouvel arbre à partir des éléments de l'index\n- `read-tree` pour lire un objet arbre\n- `commit-tree` pour créer un commit à partir d'un arbre\n- `cat-file` pour lire un objet spécifique dans un fichier temporaire\n\nNotez que la commande `git` n'existait pas encore à ce moment-là. Il fallait dès lors les exécuter directement.\n\nPour vous montrer un exemple concret, créons un nouveau dépôt :\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nCela peut surprendre : il n'y a pas de répertoire `.git`, mais un répertoire `.dircache`. Ce dernier représentait une zone de stockage privée. \n\nGit distinguait alors deux types d'espaces de stockage des objets : un espace « privé » et un espace « partagé ». Ceux-ci regroupaient tous vos objets Git : vos commits et vos blobs, par exemple.\n\nPar défaut, `init-db` créait un espace de stockage des objets privé qui n'était utilisé que pour le répertoire géré dans lequel il avait été créé. L'espace de stockage des objets « partagé », quant à lui, permettait de centraliser les objets communs à plusieurs répertoires, ce qui évitait d'avoir à les stocker deux fois.\n\n### Créer un commit\n\nNous disposons maintenant d'un dépôt, mais comment procéder pour créer un commit ? Autant vous dire que ce n'est pas aussi simple qu'avec la commande actuelle `git add . && git commit`. À l'époque, vous deviez :\n\n1. Mettre à jour l'index en appelant `update-cache` pour chaque fichier que vous souhaitiez ajouter. \n2. Écrire un nouvel arbre en appelant `write-tree` pour prendre le contenu que vous aviez\n   ajouté à l'index.\n3. Configurer les variables d'environnement pour indiquer à Git que vous en étiez l'auteur.\n4. Créer un objet de commit en appelant `commit-tree`.\n\nCréons un commit dans le dépôt pour illustrer ce processus :\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nCertes, ce processus n'est pas très pratique, mais il fonctionne ! Découvrons maintenant le commit généré :\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nNotez que `cat-file` n'a pas affiché le contenu directement, mais l'a d'abord écrit\ndans un fichier temporaire. Toutefois, le contenu du fichier ressemblait déjà en tous points à\ncelui des commits actuels.\n\n### Apporter des modifications\n\nMaintenant que nous avons des fichiers, comment pouvons-nous obtenir leur statut ? Vous l'aviez peut-être deviné, en utilisant `show-diff` :\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nÉtonnamment, la commande `show-diff` permettait déjà de générer des diffs entre l'ancien et le nouvel état des fichiers modifiés ! Et pour l'anecdote, Git accomplissait cette tâche en exécutant simplement l'outil Unix diff(1).\n\nEn somme, tout était encore rudimentaire, mais suffisant pour assurer le suivi de l'historique. À ce stade, Git était encore très limité :\n\n- Il était impossible de passer facilement d'un commit à un autre.\n- Il était impossible d'afficher les logs.\n- Il n'y avait pas de branches, de tags ou même de références. Les utilisateurs devaient manuellement conserver une trace des ID d'objet.\n- Il était impossible de synchroniser deux dépôts. Par conséquent,\n  les utilisateurs devaient utiliser rsync(1) pour synchroniser les répertoires `.dircache`.\n- Il était impossible de fusionner des modifications.\n\n## Git 0.99\n\nLa version 0.99 de Git a été la première à entrer en phase de test. Celle-ci a été publiée seulement deux mois après le commit initial, mais contenait déjà 1 076 commits. Près de 50 développeurs différents ont participé à son développement. À ce stade, Linus Torvalds était encore le principal contributeur, talonné de près par Junio Hamano, qui est aujourd'hui le chargé de maintenance.\n\nDe nombreuses améliorations avaient été mises en place depuis le premier commit :\n\n- Git avait commencé à suivre différentes branches de développement à l'aide de références, ce qui, dans la grande majorité des cas, dispensait les utilisateurs de suivre les ID d'objets manuellement.\n- Un nouveau protocole distant permettait désormais à deux dépôts d'échanger\n  des objets entre eux.\n- Le répertoire `.dircache` avait été renommé `.git`.\n- Il était désormais possible de fusionner des fichiers uniques entre eux.\n\nMais le changement le plus marquant a sans doute été l'arrivée de\nla commande principale `git` et de ses nombreuses sous-commandes. C'est aussi à cette occasion\nqu'est née la distinction entre les commandes dites de « plomberie » (plumbing) et de « porcelaine » (porcelain) :\n\n- Les outils de « plomberie » sont les commandes de bas niveau qui accèdent au dépôt Git\n sous-jacent.\n- Les outils de « porcelaine » sont des scripts shell qui encapsulent les commandes de « plomberie » pour fournir une interface utilisateur plus conviviale et performante.\n\nCette distinction existe encore aujourd'hui, comme expliqué dans\n[`git(1)`](https://git-scm.com/docs/git/fr#_commandes_de_haut_niveau_porcelaine), mais avec\nla réécriture en C de nombreuses commandes de « porcelaine » initialement en shell, la frontière entre ces deux catégories a commencé à s'estomper significativement.\n\n## Linus Torvalds passe la main\n\nLinus Torvalds n'a jamais créé Git par passion pour les systèmes de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version\"), mais parce qu'il était nécessaire de remplacer BitKeeper pour le développement du noyau Linux. Dès le départ, il n'avait pas l'intention d'en assurer la maintenance indéfiniment, mais juste le temps de trouver quelqu'un de confiance pour reprendre le flambeau. \n\nEt cette personne fut Junio Hamano. Junio a rejoint Git une semaine à peine après le premier  commit de Linus Torvalds et comptait déjà plusieurs centaines de commits dans l'historique au moment de la sortie de la version 0.99. Ainsi, le 26 juillet 2005, [Linus Torvalds l'a désigné comme nouveau chargé de maintenance du projet Git](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). Même si Linus Torvalds a continué à contribuer à Git, son implication s'est progressivement réduite, ce qui n'a rien de surprenant, vu ses responsabilités à la tête du projet Linux. \n\nA ce jour, Junio Hamano dirige toujours le projet Git. \n\n## Git 1.0\n\nLa première version majeure de Git est sortie le 21 décembre 2005 par Junio Hamano. Fait intéressant : pas moins de 34 nouvelles versions ont été publiées entre la version 0.99 et la version 1.0 : 0.99.1 à 0.99.7, 0.99.7a à 0.99.7d, 0.99.8 à 0.99.8g, et 0.99.9 jusqu'à 0.99.9n.\n\nParmi les évolutions majeures depuis la version 0.99, l'une des plus importantes a sans doute été l'introduction de la commande `git-merge(1)` pour fusionner deux arbres. Un changement radical par rapport à la version précédente, dans laquelle chaque merge devait être effectuée manuellement, fichier par fichier.\n\n### Dépôts distants\n\nUn autre changement majeur a été l'introduction de la notation abrégée pour\nles dépôts distants. Git savait déjà communiquer avec eux, mais jusque-là,\nles utilisateurs devaient entrer l'URL complète à chaque\nrécupération de modifications. Ce processus était plutôt contraignant, car dans la grande majorité des cas, les utilisateurs interagissaient toujours avec le même dépôt distant. \n\nAujourd'hui, vous connaissez probablement le fonctionnement des dépôts distants,\nmais à l'époque, le mécanisme était encore très différent. Il n'existait pas de commande `git-remote(1)`  \npour les gérer. Ils n'étaient même pas stockés  \ndans votre fichier`.git/config` file. À vrai dire, lorsque les dépôts distants ont fait leur apparition dans\nla version 0.99.2, Git ne *disposait* même pas encore de fichiers de configuration. \n\nPour les configurer, il fallait créer un fichier dans le\nrépertoire `.git/branches`, un mécanisme qui semble aujourd'hui plutôt contre-intuitif. Mais  \nil fonctionne encore aujourd'hui :\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nEt ce n'est pas tout ! Le répertoire a été renommé en « dépôts distants » dès la version 0.99.5 de Git. Aujourd'hui, il existe donc trois méthodes distinctes pour configurer des dépôts distants dans un client Git actuel. \n\nMais soyons honnêtes : la plupart d'entre vous n'ont sans doute jamais eu à utiliser `.git/branches` ni `.git/remotes`,\ndeux mécanismes devenus obsolètes en 2005 et 2011,\nrespectivement. Ces répertoires seront d'ailleurs définitivement supprimés dans la version Git 3.0.\n\n## Image de marque de Git\n\nEn 2007, Git créé son premier logo. Le terme « logo » est peut-être un peu excessif : il ne s'agissait en réalité que de trois signes moins rouges au-dessus de trois signes plus verts, une référence visuelle directement inspirée de la sortie de `git diff` :\n\n![trois signes moins rouges au-dessus de trois signes plus verts, référence visuelle inspirée de la sortie de `git diff`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nLe site web [git-scm.com](https://git-scm.com) voit quant à lui le jour en 2008 :\n\n![page de destination pour git-scm.com en 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nEn 2012, le site web de Git est [remanié](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/) par Scott Chacon et Jason Long et son design ne changera que très peu par la suite :\n\n![site web git remanié en 2012](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nCette refonte du site arbore le nouveau logo rouge-orange conçu par Jason Long, qui est encore utilisé aujourd'hui :\n\n![logo git](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nDès la version 1.0, Git ressemblait déjà fortement à la version d'aujourd'hui,\nc'est pourquoi nous allons faire un grand saut dans le temps et passer directement à une autre étape clé de son histoire : Git 2.0. Publiée environ dix ans après Git 1.0,\ncette version a été la première à\nintroduire délibérément des changements non compatibles avec les versions précédentes dans les workflows principaux.\n\n### Comportement par défaut de `git-push(1)`\n\nLe changement le plus déroutant de cette version a sans doute été\nl'ajustement du comportement par défaut de la commande  `git-push(1)`.\n\nSi vous réalisiez un push dans un dépôt distant sans en indiquer explicitement l'objet,\nGit pouvait réagir de plusieurs façons :\n\n- Refuser d'agir et vous inviter à préciser l'objet de votre push.\n- Effectuer un push de la branche actuellement extraite.\n- Effectuer un push de la branche actuellement extraite, mais uniquement s'il détectait une branche correspondante dans le dépôt distant.\n- Effectuer un push de toutes vos branches disposant d'un équivalent dans le dépôt distant.\n\nAujourd’hui, le comportement par défaut de Git suit la stratégie dite « simple », c'est-à-dire la\ntroisième option mentionnée ci-dessus. Mais avant Git 2.0, le comportement par défaut était la stratégie de « correspondance », soit la dernière option.\n\nLa stratégie de « correspondance » était nettement plus risquée. Avant le push, vous deviez toujours vous assurer que vous vouliez vraiment effectuer un push de toutes vos branches locales disposant d'un équivalent dans le dépôt distant. Dans le cas contraire, vous risquiez d'envoyer des modifications par erreur. C'est pourquoi Git a opté pour la stratégie dite « simple », afin de limiter les risques et de faciliter la prise en main pour les nouveaux utilisateurs.\n\n### `git-add(1)`\n\nLe comportement par défaut de `git-add(1)` vis-à-vis des fichiers supprimés\na lui aussi connu une évolution importante. Avant Git 2.0, la commande `git-add(1)` ne\nprenait pas en compte les fichiers supprimés : il fallait les ajouter manuellement\navec `git-rm(1)` pour qu'ils soient inclus dans un commit. À partir de la version 2.0, la commande `git-add(1)` détecte également les suppressions de fichiers et les ajoute à l’index.\n\n## La communauté Git à l'honneur\n\nNous n'allons pas entrer dans les détails du fonctionnement actuel de Git : vous l'utilisez probablement déjà au quotidien, et dans le cas contraire, de nombreux tutoriels existent pour bien débuter. Prenons plutôt un moment pour célébrer et remercier la communauté Git, qui a permis à ce système de rester aussi performant après deux décennies.\n\nAu fil du temps, Git a :\n\n- Accumulé 56 721 commits depuis [Git 2.49.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-49-0/ \"Git 2.49.0\")\n- Reçu des contributions de plus de 2 000 personnes différentes.\n- Publié 60 nouvelles versions majeures.\n\nLe projet Git continue aussi de se renouveler grâce à l'arrivée régulière de nouveaux contributeurs, notamment par le biais des programmes [Google Summer of Code](https://summerofcode.withgoogle.com/) et [Outreachy](https://www.outreachy.org/). Ce sont eux qui assurent la pérennité du projet Git. \n\n## L'avenir de Git\n\nGit s'est clairement imposé comme le grand gagnant dans la course aux systèmes de contrôle de version. Il domine largement le marché et il est rare aujourd'hui de voir un projet [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui n'utilise pas Git. C'est bien la preuve que Git a su faire les bons choix.\n\nCela dit, le développement de Git est loin d'être terminé et de nombreux défis restent à relever. Sur le plan technique :\n- la modernisation d'un code base vieillissant  \n- la mise à l'échelle face à la croissance continue des monorepos  \n- la gestion plus efficace des fichiers binaires volumineux\n\nSur le plan communautaire :\n- l'amélioration de la convivialité de Git  \n- la promotion de la communauté Git pour garantir la pérennité du\nprojet\n\nLe travail ne s'arrête pas là et chez GitLab, nous sommes fiers de contribuer activement à faire en sorte que Git reste un système de contrôle de version de référence pour les vingt années à venir.\n\n## En savoir plus sur Git\n\n- [Git fête ses 20 ans : entretien avec son créateur Linus Torvalds](https://about.gitlab.com/fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) \n- [Format reftable de Git : guide pour les débutants](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/ \"Git fetch vs git pull \")\n- [Commits Git : comment et pourquoi maintenir un historique propre](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Commits Git\") \n- [Git en ligne de commande sous Windows avec Git Bash](https://about.gitlab.com/fr-fr/blog/git-bash/ \"Git Bash\")  \n- [Améliorez votre workflow avec Git rebase](https://about.gitlab.com/fr-fr/blog/take-advantage-of-git-rebase/ \"Git rebase\")\n",[901,985],"2025-04-25",{"slug":1097,"featured":91,"template":808},"journey-through-gits-20-year-history",{"category":90,"slug":771,"posts":1099},[1100,1113,1127],{"content":1101,"config":1111},{"title":1102,"description":1103,"authors":1104,"heroImage":1107,"date":1108,"category":771,"tags":1109,"body":1110},"GitLab Premium et l’IA : au cœur de l'enseignement supérieur","La plateforme DevSecOps facilite les workflows, la protection des données, le support, la collaboration, la sécurité et la productivité au niveau universitaire.\n",[1105,1106],"Jessica Hurwitz","Elisabeth Burrows","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_820,h_500,c_lfill/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","2025-07-07",[550,771,803,187],"Les établissements d'enseignement supérieur s'appuient de plus en plus sur des pratiques modernes de développement logiciel dans leurs missions pédagogiques, leurs activités de recherche et la gestion de leurs infrastructures. Face à des besoins en développement logiciel de plus en plus complexes, GitLab Premium avec [GitLab Duo](https://about.gitlab.com/gitlab-duo/ \"Qu'est-ce que GitLab Duo ?\") fournit des fonctionnalités essentielles qui répondent aux défis spécifiques du secteur universitaire, notamment en matière de développement [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\"), de collaboration à distance et de sécurité globale.\n\nLa plateforme DevSecOps complète alimentée par l'IA de GitLab offre des fonctionnalités qui vont bien au-delà du simple [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\"). Basée sur une architecture open source et dotée de fonctionnalités avancées, GitLab Premium permet de prévenir les incidents de sécurité coûteux impliquant des données sensibles d'étudiants, propose des environnements de développement cloud accessibles aux équipes situées à différents emplacements géographiques et offre une assistance professionnelle adaptée aux systèmes critiques des établissements d'enseignement. [GitLab Premium inclut à présent le chat et les suggestions de code, des fonctionnalités d'IA clés de GitLab Duo](https://about.gitlab.com/fr-fr/blog/gitlab-premium-with-duo/), et ce sans frais supplémentaires.\n\n## Les particularités du développement logiciel dans l'enseignement supérieur\n\nLes universités et les établissements d'enseignement supérieur opèrent dans un environnement technique particulièrement complexe. Les équipes de développement doivent faciliter une collaboration multidisciplinaire entre les services techniques et non techniques, tout en gérant de grandes quantités de données sensibles (dossiers des étudiants, informations financières, résultats de recherche, évaluations des professeurs).\n\nLa plupart des établissements doivent travailler avec des ressources informatiques limitées et prendre en charge simultanément des milliers d'utilisateurs participant à un grand nombre de projets et d'initiatives de recherche. L'intégrité exigée dans le cadre de la recherche ajoute un niveau supplémentaire de complexité, car le travail de développement doit souvent adhérer à des normes de traçabilité et de reproductibilité.\n\n## Les fonctionnalités de GitLab Premium pour l'éducation\n\nGitLab Premium avec GitLab Duo offre les fonctionnalités dont l'enseignement supérieur a besoin.\n\n### Amélioration de la collaboration et capacités de workflow\n\nLes projets qui impliquent différents services sont courants dans le secteur universitaire, qu'il s'agisse d'initiatives de recherche interdisciplinaire ou du développement de modules personnalisés pour des systèmes d'ERP. Ces projets complexes nécessitent une gestion sophistiquée des workflows qui ne se limite pas uniquement au simple contrôle de version.\n\nGitLab Premium répond à ces défis en offrant des fonctionnalités de collaboration et de visualisation de projet, notamment des epics, des roadmaps et des tableaux Kanban avancés pour les workflows de développement Agile. En attribuant plusieurs approbateurs à certaines merge requests et branches protégées, vous garantissez une meilleure qualité du code et une plus grande responsabilisation des équipes. Ces outils permettent aux établissements de coordonner les travaux entre les différents services, tout en s'assurant que ces efforts sont alignés sur les objectifs globaux de l'institution. Il s'agit d'une condition essentielle pour gérer efficacement des initiatives technologiques qui se déroulent en plusieurs étapes à l'échelle du campus.\n\nEn Australie, l'équipe Digital Enablement de l'Université Deakin utilise GitLab pour créer des processus standardisés et des templates réutilisables (templates de merge request personnalisés, pipelines de compilation basés sur un template, framework de sécurité et de conformité) qu'elle partage avec la communauté universitaire et les développeurs citoyens. Cette approche favorise l'innovation et renforce la collaboration à la fois au sein de l'université et avec ses partenaires stratégiques. « Nous voulions depuis longtemps créer une communauté et l'aider à se développer, mais sans succès, jusqu'à l'adoption de cet outil », confie Aaron Whitehand, Director of Digital Enablement à l'Université Deakin.\n\n**Découvrez comment l'[Université Deakin](https://about.gitlab.com/customers/deakin-university/) utilise GitLab pour renforcer la collaboration et la productivité, notamment grâce à une réduction de 60 % des tâches manuelles.**\n\n### Protection et gouvernance avancées des données\n\nLes établissements d'enseignement génèrent et gèrent des quantités considérables de données (dossiers des étudiants, informations financières, résultats de recherche, évaluations des professeurs, et bien plus encore). La sécurité de ces informations est un enjeu majeur. La [faille de sécurité MOVEit](https://universitybusiness.com/in-just-3-months-this-data-breach-has-compromised-nearly-900-institutions/) de 2023, qui a duré trois mois et compromis environ 900 établissements d'enseignement, a exposé les informations sensibles de plus de 62 millions de personnes. Cet exemple illustre l'importance cruciale d'intégrer des mesures de sécurité proactives directement dans les workflows de développement dans ce secteur.\n\nLe scanning des vulnérabilités bloque les sorties de nouvelles versions de code qui contiennent des risques de sécurité afin de permettre aux établissements de mettre en place et de faire respecter des protocoles de gouvernance qui protègent ces données sensibles. Cette fonctionnalité aide les universités à mettre en œuvre des contrôles d'accès et des structures d'autorisation adaptés aux bases de données de recherche. Ce framework sécurisé garantit que seuls les chercheurs autorisés disposent des droits d'accès nécessaires et assure une protection stricte sans entraver la collaboration entre les différentes équipes.\n\nLa plateforme de GitLab est conçue dès le départ pour garantir la sécurité de votre code source. Les dépôts [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") évolutifs, des contrôles d'accès granulaires et des fonctionnalités de conformité intégrées éliminent les goulots d'étranglement dans votre workflow tout en répondant aux exigences de sécurité. GitLab Premium fournit des fonctionnalités de suivi des audits et de conformité essentielles, particulièrement adaptés aux environnements éducatifs. Les pistes d'audit complètes consignent sous forme de logs l'ensemble des modifications apportées au code, les tentatives d'accès et les modifications du système, en incluant les horodatages ainsi que les utilisateurs concernés. La documentation exhaustive sur la gestion des modifications garantit une traçabilité optimale (auteur, date et motif), essentielle pour garantir l'intégrité de la recherche. Quant à l'audit du contrôle d'accès, il permet de surveiller l'accès au dépôt et les changements d'autorisations.\n\n### Développement cloud et collaboration à distance\n\nLes établissements d'enseignement modernes requièrent des environnements de développement flexibles, adaptés aux besoins des équipes situées à différents emplacements géographiques, aux scénarios d'apprentissage à distance et aux diverses exigences techniques. \n\nGitLab Premium offre donc les avantages suivants :\n\n* [Workspaces GitLab](https://docs.gitlab.com/user/workspace/) : environnements de développement cloud accessibles depuis n'importe quel appareil\n* [Intégration au Web IDE](https://docs.gitlab.com/user/project/web_ide/) : codage basé sur le navigateur avec une intégration complète des fonctionnalités de GitLab\n* [Développement conteneurisé](https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces/) : environnements de développement cohérents et reproductibles, quelle que soit la nature du projet ou le groupe d'utilisateurs\n\nCes fonctionnalités sont particulièrement utiles pour prendre en charge les modèles d'apprentissage à distance et hybrides. Elles permettent aux étudiants et aux chercheurs d'accéder à des environnements de développement standardisés, indépendamment de leur emplacement physique ou des contraintes matérielles locales.\n\n### Assistance professionnelle pour les systèmes critiques\n\nLes petites équipes informatiques des établissements d'enseignement prennent souvent en charge des infrastructures importantes et complexes avec des ressources minimales. Elles doivent parfois s'appuyer sur des forums communautaires, mais la fiabilité des réponses n'est pas toujours garantie. Par ailleurs, cette approche n'est pas efficace pour les structures de grande envergure. C'est pourquoi GitLab Premium inclut une assistance professionnelle dédiée, qui permet de résoudre les problèmes plus rapidement et d'obtenir de l'aide pour les mises à niveau pendant les périodes critiques, telles que les inscriptions aux cours ou les échéances de recherche.\n\nCette assistance réduit au maximum les temps d'arrêt des services critiques et garantit la continuité des opérations pendant les périodes de pointe, ce qui donne aux services informatiques surchargés la fiabilité dont ils ont besoin pour les systèmes essentiels.\n\n### Architecture open source, performances d'entreprise\n\nLes logiciels open source sont développés de manière collaborative et publique, le code source pouvant être librement consulté, modifié et distribué par tous. Ce modèle de développement favorise l'innovation grâce aux contributions de la communauté et garantit un fonctionnement homogène des logiciels. La base open source de GitLab est en parfaite adéquation avec les valeurs fondamentales des établissements d'enseignement en matière de collaboration, de transparence et de contribution communautaire. Les fonctionnalités de GitLab Premium enrichissent cette base avec des capacités de niveau entreprise et offrent parallèlement la possibilité de contribuer à l'écosystème open source.\n\nVoici les principaux avantages de l'open source :\n\n* **Une transparence totale** : visibilité complète sur les fonctionnalités de la plateforme et les mesures de sécurité. Vous savez précisément comment le logiciel fonctionne.\n* **Une contribution de la communauté** : possibilité de contribuer à améliorer l'outil au bénéfice de la communauté au sens large et de profiter de l'expertise d'une communauté mondiale de développeurs et développeuses. \n* **Une indépendance vis-à-vis des fournisseurs** : réduction du risque de blocage avec des alternatives open source et liberté de modifier le code au besoin.\n* **Des opportunités de co-création** : développement collaboratif avec la communauté, y compris d'autres établissements universitaires, pour concevoir des solutions partagées.\n\n### Assistant d’IA dédié au développement logiciel\n\nGitLab Premium avec GitLab Duo intègre de puissantes capacités d'IA directement dans le workflow de développement, avec notamment :\n\n* Les [suggestions de code](https://docs.gitlab.com/user/project/repository/code_suggestions/ \"suggestions de code GitLab\"), qui fournissent une complétion et des suggestions de code en temps réel, pour aider les équipes de développement à écrire du code plus rapidement et plus efficacement.\n* Le [chat](https://docs.gitlab.com/user/gitlab_duo_chat/ \"GitLab Duo Chat\"), qui permet d'obtenir des réponses instantanées aux questions posées, de résoudre les problèmes et d'accéder à la documentation directement dans l'environnement GitLab.\n\nCes outils d'IA améliorent considérablement la productivité, réduisent les erreurs et renforcent la collaboration. C'est précisément la raison pour laquelle GitLab Premium est un atout encore plus précieux pour les équipes de développement logiciel dans l'enseignement supérieur.\n\n### La transparence comme principe fondateur\n\nLes établissements d'enseignement supérieur traitent des données particulièrement sensibles, qu’il s’agisse de dossiers étudiants, de résultats de recherche, de travaux universitaires confidentiels ou d'informations liées à des financements publics.\n\nLe [Centre pour la transparence de l'IA de GitLab](https://about.gitlab.com/fr-fr/ai-transparency-center/ \"Centre de transparence de l'IA de GitLab\") démontre notre engagement en faveur de la transparence, de la responsabilisation, de la protection des données et de la propriété intellectuelle des clients et fournit les garanties de confidentialité dont les établissements d'enseignement ont besoin.\n\nNous avons lancé ce centre afin d'aider nos clients, notre communauté et nos équipes à mieux comprendre comment GitLab applique les principes d'éthique et de transparence dans ses fonctionnalités alimentées par l'IA.\n\nNotre documentation publique détaille l'ensemble des mesures mises en place pour protéger les données et la propriété intellectuelle de votre établissement. Les [principes d'éthique IA pour le développement de produits de GitLab](https://handbook.gitlab.com/handbook/legal/ethics-compliance-program/ai-ethics-principles/) nous guident dans la création et l'amélioration de nos fonctionnalités d'IA, afin d'aider les établissements d'enseignement supérieur à tirer parti des promesses de l'IA, tout en conservant un contrôle total et une surveillance complète de leurs actifs les plus précieux.\n\n## Découvrez GitLab Premium dès aujourd'hui\n\nPour les établissements d'enseignement, GitLab Premium avec GitLab Duo représente un investissement technologique stratégique, qui combine les avantages du développement open source avec des fonctionnalités d'IA native de niveau entreprise. En fournissant des outils de qualité professionnelle prêts à relever les défis propres à l'environnement technique complexe de l'enseignement supérieur, GitLab Premium avec GitLab Duo aide les établissements à corriger les failles de sécurité, à rationaliser les workflows de développement et à maintenir une infrastructure fiable dont dépendent les opérations universitaires et de recherche.\n\nDécouvrez [GitLab pour le secteur public](https://about.gitlab.com/fr-fr/solutions/public-sector/ \"GitLab pour le secteur public\") ou [contactez notre équipe commerciale](https://about.gitlab.com/fr-fr/sales/ \"Contacter les équipes de GitLab\") dès aujourd'hui.",{"featured":6,"template":808,"slug":1112},"ai-native-gitlab-premium-transform-higher-education-software-development",{"content":1114,"config":1125},{"heroImage":1115,"body":1116,"authors":1117,"updatedDate":1120,"date":1121,"title":1122,"tags":1123,"description":1124,"category":771},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","GitLab et IBM unissent leurs forces pour moderniser le développement logiciel sur mainframe. Ce partenariat permet aux équipes de développement mainframe de bénéficier des mêmes outils modernes, workflows et fonctionnalités collaboratives que ceux utilisés dans les environnements distribués. Baptisée GitLab Ultimate pour IBM Z, cette solution d'automatisation DevSecOps intégrée et certifiée par GitLab, adaptée à l'environnement mainframe, relève ce défi. Elle permet aux entreprises de moderniser leurs workflows de développement mainframe grâce à une migration sans accroc depuis les gestionnaires de bibliothèques hérités obsolètes. Avec des pipelines CI/CD exécutés de façon native sur IBM z/OS, ces entreprises sont en mesure d'innover plus rapidement et de réduire les coûts opérationnels.\n\n## Les défis actuels du développement sur mainframe\n\nLes entreprises qui utilisent les systèmes IBM Z pour leurs charges de travail critiques sont confrontées à des défis que les outils DevSecOps classiques ne sont pas en mesure de relever. Tandis que les équipes [cloud-native](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Qu'est-ce que cloud-native ?\") bénéficient de pipelines [CI/CD](https://about.gitlab.com/topics/ci-cd/) modernes, d'un développement collaboratif fluide et de tests automatisés, les équipes mainframe restent souvent confinées à des outils obsolètes, source d'inefficacités coûteuses et de silos opérationnels.\n\nElles ont souvent recours à des solutions de contournement, telles que les connexions SSH et les transferts manuels de fichiers, qui fragilisent la sécurité et complexifient les audits. Or, dans un contexte de conformité de plus en plus exigeant, ces pratiques improvisées s’exposent à des risques inacceptables. Par ailleurs, les entreprises maintiennent des chaînes d'outils parallèles coûteuses, reposant sur des outils de développement mainframe hérités aux coûts de licence élevés et aux fonctionnalités limitées par rapport aux alternatives modernes.\n\nCette fragmentation crée deux problèmes : des cycles de livraison de logiciels plus lents et une difficulté à attirer des développeurs, qui recherchent des environnements de travail modernes.\n\n> **« GitLab Ultimate pour IBM Z représente une avancée décisive pour résoudre une problématique à laquelle le secteur doit faire face depuis longtemps. D'après les recherches menées par IDC, les équipes de développement mainframe s'appuient encore largement sur des outils hérités qui contribuent à freiner les livraisons et compliquent l'acquisition de nouveaux talents. Avec cette offre conjointe, les fonctionnalités DevSecOps modernes et les workflows unifiés sont intégrés directement au mainframe. Résultat : une collaboration plus fluide et plus efficace pour les équipes de développement, et une accélération de l'innovation pour les entreprises, qui peuvent ainsi totalement intégrer le développement mainframe à leurs stratégies globales de transformation digitale. »** - Katie Norton, Research Manager, DevSecOps and Software Supply Chain Security chez IDC\n\n## Vers des environnements de développement unifiés\n\nUne véritable modernisation du développement mainframe nécessite de concevoir une plateforme unifiée où les équipes mainframe, cloud-native, web et mobile collaborent en harmonie. \n\nGitLab Ultimate pour IBM Z permet aux équipes de développement d'utiliser des workflows cohérents, qu'ils déploient sur z/OS, dans le cloud ou sur une infrastructure locale. Les connaissances sont ainsi transférées entre les équipes au lieu de rester cloisonnées. Les entreprises peuvent ainsi moderniser leurs pratiques progressivement, à leur propre rythme, sans interrompre leurs activités, car les systèmes hérités continuent de fonctionner.\n\nÀ l'heure où les architectures hybrides mêlant mainframe et développement cloud-native deviennent la norme, GitLab fournit une base robuste pour développer des applications entre ces différents environnements.\n\n## Qu'est-ce que GitLab Ultimate pour IBM Z ?\n\nGitLab Ultimate pour IBM Z offre une prise en charge native des runners sur z/OS et permet ainsi une exécution fluide et sécurisée de vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD?\") directement sur votre infrastructure mainframe. Cette solution certifiée par GitLab supprime le besoin de solutions de contournement complexes tout en maintenant la sécurité et la fiabilité que vos applications exigent. \n\nEn combinant la plateforme DevSecOps complète de GitLab avec l'expertise approfondie d'IBM en matière de mainframe, cette offre unique et certifiée connecte les systèmes hérités aux pratiques d'innovation cloud-native.\n\n## Quelles fonctionnalités offre GitLab Ultimate pour IBM Z ?\n\nGitLab Ultimate pour IBM Z fournit aux équipes de développement les outils dont elles ont besoin pour moderniser le développement mainframe tout en préservant la continuité des systèmes métier critiques. \n\nVoici les principales fonctionnalités de cette solution intégrée :\n\n**La prise en charge native des runners sur z/OS** : les pipelines CI/CD s'exécutent directement sur votre mainframe. Cette approche réduit les risques de sécurité et les goulots d'étranglement d'évolutivité associés aux connexions distantes, tout en accélérant les déploiements et les livraisons.\n\n**La gestion unifiée du code source** : votre chaîne d'outils est modernisée en remplaçant les outils de gestion de bibliothèques hérités coûteux par le système de dépôt consultable et le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") de GitLab. Ainsi, vos coûts de licence et frais de maintenance sont réduits.\n\n**L'intégration fluide** avec IBM Developer for z/OS Enterprise Edition (IDzEE) : les cycles de livraison sont accélérés grâce à des compilations basées sur les dépendances, à une analyse automatique du code et à des outils de débogage complets, directement accessibles dans les environnements de développement habituels. Le tout améliore à la fois la qualité du code et la sécurité des applications, sans perturber les habitudes des équipes. \n\n**La visibilité complète** sur les environnements mainframe et distribués : une gestion complète des projets, de la planification à la production, permet d'automatiser les workflows DevOps et améliore l'expérience développeur grâce à des outils de développement modernes de nouvelle génération.\n\n## Modernisez votre environnement de développement mainframe dès aujourd'hui\n\nGitLab Ultimate pour IBM Z est désormais disponible pour les entreprises prêtes à transformer leur expérience de développement mainframe. Pour en savoir plus, consultez la [page dédiée au partenariat entre GitLab et IBM](https://about.gitlab.com/fr-fr/partners/technology-partners/ibm/).",[1118,1119],"Mike Flouton","Andy Bradfield","2025-06-30","2025-06-20","GitLab Ultimate pour IBM Z : le DevSecOps moderne sur mainframe",[284,771,109,720],"Découvrez comment l'intégration d'IBM à GitLab allie développement sur mainframe et cloud-native, avec prise en charge des runners CI/CD, visibilité complète et coûts réduits.",{"featured":91,"template":808,"slug":1126},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"content":1128,"config":1137},{"title":1129,"description":1130,"authors":1131,"heroImage":1132,"date":1133,"body":1134,"category":771,"tags":1135,"updatedDate":1136},"GitLab nommée Leader dans le rapport The Forrester Wave™: DevOps Platforms (T2 2025)","Téléchargez le rapport The Forrester Wave™: DevOps Platforms (T2 2025) et découvrez pourquoi la plateforme GitLab a été nommée Leader.",[1025],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","2025-06-02","Le choix d'une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ? \") est l'une des décisions technologiques les plus stratégiques pour une entreprise. C'est pourquoi nous sommes particulièrement fiers d'annoncer que GitLab a été nommée [**Leader dans le rapport The Forrester Wave™: DevOps Platforms, T2 2025**](https://about.gitlab.com/forrester-wave-devops-platform/). Notre plateforme a obtenu les meilleurs scores pour les critères qui comptent le plus aux yeux de nos clients, notamment l'expérience zero-day, les outils de développement, l'automatisation de la compilation, l'intégration continue, l'automatisation du déploiement, ainsi que l'atténuation des risques liés à l'IA, l'injection d'IA, les outils de sécurité directement intégrés et la cohésion au sein de la plateforme.\n\n***« GitLab est la solution tout-en-un la plus complète. Elle s'adresse aux entreprises qui cherchent à standardiser leurs processus avec un seul achat. » -*** Rapport The Forrester Wave™ dédié aux plateformes DevOps, T2 2025\n\nCette reconnaissance vient renforcer notre conviction : les équipes de développement logiciel doivent livrer des logiciels sécurisés, plus rapidement, sans sacrifier ni la rapidité, ni la sécurité, ni la simplicité, alors que d'autres plateformes imposent ce compromis. GitLab unifie les enjeux de rapidité, de fiabilité et de gouvernance. Avec la [version 18.0 de GitLab](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) sortie en mai, nous franchissons une nouvelle étape en intégrant les [fonctionnalités basées sur l'IA native de GitLab Duo](https://about.gitlab.com/fr-fr/blog/gitlab-premium-with-duo/), sans frais supplémentaires. Avec GitLab Duo, nos clients bénéficient de fonctionnalités avancées, telles que la génération de tests, les suggestions de code et la refactorisation du code, directement dans GitLab Premium et GitLab Ultimate. \n\n> [Consultez le rapport Forrester dès aujourd'hui !](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n![ Graphique issu du rapport The Forrester Wave™ dédié aux plateformes DevOps, T2 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## Une IA de pointe, sans compromis sur la sécurité\n\nLes principes de l'approche DevSecOps évoluent rapidement, et l'IA est au cœur de cette transformation. Malheureusement, de nombreux outils alimentés par l'IA imposent de choisir entre des fonctionnalités de pointe et la sécurité à l'échelle de l'entreprise. \n\nForrester a attribué à GitLab la note maximale de 5 pour 2 critères clés : l'**injection d'IA** et l'**atténuation des risques liés à l'IA**. Nous sommes fiers que notre engagement à créer des fonctionnalités d'IA innovantes qui renforcent la sécurité soit remarqué non seulement par nos clients, mais également par d'autres parties prenantes.\n\nCes deux critères se reflètent dans nos offres d'IA GitLab Duo, notamment :\n\n* **Duo Workflow (bêta privée)** : des agents d'IA autonomes capables de gérer des tâches DevSecOps complexes, avec l'implémentation de garde-fous adaptés au secteur d'activité concerné et de pistes d'audit.  \n* **Agentic Chat** : une IA contextuelle et conversationnelle adaptée à toutes les étapes du cycle de développement, des explications de code à la création de tests, avec une protection de la propriété intellectuelle et des contrôles de confidentialité intégrés.  \n* **Suggestions de code** : génération prédictive de blocs de code, définition d'une logique fonctionnelle, génération de tests et suggestion d'un code commun comme des motifs regex.  \n* **Résolution de vulnérabilités intégrant l'IA native** : détection, explication et correction automatiques des vulnérabilités, avec des merge requests générées automatiquement, qui simplifient le processus de développement.\n\n## En finir avec la multiplication des outils \n\nLes équipes DevSecOps ne veulent plus jongler entre plusieurs outils disparates et des intégrations qui les aident seulement pour une partie de leur cycle de développement logiciel. Elles ont besoin d'une expérience de développement fluide, intégrée et cohérente de bout en bout.\n\nLes scores de GitLab dans les critères suivants valident notre stratégie centrée sur le client :\n\n* **Expérience zero-day :** Forrester a cité notre « forte expérience zero-day », en notant que « la plateforme est opérationnelle immédiatement », grâce notamment aux nombreux outils de migration et tutoriels complets mis à disposition. \n* **Outils de développement :** Forrester a cité [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), notre offre d'IA agentique destinée aux clients AWS, ainsi que notre environnement de développement cloud, notre plateforme de développement intégrée et nos wikis de documentation.  \n* **Planification et alignement des projets :** Forrester a noté la « robustesse de notre centre de conformité » et le fait que nous disposons d'outils pour favoriser une approche à la fois descendante et ascendante.  \n* **Sécurité des pipelines :** Forrester nous a attribué la note maximale pour ce critère.  \n* **Automatisation des compilations et intégration continue (CI) :** Forrester a cité notre automatisation des compilations et nos fonctionnalités d'intégration continue avec des pipelines de compilation en plusieurs étapes et une solide prise en charge des modèles auto-hébergés.\n\n## Téléchargez notre rapport\n\nLe fait que GitLab soit nommée Leader dans le rapport The Forrester Wave™: DevOps Platforms (T2 2025) témoigne de l'étendue et de la profondeur des fonctionnalités de notre plateforme, qui fournit une source unique de vérité pour l'ensemble du cycle de développement logiciel. Plus besoin de jongler avec plusieurs outils et multiples intégrations : GitLab offre une expérience fluide et intégrée qui augmente la productivité et réduit les points de friction. Cette distinction reflète le travail assidu de nos équipes, les nombreuses contributions de notre communauté [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ? \"), les précieux retours de nos clients et notre engagement constant à façonner l'avenir du développement logiciel.\n\n> #### [Téléchargez le rapport dès aujourd'hui !](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n*Forrester ne cautionne aucune entreprise, aucun produit, aucune marque ou aucun service inclus dans ses publications de recherche et ne conseille à quiconque de sélectionner les produits ou services d'une entreprise ou d'une marque en fonction des notes attribuées. Les informations se fondent sur les meilleures ressources disponibles. Les opinions reflètent notre jugement du moment et peuvent évoluer. Pour en savoir plus, découvrez les [critères d'objectivité de Forrester](https://www.forrester.com/about-us/objectivity/).*",[1030,771,748,802],"2025-06-10",{"slug":1138,"featured":91,"template":808},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"category":779,"slug":783,"posts":1140},[1141,1153,1166],{"content":1142,"config":1151},{"title":1143,"description":1144,"authors":1145,"heroImage":1147,"date":1148,"body":1149,"category":783,"tags":1150},"Intégrez la conformité à vos workflows DevSecOps avec GitLab","Découvrez comment les frameworks de conformité personnalisés de GitLab transforment vos exigences réglementaires en composants intégrés et automatisés dans vos workflows.",[1146],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","2025-04-30","La conformité n'est plus une formalité, mais un vecteur stratégique : elle aide à maîtriser les risques opérationnels, renforce la confiance des clients et améliore la performance globale. Pourtant, trouver l'équilibre entre exigences de conformité et vélocité peut s'avérer particulièrement complexe pour les équipes de développement logiciel. Les [frameworks de conformité personnalisés](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) de GitLab apportent une réponse concrète à cette problématique en intégrant la vérification de la conformité directement dans vos workflows de développement. \n\nDécouvrez dans cet article tout ce que vous devez savoir sur les frameworks de conformité personnalisés de GitLab et comment les utiliser de façon optimale.\n\n## Qu’est-ce qu’un framework de conformité personnalisé ?\n\nLes frameworks de conformité personnalisés de GitLab vous permettent de définir, d'appliquer et de faire respecter vos propres normes de conformité directement dans votre instance GitLab. GitLab propose déjà des fonctionnalités de conformité « prêtes à l’emploi », mais chaque entreprise a ses propres obligations. Avec les frameworks personnalisés, vous pouvez donc définir vos propres stratégies de conformité en fonction de réglementations spécifiques, de vos politiques internes ou des normes de votre secteur.\n\nCes frameworks offrent les principaux avantages suivants : \n\n* Réduction significative du suivi manuel  \n* Accélération de la préparation aux audits  \n* Intégration native des contrôles de conformité\n\n![Capture d'écran du centre de conformité avec les frameworks répertoriés](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nGitLab propose à ce jour plus de 50 contrôles préconfigurés, modifiables, que vous pouvez activer selon vos besoins. Ils couvrent un large éventail de réglementations, comme la loi HIPAA dans le domaine de la santé, le RGPD pour la protection des données, la [norme SOC 2](https://about.gitlab.com/fr-fr/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam/ \"Norme SOC 2\") relative aux prestataires de services et bien d'autres réglementations propres à des secteurs d'activité spécifiques. En voici quelques exemples :\n\n* Séparation des tâches : au moins deux approbateurs requis, y compris l'auteur de la merge request  \n* Scanners de sécurité : scans [SAST](https://docs.gitlab.com/user/application_security/sast/) et [analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) exécutés automatiquement  \n* Authentification/autorisation : visibilité du projet définie sur privé et authentification unique (SSO) activée  \n* Configuration de l'application : vérification obligatoire des statuts de conformité et utilisation de fichiers de configuration Terraform exigée\n\nEn outre, vous pouvez étendre les capacités de conformité de GitLab en configurant vos propres contrôles sur des environnements externes à l'aide de l'API GitLab.\n\n## Comment créer un framework de conformité personnalisé dans GitLab ?\n\nMaintenant que nous avons clarifié l’importance des frameworks de conformité personnalisés, voyons comment les mettre en œuvre dans votre environnement GitLab, en utilisant l'application de démonstration reprise dans la vidéo ci-dessous. \n\n**Remarque :** un abonnement [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"Qu'est-ce que GitLab Ultimate ?\") est requis.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Étape 1 : définissez vos exigences de conformité**\n\nAvant de créer votre framework de conformité personnalisé, vous devez définir clairement vos exigences en la matière :\n\n1. **Identifiez les réglementations applicables :** déterminez les obligations légales et normes qui s'appliquent à votre entreprise (par exemple, le RGPD, la norme PCI DSS ou la loi HIPAA). \n2. **Associez les exigences à des contrôles :** décomposez chaque exigence réglementaire identifiée en contrôles spécifiques et exploitables.  \n3. **Hiérarchisez les exigences :** concentrez vos efforts sur les domaines à haut risque et les exigences à fort impact.\n\n**Étape 2 : créez votre framework de conformité personnalisé dans GitLab**\n\nVoici comment procéder :\n\n1. Accédez à la section **Sécurisation > Centre de conformité** de votre groupe GitLab.  \n2. Cliquez sur le bouton **Nouveau framework**.  \n3. Sélectionnez **Créer un framework vide**.\n\n![Écran de création d'un framework de conformité personnalisé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Renseignez son nom, sa description et choisissez sa couleur.\n\n![Écran Nouveau framework de conformité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Ajoutez des exigences :\\\n   a. Accédez à l'onglet **Exigences**.\n\n   b. Cliquez sur le bouton **Nouvelle exigence**.\n\n   c. Fournissez un nom et une description.\\\n   d. Dans la section **Contrôles**, sélectionnez **Choisir un contrôle GitLab**.\\\n   e. Sélectionnez un contrôle dans la liste (par exemple, au moins deux approbations, l'exécution de scans SAST).\\\n   f. Cliquez ensuite sur le bouton **Créer une exigence**.\n\n![Bouton Créer une exigence](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Cliquez sur le bouton **Créer un framework**.\n\nUne fois créé, ce framework pourra être appliqué à vos projets selon les paramètres définis. Par ailleurs, GitLab permet également d'importer des frameworks de conformité au format JSON, selon le schéma prévu.\n\n**Étape 3 : appliquez le framework à vos projets**\n\nUne fois votre framework de conformité créé, suivez les étapes ci-dessous pour l’appliquer à un ou plusieurs projets :\n\n1. Accédez au **Centre de conformité** de GitLab, puis sélectionnez l'onglet **Projets**.  \n2. Utilisez la barre de recherche pour **Rechercher** ou **Filtrer** les projets concernés.  \n3. Sélectionnez le ou les projets dans la liste.  \n4. Cliquez sur le bouton **Choisir une action groupée**.  \n5. Sélectionnez **Appliquer les frameworks aux projets sélectionnés**.  \n6. Cliquez sur le bouton **Sélectionner des frameworks**.  \n7. Sélectionnez le ou les frameworks de votre choix dans la liste.  \n8. Cliquez sur le bouton **Appliquer**.\n\n![Écran du Centre de conformité avec la liste déroulante affichant le framework SOC 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nUne fois cette opération effectuée, le framework sélectionné est associé aux projets choisis. Les exigences définies sont alors visibles et peuvent être vérifiées directement dans l'interface GitLab.\n\n**Étape 4 : surveillez et générez des rapports de conformité**\n\nUne fois votre framework de conformité en place, GitLab vous offre un suivi continu et centralisé dans le **Centre de conformité** :\n\n1. Suivez le statut de conformité de vos projets, y compris les détails sur les contrôles appliqués, ainsi que des correctifs suggérés pour les contrôles ayant échoué.\n2. Générez des **rapports de conformité** pour les audits et l'examen par les parties prenantes.  \n3. Configurez des **alertes de conformité** pour informer les parties prenantes des problèmes de conformité potentiels. \n4. Consultez les **événements d'audit** pour une vue d'ensemble des mesures prises concernant les paramètres de conformité.\n\n![Écran du Centre de conformité affichant le framework de test SOC 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Exemple : mise en œuvre d'un framework de conformité SOC 2\n\nLe SOC 2 (System and Organization Controls 2), développée par l'American Institute of Certified Public Accountants, est une norme d'audit rigoureuse qui évalue les contrôles mis en œuvre par les prestataires de services en matière de sécurité, de disponibilité, d'intégrité du traitement des données, de confidentialité et de protection des données personnelles. Pour en savoir plus, consultez le [guide sur le respect des exigences de sécurité SOC 2 avec GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/).\n\nVoici un exemple concret d'implémentation d'un framework de conformité personnalisé GitLab dont l'objectif est de vérifier la conformité à la norme de sécurité SOC 2 à l’aide des contrôles GitLab préconfigurés suivants :\n\n* Contrôles contre les accès non autorisés  \n* Procédures d'identification et d'atténuation des risques  \n* Systèmes de détection et de gestion des incidents de sécurité\n\n**Avertissement :** il ne s'agit là que d'un exemple qui illustre certains des contrôles possibles pour vérifier l'adhésion à la norme SOC 2. Avant toute mise en production, validez votre configuration avec votre équipe sécurité ou conformité.\n\nCe framework se présentera comme suit :\n\n* **Nom :** Exigences de sécurité SOC 2  \n* **Description :** Ajout des exigences de sécurité pour la conformité au framework SOC 2  \n* **Exigences :**  \n\n  * **Contrôles contre les accès non autorisés**  \n\n    * Authentification SSO activée  \n    * Portée des tokens pour les jobs CI/CD activée \n    * Authentification multifacteur requise au niveau de l'entreprise\n* **Procédures d'identification et d'atténuation des risques**   \n\n  * Au moins deux approbations requises avant tout merge \n  * Merge request approuvée par l'auteur      \n  * Merge request approuvée par les validateurs \n  * Branche par défaut protégée    \n* **Systèmes de détection et de gestion des incidents de sécurité**  \n\n  * Analyse des dépendances activée  \n  * SAST activé \n  * DAST activé\n\nLorsqu'il est appliqué à vos projets, ce framework vous permet de surveiller toute erreur de conformité et d'identifier les corrections envisageables. Notez que vous pouvez associer plusieurs frameworks de conformité à vos projets, par exemple, pour couvrir les exigences d'intégrité des processus SOC 2.\n\n## Comment définir des stratégies de sécurité en accord avec les exigences de conformité ?\n\nBien que cet aspect ne soit pas obligatoire, il est fortement recommandé d'appliquer des stratégies de sécurité aux projets associés à un framework de conformité personnalisé. Cette approche garantit que les exigences de conformité critiques sont correctement appliquées de manière automatisée et cohérente dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Par exemple, si votre framework de conformité personnalisé impose que des scans de sécurité soient exécutés sur chaque pipeline, une stratégie de sécurité peut en forcer l’exécution.\n\nGitLab fournit différentes stratégies de sécurité pour répondre aux différents objectifs de sécurité et de conformité :\n\n* [Stratégie d'exécution des scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) : impose l'exécution de scans de sécurité dans les pipelines ou selon un calendrier précis.  \n* [Politique d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) : définit des paramètres et règles d'approbation au niveau du projet en fonction des résultats des scans.  \n* [Stratégie d'exécution de pipeline](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) : force l'exécution de jobs CI/CD spécifiques dans les pipelines. \n* [Stratégie de gestion des vulnérabilités](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/) : corrige automatiquement les vulnérabilités afin qu’elles soient supprimées de la branche par défaut.\n\nSi votre framework de conformité personnalisé exige l'exécution de scans SAST, voici comment créer une stratégie de sécurité pour en garantir l’exécution automatique :\n\n1. Accédez à un projet qui dispose d'un framework de conformité personnalisé incluant les **scans SAST**. \n2. Dans la barre latérale du projet, sélectionnez **Sécurisation > Politiques**.\n3. Cliquez sur le bouton **Nouvelle stratégie**.  \n4. Dans la section **Stratégie d'exécution des scans**, cliquez sur le bouton **Sélectionner une stratégie**. \n5. Renseignez le **Nom** et la **Description**. \n6. Dans la section **Actions**, sélectionnez **SAST** comme type de scan à exécuter.\n\n![Écran des actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Dans la section **Conditions**, sélectionnez tous les pipelines, quelle que soit la branche.\n\n![Écran des conditions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Cliquez sur le bouton **Configurer avec une merge request**.  \n9. Une merge request est alors créée dans un projet distinct dédié aux stratégies de sécurité appliquées à ce projet.\n10. Cliquez sur le bouton **Fusionner**.\n\nDésormais, les scans SAST s'exécuteront automatiquement sur toutes les branches du projet afin de garantir le respect continu des exigences de conformité. Nous vous conseillons de parcourir les autres types de stratégies de sécurité pour identifier celles qui répondent le mieux à vos besoins.\n\n## 5 bonnes pratiques pour des frameworks de conformité efficaces\n\nPour tirer pleinement parti des frameworks de conformité personnalisés de GitLab, nous vous conseillons de suivre les principes suivants :\n\n1. **Avancez pas à pas :** commencez par une seule réglementation ou norme critique avant d'aller plus loin.  \n2. **Impliquez les principales parties prenantes :** incluez les équipes de conformité, de sécurité et de développement dans la création du framework.  \n3. **Automatisez dans la mesure du possible :** utilisez GitLab CI/CD pour automatiser les contrôles de conformité.  \n4. **Documentez minutieusement votre approche :** conservez une documentation claire du lien entre chaque exigence réglementaire et les contrôles GitLab mis en place.  \n5. **Révisez régulièrement vos frameworks :** mettez à jour vos frameworks à mesure que les réglementations évoluent ou que de nouvelles exigences sont nécessaires.\n\n## Lancez-vous dès aujourd'hui\n\nLes frameworks de conformité personnalisés de GitLab marquent une avancée majeure pour intégrer la conformité directement dans le workflow de développement DevSecOps. En les adoptant, vous réduisez les frais liés à la conformité, améliorez votre gestion des risques et accélérez vos cycles de développement logiciel, tout en garantissant la meilleure conformité possible aux exigences réglementaires.\n\nGrâce à cette approche, vos équipes bénéficient à la fois de la flexibilité dont elles ont besoin pour répondre aux exigences réglementaires et de la structure indispensable pour garantir des pratiques de conformité cohérentes dans l'ensemble de l'entreprise.\n\nDans un contexte réglementaire de plus en plus exigeant, des outils comme les frameworks de conformité personnalisés de GitLab sont essentiels pour traiter la conformité comme un processus continu, sans compromettre la vélocité de développement.\n\n> Lancez-vous dès aujourd'hui avec un [essai gratuit de 60 jours de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n\nPour en savoir plus, consultez nos ressources connexes :\n\n* [Documentation sur les frameworks de conformité personnalisés](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\n* [Epic sur les frameworks de conformité personnalisés](https://gitlab.com/groups/gitlab-org/-/epics/13295)\n* [Documentation sur les stratégies de sécurité](https://docs.gitlab.com/user/application_security/policies/)\n* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)",[783,804,802,803,771],{"slug":1152,"featured":91,"template":808},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"content":1154,"config":1164},{"title":1155,"description":1156,"authors":1157,"heroImage":1158,"date":1159,"body":1160,"category":783,"tags":1161,"updatedDate":1163},"GitLab + HackerOne : pour une sécurité applicative renforcée","Découvrez le partenariat entre GitLab et HackerOne et comment cette intégration peut vous aider à renforcer la sécurité de vos applications.",[1146],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","2025-04-03","La sécurité doit désormais être intégrée dès le début du processus de développement. Les entreprises ont besoin de solutions robustes qui intègrent la sécurité à chaque étape du cycle de développement logiciel. Le partenariat entre HackerOne et GitLab offre une combinaison gagnante pour les équipes de développement d'applications modernes.\n\nGitLab, la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ? \") complète et alimentée par l'IA, s'associe à HackerOne, leader de la sécurité collaborative, pour combiner le meilleur des deux univers : les workflows DevSecOps rationalisés de GitLab et les puissantes capacités de gestion des vulnérabilités de HackerOne.\n\nDécouvrez dans ce tutoriel comment améliorer la productivité de vos équipes de développement et renforcer votre posture de sécurité grâce à l'intégration de GitLab à HackerOne.\n\n## Une intégration pensée pour les développeurs\n\nL'intégration de GitLab à la plateforme de cybersécurité HackerOne est aussi simple à mettre en œuvre que puissante. Lorsqu'un chercheur en cybersécurité détecte une vulnérabilité via la plateforme HackerOne, celle-ci est automatiquement convertie en un ticket GitLab. \n\nCe workflow permet de :\n\n* détecter les vulnérabilités sur la plateforme HackerOne\n* créer automatiquement des tickets GitLab à partir des vulnérabilités validées\n* permettre aux équipes de développement de traiter ces tickets directement dans leur workflow existant\n* synchroniser le statut de résolution de ces vulnérabilités entre les deux plateformes\n\nVous pouvez tirer parti de cette [intégration](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) en liant les tickets GitLab aux rapports HackerOne comme références. Cette synchronisation bidirectionnelle et fluide des données entre vos rapports HackerOne et les tickets GitLab améliore ainsi la coordination entre les équipes de développement et de sécurité tout en rationalisant le traitement des failles de sécurité.\n\nPour configurer cette intégration, référez-vous aux instructions détaillées de la [documentation HackerOne dédiée à l'intégration GitLab](https://docs.hackerone.com/en/articles/10394699-gitlab-setup), dont voici les principales étapes :\n\n1. [Créez une application OAuth 2.0](https://docs.gitlab.com/ee/integration/oauth_provider.html) pour votre instance GitLab à l'aide des paramètres fournis par HackerOne\n2. Connectez la plateforme HackerOne à votre instance GitLab en utilisant cette application OAuth 2.0\n3. Autorisez HackerOne à accéder à l'API GitLab\n4. Configurez le projet GitLab vers lequel vous souhaitez transférer les rapports HackerOne \n5. Sélectionnez les champs HackerOne à mapper aux champs GitLab correspondants\n6. Définissez les événements à synchroniser, de GitLab vers HackerOne et de HackerOne vers GitLab\n\nUne fois l'intégration mise en place, la synchronisation bidirectionnelle des données entre GitLab et HackerOne devient fluide, réduisant les changements de contexte et facilitant le suivi des vulnérabilités sur les deux systèmes. \n\nLes principales fonctionnalités de cette intégration sont les suivantes :\n\n* **Création de tickets GitLab depuis HackerOne** : créez de nouveaux tickets GitLab à partir des rapports que vous recevez dans HackerOne.\n* **Connexion des rapports HackerOne aux tâches GitLab existantes.**   \n* **Synchronisation des mises à jour apportées aux rapports HackerOne vers GitLab** : les informations suivantes sont envoyées sous forme de commentaires dans le ticket GitLab correspondant.\n  * Commentaires du rapport  \n  * Changements d'état  \n  * Récompenses  \n  * Changements d'assignation  \n  * Divulgation publique  \n  * Fermeture du ticket GitLab  \n* **Synchronisation des mises à jour de GitLab vers HackerOne** : lorsque certaines actions sont effectuées dans un ticket GitLab, ces mises à jour sont reprises automatiquement dans le rapport correspondant sur HackerOne, sous forme de commentaire interne :\n  * Commentaires  \n  * Changements d'état  \n* **Mappage des niveaux de gravité HackerOne avec les labels GitLab** : définissez une priorité personnalisée lorsque vous transférez un rapport HackerOne vers GitLab.  \n* **Mappage des dates d'échéance** : définissez automatiquement une date d'échéance personnalisée dans GitLab en fonction du niveau de gravité du rapport HackerOne.\n\n![GitLab + HackerOne : Ajouter des commentaires ou modifier l'état du rapport dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nCes fonctionnalités renforcent la coordination entre les équipes de développement et de sécurité et rationalisent le traitement des failles de sécurité. Pour en savoir plus sur le fonctionnement de l'intégration, consultez la [documentation](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) fournie par HackerOne.\n\n## Aperçu des programmes de bug bounty de HackerOne\n\nHackerOne propose des programmes de bug bounty, c'est-à-dire des initiatives en matière de cybersécurité qui récompensent la découverte et le signalement de vulnérabilités dans les systèmes logiciels, les sites web ou les applications de ses clients. Ces programmes contribuent à renforcer la sécurité des applications en :\n\n* identifiant les failles de sécurité avant que des acteurs malveillants ne puissent les exploiter\n* tirant parti de l'expertise diversifiée d'une communauté mondiale de chercheurs en cybersécurité\n* offrant un moyen rentable d'améliorer la cybersécurité\n* complétant les efforts de sécurité internes et les tests de pénétration traditionnels\n\nGitLab s'appuie sur le programme de bug bounty de HackerOne pour permettre aux chercheurs en cybersécurité de signaler les vulnérabilités présentes dans ses applications ou son infrastructure. Cette approche collaborative aide GitLab à identifier et à résoudre plus efficacement les potentielles failles de sécurité.\n\n![Page du programme de bug bounty de GitLab de HackerOne](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nEn tirant parti de la plateforme HackerOne et de la communauté mondiale de hackers éthiques, les entreprises peuvent considérablement renforcer leur posture de sécurité, identifier plus rapidement les vulnérabilités et garder une longueur d'avance sur les menaces potentielles.\n\n## Sécurisez vos applications et améliorez votre productivité avec GitLab\n\nGitLab offre une plateforme DevSecOps complète, qui intègre des fonctionnalités couvrant l'ensemble du cycle de développement logiciel, y compris des outils de [sécurité et de conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et conformité GitLab\"). GitLab prend en charge les types de scanners de sécurité suivants :\n- Tests statiques de sécurité des applications (SAST)\n- Tests dynamiques de sécurité des applications (DAST)\n- Analyse des conteneurs\n- Analyse des dépendances\n- Analyse de l'Infrastructure as Code (IaC)\n- Fuzzing guidé par la couverture de code\n- Test de l’API web par injection de données aléatoires\n\nAvec GitLab, vous pouvez simplement appliquer un template à votre fichier de définition de [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") pour activer un scanning de sécurité. Par exemple, l'activation de SAST ne nécessite que quelques lignes de code dans le fichier `.gitlab-ci.yml` :\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nCela exécutera SAST à l'étape de test et [détectera automatiquement les langages utilisés](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) dans votre application. Ainsi, chaque fois que vous créez une merge request, SAST analyse les différences entre la branche de fonctionnalité et la branche cible pour détecter les vulnérabilités et fournit des données précises sur chaque faille de sécurité afin d'en faciliter la correction.\n\n![Vulnérabilité d'injection NoSQL détectée dans une MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nLes résultats du scanner SAST peuvent bloquer le merge du code si des stratégies de sécurité sont appliquées. Les utilisateurs natifs de GitLab peuvent être définis comme approbateurs, ce qui permet d'effectuer les revues requises avant de fusionner du code non sécurisé. Cela garantit que toutes les vulnérabilités sont surveillées par les parties concernées.\n\n![Stratégie d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOne a intégré GitLab à ses processus opérationnels et à ses processus de développement de manière stratégique, ce qui lui a permis de les rendre plus fluides et plus efficaces, à grande échelle, et de renforcer la collaboration entre les équipes. Parmi ces améliorations, HackerOne profite désormais de déploiements plus rapides et d'une planification inter-équipes performante.\n\n## Principaux avantages d'intégrer GitLab à HackerOne\n\nL'utilisation conjointe de HackerOne et GitLab offre les avantages suivants :\n\n* **Visibilité accrue en matière de sécurité** : les équipes de développement bénéficient d'un accès immédiat aux failles de sécurité sans quitter leur environnement de workflow principal. Cette visibilité en temps réel aide les équipes à prioriser les problèmes de sécurité parallèlement au développement des fonctionnalités.\n* **Processus de correction rationalisé** : en convertissant automatiquement les rapports HackerOne en tickets GitLab, le processus de correction des vulnérabilités s'intègre naturellement au cycle de développement standard. Cela évite les changements de contexte entre les plateformes et garantit des correctifs de sécurité en parallèle des autres tâches de développement.\n* **Temps de correction réduit** : l'intégration raccourcit considérablement le délai entre la détection d'une vulnérabilité et sa résolution. Les soumissions de vulnérabilités dans HackerOne étant immédiatement disponibles dans GitLab, les équipes de développement peuvent réagir sans délai et renforcer ainsi la posture de sécurité globale.\n* **Collaboration améliorée** : cette intégration fluidifie les échanges entre les chercheurs en cybersécurité, les équipes de sécurité et de développement. Les commentaires et mises à jour circulent entre les deux plateformes, créant ainsi un environnement collaboratif axé sur le renforcement de la sécurité.\n* **Impact réel** : les entreprises qui ont opté pour l'intégration HackerOne + GitLab ont constaté les améliorations suivantes :\n    * Une réduction pouvant atteindre 70 % du temps nécessaire entre l'identification d'une vulnérabilité et sa correction\n    * Une satisfaction accrue des équipes de développement, qui peuvent continuer à travailler dans leur environnement préféré\n    * Une visibilité accrue de la sécurité à l'échelle de l'entreprise\n    * Une allocation plus efficace des ressources de sécurité\n\n## En savoir plus sur GitLag + HackerOne \n\nPour en savoir plus sur GitLab et HackerOne, et découvrir comment nous pouvons vous aider à renforcer votre posture de sécurité, consultez les ressources suivantes :\n\n* [Utilisation de l'intégration GitLab sur HackerOne](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)\n* [Programme de Bug Bounty de GitLab sur HackerOne](https://hackerone.com/gitlab?type=team)\n* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)\n* [HackerOne réalise des déploiements 5  fois plus rapides avec la sécurité intégrée de GitLab](https://about.gitlab.com/fr-fr/customers/hackerone/) \n* [Documentation sur la sécurité des applications GitLab](https://docs.gitlab.com/ee/user/application_security/)\n",[783,804,234,284,802,720,1162],"bug bounty","2025-05-13",{"slug":1165,"featured":6,"template":808},"enhance-application-security-with-gitlab-hackerone",{"content":1167,"config":1177},{"heroImage":1168,"body":1169,"authors":1170,"updatedDate":1172,"date":1173,"title":1174,"tags":1175,"description":1176,"category":783},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","Imaginez le scénario suivant : un ingénieur travaille dans une entreprise technologique en pleine croissance et reçoit un appel urgent à 2 heures du matin. Un pipeline de déploiement critique a échoué, et son équipe essaie de comprendre les raisons de cet échec. Après des heures d'investigation, il réalise qu'un utilisateur a révoqué le jeton d'accès personnel d'un ingénieur qui a quitté l'entreprise une semaine plus tôt. Ce token étant lié à plusieurs processus d'automatisation clés, votre système est maintenant dans un état catastrophique. Comment faire en sorte que cette situation ne se reproduise plus ?\n\nDécouvrez dans cet article toutes les étapes de la gestion des tokens, de leur identification à leur sécurisation. Ce guide complète notre [documentation officielle sur les tokens](https://docs.gitlab.com/ee/security/tokens) et s'adresse aux administrateurs GitLab, aux équipes de développement et de sécurité qui doivent garantir une gestion efficace et sécurisée des tokens dans le cadre de leurs projets.\n\n## Sélection du token adapté au job\n\nChoisir le bon token garantit à la fois la sécurité et des fonctionnalités optimales selon votre cas d'utilisation. Les tokens peuvent servir à authentifier des requêtes API, à automatiser des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), à intégrer des outils tiers, à gérer des déploiements, à accéder aux dépôts et bien plus encore.\n\n![Guide de gestion des tokens - organigramme des jetons](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\nLe graphique ci-dessus illustre un cas d'utilisation classique lié à la propriété d'un seul utilisateur. Pour plus d'informations, consultez notre documentation sur les rôles et autorisations des utilisateurs dans chaque [espace de nommage](https://docs.gitlab.com/ee/user/permissions.html) (utilisateur/groupe) au sein de votre instance ou groupe principal.\n\nVoici quelques exemples d'utilisation :\n\n* Les **jetons d'accès personnel** ([PAT](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)) peuvent être utilisés lorsque l'accès personnel et les autorisations d'un utilisateur sont requis. Dans ce cas, les identifiants de connexion suivent le statut et les autorisations du compte de l'utilisateur, y compris sa révocation si le compte perd l'accès à un projet ou à un groupe spécifique (ou est entièrement bloqué).\n\n* Les **tokens d'accès au projet/groupe** ([PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token) / [GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)) sont recommandés lorsque l'accès doit être limité aux ressources d'un projet/groupe spécifique. Ainsi, tout utilisateur disposant d'un PrAT/GrAT peut accéder à ces ressources via des mécanismes gérés par des portées attribuées.\n\n## Types de tokens\n\nVoici la liste des tokens GitLab, avec leurs préfixes par défaut et le principal cas d'utilisation associé. Pour plus de détails, consultez la [page de présentation des tokens GitLab](https://docs.gitlab.com/ee/security/tokens/#available-scopes).\n\n| Tokens                            | Préfixe | Description |\n| --------------------------------- | ------- | ----------- |\n| Jeton d'accès personnel           | glpat   | Accès aux données propres à l'utilisateur |\n| Token OAuth 2.0                   | gloas   | Authentification à l'aide du protocole OAuth2.0 pour des intégrations tierces |\n| Token d'emprunt d'identité        | glpat   | Possibilité d'agir au nom d'un autre utilisateur à des fins d'administration |\n| Token d'accès au projet           | glpat   | Accès aux données d'un projet spécifique |\n| Token d'accès au groupe           | glpat   | Accès aux données d'un groupe spécifique |\n| Token de déploiement              | gldt    | Accès aux images d'un registre de conteneurs pour cloner ou effectuer un push/pull sans identifiants utilisateur ni mot de passe |\n| Clés de déploiement               | N/A     | Accès en lecture seule ou en lecture-écriture aux dépôts |\n| Token d'accès au runner           | glrt    | Authentification des GitLab Runners |\n| Token de job CI/CD                | glcbt   | Automatisation des processus CI/CD |\n| Token de déclenchement            | glptt   | Déclenchement manuel ou automatique des pipelines |\n| Token de flux                     | glft    | Authentification de l'accès aux flux de paquets/RSS |\n| Token d'e-mail entrant            | glimt   | Traitement des e-mails entrants |\n| Token GitLab Agent for Kubernetes | glagent | Gestion des clusters [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") via GitLab Agent |\n| Tokens SCIM                       | glsoat  | Activation des intégrations SCIM pour le provisionnement des utilisateurs |\n| Token client pour feature flags   | glffct  | Activation automatisée des feature flags |\n| Token de webhook                  | N/A     | Token de secret défini par l'utilisateur pour sécuriser les charges utiles des webhooks et vérifier que les requêtes proviennent de GitLab |\n\n## Identification des tokens utilisés\n\n### Inventaire des identifiants de connexion\n\nAvec GitLab Ultimate, les administrateurs (GitLab Self-Managed) et les propriétaires de groupe principal (GitLab.com, à partir de la version 17.5) peuvent surveiller les identifiants de connexion dans leur espace de nommage.\n\nCet inventaire permet de suivre les détails des tokens, notamment :\n\n* Le type de tokens\n* Les tokens disponibles sur [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)\n* Les tokens disponibles sur [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)\n* Les comptes utilisateurs associés\n* Les portées des tokens, ainsi que leur date de création et d'expiration\n* Les adresses IP des derniers tokens utilisés (à partir de GitLab 17.10)\n* Le filtrage des tokens en fonction des paramètres définis par l'utilisateur\n* La possibilité de révoquer et de procéder à une rotation de ces tokens\n\nTenir correctement un inventaire des identifiants de connexion permet d'identifier les tokens avec des autorisations excessives et ceux dont la rotation est requise, ce qui garantit un workflow sécurisé et efficace.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n#### API dédiée pour l'inventaire des identifiants\n\nEn complément de l'interface utilisateur, une API d'inventaire des identifiants de connexion permet d’accéder à cet inventaire via le nouveau [point de terminaison](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project) /group/:id/manage. Les identifiants de connexion accessibles sous ce point de terminaison sont réservés aux [comptes utilisateurs Entreprise](https://docs.gitlab.com/ee/user/enterprise_user/) ayant souscrit un abonnement GitLab. Ils ne peuvent être consultés que par le propriétaire du groupe principal du projet de l'entreprise concernée.\n\nVoici à quoi pourrait ressembler un appel API à l'avenir :\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\"\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\" \"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"\n```\n\n### API GitLab\n\nL'API GitLab vous permet de répertorier et de gérer les tokens automatiquement (à l'aide de scripts ou d'applications) au sein de votre entreprise. Les points de terminaison clés liés à l'authentification prennent en charge [différents types de tokens](https://docs.gitlab.com/ee/api/rest/authentication.html), notamment les jetons d'accès personnel, les tokens d'accès au groupe, les tokens de job CI/CD, entre autres. Voici un exemple d'utilisation d'un jeton d'accès personnel qui répertorie tous les projets visibles sur GitLab pour l'utilisateur authentifié :\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \"https://gitlab.example.com/api/v4/projects\"\n```\n\nRegardez cette vidéo et découvrez comment effectuer des appels à l'API GitLab.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n### Identification de l’utilisation des tokens\n\nVous pouvez identifier de différentes manières les emplacements ou les contextes dans lesquels les tokens sont utilisés :\n\n* Depuis **Paramètres utilisateur > [Jetons d'accès](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n* Dans l'inventaire des identifiants de connexion\n* Dans les événements d'audit\n* Via l'API\n\nLes informations sur l'utilisation des tokens sont mises à jour toutes les 10 minutes pour **last_used** et toutes les minutes pour **last_used_ip**.\n\nLa possibilité d'afficher les adresses IP a été introduite dans GitLab 17.9 et est contrôlée par le feature flag **:pat_ip**. Suivez ces [étapes pour afficher la dernière fois où un token a été utilisé](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used), ainsi que ses cinq dernières adresses IP distinctes.\n\n![Guide de gestion des tokens - paramètres des jetons d'accès personnels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n## Gestion des tokens dans l'API et l'interface utilisateur de GitLab\n\nLe tableau suivant répertorie des vidéos qui présentent plusieurs créations de tokens dans l'interface utilisateur et leur utilisation via l'API.\n\n| Tokens                  | UI GitLab | API GitLab |\n| ----------------------- | --------- | ---------- |\n| Jeton d'accès personnel | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=3) | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=43) |\n| Token d'accès au groupe | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=120) | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=157) |\n| Token d'accès au projet | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=254) | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=285) |\n\n## Gestion de la rotation et de l'expiration des tokens\n\nLa mise en œuvre d'une rotation des tokens et de règles d'expiration strictes permet de réduire les risques de compromission et de garantir la conformité aux normes de sécurité. Une rotation régulière et des expirations contrôlées empêchent que les identifiants de connexion obsolètes ne deviennent des failles de sécurité.\n\nAuparavant, les tokens d'accès au groupe et au projet arrivés à expiration étaient automatiquement supprimés, ce qui compliquait les audits et les analyses de résultats des scans de sécurité en raison de l'absence d'historique de ces tokens inactifs. Pour remédier à ce problème, une [fonctionnalité](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) a introduit la conservation dans l'interface utilisateur des enregistrements de tokens d'accès au groupe et au projet inactifs pendant 30 jours après leur expiration. Cette amélioration permet aux équipes de suivre l'utilisation, l'expiration et la révocation des tokens et offre ainsi une meilleure conformité et un meilleur contrôle.\n\nPour gérer de manière proactive la rotation et l'expiration de vos tokens, procédez comme suit :\n\n* Régénérez activement vos tokens via l'interface utilisateur ou l'API. Si vous utilisez l'API, tenez compte du mécanisme de sécurité de [détection automatique de la réutilisation des tokens](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection).\n\n* Définissez une [limite de durée de validité maximale](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) à l'échelle de l'instance pour les tokens d'accès.\n\n### API de rotation des tokens\n\nJusqu'à la version GitLab 17.7, les utilisateurs devaient effectuer une rotation automatique des tokens d'accès exclusivement via l'API. Cette fonctionnalité est maintenant disponible dans l'interface utilisateur. Pour en savoir plus, regardez les vidéos dans le tableau ci-dessous ou consultez notre [documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui).\n\n### Extraits de code pour la rotation des tokens\n\nLe tableau suivant regroupe des vidéos expliquant le processus de rotation des tokens dans GitLab.\n\n| Tokens                  | Prérequis | UI GitLab | API GitLab |\n| ----------------------- | --------- | --------- | ---------- |\n| Jeton d'accès personnel | Portée : API | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=76) | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=92) |\n| Token d'accès au groupe | Portée : API et rôle(s) : propriétaire | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=203) | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=214) |\n| Token d'accès au projet | Portée : API et rôle(s) : propriétaire, chargé de maintenance | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=335) | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=349) |\n\n## Bonnes pratiques de gestion des tokens\n\n### Principe de moindre privilège\n\nAtténuez les risques en limitant les autorisations attribuées aux tokens à celles strictement nécessaires à leurs tâches respectives. Vous pourrez ainsi anticiper et résoudre de manière proactive les points de défaillance de vos systèmes.\n\nPour ce faire, procédez comme suit :\n\n* Sélectionnez le token adapté au job. Consultez l'organigramme en cas de besoin.\n* Attribuez uniquement les portées nécessaires lors de la création d'un token. Par exemple, utilisez des portées en lecture seule pour les tokens employés à des fins d'audit. Consultez notre documentation sur les [rôles](https://docs.gitlab.com/ee/user/permissions.html#roles).\n* Évitez d'accorder des privilèges d'administrateur, sauf si cela est explicitement requis.\n* Appliquez une [durée de validité](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1) par défaut à l'échelle de l'instance.\n* Examinez et auditez régulièrement les autorisations octroyées aux tokens pour vous assurer de leur adéquation avec les besoins opérationnels actuels.\n* Révoquez les tokens une fois leur tâche terminée.\n\n\n\n### Comptes de service\n\nLes [comptes de service](https://docs.gitlab.com/ee/user/profile/service_accounts.html) associent les tokens à des entités non humaines, ce qui permet de les distinguer des comptes d'utilisateurs et de réduire la dépendance à des utilisateurs spécifiques. Au lieu d'utiliser des comptes personnels pour générer des tokens à des fins d'automatisation, créez des comptes de service avec des portées limitées.\n\nVoici les principaux avantages :\n\n* Utilisation de tokens de compte de service dans les pipelines CI/CD pour éviter les perturbations causées par les modifications de compte d'utilisateur\n* Automatisation des processus de rotation, sans impact sur les comptes personnels\n* Suivi ciblé et piste d'audit plus clairs des actions entreprises par les comptes de service\n* Comptes de service [sans date d'expiration](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date)\n* Aucun [siège de licence](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account) consommé\n\nGitLab a lancé une nouvelle [interface utilisateur dédiée aux comptes de service](https://gitlab.com/groups/gitlab-org/-/epics/9965) en complément de leur [création via l'API](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), afin de simplifier leur gestion et celle des tokens associés. Regardez la démo ci-dessous sur l'utilisation automatique des comptes de service.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n### Outils de détection des vulnérabilités\n\nTirez parti des outils de sécurité intégrés à la plateforme GitLab pour détecter et atténuer les vulnérabilités associées à l'utilisation des tokens. Pour une protection optimale, il est recommandé d'utiliser l'ensemble de ces outils de manière combinée.\n\n* [Détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) : analyse votre dépôt à la recherche de secrets codés en dur, tels que les tokens d'API, les mots de passe et d'autres informations contenant des données sensibles. Consultez la [liste des secrets détectés](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html).\n* [Tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) : analyse votre code source à la recherche de failles de sécurité et [fournit des rapports intégrés aux merge requests contenant les résultats de l'interface utilisateur](https://docs.gitlab.com/ee/user/application_security/sast/#features), entre autres fonctionnalités.\n* [Analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) : assure que les bibliothèques tierces utilisées dans votre projet ne présentent pas de vulnérabilités liées aux tokens.\n\n### Journaux d'audit et surveillance\n\nVeillez à l'intégrité de vos tokens en examinant régulièrement les journaux d'audit et les données d'utilisation des tokens au niveau de l'instance et/ou du groupe.\n\n* [Événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html) : activez la journalisation des événements d'audit dans GitLab pour suivre les activités liées aux tokens, telles que la création, l'utilisation, la révocation et les appels API suspects (paramètres non autorisés dans les journaux, déclenchements répétés du limiteur de débit).\n* [Liste des adresses IP autorisées](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions) : permet d'empêcher qu'un utilisateur malveillant masque ses activités derrière plusieurs adresses IP.\n* [Alertes](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) : configurez des alertes pour les activités inhabituelles (déclenchement d'une remontée d'alerte d'incident lors des rotations d'astreinte ou création d'incidents).\n* [Inventaire des identifiants de connexion](https://docs.gitlab.com/ee/administration/credentials_inventory.html) : contrôlez l'ensemble des tokens d'accès disponibles avec la possibilité de les révoquer si nécessaire.\n* [Notifications](https://docs.gitlab.com/ee/user/profile/notifications.html) : gérez de manière proactive tous les e-mails de notification d'expiration de tokens (d'accès au groupe/projet et personnel) que vous recevez. Suite aux retours de nos clients, cette fonctionnalité a été étendue pour inclure des notifications à 30 jours et 60 jours, en plus de la notification par défaut à 7 jours.\n* [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook) : les webhooks de tokens d'accès peuvent être configurés sur les groupes et les projets pour envoyer des événements d'expiration de tokens à sept jours. Cette fonctionnalité a également été étendue pour inclure des notifications à 30 jours et 60 jours via le feature flag **:extended_expiry_webhook_execution_setting** (désactivé par défaut).\n\n## Perspectives\n\nCompte tenu du vaste catalogue de tokens de GitLab, nous avons [prévu](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) une consolidation axée sur la durée de validité, les portées affinées, la gestion cohérente et l'utilisation. En ce qui concerne les fonctionnalités liées aux tokens, nous avons identifié les priorités suivantes : une interface utilisateur complète pour les comptes de service, l'ajout de nouveaux types d'identifiants dans l'inventaire des identifiants de connexion et une amélioration de l'audit des tokens et comptes de service.\n\n> [Essayez GitLab Ultimate gratuitement pendant 60 jours](https://about.gitlab.com/free-trial/) et commencez à utiliser les fonctionnalités de gestion des tokens.\n",[1171],"Hakeem Abdul-Razak","2025-07-01","2025-02-25","Gestion des tokens sur GitLab : guide complet",[804,783,802,803,771],"Découvrez le processus de gestion, d'identification et de sécurisation des tokens et renforcez votre sécurité tout au long du cycle de développement logiciel.",{"slug":1178,"featured":91,"template":808},"the-ultimate-guide-to-token-management-at-gitlab",{"content":1180,"config":1183},{"title":938,"description":939,"authors":1181,"heroImage":942,"date":943,"body":944,"category":724,"tags":1182},[941],[109,720,802,804,783,771],{"slug":947,"featured":91,"template":808},[1185,1190,1195],{"content":1186,"config":1189},{"title":838,"description":839,"authors":1187,"heroImage":842,"date":843,"body":844,"category":688,"tags":1188},[841],[846,847,720],{"featured":6,"template":808,"slug":849},{"content":1191,"config":1194},{"title":1102,"description":1103,"authors":1192,"heroImage":1107,"date":1108,"category":771,"tags":1193,"body":1110},[1105,1106],[550,771,803,187],{"featured":6,"template":808,"slug":1112},{"content":1196,"config":1199},{"heroImage":852,"date":853,"title":854,"description":855,"authors":1197,"body":858,"category":688,"tags":1198},[857],[846,720,748,771],{"featured":6,"template":808,"slug":861},[1201,1206,1211],{"content":1202,"config":1205},{"title":864,"description":865,"authors":1203,"heroImage":867,"date":868,"body":869,"category":688,"tags":1204},[841],[846,802,871,771,803,284,847,804],{"featured":6,"template":808,"slug":873},{"content":1207,"config":1210},{"heroImage":1115,"body":1116,"authors":1208,"updatedDate":1120,"date":1121,"title":1122,"tags":1209,"description":1124,"category":771},[1118,1119],[284,771,109,720],{"featured":91,"template":808,"slug":1126},{"content":1212,"config":1215},{"title":950,"description":951,"authors":1213,"heroImage":954,"date":955,"body":956,"category":724,"tags":1214},[953],[720,802,771],{"slug":959,"featured":6,"template":808},1752683461831]