[{"data":1,"prerenderedAt":795},["ShallowReactive",2],{"/fr-fr/blog/categories/insights/":3,"navigation-fr-fr":23,"banner-fr-fr":443,"footer-fr-fr":456,"insights-category-page-fr-fr":667},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":16,"_type":17,"title":18,"_source":19,"_file":20,"_stem":21,"_extension":22},"/fr-fr/blog/categories/insights","categories",false,"",{"title":9,"description":10},"Informations clés","Browse articles related to Informations clés on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":15},"BlogCategory","insights",true,"content:fr-fr:blog:categories:insights.yml","yaml","Insights","content","fr-fr/blog/categories/insights.yml","fr-fr/blog/categories/insights","yml",{"_path":24,"_dir":25,"_draft":6,"_partial":6,"_locale":7,"data":26,"_id":439,"_type":17,"title":440,"_source":19,"_file":441,"_stem":442,"_extension":22},"/shared/fr-fr/main-navigation","fr-fr",{"logo":27,"freeTrial":32,"sales":37,"login":42,"items":47,"search":380,"minimal":416,"duo":430},{"config":28},{"href":29,"dataGaName":30,"dataGaLocation":31},"/fr-fr/","gitlab logo","header",{"text":33,"config":34},"Commencer un essai gratuit",{"href":35,"dataGaName":36,"dataGaLocation":31},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":38,"config":39},"Contacter l'équipe commerciale",{"href":40,"dataGaName":41,"dataGaLocation":31},"/fr-fr/sales/","sales",{"text":43,"config":44},"Connexion",{"href":45,"dataGaName":46,"dataGaLocation":31},"https://gitlab.com/users/sign_in/","sign in",[48,92,190,195,301,361],{"text":49,"config":50,"cards":52,"footer":75},"Plateforme",{"dataNavLevelOne":51},"platform",[53,59,67],{"title":49,"description":54,"link":55},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":56,"config":57},"Découvrir notre plateforme",{"href":58,"dataGaName":51,"dataGaLocation":31},"/fr-fr/platform/",{"title":60,"description":61,"link":62},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":63,"config":64},"Découvrez GitLab Duo",{"href":65,"dataGaName":66,"dataGaLocation":31},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":68,"description":69,"link":70},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":71,"config":72},"En savoir plus",{"href":73,"dataGaName":74,"dataGaLocation":31},"/fr-fr/why-gitlab/","why gitlab",{"title":76,"items":77},"Démarrer avec",[78,83,88],{"text":79,"config":80},"Ingénierie de plateforme",{"href":81,"dataGaName":82,"dataGaLocation":31},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":84,"config":85},"Expérience développeur",{"href":86,"dataGaName":87,"dataGaLocation":31},"/fr-fr/developer-experience/","Developer experience",{"text":89,"config":90},"MLOps",{"href":91,"dataGaName":89,"dataGaLocation":31},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":93,"left":15,"config":94,"link":96,"lists":100,"footer":172},"Produit",{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"Voir toutes les solutions",{"href":99,"dataGaName":95,"dataGaLocation":31},"/fr-fr/solutions/",[101,127,150],{"title":102,"description":103,"link":104,"items":109},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":31},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":31,"dataGaName":111},"/fr-fr/solutions/continuous-integration/",{"text":115,"config":116},"Développement assisté par l'IA",{"href":65,"dataGaLocation":31,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"Gestion du code source",{"href":121,"dataGaLocation":31,"dataGaName":122},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Livraison de logiciels automatisée",{"href":107,"dataGaLocation":31,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":31,"icon":134},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[136,141,146],{"text":137,"config":138},"Application Security Testing",{"href":139,"dataGaName":140,"dataGaLocation":31},"/solutions/application-security-testing/","Application security testing",{"text":142,"config":143},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":144,"dataGaLocation":31,"dataGaName":145},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":147,"config":148},"Software Compliance",{"href":149,"dataGaName":147,"dataGaLocation":31},"/solutions/software-compliance/",{"title":151,"link":152,"items":157},"Mesures",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":31},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Visibilité et mesures",{"href":155,"dataGaLocation":31,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Gestion de la chaîne de valeur",{"href":165,"dataGaLocation":31,"dataGaName":166},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"Données d'analyse et informations clés",{"href":170,"dataGaLocation":31,"dataGaName":171},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLab pour",[175,180,185],{"text":176,"config":177},"Entreprises",{"href":178,"dataGaLocation":31,"dataGaName":179},"/fr-fr/enterprise/","enterprise",{"text":181,"config":182},"PME",{"href":183,"dataGaLocation":31,"dataGaName":184},"/fr-fr/small-business/","small business",{"text":186,"config":187},"Secteur public",{"href":188,"dataGaLocation":31,"dataGaName":189},"/fr-fr/solutions/public-sector/","public sector",{"text":191,"config":192},"Tarifs",{"href":193,"dataGaName":194,"dataGaLocation":31,"dataNavLevelOne":194},"/fr-fr/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":288},"Ressources",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Afficher toutes les ressources",{"href":202,"dataGaName":198,"dataGaLocation":31},"/fr-fr/resources/",[204,237,260],{"title":205,"items":206},"Premiers pas",[207,212,217,222,227,232],{"text":208,"config":209},"Installation",{"href":210,"dataGaName":211,"dataGaLocation":31},"/fr-fr/install/","install",{"text":213,"config":214},"Guides de démarrage rapide",{"href":215,"dataGaName":216,"dataGaLocation":31},"/fr-fr/get-started/","quick setup checklists",{"text":218,"config":219},"Apprentissage",{"href":220,"dataGaLocation":31,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Documentation sur le produit",{"href":225,"dataGaName":226,"dataGaLocation":31},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Vidéos sur les bonnes pratiques",{"href":230,"dataGaName":231,"dataGaLocation":31},"/fr-fr/getting-started-videos/","best practice videos",{"text":233,"config":234},"Intégrations",{"href":235,"dataGaName":236,"dataGaLocation":31},"/fr-fr/integrations/","integrations",{"title":238,"items":239},"Découvrir",[240,245,250,255],{"text":241,"config":242},"Histoires de succès client",{"href":243,"dataGaName":244,"dataGaLocation":31},"/fr-fr/customers/","customer success stories",{"text":246,"config":247},"Blog",{"href":248,"dataGaName":249,"dataGaLocation":31},"/fr-fr/blog/","blog",{"text":251,"config":252},"Travail à distance",{"href":253,"dataGaName":254,"dataGaLocation":31},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":256,"config":257},"TeamOps",{"href":258,"dataGaName":259,"dataGaLocation":31},"/fr-fr/teamops/","teamops",{"title":261,"items":262},"Connecter",[263,268,273,278,283],{"text":264,"config":265},"Services GitLab",{"href":266,"dataGaName":267,"dataGaLocation":31},"/fr-fr/services/","services",{"text":269,"config":270},"Communauté",{"href":271,"dataGaName":272,"dataGaLocation":31},"/community/","community",{"text":274,"config":275},"Forum",{"href":276,"dataGaName":277,"dataGaLocation":31},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"Événements",{"href":281,"dataGaName":282,"dataGaLocation":31},"/events/","events",{"text":284,"config":285},"Partenaires",{"href":286,"dataGaName":287,"dataGaLocation":31},"/partners/","partners",{"backgroundColor":289,"textColor":290,"text":291,"image":292,"link":296},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":293,"config":294},"carte promo The Source",{"src":295},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":297,"config":298},"Lire les articles les plus récents",{"href":299,"dataGaName":300,"dataGaLocation":31},"/fr-fr/the-source/","the source",{"text":302,"config":303,"lists":305},"Société",{"dataNavLevelOne":304},"company",[306],{"items":307},[308,313,319,321,326,331,336,341,346,351,356],{"text":309,"config":310},"À propos",{"href":311,"dataGaName":312,"dataGaLocation":31},"/fr-fr/company/","about",{"text":314,"config":315,"footerGa":318},"Emplois",{"href":316,"dataGaName":317,"dataGaLocation":31},"/jobs/","jobs",{"dataGaName":317},{"text":279,"config":320},{"href":281,"dataGaName":282,"dataGaLocation":31},{"text":322,"config":323},"Leadership",{"href":324,"dataGaName":325,"dataGaLocation":31},"/company/team/e-group/","leadership",{"text":327,"config":328},"Équipe",{"href":329,"dataGaName":330,"dataGaLocation":31},"/company/team/","team",{"text":332,"config":333},"Manuel",{"href":334,"dataGaName":335,"dataGaLocation":31},"https://handbook.gitlab.com/","handbook",{"text":337,"config":338},"Relations avec les investisseurs",{"href":339,"dataGaName":340,"dataGaLocation":31},"https://ir.gitlab.com/","investor relations",{"text":342,"config":343},"Centre de confiance",{"href":344,"dataGaName":345,"dataGaLocation":31},"/fr-fr/security/","trust center",{"text":347,"config":348},"Centre pour la transparence de l'IA",{"href":349,"dataGaName":350,"dataGaLocation":31},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":352,"config":353},"Newsletter",{"href":354,"dataGaName":355,"dataGaLocation":31},"/company/contact/","newsletter",{"text":357,"config":358},"Presse",{"href":359,"dataGaName":360,"dataGaLocation":31},"/press/","press",{"text":362,"config":363,"lists":364},"Nous contacter",{"dataNavLevelOne":304},[365],{"items":366},[367,370,375],{"text":38,"config":368},{"href":40,"dataGaName":369,"dataGaLocation":31},"talk to sales",{"text":371,"config":372},"Aide",{"href":373,"dataGaName":374,"dataGaLocation":31},"/support/","get help",{"text":376,"config":377},"Portail clients GitLab",{"href":378,"dataGaName":379,"dataGaLocation":31},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":381,"login":382,"suggestions":389},"Fermer",{"text":383,"link":384},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":385,"config":386},"gitlab.com",{"href":45,"dataGaName":387,"dataGaLocation":388},"search login","search",{"text":390,"default":391},"Suggestions",[392,395,400,402,407,412],{"text":60,"config":393},{"href":65,"dataGaName":394,"dataGaLocation":388},"GitLab Duo (AI)",{"text":396,"config":397},"Suggestions de code (IA)",{"href":398,"dataGaName":399,"dataGaLocation":388},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":401},{"href":113,"dataGaName":111,"dataGaLocation":388},{"text":403,"config":404},"GitLab sur AWS",{"href":405,"dataGaName":406,"dataGaLocation":388},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":408,"config":409},"GitLab sur Google Cloud ",{"href":410,"dataGaName":411,"dataGaLocation":388},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":413,"config":414},"Pourquoi utiliser GitLab ?",{"href":73,"dataGaName":415,"dataGaLocation":388},"Why GitLab?",{"freeTrial":417,"mobileIcon":422,"desktopIcon":427},{"text":418,"config":419},"Commencer votre essai gratuit",{"href":420,"dataGaName":36,"dataGaLocation":421},"https://gitlab.com/-/trials/new/","nav",{"altText":423,"config":424},"Icône GitLab",{"src":425,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":423,"config":428},{"src":429,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":431,"mobileIcon":435,"desktopIcon":437},{"text":432,"config":433},"En savoir plus sur GitLab Duo",{"href":65,"dataGaName":434,"dataGaLocation":421},"gitlab duo",{"altText":423,"config":436},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":438},{"src":429,"dataGaName":426,"dataGaLocation":421},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":444,"_dir":25,"_draft":6,"_partial":6,"_locale":7,"title":445,"titleMobile":445,"button":446,"config":451,"_id":453,"_type":17,"_source":19,"_file":454,"_stem":455,"_extension":22},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":447,"config":448},"Essayer la version bêta",{"href":449,"dataGaName":450,"dataGaLocation":31},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":452},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":457,"_dir":25,"_draft":6,"_partial":6,"_locale":7,"data":458,"_id":663,"_type":17,"title":664,"_source":19,"_file":665,"_stem":666,"_extension":22},"/shared/fr-fr/main-footer",{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":654},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":461,"config":462},"Afficher le code source de la page",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"Modifier cette page",{"href":469,"dataGaName":470,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":472,"config":473},"Veuillez contribuer",{"href":474,"dataGaName":475,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":477,"facebook":478,"youtube":479,"linkedin":480},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,505,559,591,625],{"title":49,"links":483,"subMenu":488},[484],{"text":485,"config":486},"Plateforme DevSecOps",{"href":58,"dataGaName":487,"dataGaLocation":465},"devsecops platform",[489],{"title":191,"links":490},[491,495,500],{"text":492,"config":493},"Voir les forfaits",{"href":193,"dataGaName":494,"dataGaLocation":465},"view plans",{"text":496,"config":497},"Pourquoi choisir GitLab Premium ?",{"href":498,"dataGaName":499,"dataGaLocation":465},"/fr-fr/pricing/premium/","why premium",{"text":501,"config":502},"Pourquoi choisir GitLab Ultimate ?",{"href":503,"dataGaName":504,"dataGaLocation":465},"/fr-fr/pricing/ultimate/","why ultimate",{"title":506,"links":507},"Solutions",[508,513,516,518,523,528,532,535,538,543,545,547,549,554],{"text":509,"config":510},"Transformation digitale",{"href":511,"dataGaName":512,"dataGaLocation":465},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":514,"config":515},"Sécurité et conformité",{"href":139,"dataGaName":140,"dataGaLocation":465},{"text":124,"config":517},{"href":107,"dataGaName":108,"dataGaLocation":465},{"text":519,"config":520},"Développement agile",{"href":521,"dataGaName":522,"dataGaLocation":465},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":524,"config":525},"Transformation cloud",{"href":526,"dataGaName":527,"dataGaLocation":465},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":529,"config":530},"SCM",{"href":121,"dataGaName":531,"dataGaLocation":465},"source code management",{"text":111,"config":533},{"href":113,"dataGaName":534,"dataGaLocation":465},"continuous integration & delivery",{"text":163,"config":536},{"href":165,"dataGaName":537,"dataGaLocation":465},"value stream management",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":465},"/fr-fr/solutions/gitops/","gitops",{"text":176,"config":544},{"href":178,"dataGaName":179,"dataGaLocation":465},{"text":181,"config":546},{"href":183,"dataGaName":184,"dataGaLocation":465},{"text":186,"config":548},{"href":188,"dataGaName":189,"dataGaLocation":465},{"text":550,"config":551},"Formation",{"href":552,"dataGaName":553,"dataGaLocation":465},"/fr-fr/solutions/education/","education",{"text":555,"config":556},"Services financiers",{"href":557,"dataGaName":558,"dataGaLocation":465},"/fr-fr/solutions/finance/","financial services",{"title":196,"links":560},[561,563,565,567,570,572,575,577,579,581,583,585,587,589],{"text":208,"config":562},{"href":210,"dataGaName":211,"dataGaLocation":465},{"text":213,"config":564},{"href":215,"dataGaName":216,"dataGaLocation":465},{"text":218,"config":566},{"href":220,"dataGaName":221,"dataGaLocation":465},{"text":223,"config":568},{"href":225,"dataGaName":569,"dataGaLocation":465},"docs",{"text":246,"config":571},{"href":248,"dataGaName":249},{"text":573,"config":574},"Histoires de réussite client",{"href":243,"dataGaLocation":465},{"text":241,"config":576},{"href":243,"dataGaName":244,"dataGaLocation":465},{"text":251,"config":578},{"href":253,"dataGaName":254,"dataGaLocation":465},{"text":264,"config":580},{"href":266,"dataGaName":267,"dataGaLocation":465},{"text":256,"config":582},{"href":258,"dataGaName":259,"dataGaLocation":465},{"text":269,"config":584},{"href":271,"dataGaName":272,"dataGaLocation":465},{"text":274,"config":586},{"href":276,"dataGaName":277,"dataGaLocation":465},{"text":279,"config":588},{"href":281,"dataGaName":282,"dataGaLocation":465},{"text":284,"config":590},{"href":286,"dataGaName":287,"dataGaLocation":465},{"title":302,"links":592},[593,595,597,599,601,603,605,609,614,616,618,620],{"text":309,"config":594},{"href":311,"dataGaName":304,"dataGaLocation":465},{"text":314,"config":596},{"href":316,"dataGaName":317,"dataGaLocation":465},{"text":322,"config":598},{"href":324,"dataGaName":325,"dataGaLocation":465},{"text":327,"config":600},{"href":329,"dataGaName":330,"dataGaLocation":465},{"text":332,"config":602},{"href":334,"dataGaName":335,"dataGaLocation":465},{"text":337,"config":604},{"href":339,"dataGaName":340,"dataGaLocation":465},{"text":606,"config":607},"Sustainability",{"href":608,"dataGaName":606,"dataGaLocation":465},"/sustainability/",{"text":610,"config":611},"Diversité, inclusion et appartenance (DIB)",{"href":612,"dataGaName":613,"dataGaLocation":465},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":342,"config":615},{"href":344,"dataGaName":345,"dataGaLocation":465},{"text":352,"config":617},{"href":354,"dataGaName":355,"dataGaLocation":465},{"text":357,"config":619},{"href":359,"dataGaName":360,"dataGaLocation":465},{"text":621,"config":622},"Déclaration de transparence sur l'esclavage moderne",{"href":623,"dataGaName":624,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":362,"links":626},[627,630,632,634,639,644,649],{"text":628,"config":629},"Échanger avec un expert",{"href":40,"dataGaName":41,"dataGaLocation":465},{"text":371,"config":631},{"href":373,"dataGaName":374,"dataGaLocation":465},{"text":376,"config":633},{"href":378,"dataGaName":379,"dataGaLocation":465},{"text":635,"config":636},"Statut",{"href":637,"dataGaName":638,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":640,"config":641},"Conditions d'utilisation",{"href":642,"dataGaName":643},"/terms/","terms of use",{"text":645,"config":646},"Déclaration de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":465},"/fr-fr/privacy/","privacy statement",{"text":650,"config":651},"Préférences en matière de cookies",{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":15},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,661],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":465},{"text":659,"config":660},"Politique de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":465},{"text":650,"config":662},{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":15},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"featuredPost":668,"allPosts":696,"totalPages":793,"initialPosts":794},{"_path":669,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":678,"config":689,"_id":692,"_type":17,"title":693,"_source":19,"_file":694,"_stem":695,"_extension":22},"/fr-fr/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":671,"description":672,"ogTitle":671,"ogDescription":672,"noIndex":6,"ogImage":673,"ogUrl":674,"ogSiteName":675,"ogType":676,"canonicalUrls":674,"schema":677},"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","https://about.gitlab.com","article","\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":671,"description":672,"authors":679,"heroImage":673,"date":681,"body":682,"category":14,"tags":683},[680],"Dave Steer","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/).",[684,685,686,687,688],"developer survey","DevSecOps","AI/ML","security","news",{"slug":690,"featured":6,"template":691},"3-surprising-findings-from-our-2024-global-devsecops-survey","BlogPost","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",[697,723,746,769],{"_path":698,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":699,"content":705,"config":717,"_id":719,"_type":17,"title":720,"_source":19,"_file":721,"_stem":722,"_extension":22},"/fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":700,"description":701,"ogTitle":700,"ogDescription":701,"noIndex":6,"ogImage":702,"ogUrl":703,"ogSiteName":675,"ogType":676,"canonicalUrls":703,"schema":704},"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":700,"description":701,"authors":706,"heroImage":702,"date":710,"body":711,"category":14,"tags":712,"updatedDate":716},[707,708,709],"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",[713,714,715],"careers","contributors","inside GitLab","2024-08-08",{"slug":718,"featured":6,"template":691},"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":724,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":725,"content":731,"config":740,"_id":742,"_type":17,"title":743,"_source":19,"_file":744,"_stem":745,"_extension":22},"/fr-fr/blog/4-must-know-devops-principles",{"title":726,"description":727,"ogTitle":726,"ogDescription":727,"noIndex":6,"ogImage":728,"ogUrl":729,"ogSiteName":675,"ogType":676,"canonicalUrls":729,"schema":730},"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":726,"description":727,"authors":732,"heroImage":728,"date":734,"body":735,"category":14,"tags":736,"updatedDate":739},[733],"GitLab","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",[737,738,236],"DevOps","collaboration","2024-10-22",{"slug":741,"featured":6,"template":691},"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":747,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":748,"content":754,"config":763,"_id":765,"_type":17,"title":766,"_source":19,"_file":767,"_stem":768,"_extension":22},"/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":749,"description":750,"ogTitle":749,"ogDescription":750,"noIndex":6,"ogImage":751,"ogUrl":752,"ogSiteName":675,"ogType":676,"canonicalUrls":752,"schema":753},"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":749,"description":750,"authors":755,"heroImage":751,"date":757,"body":758,"category":14,"tags":759,"updatedDate":762},[756],"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",[760,761,737],"CI","CD","2024-10-17",{"slug":764,"featured":6,"template":691},"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":770,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":771,"content":777,"config":787,"_id":789,"_type":17,"title":790,"_source":19,"_file":791,"_stem":792,"_extension":22},"/fr-fr/blog/agile-pairing-sessions",{"ogTitle":772,"schema":773,"ogImage":774,"ogDescription":775,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":776,"title":772,"canonicalUrls":776,"description":775},"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":774,"body":778,"authors":779,"updatedDate":781,"date":782,"title":783,"tags":784,"description":775,"category":14},"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. \")",[780],"Suri Patel","2024-09-24","2019-08-20","Pair programming : coder en binôme pour progresser et améliorer sa productivité",[785,738,737,786],"agile","workflow",{"slug":788,"featured":6,"template":691},"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",1,[697,723,746,769],1758662345148]