Artifact dans le développement d'applications : ce que c'est, types et comment gérer

Qu'est-ce qu'un Artifact dans le développement

Un artifact (artefact de build) est le résultat de la compilation du code source, prêt à être déployé ou utilisé comme dépendance. Le processus de build transforme les fichiers sources (Java, Kotlin, Swift, C++ et autres) en paquets binaires qui peuvent être exécutés sur un appareil ou un serveur cible.

Le concept d'artefact va au-delà des fichiers exécutables. Par exemple, une bibliothèque JAR est un artefact utilisé comme dépendance dans d'autres projets. Une image Docker est un artefact contenant l'application et son environnement. Même un rapport de couverture de tests peut être considéré comme un artefact dans le contexte CI/CD.

Le développement moderne dans les grandes entreprises implique la gestion de centaines de milliers d'artefacts. Google DORA lie la maturité de la gestion des artefacts à l'efficacité globale du DevOps — les équipes utilisant des registres d'artefacts publient des versions plus rapidement et rencontrent moins de problèmes de déploiement.

Cycle de vie d'un artefact

Chaque artefact passe par plusieurs étapes : création (build, compilation), validation (tests, vérifications de sécurité), stockage (registre d'artefacts), distribution (publication pour téléchargement) et archivage ou suppression (lorsque la version devient obsolète).

Types d'artefacts dans le développement mobile

Différentes plateformes et technologies génèrent différents formats d'artefacts. Comprendre les formats est essentiel pour configurer correctement le pipeline CI/CD et choisir un système de stockage.

Artefacts Android

APK (Android Package Kit) est le format traditionnel de paquet d'installation. AAB (Android App Bundle) est un format moderne pour publier sur Google Play, contenant uniquement les ressources nécessaires à un appareil spécifique. AAB réduit la taille de l'application installée de 15 à 20 % en moyenne par rapport à un APK universel.

Artefacts iOS

IPA (iOS App Store Package) est une archive contenant le code et les ressources pour les appareils iOS. XCArchive est un artefact intermédiaire créé par Xcode, à partir duquel l'IPA final est exporté. dSYM est un fichier de symboles de débogage nécessaire à la symbolisation des journaux de crash.

Artefacts de projets serveur et bibliothèques

JAR (Java ARchive) — pour les bibliothèques Java/Kotlin. AAR (Android ARchive) — pour les bibliothèques Android avec ressources. Images Docker — artefacts conteneurs pour microservices. Chaque type a son propre registre et ses règles de gestion de versions.

Artefacts dans le pipeline CI/CD

Les artefacts sont le lien entre les étapes du pipeline. Chaque étape consomme les artefacts de la précédente et en produit de nouveaux. Comprendre ce flux est essentiel pour configurer un pipeline CI/CD efficace.

Flux des artefacts dans le pipeline

Un flux typique comprend : commit -> le serveur de build compile le code et crée un artefact non optimisé -> l'artefact de test est utilisé pour exécuter les tests -> en cas de succès, un artefact de release est créé -> il est signé et publié dans le registre d'artefacts -> l'artefact est récupéré du registre pour le déploiement en staging et en production. Chaque transition entre les étapes est accompagnée d'une vérification d'intégrité et de conformité aux exigences.

Artefacts intermédiaires et finaux

Le pipeline peut créer plusieurs artefacts à différentes étapes. Les artefacts de débogage contiennent des informations de débogage, les non optimisés sont construits rapidement pour les tests, les artefacts de release sont finaux, avec optimisation et obscurcissement. Le système CI doit être capable de les distinguer et d'appliquer des politiques de rétention appropriées pour chaque type.

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

Cache vs Artifact

Il est important de distinguer le cache de dépendances des artefacts de build. Le cache (cache Gradle, cache CocoaPods) accélère les builds répétées mais n'est pas destiné au déploiement. Les artefacts sont le produit final, prêt à être distribué. Définissez un TTL de plusieurs jours pour le cache et de semaines ou mois pour les artefacts.

Dépôts d'artefacts

Les artefacts ne doivent pas être stockés sur le serveur de build — des systèmes spécialisés existent à cet effet. Un Repository Manager fournit un stockage centralisé, une indexation, un contrôle d'accès et une intégration avec les outils CI/CD.

Registres d'artefacts populaires

JFrog Artifactory — un gestionnaire universel prenant en charge Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — une alternative open source prenant en charge les formats principaux. GitHub Packages — un registre intégré dans GitHub, pratique pour les équipes utilisant déjà GitHub. GitLab Container Registry — pour les images Docker.

Critères de sélection du registre

Facteurs clés : formats pris en charge, modèle de licence (open source/entreprise), intégration avec le CI/CD existant, capacités de réplication entre régions, disponibilité de politiques de nettoyage automatique des anciennes versions et rapports de conformité.

// Pipeline Jenkins — publication d'APK dans Artifactory
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

Versionnage et nomenclature

Une stratégie appropriée de versionnage des artefacts est essentielle pour la reproductibilité des builds et le suivi des modifications. Sans versionnage, il est impossible de déterminer quelle version du code a causé un problème en production.

Versionnage sémantique (SemVer)

La norme MAJOR.MINOR.PATCH : MAJOR change avec des modifications d'API incompatibles, MINOR avec des ajouts de fonctionnalités rétrocompatibles, PATCH avec des corrections de bugs rétrocompatibles. Pour CI/CD, des métadonnées de build sont ajoutées à la version : 2.4.1+build.20260703.1. Cela permet de déterminer exactement quel commit a produit un artefact spécifique et quand il a été créé.

Traçabilité — lien Git

Chaque artefact doit contenir des métadonnées sur son origine : SHA du commit, numéro de build CI, nom de branche, date de build. Ces informations sont enregistrées dans le manifeste de l'artefact et permettent de reconstruire le contexte de sa création à tout moment. Sans traçabilité, travailler avec des artefacts devient une devinette de versions, ce qui est inacceptable pour les systèmes de production ayant des exigences d'audit.

Nomenclature des artefacts

Convention de nommage : {project}-{module}-{version}.{ext}. Par exemple : messaging-sdk-2.4.1.aar ou app-release-2.4.1.apk. Le serveur de build peut générer automatiquement une version basée sur un tag Git ou le numéro de build du système CI.

• Utilisez un tag Git comme source de version — cela lie l'artefact à un état de code spécifique
• Ajoutez le SHA du commit aux métadonnées pour une identification précise lors du débogage
• Configurez une politique de rétention — conservez les N dernières versions, archivez le reste

Snapshot vs Release

Dans les registres d'artefacts Maven/Gradle, on distingue les versions de release (fixes, immuables) et les versions snapshot (développement en cours, peuvent être écrasées). Dans les pipelines CI/CD, les artefacts snapshot sont pratiques pour le développement, mais en production, seules les versions de release doivent être utilisées.

Sécurité des artefacts

Les artefacts sont un élément clé de la chaîne d'approvisionnement logicielle. La compromission d'un artefact peut entraîner l'introduction de code malveillant en production. La sécurité des artefacts comprend plusieurs niveaux de protection.

Signature des artefacts

Les fichiers APK sont signés avec jarsigner ou apksigner ; les IPA sont signés avec un certificat Apple ; les images Docker sont signées avec Content Trust (Notary) de Docker. La signature garantit l'intégrité et confirme l'auteur de l'artefact. Le pipeline CI/CD doit inclure la vérification des signatures de toutes les dépendances tierces.

Analyse des vulnérabilités

Avant publication, l'artefact est vérifié par des scanners automatisés : Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Ils analysent les dépendances incluses, les versions des bibliothèques utilisées et les vulnérabilités CVE connues. Si une vulnérabilité critique est détectée, la release est immédiatement bloquée jusqu'à ce qu'elle soit corrigée par les développeurs.

Niveaux de chaîne d'approvisionnement

SLSA (Supply chain Levels for Software Artifacts) est un cadre de sécurité définissant des niveaux de confiance de SLSA 1 (de base) à SLSA 4 (maximum). Le serveur de build doit générer une attestation de provenance — une déclaration signée cryptographiquement sur comment et à partir de quel code l'artefact a été construit.