Comment intégrer LiteLLM aux workflows Git, GitHub et GitLab ?

LiteLLM offre un moyen pratique d’intégrer des capacités d’IA à des processus d’automatisation basés sur Git, sans vous enfermer chez un fournisseur de modèles unique.

Pour les équipes utilisant GitHub ou GitLab, l’outil peut servir de passerelle d’IA unifiée pour la révision de code, l’aide à la rédaction de commits, l’analyse des demandes de fusion (merge requests) et les automatisations pilotées par l’intégration continue (CI).

Cela s’avère particulièrement utile lorsque vous recherchez de la flexibilité entre les différents fournisseurs, une gouvernance centralisée et une API cohérente pour vos pipelines.

litellm git github gitlab

Pourquoi LiteLLM s’adapte bien aux workflows Git

In git-based environments, the same AI capability often needs to work across different stages: commit time, pull request or merge request review, release preparation, and CI checks.

LiteLLM helps by giving you one OpenAI-compatible endpoint that can route requests to many model providers behind the scenes. That means your automation can stay stable even if you change models, add fallbacks, or move some workloads to self-hosted inference.

For DevOps and DevSecOps teams, this is a strong pattern because it keeps AI usage centralized.

You can add policy controls, logging, model allowlists, and cost tracking at the proxy layer instead of spreading those concerns across many scripts and repositories.

In practice, that makes AI features easier to standardize across GitHub and GitLab estates.

Dans les environnements basés sur Git, une même fonctionnalité d’IA doit souvent opérer à différentes étapes : lors du commit, de la revue de pull request ou de merge request, de la préparation de la mise en production et des vérifications d’intégration continue (CI).

LiteLLM facilite cette tâche en proposant un point de terminaison unique compatible avec l’API OpenAI, capable d’acheminer les requêtes vers divers fournisseurs de modèles en arrière-plan. Ainsi, vos processus automatisés restent stables, même si vous changez de modèle, mettez en place des mécanismes de secours (fallbacks) ou déplacez certaines charges de travail vers une infrastructure d’inférence auto-hébergée.

Pour les équipes DevOps et DevSecOps, cette approche est particulièrement pertinente car elle permet de centraliser l’utilisation de l’IA.

Vous pouvez intégrer des contrôles de politique, la journalisation, des listes blanches de modèles et le suivi des coûts directement au niveau du proxy, plutôt que de disperser ces éléments à travers de multiples scripts et dépôts.

Concrètement, cela simplifie la standardisation des fonctionnalités d’IA au sein de vos écosystèmes GitHub et GitLab.

Cas d’utilisation courants

Voici des moyens pratiques d’utiliser LiteLLM dans des workflows basés sur Git :

  1. Revue de pull request ou de merge request.
  2. Génération de messages de commit.
  3. Vérifications de sécurité et de conformité.
  4. Rédaction de notes de version.
  5. Aide à la documentation.
  6. Enrichissement du pipeline CI.

Exemple de GitHub Actions

Cet exemple illustre un modèle simple dans lequel GitHub Actions fait appel à un proxy LiteLLM lors d’un workflow de pull request. Vous pouvez adapter le prompt pour générer un résumé de la revue, une ébauche de journal des modifications (changelog) ou une liste de contrôle de sécurité.

textname: AI Review with LiteLLM

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Get diff
        run: |
          git fetch origin ${{ github.base_ref }} --depth=1
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff

      - name: Call LiteLLM proxy
        env:
          LITELLM_API_KEY: ${{ secrets.LITELLM_API_KEY }}
        run: |
          PROMPT=$(cat <<'EOF'
          Review the following pull request diff and provide:
          1. A short summary
          2. Potential risks
          3. Suggested improvements

          Diff:
          EOF
          )
          DIFF_CONTENT=$(cat pr.diff)

          curl -s https://litellm.example.com/v1/chat/completions \
            -H "Authorization: Bearer ${LITELLM_API_KEY}" \
            -H "Content-Type: application/json" \
            -d "$(jq -n \
              --arg model 'gpt-4o-mini' \
              --arg system "$PROMPT" \
              --arg user "$DIFF_CONTENT" \
              '{
                model: $model,
                messages: [
                  {role: "system", content: $system},
                  {role: "user", content: $user}
                ]
              }')"

Ce modèle est particulièrement adapté lorsque vous souhaitez intégrer la sortie de l’IA directement dans le flux de travail, plutôt que de passer par une étape distincte de révision manuelle. Vous pouvez également enregistrer la réponse sous forme de commentaire de pull request, d’artefact de build ou de résumé de tâche.

