Dans 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.

Qu’est-ce que le CI/CD ?

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 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 et favorise une meilleure collaboration entre les équipes.

Là où la l'intégration continue (CI) s'arrête, la livraison continue (CD) 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 nécessaires à la gestion du cycle de développement logiciel.

Ensemble, 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.

En 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.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement et découvrez toute la puissance du CI/CD intégré à une plateforme DevSecOps complète.

Les 10 meilleures pratiques CI/CD

1. Utilisez une plateforme DevSecOps unifiée

Regroupez 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.

2. Automatisez tout

Optimisez 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.

3. Échouez vite et souvent

Les é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.

4. Validez fréquemment

Des 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.

5. Adoptez une approche « shift-left »

Le 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.

6. Exploitez l'IA pour diagnostiquer les pipelines en échec

Les outils alimentés par l'intelligence artificielle 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.

7. Décorrélez déploiement et release grâce aux feature flags

Les 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.

8. Monitorez tout

Mettez 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.

9. Maintenez le pipeline en tant que code

Stockez 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.

10. Mettez en place des boucles de rétroaction continues

Le 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.

Les meilleures pratiques en matière de livraison continue

La 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 : livrer plus vite et plus souvent.

Voici les meilleures pratiques à adopter en matière de livraison continue pour des déploiements fluides et fiables :

• 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à.
• Adoptez des stratégies de déploiement progressif. Mettez en place des approches éprouvées comme le déploiement bleu/vert, le déploiement canari ou les feature flags. Ces méthodes réduisent considérablement les risques et facilitent les retours en arrière rapides en cas d'incident.
• 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) vous aidera à éliminer les dérives de configuration.
• 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.
• 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.
• 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.
• 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.
• 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.

Tirez parti de tous les avantages de l'intégration et de la livraison continues avec la plateforme DevSecOps de GitLab.

Comment optimiser son pipeline CI/CD ?

Le 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.

Optimisez les performances du pipeline

• Utilisez la mise en cache des builds pour éviter de recompiler les éléments inchangés.
• Définissez des règles conditionnelles pour ignorer les étapes inutiles lorsque le code n'a pas été modifié.
• Optimisez les images Docker avec des builds multi-étapes et des images de base plus légères.

Améliorez la visibilité du pipeline

• Ajoutez un suivi de la durée du pipeline pour identifier les goulots d'étranglement.
• Mettez en place une journalisation détaillée et une collecte d’artefacts pour faciliter le diagnostic.
• Appuyez-vous sur les tableaux de bord de GitLab pour visualiser les taux de réussite et les tendances en matière de performances.

Optimisez l'efficacité des ressources

• Ajustez la taille de vos runners selon leur charge réelle.
• Exploitez les instances ponctuelles ou la mise à l'échelle automatique pour réduire les coûts d'exécution.
• Nettoyez les ressources temporaires et les artefacts après l'achèvement du pipeline.

Anticipez la croissance de l'équipe

• Utilisez des composants de pipeline pour uniformiser les pratiques entre projets. Utilisez des environnements dynamiques qui se créent et se suppriment automatiquement.
• Configurez des workflows d'approbation de déploiement avant toute mise en production.

Stratégie de déploiement CI/CD

L'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.

Voici quelques leviers pour réussir vos déploiements :

• 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.
• Montez progressivement en puissance. Démarrez sur des projets à faible impact pour affiner vos processus avant de vous attaquer aux systèmes critiques.
• 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.
• 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.
• Planifiez vos fenêtres de déploiement. Commencez par des périodes de faible activité avant de passer à un déploiement continu.
• 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.

Comment mesurer la performance de votre CI/CD ?

Il 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.

Les 4 métriques DORA

Les organisations les plus performantes mesurent systématiquement ces quatre indicateurs issus du framework DORA :

• 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.
• 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.
• 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.
• 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.

Les autres KPI à suivre

• 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.
• 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.

Impact business immédiat

Ces indicateurs techniques se traduisent par des gains concrets :

• Des cycles de livraison plus courts améliorent les délais de mise sur le marché et la compétitivité.
• Un faible taux d'échec réduit les coûts d'assistance et les interruptions.
• Un temps moyen de réparation rapide garantit la continuité des services et la satisfaction client.

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

Quels sont les avantages d'une approche CI/CD maîtrisée ?

L'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é.

• Des fonctionnalités livrées plus vite : cycles courts, releases fréquentes et corrections rapides.
• Une qualité logicielle renforcée : moins de bugs, moins de stress, plus de stabilité.
• Une meilleure réactivité client : intégration immédiate des retours utilisateurs.
• Un service plus fiable : supervision continue et retours à la version précédente automatisés.
• Un environnement propice à l'innovation : moins de tâches répétitives, plus de création de valeur.
• Des équipes plus engagées : moins d'incidents, plus de temps pour le développement et la collaboration.

Comment déployer le CI/CD dans votre organisation ?

Avant 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.

• Évaluez les solutions adaptées à vos besoins (infrastructure, sécurité, gouvernance).
• Testez les outils via des essais gratuits pour valider leur intégration dans votre pile existante.
• Avancez progressivement, en automatisant étape par étape.
• Suivez vos métriques clés pour mesurer les gains de performance et d'efficacité.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement et découvrez toute la puissance du CI/CD intégré à une plateforme DevSecOps complète.

🎯 Essayez GitLab Duo Agent Platform dès aujourd'hui !

Qu'est-ce qu'un agent ?

Les agents sont des partenaires de collaboration d'IA spécialisés au sein de GitLab Duo Agent Platform. Chaque type d'agent remplit des objectifs différents et s'exécute dans des contextes différents.

Types d'agents

Agents de base

Conçus et maintenus par GitLab, ces agents sont disponibles immédiatement sans aucune configuration requise.

La disponibilité des agents de base peut être gérée par les propriétaires d'espaces de nommage ou les administrateurs d'instance.

Commencez à interagir avec les agents de base en ouvrant GitLab Duo Agentic Chat dans l'IDE ou l'interface utilisateur Web.

L'agent GitLab Duo

Il s'agit de l'agent par défaut, votre partenaire de collaboration de développement polyvalent pour créer et modifier du code, ouvrir des merge requests, trier et mettre à jour des tickets et epics, et exécuter des workflows avec un contexte complet de la plateforme SDLC.

Exemples de prompts :

• « Explique-moi comment fonctionne le système d'authentification. »
• « Où se trouve la logique du profil utilisateur ? »
• « Comment dois-je implémenter la fonctionnalité X ? »

L'agent Planner

Il aide à la planification produit, à la décomposition des epics et à la création de tickets structurés.

Exemples de prompts :

• « Crée un epic pour le nouveau système de paiement avec des sous-tâches. »
• « Décompose le ticket #789 en tâches plus petites. »
• « Génère des critères d'acceptation pour cette fonctionnalité. »

En savoir plus sur l'agent Planner Agent.

L'agent Security Analyst

Il trie les vulnérabilités, identifie les faux positifs et hiérarchise les risques de sécurité.

Exemples de prompts :

• « Trie toutes les vulnérabilités détectées lors du dernier scan. »
• « Quels résultats SAST sont des faux positifs ? »
• « Hiérarchise les problèmes de sécurité en fonction du risque réel. »

En savoir plus sur l'agent Security Analyst Agent.

L'agent Data Analyst

ll interroge, visualise et met en évidence les données à travers la plateforme de GitLab en utilisant GitLab Query Language (GLQL) pour fournir des informations exploitables sur vos projets et équipes.

Exemples de prompts :

• « Combien de merge requests ont été créées au cours du dernier trimestre ? »
• « Montre-moi sur quoi chaque membre de l'équipe a travaillé ce mois-ci. »
• « Quelles sont les tendances en matière de délais de résolution des tickets ? »
• « Trouve tous les tickets ouverts avec le label 'bug' dans mon projet. »
• « Génère une requête GLQL pour compter les merge requests par auteur. »

En savoir plus sur l'agent Data Analyst Agent.

Les agents personnalisables

Créez vos propres agents adaptés aux workflows et standards spécifiques de votre équipe.

Cas d'usage courants

• Agent chargé du dépannage et du débogage : il débogue les bogues logiciels et les régressions, et analyse les échecs de déploiement.
• Agent chargé de la documentation : il maintient la documentation conformément à vos conventions.
• Assistant chargé de l'intégration des équipes : il aide les nouveaux membres de l'équipe à se familiariser avec les pratiques spécifiques à l'entreprise.
• Moniteur de conformité : il veille au respect des exigences réglementaires.
• Agent d'assistance localisé : il trie les tickets d'assistance dans une langue localisée, par exemple le français.

Regardez l'enregistrement de la présentation des cas d'utilisation de la plateforme Duo Agent lors du GitLab DACH Roadshow Vienna 2025 :

🎯 Essayez maintenant : démo interactive des agents personnalisables. Explorez comment créer et configurer des agents personnalisés.

Comment créer un agent personnalisé ?

Les agents personnalisés sont configurés via les paramètres de votre projet ou de votre groupe. Le composant clé est le prompt système, qui définit le comportement et l'expertise de votre agent.

Exemple de prompt système de l'agent personnalisé devops-debug-failures-agent :

You are an expert in Dev, Ops, DevOps, and SRE, and can debug code and runtime failures.

Your speciality is that you can correlate static SDLC data with runtime data from CI/CD pipelines, logs, and other tool calls necessary.

Expect that the user has advanced knowledge, but always provide commands and steps to reproduce your analysis so they can learn from you.

Start with a short summary and suggested actions, and then go into detail with thoughts, analysis, suggestions.

Think creative and consider unknown unknowns in your debug journey.

Options de visibilité :

• Privé : il est visible uniquement par les membres du projet de gestion (rôle Developeur et niveau supérieur). Ne peut pas être activé dans d'autres projets.
• Public : il peut être visible par tous et activable dans tout projet répondant aux prérequis. Il apparaît dans le catalogue d'IA.
  

Guide de configuration complet disponible dans la documentation.

Bonnes pratiques

Conseils pour le prompt système :

• Soyez précis sur le rôle et les responsabilités de l'agent.
• Définissez des standards de qualité et des contraintes clairs.
• Incluez des exemples de résultats attendus.
• Gardez les prompts concentrés sur une tâche principale.

Commencez progressivement :

• Commencez par des autorisations en lecture seule.
• Testez minutieusement avant d'accorder un accès en écriture.
• Recueillez les retours de l'équipe et itérez.

Les agents externes

Les agents externes s'exécutent en arrière-plan sur la plateforme GitLab lorsqu'ils sont déclenchés par des mentions (par exemple, @ai-codex) ou des assignations dans des tickets et des merge requests. Contrairement aux agents de base et aux agents personnalisables qui fonctionnent de manière interactive dans le chat, les agents externes s'exécutent de manière asynchrone, permettant une automatisation puissante avec des fournisseurs d'IA spécialisés.

Gestion des identifiants : à partir de la disponibilité générale de GitLab Duo Agent Platform, les identifiants de connexion gérés par GitLab seront utilisés pour prendre en charge les agents externes, évitant aux clients d'avoir à gérer et faire pivoter eux-mêmes les clés API.

Quand utiliser les agents externes ?

• Vous avez besoin d'un comportement d'IA agentique spécifique ou de LLM pour des tâches spécialisées.
• Vous souhaitez une automatisation déclenchée par des événements (et non un chat interactif).
• Vous devez respecter des exigences spécifiques en matière de conformité ou de résidence des données.

Pourquoi utiliser les agents externes ?

• Exploiter des modèles d'IA spécialisés : accédez à des fonctionnalités spécifiques à certains fournisseurs comme l'analyse de code de Claude Code ou la délégation de tâches d'OpenAI Codex.
• Respecter les exigences de conformité : conservez les données auprès de fournisseurs d'IA approuvés pour respecter les politiques réglementaires ou de sécurité.
• Tester différents fournisseurs : testez différents comportements d'IA agentique et de LLM afin de trouver celui qui convient le mieux à vos workflows.
• Accéder à des fonctionnalités uniques : utilisez des outils spécifiques à certains fournisseurs comme l'analyse de code de Claude Code ou la délégation de tâches d'OpenAI Codex.

Exemple concret

Une équipe de développement utilise OpenAI Codex comme agent externe pour la revue de code. Lorsque les développeurs créent des merge requests, ils assignent Codex comme relecteur. L'agent :

1. Analyse les modifications apportées au code dans la merge request.
2. Vérifie les bonnes pratiques et les problèmes de qualité du code.
3. Suggère des améliorations et des optimisations.
4. Publie des commentaires de revue détaillés avec des recommandations spécifiques.
5. Fournit des liens vers la documentation pertinente.

Tout cela se produit automatiquement en arrière-plan pendant que le développeur continue à travailler, avec les résultats publiés directement dans la merge request.

Agents externes pris en charge

Les intégrations suivantes ont été testées et sont disponibles :

• Anthropic Claude : génération, revue et analyse de code
• OpenAI Codex : assistance au code alimentée par GPT

Exemple d'utilisation :

@ai-codex Please implement this issue

Cela déclenche un job d'exécution de runner qui exécute l'outil IA externe et publie les résultats dans GitLab.

Configuration des agents externes

Pour obtenir des instructions de configuration complètes incluant les comptes de service, les déclencheurs et des exemples de configuration, consultez notre documentation sur les agents externes.

Personnalisation du comportement des agents avec AGENTS.md

Personnalisez le comportement des agents à l'aide des fichiers AGENTS.md suivant le standard agents.md. Pour en savoir plus, consultez la Partie 8 : personnalisation de GitLab Duo Agent Platform : règles de chat, prompts et workflows.

Choisir le type d'agent le mieux adapté à vos cas d'usage

Résumé

GitLab Duo Agent Platform offre les types d'agents suivants :

• Agent de base : des agents prêts à l'emploi pour les tâches courantes (Chat, Planner, Security Analyst, Data Analyst)
• Agent personnalisable : des agents spécifiques à l'équipe qui peuvent être créés avec des prompts et comportements personnalisés
• Agent externe : des agents intégrés avec des outils IA externes

Commencez avec les agents de base, créez des agents personnalisés pour répondre aux besoins spécifiques de votre équipe et explorez les agents externes lorsque vous avez besoin de fournisseurs d'IA spécialisés.

Article suivant : Partie 4 : comprendre les flows

Article précédent : Partie 2 : démarrer avec GitLab Duo Agentic Chat

Qu'est-ce que GitLab Duo Agentic Chat ?

GitLab Duo Agentic Chat est votre interface principale où vous pouvez interagir avec des agents d'IA tout au long de votre workflow de développement. Contrairement aux chatbots classiques de type questions-réponses qui se contentent de répondre à des requêtes, GitLab Duo Agentic Chat est un partenaire de collaboration d'IA autonome capable d'agir en votre nom : il peut créer et modifier du code, ouvrir des merge requests, trier et mettre à jour des tickets/epics et exécuter des workflows avec un contexte complet de la plateforme SDLC, le tout en vous informant à chaque étape.

🎯 Essayez GitLab Duo Agent Platform dès aujourd'hui !

Capacités clés :

• Opérations sur le code : création de fichiers, modification de code, ouverture de merge requests.
• Analyse de projet : consultation des tickets, epics, merge requests, commits Git, pipelines CI/CD, analyses (GLQL) et scans de sécurité.
• Tâches opérationnelles : hiérarchisation, mise à jour ou création de tickets et d'epics, résolution des vulnérabilités, génération de documentation et de tests, correction des pipelines CI/CD en échec.
• Conscience du contexte : mémorisation de l'historique des conversations, compréhension de l'architecture du projet, recherche dans le code source, le wiki et la documentation de GitLab.
• Extensibilité : intégration avec des services externes via Model Context Protocol (MCP).
• Prise en charge de plusieurs agents : utilisation d'agents spécialisés pour différentes tâches.

🎯 Découvrez une démo interactive de GitLab Duo Agentic Chat et explorez l'interface de chat ainsi que ses fonctionnalités.

Accéder à GitLab Duo Agentic Chat

Fonctionnalités du panneau de l'interface utilisateur Web

• Panneau réduit : icône visible dans le coin supérieur droit
• Panneau ouvert : barre latérale déployée (~400px de largeur)
• Panneau maximisé : extension pour afficher des réponses détaillées

Sélection du modèle

Les grands modèles de langage (LLM) excellent dans différentes tâches et exigences en matière de connaissances. Choisissez le modèle approprié en fonction de vos besoins.

Niveaux de configuration

• Niveau du groupe : défini par le propriétaire du groupe, s'applique à tous les utilisateurs
• Niveau de l'utilisateur : contrôle individuel lorsque le groupe l'autorise

Sélection de l'agent

Les agents sont des partenaires de collaboration d'IA spécialisés dans des tâches spécifiques. Basculez entre les agents selon vos besoins :

Sélection de l'agent

Comment changer d'agent

1. Ouvrez GitLab Duo Agentic Chat.
2. IDE : cliquez sur le menu déroulant de l'agent (sous l'onglet de sélection du modèle).
3. Interface Web : ouvrez un nouveau chat.
4. Sélectionnez l'agent dont vous avez besoin.

Cas d'utilisation courants

Gestion et hiérarchisation des tickets

Pour la gestion des tickets et les workflows de planification, utilisez l'agent Planner, un agent spécialisé conçu pour les tâches de gestion de produit.

Exemples de prompts :

• « Répertorie tous les tickets ouverts avec les labels “bogue” et “priorité élevée” créés au cours des 30 derniers jours. »
• « Crée un ticket pour l'implémentation de l'authentification utilisateur avec OAuth2, inclus les critères d'acceptation et les exigences techniques. »
• « Analyse le ticket #456 et suggère des tickets connexes qui pourraient avoir la même cause profonde. »
• « Décompose l'epic #123 en tâches plus petites et indique une estimation de la complexité. »

Analyse et résolution des vulnérabilités

Pour les workflows de sécurité, utilisez l'agent Security Analyst, un agent spécialisé conçu pour la gestion et la résolution des vulnérabilités.

Exemples de prompts :

• « Montre-moi toutes les vulnérabilités critiques dans le dernier scan de pipeline. »
• « Classe toutes les vulnérabilités du dernier scan de sécurité et identifie lesquelles sont des faux positifs. »
• « Explique la vulnérabilité #789 en termes simples et montre-moi où elle se situe dans le code. »
• « Quelle est la correction recommandée pour la vulnérabilité d'injection SQL dans le point d'entrée de recherche utilisateur ? »
• « Crée une merge request pour corriger la vulnérabilité XSS trouvée dans src/components/UserProfile.vue. »

Compréhension et documentation du code

Obtenez des réponses sur votre code source sans avoir à rechercher manuellement dans les fichiers avec l'agent GitLab Duo.

Exemples de prompts :

• « Comment fonctionne le flux d'authentification dans cette application ? »
• « Trouve tous les endroits où la fonction sendEmail est appelée. »
• « Explique ce que fait la méthode calculateDiscount dans src/pricing/calculator.ts. »
• « Génère la documentation pour les points de terminaison API dans src/api/routes/. »
• « Quels design patterns sont utilisés dans le répertoire src/services/ ? »

Intégration à un nouveau projet

Mettez-vous rapidement à la page en cas de nouveau projet afin de comprendre son architecture, sa configuration et ses dépendances avec l'agent GitLab Duo.

Exemples de prompts :

• « Donne-moi un aperçu de l'architecture de ce projet et de ses composants principaux. »
• « Où est défini le schéma de base de données ? »
• « Comment configurer mon environnement de développement local ? »
• « Quelles sont les dépendances principales et à quoi servent-elles ? »

Débogage et dépannage de pipeline

Identifiez et résolvez rapidement les problèmes dans votre code et vos pipelines CI/CD grâce à l'analyse assistée par l'IA avec l'agent GitLab Duo.

Exemples de prompts :

• « Pourquoi le pipeline CI/CD échoue-t-il à l'étape de test ? »
• « Analyse les logs d'erreur du job #12345 et suggère des corrections. »
• « Pourquoi le pipeline #9876 a-t-il échoué ? Montre-moi les logs d'erreur du job de déploiement qui a échoué. »
• « L'application plante lors du traitement de fichiers volumineux. Aide-moi à déboguer cela. »
• « Examine les commits récents qui pourraient avoir causé la régression de performance. »
• « Comment puis-je optimiser le temps de build de ce pipeline ? »
• « Crée un nouveau job CI/CD pour exécuter des scans de sécurité sur chaque merge request. »

Revue de code et amélioration de la qualité

Bénéficiez d'une assistance d'IA durant les revues de code pour détecter les problèmes et améliorer la qualité du code avec un agent personnalisé entraîné sur les standards de codage et les bonnes pratiques de votre équipe.

Exemples de prompts :

• « Examine la merge request !234 pour détecter les bogues potentiels et les problèmes de sécurité. »
• « Suggère des optimisations de performance pour les requêtes de base de données dans cette merge request. »
• « Vérifie si la merge request !456 respecte nos standards de codage et nos bonnes pratiques. »
• « Identifie tout problème d'accessibilité dans les nouveaux composants d'interface. »

Implémentation de fonctionnalités

Accélérez le développement en générant du code, des tests et de la documentation avec l'agent GitLab Duo.

Exemples de prompts :

• « Crée un point de terminaison d'API REST pour l'inscription utilisateur avec validation. »
• « Génère des tests unitaires pour la classe OrderService avec une couverture de 80 %. »
• « Implémente la pagination pour la page de liste des produits. »
• « Ajoute la gestion d'erreurs et la journalisation à la fonctionnalité de téléchargement de fichiers. »

Refactorisation et amélioration du code

Modernisez et améliorez le code existant avec les conseils de l'IA en utilisant l'agent GitLab Duo.

Exemples de prompts :

• « Refactorise UserController en fonction des principes SOLID. »
• « Convertis ce fichier JavaScript en TypeScript avec des définitions de types appropriées. »
• « Suggère des améliorations pour faciliter le test de cette fonction. »
• « Identifie la duplication de code dans le répertoire src/utils/ et suggère comment la consolider. »
• « Modernise le projet de Java 8 vers Java 21. Suis les recommandations de l'epic 188. »
• « Crée un plan de migration pour moderniser le code mainframe COBOL, et évalue Java/Python. »

Dépannage

Des conseils de dépannage supplémentaires sont disponibles dans notre documentation.

Perspectives

GitLab Duo Agentic Chat est disponible dans les IDE et l'interface utilisateur de GitLab. Les prochaines versions fourniront la prise en charge du terminal avec GitLab Duo CLI, qui est actuellement en développement. Suivez l'epic produit pour obtenir plus d'informations.

Maintenant que vous avez découvert GitLab Duo Agentic Chat, explorez les différents types d'agents et apprenez à créer des agents personnalisés dans la Partie 3 : comprendre les agents. Découvrez les agents de base, créez des agents personnalisés pour votre équipe et intégrez des agents externes comme Claude Code et OpenAI Codex.

Ressources

• Documentation concernant GitLab Duo Agentic Chat
• Documentation concernant GitLab Duo Agent Platform

Article suivant : Partie 3 : comprendre les agents

Article précédent : Partie 1 : démarrer avec GitLab Duo Agent Platform

GitLab Duo Agent Platform représente un changement fondamental dans la façon dont les développeurs interagissent avec l'IA au cours du cycle de vie du développement logiciel. Axé non plus seulement sur le code et s'appuyant sur le contexte complet du SDLC, GitLab Duo Agent Platform permet à plusieurs agents d'IA spécialisés de travailler aux côtés de votre équipe, en gérant des tâches complexes de manière asynchrone tandis que vous vous concentrez sur l'innovation et la résolution de problèmes.

GitLab Duo Agent Platform transforme les workflows de développement linéaires traditionnels en systèmes de collaboration multi-agents dynamiques.

Qu'est-ce que GitLab Duo Agent Platform ?

