Artefact
Infrastructure
Produit fini d'une chaîne de construction logicielle (binaire, archive, paquet, image de conteneur), stocké et versionné pour être déployé tel quel. C'est lui qui part en production, pas le code source qui l'a engendré.
Formes courantes : Une archive JAR, une image de conteneur, un paquet .deb ou .rpm, une wheel Python, un bundle JavaScript minifié, voire un rapport de tests ou une documentation générée. Tout ce qu'un pipeline produit et qu'on veut conserver mérite le nom.
Immuable et identifiable : Une fois publié, un artefact ne se modifie plus : on en publie un nouveau avec une autre version. Son empreinte cryptographique (SHA-256 en général) garantit que ce qui est déployé est bien ce qui a été construit.
Construire une fois, déployer partout : Le même artefact est promu de la recette à la préproduction puis à la production, sans reconstruction intermédiaire. Reconstruire « à l'identique » pour la production est une promesse que les dépendances ne tiennent jamais tout à fait, et l'écart se découvre toujours au meilleur endroit : en production, un vendredi soir.
Traçabilité : Un artefact sérieux s'accompagne de sa provenance (commit, pipeline, dépendances) et souvent d'une signature. C'est ce qui permet de répondre à la question « qu'est-ce qui tourne exactement en prod ? » sans ouvrir une enquête.
L'autre artefact : En réponse à incident, le mot désigne tout autre chose : la trace laissée sur un système et collectée comme preuve (journaux, ruches de registre, image mémoire, fichier temporaire). Même idée d'objet fabriqué puis conservé, à ceci près que personne n'avait l'intention de le produire. Le contexte tranche sans peine ; le lecteur pressé, moins.
Ce qui arrive si on s'en passe
Sans artefact stocké et versionné, chaque déploiement reconstruit le logiciel à partir du code source, souvent directement sur la machine cible. Ce qui part en production n'est alors plus un objet unique et identifiable : deux environnements peuvent exécuter des binaires différents issus du même commit, selon les dépendances récupérées au moment de la construction. Aucune empreinte ne permet de vérifier que le composant en service est bien celui qui a été testé, analysé ou signé ; une dépendance altérée ou une modification locale entre ainsi sans laisser de trace. La reprise en souffre aussi : revenir à une version antérieure oblige à la reconstruire, sans garantie d'obtenir le même résultat, et l'analyse après un incident ne dispose d'aucune référence fiable à laquelle comparer ce qui tourne.
Explication de la marmotte
Quand des développeurs écrivent un programme, ils produisent d'abord une sorte de recette : du texte que l'ordinateur ne sait pas utiliser tel quel. Une machine se charge ensuite de « cuisiner » cette recette pour fabriquer le produit fini, prêt à être installé. Ce produit fini, emballé et étiqueté avec un numéro de version, c'est l'artefact. Imagine une boulangerie industrielle : le gâteau sort du four, on le met en boîte, on colle une étiquette, et c'est exactement cette boîte qu'on livre à tous les magasins. Personne ne refait le gâteau en route. Comme ça, si un client se plaint, on sait précisément quel lot a été livré.
Où ce terme est utilisé
- SLSA : niveaux Build, provenance in-toto et vérification (20 occurrences)
- Prouver qu'un programme a tourné : AmCache, ShimCache et leurs pièges (16 occurrences)
- SBOM pour inventorier les composants réellement exécutés (11 occurrences)
- Vérifier une chaîne de compilation reproductible (11 occurrences)
- Intégrer un HSM à la signature CI/CD (10 occurrences)
- Pourquoi les builds reproductibles échouent souvent (10 occurrences)
- Signer et vérifier les artefacts de build (10 occurrences)
- Attaques supply chain et protection des dépendances (8 occurrences)
- Générer un SBOM CycloneDX dans un pipeline CI (8 occurrences)
- Signer numériquement : preuve publique, politiques de vérification (7 occurrences)