Exemple GitLab CI

Dans GitLab, cette même idée correspond parfaitement à un pipeline de demande de fusion (merge request pipeline). Cet exemple utilise un job qui récupère le diff et l’envoie à un proxy LiteLLM.

textstages:
  - ai_review

ai_review:
  stage: ai_review
  image: alpine:3.20
  variables:
    GIT_DEPTH: "1"
  before_script:
    - apk add --no-cache git curl jq
  script:
    - git fetch origin "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" --depth=1
    - git diff "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > mr.diff
    - |
      PROMPT="Review the following merge request diff and provide:
      1. A short summary
      2. Potential risks
      3. Suggested improvements"
      DIFF_CONTENT="$(cat mr.diff)"

      curl -s https://litellm.example.com/v1/chat/completions \
        -H "Authorization: Bearer ${LITELLM_API_KEY}" \
        -H "Content-Type: application/json" \
        -d "$(jq -n \
          --arg model 'gpt-4o-mini' \
          --arg system "$PROMPT" \
          --arg user "$DIFF_CONTENT" \
          '{
            model: $model,
            messages: [
              {role: "system", content: $system},
              {role: "user", content: $user}
            ]
          }')"
  rules:
    - if: $CI_MERGE_REQUEST_IID

Cela s’intègre parfaitement à GitLab, car les pipelines de demandes de fusion constituent déjà un emplacement tout indiqué pour les vérifications automatisées. Vous pouvez étendre le même job pour publier la réponse en tant qu’artefact, ajouter un commentaire à la demande de fusion ou transmettre le résultat à une étape de contrôle qualité ultérieure.

Conseil de mise en œuvre

Si vous développez cette solution pour un environnement de production, veillez à structurer le format des invites et des réponses.

Par exemple, demandez une sortie JSON afin que votre pipeline puisse analyser correctement la gravité, le résumé et les recommandations.

Il est également judicieux de séparer les modèles publics des dépôts sensibles et d’acheminer les projets protégés uniquement vers des fournisseurs auto-hébergés ou agréés.

Pour les environnements fortement basés sur GitLab, LiteLLM peut également servir de couche de compatibilité devant les systèmes d’IA auto-hébergés ou internes.

Pour les flux de travail centrés sur GitHub, il permet de standardiser le comportement de l’IA entre les dépôts, même si les équipes préfèrent des modèles différents. Dans les deux cas, la véritable valeur ajoutée réside non seulement dans l’accès aux modèles, mais aussi dans le contrôle et la cohérence.

Notre entreprise propose des licences par abonnement, du support et des services gérés pour LiteLLM, git, GitLab et GitHub.
Contactez-nous pour toute question.: litellm@almtoolbox.com
ou appelez-nous : +33 1 84 17 53 28

L’IA identifie les vulnérabilités du code, mais qui gère le risque ?

Diagramme montrant la supervision de la sécurité dans GitLab au sein d'un environnement de développement IA

L’identification des vulnérabilités assistée par l’IA évolue rapidement. Cependant, les défis plus complexes liés à l’application des règles, à la gouvernance et à la sécurité de la chaîne d’approvisionnement nécessitent une plateforme holistique comme GitLab.

Récemment, la société Anthropic a annoncé Claude Code Security. Il s’agit d’un système d’IA qui identifie les failles et suggère des correctifs. Le marché a réagi immédiatement. Les actions du secteur de la sécurité ont chuté, et les investisseurs se sont demandé si l’IA risquait de remplacer les outils AppSec et DevSecOps traditionnels.

La question qui préoccupe tout le monde est claire : Si l’IA peut écrire et sécuriser du code, le domaine de la sécurité des applications devient-il obsolète ? La réponse courte est non. Si la sécurité se limitait uniquement à l’analyse du code, cela pourrait être vrai. Mais la sécurité d’entreprise (Enterprise Security) ne s’est jamais résumée à la simple détection. L’identification des vulnérabilités par l’IA progresse certes très vite, mais les défis complexes de l’application des politiques, de la gouvernance et de la sécurisation de la chaîne d’approvisionnement exigent une plateforme globale comme GitLab.

Les vraies questions difficiles en sécurité applicative

Les organisations ne demandent plus si l’IA est capable de trouver des vulnérabilités. Elles posent trois questions bien plus difficiles :

  1. Ce que nous nous apprêtons à livrer est-il réellement sécurisé ?
  2. Notre posture de risque a-t-elle changé à mesure que les environnements et les dépendances évoluent ?
  3. Comment supervisons-nous le code composé par l’IA et les sources tierces, dont nous restons responsables ?