GitLab Duo Agent Platform est une couche d'orchestration d'IA qui permet :

• La collaboration asynchrone entre les développeurs et les agents d'IA spécialisés
• Un contexte SDLC complet qui couvre le code, les tickets, les epics, les merge requests, les pipelines CI/CD, les wikis, les analyses et les scans de sécurité
• Des flows multi-agents où de nombreux agents collaborent en parallèle sur des tâches complexes
• Une automatisation intelligente qui comprend les normes, les pratiques et les exigences de conformité de votre organisation

Il s'agit d'assistants d'IA pour votre équipe qui peuvent prendre en charge des workflows entiers, car ils comprennent les exigences et créent des merge requests, tandis que vous maintenez une visibilité et un contrôle complets.

🧠 Essayez GitLab Duo Agent Platform dès aujourd'hui !

Architecture de GitLab Duo Agent Platform

GitLab Duo Agent Platform se compose de plusieurs composants interconnectés qui travaillent ensemble pour fournir une assistance d'IA complète. Le diagramme ci-dessous montre les méthodes d'interaction de l'utilisateur avec GitLab Duo Agent Platform. Il illustre les quatre façons dont les utilisateurs peuvent interagir avec les agents :

Comment les équipes interagissent avec GitLab Duo Agent Platform

Quatre façons d'utiliser les agents

1. GitLab Duo Agentic Chat : ouvrez le panneau de chat dans l'interface GitLab ou votre IDE pour engager des conversations interactives avec les agents fondamentaux et personnalisés. Sélectionnez parmi les modèles IA disponibles et obtenez une aide en temps réel.
2. Déclencher des flows personnalisés : mentionnez les flows dans les commentaires de tickets ou de merge requests, ou assignez des relecteurs pour déclencher automatiquement les flows personnalisés. Ceux-ci s'exécutent de manière asynchrone via l'exécution du runner.
3. Déclencher des flows de base : construits et maintenus par GitLab, notamment le flow Déveloper (développeur), le flow Code Review (revue de code), le flow Fix CI/CD Pipeline (correction de pipelines CI/CD), le flow Convert Jenkins to GitLab CI/CD (conversion de fichiers Jenkins en GitLab CI/CD), et le flow Software Development (développement logiciel).
4. Déclencher des agents externes : assignez ou mentionnez des agents d'IA externes (comme Claude Code ou OpenAI Codex) dans les commentaires de tickets ou de merge requests pour les déclencher automatiquement. Ceux-ci s'exécutent de manière asynchrone via l'exécution du runner.

Gestion et découverte

• Catalogue d'IA : parcourez, créez et partagez des agents et des flows dans votre organisation. Découvrez les agents et les flows créés par GitLab et votre équipe, puis ajoutez-les à vos projets. Vous pouvez également créer et publier vos propres agents et flows personnalisés et les mettre à disposition.
• Fonctionnalités d'automatisation : votre hub central où vous pouvez tout gérer. Affichez et gérez vos agents, configurez et surveillez les flows, examinez toutes les activités dans les sessions (y compris l'état du pipeline), et configurez des déclencheurs pour l'automatisation basée sur les événements.

Explorons brièvement chaque composant (nous les approfondirons dans les articles ultérieurs) :

GitLab Duo Agentic Chat

Votre interface principale pour interagir avec les agents. Disponible en tant que panneau persistant dans l'interface GitLab et dans votre IDE. Pour en savoir plus, consultez l'article Partie 2 : démarrer avec GitLab Duo Agentic Chat.

Agents

Les agents sont des assistants spécialisés alimentés par l'IA conçus pour gérer des tâches spécifiques tout au long de votre workflow de développement. Considérez-les comme des membres de votre équipe avec une expertise et des capacités uniques.

À propos des agents externes

Les agents externes s'exécutent en arrière-plan sur le calcul de la plateforme GitLab lorsqu'ils sont déclenchés par des mentions (par exemple, @ai-codex) ou des assignations dans les tickets et les merge requests. Contrairement aux agents de base et personnalisables qui utilisent des boucles de rétroaction synchrones, les agents externes s'exécutent de manière asynchrone, ce qui entraîne une automatisation puissante avec des fournisseurs IA spécialisés.

Les forces des agents

• Prompts spécialisés : chaque agent possède un prompt système unique qui définit son expertise, son comportement et son style de communication.
• Accès aux outils : les agents peuvent lire des fichiers, accéder aux tickets/merge requests/epics, rechercher du code, analyser les logs des tâches CI/CD et les rapports de vulnérabilité, et bien plus en fonction de leur configuration.
• Contexte du projet : ils ont accès aux tickets, merge requests, code, pipelines CI/CD et vulnérabilités de sécurité.

Pour plus d'informations, consultez la Partie 3 : comprendre les agents. Découvrez comment créer des agents personnalisés, intégrer des fournisseurs d'IA externes et configurer les prompts et les outils des agents pour les besoins spécifiques de votre équipe.

Flows

Les flows sont des workflows multi-étapes qui combinent plusieurs actions pour résoudre des problèmes complexes. Contrairement aux agents qui répondent à des questions, les flows exécutent des workflows complets de manière autonome via l'exécution du runner.

Les forces des flows

• Exécution multi-étapes : ils combinent plusieurs opérations en un seul workflow.
• Traitement asynchrone : ils s'exécutent en arrière-plan tandis que vous continuez à travailler.
• Accès complet au pipeline : ils s'exécutent via l'exécution du runner avec un contexte de projet complet.
• Déclenchement en fonction d'événements : ils sont déclenchés automatiquement en fonction d'événements GitLab

Pour plus d'informations, consultez la Partie 4 : comprendre les flows, y compris les workflows multi-agents.

Agents vs flows : quelle est la différence ?

Comprendre quand utiliser un agent plutôt qu'un flow est essentiel pour travailler efficacement avec GitLab Duo Agent Platform.

Guide de décision rapide

• Vous travaillez de manière interactive ou souhaitez des commentaires instantanés ? → Utilisez le chat
• Vous avez besoin d'automatisation en arrière-plan, de revues de merge requests ou de tâches complexes dans plusieurs fichiers ? → Utilisez les flows

Point essentiel

Les agents et les flows peuvent tous deux prendre des mesures et créer du code. La principale différence est la façon dont ils interagissent et s'exécutent : les agents communiquent de manière interactive dans votre interface de chat, tandis que les flows s'exécutent de manière asynchrone en arrière-plan sur le calcul de la plateforme.

Catalogue d'IA

Une bibliothèque centralisée où vous pouvez parcourir, découvrir, créer et partager des agents et des flows dans votre organisation. Vous retrouverez plus d'informations à ce sujet dans la Partie 5 : découvrir le catalogue d'IA.

Capacités d'automatisation

Votre hub pour gérer les workflows d'agents et de flows :

• Agents : affichez et gérez les agents de votre projet. Plus d'informations dans la Partie 3.
• Flows : affichez, créez et gérez les flows de votre projet. Plus d'informations dans la Partie 4.
• Sessions : logs d'activité des agents
• Déclencheurs : gestion de l'automatisation basée sur les événements pour les flows de votre projet

Comprendre les sessions

Chaque exécution d'agent et de flows crée une session qui enregistre les activités agentiques. Les sessions fournissent une transparence complète sur les événements, y compris le raisonnement de l'agent, les détails d'exécution, l'appel d'outils, les résultats et le suivi complet des décisions.

Pour afficher les sessions, accédez à votre projet > Automatiser > Sessions. Vous pourrez ensuite accéder à la console du pipeline pour voir les logs d'exécution détaillés.

Sélection du modèle

L'une des puissantes fonctionnalités de GitLab Duo Agent Platform est la capacité à choisir le modèle IA qui alimente votre conversation.

Disponible dans : GitLab 18.4 et versions ultérieures

Comment sélectionner le modèle :

1. Ouvrez GitLab Duo Agentic Chat.
2. Recherchez la liste déroulante des modèles.
3. Cliquez pour voir les modèles disponibles.
4. Sélectionnez le modèle qui convient le mieux à votre tâche.

Remarque : la sélection du modèle est actuellement disponible uniquement dans l'interface web. L'intégration IDE utilise le modèle par défaut sélectionné pour votre groupe.

Votre première interaction avec un agent

Découvrons une simple première interaction avec GitLab Duo Agentic Chat :

Exemple 1 : comprendre votre projet (agent)

Scénario : vous venez de rejoindre un projet et vous devez comprendre sa structure et son architecture.

Étapes :

