CRACI vs Jenkins

En bref

Jenkins se présente comme « the leading open source automation server », et à juste titre : il s'exécute partout où vous l'installez, répartit le travail sur autant de machines que vous lui en donnez, et plus de 2 300 plugins de la communauté le relient à presque n'importe quel outil. Si les builds doivent rester entièrement dans votre propre réseau, ou si vos pipelines dépendent de plugins sans équivalent ailleurs, Jenkins est difficile à remplacer.

CRACI est un produit d'un autre type. C'est un runner géré pour GitHub Actions : pas de contrôleur à mettre à niveau ni d'agent à corriger. Pendant l'exécution de chaque job, CRACI enregistre chaque dépendance externe récupérée par le build, applique une politique de trafic sortant au réseau du build, et produit à partir de cet enregistrement des SBOM, des données de provenance et une surveillance des vulnérabilités. Jenkins peut en faire une partie grâce à des plugins que vous choisissez, configurez et maintenez à jour ; CRACI fait du runner lui-même l'enregistrement de sécurité.

Un point pratique avant tout. CRACI prend en charge GitHub Actions aujourd'hui, avec Jenkins et GitLab CI sur la roadmap, sans date. Pour s'exécuter sur CRACI dès maintenant, un pipeline Jenkins doit d'abord devenir un workflow GitHub Actions.

En un coup d'œil

Ce que Jenkins fait bien

Il s'exécute là où vous en avez besoin. Jenkins s'exécute sur vos propres serveurs, dans votre propre réseau, sans plan de contrôle SaaS. Les agents peuvent être des machines Linux, Windows, macOS ou toute autre machine que vous pouvez connecter : un même contrôleur peut donc construire un backend, un client de bureau et un firmware.

Des plugins pour presque tout. L'écosystème de plugins est la plus grande force de Jenkins. Gestion du code source, outils de build, rapports de tests, cibles de déploiement et scanners de sécurité ont tous des plugins, et les équipes aux chaînes d'outils inhabituelles constatent souvent que Jenkins est la seule CI qui les prend déjà en charge.

Aucun coût de licence. Jenkins est gratuit et open source. Vos coûts sont les machines sur lesquelles il s'exécute et le temps que votre équipe passe à le faire tourner.

Ce qui distingue CRACI

Rien à exploiter

Une installation Jenkins est un système dont votre équipe est propriétaire : le contrôleur, les agents, les plugins et les mises à niveau. Le projet Jenkins publie souvent des avis de sécurité pour le cœur et les plugins, plusieurs par mois en 2026 (par exemple les 2 et 16 septembre et le 5 août), et les appliquer vous revient. CRACI exécute les jobs sur des runners gérés, dans des machines virtuelles isolées, avec une VM par job : il n'y a donc aucun serveur de build à corriger de votre côté.

La SBOM vient du build

Sur Jenkins, une SBOM provient d'un plugin ou d'une étape de scan que vous ajoutez, qui lit généralement les manifestes et les lockfiles après coup. Les builds en font souvent plus que ce que disent ces fichiers : des scripts d'installation téléchargent du code, des scripts de build récupèrent des éléments au moment du build, et des caches restaurent des paquets qu'aucun lockfile ne mentionne. CRACI voit ce trafic, car il est le runner. Un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les sources de paquets, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, et les preuves de dépendances suivent les caches CI. Chaque SBOM CycloneDX ou SPDX indique son niveau de complétude, par job et par cache.

Une politique sur le réseau du build

Sur Jenkins, contrôler ce qu'un build peut joindre passe par des règles de pare-feu ou des proxys autour de vos agents, que vous concevez et maintenez. Sur CRACI, une politique de trafic sortant sur chaque job décide quels hôtes il peut joindre : refus ou autorisation par défaut, avec 24 presets de sources logicielles intégrés et des sources personnalisées typées, validée avant le démarrage du job. Les politiques bloquent tout en cas d'échec, et les violations déclenchent une alerte.

Surveiller ce qui a été livré

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, continue de réévaluer les SBOM surveillées à mesure que paraissent les avis de sécurité, et montre quels builds passés contenaient une dépendance vulnérable : vous connaissez ainsi la période pendant laquelle vous avez été exposé.

Une tarification à la minute de build

Jenkins n'a pas de frais de licence, mais le faire tourner n'est pas gratuit : vous payez le contrôleur et les agents, qu'ils soient inactifs ou occupés, ainsi que les personnes qui les maintiennent à jour. CRACI ne facture que les minutes de build : $0.002 par minute vCPU ($0.004 pour un runner par défaut à 2 vCPU), décompté à la seconde, sans abonnement mensuel ni frais par SBOM.

Lequel choisir

• Restez sur Jenkins si les builds doivent s'exécuter entièrement sur votre propre infrastructure, si vous dépendez de plugins sans équivalent GitHub Actions, si vous avez besoin de builds Windows ou macOS, ou si vous avez les personnes pour le faire tourner et que cela fonctionne.
• Choisissez CRACI si votre code est sur GitHub, que vous migrez ou êtes prêt à migrer vos pipelines vers GitHub Actions, et que vous voulez cesser d'exploiter des serveurs de build tout en obtenant un enregistrement de ce qui est entré dans chaque release.
• Utilisez les deux pendant une migration progressive : faites passer les nouveaux projets et les pipelines Linux sur GitHub Actions avec CRACI, et laissez les jobs Jenkins stables où ils sont.

Soyez clair sur ce à quoi vous renoncez en choisissant CRACI aujourd'hui. Il n'exécute que des jobs Linux, avec Windows et macOS sur la roadmap ; les runners hébergés par le client figurent sur la roadmap pour Enterprise ; et les pipelines Jenkins doivent devenir des workflows GitHub Actions tant que la prise en charge de Jenkins n'est pas disponible.

Pour les produits réglementés

Des cadres tels que le Cyber Resilience Act de l'UE attendent des fabricants qu'ils sachent ce que contient chaque release et qu'ils en traitent les vulnérabilités, avec des obligations de signalement à partir de septembre 2026. Sur Jenkins, ces preuves proviennent des plugins et scanners que vous intégrez à chaque pipeline. CRACI les produit à partir de l'enregistrement du build et exporte les SBOM en CycloneDX ou SPDX. Il automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont une entreprise a besoin pour sa démarche CRA plus large ; aucun des deux outils ne rend un produit conforme à lui seul.

Migrer un pipeline vers CRACI

GitHub Actions Importer, l'outil de GitHub, convertit les pipelines Jenkins en workflows GitHub Actions. GitHub vise une conversion automatique de 80 % de chaque workflow et indique que tout workflow converti doit être inspecté avant de s'exécuter en production : prévoyez donc un peu de travail manuel. Dès qu'un pipeline s'exécute sous forme de workflow GitHub Actions, il s'exécute sur CRACI avec une seule ligne :

runs-on: craci

Les exécutions apparaissent toujours dans l'interface GitHub. En savoir plus sur la génération de SBOM au build, voir les alternatives à Jenkins, comparer les plateformes CI/CD ou consulter les tarifs.