Ces questions nécessitent une solution au niveau de la plateforme. La détection signale le risque, mais la gouvernance détermine ce qui se passe ensuite. GitLab est la couche d’orchestration conçue pour superviser le cycle de vie du logiciel de bout en bout. Elle fournit aux équipes l’application des règles, la visibilité et la capacité d’audit nécessaires pour le développement assisté par l’IA.

Faire confiance à l’IA exige une supervision des risques

Les systèmes d’IA s’améliorent rapidement pour détecter les failles et proposer des correctifs. C’est une avancée significative, mais l’analyse ne remplace pas la responsabilité. Les systèmes d’IA ne peuvent pas appliquer d’eux-mêmes les politiques de l’entreprise. Ils ne peuvent pas non plus définir seuls ce qu’est un risque acceptable.

Ce sont les humains qui doivent définir les limites et les politiques à l’intérieur desquelles les agents opèrent. Il faut établir une séparation des tâches, garantir des pistes d’audit et maintenir des contrôles cohérents. La confiance envers les agents ne découle pas de leur autonomie, mais d’une supervision bien définie. Plus les organisations accordent d’autonomie à l’IA, plus la supervision doit être robuste. Cette supervision n’est pas un frein ou un obstacle ; c’est la fondation qui rend le développement assisté par l’IA fiable à grande échelle.

Les modèles d’IA voient le code – Les plateformes voient le contexte

Un grand modèle de langage (LLM) analyse le code de manière isolée. À l’inverse, une plateforme de sécurité applicative d’entreprise comprend le contexte. Cette différence est fondamentale, car les décisions relatives aux risques dépendent du contexte :

  1. Qui a écrit le changement ?
  2. À quel point l’application est-elle critique pour l’entreprise ?
  3. Comment interagit-elle avec l’infrastructure et les dépendances ?
  4. La vulnérabilité est-elle réellement accessible (reachable) en production ?
  5. Est-elle exploitable dans l’environnement de production ?

Les décisions de sécurité dépendent de ce contexte. Sans lui, la détection génère des alertes bruyantes et des faux positifs. Ces alertes ralentissent le développement. Avec le contexte, les organisations peuvent prioriser (triage) rapidement et gérer les risques efficacement.

Les analyses statiques ne suffisent plus

Le contexte évolue sans cesse à mesure que le logiciel change. Par conséquent, la supervision ne peut se limiter à une décision unique ou à une analyse statique. Les risques logiciels sont dynamiques. Les dépendances changent et les environnements évoluent de manière imprévisible pour une analyse isolée. Un scan “propre” à un instant T ne garantit pas la sécurité future (au moment de la mise en production et au-delà).

La sécurité d’entreprise dépend d’une assurance continue. Il faut intégrer des contrôles directement dans les flux de travail (workflows) de développement. Ces contrôles évaluent le risque pendant la construction, le test et le déploiement du logiciel. La détection fournit l’information, et la supervision continue permet aux organisations de publier leurs produits en toute sécurité.

Superviser l’avenir des agents autonomes (Agentic)

L’IA redéfinit la création de logiciels. La question n’est plus de savoir si nous utiliserons l’IA, mais avec quel niveau de sécurité nous pourrons étendre son utilisation. Les logiciels d’aujourd’hui sont composés de code généré par l’IA, de bibliothèques open source et de dépendances tierces.

Superviser ce qui est publié à partir de toutes ces sources est la partie la plus difficile de la sécurité applicative. Aucun outil destiné uniquement au développeur n’est conçu pour gérer cela. En tant que plateforme d’orchestration intelligente, GitLab a été spécifiquement bâtie pour résoudre ce problème. GitLab Ultimate intègre la supervision et l’application des politiques directement dans les workflows où le logiciel est créé. Ainsi, les équipes de sécurité peuvent superviser à la vitesse de l’IA.

L’IA va accélérer le développement de manière spectaculaire. Les organisations qui en tireront le meilleur parti ne seront pas seulement celles dotées des assistants les plus intelligents. Ce seront celles qui auront instauré la confiance grâce à une supervision robuste.

Pour savoir comment GitLab aide les organisations à superviser et à publier du code généré par l’IA en toute sécurité, contactez-nous.

Pour plus d’informations sur la solution GitLab pour la gestion de la sécurité du code et des applications,
Contactez-nous : gitlab@almtoolbox.com Ou par téléphone : +33 01 84 17 53 28 (France) or 866-503-1471 (USA & Canada)