1. Ouvrez le panneau GitLab Duo Chat (cliquez sur l'icône Duo en haut à droite).
2. Assurez-vous que le mode Agentique (version bêta) est activé.
3. Sélectionnez l'agent GitLab Duo (par défaut).
4. Saisissez : « Donne-moi un aperçu de l'architecture de ce projet ».
5. Appuyez sur Entrée.

Ce qui se passe :

L'agent :

• Analyse la structure de votre dépôt
• Examine votre README, l'organisation du code et la documentation
• Fournit un aperçu complet avec les composants clés

Vous pouvez poser des questions de suivi pour clarifier.

Exemple 2 : une merge request (flow)

Scénario : vous avez un ticket qui doit être résolu avec des modifications de code.

Étapes :

1. Ouvrez le ticket dans GitLab.
2. Cliquez sur le bouton Générer une MR avec Duo.
3. Une session d'agent démarre.
4. En quelques minutes, une merge request (MR) est créée avec :
   • Des modifications de code dans plusieurs fichiers
   • Un message de validation descriptif
   • Une explication des modifications dans la description de la merge request

Ce qui se passe :

Le flow Developer :

• Analyse le ticket
• Comprend la structure du dépôt, les modèles de conception et le contexte SDLC
• Effectue les modifications de code appropriées
• Ouvre une MR prête à être examinée

Questions fréquemment posées

Q : Mes conversations avec les agents sont-elles privées ?

R : Oui. Les conversations suivent les modèles de confidentialité et de sécurité standard de GitLab. En savoir plus.

Q : Puis-je utiliser GitLab Duo Agent Platform avec des modèles auto-hébergés ?

R : Oui. Cette approche requiert une configuration supplémentaire à partir de GitLab 18.8. Voir la documentation GitLab.

Perspectives

Maintenant que vous avez compris les bases de GitLab Duo Agent Platform, vous êtes prêt à approfondir chaque composant :

• Partie 2 : démarrer avec GitLab Duo Agentic Chat. Maîtrisez le panneau de chat persistant, découvrez les stratégies pour sélectionner un modèle, comprenez comment changer d'agent et utilisez le chat efficacement dans l'interface utilisateur web et tous les IDE pris en charge.
• Partie 3 : comprendre les agents. Explorez les agents de base construits par GitLab, créez des agents personnalisés avec des prompts spécialisés pour les workflows de votre équipe et intégrez les agents CLI externes de fournisseurs comme Claude Code et OpenAI Codex.
• Partie 4 : comprendre les flows. Découvrez comment les flows orchestrent plusieurs agents pour résoudre des problèmes complexes, créez des workflows personnalisés définis en YAML et exploitez les fournisseurs d'IA externes pour l'exécution de pipeline automatisée.
• Partie 5 : découvrir le catalogue d'IA. Parcourez le dépôt centralisé pour découvrir les agents et les flows créés par GitLab et la communauté, ajoutez-les à vos projets et publiez vos propres solutions pour que d'autres les utilisent.
• Partie 6 : surveiller, gérer et automatiser les workflows d'IA. Surveillez toutes les activités d'agents et de flows via les sessions, configurez les déclencheurs basés sur les événements pour automatiser les workflows et gérez tout votre écosystème de GitLab Duo Agent Platform à partir d'un seul endroit central.
• Partie 7 : intégrer le Model Context Protocol (MCP). Exploitez les capacités de GitLab Duo sur d'autres systèmes en vous connectant à des outils externes comme Jira, Slack et AWS via la norme MCP ouverte et autorisez les outils d'IA externes à accéder à vos données GitLab.
• Partie 8 : personnaliser GitLab Duo Agent Platform. Configurez des règles de chat personnalisées, créez des prompts système pour les agents, configurez les outils des agents, intégrez des systèmes externes avec MCP et personnalisez les flows en fonction des besoins spécifiques de votre équipe.

Ressources

• Documentation concernant GitLab Duo Agent Platform
• Site de GitLab Duo Agent Platform
• Forum de GitLab

Article suivant : Partie 2 : démarrer avec GitLab Duo Agentic Chat

Les tâches routinières, de la refactorisation de code aux scans de sécurité en passant par la recherche, peuvent être déléguées à des agents d'IA spécialisés. Les équipes peuvent ainsi se concentrer sur la résolution de problèmes complexes et l'innovation.

La plateforme tire parti du rôle de GitLab en tant que plateforme DevSecOps centrale (englobant la gestion du code, les pipelines CI/CD, la gestion des tickets, les résultats des tests, les scans de sécurité, etc.) pour fournir à ces agents un contexte de projet complet et leur permettre de contribuer de manière significative tout en respectant les normes et pratiques de votre équipe.

Ce guide complet en huit parties vous guidera de votre première interaction jusqu'à la mise en place de workflows d'automatisation entièrement personnalisables et prêts pour la production.

Évolution de GitLab Duo Pro/Enterprise vers GitLab Duo Agent Platform

GitLab Duo Agent Platform est une évolution, et n'a pas pour objectif de remplacer GitLab Duo Pro et GitLab Duo Enterprise. Il s'agit d'un sur-ensemble qui s'éloigne des interactions entre un seul développeur et l'IA et privilégie une collaboration entre plusieurs équipes et agents.

• GitLab Duo Pro a amélioré la productivité individuelle des développeurs dans l'IDE avec des suggestions de code alimentées par l'IA et un chat.
• GitLab Duo Enterprise a permis d'offrir des capacités d'IA complètes tout au long du cycle de développement logiciel. Mais il s'agissait encore principalement d'une approche qui facilitait les interactions entre un seul utilisateur et un assistant d'IA, principalement lors d'une session de questions-réponses avec un seul cas d'usage à la fois.
• GitLab Duo Agent Platform relègue les interactions individuelles au second plan et se concentre sur une collaboration entre équipes et agents, où des agents spécialisés gèrent de manière autonome les tâches routinières tout au long du cycle de vie logiciel.

La série complète

Référence des concepts clés

Composants principaux

Terminologie essentielle

Prêt à commencer ?

Commencez par lire l'article Partie 1 : Introduction à GitLab Duo Agent Platform pour découvrir les principes fondamentaux de la plateforme.

Retours

Nous aimerions avoir vos retours ! Vous avez trouvé une erreur ? Vous avez une suggestion ?

• Ouvrir un ticket
• Contribuer
• Échanger

Les outils d'IA ont considérablement amélioré la capacité des équipes de développement à écrire du code, et dans certains cas, les développeurs signalent une productivité multipliée par dix. Malheureusement, puisque seulement environ 20% du temps d'un développeur est consacré à l'écriture de code, l'amélioration de la vélocité d'innovation totale et de la livraison obtenue par l'IA est progressive. C'est ce qu'on appelle souvent le paradoxe de l'IA dans la livraison logicielle.

De plus, pour de nombreuses équipes, l'accélération de la création de code entraîne de nouveaux goulots d'étranglement, notamment un retard important dans la revue de code, des failles de sécurité, des contrôles de conformité et des corrections de bogues en aval.

GitLab Duo Agent Platform résout le paradoxe de l'IA grâce à une orchestration intelligente et une automatisation avec l'IA agentique tout au long du cycle de vie logiciel.

Pour obtenir plus d'informations, visionnez la vidéo et lisez la suite.

💡 Rejoignez GitLab Transcend le 10 février pour découvrir comment l'IA agentique transforme la livraison logicielle. Apprenez des témoignages de nos clients et explorez comment accélérer votre propre parcours de modernisation. Inscrivez-vous dès maintenant.

Nous sommes également ravis d'annoncer que les clients GitLab disposant d'abonnements GitLab Premium et GitLab Ultimate actifs recevront 12 et 24 dollars, respectivement, en GitLab Credits par utilisateur sans frais supplémentaires.* Ces crédits se renouvelleront chaque mois et donneront aux utilisateurs un accès à toutes les fonctionnalités de GitLab Duo Agent Platform.

Voici comment les GitLab Credits fonctionnent : un GitLab Credit est une monnaie virtuelle utilisée pour les produits basés sur l'utilisation de GitLab. L'utilisation de GitLab Duo Agent Platform consommera des crédits disponibles, en commençant par les crédits inclus mentionnés ci-dessus. Les clients peuvent ensuite décider de s'engager dans un pool partagé de crédits pour toute leur organisation, ou les payer mensuellement, à la demande. Pour plus d'informations, veuillez consulter notre article présentant GitLab Credits.

Les clients avec un abonnement GitLab Duo Pro ou GitLab Duo Enterprise sont invités à continuer à utiliser ces produits, ou à migrer vers GitLab Duo Agent Platform à tout moment. La valeur restante du contrat GitLab Duo Enterprise peut être convertie en GitLab Credits à tout moment. Contactez votre représentant GitLab pour en savoir plus.

Voici des cas d'usage et des fonctionnalités intéressants que vous pouvez tester dès aujourd'hui :

Une expérience unifiée pour la collaboration humaine et agentique

GitLab Duo Agent Platform introduit une expérience utilisateur unifiée conçue pour une intégration transparente entre les humains et leurs agents IA dans GitLab. Les développeurs et leurs équipes peuvent utiliser GitLab Duo Agentic Chat sur chaque page ou presque, poser des questions en contexte, suivre les sessions agentiques asynchrones et interagir avec les agents dans les workflows familiers comme les tickets, les merge requests et les activités de pipeline afin d'assurer la transparence des actions d'IA et de faciliter leur intégration dans les tâches quotidiennes.

Agentic Chat : assistance intelligente et contextuelle

Gitlab Duo Agentic Chat apporte un véritable raisonnement multi-étapes dans l'interface Web de GitLab et les IDE, en utilisant le contexte complet du cycle de vie des tickets, des merge requests, des pipelines, des résultats des scans de sécurité, et bien plus. S'appuyant sur GitLab Duo Chat précédemment publié, Agentic Chat peut effectuer des actions en votre nom de manière autonome et vous aider à répondre à des questions complexes de manière plus complète. Il fournit à chaque membre de l'équipe de développement logiciel des conseils précis et contextuels qui aident à améliorer l'intégration, la qualité du code et la vitesse de livraison.

GitLab Duo Agentic Chat prend en charge de nombreux cas d'usage pour permettre la collaboration entre les développeurs et l'IA. Pour plus de détails sur la façon de commencer, veuillez consulter notre guide « Démarrez avec GitLab Duo Agent Platform » et consultez ces suggestions de prompts que nous alimentons régulièrement.

• Analyser : dans l'interface Web, Agentic Chat peut créer des tickets, des epics, des merge requests et fournir des résumés, mettre en évidence des résultats clés et offrir des conseils exploitables basés sur le contexte en temps réel du ticket, de l'epic et de la merge request spécifiques, et de bien d'autres types de contenu. Agentic Chat aide les équipes de développement à comprendre le code, les dépendances, l'architecture et la structure du projet qu'ils ne connaissent pas bien dans l'IDE ou dans un dépôt GitLab.
• Coder : Agentic Chat peut générer du code, des configurations et une Infrastructure as Code à travers un large éventail de langages et de frameworks. Il peut aider à corriger les bogues, moderniser l'architecture et le code, générer des tests et de la documentation pour une intégration plus rapide. Directement à portée de main des développeurs, Agentic Chat est leur partenaire de collaboration dans VS Code, les IDE JetBrains, Cursor et Windsurf, avec des règles optionnelles au niveau de l'utilisateur et du workspace pour adapter les réponses.
• CI/CD : Agentic Chat peut vous aider à mieux comprendre, configurer et dépanner les pipelines existants, ou en créer de nouveaux à partir de zéro.
• Sécuriser : Agentic Chat peut expliquer les vulnérabilités, prioriser les tickets en fonction de leur accessibilité et recommander des corrections pour vous faire gagner du temps.

Agents : des spécialistes qui collaborent à la demande

GitLab Duo Agent Platform permet aux développeurs de déléguer des tâches à des agents spécialisés. La plateforme offre une combinaison unique d'agents de base, personnalisables et externes, tous intégrés de manière transparente dans l'expérience utilisateur GitLab, ce qui facilite le choix de l'agent adapté en fonctiond de la tâche.

Les agents de base sont préconfigurés par les experts GitLab et sont prêts à l'emploi pour gérer les tâches les plus complexes du cycle de livraison logicielle. Les agents de base ci-dessous sont inclus dans le cadre de la disponibilité générale de GitLab Duo Agent Platform, et d'autres sont actuellement en version bêta et seront bientôt disponibles.

• L'agent Planner aide les équipes à structurer, hiérarchiser et décomposer les tâches directement dans GitLab, ce qui rend la planification plus claire, plus rapide et plus facile à mettre en œuvre.
• L'agent Security Analyst examine les vulnérabilités et les signaux de sécurité, explique leur impact en langage clair et aide les équipes à comprendre les tâches à traiter en priorité.

Les agents personnalisables peuvent être créés à l'aide du Catalogue d'IA, un dépôt central où les équipes créent, publient, gèrent et partagent des agents et des flows personnalisés dans toute l'organisation. Les équipes peuvent créer des agents et des flows avec un contexte et des capacités spécifiques pour reproduire la façon dont leur équipe d'ingénierie fonctionne et résoudre les problèmes en utilisant les normes et les garde-fous utilisés par leurs ingénieurs.

Les agents externes sont intégrés de manière transparente dans GitLab et comprennent certains des meilleurs outils d'IA disponibles, notamment Claude Code d'Anthropic et Codex CLI d'OpenAI. Les utilisateurs bénéficient d'un accès natif GitLab à ces outils depuis GitLab pour divers cas d'utilisation, notamment la génération de code, la revue de code et l'analyse avec une sécurité transparente et des abonnements LLM intégrés.

Ensemble, ces approches offrent aux équipes une adoption flexible de l'IA agentique, des agents spécialisés aux automatisations spécifiques à l'organisation en passant par l'intégration d'outils d'IA externes, le tout dans une seule plateforme gouvernée.

Flows : transformez le travail multi-étapes en résultats reproductibles et guidés

Les flows automatisent les tâches complexes avec plusieurs workflows agentiques, du début à la fin.

Notre équipe d'ingénierie a créé plusieurs flows inclus en disponibilité générale, avec d'autres à venir :

• Le flow Developer (Issue to Merge Request) crée une merge request structurée à partir d'un ticket bien défini afin que les équipes puissent commencer à travailler immédiatement.
• Le flow Convert to GitLab CI/CD aide les équipes à migrer ou à moderniser les configurations de pipeline sans réécriture manuelle.
• Le flow Fix CI/CD pipeline analyse les échecs, identifie les causes probables et prépare les modifications recommandées.
• Le flow Code Review analyse les modifications de code, les commentaires des merge requests, et plus encore afin de rationaliser les revues de code avec une analyse et des retours natifs de l'IA.
• Le flow Software development in IDE guide le travail des équipes dans les étapes de développement et de revue quotidiennes.

Client MCP : connectez GitLab Duo Agent Platform aux outils que vos équipes utilisent déjà

Dans les IDE, le Client MCP permet à GitLab Duo Agent Platform de se connecter de manière sécurisée à des systèmes externes comme Jira, Slack, Confluence et d'autres outils compatibles MCP pour extraire le contexte et prendre des mesures dans votre chaîne d'outils DevSecOps.

Au lieu que l'assistance d'IA soit isolée dans des outils individuels, le Client MCP permet à GitLab Duo Agent Platform de comprendre et d'opérer dans les systèmes où la planification, la collaboration et l'exécution se produisent réellement. Cela réduit le changement de contexte manuel et permet des workflows plus complets et de bout en bout alimentés par l'IA qui reflètent la façon dont les équipes travaillent en pratique.

Les fonctionnalités suivantes sont incluses en disponibilité générale :

• Connexion à des systèmes externes compatibles MCP tels que Jira, Confluence, Slack, Playwright et Grafana
• Configuration au niveau du workspace et de l'utilisateur
• Contrôles au niveau du groupe pour activer ou restreindre l'utilisation de MCP
• Flux d'approbation de l'utilisateur pour l'accès aux outils
• Prise en charge dans Agentic Chat dans les extensions IDE

Nous prévoyons d'ajouter d'autres fonctionnalités à la capacité du serveur MCP GitLab, qui est actuellement en version bêta et devrait être en disponibilité générale dans les versions à venir.

Choisissez le bon modèle pour votre équipe et vos charges de travail

GitLab Duo Agent Platform est construit sur une sélection de frameworks flexible qui permet aux équipes d'adapter la plateforme en fonction de leurs besoins en matière de confidentialité, de sécurité et de conformité. GitLab utilise par défaut un LLM optimal pour chaque fonctionnalité, mais les administrateurs ont la possibilité de choisir parmi les modèles pris en charge tels que les variantes OpenAI GPT-5, Mistral, Meta Llama et Anthropic Claude. Les équipes possèdent ainsi un contrôle et une flexibilité plus précis sur le modèle utilisé pour le chat, les tâches de codage et les interactions d'agent pour chaque cas d'usage spécifique, en fonction des normes de leur organisation. Pour une liste complète des modèles pris en charge et des détails sur la configuration de la sélection de modèles, consultez la section sélection d'un modèle de notre documentation.

Gouvernance, visibilité et flexibilité de déploiement

GitLab Duo Agent Platform offre aux organisations le contrôle et la transparence dont elles ont besoin pour adopter l'IA de manière responsable, avec des options de déploiement flexibles qui fonctionnent dans différents environnements.

Les fonctionnalités suivantes sont incluses en disponibilité générale :

• Disponibilité sur toutes les plateformes : GitLab.com, GitLab Self-Managed et GitLab Dedicated dans le cadre du cycle de release GitLab 18.8.
• Gouvernance et visibilité : les équipes peuvent voir comment les agents sont utilisés, quelles actions ils effectuent et comment ils contribuent aux tâches. Les détails d'utilisation et d'activité aident les dirigeants à comprendre l'adoption, à mesurer l'impact et à s'assurer que l'IA est utilisée de manière appropriée. Ces contrôles facilitent le déploiement de l'IA à grande échelle en toute confiance.
• Contrôles d'accès basés sur les groupes : les administrateurs peuvent définir des règles au niveau de l'espace de nommage qui prescrivent quels utilisateurs peuvent accéder aux fonctionnalités de GitLab Duo Agent Platform. Cette approche contribue à une adoption flexible, de l'activation immédiate à l'échelle de l'organisation aux déploiements progressifs. L'intégration du protocole LDAP (Lightweight Directory Access Protocol) et du langage SAML (Security Assertion Markup Language) permet une gouvernance à grande échelle sans configuration manuelle.
• Sélection de modèles et options auto-hébergées : la sélection de LLM est disponible pour toutes les fonctionnalités en disponibilité générale sur GitLab.com, GitLab Self-Managed et GitLab Dedicated. Les propriétaires d'espaces de nommage de niveau supérieur choisissent le modèle, et les sous-groupes héritent automatiquement de ces paramètres. Pour les organisations qui souhaitent davantage de contrôle, la plateforme prend en charge les modèles auto-hébergés pour les déploiements GitLab Self-Managed.

Découvrez une démonstration de GitLab Duo Agent Platform en action :

Maintenez votre instance GitLab à jour

Pour vous assurer de bénéficier des dernières fonctionnalités, mises à jour de sécurité et améliorations de performances, nous vous recommandons de maintenir votre instance GitLab à jour. Les ressources suivantes peuvent vous aider à planifier et à effectuer votre mise à niveau :

• Outil de chemin d'accès de mise à niveau : indiquez votre version actuelle et consultez les étapes de mise à niveau à suivre pour votre instance.
• Documentation de mise à niveau : guides détaillés pour chaque version prise en charge, y compris les prérequis, les instructions étape par étape et les meilleures pratiques à suivre.

En effectuant des mises à niveau régulières, vous vous assurez que votre équipe bénéficie des dernières fonctionnalités de GitLab ainsi que d'une sécurité et d'une prise en charge optimales.

Pour les organisations qui privilégient une approche autonome, pourquoi ne pas faire appel à GitLab Managed Maintenance. Avec GitLab Managed Maintenance, votre équipe se concentre sur l'innovation tandis que les experts GitLab gèrent les mises à niveau de votre instance GitLab Self-Managed afin d'assurer la fiabilité, la sécurité et l'efficacité de vos processus DevSecOps. Contactez votre gestionnaire de compte pour obtenir plus d'informations.

* Les clients GitLab disposant d'un abonnement GitLab Premium et GitLab Ultimate actif recevront automatiquement 12 $ et 24 $ de crédits inclus par utilisateur, respectivement, qui seront renouvelés mensuellement. Ces crédits sont disponibles pour une durée limitée et sont susceptibles d'être modifiés (voir les conditions de la promotion).

Cet article de blog contient des déclarations de nature prospective au sens de la Section 27A du Securities Act de 1933, telle que modifiée, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous pensions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou conséquences sensiblement différents. De plus amples informations sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos documents déposés auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de publication de cet article de blog, sauf si la loi l'exige.

La tarification par siège crée une fracture entre les équipes d'ingénierie qui ont accès à l'IA et celles qui n'y ont pas accès, ce qui est en totale contradiction avec la manière dont l'IA agentique moderne devrait être utilisée tout au long du cycle de développement logiciel.

Aujourd'hui, vous devez acheter un siège pour chaque personne avant qu'elle ne puisse commencer à utiliser l'IA. Bien que cette tarification fonctionne pour les quelques utilisateurs intensifs, elle peut s'avérer trop coûteuse et injuste pour la majorité de l'équipe dont l'utilisation est ponctuelle. C'est pourquoi dans de nombreuses organisations, seule une partie de l'équipe dispose d'un « siège IA ».

Par ailleurs, GitLab Duo Agent Platform diffère de GitLab Duo Pro, de GitLab Duo Enterprise et des autres outils de développement d'IA sur le marché. Les agents et les flows agentiques peuvent être utilisés par votre équipe lorsque celle-ci a besoin d'une assistance IA et déclenchés par des événements SDLC qui s'exécutent en arrière-plan. Avec GitLab Duo Agent Platform, l'IA agentique n'est plus uniquement liée aux sièges utilisateurs.

GitLab Credits, notre nouvelle monnaie virtuelle pour la tarification à l'usage, permet de pallier ces différences d'utilisation, à commencer par GitLab Duo Agent Platform. Chaque membre de votre organisation avec un compte GitLab (Premium ou Ultimate) peut désormais utiliser les fonctionnalités d'IA agentique sans que vous ayez à payer pour un siège IA, que celles-ci soient utilisées directement ou configurées comme agents en arrière-plan.

Fonctionnement de GitLab Credits

Les crédits sont mutualisés dans l'ensemble de votre organisation. GitLab Duo Agent Platform, y compris l'usage synchrone et asynchrone des agents et des flows agentiques, requiert des GitLab Credits.

Les fonctionnalités suivantes consomment des GitLab Credits :

• Les agents de base tels que l'agent GitLab Duo Security Analyst, l'agent GitLab Duo Planner et l'agent GitLab Duo Data Analyst
• Les flows de base tels que le flow « revue de code », le flow flow « développeur » et le flow « correction de pipelines CI/CD »
• Les agents externes tels qu'Anthropic Claude Code et OpenAI Codex
• Les agents et les flows personnalisés que vous créez et publiez dans votre Catalogue d'IA
• Agentic Chat dans l'interface de GitLab et dans l'IDE.

Remarque : les agents externes sont disponibles gratuitement dans la version 18.8 et ne consomment pas de GitLab Credits. Nous présenterons la tarification le mois prochain, lors de la sortie de la version GitLab 18.9. Les flow personnalisés sont actuellement en version bêta et ne consomment pas de GitLab Credits.

Le nombre de crédits utilisés est basé sur le nombre de requêtes agentiques effectuées par les grands modèles de langage (LLM) (plus de détails ici). À mesure que le nombre de LLM disponibles augmentera, nous les certifierons pour une utilisation avec GitLab Duo Agent Platform et les ajouterons à cette liste afin d'offrir aux utilisateurs une vision transparente de leur consommation.

Le nombre total de crédits est calculé à la fin du mois en fonction de l'utilisation réelle. Ce modèle compense également automatiquement l'usage des utilisateurs intensifs par rapport à celui des utilisateurs occasionnels, afin de réduire ainsi efficacement le coût total de l'IA par personne (par rapport au paiement par siège pour chaque personne).

Par souci de simplicité, chaque crédit a un prix catalogue à la demande de 1 $. Vous pouvez utiliser GitLab Duo Agent Platform sans aucun engagement, et l'utilisation est facturée mensuellement (à la fin de chaque mois). Pour les clients Enterprise qui souscrivent à des engagements annuels, nous proposons des remises sur volume pour les crédits mensuels.

Dans le cadre d'une promotion à durée limitée*, tous les clients GitLab avec un abonnement GitLab Premium et GitLab Ultimate actif recevront automatiquement 12 $ et 24 $ de crédits inclus par utilisateur, respectivement. Ces crédits seront renouvelés chaque mois jusqu'à la fin de la période promotionnelle et permettront à votre équipe d'accéder à toutes les fonctionnalités de GitLab Duo Agent Platform sans frais supplémentaires. Lorsque vous acceptez nos conditions de facturation, toute utilisation supérieure à ces crédits inclus sera facturée via des crédits mensuels engagés ou des crédits à la demande.

Gouvernance des coûts avec GitLab Credits

Dimensionnement de GitLab Credits : votre équipe commerciale dispose d'un calculateur de dimensionnement dans le cadre de la disponibilité générale de GitLab Duo Agent Platform, pour estimer le nombre de crédits dont vous aurez besoin chaque mois. Ce calculateur a été conçu avec des modèles d'utilisation que nous avons observés pendant la période bêta. De plus, en tant que client existant ou nouveau client, vous pouvez demander un essai gratuit pour confirmer votre utilisation réelle estimée.

Visibilité de l'utilisation : avec la version 18.8, vous disposez d'informations détaillées sur l'utilisation via deux tableaux de bord complémentaires : un disponible dans le portail clients de GitLab pour les responsables de facturation à des fins de supervision financière, et l'autre intégré au produit pour les administrateurs à des fins de surveillance opérationnelle. Les deux fournissent une attribution de l'utilisation, des répartitions de coûts et des tendances historiques afin que vous sachiez toujours exactement comment vos crédits sont consommés. Si vous suivez une pratique de refacturation interne, vous pourrez utiliser les cumuls au niveau des projets et des groupes pour les allocations de coûts.

Contrôles d'utilisation : vous pouvez activer ou désactiver l'accès à GitLab Duo Agent Platform pour des équipes ou des projets spécifiques afin de garantir que seule l'utilisation approuvée peut être comptabilisée dans vos crédits. Nous prévoyons également d'ajouter des contrôles au niveau utilisateur peu après la disponibilité générale pour vous aider à gérer l'usage des fonctionnalités de GitLab Duo Agent Platform et des crédits.

Notifications automatiques d'utilisation : nous vous tiendrons informé de manière proactive de votre utilisation des crédits via des alertes par e-mail lorsque vous atteindrez 50 %, 80 % et 100 % de vos crédits mensuels engagés, afin que vous ayez le temps d'ajuster votre utilisation, d'acheter des engagements supplémentaires ou de planifier la facturation à la demande.

Mise à niveau de la tarification par siège GitLab Duo Pro/GitLab Enterprise vers GitLab Credits pour GitLab Duo Agent Platform

Si vous avez acheté et utilisez GitLab Duo Pro et GitLab Duo Enterprise, vous pouvez continuer à utiliser ces fonctionnalités comme options prises en charge. Vous pouvez passer à tout moment à GitLab Duo Agent Platform, afin d'utiliser la version « classique » de GitLab Duo, et accéder à de nouvelles fonctionnalités telles que l'Agentic Chat, des agents de base supplémentaires, des agents et des flows personnalisés, des agents externes et plus encore.

Au moment de la mise à niveau, nous transférerons votre investissement dans les sièges de GitLab Duo Pro et GitLab Duo Enterprise vers GitLab Credits pour GitLab Duo Agent Platform. Le montant restant des engagements de sièges sera échangé contre des GitLab Credits mensuels avec des remises basées sur le volume. Les crédits mensuels pourront ensuite être partagés entre tous les membres de votre organisation que vous autorisez, et non plus seulement les utilisateurs qui disposaient de sièges GitLab Duo assignés auparavant.

Comparaison concurrentielle : GitLab Credits vs tarification par siège

Configuration

1. Pour les clients GitLab Premium et GitLab Ultimate existants : avec la disponibilité générale, GitLab Duo Agent Platform sera disponible pour les clients disposant de licences GitLab Premium et GitLab Ultimate actives**. Les clients GitLab.com SaaS y auront accès automatiquement. Les clients GitLab Self-Managed y auront accès lorsqu'ils passeront à la version GitLab 18.8 (avec la disponibilité générale prévue de GitLab Duo Agent Platform). Les clients GitLab Dedicated seront mis à niveau vers GitLab 18.8 pendant leur fenêtre de maintenance programmée en février et pourront alors utiliser GitLab Duo Agent Platform.
2. Activez GitLab Duo : assurez-vous que GitLab Duo Agent Platform est activé dans les paramètres de votre espace de nommage.
3. Commencez à explorer : utilisez vos GitLab Credits mensuels inclus pour essayer les fonctionnalités de GitLab Duo Agent Platform.
4. Au-delà des crédits inclus : vous pourrez accepter GitLab Credits pour une utilisation étendue au-delà des crédits inclus au prix catalogue à la demande. Pour des remises sur volume avec engagement, veuillez nous contacter pour obtenir un devis pour votre niveau d'utilisation spécifique.

Consultez notre documentation pour en savoir plus sur la prise en main de GitLab Duo Agent Platform.

Remarques

* Ces crédits promotionnels inclus sont disponibles pour une durée limitée lors de la disponibilité générale, et peuvent être modifiés à la discrétion de GitLab.

** Exclut GitLab Duo avec Amazon Q et GitLab Dedicated pour les clients gouvernementaux.

Pour en savoir plus sur GitLab Duo Agent Platform et toutes les façons dont l'IA agentique peut transformer le travail de votre équipe, consultez notre page GitLab Duo Agent Platform. Si vous êtes un client GitLab existant, contactez votre gestionnaire de compte GitLab ou votre partenaire pour planifier une démonstration de nos fonctionnalités de plateforme.

FAQ sur GitLab Credits

1. Qu'est-ce que GitLab Credits et pourquoi GitLab les a-t-il introduits ?

GitLab Credits est une nouvelle monnaie virtuelle pour les fonctionnalités GitLab basées sur l'utilisation, à commencer par GitLab Duo Agent Platform. GitLab a introduit ce modèle car la tarification par siège forçait les organisations à rationner l'accès à l'IA au sein des équipes d'ingénierie, et l'utilisation de GitLab Duo Agent Platform n'est pas uniquement liée aux sièges. Les crédits sont mutualisés dans l'ensemble de votre organisation, vous permettant de donner à chaque membre de l'équipe un accès aux fonctionnalités d'IA, ou de configurer des workflows agentiques en arrière-plan, sans nécessiter l'achat de sièges individuels à l'avance.

2. Comment fonctionne la consommation de crédits ?

Les crédits sont déduits en fonction du nombre de requêtes agentiques effectuées, avec des taux différents selon le LLM utilisé. Par exemple, vous obtenez deux requêtes de modèle par crédit pour Claude-sonnet-4.5 (le modèle par défaut pour la plupart des fonctionnalités), et 20 requêtes par crédit pour des modèles comme gpt-5-mini ou claude-3-haiku.

3. Qu'est-ce qui est inclus pour les clients GitLab Premium et GitLab Ultimate existants ?

Dans le cadre d'une promotion à durée limitée, les clients disposant d'abonnements GitLab Premium et GitLab Ultimate actifs reçoivent automatiquement des crédits inclus gratuitement parallèlement à la version de disponibilité générale de GitLab Duo Agent Platform dans GitLab 18.8 :

• 12 $ de crédits par utilisateur par mois pour GitLab Premium
• 24 $ de crédits par utilisateur par mois pour GitLab Ultimate

Les crédits inclus sont au niveau utilisateur, se renouvellent mensuellement et permettent l'accès à toutes les fonctionnalités de GitLab Duo Agent Platform sans frais supplémentaires. Toute utilisation supplémentaire sera facturée séparément. Ces crédits promotionnels inclus sont disponibles pour une durée limitée après la disponibilité générale, et peuvent être modifiés à la discrétion de GitLab.

4. Comment puis-je contrôler et surveiller l'utilisation des crédits ?

GitLab fournit plusieurs outils de gouvernance : tableaux de bord d'utilisation détaillés dans le portail clients et au sein du produit, possibilité d'activer et de désactiver l'accès pour des équipes ou des projets spécifiques, contrôles au niveau utilisateur à venir, et alertes e-mail automatisées à 50 %, 80 % et 100 % des crédits mensuels engagés. Nous prévoyons également de proposer un calculateur de dimensionnement pour estimer vos besoins mensuels en crédits.

5. Comment puis-je commencer à utiliser GitLab Duo Agent Platform ?

Une fois en disponibilité générale, pour les clients GitLab Premium et GitLab Ultimate existants, l'accès est automatique sur GitLab.com SaaS. Les clients Self-Managed obtiennent l'accès lors de la mise à niveau vers GitLab 18.8 avec la disponibilité générale prévue de GitLab Duo Agent Platform. Activez simplement GitLab Duo Agent Platform dans les paramètres de votre espace de nommage et commencez à explorer GitLab Duo Agent Platform en utilisant vos crédits mensuels inclus. Pour une utilisation au-delà des crédits inclus, vous pouvez accepter la facturation à la demande ou contacter GitLab pour des remises sur volume avec engagements annuels.

Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou des issues réels sensiblement différents. Des informations supplémentaires sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige.

Pourquoi cette mesure a-t-elle été prise ?

Cette mesure fait partie intégrante de notre engagement envers les principes Secure by Design. L'authentification multifacteur offre une protection essentielle contre les attaques par « credential stuffing » (bourrage d’identifiant) et les tentatives de prise de contrôle de compte, qui restent des menaces persistantes dans le secteur du développement logiciel.

Informations clés à connaître

Qu'est-ce qui change ?

GitLab rend l'authentification multifacteur obligatoire pour les utilisateurs qui s'authentifient avec un nom d'utilisateur et un mot de passe. Cette mesure ajoute une deuxième couche de sécurité essentielle au-delà du simple mot de passe.

Cette mesure s'applique-t-elle à mon compte ?

1. Oui, elle s'applique si : vous vous connectez à GitLab.com avec un nom d'utilisateur et un mot de passe, ou si vous utilisez un mot de passe pour vous authentifier auprès de l'API.
2. Non, elle ne s'applique pas si : vous utilisez exclusivement une connexion via un réseau social (comme Google) ou une authentification unique (SSO) pour accéder à la plateforme. (Veuillez noter que si vous utilisez une authentification unique, mais que vous disposez également d'un mot de passe pour une connexion directe, vous aurez toujours besoin de l'authentification multifacteur pour toute connexion basée sur un mot de passe sans SSO.)

Quel est le calendrier de déploiement ?

1. La mise en œuvre se fera par étapes au cours des prochains mois afin de minimiser les interruptions inattendues et les pertes de productivité pour les utilisateurs, ainsi que de prévenir les blocages de compte. Des groupes d'utilisateurs seront invités à activer l'authentification multifacteur : chaque groupe sera sélectionné en fonction des actions qu'il a entreprises ou du code auquel il a contribué. Vous serez notifié de la manière suivante :
   • ✉️ Notification par e-mail : avant la phase qui vous concerne
   • 🔔 Rappels réguliers dans le produit : 14 jours auparavant
   • ⏱️ Après une période spécifique (qui sera communiquée par e-mail) : accès à GitLab bloqué jusqu'à ce que vous activiez l'authentification multifacteur

Quelle action dois-je entreprendre ?

1. Si vous vous connectez à GitLab.com avec un nom d'utilisateur et un mot de passe :
   • Nous vous recommandons vivement de configurer de manière proactive l'une des méthodes d'authentification multifacteur disponibles dès aujourd'hui (clés d'accès, application d'authentification, appareil WebAuthn, vérification par e-mail) afin de garantir la transition la plus sécurisée et la plus fluide possible :
   • Accédez à vos Paramètres utilisateur sur GitLab.com.
   • Sélectionnez la section Compte.
   • Activez l'authentification à deux facteurs et configurez la méthode de votre choix (par exemple, une application d'authentification ou un appareil WebAuthn).
   • Enregistrez de manière sécurisée vos codes de récupération pour vous assurer de pouvoir configurer à nouveau votre accès si nécessaire.
2. Si vous utilisez un mot de passe pour vous authentifier auprès de l'API :
   • Nous vous recommandons vivement de passer de manière proactive à un jeton d'accès personnel (PAT). Consultez notre documentation pour en savoir plus.

FAQ

Que se passe-t-il si je n'active pas l'authentification multifacteur avant la date limite ?

• Vous serez tenu de configurer l'authentification multifacteur avant de pouvoir vous connecter.

Cela affecte-t-il les pipelines CI/CD ou l'automatisation ?

• Oui, sauf si vous utilisez des jetons d'accès personnels (PAT) ou des jetons de déploiement à la place des mots de passe.

J'utilise l’authentification unique (SSO) mais je me connecte parfois directement, ai-je besoin de l'authentification multifacteur ?

• Oui, l'authentification multifacteur est requise pour toute authentification basée sur un mot de passe, y compris les scénarios de secours.

Un calendrier spécifique et d'autres ressources seront communiqués à l'approche des dates de déploiement. Nous vous remercions d'avance pour votre coopération.

Pourtant, 63 % des professionnels DevSecOps français déclarent que l'IA complexifie la gestion de la conformité, et 78 % estiment que l'IA agentique créera des défis de sécurité sans précédent.

C'est le paradoxe de l'IA : elle accélère le codage, mais la livraison logicielle ralentit car les équipes peinent à tester, sécuriser et déployer tout ce code.

Pour accéder à notre rapport DevSecOps complet dédié à « L'ère du développement logiciel intelligent », cliquez ici.

Les gains de productivité se heurtent à des goulots d'étranglement dans les workflows

Le problème n'est pas l'IA en elle-même, mais la façon dont les logiciels sont développés aujourd'hui. Le cycle de vie DevSecOps traditionnel comporte des centaines de petites tâches que les équipes de développement doivent gérer manuellement : mise à jour des tickets, exécution des tests, demandes de revue, attente des approbations, résolution des conflits de merge, traitement des problèmes de sécurité. Ces tâches mobilisent en moyenne six heures par semaine pour chaque membre de l'équipe, selon notre étude, sans compter les 14 heures mensuelles dédiées à la conformité.

Les équipes de développement génèrent du code plus vite que jamais. D'ailleurs, 100 % des professionnels interrogés affirment que l'IA leur a permis de gagner en productivité. Parmi les domaines où les outils d'IA ont permis les gains d'efficacité les plus importants, nous retrouvons l'automatisation des tâches répétitives (44 %), les tests/assurance qualité (38 %) et la génération de code (37 %).

