hariri.ch
Prenez contact

Cloud & Infrastructure

Qodana for DevOps : ce que JetBrains envisage pour contrôler l’infrastructure comme le code

6 min de lecture

Illustration abstraite d’une chaîne DevOps reliant des configurations d’infrastructure, des conteneurs et des contrôles de qualité.

Un linter unique pour des contrôles aujourd’hui dispersés

Les équipes DevOps et platform engineering s’appuient souvent sur une collection d’outils en ligne de commande pour examiner leur infrastructure. Le projet présenté par JetBrains consiste à appliquer à ces artefacts une logique proche de celle déjà utilisée par Qodana pour le code applicatif : détecter les problèmes avant leur arrivée en production et regrouper les résultats dans une même expérience.

Qodana analyse actuellement le code des applications pour repérer notamment les variables inutilisées, les vulnérabilités de sécurité, les violations de conventions de style et certains problèmes d’architecture. L’extension envisagée chercherait à transposer cette approche à l’environnement qui déploie et exécute les applications.

Point essentiel : Qodana for DevOps n’est pas présenté comme un produit disponible. JetBrains le décrit comme une idée en phase d’exploration précoce. Il faut donc distinguer clairement la direction proposée des fonctionnalités effectivement accessibles aujourd’hui.

Quels artefacts seraient concernés ?

Selon la proposition de JetBrains, le périmètre pourrait couvrir plusieurs briques centrales d’une chaîne d’infrastructure moderne :

  • les manifests Kubernetes ;
  • Terraform et CloudFormation ;
  • les Dockerfiles ;
  • les playbooks et rôles Ansible ;
  • les bonnes pratiques et contrôles de sécurité Terraform ;
  • les images de conteneurs et l’infrastructure as code ;
  • les politiques écrites avec Open Policy Agent ;
  • les fichiers YAML ;
  • les workflows GitHub Actions.

Cette liste correspond à une ambition de couverture plutôt qu’à une matrice de compatibilité annoncée. Aucun niveau de prise en charge, calendrier de disponibilité ou ensemble détaillé de règles n’est fourni dans les éléments disponibles.

Pour les équipes, l’intérêt potentiel serait de rapprocher des contrôles qui sont souvent exécutés séparément. Une erreur de configuration Kubernetes, une faiblesse dans une définition Terraform ou une politique incohérente pourraient être remontées dans un même dispositif de qualité. Cela ne supprimerait pas nécessairement les outils spécialisés, mais pourrait offrir un point de lecture commun aux développeurs, aux ingénieurs plateforme et aux responsables sécurité.

Le même modèle de qualité que pour le code

Le Qodana DevOps Linter envisagé utiliserait, selon JetBrains, la même structure de rapport, le même modèle de niveaux de gravité et la même quality gate que l’interface Qodana dédiée au code applicatif. Cette continuité est importante dans les organisations qui ont déjà intégré Qodana dans leurs revues ou leurs pipelines : les équipes n’auraient pas à apprendre un second mode de restitution pour interpréter les résultats d’infrastructure.

Le rapport de synthèse projeté donnerait une vue immédiate de la qualité de l’infrastructure, avec le nombre total de problèmes, le nombre d’inspections exécutées et une ventilation par gravité et par catégorie dans cinq domaines. Une telle présentation pourrait faciliter le suivi entre deux exécutions et la définition de seuils bloquants dans une chaîne d’intégration continue.

En pratique, la valeur d’une quality gate dépendrait toutefois de la précision des règles, du taux de faux positifs et de la capacité à adapter les contrôles au contexte de chaque organisation. Ces aspects ne sont pas détaillés dans les faits disponibles et devront être vérifiés si le projet évolue vers une offre concrète.

Une extensibilité envisagée, mais encore à démontrer

JetBrains envisage également une analyse extensible grâce à des adaptateurs développés par la communauté. Des outils comme Pulumi, CDK ou GitLab CI pourraient, selon cette proposition, être connectés directement via qodana.yaml.

