Continuous Integration (CI)

L’intégration continue (CI) consiste à fusionner fréquemment les modifications de chaque développeur dans une branche principale partagée, au moins chaque jour, puis à compiler et tester automatiquement chaque modification, afin de détecter les problèmes d’intégration en quelques minutes plutôt qu’au moment de la publication. Grady Booch a proposé le terme en 1991, Kent Beck en a fait une pratique centrale de l’Extreme Programming à la fin des années 1990, et l’article de Martin Fowler, Continuous Integration, décrit le flux de travail que la plupart des équipes suivent encore. En apprentissage automatique (ML), la CI vérifie également les données, le code d’entraînement et le comportement des modèles, car une modification peut laisser passer tous les tests unitaires tout en réduisant l’exactitude d’un modèle.

Fonctionnement d’un pipeline CI#

Lorsqu’un développeur envoie une branche ou ouvre une demande de fusion, un service CI comme GitHub Actions, GitLab CI/CD ou Jenkins démarre un nouvel exécuteur, récupère le code, installe les dépendances et exécute une suite de tâches : linters et vérificateurs de types, tests unitaires, tests d’intégration et compilation de paquets ou d’images conteneur. Chaque tâche renvoie son état à la demande de fusion, et les règles de protection de branche peuvent en bloquer la fusion tant que tous les contrôles requis ne sont pas réussis. Les pipelines répètent souvent les mêmes tests sur une matrice de systèmes d’exploitation et de versions Python, puis relancent toute la suite sur la branche principale après chaque fusion. La rapidité fait partie de la pratique : l’Extreme Programming de Beck fixait un objectif de dix minutes pour compiler le système entier et exécuter tous les tests, car les compilations plus longues sont lancées moins souvent.

CI pour l’apprentissage automatique#

Les projets ML ajoutent leurs propres contrôles. Les tests de données vérifient que les nouvelles données d’entraînement respectent le schéma attendu, que chaque fichier d’étiquettes est analysable et qu’aucune image ne figure à la fois dans les ensembles d’entraînement et de validation, ce qui entraînerait une fuite de données. Un test de fumée entraîne le modèle pendant une époque sur un minuscule jeu de données pour détecter les erreurs de forme et les plantages en quelques minutes. Les tests qui comparent les sorties du modèle fixent les graines aléatoires et tolèrent de petits écarts numériques, car les noyaux GPU et l’ordre de chargement des données peuvent modifier les résultats en virgule flottante d’une exécution à l’autre. Une porte de qualité évalue le modèle sur un ensemble de validation fixe et fait échouer la compilation si une métrique comme la précision moyenne moyenne (mAP) descend sous un seuil ; les tests d’export vérifient que les versions du modèle au format ONNX ou TensorRT se chargent toujours et obtiennent des scores comparables à l’original. L’entraînement complet est lent et les exécuteurs GPU sont coûteux ; les équipes exécutent donc généralement des contrôles rapides à chaque demande de fusion et réservent le réentraînement complet et le déploiement du modèle aux exécutions planifiées ou sur la branche principale. Des outils de gestion des versions comme DVC permettent à chaque tâche de récupérer la version exacte du jeu de données dont elle a besoin.

Le mode benchmark d’Ultralytics YOLO fonctionne comme une telle porte de qualité : lorsque verbose est défini sur un nombre flottant comme 0.216, il génère une erreur si un export échoue ou si le mAP_50-95 d’un format exporté n’atteint pas ce seuil ; la CI du dépôt Ultralytics l’utilise pour tester les exports YOLO26 sur des exécuteurs Linux, macOS et ARM. Un flux de travail GitHub Actions minimal associe les tests unitaires à cette porte de qualité :

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

Chaque demande de fusion et chaque envoi vers main lance la tâche sur un nouvel exécuteur Ubuntu. Un test unitaire en échec ou un modèle ONNX dont le score atteint ou reste sous le seuil sur le petit jeu de données COCO8 fait passer le contrôle au rouge avant la fusion de la modification.

CI, CD, MLOps et entraînement continu#

• Livraison continue (CD) : Prend les compilations validées par la CI et les maintient prêtes à être publiées, en les déployant souvent automatiquement dans un environnement de préproduction. Le déploiement continu va plus loin et met en production chaque modification validée.
• MLOps : Discipline plus vaste qui associe CI et CD à la gestion des versions des données, au déploiement des modèles, à la surveillance et au réentraînement tout au long du cycle de vie du ML.
• Entraînement continu (CT) : Réentraîne et redéploie automatiquement un modèle lorsque de nouvelles données arrivent ou que la surveillance détecte une dérive. Les niveaux de maturité MLOps de Google situent le réentraînement automatisé au niveau 1 et la CI/CD automatisée du pipeline d’entraînement lui-même au niveau 2.