Mais ce code continue de passer par des chaînes d'outils fragmentées, des transferts manuels et des processus déconnectés.

En France, 52 % des équipes DevSecOps utilisent plus de cinq outils pour le développement logiciel, et 47 % utilisent plus de cinq outils d'IA. Plus préoccupant encore, 48 % des professionnels utilisent des outils d'IA non officiellement approuvés par leur entreprise.

Cette fragmentation crée des obstacles à la collaboration : 96 % des professionnels DevSecOps font face à des éléments qui limitent la collaboration dans le cycle de vie du développement logiciel, notamment le manque de communication interfonctionnelle (34 %), les effets de silo organisationnels (31 %) et la multiplication des outils utilisés (29 %).

La solution n'est pas d'ajouter davantage d'outils. Il s'agit plutôt d'une orchestration intelligente qui rassemble les équipes logicielles et leurs agents d'IA à travers les projets et les cycles de release, avec une sécurité, une gouvernance et une conformité de niveau entreprise intégrées nativement.

Vers un partenariat humain-IA renforcé

Les professionnels DevSecOps ne veulent pas que l'IA prenne le contrôle. Ils veulent des partenariats fiables. 75 % affirment que l'utilisation de l'IA agentique augmenterait leur satisfaction au travail, et 39 % envisagent un avenir idéal avec une répartition équitable entre les contributions humaines et l'IA. Ils sont prêts à confier 33 % de leurs tâches quotidiennes à l'IA sans révision humaine, notamment pour la documentation (48 %), la création de tests (48 %) et les revues de code (44 %).

Ce que nous avons entendu de manière unanime de la part des professionnels DevSecOps, c'est que l'IA ne les remplacera pas, mais qu'elle transformera fondamentalement leurs rôles. 80 % pensent que l'IA modifiera significativement leur travail dans les cinq prochaines années. Et fait notable, 68 % estiment que cela créera même davantage d'emplois d'ingénieurs. À mesure que le codage devient plus facile avec l'IA, les ingénieurs capables de concevoir des systèmes, d'assurer la qualité et d'apporter un contexte métier seront très demandés. 83 % des répondants affirment d'ailleurs que les ingénieurs qui adoptent l'IA assurent la pérennité de leur carrière.

Point important : 85 % s'accordent à dire qu'il existe des qualités humaines essentielles que l'IA ne remplacera jamais totalement, notamment l'innovation (42 %), la vision stratégique (42 %), la créativité (41 %) et la collaboration (38 %).

Alors comment les organisations peuvent-elles combler le fossé entre la promesse de l'IA et la réalité des workflows fragmentés ?

Vous souhaitez en savoir plus ? Téléchargez notre rapport complet dédié à « L'ère du développement logiciel intelligent ».

Participez à GitLab Transcend

Participez le 10 février prochain à notre événement GitLab Transcend, où nous dévoilerons comment l'orchestration intelligente transforme le développement logiciel alimenté par l'IA. Vous découvrirez en avant-première la roadmap produit de GitLab et apprendrez comment les équipes résolvent des défis concrets en modernisant leurs workflows de développement avec l'IA.

Les organisations qui réussissent dans cette nouvelle ère trouvent un équilibre entre l'adoption de l'IA et la sécurité, la conformité et la consolidation des plateformes. L'IA offre de véritables gains de productivité lorsqu'elle est implémentée de manière réfléchie. 81 % des professionnels estiment que l'adoption systématique de l'IA générera plus de retours à long terme que son utilisation pour des solutions tactiques rapides. Non pas en remplaçant les développeurs humains, mais en libérant les professionnels DevSecOps pour qu'ils se concentrent sur la réflexion stratégique et l'innovation créative.

Inscrivez-vous dès aujourd'hui à GitLab Transcend et découvrez comment l'orchestration intelligente peut aider vos équipes logicielles.

Qu’est-ce que le DevOps ?

Le terme DevOps désigne une approche unifiée du développement logiciel et des opérations informatiques. Elle vise à supprimer les silos organisationnels entre les équipes de développement (Dev) et d'opérations (Ops) pour créer une culture de la collaboration et améliorer la rapidité et la fiabilité des livraisons logicielles.

Le DevOps ne se limite pas à une méthodologie ou à un ensemble d’outils : c’est avant tout une culture et un cadre opérationnel fondé sur trois piliers essentiels :

1. L’automatisation du cycle de vie applicatif.
2. La communication et la collaboration entre les équipes.
3. L’amélioration continue des processus et des produits.

Cette approche s’inscrit pleinement dans les pratiques CI/CD (Intégration et Livraison continues) modernes où vitesse, qualité et sécurité sont combinées.

Pourquoi adopter le DevOps ?

Le DevOps répond directement aux enjeux liés aux cycles de développement qui se raccourcissent et à l’exigence accrue de fiabilité, en unifiant les processus de bout en bout : de la planification au déploiement, en passant par les tests et la supervision.

1. Des équipes alignées

Le DevOps élimine les silos historiques entre les équipes chargées du développement et des opérations. Les équipes collaborent sur un même pipeline, avec des objectifs partagés et des indicateurs communs. Cette approche collaborative réduit les transferts d’information, les malentendus et les délais liés aux validations successives.

GitLab renforce cette collaboration en centralisant tout le cycle de vie logiciel, du commit à la mise en production, au sein d’une seule et même plateforme.

2. L’automatisation comme levier de fiabilité

Les pipelines CI/CD exécutent automatiquement les étapes critiques : build, tests, contrôle qualité, sécurité et déploiement et chaque livraison suit un processus standardisé et documenté.

Cette industrialisation réduit la dépendance aux actions manuelles, tout en garantissant la stabilité et la traçabilité du code.

Résultat : des déploiements plus fréquents, reproductibles et sûrs, avec un taux d’échec nettement inférieur.

3. Des environnements stables, des incidents réduits

Les pratiques DevOps s’appuient sur l’Infrastructure as Code (IaC) pour garantir la cohérence entre le développement, les tests et la mise en production. Les configurations ne sont plus gérées manuellement, mais sont versionnées, validées et déployées via les pipelines.

Ce modèle élimine la plupart des erreurs liées aux différences d’environnement et en cas de défaillance, les équipes peuvent revenir à une version précédente en quelques secondes.

L’effet sur les opérations est immédiat : un MTTR réduit, une meilleure prévisibilité et une confiance accrue dans chaque déploiement.

4. Une culture d’amélioration continue

Le DevOps repose sur une logique d’apprentissage permanent. Les performances sont mesurées à l’aide des métriques DORA qui incluent la fréquence de déploiement, le délai de mise en production, le taux d’échec des changements, et le temps moyen de restauration. Ces indicateurs permettent aux équipes de mesurer et d'améliorer leurs performances DevOps.

En utilisant les rapports personnalisés DORA dans GitLab, les équipes transforment leurs pipelines en levier de performance mesurable.

5. Sécurité intégrée, agilité préservée

Le DevOps évolue progressivement vers une approche DevSecOps, où la sécurité est intégrée à chaque étape du cycle de développement logiciel.

Les contrôles de code, l’analyse des dépendances et l’analyse des conteneurs s’exécutent automatiquement dans les pipelines CI/CD.

Cette approche « shift-left » détecte et corrige les vulnérabilités avant qu’elles n’atteignent la production. Les équipes gagnent ainsi en efficacité : elles maintiennent la cadence des livraisons et renforcent la conformité.

GitLab automatise l’ensemble de ces contrôles à chaque commit, garantissant un équilibre entre vitesse et sécurité.

6. Des cycles de livraison plus courts

Le DevOps accélère radicalement le passage du code à la production. Les itérations sont plus courtes, les versions plus fréquentes et les feedbacks plus rapides. Les entreprises peuvent ainsi expérimenter, ajuster et livrer au rythme du marché.

Les équipes les plus matures déploient jusqu'à plusieurs centaines de fois plus souvent que les modèles traditionnels. Cette vitesse maîtrisée transforme la mise en production en un processus quotidien plutôt qu’en un événement risqué.

7. Une efficacité opérationnelle mesurable

En automatisant les processus et en centralisant les outils, l’approche DevOps réduit la complexité opérationnelle. Les ressources humaines et matérielles sont optimisées, et la productivité des équipes augmente significativement.

Les gains ne se limitent pas à la technique : la réduction du temps passé sur la maintenance libère du temps pour permettre aux équipes d’innover. Chaque heure économisée sur la coordination manuelle est une heure investie dans l’innovation et la création de valeur.

8. Une meilleure expérience utilisateur

Le DevOps raccourcit la distance entre les équipes techniques et les utilisateurs finaux. Des livraisons plus fréquentes permettent d’intégrer rapidement les retours utilisateurs, d’ajuster les fonctionnalités et de corriger les anomalies avant qu’elles ne deviennent critiques.

La stabilité des environnements garantit une expérience d’utilisation cohérente et fiable. Les utilisateurs bénéficient d’un produit plus fiable, plus réactif et en amélioration constante, preuve que l’excellence technique sert directement la satisfaction client.

Comment mesurer les avantages du DevOps ?

Le succès d’une transformation DevOps se mesure par des indicateurs concrets, généralement regroupés dans le modèle DORA :

• Délai de mise en production : délai moyen pour déployer un changement en production.
• Fréquence de déploiement : fréquence de mise en production.
• Taux d’échec des changements : pourcentage de déploiements entraînant un incident.
• Temps moyen de restauration (MTTR) : temps moyen de restauration après un incident.

Ces métriques permettent d’évaluer objectivement la maturité DevOps d’une organisation et d’identifier les axes d’amélioration prioritaires.

GitLab fournit ces indicateurs directement dans son interface, permettant un suivi en temps réel et une visibilité complète sur les performances CI/CD.

Adoptez une approche DevOps avec GitLab

GitLab offre une plateforme DevSecOps unifiée qui centralise le code, les pipelines CI/CD, la sécurité et le déploiement dans un seul espace de travail.

Cette approche intégrée supprime la fragmentation des outils et facilite la collaboration entre les équipes.

Les équipes peuvent :

• gérer le code, les tests et la sécurité dans un même environnement,
• automatiser les déploiements via des pipelines CI/CD complets,
• suivre les métriques DORA pour mesurer l’efficacité de leur travail,
• appliquer une gouvernance unifiée à l’échelle de l’organisation.

Grâce à cette intégration, GitLab aide les entreprises à concrétiser rapidement les bénéfices du DevOps sans complexité additionnelle.

Conclusion

Adopter une approche DevOps, c’est transformer la manière dont les organisations conçoivent, livrent et sécurisent leurs logiciels. Les avantages sont clairs : plus de rapidité, de fiabilité, de sécurité et de collaboration entre les équipes.

En combinant ces principes à une plateforme complète comme GitLab, les entreprises peuvent accélérer leur innovation tout en maîtrisant la qualité et les coûts.

→ Essayez GitLab Ultimate gratuitement et découvrez comment une plateforme DevSecOps intégrée peut amplifier les avantages de votre démarche DevOps.

Je me suis récemment entretenu avec un ingénieur plateforme d'une entreprise du classement Fortune 500 qui m'a confié : « Je passe plus de temps à gérer les dépôts d'artefacts qu'à améliorer réellement la plateforme. » Cette conversation m'a rappelé à quel point il était nécessaire de se pencher sur les coûts réels de la gestion fragmentée des artefacts et sur les mesures réalistes que les équipes plateforme peuvent prendre à ce sujet. Cet article vous aidera à mieux comprendre le problème et comment GitLab peut vous aider à le résoudre grâce à une consolidation stratégique.

Impact concret : les chiffres

D'après les données de nos clients et les recherches dans le secteur, la gestion fragmentée des artefacts entraîne généralement les coûts suivants pour une organisation de taille moyenne (plus de 500 développeurs) :

• Licences : 50 000 $ à 200 000 $ par an répartis sur plusieurs outils
• Coûts opérationnels : 2 à 3 équivalents temps plein consacrés aux tâches de gestion des artefacts
• Inefficacité du stockage : 20 % à 30 % de coûts de stockage supplémentaires en raison de la duplication et d'une mauvaise gestion du cycle de vie
• Perte de productivité des développeurs : 15 à 20 minutes par jour et par développeur en raison des difficultés liées aux artefacts

Pour les grandes entreprises, ces chiffres peuvent être multipliés considérablement. Un client a calculé qu'il dépensait plus de 500 000 $ par an uniquement pour les coûts opérationnels liés à la gestion de sept systèmes de stockage d'artefacts différents.

Les coûts cachés s'accumulent chaque jour :

Multiplication du temps : chaque politique de cycle de vie, règle de sécurité ou modification de contrôle d'accès doit être mise en œuvre sur plusieurs systèmes. Une configuration qui devrait prendre 15 minutes requiert au final plusieurs heures de travail.

Risques de failles de sécurité : la gestion des politiques de sécurité sur des systèmes disparates crée des espaces vulnérables. L'analyse des vulnérabilités, les contrôles d'accès et les pistes d'audit deviennent fragmentés.

Coût du changement de contexte : les développeurs perdent en productivité lorsqu'ils ne trouvent pas les artefacts ou doivent se rappeler quel système stocke quoi.

Quand la multiplication des outils devient un problème

L'environnement de la gestion des artefacts a explosé. Là où les équipes de plateforme géraient autrefois un seul dépôt Maven, elles doivent aujourd'hui jongler avec :

• Des registres de conteneurs (Docker Hub, ECR, GCR, Azure ACR)
• Des dépôts de paquets (JFrog Artifactory, Sonatype Nexus)
• Des registres spécifiques au langage (npm, PyPI, NuGet, Conan)
• Des artefacts d'infrastructure (modules Terraform, charts Helm)
• Des registres de modèles ML (MLflow, Weights & Biases)

Chaque outil possède son propre système d'authentification, ses politiques de cycle de vie, son analyse de sécurité et ses exigences opérationnelles. Pour les organisations qui comptent des centaines ou des milliers de projets, la gestion devient un fardeau exponentiel.

L'approche stratégique de GitLab

Lorsque nous avons commencé à développer les fonctionnalités de gestion des artefacts de GitLab il y a six ans, nous avons été confrontés à une décision produit classique : prendre en charge tous les formats d'artefacts imaginables ou approfondir les formats les plus importants pour les équipes d'entreprise. Nous avons choisi la deuxième approche, et cette décision a façonné tout ce que nous avons construit depuis.

Nos priorités

Au lieu de créer une prise en charge superficielle pour plus de 20 formats, nous nous sommes engagés à fournir des capacités de niveau entreprise pour une sélection de formats stratégiques :

• Maven (écosystème Java)
• npm (JavaScript/Node.js)
• Docker/OCI (images de conteneurs)
• PyPI (paquets Python)
• NuGet (paquets C#/.NET)
• Paquets génériques (tout artefact binaire)
• Modules Terraform (Infrastructure as Code)

Ces sept formats représentent environ 80 % de l'utilisation des artefacts dans les environnements d'entreprise, d'après nos données clients.

Le niveau entreprise

En nous concentrant sur moins de formats, nous pouvons fournir des capacités qui fonctionnent dans des environnements de production avec des centaines de développeurs, des téraoctets d'artefacts et des exigences strictes en matière de conformité :

Registres virtuels : proxy et mise en cache des dépendances en amont pour des builds fiables et un contrôle de la chaîne d'approvisionnement. Actuellement en production pour Maven, avec npm et Docker prévus pour début 2026.

Gestion du cycle de vie : politiques de nettoyage automatisées qui empêchent l'augmentation des coûts de stockage et préservent les artefacts à des fins de conformité. Disponible au niveau du projet aujourd'hui, avec des politiques au niveau de l'organisation prévues pour mi-2026.

Intégration de la sécurité : analyse des vulnérabilités intégrée, analyse des dépendances et application des politiques. Notre future fonctionnalité Dependency Firewall (prévu pour fin 2026) fournira un contrôle de sécurité de la chaîne d'approvisionnement sur tous les formats.

Intégration CI/CD approfondie : traçabilité complète du commit source à l'artefact déployé, avec provenance du build et résultats d'analyse de sécurité intégrés dans les métadonnées d'artefact.

Capacités actuelles : des fonctionnalités éprouvées

Registres virtuels Maven : notre capacité phare au niveau entreprise, une solution éprouvée et utilisée par plus de 15 entreprises clientes. Deux mois suffisent pour configurer un registre virtuel Maven avec une assistance GitLab minimale.

Dépôts hébergés localement : les sept formats pris en charge offrent des capacités complètes d'importation, de téléchargement, de gestion des versions et de contrôle d'accès qui prennent en charge des charges de travail critiques dans des organisations avec des milliers de développeurs.

Artefacts protégés : protection complète qui empêche les modifications non autorisées, avec prise en charge de contrôles d'accès précis sur tous les formats.

Politiques de cycle de vie au niveau du projet : politiques automatisées de nettoyage et de rétention pour le contrôle des coûts de stockage et la conformité.

Performances et mise à l'échelle

D'après les déploiements en production actuels :

• Débit : plus de 10 000 téléchargements d'artefacts par minute/par instance
• Stockage : clients avec une gestion efficace de plus de 50 To d'artefacts
• Utilisateurs simultanés : accès simultané de plus de 1 000 développeurs aux artefacts
• Disponibilité : disponibilité de 99,99 % pour GitLab.com depuis plus de 2 ans

Roadmap stratégique : 18 prochains mois

T1 2026

• Registres virtuels npm : proxy/cache d'entreprise pour les paquets JavaScript
• Registres virtuels Docker : capacités de proxy de registres de conteneurs

T2 2026

• Politiques de cycle de vie au niveau de l'organisation (version bêta) : politiques de nettoyage centralisées avec remplacements au niveau du projet
• Registres virtuels NuGet (version bêta) : prise en charge du proxy de paquets .NET
• Registres virtuels PyPI (version bêta) : finalisation de la prise en charge du registre virtuel pour Python

T3 2026

• Tableau de bord d'analyse avancée : informations sur l'optimisation du stockage et l'utilisation

T4 2026

• Dependency Firewall (version bêta) : contrôle de sécurité de la chaîne d'approvisionnement pour tous les types d'artefacts

Quand choisir GitLab : framework de décision

GitLab est probablement le bon choix si :

• 80 % ou plus de vos artefacts sont dans nos sept formats pris en charge
• Vous utilisez déjà GitLab pour le code source ou le CI/CD
• Vous privilégiez les workflows intégrés plutôt que la richesse des fonctionnalités autonomes
• Vous souhaitez réduire la complexité opérationnelle liée à la gestion de plusieurs systèmes
• Vous avez besoin d'une traçabilité complète de la source au déploiement

Déroulement d'une migration

Calendrier typique : 2 à 4 mois pour une migration complète depuis Artifactory/Nexus

Défis courants : configuration du registre virtuel, mappage du contrôle d'accès et modifications des workflows des équipes de développement

Facteurs de réussite : approche progressive, tests complets et formation des développeurs

Les migrations réussies suivent ce modèle :

1. Évaluation (2 à 4 semaines) : inventaire des artefacts actuels et des modèles d'utilisation
2. Phase pilote (4 à 6 semaines) : migration d'une équipe/d'un projet de bout en bout
3. Déploiement (6 à 12 semaines) : migration progressive avec systèmes parallèles
4. Optimisation (en continu) : mise en œuvre de fonctionnalités et de politiques avancées

Une meilleure gestion des artefacts dès aujourd'hui

La gestion des artefacts de GitLab n'a pas pour objectif de convenir à toutes les entreprises. Nous avons fait des compromis stratégiques : des capacités approfondies pour les formats d'entreprise de base plutôt qu'une prise en charge superficielle.

Si vos besoins en matière d'artefacts correspondent à nos formats pris en charge et que vous privilégiez les workflows intégrés, nous pouvons réduire considérablement vos coûts opérationnels et améliorer l'expérience des équipes de développement.

Nous souhaitons vous aider à prendre des décisions éclairées sur votre stratégie de gestion des artefacts grâce à une compréhension claire des fonctionnalités et de notre roadmap.

N'hésitez pas à me contacter à l'adresse trizzi@gitlab.com pour en savoir plus sur la gestion des artefacts chez GitLab. Nous pourrons aborder vos exigences spécifiques et vous mettre en relation avec notre équipe technique pour une évaluation plus approfondie.

Cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter qu'elles ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article sont susceptibles de changer ou d’être retardés. Le développement, la sortie et le calendrier de tout produit ou de toute fonctionnalité restent à la seule discrétion de GitLab.

L'intégration de GitLab avec CodeSonar (d'AdaCore) relève ce défi grâce à une automatisation des workflows de conformité et une vérification continue tout au long du cycle de développement logiciel.

Scan spécialisé pour les systèmes critiques

Les systèmes critiques nécessitent une analyse approfondie du code C/C++ compilé avec des outils embarqués spécialisés. Ces systèmes doivent démontrer leur conformité aux normes de codage (MISRA C/C++, CERT C/C++, AUTOSAR C++) et aux frameworks de sécurité fonctionnelle (ISO 26262, DO-178C, IEC 61508) qui exigent des pistes d'audit détaillées. Outre l'alignement avec les normes de codage, les équipes doivent également traiter les incidents de sécurité et tester les problèmes de mémoire, les variables non initialisées et l'injection de commandes.

CodeSonar effectue une analyse complète du programme avec des capacités d'analyse spécialisées pour ces normes. L'association de CodeSonar avec GitLab permet aux équipes d'automatiser les workflows de conformité et de maintenir des pistes d'audit complètes tout au long du cycle de développement.

Automatisation de la conformité du commit au merge

L'intégration de GitLab et CodeSonar offre une approche Compliance-as-Code qui automatise l'application des politiques dès les premières étapes du développement. CodeSonar fonctionne comme un scanner supplémentaire au sein des pipelines CI/CD GitLab et analyse le code à chaque commit et merge request.

Conçu spécifiquement pour les systèmes embarqués, CodeSonar effectue une analyse approfondie du flux de contrôle et de données sur l'ensemble des programmes. Il identifie les vulnérabilités telles que les dépassements de mémoire tampon, la contamination des données, les variables non initialisées, les conditions « use-after-free » (tentative d'accès à la mémoire) et l'injection de commandes : il s'agit là des causes profondes de la plupart des incidents de sécurité dans les systèmes embarqués.

L'intégration fonctionne via la configuration CI/CD de GitLab. Lorsque les équipes de développement effectuent un push des modifications de code, le pipeline déclenche le scan CodeSonar. Pour les firmwares C et C++, CodeSonar observe les invocations du compilateur pendant le processus de build réel et crée une représentation interne du code en vue d'une analyse sophistiquée. Les résultats sont convertis du format SARIF au format de test statique de sécurité des applications (SAST) de GitLab et affichés directement dans les merge requests, où ils alimentent le tableau de bord de sécurité de GitLab Ultimate, la gestion des vulnérabilités et les frameworks de conformité.

Exemple de workflow : conformité à la norme ISO 26262 ASIL-D

La vidéo de démonstration ci-dessous présente le workflow complet pour un système embarqué soumis aux exigences de la norme ISO 26262 ASIL-D. Le scénario illustre comment les équipes de développement embarqué peuvent mettre en œuvre une conformité continue sans compromettre la vélocité de développement.

Le workflow commence lorsqu'un développeur soumet une merge request afin de modifier le firmware. Le pipeline CI/CD de GitLab déclenche automatiquement le scan CodeSonar, qui effectue une analyse approfondie C/C++ des politiques ISO 26262 personnalisées configurées dans le pipeline. Lorsque CodeSonar identifie une vulnérabilité pertinente pour ASIL-D, le pipeline s'arrête automatiquement conformément à la politique de conformité et fournit une documentation claire du problème. Les résultats complets du scan, le suivi des tickets et le workflow d'approbation sont conservés dans GitLab comme source unique de vérité pour les pistes d'audit.