Cette orientation répond à une difficulté classique des plateformes internes : les équipes combinent rarement un seul outil d’orchestration, de provisioning ou de CI. Une architecture d’adaptateurs pourrait limiter le risque de rester prisonnier d’un périmètre initial trop étroit. Elle déplacerait néanmoins une partie de la responsabilité vers les mainteneurs de ces extensions : compatibilité, maintenance des règles et cohérence des résultats devraient être suivies dans le temps.

À ce stade, il s’agit d’une possibilité décrite par JetBrains, pas d’un catalogue d’intégrations annoncé. Les détails sur l’API, le cycle de vie des adaptateurs et leur validation n’ont pas été communiqués.

Ce que les informations de confidentialité changent pour une analyse DevOps

La question des données devient particulièrement importante dès lors qu’un service cloud analyse des fichiers d’infrastructure. La notice de confidentialité de JetBrains est indiquée en version 3.2, mise à jour le 12 juin 2026. JetBrains et ses sociétés associées y sont désignés comme responsables conjoints du traitement.

JetBrains indique pouvoir collecter des informations sur l’utilisation de fonctionnalités de ses produits, notamment la consommation de quotas d’IA et des statistiques sur l’acceptation des suggestions d’IA. Ces éléments concernent l’usage des fonctionnalités ; ils ne permettent pas, à eux seuls, de conclure quelles données précises seraient envoyées dans le cadre d’un éventuel linter DevOps. Ce point devra être clarifié avant toute adoption dans un environnement manipulant des secrets, des configurations sensibles ou des informations propriétaires.

La notice précise que le chiffrement est utilisé en transit et au repos lorsque cela est techniquement possible, avec un protocole TLS à jour pour les transmissions et des algorithmes tels que AES-256 pour les données stockées. Elle indique aussi que l’emplacement par défaut des données personnelles des clients est l’Union européenne, sauf indication contraire.

Cloud, produits locaux et fournisseurs d’IA : vérifier le périmètre réel

Le document consacré aux services tiers est référencé en version 3.13, effective au 9 juillet 2026. Il indique que Qodana est hébergé par Amazon Web Services EMEA SARL, avec un centre de données situé en Irlande, dans l’Union européenne.

Cette information ne doit pas être généralisée à tous les produits JetBrains. L’entreprise indique ne pas héberger ses produits sur site, notamment les IDE et les outils .NET et Visual Studio, et ne pas avoir accès aux données traitées avec ces outils sauf si le client choisit activement de les partager.

Pour les services d’IA de JetBrains, les fournisseurs ou sous-traitants listés comprennent OpenAI, Google, Anthropic, xAI, Baseten et Tavily. Les emplacements de centres de données mentionnés sont les suivants : États-Unis pour OpenAI, États-Unis, Union européenne et Asie pour Google, États-Unis pour Anthropic et xAI, États-Unis et Royaume-Uni pour Baseten, et États-Unis pour Tavily. JetBrains affirme par ailleurs ne pas vendre les données des utilisateurs à des tiers.

Pour une équipe DevOps, la conclusion opérationnelle est simple : avant de brancher une future analyse à une pipeline, il faudra examiner séparément le service utilisé, les données transmises, les sous-traitants concernés, les régions de traitement et les options de conservation. La localisation européenne annoncée pour Qodana ne suffit pas à décrire automatiquement le parcours de toutes les fonctionnalités associées.

À retenir

  • Qodana for DevOps est une proposition en exploration précoce, pas un produit annoncé comme disponible.
  • Le périmètre envisagé couvre notamment Kubernetes, Terraform, CloudFormation, Dockerfiles, Ansible, OPA, YAML et GitHub Actions.
  • Le projet reprendrait les rapports, niveaux de gravité et quality gates de Qodana pour le code applicatif.
  • Des adaptateurs communautaires pour Pulumi, CDK ou GitLab CI sont envisagés via <code>qodana.yaml</code>.
  • Qodana est indiqué comme hébergé en Irlande, tandis que les services d’IA de JetBrains font intervenir plusieurs fournisseurs et régions.

Sources