Notre société a aidé des centaines de clients à passer à Git et GitLab (depuis 2015) ainsi qu’à choisir des outils d’aide au développement logiciel, de gestion de configuration, de CI/CD et de développement sécurisé, y compris avec l’assistance d’outils d’IA et dans des environnements hébergés sur site (Self-hosted).
Nous sommes également les représentants officiels de GitLab en Israël et opérons à l’international depuis 2016.
Pour plus de détails, contactez-nous : gitlab@almtoolbox.com

Cet article a été rédigé par ALM Toolbox, basé notamment sur un article écrit par Omar Azaria de GitLab, et a été adapté par nos soins pour le public francophone.

Liens pertinents :

Sécurité et conformité du code à l’aide de GitLab

gitlab-security

Peu de gens le savent, mais GitLab a également la possibilité d’effectuer une variété de contrôles de sécurité sur le code que vous développez et / ou utilisez (open source), ainsi que des capacités de conformité du code – c’est-à-dire de vous assurrez  de faire une utilisation correcte et légale de l’open source que vous utilisez.

En fait, dans GitLab, vous pouvez également exécuter les tests sur le code, puis tout voir à l’aide d’un tableau de bord central qui affiche tout de manière ordonnée, et vous permet également d’effectuer des actions sur les résultats et les constatations et de partager réellement les informations entre tous les projets. personnes (ou quiconque est autorisé à le consulter).

Les tests peuvent être exécutés à partir de GitLab CI (qui est l’outil CI / CD fourni avec GitLab) et peuvent également être connectés à d’autres outils CI tels que Jenkins.

En fait, les tests peuvent être exécutés même si le code est dans un autre outil SCM (tel que git, GitHub, Bitbucket, etc.).

Certains des tests ne concernent pas le code lui-même, mais l’application ou le site Web qui exécute le code.

Il peut être exécuté à la fois à partir d’un serveur GitLab privé (c’est-à-dire auto-hébergé) et à partir du cloud.

 Voici une courte liste de ces fonctionnalités:

Fonctionnalité / test

Description 

Container Scanning  Conteneurs vides (docker) pour les faiblesses connues
Dependency List Afficher une liste des dépendances de projet et des vulnérabilités connues
Dependency Scanning Analyse des dépendances concernant les faiblesses connues
Static Application Security Testing (SAST) Scan du  code (analyse statique) pour les vulnérabilités connues. C / C ++, Apex, .NET, Java, Go, JS, Python, PHP, Swift, TypeScript, NodeJS pris en charge et plus encore
Dynamic Application Security Testing (DAST) Check des Application Web et sites Web vides pour détecter les vulnérabilités connues
Secret Detection  Scan גו code et de l’historique (de git) pour trouver des secrets et les informations sensibles
API Fuzzing Decouverte des bugs  et des vulnérabilités inconnus dans l’API Web (c’est-à-dire l’API que vous fournissez à vos clients) à l’aide de la technologie FUZZING
Coverage Fuzzing Détection de bugs et de vulnérabilités qui ne sont parfois pas détectés dans la phase d’assurance qualité (comme une entrée inattendue et une entrée aléatoire). Support de  C / C ++, Go, Java, JS, Python et plus
Security Dashboard  Vue centrale de toutes les conclusions dans tous les projets et groupes
License Compliance Détectetion  des dépendances open source dans votre code et savoir si le code et les répertoires dont nous dépendons sont légalement utilisés (tels que GPL, BSD, Apache, MIT, etc.) comme   définis dans le projet  

Questions courantes:

  • Question: Est-il possible de le connecter à des systèmes CI non GitLab?
    Réponse: Oui – c’est généralement possible (en fonction de l’utilisation et de la situation – cela doit être testé)
  • Question: Est-il possible d’exécuter les tests même sur des réseaux déconnectés d’Internet?
    Réponse: Certains des tests peuvent être exécutés hors ligne. Nous proposons également une assistance et une licence d’outils supplémentaires (en plus de GitLab) spécialement conçus pour les réseaux privés.

ALMtoolbox est spécialisée dans le développement et le test pour   DevOps et pour l’amélioration des processus de travail comprenant outils de développement, tests, CI / CD, transfert en production et travail sur le cloud, tels que GitLab, Kubernetes, Spotinst, Terraform, Vault, Consul, Rancher et autres., Nous offrons des services de Consultant et vente de licences d’outils.

ALMtoolbox est le  représentant officiel de GitLab, Hashicorp  en France et dans d’autres pays.

Contactez pour nous toute question, un devis ou même une license d’évaluation.

ALMtoolbox : 01 84 17 53 28, devops.fr@almtoolbox.com