Les équipes de développement peuvent utiliser à la fois l'interface hub de CodeSonar et GitLab Duo pour comprendre la vulnérabilité. CodeSonar fournit des informations détaillées sur le chemin dans le code source qui mène au problème, ainsi que des fonctionnalités de navigation dans le code pour isoler la cause profonde. GitLab Duo explique la vulnérabilité et fournit des recommandations de correction spécifiques. Une fois la correction implémentée et la résolution validée, le code est fusionné, et les équipes disposent également de preuves de conformité qui ont été automatiquement collectées tout au long du processus.

Avantages de l'intégration

Les organisations qui mettent en œuvre cette conformité intégrée avec GitLab et CodeSonar constateront des améliorations significatives tant au niveau de la vélocité de développement que de la confiance en matière de conformité.

• Gains d'efficacité : les équipes de développement réduisent le délai de mise sur le marché, car elles détectent les problèmes de conformité aux normes de codage tôt, lorsqu'ils sont moins coûteux à corriger. L'application automatisée des politiques de sécurité réduit la charge de travail liée aux revues de sécurité manuelles et permet aux spécialistes de se concentrer sur des problèmes complexes plutôt que sur des vérifications routinières. La préparation aux audits s'améliore grâce à la collecte automatisée de preuves. Les artefacts de conformité sont générés comme un sous-produit du développement normal plutôt que lors de tâches de documentation séparées.
• Maturité de la conformité : cette approche intégrée aide les organisations à maintenir une conformité continue avec les normes et réglementations du secteur. En intégrant la vérification dans chaque modification de code, les équipes construisent des pistes d'audit complètes qui démontrent l'adhésion aux normes ISO 26262, DO-178C, MISRA C/C++ et d'autres exigences. Le workflow automatisé transforme la conformité d'un point de contrôle périodique en un processus de vérification continu.

Considérations relatives à l'implémentation

La mise en œuvre de l'intégration GitLab et CodeSonar nécessite un accès à GitLab Ultimate, un hub CodeSonar, des runners GitLab où le code peut être compilé et analysé, ainsi que des mécanismes appropriés pour la gestion des fichiers de données d'analyse. GitLab et CodeSonar prennent tous deux entièrement en charge les environnements sur site et air-gapped et peuvent également être déployés dans des environnements cloud auto-évolutifs.

Les équipes doivent configurer des frameworks de conformité personnalisés dans GitLab pour définir des politiques spécifiques à leurs normes pertinentes : ISO 26262 pour l'automobile, DO-178C pour l'aérospatiale, IEC 62304 pour les dispositifs médicaux, et bien d'autres encore. Ces frameworks permettent l'application automatisée des exigences de conformité via des règles d'approbation de merge request, des seuils de vulnérabilité et des portes relatives aux politiques de scans.

Lancez-vous

Le composant CI CodeSonar pour GitLab est disponible via le catalogue CI/CD de GitLab. Une documentation d'intégration détaillée fournit des instructions de configuration spécifiques à chaque plateforme pour les environnements Linux, Docker et Windows. Pour les organisations qui évaluent cette solution, l'implémentation démontre comment des outils spécialisés pour systèmes embarqués peuvent s'intégrer à une plateforme DevSecOps moderne afin d'offrir à la fois vélocité de développement et rigueur de conformité.

Pour plus d'informations sur l'implémentation de GitLab avec CodeSonar pour votre développement de systèmes embarqués, consultez la documentation d'intégration CodeSonar. Vous pouvez également demander un essai de CodeSonar.

La disponibilité générale de GitLab Duo Agent Platform a pour objectif d’introduire une approche unifiée et gouvernée afin que les organisations puissent orchestrer l'IA agentique dans l'ensemble du cycle de développement logiciel. Avec des agents de base, des agents personnalisés et des flows automatisés qui fonctionnent en symbiose au sein de GitLab, les équipes pourront adopter des workflows agentiques qui accélèrent les tâches tout en restant alignés sur les standards de leur organisation. Lors de la disponibilité générale, nous prévoyons également de renforcer la fiabilité et d'inclure des fonctionnalités étendues du catalogue d’IA, des contrôles renforcés ainsi qu'un modèle de facturation flexible basé sur l'utilisation, conçu pour offrir plus de flexibilité dans l'usage de l'IA agentique dans de nombreux rôles et projets.

La version 18.7 ajoute des éléments fondamentaux importants pour préparer la disponibilité générale de GitLab Duo Agent Platform. Les nouvelles fonctionnalités d’automatisation, les contrôles de gouvernance renforcés et les améliorations apportées à la sécurité et la création de pipelines aident les équipes à rationaliser leur travail et à poser les bases d'une expérience agentique encore plus fiable pour la version 18.8 et au-delà.

Le 10 février 2026, nous organisons un événement de lancement mondial qui donnera vie à notre vision de GitLab en tant que plateforme d'orchestration intelligente, où les équipes logicielles et leurs agents d’IA collaborent. Vous découvrirez comment nos clients relèvent le paradoxe de l'IA dans la livraison logicielle, testerez l'orchestration intelligente en action dans les workflows DevSecOps et prendrez une longueur d'avance dans votre parcours de modernisation. Réservez votre place dès maintenant !

Quelles sont les nouveautés de la version 18.7 ?

GitLab Duo Agent Platform

Alors que de plus en plus d'équipes intègrent l'IA dans leurs workflows de développement et de sécurité, GitLab continue de miser sur une adoption à la fois puissante et prévisible de cette technologie. Les mises à jour de la version 18.7 renforcent les fondations pour des expériences d'IA guidées et gouvernées qui se concrétiseront pleinement lorsque GitLab Duo Agent Platform atteindra la disponibilité générale dans la version 18.8.

Flows personnalisés

Les flows personnalisés introduisent une nouvelle façon pour les équipes d'automatiser des workflows en plusieurs étapes à l'aide de séquences définies en YAML qui orchestrent des agents pour accomplir des tâches de développement répétitives. Les flows personnalisés permettent d'éliminer le travail manuel pour les scénarios qui suivent des schémas prévisibles, comme diagnostiquer et corriger des pipelines en échec, mettre à jour des dépendances ou exécuter des vérifications de conformité lorsque des relecteurs sont assignés. Au lieu de gérer ces tâches de manière interactive, les équipes peuvent définir des flows qui se déclenchent automatiquement à partir d'événements GitLab comme les mentions ou les assignations. Cette fonctionnalité aide les équipes de développement qui souhaitent mettre en place des automatisations sur mesure pour leurs propres projets, ainsi que les administrateurs qui ont besoin de workflows cohérents à l'échelle de l'organisation pour la conformité et l'efficacité opérationnelle.

Flow de détection des faux positifs SAST

La gestion des faux positifs alimentée par l'IA pour les tests statiques de sécurité des applications (SAST) introduit une approche plus rapide et plus précise pour que les équipes évaluent et traitent les potentiels faux positifs. GitLab utilise désormais l'IA pour identifier les éventuels faux positifs plus tôt dans le processus de revue afin de réduire le temps que les équipes de développement et de sécurité passent à trier ces éléments. Les utilisateurs peuvent voir un aperçu du nombre de vulnérabilités qui méritent une revue, suivre leur progression et rejeter les faux positifs directement depuis le rapport de vulnérabilités. Une fois rejetés, ces éléments conservent le statut rejeté dans les futurs pipelines et les widgets de merge request afin de maintenir un signal cohérent et fiable au fur et à mesure que le code évolue. Les équipes peuvent se concentrer sur les risques réels, rationaliser la remédiation et réduire les cycles de revue de sécurité inutiles.

Versioning des agents personnalisés

La gestion des versions des agents personnalisés donne aux équipes le contrôle sur la version d'un agent ou d'un flow du catalogue d’IA qu'elles utilisent dans leurs projets. Au lieu d'hériter automatiquement des mises à jour de l'auteur, GitLab épingle désormais chaque projet à la version exacte de l'agent et du flow activés pour l'équipe. Cette mise à jour permet d'éviter les changements cassants, les risques de sécurité et les perturbations de workflow, en particulier dans les pipelines de production ou les environnements où la sécurité est primordiale. Les équipes peuvent effectuer les mises à niveau quand elles le décident, tester les nouvelles versions en préproduction avant de les déployer, et voir clairement la version en cours d'exécution pour éviter toute confusion. La personnalisation s'en trouve également renforcée, car les utilisateurs peuvent dupliquer un agent à une version spécifique et le faire évoluer de manière indépendante. Résultat ? Une adoption plus prévisible, stable et sécurisée des agents personnalisés dans les workflows de développement et le CI/CD.

Nouveaux paramètres pour les agents de base

Les administrateurs ont désormais la possibilité d'activer ou de désactiver les agents de base afin d'offrir aux équipes un contrôle accru sur la façon dont l'IA est utilisée dans leur organisation. Avec cette mise à jour, les administrateurs peuvent activer ou désactiver ces agents au niveau de l'instance ou du groupe, choisir la disponibilité par défaut et contrôler comment les nouveaux agents sont introduits tout en offrant l'accès à l'agent principal. L'adoption de l'IA devient ainsi plus flexible, car les équipes profitent de la gouvernance, de la cohérence et du contrôle dont elles ont besoin.

L’agent Data Analyst

L’agent Data Analyst offre aux équipes un moyen simple d'explorer les données de GitLab dans un langage naturel. Il génère automatiquement des requêtes GitLab Query Language (GLQL) et récupère des informations pertinentes et claires sans nécessiter de tableaux de bord ni d'écriture manuelle de requêtes. Les utilisateurs peuvent analyser le volume de travail, comprendre l'activité de l'équipe, identifier les tendances de développement, surveiller le statut des tickets et merge requests et découvrir rapidement des éléments de travail par labels, auteurs, jalons ou autres critères. Il crée également des requêtes GLQL réutilisables qui peuvent être intégrées partout où GitLab Flavored Markdown est pris en charge afin de faciliter le partage des résultats et le traitement des questions quotidiennes sur l'activité du projet directement dans GitLab.

Core DevOps

Les innovations avec GitLab Duo Agent Platform sont plus efficaces lorsque l'expérience DevOps sous-jacente est tout aussi rationalisée et fiable. Dans la version 18.7, les améliorations apportées aux workflows GitLab principaux garantissent que l'automatisation, les pipelines et les composants réutilisables fonctionnent avec les plus hauts niveaux de clarté et de cohérence.

Sélection dynamique des intrants dans les pipelines GitLab

La sélection dynamique des intrants dans les pipelines GitLab introduit une façon plus intuitive de déclencher des pipelines via des champs déroulants dynamiques et en cascade dans l'interface utilisateur de GitLab. Avec cette fonctionnalité, les équipes interfonctionnelles peuvent exécuter des pipelines sans modifier le fichier YAML ni faire appel aux équipes de développement, et ont la garantie que seules des options valides et contextuelles sont affichées au fur et à mesure qu'elles effectuent leurs sélections. La fonctionnalité prend en charge les workflows complexes, contribue à réduire les exécutions mal configurées et supprime un obstacle majeur pour les équipes qui migrent depuis Jenkins Active Choice afin d'aider les organisations à standardiser entièrement leurs processus CI/CD sur GitLab.

Garde-fous de publication du catalogue CI/CD

Les administrateurs de GitLab Self-Managed et GitLab Dedicated peuvent désormais contrôler quels projets sont autorisés à publier des composants dans le catalogue CI/CD. Ce nouveau paramètre aide les organisations à maintenir un écosystème organisé et de confiance en s'assurant que seules les sources approuvées peuvent ajouter des composants. Il renforce la gouvernance pour les clients qui souhaitent préserver le contrôle sur leur paysage CI/CD et aide les équipes à découvrir et à réutiliser des composants approuvés.

Sécurité de la plateforme

À mesure que l’automatisation et les workflows de pipelines deviennent plus efficaces, il est essentiel que les équipes maintiennent une forte visibilité et un contrôle sur la façon dont les modifications de code respectent les standards de l'organisation. La mise à jour de la sécurité de la plateforme dans la version 18.7 renforce cet équilibre : les équipes profitent d'une approche plus flexible pour introduire et affiner les politiques de sécurité sans interrompre la livraison.

Mode avertissement pour les politiques d'approbation des merge requests

Le mode avertissement pour les politiques d'approbation des merge requests permet de signaler les violations sans bloquer les merges. Il s'agit d'un moyen moins contraignant pour les équipes d'introduire ou d’ajuster les politiques et d'évaluer leur impact avant une application complète. Il prend également en charge une approche guidée, où les équipes de développement peuvent examiner ou rejeter les violations, toutes les actions étant auditées pour aider l'AppSec à affiner l'efficacité des politiques. Au-delà des merge requests, les violations déjà présentes ou introduites dans la branche par défaut apparaissent désormais avec un badge dans le rapport de vulnérabilités afin de faciliter l'identification et la priorisation des tickets qui enfreignent la politique.

Élever la façon dont les équipes construisent, sécurisent et livrent des logiciels

La version 18.7 vise à renforcer les fondations pour une automatisation fiable et flexible dans votre environnement GitLab.

Les utilisateurs de GitLab Premium et GitLab Ultimate peuvent commencer à utiliser ces capacités dès aujourd'hui sur GitLab.com et dans les environnements auto-hébergés, avec une disponibilité pour les clients GitLab Dedicated prévue pour le mois prochain.

GitLab Duo Agent Platform est actuellement disponible en version bêta : activez les fonctionnalités bêta et expérimentales pour découvrir comment l'IA en contexte complet peut transformer la façon dont vos équipes construisent des logiciels. Nouveau sur GitLab ? Démarrez votre essai gratuit et découvrez pourquoi l'avenir du développement est alimenté par l'IA, sécurisé et orchestré via la plateforme DevSecOps la plus complète au monde.

Remarque : les fonctionnalités de la plateforme en version bêta sont disponibles dans le cadre du programme GitLab Beta. Elles sont gratuites pendant la période bêta, et lorsqu'elles seront en disponibilité générale, elles seront proposées avec une option à la demande payante avec GitLab Duo Agent Platform.

Maintenez votre instance GitLab à jour

Pour vous assurer de bénéficier des dernières fonctionnalités, mises à jour de sécurité et améliorations de performances, nous vous recommandons de maintenir votre instance GitLab à jour.

Les ressources suivantes peuvent vous aider à planifier et à effectuer votre mise à niveau :

• Outil de chemin d’accès de mise à niveau : indiquez votre version actuelle et consultez les étapes de mise à niveau à suivre pour votre instance.
• Documentation de mise à niveau : guides détaillés pour chaque version prise en charge, y compris les prérequis, les instructions étape par étape et les meilleures pratiques à suivre.

En effectuant des mises à niveau régulières, vous vous assurez que votre équipe bénéficie des dernières fonctionnalités de GitLab ainsi que d'une sécurité et d'une prise en charge optimales.

Pour les organisations qui privilégient une approche autonome, pourquoi ne pas faire appel à GitLab Managed Maintenance. Avec GitLab Managed Maintenance, votre équipe se concentre sur l'innovation tandis que les experts GitLab gèrent les mises à niveau de votre instance GitLab Self-Managed afin d'assurer la fiabilité, la sécurité et l'efficacité de vos processus DevSecOps. Contactez votre gestionnaire de compte pour obtenir plus d'informations.

Cet article de blog contient des déclarations de nature prospective au sens de la Section 27A du Securities Act de 1933, telle que modifiée, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous pensions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou conséquences sensiblement différents. De plus amples informations sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos documents déposés auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de publication de cet article de blog, sauf si la loi l'exige.

Dans cet article, vous découvrirez comment nous avons construit un pipeline de déploiement automatisé en utilisant les fonctionnalités principales de GitLab CI/CD afin de gérer cette complexité de déploiement.

L'impératif métier de la vélocité de déploiement

Pour GitLab, la fréquence de déploiement ne représente pas simplement un indicateur technique, il s'agit au contraire d'un impératif métier. Des cycles de déploiement rapides nous permettent de répondre aux retours clients en quelques heures, de déployer immédiatement des correctifs de sécurité et de valider les nouvelles fonctionnalités en production avant de les déployer à grande échelle.

Pour nos clients, chaque déploiement vers GitLab.com valide les pratiques de déploiement que nous recommandons à nos utilisateurs. Lorsque vous utilisez les fonctionnalités de déploiement de GitLab, vous utilisez la même approche éprouvée qui gère quotidiennement des millions d'opérations git, de pipelines CI/CD et d'interactions utilisateurs. Vous bénéficiez ainsi des avantages suivants :

• Disponibilité immédiate des dernières fonctionnalités : les nouvelles fonctionnalités vous parviennent quelques heures après leur finalisation, et non dans des cycles trimestriels.
• Fiabilité éprouvée à grande échelle : si une fonctionnalité fonctionne sur GitLab.com, il en ira de même pour votre environnement.
• Valeur complète de GitLab : les déploiements sans interruption garantissent un accès constant à votre plateforme DevOps, même pendant les mises à jour.
• Pratiques testées en conditions réelles : notre documentation de déploiement ne relève pas de la théorie et reflète exactement la manière dont nous exploitons la plus grande instance GitLab existante.

Architecture du flux de code

Notre pipeline de déploiement suit une progression structurée à travers plusieurs étapes, chacune agissant comme un point de contrôle sur le parcours allant de la proposition de code au déploiement en production.

  graph TD
      A[Code proposé] --> B[Merge request créée]
      B --> C[Pipeline déclenché]
      C --> D[Build et test]
      D --> E{Spécifications/intégration/tests QA réussis ?}
      E -->|Non| F[Boucle de rétroaction]
      F --> B
      E -->|Oui| G[Merge vers la branche par défaut]
      G -->|Périodiquement| H[Branche déployée automatiquement]

      subgraph "Pipeline de déploiement"
          H --> I[Création de paquet]
          I --> K[Environnement canari]
          K --> L[Validation QA]
          L --> M[Environnement principal]

      end

Composition du pipeline de déploiement

Notre approche de déploiement utilise les capacités CI/CD natives de GitLab afin d'orchestrer des déploiements complexes sur une infrastructure hybride. Voici comment nous procédons.

Build

Le build de GitLab constitue en soi un sujet complexe, c'est pourquoi nous en aborderons les détails à un niveau général.

Nous construisons à la fois notre paquet Omnibus et nos images Cloud Native GitLab (CNG). Les paquets Omnibus se déploient sur notre flotte Gitaly (notre couche de stockage Git), tandis que les images CNG exécutent tous les autres composants sous forme de charges de travail conteneurisées. D'autres services dynamiques comme Postgres et Redis ont pris une telle ampleur que nous disposons d'équipes dédiées qui les gèrent séparément. Pour GitLab.com, ces systèmes ne sont pas déployés lors de nos procédures de déploiement automatique.

Nous disposons d'un pipeline planifié qui examine régulièrement gitlab-org/gitlab et recherche le commit le plus récent sur la branche par défaut avec un pipeline réussi (« vert »). Les pipelines verts signalent que chaque composant de GitLab a réussi sa suite de tests complète. Nous créons ensuite une branche déployée automatiquement à partir de ce commit.

Une séquence d'événements est déclenchée : nous devons construire ce paquet et tous les composants qui font partie de notre monolithe. Un autre pipeline planifié sélectionne le dernier paquet construit et initie le pipeline de déploiement, ce qui ressemble à ceci :

  graph LR
      A[Créer une branche] --> B[Build]
      B --> C[Choisir le paquet construit]
      C --> D[Démarrer le pipeline de déploiement]

Le build prend un certain temps et, étant donné que les déploiements peuvent varier en raison de diverses circonstances, nous choisissons le dernier build à déployer. Techniquement, nous construisons plus de versions de GitLab pour GitLab.com que nous n'en déploierons jamais. Cela nous permet de toujours disposer d'un paquet prêt à être utilisé, ce qui nous rapproche le plus possible d'un produit entièrement livré en continu pour GitLab.com.

Validation basée sur l'environnement et stratégie canari

L'assurance qualité (QA) ne constitue pas ici une simple réflexion après coup : elle est intégrée à chaque couche, du développement au déploiement. Notre processus QA exploite des suites de tests automatisées qui incluent des tests unitaires, des tests d'intégration et des tests de bout en bout qui simulent les interactions réelles des utilisateurs avec les fonctionnalités de GitLab. Mais plus important encore pour notre pipeline de déploiement, notre processus QA fonctionne en synergie avec notre stratégie canari via une validation basée sur l'environnement .

Dans le cadre de notre approche de validation, nous exploitons les déploiements canari natifs de GitLab. Ces derniers permettent une validation contrôlée des modifications avec une exposition limitée au trafic avant le déploiement complet en production. Environ 5 % de l'ensemble du trafic passe par l'étape canari. Cette approche augmente la complexité des migrations de base de données, mais des étapes canari réussies garantissent le déploiement d'un produit fiable de manière transparente.

Les fonctionnalités de déploiement canari que vous utilisez dans GitLab ont été affinées grâce à la gestion de l'un des scénarios de déploiement les plus complexes en production. Lorsque vous implémentez des déploiements canari pour vos applications, vous utilisez des modèles éprouvés à très grande échelle. Notre processus de déploiement suit une stratégie de déploiement progressif :

1. Préproduction canari : environnement de validation initial
2. Production canari : trafic de production limité
3. Préproduction environnement principal : déploiement complet de l'environnement de préproduction
4. Production environnement principal : déploiement complet en production

  graph TD
      C[Déploiement préproduction canari]
      C --> D[QA – smoke tests étape environnement principal]
      C --> E[QA – smoke tests étape canari]
      D --> F
      E --> F{Tests réussis ?}
      F -->|Oui| G[Déploiement production canari]
      G --> S[QA – smoke tests étape environnement principal]
      G --> T[QA – smoke tests étape canari]
      F -->|Non| H[Création de ticket]
      H --> K[Correction et rétroportage]
      K --> C

      S --> M[Surveillance trafic canari]
      T --> M[Période de stabilisation surveillance trafic canari]
      M --> U[Vérifications de sécurité production]
      U --> N[Préproduction environnement principal]
      N --> V[Production environnement principal]

Notre validation QA intervient à plusieurs points de contrôle tout au long de ce processus de déploiement progressif : après chaque déploiement canari, puis de nouveau après les migrations post-déploiement. Cette approche multi-couches garantit que chaque phase de notre stratégie de déploiement dispose de son propre filet de sécurité. Vous pouvez en apprendre davantage sur l'approche de test complète de GitLab dans notre handbook.

Pipeline de déploiement

Voici les défis que nous relevons avec notre pipeline de déploiement.

Considérations relatives à l'architecture technique

GitLab.com représente une complexité de déploiement réelle à grande échelle. En tant que plus grande instance GitLab connue, les déploiements utilisent notre chart Helm GitLab officiel et le paquet Linux officiel, soit les mêmes artefacts que nos clients utilisent. Vous pouvez en apprendre davantage sur l'architecture de GitLab.com dans notre manuel. Cette approche hybride signifie que notre pipeline de déploiement doit gérer intelligemment à la fois les services conteneurisés et les services Linux traditionnels au sein du même cycle de déploiement.

Utilisation de nos fonctionnalités à grande échelle (dogfooding) : nous déployons en utilisant les mêmes procédures que nous documentons pour les mises à niveau sans temps d’arrêt. Si certaines fonctionnalités ne fonctionnent pas correctement pour nous, nous ne les recommandons pas à nos clients. Cette contrainte que nous nous imposons stimule l'amélioration continue de nos outils de déploiement.

Les étapes suivantes sont exécutées pour toutes les mises à niveau d'environnement et d'étape :

  graph LR
      a[Préparation] --> c[Migrations régulières – étape canari uniquement]
      a --> f[Actifs – étape canari uniquement]
      c --> d[Gitaly]
      d --> k8s

      subgraph subGraph0["Charges de travail MV"]
        d["Gitaly"]
      end

      subgraph subGraph1["Charges de travail Kubernetes"]
        k8s["k8s"]
      end

      subgraph fleet["Flotte"]
        subGraph0
        subGraph1
      end

