[{"data":1,"prerenderedAt":804},["ShallowReactive",2],{"/fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab":3,"navigation-fr-fr":43,"banner-fr-fr":449,"footer-fr-fr":459,"blog-post-authors-fr-fr-Suzanne Selhorn|Susan Tacker|Diana Logan":669,"blog-related-posts-fr-fr-five-fast-facts-about-docs-as-code-at-gitlab":707,"assessment-promotions-fr-fr":755,"next-steps-fr-fr":795},{"id":4,"title":5,"authorSlugs":6,"body":10,"categorySlug":11,"config":12,"content":16,"description":10,"extension":31,"isFeatured":14,"meta":32,"navigation":33,"path":34,"publishedDate":24,"seo":35,"stem":39,"tagSlugs":40,"__hash__":42},"blogPosts/fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab",[7,8,9],"suzanne-selhorn","susan-tacker","diana-logan",null,"insights",{"slug":13,"featured":14,"template":15},"five-fast-facts-about-docs-as-code-at-gitlab",false,"BlogPost",{"title":17,"description":18,"authors":19,"heroImage":23,"date":24,"body":25,"category":11,"tags":26,"updatedDate":30},"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.",[20,21,22],"Suzanne Selhorn","Susan Tacker","Diana Logan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","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",[27,28,29],"careers","contributors","inside GitLab","2024-08-08","yml",{},true,"/fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":17,"description":18,"ogTitle":17,"ogDescription":18,"noIndex":14,"ogImage":23,"ogUrl":36,"ogSiteName":37,"ogType":38,"canonicalUrls":36},"https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab","https://about.gitlab.com","article","fr-fr/blog/five-fast-facts-about-docs-as-code-at-gitlab",[27,28,41],"inside-gitlab","A4MJb_0ANSvXvWd42udIqZTu_zvm8ZN4wX0Xb2OtA18",{"data":44},{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":375,"minimal":410,"duo":429,"pricingDeployment":439},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/fr-fr/","gitlab logo","header",{"text":51,"config":52},"Commencer un essai gratuit",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Contacter l'équipe commerciale",{"href":58,"dataGaName":59,"dataGaLocation":49},"/fr-fr/sales/","sales",{"text":61,"config":62},"Connexion",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,93,190,195,296,356],{"text":67,"config":68,"cards":70},"Plateforme",{"dataNavLevelOne":69},"platform",[71,77,85],{"title":67,"description":72,"link":73},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":74,"config":75},"Découvrir notre plateforme",{"href":76,"dataGaName":69,"dataGaLocation":49},"/fr-fr/platform/",{"title":78,"description":79,"link":80},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":81,"config":82},"Découvrir GitLab Duo",{"href":83,"dataGaName":84,"dataGaLocation":49},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":86,"description":87,"link":88},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":89,"config":90},"En savoir plus",{"href":91,"dataGaName":92,"dataGaLocation":49},"/fr-fr/why-gitlab/","why gitlab",{"text":94,"left":33,"config":95,"link":97,"lists":101,"footer":172},"Produit",{"dataNavLevelOne":96},"solutions",{"text":98,"config":99},"Voir toutes les solutions",{"href":100,"dataGaName":96,"dataGaLocation":49},"/fr-fr/solutions/",[102,127,150],{"title":103,"description":104,"link":105,"items":110},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":106},{"icon":107,"href":108,"dataGaName":109,"dataGaLocation":49},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[111,115,118,123],{"text":112,"config":113},"CI/CD",{"href":114,"dataGaLocation":49,"dataGaName":112},"/fr-fr/solutions/continuous-integration/",{"text":78,"config":116},{"href":83,"dataGaLocation":49,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"Gestion du code source",{"href":121,"dataGaLocation":49,"dataGaName":122},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Livraison de logiciels automatisée",{"href":108,"dataGaLocation":49,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":49,"icon":134},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Tests de sécurité des applications",{"href":132,"dataGaName":139,"dataGaLocation":49},"Application security testing",{"text":141,"config":142},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":143,"dataGaLocation":49,"dataGaName":144},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Conformité logicielle",{"href":148,"dataGaName":149,"dataGaLocation":49},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":151,"link":152,"items":157},"Mesures",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":49},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Visibilité et mesures",{"href":155,"dataGaLocation":49,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Gestion de la chaîne de valeur",{"href":165,"dataGaLocation":49,"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":49,"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":49,"dataGaName":179},"/fr-fr/enterprise/","enterprise",{"text":181,"config":182},"PME",{"href":183,"dataGaLocation":49,"dataGaName":184},"/fr-fr/small-business/","small business",{"text":186,"config":187},"Secteur public",{"href":188,"dataGaLocation":49,"dataGaName":189},"/fr-fr/solutions/public-sector/","public sector",{"text":191,"config":192},"Tarifs",{"href":193,"dataGaName":194,"dataGaLocation":49,"dataNavLevelOne":194},"/fr-fr/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":283},"Ressources",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Afficher toutes les ressources",{"href":202,"dataGaName":198,"dataGaLocation":49},"/fr-fr/resources/",[204,237,255],{"title":205,"items":206},"Premiers pas",[207,212,217,222,227,232],{"text":208,"config":209},"Installation",{"href":210,"dataGaName":211,"dataGaLocation":49},"/fr-fr/install/","install",{"text":213,"config":214},"Guides de démarrage",{"href":215,"dataGaName":216,"dataGaLocation":49},"/fr-fr/get-started/","quick setup checklists",{"text":218,"config":219},"Apprentissage",{"href":220,"dataGaLocation":49,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Documentation sur le produit",{"href":225,"dataGaName":226,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Vidéos sur les bonnes pratiques",{"href":230,"dataGaName":231,"dataGaLocation":49},"/fr-fr/getting-started-videos/","best practice videos",{"text":233,"config":234},"Intégrations",{"href":235,"dataGaName":236,"dataGaLocation":49},"/fr-fr/integrations/","integrations",{"title":238,"items":239},"Découvrir",[240,245,250],{"text":241,"config":242},"Témoignages clients",{"href":243,"dataGaName":244,"dataGaLocation":49},"/fr-fr/customers/","customer success stories",{"text":246,"config":247},"Blog",{"href":248,"dataGaName":249,"dataGaLocation":49},"/fr-fr/blog/","blog",{"text":251,"config":252},"Travail à distance",{"href":253,"dataGaName":254,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":256,"items":257},"Connecter",[258,263,268,273,278],{"text":259,"config":260},"Services GitLab",{"href":261,"dataGaName":262,"dataGaLocation":49},"/fr-fr/services/","services",{"text":264,"config":265},"Communauté",{"href":266,"dataGaName":267,"dataGaLocation":49},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Événements",{"href":276,"dataGaName":277,"dataGaLocation":49},"/events/","events",{"text":279,"config":280},"Partenaires",{"href":281,"dataGaName":282,"dataGaLocation":49},"/fr-fr/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":288,"config":289},"carte promo The Source",{"src":290},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":292,"config":293},"Lire les articles les plus récents",{"href":294,"dataGaName":295,"dataGaLocation":49},"/fr-fr/the-source/","the source",{"text":297,"config":298,"lists":300},"Société",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"À propos",{"href":306,"dataGaName":307,"dataGaLocation":49},"/fr-fr/company/","about",{"text":309,"config":310,"footerGa":313},"Carrières",{"href":311,"dataGaName":312,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":49},{"text":317,"config":318},"Leadership",{"href":319,"dataGaName":320,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":322,"config":323},"Équipe",{"href":324,"dataGaName":325,"dataGaLocation":49},"/company/team/","team",{"text":327,"config":328},"Manuel",{"href":329,"dataGaName":330,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Relations avec les investisseurs",{"href":334,"dataGaName":335,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Centre de confiance",{"href":339,"dataGaName":340,"dataGaLocation":49},"/fr-fr/security/","trust center",{"text":342,"config":343},"Centre pour la transparence de l'IA",{"href":344,"dataGaName":345,"dataGaLocation":49},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":352,"config":353},"Presse",{"href":354,"dataGaName":355,"dataGaLocation":49},"/press/","press",{"text":357,"config":358,"lists":359},"Nous contacter",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":56,"config":363},{"href":58,"dataGaName":364,"dataGaLocation":49},"talk to sales",{"text":366,"config":367},"Portail d’assistance",{"href":368,"dataGaName":369,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":371,"config":372},"Portail clients GitLab",{"href":373,"dataGaName":374,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Fermer",{"text":378,"link":379},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":380,"config":381},"gitlab.com",{"href":63,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Suggestions",[387,389,394,396,401,406],{"text":78,"config":388},{"href":83,"dataGaName":78,"dataGaLocation":383},{"text":390,"config":391},"Suggestions de code (IA)",{"href":392,"dataGaName":393,"dataGaLocation":383},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":112,"config":395},{"href":114,"dataGaName":112,"dataGaLocation":383},{"text":397,"config":398},"GitLab sur AWS",{"href":399,"dataGaName":400,"dataGaLocation":383},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":402,"config":403},"GitLab sur Google Cloud ",{"href":404,"dataGaName":405,"dataGaLocation":383},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":407,"config":408},"Pourquoi utiliser GitLab ?",{"href":91,"dataGaName":409,"dataGaLocation":383},"Why GitLab?",{"freeTrial":411,"mobileIcon":416,"desktopIcon":421,"secondaryButton":424},{"text":412,"config":413},"Commencer votre essai gratuit",{"href":414,"dataGaName":54,"dataGaLocation":415},"https://gitlab.com/-/trials/new/","nav",{"altText":417,"config":418},"Icône GitLab",{"src":419,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":425,"config":426},"Commencer",{"href":427,"dataGaName":428,"dataGaLocation":415},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/compare/gitlab-vs-github/","get started",{"freeTrial":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"En savoir plus sur GitLab Duo",{"href":433,"dataGaName":434,"dataGaLocation":415},"/fr-fr/gitlab-duo/","gitlab duo",{"altText":417,"config":436},{"src":419,"dataGaName":420,"dataGaLocation":415},{"altText":417,"config":438},{"src":423,"dataGaName":420,"dataGaLocation":415},{"freeTrial":440,"mobileIcon":445,"desktopIcon":447},{"text":441,"config":442},"Retour aux tarifs",{"href":193,"dataGaName":443,"dataGaLocation":415,"icon":444},"back to pricing","GoBack",{"altText":417,"config":446},{"src":419,"dataGaName":420,"dataGaLocation":415},{"altText":417,"config":448},{"src":423,"dataGaName":420,"dataGaLocation":415},{"title":450,"button":451,"config":456},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":452,"config":453},"Regarder GitLab Transcend maintenant",{"href":454,"dataGaName":455,"dataGaLocation":49},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":457,"icon":458},"release","AiStar",{"data":460},{"text":461,"source":462,"edit":468,"contribute":473,"config":478,"items":483,"minimal":660},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":463,"config":464},"Afficher le code source de la page",{"href":465,"dataGaName":466,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":469,"config":470},"Modifier cette page",{"href":471,"dataGaName":472,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":474,"config":475},"Veuillez contribuer",{"href":476,"dataGaName":477,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":479,"facebook":480,"youtube":481,"linkedin":482},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[484,507,561,593,628],{"title":67,"links":485,"subMenu":490},[486],{"text":487,"config":488},"Plateforme DevSecOps",{"href":76,"dataGaName":489,"dataGaLocation":467},"devsecops platform",[491],{"title":191,"links":492},[493,497,502],{"text":494,"config":495},"Voir les forfaits",{"href":193,"dataGaName":496,"dataGaLocation":467},"view plans",{"text":498,"config":499},"Pourquoi choisir GitLab Premium ?",{"href":500,"dataGaName":501,"dataGaLocation":467},"/fr-fr/pricing/premium/","why premium",{"text":503,"config":504},"Pourquoi choisir GitLab Ultimate ?",{"href":505,"dataGaName":506,"dataGaLocation":467},"/fr-fr/pricing/ultimate/","why ultimate",{"title":508,"links":509},"Solutions",[510,515,518,520,525,530,534,537,540,545,547,549,551,556],{"text":511,"config":512},"Transformation digitale",{"href":513,"dataGaName":514,"dataGaLocation":467},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":516,"config":517},"Sécurité et conformité",{"href":132,"dataGaName":139,"dataGaLocation":467},{"text":124,"config":519},{"href":108,"dataGaName":109,"dataGaLocation":467},{"text":521,"config":522},"Développement agile",{"href":523,"dataGaName":524,"dataGaLocation":467},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":526,"config":527},"Transformation cloud",{"href":528,"dataGaName":529,"dataGaLocation":467},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":531,"config":532},"SCM",{"href":121,"dataGaName":533,"dataGaLocation":467},"source code management",{"text":112,"config":535},{"href":114,"dataGaName":536,"dataGaLocation":467},"continuous integration & delivery",{"text":163,"config":538},{"href":165,"dataGaName":539,"dataGaLocation":467},"value stream management",{"text":541,"config":542},"GitOps",{"href":543,"dataGaName":544,"dataGaLocation":467},"/fr-fr/solutions/gitops/","gitops",{"text":176,"config":546},{"href":178,"dataGaName":179,"dataGaLocation":467},{"text":181,"config":548},{"href":183,"dataGaName":184,"dataGaLocation":467},{"text":186,"config":550},{"href":188,"dataGaName":189,"dataGaLocation":467},{"text":552,"config":553},"Formation",{"href":554,"dataGaName":555,"dataGaLocation":467},"/fr-fr/solutions/education/","education",{"text":557,"config":558},"Services financiers",{"href":559,"dataGaName":560,"dataGaLocation":467},"/fr-fr/solutions/finance/","financial services",{"title":196,"links":562},[563,565,568,570,573,575,578,581,583,585,587,589,591],{"text":208,"config":564},{"href":210,"dataGaName":211,"dataGaLocation":467},{"text":566,"config":567},"Guides de démarrage rapide",{"href":215,"dataGaName":216,"dataGaLocation":467},{"text":218,"config":569},{"href":220,"dataGaName":221,"dataGaLocation":467},{"text":223,"config":571},{"href":225,"dataGaName":572,"dataGaLocation":467},"docs",{"text":246,"config":574},{"href":248,"dataGaName":249},{"text":576,"config":577},"Histoires de réussite client",{"href":243,"dataGaLocation":467},{"text":579,"config":580},"Histoires de succès client",{"href":243,"dataGaName":244,"dataGaLocation":467},{"text":251,"config":582},{"href":253,"dataGaName":254,"dataGaLocation":467},{"text":259,"config":584},{"href":261,"dataGaName":262,"dataGaLocation":467},{"text":264,"config":586},{"href":266,"dataGaName":267,"dataGaLocation":467},{"text":269,"config":588},{"href":271,"dataGaName":272,"dataGaLocation":467},{"text":274,"config":590},{"href":276,"dataGaName":277,"dataGaLocation":467},{"text":279,"config":592},{"href":281,"dataGaName":282,"dataGaLocation":467},{"title":297,"links":594},[595,597,600,602,604,606,608,612,617,619,621,623],{"text":304,"config":596},{"href":306,"dataGaName":299,"dataGaLocation":467},{"text":598,"config":599},"Emplois",{"href":311,"dataGaName":312,"dataGaLocation":467},{"text":317,"config":601},{"href":319,"dataGaName":320,"dataGaLocation":467},{"text":322,"config":603},{"href":324,"dataGaName":325,"dataGaLocation":467},{"text":327,"config":605},{"href":329,"dataGaName":330,"dataGaLocation":467},{"text":332,"config":607},{"href":334,"dataGaName":335,"dataGaLocation":467},{"text":609,"config":610},"Sustainability",{"href":611,"dataGaName":609,"dataGaLocation":467},"/sustainability/",{"text":613,"config":614},"Diversité, inclusion et appartenance (DIB)",{"href":615,"dataGaName":616,"dataGaLocation":467},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":618},{"href":339,"dataGaName":340,"dataGaLocation":467},{"text":347,"config":620},{"href":349,"dataGaName":350,"dataGaLocation":467},{"text":352,"config":622},{"href":354,"dataGaName":355,"dataGaLocation":467},{"text":624,"config":625},"Déclaration de transparence sur l'esclavage moderne",{"href":626,"dataGaName":627,"dataGaLocation":467},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":357,"links":629},[630,633,638,640,645,650,655],{"text":631,"config":632},"Échanger avec un expert",{"href":58,"dataGaName":59,"dataGaLocation":467},{"text":634,"config":635},"Aide",{"href":636,"dataGaName":637,"dataGaLocation":467},"/support/","get help",{"text":371,"config":639},{"href":373,"dataGaName":374,"dataGaLocation":467},{"text":641,"config":642},"Statut",{"href":643,"dataGaName":644,"dataGaLocation":467},"https://status.gitlab.com/","status",{"text":646,"config":647},"Conditions d'utilisation",{"href":648,"dataGaName":649},"/terms/","terms of use",{"text":651,"config":652},"Déclaration de confidentialité",{"href":653,"dataGaName":654,"dataGaLocation":467},"/fr-fr/privacy/","privacy statement",{"text":656,"config":657},"Préférences en matière de cookies",{"dataGaName":658,"dataGaLocation":467,"id":659,"isOneTrustButton":33},"cookie preferences","ot-sdk-btn",{"items":661},[662,664,667],{"text":646,"config":663},{"href":648,"dataGaName":649,"dataGaLocation":467},{"text":665,"config":666},"Politique de confidentialité",{"href":653,"dataGaName":654,"dataGaLocation":467},{"text":656,"config":668},{"dataGaName":658,"dataGaLocation":467,"id":659,"isOneTrustButton":33},[670,683,695],{"id":671,"title":20,"body":10,"config":672,"content":674,"description":10,"extension":31,"meta":678,"navigation":33,"path":679,"seo":680,"stem":681,"__hash__":682},"blogAuthors/en-us/blog/authors/suzanne-selhorn.yml",{"template":673},"BlogAuthor",{"name":20,"config":675},{"headshot":676,"ctfId":677},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755616156/vboecuoyo8tjfdis7c5a.jpg","6SK0DpWNK5NmfLyn2vWMPI",{},"/en-us/blog/authors/suzanne-selhorn",{},"en-us/blog/authors/suzanne-selhorn","CiU5TOoNLo7BlyHAPSbAR41rLuSx950NfJfaPG1rjZI",{"id":684,"title":21,"body":10,"config":685,"content":686,"description":10,"extension":31,"meta":690,"navigation":33,"path":691,"seo":692,"stem":693,"__hash__":694},"blogAuthors/en-us/blog/authors/susan-tacker.yml",{"template":673},{"name":21,"config":687},{"headshot":688,"ctfId":689},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660253/Blog/Author%20Headshots/susantacker-headshot.jpg","6uxN75wAjT3afaKtVlr9GM",{},"/en-us/blog/authors/susan-tacker",{},"en-us/blog/authors/susan-tacker","h7vgK-KMZACM5px7XT9CQ_bYRNV9VtohEWM2y-5eA7o",{"id":696,"title":22,"body":10,"config":697,"content":698,"description":10,"extension":31,"meta":702,"navigation":33,"path":703,"seo":704,"stem":705,"__hash__":706},"blogAuthors/en-us/blog/authors/diana-logan.yml",{"template":673},{"name":22,"config":699},{"headshot":700,"ctfId":701},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6poIwhQe6W9ysm5rBuSPXX",{},"/en-us/blog/authors/diana-logan",{},"en-us/blog/authors/diana-logan","abhZHI7covkEFaBG5GwqnR-muafYHLwlFfFWAEoEzqA",[708,724,741],{"content":709,"config":722},{"heroImage":710,"body":711,"authors":712,"updatedDate":714,"date":715,"title":716,"tags":717,"description":721,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1756989645/fojzxakmfdea6jfqjkrl.png","L'intégration continue et la livraison continue (CI/CD) sont au cœur de toute pratique DevSecOps réussie. Elles permettent aux équipes d'automatiser le build, les tests et le déploiement du code tout en intégrant la sécurité dès les premières étapes du développement.\n\nDans cet article, découvrez les meilleures pratiques CI/CD à connaître pour accélérer la livraison de logiciels, réduire les risques et améliorer la qualité logicielle.\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 ?\") est à la fois un processus technologique, un état d'esprit et une suite d'étapes. En termes simples, l'**intégration continue (CI)** permet aux [équipes DevSecOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Equipes DevOps\") d'optimiser le développement du code grâce à l'automatisation. Elle simplifie les builds logiciels et l'intégration du code source, permet le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") et favorise une meilleure collaboration entre les équipes.\n\nLà où la l'intégration continue (CI) s'arrête, la **[livraison continue (CD)](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que le livraison continue ?\")** prend le relais avec des tests et des déploiements automatisés. La livraison continue réduit considérablement le travail manuel des équipes Ops, tout en permettant de **[réduire la chaîne d'outils](https://about.gitlab.com/fr-fr/the-source/platform/devops-teams-want-to-shake-off-diy-toolchains-a-platform-is-the-answer/ \"Chaîne d’outils\")** nécessaires à la gestion du cycle de développement logiciel.\n\nEnsemble, la CI et la CD forment un **pipeline d'intégration et de livraison continues**, orchestré pour automatiser les étapes de développement, du build du code à son déploiement en production.\n\nEn intégrant des scans de sécurité et des contrôles de conformité en amont du pipeline, le CI/CD met en œuvre une approche « shift-left » de la sécurité où les problèmes sont identifiés et corrigés en amont avant d'atteindre l’environnement de production.\n\n> **[→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement et découvrez toute la puissance du CI/CD intégré à une plateforme DevSecOps complète.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**\n\n## Les 10 meilleures pratiques CI/CD\n\n### 1. Utilisez une plateforme DevSecOps unifiée\n\nRegroupez vos outils CI/CD au sein d'une seule et même plateforme afin de réduire les coûts de maintenance, limiter les changements de contexte et renforcer la collaboration entre les équipes. Moins il y a d'outils, moins il y a de complexité d'intégration, et meilleure est l'expérience pour les équipes chargées du développement, de la sécurité et des opérations.\n\n### 2. Automatisez tout\n\nOptimisez continuellement votre pipeline CI/CD pour atteindre un état d'« automatisation continue ». Cette automatisation inclut les **tests automatisés**, les scans de sécurité, le déploiement et le provisionnement de l'infrastructure. Plus vos processus sont automatisés, plus vos livraisons sont rapides, cohérentes et fiables.\n\n### 3. Échouez vite et souvent \n\nLes équipes de développement doivent être informées immédiatement lorsqu'un commit provoque une erreur. Corriger le code pendant que le problème est encore frais dans leur esprit limite le changement de contexte, tout en améliorant la qualité du code. Cette approche contribue aussi à la satisfaction et à la productivité des équipes DevSecOps.\n\n### 4. Validez fréquemment \n\nDes commits réguliers et de petite taille facilitent la revue, les tests et le déploiement du code. Ces changements incrémentaux limitent les risques et accélèrent les livraisons.\n\n### 5. Adoptez une approche « shift-left »\n\nLe CI/CD offre l'opportunité d'intégrer la sécurité très tôt dans le développement logiciel. En déplaçant la sécurité plus en amont, les failles sont détectées avant la mise en production, réduisant ainsi le coût et l'impact des correctifs.\n\n### 6. Exploitez l'IA pour diagnostiquer les pipelines en échec\n\nLes [outils alimentés par l'intelligence artificielle](https://about.gitlab.com/fr-fr/topics/devops/the-role-of-ai-in-devops/) permettent de diagnostiquer automatiquement les pipelines en échec, d'identifier leur cause et de suggérer des correctifs. Cette approche réduit considérablement le temps de résolution de plusieurs heures à quelques minutes tout en libérant les équipes de tâches répétitives.\n\n### 7. Décorrélez déploiement et release grâce aux feature flags\n\nLes feature flags permettent de déployer du code en production sans exposer immédiatement les nouvelles fonctionnalités aux utilisateurs. Cette approche sécurise les déploiements, facilite les tests progressifs et rend les retours en arrière instantanés en cas de problème.\n\n### 8. Monitorez tout\n\nMettez en place une surveillance complète couvrant les métriques applicatives, les logs et les indicateurs de performance. Des alertes bien configurées, à la fois sur les seuils techniques et métier, permettent d'anticiper les anomalies et d'assurer la stabilité du service.\n\n### 9. Maintenez le pipeline en tant que code\n\nStockez la configuration de votre pipeline CI/CD dans le même système de contrôle de version que votre application. Chaque modification est ainsi suivie, révisable et réversible. \n\n### 10. Mettez en place des boucles de rétroaction continues\n\nLe CI/CD n'est pas un processus figé. Veillez à ce que toutes les équipes puissent facilement recevoir et apporter des retours. Les retours issus de la supervision, des alertes ou des validations post-déploiement alimentent une amélioration continue du pipeline.\n\n## Les meilleures pratiques en matière de livraison continue\n\nLa livraison continue mérite à elle seule une attention particulière : si l'intégration continue fait souvent la une, c'est bien la livraison continue qui concrétise la promesse du [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") : livrer plus vite et plus souvent.\n\nVoici les meilleures pratiques à adopter en matière de livraison continue pour des déploiements fluides et fiables :\n\n* **Commencez par votre configuration actuelle.** Inutile d'attendre la plateforme parfaite. Analysez vos processus de déploiement existants, repérez les points de friction et automatisez d'abord les tâches manuelles les plus répétitives. L'amélioration continue commence toujours avec ce que vous avez déjà.\n\n* **Adoptez des stratégies de déploiement progressif.** Mettez en place des approches éprouvées comme le [déploiement bleu/vert](https://docs.gitlab.com/ci/environments/incremental_rollouts/#blue-green-deployment), le [déploiement canari](https://docs.gitlab.com/user/project/canary_deployments/) ou les [feature flags](https://docs.gitlab.com/operations/feature_flags/). Ces méthodes réduisent considérablement les risques et facilitent les retours en arrière rapides en cas d'incident.\n\n* **Assurez la cohérence entre vos environnements.** Vos environnements de développement, de préproduction et de production doivent être les plus similaires possible. L'[Infrastructure as Code (IaC)](https://about.gitlab.com/fr-fr/topics/gitops/infrastructure-as-code/ \"Infrastructure as Code\") vous aidera à éliminer les dérives de configuration.\n\n* **Automatisez la validation après chaque déploiement.** Mettez en place des smoke tests automatisés et des états de service automatiques pour vérifier instantanément la stabilité du système après une mise en production. Si une validation échoue, le pipeline doit pouvoir déclencher automatiquement un retour à la version précédente.\n\n* **Mettez en place une supervision complète.** Suivez à la fois les indicateurs techniques (temps de réponse, taux d'erreur) et les indicateurs métiers (satisfaction, engagement, conversion). La détection précoce des anomalies est la clé d'une production stable.\n\n* **Adoptez le déploiement sans interruption.** Concevez vos applications et votre processus de déploiement de manière à gérer les mises à jour sans temps d'arrêt. Le « zéro temps d'arrêt » doit être un objectif dès la conception.\n\n* **Simplifiez les retours à la version précédente.** Le retour en arrière doit être instantané. Testez vos processus régulièrement et assurez-vous qu'un retour complet puisse être exécuté en un clic.\n\n* **Dissociez déploiement et mise en production.** Grâce aux feature flags, vous pouvez déployer du code sans exposer immédiatement les nouvelles fonctionnalités. Cela vous permet de tester en conditions réelles tout en limitant les risques pour les utilisateurs finaux.\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 optimiser son pipeline CI/CD ?\n\nLe [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") est la colonne vertébrale du développement moderne. C’est une série d'étapes automatisées qui achemine le code du développement à la mise en production. Un pipeline type comprend les étapes suivantes : **build, tests, scans de sécurité, déploiement et supervision**. Ces étapes peuvent être réalisées manuellement, mais c'est leur automatisation qui décuple la rapidité et la fiabilité du processus.\n\n### Optimisez les performances du pipeline\n\n- Utilisez la [mise en cache des builds](https://docs.gitlab.com/ci/caching/) pour éviter de recompiler les éléments inchangés.\n- Définissez des [règles conditionnelles](https://docs.gitlab.com/ci/jobs/job_rules/#rules-examples) pour ignorer les étapes inutiles lorsque le code n'a pas été modifié.\n- Optimisez les images [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") avec des builds multi-étapes et des images de base plus légères.\n\n### Améliorez la visibilité du pipeline\n\n- Ajoutez un suivi de la durée du pipeline pour identifier les goulots d'étranglement.\n- Mettez en place une journalisation détaillée et une collecte d’artefacts pour faciliter le diagnostic.\n- Appuyez-vous sur les [tableaux de bord de GitLab](https://docs.gitlab.com/user/operations_dashboard/) pour visualiser les taux de réussite et les tendances en matière de performances.\n\n### Optimisez l'efficacité des ressources\n\n- Ajustez la taille de vos runners selon leur charge réelle.\n- Exploitez les instances ponctuelles ou la [mise à l'échelle automatique](https://docs.gitlab.com/runner/runner_autoscale/) pour réduire les coûts d'exécution.\n- Nettoyez les ressources temporaires et les artefacts après l'achèvement du pipeline.\n\n### Anticipez la croissance de l'équipe\n\n- Utilisez des [composants de pipeline](https://docs.gitlab.com/ci/components/) pour uniformiser les pratiques entre projets. Utilisez des environnements dynamiques qui se créent et se suppriment automatiquement.\n- Configurez des workflows d'[approbation de déploiement](https://docs.gitlab.com/ci/environments/deployment_approvals/) avant toute mise en production.\n\n##  Stratégie de déploiement CI/CD\n\nL'objectif du CI/CD est simple : livrer un logiciel plus performant, plus rapidement, et en continu. Les organisations qui adoptent cette approche gagnent en agilité, en productivité et en qualité. Encore faut-il définir une stratégie adaptée à votre contexte.\n\nVoici quelques leviers pour réussir vos déploiements :\n\n* **Privilégiez les petits changements.** Le déploiement fréquent de mises à jour incrémentales facilite les tests, les revues et les retours en arrière. Cela réduit les risques et améliore la stabilité des logiciels. \n\n* **Montez progressivement en puissance.** Démarrez sur des projets à faible impact pour affiner vos processus avant de vous attaquer aux systèmes critiques.\n\n* **Automatisez les retours en arrière.** Définissez des seuils d'alerte (taux d'erreur, indicateurs de performance, état des services) qui déclenchent un retour à la version précédente automatique.\n\n* **Répétez vos déploiements.** Testez régulièrement votre processus de déploiement dans des environnements de préproduction qui reflètent la production.\n\n* **Planifiez vos fenêtres de déploiement.** Commencez par des périodes de faible activité avant de passer à un déploiement continu.\n\n* **Mesurez l'impact de chaque déploiement.** Suivez les performances techniques et les indicateurs business après chaque déploiement pour évaluer la réussite.\n\n## Comment mesurer la performance de votre CI/CD ?\n\nIl est impossible d'améliorer ce qu'on ne mesure pas. Les équipes DevSecOps s'appuient sur des indicateurs pour évaluer la performance et détecter les marges de progrès.\n\n### Les 4 métriques DORA\n\nLes organisations les plus performantes mesurent systématiquement ces quatre indicateurs issus du [framework DORA](https://docs.gitlab.com/user/analytics/dora_metrics/) :\n\n* **Fréquence de déploiement** : nombre de mises en production réussies sur une période donnée. Les organisations d'élite déploient jusqu'à plusieurs fois par jour.\n* **Délai d'exécution des modifications** : temps écoulé entre le le premier commit et le déploiement en production. Objectif cible : passer sous la barre des 24 heures.\n* **Taux d'échec des modifications** : pourcentage de déploiements provoquant des incidents en production et nécessitant des correctifs urgents ou des retours en arrière. Un taux inférieur à 15 % est signe d'un pipeline mature.\n* **Temps moyen de restauration** : rapidité de résolution après incident. Les meilleurs rétablissent un service complet en moins d'une heure. Une restauration rapide nécessite une supervision robuste et des capacités de retour en arrière automatisées.\n\n### Les autres KPI à suivre\n\n* **Coûts d'infrastructure** : le CI/CD cloud-native peut entraîner des dépenses importantes s'il n'est pas géré correctement. Les pratiques qui réduisent les temps de build et optimisent l'utilisation des ressources ont un impact direct sur les coûts opérationnels.\n* **Satisfaction et rétention des équipes** : les développeurs satisfaits restent fidèles à l'entreprise. Lorsque les équipes collaborent efficacement sur les pratiques CI/CD, la fidélisation suit. Un pipeline fluide réduit ainsi le stress, améliore la collaboration et fidélise les équipes de développement.\n\n### Impact business immédiat\n\nCes indicateurs techniques se traduisent par des gains concrets :\n\n* Des cycles de livraison plus courts améliorent les délais de mise sur le marché et la compétitivité.\n* Un faible taux d'échec réduit les coûts d'assistance et les interruptions.\n* Un temps moyen de réparation rapide garantit la continuité des services et la satisfaction client.\n\n> *Les équipes hautement performantes en matière de CI/CD obtiennent systématiquement de meilleurs résultats commerciaux, améliorent leur productivité, et ont une plus grande capacité d'innovation.* — [Étude DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report?hl=en)\n\n## Quels sont les avantages d'une approche CI/CD maîtrisée ?\n\nL'application rigoureuse des bonnes pratiques CI/CD profite à tous : utilisateurs, développeurs et dirigeants, en favorisant un développement logiciel plus fluide, collaboratif et orienté qualité.\n\n* **Des fonctionnalités livrées plus vite** : cycles courts, releases fréquentes et corrections rapides.\n* **Une qualité logicielle renforcée** : moins de bugs, moins de stress, plus de stabilité.\n* **Une meilleure réactivité client** : intégration immédiate des retours utilisateurs.\n* **Un service plus fiable** : supervision continue et retours à la version précédente automatisés.\n* **Un environnement propice à l'innovation** : moins de tâches répétitives, plus de création de valeur.\n* **Des équipes plus engagées** : moins d'incidents, plus de temps pour le développement et la collaboration.\n\n## Comment déployer le CI/CD dans votre organisation ?\n\nAvant de vous lancer, clarifiez les objectifs stratégiques et leur impact sur votre cycle de développement logiciel. Impliquez vos équipes dès la phase de conception de votre approche CI/CD : elles seront les premières concernées par ce changement.\n\n* Évaluez les solutions adaptées à vos besoins (infrastructure, sécurité, gouvernance).\n* Testez les outils via des essais gratuits pour valider leur intégration dans votre pile existante.\n* Avancez progressivement, en automatisant étape par étape.\n* Suivez vos métriques clés pour mesurer les gains de performance et d'efficacité.\n\n> **[→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement et découvrez toute la puissance du CI/CD intégré à une plateforme DevSecOps complète.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**",[713],"Valerie Silverthorne","","2026-01-23","Quelles sont les meilleures pratiques CI/CD à connaître ?",[718,719,720],"CI","CD","DevOps","Dans cet article, nous vous partageons tous nos conseils pour mettre en œuvre une approche CI/CD réussie.",{"slug":723,"featured":14,"template":15},"how-to-keep-up-with-ci-cd-best-practices",{"content":725,"config":739},{"title":726,"description":727,"authors":728,"heroImage":730,"date":731,"body":732,"category":11,"tags":733},"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.",[729],"Dave Steer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751993603/Blog/Hero%20Images/fy25-global-devsecops-report-blog-image.png","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/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 ».\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.\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\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/developer-survey/).",[734,735,736,737,738],"developer survey","DevSecOps","AI/ML","security","news",{"slug":740,"featured":14,"template":15},"3-surprising-findings-from-our-2024-global-devsecops-survey",{"content":742,"config":753},{"title":743,"description":744,"authors":745,"heroImage":747,"date":748,"body":749,"category":11,"tags":750,"updatedDate":752},"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é.",[746],"GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665982/Blog/Hero%20Images/jpvalery-9pLx0sLli4unsplash.jpg","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",[720,751,236],"collaboration","2024-10-22",{"slug":754,"featured":14,"template":15},"4-must-know-devops-principles",{"promotions":756},[757,771,784],{"id":758,"categories":759,"header":761,"text":762,"button":763,"image":768},"ai-modernization",[760],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":764,"config":765},"Get your AI maturity score",{"href":766,"dataGaName":767,"dataGaLocation":249},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":769},{"src":770},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":772,"categories":773,"header":776,"text":762,"button":777,"image":781},"devops-modernization",[774,775],"product","devsecops","Are you just managing tools or shipping innovation?",{"text":778,"config":779},"Get your DevOps maturity score",{"href":780,"dataGaName":767,"dataGaLocation":249},"/assessments/devops-modernization-assessment/",{"config":782},{"src":783},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":785,"categories":786,"header":787,"text":762,"button":788,"image":792},"security-modernization",[737],"Are you trading speed for security?",{"text":789,"config":790},"Get your security maturity score",{"href":791,"dataGaName":767,"dataGaLocation":249},"/assessments/security-modernization-assessment/",{"config":793},{"src":794},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":796,"blurb":797,"button":798,"secondaryButton":802},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":51,"config":799},{"href":800,"dataGaName":54,"dataGaLocation":801},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":56,"config":803},{"href":58,"dataGaName":59,"dataGaLocation":801},1772652121077]