Détails des étapes :

• Préparation : cette étape valide la préparation du déploiement et effectue des vérifications de pré-déploiement.
• Migrations : cette étape exécute les migrations régulières de base de données, uniquement pendant l'étape canari. Étant donné que les étapes canari et environnement principal partagent la même base de données, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie, ce qui signifie qu'il n'est plus nécessaire de répéter ces tâches.
• Actifs : nous exploitons un bucket GCS pour tous les actifs statiques. Si de nouveaux actifs sont créés, nous les importons vers notre bucket de sorte qu'ils soient immédiatement disponibles pour notre étape canari. Comme nous exploitons WebPack pour les actifs et utilisons correctement les SHA dans le nommage de nos actifs, nous pouvons être sûrs que nous n'écrasons pas un actif plus ancien. Par conséquent, les anciens actifs restent disponibles pour les déploiements plus anciens et les nouveaux actifs sont immédiatement disponibles lorsque l'étape canari commence son déploiement. Cela se produit uniquement pendant le déploiement de l'étape canari. Étant donné que l'étape canari et l'étape environnement principal partagent le même stockage d'actifs, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie.
• Gitaly : cette étape met à jour la couche de stockage de la machine virtuelle Gitaly via notre paquet Linux Omnibus sur chaque nœud Gitaly. Ce service est unique car nous le regroupons avec git. Par conséquent, nous devons garantir que ce service soit capable de procéder à des mises à niveau atomiques. Nous exploitons un encapsuleur autour de Gitaly, qui nous permet d'installer une version plus récente de Gitaly et d'utiliser la bibliothèque tableflip afin de faire pivoter proprement le Gitaly en cours d'exécution, et de garantir la haute disponibilité de ce service sur chacune de nos instances.
• Kubernetes : déploie les composants GitLab conteneurisés via notre chart Helm. Notez que nous déployons sur de nombreux clusters répartis sur plusieurs zones pour des questions de redondance, ces étapes sont donc généralement divisées en leurs propres étapes afin de minimiser les dommages et de nous permettent d'arrêter un déploiement en cours si des problèmes critiques sont détectés.

Compatibilité multi-versions : le défi caché

À la lecture de nos processus, vous remarquerez qu'il existe une période pendant laquelle notre schéma de base de données est en avance sur le code que l'étape environnement principal connaît. Cette situation se produit parce que l'étape canari a déjà déployé le nouveau code et exécute des migrations régulières de base de données, mais l'étape environnement principal exécute toujours la version précédente du code qui ne connaît pas encore ces nouvelles modifications de base de données.

Exemple concret : imaginons que nous ajoutons un nouveau champ merge_readiness aux merge requests. Pendant le déploiement, certains serveurs exécutent du code qui s'attend à ce champ, tandis que d'autres ignorent son existence. Si nous gérons mal cette situation, GitLab.com sera inutilisable pour des millions d'utilisateurs. Si nous la gérons bien, personne ne remarquera quoi que ce soit.

Cette situation se produit également avec la plupart des autres services. Par exemple, si un client envoie plusieurs requêtes, il est possible que l'une d'entre elles aboutisse dans notre étape canari ; d'autres requêtes pourraient être dirigées vers l'étape environnement principal. Ce n'est pas très différent d'un déploiement, car il faut un temps considérable pour parcourir les quelques milliers de pods qui exécutent nos services.

À quelques exceptions près, la grande majorité de nos services exécutera une version légèrement plus récente de ce composant dans l'étape canari pendant une certaine période. Dans un sens, ces scénarios sont tous des états transitoires. Mais ils peuvent souvent persister pendant plusieurs heures ou jours dans un environnement de production actif. Par conséquent, nous devons les traiter avec le même soin que les états permanents. Pendant tout déploiement, plusieurs versions de GitLab s'exécutent simultanément, et elles doivent toutes cohabiter harmonieusement.

Opérations de base de données

Les migrations de base de données présentent un défi unique dans notre modèle de déploiement canari. Nous avons besoin de modifier le schéma afin de prendre en charge les nouvelles fonctionnalités et de maintenir notre capacité à effectuer un retour à la version précédente si des problèmes surviennent. Notre solution implique une séparation minutieuse des préoccupations :

• Migrations régulières : exécutées pendant l'étape canari, conçues pour être rétrocompatibles, constituées uniquement de modifications réversibles.
• Migrations post-déploiement : les migrations « point de non-retour » qui se produisent uniquement après plusieurs déploiements réussis.

Les modifications de base de données sont gérées avec précision et selon des procédures de validation approfondies :

  graph LR
      A[Migrations régulières] --> B[Déploiement étape canari]
      B --> C[Déploiement étape environnement principal]
      C --> D[Migrations post-déploiement]

Migrations post-déploiement

Les déploiements GitLab impliquent de nombreux composants. La mise à jour de GitLab n'est pas atomique, c'est pourquoi de nombreux composants doivent être rétrocompatibles.

Les migrations post-déploiement contiennent souvent des modifications qui ne peuvent pas être facilement annulées, comme les transformations de données, les suppressions de colonnes ou les modifications structurelles qui entraîneraient une rupture dans les versions de code plus anciennes. En les exécutant après plusieurs déploiements réussis, nous garantissons les aspects suivants :

1. Le nouveau code est stable et il est peu probable que nous ayons besoin de devoir retourner à la version précédente.
2. Les caractéristiques de performance sont bien comprises en production.
3. Tous les cas marginaux ont été découverts et traités.
4. Le rayon d'impact est minimisé en cas de problème.

Cette approche offre un équilibre optimal entre un déploiement rapide des fonctionnalités via les releases canari et des capacités de retour à la version précédente jusqu'à ce que nous ayons suffisamment confiance dans la stabilité du déploiement.

Modèle étendre-migrer-réduire : nos modifications de compatibilité de base de données, frontend et application suivent une approche en trois phases soigneusement orchestrée.

1. Étendre : ajouter de nouvelles structures (colonnes, index) tout en gardant les anciennes fonctionnelles.
2. Migrer : déployer le nouveau code d'application qui utilise les nouvelles structures.
3. Réduire : supprimer les anciennes structures dans les migrations post-déploiement une fois que tout est stable.

Exemple concret : lors de l'ajout d'une nouvelle colonne merge_readiness aux merge requests :

1. Étendre : ajouter la nouvelle colonne avec une valeur par défaut ; le code existant l'ignore.
2. Migrer : déployer le code qui lit et écrit dans la nouvelle colonne tout en prenant en charge l'ancienne approche.
3. Réduire : après plusieurs déploiements réussis, supprimer l'ancienne colonne dans une migration post-déploiement

Toutes les opérations de base de données, le code d'application, le code frontend et bien d'autres, sont soumis à un ensemble de directives que les équipes d’ingénieries doivent respecter, que vous pouvez consulter dans notre documentation sur la compatibilité multi-versions.

Résultats et impact

Notre infrastructure de déploiement offre des avantages mesurables :

Pour GitLab

• Jusqu'à 12 déploiements quotidiens sur GitLab.com
• Déploiements sans temps d’arrêt au service de millions de développeurs
• Application de correctifs de sécurité en production en quelques heures au lieu de plusieurs jours
• Nouvelles fonctionnalités validées en production à grande échelle avant la disponibilité générale

Pour nos clients

• Modèles de déploiement éprouvés que vous pouvez adopter pour vos propres applications
• Fonctionnalités testées en conditions réelles sur la plus grande instance GitLab au monde avant d'atteindre votre environnement
• Documentation qui reflète les pratiques de production réelles, et non des bonnes pratiques théoriques
• Fiabilité des procédures de mise à niveau recommandées par GitLab à toute échelle

Points clés pour les équipes d'ingénierie

Le pipeline de déploiement de GitLab représente un système sophistiqué qui met en jeu la vélocité de déploiement et la fiabilité opérationnelle. Le modèle de déploiement progressif, l'intégration complète des tests et les capacités robustes de retour à la version précédente fournissent une base pour une livraison logicielle fiable à grande échelle.

Les équipes d'ingénierie qui implémentent des systèmes similaires doivent avoir les points clés suivants en tête :

• Tests automatisés : couverture de tests complète tout au long du pipeline de déploiement
• Déploiement progressif : déploiements par étapes afin de minimiser les risques et permettre une récupération rapide
• Intégration de la surveillance : observabilité complète à travers toutes les étapes de déploiement
• Réponse aux incidents : capacités de détection et de résolution rapides pour les problèmes de déploiement

L'architecture de GitLab démontre comment des systèmes CI/CD modernes peuvent gérer la complexité de déploiements à grande échelle tout en maintenant la vélocité requise pour un développement logiciel compétitif.

Note importante sur la portée

Cet article couvre spécifiquement le pipeline de déploiement pour les services qui font partie du paquet GitLab Omnibus et du chart Helm, soit le monolithe GitLab principal et ses composants étroitement intégrés.

Cependant, le paysage d'infrastructure de GitLab s'étend au-delà de ce qui est décrit ici. D'autres services, notamment nos services d'IA et les services qui pourraient faire partie d'une étude de faisabilité, suivent une approche de déploiement différente au moyen de notre plateforme interne Runway.

Si vous travaillez avec ces services ou souhaitez en savoir plus, vous pouvez obtenir plus d'informations dans notre documentation dédiée à Runway.

D'autres offres, telles que GitLab Dedicated, sont déployées de manière plus alignée avec ce que nous attendons que les clients soient capables de réaliser eux-mêmes au moyen de GitLab Environment Toolkit. Si vous souhaitez en savoir plus, consultez le projet GitLab Environment Toolkit.

Les stratégies de déploiement, les considérations architecturales et les complexités de pipeline décrites dans cet article représentent l'approche éprouvée que nous utilisons pour notre plateforme principale, mais comme toute grande organisation d'ingénierie, nous disposons de plusieurs stratégies de déploiement adaptées aux différents types de services et niveaux de maturité.

Pour plus de documentation sur le déploiement automatique et nos procédures, vous pouvez consulter les liens ci-dessous :

• Déploiements d'ingénierie
• Documentation sur les procédures de release

Les victimes ont signalé avoir reçu de fausses invitations à des entretiens, des offres d'emploi et des documents d'intégration, souvent suivis de demandes de paiement ou d'informations personnelles. Ces campagnes ne sont en aucun cas affiliées à GitLab.

Les nouveautés de cette vague

Les incidents récents se distinguent des escroqueries précédentes par l'introduction de nouveaux domaines et tactiques, notamment :

• L'utilisation de domaines non autorisés tels que gitlab[.]careers et careers-gitlab[.]com
• Des références à de fausses certifications comme « CPD USA Certification »
• De faux profils de recruteurs sur LinkedIn et Teams usurpant l'identité du personnel RH de GitLab
• Des demandes d'informations sensibles ou de paiements anticipés pour « l'équipement » après de faux entretiens

Ces usurpateurs deviennent de plus en plus sophistiqués, utilisant des e-mails professionnels, des lettres d'offre d'apparence authentique et des invitations réalistes à des entretiens vidéo.

Signaux d'alerte courants

Les candidats doivent faire preuve de prudence s'ils rencontrent l'un des éléments suivants :

• Le domaine de messagerie n'est pas @gitlab.com (par exemple, Gmail, Outlook ou un domaine ressemblant).
• Le recruteur vous demande de payer pour de l'équipement, une certification ou des vérifications d'antécédents.
• La communication se fait uniquement par chat, sans invitations calendrier vérifiées de GitLab.
• L'offre d'emploi n'apparaît pas sur la page carrière officielle de GitLab.
• Le recruteur refuse de prouver son identité via une adresse GitLab.com ou vous dirige vers des URL externes non liées à GitLab.

Le processus de recrutement officiel de GitLab

Le processus de recrutement de GitLab est entièrement à distance mais transparent et vérifiable.

• Toutes les communications proviennent d'adresses de messagerie officielles @gitlab.com.
• Les entretiens sont menés via Zoom, et non Microsoft Teams ou WhatsApp.
• GitLab ne demande jamais de paiement, d'achats ou de frais de certification pendant le recrutement.
• Les offres légitimes et les étapes d'intégration sont gérées de manière sécurisée via les systèmes GitLab.

Pour plus de détails sur notre processus de recrutement, veuillez consulter notre manuel du candidat.

Les mesures prises par GitLab

Les équipes Sécurité et Ressources humaines de GitLab enquêtent activement et signalent les faux domaines et profils de recrutement aux fournisseurs d'hébergement et réseaux sociaux. Nous continuons à collaborer avec nos partenaires juridiques, de communication et de plateforme pour supprimer le contenu frauduleux et informer les personnes concernées.

Si vous remarquez quelque chose de suspect, informez-nous à l'adresse security@gitlab.com. Toute personne peut signaler une activité de recrutement suspecte pour examen par notre équipe de réponse aux incidents de sécurité.

Comment vous protéger

Si vous recevez une communication suspecte prétendant provenir de GitLab :

1. Vérifiez le domaine de messagerie de l'expéditeur : il doit toujours se terminer par @gitlab.com.
2. Consultez les offres d'emploi directement sur about.gitlab.com/jobs.
3. Évitez d'envoyer des informations personnelles ou financières à des recruteurs non vérifiés.
4. Signalez tout domaine ou message suspect à security@gitlab.com.

Pour des informations supplémentaires sur la façon d'éviter les escroqueries à l'emploi, consultez ces ressources fiables :

• Manuel du candidat
• Ressources sur les escroqueries à l'emploi en ligne – FTC

Si vous pensez avoir été ciblé par un faux recruteur GitLab, veuillez le signaler immédiatement à security@gitlab.com afin que notre équipe puisse enquêter.

Vue d'ensemble

GitLab propose à la fois Congregate (maintenu par les Services professionnels de GitLab) et une importation intégrée des dépôts Git pour migrer des projets depuis Azure DevOps (ADO). Ces options prennent en charge la migration dépôt par dépôt ou de façon groupée et préservent l'historique des commits git, les branches et les tags. Elles prennent également en charge des éléments supplémentaires tels que les wikis, les éléments de travail, les variables CI/CD, les images de conteneurs, les paquets, les pipelines et bien plus encore (matrice de fonctionnalités). Utilisez ce guide pour planifier et exécuter votre migration, puis accomplir les tâches de suivi post-migration.

Les entreprises qui migrent d'Azure DevOps vers GitLab suivent généralement une approche en plusieurs étapes :

• Elles migrent les dépôts d'Azure DevOps vers GitLab à l'aide de Congregate ou de la migration de dépôt intégrée à GitLab.
• Elles migrent les pipelines d'Azure Pipelines vers GitLab CI/CD.
• Elles migrent les éléments restants tels que les tableaux, les éléments de travail et les artefacts vers les tickets, registres de paquets et de conteneurs GitLab.

Phases de migration principales :

graph LR
    subgraph Prérequis
        direction TB
        A["Configurer le fournisseur d'identité (IdP)<br/>et provisionner les utilisateurs"]
        A --> B["Configurer les runners et<br/>les intégrations tierces"]
        B --> I["Former les utilisateurs et<br/>gérer le changement"]
    end
    
    subgraph MigrationPhase["Phase de migration"]
        direction TB
        C["Migrer le code source"]
        C --> D["Préserver les contributions et<br/>l'historique du format"]
        D --> E["Migrer les éléments de travail,<br/>mapper vers <a href="https://docs.gitlab.com/topics/plan_and_track/">GitLab Plan<br/>et suivre le travail"]
    end
    
    subgraph PostMigration["Étapes post-migration"]
        direction TB
        F["Créer ou traduire les<br/>pipelines ADO vers GitLab CI"]
        F --> G["Migrer les autres actifs,<br/>paquets et images de conteneurs"]
        G --> H["Introduire des améliorations SDLC et de <a href="https://docs.gitlab.com/user/application_security/secure_your_application/">sécurité</a><br/>"]
    end
    
    Prérequis --> MigrationPhase
    MigrationPhase --> PostMigration

    style A fill:#FC6D26
    style B fill:#FC6D26
    style I fill:#FC6D26
    style C fill:#8C929D
    style D fill:#8C929D
    style E fill:#8C929D
    style F fill:#FFA500
    style G fill:#FFA500
    style H fill:#FFA500

Planifiez votre migration

Pour planifier votre migration, posez-vous ces questions :

• Dans quels délais devons-nous achever la migration ?
• Comprenons-nous ce qui sera migré ?
• Qui exécutera la migration ?
• Quelle structure organisationnelle souhaitons-nous mettre en place dans GitLab ?
• Existe-t-il des contraintes, limitations ou pièges à prendre en compte ?

Déterminez votre calendrier, car il dictera en grande partie votre approche de migration. Identifiez des spécialistes ou des groupes familiarisés avec les plateformes Azure DevOps et GitLab (comme les « Early adopters ») pour faciliter l'adoption et fournir des conseils.

Faites l'inventaire de ce que vous devez migrer :

• Le nombre de dépôts, de pull requests et de contributeurs
• Le nombre et la complexité des éléments de travail et des pipelines
• Les tailles de dépôts et les relations de dépendance
• Les intégrations critiques et les exigences relatives aux runners (pools d'agents dotés de capacités spécifiques)

Utilisez l'outil Evaluate des Services professionnels de GitLab pour produire un inventaire complet de toute votre organisation Azure DevOps avec les dépôts, le nombre de pull requests, les listes de contributeurs, le nombre de pipelines, les éléments de travail, les variables CI/CD et bien plus encore. Si vous travaillez avec l'équipe des Services professionnels de GitLab, partagez ce rapport avec votre responsable de mission ou votre architecte technique pour faciliter la planification de la migration.

Le calendrier de migration est principalement déterminé par le nombre de pull requests, la taille des dépôts et le volume de contributions (par exemple, les commentaires dans les pull requests, les éléments de travail, etc.). 1 000 petits dépôts avec un nombre limité de pull requests et de contributeurs peuvent migrer beaucoup plus rapidement qu'un ensemble plus restreint de dépôts contenant des dizaines de milliers de pull requests et des milliers de contributeurs. Utilisez vos données d'inventaire pour estimer l'effort et planifier des tests avant de procéder aux migrations de production.

Comparez l'inventaire avec le calendrier souhaité et décidez si vous allez migrer tous les dépôts à la fois ou par lots. Si les équipes ne peuvent pas migrer simultanément, organisez les migrations par lots et échelonnez-les pour vous aligner sur les calendriers des équipes. Par exemple, lors des missions des Services professionnels, nous organisons des migrations par vagues de 200 à 300 projets pour limiter la complexité et respecter les limites de débit des API, à la fois dans GitLab et ADO.

L'outil d'importation de dépôt intégré de GitLab migre les dépôts Git (commits, branches et tags) un par un. Congregate est conçu pour préserver les pull requests (appelées merge requests dans GitLab), les commentaires et les métadonnées associées lorsque cela est possible ; l'importation simple de dépôt intégrée se concentre uniquement sur les données Git (historique, branches et tags).

Éléments nécessitant généralement une migration distincte ou une recréation manuelle :

• Pipelines Azure : créez des pipelines GitLab CI/CD équivalents (consultez la documentation YAML CI/CD et/ou les composants CI/CD). Vous pouvez également envisager d'utiliser la conversion de pipelines basée sur l'IA disponible dans Congregate.
• Éléments de travail et tableaux : mappez-les vers les tickets, epics et tableaux de tickets de GitLab.
• Artefacts, images de conteneurs (ACR) : migrez-les vers le registre de paquets ou le registre de conteneurs de GitLab.
• Hooks de service et intégrations externes : recréez-les dans GitLab.
• Les modèles de permissions diffèrent entre ADO et GitLab ; examinez et planifiez le mappage des permissions plutôt que de supposer une préservation exacte.

Examinez ce que chaque outil (Congregate vs importation intégrée) va migrer et choisissez celui qui correspond à vos besoins. Dressez une liste de toutes les données ou intégrations qui doivent être migrées ou recréées manuellement.

Qui exécutera la migration ?

Les migrations sont généralement exécutées par un propriétaire de groupe GitLab ou un administrateur d'instance, ou par une personne désignée ayant obtenu les permissions nécessaires relatives au groupe/projet de destination. Congregate et les API d'importation GitLab nécessitent des tokens d'authentification valides pour Azure DevOps et GitLab.

• Décidez si un propriétaire/administrateur de groupe effectuera les migrations ou si vous accorderez un accès délégué à une équipe/personne spécifique.
• Assurez-vous que la personne dédiée à la migration a correctement configuré les tokens d'accès personnels (Azure DevOps et GitLab) avec les portées requises par votre outil de migration choisi (par exemple, les portées api/read_repository et toute exigence spécifique à l'outil).
• Testez les tokens et les permissions avec une petite migration pilote.

Remarque : Congregate exploite la fonctionnalité d'importation basée sur des fichiers pour les migrations ADO et nécessite des permissions d'administrateur d'instance pour s'exécuter (consultez notre documentation). Si vous migrez vers GitLab.com, envisagez de faire appel aux Services professionnels. Pour plus d'informations, consultez leur catalogue complet. Un compte non-administrateur ne peut pas préserver l'attribution des contributions !

Quelle structure organisationnelle souhaitons-nous dans GitLab ?

Bien qu'il soit possible de mapper directement la structure ADO vers la structure GitLab, il est recommandé de rationaliser et de simplifier la structure pendant la migration. Réfléchissez à la façon dont les équipes travailleront dans GitLab et concevez la structure de façon à faciliter la collaboration et la gestion des accès. Voici un exemple de mappage de la structure ADO vers la structure GitLab :

graph TD
    subgraph GitLab
        direction TB
        A["Groupe principal"]
        B["Sous-groupe (facultatif)"]
        C["Projets"]
        A --> B
        A --> C
        B --> C
    end

    subgraph AzureDevOps["Azure DevOps"]
        direction TB
        F["Organisations"]
        G["Projets"]
        H["Dépôts"]
        F --> G
        G --> H
    end

    style A fill:#FC6D26
    style B fill:#FC6D26
    style C fill:#FC6D26
    style F fill:#8C929D
    style G fill:#8C929D
    style H fill:#8C929D

Approche recommandée :

• Mappez chaque organisation ADO à un groupe GitLab (ou un petit ensemble de groupes), et non à de nombreux petits groupes. Évitez de créer un groupe GitLab pour chaque projet d'équipe ADO et utilisez la migration comme une opportunité de rationaliser votre structure GitLab.
• Utilisez des sous-groupes et des permissions au niveau du projet pour regrouper les dépôts associés.
• Gérez l'accès à des ensembles de projets en utilisant les groupes et l'appartenance aux groupes (groupes et sous-groupes) de GitLab plutôt qu'un groupe par projet d'équipe.
• Examinez les permissions de GitLab et utilisez les liens de groupe SAML pour mettre en œuvre un modèle de contrôle d'accès basé sur les rôles (RBAC) d'entreprise pour votre instance GitLab (ou un espace de nommage GitLab.com).

Tableaux ADO et éléments de travail : état de la migration

Il est important de comprendre comment les éléments de travail migrent d'ADO vers GitLab Plan (tickets, epics et tableaux).

• Les tableaux et éléments de travail ADO sont mappés vers les tickets, epics et tableaux de tickets de GitLab. Planifiez comment vos workflows et configurations de tableaux seront migrés.
• Les epics et fonctionnalités ADO deviennent des epics GitLab.
• Les autres types d'éléments de travail (user stories, tâches, bogues) deviennent des tickets au niveau du projet.
• La plupart des champs standard sont préservés ; certains champs personnalisés sélectionnés peuvent être migrés lorsqu'ils sont pris en charge.
• Les relations parent-enfant sont conservées afin que les epics référencent tous les tickets associés.
• Les liens vers les pull requests sont convertis en liens de merge requests pour maintenir la traçabilité du développement.

Exemple d'une migration d'un élément de travail individuel vers un ticket GitLab, avec conservation des champs et relations :

Conseils pour la migration par lots :

• Si vous devez exécuter des migrations par lots, utilisez votre nouvelle structure de groupe/sous-groupe pour définir les lots (par exemple, par organisation ADO ou par domaine produit).
• Utilisez les rapports d'inventaire pour orienter la sélection des lots et testez chaque lot avec une migration pilote avant d'effectuer la migration complète.

Migration des pipelines

Congregate a récemment introduit une conversion basée sur l'IA pour les pipelines YAML multi-étapes d'Azure DevOps vers GitLab CI/CD. Cette conversion automatisée fonctionne avant tout pour les pipelines simples avec un fichier unique et est conçue pour fournir un point de départ fonctionnel plutôt qu'un fichier .gitlab-ci.yml prêt pour la production. L'outil génère un pipeline GitLab équivalent sur le plan fonctionnel que vous pouvez ensuite affiner et optimiser selon vos besoins.

• Conversion automatique des pipelines YAML Azure au format .gitlab-ci.yml
• Mieux adapté pour les configurations de pipeline simples avec un fichier unique
• Fichier passe-partout fourni pour accélérer la migration, pas un artefact de production final
• Revue et ajustement requis pour les scénarios complexes, les tâches personnalisées ou les exigences de l'entreprise
• Pas de prise en charge de pipelines de version classiques Azure DevOps, conversion en YAML multi-étapes nécessaire

Les propriétaires de dépôts doivent consulter la documentation GitLab CI/CD pour optimiser et améliorer davantage leurs pipelines après la conversion initiale.

Exemple de pipelines convertis :

# azure-pipelines.yml

trigger:
  - main

variables:
  imageName: myapp

stages:
  - stage: Build
    jobs:
      - job: Build
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - checkout: self

          - task: Docker@2
            displayName: Build Docker image
            inputs:
              command: build
              repository: $(imageName)
              Dockerfile: '**/Dockerfile'
              tags: |
                $(Build.BuildId)

  - stage: Test
    jobs:
      - job: Test
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - checkout: self

          # Example: run tests inside the container
          - script: |
              docker run --rm $(imageName):$(Build.BuildId) npm test
            displayName: Run tests

  - stage: Push
    jobs:
      - job: Push
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - checkout: self

          - task: Docker@2
            displayName: Login to ACR
            inputs:
              command: login
              containerRegistry: '<your-acr-service-connection>'

          - task: Docker@2
            displayName: Push image to ACR
            inputs:
              command: push
              repository: $(imageName)
              tags: |
                $(Build.BuildId)

# .gitlab-ci.yml

variables:
  imageName: myapp

stages:
  - build
  - test
  - push

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .
  only:
    - main

test:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker run --rm $imageName:$CI_PIPELINE_ID npm test
  only:
    - main

push:
  stage: push
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID
    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID
  only:
    - main

Liste de contrôle finale :

• Décidez du calendrier et de la stratégie par lots.
• Produisez un inventaire complet des dépôts, pull requests et contributeurs.
• Choisissez Congregate ou l'importation intégrée en fonction de la portée (pull requests et métadonnées vs données Git uniquement).
• Décidez qui exécutera les migrations et assurez-vous que les tokens/permissions sont configurés.
• Identifiez les éléments qui doivent être migrés séparément (pipelines, éléments de travail, artefacts et hooks) et planifiez ces migrations.
• Effectuez des migrations pilotes, validez les résultats, puis passez à la migration complète selon votre calendrier.

Exécutez vos migrations

Une fois la planification terminée, exécutez les migrations par étapes, en commençant par des migrations d'essai, qui permettent de faire remonter les problèmes spécifiques à l'organisation tôt et de mesurer la durée, de valider les résultats et d'affiner votre approche avant la production.

Utilisez les migrations d'essai pour valider les éléments suivants :

• Succès de la migration d'un dépôt donné et des éléments associés (historique, branches, tags ; ainsi que les merge requests/commentaires si vous utilisez Congregate)
• Utilisation immédiate de la destination (permissions, runners, variables CI/CD, intégrations)
• Durée de chaque lot (afin de définir les calendriers et les attentes des parties prenantes)

Conseils concernant les temps d'arrêt :

• L'importation Git intégrée de GitLab et Congregate ne nécessitent pas intrinsèquement de temps d'arrêt.
• Pour les vagues de production, gelez les modifications dans ADO (protections de branches ou lecture seule) pour éviter les commits manqués, les mises à jour de pull requests ou les éléments de travail créés en cours de migration.
• Les essais n'ont pas besoin d'être gelés et peuvent être exécutés à tout moment.

Conseils pour la migration par lots :

• Exécutez des lots d'essai consécutifs pour raccourcir le temps écoulé ; laissez les équipes valider les résultats de manière asynchrone.
• Utilisez votre structure de groupe/sous-groupe planifiée pour définir les lots et respectez les limites de débit des API.

Étapes recommandées :

1. Créez une destination de test dans GitLab pour les essais :

• GitLab.com : créez un groupe/espace de nommage dédié (par exemple, my-org-sandbox).
• Instance auto-gérée : créez un groupe de niveau supérieur ou une instance de test distincte si nécessaire.

2. Préparez l'authentification :

• PAT Azure DevOps avec les portées requises.
• Token d'accès personnel GitLab avec api et read_repository (plus accès administrateur pour les importations basées sur des fichiers utilisées par Congregate).

3. Exécutez des migrations d'essai :

• Dépôts uniquement : utilisez l'importation intégrée de GitLab (dépôt par URL).
• Dépôts + pull requests/merge requests et actifs supplémentaires : utilisez Congregate.

4. Suivi post-essai :

• Vérifiez l'historique du dépôt, les branches, les tags ; les merge requests (si elles ont été migrées), les tickets/epics (s'ils ont été migrées), les labels et les relations.
• Vérifiez les permissions/rôles, les branches protégées, les approbations requises, les runners/tags, les variables/secrets, les intégrations/webhooks.
• Validez les pipelines (.gitlab-ci.yml) ou les pipelines convertis le cas échéant.

5. Demandez aux utilisateurs de valider la fonctionnalité et la fidélité des données.
6. Résolvez les problèmes découverts lors des essais et mettez à jour vos runbooks.
7. Réseau et sécurité :

• Si votre destination utilise des listes d'IP autorisées, ajoutez les IP de votre hôte de migration et tous les runners/intégrations requis afin de garantir la réussite des importations.

8. Exécutez les migrations de production par vagues :

• Appliquez des gels de modifications dans ADO pendant chaque vague.
• Surveillez la progression et les logs ; réessayez ou ajustez les tailles de lots si vous atteignez les limites de débit.

9. Facultatif : supprimez le groupe de l'environnement sandbox ou archivez-le après avoir terminé.

Références terminologiques pour GitLab et Azure DevOps

Dans cet article, découvrez le fonctionnement complet du SDLC, ses différentes phases et comment GitLab accompagne vos équipes à chaque étape du cycle de développement logiciel, avec une plateforme DevSecOps unifiée.

En résumé

Le SDLC structure le développement logiciel en phases clés : planification, développement, tests, déploiement, suivi et amélioration continue. Avec l'évolution rapide des technologies, il intègre aujourd'hui une approche itérative et DevSecOps pour allier rapidité, qualité et sécurité. GitLab centralise ces étapes grâce à un ensemble de fonctionnalités alimentées par l'IA qui facilitent la collaboration entre les différentes parties prenantes d'un projet de développement logiciel. Résultat : des cycles de livraison plus rapides, une meilleure qualité logicielle et une sécurité renforcée à chaque étape.

Comment fonctionne le SDLC ?

Le SDLC s'adapte en permanence à son environnement technologique. Actuellement, l'écosystème économique impose une rapidité d'exécution optimale. Les logiciels doivent être conçus, développés, testés, déployés et maintenus en continu, avec la sécurité intégrée à chaque étape grâce à une approche DevSecOps.

Afin de réduire les délais et d'améliorer la qualité du logiciel, son cycle de vie suit désormais une logique itérative qui prend la forme suivante :

  graph LR
      A[Planification] --> B[Développement]
      B --> C[Test]
      C --> D[Déploiement]
      D --> E[Supervision]  
      E --> F[Amélioration] 

Cette approche peut s'avérer complexe, tant elle combine d'étapes différentes interdépendantes.

Mais avec une plateforme unifiée comme GitLab, l'ensemble du cycle de développement logiciel est couvert de bout en bout.

Vos équipes peuvent ainsi travailler sur plusieurs projets simultanément, à des étapes de développement différentes, sans perdre en cohérence ni en performance.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.

Les acteurs impliqués (Dev, Ops, QA, Sec, Product Owner)

Le SDLC implique la collaboration de plusieurs acteurs clés, chacun ayant un rôle spécifique dans la réussite du projet :

• Développeurs (Dev) : ils conçoivent et écrivent le code, puis l'intègrent en continu via des pipelines CI/CD. Ils assurent la traçabilité de chaque modification et collaborent via des systèmes de gestion de versions.
• Opérations (Ops) : ils déploient, surveillent et assurent la maintenance des environnements de production. Ils collaborent étroitement avec les équipes de développement pour garantir des déploiements fluides et la stabilité des systèmes.
• Qualité (QA) : ils testent le code tout au long du cycle de développement pour identifier les anomalies le plus tôt possible. Ils mettent en place des tests (manuels ou automatisés) pour garantir la conformité aux exigences fonctionnelles.
• Sécurité (Sec) : ils effectuent des contrôles de sécurité dès les premières étapes du cycle de développement, selon le principe du « Shift Left ». Leur rôle est d'identifier les vulnérabilités et de renforcer la conformité du logiciel avant son déploiement.
• Product Owner (PO) : il définit la vision du produit et priorise les fonctionnalités à développer. Il assure la cohérence entre les besoins métiers et les réalisations techniques de toutes les équipes.

Outils et environnements typiques (CI/CD, conteneurs, etc.)

• Conteneurs Docker : ils permettent d'empaqueter les applications avec leurs dépendances dans des environnements isolés et portables, garantissant une cohérence entre le développement, les tests et la production.
• Orchestration Kubernetes : elle automatise le déploiement, la mise à l'échelle et la gestion des conteneurs en production, assurant haute disponibilité et résilience des applications.
• Pipelines CI/CD : ils automatisent les tests, la validation et le déploiement du code pour garantir une livraison continue plus rapide tout en réduisant les risques d'erreur humaine.
• Registres de conteneurs : ils stockent et versionnent les images Docker pour faciliter leur distribution et leur déploiement.

L'ensemble de ces outils et environnements est nativement intégré à la plateforme GitLab. Depuis une interface centralisée, vous supervisez l'ensemble de vos workflows DevSecOps, du code source au déploiement en production, sans avoir à jongler entre plusieurs solutions.

Quelles sont les étapes du cycle de développement logiciel ?

1. Planification et analyse des besoins

La planification est à la base de tout projet SDLC. Cette étape nécessite une communication efficace entre l'équipe de développement et les parties prenantes du projet. Ensemble, ils effectuent une analyse coût-bénéfice, en prenant en compte les attentes fonctionnelles, techniques et business du projet. L'ensemble de ces éléments est formalisé dans un document de spécification des exigences logicielles (SRS), essentiel pour structurer, organiser et suivre chaque étape du cycle de développement logiciel.

2. Étude de faisabilité

Une fois les attentes et le programme établis, il est nécessaire d'analyser les contraintes spécifiques du projet.

• Quelles sont les ressources techniques indispensables pour sa réalisation ?
• Quels sont les délais imposés ?
• Quel est le budget ?

Avec l'étude de faisabilité, les équipes évaluent les risques, planifient plus précisément les différentes étapes du projet et ajustent les attentes. La transparence doit être totale, notamment au niveau des budgets et des ressources à mobiliser. La plateforme GitLab intègre des outils de planification complets (tickets, epics, roadmaps, jalons, etc.) pour faciliter cette phase cruciale et assurer une visibilité complète sur l'avancement du projet.

3. Conception

Lors de la phase de conception, les ingénieurs logiciels procèdent à l'analyse des exigences afin d'identifier les meilleures solutions techniques pour créer le logiciel. Du choix des outils de développement (frameworks, langages, environnements) aux technologies d'infrastructure et d'architecture logicielle, les experts sélectionnent la méthode la plus optimale pour intégrer le nouveau logiciel à l'architecture informatique en place. Cette phase aboutit généralement à la création de documents de conception technique et de diagrammes d'architecture qui guideront le développement.

4. Développement

Le développement du code est une phase qui nécessite une grande rigueur. Elle se décline en plusieurs sous-étapes à respecter pour assurer la qualité et la cohérence du logiciel :

• Écriture du code source selon les standards définis lors de la phase de conception.
• Contrôle de version pour assurer une traçabilité complète des modifications.
• Tests unitaires et d'intégration pour garantir la stabilité des modules tout au long du projet.
• Documentation du code pour faciliter la compréhension de la logique et assurer la maintenabilité.

GitLab propose plusieurs fonctionnalités dédiées pour faciliter cette phase : Web IDE pour le développement en ligne, merge requests pour la revue de code collaborative, snippets pour le partage de code réutilisable, et une gestion complète du code source (SCM - Source Code Management) avec Git intégré.

5. Tests et validation

La phase de test s'effectue tout au long de la phase de développement. En effet, les équipes DevOps testent généralement leur code, immédiatement après chaque itération ou ajout de fonctionnalité. Cette approche permet de s'assurer, à chaque étape, que le code est stable, fonctionnel et sans bogue.

La phase de vérification impose également des tests de sécurité (SAST/DAST) et de conformité avec les exigences du document SRS.

Pour cela, elle combine des approches manuelles (revues de code, audits de sécurité) et des outils d'automatisation (intégration continue, pipelines CI/CD, tests automatisés).

Le reporting fait également partie intégrante du processus, afin de documenter les résultats et de garantir la traçabilité complète des tests tout au long du cycle de développement.

6. Déploiement

Les déploiements de logiciels en SDLC sont aujourd'hui largement automatisés grâce à l'intégration de pipelines CI/CD comme GitLab CI/CD.

Concrètement, le processus fonctionne de la manière suivante :

• Les équipes de développement codent et testent sur des environnements de développement isolés.
• La version de production reste accessible en continu par les utilisateurs finaux.
• Les mises à jour et nouvelles fonctionnalités sont d'abord déployées sur des environnements de test ou de préproduction.
• Via des processus d'intégration continue (CI) et de livraison continue (CD), les nouvelles versions sont automatiquement testées, validées et déployées en production.

Grâce à cette automatisation du cycle de déploiement, vous réduisez les erreurs humaines et garantissez des mises à jour continues sans interruption de service. GitLab CI/CD permet également de configurer des pipelines personnalisés avec des stratégies de déploiement avancées (Blue-Green, Canary, Rolling).

7. Maintenance et amélioration continue

Le cycle de vie d'un logiciel ne s'arrête pas à son déploiement. Il continue d'évoluer afin d'améliorer son expérience utilisateur et ses performances globales.

Cette phase repose sur deux piliers complémentaires :

• Monitoring et observabilité : surveillance en temps réel des performances, détection proactive des anomalies, collecte des métriques d'utilisation et analyse des retours utilisateurs pour identifier les axes d'amélioration.
• Maintenance et gouvernance : correction rapide des bogues détectés, application des correctifs de sécurité, optimisation continue des performances et respect des standards de conformité et de gouvernance.

GitLab intègre des fonctionnalités de monitoring (métriques, logs, traces) et de gouvernance (politiques de sécurité, audits de conformité, gestion des vulnérabilités) pour accompagner cette phase cruciale. L'objectif est de maintenir un alignement total avec les besoins des utilisateurs tout en garantissant la sécurité et la stabilité du logiciel en production.

Les 8 modèles SDLC

1. Waterfall (en cascade)

Le modèle en cascade organise les phases du cycle de vie de manière séquentielle. Chaque nouvelle phase dépend du résultat de la phase précédente. L'intérêt de cette méthode réside dans sa discipline et dans les résultats concrets et mesurables, tout au long du projet. Toutefois, le modèle Waterfall a tendance à manquer de flexibilité, car lorsqu'une phase est close, il est difficile de revenir en arrière pour apporter des modifications. C'est une approche SDLC plus adaptée aux petits projets où les exigences sont stables et bien définies dès le départ.

2. V-Model (validation et vérification)

Le V-Model est très proche du modèle Waterfall. Il s'en distingue par un système de tests planifiés à chaque étape afin de valider la conformité du développement selon les exigences initiales. C'est une version améliorée du modèle en cascade qui intègre une dimension de contrôle qualité continu dès les premières phases du projet.

3. Incremental Model (modèle incrémental)

Le modèle incrémental est constitué de plusieurs cycles successifs qui s'enchaînent de manière structurée.

Il s'appuie sur des exigences clairement définies dès le début du projet et respecte un plan de développement rigoureux. Le cycle SDLC se répète avec, à chaque fois, l'ajout de nouvelles fonctionnalités jusqu'à la livraison de la version finale.

L'originalité de ce modèle réside dans ses cycles qui se chevauchent pour permettre le développement de plusieurs modules en parallèle. Une approche flexible, mais qui peut complexifier la gestion de projet et la coordination des équipes.

4. Iterative Model (modèle itératif)

Le processus itératif organise les projets de développement logiciel en boucles successives d'amélioration.

La première itération se limite à quelques exigences fonctionnelles, la seconde en intègre davantage, et ainsi de suite. Les différentes versions du logiciel évoluent ainsi de manière itérative vers une complexité croissante jusqu'à obtenir une version finale prête pour la production.

Cette méthode se distingue par sa flexibilité, car à la fin de chaque itération, les exigences peuvent être ajustées selon les besoins et retours clients. Toutefois, ces cycles répétés peuvent entraîner un changement de direction complet du produit final et augmenter significativement les délais et les ressources allouées.

5. Spiral Model (modèle en spirale)

Le modèle en spirale combine les cycles répétitifs du modèle itératif et la linéarité du modèle en cascade. Il intègre également une dimension de gestion des risques plus marquée. En effet, il implique la création de prototypes à chaque nouvelle phase pour valider les choix techniques et fonctionnels. Il convient particulièrement aux projets complexes qui nécessitent des modifications fréquentes. Toutefois, il est coûteux et peu adapté aux projets de moindre portée.

6. Big Bang Model (modèle Big Bang)

Le modèle Big Bang est réservé aux prototypes de logiciel ou aux très petits projets. C'est un modèle à haut risque qui concentre toutes les ressources sur le développement sans planification formelle. Les exigences ne sont pas préalablement définies et approfondies. Elles sont seulement mises en œuvre lorsqu'elles se présentent en cours de développement.

7. Agile Model (modèle Agile)

Le modèle Agile intègre une approche à la fois itérative et incrémentale. C'est une méthode qui se concentre sur l'adaptabilité et la collaboration. Les phases du SDLC sont découpées en cycles courts (sprints) avec des livraisons fréquentes. L'accent est mis sur l'évaluation continue des exigences, des plans et des résultats avec une implication importante des utilisateurs. Cette implication peut toutefois être source de modifications excessives si elle n'est pas bien encadrée.

8. DevOps / DevSecOps Model (modèle DevOps et DevSecOps)

L'approche DevOps/DevSecOps promeut une gestion unifiée et automatisée du cycle de développement logiciel. GitLab illustre parfaitement ce modèle avec sa plateforme dans laquelle les équipes Dev, Sec et Ops disposent d'une vue complète de l'ensemble du SDLC pour planifier, coder, tester, déployer, améliorer et sécuriser leurs logiciels.

Les grandes évolutions apportées par ce modèle sont :

• L'intégration de la sécurité tout au long du cycle de développement logiciel (DevSecOps)
• L'automatisation des tests, déploiements et supervision
• L'utilisation de l'IA pour simplifier les tâches répétitives et accélérer le développement logiciel

Comment fonctionne le SDLC sécurisé (SSDLC) ?

Le SDLC sécurisé (SSDLC) intègre la sécurité dès les premières phases du développement logiciel, selon le principe du « Shift Left ». GitLab vous aide à mettre en œuvre le concept de Secure by Design à l'aide de scanners de sécurité nativement intégrés dans les pipelines CI/CD. Cette approche place la sécurité et la gestion des risques au cœur de la conception du projet.

À chaque étape du cycle SDLC, des contrôles de sécurité automatisés assurent une protection continue du code et des dépendances :

• Test statique de sécurité des applications (SAST) : analyse le code source avant exécution pour détecter les vulnérabilités potentielles.
• Test dynamique de sécurité des applications (DAST) : teste les applications en fonctionnement pour identifier les failles dans des environnements réels.
• Analyse des dépendances (Dependency Scanning) : vérifie les bibliothèques et dépendances pour repérer les versions vulnérables.
• Analyse des conteneurs (Container Scanning) : analyse les images de conteneurs pour détecter les failles avant le déploiement.
• Détection des secrets (Secret Detection) : détecte les secrets (clés API, mots de passe) accidentellement exposés dans le code.

Cette approche permet de réduire significativement les vulnérabilités potentielles, d'accélérer la remédiation et de renforcer la conformité réglementaire.

Accélérez votre SDLC avec GitLab

Quel que soit le modèle SDLC que vous adoptez, la réussite de vos projets reposera sur trois piliers clés : une collaboration efficace entre équipes, une automatisation des processus et une sécurité intégrée tout au long du cycle de développement logiciel.

Avec sa plateforme DevSecOps unifiée, GitLab couvre l'intégralité du cycle de développement logiciel dans un seul et même endroit. De la planification au déploiement, vos équipes disposent d'un environnement centralisé pour coder, tester, sécuriser et livrer leurs applications en continu, sans multiplier les outils.

GitLab Duo, notre suite de fonctionnalités alimentées par l'IA, va encore plus loin en accélérant chaque phase du cycle de développement logiciel : génération de code, revue automatisée, résolution de vulnérabilités, création de tests et résumés de merge requests. L'IA s'intègre directement dans votre workflow pour réduire les tâches répétitives et permettre à vos équipes de se concentrer sur des tâches à forte valeur ajoutée.

Résultat : des cycles de livraison plus rapides, une meilleure qualité logicielle et une sécurité renforcée à chaque étape.

Prêt à améliorer votre SDLC ?

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.

FAQ sur le SDLC

Quelle est la différence entre le SDLC et le modèle Agile ?

Le SDLC est un processus utilisé pour la conception et le développement d'une application logicielle. Il est découpé en plusieurs tâches prédéfinies qui correspondent aux phases du cycle de vie d'un produit. Le modèle Agile est une approche du SDLC.

Le SDLC est-il adapté aux petites équipes ?

Oui. Grâce à des plateformes de développement logiciel comme GitLab, les processus de SDLC peuvent être facilement mis en place et maintenus par des équipes restreintes. Les automatisations natives simplifient les tâches, optimisent la productivité et la collaboration à chaque étape du cycle de développement.

Quelles sont les meilleures pratiques SDLC en 2026 ?

Le SDLC évolue en même temps que les technologies de développement. Actuellement, les meilleures pratiques de gestion de cycle intègrent une automatisation complète des pipelines CI/CD, une utilisation de l'IA (GitLab Duo), une sécurité proactive dès la planification du projet et une documentation continue pour garantir transparence et conformité.

Comment la plateforme de GitLab facilite-t-elle la gestion du cycle de développement logiciel ?

GitLab est une plateforme DevSecOps alimentée par l'IA qui centralise toutes les fonctionnalités essentielles pour planifier, développer, tester, sécuriser et monitorer vos projets de développement depuis une interface unifiée. La plateforme dispose d'un environnement intégré qui simplifie l'organisation et la communication entre l'ensemble des acteurs impliqués et optimise la productivité des équipes grâce à des automatisations à chaque étape et à l'intégration de l'IA.

À retenir

• Le SDLC est une méthodologie qui structure le développement logiciel en phases clés : planification, développement, test, déploiement, supervision et amélioration continue.
• GitLab centralise l'ensemble du SDLC dans une plateforme unifiée alimentée par l'IA, qui améliore la cohérence et la performance des équipes sur l'ensemble des projets.
• Les acteurs clés du SDLC (Dev, Ops, QA, Sec, Product Owner) collaborent pour assurer qualité, sécurité et alignement avec les besoins métiers.
• Le cycle SDLC est composé de 7 étapes : planification et analyse des besoins, étude de faisabilité, conception, développement, tests et validation, déploiement, maintenance et amélioration continue.
• Huit modèles SDLC existent, du modèle Waterfall traditionnel au modèle DevSecOps moderne intégrant sécurité et automatisation.
• GitLab prend en charge l'approche Secure by Design avec des scanners intégrés (SAST, DAST, analyse des dépendances, analyse des conteneurs, détection des secrets) pour garantir la sécurité continue du code.

Concrètement, une plateforme AIOps agrège de vastes volumes de données issus des applications, réseaux et infrastructures informatiques. Elle les analyse grâce à l’intelligence artificielle afin d’isoler les signaux pertinents, identifier les causes racines et déclencher des actions correctives automatisées. L’objectif n’est pas seulement de réagir plus vite aux incidents, mais surtout d’anticiper les anomalies et de maintenir une expérience utilisateur optimale dans des environnements multicloud et distribués de plus en plus complexes.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.

Pourquoi les organisations s’intéressent-elles de plus en plus à l’AIOps ?

Plusieurs tendances expliquent l’essor de l’AIOps dans les entreprises. D’abord, la croissance exponentielle des volumes de données rend impossible une supervision manuelle. Ensuite, la pression sur la qualité de service et l’expérience utilisateur ne tolère plus les interruptions prolongées. Enfin, la généralisation des environnements hybrides et multicloud multiplie les interdépendances et complexifie la détection des causes profondes.

Dans ce contexte, les équipes informatiques ne peuvent plus se contenter de collecter et de réagir. Elles ont besoin d’outils capables d’analyser en continu, de hiérarchiser les incidents et d’apporter une aide à la décision en temps réel. L’AIOps répond à cette attente en transformant la gestion opérationnelle : de réactive, elle devient proactive, et souvent prédictive.

Comment fonctionne l’AIOps ?

Le fonctionnement de l’AIOps repose sur un cycle continu d’analyse et d’automatisation qui transforme des volumes massifs de données en actions concrètes. On peut le décomposer en plusieurs étapes complémentaires.

Collecte et unification des données

Les plateformes AIOps commencent par agréger des flux de données provenant de sources multiples : métriques systèmes, journaux applicatifs, événements réseau, événements de sécurité, données issues d’outils ITSM (gestion des incidents, tickets) ou encore environnements cloud. Ces données sont souvent hétérogènes et redondantes, la première valeur de l’AIOps est donc de les centraliser et de les normaliser dans un format commun.

Nettoyage et enrichissement

Avant toute analyse, les données brutes sont filtrées et nettoyées pour éliminer le bruit : redondances, faux positifs et alertes mineures, afin de ne conserver que les signaux pertinents. À ce stade, des techniques d’enrichissement comme la corrélation avec l’historique ou l’ajout de métadonnées permettent déjà d’améliorer la lisibilité.

Analyse et corrélation

Une fois les données préparées, les algorithmes de machine learning prennent le relais. Ils recherchent des corrélations, détectent des anomalies et identifient des schémas récurrents. Par exemple, une série de dégradations de performances sur un service peut être corrélée à une mise à jour récente ou à une saturation réseau. L’AIOps permet ainsi de séparer le « signal » du « bruit » et de comprendre les causes profondes.

Détection et priorisation des incidents

Plutôt que de générer des centaines d’alertes, la plateforme hiérarchise les problèmes selon leur criticité et leur impact métier. Un incident susceptible d’affecter directement les utilisateurs finaux est mis en avant, tandis que les anomalies de moindre importance sont regroupées ou reportées. Cette priorisation change la donne pour les équipes IT, qui peuvent concentrer leur énergie sur ce qui compte réellement.

Automatisation et remédiation

La dernière étape est celle de l’action. En fonction des scénarios détectés, la plateforme peut :

• déclencher automatiquement des workflows de remédiation (redémarrage d’un service, scaling d’une ressource cloud, « rollback » d’une version),
• enrichir un ticket avec toutes les données utiles pour l’équipe concernée,
• ou générer une recommandation que l’humain valide avant exécution.

Avec le temps, les modèles s’affinent grâce aux boucles de rétroaction : chaque correction appliquée nourrit l’historique et rend le système plus précis. C’est cette capacité d’apprentissage continu qui distingue l’AIOps d’une simple automatisation basée sur des règles fixes.

Quels sont les avantages de l’AIOps ?

L’AIOps présente des avantages à plusieurs niveaux, qui vont bien au-delà d’une simple réduction du volume d’alertes généré par les outils de supervision et de monitoring.

Le plus évident est l’accélération de la résolution des incidents. En corrélant automatiquement les événements et en mettant en avant les causes probables, l’AIOps réduit le temps moyen de détection (MTTD) et le temps moyen de résolution (MTTR). Là où une panne pouvait mobiliser plusieurs équipes pendant des heures, l’analyse algorithmique permet d’orienter rapidement les équipes vers le bon levier d’action.

L’AIOps se distingue également par sa capacité prédictive. Grâce au machine learning, les systèmes AIOps ne se contentent pas de réagir aux incidents, ils peuvent anticiper des dégradations futures. Un exemple typique est la détection d’une tendance à la saturation mémoire : plutôt que d’attendre que l’application tombe, l’AIOps déclenche une action préventive.

Un autre avantage réside dans la rationalisation des opérations. Dans des environnements multicloud ou hybrides, les équipes utilisent souvent une dizaine d’outils de monitoring différents, chacun générant ses propres alertes. L’AIOps centralise et standardise ces flux de données, ce qui permet de travailler sur une vision unifiée, beaucoup plus lisible.

Enfin, l’AIOps contribue à l’efficacité organisationnelle. Il automatise les tâches répétitives (ouverture de tickets enrichis, redémarrage d’un service, ajustement des ressources cloud) et libère ainsi du temps pour que les équipes IT se consacrent à des projets à plus forte valeur ajoutée : améliorer la qualité logicielle, renforcer la sécurité, ou encore soutenir la transformation numérique.

Quels sont les cas d’usage concrets de l’AIOps ?

L’AIOps n’est pas une idée théorique : il se déploie déjà dans de nombreux environnements IT, où il permet de transformer la manière dont les équipes détectent et résolvent les problèmes.

Voici quelques exemples concrets de son application.

Supervision et détection d’anomalies

Dans un environnement applicatif complexe, les équipes doivent surveiller des centaines de métriques en parallèle : temps de réponse des applications déployées, charge CPU des runners CI/CD, utilisation mémoire des conteneurs, trafic réseau. L’AIOps analyse en continu ces flux de données pour repérer les écarts par rapport à la normale, même lorsqu’ils sont subtils. Par exemple, une légère dérive de latence sur un service critique après un déploiement via GitLab CI/CD peut être détectée et signalée bien avant qu’elle ne se transforme en panne visible pour l’utilisateur.

Analyse des causes profondes

Lorsqu’un incident survient, identifier rapidement la cause est souvent le plus difficile. L’AIOps croise automatiquement les événements (logs applicatifs, alertes réseau, changements de configuration) et propose des hypothèses de causes probables. Imaginons une indisponibilité soudaine en production : plutôt que d’examiner manuellement chaque outil de supervision, la plateforme AIOps peut corréler l’incident à une mise à jour logicielle déployée quelques minutes auparavant.

Optimisation du cloud et des environnements hybrides

Le cloud offre de la flexibilité, mais aussi une complexité nouvelle. L’AIOps peut anticiper un pic de charge en production et déclencher automatiquement le redimensionnement d’instances pour absorber le trafic.

À l’inverse, il peut identifier des ressources sous-utilisées et recommander leur réduction ou leur arrêt, contribuant ainsi à l'optimisation des coûts cloud dans une approche FinOps. Dans des environnements multicloud, cette automatisation est précieuse pour éviter la surconsommation ou les pannes liées à la saturation, tout en maintenant une visibilité complète sur les coûts et la performance de chaque composant de l'infrastructure.

Sécurité et détection de menaces

L’AIOps s’applique également à la cybersécurité. En corrélant des tentatives d’authentification suspectes avec d’autres signaux (activité réseau inhabituelle, anomalies de logs, accès à des dépôts sensibles), il peut alerter sur une attaque en cours ou isoler automatiquement un système compromis.

Dans le contexte d'une plateforme DevSecOps comme GitLab, l'AIOps permet d’analyser les logs d'audit pour détecter des comportements suspects : accès inhabituel à des secrets ou variables CI/CD, modifications massives de configurations de sécurité. Il peut également corréler les vulnérabilités détectées par les scanners de sécurité de GitLab (SAST, DAST, détection des secrets, analyse des conteneurs, analyse des dépendances) avec des tentatives d'exploitation réelles observées en production, permettant ainsi de prioriser les correctifs en fonction du risque effectif.

Accélération du cycle de développement logiciel

Intégré aux pipelines CI/CD, l’AIOps joue un rôle de « garde-fou intelligent » à plusieurs niveaux, en repérant des anomalies dès la phase de tests ou de déploiement. Par exemple, si une nouvelle version provoque une augmentation inhabituelle du taux d’erreurs, la plateforme peut déclencher automatiquement un « rollback » avant que l’incident ne touche les utilisateurs finaux. GitLab permet également de configurer des règles de déploiement basées sur des métriques (temps de réponse, taux d'erreur) pour automatiser ces décisions. Cette approche permet d'accélérer les cycles de livraison tout en limitant les risques.

Les différences de l’AIOps avec le DevOps, MLOps, SRE ou le DataOps

L'AIOps s'inscrit dans un écosystème de pratiques modernes qui partagent des objectifs communs : automatisation, fiabilité, efficacité. Il est donc naturel de les comparer, bien qu'elles soient en réalité complémentaires.

AIOps VS DevOps

Le DevOps est un ensemble de pratiques qui vise à rapprocher les équipes de développement et opérations pour accélérer la livraison de logiciels. L’AIOps, quant à lui, enrichit et soutient les équipes DevOps en automatisant la supervision, la détection d’anomalies et la gestion des incidents, apportant ainsi une visibilité en temps réel et une capacité de réaction accrue.

AIOps VS MLOps

Le MLOps concerne la mise en production et l’industrialisation des modèles de machine learning : versioning des modèles, pipelines d'entraînement automatisés, monitoring de la dérive des modèles. L’AIOps, de son côté, utilise le machine learning pour résoudre des problèmes opérationnels IT.

AIOps VS SRE (Site Reliability Engineering)

Le SRE (Site Reliability Engineering) est une discipline qui applique des principes d'ingénierie logicielle aux opérations pour améliorer la fiabilité des systèmes, en s'appuyant sur des concepts comme les SLO (Service Level Objectives), les budgets d’erreur et la réduction des tâches manuelles répétitives. L’AIOps est un accélérateur naturel de la démarche SRE car il automatise la détection et la résolution des incidents, réduit le MTTD/MTTR et élimine les tâches manuelles répétitives.

AIOps VS DataOps

Le DataOps est une autre pratique qui vise à fiabiliser et automatiser les pipelines de données en appliquant des principes DevOps au domaine de la data. Là où le DataOps se concentre sur la gouvernance et la qualité des données, l’AIOps met l’accent sur leur exploitation pour améliorer la supervision et les opérations IT.

Quels défis et limites à l’adoption de l’AIOps ?

L’adoption de l’AIOps dans une organisation ne se fait pas sans obstacles. La qualité des données est un préalable indispensable, or celles-ci sont souvent fragmentées ou bruitées. Les organisations doivent aussi surmonter des silos internes pour permettre une corrélation efficace. Enfin, la mise en œuvre de l’AIOps suppose des compétences spécialisées en data science et peut nécessiter un investissement initial conséquent avant d’en percevoir les bénéfices.

Certification AIOps Foundation

Il n’existe pas à ce jour d’organisme reconnu qui pilote la discipline AIOps de façon indépendante. Toutefois, on trouve une certification AIOps Foundation (gérée par le DevOps Institute) qui constitue une référence dans le domaine.

Cette certification aborde les origines du concept AIOps, les technologies associées (big data, machine learning), les usages, les défis et les bonnes pratiques pour l’intégration. Elle joue un rôle de repère pour les professionnels et les organisations souhaitant structurer leur démarche AIOps, sans pour autant être une « fondation normative».

L’AIOps, l’open source et GitLab

L’AIOps s’appuie fortement sur l'écosystème open source : observabilité (Prometheus, Grafana), automatisation (Ansible, Terraform), intelligence artificielle (PyTorch, TensorFlow).

Dans ce paysage, GitLab joue un rôle naturel de plateforme d'intégration. En unifiant développement, sécurité et opérations, GitLab facilite l’adoption de l’AIOps :

• Intégration avec les outils AIOps : GitLab se connecte nativement avec Datadog, Dynatrace, Prometheus via webhooks et APIs.
• Traçabilité complète : chaque déploiement via GitLab CI/CD est automatiquement corrélé aux commits, merge requests et pipelines.
• Automatisation des remédiations : GitLab CI/CD peut orchestrer des actions correctives automatisées : « rollbacks », exécution de runbooks ou création automatique d'incidents pour les équipes concernées.
• Collaboration centralisée : GitLab offre un socle commun entre développeurs, SRE et équipes IT pour réduire les silos.
• Intelligence artificielle pour le développement : avec GitLab Duo, les équipes bénéficient d'une assistance IA pour accélérer le développement (suggestions de code, chat contextuel, génération de tests), améliorer la qualité logicielle et réduire le temps de résolution des bugs, s'inscrivant dans la même logique d'automatisation intelligente.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.

Qu'est-ce que le CI/CD ?

Le CI/CD désigne un ou des systèmes d'intégration et de livraison continues dans le développement logiciel. L'architecture sous-jacente au CI/CD est généralement appelée pipeline, car le logiciel progresse à travers différentes étapes comme dans un tuyau. Mais que signifient réellement l'intégration continue et la livraison continue ? Prenons le temps d'approfondir ces notions afin de pouvoir maîtriser rapidement le CI/CD.

Du côté gauche du pipeline, l'intégration continue englobe une variété d'automatisations qui se déroulent en plusieurs étapes conçues pour tester et fournir des retours rapides sur différents aspects de la qualité du code, de la fonctionnalité et de la sécurité. Les tests CI peuvent aller des tests unitaires et du linting exécutés localement sur un poste de développeur aux suites complètes de tests d'intégration en passant par l'analyse statique. Un simple changement de code peut provoquer une panne ou un dysfonctionnement majeur une fois en production, d'où l'importance des tests automatisés et reproductibles au lieu de tests manuels.

Une fois qu'un changement de code a passé les tests et obtenu toutes les approbations requises, il est temps de déployer. Dans les environnements legacy, les administrateurs système et le personnel d'exploitation devaient souvent transférer et installer manuellement les mises à jour, puis redémarrer les serveurs pour déployer de nouvelles fonctionnalités. Ces tâches manuelles, sujettes aux erreurs, ne peuvent tout simplement pas être adaptées aux exigences des écosystèmes d'applications modernes. Avec la livraison continue, ce code est automatiquement déployé sur les serveurs de manière testable et déterministe. Le code peut être déployé dans des environnements de préproduction avec des accords de niveau de service moins stricts, tels que le développement, la préproduction et l'assurance qualité. Une fois vérifiées, les nouvelles fonctionnalités peuvent être lancées en tant que charges de travail de production. Dans certains environnements, la « livraison continue » devient le « déploiement continu », dans lequel des tests complets déploient automatiquement le nouveau code en production sans intervention humaine.

Cette automatisation a pour objectif d'obtenir une cadence de déploiement plus rapide, gage de réussite pour les organisations.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.

Se lancer avec le CI/CD

Maintenant que les bases sont connues, il est temps de se concentrer sur l'objectif principal : être opérationnel rapidement. Nous visons à implémenter une approche CI/CD pour améliorer la vélocité de déploiement, et espérons-le, initier des efforts plus larges en vue de l'adoption généralisée et efficace du CI/CD.

Le CI/CD peut sembler intimidant en raison de la multitude d'outils, de services et de plateformes et de leurs fonctionnalités spécifiques et solutions de bout en bout. Certaines options comme Jenkins sont auto-gérées et nécessitent d'utiliser plusieurs outils ; d'autres, y compris la plateforme DevSecOps de GitLab, fournissent une solution complète et intégrée dans une plateforme unifiée qui combine le contrôle de version, les pipelines CI/CD, les tests de sécurité et les capacités de déploiement.

L'expérience des équipes de développement

Une implémentation CI/CD réussie doit faciliter la vie des équipes de développement. Visez des exécutions de pipeline de moins de 10 minutes et intégrez les notifications de statut directement dans les outils de développement (extensions IDE, Slack, tableaux de bord). Utilisez l'exécution de tests en parallèle et la mise en cache pour maintenir la vélocité des pipelines à mesure que votre suite d'outils de test évolue.

Construisez votre pipeline

Il n'existe pas de configuration magique pour le CI/CD. Chaque implémentation dépend de plusieurs facteurs : le type d'application déployée, la taille et les compétences des équipes d'ingénierie, les exigences métier et l'échelle de l'application elle-même. Les considérations en matière de design et d'implémentation pour une application avec 100 utilisateurs par jour sont différentes de celle avec un million d'utilisateurs. Il en va de même pour le CI/CD.

Découvrez sept stratégies pour votre premier pipeline CI/CD :

1. Pensez à la conteneurisation dès le début

Les pipelines CI/CD modernes exploitent généralement la conteneurisation avec Docker et les plateformes d'orchestration comme Kubernetes. Les conteneurs fournissent des environnements cohérents pour le développement, les tests ainsi que les étapes de production et éliminent tout problème lié aux machines individuelles. Bien que ce ne soit pas essentiel pour votre premier pipeline, conteneuriser votre application peut considérablement simplifier les processus de déploiement et limiter les problèmes liés à l'environnement. Si votre architecture d'application prend en charge cette approche, utilisez des conteneurs dès le début pour faciliter la mise à l'échelle de votre implémentation CI/CD à mesure que votre équipe grandit.

2. Commencez avec des petits projets

N'essayez pas de tout corriger d'un coup. La refactorisation d'un code source ou d'une infrastructure entière est un processus complexe qui implique généralement plusieurs niveaux d'approbation, de discussion, de planification et de possibles résistances des équipes dépendantes. Il est beaucoup plus facile d'améliorer un petit sous-ensemble de l'infrastructure de l'application.

3. Concentrez-vous sur les tâches faciles

Les erreurs les plus simples et les plus faciles à détecter (et à corriger) peuvent finir par causer de gros problèmes si elles se retrouvent dans les charges de travail de production. Cependant, il n'est pas toujours judicieux d'ajouter des étapes au pipeline CI/CD ou de le complexifier inutilement. Dans ce cas, il vaut mieux configurer des tests automatiques qui s'exécutent sur les machines des développeurs avant que le code ne soit validé. La plupart des fournisseurs Git DVCS, y compris GitLab, permettent aux utilisateurs de déployer des hooks avant validation. Les hooks avant validation sont un type de script ou d'automatisation qui sont déclenchés lorsque des actions spécifiques se produisent. Par exemple, lorsqu'un développeur initie un nouveau commit, un hook avant validation peut vérifier que le code est conforme aux normes syntaxiques et structurelles, et qu'il ne contient pas d'erreurs de syntaxe de base. D'autres hooks avant validation peuvent s'assurer que les tests unitaires sont exécutés avec succès avant qu'un commit soit autorisé à progresser dans le pipeline.

4. Intégrez la sécurité au CI/CD

Les tests ne doivent pas se limiter à la syntaxe et à la logique. La détection des problèmes de sécurité tôt dans le cycle de vie du développement logiciel (SDLC) facilite la correction, réduit les coûts et renforce la sécurité. L'ajout d'outils d'analyse de code statique de base et de dépendances peut améliorer de manière significative la posture de sécurité d'une application grâce à des retours rapides et une détection précoce des problèmes de sécurité et des vulnérabilités potentielles. Envisagez également d'analyser les conteneurs si vous utilisez des déploiements conteneurisés pour détecter des vulnérabilités dans vos images de base et vos dépendances.

5. Tirez parti de l'assistance par IA

Les plateformes DevSecOps modernes intègrent des outils alimentés par l'IA qui assistent les équipes à chaque étape du cycle de vie du développement. L'IA peut analyser le code afin de détecter les vulnérabilités de sécurité, suggérer des optimisations de pipeline basées sur votre code source, aider à la configuration des pipelines et dépanner les échecs de jobs. Certaines plateformes proposent une sélection intelligente de tests qui n'exécute que les tests pertinents pour les changements de code et réduit considérablement le temps d'exécution du pipeline. Les équipes peuvent commencer à travailler plus rapidement et maintenir des pipelines sécurisés et efficaces, même pour celles avec moins d'expérience CI/CD.

6. Adaptez les tests aux problèmes courants

La plupart des équipes d'ingénierie qui s'appuient sur des méthodologies de déploiement legacy devraient être capables d'identifier facilement un ou deux problèmes courants et récurrents dans les déploiements. Peut-être que la copie du code de l'application sur les serveurs via SCP entraîne toujours des permissions de fichiers cassées, ou qu'un frontend NGINX n'est jamais redémarré correctement. Pour la première itération des tests automatisés, choisissez ces problèmes spécifiques à traiter avec des tests. Cette approche sert deux objectifs : elle limite la portée du travail et donne à l'équipe une définition des tâches terminées qu'il est possible d'atteindre, et elle fournit une histoire à succès visible en corrigeant les problèmes de déploiement existants les plus problématiques. Une fois qu'un pipeline fonctionnel a été déployé et que l'organisation adopte le CI/CD, les tests peuvent être étendus.

7. Automatisez le déploiement vers les environnements inférieurs

Les nouvelles implémentations CI/CD devraient se concentrer sur la livraison continue, déployer automatiquement vers un environnement de préproduction et proposer une interface où il est possible de décider manuellement de déployer en production. Généralement, le déploiement continu est une étape plus avancée du parcours DevSecOps, lorsque les équipes possèdent davantage de connaissances et de maturité technique relatives aux déploiements automatisés.

Astuce : implémentez la parité dans vos environnements. Maintenez votre environnement de préproduction aussi similaire que possible de celui de production en termes de configuration, de volumes de données et d'infrastructure afin de limiter les scénarios où un projet fonctionne en préproduction, mais échoue en production.

Maîtrisez rapidement le CI/CD

Une bonne implémentation CI/CD peut améliorer de manière mesurable la vélocité de déploiement logiciel et constitue un pilier central d'une stratégie DevSecOps solide. Néanmoins, évitez autant que possible les déploiements lourds et complexes lors de votre première utilisation du CI/CD et visez plutôt une approche « tout compris » qui offre aux équipes un cycle court de rentabilisation.

Une fois les premiers résultats probants obtenus grâce au CI/CD, les équipes d'ingénierie pourront s'appuyer sur cet élan pour étendre la solution à l'ensemble de l'organisation afin d'améliorer la vitesse et les résultats de déploiement.

Découvrez le CI/CD dès aujourd'hui !

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.